Chapitre 1 Introduction aux systèmes embarqués et temps réel

Chapitre 1 Introduction aux systèmes embarqués et temps réel

Cours – Module ASTRE

Z. MAMMERI

IRIT - UPS - Toulouse

1

1. Notions et caractéristiques des systèmes embarqués Domaines d’application des systèmes embarqués z Domaines « traditionnels »

-

Avionique Robotique Automobile Militaire

z Domaines « nouveaux »

- Jeux et loisirs - Téléphonie, Internet mobile - Implants (santé (santé, sécurité sécurité…)) - Domotique, - immeubles intelligents, - Villes intelligentes - Vêtements… Cours – Module ASTRE

Z. MAMMERI


2

1

Exemple typique de système embarqué


Z. MAMMERI


3

Exemples de systèmes embarqués Cours – Module ASTRE

Z. MAMMERI


4

2

Tendances du marché z Logiciel : - Beaucoup de fournisseurs - Pas de fournisseur dominant - Problèmes de compatibilité : Posix 1003.1c 1003 1c et 1b

z Matériel : - Processeurs essentiellement Motorola - Cartes à puce - Périphériques d’E/S (mesures…) : très diversifiés


Z. MAMMERI


5

z Définitions 1. Un système embarqué (SE) est un système informatisé spécialisé qui constitue une partie intégrante d’un système plus large ou une machine. Typiquement, c’est un système sur un seul processeur et dont les programmes sont stockés en ROM. A priori, tous les systèmes qui ont des interfaces digitales (i.e. montre, caméra, voiture…) peuvent être considérés comme des SE. Certains SE ont un système d’exploitation et d’autres non car toute leur logique peut être implantée p en un seul programme. p g 2. Un système embarqué est une combinaison de logiciel et matériel, avec des capacités fixes ou programmables, qui est spécialement conçu pour un type d’application particulier. Les distributeurs automatiques de boissons, les automobiles, les équipements médicaux, les caméras, les avions, les jouets, les téléphones portables et les PDA sont des exemples de systèmes qui abritent des SE. Les SE programmables sont dotés d’interfaces de programmation et leur programmation est une activité spécialisée. 3. Un système embarqué est une composante primordiale d’un système (i.e. un avion, une voiture…) dont l’objectif est de commander, contrôler et superviser ce système.

z ‘Embedded’ : Enfoui / Embarqué Cours – Module ASTRE

Z. MAMMERI


6

3

z Principales caractéristiques - Encombrement mémoire (mémoire limitée, pas de disque en général) - Consommation d’énergie (batterie : point faible des SE) - Poids et volume - Autonomie - Mobilité - Communication (attention : la communication affecte la batterie) - Contraintes de temps réel - Contraintes de sécurité - Coût de produits en relation avec le secteur cible


Z. MAMMERI


7

Besoins z Intégration massive de composants embarqués répartis pour bâtir la société de l’information :

téléphones cellulaires – PDA – machines programmables – automobile - appareils médicaux – photo/vidéo/hifi – g – avionique q - spatial p – jjouets électroménager z Outils théoriques et pratiques pour l’intégration permettant de prendre en compte tous ces critères à la fois - Fonctionnalité - Qualité : Robustesse et Performances - Contraintes matérielles (poids, encombrement, .. ) - Coût g global,, consommation électrique q - Délai de mise sur le marché z Construire des systèmes de fonctionnalité et qualité déterminée et garantie, à coût acceptable, est un défi technologique et scientifique majeur.


Z. MAMMERI


8

4

Aspects à considérer z Techniques : Conception conjointe (Matériel, Logiciel, Environnement) z Économiques : Optimisation par rapport au marché, entre coût et qualité z Multi-compétence : Combinaison de compétences en logiciel, contrôle, réseaux, ingénierie en électronique, IHM, automatique, médecine, mécanique…

Défis à considérer z Hétérogénéité : Construire des systèmes complexes par intégration de composants hétérogènes (mécanismes de communication, vitesse de fonctionnement, granularité des calculs, variété des médias…) z Complexité : L’effort de développement augmente exponentiellement avec le nombre de composants intégrés intégrés. D’où D où la nécessité de remplacer les méthodes de validation a posteriori par des méthodes de validation incrémentale. Développer des outils théoriques et techniques pour la validation incrémentale. z Intelligence : Moyen d’améliorer la qualité (robustesse et la performance) de système : Auto-diagnostic, Auto-configuration, Adaptabilité à l’environnement, Evaluation des risques…


