STR Embarqués STR Embarqués

STRE

Plan

1. Présentation des systèmes temps réel embarqués (STRE)

Systèmes temps réel
a. rappels sur les systèmes temps réel
Embarqués
b. contraintes des systèmes embarqués
c. les STRE
2. Structure et fonctionnement des STRE
a. Exécutif ou système
b. Ordonnancement
c. Entrées/sorties

Bertrand Dupouy 3. Développement d'applications embarquées

4. Les STRE disponibles
5. Perspectives

©ENST 8/06/10 80 ©ENST 8/06/10 81

STR Embarqués STR Embarqués

STRE

Plan

1. Présentation des systèmes temps réel embarqués (STRE)

a. rappels sur les systèmes temps réel
b. contraintes des systèmes embarqués
c. les STRE
2. Structure et fonctionnement des STRE
a. Exécutif ou système
b. Ordonnancement
c. Entrées/sorties
3. Développement d'applications embarquées
4. Les STRE disponibles
5. Perspectives

©ENST 8/06/10 82 ©ENST 8/06/10 83

STR Embarqués STR Embarqués

La plateforme embarquée (1)

Définition
Des système embarqués
• Compromis matériel/logiciel :
• Leur place : - seules les fonctions simples et pérennes sont réalisées en matériel,
Environnement
contrôlé
- tendance aux processeurs généralistes puissants et aux réalisations
Capteur/Emetteur logicielles,
Système de
commande
Noyau temps réel - Le matériel assure la performance, le logiciel apporte portabilité,
Ordonnancement
Communications flexibilité…
Langage de programmation
• Exemple de matériels embarqués :
- processeur + E/S simples : carte à puce,
• STRE : mise en œuvre conjointe de matériel et de logiciel pour gérer - processeur + réseau : routeur,
un dispositif qui n’est pas un ordinateur et qui interagit avec le monde
extérieur (qui est donc sous contraintes temporelles), - processeur + réseau sans fil + E/S simples : téléphone portable,

• Système d’exploitation et logiciels applicatifs sont « immergés » dans - processeur + capteurs/émetteurs sophistiqués : robots, contrôle de
l’architecture matérielle et ne sont pas aussi visibles que sur un PC processus,
classique, c’est pour cette raison que l’on parle de:
- système enfoui (embedded system), • Remarque sur les processeurs embarqués :
- informatique diffuse (pervasive computing) : l’informatique est - grande capacité d'E/S,
présente partout, mais on ne la remarque pas,
- un problème : le rapport Mips/Watt, hot RISC (sur les stations) et
cold RISC (embarqués)

©ENST 8/06/10 84 ©ENST 8/06/10 85

STR Embarqués STR Embarqués

La plateforme embarquée (2)

• Contraintes spécifiques au niveau matériel :

o faible encombrement, faible poids, faible consommation,
o robustesse: résistance aux vibrations, chocs, température, …
o processeur : réserve d’énergie limitée (par le coût, par le
poids) ; la consommation d’énergie sera peut être à prendre en
compte par l’ordonnanceur (energy aware scheduling) ,
o mémoire : faible espace d’adressage (small footprint) ,
o disque : souvent absent (disk on RAM)

• Contraintes spécifiques au niveau logiciel:

o sûreté de fonctionnement (capacité à accorder une confiance
justifiée au service),
o résistance aux pannes (la panne d’un composant ne remet pas
en cause la vie du système),
o développement en environnement croisé (cross compilation),

©ENST 8/06/10 86 ©ENST 8/06/10 87

STR Embarqués STR Embarqués

Système temps réel embarqué : Système temps réel embarqué :

Contraintes temporelles Ressources limitées

• Le STRE reçoit des stimuli via ses capteurs et répond en actionnant les • Comme le STR, le STR embarqué (STRE) doit être prédictible dans les
périphériques adéquats. Ces interactions avec le monde extérieur se domaines temporel (échéances) et logique (sûreté, vivacité...)
font de plusieurs manières :
• Notion de qualité de la réponse :
- synchrone, (scrutation : clock based system),
- moins précise, plus rapidement,
- asynchrone, (interruption : sensor based system),
- exacte, moins rapidement,
- combien d'échéances peut-on manquer ?
• Le STRE doit offrir une bonne réactivité à ces événements extérieurs :
- gestion déterministe des interruptions et des timers,
• le STRE a des contraintes supplémentaires:
- importance des interruptions qui indiquent l’occurrence d'une
- émettre des signaux ou répondre à des stimuli externes (capteurs)
échéance, et en particulier son dépassement. Que doit-on faire
dans une fenêtre de temps limitée (respect des échéances,
dans ce cas : arrêter le système, juste la tâche fautive, passer dans
déterminisme temporel),
un mode dégradé ?
- se satisfaire de ressources limitées (espace mémoire, puissance
• Les tâches qui gèrent ces événements sont :
processeur, énergie, ...), donc utiliser des algorithmes économes en
- périodiques (déclenchement à fréquence fixe), consommation de mémoire, énergie, cpu,
- apériodiques (fréquence de déclenchement variable) , - sécurité, reprise en cas d'erreur, fonctionnement en mode dégradé
- sporadiques (fréquence de déclenchement variable mais bornée)
Remarque : le critère du WCET conduit à la sous-utilisation des
ressources.

