Cours de Systèmes Experts Et Temps Réel - 2020-2021

UNIVERSITE DE MBUJI-MAYI
FACULTES SCIENCES APPLIQUEES

L2 Informatique
SYSTEME EXPERT ET TEMPS

REEL
Notes de Cours
Prof. Dr. Jean Didier BATUBENGA
Septembre 2021
Cours de Système Expert et Temps réel, L2 Informatique
1
Prof. Dr. Batubenga Mwamba Nz. J.D.
Chapitre 1 : Introduction aux Systèmes temps réel et Systèmes embarqués

1.1. Notion de « système temps réel »
Dans le processus de choix de moyens conduisant à l‟informatisation, il existe trois types de
solutions informatiques :
- Le traitement en temps réel,
- Le traitement en temps différé
- Le traitement en temps partagé.
Un traitement est dit en temps différé, lorsqu‟il y a un décalage entre la saisie des informations
et l‟obtention des résultats. En d‟autres termes, il y a désynchronisation dans le temps entre les
quatre opérations : saisie des données, transmission, traitement et restitution des résultats.
Un traitement est dit en temps partagé, lorsque plusieurs utilisateurs accèdent à un ordinateur
central d‟une manière simultanée. Chacun des utilisateurs pouvant travailler sur ses propres
programmes.
Un traitement est dit en temps réel, lorsque l‟événement qui a fourni l‟information n‟étant pas
encore terminé, il y a un feed back (une réponse). En d‟autres termes, il n‟y a pas de décalage
de temps entre les quatre opérations précitées.
Nombreux sont ceux qui ont essayé de donner une définition au terme système temps réel, nous
en avons retenu deux :
Définition 1
« On qualifie de temps réel, les systèmes dont la réactivité est assujettie à l‟évolution de l‟état
d‟un environnement, qui peut être l‟homme, un phénomène naturel ou artificiel, un équipement
manufacturé ... Dans ces systèmes, le facteur temps est une contrainte essentielle à respecter, et
ce facteur est prépondérant pour évaluer la qualité du service. »
Définition 2
« Un système temps réel est un système dans lequel l‟exactitude de son fonctionnement ne
dépend pas seulement de l‟exactitude du résultat mais aussi du temps auquel ce résultat est
produit. Si les contraintes temporelles de l‟application ne sont pas respectées, on parle de
défaillance du système. Il est donc essentiel de pouvoir garantir le respect des contraintes
temporelles du système. » (GILLIES, 1995)
En définitive, nous pourrions définir un système temps réel comme, un système informatique
dont les temps de réaction à l‟évolution et aux sollicitations de l‟environnement avec lequel il
est en relation, sont compatibles avec la dynamique propre de chacun des objets de cet
environnement.
1.2. Caractéristiques d’un système temps réel
Les cinq caractéristiques suivantes permettent de bien cerner ce qu‟est un système informatique
temps réel.
2
1.2.1. Système informatique en interaction avec son environnement

Tout système informatique temps réel est obligatoirement inséré dans un environnement dont il
doit commander et contrôler le comportement.
Figure 1 : système informatique en interaction avec son environnement

Une application temps réel est l‟ensemble fermé, formé du système informatique et des objets
en relation avec lui (entités).
L‟environnement est l‟ensemble des objets de l‟application, à l‟exclusion du système
informatique.
Une entité a un comportement dynamique et possède sa propre autonomie. Tout comme le
système informatique, elle possède des entrées, des sorties et au moins un état interne qui
caractérise sa situation à chaque instant.
Une entité fortement couplée par des entrées et des sorties avec le système informatique est
considérée en interaction avec lui.
Les objets de diverses natures (certains sont physiques, d‟autres sont humains) qui composent
l‟environnement d‟un système temps réel sont donc des objets dynamiques. Du fait même de
leur activité, ils génèrent des événements, des informations, des flux de données. Ils sont
d‟autre part sensibles à des sollicitations externes selon une dynamique qui leur est propre.
En conséquence, fonctionnellement, un système temps réel est dit de type réactif, car il réagit
sur l‟environnement à partir de sollicitations qui en proviennent. La fréquence des sollicitations
constitue le paramètre essentiel à prendre en compte lors de la conception du système temps
réel.
Pour satisfaire l‟objectif qui lui est assigné, le système temps réel est couplé aux objets de son
environnement par des interfaces qui lui permettent d‟observer et de commander ces objets. On
peut distinguer deux grandes catégories d‟interfaces :
 les interfaces homme-machine et ;
 les interfaces avec les entités physiques.
Les procédures d‟échanges entre le système et les différents objets de son environnement sont
tributaires de la nature de ces interfaces.
3
Interface utilisateur
Cœur du
Entrées Système temps réel Sorties

