Chapitre 1 : Généralités sur les systèmes embarqués

Généralités sur les systèmes embarqués

1. Introduction
L'ingénierie des systèmes embarqués est un champ d’activité se trouvant à la frontière de
l’informatique (logiciels, plates-formes) et de l’électronique (microcontrôleurs, processeurs de
traitement de signal, circuits spécifiques, capteurs, actionneurs). Ce « mariage » entre
l’électronique et l’informatique a donné naissance à un ensemble de méthodes, de techniques
et d’outils qui associent le hardware et le software pour concevoir et développer des sous-
systèmes autonomes, intelligents capables d’assurer, des fonctions allant du simple contrôle,
de la communication de la surveillance à la supervision dans les secteurs suivants :

• le transport automobile et aéronautique : assistance à la conduite et à la commande de

vol, maintenance des véhicules, contrôle aérien ;

• le spatial : véhicule orbital ;

• la défense : contrôle de trajectoires, lanceur ;

• le secteur de la santé : équipement de diagnostic médical et de soins ;

• le secteur manufacturier : automatismes industriels, dispositifs de sécurité, assistance à

la maintenance ;

• l'électronique grand public : appareils photographiques et vidéo, lecteurs DVD, gros

électroménager ;

• les télécommunications : téléphones, switches, routeurs ;

• l'agriculture : robots, surveillance.

Ces systèmes connaissent ces dernières années un développement sans précédent,

néanmoins, ce développement ne se fait pas sans contraintes. En effet, ces systèmes subissent
des contraintes fortes et plusieurs défis technologiques doivent être affrontés :

• Faible consommation,

• Capacité mémoire réduite,

• Communication en temps-réel,

• Méthode de conception pour une double intégration (Hardware et software)

• Tolérance aux fautes, et sécurité,

Pr. Amami Benaissa

I-1
Chapitre 1 : Généralités sur les systèmes embarqués

• Embarquabilité etc..

2. Qu'est-ce qu'un système embarqué ?

Un système embarqué est l’association des systèmes d'électroniques plus ou moins complexes
et d'informatique plus ou moins évoluée. Un système embarqué peut être défini comme un
système électronique et informatique autonome, qui est dédié à une tâche bien précise. Il ne
possède généralement pas des entrées/sorties standards et classiques comme un clavier ou un
écran d'ordinateur. Le système matériel et l’application sont intimement liés, le logiciel embarqué
étant enfoui, noyé dans le matériel. Le matériel et le logiciel ne sont pas aussi facilement
discernables comme dans un environnement de travail classique de type ordinateur PC.
.

3. Caractéristiques principales d'un système embarqué

• Il n'a pas réellement de clavier standard (Bouton Poussoir, clavier matriciel...). L’affichage est
limité (écran LCD…) ou n’existe pas du tout.
• Ce n’est pas un PC en général mais des architectures similaires (x86) basse consommation
sont de plus en plus utilisées pour certaines applications embarquées. Les principales
caractéristiques d'un système embarqué sont les suivantes :
• C'est un système principalement numérique.
• Il met en oeuvre généralement un processeur.
• Il exécute une application logicielle dédiée pour réaliser une fonctionnalité précise et n'exécute
donc pas une application scientifique ou grand public traditionnelle. : PC standard peut exécuter
tout type d'applications car il est généraliste alors qu'un système embarqué n'exécute qu'une
application dédiée.
• Que l’interface IHM peut être aussi simple qu’une led qui clignote ou aussi complexe qu’un
cockpit d'avion de ligne.
• Que des circuits numériques ou des circuits analogiques sont utilisés en plus pour augmenter
les performances du système embarqué ou sa fiabilité.
L'omniprésence des systèmes embarqués dans notre vie est liée à la révolution numérique
opérée dans les années 1970 avec l'avènement des processeurs. Les processeurs, de plus en
plus rapides, puissants et bon marché ont permis cette révolution et aussi le boom du marché
de l'embarqué.
Les grands secteurs de l'embarqué concernent les domaines suivants :
• Jeux et calcul général : application similaire à une application de bureau mais empaquetée
dans un système embarqué : jeux vidéo, set top box...
• Contrôle de systèmes : automobile, process chimique, process nucléaire, système de
navigation...
• Traitement du signal : radar, sonar, compression vidéo...
• Communication et réseaux : transmission d’information et commutation, téléphonie, Internet...

La figure 1.1 présente les caractéristiques principales d'un système embarqué typique.

Pr. Amami Benaissa