©ENST 8/06/10 88 ©ENST 8/06/10 89

STR Embarqués STR Embarqués

Système temps réel Système temps réel

embarqué : spécificités (1) embarqué : spécificités (2)
• En plus de ceux fournis par les STR, les STRE devront offrir les
services suivants :
• Gestion des pannes :
• Gestion des entrées-sorties :
- interventions de maintenance difficiles ou impossibles, ce qui
- gestion déterministe du temps, mise à disposition de timers haute implique :
résolution,
o un haut niveau de disponibilité,
• Gestion de l’énergie :
o des mécanismes de reprise en cas d'erreur,
- assurer une faible consommation : les algorithmes utilisés par les
o des possibilités de fonctionnement en mode dégradé,
STR ne pourront pas toujours être implantés par les STRE. Cette
gestion peut se traiter dynamiquement soit au niveau matériel soit • Méthodes de développement :
au niveau de l'ordonnancement,
- développement en environnement croisé ; mise au point difficile, on
• Gestion de la mémoire : attend des outils de trace et de mesure,
- au niveau temporel : allocation des blocs mémoire en temps • Adaptabilité :
prédictible (cf. RTSJ),
- adaptabilité à la variation de configuration logicielle (cf. les
- au niveau espace d’adressage : prise en compte des contraintes de managers de RTEMS),
faible encombrement. Les STRE proposent également des facilités
pour dimensionner précisément l’espace d’adressage d’une - adaptabilité aux différentes configurations matérielle :
application, o notion de HAL (Hardware Layer) ou de BSP (Board Support
• Gestion du disque : Package) : une couche qui sépare du noyau les sections de
code spécifiques au processeur. Au-delà de cette couche, le
- implantation des file systems en RAM (système de fichier en système d’exploitation est indépendant du processeur sur
mémoire flash), lequel il s'exécute,

©ENST 8/06/10 90 ©ENST 8/06/10 91

STR Embarqués STR Embarqués

Conséquences : STRE

Plan
• Conséquences de ces nouvelles contraintes :
- les algorithmes utilisés dans les STR ne peuvent pas toujours être
implantés à cause d'une trop grande consommation de ressources :
1. Présentation des systèmes temps réel embarqués (STRE)
o taille mémoire du code, des données,
a. rappels sur les systèmes temps réel
o dégradation des performances en fonction des restrictions de
b. contraintes des systèmes embarqués
ressources,
c. les STRE
• Exemples :
2. Structure et fonctionnement des STRE
- les garbage collectors des machines Java doivent être repensés
pour les JVM embarquées, a. Exécutif ou système
- gestion des file systems en RAM, b. Ordonnancement
- que faire si une échéance n'est pas respectée ? Importance des c. Entrées/sorties
interruptions qui indiquent la proximité d'une échéance ou bien qu'on
l'a manquée. 3. Développement d'applications embarquées
4. Les STRE disponibles
5. Perspectives

©ENST 8/06/10 92 ©ENST 8/06/10 93

STR Embarqués STR Embarqués

Quel système Exécutif TR

pour les applications embarquées ? Ou système TR ?

• Exécutif temps réel, moniteur temps réel (par exemple, RTEMS):

• Système dédié ou généraliste ?
- Le construire en tant que tel (cf. cours STR !!!),
- Le construire en le dérivant d'un système classique (UNIX ou autre),
pour cela, il faut :
Niveau système :
o réduire sa taille !
o donner des outils déterministes pour la gestion du temps
(alarmes, signaux),
• Système temps réel (par exemple, Linux) :
o modifier l'ordonnancement (et la synchronisation) pour
respecter les contraintes temporelles,
o gestion des ressources prédictible (exemple : allocation
mémoire),
- recompilé avec l'application, se présente sous forme d’une
bibliothèque, « linkée » avec l'application. On recharge l’ensemble
[application+système] à chaque fois qu’on relance l’application.
- Il est de très petite taille, parce que modulable en fonction de
l’application,
- gestion mémoire très simple donc efficace en terme de temps,
- pas d'interface utilisateur, le couple écran/clavier n’est plus le
périphérique privilégié,
- système chargé en entier en mémoire, il reste en mémoire et permet
l’exécution successive de plusieurs applications,
- mais il est plus volumineux qu’un exécutif,

Niveau interface avec le matériel: - plus portable ( ?), souvent compatible POSIX,

o outils pour ajouter simplement des pilotes de périphériques, - utilisation plus souple (interface du type shell…), mais est-ce
toujours nécessaire ?

©ENST 8/06/10 94 ©ENST 8/06/10 95