Modèle fonctionnel
(entités (entités
physiques) (indépendant de la physiques)
Maintenance
(auto-test,
redondance,…)
Les supports physiques du dialogue homme-machine peuvent être très variés : il peut s‟agir
d‟un pupitre conventionnel, d‟un ensemble clavier-écran, de dispositifs mettant en œuvre des
technologies vocales avancées (analyse et synthèse de la parole), etc.
Les entités physiques sont des procédés industriels, des machines et autres dispositifs
physiques. Ces entités fournissent par l‟intermédiaire de capteurs des signaux électriques. En
sens inverse, des actionneurs commandés électriquement permettent d‟agir sur ces entités.
1.2.2. Système qui doit effectuer des traitements simultanés
Un système temps réel doit être capable d‟assurer simultanément :
 l‟observation de grandeurs caractérisant l‟évolution de l‟activité des entités,
 la prise en compte d‟événements survenant de façon aléatoire,
 l‟évaluation, à partir des événements et des observations, des décisions à prendre,
 la génération d‟actions en direction des entités pour assurer la cohérence de l‟ensemble de
l‟application.
Le nombre de traitements simultanés que doit assurer un système temps réel dépend du nombre
des entités de son environnement et de la diversité de leur activité, et donc, du nombre des
entrées et des sorties que le système doit gérer, de la richesse des fonctionnalités du système.
Le degré de simultanéité de ces traitements est fonction de la technique de réalisation du
système informatique. La simultanéité est complète lorsqu‟une unité centrale (CPU) est
attribuée à chaque traitement à effectuer (on parle de systèmes multiprocesseurs). Il y a
pseudo-simultanéité lorsqu‟ un processeur unique partage son activité pour satisfaire plusieurs
traitements (on parle de systèmes monoprocesseurs).
1.2.3. Les activités respectent des contraintes de temps
Nous avons déjà indiqué que dans les applications temps réel le facteur temps constitue une
contrainte essentielle à respecter, que c‟est même un facteur prépondérant pour évaluer la
qualité de service du système de commande.
4
Le système informatique est tributaire de la dynamique, de la vitesse d‟évolution des objets

avec lesquels il interagit. Cet environnement est en effet constitué d‟entités qui, chacune à son
propre rythme, génèrent des événements et modifient des informations. Toute fonction du
système qui est en interaction avec une entité doit a priori réagir à la même échelle de vitesse.
La commande d‟un robot, d‟un chariot filoguidé, d‟un avion est intimement liée à la vitesse
d‟évolution, à la dynamique propre de ces objets.
D‟autre part, lors de la conception d‟un système temps réel il doit être tenu compte du temps de
réaction du programme informatique à chaque sollicitation externe. Ce temps de réaction
dépend notamment du temps de traitement de l‟information, et donc du volume des calculs et
de la puissance du processeur.
Évaluation des contraintes de temps
Un système temps réel est donc un système dont les activités respectent des contraintes de
temps bien précises. L‟interaction importante du système avec son environnement fait
apparaître plusieurs types de contraintes de temps ; celles-ci découlent de :
 La fréquence des sollicitations en provenance des entités : fréquence d‟événements, débit des
données entrantes, …
 La fréquence des actions à déterminer et à appliquer aux entités, compte tenu notamment, du
temps de réponse des procédés physiques.
 La valeur maximale admissible du temps de réaction, à savoir le temps entre l‟instant
d‟apparition d‟une sollicitation et l‟instant d‟achèvement de l‟action conséquente (date
d‟échéance).
Les performances temporelles qu‟un système doit réaliser, peuvent en définitive être exprimées
en considérant d‟une part le temps de réponse du système et d‟autre part le taux de transfert des
données :
 Le temps de réponse du système est le temps maximal qui s‟écoule entre la détection d‟un
signal externe et la génération de l‟action appropriée.
 Le taux de transfert des données, exprimé sous forme de débit, est la vitesse avec laquelle des
données sont acquises ou produites par le système.
Importance du respect des contraintes de temps
Le non-respect des contraintes de temps peut conduire l‟application dans un état assimilable à
un état de panne, ce qui peut engendrer des conséquences très graves, jusqu‟à la mise en danger
de vies humaines.
Dans un système temps réel, on parle de faute temporelle pour désigner le non-respect d‟une
échéance, de l‟arrivée hors délai d‟un message, de la non régularité d‟une période
d‟échantillonnage, d‟une dispersion temporelle trop importante dans un lot de mesures censées
être simultanées.
Contraintes strictes et contraintes relatives
Parmi toutes les contraintes temporelles d‟une application temps réel on est amené à distinguer
contraintes strictes et les contraintes relatives :
5
 Le temps réel est à contraintes strictes lorsque les conséquences d‟une seule faute temporelle
peuvent être catastrophiques.
 le temps réel est à contraintes relatives lorsque des fautes temporelles engendrent des dégâts
dont le coût, rapporté à leur probabilité d‟occurrence, est estimé tolérable pour l‟exploitant de
l‟application.
A propos du temps chronométrique et du temps chronologique
On se préoccupe des applications dont la fonction est de piloter (ou de suivre) en temps réel un
environnement par un système informatique. Il est alors commode de scinder de telles
applications en deux parties : le système informatique et le procédé, c‟est-à-dire
l‟environnement auquel ce système informatique est connecté et dont il doit commander le
comportement.
Le fait qu‟un système informatique intègre une gestion du temps constitue une spécificité
fondamentale qui le distingue d‟un système informatique classique. En effet, la validité des
résultats produits par une application temps réel ne dépend pas seulement de la justesse des
calculs, mais aussi de leur instant de production : un résultat juste mais hors délai est un résultat
faux, et est considéré comme une faute temporelle.
Or, dans une application temps réel les deux partenaires que sont le procédé et le système sont
régis par des règles d‟évolution différentes. Le procédé est régi par une dynamique propre
pouvant être exprimée par des mesures précises de durée, c‟est-à-dire par un temps
chronométrique. Un système informatique organise la succession des instructions de la
machine, et génère ainsi un temps chronologique. La conduite d‟une application temps réel par
un système informatique réside dans le bon contrôle de la concordance de ces deux temps.
Comme le temps chronométrique est régi par le procédé et en constitue une donnée intangible,
c‟est au système informatique de mettre le cadencement de ses actions en phase avec l‟horloge
du procédé.
1.2.4. Système dont le comportement est à la fois prévisible et déterministe
Selon la méthode employée par le système informatique pour prendre en compte puis répondre
aux événements externes, on obtiendra des temps de réaction plus ou moins longs et surtout
plus ou moins prévisibles.
L‟un des aspects importants des systèmes temps réel est la prévisibilité du comportement du
système. Un système temps réel doit être conçu de telle façon que ses performances soient
définies dans le pire des cas, alors que dans les systèmes classiques on s‟intéresse au traitement
du cas « moyen ». La prévisibilité est ce qui permet de déterminer à l‟avance si un système va
respecter ses contraintes temporelles. La prévisibilité est d‟autant plus forte que l‟on connaît
avec précision les paramètres liés aux calculs des activités : le temps global de calcul de chaque
activité, leur périodicité, etc. Tous ces éléments conduisent à choisir la politique
d‟ordonnancement des activités de telle manière que le comportement du système soit
prévisible.
Le déterminisme est le but que l‟on cherche à atteindre afin de prédire le comportement
temporel d‟un système : il s‟agit d‟enlever toute incertitude sur le comportement des activités
individuelles et sur leurs comportements quand elles sont mises ensemble dans le contexte
d‟exécution du système. Dans le cas du temps réel à contraintes strictes, on cherche à savoir si
6
toutes les échéances de toutes les activités seront respectées. Dans le cas du temps réel à
contraintes relatives, on cherche à connaître, par exemple, le retard moyen des activités.
Les principaux facteurs qui entraînent des variations dans le comportement du système, et sont
donc source de non-déterminisme, sont les suivants :
 charge de calcul : variation des durées d‟exécution des activités,
 entrées/sorties : profil d‟arrivée, durées des communications, temps de réaction,
 interruptions : temps de réaction du système,
 fautes et exceptions matérielles ou logicielles.
Le déterminisme absolu est difficile à atteindre ; cependant, les systèmes auront un
comportement temporel plus déterministe s‟ils utilisent les services d‟un support d‟exécution
qui masque les fluctuations mentionnées ci-dessus. Par ailleurs, certaines méthodes
d‟ordonnancement des activités du système permettent une analyse a priori du comportement
de ce dernier.
En définitive, un système temps réel est un système déterministe dans le sens où il doit offrir
des temps de réponse garantis aux diverses sollicitations de son environnement ; et ce, quel que
soit le contexte ou l‟état du système au moment où surviennent ces sollicitations. Le
déterminisme est un des concepts clés des systèmes temps réel.
1.2.5. Système qui possède une grande sûreté de fonctionnement
La sûreté de fonctionnement du système est son aptitude à minimiser la probabilité d‟apparition
de défaillances, et à minimiser leurs effets quand, malgré tout, elles se produisent.
Les principales composantes de la sûreté de fonctionnement sont :
 La sécurité : c‟est l‟aptitude à éviter des événements catastrophiques pour l‟application
considérée.
 La fiabilité : c‟est la probabilité qu‟un système fonctionne correctement durant une période de
temps T.
 La maintenabilité : c‟est la facilité que possède un système à supporter des changements pour
satisfaire les demandes des utilisateurs et pour corriger les défauts détectés.
Qui dit sécurité dit protection de l‟utilisateur et du matériel afin d‟éviter des incidents ou des
détériorations. Comme les conséquences d‟une défaillance peuvent être catastrophiques, le
système doit donc être en mesure d‟assurer en toutes circonstances la sécurité du dispositif qu‟il
commande.
Autrement dit, le dépassement d‟une valeur critique ou l‟occurrence d‟un événement accidentel
doit pouvoir être détecté à tout instant, et le traitement de cet incident doit interrompre les
opérations en cours.
Le système doit de plus garantir un service minimal ; et ceci, même en cas de panne du
matériel, d‟événements accidentels ou d‟erreurs humaines. La fonction sécurité doit donc être
prioritaire sur toutes les autres fonctions assurées par le système.
Autre aspect important des systèmes temps réel : la fiabilité. Il est en effet difficile de prédire le
comportement d‟un système dont les composants matériels et logiciels ne sont pas fiables. Pour
cette raison, les systèmes temps réel sont souvent conçus de façon à être tolérants aux fautes.
7
En résumé, dans l‟ensemble des systèmes informatiques, les systèmes temps réel présentent
des spécificités telles qu‟ils constituent un domaine à part entière.
Un système temps réel, c‟est donc tout à la fois :
 un système informatique en interaction avec son environnement,
 un système qui doit effectuer des traitements simultanés,
 un système qui effectue ses activités en respectant des contraintes de temps,
 un système dont le comportement est à la fois prévisible et déterministe,
 un système qui possède une grande sûreté de fonctionnement.
1.3. Architecture matérielle d’une application temps réel
Nous appelons architecture matérielle, l‟ensemble des composants physiques qu‟il est
nécessaire d‟ajouter à un processus pour réaliser l‟application temps réel. L‟architecture
matérielle est donc composée d‟un calculateur, de capteurs et d’actionneurs.
1.3.1. Calculateur
Le calculateur peut être composé d‟un ou plusieurs microprocesseurs, de circuits intégrés
spécialisés tels que des ASIC ou des FPGA ainsi que des médias de communication.
1.3.1.1 ASIC et FPGA
Les ASIC et les FPGA sont des circuits intégrés que l‟on peut configurer pour réaliser à bas
coût des fonctions “câblées” simples dont les temps de réaction sont extrêmement courts. La
programmation de ces circuits n‟est pas évidente car elle nécessite l‟utilisation de
programmateurs ou de procédures spécialisés. Ces circuits n‟intègrent pas de séquenceur
d‟instructions, ils ne sont donc capables que d‟exécuter une seule fonction.
1.3.1.2 Microprocesseurs, microcontrôleurs
Un microprocesseur est composé d‟un CPU2 et d‟unités de communication pour communiquer
avec des périphériques externes ou d‟autres microprocesseurs.
Le CPU est une machine séquentielle constituée généralement d‟un séquenceur d’instruction
(SI), d‟une unité de traitement (UT) et d‟une mémoire. Les dernières générations de
microprocesseurs peuvent aussi intégrer une unité de calcul flottant (FPU) dont le but est de
considérablement accélérer certains calculs mathématiques (multiplication, division, sinus,
arrondi, etc.).
Un microcontrôleur est un microprocesseur intégrant un certain nombre d‟interfaces
supplémentaires (mémoires, timers, PIO3, décodeurs d‟adresse, etc.). Ces nombreuses entrées-
sorties garantissent un interfaçage aisé avec un environnement extérieur tout en nécessitant un
minimum de circuits périphériques ce qui les rend particulièrement bien adaptés aux
applications temps réel embarquées.
Du fait de leur forte intégration en périphérique (certains microcontrôleurs vont jusqu‟à intégrer
des fonctions spécialisées dans la commande des moteurs), les microcontrôleurs sont souvent
moins puissants que les microprocesseurs; le CPU qu‟ils intègrent est généralement en retard
d‟une ou même deux générations.
8
Dans la suite du cours, nous utiliserons le terme de processeur pour désigner indifféremment un
microprocesseur ou un microcontrôleur. De ce point de vue le processeur est simplement un
circuit qui intègre un CPU.
1.3.1.3 Médias de communication
Lorsque le calculateur intègre plusieurs processeurs on dit que l‟architecture matérielle du
système est multiprocesseur ou parallèle. Les médias de communications sont les éléments qui
permettent aux processeurs d‟un calculateur multiprocesseur d‟échanger des données. On peut
classer ces médias de communication selon trois catégories principales :
 média point à point SAM ( Sequential Access Memory. L‟accès à ce type de liaison est de
type FIFO -First In First Out- pour lequel l‟ordre d‟émission des données est aussi l‟ordre de
réception) aussi appelée lien : c‟est une liaison bidirectionnelle entre deux mémoires SAM
de deux processeurs différents ;
 média multipoint SAM ou bus SAM: c‟est une liaison multidirectionnelle qui relie les
mémoires SAM de plus de deux processeurs ;
 média multipoint RAM ou bus RAM: c‟est aussi une liaison multidirectionnelle, mais ici
contrairement aux médias précédents la communication est réalisée à travers une mémoire
commune de type RAM5
1.3.2. Transducteurs
Le calculateur interagit avec le processus par l‟intermédiaire de transducteurs. Ceux qui
permettent d‟observer le processus sont appelés capteurs et ceux qui permettent d‟agir sur le
processus sont appelés actionneurs.
1.3.2.1 Capteur
Un capteur est un dispositif conçu pour mesurer une grandeur physique (température, pression,
accélération, etc.) en la convertissant en une tension ou un courant électrique. Le signal
électrique issu d‟un capteur est un signal analogique qui doit être discrétisé pour pouvoir être
traité par le calculateur. Cette discrétisation ou numérisation est réalisée par un circuit appelé
Convertisseur Analogique-Numérique (C.A.N). Il est utilisé pour échantillonner le signal
électrique issu du capteur, c‟est-à-dire mesurer- le plus souvent à des intervalles réguliers- la
valeur de ce signal électrique et ainsi produire une suite de valeurs binaires qui constituent le
signal discrétisé ou signal numérique.
L‟opération de codage de la valeur échantillonnée en un nombre binaire codé sur n bits est
appelée quantification. La résolution de la quantification et donc la précision de la mesure
dépend du nombre de bits utilisés pour coder la valeur (la valeur peut être codée sur 2n
niveaux) .
Dans le cas particulier où le codage est réalisé à l‟aide d‟un seul bit, le capteur est appelé
capteur binaire, le signal qu‟il délivre est un signal booléen qui par définition ne peut prendre
que deux valeurs (0 ou 1). Ce type de capteur est utilisé pour déterminer l‟état d‟un phénomène
modélisé par deux états exclusifs (exemple : présence/non-présence d‟un objet, seuil de
température atteint/nonatteint, récipient vide/non-vide, etc.).
9
1.3.2.2 Actionneur
L‟actionneur est un dispositif qui convertit un signal électrique en un phénomène physique

(moteur, vérin électrique, voyant, haut-parleur, etc.) censé modifier l‟état courant du processus.
Le signal de commande fourni par le calculateur est un signal numérique qu‟il faut convertir en
signal électrique analogique à l‟aide d‟un Convertisseur Numérique Analogique (C.N.A).
FIG.2 – Capteur analogique
FIG. 3 – Actionneur
Pour reconstruire un signal analogique à partir de la suite des valeurs numériques qui
constituent le signal numérique de commande, le C.N.A maintient grâce à un bloqueur, la
valeur du signal analogique à la même valeur pendant le laps de temps nécessaire au
calculateur pour produire la valeur suivante. Le signal obtenu est ensuite lissé par un filtre. Il
est à noter que ce signal analogique de commande ne peut être appliqué directement à l‟entrée
de l‟actionneur. Il est nécessaire d‟intercaler un amplificateur entre le C.N.A et l‟actionneur qui
fournira à ce dernier la puissance nécessaire à la création du phénomène physique pour lequel il
est conçu.
Certains actionneurs ne nécessitent pas l‟utilisation d‟un C.N.A car ils peuvent directement être
commandés par des signaux numériques, c‟est le cas par exemple :
 d‟une vanne hydraulique qui peut être commandée par un signal booléen (ouverte/fermée) ;
10
 d‟un moteur à courant continu piloté par un pont de transistors (rôle d‟amplificateur de
puissance) commandé par un signal booléen dont le rapport cyclique déterminera la tension
moyenne appliquée au moteur.
1.4. Notion de « Système Temps réel embarqué »
1.4.1. Définitions
La diversité des domaines d‟applications rend difficile l‟élaboration de définitions sur

lesquelles tout le monde s‟accorde.
Voici quelques définitions pour cerner le concept de système embarqué :
 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 ont 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 en un seul programme.
 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.
 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.
 Un système embarqué est un système enfoui (embedded system)
Par rapport aux autres systèmes informatisés, les systèmes embarqués sont caractérisés par :
 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 ;
1.4.2. Spécificité des systèmes temps réel embarqués

Lorsque le système temps réel est physiquement intégré à l‟environnement qu‟il contrôle et
qu‟il est soumis aux mêmes contraintes physiques (température, pression, etc.) que son
environnement, il est dit embarqué.
Exemples
Un système temps réel intégré dans un robot mobile est un système embarqué, alors qu‟un
système de contrôle de bras de robot n‟en est pas un. Dans le premier cas, le système temps réel
fait partie intégrale du robot, il se déplace avec lui, il est soumis aux mêmes contraintes
11
physiques externes. Dans le deuxième cas, le système peut être dans une armoire électrique
placée dans une pièce différente de la pièce où se situe le robot. Ce système temps réel est donc
indépendant du bras manipulateur, il n‟est pas intégré à son environnement (bras + objets
manipulés).
Les systèmes embarqués sont généralement soumis à des contraintes spécifiques de coûts pris
au sens large du terme. Ces contraintes sont dues, d‟une part, au type d‟applications couvertes
par ce type de système, d‟autre part, à l‟intégration du système à son environnement. Ces
contraintes particulières de coût sont de plusieurs types : encombrement, consommation
d‟énergie, prix, etc.
Prenons l’exemple d‟un système temps réel embarqué dans un robot dont la mission est
d‟explorer des canalisations. Ce système sera soumis à des contraintes d‟autonomie car il devra
intégrer et gérer au mieux sa propre source d‟énergie et sera soumis à de fortes contraintes
d‟encombrement.
D‟autres applications telles que les applications automobiles nécessitent l‟utilisation de
systèmes embarqués dont les contraintes sont principalement des contraintes de coût financier
(forte compétitivité du secteur commercial), d‟encombrement (habitabilité du véhicule) et de
consommation d‟énergie.
Concevoir un système temps réel embarqué nécessite une bonne maîtrise des coûts matériels
mais aussi une bonne maîtrise des coûts de développement car ces derniers représentent une
grande part du coût financier d‟une application.
1.5. Domaines d’applications des systèmes temps réel et embarqués
Jusqu‟à une date récente, les systèmes temps réel et embarqués étaient destinés quasi-
exclusivement aux applications de contrôle/commande de procédés (ou de phénomènes)
physiques (tels que des laminoirs ou des usines de fabrication de voitures) et applications
militaires. La notion de temps réel se confondait alors avec ce type d‟applications. Le
développement de l‟informatique aidant, les applications temps réel et embarqués sont
présentes aujourd‟hui dans des domaines très variés comme le montre la liste suivante, même si
elle n‟est pas exhaustive :
 télécommunications (transport de la parole, systèmes de commutation, …),
 domaine médical (assistance et supervision de malades, …),
 contrôle de différents équipements dans les voitures, bus, trains, avions, …,
 contrôle et régulation de trafic en milieu urbain,
 guidage de véhicules en milieu urbain,
 industrie (contrôle/commande de procédés manufacturiers ou continus, …),
 domaine militaire (suivi de trajectoires de missiles, …)
 aérospatial (suivi de satellites, simulation de vols, pilotage automatique, …),
 multimédia (transport d‟images et de voie, téléconférences, …),
 finance (suivi du cours des devises et actions, ...),
 loisirs (consoles de jeu, ...),
 domotique (sécurité d‟habitations, …),
 contrôle/commande d‟appareils électroménagers.
12
1.6. Décomposition des systèmes embarqués

Quelle que soit la nature et la complexité du système, on décompose un système embarqués en :
 le système contrôlé
 le système de contrôle
Le système contrôlé = environnement (procédé) équipé d'une instrumentation qui réalise
l'interface avec le système de contrôle.
Le système de contrôle = éléments matériels (microprocesseurs…) et logiciels dont la mission
est d'agir sur le procédé via les actionneurs en fonction de l‟état de ce procédé indiqué par les
capteurs de manière à maintenir ou conduire le procédé dans un état donné.
Figure 4 : Décomposition d‟un système embarqué

Un système électronique embarqué ou enfoui est un élément constitutif d'un système plus
complexe pour lequel il rend des services bien précis (contrôle, surveillance,
communication…). Il est constitué de parties matérielles et logicielles qui sont conçues
spécifiquement pour réaliser une fonction dédiée.
Système embarqué = Système électronique/informatique conçu pour réaliser une ou plusieurs
tâches précises.
1.7. Architecture des systèmes embarqués
Les architectures sont supportées par trois générations d'outils de conception.
1.7.1. Les systèmes embarqués de première génération
Ils sont composés de deux parties :
 Partie matérielle des systèmes embarqués de première génération
Les premiers systèmes embarqués supportés par des outils tels que COSYMA et Vulcan étaient
très simples : ils étaient constitués d'un processeur qui contrôlait un nombre restreint de CIAS
(circuits intégrés à applications spécifiques) ou ASIC qui étaient appelés périphériques. Les
communications de cette architecture se situent au niveau du bus du processeur et sont type
maître/esclave : le processeur est le maître et les périphériques sont les esclaves.
Les périphériques de ces architectures étaient essentiellement des capteurs et des actionneurs
(contrôleurs magnétiques, sortie, etc.). Le processeur est dédié au calcul et au contrôle de
l'ensemble du système.
Les microcontrôleurs assemblent sur une même puce le processeur et les périphériques.
13
 Partie logicielle des systèmes embarqués de première génération

Ne devant pas exécuter de nombreuses opérations simultanées (le nombre de périphériques et
de fonctions étant restreint), les parties logicielles étaient constituées d'un seul programme. La
réaction aux événements était effectuée par le biais de routines de traitement d'interruptions.
Cette partie logicielle était décrite directement en langage d'assemblage ce qui permettait
d'obtenir un code efficace et de petite taille.
1.7.2. Les systèmes embarqués de deuxième génération
Les premiers systèmes embarqués ne pouvaient fournir que des fonctions simples ne requérant
que peu de puissance de calcul. Leur architecture ne peut pas supporter les fonctionnalités
requises pour les systèmes embarqués actuels à qui il est demandé non seulement d'effectuer du
contrôle, mais aussi des calculs complexes tels que ceux requis pour le traitement numérique du
signal. De nouveaux outils tels que N2C (dans ces nouvelles versions) permettent de traiter des
architectures plus complexes.
Ils sont composés de deux parties :
 Partie matérielle des systèmes embarqués de deuxième génération :
L'architecture des systèmes embarqués de deuxième génération est composée d'un processeur
central, de nombreux périphériques, et souvent de quelques processeurs annexes contrôlés par
le processeur central. Le processeur central est dédié au contrôle de l'ensemble du système. Les
processeurs annexes sont utilisés pour les calculs ; il s'agit souvent de processeurs spécialisés
comme les DSP. Dans une telle architecture, plusieurs bus de communication peuvent être
nécessaires : chaque processeur dispose de son bus de communication.
 Partie logicielle des systèmes embarqués de deuxième génération :
La partie logicielle des systèmes embarqués de deuxième génération est répartie sur plusieurs
processeurs (le processeur principal et les processeurs annexes). Les systèmes actuels sont trop
complexes pour pouvoir être gérés par un unique programme sur le processeur principal. Il est
donc nécessaire d'avoir une gestion multitâche sur ce processeur, et un système d'exploitation
est couramment employé dans ce but.
Le logiciel du processeur central est souvent décrit dans un langage de haut niveau tel que le C.
le logiciel des processeurs annexes est souvent trop spécifique pour être entièrement décrit dans
un langage de haut niveau, et l'utilisation des langages d'assemblage est nécessaire.
1.7.3. Les systèmes embarqués de troisième génération :
Les progrès de l'intégration permettent d'envisager des circuits pouvant contenir plusieurs
milliers de portes. Il devient donc techniquement possible de fabriquer des systèmes embarqués
pouvant remplir toutes les fonctionnalités souhaitées.
 Parties matérielles des systèmes embarqués de troisième génération :
Pour pouvoir supporter conjointement les besoins en puissance et en flexibilité, ces
architectures comprennent de plus en plus de processeurs, qui peuvent chacun se comporter en
maître : l'architecture couramment utilisée, basée sur un processeur central contrôlant le reste
du système, n'est donc plus suffisante.
14
Alors que le goulot d'étranglement était les ressources en calcul, de nos jours il est situé plutôt
au niveau des communications. Ce sont elles qui définissent désormais l'architecture, et non
plus les ressources de calcul. Le premier exemple est basé sur des communications par bus : ce
modèle de communication consomme peu de surface, mais risque de devenir un goulot
d'étranglement. Le deuxième est basé sur des communications en barres croisées très
performantes mais aussi très coûteuses en surface. Le troisième exemple donne une solution
intermédiaire, par réseau commuté.
Enfin le dernier exemple montre qu'il est possible de mixer plusieurs modèles de
communication, et d'apporter de la hiérarchie dans l'architecture.
Autour de ce modèle d'architecture centré sur les communications, se greffent les autres
modèles d'architecture : architectures des éléments de calcul et des mémoires. L'architecture
des éléments de calcul consiste à définir quels sont les éléments principaux et quels sont leurs
périphériques de manière à les grouper dans une architecture locale. L'architecture des
mémoires sert à définir quelles sont les mémoires locales à un groupe et quelles sont celles qui
seront partagées.
 Parties logicielles des systèmes embarqués de troisième génération :
Les parties logicielles ont beaucoup gagné en importance dans les systèmes embarqués.
Plusieurs systèmes d'exploitation sont parfois nécessaires pour les divers processeurs de
l'architecture. De plus, la complexité et la diversité des architectures possibles font qu'il devient
de plus en plus nécessaire d'abstraire les tâches logicielles des détails du matériel. Toute cette
complexité est donc reportée dans les systèmes d'exploitation, qui deviennent de plus en plus
complexes.
Cette complexité logicielle et matérielle entraîne de nombreuses alternatives. En particulier,
l'aspect multiprocesseur apporte des alternatives pour les systèmes d'exploitation : il peut y
avoir un seul système pour tous les processeurs (solution difficilement applicable lorsque les
processeurs sont hétérogènes), ou il peut y avoir un système par processeur (solution qui peut
être plus coûteuse).
1.7.4. Les systèmes embarqués spécifiques
Lorsqu'un système est utilisé pour une tâche bien précise, il est souvent plus efficace et
économe s'il est spécifique à cette fonctionnalité que s'il est général. Les systèmes embarqués
sont très souvent utilisés dans ces conditions, et il est donc intéressant qu'ils soient conçus
spécifiquement pour les fonctions qu'ils doivent remplir. Notamment, les contraintes citées
dans la section précédente ne peuvent souvent être respectées que si le système est conçu dès le
départ pour pouvoir les respecter. Il est donc de par sa conception même spécifique.
Le problème qui se pose alors est que, pour chaque nouvelle fonctionnalité, il faudra concevoir
un système spécifique.
1.8. Modes de fonctionnement des systèmes embarqués
1.8.1. Fonctionnement général : boucle infinie
Tant que TOUJOURS faire
Acquisition des entrées (données capteurs, mesures…)
15
Calcul des ordres à envoyer au procédé

Émission des ordres
Fin tant que
Mais, il existe aussi d‟autres modes de fonctionnement :
 fonctionnement cyclique (time driven ou système "synchrone")
 fonctionnement événementiel (event driven)
 fonctionnement mixte : à base de traitements périodiques et apériodiques (déclenchés sur
événements)
1.8.2. Fonctionnement Cyclique :
Le principe est le suivant :
 la scrutation d'une mémoire d'entrée périodiquement (polling)
 l‟échantillonnage des entrées sur l'horloge du système
 l‟activation du système à chaque top d'horloge
A chaque top d'horloge faire
Lecture de la mémoire des entrées
Calcul des ordres à envoyer au procédé
Émission des ordres
Fin
Mais ce type de système est peu "réactif" si l'environnement produit des informations à des
fréquences différentes ce qui oblige à prévoir toutes les réactions du système dans la même
boucle donc il y a un problème de performance et en est obligé à imbriquer des boucles de
fréquences multiples ce qui implique des difficultés de réalisation, de lisibilité du code et
d'évolution
1.8.3. Fonctionnement Evénementiel :
Le fonctionnement est basé sur le principe d'activation du système à chaque événement (notion
d'interruption)
A chaque interruption faire
Lecture de l'information arrivée
activation du traitement correspondant
Émission des ordres issus de ce traitement
Fin
Mais dans ce cas le problème réside dans le cas où une interruption survient alors que le
système est en train de traiter une interruption précédente, ce qui implique des contraintes de
programmation :
 notion de priorité des interruptions
 notion de "tâche" associée à une ou plusieurs interruptions
16
 mécanisme de préemption et de reprise de tâche

 gestion de l'exécution concurrente des tâches (ordonnancement)
=> Un système temps réel est souvent un système multitâche incluant un gestionnaire de tâches
(Ordonnanceur)
1.9. Quelques exemples de systèmes temps réel contrôle - commande
1.9.1. Exemple de Système temps réel de contrôle commande
Figure 5 : Système temps réel de contrôle commande

1.9.2. Exemple de système temps de contrôle commande (Boite de vitesse robotisé)
Figure 6 : système temps de contrôle commande (Boite de vitesse robotisé)
17
1.9.3. Composants d’un système temps réel de contrôle commande.
Figure 7 : Composants d‟un système temps réel de contrôle commande.

1.9.4. Systèmes temps réel non embarqués
Figure 8 : Systèmes temps réel non embarqués

1.9.5. Systèmes temps réel embarqués
Figure 9 : Systèmes temps réel embarqués
18
1.10. Construction d’un système informatique temps réel
Un système informatique temps réel peut être construit :
 comme un générateur cyclique qui périodiquement capte la dynamique du procédé par

échantillonnage, effectue des calculs, prépare des actions et envoie des commandes sur les
actionneurs (on parle aussi de système synchrone),
 comme un système réactif qui répond instantanément aux stimuli provenant du procédé
selon la dynamique de celui-ci (on parle alors de système asynchrone),
 comme une organisation qui combine ces deux approches en ordonnançant l‟exécution
d‟activités périodiques et d‟activités apériodiques.
La première approche conduit à la réalisation d‟un programme unique dont la structure générale
est une boucle sans fin. Nous qualifierons cette approche de monotâche.
Les seconde et troisième approches conduisent à la réalisation d‟un programme dont la
structure est un ensemble de séquences de traitement susceptibles de se dérouler en parallèle.
Nous qualifierons ces approches de multitâches.
Nous allons décrire en détail la mise en œuvre de l‟approche monotâche dans la construction
d‟un système informatique temps réel. Nous dégagerons les avantages d‟une telle approche
mais aussi en mettrons en évidence les limites ; celles-ci conduisent à adopter l‟approche
multitâche lorsque l‟application à développer est complexe.
1.10.1. L’approche monotâche de construction d’un STR
Dans cette approche, le programme informatique du système de commande ne comprend

qu‟une seule tâche. Cette tâche unique se présente sous la forme d‟un programme bouclé sur
lui-même dont la structure générale est la suivante :
Initialisation
Acquisition des données

d’entrée
Traitements primaires
Écriture dessorties
envoi des commandes,
Traitements secondaires
19
Une telle architecture de programme est particulièrement simple car le programme traite
séquentiellement les entrées, les phases de calcul et les sorties.
Dans cette approche monotâche, l‟interaction du système avec son environnement peut se faire
soit par interruption, soit par scrutation cyclique des entrées/sorties, soit par une combinaison
de ces deux modèles d‟interaction.
Bien que cela exige un certain nombre de précautions, dans l‟approche monotâche il est
possible, pour la gestion des entrées/sorties, de combiner une gestion par interruption avec une
gestion par scrutation cyclique.
Nous allons examiner successivement ces deux types de gestion des entrées/sorties :
 la scrutation logicielle des E/S,
 l‟interruption immédiate du logiciel à la suite d‟événements externes.
Quelques exemples d‟événements pouvant générer une interruption :

1. Réception d‟un caractère par le contrôleur d‟une liaison RS232,
2. Fin d‟une conversion analogique-numérique,
3. Arrivée à échéance d‟un compteur de temps.
1.10.1.1 Interaction par scrutation cyclique des E/S (polling)
Dans ce type d‟interaction avec l‟environnement, le programme informatique interroge (scrute)
périodiquement les périphériques du processeur. Pour cela, en fonction des périphériques
installés :
 il teste successivement l‟état des bascules qui sur les différentes cartes électroniques d‟E/S
mémorisent l‟occurrence d‟un événement externe1
 il lit l‟état des entrées logiques,
 et, dans le cas notamment d‟une commande de processus continus, il lit la valeur numérisée
donnée par des capteurs analogiques.
Quand la valeur d‟une bascule indique l‟occurrence d‟un événement, ce dernier est mémorisé
dans une variable du programme, variable qui sera exploitée durant la phase des traitements. De
même, l‟état d‟une entrée logique, la valeur numérisée lue sur une entrée de type capteur
analogique sont mémorisés dans des variables du programme, variables destinées à être
exploitées durant la phase suivante du cycle.
Ainsi, chaque cycle du programme débute par l‟acquisition de toutes les données d‟entrée ; et
ce n‟est que lorsque cette acquisition est terminée que débute la phase de traitement.
Le déroulement de la phase d‟acquisition des données d‟entrée peut ainsi être schématisé :
1Les boîtiers contrôleurs d‟E/S des microprocesseurs disposent généralement d‟une ou de

plusieurs bascules internes qui mémorisent l‟occurrence d‟événements.
20
PhaseAcquistion
Lire les valeurs numérisées données par les capteurs analogiques et les mémoriser dans des
variables du programme ;
Lire l‟état de toutes les entrées logiques et les mémoriser dans des variables du programme ;
Pour chaque bascule mémorisant l’occurrence d’un événement externe :
Si bascule = 1 alors :
Positionner l‟indicateur d‟activation du traitement associé ;
Si nécessaire, remettre la bascule à zéro ;
finSi
finPhaseAcquisition
1.10.1.2. Interaction par interruption
Dans ce type d‟interaction avec l‟environnement, le programme informatique est informé de
l‟occurrence d‟un événement grâce à un mécanisme qui interrompt, lorsque survient cet
événement, le cours normal de l‟exécution du programme, et qui permet la reprise du cours
normal du programme exactement à l‟endroit où celui-ci a été interrompu.
De tels événements qui déclenchent une interruption du programme en cours d‟exécution sont
dits asynchrones car, ils se produisent à des instants aléatoires par rapport au déroulement du
programme.
« Ce concept d’interruption a été initialement introduit pour gérer les entrées/sorties d’un
processeur. On la définissait alors comme un événement matériel provoquant un changement
dans l’exécution d’un programme.
Ce concept a ensuite été étendu à la notion d’interruption interne ou exception (trap) qui est
déclenchée par une opération logicielle (plutôt que par une opération liée au matériel). Dans
un cas comme dans l’autre, le terme d’interruption désigne l’événement qui provoque un
changement dans l’exécution normale d’un programme. On classe souvent les interruptions
selon la cause de leur arrivée : interruption d’entrée/sortie, interruption d’horloge,
interruption de défaut de page mémoire, etc. »
Lors de l‟arrivée d‟une interruption, le programme est interrompu à la fin de l‟instruction
machine en cours d‟exécution. Afin que l‟exécution du programme puisse reprendre
ultérieurement son cours normal, le contexte d‟exécution du processeur est automatiquement
sauvegardé dans la pile2. Une fois le contexte d‟exécution sauvegardé, il y a identification de la
source de l‟interruption puis, en fonction de cette source, branchement vers une séquence
spéciale d‟instructions (appelée gestionnaire d’interruption ou tâche immédiate) chargée de
traiter l‟interruption.
2Ce contexte contient notamment la valeur qu‟avait le compteur ordinal à la fin de l‟instruction
au cours de laquelle est survenue l‟interruption. Cette valeur est celle de l‟adresse de la
prochaine instruction machine à exécuter, donc l‟adresse de l‟instruction à partir de laquelle se
fera la reprise de l‟exécution du programme interrompu.
21
Traitement de l’interruption
Sauvegarde du Restauration du
contexte d’exécution contexte

d’exécution
Événement
 déclenchant une
Poursuite du
Déroulement normal déroulement
Temps
Figure 10 : Interaction par interruption
Plusieurs sources d‟interruption peuvent partager la même entrée d‟interruption du
microprocesseur. Le gestionnaire d‟interruption associé à une telle ligne d‟interruption doit
alors tester les sources possibles d‟interruption afin de connaître celle qui est à l‟origine de
l‟interruption du processeur. Ceci se fait en effectuant une scrutation (polling) des bascules des
boîtiers contrôleurs d‟E/S.
Le temps de latence d’une interruption est le temps qui sépare l‟apparition d‟un événement
issu d‟un capteur ou de tout autre dispositif électronique, et l‟exécution de la première
instruction du gestionnaire d‟interruption associé à cet événement.
Nous examinerons dans le paragraphe suivant la façon dont peut, dans une approche
monotâche, être mise en œuvre une gestion des entrées/sorties par interruption.
1.10.1.3 Architecture possible d’un système monotâche temps réel
En pratique, on fixe la périodicité à laquelle la boucle de programme est exécutée ; on ne veut
pas en effet faire dépendre cette périodicité du temps d‟exécution effectif d‟un tour de boucle.
Bien évidemment, cette périodicité devra être strictement supérieure à la valeur maximale du
temps d‟exécution d‟un tour de boucle, c‟est-à-dire du temps d‟exécution de la boucle lorsque
sont effectués tous les traitements, y compris ceux relatifs à la gestion des E/S. Un timer
générera les signaux de réactivation périodique de la boucle. Ces signaux périodiques seront
gérés par scrutation ou par interruption.
L‟architecture du programme de l‟application peut alors être schématisée de la façon suivante :
22
Effectuer l‟initialisation générale du système ;

Initialiser le timer d‟activation périodique du corps de la boucle ;
TantQue (VRAI) faire :
Attendre la prochaine occurrence du signal périodique ;
Acquérir les données d‟entrée ;
Effectuer les traitements primaires ; Corps de la
boucle
Mettre à jour les sorties ; boucle
Effectuer les traitements secondaires ;
finTantQue
Si l‟on s‟intéresse maintenant à la structure du corps de la boucle, celui-ci pourrait, dans le cas
le plus général, être constitué d‟un programme principal, de deux ensembles de procédures :
 les procédures de gestion des E/S
 les procédures de traitement (calculs, préparation des actions, etc.), et d‟un ensemble de
gestionnaires d‟interruption.
Le programme principal joue alors de rôle d‟un séquenceur rudimentaire qui enchaîne
l‟exécution des différentes procédures3 en fonction de stimuli externes (ordres de l‟opérateur,
état des capteurs, occurrences d‟événements) ou systématiquement à chaque tour de la boucle.
Pour la réalisation du programme principal, il est intéressant de définir une table d‟adresses de
procédures, dont l‟ordre de rangement - défini au moment de la conception du système - est
celui dans lequel se fait l‟exécution des procédures. Assurant la gestion du pointeur de cette
table, le programme principal lance l‟exécution de la procédure pointée Pi, puis, lorsque
l‟activité de cette procédure Pi est terminée, enchaîne sur la procédure suivante prévue dans la
table, et ainsi de suite.
Il est à noter que dans la table des adresses de procédures, certaines d‟entre elles peuvent
apparaître plusieurs fois.
En ce qui concerne la façon dont les gestionnaires d‟interruption vont s‟intégrer au reste du
programme, la solution la plus sûre est la suivante. Pour chaque périphérique géré par
interruption, on définit deux procédures :
 l‟une qui initialise les E/S avec le périphérique en question ;
 l‟autre qui assure le traitement demandé par le gestionnaire d‟interruption.
Dans une approche monotâche, un gestionnaire d‟interruption ne peut et ne doit effectuer que
des opérations élémentaires de gestion du périphérique (comme par exemple, dans le cas d‟un
périphérique d‟entrée, une simple récupération de données). Les traitements qui doivent ensuite
être faits sur ces données le seront par une procédure de traitement appelée par le programme
principal lors de l‟exécution d‟un tour de boucle.
3Parmi les procédures - celles de gestion des E/S comme celles de traitements - on peut en effet
distinguer celles qui sont exécutées à la suite de l‟occurrence d‟un événement (donc de façon
épisodique) de celles qui sont exécutées à chaque tour de boucle.
23
1.10.1.4 Avantages et limites de l’approche monotâche

Dans le cas d‟une application de faible complexité, gérant peu de périphériques (périphériques
de préférence identiques, ou soumis à des contraintes de temps du même ordre de grandeur), la
conception d‟un système temps réel selon une approche monotâche présente un certain nombre
d‟avantages :
Le système est simple à programmer du fait même de sa structure : une boucle unique qui
regroupe et gère l‟ensemble des actions à réaliser. Les diverses procédures s‟exécutent les unes
après les autres, sans conflit possible entre elles puisque l‟une ne commence son exécution que
lorsque l‟autre a terminé la sienne.
Le fait que, dans l‟approche monotâche, le programme informatique ne fasse pas appel aux
services d‟un exécutif ou d‟un système d‟exploitation temps réel multitâche (on parle alors
d‟implantation directe du logiciel sur le microprocesseur) conduit à réduire au minimum la
partie organisationnelle et donc le temps de développement de l‟application4.
Lorsque la détection d‟un événement externe se fait par scrutation cyclique, le temps maximal
qui sépare l‟apparition d‟un événement externe et sa détection par le système est simple à
déterminer : c‟est le temps de traitement d‟une boucle. On peut donc savoir immédiatement si
le système satisfait ou non les contraintes de temps que lui impose la dynamique de la partie
opérative.
Cependant l‟approche monotâche présente nombre de limites :
Quel que soit le mode d‟interaction du système avec son environnement (par scrutation
cyclique ou par interruption) il s‟écoule un temps indéterminé –quoique borné - entre
l‟apparition d‟un événement asynchrone et le lancement par le programme principal de la
procédure de traitement de cet événement.
La conception d‟un système temps réel selon une approche monotâche devient de plus en plus
inextricable au fur à mesure que croit la complexité de l‟application à réaliser. Ceci, du fait
notamment du nombre et surtout de la diversité des périphériques à gérer (diversité en
particulier au niveau de la fréquence des traitements associés).
L‟accroissement des entrées/sorties à gérer et des traitements à réaliser conduit inéluctablement
à la réalisation d‟un programme mal structuré qui devient rapidement illisible et impossible à
maintenir. En effet, un tel programme ne se prête pas facilement à une mise au point
progressive par intégration de sous-systèmes testés unitairement, et l‟insertion d‟un nouveau
périphérique ou l‟ajout d‟un nouveau traitement nécessite une remise en cause de l‟existant.
1.10.2 L’approche multitâche
Un système temps réel multitâche est composé de plusieurs tâches s‟exécutant de manière
autonome mais concourant toutes à la réalisation d‟un même objectif global.
L‟approche multitâche dans la conception du logiciel d‟un système temps réel répond d‟abord à
l‟objectif d‟une meilleure structuration du programme informatique. Ceci, dans le sens que
4Découlant naturellement de l‟approche monotâche, l‟implantation directe n‟est réaliste que

pour des applications dédiées de faible complexité. De telles applications représenteraient
toutefois près de 80% des développements de systèmes à microprocesseur.
24
l‟organisation des différents traitements et actions présente plus de rationalité, de souplesse, de

lisibilité, et qu‟elle facilite l‟évolution et même la réutilisation de modules logiciels déjà
développés. Cette démarche est indispensable lorsque l‟on a à concevoir et à réaliser une
application temps réel complexe.
Sauf dans les applications très simples de commande de procédés, il est donc conseillé, dans la
mesure du possible, d‟adopter l‟approche multitâche car elle offre un haut degré de modularité,
de maintenabilité et de flexibilité, notamment en cas d‟évolution du système. Elle se prête bien
à la programmation séparée et la collaboration entre membres d‟une même équipe de
programmeurs. Enfin, elle assure une réutilisabilité importante des différents composants ou
modules du système.
Cependant, la structuration d‟une application informatique en tâches concurrentes et
coopérantes pose des problèmes spécifiques. Ces problèmes que posent la conception et la
programmation d‟applications multitâches concernent d‟une part la coopération et la
communication entre les tâches, et d‟autre part l‟organisation dans le temps de l‟exécution
des tâches.
Ce sont justement ces problèmes fondamentaux posés par la conception et la mise en œuvre de
logiciels multitâches que nous allons introduire dans le chapitre suivant. Les concepts de base
et les problèmes que pose la mise en œuvre d‟un système temps réel multitâche peuvent être
regroupés autour des quatre thèmes suivants :
 Les tâches : définition et caractéristiques
 L’ordonnancement des tâches : l‟organisation de leur exécution
 L‟accès concurrent des tâches à des ressources partagées
 La synchronisation et la communication entre les tâches.
Cependant, comme pour les applications monotâche, l‟interaction du système informatique
avec son environnement peut se faire par scrutation cyclique des E/S, par interruption ou par
une combinaison de ces deux modes d‟interaction.
25
Chapitre II. Modélisation des systèmes temps réels

II.1. Les contraintes temporelles
Dans un STR, les contraintes temporelles portent sur essentiellement sur les dates de début et
de fin d‟exécution des tâches. Si nous supposons que le Système est décomposé en termes de
tâches Ti, i=1,..., n alors pour chaque tâche Ti, les contraintes temporelles sont modélisées par
les paramètres suivants :
- Ai : C‟est la date d‟arrivée de la tâche au processeur (ou date de la création de la tâche ou
éventuellement la date à laquelle une tâche transférée par un autre processeur est reçue). Il est
désormais possible d‟ordonnancer cette tâche. Ainsi, chaque fois qu‟une nouvelle tâche arrive
au processeur ou chaque fois qu‟une tâche est créée, l‟ordonnanceur (mécanisme
d‟ordonnancement), recherche un nouvel ordre qui prendra en compte la nouvelle tâche.
- Ri : C‟est la date à laquelle une tâche peut commencer son exécution. Certaines tâches sont
dépendantes les unes des autres, et ne peuvent donc commencer leurs exécutions que si les
tâches dont elles dépendent (les tâches qui les précèdent) ont terminé leurs exécutions. Dans ce
cas, elles sont liées par des relations de précédence (communication de résultat d‟une tâche en
fin d‟exécution) ou de causalité (estampillages des tâches). L’estampillage des tâches consiste
à attribuer un numéro d‟ordre aux tâches de sorte que durant l‟exécution, cette numérotation
soit respectée à travers le réseau. In convient de souligner que souvent Ai et Ri sont
confondues.
- Di : C‟est la date au plus tard à laquelle une tâche peut terminer son exécution. Elle est aussi
appelées échéance. Ce paramètre détermine énormément la performance du système. Ainsi, on
distingue les échéances strictes et les échéances relatives. Les échéances strictes ne peuvent
jamais être dépassées, sinon elles dégradent les performances du système. Les échéances
relatives peuvent être dépassées sans dégrader les performances du système.
- Ei : C‟est la durée d‟exécution de la tâche. Elle est déterminée par des simulations ou une
étude poussée du code source. Cependant, lorsque le code source est composé de boucles ou de
traitements conditionnels, il est difficile de déterminer d‟emblée Ei. Dans ce cas, on détermine
un temps d‟exécution dit « au pire des cas » qui reflète une borne supérieure E i. Notons que
l‟on parle de pire des cas lorsqu‟on suppose que toutes les formes possibles du code source de
la tâche ont lieu c'est-à-dire le nombre d‟itérations maximum atteint pour toutes les boucles.
Dans les STR dynamiques, Ei ne peut être connue à l‟avance puisque la tâche Ti est créée
dynamiquement. Il est mis à jour au fur et à mesure de l‟exécution de la tâche. On peut par
exemple procéder à la déduction du temps restant (Erest i) à partir du temps atteint (Eatt i),
c'est-à-dire Ei = Eatt i + Erest i. Parmi les méthodes utilisées pour approximer le temps
d‟exécution d‟une tâche, nous pouvons citer : Prischner et Koza, Kligerman et Stoyenko,
Leinbaugh et yamini, etc.
- Pi : C‟est la période d‟une tâche. Une tâche est dite périodique de période Pi, lorsqu‟elle a
une occurrence toutes les Pi unités de temps.
D‟autres paramètres sont déterminés par le mécanisme d‟ordonnancement grâce aux paramètres
Ri, Ei et Di précédents. Il s‟agit :
- Si : C‟est la date à laquelle une tâche Ti accède à la ressource selon l‟algorithme
26
d‟ordonnancement déroulé.
- Ci : C‟est la date à laquelle une tâche Ti termine son exécution. Cette date ne correspond
pas forcément à Si + Ei. En effet, selon l‟algorithme d‟ordonnancement appliqué, une tâche
peut être interrompue ou retardée pour la prise en compte d‟une tâche plus urgente.
- TRi : C‟est le temps de réponse de la tâche Ti c'est-à-dire la période entre la date la plus
antérieure à laquelle une tâche peut commencer son exécution et la date postérieure à laquelle
elle termine son exécution. Il s‟exprime par la formule : TRi = Ci - Ri.
- TLi : C‟est le temps de latence d‟une tâche Ti c'est-à-dire la période pendant laquelle une
tâche peut être retardée sans que son exécution ne dépasse son échéance. Elle s‟exprime par la
formule : TLi = Di - Ri - Ei.
- Li : C‟est la laxité c'est-à-dire la date au plus tard à laquelle la tâche Ti peut commencer son
exécution. Elle s‟exprime par la formule : Li = Di - Ei. Par déduction, on obtient la formule: TLi
= Li - Ri. Le temps de latence n‟est pas constant. En effet, plus une tâche Ti est retardée plus
son temps de latence diminue.
- Ui : C‟est le taux d‟utilisation du processeur dédié à la tâche Ti. Il s‟exprime par la formule:
. Le taux global d‟utilisation sera la somme de tous les Ui.
Pour les tâches périodiques, le taux d‟utilisation du processeur ou le pourcentage de l‟activité
du processeur dédié à la tâche Ti est donnée par :
, et la Charge processeur = taux d‟utilisation du processeur pour les tâches périodiques
est donnée par ∑ .

Lorsque U>m alors l‟application est non ordonnançable sur m processeurs.
N.B. : L‟ensemble de ces paramètres doit vérifier les contraintes suivantes :
Ai < Ri < Si < Ci - Ei < Di - Ei
Schématiquement, nous pouvons illustrés les contraintes temporelles d‟une tâche temps réel de
la manière suivante :
Figure I.2. : Les paramètres temporels d‟une tâche Ti
27
Remarque :
- Dans certains STR, l‟échéance est modélisée par une fonction à valeur dans le temps
(FVT) appelée « Time Value Fonction » (TVF). Chaque tâche Ti fournit au moment de sa
terminaison, une contribution qui est décrite par une fonction de coût Fi(t). La valeur de cette
fonction renseigne sur l‟utilité de la terminaison de la tâche à l‟instant t. Fi(t) a la valeur
maximale si Ti termine avant Di, autrement la valeur de la fonction décroît vers 0, où elle
signifie qu‟une terminaison à cette date-là est inacceptable. Quand la valeur de la fonction
décroit brusquement après son échéance, ceci indique une échéance stricte à ne pas dépasser
dans n‟importe quelle situation. Par contre, si la valeur de la fonction décroit progressivement,
cela indique une échéance relative qui peut éventuellement être dépassée de peu.
- L‟ordonnancement est ramené, dans ce cas, à un problème d‟optimisation des tâches.
L‟ordonnancement est déterminé par une série d‟évaluations des valeurs des FVT selon la
position des tâches dans la séquence d‟ordonnancement.
II.2. Les caractéristiques des tâches

Une tâche est une entité élémentaire d‟exécution et de structuration de l‟application. Une tâche
est localisée dans le temps par une date de début et/ou une date de fin, dont la réalisation
nécessite une durée et une échéance (la date à laquelle la tâche doit avoir terminé son
exécution).
L‟ordonnancement des tâches consiste à déterminer une séquence d‟exécution des tâches sur le
processeur en respectant les contraintes de temps. Cependant certaines caractéristiques des
tâches que nous évoquons ci-après peuvent influencées cet ordonnancement. Il s‟agit de la
priorité utilisateur et la périodicité des tâches.
a) Notion de priorité utilisateur
Lorsque toutes les tâches n‟ont pas la même importance vis-à-vis de système, on parle alors de
priorité attribuée par l‟ordonnanceur pour distinguer les tâches entre elles en fonction de leurs
échéances. On distingue ainsi des tâches plus prioritaires par rapport aux tâches moins
prioritaires. C‟est l‟utilisateur qui définir les priorités.
Selon le système Spring, il existe trois types de tâches selon leurs priorités :
- Les tâches temps réel critiques : ce sont des tâches dont les échéances ou les
contraintes temporelles (qui sont connues à l‟avance) doivent être rigoureusement respectées
pour éviter la catastrophe. Elles ont la priorité la plus haute dans le système.
- Les tâches temps réel essentiel : Ce sont des tâches dont les contraintes sont non
sévères et peuvent éventuellement être relâchées dans la mesure du possible. Dans
certaines applications, leur échéance est composée d‟une échéance stricte et d‟une
échéance relative. La première partie de l‟exécution d‟une telle tâche doit être rigoureusement
respectée, la seconde (qui peut consister en un affinement du résultat délivré par la première
partie) peut ne pas être terminée. Dans ce cas, le résultat ne sera pas très précis. Les tâches
essentielles peuvent être ordonnancées dynamiquement.
- Les tâches non essentielles : Ce sont des tâches qui peuvent ne pas avoir des
contraintes quant à la fin de leur exécution ou la date de leur déclenchement, elles ont donc la
priorité minimale. Elles seront exécutées une fois que toutes les tâches à contraintes seront servies
28
et selon leur ordre d‟arrivée ou selon un ordre décidé par l‟utilisateur.

