Programmation Temps Réel - Institut REDS - HEIG-VD

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