STR Embarqués
Comment choisir
le système (ou l’exécutif)?
• Exemple de critères de choix :
- sur quelle cible (BSP et processeur) va être déployée l’application ?
- quels langages de programmation sont disponibles ?
- taille mémoire nécessaire en RAM et en ROM (footprint),
- pilotes de périphériques disponibles, facilité de leur écriture,
- outils offerts par la chaîne de développement croisée,
- disponibilité ou non du code source, support technique, maturité,
©ENST 8/06/10 96
STR Embarqués
Résumé : Evolution des systèmes embarqués
• De la simple boucle de gestion des interruptions (années 70) à la notion
de système et de BSP (board support package ) :
Structure des années 70 :
Boucle : tests de variables d’état et exécution de fonctions approriées.
Mise à jour de ces variables par les procédures de gestion des
interruptions à bas niveau (ISR, Interrupt Service Routines). Ces
procédures sont écrites en assembleur.
Structure des systèmes embarqués actuels :
Application écrite en langage de haut niveau
Intergiciel (exemple : RT CORBA)
Bibiliothèques (exemple : POSIX threads), couches réseau (exemple :
IP stack), …
Noyau temps réel embarqué (exemple : RTEMS).
Ordonnancement, synchronisation, gestion mémoire
Processeur et carte électronique spécifique (BSP, Board Support
Package ; HAL, Hardware Layer)
Matériel piloté (exemple : robot, téléphone portable, …).
©ENST 8/06/10 97
STR Embarqués STR Embarqués

Peut-on se passer Peut-on se passer

du STRE ? du STRE ?
1-La boucle de scrutation des évènements

• On va maintenant voir pourquoi la gestion directe des évènements,

sans système d’exploitation proprement dit, n’est satisfaisante que
• La solution la plus simple est la boucle de scrutation de l’ensemble des
dans les cas les plus simples.
périphériques :
- On envisagera successivement :
- C’est une suite de tests qui vérifie l’état de chaque périphérique :
o La boucle de scrutation,
o Si cet état a changé, alors exécution d’une action,
o L’ exécutif cyclique,
o Sinon : rien
- Inconvénients :
o La suite définit un ordre, donc une priorité implicite, sur les
traitements,
o Pas de gestion des interruptions : le dialogue avec les
périphériques se fait à l’initiative de l’application (alors que
l’objectif peut être : event driven !),
o Polling (attente active)

©ENST 8/06/10 98 ©ENST 8/06/10 99

STR Embarqués STR Embarqués

Peut-on se passer Peut-on se passer

du STRE ? du STRE ?
2- Amélioration : Exécutif cyclique 3 - Exécutif cyclique « time driven »

• Exécutif cyclique élémentaire:

- Si les traitements sont longs, la simple boucle de scrutation ne suffit
pas, on associe une « tâche « à chaque test (cf. dispatcher vs
scheduler),
- Remarque : pas de problème de concurrence entre tâches : chacune
se termine avant que l’on passe à la suivante,
- Inconvénients :
o La boucle doit être (comme précédemment) exécutée à une
fréquence permettant le traitement de tous les événements,
o Toujours pas de gestion des interruptions : le dialogue avec les
périphériques est à l’initiative de l’application (la boucle !),
- Fonctionnement dérivé de celui de l’exécutif cyclique :
o Un timer lance les tâches,
o Chacune est exécutée en totalité avant de passer à la suivante,
o La dernière doit se terminer avant la prochaine interruption
timer,
o Pour gérer plus finement des événements à fréquences
différentes, on peut exécuter certaines tâches plusieurs fois
dans un cycle (cycle majeur et cycle mineur),
- On essaie d’exécuter les tâches aussi vite et fréquemment que
possible, mais :
o Le respect des échéances importe plus que la rapidité du
traitement,
o Les interruptions ne sont toujours pas gérées,

©ENST 8/06/10 100 ©ENST 8/06/10 101

STR Embarqués STR Embarqués

Peut-on se passer Domaines d’application

du STRE ? Des systèmes embarqués
4- Exécutif cyclique : limitations

• Les domaines traditionnels :

• Bilan :
- spatial, avionique (systèmes temps réel répartis embarqués),
- Simple à implémenter : exécution de traitements à fréquences
- robotique,
régulières,
- contrôle de processus industriels (chimie, nucléaire, …),
- Pas de gestion des interruptions. Les périphériques (sauf le timer !)
sont gérés en polling, l’initiative n’est pas donnée aux stimuli
externes,
• Les nouveaux domaines:
- Pas de contrôle du temps d’exécution des tâches (revient à faire
- automobile,
FCFS),
- médical,
- Comment gérer le temps :
- électronique grand public (jeux), téléphonie mobile,
o découper en sous tâches (pb de partage de données),
- systèmes embarqués temps réel répartis à grande échelle (digital
o quantum ,
city,…),
o déclenchement de chaque tâche par un timer ,
- informatique diffuse (pervasive computing, ubiquitous computing),
wearable computer, domotique, objets intelligents (smart objects),
immeubles intelligents…

©ENST 8/06/10 102 ©ENST 8/06/10 103

STR Embarqués STR Embarqués

L’informatique diffuse Le marché (1)