b) Notion de périodicité
Lorsque les tâches temps réel n‟ont pas de priorité utilisateur, leurs priorités seront définies par
leurs échéances. Toutefois, la notion de périodicité que nous introduisons dans cette section,
révèle une autre distinction entre les tâches. Outre les priorités des tâches, le mécanisme doit
prendre en compte le fait que ces tâches peuvent être périodiques apériodiques ou sporadiques.
- Les tâches périodiques i: une tâche Ti est dite périodique de période Pi si elle est
exécutée chaque Pi unités de temps. Une telle tâche a ses paramètres Ri et Di connus. Si Tin, la
nème exécution de la tâche Ti, alors la date au plus tôt Rin est donnée par le taux d‟inter-arrivée
et la date au plus tard Din est déterminée par l‟occurrence de la (n+1)ème exécution de T (comme
illustré dans la figure suivante).
Quand un système doit ordonnancer une tâche périodique, il doit garantir toutes les futures
occurrences de la tâche.
Figure I.3. : Tâches périodiques

N.B. : Si : représente la date à laquelle une tâche accède à la ressource selon l‟ordonnancement.
Une occurrence de tâche peut avoir son échéance inférieure ou égale à sa période. Cela dépend
du système.
- Les tâches apériodiques : ce sont des tâches dont l‟arrivée au processeur suit une loi
aléatoire (la loi de Poisson par exemple). Leurs paramètres temporelles sont donc inconnus à
l‟avance.
- Les tâches sporadiques : Les tâches apériodiques sont caractérisées par la moyenne des
temps d‟arrivée et un standard de déviation (écart type) par rapport au taux d‟arrivée.
Cependant, si les occurrences d‟une tâche apériodique sont au moins espacées de q unités de
temps, on caractérise cette tâche de tâche sporadique de période q.
Schématiquement :
Figure I.4 : Tâches périodiques, apériodiques et sporadiques

29
- Une tâche non préemptible ne peut être interrompues qu‟à des endroits spécifiques et
à la demande de la tâche elle-même, par exemple fin_de_tâche, attente_signal…
- Une tâche préemptible peut être interrompue à n‟importe quel instant et le processeur
affecté à une autre tâche.
- Les tâches indépendantes : ce sont des tâches qui ne sont définies que par leurs
paramètres temporels, on dit alors qu‟elles. En effet, certaines tâches doivent communiquer
avec les autres tâches, ou doivent être connectées vers l‟extérieur pour les entrées/sorties. Par
conséquent, elles peuvent être liées par un des types des relations suivant:
- Synchronisation : se traduit par une relation de précédence d‟exécution entre les tâches,
- Communication : se traduit par une relation de précédence comme la synchronisation mais
avec l‟échange de données entre les tâches,
- Partage de ressources : les ressources sont les moyens techniques nécessaires à l‟exécution
des tâches. Au niveau d‟un système, les tâches utilisent des ressources mises en commun
comme des zones de mémoire, des cartes d‟entrées/sorties, etc. Certaines des ressources
n‟autorisent que des accès en exclusion mutuelle, c‟est-à-dire pas plus d‟une tâche peut y
accéder à la fois, pour avoir un fonctionnement correct. Elles sont appelées ressources critiques.
Remarques
- Les algorithmes d‟ordonnancement sont extrêmement dépendants du modèle de tâches.
Ainsi ils sont plus conçus pour des tâches périodiques ou apériodiques et les tâches sporadiques
sont converties en tâches périodiques.
- Les applications temps réel sont en majorité composées de tâches périodiques.
- Les sources de contraintes de temps sont souvent : le processus physique (lois de
commande), la qualité de service (qualité audio/vidéo), le choix d‟architecture, le choix de
conception, etc.
II.3. Exécutif ou noyau temps réel

Un noyau de système d‟exploitation (kernel) est la partie fondamentale de certains systèmes
d‟exploitation. Le rôle du noyau est de gérer les ressources matérielles et permet aux différents
composants, matériels et logiciels, de communiquer entre eux. Un noyau fournit des
mécanismes d‟abstraction du matériel («Gestion du matériel»), notamment de la mémoire
(«Gestionnaire de mémoire»), du (ou des) processeur(s) («Ordonnanceur»), et des échanges
d‟informations entre logiciels et périphériques matériels. Il autorise aussi diverses abstractions
logicielles et facilite la communication entre les processus.
- Ordonnanceur d‟un système d‟exploitation: n‟a de sens qu‟en système multitâche. Il gère
l‟ordre dans lequel les instructions des différentes tâches sont exécutées, est assisté par le
dispatcher qui est responsable de la sauvegarde et de la restauration du contexte des tâches
(commutation de contexte).
- Gestionnaire de mémoire: alloue de la mémoire à des processus lorsqu‟ils en ont besoin. Si
un processus tente d‟utiliser des zones de mémoire ne lui appartenant pas, il peut être évincé
automatiquement, c‟est-à-dire que le noyau lui-même peut prendre la décision de suspendre ou
détruire immédiatement le processus fautif.
- Gestion du matériel: se fait par l‟intermédiaire de pilotes de périphériques, qui sont
30
généralement inclus dans l‟espace noyau et communiquent avec l‟espace utilisateur via les
appels système (des fonctions fournies par le noyau, et utilisées par les programmes s‟exécutant
dans l‟espace utilisateur).
Exécutif ou noyau temps réel sont souvent assimilés, dans le sens où l‟exécutif est souvent vu
comme un noyau possédant des pilotes de périphériques ou des services supplémentaires (pile
réseau,…) par rapport à un noyau. Un noyau est généralement léger, et on parle d‟empreinte
mémoire d‟un noyau (occupation mémoire) pour caractériser son encombrement. Les noyaux
temps réel fournissent au moins deux types de modules, l‟un spécifique pour le temps réel
(gestion des tâches, communication, synchronisation, gestion du temps) et l‟autre plus classique
(librairies standard). Les applications temps réel font alors appel à la partie temps réel du
noyau.
Contrairement au système d‟exploitation classique (politiques d‟ordonnancement des activités
basées sur le partage équitable du processeur; gestion de temporisateurs ou de l‟horloge pas
assez fine; la concurrence de l‟application temps réel avec le système d‟exploitation toujours
actif…), les principales fonctions d‟un noyau temps réel peuvent être scindées en trois groupes
ci-dessous.
Donc, les tâches de même que les processus concourent à l‟obtention du ou des processeurs, et
peuvent communiquer ou se synchroniser. La différence est qu‟une tâche est caractérisée par
une pile et un pointeur d‟instruction, mais partage la mémoire avec les autres tâches du
même processus; tandis que la mémoire pour les processus est privée (il en résulte que le
passage par l‟exécutif pour la communication entre processus est plus lourd mais plus sécurisé
que pour les tâches):
- Gestion des entrées/sorties.
- Ordonnancement des tâches.
- Relations entre les tâches (synchronisation, communication, accès à une ressource
critique en exclusion mutuelle, gestion de temps…).
Figure I.5. : Architecture de l‟application : tâches et noyau temps réel

Il est important de noter que les tâches sont les unités actives du système; le noyau temps réel
n‟est actif que lors de leur appel: donc, une tâche activée peut appeler le noyau temps réel sous
forme d‟une requête, les différentes requêtes sont servies par des modules du noyau temps réel
appelées primitives (partie temps réel du noyau). Ensuite le noyau temps réel réactive une tâche
31
de l‟application selon l‟algorithme d‟ordonnancement utilisé (partie générique du noyau) (voir

Figure I.5).
Une autre architecture souvent retenue est un noyau hybride qui s‟appuie sur la combinaison
d‟un noyau temps réel spécialisé, allouant du temps d‟exécution à un noyau de système
d‟exploitation non spécialisé. Cette technique permet d‟assurer le fonctionnement temps réel
des applications, tout en maintenant la compatibilité avec des environnements préexistants.
Nous trouvons une telle architecture dans RTLinux.
II.4. Gestion des tâches

Les noyaux temps réel gèrent les tâches suivant le même principe que les systèmes
d‟exploitation non spécialisés. Alors, au cours de la vie d‟une application, les tâches peuvent
atteindre les états suivants (voir Figure I.6.) :
- Tâche «inexistante» : la tâche n‟est pas créée,
- Tâche «passive» : la tâche est créée, et initialement elle doit être endormie (passive) pour
l‟attente de son réveil. De plus, une tâche peut devenir «passive» à partir de l‟état «élue»
pendant un certain temps ou jusqu‟à une certaine date, on parle de «suspension»,
- Tâche «prête» : la tâche attend d‟être élue. Dans cet état elle requiert un processeur
pour s‟exécuter,
- Tâche «élue» : lorsque le noyau le décide, une tâche en état «prête» alloue un processeur
afin d‟être exécutée. Cependant, de l‟état «élue», une tâche peut être préemptée par une autre
tâche. Dans ce cas, elle passe dans l‟état «prête» en attendant le processeur,
- Tâche «en attente» : de l‟état «exécutée», une tâche peut se mettre en attente d‟un message,
d‟un événement, ou de l‟accès à une ressource (on parle de «blocage»). Lorsque le message,
l‟événement (ou la ressource) est arrivé (ou libre), la tâche passe dans l‟état «prête» pour
requérir le processeur.
Figure I.6.: Graphe des états possibles d‟une tâche

A tout instant, une tâche peut être supprimée. Dans ce cas, elle passe dans l‟état «inexistante».
Etant donné que les tâches sont générées finement dans les noyaux temps réel, certains noyaux
distinguent la création et l‟initialisation d‟une tâche.
32
II.5. Outils de communication et de synchronisation

Cette section présente les concepts de base des outils de communication et de synchronisation,
permettant aux tâches d‟interagir. Effectivement, les exécutifs temps réel ne proposent
pas toujours tous les outils de communication et de synchronisation, et il faut que dans certains
cas le concepteur d‟une application les implémente lui-même en utilisant ces concepts de base.
II.5. a. Sémaphore
Le sémaphore est un outil introduit par Dijkstra en 1965, donc l‟un de ses rôles est de protéger
une zone de programme dite critique lorsque le nombre de tâches qui accèdent simultanément à
une ressource critique est supérieur à un nombre limité d‟instances de cette ressource. En effet,
un sémaphore est une variable soit binaire (avec deux états possibles: libre et pris), soit n-aire.
Dans le cas des sémaphores binaires, un sémaphore est caractérisé par une valeur booléenne et
une file d‟attente de tâches en attente du sémaphore (voir Figure I.7(a)). Tandis que dans le cas
des sémaphores n-aire, appelés «sémaphores à compte» ou «sémaphores compteur», un
sémaphore est caractérisé par un nombre entier naturel (donc la valeur 0 indique que le
sémaphore est pris, et une valeur différente de zéro indique qu‟il y a un certain nombre
d‟instances libres), et une file d‟attente de tâches en attente du sémaphore (donc, chaque tâche
est couplée avec un nombre entier strictement positif indiquant le nombre d‟instances requises)
(voir Figure I.8(a)).
Figure I.7.: Caractérisation d‟un sémaphore binaire

(a) Sans protocole de gestion de ressource ou avec protocole à priorité hérité
(b) Avec protocole à priorité plafond
Figure I.8. : Caractérisation d‟un sémaphore compteur

(a) Sans protocole de gestion de ressource ou avec protocole à priorité hérité
(b) Avec protocole à priorité plafond
La file d‟attente peut être gérée, en fonction de l‟exécutif sous-jacent, soit de façon FIFO, soit
sous la forme de plusieurs files FIFO gérées par priorité des tâches désirant accéder au
sémaphore. Lorsque les sémaphores sont utilisés pour assurer l‟exclusion mutuelle, ou encore
pour permettre un accès de type lecteur/écrivain (soit un lecteur/un écrivain en cas de
sémaphore binaire, soit multiple lecteur/un écrivain en cas de sémaphore compteur), ces
sémaphores peuvent être couplés, selon les exécutifs, avec un protocole à priorité héritée ou
bien un protocole à priorité plafond afin d‟éviter le phénomène d‟inversion de priorité. Dans le
cas du protocole à priorité plafond, il est nécessaire de caractériser chaque type des sémaphores
33
par une «priorité plafond» (voir Figure I.7.(b), Figure I.8 (b)).
II.5 b. Moniteurs
Le moniteur est un outil utilisé pour synchroniser deux ou plusieurs tâches qui utilisent des
ressources partagées. En fait, l‟utilisation de la ressource ne peut avoir lieu qu‟à travers
le moniteur, et les primitives du moniteur permettant de manipuler cette ressource sont non
réentrantes. Le moniteur est strictement plus puissant que le sémaphore. Un moniteur est
constitué de:
- un ensemble de primitives permettant l‟interaction avec la ressource partagée,
- un verrou d‟exclusion mutuelle,
- des variables associées à la ressource.
En pratique, il existe deux types de moniteur, l‟un de moniteur classique et l‟autre de moniteur
à la Ada.
- Le moniteur classique, appelé «moniteur de Hoare»: est un mécanisme dans lequel la non
réentrance des primitives est couplée avec un «wait» et un «signal» permettant respectivement
de mettre en attente et de réveiller une tâche accédant au moniteur sous certaines conditions. Ce
type de moniteur peut être implémenté par exemple dans la norme POSIX 1003.1 à l‟aide de
variables conditionnelles. Lorsqu‟une tâche doit être mise en attente sur le moniteur tant qu‟une
condition n‟est pas réalisée, charge au programmeur d‟utiliser les outils «wait» et «signal» pour
implémenter les conditions (gardes) d‟accès.
- Le moniteur à la Ada (objet protégé): permet de mettre une garde (une barrière logique) à
l‟entrée de chaque primitive du moniteur, ce qui offre des traitements plus fins et plus
transparents des conditions d‟accès par rapport au moniteur de Hoare. Par exemple, dans le cas
où il y a plusieurs conditions de réveil, seule la tâche concernée est réveillée par le changement
d‟état du moniteur, contrairement au cas du moniteur de Hoare dans lequel toutes les tâches en
attente sur «wait» sont réveillées sur un «signal», puis doivent évaluer leur condition afin de se
remettre en attente ou de poursuivre leur exécution. De plus, le moniteur à la Ada possède un
mécanisme natif de l‟accès de type lecteur/écrivain, c‟est-à-dire plusieurs tâches peuvent
accéder au moniteur en lecture en même temps, mais une seule tâche peut y accéder en écriture
à la fois. En outre, le protocole à priorité plafond existe également pour le moniteur à la Ada.
II.5. c. Signaux
Les signaux sont des événements (sans données) pouvant être envoyés à une ou plusieurs
tâches simultanément. Il y a deux types de signaux: les «signaux synchrones», internes à une
tâche ou un processus, et les «signaux asynchrones», provenant d‟autres tâches ou processus,
ou bien de source matérielle externe.
- Un signal synchrone est le résultat d‟un événement interne à une tâche. Il s‟agit lorsqu‟un
événement interne a lieu, qu‟une occurrence du signal synchrone associé ait lieu. Et ce signal
est traité immédiatement de façon synchrone à son occurrence par la tâche. Normalement, à
chaque signal synchrone est associée une action par défaut, qu‟une tâche peut effectuer
lorsqu‟elle reçoit un signal synchrone.
- Les signaux asynchrones sont des signaux provenant d‟une source externe à l‟adresse d‟une
tâche ou un processus (signaux privés), ou bien à plusieurs tâches et/ou plusieurs processus
34
(signaux publics). Lorsqu‟un signal privé est envoyé à un processus, la dernière tâche
(chronologiquement) à s‟être sensibilisé à l‟événement peut percevoir l‟événement. Lorsqu‟un
signal public est envoyé à un processus, toutes les tâches sensibilisées au signal peuvent le
percevoir. Alors dans les cas de signaux public, un répartiteur d‟occurrences s‟occupera
de prévenir chaque tâche sensibilisée qu‟un signal public est envoyé.
Si une tâche n‟est pas prête à recevoir un signal au moment où l‟occurrence de ce signal a lieu,
il existe trois possibilités dont les occurrences non prises en compte peuvent être gérées:
«signal fugace» (l‟occurrence non prise en compte est perdue, la tâche doit attendre l‟arrivée de
cette occurrence de nouveau); «signal mémorisé» (l‟occurrence non prise en compte est
mémorisée en mettant le «drapeau» à 1, par conséquent si une autre occurrence du même
événement a lieu d‟ici à sa prise en compte, elle est ignorée); «signal à compte» (les
occurrences non prises en compte immédiatement sont comptées pour utilisation ultérieure).
II.5. d. La boîte aux lettres
Une boîte aux lettres permet une communication asynchrone entre des tâches. Une boîte aux
lettres est constituée typiquement d‟une zone d‟échange tampon (buffer) dans laquelle une
tâche dite «émettrice» peut déposer des données, et d‟un mécanisme de gestion des données
(messages) stockées dans la boîte aux lettres.
- - La taille de la zone d‟échange est déterminée par le nombre de messages maximum
multiplié par la taille de chaque message.
- - Les données de la boîte aux lettres sont gérées généralement par une file de type FIFO (i.e.,
premier déposé/premier retiré). Donc, une tâche dite «réceptrice» retire les données dans
l‟ordre d‟arrivée des données. En fonctions de l‟implémentation, les données de la boîte aux
lettres peuvent être gérées par niveau de priorité. Ainsi, la priorité de données peut être
déterminée d‟une façon soit orientée message (chaque message est muni d‟une priorité qui
influence l‟ordre dans lequel il va être lu), soit orientée tâche (la priorité du message est liée à
la priorité de la tâche « émettrice »). Il en résulte que la zone d‟échange tampon possède
plusieurs files d‟attente des messages à l‟ordre de priorité, et les messages ayant la même
priorité sont gérés dans la même file d‟attente des messages de type FIFO.
Il est important de noter que la communication par la boîte aux lettres est asynchrone, car la
tâche « émettrice » n‟a pas besoin d‟attendre que la tâche «réceptrice» soit à l‟écoute pour lui
envoyer des données.
- Si la tâche «réceptrice» désire recevoir des données au moment où la boîte est vide, elle est
mise en attente jusqu‟à ce que des données aient été déposées dans la boîte (on parle de blocage en
lecture).
- Lorsque la tâche «émettrice» désire déposer des données dans une boîte pleine (car la taille
de la zone d‟échange tampon est normalement bornée), en règle générale, cette tâche elle-même,
est mise en état «en attente» jusqu‟à ce que des données aient été retirées de la boîte (on parle alors
de blocage en écriture, ou de la boîte aux lettres sans écrasement, qui dans ce cas ne fonctionne
plus de façon asynchrone). Cependant, en fonction de l‟implémentation choisie, le message le plus
ancien de la boîte peut être écrasé par le nouveau, en conséquence la tâche «émettrice» ne se
bloque jamais en écriture (on parle de la boîte avec écrasement).
La Figure suivante illustre une représentation récapitulative de la composition d‟une boîte aux
35
lettres (sans écrasement et avec écrasement).
Figure I.9 : Composition d‟une boîte aux lettres

II.5. e. Le rendez-vous
Le rendez-vous est une communication synchrone asymétrique des tâches avec passage de
données où une tâche dite «acceptante» attend un rendez-vous, et une tâche dite «appelante»
demande à effectuer un rendez-vous avec une tâche «acceptante». Lorsque un rendez-vous est
établi (donc, la tâche «acceptante» est sur une instruction de type «accept» et la tâche
«appelante» demande l‟obtention du rendez-vous), la tâche «acceptante» exécuté le code du
rendez-vous, tandis que la tâche «appelante» est bloquée jusqu‟à la fin du rendez-vous. Des
données peuvent alors être passées de la tâche «acceptante» à la tâche «appelante».
Le rendez-vous peut se ramener à l‟utilisation de deux boîtes aux lettres, nommées
respectivement «bal_demande_rdz» et «bal_fin_rdz» par exemple. Remarquez que dans cette
implémentation, la boîte aux lettres de demande de rendez-vous est nécessairement publique,
car toute tâche peut demander un rendez-vous, alors que la boîte aux lettres utilisée pour
signifier la fin du rendez- vous est spécifique à chaque tâche demandant le rendez-vous.
II.5. f. Le tableau noir
Le tableau noir est la forme la plus simple des outils de communication asynchrone. En effet,
un tableau noir est une zone de mémoire commune pouvant contenir un message où l‟écriture
d‟un message écrase le message précédent, et la lecture est non bloquante et non destructive
(c‟est-à-dire, une valeur déjà lue peut être relue plusieurs fois tant qu‟elle n‟a pas été écrasée
par une écriture).
Il est nécessaire d‟utiliser un mécanisme de protection pour garantir l‟exclusion mutuelle: un
accès à la donnée ne doit pas être interrompu par un autre accès. Cependant, il n‟est pas gênant
que plusieurs accès simultanés en lecture aient lieu. Nous voyons que le mécanisme de
protection d‟un tableau noir s‟apparente au problème du «lecteur/écrivain». La Figure
I.10 suivante représente un modèle de la communication par tableau noir.
Figure I.10 : Communication par tableau noir
II.6. Classification des algorithmes d’ordonnancement

L‟ordonnancement et l‟allocation sont des termes qui concernent des domaines étroitement liés
de sorte que l‟allocation des tâches est souvent confondue avec l‟ordonnancement des tâches et
on parle alors d‟ordonnancement local et d‟ordonnancement distribué (ou global).
36
Nous estimons que l‟appellation « ordonnancement local » exprime parfaitement le partage

d‟un processeur entre plusieurs tâches. Concernant l‟ordonnancement global ou distribué,
nous pensons que le terme allocation dynamique convient mieux, étant donné qu‟il s‟agit
d‟allouer les tâches refusées aux processeurs. Cela permet d‟éviter toute confusion.
II.6.1. Terminologie
- Ordonnancement de tâches : C‟est la détermination d‟un ordre d‟exécution des tâches selon les
critères spécifiés. Quand cet ordre est déterminé avant le début de l‟exécution, on parle d‟un
ordonnancement statique.
- Ordonnancement dynamique : Ordonnancement des tâches où la séquence déterminée au
préalable est mise à jour et réordonnée en fonction de nouvelles tâches.
- Allocation statique : placement d‟un ensemble de tâches sur un réseau de processeurs en
respectant et en optimisant certains critères ;
- Allocation dynamique : placement des tâches créées durant l‟exécution.
II.6.2. Mécanismes et algorithmes d’ordonnancement
- Mécanisme d’ordonnancement local de tâches : ensemble de modules nécessaires pour la
coordination de l‟ordonnancement des tâches sur un processeur. On l‟appelle aussi ordonnanceur.
Un bon mécanisme d‟ordonnancement doit assurer les fonctions suivantes :
- Vérification de la possibilité d‟exécuter une tâche sur le processeur sans violer ses contraintes.
Cela permet de répondre à la question suivante : « Etant donné un ensemble de tâches dont on sait
que les contraintes temporelles seront vérifiées, peut – on accepter une nouvelle tâche ? » Par
conséquent, une tâche peut être refusée localement lorsque l‟ordonnanceur local ne peut garantir
ses contraintes avec l‟ensemble des tâches préalablement ordonnancées.
- Le calcul des priorités des tâches ainsi que leur ordre d‟exécution et leurs dates de début et de fin
d‟exécution. Plusieurs algorithmes existent déjà pour réaliser ce calcul.
- La mise à jour et l‟adaptation (le re-calcul des priorités, le ré-ordonnancement) dans le cas de
l‟arrivée d‟une nouvelle tâche.
- Ordonnancement optimal : un algorithme d‟ordonnancement est dit optimal lorsque toute
configuration T de tâches qui est ordonnanceur par un algorithme donné, l‟est aussi par cet
algorithme. En d‟autres termes c‟est un algorithme qui permet de déterminer la meilleure séquence
d‟ordonnancement qui puisse exister (respect des échéances, le cas échéant, minimisation es
retards, minimisation du temps d‟utilisation des ressources notamment le processeur).
- Ordonnancement préemptif : C‟est un algorithme qui permet d‟interrompre
l‟exécution de la tâche courante pour la prise en compte d‟une autre tâche plus prioritaire. Cela
signifie qu‟il fournit des mécanismes nécessaires pour gérer la préemption c'est-à-dire la
commutation du contexte : elle consiste à sauvegarder le contexte de la tâche en cours
d‟exécution (registres et zones mémoires) interrompue pour l‟exécution d‟une autre tâche. Ce
contexte sera restauré quand l‟exécution de la tâche sera reprise. Ainsi, une tâche qui ne pouvant
pas être exécutée en entier est tout de même accepté si son exécution peut être partitionnée. Le
temps de commutation doit être négligeable et doit être pris en compte lors du calcul des dates de
début d‟exécution par l‟ordonnanceur. Il existe deux façons d‟autoriser la préemption : la première
consiste à n‟autoriser la préemption ou l‟interruption de la tâche en cours que si son exécution peut
ultérieurement être reprise sur le même processeur et la seconde envisage le cas échéant de faire
migrer la tâche. La migration se fait lorsque le processeur reçoit une tâche très prioritaire et qu‟il
interrompe la tâche en cours car sa priorité est moindre, sans pouvoir reprendre cette exécution par
la suite. Il est déconseillé de recourir à la migration. On préfère plutôt le transfert de tâches c‟est
37
placer des tâches avant le début de leur exécution. L‟ordonnancement préemptif est très
recommandé pour toutes les applications temps réel dynamiques.
- Mécanisme d’allocation statique des tâches : c‟est un algorithme qui permet de répartir un
ensemble de tâches entre les processeurs alloués à la machine en tenant compte des contraintes
temporelles.
- Mécanisme d’allocation dynamique des tâches : c‟est un algorithme qui entre en action
lorsqu‟une tâche est refusée localement. Il se charge de déterminer un processeur pour exécuter la
tâche. Il est doté des modules de politiques de recherche de processeurs pour la tâche refusée et de
politiques pour le maintien d‟un état de processeurs afin de choisir le plus capable d‟assumer le
respect des contraintes de la tâche.
38
Chapitre III. Programmation concurrente et programmation

