Systèmes temps réel Embarqués STRE

Transcription

STR Embarqués
STR Embarqués
STRE
Plan
Systèmes temps réel
Embarqués
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
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
c. les STRE
b. Ordonnancement
c. Entrées/sorties
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é
Capteur/Emetteur
Système de
commande
Noyau temps réel
Ordonnancement
Communications
Langage de programmation
- tendance aux processeurs généralistes puissants et aux réalisations
logicielles,
- Le matériel assure la performance, le logiciel apporte portabilité,
flexibilité…
• 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
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 : routeur,
• Système d’exploitation et logiciels applicatifs sont « immergés » dans
l’architecture matérielle et ne sont pas aussi visibles que sur un PC
classique, c’est pour cette raison que l’on parle de:
- processeur + capteurs/émetteurs sophistiqués : robots, contrôle de
processus,
- système enfoui (embedded system),
- informatique diffuse (pervasive computing) : l’informatique est
présente partout, mais on ne la remarque pas,
- processeur + réseau sans fil + E/S simples : téléphone portable,
• Remarque sur les processeurs embarqués :
- grande capacité d'E/S,
- 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é :
Contraintes temporelles
Système temps réel embarqué :
Ressources limitées
• Le STRE reçoit des stimuli via ses capteurs et répond en actionnant les
périphériques adéquats. Ces interactions avec le monde extérieur se
font de plusieurs manières :
• Comme le STR, le STR embarqué (STRE) doit être prédictible dans les
domaines temporel (échéances) et logique (sûreté, vivacité...)
- synchrone, (scrutation : clock based system),
- asynchrone, (interruption : sensor based system),
• Notion de qualité de la réponse :
- moins précise, plus rapidement,
- 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,
- importance des interruptions qui indiquent l’occurrence d'une
échéance, et en particulier son dépassement. Que doit-on faire
dans ce cas : arrêter le système, juste la tâche fautive, passer dans
un mode dégradé ?
• le STRE a des contraintes supplémentaires:
- émettre des signaux ou répondre à des stimuli externes (capteurs)
dans une fenêtre de temps limitée (respect des échéances,
déterminisme temporel),
- périodiques (déclenchement à fréquence fixe),
- se satisfaire de ressources limitées (espace mémoire, puissance
processeur, énergie, ...), donc utiliser des algorithmes économes en
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é
• Les tâches qui gèrent ces événements sont :
- sporadiques (fréquence de déclenchement variable mais bornée)
Remarque : le
ressources.
©ENST 8/06/10
88
©ENST 8/06/10
critère du WCET conduit à la sous-utilisation des
89
STR Embarqués
STR Embarqués
Système temps réel
embarqué : spécificités (1)
• En plus de ceux fournis par les STR, les STRE devront offrir les
services suivants :
• Gestion des entrées-sorties :
- gestion déterministe du temps, mise à disposition de timers haute
résolution,
• Gestion de l’énergie :
• Gestion des pannes :
- interventions de maintenance difficiles ou impossibles, ce qui
implique :
o un haut niveau de disponibilité,
o des mécanismes de reprise en cas d'erreur,
- assurer une faible consommation : les algorithmes utilisés par les
STR ne pourront pas toujours être implantés par les STRE. Cette
gestion peut se traiter dynamiquement soit au niveau matériel soit
au niveau de l'ordonnancement,
• Gestion de la mémoire :
- au niveau temporel : allocation des blocs mémoire en temps
prédictible (cf. RTSJ),
- au niveau espace d’adressage : prise en compte des contraintes de
faible encombrement. Les STRE proposent également des facilités
pour dimensionner précisément
l’espace d’adressage d’une
application,
• Gestion du disque :
- implantation des file systems en RAM (système de fichier en
mémoire flash),
©ENST 8/06/10
Système temps réel
embarqué : spécificités (2)
90
o des possibilités de fonctionnement en mode dégradé,
• Méthodes de développement :
- développement en environnement croisé ; mise au point difficile, on
attend des outils de trace et de mesure,
• Adaptabilité :
- adaptabilité à la variation de configuration logicielle (cf. les
managers de RTEMS),
- adaptabilité aux différentes configurations matérielle :
o notion de HAL (Hardware Layer) ou de BSP (Board Support
Package) : une couche qui sépare du noyau les sections de
code spécifiques au processeur. Au-delà de cette couche, le
système d’exploitation est indépendant du processeur sur
lequel il s'exécute,
©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 :
o taille mémoire du code, des données,
o dégradation des performances en fonction des restrictions de
ressources,
c. les STRE
• Exemples :
- les garbage collectors des machines Java doivent être repensés
pour les JVM embarquées,
- gestion des file systems en RAM,
b. Ordonnancement
- que faire si une échéance n'est pas respectée ? Importance des
interruptions qui indiquent la proximité d'une échéance ou bien qu'on
l'a manquée.
c. Entrées/sorties
5. Perspectives
©ENST 8/06/10
92
©ENST 8/06/10
93
STR Embarqués
STR Embarqués
Quel système
pour les applications embarquées ?
Exécutif TR
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 :
- 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,
o réduire sa taille !
o donner des outils déterministes pour la gestion du temps
(alarmes, signaux),
o modifier l'ordonnancement (et la synchronisation) pour
respecter les contraintes temporelles,
o gestion des ressources prédictible (exemple : allocation
mémoire),
- pas d'interface utilisateur, le couple écran/clavier n’est plus le
périphérique privilégié,
• Système temps réel (par exemple, Linux) :
- 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,
- plus portable ( ?), souvent compatible POSIX,
Niveau interface avec le matériel:
o outils pour ajouter simplement des pilotes de périphériques,
©ENST 8/06/10
- 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.
94
- utilisation plus souple (interface du type shell…), mais est-ce
toujours nécessaire ?
©ENST 8/06/10
95
STR Embarqués
STR Embarqués
Comment choisir
le système (ou l’exécutif)?
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 :
• 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,
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 :
- outils offerts par la chaîne de développement croisée,
Application écrite en langage de haut niveau
- disponibilité ou non du code source, support technique, maturité,
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
96
©ENST 8/06/10
97
STR Embarqués
STR Embarqués
Peut-on se passer
du STRE ?
• On va maintenant voir pourquoi la gestion directe des évènements,
sans système d’exploitation proprement dit, n’est satisfaisante que
dans les cas les plus simples.
- On envisagera successivement :
Peut-on se passer
du STRE ?
1-La boucle de scrutation des évènements
• La solution la plus simple est la boucle de scrutation de l’ensemble des
périphériques :
- 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
du STRE ?
2- Amélioration : Exécutif cyclique
Peut-on se passer
du STRE ?
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,
- 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),
o Toujours pas de gestion des interruptions : le dialogue avec les
périphériques est à l’initiative de l’application (la boucle !),
- 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
du STRE ?
4- Exécutif cyclique : limitations
Domaines d’application
Des systèmes embarqués
• Les domaines traditionnels :
• Bilan :
- spatial, avionique (systèmes temps réel répartis embarqués),
- Simple à implémenter : exécution de traitements à fréquences
régulières,
- 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,
- Pas de contrôle du temps d’exécution des tâches (revient à faire
FCFS),
- contrôle de processus industriels (chimie, nucléaire, …),
• Les nouveaux domaines:
- automobile,
- médical,
- Comment gérer le temps :
o découper en sous tâches (pb de partage de données),
- électronique grand public (jeux), téléphonie mobile,
- systèmes embarqués temps réel répartis à grande échelle (digital
city,…),
o quantum ,
o déclenchement de chaque tâche par un timer ,
©ENST 8/06/10
- robotique,
102
- informatique diffuse (pervasive computing, ubiquitous computing),
wearable computer, domotique, objets intelligents (smart objects),
immeubles intelligents…
©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
computing, Weiser 1993) :
- l’informatique disparaît, mais elle est partout, invisible pour
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 ?
- Ce marché devient un marché de masse,
- Standardisation (POSIX temps réel, embedded Linux, RTSJ),
- interconnexion des équipements par des réseaux sans fil,
• 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 :
- contraintes soft real time(multimédia),
- Pas de fournisseur dominant (31% de systèmes dits
"propriétaires"),
- gestion de l’énergie, gestion de la localisation (par rapport au réseau
et/ou localisation physique ?) ,
- Microsoft, Sun, IBM sont marginaux,
- configuration dynamique de réseaux sans fil (réseaux ad hoc),
- information contextuelle
information),
©ENST 8/06/10
(validité
104
seulement
locale
d’une
©ENST 8/06/10
105
STR Embarqués
STR Embarqués
Le marché (2)
STRE
Plan
• Type des marchés :
Secteur
Scientifique,
aérospatilae,
militaire
Transports
Industrie
Bureau
Maturité
Forte
Contraintes
Performance,
fiabilité
Tendances
Réduction des coûts
(économie
d'échelle)
Ergonomie, réseau
Réseau
Standardisation,
puissance
puissance
Moyenne Fiabilité, coût
Forte
Fiabilité, coût
Forte
Performance,
coût
Télecomm.
Forte
Performance,
Fiabilité
Gd public
Faible
Performance,
Internet
coût
Commerce elec. Faible
Fiabilité,
coût, Commerce en ligne
sécurité
1 Présentation des systèmes temps réel embarqués (STRE)
c. les STRE
2 Structure et fonctionnement des STRE
b. Ordonnancement : précisions
c. Entrées/sorties
3 Développement d'applications embarquées
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 :
- dans un certaine fenêtre de temps,
- même dans le pire cas,
- dans un contexte de ressources (très) réduites,
- exemple : un événement externe peut réactiver une plus prioritaire
que la courante, il faut alors :
o sauvegarder le contexte de la tâche courante,
o créer ou restaurer le contexte de la tâche à démarrer,
• Problèmes liés :
• … en assurant le respect des échéances pour les tâches critiques,
Attention : une tâche de faible importance peut avoir de fortes
contraintes de temps, et une tâche de forte importance peut avoir de
faibles contraintes de temps),
- quelles tâches peut-on préempter (notion de priorité) ?
- gestion fine du contexte,
- 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
si la charge augmente (gracefull degrade) l'objectif n'est PAS le
rendement,
©ENST 8/06/10
108
o files de messages, sémaphores, …
©ENST 8/06/10
109
,
STR Embarqués
STR Embarqués
Gestion des
Priorités
Ordonnancement
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 la criticité (la tâche dont l’exécution est la plus importante n’est
pas forcément celle dont la période est la plus courte)
- priorité fixe (RMS) ou variable (EDF)
o copie de registres
o informations sur la pile : adresse, taille, utilisation
o informations sur la consommation des ressources
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
Du changement de contexte (1)
• 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 :
Le changement de contexte :
La fonction où on ne revient jamais
• 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
null ou idle,
Gestion de la concurrence :
Les sémaphores
• Opération P :
• le rôle de sched ()est seulement de choisir un processus parmi les
READY et CURRENT :
- elle ne créé PAS de processus,
- elle ne vérifie pas si la liste des READY est vide,
- conséquence : il doit toujours y avoir au moins un processus dans l’état
READY : le null process
- si le compteur passe négatif :
o faire passer le processus de CURRENT à BLOCKED,
o indique le numéro du sémaphore dans l’entrée de la process
table associée au processus
o appel à sched()
• Opération V :
- si le compteur passe négatif ou nul :
o choisir un
READY,
processus et le faire passer de BLOCKED à
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
dépendantes (ici, EDF)
Rappel sur l’ordonnancement de tâches
dépendantes (EDF)
• Si une tâche (ex : gestion de la direction d’un véhicule) attend un
résultat fourni par une autre (ex : détecteur de choc), on parle de
tâches dépendantes,
• Exemple pour trois tâches T1, T2 et T3 dont on donne ci-dessous le
graphe de dépendance :
• 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é
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
d’activation. La date de réveil ri de Ti devient :
r*i = max { ri, max{ r*j + C j } },
©ENST 8/06/10
pour j tel que Tj précède Ti
r*i = max { ri, max{ r*j + C j } },
pour j tel que Tj précède Ti
• Si la dépendance est une communication par message, on ajoute le
délai ! ij dû à la durée de la transmission et la date de réveil devient :
r*= max { r, max{ r*+ C+ ! j } , pour j tel que Tj précède Ti
118
©ENST 8/06/10
119
STR Embarqués
STR Embarqués
Gestion
des interruptions
• On associe à chaque interruption une fonction de traitement (vecteur
d’interruption, ISR) :
- Attention au partage de données
Gestion
Des interruptions
• Tables des vecteurs, priorités, masquage, traitement
•Horloges
- 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 ?
- périodiquement : tous les n tics d’horloge,
- préemption,
o sert à gérer des alarmes (quantum, échéance), utilisation
d’une liste du type delta
- time of day clock (consulté à sa demande par le système)
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
dans un STRE
• Elément déterminant d'un STRE : la gestion des entrées-sorties :
- lire (périph. , données, échéance)
Spécificité des systèmes embarqués :
Gestion de lʼénergie
• Les dispositifs embarqués sont souvent contraints par la ressource
énergie (les batteries ont une capacité limitée) :
- à 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,
- annuler une demande lorsque son échéance est dépassée,
- réordonner les demandes si une plus prioritaire arrive,
• Le système peut prendre en charge cette gestion, car il a une vue
globale :
- ordonnancement prenant en compte la gestion de l’énergie
• Plusieurs stratégies :
• Si les tâches partagent des ressources (capteurs/émetteurs, accès au
réseau) :
- transition (passage d’un état à un autre), exemple : mise en
veille du processeur
- utiliser des algorithmes d’ordonnancement entre tâches
dépendantes,
- adaptation (changement de technologie), exemple : remplacer
un disque par de la mémoire flash
- utiliser PCP ou PIP pour accéder aux sémaphores gérant les
ressources,
- modification de la charge d’un composant, par exemple :
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,
-entrées-sorties indépendantes du processeur (DMA),
©ENST 8/06/10
122
• Le matériel propose des outils : mise en veille, réduction de fréquence,
©ENST 8/06/10
123
STR Embarqués
STR Embarqués
STRE
Plan
c. les STRE
b. Ordonnancement
c. Entrées/sorties
5. Perspectives
©ENST 8/06/10
124
©ENST 8/06/10
125
STR Embarqués
STR Embarqués
Environnement
de développement
Environnement
de développement
• Cycle de mise au point :
• Développement en environnement croisé : compilateur croisé et outils
associés, suivi de mise au point à distance ( remote debugging),
Edition de sources
• Les développements ne se font plus en assembleur, le langage de haut
niveau peut prendre en main les problèmes proches du matériel,
Compilation croisée
et éditions de liens
Téléchargement
• Utilisation de plus en plus courante de logiciels du type gnu (gcc,
gdb)
Moniteur
Exécution et mise
au point
• Style de programmation spécifique (pas d'allocation dynamique de
ressources, gestion de timers, écriture de pilotes d’E/S, ...)
Système +
application
EPROM, Flash
RAM
Host (hôte)
Target (cible)
1. téléchargement
ROM RAM
Processeur A
Outils dedéveloppement croisé
2. Exécution/mise
au point
Processeur B
• Le moniteur sert à démarrer (« booter ») la carte : il initialise les
registres de base du processeur, et gère au moins une ligne série pour
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
de développement
Exemples
• RTEMS et ppcboot :
• Plate-forme logicielle de base :
- un STRE (ex : RTEMS),
Target (cible)
- un ou plusieurs compilateurs croisés (ex : gcc sur PC-Linux
générant du code pour Motorola PowerPC) et des outils de
développement croisés (les bibliothèques C),
ROM RAM
- un moniteur (ex : ppcboot) et des protocoles de communication pour
le téléchargement et la mise au point (ex : tftp),
• On rappelle ci-dessous la place du BSP qui isole le système de la
configuration matérielle :
Pilotes
Processeur de base
Carte particulière
Matériel
Outils dedéveloppement croisé
2. Exécution/mise
au point
Processeur A
Processeur B
Moniteur en ROM
Pas d'écran
Pas de disque
• Embedded Linux (< 500K octets avec TCP-IP), et mise au point avec
remote gdb :
Bibliothèque, threads, etc
Systéme
Host (hôte)
1. téléchargement
Hôte : PC
sous Linux
Cible : plateforme
PowerPC
BSP
MPC860
RAM
Interface
Ethernet
• Pour réduire les coûts
Port série
- simulateurs,
1. téléchargement
BDM
Port parallèle
2. accès nfs
Interface
Ethernet
3. Exécution/mise
au point
- plate-forme de développement propriétaires,
- outils free software,
©ENST 8/06/10
128
©ENST 8/06/10
129
Port série
COM1
STR Embarqués
STR Embarqués
Du côté du matériel
• A vérifier du côté architecture matérielle :
Quelques critères
Pour la conception
• 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
STRE
Facteurs
intervenant dans la
gestion du temps
(rappels)
•
Facteurs matériels d’indéterminisme dans la gestion mémoire :
- pagination (en général inhibée en embarqué),
- fonctionnement des mémoires caches,
• Facteurs
matériels d’indéterminisme dans la gestion du processeur :
- pipe-line,
- superscalaire, VLIW…
•
•
Attention au partage des ressources :
- pb. de concurrence (inversion de priorité),
Attention à la gestion des entrées-sorties à bas niveau:
- priorités, échéances, interruptions
- attention au bon typage des variables (cf. volatile en C pour l’accès
aux registres des périphériques),
©ENST 8/06/10
132
Plan
c. les STRE
b. Ordonnancement
c. Entrées/sorties
5. Perspectives
©ENST 8/06/10
133
STR Embarqués
STR Embarqués
Quelques STR
embarqués ...
Quelques systèmes
Embarqués :
• Propriétaires :
- LynxOS de Lynx, 4% du marché, QNX, 5% du marché,
- iRMX, produit par Intel pour 8086, 5% du marché,
• Parmi les systèmes temps réel portés sur de nombreuses plateformes,
citons :
- pSOS (ISI) et VRTX (Microtec) pour 68xxx, 9% du marché,
- RTEMS,
- VxWorks, 286 Ko, de WindRiver (terminaux X, Mars Pathfinder),
11% du marché,
- Linux (RTLinux),
• 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 :
- RTEMS de OAR, implémenté en C et Ada, porté sur de très
nombreux processeurs et BSP,
• Dans le monde des systèmes embarqués sur les mobiles, mais non
temps réel : Microsoft Mobile Windows et la JVM J2ME.
- 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
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
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
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,
Quelques systèmes
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.
- 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.
-
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
embarqués: RTSJ
Quelques systèmes
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 :
o L’ordonnancement doit être préemptif, avec une gestion FIFO
des threads ayant la même priorité, la JVM ne peut changer la
priorité d’un thread que dans le cas de l’inversion de priorité,
o Gestion des threads au niveau utilisateur :
! caractérisation fine des threads temps réel en précisant
leur coût, leur échéance et leur période,
• Windows Mobile (http://www.microsoft.com/windowsmobile) :
- Windows Mobile 5.0 de Microsoft n’est pas temps réel mais
propose la technologie push qui permet de recevoir des mails le plus
tôt possible. Une technologie qui a fait le succès de RIM (Research
In
Motion,
http://www.rim.com)
et
Blackberry
(http://www.blackberry.com) : 3 millions d'utilisateurs dans le monde,
- possibilité de stockage des informations utilisateur en mémoire
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
(RT CORBA, …) ?
• Ordonnancement : notions de partitions (ARINC 653), ordonnancement
dynamique et adaptable (flexible scheduling, power aware scheduling),
c. les STRE
• Gestion mémoire déterministe (cf les outils RTSJ),
• Gestion de l’énergie : par l’ordonnancement, par le matériel, à la
compilation ?
• Compilateurs , exemple : impact de la compilation sur la gestion de
l’énergie :
b. Ordonnancement
c. Entrées/sorties
- réduction du nombre d’instructions (+)
- unrolling des boucles (-)
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

Systèmes temps réel Embarqués STRE

Transcription

Documents pareils

Stage de développement Java d`une heuristique d

SYSTÈMES EMBARQUÉS ET RÉSEAUX ÉLECTRIQUES

Conception et Commande des Systèmes Electriques Embarqués.

Licence Professionnelle CCSEE

Formation continue à la Faculté des Sciences de Kénitra Université

MASTER recherche SISEA

Ingénieur par apprentissage / Systèmes embarqués

INGENIEURS SYSTEMES EMBARQUES Contexte

la licence professionnelle - IUT de Vélizy