I-2
Chapitre 1 : Généralités sur les systèmes embarqués

Figure 1.1 : Caractéristiques principales d'un système embarqué typique

On retrouve en entrée des capteurs généralement analogiques couplés à des convertisseurs

A/N.
On retrouve en sortie des actionneurs généralement analogiques couplés à des convertisseurs
N/A.
Au milieu, on trouve le calculateur mettant en œuvre un processeur embarqué et ses
périphériques d'E/S. Il est à noter qu'il est complété généralement d'un circuit FPGA jouant le
rôle de coprocesseur afin de proposer des accélérations matérielles au processeur.
On retrouve en fait un système d'asservissement entre les entrées et les sorties ! Il est à noter
que l'expression la plus simple de cette figure est de considérer comme capteurs, des
interrupteurs et comme actionneurs, des
Sur ce schéma théorique se greffe un paramètre important : le rôle de l'environnement extérieur.
Contrairement au PC, un système embarqué doit faire face à des environnements plus hostiles.
Il doit faire face à un ensemble de paramètres agressifs :
• Variations de la température.
• Vibrations, chocs.
• Variations des alimentations.
• Interférences RF.
• Corrosion.
• Eau, feu, radiations.
• ...
L'environnement dans lequel opère le système embarqué n'est pas contrôlé ou contrôlable. Cela
suppose donc de prendre en compte ce paramètre lors de sa conception. On doit par exemple
Pr. Amami Benaissa

I-3
Chapitre 1 : Généralités sur les systèmes embarqués

prendre en compte les évolutions des caractéristiques électriques des composants en fonction
de la température, des radiations.
Enfin pour terminer cette partie, les systèmes embarqués sont aujourd'hui fortement
communicants. Cela est possible grâce aux puissances de calcul offertes par les processeurs
pour l'embarqué (32 bits en particulier) et grâce aussi à l'explosion de l'usage la connectivité
Internet ou connectivité IP.
La connectivité IP permet fondamentalement de contrôler à distance un système embarqué par
Internet. Ce n'est en fait que l'aboutissement du contrôle à distance d'un système électronique
par des liaisons de tout type : liaisons RS.232, RS.485, bus de terrain...
Cela permet l'emploi des technologies modernes du web pour ce contrôle à distance par
l'utilisateur : il suffit d'embarquer un serveur web dans son équipement électronique pour pouvoir
le contrôler ensuite à distance, de n'importe où, à l'aide d'un simple navigateur. Il n'y a plus
d'IHM spécifique à concevoir pour cela, ce rôle étant rempli par le navigateur web.
Il faut aussi noter la montée en puissance des communications sans fil dans l'embarqué au
détriment des communications filaires pour limiter le câblage et faciliter la mise en place du
système embarqué. Le Wifi et toutes les normes de réseaux sans fil IEEE 802.15 comme
Zigbee ont le vent en poupe dans l'embarqué et surtout en domotique (réseaux de capteurs
sans fil par exemple).

4. Les systèmes embarqués temps réel

On entend souvent parler de Temps Réel dès que l'on parle de système embarqué. En fait, un
système embarqué doit généralement respecter des contraintes temporelles fortes (Hard Real
Time) et l'on y trouve enfoui un système d'exploitation ou un noyau Temps Réel (Real Time
Operating System, RTOS).
Le Temps Réel est un concept un peu vague et chacun a sa propre idée sur la question.
On pourrait le définir comme : Un système est dit Temps Réel lorsque l'information après
acquisition et traitement reste encore pertinente.
Plus précisément, cela veut dire que dans le cas d'une information arrivant de façon périodique
(sous forme d’une interruption périodique du système), les temps d'acquisition et de traitement
doivent rester inférieurs à la période de rafraîchissement de cette information. Un temps
maximum d'exécution est garanti (pire cas) et non un temps moyen.
Pour cela, il faut que le noyau ou le système Temps Réel :
▪ Soit déterministe : les mêmes causes produisent les mêmes effets avec les mêmes
temps d'exécution.
▪ Soit préemptif : la tâche de plus forte priorité prête à être exécutée doit toujours avoir
accès au processeur.
Ce sont là des conditions nécessaires mais malheureusement pas suffisantes pour affirmer
qu'un système embarqué est Temps Réel par définition.
En fait, être Temps Réel, c’est être capable d’acquitter l’interruption périodique (moyennant un
temps de latence de traitement d’interruption imposé par le matériel), traiter l’information et le
signaler au niveau utilisateur (réveil d’une tâche, libération d’un sémaphore…) dans un temps
inférieur au temps entre deux interruptions périodiques consécutives.
On est donc lié à la contrainte durée entre deux interruptions. C'est donc bien le processus
extérieur à contrôler qui impose ses contraintes temporelles au système embarqué et non le
contraire.
Si cette durée est de l’ordre de la seconde (pour le contrôle d’une réaction chimique par
exemple), il ne sert à rien d’avoir un système à base de processeur 32 bits performant. Un