temps réel
Une application TR est être décrite comme un ensemble de tâches communicantes qui peuvent
partager des ressources critiques.
La concurrence est donc un des problèmes fréquemment posés dans les STR et dans de tels
systèmes, plusieurs activités dont chacune est représentée par une tâche indépendante, peuvent
s‟exécuter en parallèle. D‟une manière générale, le fonctionnement d‟une application TR
comprend les activités suivantes :
- L‟acquisition des données depuis l‟environnement à l‟aide des capteurs ;
- Le traitement des données et l‟élaboration des résultats des résultats au bout d‟un délai
limité (caractère tempe réel)
- L‟envoi des ordres de commande de l‟environnement à l‟aide d‟actionneurs ;
Ainsi, des tâches peuvent être chargées de l‟acquisition des données à différentes périodes,
d‟autres tâches peuvent être dédiées au calcul, et d‟autres à l‟application de commandes.
Lorsque ces activités se synchronisent et communiquent, le respect de l‟exclusion mutuelle, de
la synchronisation et de la communication est vraiment un point clé auquel il convient de
s‟adresser. L‟exclusion mutuelle consiste à garantir un aspect exclusif à une donnée ou une
ressource partagée par plusieurs tâches. La synchronisation permet de bloquer une tâche tant
qu‟une autre ne la réveille pas. La communication permet à des tâches d‟échanger des données.
D‟où les méthodes de conception de ces systèmes sont utilisées pour faciliter l‟implémentation
de tâches partageant des ressources communiquant et se synchronisant : DARTS, SA, SD, etc.
III.1. Définitions
On appelle programmation concurrente les techniques et notations permettant :
- l'expression et la manipulation (construction, destruction, lancement, arrêt, ...) d'entité
concurrentes que l'on appelle tâches ou processus ;
- la mise en place de moyens de communication et de synchronisation entre ces entités ;
- l'abstraction de l'exécution réelle des processus ou tâches sur une architecture parallèle ou
non.
La programmation temps réel est assimilable à la programmation concurrente avec comme
particularité :
- Des mécanismes ou notations permettant d'accéder au temps réel (généralement une horloge
temps réel) ;
- Des mécanismes permettant de définir ou de modifier la priorité des processus et/ou de
définir et de modifier des échéances temporelles ;
- La suppression ou l‟adaptation de certains traits du langage utilisé afin d'alléger l'applicatif
et/ou de le rendre plus déterministe.
III.2. Intérêts de la programmation concurrente

- Optimisation de l'utilisation des ressources : C'est-à-dire la programmation concurrente
optimise l'utilisation du CPU sur une architecture mono-processeur par la prise en compte du
39
parallélisme entre calcul et entrées / sorties.
III.1. Programmation concurrente

Calquer le monde réel :
En effet, le monde réel est fait d'entités concurrentes qui interagissent. Par exemple :
- Un système de réservation de billets doit nécessairement prendre en compte le fait que les
agences effectuent les réservations en parallèle.
- Un système de guidage doit utiliser les informations fournis par plusieurs capteurs
simultanément et donner des ordres à plusieurs actionneurs.
La traduction d„un monde à base d'entités concurrentes à l'aide de techniques de
programmation séquentielle conduit à :
- Inclure dans le code la répartition de l'appel des différents composants du système ;
- Modifier le programme dès que l'on change d'architecture (nombre de processeur, répartition
de l'application) ;
- Modifier profondément le programme dès que l'on inclut une nouvelle activité.
III.3. Problèmes possibles

Les problèmes inhérents à la programmation concurrente sont :
Problèmes de sûreté : la synchronisation des processus ou tâches peut entraîner des problèmes
tels que l'interblocage ou la famine.
- Par exemple, le processus A attend le processus B, qui lui-même attend le processus C qui
lui-même attend le processus A : il y a un interblocage (ou étreinte fatale ou encore
deadlock)
- Autre exemple, le processus A et B forment une coalition pour empêcher C d'accéder à une
ressource (A et B se la passent) : il y a famine du processus C.
Ces problèmes sont inhérents à la concurrence
Problème de vivacité :
- Suite à une mauvaise entente, il est possible que deux processus n'arrivent jamais à se
synchroniser; ceci peut conduire à l'absence de respect d'un objectif fixé sans pour autant
qu'il y ait interblocage.
Par exemple, pour réparer un chauffe-eau électrique, le plombier peut exiger que l'électricité
40
soit à la norme : il faut donc l'intervention préalable de l'électricien; l'électricien peut lui exiger
de ne faire les travaux que lorsque les problèmes de fuites d'eau seront résolus : il faut au
préalable l'intervention du plombier.
Les deux processus sont actifs (ils viennent régulièrement) mais ils ne font pas progresser les
choses : on est face à une activité non constructive et donc un problème de vivacité
Difficile reproductibilité des erreurs
- L'entrelacement des différents processus (chacun peut avancer à son rythme) va définir un
nombre de comportements possibles très important.
Si l'on a quatre processus indépendants, chacun ayant dix états différents, on obtient un système
complet ayant 10^4 = 10 000 états différents ;
Chaque exécution ne va pas nécessairement faire évoluer exactement de la même façon les
processus (leur évolution dépend généralement du monde extérieur qui est en perpétuel
changement).
- Ainsi, si une erreur survient il est très difficile de reproduire cette erreur afin de comprendre
son origine.
En conclusion
La concurrence introduit des problèmes spécifiques qui peuvent être difficile à analyser.
Cependant, elle simplifie énormément le travail du concepteur et du programmeur qui peut à la
fois calquer la réalité dans son programme tout en tirant partie de l'optimisation possible des
ressources. Il existe de plus des méthodes de test formel adaptées à l'analyse de systèmes
concurrents.
III.4. Généralités sur la manipulation de processus et de tâches

III.4.1. Terminologie
On dit qu‟un système est :
- Multi-tâches lorsque plusieurs entités concurrentes s'exécutent sur une machine mono
processeur.
- Parallèle lorsque plusieurs entités concurrentes s'exécutent sur plusieurs processeurs avec une
mémoire commune.
- Réparti lorsque plusieurs entités concurrentes s'exécutent sur des machines distinctes reliées
en réseau et ne partageant pas de mémoire commune.
On dit que deux processus ou tâches sont
- Indépendants, si l'évolution de l'un n'influe pas et ne dépend pas de l'autre ;
- En coopération, si chacun mène un travail distinct de l'autre mais avec un objectif commun
et la mise en place de synchronisation et de communication et qu'il n'y a pas compétition sur
l'accès à certaines ressources ;
- En compétition lorsqu'ils sont en coopération mais lorsque, de plus, ils sont en compétition
sur l'accès de certaines ressources.
Selon le niveau d'observation, deux processus peuvent être vus en coopération ou en
compétition.
41
III.4.2. Processus et tâches

Un processus possède son propre espace d'adressage : il s'exécute sur sa propre machine
virtuelle.
Le système d'exploitation (ou le "run-time" dans le cas d'un exécutif) met en place des
mécanismes de protection contre l'interférence inter-processus.
Le partage de mémoire est alors soit impossible soit doit se faire de manière explicite (i.e. appel
système).
Une tâche partage son espace d'adressage (sa machine virtuelle) avec d'autres tâches (dépend du
système et de la création des tâches).
Les mécanismes de protection limitant l'interférence interprocessus n'existent pas pour les tâches
: une tâche accède sans limite à sa machine virtuelle.
Le programmeur (et/ou le langage utilisé) doit mettre en place manuellement ces mécanismes de
contrôle.
III.4.3. Etats de base d’un processus
III.2. Etats de base d‟un processus

1. Etat d’initialisation
L'initialisation d'un processus (ou d'une tâche) consiste à construire un environnement
d'exécution.
Selon les constructions offertes par le langage ou le système, il est ou non possible de passer en
paramètres du processus ou de la tâche des valeurs lui permettant de s'initialiser.
2. Etat d’exécution
L'état "exécution" peut être décomposé en sous états : prêt/bloqué/exécution réelle.
Figure III.3. Etats d‟exécution des tâches
42
3. Etat de terminaison
Un processus ou une tâche peut terminer sous différentes conditions :
- fin normale des instructions
- suicide par l'exécution d'une instruction de terminaison
- avorté par l'action d'un autre processus/tâche
- fin sur erreur (exception ou signal non récupéré)
- lorsque son rôle n'est plus utile
- jamais
III.5. Ecriture et lancement (démarrage) des processus et de tâches

Quatre possibilités existent pour écrire les processus :
L'utilisation de co-routines
- Les co-routines sont des sous-programmes qui se passent le contrôle les unes aux autres
par une opération « resume Nom_Coroutine »
- L'exécution par A d'un « resume B » suspend l'activité de la co-routine A au profit de B qui
s'exécute alors jusqu'à l'exécution d'un « resume ». A reprendra son exécution au point où
elle l'avait laissé lorsqu‟une co-routine lui passera le contrôle avec un « resume A ».
- Les données locales à une co-routine sont persistantes d'un appel à l'autre.
- Chaque co-routine peut être vue comme un processus. Cependant, il n‟est pas nécessaire
d‟utiliser un véritable système concurrent : l'enchaînement des opérations est réalisé par les
co-routines elles même.
L'utilisation de primitive du type "fork & join »
- La primitive « fork » permet de créer un nouveau processus qui s'exécutera concurremment
avec son père.
- La primitive « join » est l'opération inverse et permet à un père d'attendre la terminaison de
ses fils.
- L'acceptation classique du fork (le fork d'Unix) est que le processus crée ne diffère de son
père que par la valeur du retour de cette primitive (0 pour le fils et l'identifiant système du
fils pour le père).
- Le join en Unix est implémenté par la primitive « wait » ou « waitpid ».
Exemple
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>
#define N 50 int main(void)
{
pid_t tab_pid[N]; // pid des fils int status, i;
for (i=0; i<N; i++){
if ( ! (tab_pid[i] = fork()) ){
// le code du fils; ici un simple affichage et un repos de une seconde printf("hello\n");
sleep(1);
exit();
}
43
}
// seul le pere arrive ici car les fils ont termine par exit
// il attend cette terminaison for (i=0; i<N; i++){
waitpid( tab_pid[i], &status, 0);

}
return 0;
}
L'utilisation de blocs "cobegin" ou "parbegin »
- Le cobegin est une construction réalisant l'exécution concurrente d'un ensemble de
séquences d'instructions.
cobegin
Suite_D_Instructions_1
Suite_D_Instructions_2
... Suite_D_Instructions_N coend
- Le bloc termine quand toutes les séquences ont terminées
La déclaration explicite des processus avec lancement implicite ou explicite
Les co-routines :
- Certains langages offrent des constructions spécifiques pour la déclaration de tâches ou de
processus :
- En Ada : type Task
- En Java : classe thread
- L‟exécution d’une tâche ou d’un processus est soit faite automatiquement lors du démarrage du
programme (cas de Ada) ou faite explicitement par une instruction particulière (cas de Java avec
l’appel de la méthode start() d’une thread)
III.6. Conclusion
La programmation concurrente simplifie la conception des systèmes temps-réel qui sont par
nature des systèmes concurrents.
Elle peut cependant introduire certains problèmes spécifiques liés en grande partie à la
synchronisation des tâches.
Les langages, ou les systèmes d‟exploitation, offrent différents mécanismes pour la
représentation et l‟exécution des tâches ou processus.
44
Chapitre IV : Cycles de vie de développement des applications temps réel

Le développement d‟une application selon le génie logiciel peut être découpé en plusieurs
activités (appelées aussi phases), lesquelles constituent le cycle de vie de l‟application. Les
systèmes experts temps réel n‟échappent pas à cette règle. Plusieurs méthodes ont été proposées
pour la maîtrise du processus de développement d‟un logiciel et prennent en compte en plus des
aspects techniques, l‟organisation et les aspects humains.
Le modèle en V est le modèle le plus complet du fait qu‟elle intègre les relations entre les
différentes activités, entre les différentes étapes et entre les étapes et les activités.
Les applications temps réel sont vues comme un ensemble de tâches communicantes et
partageant des ressources limitées. Par conséquent, le cycle de développement en W convient
mieux pour ces types d‟applications. En effet, un cycle en W est décrit par deux cycles en V qui
sa suivent :
Le premier cycle V (spécification, conception unitaire et détaillée, codage, tests unitaires, test
d‟intégration) a lieu généralement en liant l‟application temps réel à un simulateur du procédé
contrôlé.
Le second cycle en V consistera à valider le partage du système, validé sur un simulateur dans
le premier cycle en V, sur un noyau temps réel physiquement connecté au procédé connecté.
Ainsi, le premier cycle verra ses premières phases (spécification, conception et codage) réduites
à l‟étude du partage du système sur le noyau temps réel et à la connexion physique au procédé.
Notons qu‟à la fin du cycle en W, il est nécessaire dans le cadre des applications TR à
contraintes strictes, de s‟assurer de la correction temporelle du système (c‟est-à-dire la
cohérence entre la dynamique du procédé contrôlé et la vitesse d‟exécution des tâches). La
validation temporelle de telles applications s‟avère très indispensable et cruciale à un niveau
très haut de sûreté de fonctionnement.
4.1. Architecture des systèmes de contrôle-commande
Une application de contrôle-commande est constituée de deux composantes fondamentales. La
première composante est matérielle. Il s‟agit des interfaces permettant de piloter le procédé et
de recueillir des informations en provenance de ce dernier (i.e., des cartes d‟entrée/sorties
analogiques ou numériques,…). La deuxième composante est logicielle. Elle assure le bon
fonctionnement du procédé. C'est-à-dire que ce dernier puisse satisfaire toute sa spécification
sans aucune défaillance. Cette double composante implique une spécification et un
développement conjoints des parties matérielles et logicielles ainsi que des tests d‟intégration
lors de la mise en oeuvre effective sur le procédé.
4.1.a. Architecture logicielle muti-tâches des systèmes de contrôle-commande
Un système informatique de contrôle-commande doit satisfaire a priori la cohérence entre des
changements de l‟environnement et des réactivités du système face à ces changements. A cause
du comportement concurrent des événements et des données externes, il est nécessaire de
décrire l‟environnement en tant qu‟un système fortement parallèle. Il en résulte qu‟une
architecture adaptée pour répondre à ce comportement parallèle du procédé externe est une «
architecture multitâche ».
45
Figure IV.1 : Architecture multi-tâche d‟une application temps réel

Cette architecture permet de faciliter la conception de logiciel en définissant les tâches comme
« les entités d‟exécution et de structuration de l‟application ». En effet, dans cette architecture
logicielle multitâche, on peut découper cet ensemble de tâches selon les groupes suivants :
. Tâches d’entrées/sorties : permettent d‟accéder aux données externes fournies par des
capteurs, ou de générer des commandes aux actionneurs par l‟intermédiaire de cartes
d‟entrées/sorties. Ces tâches peuvent être exécutées de façon régulière ou par interruption.
. Tâches de traitement : constituent le coeur de l‟application. Elles peuvent être considérées
comme des boîtes noires, exécutant des algorithmes issus par exemple du traitement du signal,
du traitement d‟images, ou de l‟automatique…
. Tâches de gestion de l’interface utilisateur: permettent de présenter l‟état du procédé ou de sa
gestion à l‟utilisateur. Donc, l‟utilisateur peut modifier les consignes données ou changer les
commandes.
Tâches de communication: 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: permettent de stocker l‟état du système à des instants fixés afin de
pouvoir être utilisé a posteriori en cas de l‟analyse de son fonctionnement, ou de reprise
d‟exécution à une étape précédente.
Les tâches obtenues, qui constituent le système informatique de contrôle-commande, ne sont
pas des entités d‟exécution indépendantes. Certaines tâches dès leur activation communiquent
et/ou se synchronisent avec les autres tâches, ou sont connectées à l‟extérieur pour les
entrées/sorties.
Ainsi, dans l‟architecture logicielle multitâche, il faut que le concepteur adresse des problèmes
des relations entre tâches, qui sont représentées typiquement par la synchronisation, la
46
communication, le partage de ressources (ces types de relations sont décrits en détails aux
paragraphes suivants de ce manuscrit), afin d‟assurer le comportement concurrent des systèmes
de contrôle-commande.
4.1.b. Architecture matérielle des systèmes de contrôle-commande
L‟aspect matériel a une très grande importance dans les applications de contrôle-commande.
Cette implication est liée d‟une part à la connexion directe avec le monde physique réel à l‟aide
d‟une grande diversité de systèmes d‟entrées/sorties, et d‟autre part au matériel informatique
parfois spécifique et développé pour une application donnée. En fait, l‟architecture matérielle
décrit l‟agencement de composants électroniques ainsi que leur interaction. Elle est souvent
grandement masquée aux utilisateurs par le biais du système d‟exploitation, qui donne une
abstraction unifiée de tous les composants physiques. Dans ces matériels, nous pouvons trouver
des processeurs du type microcontrôleur, des mémoires, des horloges, des composants
spécifiques (i.e., ASIC: Application Specific Integrated Circuit), des alimentations…,
disciplines qui débordent largement le contexte de ce manuscrit.
4.2. Cycles de vie développement d’un logiciel
Le génie logiciel est « l‟application pratique de la connaissance scientifique dans la conception
et l‟élaboration de programmes informatiques et de la documentation associée nécessaire pour
les développer, les mettre en œuvre et les maintenir ». Le génie logiciel consiste à appliquer des
méthodologies, c‟est-à-dire à développer et à utiliser des méthodes et des outils dans le but de
produire des logiciels de qualité en respectant des contraintes de temps et de coût. En effet, on
cherche à développer des logiciels qui correspondent aux besoins des utilisateurs de ces
logiciels.
Le cycle « problème-solution » en est un exemple. Dans ce cas, on est souvent en quête de la
solution. Mais il n‟existe pas de solution définitive parce que la solution proposée peut être
inadaptée (le problème a été mal compris) ou l‟application de cette solution peut entraîner des
nouveaux problèmes ou mettre à jour des problèmes déjà existants. Donc, le fait de trouver une
solution n‟implique pas la fin des problèmes.
Il existe des « critères » de qualité dont un développement peut être fait pour satisfaire tout ou
partie d‟un ensemble de ces critères.
. Exactitude: le plus important des critères de qualité. Exigence d‟un logiciel à être exempt
d‟erreur; à fournir des mêmes résultats dans les mêmes conditions normales d‟utilisation.
Notons que ce déterminisme et cette reproductibilité des résultats ne sont pas adaptés au temps
réel.
. Robustesse: Capacité d‟un logiciel à maintenir ses performances malgré des changements
dans les conditions de fonctionnement ou la présence d‟incertitudes liées à ses paramètres. Il
s‟agit du fait qu‟un logiciel doit bien réagir lorsque l‟on s‟écarte des conditions normales
d‟utilisation.
. Extensibilité: Possibilité pour un logiciel d‟utiliser tout ou certaines parties de ce logiciel pour
développer un autre logiciel répondant à d‟autres besoins, sans modification ou avec des
modifications mineures.
47
. Portabilité: Facilité avec laquelle on peut exploiter un logiciel dans différentes

implémentations. On distingue la portabilité de la compatibilité. Le terme compatibilité est
plutôt employé pour désigner la capacité d‟un ordinateur et du matériel associé à communiquer
entre eux et à échanger des données ou de deux ordinateurs à exécuter les mêmes programmes.
. Efficience: Caractéristique d‟un logiciel dans laquelle il y a un gain de temps, de taille,…
pour satisfaire des besoins des utilisateurs. Ce critère est très important dans les applications
embarquées.
Le développement d‟un logiciel se fait suivant un cycle, appelé le cycle de vie d‟un logiciel. Le
cycle de développement du logiciel est un ensemble de phases permettant de transformer à
travers un logiciel les besoins en des processus de traitement automatique d‟information en
provenance de son utilisateur, de son environnement ou de lui-même pour répondre à ces
besoins. La décomposition en phases de développement permet aussi de faciliter le suivi, la
vérification et la validation du projet par le concepteur et l‟utilisateur.
Il existe de nombreux modèles de cycle de vie: modèle en «Cascade», modèle en V, modèle en
«Spirale», modèle en W,… Malgré des différences de ces modèles, tous se composent des
différentes phases qui sont échelonnées dans le temps :
- Spécifications des besoins
- Conception préliminaire
- Conception détaillée
- Implémentation
- Tests unitaires et tests d‟intégration
- Validation
- Exploitation/Recette
Une phase se termine par la remise d‟un (ou plusieurs) document(s) validé(s) conjointement par
l‟utilisateur et le concepteur. Une phase est terminée lorsque la revue de cette phase est faite. Et
une phase ne peut commencer que lorsque la précédente est terminée.
4.2.1. Le cycle de vie en «Cascade»
Etant proposé par W. Royce, le modèle en « Cascade » est considéré comme le modèle
classique de développement d‟un logiciel. A l‟origine, le cycle de vie en « Cascade » n‟est pas
itératif. Il est vu comme un processus séquentiel comprenant les phases suivantes : la
Spécification, la Conception Préliminaire, la Conception Détaillée, l‟Implémentation, des Tests
unitaires et tests d‟intégration. Si une erreur se produit dans une de ces phases, elle va se
propager à des phases successives. Et des changements ne sont pris en compte qu‟à la fin de la
dernière phase. Ce qui pose un surcoût de développement et de validation d‟un logiciel.
48
Figure.IV.2.a :Modèle en Cascade affiné et IV.2.b :Itérations dans la phase de conception

Le modèle de vie en «Cascade» affiné est présenté sur la Figure IV.2.a Dans ce modèle, chaque
phase peut mener à la précédente ou la suivante mais rarement aux phases plus éloignées dans
la séquence.
La vertu de ce modèle dans le développement est qu‟il existe une liaison entre les phases après
la phase de Spécification, ce qui permet de retourner au point pour lequel une difficulté
imprévue survient. Cependant, dans certains cas, une telle démarche peut être risquée et
échouer. Ainsi, si une erreur détectée dans la phase de Tests est liée à une mauvaise Conception
ou à une Spécification imprécise, un effort pour refaire le code dans la phase d‟Implémentation
peut ne pas remédier au problème. En effet, le développement peut retourner de nouveau à
l‟origine de la phase de Spécification (voir Figure IV.2.b). Un autre modèle en «Cascade»
affiné est proposé dans d‟autres ouvrages: il permet de revenir depuis une étape à l‟une
quelconque des étapes précédentes. W. Boehm propose un modèle en «Cascade» raffiné vers
une étape “build it twice” en incorporant un prototype à chaque étape pour le feed back.
Dans le schéma de la figure IV.2.a ou IV.2.b., on retrouve :
La Spécification: l‟appréhension du système passe par une vue totale de toutes ses
caractéristiques pour répondre à la question “De quoi s‟agit-t-il?”. Ce sont des aspects
exhaustifs du système qui décrivent non seulement des besoins fonctionnels (les services
attendus du système), mais également des besoins non fonctionnels, c‟est-à-dire les services
comportementaux, matériels et les qualités requises. En effet, pour les systèmes temps réel, il
faut s‟étendre sur des contraintes temporelles, d‟interfaces de communication, etc. La
Spécification peut être exprimée de manière informelle en langue naturelle, mais elle peut être
complétée sous forme de notations ou de diagrammes formels comme le proposent Z, B,
SART, UML, Statechart,…
La Conception: cette phase peut se diviser elle-même en deux étapes, la Conception
Préliminaire et la Conception Détaillée. Elle a pour objectif de définir une structure interne du
système vis-à-vis des spécifications imposées dans la phase précédente pour répondre à la
question “Comment fait le système?”. La Conception Préliminaire produit une architecture
générale du système en le décomposant en composants constitutifs, notamment des modules et
des tâches concurrentes. Un module est une unité regroupant un ensemble de fonctions ou
procédures destinée à être utilisées en conjonction avec d‟autres composants. Une tâche
concurrente est une tâche pouvant s‟exécuter en parallèle d‟autres tâches. Le découpage en
modules et tâches concurrentes impose une différence entre les systèmes temps réel et les
49
autres. Elle constitue le point de vue statique et le point de vue dynamique de la structure
interne du système. La Conception Détaillée permet à partir du résultat de la Conception
Générale de poursuivre le découpage du système jusqu‟à arriver à une description détaillée de
chacun des composants. Cette phase consiste à décrire les choix algorithmiques, à préciser la
signature des tâches et des fonctions, à définir les structures de données, et à spécifier les
protocoles de communication. Comme la phase de Spécification, il est possible d‟utiliser une
méthode de conception lors de cette phase. DARTS, UML, etc. font partie des méthodes de
conception.
L’Implémentation: cette étape permet d‟implémenter les concepts proposés dans la phase de
Conception. Lors de cette étape, chacun des composants est encodé en langage de
programmation. En effet, pour les systèmes concurrents, soit un langage concurrent (Ada,
Module 2,…) soit un langage séquentiel utilisé conjointement à un système d‟opération
multitâche ou un noyau temps réel (i.e., C et exécutif temps réel). En outre, un langage de
programmation graphique peut être utilisé. Grâce à sa programmation graphique, ce langage
permet non seulement d‟implémenter des concepts de
Conception mais aussi de faire intégrer les composants continus d‟une application réelle dans
un environnement homogène de manière intuitive. LabVIEW (Laboratory Virtual Instrument
Engineering) est un tel langage qui sera utilisé principalement dans la suite pour le
Développement d‟un logiciel.
4.2.2. Le cycle de vie en «V»
Le cycle de vie en «V» est une variation du modèle en «Cascade». Contrairement au cycle de
vie en «Cascade», le cycle de vie en «V» se focalise sur la vérification et la validation. Un
processus en «V» s‟accomplit en deux pentes: une pente descendante et une pente ascendante.
La pente descendante du «V» reprend les étapes progressives du modèle en «Cascade» à partir
de la Spécification jusqu‟à l‟Implémentation. La pente ascendante du «V» porte un ensemble
de tests qui permettent de vérifier et/ou de valider le système développé en faisant correspondre
chaque étape de tests ou de validation à une étape de l‟analyse et de la conception (voir Figure
IV.2.c).
Figure IV.2.c. : Modèle en V
- Les tests unitaires: permettent de vérifier que les composants indépendants du système
répondent chacun à leurs spécifications et fonctionnent correctement en tous Les tests
d‟intégration: sont des tests qui se déroulent suivant les tests unitaires servant à vérifier que les
composants réalisés indépendamment fonctionnent bien ensemble. Il s‟agit de tester des
50
relations d‟utilisation entre les composants, le fonctionnement de tâches qui s‟appuient sur les
composants, des mécanismes de communication et de synchronisation La validation: permet de
vérifier que le logiciel développé répond aux besoins exprimés dans la phase de Spécifications.
Le canevas du modèle en «V» améliore celui du modèle en «Cascade» avec une limitation des
retours aux étapes précédentes. Les phases de la partie montante doivent renvoyer des
informations sur les phases en vis-à-vis lorsque des défauts sont détectés afin d‟améliorer le
logiciel. Cependant les difficultés fondamentales du modèle linéaire que l‟on affronte dans le
modèle en «Cascade» existent encore. Parce que chaque phase est traitée complètement avant
que la suivante ne soit commencée, les tests de vérification et de validation ne sont renvoyés
qu‟en fin du processus d‟implémentation. Et parce que la plupart des erreurs sont relevées
pendant les spécifications, les retours coûtent chers.
4.2.3. Les autres cycles de développement d’un logiciel
Pour le modèle en «V» en particulier, le modèle linéaire en général s‟appuie sur des documents
complètement élaborés comme un critère de transition entre des étapes. Un tel modèle est bien
adapté pour des systèmes dont on pourrait obtenir la totalité des besoins au départ. Ce qui nous
permet d‟une part de préparer tardivement des phases de tests, d‟autre part de figer ces besoins
dans toutes les étapes successives. Pourtant, avec un modèle «dirigé par les documents»
[Boe88], plusieurs projets sont produits avec des spécifications détaillées de services qu‟ils ne
maîtrisent pas encore (i.e., l‟interface utilisateur et les opérations fournies). Par conséquence, il
y a de grandes chances que dans la conception et le développement de ces projets qui vont
suivre, une grande quantité de code soit inutilisable.
Pour des systèmes à risques, il est favorable d‟utiliser d„autres techniques de prototypage qui
permettent de valider tout ou une partie du cahier des charges et de prendre en considération le
«feedback» entre le concepteur et l‟utilisateur. Parmi ces modèles, on retrouve:
6.2.3. a. Le modèle en «Prototype Rapide» (Rapid Prototyping Model)
Ce modèle focalise l‟objectif du logiciel à la première étape du cycle de développement: une
conception et un prototype seront construits rapidement, ce qui permet de le vérifier avant la
phase de spécification et d‟exiger moins de boucles de «feed-back» par rapport au modèle en
«Cascade». Ce modèle est très utilisé dans l‟industrie automobile, où le constructeur peut être
amené à faire à l‟appel d‟offre aux instrumentiers en se basant sur un prototype tournant.
51
Figure IV.2.d. : Modèle en Prototype Rapide

