Vous êtes sur la page 1sur 58

Architectures logicielles TR embarques

Architectures logicielles Pour systmes temps rel embarqus INF342

Telecom-ParisTech 6/05/11

Architectures logicielles TR embarques

Plan
1. Architectures embarques : de lapplication au matriel a. Les 3 niveaux : application, support dexcution, matriel b. Les 3 contraintes, consquences c. Larchitecture logicielle : i. un systme ractif ii. Larchitecture logicielle : adaptation des modles d. Les domaines dapplication 2. Les supports dexcution a. Notions de base : priorit, premption b. Evolution c. Les diffrents modles d. Quelques points techniques 3. Les supports dexcution disponibles a. Exemples b. Critres de choix 4. Perspectives

Telecom-ParisTech 6/05/11

Architectures logicielles TR embarques

Plan
1. Architectures embarques : de lapplication au matriel a. Les 3 niveaux : application, support dexcution, matriel b. Les 3 contraintes, consquences c. Larchitecture logicielle : i. un systme ractif ii. Larchitecture logicielle : adaptation des modles d. Les domaines dapplication 2. Les supports dexcution a. Notions de base : priorit, premption b. Evolution c. Les diffrents modles d. Quelques points techniques 3. Les supports dexcution disponibles a. Exemples b. Critres de choix

Telecom-ParisTech 6/05/11

Architectures logicielles TR embarques

Architecture, partie logicielle : lapplication


Le matriel (robot, ) interagit avec le monde extrieur en utilisant des capteurs et des actionneurs : Environnement ! " Matriel de communication: capteurs et actionneurs

Pour commander les priphriques, on leur associe une informatique embarque : Environnement Matriel de ! communication, " capteurs et actionneurs Matriel informatique embarqu (processeur, mmoire, bus), donc disposant de ressources limites. Contrainte 1 : comme toute application TR, lapplication est soumise des contraintes temporelles, contraintes imposes par des stimuli externes : ceux des priphriques (priodes, chances, gigues), Application:conception dun modle et dune architecture logicielle !

Telecom-ParisTech 6/05/11

Architectures logicielles TR embarques

Architecture, partie logicielle : support dexcution


On choisit, ou on construit, un support dexcution (interface avec le matriel) pour rendre accessible au logiciel applicatif lensemble des ressources matrielles :
Architecture matrielle Environnement Architecture logicielle Logiciel applicatif

Matriel de ! communication, " capteurs et actionneurs


Matriel informatique embarqu disposant de ressources limites

#$ Support dexcution

Le support dexcution peut tre rudimentaire (simple gestion des timers et des interruptions) ou trs labor et fournir des services de haut niveau (synchronisation, ordonnancement, etc) Contraintes 2 et 3 : Larchitecture logicielle est contrainte par les ressources matrielles,

Telecom-ParisTech 6/05/11

Architectures logicielles TR embarques

Lensemble matriel et logiciel doit garantir : fiabilit et disponibilit (sret de fonctionnement),

Telecom-ParisTech 6/05/11

Architectures logicielles TR embarques

Architecture, partie matrielle


Schma simplifi dune architecture matrielle embarque : o processeur (grandes capacits dE/S, mais limit en nergie), o mmoire, o les units dchange contrlent les priphriques, nombreux et spcifiques grs en espace dadressage unique, ou non, % en gnral : pas de support de stockage permanent,
Processeur Mmoire Unit d'change Donnes Adresses Contrle