Z. MAMMERI


9

Développement de SE – Niveaux d’abstraction


Z. MAMMERI


10

5

Intégration de technologies

Méthodes et outils

Programmation et Middleware Réseau OS SoC


Z. MAMMERI


11

Compétences pour la conception et développement de SE z Domaine métier : médical, loisirs, transport… z Ingénierie : électricité, électronique, chimie, mécanique, robotique, …, informatique z Sciences : mathématiques, statistiques, probabilités,recherche opérationnelle z Informatique • Algorithmique • Programmation • Architectures (CPU, mémoires, périphériques) • Gestion de l’énergie des processeurs et périphériques • Génie logiciel, co-design, méthodes formelles, automates… • Evaluation de performances, test, simulation, vérification • Systèmes S tè d’ d’exploitation l it ti ((ordonnancement…) d t ) • Sécurité et robustesse • Réseaux, mobilité • Capteurs et actionneurs • Vision par ordinateur, caméra Cours – Module ASTRE

Z. MAMMERI


12

6

2. Notions et caractéristiques des systèmes temps réel La gestion du temps dans un OS classique (temps partagé) z Un système d'exploitation (OS) classique, c.-à-d. orienté temps partagé, doit organiser et optimiser l'utilisation l utilisation des ressources de façon à ce que l'accès l accès à ces ressources soit équitable. équitable Un OS n'a donc pour seule contrainte de temps que celle d'un temps de réponse satisfaisant pour les utilisateurs avec lesquels il dialogue. Les traitements qu'on lui soumet sont effectués en parallèle au fil de l'allocation des quanta de temps aux diverses applications. z Un OS est capable de dater les événements qui surviennent au cours du déroulement de l'application! : mise à jour d'un fichier, envoi d'un message, etc. Il permet aussi de suspendre un traitement pendant un certain délai, d'en lancer un à une certaine date... z En aucun cas, un OS classique ne garantit que les résultats seront obtenus pour une date précise, surtout si ces résultats sont le fruit d'un traitement déclenché par un événement EXTERIEUR (émission d'un signal par un périphérique quelconque,…)


Z. MAMMERI


13

Définitions z « Intervalle de temps compatible avec le rythme réel d’arrivée des données et à l’intérieur duquel un ordinateur peut effectuer les traitements nécessaires » Le petit Robert. Robert z « Temps réel signifie l’aptitude d’un système d’exploitation de fournir le niveau de service requis au bout d’un temps de réponse borné ». Posix 1003.1b z Un système temps réel est un système informatique qui doit répondre à des stimuli fournis par un environnement externe afin de le contrôler. z Un STR est un système dont la correction dépend non seulement de la justesse des calculs mais aussi du temps auquel est fourni la réponse (contraintes temporelles). Un résultat hors délai et un résultat faux. Attention : Ne pas confondre temps réel et rapidité Temps réel veut dire prédictibilité et non rapidité.


Z. MAMMERI


14

7

Classification z Temps réel dur (‘hard real-time’) : le non respect des contraintes temporelles entraîne la faute du système – e.g. contrôle de trafic aérien, système de conduite de missile, ... z Temps réel souple (‘soft real-time’) : le respect des échéances est important mais le non respect des échéance n’a pas de graves conséquences – e.g. système d'acquisition de données pour affichage z Temps réel ferme (‘firm real-time’) : temps réel souple, mais si l’échéance est dépassée le résultat obtenu n’a plus de valeur (et est donc écarté) – e.g. projection vidéo


Z. MAMMERI

15


Capteurs

Actionneurs

Environnement Cours – Module ASTRE

Système de contrôle Z. MAMMERI


16

8

Domaines d’applications z Installations industrielles (chimique, nucléaire, automobile, …) z Contrôle et régulation de trafic en milieu urbain z Systèmes embarqués (voitures, (voitures trains, trains ...)) z Télécommunications z Avionique et aérospatial z Domaine militaire z Multimédia et Web (téléconférences, télé-achat, …) z Domotique, Jeux z Médecine, Télé-médecine z Réalité virtuelle, Travail coopératif z Autres Cours – Module ASTRE

Z. MAMMERI


17

Exemple simple et éclairant (1) z On dispose de deux systèmes : - Système Cool, avec : processeur à vitesse 1 ; surcoût système de 1 ; ordonnancement EDF (Earliest Deadline First) - Système Speedy, avec : processeur à vitesse 10 ; surcoût système de 0 ; ordonnancement à l'ancienneté (FIFO) z Donc Speedy est 10 fois plus rapide et infiniment plus efficace que Cool z On considère une application composée de deux tâches non préemptibles : - Tâche T1 envoie des commandes périodiques pour entretenir la commande moteur du véhicule sa durée est de 270 sur Cool et de 27 sur Speedy ; son délai critique de 320 - Tâche T2 réagit à une commande du volant ; sa durée est de 15 sur Cool et de 1,5 sur Speedy ; son délai critique est de 21. z A l’instant t=0, la tâche T1 est déclenchée pour son exécution périodique. Cependant, au même instant, T2 est demandée en réaction à un événement. Les tâches T1 et T2 sont de même importance pour la conduite du véhicule Cours – Module ASTRE

Z. MAMMERI


18

9

Exemple simple et éclairant (2) Exécution de T2 d’abord

Surcoût

T1

T2

À cause de son échéance

E é i de Exécution d 15 u.t

0

E é i de Exécution d 270 u.t

16 17

287

320

Exécution sur le processeur Cool T2 respecte son échéance T2 ne respecte pas son échéance Exécution en FIFO

Exécution de 27 u.t

0

21

27 28,5

Exécution sur le processeur Speedy


Z. MAMMERI


19

Sources des contraintes de temps (1) Î Origines externes − Caractéristiques physiques (vitesse, durée de réaction chimique, …) − Caractéristiques liées aux lois de commande du système physique − Qualité de service requise en terme de délai de réponse tolérable (qualité audio/vidéo) − Perception sensorielle et le temps de réaction de l’homme − Contraintes à caractère commercial − Autres

Connaissance des aspects physiques nécessaire Cours – Module ASTRE

Z. MAMMERI


20

10

Sources des contraintes de temps (2) Î Origines internes − Choix de conception • architecture centralisée ou répartie (données, traitements, contrôle) • actions périodiques (avec les périodes adéquates) ou apériodiques • choix d’une structure d’application (interface entre composants, …) • autres

− Choix d’architecture matérielle et logicielle • processeurs avec des vitesses particulières • système d’exploitation (intégrant des algorithmes d’ordonnancement) • réseau avec des débits et des temps de réponse donnés • autres


Z. MAMMERI


21

Expression des contraintes de temps (1) Expression à l’aide du temps quantifié (temps physique) Î Temps absolu − un instant (date) − une fenêtre temporelle (intervalle de temps)

Î Temps relatif − une durée (délai, (délai période), période) minimale, minimale maximale, maximale moyenne


Z. MAMMERI


22

11

Expression des contraintes de temps (2) Expression sur les événements Î Contraintes sur la durée de vie d’un événement Î Contraintes sur les instants et l’ordre d’occurrence d’événements é é

Expression sur les données Î Durée de validité (ou contrainte de fraîcheur) Î Contraintes de production Î Contraintes de corrélation


Z. MAMMERI


23

Expression des contraintes de temps (4) Expression sur les actions (opérations) Î Période Î Instant au plus tôt/tard, pour démarrer une action Î Instant au plus tard/tôt, pour finir une action Î Temps maximum d’exécution (ou échéance relative) Î Temps maximal d’attente d’une ressource Î Temps minimal/maximal d’utilisation d’une ressource Î Temps minimum d’exécution affecté à une action Î Précédence entre actions


Z. MAMMERI


24

12

Quelques ordres de grandeur Domaines d’applications

Ordre de grandeur des CT

Î Processus chimique

en heure

Î Fabrication

en minute

Î Robotique

en 10 ms

Î Systèmes vocaux

en ms

Î Systèmes radar

en ms


Z. MAMMERI


25

Principes et concepts de base (1) z Application temps réel = Ensemble de tâches qui coopèrent z Les tâches accèdent à des ressources communes z Les tâches s s’échangent échangent des messages via un réseau z Les tâches doivent respecter différentes contraintes : - Cohérence des ressources partagées - Tolérance aux fautes - Sécurité - Temps de réponse z Les tâches s’exécutent sur 1 ou n processeurs z Système temps réel vs Application temps réel Les deux notions sont souvent confondues Cours – Module ASTRE

Z. MAMMERI


26

13

Exemple d’application temps réel et embarquée (1)

zTâches critiques : - Contrôle airbag, contrôle ABS - Contrôle injection injection-moteur moteur - Contrôle pneumatique… zTâches non critiques z Contrôle climatisation z Contrôle vitres z Radio … Cours – Module ASTRE

Z. MAMMERI

27


Exemple d’application temps réel et embarquée (2)

Tâches contrôle de vol

Tâches gestion de cabine

Tâches de Maintenance Cours – Module ASTRE

Z. MAMMERI


28

14

Eléments constituant le temps de réponse d’une tâche z Temps d’exécution (Worst Case Execution Time) z Temps d’attente de ressources z Temps d’attente des E/S z Temps dus au système d’exploitation et difficilement calculables – Temps de latence des interruptions (délai entre l’arrivée d’une IT et le début de sa prise en compte effective)

– Temps de préemption (délai de sélection de la tâche à exécuter)

– Latence de l’ordonnancement (dél i entre (délai t lla réception é ti d de l’IT ett l’l’entrée té d dans lla tâ tâche h d de l’l’utilisateur) tili t )

– Temps de commutation de contexte de tâche – Latence de sémaphore (délai entre la libération d’un sémaphore et la réactivation de la tâche bloquée derrière ce sémaphore) Cours – Module ASTRE

Z. MAMMERI

29


Exemple de temps de réponse à un événement z - On considère deux threads Th1 et Th2. Th1 est le plus prioritaire. - A l’instant t0, Th1 lance une E/S. - Le dessin ci-dessous schématise la suite des événements : Th2 devient actif Th1 se met en attente de l’E/S

t0

Le driver fait Passer Th1 à prêt Fin de l’E/S

t1

Temps d’élection et changement de contexte

t2

Th2 est préempté

t3 Latence d’IT

t4

Temps de préemption

Th1 devient Th1 sort de l’appel actif système (E/S)

t5

t6

Temps de Durée de changement retour de de contexte l’appel système

Durée de l’opération d’E/S Cours – Module ASTRE

Z. MAMMERI


30

15

Principes et concepts de base (2) z Problèmes à gérer - Problèmes de l’informatique classique - Concurrence

en présence de contraintes de temps

- Communication

“

“

“

- Tolérance aux fautes

“

“

“

- Sécurité

“

“

“

z L’ordonnancement joue un rôle fondamental


Z. MAMMERI


31

Langages de développement (1) z Besoins – Expression des contraintes de temps – Expression et gestion du parallélisme – spécification et gestion de périphérique de bas niveau (E/S de base) – Modularité – Interfaces avec d’autres langages z 3 familles de langages – Langages assembleurs – Langages séquentiels liés à des librairies système – Langages concurrents de haut niveau Langages synchrones (Lustre, Esterel…) : déterminisme garanti Langages asynchrones (SDL, UML, Java…) : difficulté de garantir le déterminisme


Z. MAMMERI


32

16

Langages de développement (2) z Langages assembleurs – Historiquement, ces langages furent longtemps les seuls à être utilisés dans le contexte des STR – Dépendant par nature de l'architecture cible (matériel et système d'exploitation) – Aucune abstraction possible et grande difficulté de développement, de maintenance et d'évolution – Langages à proscrire sauf pour l'implémentation de petites fonctionnalités très spécifiques et apportant t t une grande d amélioration éli ti des d performances f