4.2.3.b. Le modèle Incrémentiel et Itératif (Incremental and Iterative Model)
Avec ce modèle, le développement est découpé en étapes quand le logiciel se divise en
morceaux dont chacun correspond à un ensemble de besoins. A chaque étape, on emploie un
modèle de vie linéaire pour élaborer un ou plusieurs morceaux du système simultanément. Puis
ces morceaux sont intégrés et testés ensemble. Le produit final est une série de modèles
incrémentiels (voir Figure IV.2.e).
52
Figure IV.2.e : Modèle incrémental

4.2.3.c. Le modèle en «Spirale»
Le modèle en «Spirale» est un modèle dirigé par les risques, proposé par W. Boehm.
Dans ce modèle, la dimension radicale représente le coût cumulatif, la dimension angulaire
représente le progrès atteint à chaque cycle de spirale (phase). Une phase commence par
l‟identification des objectifs de la phase, des alternatives pour obtenir ces objectifs et leurs
contraintes. Puis, à la suite, chaque alternative est analysée sous un point de vue «risques». Des
prototypes, des simulations,... seront préparés afin de résoudre chacun des potentiels risques. Si
tous les risques sont résolus, le concepteur peut poursuivre l‟étape suivante. Cette étape
correspond à un modèle de vie classique (en «Cascade» ou en «V» avec Recherche des
fonctionnalités, Analyse des besoins, Conception Préliminaire, Conception Détaillée, etc.)
modifié pour incorporer au développement évolutif. Enfin, les résultats du cycle actuel sont
évalués et un plan est vérifié pour les cycles successifs (voir Figure IV.2.f).
53
Figure IV.2.f. : Modèle en Spirale

4.2.3.d. Programmation orientée-objet (Object-Oriented Programming)
Figure IV.2.g. : Modèle « Round-Tripping » de Booch

54
La programmation orientée-objet (OOP ou POO) n‟est pas un modèle de développement d‟un

logiciel à proprement parler. Elle fait appel notamment à l‟encapsulation et au polymorphisme,
ce qui permet de réduire la complexité et d‟augmenter la réutilisabilité des programmes. Avec
le développement des langages de programmation orientée-objet tels que C++, Smalltalk, Java,
C#, etc. de nos jours, la POO devient un nouveau style de programmation, ce qui la fait se
différencier par rapport à la programmation procédurale traditionnelle. Diverses méthodes
utilisées lors du cycle de développement se basent directement sur ce modèle de
développement, comme le modèle «Round-Tripping» de Booch représenté sur la Figure IV.2.g.
A gauche, nous voyons que les diagrammes UML sont utilisés pour l‟analyse et la conception
d‟un système, tandis qu‟à droite le langage Java est utilisé pour l‟implémentation. Le code Java
est généré à partir des diagrammes UML, et le «feed-back» des changements de code est
renvoyé aux diagrammes UML. Le domaine des applications de ce modèle est très vaste, car il
est basé sur UML.
Tous ces modèles prennent en charge la totalité du développement du logiciel en prenant en
compte le cycle de décision et de l‟analyse de risques. Dans le cadre de cette thèse, où nous
nous focalisons sur la conception, ce sujet n‟est pas traité en détail.
4.3. Le cycle de vie Logiciel/Matériel
En informatique industrielle, on parle d‟un système temps réel lorsque ce système informatique
contrôle un procédé physique à une vitesse adaptée à l‟évolution du procédé contrôlé. Ce
système doit réagir continuellement à des événements en provenance du procédé contrôlé avec
des contraintes temporelles dont le respect est aussi important que l‟exactitude du résultat. Une
réaction ne respectant pas son échéance pourrait causer une catastrophe humaine et financière.
Un tel système comporte deux parties fondamentales: le matériel et le logiciel. Le matériel
est la partie physique (le microprocesseur, la carte d‟acquisition, le convertisseur A/D ou D/A,
etc.) permettant de piloter le procédé et de recueillir des informations en provenance de ce
dernier. Le logiciel est un ensemble des éléments informatiques assurant le fonctionnement du
procédé contrôlé. Une part significative du développement d‟un système temps réel consiste à
décider des composants matériels et des composants logiciels du système, ainsi que du choix de
quelles parties peuvent être implémentées comme des logiciels s‟exécutant sur des composants
programmables et lesquelles peuvent être implémentées sur des matériels spécifiques .
Il existe deux approches: l‟approche de développement «Matériel/Logiciel» traditionnelle et
l‟approche de développement «Matériel/Logiciel» en Co-design.
4.3.1. L’approche de développement «Logiciel/Matériel» traditionnelle
Dans cette approche, le développement d‟un système temps réel est divisé en deux parties, une
partie matérielle et une partie logicielle. Les deux cycles en «V» dans la Figure IV.2.h.
représentent les deux développements distincts de l‟architecture matérielle et de l‟architecture
logicielle. A partir de la conception préliminaire, le concepteur partitionne le système en des
composants matériels et des composants logiciels. Parce que la distinction des composants
matériel/logiciel à ce niveau n‟est pas claire. Le choix dépend de l‟expérience du concepteur,
du savoir-faire, du coût de production et de maintenance. Le choix du matériel se déroule
souvent a priori en fonction des expériences passées du concepteur. Puis, à la suite, les
architectures sont développées séparément dans leur propre cycle de vie en «V» avec des
55
phases séquentielles (la conception détaillée, l‟implémentation, des tests unitaires). Lorsque le
matériel et le logiciel satisfont chacun leur fonctionnement, on les intègre ensemble dans la
phase d‟intégration et la phase de validation afin de vérifier la communication entre ces deux
parts, et aussi le fonctionnement du système considéré (i.e., des tests d‟opération, des
évaluations des contraintes temporelles,…).
Figure h. : Modèle de développement « Matériel Logiciel » traditionnel

L‟approche développement «Matériel/Logiciel» traditionnelle est une approche très répandue
dans le monde des systèmes embarqués temps réel. En séparant un tel système en une partie
matérielle et une partie logicielle, l‟approche traditionnelle donne une vue claire de
l‟architecture opérationnelle d‟un système temps réel. Cependant, cette approche a quelques
inconvénients.
Premièrement, la partition de matériel/logiciel a lieu aussitôt à partir de la conception générale,
ce qui ne permet pas une séparation évidente des composantes matérielles/logicielles. Le choix
de matériel a priori est empirique et dépend de l‟expérience du concepteur. De plus, des
impacts entre le matériel et le logiciel ne sont pas bien définis. Par conséquent, des problèmes
de matériel détectés tardivement dans la phase de l‟intégration peuvent entraîner un nombre de
modifications de logiciel. Cela va diminuer la qualité et augmenter le coût de développement
d‟un système.
Enfin, la validation des composantes logicielles sur des exécutifs réels n‟est pas aisée. Il faut
vérifier ces dernières sur les deux aspects, l‟aspect fonctionnel et l‟aspect temporel. Il existe de
nombreuses techniques qui permettent la vérification de l‟aspect fonctionnel des composantes
logicielles (i.e., des langages formels, des méthodes formelles,…). Mais, pour leurs aspect
temporel, des analyses de codes générés sur des exécutifs réels sont souvent longues et
coûteuses (humaines et matérielles). Donc, la lacune de l‟interaction entre le matériel et le
logiciel dans l‟approche traditionnelle peut causer des influences imprévues sur le temps acquis
pour le développement d‟un système au point de la livraison («time-to-market»).
56
Malgré ces inconvénients, l‟approche traditionnelle est encore très utilisée pour les applications
embarquées.
4.3.2. L’approche de développement «Logiciel/Matériel» en Co-design
«Matériel/Logiciel» en co-design signifie la rencontre des objectifs au niveau du système en
exploitant la synergie de matériel et de logiciel par leur conception concurrente. Contrairement
à l‟approche traditionnelle, l‟approche de développement «Matériel/Logiciel» en Co-design se
concentre sur la combinaison des perspectives de matériel et de logiciel dès les premières
phases de développement. Alors, un développement va commencer avec une notation abstraite
telle que chaque composante ou module est indépendant(e) de sa réalisation finale en matérielle
ou en logicielle. Puis, la séparation des composantes matérielles/logicielles peut être effectuée
de manière la plus appropriée. L‟intégration «Matériel/Logiciel» est ensuite complétée par un
ensemble des instructions permettant des tests et des co-simulations. Un modèle typique de
développement en Co-design est présenté sur la Figure 9i ci-dessous.
Figure IV.2.i. : Modèle de développement « Matériel Logiciel en co-design
L‟approche de développement en Co-design est une approche encore récente pour les systèmes
temps réel. Cette approche est bien adaptée à des applications dont la spécification peut
changer continuellement et dont le «Time-to-market» affecte fortement le succès (i.e., systèmes
de communication, électroménager,…). L‟approche de développement en Co-design se base
sur la communication synchrone dirigée par les événements. Dans cette approche, la
description fonctionnelle du système est exprimée sous la forme de graphes orientés, appelés
des CFSMs (Machines à états finis en Co-design ou Co-design Finite State Machine en
anglais). Un CFSM interprète un ensemble d‟entrées en un ensemble de sorties avec un nombre
fini d„états internes. Mais, contrairement à un FSM traditionnel, un CFSM ne change pas tous
ses états exactement en même temps. La communication entre des CFSMs est réalisée par des
événements unidirectionnels, non zéro et sans bornes de temps (asynchrone globalement). Il
existe aussi des traductions qui permettent de convertir des spécifications en provenance d‟un
57
langage synchrone (i.e., ESTEREL, SIGNAL, HardwareC,…) en des CFSMs. Les CFSMs sont
supposés indépendant des choix matériels ou logiciels. Cela permet un choix libre de
l‟implémentation dans l‟étape de «Matériel/Logiciel Partition», tel que l‟on transforme des
CFSMs en un format de description du matériel dans lequel chaque transition est implémentée
par un circuit combinatoire verrouillant ses sorties afin d‟assurer leurs non zéro retard de
réaction; ou bien que l‟on transforme des CFSMs en une structure de logiciel qui comporte des
procédures et un système d‟exploitation simple exprimés sous la forme d‟un sgraphe (une
forme réduite de graphe flot de contrôle contenant les noeuds, nommés «Begin», «End»,
«Call», «Test», Assign»). Un s-graphe peut être interprété en des codes pour être exécutables
par un microprocesseur. Des interfaces entre des composantes matérielles et des composantes
logicielles sont générées automatiquement grâce à des techniques de mémoire partagée (pour
des communications dans lesquelles l‟événement émis par le logiciel est consommé par le
matériel), de «scrutation» ou d‟«interruption», de communication directe entre des matériels ou
des logiciels par «bus» ou «drapeau» respectivement. Cela permet de faciliter la vérification de
l‟intégration des matériels/logiciels et la validation dans les étapes suivantes. Les co-
simulations s‟exécutent sur des matériels simulés (i.e., des ASICs, Application Specific
Integrated Circuit), ce qui permet de réduire le coût de production et d‟augmenter la fiabilité,
mais d‟élever également le coût et le temps de développement. Par ailleurs, l‟implémentation
des logiciels possède un temps de réponse pouvant être plus grand que celui des matériels.
Notamment, si le logiciel est basé sur un système d‟exploitation avec le mécanisme de
préemption, le temps de réaction d‟un logiciel ne peut être représenté exactement par un
modèle basé sur une hypothèse synchrone.
De nos jours, avec des outils de conception assistés par ordinateur (CAO), l‟introduction du
FPGA (Field-Programmable Gate Array), et des HDLs (Hardware Description Language), le
développement «Matériel/Logiciel» en Co-design devient un vaste domaine de recherche et une
clé de technologie pour des systèmes numériques pour le COSYMA (COSYnthesis for
eMbedded micro Achitectures), pour le Ptolemy, pour le POLIS, etc.
Bien que ces méthodes soient bien adaptées pour le développement d‟applications très
intégrées, il nécessite de la part du concepteur une maîtrise globale du système. Or il est assez
classique, notamment dans le monde automobile, et afin de réduire le coût et le «time-to-
market», d‟avoir un choix de matériels précis (1 ou 2 microcontrôleurs au choix, récupérant des
informations sur un réseau de terrain). Dans ce cas, les développements matériels peuvent se
réduire à la mise sur circuits de certaines fonctions ne pouvant être exécutées de façon
logicielle pour des problèmes de puissance de calcul. Dans ce cas, une approche traditionnelle
pourra réduire le temps de développement. Il convient cependant que l‟impact du matériel sur
le logiciel soit bien connu. De plus, il convient de pouvoir tester le logiciel indépendamment du
matériel. Dans ce cas, il est fréquent d‟appliquer un cycle de développement en «W».
4.3.3. Le cycle de développement en «W» dans l’approche traditionnelle
Le modèle en «W» (voir Figure IV.2.j) est une extension du modèle en «V». Dans ce modèle,
le premier V correspond au cycle de vie en «V» classique sur simulateur logiciel (à
développer), le deuxième V étend le premier pour prendre en considération les propriétés du
matériel dans le développement d‟un logiciel.
58
Figure IV.2.j. : Modèle en W

La conception adaptée: consiste à prendre en compte les modifications dues à la prise en
compte du matériel (i.e., initialisation, alimentation, etc.).
Le codage croisé: consiste à adapter le code exécutif spécifique, pilotes de périphérique des
composants logiciels conformes à une cible implémentée (i.e., norme POSIX, VxWorks,
OSEK/VDX, etc.).
La validation sur cible: vérifie l‟intégration de matériel/logiciel pour voir si tout s‟exécute
bien sur la cible.
La validation temporelle: vérifie l‟ordonnancement du modèle des tâches implémentées sur la
cible.
Le modèle en «W» permet une flexibilité du choix du matériel par rapport au modèle en «V»
classique. En facilitant des modifications de l‟architecture logicielle lorsqu‟il y a des
changements de l‟architecture matérielle, la lacune de l‟interaction entre le logiciel et le
matériel dans l‟approche traditionnelle peut être résolue. Par conséquent, on peut diviser
l‟architecture logicielle en deux parties, donc une part indépendante du matériel et une part
étant spécifique à une cible réelle. A partir de la conception préliminaire, on prend la première
part (le premier V) pour développer le logiciel en des composantes «pures». Ce sont des tâches,
des modules, des outils de communication ou synchronisation, des tests et des simulations
vérifiant son aspect fonctionnel. Puis dans la part suivante (le deuxième V), en associant des
informations en provenance de l‟architecture matérielle, on peut générer des codes des
composantes logicielles qui s‟adaptent bien à une cible. Cela nous permet de tester l‟intégration
matériel/logiciel et la validation temporelle. Alors, un changement de l‟architecture matérielle
n‟entraîne que des modifications sur la deuxième partie de l‟architecture logicielle.
59
Figure IV.2.k : Modèle en W dans l‟approche traditionnelle

Dans la suite, le cycle de vie en «W» sera utilisé comme un modèle de développement dans
lequel les différentes étapes sont échelonnées et les différentes méthodes sont employées pour
produire des logiciels de qualité en respectant les contraintes de temps et de coût.
4.3.4. «Time-to-market»,
Un point clé à succès «Time-to-market» est le temps séparant la mise en conception d‟un
produit à sa mise sur le marché. De nos jours, avec le développement très rapide de la
technologie, ou bien l‟augmentation de demandes de la part des utilisateurs, le «Time-to-
market» devient un critère de plus en plus important de réussite d‟un produit, notamment dans
les domaines de haute technologie, ou dans les domaines où leur environnement et leurs
matériels d‟input changent rapidement. Si une chaîne de fabrication d‟un produit ou un cycle de
développement d‟un logiciel nécessite plus de temps pour la mise en oeuvre ou la mise à jour,
ce produit/logiciel peut être démodé à cause des nouvelles demandes en provenance des
utilisateurs, ou à cause d‟un ou de plusieurs concurrents.
Figure IV.2.l : « Time-to-market » et modèle en W dans l‟approche traditionnelle