Les interactions avec les priphriques sont de deux types (on peut avoir les combinaisons -1-, -2- , -1et 2-- : 1. contrles par une horloge (chantillonnage, prise de mesures), cest dire time driven (ou time triggered), 2. vnementielles (alarmes), cest dire event driven (ou event triggered),

Telecom-ParisTech 6/05/11

Architectures logicielles TR embarques

Les trois contraintes : exemples


1. Ressources limites, cest dire : faible poids, faible consommation, faible encombrement. Quelques exemples : % mmoire : faible espace dadressage (small footprint,) ! allocation statique, % faible rserve dnergie, or les E/S sont trs consommatrices ! la fiabilit, la disponibilit pour viter des E/S rptes, % stockage de masse : souvent absent, disk on RAM, 2. Contraintes temporelles : % chances, gigue, WCET 3. Suret de fonctionnement : % la panne dun composant ne doit pas remettre en cause la vie du systme, % robustesse : rsistance aux vibrations, chocs, temprature,

Telecom-ParisTech 6/05/11

Architectures logicielles TR embarques

Contraintes : consquences
Quelques exemples : Niveau applicatif : les algorithmes utiliss dans les STR ne peuvent pas toujours tre implants cause d'une trop grande consommation de ressources : o taille mmoire du code, des donnes, o dgradation des performances en fonction des restrictions de ressources, Niveau support dexcution : gestion de la mmoire : o Les supports dexcution peuvent proposer des facilits pour dimensionner prcisment lespace dadressage dune application, o Les processus d'allocation dynamique et de rcupration sont revoir (cf. le garbage collector des JVM temps rel), Gestion des pannes : les interventions de maintenance sont difficiles ou impossibles, ce qui implique : o un haut niveau de disponibilit, o des possibilits de fonctionnement en mode dgrad,

Telecom-ParisTech 6/05/11

Architectures logicielles TR embarques

Larchitecture logicielle : un systme ractif


Larchitecture logicielle est le systme de commande de lensemble du dispositif :
Environnement contrl Systme de commande Capteur/Emetteur Noyau temps rel Ordonnancement Communications Langage de programmation

Rle et mode de fonctionnement de larchitecture logicielle : rpondre aux stimuli du monde extrieur, en excutant des traitements soumis des contraintes temporelles galement fournies par lenvironnement, elle ne dcide pas de la base de temps, comme dans les cas des systmes temps partag, cest un systme ractif : les contraintes temporelles sont imposes par lenvironnement, Un systme ractif est en interaction constante avec son environnement, il en reoit des signaux et rpond par des signaux en sortie en excutant des fonctions soumises des contraintes temporelles fortes

Telecom-ParisTech 6/05/11

10

Architectures logicielles TR embarques

Plan
1. Architectures embarques : de lapplication au matriel a. Les 3 niveaux : application, support dexcution, matriel b. Les 3 contraintes, consquences c. Larchitecture logicielle : i. un systme ractif ii. Larchitecture logicielle : adaptation des modles d. Les domaines dapplication 2. Les supports dexcution a. Notions de base : priorit, premption b. Evolution c. Les diffrents modles d. Quelques points techniques 3. Les supports dexcution disponibles a. Exemples b. Critres de choix

Telecom-ParisTech 6/05/11

11

Architectures logicielles TR embarques

Adaptation du modle du logiciel applicatif A celui du support dexcution


Lapplication interagit avec le monde extrieur en utilisant le support dexcution qui lui donne accs au matriel :
! " (API)

Modle applicatif

Support dexcution

! Matriel " (adresses mmoire et instructions)

Le support dexcution peut tre plus ou moins complexe et son modle de tches (ordonnancement) plus ou moins proche de celui de lapplication,

Problme : les styles de fonctionnement de ces trois composantes peuvent donc diffrer, par exemple : % modle de tche applicatif : RMS, ordonnancement fourni par les support dexcution : FCFS (FIFO) premptif, matriel event triggered, o consquence : lapplication devra donc implmenter RMS en utilisant FIFO, et le support se satisfaire dun seul type de trigger,

Telecom-ParisTech 6/05/11

12

Architectures logicielles TR embarques

Adaptation du modle du logiciel applicatif A celui du support dexcution

Exemples de problmes dajustement des diffrents modles :

Modle applicatif Support dexcution Matriel

RMS RTEMS (FIFO premptif) Type des triggers? Linux RT ARINC

"
Problme : Comment grer Ladaptation RMS sur FIFO ?

"

"

Les timers matriels sont plus ou moins prcis : larchitecture logicielle doit prendre en compte la gestion des gigue et des drives dhorloges,

Telecom-ParisTech 6/05/11

13

Architectures logicielles TR embarques

Plan
1. Architectures embarques : de lapplication au matriel a. Les 3 niveaux : application, support dexcution, matriel b. Les 3 contraintes, consquences c. Larchitecture logicielle : i. un systme ractif ii. Larchitecture logicielle : adaptation des modles d. Les domaines dapplication 2. Les supports dexcution a. Notions de base : priorit, premption b. Evolution c. Les diffrents modles d. Quelques points techniques 3. Les supports dexcution disponibles a. Exemples b. Critres de choix

Telecom-ParisTech 6/05/11

14

Architectures logicielles TR embarques

Domaines dapplication Des architectures logicielles TR embarques


Les domaines traditionnels : - spatial, avionique (systmes temps rel rpartis embarqus), - robotique, - contrle de processus industriels (chimie, nuclaire, ), Les nouveaux domaines: - transport, - mdical, - lectronique grand public (jeux), tlphonie mobile, - systmes embarqus temps rel rpartis grande chelle (digital city,), - informatique diffuse (pervasive computing, ubiquitous computing), wearable computer, domotique, objets intelligents (smart objects), immeubles intelligents

Telecom-ParisTech 6/05/11

15

Architectures logicielles TR embarques

Le march
Tendances : Ce march devient un march de masse, Standardisation (POSIX temps rel, embedded Linux, RTSJ), March atomis : Pas d'offre globale (on compose soi-mme sa configuration tant au niveau matriel que logiciel), Pas de fournisseur dominant (31% de systmes dits "propritaires"), Microsoft, Sun, IBM sont marginaux, Secteur Arospatilae, militaire Transports Industrie Tlecomm. Maturit Forte Contraintes Tendances Rduction des cots (conomie d'chelle) Ergonomie, rseau Rseau Puissance Internet Commerce en ligne

