Programmation Temps Réel

Introduction

Yann Thoma

Reconfigurable and Embedded Digital Systems Institute

Haute 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 temps

d’arrivée du résultat est aussi important que le résultat lui-même
Par 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
système de contrôle

gestion des entrées 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 un
temps 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’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.

Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 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

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 de
diffé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 critique

Le système est compromis si l’échéance est dépassée

Valeur
échéance

Temps

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 essentiel

Le résultat ne sert à rien si son échéance est dépassée

Valeur
échéance

Temps

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éance

La pénalité liée au non respect de l’échéance n’est pas
catastrophique

Valeur
échéance

Temps

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 (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?

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é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.

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, 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

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 à effectuer
But (2): Baser la mise au point du système sur ces temps de
ré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 cycle

Hardware FP: 10-12 cycle hardware divide
Soft 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<n;i++) n peut prendre n’importe quelle valeur

faireQuelqueChose();

unsigned int factorielle(int n){ idem

if (n==1)
return n;
else
return n*factorielle(n-1);
}

ajouterNoeud(maListeChainee, monNoeud);

Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 20 / 45

 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 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);

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é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

Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 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

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
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

Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 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

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 à 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

Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 35 / 45

 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

 Environnement

Décomposition

Un système temps réel est souvent décomposé en tâches

Séparation des traitements
Meilleure utilisation du processeur
Meilleure 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è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

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 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

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 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

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++, 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

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 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 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 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.
Y. Thoma (HES-SO / HEIG-VD / REDS) Programmation Temps Réel Septembre 2017 45 / 45