Pour les systèmes temps réel, le choix d‟un cycle de développement adéquat influence
considérablement le «Time-to-market». Ainsi, si l‟on compare le cycle de développement
Matériel/Logiciel traditionnel avec le modèle de développement de logiciel en «W», une
modification dans la partie matérielle peut être mise à jour aisément par la partie logicielle
60
correspondante grâce à des phases dans le deuxième V du cycle de développement en W (au

lieu de toutes les phases de ce cycle). En conséquence, le «Time-to-market» pour la mise à jour
d‟un produit à cause de cette modification se voit réduit. Autrement dit, ce cycle de
développement peut s‟adapter aux changements des composants matériels. En fait, il est
difficile de dire quel est le meilleur cycle de vie pour le «Time-to-market», car il faut relier cela
aux domaines d‟applications, ou bien aux caractéristiques spécifiques de chaque cycle. Donc, le
choix d‟un cycle de vie convenable pour le développement d‟un système devient une «tâche»
vitale, il est souvent choisi en fonction des expériences de concepteur.
4.4. Gestion du temps
Le temps informatique est compté par des horloges. Il existe deux types d‟horloges: le premier
type d‟horloge est le plus simple qui dépend de l‟alimentation électrique et génère une
interruption à chaque période de la tension dont la fréquence est souvent de 50 Hz ou 60 Hz (il
s‟agit d‟une horloge de faible résolution de l‟ordre de la milliseconde. La plupart des systèmes
d‟exploitation généralistes sont munies de ce type de l‟horloge); le deuxième type d‟horloge est
plus complexe et peut générer un signal périodique dont la fréquence correspond à la fréquence
d‟activation de l‟ordonnanceur et peut être maitrisée par un logiciel (il s‟agit des horloges
programmables de haute résolution de l‟ordre de la micro seconde que les exécutifs temps réel
utilisent).
En pratique, les systèmes d‟exploitation temps réel utilisent un ou plusieurs circuits
programmables spécialisés dans la gestion du temps. Ces circuits peuvent être programmés de
sorte à:
- déclencher périodiquement une interruption, ce type de programmation est utilisé
typiquement pour déclencher périodiquement l‟ordonnanceur,
- déclencher une interruption à une certaine date, ce type de programmation permet
typiquement à une tâche de se réveiller périodiquement, avec une résolution temporelle
importante (période),
- déclencher une interruption au bout d‟un certain temps, ce type de programmation permet
typiquement à une tâche de s‟endormir pendant un certain temps, ou bien de surveiller la
durée d‟un traitement par «chien de garde». Il est associé normalement à une ou plusieurs
actions, qui sont lancées immédiatement au cas où le traitement ou l‟attente prendrait un temps
plus élevé que prévu.
Pour terminer cette section, nous parlons des modèles de la gestion du temps sur lesquels les
exécutifs ou les systèmes d‟exploitation temps réel sont actuellement basés. Il est l‟un des deux
modèles suivants:
- Noyau dirigé par le temps: seule la notion de «tick» est utilisée pour gérer le temps. Donc, le
noyau prend à main à chaque «tick», et les tâches ou les processus ne peuvent être réveillés
que sur des «ticks».
- Noyau dirigé par les événements: les horloges programmables sont utilisées à leur
granularité pour réveiller une tâche ou un processus. Ce modèle permet non seulement
d‟obtenir le fonctionnement similaire au modèle dirigé par le temps, mais aussi d‟atteindre
61
une résolution d‟horloge de l‟ordre de la micro seconde avec un surcoût processeur moindre
par rapport au modèle dirigé par le temps.
4.5. Principales normes temps réel
4.5. a. La norme POSIX
POSIX (Portable Operating System Interface) est le nom d‟une famille des standards définie
depuis 1988 par l‟IEEE et formellement désignée P1003. Le but au début de cette norme est de
normaliser l‟accès aux services offerts à différents niveaux par les systèmes d‟exploitation
UNIX.
De nos jours, beaucoup de systèmes d‟exploitation, d‟exécutifs temps réel ou de noyaux temps
réel se disent conformes à la norme POSIX. Dans les paragraphes suivants, nous parlons de
quelques éléments sur les normes POSIX orientées temps réel.
IPC (Interprocess Communication): proposé dans l‟amendement POSIX 1003.1b (1993)
corrigée par le 1003.1i en 1995, regroupe les trois outils définis pour la communication entre
processus, ce sont la boîte aux lettres, le sémaphore et le tableau noir.
Les boîtes aux lettres sont dites «boîtes aux lettres nommées», car chaque boîte est identifiée
par un nom unique dès la création de cette boîte. La manipulation d‟une boîte aux lettres
nommée se fait à l‟aide de fonctions dont le nom est préfixé par «mq_» pour message queue,
par exemple «mq_open» crée une nouvelle boîte ou bien ouvre une boîte aux lettres existante;
«mq_send» et «mq_receive» servent respectivement à envoyer et à attendre des messages d‟une
boîte aux lettres, etc. Il est important de noter qu‟une boîte aux lettres nommée est une boîte
aux lettres bornée sans écrasement, avec possibilité d‟affecter une priorité aux messages.
Les sémaphores dits «sémaphores nommés» sont des sémaphores à compte. La manipulation
d‟un sémaphore se fait à travers des fonctions dont le nom est préfixé par «sem_», par exemple
«sem_open» crée ou ouvre un sémaphore; «sem_wait» prend un sémaphore; «sem_post» libère
un sémaphore, etc. Aucun protocole de gestion de ressource n‟est disponible pour les
sémaphores nommés.
Les tableaux noirs dits «shared memories», sont les zones des mémoires spécifiques partagées,
car la mémoire de chaque processus est protégée. En utilisant la fonction «shm_open» nous
pouvons créer ou ouvrir une zone de mémoire partagée. Après avoir ouvert/créé, on peut
calquer cette zone de mémoire partagée sur une variable d‟un processus avec la fonction
«mmap». Notons que tout accès à la variable « mappée » est alors un accès à la zone de
mémoire partagée, et non pas l‟accès à une variable interne au processus. Ce mécanisme se
couple généralement à un sémaphore pour garantir l‟exclusion mutuelle.
Pour les boîtes aux lettres nommées et les sémaphores nommés, l‟amendement 1003.1j ajoute
la possibilité de borner des attentes lors des envois ou réceptions de messages, ou des demandes
de sémaphores. Par conséquent, dans ce cas, si le délai ou bien la date maximale est dépassé, la
primitive bloquante se termine en renvoyant un code d‟erreur.
- Tâches POSIX: définies dans l‟amendement POSIX.1c. Des tâches POSIX appartenant à un
processus partagent le même espace mémoire global, et se distinguent par une pile différente,
ainsi que des attributs particuliers (priorité, type d‟ordonnancement…).
62
Une tâche POSIX est créée par la fonction «pthread_create». Cette fonction comporte des
arguments principaux suivants: des attributs de tâche, un pointeur de fonction (cette fonction
est le code de la tâche), et un pointeur pouvant contenir le ou les arguments à passer à la
fonction.
Une tâche POSIX peut être exécutée en mode «détaché» ou «attaché». Donc, en mode
«attaché», chaque tâche s‟exécute de façon synchrone (join) avec son créateur, dans ce cas, le
créateur de la tâche attend la terminaison de celle-ci avant de continuer son exécution. Au
contraire, en mode «détaché», les tâches peuvent s‟exécuter de façon indépendante de leur
créateur (« detach state »). Il en résulte que si les tâches sont créées par la procédure principale
d‟un processus, afin d‟éviter la terminaison prématurée du processus avant la terminaison des
tâches, on pourra attacher ces tâches à la procédure principale du processus.
- Synchronisation et communication des tâches: définies aussi dans l‟amendement 1003.1c,
ce sont des outils de communication et de synchronisation entre des tâches POSIX.
Sémaphores binaires (ou mutex) : sont dédiés à l‟exclusion mutuelle. Les attributs d‟un
«mutex» permettent de choisir le protocole de gestion de ressource associé au «mutex» (soit
priorité plafond immédiate, soit priorité héritée). Les tâches en attente d‟un sémaphore sont
gérées par les files d‟attente FIFO à priorités.
Sémaphores en lecture/écriture (ou rwlocks) comportent pour chacun les deux sémaphores,
nommés «rdlock» et «wrlock», donc la fonction «pthread_rwlock_rdlock» permet de requérir le
sémaphore en lecture, alors que «pthread_rwlock_wrlock» requiert le sémaphore en écriture.
Aucun protocole de gestion de ressources n‟est défini sur les sémaphores en lecture/écriture.
Variable conditionnelle (ou pthread_cond) peuvent être utilisées conjointement avec des
«mutex» pour synchroniser des tâches. La fonction «pthread_cond_init» crée une variable
conditionnelle. Au cas où plusieurs tâches sont bloquées simultanément sur la même variable
conditionnelle, un appel à l‟équivalent de «signal(pthread_cond_signal)» ne réveille qu‟une
seule tâche bloquée sur la variable conditionnelle. Donc, on peut utiliser la fonction
«pthread_cond_broadcast» pour réveiller toutes les tâches bloquées sur une variable
conditionnelle.
Notons qu‟il est possible d‟effectuer des attentes bornées sur les instructions bloquantes des
objets de synchronisation et de communication (soit en durée, soit jusqu‟à une certaine date).
- Horloges: il existe deux types d‟horloge, appelés respectivement «CLOCK_REALTIME» et
«CLOCK_MONOTONIC». «CLOCK_REALTIME» représente le temps écoulé depuis le 1 er
Janvier 1970 à 00 h 00. Cette horloge permet de donner une date absolue à un «timer». Elle a
une résolution au pire de 20 ms, mais en fonction de l‟architecture matérielle sous-jacente, on
peut attendre une résolution de l‟ordre de la micro seconde ou de la dizaine de micro secondes.
«CLOCK_MONOTONIC» (cette horloge est optionnelle dans les implémentations) a une
propriété de monotonie: elle est modifiée par l‟horloge physique, mais ne peut pas être
modifiée par le programme. Elle permet de donner un délai Deux autres horloges peuvent
optionnellement exister: «CLOCK_CPU_TIME», donnant le temps processeur consacré à un
processus, et «CLOCK_THREAD_CPU_TIME_ID», donnant le temps processeur consacré à
une tâche.
63
POSIX définit les exécutifs comme étant dirigés par les événements.
4.5.b. La norme OSEK/VDX
OSEK est l‟acronyme de «Offene Systeme und deren Schnittstellen für die Elektronik im
Krafttfahrzeug», en français Systèmes ouverts et interfaces correspondantes pour l‟électronique
des véhicules automobiles. La norme OSEK/VDX est née en 1995 de la fusion d‟un consortium
de constructeurs d‟automobiles allemands et d‟un consortium de constructeurs d‟automobiles
français (VDX est l‟acronyme de «Vehicle Distributed eXecutive»). Bien qu‟initialement
conçue pour le domaine automobile, cette norme est très bien adaptée aux applications de
contrôle- ommande.
Contrairement à POSIX où tout est dynamiquement créé, la plupart des objets OSEK/VDX sont
définis de façon statique à l‟élaboration de l‟exécutif et de l‟application: tous les services
utilisés (tâches, objets de communication et de synchronisation, etc.) sont définis de façon
statique dans le langage OIL (OSEK Implementation Language). Cela entraîne une faible
empreinte mémoire, notamment des avantages indéniables en ce qui concernent les techniques
de validation. - Les tâches: Une tâche est une portion de code séquentiel. OSEK/VDX
distingue deux types de tâches, les tâches basiques et les tâches étendues.
Les tâches basiques ne peuvent pas se bloquer en attente d‟événement, de messages, de
ressource… en cours d‟exécution. Elles ne possèdent pas d‟état «en attente». Elle peut prendre
trois états différents : «passive», «prête» et «élue». Etant donné qu‟une tâche basique ne peut
être préemptée que par une tâche plus prioritaire qui se terminera forcément avant elle, il est
assez fréquent que dans l‟implémentation du système, toutes les tâches basiques soient
exécutées en utilisant une seule pile.
Les tâches étendues ont les mêmes caractéristiques que les tâches basiques avec en plus la
possibilité de se bloquer durant leur exécution. Typiquement, une tâche étendue se bloque en
attendant une synchronisation ou une ressource. Par conséquent, les tâches étendues peuvent
prendre quatre états différents, donc les trois mêmes états que les tâches basiques avec l‟état
«en attente» additionnel.
Comme dans la norme POSIX, une tâche OSEK/VDX est définie par une fonction.
Cependant, contrairement à celle-ci, elle est créée de façon statique, il n‟y a pas d‟état
«inexistante». L‟initialisation, quant à elle, est effectuée automatiquement au démarrage de
l‟exécutif.
- Synchronisation et communication des tâches:
Exclusion mutuelle : assurée par la définition de ressources (de façon statique dans le langage
OIL). OSEK/VDX fournit deux primitives, «GetResource» et «ReleaseResource» pour prendre
et vendre une ressource. Tenter de prendre une ressource non disponible a pour effet de placer
une tâche (forcément une tâche étendue) dans l‟état «en attente». Notons que chaque ressource
est gérée avec le protocole à priorité plafond immédiat afin d‟éviter l‟inversion de priorité, avec
un mécanisme pour borner la durée de blocage d‟une tâche en attente d‟une ressource.
Synchronisation par événements : synchronisations binaires de type n/1: chaque tâche étendue
est liée à un certain nombre d‟événements, qu‟elle seule peut attendre. OSEK/VDX propose
une primitive de déclenchement d‟événement («SetEvent»), une primitive d‟attente
d‟événement («WaitEvent»), et une primitive d‟effacement d‟événement («ClearEvent»). Seule
la tâche propriétaire d‟un événement a le droit de l‟attendre et de l‟effacer.
Communication par message : de type communication n/m (n émettrices, m réceptrices
possibles pour un message). Dans le cas d‟une communication de type boîte aux lettres, si un
64
message a m réceptrices, il est déposé dans chacune des files d‟attente de messages de
réceptrice de ce message, et il est consommé par chaque réceptrice de façon indépendante des
autres réceptrices. Dans le cas d‟une communication de type tableau noir, la lecture est non
bloquante et non destructive, et le message lu est le message le plus récemment écrit. Des
messages vides peuvent être transmis, dans ce cas-là, ils servent de synchronisation entre
tâches. En conséquence, l‟exécutif fournit trois primitives d‟envoi d‟un message:
«SendMessage» pour l‟envoi d‟un message de taille fixe; «SendDynamic-Message» pour
l‟envoi d‟un message de taille dynamique; et «SendZeroMessage» pour l‟envoi d‟un message
vide. OSEK/VDX permet de définir des messages périodiques, qui seront automatiquement
envoyés à chaque période.
Chaque message peut être muni d‟une échéance: si le message n‟est pas reçu dans le délai
imparti, une notification de violation d‟échéance est envoyée.
Horloges: de même que la norme POSIX, OSEK/VDX impose la présence d‟au moins une
horloge, mais en fonction de l‟architecture sous-jacente, plusieurs horloges peuvent être
disponibles. La gestion des horloges dans la norme OSEK/VDX est similaire à la norme
POSIX. Les «timers» sont définis de façon statique dans le fichier OIL. Il est important de
noter qu‟OSEK/VDX est un exécutif dirigé par les événements.
4.5.c. La norme Ada
Le langage Ada lui-même est une norme, supportant différentes implémentations. Les
implémentations de la norme Ada reposent sur un exécutif ou noyau, pouvant être lui-même
conforme à POSIX ou encore OSEK.
- Les tâches Ada: une tâche Ada est déclarée en deux parties: une spécification de tâche («task»),
et un corps de tâche («task body»). Une tâche peut être instanciée de façon globale ou
dynamiquement.
Lorsqu‟elle est instanciée de façon globale (en tant que variable de paquetage par exemple),
cette tâche est lancée automatiquement au démarrage du programme principal. Alors que
lorsqu‟elle est instanciée dynamiquement (une instance d‟un type tâche, ou allouée
dynamiquement par «new»), elle est lancée au moment de l‟instanciation. Les tâches Ada sont
toujours attachées automatiquement au programme principal (i.e. le programme principal ne se
termine pas tant qu‟il y a au moins une tâche encore vivante).
Communication et synchronisation: depuis Ada95, le moniteur de haut niveau (objet protégé)
est introduit. Le moniteur Ada permet d‟implémenter tout type de synchronisation et de
communication, synchrone et asynchrone. La spécification d‟un objet protégé comporte un
ensemble de primitives et une partie privée, correspondant aux variables internes du moniteur.
Il y a trois types de types de primitives:
Les procédures («procedure») sont des primitives non réentrantes par rapport aux autres
primitives de l‟objet protégé (i.e., une procédure ne peut pas avoir lieu tant qu‟une autre
primitive de l‟objet protégé est exécutée, et empèche toute autre primitive de s‟exécuter).
Elles sont non bloquantes au sens de l‟objet protégé auquel elles appartiennent, c‟est-à-dire
qu‟elles n‟intègrent pas la possibilité d‟attendre que le moniteur soit dans un certain état. Les
procédures peuvent avoir les paramètres en entrée et/ou en sortie.
Les procédures gardées («entry») sont des procédures dont l‟accès est conditionné (gardé).
65
Une barrière se trouve au début de chaque primitive. Si la barrière d‟une procédure gardée n‟est
pas satisfaite lors d‟un appel de cette procédure, la tâche appelante est bloquée jusqu‟à ce que
cette condition de réveil soit vraie.
Les fonctions («function») sont des primitives en lecture seule sur l‟objet protégé. Elles sont
réentrantes les unes par rapport aux autres. Cela permet d‟affiner les accès aux objets protégés
en leur donnant des primitives de type lecteur/écrivain.
La norme Ada propose le protocole à priorité plafond immédiat pour éviter l‟inversion de
priorité lors d‟accès concurrents à un objet protégé.
- Le profil Ravenscar: pour le langage Ada, une norme de développement a été proposée, sous le
nom de profil Ravenscar, normalisé par l‟ISO en 1999. La norme préconise les principes
suivants:
- pas de déclaration de tâches dynamiques: tout est déclaré au début de l‟application,
- les tâches ne se terminent pas ou alors toutes ensemble,
- toutes les tâches sont au même niveau (pas de hiérarchie mère/fille entre les tâches),
- tous les outils de communication et de synchronisation sont déclarés initialement, et pas de
façon dynamique,
- utilisation de dates et pas de durées pour les réveils de tâches périodiques, afin d‟éviter une
dérive des horloges,
- utilisation d‟un protocole de gestion de ressources à priorité plafond,
- pas d‟utilisation du rendez-vous mais uniquement des objets protégés, avec une seule primitive
de type «entry» par objet protégé, les autres pouvant être des procédures ou bien des fonctions,
- un et un seul mécanisme de déclenchement pour une tâche (attente de synchronisation, de
message ou d‟interruption, ou bien attente périodique).
4.6. Méthodes de développement d’un logiciel
Les méthodes: elles définissent le comment, c‟est-à-dire ce qu‟il faut faire pour produire un
logiciel. Chaque méthode a besoin d‟un langage pour la production d‟une spécification, et donc
à chaque méthode est attaché un langage propre.
Les outils: ils constituent le support pour les méthodes.
Les systèmes temps réel doivent produire des résultats corrects dans des intervalles de temps
spécifiés.
Si un résultat est incorrect ou arrive trop tard, un tel système est voué à l‟échec. Kopetz et al.
dans [Kop91] ont élaborées des caractéristiques principales pour une méthode de
développement d‟un système temps réel, ce sont:
Prévisibilité: la possibilité d‟une méthode de prévoir la performance de l‟architecture
matérielle, notamment l‟analyse de temps, pour assurer le respect des contraintes temporelles.
Testabilité: la possibilité d‟une méthode de vérifier l‟opération dynamique d‟un système selon
ses paramètres d‟entrée. Il s‟agit d‟indiquer à quelle fraction des scénarios du système réel
peuvent être couverts par des scénarios de test correspondant; de déterminer si le système sous
66
des tests s‟exécute correctement (par exemple, l‟ordre et le temps des événements,
l‟observation des actions et des sorties du système pendant le test, …); de contrôler l‟exécution
du système afin d‟assurer le déterminisme de réactions si le contexte d‟un scénario est changé.
Tolérance aux pannes: permet de réaliser la fiabilité requise d‟un service. Foncièrement, il
existe deux types d„applications temps réel: l‟un de «défaillance-arrêt» et l‟autre de
«défaillance-opérationnelle». Avec le deuxième, le système doit assurer une continuation de
l‟application dans toutes les situations opérationnelles, même s‟il y a des erreurs ou des
défaillances.
Conception de système: la possibilité d‟une méthode de pourvoir des mécanismes qui
permettent les développements simultanés de matériel et de logiciel de manière succincte et
consistante.
Décomposition systématique: une possibilité de faire décomposer graduellement un système
en des composantes qui sont faciles à comprendre et peuvent être traitées relativement
indépendamment.
Evaluabilité: avant le test l‟évaluation sur un exécutif temps réel, il est désirable d‟évaluer la
conception du système considéré. Cette caractéristique permet au concepteur de commencer
une telle évaluation le plus tôt possible dans un cycle de développement d‟un logiciel afin
d‟éviter une révision coûteuse dans la phase de test.
Il existe plusieurs méthodes pour le développement d‟un logiciel, parmi elles on peut distinguer
deux types: les méthodes se basant sur des descriptions mathématiques formelles du sens d‟un
programme donné par un langage de programmation informatique de haut niveau permettant
d‟obtenir un programme pour un ordinateur (il s‟agit des «méthode formelles»); et les
méthodes se basant sur des descriptions semi-formelles du sens des conceptions fonctionnelles
données par des diagrammes, des notations graphiques maîtrisés par les clients, et facilitant les
échanges entre clients et concepteurs.
Les méthodes formelles permettent d‟obtenir une très forte assurance de l‟absence de «bogue»
dans les logiciels. Cependant, elles sont des méthodes «constructives» et «universelles»
[Jack98]. Donc elles sont généralement coûteuses en ressources (humaines et matérielles) et
actuellement réservées aux logiciels les plus critiques.
Pour les approches semi-formelles, Shaw les a classifiées en quatre groupes principaux selon le
style de l‟architecture utilisé: l’Architecture orientée objet (focalise la décomposition d‟un
système en des objets distincts, en encapsulant leurs états et leurs opérations.
Les objets interagissent par invocation des opérations des autres); l’Architecture état-transition
(se concentre sur des états d‟un système et sur des événements qui provoquent des transitions
entre ces états); l’Architecture asservissement (une forme spéciale de diagramme de flot de
données adaptée pour des systèmes embarqués où le procédé doit s‟adapter régulièrement afin
de compenser des perturbations en provenance de l‟extérieur); et l’Architecture temps réel (se
concentre sur des système temps réel dans lesquels le respect des contraintes de temps doit être
satisfait). Les descriptions semiformelles offrent des mécanismes de structuration et de
décomposition très riches tout en proposant une représentation intuitive et synthétique du
système à construire. Mais, il n‟existe pas d‟outils associés permettant d‟analyser, de vérifier ou
de simuler, de valider de telles spécifications.
67
Effectivement, aucune des méthodes existantes ne qualifie tous les aspects présentés au-dessus.
En s‟apercevant que chaque méthode possède certaines caractéristiques spécifiques pour
certaine domaine d‟application, s‟il existe une méthode qui peut regrouper les caractéristiques
de chacune des méthodes existantes, la nouvelle méthode peut être qualifiée d‟un nombre
maximal des critères, et surtout ce principe peut s‟appliquer à chercher une méthode
convenable pour tous les domaines de problème ou tous les environnements de développement
à des développeurs. Saeki a proposé un modèle pour construire une telle méthode, nommée
«l‟ingénierie des méthodes» (voir Figure IV.2.m). L‟idée principale de ce modèle est la
suivante: en se basant sur la «réutilisation» des «méthodes fragmentaires», appelées «méthode
de base», les développeurs récupèrent les méthodes fragmentaires convenables d‟abord, puis
les adaptent, et les s‟intègrent à la nouvelle méthode.
Figure IV.2.m : L‟ingénierie des méthodes

En effet, on peut voir la méthode OMT de Rumbaugh (Object Modeling Technique) comme
l‟intégration de quatre fragments: le Diagramme de Classe, le Diagramme de Séquence, le
Diagramme des états-transitions, et le Diagramme flots de données. SA-RT (Structured
Analysis For Real-Time Systems) est une méthode de spécification des systèmes temps réel
construite par incorporer les diagrammes états-transitions dans les diagrammes flots de données
de la méthode SA (Structured Analysis) afin d‟exprimer l‟aspect dynamique du système. En
outre, le développeur peut construire un diagramme de classes, et puis raffiner les détails en
utilisant une technique formelle telle que le langage B.
Les difficultés dans l‟emploi de cette approche résultent de la complexité des concepts que les
méthodes possèdent. Il en résulte que la consistance de l‟intégration des méthodes doit être
vérifiée.
L‟idée de l‟intégration de plusieurs méthodes dans une seule méthode n‟est pas nouvelle, mais
pour répondre à la question "Est-ce que la nouvelle méthode est la meilleure, permettant à la
fois de satisfaire un nombre maximal de critères, et d‟obtenir le «Time-to-market» le plus court
?". Les travaux présentés dans ce manuscrit ne cernent que cet objectif. En se focalisant sur
l‟approche semiformelle, dans les paragraphes suivants, quelques méthodes semi-formelles
pour le développement de systèmes temps réel sont présentées. Puis en s‟inspirant de l‟idée
d‟ingénierie des méthodes de Saeki, une nouvelle approche, appelée DARTSVIEW, est créée
pour tenter de résoudre les problèmes énoncés en-dessus. Nous utilisons le «Système de
chauffage d‟une maison» comme un exemple typique pour comparer les avantages et les
inconvénients des méthodes semi- ormelles, ainsi que des modifications nécessaires de
méthodes elles-mêmes afin d‟être mieux adaptées aux systèmes temps réel.
68
Chapitre V : Le développement des systèmes temps réel et embarqués

5.1 Introduction
5.1.1 Définitions
La plupart des systèmes embarqués temps réel sont avant tout des systèmes de contrôle-
commande. Un système de contrôle-commande est un système informatique de contrôle de
procédé. Le terme procédé est un terme générique désignant un système physique contrôlé.
Afin de contrôler le procédé, le système informatique est en relation avec l‟environnement
physique externe par l‟intermédiaire de capteurs et/ou d‟actionneurs. Les grandeurs physiques
acquises grâce aux capteurs permettent au système de contrôle commande de s‟informer de
l‟état du procédé ou de son environnement. Le système de contrôle-commande, à partir de
consignes décrivant l‟état voulu du procédé, calcule des commandes qui sont alors appliquées
sur le procédé par l‟intermédiaire d‟actionneurs. Donnons ainsi une définition générale d‟un
système de contrôle commande (figure V.1) :
« Un système de contrôle-commande 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 voulu ».
Figure V.1 : Représentation schématique d‟un système de contrôle commande.

Exemple 1 : la figure V.1 représente un exemple de système de contrôle-commande pour un
drone. Un drone est un aéronef autonome, ou semi-autonome. L‟un des buts principaux du
système de contrôle-commande est de contrôler l‟attitude (tangage, roulis) et la vitesse du
drone : cela s‟appelle la commande de vol. Le système de contrôle-commande est exécuté par
un calculateur qu‟on appelle microcontrôleur.
Les capteurs utilisés sont une centrale inertielle, permettant de connaître les angles de tangage
et roulis du drone, et un récepteur GPS (Global Positionning System) permettant notamment de
connaître la position absolue (latitude, longitude), la vitesse par rapport au repère sol et la
vitesse ascensionnelle. Un modem sans fil permet au drone de recevoir des consignes de la part
d‟un opérateur (par exemple un angle de roulis, une vitesse et une vitesse ascensionnelle), et de
lui envoyer des informations sur le vol. À la fois capteur (lit des informations en provenance de
l‟opérateur) et actionneur (permet l‟affichage ou l‟enregistrement d‟informations pour
l‟opérateur), ce modem est qualifié d‟organe de dialogue. Enfin, trois actionneurs permettent de
commander respectivement la puissance du moteur et la position des deux ailevons. Le
différentiel des ailevons (l‟un plus haut, l‟autre plus bas), permet de donner une vitesse
angulaire sur l‟axe de roulis de l‟aéronef, alors que leur position parallèle par rapport à l‟angle
69
d‟équilibre permet d‟appliquer une vitesse angulaire sur l‟axe de tangage. La vitesse
ascensionnelle dépend de la puissance du moteur et des angles de tangage et roulis.
Figure V.2: Système de contrôle-commande embarqué sur un mini-drone.

Un système embarqué est un système informatique dont les moyens de calcul sont embarqués
sur le procédé contrôlé. Le fait d‟embarquer les moyens de calcul implique, en plus des
contraintes d‟encombrement (taille, poids, forme), des contraintes de consommation d‟énergie
puisque l‟alimentation électrique des éléments de calcul est soit embarquée (batteries,
carburant, etc.), soit ambiante (panneaux solaires, etc.).
À technologie équivalente, l‟énergie consommée par un calculateur est fonction du carré de la
vitesse de celui-ci ; en d‟autres termes, plus le calculateur est performant, plus l‟énergie
consommée est importante, avec une relation quadratique. Un système embarqué se caractérise
donc souvent par des ressources de calcul dimensionnées (ou à dimensionner) au plus juste en
fonction des besoins en calcul.
La notion « suffisamment vite » est relative à la dynamique du procédé contrôlé. Par exemple,
le drone de la figure précédente, est considéré comme un système temps réel. De par sa forme
d‟aile delta, il est très instable en roulis ; par conséquent, il est important que la commande de
vol se rafraîchisse fréquemment, par exemple toutes les 20 millisecondes. Si le drone avait une
forme de planeur, plus stable, une fréquence de rafraîchissement plus faible (de l‟ordre de 10
Hz, soit 100 millisecondes) pourrait peut-être suffire à assurer une commande de vol
acceptable.
Un système critique est un système informatique pour lequel une défaillance, totale ou partielle,
du système, peut entraîner des conséquences graves, par exemple économiques, humaines,
écologiques, etc. La défaillance d‟un drone d‟observation entraîne des conséquences
économiques (perte de l‟engin) mais surtout peut entraîner des conséquences humaines en cas
de collision, moteur allumé, avec une personne. Un drone est donc considéré comme un
système critique lorsqu‟il évolue dans une zone habitée. Un système est temps réel critique si
une défaillance temporelle (le système ne réagit pas suffisamment vite par rapport à la
dynamique du procédé) peut aussi entraîner des conséquences graves. Le drone peut être
70
considéré comme temps réel critique, puisque le fait de ne pas être capable d‟appliquer les
commandes de vol à temps peut aboutir à une perte de contrôle. La plupart des systèmes de
transport sont des systèmes embarqués de contrôle-commande, temps réel critique.
Une grande difficulté inhérente à la validation des systèmes de contrôle-commande provient du
fait que les comportements ne sont pas reproductibles :
▶ Indépendance du résultat produit par rapport à la vitesse d‟exécution. Le résultat d‟un
calcul effectué à partir de données d‟entrée similaires est indépendant de la vitesse du
calculateur. En revanche, l‟état stable d‟un procédé dépend de la dynamique du procédé par
rapport à la vitesse d‟exécution du système de contrôle-commande.
▶ Comportement reproductible. Un calcul effectué à partir de données d‟entrée identiques
donne toujours le même résultat. En revanche, dans le cas de données d‟entrée (grandeurs
physiques) obtenues par des capteurs, le système de contrôle commande travaille sur un
domaine de données réelles approximées qui sont très rarement identiques.
Cette définition des systèmes de contrôle-commande ayant été faite, nous pouvons replacer ces
systèmes par rapport aux autres systèmes informatiques en faisant trois catégories (voir figure
suivante) :
▶ 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 en relation avec l‟environnement
physique réel pour les données capteur/actionneur ; l‟aspect « temps » a une place importante
sous la forme d‟un temps de réaction, d‟une échéance à respecter, etc.
Figure V.3 : Comparaison des systèmes de contrôle-commande par rapport aux autres
applications informatiques.
71
Nous terminons cette section par des définitions qualifiant des systèmes temps réel ayant des
spécifications particulières. Ces contraintes temporelles peuvent être de plusieurs types :
▶ Contraintes temporelles relatives ou lâches (temps réel mou : soft real-time) : les fautes
temporelles sont tolérables (Ex. : jeux vidéo, applications multimédias, 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. : fonctions critiques avionique, véhicules spatiaux,
automobile, transport ferroviaire…).
▶ Contraintes temporelles fermes (temps réel ferme : firm real-time) : les fautes temporelles
sont autorisées dans une certaine limite, par exemple une erreur toutes les trois exécutions au
plus.
▶ Systèmes multi-critiques : les sous-systèmes composant le système sont caractérisés par des
degrés de criticité. Par exemple en avionique civile, la DO-178C caractérise les sous-systèmes
par un niveau de criticité appelé DAL (Design Assurance Level), allant de niveau A (Ex. :
commande de vol), catastrophique en cas de défaillance, à niveau E (Ex. : divertissement en
vol), sans effet sur la sécurité.
5.1.2 Principales caractéristiques des systèmes temps réel
Considérons un exemple représentatif d‟une application temps réel de contrôle commande
représenté sur la figure V.4. Cet exemple de contrôle-commande d‟un moteur à combustion est
repris de façon détaillée dans le chapitre suivant. Le contrôle-commande de cette application
est fait par l‟intermédiaire d‟un ensemble de capteurs et d‟actionneurs (pédale d‟accélérateur,
température air, pression air, température eau, rotation vilebrequin, capteurs de pollution,
injection essence, allumage, admission air, etc.) et d‟une connexion au réseau interne à
l‟automobile.
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.
▶ Prise en compte des comportements concurrents : l‟ensemble de ces données 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,
72
prévisibilité, déterminisme, continuité de service, tolérance aux fautes, redondance, ségrégation

des moyens de calcul et de communication, etc.).
Figure V.4 : Exemple d‟une application de contrôle-commande d‟un moteur à combustion.

5.1.3. Caractéristiques temporelles des systèmes temps réel
Les contraintes temporelles qui sont classiquement présentées sont des contraintes de bout en
bout, appelées aussi contraintes de latence. Ces contraintes représentent le délai maximal entre
lecture de l‟état du système (lecture des capteurs) et commande de celui-ci (commande des
actionneurs). Par exemple, la commande de vol du drone présenté dans l‟Exemple 1,
puisqu‟elle doit s‟exécuter à 50 Hz, c‟est-à-dire avec une période de 20 millisecondes, se verra
vraisemblablement munie de contraintes temporelles de bout en bout sur la commande de vol,
par exemple de 20 millisecondes, afin d‟obliger le système à s‟exécuter une fois par période.
Le respect du protocole de communication avec les capteurs, actionneurs, ou bus de
communication est une autre source, très importante, de contraintes temporelles.
Ainsi, à chaque fois qu‟une trame est disponible sur un réseau, le système doit la lire et soit la
traiter, soit la stocker pour traitement ultérieur, sous peine de la voir être remplacée (ou «
écrasée ») par la trame suivante.
Comme nous le verrons dans le chapitre 8, il est nécessaire de préciser et de formaliser les
caractéristiques temporelles d‟un système. Cette caractérisation peut prendre de nombreuses
formulations. Ainsi, nous pouvons définir de manière non exhaustive :
▶ Durée d‟exécution d‟une activité : l‟activité d‟une application, qui peut être l‟enchaînement
de plusieurs activités élémentaires (acquisition, traitement, commande, affichage…), possède
une durée d‟exécution qui peut être mesurée de diverses manières. Cette durée n‟est pas
constante à chaque occurrence de cette activité puisque les programmes et les enchaînements
de programmes ne sont pas toujours identiques (branchement conditionnel, itération,
synchronisation…). sation…).
73
▶ Cadence de répétition ou périodicité d‟une activité : l‟acquisition d‟une donnée ou la