Performance, fiabilit Moyenne Fiabilit, cot Forte Fiabilit, cot Forte Performance, Fiabilit Grand public Faible Performance, cot Commerce elec. Faible Fiabilit, cot, scurit

Telecom-ParisTech 6/05/11

16

Architectures logicielles TR embarques

Plan
1. Architectures embarques : de lapplication au matriel a. Les 3 niveaux : application, support dexcution, matriel b. Les 3 contraintes, consquences c. Larchitecture logicielle : i. un systme ractif ii. Larchitecture logicielle : adaptation des modles d. Les domaines dapplication 2. Les supports dexcution a. Notions de base : priorit, premption b. Evolution des supports d'excution c. Les diffrents modles d. Quelques points techniques 3. Les supports dexcution disponibles a. Exemples b. Critres de choix

Telecom-ParisTech 6/05/11

17

Architectures logicielles TR embarques

Retour sur le modle applicatif


L'application interagit avec l'extrieur en dialoguant avec les priphriques. On donne ci-dessous le diagramme d'activit des 4 tches grant les priphriques P1 P4.
date P1 P2 P3 P4 0 XXX XX XXX X XX d1 XXxX d2 d3 d4 dn XXX

On a donc plusieurs activits en parallle, un seul processeur : il va falloir grer une file d'attente pour l'accs ce processeur, c'est dire ordonnancer ces activits (ordonnancement hors-ligne possible) :
FA des date tches Tche 0 t1 t2 T3 tn P2 P1 P3 P4 P2

Si des interruptions surviennent pendant le droulement d'une activit, il va falloir grer deux files d'attente :
FA des 0 t1 t2 T3 tn tches P2 P1 P3 P4 P2 FA des 0 t1 t2 T3 tn interr. P2 P1 P3 P4 P2

Telecom-ParisTech 6/05/11

18

Architectures logicielles TR embarques

Support dexcution : gestion des vnements


Comment grer loccurrence dvnements pendant lexcution dune tche ? Cas 1, occurrence dun seul vnement pendant lactivation dune tche : Tche courante # vnement Question : continuer la tche courante ou excuter le traitement correspondant lvnement ? Rponse : premption. Cas 2, occurrence de plusieurs vnements pendant lactivation dune tche : Tche courante # # vnement vnement # vnement

Question : continuer la tche courante ou excuter le traitement correspondant lun des vnement, et, si oui ; lequel ? Rponse : priorit.

Telecom-ParisTech 6/05/11

19

Architectures logicielles TR embarques

Le concept de premption
Que faire pour traiter lvnement si un trigger se dclenche au cours dune excution : attendre la fin de lactivit courante ou le traiter immdiatement ? Rponse, premption ; cest dire : 1. arrt de la tche courante, 2. sauvegarde du contexte de cette tche courante, 3. si lvnement externe (r)active une tche plus prioritaire que la courante, alors : a. crer ou restaurer le contexte de la tche dmarrer ou ractiver, b. sinon, restaurer le contexte de la tche courante

Problmes lis : - quelles tches peut-on prempter (notion de priorit des vnements) ? - gestion fine du contexte, - gestion des donnes partages : o entre tches, entre tches et interruptions,

Telecom-ParisTech 6/05/11

20

Architectures logicielles TR embarques

Gestion des priorits

Lattribution de priorits aux activits permet de rsoudre le problme suivant : lorsque plusieurs tches sont excutables (cest dire se trouvant dans ltat prt), laquelle d'entre elles doit tre active ? rponse : la plus prioritaire, mais comment attribuer les priorits : - priorit fixe (RMS) ou variable (EDF), - la priorit doit-elle reflter : o le respect des chances, o la criticit (la tche dont lexcution est la plus importante nest pas forcment celle dont lchance est la plus proche).

Telecom-ParisTech 6/05/11

21

Architectures logicielles TR embarques

Plan
1. Architectures embarques : de lapplication au matriel a. Les 3 niveaux : application, support dexcution, matriel b. Les 3 contraintes, consquences c. Larchitecture logicielle : i. un systme ractif ii. Larchitecture logicielle : adaptation des modles d. Les domaines dapplication 2. Les supports dexcution a. Notions de base : priorit, premption b. Evolution c. Les diffrents modles d. Quelques points techniques 3. Les supports dexcution disponibles a. Exemples b. Critres de choix