• Tendances :
• L’informatique diffuse, omniprésente (pervasive computing, ubiquitous - Ce marché devient un marché de masse,
computing, Weiser 1993) :
- Standardisation (POSIX temps réel, embedded Linux, RTSJ),
- l’informatique disparaît, mais elle est partout, invisible pour
- interconnexion des équipements par des réseaux sans fil,
l’utilisateur elle entretient avec lui des liens permanents,
- mise en œuvre possible grâce aux réseaux sans fil : tous les objets
de la vie courante auront-ils une adresse IP ? • Marché atomisé :
- Pas d'offre globale (on compose soi-même sa configuration tant au
niveau matériel que logiciel),
• Rôle des systèmes embarqués dans ce contexte :
- Pas de fournisseur dominant (31% de systèmes dits
- contraintes soft real time(multimédia),
"propriétaires"),
- gestion de l’énergie, gestion de la localisation (par rapport au réseau
- Microsoft, Sun, IBM sont marginaux,
et/ou localisation physique ?) ,
- configuration dynamique de réseaux sans fil (réseaux ad hoc),
- information contextuelle (validité seulement locale d’une
information),

©ENST 8/06/10 104 ©ENST 8/06/10 105

STR Embarqués STR Embarqués

Le marché (2) STRE

Plan
• Type des marchés :
Secteur Maturité Contraintes Tendances
1 Présentation des systèmes temps réel embarqués (STRE)
Scientifique, Forte Performance, Réduction des coûts
aérospatilae, fiabilité (économie a. rappels sur les systèmes temps réel
militaire d'échelle)
b. contraintes des systèmes embarqués
Transports Moyenne Fiabilité, coût Ergonomie, réseau
Industrie Forte Fiabilité, coût Réseau c. les STRE
Bureau Forte Performance, Standardisation, 2 Structure et fonctionnement des STRE
coût puissance
Télecomm. Forte Performance, puissance a. Exécutif ou système
Fiabilité
b. Ordonnancement : précisions
Gd public Faible Performance, Internet
coût c. Entrées/sorties
Commerce elec. Faible Fiabilité, coût, Commerce en ligne
3 Développement d'applications embarquées
sécurité
4 Les STRE disponibles
5 Perspectives

©ENST 8/06/10 106 ©ENST 8/06/10 107

STR Embarqués STR Embarqués

Rappels sur la préemption

Rappels :
Objectifs du STRE
• Préemption:
- les tâches peuvent être interrompues par des facteurs qui leurs sont
étrangers,

• Une application TR embarquée doit répondre à des stimuli extérieurs : - exemple : un événement externe peut réactiver une plus prioritaire
que la courante, il faut alors :
- dans un certaine fenêtre de temps,
o sauvegarder le contexte de la tâche courante,
- même dans le pire cas,
o créer ou restaurer le contexte de la tâche à démarrer,
- dans un contexte de ressources (très) réduites,

• Problèmes liés :
• … en assurant le respect des échéances pour les tâches critiques,
- quelles tâches peut-on préempter (notion de priorité) ?
Attention : une tâche de faible importance peut avoir de fortes
contraintes de temps, et une tâche de forte importance peut avoir de - gestion fine du contexte,
faibles contraintes de temps), - gestion des données partagées :
o entre tâches, entre tâches et ISR ,
• il faut exécuter au moins un sous-ensemble minimal des tâches même o files de messages, sémaphores, …
si la charge augmente (gracefull degrade) l'objectif n'est PAS le
rendement,

©ENST 8/06/10 108 ©ENST 8/06/10 109

STR Embarqués STR Embarqués

Gestion des Ordonnancement

Priorités Et changement de contexte

• La « process table »
• Comment gérer les priorités :
- une entrée par tâche
- la priorité doit-elle refléter :
- chaque entrée contient (ou permet de retrouver) :
o la période (respect des échéances)
o copie de registres
o la criticité (la tâche dont l’exécution est la plus importante n’est
o informations sur la pile : adresse, taille, utilisation
pas forcément celle dont la période est la plus courte)
o informations sur la consommation des ressources
- priorité fixe (RMS) ou variable (EDF)
o état du processus
o sémaphore sur lequel il est bloqué
o les messages qui lui ont été envoyés

©ENST 8/06/10 110 ©ENST 8/06/10 111

STR Embarqués STR Embarqués

Mécanisme Le changement de contexte :

Du changement de contexte (1) La fonction où on ne revient jamais

• Choisir un des processus qui sont dans l’état PRET (READY) ou le
processus CURRENT :
- rôle du scheduler (qui peut être une fonction sched ())
• Le scheduler :
- choisit le plus prioritaire des processus READY ou le CURRENT
- fait éventuellement passer le CURRENT en READY
- remarque :
• La fonction ctxswitch:
- change les pointeurs de pile, etc,
- sauve les registres,
- restaure le contexte du processus réordonnancé,
- ATTENTION : dès que le compteur ordinal est restauré, on part
dans le code du processus réordonnancé : on ne revient pas de la
fonction ctxswitch qui fait le changement de contexte !!!!

o toutes les fonctions du système coopérent pour gérer l’état

des processus : l’état est modifié par les sémaphores, les
interruptions, … qui appelle ensuite sched ()
- fait passer le processus choisi en CURRENT
- appelle une fonction du type ctxswitch