z Langages séquentiels liés à des librairies système – Les plus connus sont le C, le C++, Fortran – Apportent un plus grand pouvoir d'abstraction et une certaine indépendance du matériel – Mais, doivent faire appel à des librairies systèmes spécifiques pour la manipulations des processus – Ils posent le problème de la standardisation des appels systèmes mais sont quelques fois le seul choix possible à cause de la spécificité d'une cible et des outils de développement sur celle-ci.

z Langages concurrents de haut niveau – Langages généralistes incluant de plus la notion de tâches et des primitives de synchronisation – Haut pouvoir d'abstraction, indépendance des architecture et des systèmes cibles – Parmi ces langages, Ada et Java sont des plus aboutis – Ces langages sont à privilégier lorsque d'autres contraintes ne rendent pas leur choix impossible Cours – Module ASTRE

Z. MAMMERI


33

Exécutifs temps réel (1) (RTOS : Real-Time Operating Systems) z Exécutif = Noyau de système d’exploitation z Caractéristiques d’un exécutif temps réel – comportement de l’OS prédictible * Ordonnancement de tâches prédictible * Gestion de ressources prédictible – dédié à une application spécifique (système embarqué) – plus spécialisé qu'un système d'exploitation – code de taille plus petite qu'un système classique – taille mémoire réduite ((services optimisés p et ceux non utilisés supprimés) pp ) – surcoût du système minimal (changement de contexte) – nombre élevé d’IT utilisables par les tâches – facilité d’insertion et retrait de périphériques