Telecom-ParisTech 6/05/11

22

Architectures logicielles TR embarques

Evolution des supports dexcution (1)

Structure dune architecture logicielle embarque dans les annes 1970 : 1- Logiciel applicatif : Application souvent crite la fois en langage machine et en langage de haut niveau

2- Logiciel de base (support dexcution) : Souvent une simple de boucle : tests de variables dtat associes chacun des capteurs et excution de fonctions appropries. Mise jour des donnes et des registres par les procdures de gestion des interruptions bas niveau (ISR, Interrupt Service Routines). Ces procdures sont crites en assembleur. Le support dexcution (minimaliste et efficace) est trs adapt une plate-forme matrielle. Portabilit ? Rutilisation ?

Note : Ce type de support d'excution, trs peu consommateur de ressources, convient si l'application et le matriel prsentent peu de variabilit.

Telecom-ParisTech 6/05/11

23

Architectures logicielles TR embarques

Evolution des supports dexcution (2)


Structure dune architecture logicielle embarque actuelle: 1- Logiciel applicatif : Application souvent crite en langage de haut niveau (Java RTSJ, Ada, ) 2- Logiciel de base (support dexcution) : Bibliothques (exemple : POSIX threads) Intergiciel (exemple : RT CORBA) Noyau temps rel embarqu (exemple : RTEMS) qui offre : o Ordonnancement, synchronisation, gestion mmoire (indpendants de la configuration matrielle) o Support de diffrents BSP (ou HAL) : portabilit, rutilisation Partie spcifique un ensemble (processeur et carte lectronique spcifique) :

BSP, Board Support Package ; HAL, Hardware Layer

Telecom-ParisTech 6/05/11

24

Architectures logicielles TR embarques

Evolution des supports dexcution (3)

Cette structuration en nombreuses couches rpond : o la grande diversit des plateformes matrielle : % ajout/retrait des capteurs/metteurs, le Hardware Layer ou le Board Support Package sont une couche qui spare du noyau les sections de code spcifiques au processeur et aux priphriques, % drives temporelles des horloges, o la variabilit des applications : % nombre de tches, diffrence WCET/temps effectif,

Telecom-ParisTech 6/05/11

25

Architectures logicielles TR embarques

Evolution des supports dexcution (4)

Le support dexcution (embarqu, il doit donc tre peu consommateur de ressources !) offre donc une varit de fonctionnalits permettant de construire un systme ractif : Une (ou plusieurs) politique(s) dordonnancement, des outils de synchronisation adapts au temps rel (PCP, PIP), Des moyens de rpondre sous contraintes temporelles aux vnements externes, Files des messages "temps rel"

Nous avons vu que les deux concepts la base des ces fonctionnalits sont : Premption, Priorit,

Telecom-ParisTech 6/05/11

26

Architectures logicielles TR embarques

Plan
1. Architectures embarques : de lapplication au matriel a. Les 3 niveaux : application, support dexcution, matriel b. Les 3 contraintes, consquences c. Larchitecture logicielle : i. un systme ractif ii. Larchitecture logicielle : adaptation des modles d. Les domaines dapplication 2. Les supports dexcution a. Notions de base : priorit, premption b. Evolution c. Les diffrents modles d. Quelques points techniques 3. Les supports dexcution disponibles a. Exemples b. Critres de choix

Telecom-ParisTech 6/05/11

27

Architectures logicielles TR embarques

Modles pour les supports dexcution


Modles sans tche (prdictibles mais pas flexibles, efficaces : simples appels de fonctions) : sans boucle, avec boucle, o srialisation des vnements Modles avec tches , on peut distinguer deux familles, en fonction du type de services proposs : ordonnanceur avec gestion lmentaire de la concurrence, o linterface avec le matriel se fait directement bas sniveau. Ce modle est bien adapt si la configuration matrielle et le modle applicatif sont trs proches, noyau modulaire et interface base de services, notion de HAL, o bien adapt si la variabilit est grande, par exemple dans le cas dune configuration matrielle dote de capteurs nombreux, varis, et dont les temps de rponse sont trs variables.

Telecom-ParisTech 6/05/11

28

Architectures logicielles TR embarques

Modle sans tche

Domaines dapplication du modle : fortes contraintes sur les ressources matrielles, donc peu (ou pas) de variabilit, peu de paralllisme grer, l'ordonnancement hors ligne est possible, efficace, difficilement portable, pas rutilisable,

Implmentation du modle : sans boucle o srialisation (bin packing), avec boucle o boucle de scrutation des vnements,

Telecom-ParisTech 6/05/11

29

Architectures logicielles TR embarques

Modle sans tche : La boucle de scrutation des vnements