Pr. Amami Benaissa

I-4
Chapitre 1 : Généralités sur les systèmes embarqués

simple processeur 8 bits voire même un processeur 4 bits fera amplement l’affaire ; ce qui
permettra de minimiser les coûts sur des forts volumes de production.
Si ce temps est maintenant de quelques dizaines de microsecondes (pour le traitement des
données issues de l’observation d’une réaction nucléaire par exemple), il est alors nécessaire
de choisir un processeur nettement plus performant comme un processeur 32 bits (processeurs
ARM, ColdFire..).

4.1. Quelques définitions

▪ on parle d'un système temps réel lorsque ce système informatique contrôle (ou pilote)
un procédé physique à une vitesse adaptée à l'évolution du procédé contrôlé.
▪ Un système temps réel est un système (application ou ensemble d’applications)
informatique dont le fonctionnement est assujetti à l’évolution dynamique d’un procédé
extérieur qui lui est connecté et dont il doit contrôler le comportement.
▪ La correction d’un système temps réel dépend non seulement de la justesse des calculs
mais aussi du temps auquel les résultats sont produits (contraintes temporelles).
▪ Un système temps réel n’est pas un système « qui va vite / rapide» mais un système qui
satisfait des contraintes temporelles (les contraintes de temps dépendent de l’application
et de l’environnement alors que la rapidité dépend de la technologie utilisée, celle du
processeur par exemple). Si les contraintes temporelles de l'application ne sont pas
respectées, on parle de défaillance du système. Ces contraintes temporelles peuvent
être de deux types :
- contraintes
temporelles relatives ou lâches (temps réel mou : soft real-timé) : les
fautes temporelles sont tolérables (ex. : jeux vidéo, applications multimédia, téléphonie
mobile...) ;
-contraintes temporelles strictes ou dures (temps réel dur : hard real-time} : les
fautes temporelles ne sont pas tolérables (ex. : avionique, véhicules spatiaux,
automobile, transport ferroviaire...).

4.2. Exemples de systèmes temps réel

• Exemple : Systèmes de freinage ABS

Pr. Amami Benaissa

I-5
Chapitre 1 : Généralités sur les systèmes embarqués

Exemple de l’ABS (Système anti-blocage des roues) :

Capteurs concernés : capteur de vitesse, capteur de glissement.
Actionneurs : Système hydraulique, frein.
Contrainte :
- un système de freinage ABS ne doit pas mettre plus de 150ms pour acquérir
l’information et 1s pour réagir
- Temps de réponse inferieur à 150 ms

• Exemple de l’ESP (Electronic Stability Program) :

Exemple de l’ESP (Electronic Stability Program) :

Capteurs concernés : vitesse , volant, roues.
Actionneurs : injection moteur, frein.
Contrainte :
- réaction sur les freins et l’injection suite à un coup de volant brusque en moins
- Temps de réponse inférieur à 150 ms.
Pr. Amami Benaissa

I-6
Chapitre 1 : Généralités sur les systèmes embarqués

• Exemple de l’ Airbag

Capteurs concernés : capteurs de crash .

Actionneurs : générateur de gaz.
Contrainte :
- Il doit gonfler l'airbag en 35 à 45 millisecondes
- Au bout de 120 millisecondes, le gaz s'échappe et le sac d'air est dé
- Temps de réponse inférieur à 120 ms.

5. Conception d’un système embarqué

