Programmation Temps Réel Introduction Alberto Dassatti Reconfigurable and Embedded Digital Systems Institute Haute Ecole d’Ingénierie et de Gestion du Canton de Vaud Original work is (C) by Yann Thoma, 2015 This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License Septembre 2016 A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 1 / 45 Introduction Introduction Un système temps réel est un système pour lequel le temps d’arrivée du résultat est aussi important que le résultat lui-même Par opposition aux systèmes transformationnels A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 2 / 45 Introduction Structure typique: Contrôle Système temps réel système de contrôle gestion des entrées gestion des sorties Environnement A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 3 / 45 Introduction Structure typique: Prédiction données prédiction résultat A partir des données le résultat doit être fourni au plus tard après un temps T A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 4 / 45 Introduction Définition Abrial-Bourgne: Un système fonctionne en temps réel s’il est capable d’absorber toutes les informations d’entrée sans qu’elles soient trop vieilles pour l’intérêt qu’elles représentent, et par ailleurs, de réagir à celles-ci suffisamment vite pour que cette réaction ait un sens. A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 5 / 45 Introduction Définition Abrial-Bourgne: Un système fonctionne en temps réel s’il est capable d’absorber toutes les informations d’entrée sans qu’elles soient trop vieilles pour l’intérêt qu’elles représentent, et par ailleurs, de réagir à celles-ci suffisamment vite pour que cette réaction ait un sens. Adage: Un résultat juste mais hors délai est un résultat faux. A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 5 / 45 Introduction Exemple Pilote automatique en avionique Entrées: capteurs (altitude, vitesse, ...) Sorties: actuateurs (arrivée de carburant, empennage) Traitement: calcul de la puissance à fournir, et empennage Décomposition en tâches A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 6 / 45 Echéances Catégories de systèmes temps réel Les contraintes de temps peuvent être de type: Temps réel strict (hard) Temps réel ferme (firm) Temps réel mou, ou souple (soft) Un même système peut être soumis à des contraintes de différents types A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 7 / 45 Echéances Echéance stricte Le respect du délai est critique Le système est compromis si l’échéance est dépassée Valeur échéance Temps A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 8 / 45 Echéances Echéance stricte: Exemples Pilote automatique Contrôle aérien (skyguide) Gestion du freinage d’une voiture Pacemaker A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 9 / 45 Echéances Echéance ferme Le respect du délai est essentiel Le résultat ne sert à rien si son échéance est dépassée Valeur échéance Temps A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 10 / 45 Echéances Echéance ferme: Exemples Transaction boursière Jeux d’échec avec horloge Prévision météo Confection d’horaire A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 11 / 45 Echéances Echéance molle La pertinence du résultat décrémente après l’échéance La pénalité liée au non respect de l’échéance n’est pas catastrophique Valeur échéance Temps A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 12 / 45 Echéances Echéance molle: Exemples Flux vidéo A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel VoIP Septembre 2016 13 / 45 Echéances Ordres de grandeur Temps Exemple nanoseconde - O(ns) Temps d’accès à une RAM (5-80ns) Durée entre deux ticks d’horloge d’un processeur Pentium (1GHz) Fréquence de 1GHz (109 Hz) microseconde - O(µs) Traitement dans un noyau de système d’exploitation (changement de contexte, interruption matérielle) Systèmes utilisant des radars (navigation, détection de mouvement, etc.) Transmission sur des bus de terrain, transmission radio Fréquence de 1 MHz (106 Hz) milliseconde - O(ms) Temps d’accès à un disque dur SCSI ou IDE (5-20 ms) La durée d’échantillonnage du son, protocoles de télécommunication Fréquence de 1 KHz (103 Hz) seconde (s) - O(s) Systèmes de visualisation humain, (temps durant lequel l’oeil peut "intégrer" 25 images au plus) applications multimédia temps de réponse des applications informatiques (accès DB, compilation, etc.) Fréquence de 1 Hz L’heure (h) - O(h) Applications de surveillance de réactions chimiques, surveillance de données météorologiques Le mois, l’année - O(m, a) Systèmes de navigation de sonde spatiale Quel lien avec le temps réel? A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 14 / 45 Déterminisme Déterminisme Les systèmes temps réel doivent posséder 3 caractéristiques fondamentales Déterminisme logique (aspect fonctionnel / spécification) Les mêmes entrées appliquées au système produisent les mêmes résultats. Déterminisme temporel (aspect dynamique / simulation) Respect des contraintes temporelles (échéances) Fiabilité (aspect matériel / datasheet) Le système répond à des contraintes de disponibilité (matériel/logiciel). Par conséquent, le comportement d’un système temps-réel doit être prédictible Maîtrise des temps de latence et de leurs variations (gigue) Un système temps-réel n’est PAS un système "qui va vite", mais un système qui satisfait à des contraintes temporelles. A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 15 / 45 Déterminisme Un système temps réel n’est pas forcément Rapide (fast) Tolérant aux fautes (fault-tolerant) Sûr (safe) A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 16 / 45 Déterminisme Un système temps réel n’est pas forcément Rapide (fast) Tolérant aux fautes (fault-tolerant) Sûr (safe) mais doit souvent l’être A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 16 / 45 Déterminisme Prédictibilité La prédictibilité d’un système temps réel est ESSENTIELLE, et même critique Obligatoire pour prévoir le respect des contraintes temporelles Le système doit donc être déterministe Eléments clé: Code écrit par le programmeur Structure du noyau du système d’exploitation Structure du processeur et des périphériques A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 17 / 45 Déterminisme Prédictibilité Important: Savoir identifier les facteurs d’imprédictibilité But (1): évaluer le pire temps de réponse des tâches à effectuer But (2): Baser la mise au point du système sur ces temps de réponse A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 18 / 45 Déterminisme Prédictibilité - temps de réponse int a; float b; if ( a != 3 ){ b++; } else{ b = b / 1.2; } A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 19 / 45 Déterminisme Prédictibilité - temps de réponse int a; float b; if ( a != 3 ){ b++; } else{ b = b / 1.2; } X86-64: 1 instruction, < 1 cycle Hardware FP: 10-12 cycle hardware divide Soft FP (Atmega, PIC, ARM, etc..): 2000 instructions! A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 19 / 45 Déterminisme Prédictibilité - temps de réponse int i; for(i=0;i<n;i++) faireQuelqueChose(); A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 20 / 45 Déterminisme Prédictibilité - temps de réponse int i; for(i=0;i<n;i++) faireQuelqueChose(); n peut prendre n’importe quelle valeur A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 20 / 45 Déterminisme Prédictibilité - temps de réponse int i; for(i=0;i<n;i++) faireQuelqueChose(); n peut prendre n’importe quelle valeur unsigned int factorielle(int n){ if (n==1) return n; else return n*factorielle(n-1); } A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 20 / 45 Déterminisme Prédictibilité - mémoire char *uneChaine=(char *)malloc(1000*sizeof(char)); ajouterNoeud(maListeChainee); A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 21 / 45 Déterminisme Prédictibilité - mémoire char *uneChaine=(char *)malloc(1000*sizeof(char)); ajouterNoeud(maListeChainee); unsigned int factorielle(int n) { if (n==1) return n; else return n*factorielle(n-1); } A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 21 / 45 Déterminisme Prédictibilité - mémoire char *uneChaine=(char *)malloc(1000*sizeof(char)); ajouterNoeud(maListeChainee); unsigned int factorielle(int n) { if (n==1) return n; else return n*factorielle(n-1); } La pile (stack) grandit! A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 21 / 45 Déterminisme Prédictibilité - Appels système Le temps d’exécution n’est pas forcément connu Exemple: Allocation mémoire char *uneChaine=(char *)malloc(1000*sizeof(char)); Ecriture dans un fichier printf("Bonjour les amis\n"); Communication Ethernet send(socket, buffer, bufferLength, 0); A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 22 / 45 Déterminisme Prédictibilité - mémoire Gestion de la mémoire Problèmes avec mémoire paginée/segmentée Lenteur de l’accès Défaut de page non prévisible Verrous/Sémaphores Problème d’inversion de priorité Ce problème sera abordé durant le cours A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 23 / 45 Déterminisme Prédictibilité - matériel Interruptions Générées par les périphériques Problème: non connaissance de leurs temps d’arrivée Gestion possible: Masquage des interruptions Pas d’indéterminisme Mais: scrutation des périphériques Donc: consommation inutile de temps CPU Masquage, sauf le timer Une tâche périodique pour scruter les périphériques Scrutation active uniquement par cette tâche Autorisation des interruptions Placer du code minimal dans les routines d’interruption Attente passive des tâches de traitement Temps de traitement de la routine d’interruption négligeable A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 28 / 45 images from http://tjliu.myweb.hinet.net Déterminisme Prédictibilité - matériel DMA Le processeur délègue au contrôleur DMA des transferts mémoire Ils partagent le bus mémoire Problème: arbitrage, et délai potentiel A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 30 / 45 Déterminisme Prédictibilité - matériel Mémoire cache Accélère les accès mémoire Mais: problème de la borne du temps d’accès maximal Génère de l’imprédictibilité processeur mémoire cache mémoire principale processeur mémoire cache mémoire principale A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 31 / 45 Déterminisme Hiérarchie mémoire A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 32 / 45 Déterminisme Entrées-sorties A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 33 / 45 Déterminisme Entrées-sorties A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 34 / 45 Déterminisme Prédictibilité - que faire? Programmation: concepts à appliquer Absence de structures de données dynamiques Absence de récursion Boucles bornées en temps Connaissance du matériel Connaissance du système A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 35 / 45 Déterminisme Prédictibilité - que faire? Programmation: concepts à appliquer Absence de structures de données dynamiques Absence de récursion Boucles bornées en temps Connaissance du matériel Connaissance du système Prendre des mesures (benchmarking)! http://www.ptxdist.org/development/kernel/ arm-benchmarks-20100729_en.html A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 35 / 45 Déterminisme Prédictibilité - évaluer Images from http://uuu.enseirb.fr/~kadionik/embedded/ linux_realtime/linux_realtime2.html A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 38 / 45 Environnement Décomposition Un système temps réel souvent est décomposé en tâches Séparation des traitements Meilleure utilisation du processeur Meilleure fiabilité en cas de surcharge A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 39 / 45 Environnement Système d’exploitation Un système temps réel peut fonctionner avec ou sans système d’exploitation (OS) Sans Un exécutif temps réel fournit un micro-noyau pour l’ordonnancement (si multi-tâche) Avec Possibilité d’avoir une interface graphique Gestion de fichiers L’OS doit être temps réel A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 40 / 45 Environnement Langages pour le temps réel Principaux critères de choix: Déterminisme temporel et logique Fiabilité Présence d’abstractions "temps-réel" Tâches, synchronisation, horloges, etc. Accès aisé aux ressources de bas niveau Portabilité, normalisation Compilation croisée (cross-compilation) Performances Deux approches: langages bas niveau ou haut niveau A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 41 / 45 Environnement Langages pour le temps réel (2) Langages de haut niveau: Ada 95 Langage conçu, entre autre, pour le support des applications temps-réel Abstraction temps-réel: tâche, interruption, ordonnancement (priorité fixe et dynamique), synchronisation par sémaphore, timer et gestion du temps, outils de communication basés sur les rendez-vous Interface et syntaxe normalisé par ISO Langage très portable Adapté à la production de logiciels volumineux Langage complexe A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 42 / 45 Environnement Langages pour le temps réel (3) Langages de bas niveau: C/C++, assembleur Largement diffusés et utilisés à ce jour Accès direct aux ressources de bas niveau Idéal pour les I/O (entrées/sorties) Doit être couplé avec les services du système (synchronisation,ordonnancement) Recours aux librairies Langage généralement restreint Comportement temporel déterministe facile à évaluer Peu adapté aux logiciels complexes et/ou volumineux Pas vraiment normalisé, donc peu portable Effort de standardisation par POSIX A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 43 / 45 Lois de Murphy Lois de Murphy relatives aux systèmes temps-réel (1) Murphy’s General Law If something can go wrong, it will go wrong. Murphy’s Constant Damage to an object is proportional to its value. Naeser’s Law One can make something bomb-proof, not jinx-proof. Troutman Postulates 1 2 Any software bug will tend to maximize the damage. The worst software bug will be discovered six months after the field test. A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 44 / 45 Lois de Murphy Lois de Murphy relatives aux systèmes temps-réel (2) Green’s Law If a system is designed to be tolerant to a set of faults, there will always exist an idiot so skilled to cause a nontolerated fault. Corollary Dummies are always more skilled than measures taken to keep them from harm. Johnson’s First Law If a system stops working, it will do it at the worst possible time. Sodd’s Second Law Sooner or later, the worst possible combination of circumstances will happen. Corollary A system must always be designed to resist the worst possible combination of circumstances. A. Dassatti (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2016 45 / 45