©ENST 8/06/10 112 ©ENST 8/06/10 113

STR Embarqués STR Embarqués

Le changement de contexte : Changement de contexte

Et ordonnancement

• Quelques détails
- la valeur sauvée pour le CO par ctxswitch est sa propre
adresse de retour:
o c’est celle où devrait revenir ctxswitch si elle était une
fonction ordinaire… mais elle est appelée par un processus A,
elle donne la main à un processus B, qui devra repasser le
contrôle, non pas a ctxswitch, mais à A…

- les processus appellent sched () pour faire la changement de

contexte après avoir chois le processus à activer, donc :
o tous les processus suspendus reviennent dans sched
()après l’appel à ctxswitch
o c’est le retour de sched ()qui les renvoie dans la fonction qui
a appelé sched()

©ENST 8/06/10 114 ©ENST 8/06/10 115

STR Embarqués STR Embarqués

Le processus Gestion de la concurrence :

null ou idle, Les sémaphores

• Opération P :
- si le compteur passe négatif :
• le rôle de sched ()est seulement de choisir un processus parmi les
READY et CURRENT : o faire passer le processus de CURRENT à BLOCKED,
- elle ne créé PAS de processus, o indique le numéro du sémaphore dans l’entrée de la process
table associée au processus
- elle ne vérifie pas si la liste des READY est vide,
o appel à sched()
- conséquence : il doit toujours y avoir au moins un processus dans l’état
READY : le null process

• Opération V :
- si le compteur passe négatif ou nul :
o choisir un processus et le faire passer de BLOCKED à
READY,
o appel à sched()

©ENST 8/06/10 116 ©ENST 8/06/10 117

STR Embarqués STR Embarqués

Rappel sur l’ordonnancement de tâches Rappel sur l’ordonnancement de tâches

dépendantes (ici, EDF) dépendantes (EDF)

• Si une tâche (ex : gestion de la direction d’un véhicule) attend un • Exemple pour trois tâches T1, T2 et T3 dont on donne ci-dessous le
résultat fourni par une autre (ex : détecteur de choc), on parle de graphe de dépendance :
tâches dépendantes,

• Modification des paramètres pour prendre en compte les dépendances

entre tâche EDF :
- chaque tâche doit avoir une échéance dont la date est antérieure à
celle des tâches qui dépendent d’elle. L’échéance Di de Ti devient :
D*i = min { Di, min{ D*j - C j } }, pour j tel que Ti précède Tj
• Rappel des formules :

D*i = min { Di, min{ D*j - C j } }, pour j tel que Ti précède Tj

