Programmation Temps RéelIntroduction
Yann Thoma
Reconfigurable and Embedded Digital Systems InstituteHaute Ecole d’Ingénierie et de Gestion du Canton de Vaud
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License
Septembre 2017
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 1 / 45
Introduction
Introduction
Un système temps réel est un système pour lequel le tempsd’arrivée du résultat est aussi important que le résultat lui-mêmePar opposition aux systèmes transformationnels
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 2 / 45
Introduction
Structure typique: Contrôle
Système temps réel
gestion des entrées
système de contrôle
gestion des sorties
Environnement
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 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 untemps T
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 4 / 45
Introduction
Définition
Abrial-Bourgne:Un système fonctionne en temps réel s’il est capable d’absorbertoutes les informations d’entrée sans qu’elles soient trop vieillespour 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.
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 5 / 45
Introduction
Exemple
Pilote automatique en avioniqueEntrées: capteurs (altitude, vitesse, ...)Sorties: actuateurs (arrivée de carburant, empennage)Traitement: calcul de la puissance à fournir, et empennageDécomposition en tâches
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 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 dedifférents types
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 7 / 45
Echéances
Echéance stricte
Le respect du délai est critiqueLe système est compromis si l’échéance est dépassée
Valeur
Temps
échéance
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 8 / 45
Echéances
Echéance stricte: Exemples
Pilote automatique Contrôle aérien (skyguide)
Gestion du freinage d’une voiture Pacemaker
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 9 / 45
Echéances
Echéance ferme
Le respect du délai est essentielLe résultat ne sert à rien si son échéance est dépassée
Valeur
Temps
échéance
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 10 / 45
Echéances
Echéance ferme: Exemples
Transaction boursière Jeux d’échec avec horloge
Prévision météo Confection d’horaire
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 11 / 45
Echéances
Echéance molle
La pertinence du résultat décrémente après l’échéanceLa pénalité liée au non respect de l’échéance n’est pascatastrophique
Valeur
Temps
échéance
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 12 / 45
Echéances
Echéance molle: Exemples
Flux vidéo VoIP
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 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 (109Hz)
microseconde - O(µs) Traitement dans un noyau de système d’exploitation (changement de contexte, interruptionmatérielle)Systèmes utilisant des radars (navigation, détection de mouvement, etc.)Transmission sur des bus de terrain, transmission radioFré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écommunicationFré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 auplus)applications multimédiatemps 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?
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 14 / 45
Déterminisme
Déterminisme
Les systèmes temps réel doivent posséder 3 caractéristiquesfondamentales
Déterminisme logique (aspect fonctionnel / spécification)Les mêmes entrées appliquées au système produisent les mêmesré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", maisun système qui satisfait à des contraintes temporelles.
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 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)
mais doit souvent l’être
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 16 / 45
Déterminisme
Prédictibilité
La prédictibilité d’un système temps réel est ESSENTIELLE, etmême critiqueObligatoire pour prévoir le respect des contraintes temporellesLe système doit donc être déterministeEléments clé:
Code écrit par le programmeurStructure du noyau du système d’exploitationStructure du processeur et des périphériques
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 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 à effectuerBut (2): Baser la mise au point du système sur ces temps deréponse
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 18 / 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 cycleHardware FP: 10-12 cycle hardware divideSoft FP (Atmega, PIC, ARM, etc..): 2000 instructions!
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 19 / 45
Déterminisme
Prédictibilité - temps de réponse
for(int i=0;i
Déterminisme
Prédictibilité - mémoire
unsigned int factorielle(int n) {if (n==1)
return n;else
return n*factorielle(n-1);}
La pile (stack) grandit!
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 21 / 45
Déterminisme
Prédictibilité - Appels système
Le temps d’exécution n’est pas forcément connuExemple:
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);
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 22 / 45
Déterminisme
Prédictibilité - mémoire
Gestion de la mémoireProblèmes avec mémoire paginée/segmentée
Lenteur de l’accèsDéfaut de page non prévisible
Verrous/SémaphoresProblème d’inversion de priorité
Ce problème sera abordé durant le cours
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 23 / 45
Déterminisme
Prédictibilité - matériel
InterruptionsGénérées par les périphériquesProblème: non connaissance de leurs temps d’arrivéeGestion possible:
Masquage des interruptionsPas d’indéterminismeMais: scrutation des périphériquesDonc: consommation inutile de temps CPU
Masquage, sauf le timerUne tâche périodique pour scruter les périphériquesScrutation active uniquement par cette tâche
Autorisation des interruptionsPlacer du code minimal dans les routines d’interruptionAttente passive des tâches de traitementTemps de traitement de la routine d’interruption négligeable
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 28 / 45
images from http://tjliu.myweb.hinet.net
Déterminisme
Prédictibilité - matériel
DMALe processeur délègue au contrôleur DMA des transferts mémoireIls partagent le bus mémoireProblème: arbitrage, et délai potentiel
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 30 / 45
http://tjliu.myweb.hinet.net
Déterminisme
Prédictibilité - matériel
Mémoire cacheAccélère les accès mémoireMais: problème de la borne du temps d’accès maximalGénère de l’imprédictibilité
processeur mémoire cache mémoire principale
processeur mémoire cache mémoire principale
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 31 / 45
Déterminisme
Hiérarchie mémoire
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 32 / 45
Déterminisme
Entrées-sorties
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 33 / 45
Déterminisme
Entrées-sorties
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 34 / 45
Déterminisme
Prédictibilité - que faire?
Programmation: concepts à appliquerAbsence de structures de données dynamiquesAbsence de récursionBoucles bornées en tempsConnaissance du matérielConnaissance du système
Prendre des mesures (benchmarking)!http://www.ptxdist.org/development/kernel/arm-benchmarks-20100729_en.html
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 35 / 45
http://www.ptxdist.org/development/kernel/arm-benchmarks-20100729_en.htmlhttp://www.ptxdist.org/development/kernel/arm-benchmarks-20100729_en.html
Déterminisme
Prédictibilité - évaluer
Images from http://uuu.enseirb.fr/~kadionik/embedded/linux_realtime/linux_realtime2.html
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 38 / 45
http://uuu.enseirb.fr/~kadionik/embedded/linux_realtime/linux_realtime2.htmlhttp://uuu.enseirb.fr/~kadionik/embedded/linux_realtime/linux_realtime2.html
Environnement
Décomposition
Un système temps réel est souvent décomposé en tâchesSéparation des traitementsMeilleure utilisation du processeurMeilleure fiabilité en cas de surcharge
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 39 / 45
Environnement
Système d’exploitation
Un système temps réel peut fonctionner avec ou sans systèmed’exploitation (OS)Sans
Un exécutif temps réel fournit un micro-noyau pourl’ordonnancement (si multi-tâche)
AvecPossibilité d’avoir une interface graphiqueGestion de fichiersL’OS doit être temps réel
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 40 / 45
Environnement
Langages pour le temps réel
Principaux critères de choix:Déterminisme temporel et logiqueFiabilitéPrésence d’abstractions "temps-réel"
Tâches, synchronisation, horloges, etc.
Accès aisé aux ressources de bas niveauPortabilité, normalisationCompilation croisée (cross-compilation)Performances
Deux approches: langages bas niveau ou haut niveau
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 41 / 45
Environnement
Langages pour le temps réel (2)
Langages de haut niveau: Ada 95Langage conçu, entre autre, pour le support des applicationstemps-réel
Abstraction temps-réel: tâche, interruption, ordonnancement(priorité fixe et dynamique), synchronisation par sémaphore, timeret gestion du temps, outils de communication basés sur lesrendez-vous
Interface et syntaxe normalisé par ISOLangage très portable
Adapté à la production de logiciels volumineuxLangage complexe
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 42 / 45
Environnement
Langages pour le temps réel (3)
Langages de bas niveau: C/C++, assembleurLargement diffusés et utilisés à ce jourAccès direct aux ressources de bas niveauIdéal pour les I/O (entrées/sorties)Doit être couplé avec les services du système(synchronisation,ordonnancement)
Recours aux librairiesLangage généralement restreint
Comportement temporel déterministe facile à évaluerPeu adapté aux logiciels complexes et/ou volumineux
Pas vraiment normalisé, donc peu portableEffort de standardisation par POSIX
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 43 / 45
Lois de Murphy
Lois de Murphy relatives aux systèmes temps-réel (1)
Murphy’s General LawIf something can go wrong, it will go wrong.
Murphy’s ConstantDamage to an object is proportional to its value.
Naeser’s LawOne can make something bomb-proof, not jinx-proof.
Troutman Postulates1 Any software bug will tend to maximize the damage.2 The worst software bug will be discovered six months after
the field test.
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 44 / 45
Lois de Murphy
Lois de Murphy relatives aux systèmes temps-réel (2)
Green’s LawIf a system is designed to be tolerant to a set of faults, there willalways exist an idiot so skilled to cause a nontolerated fault.
CorollaryDummies are always more skilled than measures taken to keepthem from harm.
Johnson’s First LawIf a system stops working, it will do it at the worst possible time.
Sodd’s Second LawSooner or later, the worst possible combination of circumstanceswill happen.
CorollaryA system must always be designed to resist the worst possiblecombination of circumstances.
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 45 / 45
IntroductionEchéancesDéterminismeEnvironnementLois de Murphy