Cest une suite de tests qui priphrique (srialisation) : vrifie ltat de chaque

o Si cet tat a chang, alors excution dune action, o Sinon : rien. Avantages :

Latence du systme = temps de traitement d'une boucle, Simple programmer, Inconvnients Alignement de la boucle sur le priphrique le plus lent, Programme difficile maintenir, La suite dfinit un ordre, donc une priorit implicite, sur les
traitements,

Pas de gestion immdiate des interruptions : le dialogue avec les


priphriques se fait linitiative de lapplication (alors que lobjectif peut tre du type event driven ),

Telecom-ParisTech 6/05/11

30

Architectures logicielles TR embarques

Modle avec tches : Excutif cyclique time driven


Fonctionnement driv de celui de la boucle: o Un timer lance les tches, o Chacune est excute en totalit avant de passer la suivante, o La dernire doit se terminer avant la prochaine interruption timer, o Pour grer des vnements qui ont des frquences diffrentes, on peut excuter certaines tches plusieurs fois dans un cycle (cycle majeur et cycle mineur),

Telecom-ParisTech 6/05/11

31

Architectures logicielles TR embarques

Modle avec tches : Excutif/systme


Excutif temps rel, moniteur temps rel (par exemple, RTEMS): - recompil avec l'application, se prsente sous forme dune bibliothque, linke avec l'application. On recharge lensemble [application+systme] chaque fois quon relance lapplication. - Il est de trs petite taille, parce que modulable en fonction de lapplication, - gestion mmoire trs simple donc efficace en terme de temps, - pas d'interface utilisateur, le couple cran/clavier nest plus le priphrique privilgi, Systme temps rel (par exemple, Linux) : - systme charg en entier en mmoire, il reste en mmoire et permet lexcution successive de plusieurs applications, - mais il est plus volumineux quun excutif, - plus portable ( ?), souvent compatible POSIX, - utilisation plus souple (interface du type shell), mais est-ce toujours ncessaire ?

Telecom-ParisTech 6/05/11

32

Architectures logicielles TR embarques

Plan
1. Architectures embarques : de lapplication au matriel a. Les 3 niveaux : application, support dexcution, matriel b. Les 3 contraintes, consquences c. Larchitecture logicielle : i. un systme ractif ii. Larchitecture logicielle : adaptation des modles d. Les domaines dapplication 2. Les supports dexcution a. Notions de base : priorit, premption b. Evolution c. Les diffrents modles d. Quelques points techniques 3. Les supports dexcution disponibles a. Exemples b. Critres de choix

Telecom-ParisTech 6/05/11

33

Architectures logicielles TR embarques

Les interruptions
Elles sont l'outil qui permet aux de renvoyer les vnements externes vers le processeur, par exemple :

Mots cls : tables des vecteurs dinterruption, priorits, masquage, Horloges, par exemple : - time of day clock : o mise jour dun compteur qui est ventuellement lu par le systme ou les applications, - real time clock (interrompt le processeur) : o envoie une interruption chaque tick, o sert grer des alarmes (quantum, chance), utilisation dune liste du type delta,

Telecom-ParisTech 6/05/11

34

Architectures logicielles TR embarques

Ordonnancement, la processs table


Structure de la table des processus, ou process table : - une entre par tche, - chaque entre contient (ou permet de retrouver) : o l'tat de la tche, o une copie des valeurs des registres lors de la dernire premption de cette tche, en particulier celles du compteur ordinal et du pointeur de pile (sauvegarde du contexte), o des informations sur la consommation des ressources, par exemple : % le nom du smaphore sur lequel il est bloqu, % les messages qui lui ont t envoys, % les priphriques utiliss,

Telecom-ParisTech 6/05/11

35

Architectures logicielles TR embarques

Ordonnancement : mcanisme Du changement de contexte (1)