- une tâche ne peut être activée que si toutes ses précédentes ont été r*i = max { ri, max{ r*j + C j } }, pour j tel que Tj précède Ti
activées. Donc la date de réveil d’une tâche doit être supérieure à
celle de ses précédentes à laquelle a été ajoutée la durée • Si la dépendance est une communication par message, on ajoute le
d’activation. La date de réveil ri de Ti devient :
délai ! ij dû à la durée de la transmission et la date de réveil devient :
r*i = max { ri, max{ r*j + C j } }, pour j tel que Tj précède Ti
r*= max { r, max{ r*+ C+ ! j } , pour j tel que Tj précède Ti

©ENST 8/06/10 118 ©ENST 8/06/10 119

STR Embarqués STR Embarqués

Gestion Gestion
des interruptions Des interruptions

• On associe à chaque interruption une fonction de traitement (vecteur • Tables des vecteurs, priorités, masquage, traitement
d’interruption, ISR) : •Horloges
- Attention au partage de données - real time clock (interrompt le processeur)
o bufferisation , o envoie une interruption à chaque tick
o quand passer les données aux tâches ? o ne gère pas de compteur, le décompte des interruptions doit
être fait par le système

• Quand activer ou inhiber les interruptions ? o sert à gérer des alarmes (quantum, échéance), utilisation
d’une liste du type delta
- périodiquement : tous les n tics d’horloge,
- time of day clock (consulté à sa demande par le système)
- préemption,
o mise à jour d’un compteur qui sera éventuellement lu par le
système ou les applications

• Entrées sorties :
- initialisation des vecteurs (bas niveau),
- écriture du pilote et des fonctions de haut niveau

©ENST 8/06/10 120 ©ENST 8/06/10 121

STR Embarqués STR Embarqués

Les entrées-sorties Spécificité des systèmes embarqués :

dans un STRE Gestion de lʼénergie

• Les dispositifs embarqués sont souvent contraints par la ressource

• Elément déterminant d'un STRE : la gestion des entrées-sorties :
énergie (les batteries ont une capacité limitée) :
- lire (périph. , données, échéance)
- à quel niveau gérer l’énergie : système, application, matériel ?
• On doit pouvoir gérer les e/s comme on gère les processus :
- satisfaire la plus prioritaire d'abord,
• Le système peut prendre en charge cette gestion, car il a une vue
- annuler une demande lorsque son échéance est dépassée, globale :
- réordonner les demandes si une plus prioritaire arrive, - ordonnancement prenant en compte la gestion de l’énergie
• Plusieurs stratégies :
• Si les tâches partagent des ressources (capteurs/émetteurs, accès au - transition (passage d’un état à un autre), exemple : mise en
réseau) : veille du processeur
- utiliser des algorithmes d’ordonnancement entre tâches - adaptation (changement de technologie), exemple : remplacer
dépendantes, un disque par de la mémoire flash
- utiliser PCP ou PIP pour accéder aux sémaphores gérant les - modification de la charge d’un composant, par exemple :
ressources, utiliser des caches (mémoire, disque) ce qui modifie les
stratégies de gestion des disques ,
• Attention aux mécanismes matériels :
-entrées-sorties exécutées par le processeur,
• Le matériel propose des outils : mise en veille, réduction de fréquence,
-entrées-sorties indépendantes du processeur (DMA),

©ENST 8/06/10 122 ©ENST 8/06/10 123

STR Embarqués STR Embarqués

STRE

Plan

1. Présentation des systèmes temps réel embarqués (STRE)

a. rappels sur les systèmes temps réel
b. contraintes des systèmes embarqués
c. les STRE
2. Structure et fonctionnement des STRE
a. Exécutif ou système
b. Ordonnancement
c. Entrées/sorties
3. Développement d'applications embarquées
4. Les STRE disponibles
5. Perspectives

©ENST 8/06/10 124 ©ENST 8/06/10 125

STR Embarqués STR Embarqués

Environnement Environnement
de développement de développement

• Cycle de mise au point :

• Développement en environnement croisé : compilateur croisé et outils Edition de sources
associés, suivi de mise au point à distance ( remote debugging),
• Les développements ne se font plus en assembleur, le langage de haut Compilation croisée
et éditions de liens
niveau peut prendre en main les problèmes proches du matériel,
Téléchargement
• Utilisation de plus en plus courante de logiciels du type gnu (gcc,
Moniteur
gdb)
• Style de programmation spécifique (pas d'allocation dynamique de Exécution et mise
au point
ressources, gestion de timers, écriture de pilotes d’E/S, ...) Système +
application
EPROM, Flash
Target (cible) Host (hôte) RAM
1. téléchargement
ROM RAM Outils dedéveloppement croisé

2. Exécution/mise • Le moniteur sert à démarrer (« booter ») la carte : il initialise les

au point
Processeur A registres de base du processeur, et gère au moins une ligne série pour
Processeur B
le téléchargement.
Moniteur en ROM
Pas d'écran
Pas de disque

©ENST 8/06/10 126 ©ENST 8/06/10 127

STR Embarqués STR Embarqués

Environnement Exemples
de développement

• Plate-forme logicielle de base : • RTEMS et ppcboot :

Host (hôte)
- un STRE (ex : RTEMS), Target (cible)
1. téléchargement
ROM RAM Outils dedéveloppement croisé
- un ou plusieurs compilateurs croisés (ex : gcc sur PC-Linux
générant du code pour Motorola PowerPC) et des outils de 2. Exécution/mise
développement croisés (les bibliothèques C), Processeur A au point
Processeur B
- un moniteur (ex : ppcboot) et des protocoles de communication pour
Moniteur en ROM
le téléchargement et la mise au point (ex : tftp), Pas d'écran
Pas de disque
• On rappelle ci-dessous la place du BSP qui isole le système de la
configuration matérielle :
Bibliothèque, threads, etc • Embedded Linux (< 500K octets avec TCP-IP), et mise au point avec
Systéme Pilotes remote gdb :
Processeur de base Carte particulière BSP Cible : plateforme Hôte : PC
PowerPC sous Linux
Matériel
1. téléchargement
MPC860 BDM Port parallèle

RAM
Interface 2. accès nfs Interface
• Pour réduire les coûts Ethernet Ethernet
Port série Port série
- simulateurs, 3. Exécution/mise
au point
COM1

- plate-forme de développement propriétaires,

- outils free software,

©ENST 8/06/10 128 ©ENST 8/06/10 129

STR Embarqués STR Embarqués

Du côté du matériel Quelques critères

Pour la conception

• A vérifier du côté architecture matérielle : • Qualité de la réponse aux stimuli externes,

- gestion des interruptions, - moins précise, plus rapidement,
- gestion de la mémoire (inhiber la pagination,…), - exacte, moins rapidement,
- fonctionnement des horloges, - combien d'échéances peut-on manquer ?
- fonctionnement des caches (données, instructions, peut on les
verrouiller, les geler, …)
• Choix des algorithmes :
- ils devront se satisfaire de ressources limitées (mémoire, vitesse,
énergie, ...),
- ordonnancement approprié -> RMS , EDF, …
- E/S à échéance -> gestion d’alarmes et de timers,

©ENST 8/06/10 130 ©ENST 8/06/10 131

STR Embarqués STR Embarqués

Facteurs STRE
intervenant dans la
gestion du temps Plan
(rappels)

1. Présentation des systèmes temps réel embarqués (STRE)

• Facteurs matériels d’indéterminisme dans la gestion mémoire :
- pagination (en général inhibée en embarqué), a. rappels sur les systèmes temps réel
- fonctionnement des mémoires caches,
b. contraintes des systèmes embarqués

• Facteurs matériels d’indéterminisme dans la gestion du processeur : c. les STRE

- pipe-line, 2. Structure et fonctionnement des STRE
- superscalaire, VLIW…
a. Exécutif ou système
• Attention au partage des ressources : b. Ordonnancement
- pb. de concurrence (inversion de priorité),
c. Entrées/sorties
3. Développement d'applications embarquées
• Attention à la gestion des entrées-sorties à bas niveau:
- priorités, échéances, interruptions 4. Les STRE disponibles

- attention au bon typage des variables (cf. volatile en C pour l’accès 5. Perspectives
aux registres des périphériques),

©ENST 8/06/10 132 ©ENST 8/06/10 133

STR Embarqués STR Embarqués

Quelques STR Quelques systèmes

embarqués ... Embarqués :

• Propriétaires :
- LynxOS de Lynx, 4% du marché, QNX, 5% du marché,
• Parmi les systèmes temps réel portés sur de nombreuses plateformes,
- iRMX, produit par Intel pour 8086, 5% du marché, citons :
- pSOS (ISI) et VRTX (Microtec) pour 68xxx, 9% du marché, - RTEMS,
- VxWorks, 286 Ko, de WindRiver (terminaux X, Mars Pathfinder), - Linux (RTLinux),
11% du marché,
• Dans le domaine des systèmes dédiés à la téléphonie mobile :
- Windows CE (version réduite de NT, pas temps réel, 4Mo RAM),
sur Intel et MIPS, - Symbian,

- VRTX, produit par Hunter et Ready pour 68xxx, 8% du marché, - Mobilinux,

- Symbian pour les téléphones portables, • JVM : la version RTSJ,

- JavaCard (24 à 64 Ko de ROM, 512o à 2Ko de RAM) • ARINC 653, orienté avionique, est représentatif des recherches
actuelles en haute disponibilité.
• free software :
• Dans le monde des systèmes embarqués sur les mobiles, mais non
- RTEMS de OAR, implémenté en C et Ada, porté sur de très temps réel : Microsoft Mobile Windows et la JVM J2ME.
nombreux processeurs et BSP,
- eCos de Red Hat,
- Linux embarqués variés (RT-Linux, Linux-RK)
• universitaires : Spring, ARTS, Mars, TinyOS …

©ENST 8/06/10 134 ©ENST 8/06/10 135

STR Embarqués
Quelques systèmes
embarqués: RTEMS
• RTEMS (Real-Time Executive for Multiprocessor Systems) de OAR
(On-Line Applications Research Corporation) http://www.rtems.com :
- temps réel dur, porté sur de très nombreuses plateformes
matérielles,
- exécution déterministe : elle ne varie pas en fonction du nombre
d’objets présents sur le système, temps de latence dû aux
interruptions prédictible,
- ordonnancement préemptif, basé sur les priorités, RMS fourni,
- système est configurable : seules sont chargées les fonctionnalités
(tâches, sémaphores, timers, …) nécessaires à une application
donnée (notion de manager), on optimise ainsi les performances en
vitesse et on minimise l’espace d’adressage utilisé,
- possibilité d’intégrer des services spécifiques par la mise en œuvre
d’extensions (pour insérer des traces, etc)
- implémenté en C et Ada, API POSIX, versions pour Motorola PPC,
M68xxx, Intel ix86, i960,MIPS, SPARC, …
©ENST 8/06/10 136
STR Embarqués
Quelques systèmes
embarqués : Linux temps réel
• RT Linux (Real time Linux), http://www.rtlinuxfree.com et RTAI (Real
Time Application Interface for Linux), http://www.rtai.org) :
- Construits à partir du système temps partagé Linux, qui présente les
handicaps suivants :
o Il existe dans le noyau de longues sections pendant l’exécution
desquelles les événements externes sont masqués. Il peut être
préempté lorsqu’il effectue un appel système ou lorsqu’il
exécute le code relatif à une interruption. Pas d’approche
temps réel pour gérer les périphériques, support partiel de
l’interface POSIX temps réel.
• Deux pour rendre Linux temps réel :
- applications de patches sur le noyau pour y placer des points de
préemption,
- insertion d’un second noyau entre Linux et le matériel (approche
adoptée par RTAI),
• Mobilinux (http://www.mobilinux.com), construit sur le noyau Linux
préemptible de Montavista. Il se satisfait d’une empreinte mémoire
réduite, propose un protocole publish/subscribe, et offre une gestion
dynamique de l’énergie (DPM : dynamic power management) ainsi que
des outils de mesure et de trace.
©ENST 8/06/10 137
STR Embarqués STR Embarqués

Quelques systèmes Quelques systèmes

embarqués (sur mobiles ):
Symbian
• Symbian, http://www.symbian.com :
- construit au dessus de EKA2 qui est un noyau mono utilisateur,
multitâches, préemptif, peu consommateur de mémoire et d’énergie.
Priorités préemptives, synchro. PIP,
- appels système en temps borné, timer haute résolution, latence
pour le traitement des interruptions est de 0,5ms à 1ms. Symbian ne
fait pas d’hypothèse sur le MMU du processeur et propose
plusieurs modèles de mémoire.
- outils de communication entre threads, de gestion des interruptions,
d’écriture de pilotes, des moyens pour le contrôle gestion de
l’énergie et la définition du HAL. La gestion de la sécurité et des
fichiers est également prévue.
- Gestion de pile GSM.
Embarqués : ARINC 653
• ARINC 653 ( Aeronautical Radio Inc, http://www.arinc.com) est une
spécification pour l’avionique qui décrit l’interface que doit proposer un
STRE dans une perspective de haute disponibilité :
- indépendance de l’exécution des tâches de criticités différentes en
introduisant la notion de partition. Une partition isole les données et
programmes d’une application du point de vue mémoire mais aussi
du point de vue temporel : chaque partition dispose de son propre
espace d’adressage et de créneaux de temps. Elle ne peut empiéter
ni sur les créneaux temporels ni sur l’espace mémoire des autres
partitions.
- ordonnancement cyclique : une partition peut être activée une ou
plusieurs fois par cycle. A l’intérieur d’une partition différentes tâches
peuvent être ordonnancées de façon périodique ou non, la norme
attend un ordonnancement par priorité et préemptif.
- La communication entre partitions se fait par messages, les
messages sont reçus et émis par les applications sur des ports, le
support de communication est géré par le système, les applications
ne voient que les ports.
- Les services fournis par le système sont aussi isolés dans une
partition spécifique. Traitement des pannes par l’implantation du
Health Monitor.

©ENST 8/06/10 138 ©ENST 8/06/10 139

STR Embarqués STR Embarqués

Quelques systèmes Quelques systèmes

embarqués: RTSJ embarqués sur les mobiles :
Windows Mobile
• RTSJ, Real-Time Specification for Java est une spécification de
fonctionnalités temps réel pour les JVM (http://www.rtj.org) :
- Les apports de cette spécification sont orientés vers le déterminisme
temporel : • Windows Mobile (http://www.microsoft.com/windowsmobile) :

o L’ordonnancement doit être préemptif, avec une gestion FIFO - Windows Mobile 5.0 de Microsoft n’est pas temps réel mais
des threads ayant la même priorité, la JVM ne peut changer la propose la technologie push qui permet de recevoir des mails le plus
priorité d’un thread que dans le cas de l’inversion de priorité, tôt possible. Une technologie qui a fait le succès de RIM (Research
In Motion, http://www.rim.com) et Blackberry
o Gestion des threads au niveau utilisateur : (http://www.blackberry.com) : 3 millions d'utilisateurs dans le monde,
! caractérisation fine des threads temps réel en précisant - possibilité de stockage des informations utilisateur en mémoire
leur coût, leur échéance et leur période, persistante.
! création de threads de priorité supérieure à celle du
garbage collector.
! service de contrôle d’admission : on peut demander le
calcul de l’ordonnançabilité d’un jeu de threads.
• RTSJ propose aussi des outils pour construire des ordonnancements
RMS, EDF ou LLF, pour créer des zones de mémoire qui ne sont pas
gérées par le garbage collector, et met à disposition des timers haute
résolution déterministes ainsi que des méthodes pour la gestion des
événements asynchrones.

©ENST 8/06/10 140 ©ENST 8/06/10 141

STR Embarqués STR Embarqués

STRE Perspectives :
logiciel
Plan
• Les systèmes : du plus petit au plus grand :
- Systèmes miniatures pour les réseaux de capteurs (micro
systèmes) : TinyOS de Berkeley,
- Systèmes embarqués distribués à grande échelle : quel middleware
1. Présentation des systèmes temps réel embarqués (STRE)
(RT CORBA, …) ?
a. rappels sur les systèmes temps réel
• Ordonnancement : notions de partitions (ARINC 653), ordonnancement
b. contraintes des systèmes embarqués dynamique et adaptable (flexible scheduling, power aware scheduling),

c. les STRE • Gestion mémoire déterministe (cf les outils RTSJ),

2. Structure et fonctionnement des STRE • Gestion de l’énergie : par l’ordonnancement, par le matériel, à la
compilation ?
a. Exécutif ou système
• Compilateurs , exemple : impact de la compilation sur la gestion de
b. Ordonnancement l’énergie :
c. Entrées/sorties - réduction du nombre d’instructions (+)
3. Développement d'applications embarquées - unrolling des boucles (-)
4. Les STRE disponibles
5. Perspectives

©ENST 8/06/10 142 ©ENST 8/06/10 143

STR Embarqués

Perspectives :
matériel

• Chaque composant doit avoir des performances déterministes :

- caches performants et prédictibles,
- bus (cf. CAN, TTP) et réseau (cf. TDMA, IP ?),
- préférer des pipe-lines uniques aux architectures superscalaires,

• Loi de Moore : les performances technologiques des composants sont

multipliées par deux tous les un à trois ans, mais le stockage de l’énergie
ne suit pas cette loi…

• Prendre en compte la gestion de l’énergie, l’encombrement, la fiabilité,

©ENST 8/06/10 144