commande d‟un actionneur peuvent nécessiter une régularité liée par exemple à la fréquence
d‟échantillonnage.
▶ Date au plus tôt ou date de réveil : dans certains cas, un traitement doit être déclenché à une
date précise relative par rapport au début de l‟exécution de l‟application ou absolue (plus
rarement). Cette date de réveil n‟implique pas obligatoirement l‟exécution ; il peut y avoir un
délai dû à l‟indisponibilité du processeur.
▶ Date de démarrage : cet instant correspond à l‟exécution effective de l‟activité.
▶ Date de fin : instant correspondant à la fin de l‟exécution de l‟activité.
▶ Date au plus tard ou échéance : le traitement ou la commande d‟un actionneur doit être
terminé à un instant fixé par rapport au début de l‟exécution de l‟application. Dans le cas
d‟applications à contraintes temporelles strictes, cette échéance doit être respectée de façon
impérative, sinon il y a faute temporelle et l‟application est déclarée non valide.
▶ Temps de réponse : cette caractéristique peut s‟appliquer à une activité de régulation ou à un
ensemble d‟activités de régulation ; elle est directement liée à la dynamique du système. Ce
paramètre correspond à la différence entre la date de réveil et la date de fin de l‟activité.
▶ Gigue temporelle : ce paramètre caractérise la répétabilité d‟une activité au fur et mesure de
ses occurrences. En effet, entre deux exécutions successives d‟une même activité, ses
caractéristiques temporelles peuvent changer : date d‟activation, durée d‟exécution, temps de
réponse, etc.
5.1.4 Quelques exemples d’applications
Nous pouvons citer quelques exemples d‟applications temps réel de contrôle commande :
▶ Système de transport : que cela soit pour le transport terrestre (véhicule de tourisme, utilitaire,
poids lourd, etc.), ferroviaire, aérien, ou spatial, les systèmes de transport sont caractérisés par
une forte criticité et une forte complexité due à l‟expansion du nombre de fonctions et la
nécessité de tolérance aux fautes. Ils sont typiquement décomposés en sous-systèmes
interconnectés par un ensemble de bus de terrains.
▶ Drone volant, roulant, navigant, ou sous-marin : ce type d‟applications est de plus en plus
répandu, et de plus en plus d‟autonomie est donnée aux drones. Qu‟ils soient d‟observation ou
tactiques, ce type d‟application trouve une large place aussi bien dans les applications militaires
que civiles (exploration de zone radioactive après un accident, planétaire, sous-marine, cinéma
et télévision, etc.).
▶ Robot de production: un robot, réalisant une activité spécifique (peinture, assemblage, tri) sur
une chaîne de production, doit effectuer son travail en des temps fixés par la cadence de
fabrication. S‟il agit trop tôt ou trop tard, l‟objet manufacturier traité sera détruit ou
endommagé conduisant à des conséquences financières ou humaines graves (oubli d‟un ou
plusieurs rivets sur un avion).
▶ Téléphone mobile : le système de contrôle-commande doit remplir plusieurs fonctions dont
certaines ont des contraintes temporelles fortes pour avoir une bonne qualité de service (QoS :
quality of service). Ainsi, la première fonction est de transmettre et de recevoir les signaux de
la parole (577 µs de parole émises toutes les 4,6 ms et 577 µs de parole reçues toutes les 4,6 ms
à des instants différents).
74
En parallèle, il est nécessaire de localiser en permanence le relais le plus proche et donc de

synchroniser les envois par rapport à cette distance (plus tôt si la distance augmente et plus tard
si la distance diminue). Des messages de comptes rendus de la communication sont aussi émis
avec une périodicité de plusieurs secondes. Les contraintes temporelles imposées au système
doivent être imperceptibles à l‟utilisateur.
▶ Système de vidéoconférence : ce système doit permettre l‟émission et la réception d‟images
numérisées à une cadence de 20 à 25 images par seconde pour avoir une bonne qualité de
service. Afin de minimiser le débit du réseau, une compression des images est effectuée.
D‟autre part la parole doit aussi être transmise. Bien que correspondant à un débit
d‟information moindre, la régularité de la transmission, qualifiée par une gigue temporelle, est
nécessaire pour une reproduction correcte. De plus ce signal doit être synchronisé avec le flux
d‟images. Ces traitements (numérisations images et parole, transmission, réception,
synchronisation…) sont réalisés en cascade, mais avec une cohérence précise.
▶ Pilotage d‟un procédé de fabrication (fonderie, laminoir, four verrier…) : par exemple la
fabrication d‟une bobine d‟aluminium (laminage à froid) exige un contrôle en temps réel de la
qualité (épaisseur et planéité). Cette vérification en production de la planéité nécessite une
analyse fréquentielle (FFT) qui induit un coût important de traitement. Le système doit donc
réaliser l‟acquisition d‟un grand nombre de mesures (246 Ko/s) et traiter ces données
(moyenne, FFT…) à la période de 4 ms. Ensuite, il affiche un compte-rendu sur l‟écran de
l‟opérateur toutes les 200 ms et enfin imprime ces résultats détaillés toutes les 2 s. Un
fonctionnement non correct de ce système de contrôle de la qualité peut avoir des conséquences
financières importantes : production non conforme à la spécification demandée.
5.2 Architecture des applications temps réel
5.2.1 Architecture logicielle des applications temps réel
5.2.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. Cela conduit naturellement à adapter
les méthodes de conception et de réalisation du système de contrôle-commande d‟un tel
environnement à ce parallélisme. Aussi, l‟architecture la mieux adaptée pour répondre à ce
comportement parallèle du procédé externe est une architecture multitâche. Ainsi au
parallélisme de l‟environnement, la réponse est le parallélisme de conception. Nous pouvons
définir la tâche ou activité ou processus comme « une entité d‟exécution et de structuration de
l‟application ». 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 10.5 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‟actionneurs directement
liés 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
75
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
cours.
▶ 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
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 V.5 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 : tâches d‟entrées/sortie, tâches de
traitement, tâches de gestion de l‟interface utilisateur, tâches de communications et tâches de
sauvegarde. Ce découpage purement fonctionnel peut être modifié dans certains cas en utilisant
une conception tournée vers les entités ou « objets » à contrôler. Cet aspect de la conception et
de la mise en œuvre est présenté dans les chapitres suivants.
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
76
pour les entrées/sorties. De plus elles peuvent être liées par des relations de type (voir figure
suivante) :
▶ 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
accessibles, pour avoir un fonctionnement correct, par plus d „une tâche à la fois, elles sont
dites ressources critiques.
Figure V.6 : Représentation schématique de l‟architecture multitâche d‟une application de

contrôle-commande.
5.2.1.2. Modèles d’exécution et ordonnancement
Cette architecture logicielle peut être vue comme un ensemble de tâches synchronisées,
communicantes et partageant des ressources critiques. Le rôle essentiel du système
informatique est donc de gérer l‟enchaînement et la concurrence des tâches en optimisant l
„occupation du processeur, cette fonction est appelée l‟ordonnancement.
L‟ordonnancement est un point crucial des systèmes temps réel ; en effet l‟ordonnancement va
déterminer le comportement temporel et être le garant du respect des contraintes de temps
imposées à l‟exécution de l‟application.
Nous pouvons distinguer deux modèles d‟exécution des systèmes temps réel : l‟exécution dite
synchrone et l‟exécution asynchrone. Nous allons présenter ces deux modèles d‟exécution à
l‟aide d‟un modèle d‟application très simple. Cette application, constituée d‟un ensemble de
tâches pour gérer le procédé, intègre en particulier les deux tâches suivantes :
▶ Tâche de lecture des données entrées par l‟opérateur à l‟aide d‟un clavier, appelée «
Lecture_consigne ». L‟intervention humaine fait que cette tâche peut être longue.
▶ Tâche d‟alarme qui se déclenche sur un événement d‟alerte correspondant au dépassement
d‟un paramètre critique, appelée « Alarme ». Celle-ci doit s‟exécuter au plus vite pour éviter
l‟endommagement du procédé.
77
Pour mettre en avant les différences entre les deux modèles d‟exécution nous allons étudier la
situation dans laquelle la tâche « Lecture_consigne » s‟exécute et la tâche « Alarme » demande
son exécution alors que la tâche « Lecture_consigne » n‟est pas terminée.
Dans le modèle d‟exécution synchrone, la perception de l‟occurrence de tout événement par le
système est différée du temps d‟exécution de la tâche en cours.
Dans l‟exemple proposé, nous pouvons constater que la prise en compte d‟un signal d‟alerte
n‟est effective que lors de la fin de la tâche « Lecture_consigne » (voir figure 10.7). D‟un point
de vue du procédé, la réaction est perçue comme différée, alors que du point de vue du système
informatique, elle est perçue comme immédiate.
L‟occurrence des événements externes a donc été artificiellement synchronisée avec le système
informatique, d‟où le nom d‟exécution synchrone.
Figure V.7 : Modèle d‟exécution synchrone d‟une application de contrôle-commande.

Ce retard peut affecter la prise en compte de n‟importe quel événement, quelle qu‟en soit la
gravité pour l‟application. Il faut donc vérifier que l‟architecture opérationnelle choisie
permettra de prendre en compte les contraintes temporelles : hypothèse de la fenêtre de
visibilité des événements ou d‟instantanéité des actions. La capacité du système à appréhender
un événement externe est caractérisée par la durée de la tâche la plus longue puisque les tâches
sont non interruptibles ou non préemtibles.
Dans le cas du modèle synchrone d‟exécution, nous avons un système d‟ordonnancement
complètement prévisible et, en conséquence, il est possible en faisant une analyse exhaustive de
l‟exécution de produire une séquence d‟exécution qui est jouée de façon répétitive. Cette étude
de la séquence est appelée analyse de l‟ordonnancement hors-ligne. L‟ordonnancement peut se
réduire à un séquencement. Nous avons alors un environnement informatique très simple de
l‟application développée puisqu‟il se réduit à une liste de tâches à exécuter. L‟environnement
informatique pour piloter cette liste de tâches se réduit à un système très simple : un
séquenceur.
Dans le modèle d‟exécution asynchrone, l‟occurrence de tout événement est immédiatement
prise en compte par le système pour tenir compte de l‟urgence ou de l‟importance. Dans
78
l‟exemple proposé, nous pouvons constater que la prise en compte d‟un signal d‟alerte est
immédiate sans attendre la fin de la tâche « Lecture_consigne » (voir figure 10.8). La prise en
compte de l‟événement « alerte » est identique pour le procédé et le système informatique.
L‟occurrence des événements externes n‟est pas synchronisée avec le système informatique,
d‟où le nom d‟exécution a synchrone.
Figure V.8 : Modèle d‟exécution asynchrone d‟une application de contrôle-commande.

Dans ce contexte, nous avons des tâches qui sont interruptibles ou préemptibles.
En conséquence, l‟ordonnancement n‟est pas totalement prévisible et l‟analyse de l‟exécution
des tâches doit se faire en ligne par simulation ou par test.
Cela nécessite l‟utilisation d‟un gestionnaire centralisé des événements et de la décision
d‟exécution : exécutif ou noyau temps réel.
Analyse de l‟ordonnancement hors-ligne ou en ligne : une analyse de l‟ordonnancement hors-
ligne correspond à la construction d‟une séquence d‟exécution complète sur la base des
paramètres temporels des tâches en utilisant une modélisation (réseaux de pétri) ou une
simulation (animation ou énumération du modèle). L‟ordonnanceur n »cessaire est simple
puisque la séquence d‟exécution est prédéfinie, il se réduit à un séquenceur. En revanche,
l‟application ainsi figée est peu flexible.
Une analyse de l‟ordonnancement en ligne ne correspond à un choix dynamique de la prochaine
tâche à exécuter en fonction des paramètres de la tâche. Si le système a des contraintes
temporelles, on doit utiliser préalablement la mise en exploitation du système de tests
permettant de vérifier qu‟en toutes circonstances les contraintes temporelles seront respectées.
On appelle ces tests de tests d‟ordonnançabilité.
Exécution synchrone ou asynchrone :
Une exécution est dite synchrone si les tâches sont préemptibles et s‟exécutent les unes après
les autres dans un ordre qui peut être défini par une analyse hors-ligne de l‟ordonnancement.
Une analyse de la séquence doit se faire obligatoirement en ligne. Dans ce cas l‟architecture de
l‟application est composée de plusieurs tâches réalisées par le concepteur et d‟un
79
environnement spécifique, le noyau temps réel, que nous allons décrire. Le point central de cet
environnement est l‟ordonnanceur qui permet d‟affecter à tout instant le processeur à une tâche
afin de respecter l‟ensemble des contraintes temporelles attachées à la gestion du procédé.
5.2.1.3. Exécutif ou noyau temps réel
Cet environnement particulier d‟exécution, exécutif ou noyau temps réel, peut être assimilé à
un système d‟exploitation de petite taille dédié aux applications de contrôle commande.
La caractéristique fondamentale est son déterminisme d‟exécution avec des paramètres
temporels fixés (temps de prise en compte d‟une interruption, changement de contexte entre
deux tâches, etc.). Nous pouvons comparer les différences au niveau des objectifs fixés pour le
noyau d‟exécution d‟un système informatique classique et d‟un système informatique de
contrôle-commande.
Un système classique n‟a pas été conçu pour permettre de respecter des contraintes temporelles,
mais il suit les règles suivantes :
▶ Politiques d‟ordonnancement des activités basées sur le partage équitable du processeur :
affectation identique du temps processeur à tous les processus en cours ;
▶ Gestion non optimisée des interruptions ;
▶ Mécanismes de gestion mémoire (cache…) et de micro-exécution engendrant des fluctuations
temporelles (difficulté pour déterminer précisément les durées des tâches) ;
▶ Gestion des temporisateurs ou de l‟horloge pas assez fine (plusieurs ms) ;
▶ Concurrence de l‟application temps réel avec le système d‟exploitation toujours actif ;
▶ Gestion globale basée sur l‟optimisation d‟utilisation des ressources et du temps de réponse
moyen des différents processus en cours.
Un système informatique de contrôle-commande s‟attache aux caractéristiques suivantes :
▶ Efficacité de l‟algorithme d‟ordonnancement avec une complexité limitée ;
▶ Respect des contraintes de temps (échéances…). Ces contraintes temporelles se traduisent
plus en termes de choix d‟une activité à exécuter à un instant donné plutôt que de rapidité
d‟exécution de toutes les activités ;
▶ Prédictibilité (répétitivité des exécutions dans des contextes identiques) ;
▶ Capacité à supporter les surcharges ;
▶ Possibilité de certification pour les applications de certains domaines comme l‟avionique,
l‟automobile…
En général, les contraintes temporelles ne peuvent pas être garanties dans un système
d‟exploitation généraliste (Unix, Windows 8…) contrairement à un noyau temps réel.
▶ Une application temps réel étant par définition un système multitâche, le rôle essentiel du
noyau temps réel est donc de gérer l‟enchaînement et la concurrence des tâches en optimisant
l‟occupation de l‟unité centrale du système informatique. Les principales fonctions d‟un noyau
temps réel peuvent être scindées en trois groupes :
1. gestion des entrées/sorties (gestion des interruptions, gestion des interfaces
d‟entrées/sorties, gestion des réseaux de communications…) ;
80
2. ordonnancement des tâches (orchestration du fonctionnement normal, surveillance,

changements de mode, traitement des surcharges…) ;
3. relations entre les tâches (synchronisation, communication, accès à une ressource
critique en exclusion mutuelle, gestion du temps…).
Il est important de noter que les tâches sont les unités actives du système ; le noyau temps réel
n‟est actif que lors de son appel. Une tâche activée peut appeler le noyau temps réel par une
requête. Les différentes requêtes sont servies par des modules du noyau temps réel appelées
primitives. Ensuite le noyau temps réel réactive une tâche de l‟application selon l‟algorithme
d‟ordonnancement utilisé (voir figure 10.9).
Figure V.9 : Interaction entre les tâches et le noyau temps réel.

Ainsi le noyau temps réel centralise toutes les demandes d‟activation des tâches et gère des
tables lui permettant de comparer les priorités (ou les urgences) et l‟état de ces diverses tâches,
ainsi que l‟état d‟occupation des ressources. La décision d‟activation d‟une tâche étant prise, le
noyau temps réel lance les modules de programmes correspondant à cette tâche et lui alloue les
ressources disponibles.
La tâche activée occupe un processeur jusqu‟à la fin de son exécution sous le respect des
conditions suivantes :
▶ Elle ne réalise pas d‟opérations d‟entrées-sorties ;
▶ Les ressources utilisées sont disponibles ;
▶ Aucun événement extérieur ne revendique le déroulement d‟une tâche plus prioritaire.
Nous pouvons donc décrire schématiquement le contexte complet d‟exécution d‟une
application temps réel avec les deux parties : tâches et noyau temps réel (voir figure suivante).
81
Figure V.10 : Architecture de l‟application : tâches et noyau temps réel.

En conclusion de cette section sur l‟ordonnancement qui est étudié de façon plus complète dans
le chapitre 8, l‟ordonnancement dans le cas des systèmes temps réel à contraintes temporelles
strictes a pour objectif principal de répondre aux deux cas suivants :
▶ Fautes temporelles : cela correspond à un non-respect d‟une contrainte temporelle associée à
une tâche comme le dépassement de la date limite d‟exécution ou échéance. Cela induit la
notion d‟urgence d‟une tâche.
▶ Surcharge : lors de l‟occurrence d‟une ou plusieurs fautes temporelles, l‟ordonnanceur peut
réagir en supprimant une ou plusieurs tâches de l‟application, ce qui amène à la notion
d‟importance, c‟est-à-dire le choix d‟une tâche à exécuter par rapport aux spécifications
fonctionnelles de l‟application.
7.2.1.4. Implémentation des applications de contrôle-commande
Les langages de développement des applications de contrôle-commande sont très divers.

Cependant, par rapport à l‟environnement d‟exécution que nous venons de décrire (noyau
temps réel avec les trois fonctions décrites :
1. gestion des interruptions,
2. ordonnancement,
3. Relation entre les tâches s), il est possible de décliner les langages en trois groupes (voir
figure suivante) ;
82
Figure V.11 : Langages utilisés pour développer les applications avec un noyau temps réel (1 :
gestion des interruptions, 2 : ordonnancement, 3 : relations entre les tâches).
Langages standards (langage C,Pascal, …) : le noyau temps réel qui supporte ce type de
langage doit être complet puisque le langage n‟intègre aucune spécificité multi tâche.
Langages multi tâches (langage Java, Ada, …) : ces langages permettent de décrire
l‟application en termes de tâches ; ainsi le noyau peut être plus réduit et ne comporter que les
deux premières fonctions.
Langages réactifs (langages Lustre, Esterel, Signal, …) : ces langages donnent non seulement
la possibilité de décrire les fonctionnalités du programme, mais aussi l‟enchainement des
différentes parties. Le noyau est donc limité à une couche proche du matériel lié notamment à
la gestion des interruptions. En revanche, étant donné la possibilité très limitée d‟expression de
l‟aspect fonctionnel, ils sont souvent associés à un langage standard pour pallier ce manque.
10.2.2 Architecture matérielle des applications de contrôle commande
Comme nous l‟avons vu ci-haut, l‟aspect matériel a une très grande importance dans les
applications de contrôle commande. Cette implication est liée d‟une part à la connexion directe
avec le monde physique réel à l‟aide d‟une grande diversité des systèmes d‟entrées/sorties et
d‟autre part au matériel informatique parfois spécifique et développé pour une application
donnée. Ce dernier point concerne les applications dites dédiées et embarquées ; le matériel a
été conçu et créé spécifiquement pour une application, comme un téléphone portable, une
caméra vidéo, etc.
83
Chapitre VI : LES SYSTEMES EXPERTS TEMPS REEL (SETR)

6.1. Définition
Le temps de réponse d'un système de traitement d'information peut être défini comme le temps
séparant la dernière donnée saisie et la première réponse fournie, ou plus généralement comme
la période de temps passée par le système de traitement pour répondre à une demande avec une
action appropriée [Yourdon 1972]. Par analogie, on peut évaluer le temps de réponse d'un
Système Expert Temps Réel (SETR) par le temps séparant le moment de la détection d'un
événement significatif et celui de la proposition d'une solution au problème. Ainsi, en
cohérence avec la caractérisation d'un système temps réel classique, la réponse en temps réel
d'un SETR, selon Wright [Wright 1986], signifie l'élaboration d'une réponse valide à l'intérieur
du délai autorisé.
A ce niveau, il convient d'analyser la rapidité du temps de réponse (temps que le système prend
pour reconnaitre et répondre à un événement extérieur) d'un SETR suivant deux angles
différents [Tang 1989] :
1- la rapidité du temps de réponse à elle seule ne permet pas de constituer une caractérisation
suffisante d'un SETR ;
2- une diminution du temps de réponse signifie également un gain de sécurité et une
augmentation de la marge de manœuvre de l'operateur, n‟est donc clair que le temps de réponse
est une préoccupation majeure des concepteurs de systèmes experts fonctionnant en
environnement dynamique. Il convient de préciser cependant qu'un temps de réponse court
constitue une condition nécessaire mais non suffisante dans le cadre d'un système expert temps
réel. En fait, il est important de préciser ce que l'on entend par temps réel.
L'expression 'temps réel' est souvent plus facile à reconnaitre qu‟à définir, Par exemple,
personne ne pourrait dire qu'un système qui prend toute une nuit pour faire la mise-a-jour des
transactions bancaires effectuées pendant la journée est un système temps réel. Par contre, on
s'accorde de dire qu'un système qui dirige automatiquement un avion en vol en est un. Selon
O'Reilley [O'Reilly et al. 1985], il existe plusieurs définitions du temps réel.
Son sens le plus courant est suffisamment 'rapide'; ainsi, un système est qualifié de 'temps réel'
s'il traite l'information rapidement. Une autre définition répandue est qu'un système est dit
'temps réel' s'il est perceptiblement rapide ou tout au moins plus rapide qu'un être humain.
Encore mieux, un système est dit 'temps réel' s'il peut traiter l'information aussi rapidement ou
plus rapidement qu'elle ne lui parvient.
Deux définitions plus formelles peuvent également être énoncées:
1- Un système démontre des comportements 'temps réel' s'il est possible de prévoir sa réaction
suffisamment rapidement pour l'utilité du processus en cours [Marsh et Greenwood 1986] ;
2- Un système démontre des comportements 'temps réel' s'il existe une limite stricte de temps à
l'intérieur de laquelle il doit avoir produit une réponse sans se soucier de l'algorithme employé
[O'Reilly et al. 1985].
Le temps de réponse est donc la plus importante mesure des applications temps réel. La
caractéristique qui définit Ie mieux un système temps réel est son habilite h garantir une
84
réponse après qu'un intervalle fixe de temps, faisant partie de la définition du problème, se soit
écoulé [Laffey et al. 1988].
6.2. Caractéristiques des SETR
Contrairement aux systèmes experts 'classiques', pour pouvoir raisonner (être à l'écoute de son
environnement extérieur), un Système Expert Temps Réel (SETR) devra lire des données via
des dispositifs capteurs, De cette nouvelle caractéristique découle plusieurs problèmes
complexes qui devront être résolus par les chercheurs [Laffey et al. 1988] :
 la non-monotonie des données (les données provenant des capteurs, de même que les faits
qui en sont déduits, ne restent pas fixes pendant tout le fonctionnement du programme);
 le problème de la continuité (certains SETR doivent continuer de fonctionner aussi
longtemps qu'ils ne sont pas arrêtés par un opérateur ou un événement externe);
 les événements asynchrones (dans certains SETR, il peut arriver que des événements se
produisent d'une manière aléatoire, un SETR doit pouvoir être interrompu et accepter des
données suite A un événement non planifie ou asynchrone);
 la recherche d'une haute performance (connaissant la limitation des performances
d'applications en intelligence artificielle, le problème de contrôler des systèmes complexes
en répondant rapidement à des données changeantes représente un goulot d'étranglement
critique lors de l'application des systèmes experts au domaine du temps réel);
 les données incertaines ou manquantes (la validité des données peut être altérée dans le
temps, un SETR doit pouvoir reconnaitre et traiter de façon appropriée ces données);
 le raisonnement temporel (un SETR doit pouvoir raisonner sur le passé, le présent et le
futur en suivant l'ordre dans lequel les événements se produisent);
 la focalisation sur un événement important (ceci peut impliquer l'apport d'une nouvelle
source de connaissance (spécialiste), une modification de l'ensemble des capteurs utilisés à
cet instant par le système et possiblement un changement de la vitesse d'échantillonnage de
ces capteurs);
 le temps de réponse garantie (le système doit pouvoir répondre au moment où une réponse
est attendue
et il doit produire la meilleure réponse possible avant l'échéance.
 l'intégration à des procédures temporelles (un SETR doit être intègre avec un logiciel temps
réel conventionnel qui effectuera certaines taches comme la compression des données et les
opérations d'entrée et sortie).
6.3. Les applications des SETR
Selon Turner [Turner 1986], la principale raison d'utiliser un système expert est de réduire les
efforts de raisonnement des utilisateurs ou de leur permettre d'augmenter leur productivité sans
pour autant augmenter leurs efforts de raisonnement Certains indicateurs permettent de savoir
si un système expert serait approprié dans une situation donnée (spécialement si les techniques
plus conventionnelles ont échoué ou ne sont pas utilisables). Parmi ces indicateurs, il y a ceux
qui sont relatifs aux situations de résolution de problèmes demandant un raisonnement trop
complexe, ainsi que ceux ou l'être humain ne peut pas tenir compte de toute l'information
disponible. Il en va de mène des situations relatives aux contraintes conflictuelles, ainsi que
celles qui induisent des couts élèves ou qui ne pourraient pas donner une solution à un
problème assez rapidement [Laffey et al. 1988].
85
Un système expert opérant dans une situation ou il doit traiter de l'information en temps réel va
typiquement devoir répondre à un environnement changeant, caractérisé par un flot
d'événements asynchrones, des besoins changeant dynamiquement et des limitations sur le
temps, le matériel ainsi que d'autres ressources. Une architecture logicielle flexible sera donné
nécessaire pour permettre au système de réagir face à des données changeant continuellement à
travers des plages de temps stricts tout en permettant un raisonnement temporel, Ie traitement
des interruptions et des méthodes pour le traitement des bruits de fond.
Les SETR se distinguent donc des autres systèmes par un couplage plus étroit avec le monde
extérieur et par des contraintes plus sévères de délais d'exécution [Nussbaumer 1986]. On
comprend donc tout de suite, comme nous l'avons déjà vu, que les SETR utilisent une variable
supplémentaire très importante lors de leur interaction avec le monde extérieur à savoir le
temps.
Un des traits de définition des systèmes temps réel (ne pas confondre avec système expert
temps réel) est que la valeur d'un résultat calcule dépend du moment à partir duquel ce résultat
est effectivement utilise, ce qui veux dire que les temps de calcul doivent être strictement
prévisibles,
Les systèmes experts, d'un autre côté, sont orientes spécifiquement vers des applications pour
lesquelles il n'existe aucun algorithme polynomial de temps, ce qui fait que les temps de calcul
sont habituellement imprévisibles et très variables.
Schoppers définit donc les systèmes experts temps réel (ou plus précisément les systèmes
experts de contrôle temps réel) comme étant des programmes informatiques dont l'implantation
doit inévitablement tenir compte de cinq ressources principales:
 la puissance de traitement: le nombre d'opérations effectuées par seconde ;
 le temps de réponse: le temps réel nécessaire pour répondre aux changements de valeur de
chacune des variables contrôlées par le système ;
 l'espace de données: la capacité mémoire nécessaire pour emmagasiner le programme et
toutes ses données ;
 le degré d'inattention: le degré à partir duquel l'information pertinente et les calculs sont
sous-utilisés ;
 la dégradation: le degré de diminution de l'efficacité du programme par rapport à sa situation
optimale.
6.4. Méthodologie de conception et de développement des SETR
Il est question dans cette partie de parler de la méthodologie de conception et de développement
d‟un système expert Temps réel.
Un Système expert temps réel est un système qui est :
 en relation directe avec l‟environnement ;
 reçoit les informations du monde réel ;
 traite ces informations ;
 évalue une décision ;
 agit sur son comportement extérieur pour atteindre un état stable.
86
En termes de partie commande et partie opérative :
Le Système expert (partie commande) comprend : un moteur d‟inférence, une base de

connaissances et des interfaces (utilisateur, expert, opérateur).
 Les systèmes experts temps réel sont des systèmes critiques, il y a donc nécessité lors de leur
conception de :
 Capturer les exigences des utilisateurs (fonctionnelles et non-fonctionnelles)
- Fonctionnelles : les besoins centraux de l‟application
- Non-fonctionnelles : les besoins génériques (sécurité, contraintes technologiques, etc.)
 Choisir une méthodologie stricte de développement
 Tester et valider l‟application
 Gérer la maintenance (documentation et réingénieurie)
6.4.1. Les étapes de développement logiciel
Le processus de développement logiciel contient un certain nombre d‟étapes :
1. Définir les besoins et les exigences du client et des utilisateurs
2. Analyser le système
3. Concevoir le système
4. Programmer le logiciel
5. Tester le logiciel
6. Déployer
87
7. Maintenir le système
6.4.2. Les étapes d'un projet

Un système peut être un produit ou un ensemble de produits qui seront livrés au client à l‟issu
du projet. Lorsqu‟il s‟agit d‟un projet de développement logiciel, le système pourrait donc être
un logiciel ou un ensemble de logiciels.
Etapes Descriptifs
Définition besoins et des La définition des besoins et des exigences correspond
exigences à l‟étape dans laquelle nous discutions avec le client et
les futurs utilisateurs afin de comprendre de quoi ils
ont besoin : QUI doit pouvoir faire QUOI ?
Lors de cette étape, nous définissions également les
demandes précises, telles que le respect de certaines
normes graphiques, les temps de réponse, le matériel
sur lesquels le logiciel devrait fonctionner, etc.
Analyse du système L‟analyse du système permet d‟affiner ce qui a été
définie dans l‟étape précédente. On y détaille
davantage le fonctionnement interne du futur logiciel
(COMMENT cela doit-il fonctionner ?).
Conception du système La conception du système correspond à la définition
de choix techniques.
La programmation La programmation est l‟étape dans laquelle les
informaticiens se donnent à cœur joie ! Ils réalisent le
logiciel à l‟aide de langages de programmation, de
systèmes de gestion de bases de données, etc.
Les tests Durant les tests, les informaticiens vérifient que le
logiciel fonctionne et répond aux besoins définis en
début du projet. Cette phase de tests peut intégrer des
validations du logiciel avec le client et/ou les
utilisateurs. C‟est même plus que souhaité.
Le déploiement Lors du déploiement, les informaticiens installent le
logiciel sur le matériel et réalisent des ajustements
pour faire fonctionner le logiciel dans l‟environnement
de travail des utilisateurs.
La maintenance du système La maintenance correspond à la période qui suit
l‟installation et pendant laquelle les anomalies et
problèmes doivent être corrigés.
88
Ces étapes ne sont pas forcément utilisées de façon linéaire. On parle souvent de cycles de vie,
qui ont pour but d‟organiser ces étapes de différentes manières en fonction d‟un certain nombre
de critères relatifs au projet de développement.
a) Analyse des besoins
Les besoins analysés dans un projet de système expert temps réel sont les suivants :
 Les entrées : l‟acquisition des grandeurs par des capteurs (senseurs) telles que la
température, la vitesse, l‟humidité, la lumière, etc.
 Les sorties : la commande de l‟environnement par les actionneurs (moteurs, vérins,
régulateurs, etc.)
 Les traitements : la mise à jour des sorties en fonction des entrées pour
contrôler/commander un processus physique
 Les communications : partager des données avec les systèmes de contrôle (commande
voisins)
 Les sauvegardes des états pour des reprises d‟exploitation ou des analyses du système à
priori
a1) Les tâches d’entrées
Acquérir une grandeur physique n‟est pas trivial, car il y a :
- Un grand nombre de techniques d‟acquisition (vitesse : analogie, 2 signaux carrés à 90°,
rapport cyclique asymétrique, radar doppler, etc.)
- Un grand nombre de traitements associés :
 Interrupteur : gérer les rebonds ;
 Poussoir : ne pas rater une impulsion ;
 Clavier : multiplexage binaire, analogique ;
 Grandeurs continues : plages de valeurs, granularité ;
 Données prétraitées : format, médium, retard, latence.
Exemple :
a2) Les tâches de sortie

Elles peuvent être des natures suivantes :
- Binaires : vérins, ventilateurs, résistances électriques, moteurs ;
- Discrètes : sur quel type de bus ;
- Continues : consignes de vitesse, température, pression, …
89
Exemple :
a3) Les tâches de traitements