Z. MAMMERI


34

17

Exécutifs temps réel (2)

Applications

Applications

Middleware

Middleware

Drivers

Système d’exploitation

RTOS

Drivers

STR fondés sur un RTOS

STR utilisant un OS conventionnel (approche peu efficace, non recommandée)


Z. MAMMERI


35

Exemples de Système d'exploitation temps réel z Produits commerciaux - Lynx-OS : système Unix à base de thread noyau - compatible avec Linux www.lynuxworks.com/ - QNX : système Unix www.qnx.com/ - Windows CE : système Microsoft temps réel www.microsoft.com/technet/prodtechnol/wce/plan/realtime.mspx - VxWorks et pSos : Exécutif de Wind river www.windriver.com/products/device_technologies/os/vxworks5/ - Nucleus Real-Time Operating System /p y / / / www.mentor.com/proyducts/embedded_software/nucleus_rtos/index.cfm z Open sources – extensions de Lunix - RT-Linux : www.fsmlabs.com/rtlinuxpro.html - KURT : www.ittc.ku.edu/kurt - RTAI : www.aero.polimi.it/rtai/news/index.html Cours – Module ASTRE

Z. MAMMERI


36

18

Standards POSIX pour le temps réel z POSIX = Portable Operating System Interface for uniX z Objectifs : Définir une interface standard entre les applications et l’OS pour rendre les applications (TRE) portables z Services proposés - Threads, ordonnancement, synchronisation - Gestion du temps - Files de messages, signaux - E/S asynchrones - Gestion de la mémoire z POSIX 1003.1 : interface de base d’accès à l’OS. z POSIX 1003.1b (appelé aussi 1003.4) – 1993 : Extensions temps réel (ordonnancement à priorité, signaux TR, horloges et timers, sémaphores, messages, E/S asynchrones…) z POSIX 1003.1c (appelé aussi 1003.4) – 1993 : Extensions de threads (création/destruction de threads, synchronisation et ordonnancement de threads…) z Beaucoup d’implantations de POSIX sont disponibles : Lynx, VxWorks, RTEMS… Cours – Module ASTRE