La conception d'un système embarqué demande à son concepteur d'être pluridisciplinaire :
électronique, informatique, réseaux, sécurité etc.…. Mais le concepteur se doit aussi d'être un
bon gestionnaire car concevoir un système embarqué revient finalement à un exercice
d'optimisation : minimiser les coûts de production pour des fonctionnalités optimales.
Le système embarqué se doit d'être :
• Robuste.
• Simple. La simplicité est gage de robustesse.
• Fiable.
• Fonctionnel. Le système doit toujours fonctionner correctement.
• Sûr surtout si la sécurité des personnes est en jeu.
• Tolérant aux fautes.
• L’encombrement.
• Le poids.
• Le packaging : difficulté de faire cohabiter dans un faible volume, électronique analogique,
électronique numérique et RF sans interférences.
• L’environnement extérieur.
• La consommation électrique. Le système embarqué nomade doit être faible consommation car
il est alimenté par des batteries. Une consommation excessive augmente le prix de revient du
système embarqué car il faut alors des batteries de plus forte capacité.
• Le coût. Beaucoup de systèmes embarqués sont fabriqués en grande série et doivent avoir
des prix de revient extrêmement faibles.

Pr. Amami Benaissa

I-7
Chapitre 1 : Généralités sur les systèmes embarqués

• Le temps de développement. Dans un marché concurrentiel et de niches, il convient d'avoir un

système opérationnel le plus rapidement possible pour être le premier sur le marché
(prototypage rapide).

6. Système de contrôle - commande

Il existe trois catégories de systèmes informatiques :

- les systèmes transformationnels qui utilisent des données fournies à l'initialisation par
l'utilisateur. Ces données, leurs traitements et l'obtention du résultat n'ont aucune contrainte de
temps ;
- les systèmes interactifs dans le sens où les données sont produites par interaction avec
l'environnement sous différentes formes (clavier, fichier, réseaux, souris, etc.). Mais le temps
n'intervient pas en tant que tel si ce n'est avec un aspect confort de travail ou qualité de service ;
- les systèmes de contrôle-commande ou réactifs qui sont aussi en relation avec
l'environnement physique réel pour les données en entrée ; mais, dans ce cas, l'aspect « temps
» a une place importante sous la forme d'un temps de réaction, d'une échéance à respecter, etc.

Pr. Amami Benaissa

I-8
Chapitre 1 : Généralités sur les systèmes embarqués

Figure 1.2 - Comparaison des systèmes de contrôle-commande par rapport aux autres
applications informatiques.

6.1. Définitions

Contrairement aux systèmes d'informatiques classique (gestion de base de données, CAO,

bureautique...) qui ont des entrées constituées de données fournies par des fichiers ou
éventuellement un operateur, un système de contrôle-commande (SCC) est définit comme un
système informatique en relation avec l'environnement physique réel externe par
l'Intermédiaire de capteurs et/ou d'actionneurs (figure 1.3). Les grandeurs physiques acquises
permettent au système de contrôle-commande de piloter un procédé physique quelconque.
C’est un système qui reçoit des informations sur l'état du procédé externe, traite ces données
et, en fonction du résultat, évalue une décision qui agit sur cet environnement extérieur afin
d'assurer un état stable.

L'interaction du système de contrôle-commande avec le procédé extérieur à piloter se

décompose en deux parties (figure 1.3) :
- observations par l'intermédiaire de capteurs (sensors) qui permettent d'obtenir des
informations sous la forme des interruptions (information tout ou rien) ou des mesures
(information continue) en provenance du procédé physique ;