La dcision de changement de contexte (passage d'un tche une autre) peut intervenir aprs une premption, une opration sur un smaphore, une interruption

Cette dcision est prise par le scheduler (ordonnanceur) (qui peut tre une simple fonction sched (): - il choisit le plus prioritaire des processus se trouvant dans l'tat READY (prt) ou CURRENT (actif, running), - il fait passer (ou laisse, dans ce cas pas de changement de contexte) le processus choisi dans l'tat CURRENT, - fait ventuellement passer le CURRENT en READY, - appelle une fonction du type ctxswitch,

Telecom-ParisTech 6/05/11

36

Architectures logicielles TR embarques

Le changement de contexte : La fonction o on ne revient jamais


La fonction ctxswitch: - sauve les registres, - restaure le contexte du processus rordonnanc, - ATTENTION : ds que le compteur ordinal est restaur, on part dans le code du processus rordonnanc : on ne revient pas de la fonction ctxswitch qui a fait ce changement de contexte !!!! Dans l'exemple suivant : o le processus B se bloque sur une opration P sur un smaphore Sem, o P appelle le scheduler qui donne la main au processus A, o Changement de contexte en faveur de A, appel ctxswt(B,A), o On ne sort pas de la fonction ctxswt, on retourne dans le programme excut par A, o A fait V(Sem), ce qui va ractiver B, parce que B est plus prioritaire que A, on restaure le contexte de B o On revient dans le programme excut par B,

Telecom-ParisTech 6/05/11

37

Architectures logicielles TR embarques

Le changement de contexte :

Telecom-ParisTech 6/05/11

38

Architectures logicielles TR embarques

Changement de contexte Et ordonnancement

Quelques prcisions : - la valeur du compteur ordinal sauve sur la pile lors de l'appel ctxswitch est bien sa propre adresse de retour, comme pour toutes les fonctions : o cest celle o devrait revenir ctxswitch si elle tait une fonction ordinaire mais ctxswitch sauve le contexte courant du processus A, et restaure la valeur du CO qui avait t sauve dans le programme excut par B, ctxswitch n'excutera donc jamais pas son propre return, l'excution continue dans le programme excut par B, - les processus appellent sched() pour dcider quel processus doit tre active, donc : o tous les processus suspendus reviennent dans sched() aprs lappel ctxswitch, o cest le retour de sched ()qui les renvoie dans la fonction qui a appel sched()

Telecom-ParisTech 6/05/11

39

Architectures logicielles TR embarques

Le processus null ou idle,

le rle du scheduler est seulement de choisir un processus parmi les READY et CURRENT : - il ne cr PAS de processus, - il ne vrifie pas si la liste des READY est vide, Consquence : il doit toujours y avoir au moins un processus dans ltat READY : le null process,

Telecom-ParisTech 6/05/11

40

Architectures logicielles TR embarques

Gestion de la concurrence : Les smaphores


Opration P : - si le compteur passe ngatif : o faire passer le processus de CURRENT BLOCKED, o indique le numro du smaphore dans lentre de la process table associe au processus, o appel sched(),

Opration V : - si le compteur passe ngatif ou nul : o choisir un READY, processus et le faire passer de BLOCKED

o appel sched(),

Telecom-ParisTech 6/05/11

41

Architectures logicielles TR embarques

Les entres-sorties
Elment dterminant d'un STRE : la gestion des entres-sorties : - lire (priph. , donnes, chance) On doit pouvoir grer les e/s comme on gre les processus : - satisfaire la plus prioritaire d'abord, - annuler une demande lorsque son chance est dpasse, - rordonner les demandes si une plus prioritaire arrive, Si les tches partagent des ressources (capteurs/metteurs, accs au rseau) : - utiliser des algorithmes dordonnancement entre tches dpendantes, - utiliser PCP ou PIP pour accder aux smaphores grant les ressources, Attention aux mcanismes matriels : -entres-sorties excutes par le processeur, -entres-sorties indpendantes du processeur (DMA),

Telecom-ParisTech 6/05/11

42

Architectures logicielles TR embarques

Plan
1. Architectures embarques : de lapplication au matriel a. Les 3 niveaux : application, support dexcution, matriel b. Larchitecture logicielle : un systme ractif c. Larchitecture logicielle : adaptation des modles d. Les domaines dapplication 2. Les supports dexcution a. Notions de base : priorit, premption b. Evolution c. Les diffrents modles d. Quelques points techniques 3. Les supports dexcution disponibles a. Exemples b. Critres de choix

Telecom-ParisTech 6/05/11

43

Architectures logicielles TR embarques

Quelques supports d'excution temps rel embarqus


Propritaires : - VxWorks, de WindRiver (NASA : Mars Pathfinder, ), - VRTX, de Mentor Graphics, tlscope Hubble, - LynxOS de Lynuxworks, armement, free software : - RTEMS de OAR, implment en C et Ada, port sur de trs nombreux processeurs et BSP, - Linux embarqus varis (RT-Linux, Linux-RTAI) universitaires : Spring (EDF), ARTS, MARTE (RT POSIX), TinyOS spcifications : - JVM : la version RTSJ, - ARINC 653, avionique haute disponibilit,
o o o o o http://www.lynuxworks.com http://marte.unican.es http://www.tinyos.net http://www.rtems.com http://www.arinc.com

Telecom-ParisTech 6/05/11

44

Architectures logicielles TR embarques

RTEMS

RTEMS (Real-Time Executive for Multiprocessor Systems) de OAR (On-Line Applications Research Corporation) http://www.rtems.com : - temps rel dur, port sur de trs nombreuses plateformes matrielles, - excution dterministe : elle ne varie pas en fonction du nombre dobjets prsents sur le systme, temps de latence d aux interruptions prdictible, - ordonnancement premptif, bas sur les priorits, RMS fourni, - le systme est configurable : seules sont charges les fonctionnalits (tches, smaphores, timers, ) ncessaires une application donne (notion de manager), on optimise ainsi les performances en vitesse et on minimise lespace dadressage utilis, - possibilit dintgrer des services spcifiques par la mise en uvre dextensions (pour insrer des traces, etc) - implment en C et Ada, API POSIX, versions (BSP) pour Motorola PPC, M68xxx, Intel ix86, i960, MIPS, SPARC,

Telecom-ParisTech 6/05/11

45

Architectures logicielles TR embarques

Linux temps rel


RT Linux (Real time Linux), http://www.rtlinuxfree.com et RTAI (Real Time Application Interface for Linux), http://www.rtai.org) : - Construits partir du systme temps partag Linux, qui prsente les dfauts suivants : o sections de code du noyau pendant lexcution desquelles les vnements externes sont masqus, o support partiel de linterface POSIX temps rel. Deux techniques pour rendre Linux temps rel : - applications de patches sur le noyau pour y placer des points de premption, - insertion dun second noyau entre Linux et le matriel (approche adopte par RTAI),

Telecom-ParisTech 6/05/11

46

Architectures logicielles TR embarques

Symbian
Symbian, http://www.symbian.com : - construit au dessus de EKA2 qui est un noyau mono utilisateur, multitches, premptif, peu consommateur de mmoire et dnergie. Priorits premptives, synchro. PIP, - appels systme en temps born, timer haute rsolution, latence pour le traitement des interruptions est de 0,5ms 1ms. Symbian ne fait pas dhypothse sur le MMU du processeur et propose plusieurs modles de mmoire. - outils de communication entre threads, de gestion des interruptions, dcriture de pilotes, des moyens pour le contrle gestion de lnergie et la dfinition du HAL. La gestion de la scurit et des fichiers est galement prvue. - Gestion de pile GSM.

Telecom-ParisTech 6/05/11

47

Architectures logicielles TR embarques

ARINC 653
ARINC 653 ( Aeronautical Radio Inc, http://www.arinc.com) est une spcification pour lavionique qui dcrit linterface que doit proposer un STRE dans une perspective de haute disponibilit : - indpendance de lexcution des tches de criticits diffrentes en introduisant la notion de partition. Une partition isole les donnes et programmes dune application du point de vue mmoire mais aussi du point de vue temporel : chaque partition dispose de son propre espace dadressage et de crneaux de temps. Elle ne peut empiter ni sur les crneaux temporels ni sur lespace mmoire des autres partitions. ordonnancement cyclique : une partition peut tre active une ou plusieurs fois par cycle. A lintrieur dune partition diffrentes tches peuvent tre ordonnances de faon priodique ou non, la norme attend un ordonnancement par priorit et premptif. - La communication entre partitions se fait par messages, les messages sont reus et mis par les applications sur des ports, le support de communication est gr par le systme, les applications ne voient que les ports. - Les services fournis par le systme sont aussi isols dans une partition spcifique. Traitement des pannes par limplantation du Health Monitor.

Telecom-ParisTech 6/05/11

48

Architectures logicielles TR embarques

JVM version RTSJ


RTSJ, Real-Time Specification for Java est une spcification de fonctionnalits temps rel pour les JVM (http://www.rtj.org) : - Les apports de cette spcification sont orients vers le dterminisme temporel : o Lordonnancement doit tre premptif, avec une gestion FIFO des threads ayant la mme priorit, la JVM ne peut changer la priorit dun thread que dans le cas de linversion de priorit, o Gestion des threads au niveau utilisateur : % caractrisation fine des threads temps rel prcisant leur cot, leur chance et leur priode, en

% cration de threads de priorit suprieure celle du garbage collector. % service de contrle dadmission : on peut demander le calcul de lordonnanabilit dun jeu de threads. RTSJ propose aussi des outils pour construire des ordonnancements RMS, EDF ou LLF, pour crer des zones de mmoire qui ne sont pas gres par le garbage collector, et met disposition des timers haute rsolution dterministes ainsi que des mthodes pour la gestion des vnements asynchrones.

Telecom-ParisTech 6/05/11

49

Architectures logicielles TR embarques

Plan
1. Architectures embarques : de lapplication au matriel a. Les 3 niveaux : application, support dexcution, matriel b. Larchitecture logicielle : un systme ractif c. Larchitecture logicielle : adaptation des modles d. Les domaines dapplication 2. Les supports dexcution a. Notions de base : priorit, premption b. Evolution c. Les diffrents modles d. Quelques points techniques 3. Les supports dexcution disponibles a. Exemples b. Critres de choix

Telecom-ParisTech 6/05/11

50

Architectures logicielles TR embarques

Comment choisir le support dexcution


Plus est grande la variabilit des diffrents lments (nombre de tches, WCET, gigues, etc), plus il faudra un support dexcution complexe : o pas de variabilit, connaissance a priori de toutes les contraintes --> ordonnancement hors ligne et criture dune squence de fonctions qui traitent les ractions aux vnements, o variabilit importante, comment choisir (si on peut choisir) le support d'excution : % sur quelle cible (BSP) va tre dploye lapplication ? % taille mmoire ncessaire en RAM et en ROM (footprint), % pilotes de priphriques disponibles, facilit de leur criture, % quels langages de programmation sont disponibles ? % outils de dveloppement proposs, % accs ou non au code source, support technique, maturit,

Telecom-ParisTech 6/05/11

51

Architectures logicielles TR embarques

Surcots temporels ds au Support d!excution


Une fois choisi le support d'excution, il faut en vrifier les caractristiques, par exemple : o Changement de contexte : ne se fait jamais en temps nul, il faut le prendre en compte dans le WCET, o Partage des ressources : il faut connatre la borne temporelle des oprations P et V sur les smpahores dans tous les cas (standard, PCP, PIP), o Gestion de la hirarchie de mmoire : attention la pagination (mais en gnral inhibe en embarqu), fonctionnement des mmoires caches, o Entres-sorties bas niveau : attention aux priorits, chances,

Telecom-ParisTech 6/05/11

52

Architectures logicielles TR embarques

Quelques critres pour la conception(1)


Identifier le type des vnements externes et celui des rponses leur apporter : o type dvnement : priodique, alarme, requte sporadique, combien d'chances peut-on manquer ? o type de rponse : temps de rponse born, commande priodique, Le modle applicatif dduit est-il proche de celui fournit par le support dexcution : o si non : adapter limplmentation du modle applicatif au modle propos par le support dexcution, o si ncessaire : adapter galement cette implmentation au type du matriel (event/time triggered), Choix des algorithmes : o ils doivent se satisfaire des performances (vitesse, taille) des ressources offertes par la plate-forme matrielle (mmoire, ),

Telecom-ParisTech 6/05/11

53

Architectures logicielles TR embarques

Quelques critres pour la conception(2)


Gestion mmoire : o pour le dterminisme temporel des accs la mmoire: % pr-allocation statique des ressources (donnes, threads), pas d'allocation dynamique (new, malloc) % temps d'allocation proportionnel l'espace d'adressage mmoire demand (cf. RTSJ), % pas d'dition de liens dynamique, mais dition de liens statique, Gestion des E/S : o elles sont trs couteuses, donc il faut les limiter. La fiabilit vitera les signalisations d'erreurs,

Telecom-ParisTech 6/05/11

54

Architectures logicielles TR embarques

Plan
1. Architectures embarques : de lapplication au matriel a. Les 3 niveaux : application, support dexcution, matriel b. Larchitecture logicielle : un systme ractif c. Larchitecture logicielle : adaptation des modles d. Les domaines dapplication 2. Les supports dexcution a. Notions de base : priorit, premption b. Evolution c. Les diffrents modles d. Quelques points techniques 3. Les supports dexcution disponibles a. Exemples b. Critres de choix 4. Perspectives

Telecom-ParisTech 6/05/11

55

Architectures logicielles TR embarques

Perspectives : support d!excution


Du plus petit au plus grand : o Supports miniatures pour les rseaux de capteurs : TinyOS de Berkeley, o Systmes embarqus distribus grande chelle : RT CORBA,

Ordonnancement : notions de partitions (ARINC 653), ordonnancement dynamique et adaptable (flexible scheduling, power aware scheduling), Gestion mmoire dterministe (cf. les outils RTSJ), Gestion de lnergie,

Telecom-ParisTech 6/05/11

56

Architectures logicielles TR embarques

Perspectives : matriel
Modle trs simplifi des ressources matrielles :
Processeur Mmoire Unit d'change Donnes Adresses Contrle

Chaque composant dterministes :

doit

avoir

caractristiques

temporelles

o bus CAN, bus TTP(Time Triggered Protocol), protocole TDMA, o gestion mmoire dterministe (cf. caches), Compromis matriel/logiciel : - seules les fonctions simples et prennes sont ralises en matriel, - tendance aux processeurs gnralistes et aux ralisations logicielles, - le matriel assure la performance, le logiciel apporte portabilit, flexibilit

Telecom-ParisTech 6/05/11

57

Architectures logicielles TR embarques

Telecom-ParisTech 6/05/11

58

Vous aimerez peut-être aussi