Z. MAMMERI

37


Architecture logiciel d’un système TRE N oyau tem ps réel G estion du tem p s

H orloge tem p s réel

G estio n des évén em en ts P rim itives

IT

G estion d es in terrup tions

O rd on n an ceu r

R eq uête

A ctivation

T âch es u tilisateu r T âch e i


Z. MAMMERI

T âche j

T âch e k


38

19

Niveaux simplifiés pour un STRE

Espace Utilisateur RT User process

RT User process

NonRT User process

Appels système

Ordonnancement de processus

Espace Système NonRT Kernel t k task

RT Kernel t k task

RT kernel t k task

Données

IT

Hardware


Z. MAMMERI

39


Exemple de tâches temps réel (en langage FlowC)

Filter

GetData IN

DATA

DATA

La tâche GetData mesure une température à partir de l’environnement et envoie la valeur mesurée à la tâche Filter. U mesure estt effectuée Une ff t é toutes t t les l 10 ms. Quand N mesures ont été effectuées, la moyenne des N mesures est envoyée à Filter.


Z. MAMMERI

COEF OUT

La tâche Filter lit N mesures et les ignore et lit ensuite la moyenne des mesures, multiplie cette moyenne par c (dont la valeur est lue à partir de COEF) et envoie la valeur obtenue à l’environnement via le port OUT.


40

20

Exemple de tâches temps réel (en langage FlowC)

Process GetData

Process Filter

(InPort IN, OutPort DATA)

(InPort DATA, InPort COEF, OutPort OUT)

{ float mesure, somme; int i;

{ float c, d; int j;

While(1)

c = 1; j = 0;

{ somme = 0;

While(1)

for (i=0; i< N; i++) {

{ SELECT(DATA, COEF) {

READ(IN, mesure ,1);

CASE DATA: READ(DATA, d, 1);

somme+= mesure ;

if (j==N) {j=0; d=d*c;

WRITE(DATA, mesure, 1)

WRITE(OUT, d,1); } else j++;

DELAY(10)

CASE COEF: READ(COEF, c, 1); break ;

} WRITE(DATA, somme/N,1)

}}}

}}


Z. MAMMERI


41

21

Chapitre 1 Introduction aux systèmes embarqués et temps réel

Recommend Documents