- actions réalisées par l'intermédiaire d'actionneurs (actuators) qui permettent d'agir sur le
procédé physique sous la forme de commandes (modification d'état physique du système) ou
simplement sous la forme d'un affichage (diodes, lampes, afficheurs, écrans, etc.).

Pr. Amami Benaissa

I-9
Chapitre 1 : Généralités sur les systèmes embarqués

6.2. Exemple de système de contrôle - commande

La figure 1.4.représente un exemple de système de contrôle-commande. L'analyse de cet
exemple d'application permet de mettre en exergue les principales caractéristiques des
systèmes de contrôle-commande :
- grande diversité des dispositifs d'entrées/sorties : les données à acquérir qui sont fournies par
les capteurs et les données à fournir aux actionneurs sont de types très variés (continu, discret,
tout ou rien ou analogique). Il est aussi nécessaire de piloter un bus de terrain pour les
communications ;

Figure 1.3- Exemple d'une application de contrôle-commande d'un moteur à combustion.

- prise en compte des comportements concurrents : l'ensemble de ces donnés physiques qui
arrivent de l'extérieur et le réseau qui permet de recevoir des messages ne sont pas
synchronisés au niveau de leurs évolutions, par conséquent, le système informatique doit être
capable d'accepter ces variations simultanées des paramètres ;
- respect des contraintes temporelles : la caractéristique précédente impose de la part du
système informatique d'avoir une réactivité suffisante pour prendre en compte tous ces
comportements concurrents et en réponse à ceux-ci, de faire une commande en respectant un
délai compatible avec la dynamique du système ;
- sûreté de fonctionnement : les systèmes de type contrôle-commande mettent souvent en jeu
des applications qui demandent un niveau important de sécurité pour raisons de coût ou de vies
humaines. Pour répondre à cette demande, il est nécessaire de mettre en œuvre toutes les
réponses de la sûreté de fonctionnement (développements sûrs, tests, méthodes formelles,
prévisibilité, déterminisme, continuité de service, tolérance aux fautes, redondance, etc.).

6.3. Caractéristique temporelle des systèmes de contrôle-commande

Le respect des contraintes temporelles d'une application de contrôle-commande dépend
essentiellement de la dynamique du procédé. Cette caractéristique temporelle peut être très
différente suivant l'application (figure l .5) :
- Milliseconde : systèmes radar, systèmes vocaux, systèmes de mesures...
- Seconde : systèmes de visualisation, robotique...
- Minute : chaîne de fabrication...
Pr. Amami Benaissa

I - 10
Chapitre 1 : Généralités sur les systèmes embarqués

- Heure : contrôle de réactions chimiques...

Ce paramètre temporel correspond à l'ordre de grandeur de la capacité de réponse ou de
traitement du système de contrôle-commande.

Figure 1.5 - Comparaison de la dynamique de

différentes applications de contrôle-commande.

6.4. Architecture des applications de contrôle-commande

6.4.1. Architecture logicielle des applications de contrôle-commande

6.4.1.1. Architecture Multitâche

Le comportement concurrent des événements et grandeurs physiques externes amène à décrire
l'environnement comme un système fortement parallèle. L'architecture la mieux adaptée pour
répondre à ce comportement parallèle du procédé externe est une architecture multitâche.
Cette architecture logicielle multitâche facilite la conception et la mise en œuvre et surtout
augmente l'évolutivité de l'application réalisée.
D'une manière très générique, la figure 1.6 donne l'architecture logicielle d'une application de
contrôle-commande multitâche. Nous pouvons ainsi découper cet ensemble de tâches ou
activités selon les groupes suivants :
- Tâches d'entrées/sorties : ces tâches permettent d'accéder aux données externes par
l'intermédiaire de cartes d'entrées /sorties et ensuite de capteurs et d'action- directement lies au
procédé géré. Ces tâches peuvent être activées de façon régulière ou par interruption.
- Tâches de traitement : ces tâches constituent le cœur de l'application. Elles intègrent des
traitements de signaux (analyse spectrale, corrélation, traitement d'images, etc.) ou des lois de
commande (régulation tout ou rien, régulation du premier ordre, régulation PID, etc.). Dans le
cadre de cet ouvrage, nous considérerons ces tâches comme des boîtes noires, c'est-à-dire que
le traitement effectué par ces tâches relève des domaines comme le traitement du signal, le
traitement d'images ou l'automatique, disciplines qui débordent largement le contexte de ce
livre.
- Tâches de gestion de l'interface utilisateur : ces tâches permettent de présenter l'état du
procédé ou de sa gestion à l'utilisateur. En réponse, l'opérateur peut modifier les consignes

Pr. Amami Benaissa

I - 11
Chapitre 1 : Généralités sur les systèmes embarqués

données ou changer les commandes. Ces tâches peuvent être très complexes et coûteuses en
temps de calcul si l'interface gérée est de taille importante (tableau de bord} ou de type
graphique (représentation 3D).

Figure 1.6 - Architecture logicielle d'une application de contrôle-commande multitâche.

- Tâches de communications : ces tâches sont destinées à gérer les messages envoyés ou
reçus à travers un ou plusieurs réseaux ou bus de terrain. Si ce type de tâches existe,
l'application est dite distribuée ou répartie.
- Tâches de sauvegarde : ces tâches permettent de stocker l'état du système à des instants
fixés. Cette sauvegarde peut être utilisée a posteriori pour analyser le fonctionnement de
l'application ou lors d'une reprise d'exécution à une étape précédente.
Après l'analyse et la conception de l'application, nous obtenons un ensemble de tâches ou
activités qui coopèrent afin de réaliser le contrôle-commande du procédé géré. Ces tâches
appartiennent aux différents groupes listés précédemment : fâches d'entrées/sorties, tâches de
traitement, tâches de gestion de l'interface utilisateur, tâches de communications et tâches de
sauvegarde.
Les tâches obtenues, qui constituent l'application de contrôle-commande, ne sont pas des
entités d'exécution indépendantes. En effet, certaines tâches sont connectées vers l'extérieur
pour les entrées/sorties. De plus elles peuvent être liées par des relations de type (figure 1.7) :
- synchronisation : cela se traduit par une relation de précédence d'exécution entre les tâches ;
- communications : à la notion de précédence, traduite par la synchronisation, s'ajoute le
transfert de données entre les tâches ;
- partage de ressources : les tâches utilisent des éléments mis en commun au niveau du
système comme des zones mémoire, des cartes d'entrées/sorties, cartes réseau, etc. Certaines
de ces ressources, comme par exemple les zones mémoire, ne sont pas ou ne doivent pas être

Pr. Amami Benaissa

I - 12
Chapitre 1 : Généralités sur les systèmes embarqués

accessibles, pour avoir un fonctionnement correct, par plus d'une tâche à la fois, elles sont dîtes
ressources critiques.

Figure 1.7 - Représentation schématique de l'architecture multitâche

.
6.5. Développement des applications de contrôle-commande
Le développement des applications informatiques demande de plus en plus de rigueur dans le
suivi des différentes étapes de spécification, de conception et de codage. Ce cycle de
développement permet ainsi d'obtenir des applications de très bonne qualité d'un point de vue
architecture logicielle. Les tests, qui sont un point primordial dans l'obtention d'une qualité
logicielle, sont aisés à réaliser dans le cas d'applications informatique classiques, en revanche,
dans le cas des applications de contrôle-commande, les tests opérationnels en exécution réelle
sont souvent difficiles à produire à cause de diverses particularités :
- exécution unique : satellite d'exploration ;
- coût très élevé : fusée... ;
- risques humains : avion...
Ainsi, malgré des phases de tests souvent coûteuses et conséquentes, de nombreuses
applications de contrôle-commande n'ont pas rempli les objectifs fixés. Nous pouvons citer
quelques exemples connus :
- Mission Vénus : le satellite d'exploration est passé à plus de 500 000 km de la planète Venus
au lieu de 5 000 km, prévu initialement. Cet échec a été attribué à un simple remplacement
d'une virgule par un point dans un programme Fortran (« DO 20 I = 1. 5 » au lieu de
« DO 20 I - 1, 5 »).
- Avion militaire américain F16 : lors des premiers essais en vol, l'avion était déclaré sur le «
dos » au passage de l'équateur à la très grande surprise du pilote. Cela était simplement dû à
une erreur de signe dans le programme.
- Navette spatiale américaine : lors du premier lancement de la navette, le départ a été annulé
et la mission reculée de trois jours (coût très important). Ce faux départ était dû à une erreur de
synchronisation entre les deux ordinateurs de conduite de vol. Le fonctionnement en
redondance de ces ordinateurs conduisait à un test de cohérence de certaines grandeurs
physiques. Étant donné une désynchronisation de7
Pr. Amami Benaissa

I - 13
Chapitre 1 : Généralités sur les systèmes embarqués

s deux ordinateurs, ce test a été négatif simplement à cause de la mesure du même, paramètre
effectuée à des Instants différents.
- Mission sur Mars : lors de la mission d'exploration de la planète Mars par le robot Pathrînder,
une remise à zéro périodique des données acquises a fortement perturbé la mission. Ce
problème était lié à un blocage d'une tâche très prioritaire par une tâche moins prioritaire mais
détenant une ressource critique (réseau de communication vers la terre}. En particulier les
données météorologiques mesurées étaient très spécifiques d'un point de vue « durée et taille »
du fait des caractéristiques martiennes,
- Eusce Ariane V : lors du premier lancement, la fusée a dû être détruite à cause d'une
trajectoire non correcte. Cette erreur était liée à la réutilisation de certains modules logiciels
utilisés dans le contexte d'Ariane IV. Les spécifications, attachées à l'accélération, auraient dû
être différentes en termes de limites afin d'éviter ce dysfonctionnement.
Cette liste d'exemples de problèmes au niveau de l'exécution d'applications de contrôle-
commande montre la nécessité de mettre en place un cycle de développement encore plus
rigoureux pour ces applications de gestion de procédé physique dont les tests en exécution
réelle ne sont pas toujours facilement accessibles.
6.5.1. Cycle de développement des applications informatiques
Le cycle de développement des applications informatiques suit les trois étapes classiques que
sont la spécification, la conception et la programmation. L'analyse des besoins permet d'écrire le
cahier des charges de l'application. À partir de ce cahier des charges, le déroulement des trois
étapes conduit successivement aux descriptions suivantes de l'application :
- spécification globale : description de « ce que l'on a à faire » ou le « quoi », c'est-à-dire une
mise en forme plus ou moins formelle du « cahier des charges » ;
- conceptions préliminaire et détaillée : description du « comment », c'est-à-dire une
modélisation de l'architecture logicielle de l'application (modules, tâches, objets...). Il peut être
nécessaire d'employer différents niveaux de raffinement selon la taille de l'application ;
- programmation : traduction dans un langage exécutable de l'architecture logicielle de
l'application.

Une présentation généralement plus adaptée est celle du cycle en « V » (figure 1.9). Dans cette
représentation, à chaque niveau d'analyse ou de conception correspond un niveau de validation
; ainsi, nous avons :
- conception détaillée et tests unitaires ;
- conception préliminaire et tests d'intégration ;
- spécification et validation globale.
Il est évident que cette formalisation méthodologique du développement des applications
informatiques a pour principaux objectifs : éviter les fautes logicielles, accroître la maintenabilité,
faciliter l'évolutivité... À chaque étape ou ensemble d'étapes correspond une méthode qui est
généralement supportée par un outil informatique pour aider à sa mise en œuvre plus ou moins
automatisée.

Pr. Amami Benaissa

I - 14
Chapitre 1 : Généralités sur les systèmes embarqués

Figure 1.9 : Cycle de développement en « V » d'une application informatique classique.

L'expérience du développement de logiciels prouve que l'élaboration complète de l'application

ne se fait pas en une seule fois : évolution du cahier des charges, modifications du découpage
modulaire, correction de programmes, etc. Cela a induit de nouveaux schémas de
développement, appelés itératifs ou en spirale, qui consistent à prendre en compte les passages
successifs dans les différentes étapes du développement. L'idée forte à retenir est que, lors de
toutes modifications apportées à l'application à quelque niveau que ce soit, il est nécessaire de
décliner à nouveau toutes les étapes du développement.
6.5.2. Développement couplé matériel et logiciel
Il est important de remarquer la particularité du développement de ces applications quant au
caractère du couplage fort entre les aspects matériel et logiciel.
En effet, le cahier des charges d'une application de contrôle-commande d'un procédé va
intégrer dans la grande majorité des cas à la fois la description du matériel et les fonctions à
remplir par ce procédé (figure 1.10). Ainsi, la spécification de l'application commence par une
spécification système (matériel et logiciel). Une partie de la conception préliminaire peut aussi
intégrer les deux aspects puisque la réalisation d'un module fonctionnelle peut être réalisée soit
de manière matérielle (circuit intégré spécifique - FPLA : Field Programmable Logic Array ou
FPGA : Field Programmable Gâte Array) soit d'une manière logicielle. Ensuite, le
développement des deux parties peut continuer de façon différenciée et classique avec la
conception détaillée, l'implémentation (réalisation ou codage) et les tests. À nouveau, les deux
aspects de l'application doivent se rejoindre pour passer à la phase d'intégration et de validation
de l'ensemble. La phase d'intégration est certainement l'étape la plus importante et la plus
difficile. En effet, une partie logicielle va être insérée dans un environnement matériel très
spécifique.

Pr. Amami Benaissa

I - 15
Chapitre 1 : Généralités sur les systèmes embarqués

Figure 1.10 - Cycle de développement matériel et logiciel d'une application de contrôle-

commande de procédé.

il est important de noter que le développement de la partie logicielle d'une application de

contrôle-commande va être réalisé sur une plate-forme dite « hôte » qui n'a aucun rapport avec
l'environnement d'exécution ou environnement « cible » en termes de processeur, mémoire,
système d'exploitation, etc. Lorsque le logiciel applicatif est réalisé et testé autant que faire se
peut sur cette plate-forme « hôte », le programme est compilé dans le code du processeur «
cible » par un compilateur croisé ; puis il est téléchargé avec le noyau temps réel choisi vers
l'architecture matérielle « cible ». De nouveau, des tests doivent être réalisés dans cet
environnement d'exécution. En effet, le comportement du programme dans cette architecture «
cible » de l'application peut être différent et amener à des modifications conséquentes du
programme. Ce processus conduit à modifier le cycle en « V » de développement des
applications informatiques classiques par un cycle en « W » où la deuxième partie du cycle
correspond à la reprise de la première partie du cycle mais dans l'environnement « cible »
(figure 1.12). Nous trouvons en particulier dans ce cycle en « W » un codage croisé et
l'intégration avec le noyau. Ce constat de la dualité de développement des applications de
contrôle-commande de procédé amène à plusieurs remarques concernant les environnements
permettant d'élaborer ce type d'application :

Pr. Amami Benaissa

I - 16
Chapitre 1 : Généralités sur les systèmes embarqués

- le noyau temps réel choisi doit être adapté à l'architecture « cible » de l'application en termes
de codage, de taille et de fonctionnalités (primitives, gestion des entrées, gestion du temps...) ;
- l'environnement de développement sur la plate-forme « hôte » doit posséder un émulateur du
noyau temps réel afin de pouvoir faire les premiers tests du logiciel multitâche réalisé ;

Figure 1.11- Cycle de développement en « W » d'une application de contrôle-commande de

procédé.

- l'environnement de développement sur la plate-forme « hôte » doit pouvoir faire une

compilation croisée dans le code du processeur de l'architecture « cible » ;
- l'environnement de développement sur la plate-forme « hôte » doit permettre un « débogage
» de l'application lors de son exécution sur l'architecture « cible ». Cette observation de
l'exécution se fait à distance par une liaison réseau quelconque (Ethernet...). De nombreux
environnements proposent une représentation graphique de l'exécution des tâches. La plus
grande difficulté réside dans le fait de ne pas modifier l'exécution de l'application par cette
observation.

Pr. Amami Benaissa

I - 17
Chapitre 1 : Généralités sur les systèmes embarqués

Bibliographies
• Des parties du cours entière ont été extraites du livre Système temps réel de
contrôle commande de F. Cottet et E. Grolleau, Dunod 2005
• Livre : Ordonnancement et ses applications, Chengbin chu/ Jean Marie Proth,
Masson , 1996
• Commande en temps réel, Daniel Tschirhart, Dunod 1990
• Sites officiels de National Instrument
• Les systèmes électroniques embarqués dans l’automobile, l’IUT de Belfort-
Montbéliard
• Systèmes embarqués et automobile , Gérard Duchene
• Systèmes embarqués Enjeux –Perspectives, Françoise Simonot-Lion
• Les Systèmes Électroniques Embarqués un enjeu majeur pour l’automobile,
Joseph Beretta
• Tout CAN , Benoît Sanson
• Exécutif temps réel Pierre-Yves Duval , Ecole d’informatique temps réel, La
Londes les Maures 7-11 Octobre 2002
• Cours Systèmes temps rée, Azmani Monir FST Tanger 2011
• Introduction aux systèmes temps réel, Samia Bouzefrane, CEDRIC –CNA
• La méthode DARTS et la programmation multitâche en LabVIEW KhanhHieuNGO,
Emmanuel GROLLEAU LISI/ENSMA
• Systèmes temps-réel, Matthieu Herrb CNRS-LAAS, Avril 2008

Pr. Amami Benaissa

I - 18
Chapitre 1 : Généralités sur les systèmes embarqués

Sommaire
Chapitre 1 : Généralités sur les systèmes embarqués
Généralités sur les systèmes embarqués ...................................................................................................... 1

1. INTRODUCTION .................................................................................................... 1

2. QU'EST-CE QU'UN SYSTEME EMBARQUE ? ..................................................... 2

3. CARACTERISTIQUES PRINCIPALES D'UN SYSTEME EMBARQUE ................ 2

4. LES SYSTEMES EMBARQUES TEMPS REEL .................................................... 4

4.1. Quelques définitions ......................................................................................................................................... 5

4.2. Exemples de systèmes temps réel .................................................................................................................... 5

5. CONCEPTION D’UN SYSTEME EMBARQUE ...................................................... 7

6. SYSTEME DE CONTROLE - COMMANDE ........................................................... 8

6.1. Définitions ......................................................................................................................................................... 9

6.2. Exemple de système de contrôle - commande .............................................................................................. 10

6.3. Caractéristique temporelle des systèmes de contrôle-commande .............................................................. 10

6.4. Architecture des applications de contrôle-commande ................................................................................ 11

6.4.1. Architecture logicielle des applications de contrôle-commande ............................................................ 11

6.5. Développement des applications de contrôle-commande............................................................................ 13

6.5.1. Cycle de développement des applications informatiques ......................................................................... 14
6.5.2. Développement couplé matériel et logiciel .............................................................................................. 15

Pr. Amami Benaissa

I - 19