Cette partie de tâches constituent le cœur de l‟application avec les algorithmes de :
- Traitement du signal, corrélation, analyse spectrale, traitement d‟image, etc…
- Boucles de régulation du premier ordre, PID, à retard, profil de vitesse …
- Régulateur
- Contrôle (automatique).
Exemple : Freinage ABS
Le système anti-blocage des roues, plus connu sous l'abréviation « ABS » (de l'allemand «
Antiblockiersystem »), est un système d'assistance au freinage utilisé sur les véhicules roulants,
limitant le blocage des roues pendant les périodes de freinage intense.
C‟est une fonction secondaire dans le système de contrôle de traction, utilisée sur les avions
(lors de l'atterrissage) et sur les véhicules automobiles ou motocyclettes, où elle fait de plus en
plus partie de l'équipement standard. D'autres termes sont également utilisés ou recommandés
comme « antiblocage de sécurité », « système de freinage anti-blocage », « freins anti-
blocage », ou « système d'antiblocage de roues ».
a4) les tâches d’interface utilisateur : elles permettent de gérer un pupitre de commande.
90
a.5) Les tâches de communication : ce sont des tâches destinées à échanger de l‟information
entre les tâches sur les systèmes centralisés ou distribués selon des contraintes à la fois
logicielles et matérielles.
 Les bus industriels : Modbus, Fip, SPI, I2C, CAN,
 La téléphonie, Ethernet, GSM, Wifi, ZigBee…
a.6) Les tâches de sauvegarde : elles permettent d‟enregistrer régulièrement les états du
système pour :
 Analyser son fonctionnement ;
 Améliorer les performances ;
 Analyser les erreurs ;
 Reprises et mises en route.
b) La conception du système : Elle permet de faire le choix d‟architecture (une architecture
mono-tâche ou une architecture multitâche). L‟architecture multitâche est la plus utilisée, elle
permet de bien mettre en œuvre l‟ensemble des tâches préalablement définies, en garantissant :
 Synchronisation : Précédences d‟exécution entre tâches
 Transferts de données : Communication entre tâches
 Partage des ressources : Ressources critiques communes à l‟ensemble des tâches
 Deux modèles sont utilisés : synchrone et asynchrone.
b1.) Enchaînement des tâches modèle d’exécution synchrone
Les principes établis dans le cas d‟enchainement des tâches suivant le modèle d‟exécution
synchrone sont :
- Les événements émis par le procédé peuvent être différés ;
- Les événements sont perçus comme immédiats par l‟informatique ;
- Les événements externes sont synchronisés avec les tâches.
On est donc dans le cas non préemptif avec ordonnancement a priori, d‟où le recours au
séquenceur.
91
b2.) Enchaînement des tâches modèle d’exécution asynchrone

Les principes établis dans le cas d‟enchainement des tâches suivant le modèle d‟exécution
asynchrone sont :
- Les événements émis par le procédé sont traités immédiatement : interruptions ;
- Les événements sont aussi perçus comme immédiats par l‟informatique ;
- Les événements externes ne sont pas synchronisés avec les tâches.
On est donc dans le cas préemptif avec ordonnancement en ligne, d‟où le recours au noyau
Temps réel.
c) L’implémentation de l’application
Comme nous l‟avons dit précédemment, Les langages de développement des systèmes experts
de contrôle-commande ou temps réel, sont très divers. Cependant, par rapport à
l‟environnement d‟exécution nous avons décrit (noyau temps réel) avec les trois fonctions
décrites :
1. gestion des interruptions,
2. ordonnancement,
3. Relation entre les tâches s), il est possible de décliner les langages en trois groupes (voir
figure ci-dessous) :
92
Figure : Langages utilisés pour développer les applications avec un noyau temps réel (1 :
gestion des interruptions, 2 : ordonnancement, 3 : relations entre les tâches).
On peut résumer ces étapes sous la forme du schéma ci-après représentant le développement
par étapes :
93
• Le développement par étapes est adapté aux SETR complexes.

 En effet, il permet de décomposer un problème en sous-problèmes, chaque étape se
focalisant sur un aspect du problème, soient :
 l‟expression des besoins et des contraintes de QdS,
 la définition du support d‟exécution,
 la décomposition architecturale du système,
 le choix d‟un modèle de concurrence et d‟une politique d‟ordonnancement.
 De plus dans le cadre de projets importants, l‟identification et la formalisation de chaque
étape apparaissent comme bien adaptées à la contractualisation nécessaire entre les divers
acteurs du développement.
 Par exemple, dans le domaine de l'automobile, une séparation claire est faite entre les
équipes qui spécifient (le constructeur), celles qui conçoivent et implémentent (les
équipementiers) et enfin celles qui intègrent et valident (le constructeur).
 Ces équipes, aux cultures scientifiques souvent différentes, doivent pouvoir communiquer
par l‟échange de modèles communs.
 Ces modèles concernent typiquement les étapes de spécification, de conception,
d'implémentation et de validation.
 Dans le domaine des SETR, les contraintes de QdS doivent être exprimées et prises en
compte à chacune des étapes
• La spécification permet de formaliser les besoins du système via un ensemble de
propriétés représentant les fonctionnalités, le comportement et les performances attendues
(cf. figure ci-après). Du fait de l‟aspect réactif des SETR, il est aussi nécessaire de
modéliser le comportement de l‟environnement [Per 90]. En effet, le comportement
temporel du système, et donc sa correction, est directement lié au comportement temporel
de l‟environnement Une fois les contraintes exprimées, le résultat de la conception
décrit une solution au problème posé.
• Dans ce cadre, la conception architecturale a émergé dans années 70 pour aider à la
maîtrise de la complexité des systèmes.
• Une architecture logicielle peut être définie comme un ensemble de contraintes de
programmation définissant les éléments logiciels d'un système, ainsi que les relations
entre ces éléments. L‟architecture fournit des informations sur l‟organisation et la
configuration du système, en masquant les détails d‟implémentation, considérés comme
non pertinents à ce niveau d‟analyse.
• L’architecture est un élément structurant pour la gestion de projet. Elle offre un support
pour l’évolutivité et de la réutilisation des systèmes logiciels. Et surtout elle sert de base
pour la validation et le codage.
• En fonction du stade de développement du système, la description de l‟architecture peut
être une spécification abstraite du système qu‟on cherche à concevoir ou bien une
description du système opérationnel.
• On distingue généralement l‟architecture technique ou matérielle qui correspond aux
machines (processeurs, ASIC, …), aux mediums de communication (réseaux, bus) et aux
services associés (exécutif, services de communication) de l‟architecture logique ou
94
applicative. Cette dernière décrit une organisation de l‟application en modules ou

composants et les liens ou connecteurs entre ces composants.
• Le déploiement correspond au placement des composants sur les entités d‟exécution
(machines, tâches) et à la mise en place des services nécessaires à leur communication. Il
aboutit à une architecture dite opérationnelle.
• Au final, l‟architecture opérationnelle définit l‟ensemble des éléments nécessaires à
l‟implémentation du système, sous forme de programmes concurrents et communicants
partageant des ressources communes. Ci-dessous l‟architecture opérationnelle pour un
Système Automatisé de Production.
d) Systèmes experts temps réel et microcontrôleurs

Les systèmes embarqués (en anglais : embedded systems) sont composés d'une partie matérielle
(hardware) et d'une partie logicielle (software). Ils sont intégrés ou embarqués dans un produit.
Ces produits sont par exemple un robot, une auto, un téléphone portable, un agenda
électronique, une machine à café, etc. Le système embarqué est en général responsable du
contrôle, du traitement du signal et de la surveillance des différents composants du produit ou
du produit dans son ensemble. La fonctionnalité d'un système embarqué se limite à l'exécution
d'une ou quelques tâches dédiées.
Aujourd‟hui, les systèmes experts temps réel sont intégrés dans des dispositifs de manière à les
rendre intelligents (systèmes avioniques, etc.).
d1. Du microprocesseur au microcontrôleur
Le microcontrôleur est un dérivé du microprocesseur. Sa structure est celle des systèmes à base
de microprocesseurs. Il est donc composé en plus de l‟unité centrale de traitement, d‟une
mémoire (mémoire vive RAM et mémoire morte ROM), une (ou plusieurs) interface de
communication avec l‟extérieur matérialisé par les ports d'entrée/sortie.
En plus de cette configuration minimale, les microcontrôleurs sont dotés d'autres circuits
d‟interface qui vont dépendre du microcontrôleur choisi à savoir les systèmes de comptage
(TIMER), le convertisseur analogique/numérique (CAN) intégré, gestion d‟une liaison série ou
95
parallèle, un Watchdog (surveillance du programme), une sortie PWM (modulation

d‟impulsion),…
Le contenu type d‟un microcontrôleur se présente de la manière suivante :
Les microcontrôleurs améliorent l'intégration et le coût (lié à la conception et à la réalisation)

d'un système à base de microprocesseur en rassemblant ces éléments essentiels dans un seul
circuit intégré. On parle alors de "système sur une puce" (en anglais : "System On chip").
Les microcontrôleurs sont plutôt dédiés aux applications qui ne nécessitent pas une grande
quantité de calculs complexes, mais qui demandent beaucoup de manipulations
d‟entrées/sorties. C‟est le cas de contrôle de processus.
Les systèmes à microprocesseur sont plutôt réservés pour les applications demandant beaucoup
de traitement de l‟information et assez peu de gestion d‟entrées / sorties. Les ordinateurs sont
réalisés avec des systèmes à microprocesseur.
Il existe plusieurs familles de microcontrôleurs dont les plus connues sont :
 Atmel : AT; familles AT89Sxxxx, AT90xxxx, …
 Motorolla : famille 68HCxxx, …
 Microship : PIC ; familles 12Cxxx, 16Cxxx, 16Fxxx, 18Fxxx, …
 Intel : famille 80C186XX
 STMicroelectronics : famille STX
 Analog Devices : famille ADuC
d2.Systèmes experts temps réel et plateforme Arduino
1. C’est quoi Arduino ?
 ARDUINO = 1 carte à microcontrôleur + 1 outil de développement + 1 communauté
active
 Le logiciel et le matériel sont open-source.
96
En quelques chiffres :
• Prix d'une carte Arduino uno = 25 euros
• Logiciel = 0 euros
• Support et assistance = 0 euros (forums)
2. La « philosophie »
L'idée est d'utiliser la carte Arduino comme un macro-composant dans des applications de
prototypage électronique. Le concepteur n'a plus qu'à développer des interfaces et programmer
le macrocomposant pour réaliser son application !
Les avantages de la carte Arduino :
• Elle ne coûte pas cher !
• L‟environnement de programmation est clair et simple.
• Elle est multiplateforme: elle tourne sous Windows, Macintosh et Linux.
• Elle possède de nombreuses librairies disponibles avec diverses fonctions implémentées.
•le logiciel et le matériel sont open source et extensibles.
• Nombreux conseils, tutoriaux et exemples en ligne (forums, site perso etc...)
• Existence de « shield » (boucliers en français) : ce sont des cartes supplémentaires qui se
connectent sur le module Arduino pour augmenter les possibilités comme par exemple :
afficheur graphique couleur, interface ethernet, GPS, etc...
Par sa simplicité d'utilisation, Arduino est utilisé dans beaucoup d'applications comme
l'électronique industrielle et embarquée, le modélisme, la domotique mais aussi dans des
domaines différents comme l'art contemporain ou le spectacle !
3. La carte Arduino uno
Il existe plusieurs types de cartes, j'ai commencé avec une carte Arduino uno (carte basique,
aux dimensions voisines de celle d'une carte bancaire).
97
4. Caractéristiques de la carte Arduino uno :

Micro contrôleur : ATmega328 ; Tension d'alimentation interne = 5V
Tension d'alimentation (recommandée)= 7 à 12V, limites =6 à 20 V
Entrées/sorties numériques : 14 dont 6 sorties PWM
Entrées analogiques = 6
Courant max par broches E/S = 40 mA
Courant max sur sortie 3,3V = 50mA
Mémoire Flash 32 KB dont 0.5 KB utilisée par le bootloader Mémoire SRAM 2 KB mémoire
EEPROM 1 KB
Fréquence horloge = 16 MHz
Dimensions = 68.6mm x 53.3mm
La carte s'interface au PC par l'intermédiaire de sa prise USB.
La carte s'alimente par le jack d'alimentation (utilisation autonome) mais peut être alimentée
par l'USB (en phase de développement par exemple).
5. Les « shields »
Il existe de nombreux shields que l'on traduit parfois dans les documentations par «boucliers ».
Personnellement, le terme « extension » me paraitrait plus approprié. Un « shield » Arduino est
une petite carte qui se connecte sur une carte Arduino pour augmenter ses fonctionnalités.
Quelques exemples de « shields » :
 Afficheur graphique
 Ethernet et carte SD
98
 GPS
 Carte de prototypage (type labdec)  etc…
6. Développement d'un projet sur Arduino
Le développement sur Arduino est très simple :
 On code l'application : Le langage Arduino est basé sur les langages C/C++, avec des
fonctions et des librairies spécifiques à Arduino (gestions des e/s).
 On relie la carte Arduino au PC et on transfert le programme sur la carte,
 On peut utiliser le circuit !
Le logiciel de programmation des modules Arduino est une application Java multiplateformes
(fonctionnant sur tout système d'exploitation), servant d'éditeur de code et de compilateur, et
qui peut transférer le firmware (et le programme) au travers de la liaison série (RS232,
Bluetooth ou USB selon le module).
Le logiciel est très simple à prendre en main, il existe de très bons tutoriaux très bien faits avec
même des explications en français. De très nombreux exemples sont fournis.
Les fichiers exemples sont vraiment bien documentés et permettent de coder des choses très
compliquées sans trop d'efforts. Les bibliothèques fournies permettent d'utiliser des composants
complexes très simplement en quelques lignes très claires (afficheur ou liaison SPI etc..).
99
6.5. Exemple d’un Système expert temps réel
6.5.1. Architecture d‟un système expert temps réel d'aide à la conduite.

L‟architecture suivante concerne un système expert temps réel d'aide à la conduite :
Figure 1. Architecture du système expert temps réel d'aide a la conduite

Ainsi, le module d'acquisition, de contrôle et de traitement des données en temps réel se charge
du bas niveau principalement en ce qui concerne la mise en forme, le filtrage et le traitement
des données, Ce module est détaillé dans la section ci-dessous. Il est suivi du module principal,
le module système expert temps réel (SETR), qui se charge de 'raisonner' en temps réel afin
d'aider le chauffeur dans le cadre de ses activités de conduite et d'extra-conduite.
6.5.2. Le Système d'Acquisition, de Contrôle et de Traitement de données en temps
réel (SACT)
6.5.2.1. Les objectifs du SACT
La maquette de SACT est créée afin d'alimenter en données un système expert temps réel
conçu pour donner des conseils en situation de conduite suite à l'analyse du comportement d'un
camion lourd. Ainsi, le système pourra aviser le conducteur d'une trop grande vitesse à
l'approche d'un virage, du danger de dérapage, d'un déséquilibre de la charge transportée, etc.
Les objectifs visés par l'élaboration de cette maquette sont pour l'essentiel :
1- de pouvoir traiter les données en temps réel ;
2- de pouvoir traiter de façon adéquate de l'information temporelle, c'est-a-dire des données
qui perdent de leur validité avec le temps ;
100
3- de pouvoir traiter les données d'un nombre quelconque de capteurs;

4- de pouvoir permettre au concepteur de choisir la vitesse d'échantillonnage, le niveau de
priorité et les intervalles de valeurs critiques de chacun des capteurs;
5- de pouvoir créer un fichier contenant toutes les données provenant de chacun des capteurs
et ce pour un intervalle de temps relativement grand;
6- d'être capable de filtrer l'information reçu des capteurs, c'est-à-dire qu'il doit être capable
de savoir quand les données provenant des capteurs ne respectent pas l'intervalle de valeur
critique donné par l'utilisateur;
7- et enfin de respecter des contraintes d'espace mémoire dus à la nature du système expert
temps réel alimenté par le SACT (système embarqué).
9.5.2.2. Principales caractéristiques du SACT
La première maquette du SACT a été créée à l'aide d'un exécutif temps réel appelé MTR86
[Tschirhart 1990]. La mise en œuvre de la maquette , à l'aide de l'exécutif MTR86, a permis de
mettre en pratique des techniques de mise en œuvre de SACT. Cette maquette du SACf a été
développée à l'aide du langage Turbo C de Borland © sur un ordinateur de la famille Intel
8Ox86 sous système d'exploitation MS-DOS de Microsoftcorp ©.
Figure Le système d'acquisition, de contrôle et de t:raitement de données temps réel

Concernant le fonctionnement de la maquette (voir figure précédente), l'utilisateur doit
premièrement faire 1a paramétrisation des données pour chacun des capteurs (priorités, vitesse
d'échantillonnage, valeurs critiques). Un module d'acquisition des données fait ensuite
l'échantillonnage de chacun des capteurs et crée un fichier de l'ensemble de ces données. Ce
fichier pourra ensuite être utilisé pour recréer une partie ou l'ensemble du trajet effectue par le
camion lourd. Les données sont ensuite filtrées par le module de filtrage pour en faire ressortir
les valeurs critiques (vitesse excessive, fonctionnement anormal du système de freinage, etc.).
Chaque valeur critique de même que son origine est ensuite placée dans un tampon utilisant la
technique dite homogène dans le temps [Moratore et al. 1990] afin de préserver la relation
temporelle existant entre chacune des données.
Le SETR peut ensuite venir chercher ces valeurs critiques pour les traiter.
101
L'interface de l'application, définie selon la technique des tampons homogènes dans le temps se
déroule plusieurs étapes, Quatre tampons sont utilisés selon la technique 'round robin'
permettant ainsi de préserver l'historique des données (voir figure suivante):
Figure 3. Technique des tampons homogènes dans le temps

6.5.2.3. Systèmes Experts Temps Réel (SETR) pour l'aide à la conduite
1. Problématique
L'analyse de rapports d'accidents [Girast 1986] et des entrevues avec des chauffeurs impliqués
dans des accidents porte l croire qu'un nombre appréciable d'entre eux pourraient être moins
graves ou tout simplement évites si les chauffeurs avaient one meilleure connaissance anticipée
des facteurs susceptibles de causer de tels accidents. Ces facteurs sont de divers ordres:
mécaniques (état du véhicule, usure des pneus, etc.), humains (erreurs de jugement, fatigue,
erreurs de perception, etc.) et environnementaux (conditions climatiques, état de la chaussée,
zone à risque, etc.).Il importe donc de développer des outils facilitant la prise en compte par le
chauffeur du plus grand nombre possible de ces facteurs. En plus de cela, il convient d'alléger
la tâche du chauffeur, en raison de la complexité inhérente à ce genre de problème et de la
difficulté à agir adéquatement en situation de stress intense. Cet allégement peut se faire, grâce
aux plus récents progrès de l'informatique et de l'intelligence artificielle. C'est dans ce cadre
que se situe le système expert d'aide à la conduite introduit ci-après,
2. Architecture du Système
L'architecture du système expert temps réel d'aide à la conduite est proposé à la figure 4. Elle
comporte une base de faits, une base de connaissances et un interpréteur. Les faits sont les
informations pertinentes du moment fournies par le SACT, tandis que les connaissances sont
généralement des productions du type [CONDmON] alors [ACTION]. L'interpréteur a, quand à
lui, pour rôle de déduire de nouveaux faits en unifiant les faits actuels aux productions. Parmi
ces faits, ceux qui sont pertinents au chauffeur lui sont achemines A travers une interface
ergonomique de façon à l'aider dans sa conduite.
102
Figure . Architecture du système expert temps réel d'aide à la conduite

6.5.2. Méthodologie de développement
La méthodologie utilisée pour développer Ie système d'aide à la conduite est basée sur la
méthodologie KADS [Hickman et al. 1989] pour Ie développement de systèmes à base de
connaissances (SBC). Ayant pour assises les méthodologies de développement de systèmes
conventionnels, KADS présente un ensemble de modification permettant de prendre en compte
les difficultés propres au développement de SBC. Ainsi, la phase d'analyse est-elle divisée en
trois composantes: l'analyse externe, l'analyse interne et l'analyse des modalités. Ces trois
activités se déroulent en parallèle et en étroite interaction.
L'analyse externe a pour objectif l'identification des besoins de l'utilisateur ou du client et les
contraintes imposées par l'environnement d'utilisation du système. Le produit livrable de cette
activité est Ie modèle des besoins. L'analyse interne concerne Ie processus d'acquisition des
connaissances : extraction, interprétation, analyse et modélisation des connaissances écrites et
verbales. La méthodologie KADS utilise une approche de modélisation basée sur l'utilisation de
modèles d'interprétation, Ces derniers décrivent les caractéristiques prototypiques des
principales tâches de résolution de problèmes auxquels on fait appel dans les SBC (par
exemple: Ie diagnostic, Ie contrôle, la planification). Ces modèles génériques servent de cadre à
l'analyse de la connaissance. Le résultat de cette analyse prend la forme d'un modèle d'expertise
à quatre niveaux, basé sur une typologie de la connaissance d'après Ie rôle que cette dernière
peut jouer dans Ie processus de résolution de problèmes. Dans ce modèle, on retrouve Ie
modèle générique instancié avec les connaissances du domaine.
L'analyse des modalités concerne la relation utilisateur-système en rapport avec les taches qui
doivent être réalisées au cours d'une session d'utilisation. On s'y attache à définir qui (de
l'utilisateur ou du système) fait quoi (les taches et sons-taches) et quand (déclenchement des
taches).
103

Cours de Systèmes Experts Et Temps Réel - 2020-2021

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours de Systèmes Experts Et Temps Réel - 2020-2021

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSITE DE MBUJI-MAYI

FACULTES SCIENCES APPLIQUEES

SYSTEME EXPERT ET TEMPS

Prof. Dr. Jean Didier BATUBENGA

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

1.2.1. Système informatique en interaction avec son environnement

Figure 1 : système informatique en interaction avec son environnement

Entrées Système temps réel Sorties

Le système informatique est tributaire de la dynamique, de la vitesse d‟évolution des objets

L‟actionneur est un dispositif qui convertit un signal électrique en un phénomène physique

FIG.2 – Capteur analogique

La diversité des domaines d‟applications rend difficile l‟élaboration de définitions sur

1.4.2. Spécificité des systèmes temps réel embarqués

1.6. Décomposition des systèmes embarqués

Figure 4 : Décomposition d‟un système embarqué

 Partie logicielle des systèmes embarqués de première génération

Calcul des ordres à envoyer au procédé

 mécanisme de préemption et de reprise de tâche

Figure 5 : Système temps réel de contrôle commande

Figure 6 : système temps de contrôle commande (Boite de vitesse robotisé)

1.9.3. Composants d’un système temps réel de contrôle commande.

Figure 7 : Composants d‟un système temps réel de contrôle commande.

Figure 8 : Systèmes temps réel non embarqués

Figure 9 : Systèmes temps réel embarqués

1.10. Construction d’un système informatique temps réel

Un système informatique temps réel peut être construit :

 comme un générateur cyclique qui périodiquement capte la dynamique du procédé par

Dans cette approche, le programme informatique du système de commande ne comprend

Acquisition des données

envoi des commandes,

Quelques exemples d‟événements pouvant générer une interruption :

1Les boîtiers contrôleurs d‟E/S des microprocesseurs disposent généralement d‟une ou de

contexte d’exécution contexte

Effectuer l‟initialisation générale du système ;

1.10.1.4 Avantages et limites de l’approche monotâche

4Découlant naturellement de l‟approche monotâche, l‟implantation directe n‟est réaliste que

l‟organisation des différents traitements et actions présente plus de rationalité, de souplesse, de

Chapitre II. Modélisation des systèmes temps réels

est donnée par ∑ .

Figure I.2. : Les paramètres temporels d‟une tâche Ti

II.2. Les caractéristiques des tâches

et selon leur ordre d‟arrivée ou selon un ordre décidé par l‟utilisateur.

Figure I.3. : Tâches périodiques

Figure I.4 : Tâches périodiques, apériodiques et sporadiques

II.3. Exécutif ou noyau temps réel

Figure I.5. : Architecture de l‟application : tâches et noyau temps réel

de l‟application selon l‟algorithme d‟ordonnancement utilisé (partie générique du noyau) (voir

II.4. Gestion des tâches

Figure I.6.: Graphe des états possibles d‟une tâche

II.5. Outils de communication et de synchronisation

Figure I.7.: Caractérisation d‟un sémaphore binaire

Figure I.8. : Caractérisation d‟un sémaphore compteur

lettres (sans écrasement et avec écrasement).

Figure I.9 : Composition d‟une boîte aux lettres

Figure I.10 : Communication par tableau noir

II.6. Classification des algorithmes d’ordonnancement

Nous estimons que l‟appellation « ordonnancement local » exprime parfaitement le partage

Chapitre III. Programmation concurrente et programmation

III.2. Intérêts de la programmation concurrente

parallélisme entre calcul et entrées / sorties.

III.1. Programmation concurrente

III.3. Problèmes possibles

III.4. Généralités sur la manipulation de processus et de tâches