Notes de cours de Systèmes Experts et Temps Réel

à l’usage des étudiants de Deuxième Licence Génie Informatique

en Sciences Appliquées

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

1.1 La notion de « système temps réel »

Nombreux sont ceux qui ont essayé de donner une définition de ce qu’est un système temps réel.

Définition 1 « On qualifie de temps réel les systèmes sont 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é. Les applications temps réel concernent un large spectre d’activités et se rencontrent dans
la commande de procédés, les systèmes embarqués, le guidage de mobiles, la surveillance de centrales
nucléaires, la conduite d’expériences scientifiques, la robotique, la fourniture d’images et de sons pour
le multimédia, le suivi opératoire en milieu médical, et même le suivi d’informations boursières. Dans
toutes ces applications le facteur temps est une contrainte essentielle à respecter et ce facteur est
prépondérant pour évaluer la qualité du service. » (Ordonnancement temps réel, p. 9)

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)

Définition 3

« On peut définir succinctement la qualité temps réel comme la capacité d’une application logicielle à
répondre à des sollicitations de l’environnement contrôlé, en des temps de réponse en relation avec la
constante de temps dominante de cet environnement. …Capacité d’une application à pouvoir
appréhender un flux d’événements asynchrones issus d’un processus, sans perdre un seul de ces
événements et de traiter chacun d’eux en un temps déterminé. On retiendra que le concept clé d’une
application temps réel est le déterminisme. » .

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

Nous allons préciser ce qu’est exactement un système temps réel en le caractérisant. Les cinq
caractéristiques suivantes permettent de bien cerner ce qu’est un système informatique temps réel.

1.2.1 C’est un 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.

2
 Entité 2

interaction
observation
Entité 1 Système action
Entité n
informatique

observation
environnement

Entité i
Application

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.
L’environnement est l’ensemble des objets de l’application, à l’exclusion du système.
Les objets de l’environnement sont appelés des entités.
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 C’est un 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 C’est un système qui effectue ses activités en respectant des contraintes de temps

4
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.
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 peut 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 êtres simultanées.

Contraintes strictes et contraintes relatives

5
Parmi toutes les contraintes temporelles d’une application temps réel on est amené à distinguer
contraintes strictes et les contraintes relatives :

 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 C’est un 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 toutes les échéances de toutes les activités
6
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 C’est un 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.
La définition que l’on donne généralement d’un système temps réel (par exemple : « Une application
est qualifiée de temps réel lorsqu’elle met en œuvre un système informatique dont le fonctionnement
est assujetti à l’évolution dynamique de l’état de son environnement » 1 ) ne permet pas de cerner
totalement la spécificité de ces systèmes. Aussi avons nous préféré les définir en décrivant les
caractéristiques fondamentales que possède tout système temps réel.

Un système temps réel, c’est 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

1 Rapport de 1988 du groupe de réflexion Temps réel du CNRS.

8
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.
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 actionneur 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 continu qui doit être discrétisé pour pouvoir être traîté par le calculateur. Cette
discrétisation ou numérisation est réalisée par un circuit appelé Convertisseur AnalogiqueNumé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

9
(exemple : présence/non-présence d’un objet, seuil de température atteint/nonatteint, récipient vide/non-
vide, etc.).

1.3.2.2 Actionneur

Le capteur 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 :

10
  d’une vanne hydraulique qui peut être commandée par un signal booléen (ouverte/fermée) ;
 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

11
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 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.4.3. Maîtrise des coûts matériels

Les performances des systèmes temps réel ne cessent de s’améliorer. Ce gain en performance
se traduit par un accroissement de la complexité matérielle : des microprocesseurs de plus en plus
puissants doivent être utilisés non seulement pour garantir les contraintes temps réel mais aussi pour
piloter efficacement les capteurs et actionneurs dont le nombre tend à croître avec le niveau de
performance recherché. Le coût induit par le système temps réel sur le coût d’un système automatisé
devient donc de plus en plus important. La consommation électrique et l’encombrement augmentent
aussi de manière significative avec le nombre de composants utilisés. La réalisation de tels systèmes
impose donc de concevoir un système devant satisfaire des contraintes souvent contradictoires de coût
et de puissance.
En effet, de fortes contraintes temps réel imposeront l’utilisation de calculateurs puissants basés
sur des processeurs cadencés à des fréquences élevées. Or en micro-électronique, l’utilisation de
fréquences élevées est synonyme de consommation électrique plus élevée ce qui va à l’encontre des
contraintes de consommation d’énergie. De la même manière, réduire la consommation électrique
pourra nécessiter d’utiliser des composants spécifiques à faible consommation qui sont souvent plus
coûteux que leur équivalent “forte consommation”. C’est le cas des ordinateurs personnels ; à puissance
égale un ordinateur portable est beaucoup plus coûteux qu’un ordinateur de bureau.
Réaliser un système temps réel optimal pour toutes ces contraintes relève de l’utopie. Prendre
en compte toutes les contraintes en même temps nécessite de réaliser des compromis permettant de
définir une solution non optimale mais globalement satisfaisante pour toutes les contraintes.

Un bon moyen de satisfaire globalement toutes les contraintes est de minimiser le nombre de
composants nécessaires à l’application. Nous analysons ici brièvement différents moyens d’y arriver :
12
Limiter le nombre de capteurs

Les capteurs sont utilisés pour réaliser soit l’acquisition d’une consigne, soit, dans un système bouclé,
pour réaliser le feedback. On pourrait faire l’économie de capteurs en utilisant des systèmes non bouclés,
c’est-à-dire sans feedback , mais ces systèmes sont moins performants et nécessitent un modèle fin du
processus. Dans la plupart des cas, l’utilisation d’un système bouclé est obligatoire car il n’est pas
possible de réaliser un modèle assez fin du processus. C’est le cas par exemple, d’un système
d’asservissement en vitesse d’un véhicule dit “cruise control”, pour lequel le conducteur fixe une
consigne de vitesse grâce à deux boutons positionnés sur le volant. Le véhicule doit alors maintenir cette
vitesse sans l’intervention du conducteur.

Le système temps réel chargé de réaliser cette fonction doit, à partir de la consigne, calculer une
commande à appliquer au carburateur. Il est ici impossible de définir une relation simple entre le débit
d’essence et la vitesse du véhicule, car cette vitesse est fonction de nombreux paramètres tels que la
charge du véhicule, le vent, la pente de la route, etc., un capteur de vitesse est donc ici indispensable.
Bien que l’utilisation de systèmes en boucle ouverte n’est généralement pas envisageable, il est quand
même parfois possible de limiter le nombre de capteurs en les partageant entre plusieurs fonctionnalités
que doit assurer le système. Par exemple, dans le cadre d’une automobile, un seul capteur de vitesse
pourrait être utilisé pour l’implantation du cruise control et pour la commande efficace d’une boîte de
vitesse automatique et d’un système de freinage ABS.

13
Limiter le nombre d’actionneurs

L’actionneur est l’élément qui agit physiquement sur le processus, supprimer un actionneur revient donc
à supprimer une fonctionnalité du système, ce n’est donc pas ce que l’on recherche.

Réduire les câblages Le câblage peut représenter une part importante du coût global d’une application.
C’était le cas il y a quelques années dans les applications automobiles. Certains véhicules bien équipés
pouvaient intégrer jusqu’à quatre ou cinq kilomètres de câble électrique, et plus de 1000
interconnexions. Le système temps réel était alors construit autour d’un calculateur central sur lequel
était connecté tous les capteurs et actionneurs. Cette architecture dite centralisée imposait un câblage en
étoile pour relier tous ces capteurs et actionneurs au calculateur. On peut minimiser ce câblage en
rapprochant le calculateur des actionneurs grâce à l’utilisation d’un calculateur multiprocesseur, dont
chacun des microprocesseurs est positionné le plus près possible d’un ensemble de capteurs et
actionneurs.

Limiter le nombre de composants du calculateur

Il existe au moins deux moyens de réduire le coût induit par le calculateur. Tout d’abord on va chercher
à utiliser des microcontrôleurs, plutôt que des microprocesseurs. Pour une puissance de calcul et un
ensemble d’interfaces E/S équivalents, un microcontrôleur nécessitera beaucoup moins de composants
externes qu’un microprocesseur. On cherchera ensuite à réduire la puissance de calcul nécessaire à
l’application qui peut être exprimée sous la forme du rapport (nombre de calculs à exécuter)/(contrainte
de temps d’exécution des calculs). Quelle que soit l’architecture matérielle retenue, les contraintes temps
réel doivent être satisfaites, la seule manière de diminuer la puissance de calcul nécessaire à la réalisation
d’une application donnée consiste donc à réduire le nombre de calculs à exécuter. Il faut donc utiliser
au mieux le calculateur en concevant des programmes optimisés.

Le domaine des transports développe un nombre croissant de systèmes temps réel embarqués pour
lesquels les contraintes de coût sont particulièrement sévères. Ceci est particulièrement vrai dans le
domaine de l’automobile où la forte compétitivité a incité les industriels à rechercher des technologies
permettant de construire des systèmes temps réel de plus en plus performants à moindre coût. Ainsi,
l’architecture matérielle du système temps réel a évolué en prenant en compte les différentes solutions
visant à minimiser le nombre de composants que nous venons d’énumérer. C’est à travers l’exemple
significatif de l’automobile que nous présentons ici chronologiquement les différents types
d’architecture témoins de cette évolution. Ce domaine est un bon exemple pour illustrer la complexité
de conception des systèmes temps réel embarqués car il regroupe a peu près toutes les contraintes que
l’on trouve dans d’autres domaines : sécurité (comme pour les applications médicales et avioniques),
gros volume de production et sensibilité aux coûts ( comme pour les produits de consommation courants
et les télécommunications), acquisition de données et contrôle (comme pour le domaine de la robotique),
traitement du signal et communications (comme pour le domaine des télécommunications), fortes
contraintes temps réel (comme pour le domaine militaire et aéronautique).

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

14
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.

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é

15
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.

 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

16
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.

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

17
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…)

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 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

18
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
 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)

19
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é)

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

21
1.9.5. Systèmes temps réel 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

é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 :

22
 Initialisation

Acquisition des données

d’entrée

Traitements primaires

Écriture des sorties

envoi des commandes,

Traitements secondaires

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.9.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 :

23
  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é :

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

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.
24
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 pile1. 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.

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 inerruption

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.

1Ce 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.
25
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 :

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
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édures 1 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.

1Parmi 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.
26
 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.

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’application1.
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

1Dé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.
27
 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 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âches, 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.

Conclusion
Comme nous pouvions déjà le déduire du chapitre 1 Qu’est-ce qu’un système temps réel ?, le modèle de
construction d’un système informatique temps réel se caractérise d’abord par la manière dont le système
informatique interagit avec le monde extérieur.

Dans le cadre de l’approche monotâche de construction d’un tel système informatique, nous avons
décrit de façon relativement détaillée les modes d’interaction du système avec son environnement, c’est-
28
à-dire la façon dont sont gérées les entrées/sorties : cette interaction peut se faire par interruption, par
scrutation cyclique des périphériques d’E/S ou par une combinaison de ces deux modèles d’interaction.
Nous avons cependant signalé que ces modes d’interaction entre le système informatique et son
environnement pouvaient être mis en œuvre, de façon similaire, dans un système informatique temps
réel construit selon une approche multitâche.
Parfaitement justifiée pour une application simple, l’approche monotâche a ses limites, et présente de
nombreux inconvénients dès que croit la complexité de l’application en termes de nombre et de diversité
des périphériques E/S à gérer et des traitements à réaliser.

De plus en plus s’impose l’approche multitâche, car elle conduit à une meilleure structuration du
programme informatique. En contre partie, la mise en œuvre d’un système temps réel multitâche fait
appel à un certain nombre de concepts fondamentaux et pose un certain nombre de problèmes
spécifiques. Nous entrons dans le domaine des systèmes constitués d’agents actifs (ou tâches)
concurrents et coopérants (concurrents pour l’accès à des ressources partagées, et coopérants pour la
réalisation de l’objectif global de l’application). Les chapitres suivants de ce support de cours vont
précisément traiter de ces différents aspects de la programmation multitâche.

29
Chapitre 2 : Les concepts de base des systèmes multitâches
Nous avons vu que l’approche multitâche dans le développement du logiciel d’un système temps réel
présente des avantages indéniables et même décisifs lorsqu’il s’agit d’une application temps réel
complexe.

La mise en œuvre d’un système temps réel multitâche fait appel à un certain de concepts fondamentaux
et pose un certain nombre de problèmes qui sont maintenant bien identifiés. La conception et la
réalisation d’un logiciel temps réel multitâche relève en effet du domaine des systèmes constitués
d’agents actifs (ou tâches) concurrents et coopérants (concurrents pour l’accès à des ressources
partagées, et coopérants pour la réalisation de l’objectif global de l’application). 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 dans le temps ;
 L’accès concurrent des tâches à des ressources partagées ;  La synchronisation et la
communication entre les tâches.

2.1 Les tâches

2.1.1 Qu’est-ce qu’une tâche ?

Une tâche est un agent actif responsable de l’exécution d’un programme par une machine. La tâche
représente l’unité de base de l’activité d’un processeur. Elle est référencée, exécutée et ordonnancée
comme un tout.
Une tâche est séquentielle, en ce sens qu’elle ne peut entreprendre l’exécution d’une instruction de ce
programme qu’après avoir terminé l’exécution de l’instruction précédente. On distingue deux types de
tâches : les tâches immédiates et les tâches différées :
Une tâche immédiate est une tâche programmée assurant l’interface entre le système et son
environnement. L’exécution d’une tâche immédiate démarre sur occurrence d’un signal émis par
l’interface associée. Sur les machines actuelles ce démarrage est réalisé par le mécanisme d’interruption.
Une tâche différée est une tâche dont l’activation est demandée par une autre tâche. Les tâches différées
effectuent des traitements pour le compte de l’application à partir de données fournies soit par les tâches
immédiates soit par d’autres tâches différées.

2.1.2 Les éléments constitutifs d’une tâche Une

tâche dispose de trois zones de mémoire :
La zone programme qui contient les instructions du programme auquel la tâche est associée. Cette zone
est considérée comme une zone de données constantes, accessible uniquement en lecture. La zone de
données contenant les données variables et les constantes initialisées. Cette zone est accessible en lecture
et en écriture.
La zone de pile qui permet de ranger les informations temporaires (variables locales, adresses de retour
de sous-programmes, etc.). Cette zone est généralement accessible en lecture et en écriture.

Une tâche possède :

30
Un contexte d’exécution caractéristique de la machine sur laquelle la tâche s’exécute, un
descripteur qui rassemble les informations nécessaires à sa gestion.
Une tâche possède au minimum les attributs caractéristiques suivants, définis dans son descripteur :
 un nom,
 une priorité,
 un état.
La manipulation d’une tâche se fait par l’intermédiaire de son descripteur.

2.1.3 Contexte d’exécution d’une tâche

On appelle contexte d’exécution d’une tâche l’ensemble des informations strictement nécessaires à un
processeur pour en assurer l’exécution. Autrement, on peut définir un contexte d’exécution comme étant
l’ensemble des informations qu’il faut sauvegarder pour permettre la reprise ultérieure de la tâche lorsque
son exécution est interrompue.

Il comprend notamment :

 le mot d’état du processeur,

 les registres à usage général,  les
registres de segment mémoire.

Le mot d’état du processeur se compose du registre d’état (ou registre des indicateurs) et du compteur
ordinal (ou pointeur d’instruction).
On appelle contexte mémorisé d’une tâche, la zone mémoire propre à cette tâche dans laquelle est rangé
le contexte d’exécution de la tâche lorsque celle-ci n’est pas en cours d’exécution.

2.1.4 Les opérations élémentaires sur une tâche

Une tâche fait l’objet des quatre opérations élémentaires suivantes :

Création. La création d’une tâche consiste à associer à un nouveau nom de tâche tous les éléments
nécessaires à l’exécution de cette tâche (place mémoire, code, données, pile, …).

Destruction. La destruction d’une tâche consiste à effacer l’association précédente.

Démarrage. Le démarrage d’une tâche consiste à la rendre candidate à l’exécution.

Arrêt. L’arrêt d’une tâche consiste à suspendre son exécution.

Une tâche appartient à une machine tout au long de son existence. Si deux tâches appartiennent à la
même machine, elles sont dites voisines, dans le cas contraire, elles sont distantes. 2.1.5. Les
caractéristiques des tâches temps réel
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

31
nous évoquons ci-après peuvent influencées cet ordonnancement. Il s’agit de la priorité utilisateur et la
périodicité des tâches.
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 essentielles : Ce sont des tâches dont les contraintes son 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 et selon leur ordre d’arrivée ou selon
un ordre décidé par l’utilisateur.
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 : 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

D in est déterminée par l’occurrence de la (n+1)ème exécution de Ti (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. Voici la figure de représentation des tâches périodiques.
Première occurrence ième Ti
n occurrence de
T

Ti Ti

S i1 S i 2

Di1= Ri1+ Pi Din = R i1+ n P i

Figure 11 : Représentation d’une tâche périodique

32
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.
La figure 12 suivante représentent les tâches périodiques, apériodiques et sporadiques

Tâches périodiques Tâches apériodiques Tâches sporadiques

Activation i Activation i+1 Activation i Activation Activation i Activation

i+1 i+1

Fixe
Aléatoire Aléatoire
Figure 12 : Représentation des tâches périodiques, apériodiques et sporadiques

Une tâche non préemptible ne peut être interrompues qu’à des endroits spécifiques et à la demande
des 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.

33
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.

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 temps réel T est décomposé en termes de
tâches Ti , i 1,...,n ( T = (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 de Ei . 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 ( Eresti ) à partir du
temps atteint ( Eatti ), c'est-à-dire Ei = Eatti + Eresti . 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 :

34
Si : C’est la date à laquelle une tâche Ti accède à la ressource selon l’algorithme 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 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 - R i . Le temps
de latence n’est pas constant. En effet, plus une tâche Ti est retardée plus son temps de latence diminue.

U i : C’est le taux d’utilisation du processeur dédié à la tâche Ti . Il s’exprime par la formule : U i =

Ei
. Le taux global d’utilisation sera la somme de tous les U i . Pour les tâches périodiques, le taux Pi
d’utilisation du processeur ou le pourcentage de l’activité du processeur dédié à la tâche Ti est donnée

par : U i = C i , et la Charge processeur = taux d’utilisation du processeur pour les tâches périodiques

Pi
Ci
est donnée par U = n . Lorsque U > m alors l’application est non ordonnançable sur m i 1 Pi
processeurs.

N.B. L’ensemble de ces paramètres doit vérifier les contraintes suivantes :

Ai < Ri < Si < Ci - Ei < Di - E i

Schématiquement, nous pouvons illustrés la modélisation des paramètres temporels d’une tâche Ti temps
réel de la manière suivante :

35
 1 + 2 = TL i Ti
Temps de latence de

Ti TR
peut i
Temps de réponse de Di Ti
Echéance de

Ti

Ri Ei Ti
Temps d’exécution de
Ti Ti Ti

Si Li Ci
Ti t
Tâche
Ti
Ti Fin d’exécution de
accède au
processeur
Ti
ne peut plus s’exécuter
Li Di
après sans dépasser

Figure 13 : modélisation des paramètres temporels d’une tâche Ti

Remarque

Dans certains STR, l’échéance est modélisée par une fonction a 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.
2.2 L’ordonnancement des tâches
Les systèmes informatiques temps réel sont des systèmes multitâches c’est-à-dire décomposables en
plusieurs tâches qui sont associées à des traitements particuliers. Ces traitements sont généralement
déclenchés par des événements. En fonction de la fréquence de ces événements, on distingue plusieurs
tâches comme nous l’avons vu dans la section précédente. Pour garantir la réactivité d’un système temps
réel, on impose des échéances temporelles aux tâches : une fois activée par l’occurrence d’un événement,
une tâche dispose d’une durée limitée pour effectuer le traitement qui lui est associé. En conséquence,
l’ordre selon lequel les tâches sont exécutées est primordial. Pour déterminer un ordre permettant de
garantir le respect de toutes les échéances, on utilise une politique d’ordonnancement.
Dans un système informatique multitâche, il se pose donc le problème de l’organisation de l’exécution
des tâches dans le temps, c’est-à-dire de l’ordonnancement de celles-ci en fonction d’une certaine
politique.
L’organisation de l’exécution des tâches par les processeurs du système est appelée ordonnancement
temps réel de ces tâches. Cet ordonnancement doit satisfaire les contraintes temporelles de l’application

36
; la règle d’organisation de l’exécution de tâches qu’il met en œuvre est appelée politique
d’ordonnancement.
2.2.1 Qu’est-ce qu’un ordonnanceur ?

On appelle ordonnanceur un module (câblé, micro-programmé ou programmé) chargé de gérer un

ensemble de processeurs pour le compte d’une famille de tâches.

Cette gestion consiste, en fonction d’un certain algorithme de choix, à :

 attribuer les processeurs (libres ou libérés) aux tâches prêtes à commencer ou à continuer leur
exécution,
 à reprendre le processeur à une tâche : soit à sa demande explicite (par exemple, lorsque la tâche

se met en attente d’une condition), soit inconditionnellement ; on parle dans ce cas de préemption

ou de réquisition du processeur

au profit d’une autre tâche.

Les machines actuelles sont généralement gérées par deux types d’ordonnanceurs :

 l’ordonnanceur des tâches immédiates, dit ordonnanceur câblé,

 l’ordonnanceur des tâches différées, dit ordonnanceur programmé.

2.2.2 Préemption du processeur

Lorsqu’il reçoit une demande qui conduit à mettre une tâche dans l’état Prêt, un ordonnanceur a la
possibilité, en fonction de son algorithme de choix et des attributs de cette tâche, de prendre le processeur

37
 Ordonnanceur

câblé Td_1

Ti_1
Td_2

Ti_2 Ordonnanceur

programmé Td_m
Ti_n

Domaine des Domaine du noyau de Domaine des

l’exécutif temps réel
tâches immédiates tâches différées
Figure 14 : Ordonnanceur
d’une tâche en cours pour l’attribuer à cette tâche. Cette action s’appelle préemption (ou réquisition) du
processeur.

2.2.3 L’ordonnanceur câblé

L’ordonnanceur des tâches immédiates correspond au système de gestion des interruptions de la
machine.
L’algorithme de choix de cet ordonnanceur est le plus souvent basé sur les priorités associées aux
interruptions. L’algorithme de choix de l’ordonnanceur câblé est de la forme suivante :
Examiner séquentiellement les niveaux d’interruption depuis le niveau de priorité maximum jusqu’à
celui de la priorité courante ;
Pour l’un quelconque de ces niveaux d’interruption, si le signal associé à l’interruption est arrivé et si
l’interruption n’est pas masquée, alors :

 sauvegarder le contexte de la tâche immédiate courante,

 démarrer la tâche immédiate associée au niveau d’interruption considéré.

Cet algorithme peut être exécuté par le processeur en tout point d’interruptibilité de la tâche en cours. La
fin de l’exécution d’une tâche immédiate relance la tâche immédiate la plus prioritaire parmi celle prêtes
à être exécutées.

2.2.4 L’ordonnanceur programmé

L’ordonnanceur des tâches différées gère les tâches suivant un algorithme de choix (ou algorithme
d’allocation) qui est imposé par le type de l’exécutif temps réel.
Les exécutifs temps réel se divisent en deux catégories :
 Les exécutifs non préemptifs (ou sans réquisition du processeur). La tâche en cours conserve
le processeur jusqu’à ce qu’elle fasse appel à un service de l’exécutif.

38
  Les exécutifs préemptifs (ou avec réquisition du processeur). A tout instant la tâche en cours
peut, sans qu’elle le sache, se voir retirer son processeur pour qu’il puisse être attribué à une
tâche plus prioritaire.
Une tâche différée peut demander d’être mise en attente d’une condition. L’ordonnanceur lui retire son
processeur si la condition attendue n’est pas satisfaite. Il lui attribue un processeur dès que cette condition
est satisfaite et compte tenu de son algorithme de choix.
2.2.5 Les états d’une tâche
Afin de représenter ces relations, on introduit pour une tâche les états suivants :
En cours (ou élu) : état d’une tâche qui s’exécute sur un processeur.
Prêt : état d’une tâche dont toutes les conditions d’exécution sont satisfaites mais qui ne possède pas
encore de processeur pour s’exécuter.
En attente (ou bloqué) : état d’une tâche en attente d’une condition non satisfaite.
Le changement d’état d’une tâche conduit à un changement de contexte. Un changement de contexte
consiste à remplacer le contexte d’exécution d’une tâche par celui d’une autre tâche.

(3)

En cours
En attente
(1) (2)

Prêt
(4)

Figure 15 : Les états d’une tâche

(1) allocation d’un processeur
(2) préemption (ou réquisition) du processeur
(3) mise en attente (blocage) de la tâche jusqu’à ce qu’une condition soit satisfaite
(4) réveil de la tâche suite à la satisfaction de la condition attendue par la tâche
2.2.6. 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).

39
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 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-après :
 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…).
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).
La figure ci-dessous montre l’architecture type d’une application temps réel : tâches et noyau temps réel

Figure 16 : Architecture type d’une application 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

40
(partie temps réel du noyau). Ensuite le noyau temps réel réactive une tâche de l’application selon
l’algorithme d’ordonnancement utilisé (partie générique du noyau).
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.
2.2.7. 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 :
- 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.
Le Graphe des états possibles d’une tâche est schématisé ci-après :

Figure 17 : 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.
2.3 L’accès concurrent des tâches à des ressources partagées
2.3.1 Notion de ressource
Pour qu’elle puisse évoluer une tâche a besoin de procédures et de données, de mémoire destinée à les
contenir, de l’unité centrale, et éventuellement de fichiers et de périphériques. Nous appelons toutes ces
entités des ressources.

41
Nous désignons donc par ressource tout objet dont peut avoir besoin une tâche pour son exécution. Pour
une présentation détaillée de la notion d’objet, voir l’annexe de ce chapitre. A une ressource sont
toujours associées des procédures d’accès qui permettent de l’utiliser, et des règles d’utilisation qui
constituent son « mode d’emploi ».
Il n’y a donc pas de distinction fondamentale entre la notion d’objet et la notion de ressource. On parle
plutôt d’objet lorsqu’on s’intéresse à la spécification et à la réalisation de l’objet et de ses fonctions
d’accès, et plutôt de ressource lorsqu’on s’intéresse aux problèmes d’allocation et de partage.
On dit qu’une ressource est allouée à une tâche lorsque celle-ci peut utiliser la ressource.
L’acquisition de la ressource par la tâche peut être implicite ou explicite :
Dans le premier cas, l’existence même de la tâche ou son passage dans un certain état rend la tâche
candidate à l’usage de la ressource ;
Dans le second cas, la demande doit être explicitement formulée sous la forme d’une requête adressée à
un allocateur de la ressource.
La fin de l’utilisation d’une ressource par une tâche peut également prendre plusieurs formes :

libération explicite ou implicite de la ressource par la tâche, ou réquisition, c’est-à-dire

retrait forcé de la ressource par l’allocateur.

2.3.2 Accès aux ressources

Une ressource est dite locale à une tâche si elle ne peut être utilisée que par cette tâche.
La zone des données et la zone de pile propres à une tâche sont des exemples typiques de ressources
locales.
Une ressource qui n’est locale à aucune tâche est dite commune.
Une ressource commune est dite partageable avec n points d’accès (n >= 1) si cette ressource peut être
attribuée, au même instant à au plus n tâches.
Une ressource partageable à un seul point d’accès est dite critique.
Des tâches sont dites indépendantes si elles n’ont que des ressources locales. Elles sont dites parallèles
pour une ressource si elles peuvent simultanément utiliser cette ressource, et en exclusion mutuelle s’il
agit d’une ressource critique.
Exemple 1 : Une unité centrale est une ressource à un seul point d’accès : toutes les tâches sont en
exclusion mutuelle pour cette ressource.
Exemple 2 : Un programme réentrant est une ressource à un nombre illimité de points d’accès.
Le mode d’accès à une ressource peut évoluer dynamiquement.
Ainsi un fichier est :
 une ressource à une infinité de points d’accès quand il est ouvert en lecture,
 une ressource critique quand il est ouvert en écriture.

2.3.3 Problèmes posés par l’accès à des ressources critiques

Des tâches peuvent donc être en compétition pour utiliser une ressource critique, c’est-à-dire un objet
qui ne peut, à un instant donné, être utilisé que par une seule tâche. On dit alors que les tâches sont en
exclusion mutuelle pour l’usage de cette ressource.

42
Le problème de l’accès de plusieurs tâches à une ressource critique conduit à sérialiser de façon
convenable, pour les actions qui mettent en jeu cette ressource, l’exécution des tâches en compétition.
Si cette sérialisation n’est pas faite de façon convenable, peuvent se produire des phénomènes qui
conduisent à un dysfonctionnement grave de l’application multitâche. Il s’agit notamment des deux
phénomènes typiques suivants :
1. La famine ou privation
Une tâche est en famine (starvation) lorsqu’elle n’arrive jamais à disposer de la ressource critique dont
elle a besoin. En d’autres termes, la satisfaction de sa demande d’une ressource critique peut être
indéfiniment retardée au profit d’autres tâches.
2. L’interblocage ou étreinte fatale
Plusieurs tâches sont en interblocage (dead lock) lorsque chacune d’elles détient une partie des ressources
critiques nécessaires à la poursuite de son activité.
Dans une telle situation, chaque tâche attend de pouvoir disposer d’une ressource critique qui est
possédée par une autre tâche ; cette dernière ne peut libérer la ressource car à son tour elle attend
pour continuer son exécution la disponibilité d’une ressource possédée par une autre, et ainsi de
suite. Ces tâches sont donc bloquées indéfiniment, car chacune d’elles ne peut être réveillée que
par l’autre.
2.3.4 Les procédures réentrantes

Dans l’approche multitâche, il convient de donner une qualité particulière à certaines procédures dans la
mesure où celles-ci peuvent être partagées simultanément par plusieurs tâches.
On dit qu’une procédure est réentrante si elle peut être appelée simultanément et sans conflit par
plusieurs tâches.
Une procédure réentrante est une ressource partagée dont le nombre de points d’accès
est illimité.
Dans une procédure réentrante, seul le code est effectivement partagé. Les variables et données sur
lesquelles s’effectuent les opérations du programme sont propres à chaque exécution de celui–ci.
A chaque appel d’une procédure réentrante sont donc transmis à la procédure un ou plusieurs
pointeurs sur les données et variables qui font l’objet des opérations de traitement de la
procédure.
La réentrance est une propriété qui permet de réduire considérablement la taille d’un logiciel. Elle permet
également de faciliter sa maintenance.

2.4 La synchronisation et la communication entre les tâches

2.4.1 Relations entre tâches
Deux tâches sont en relation, c’est-à-dire ne sont pas indépendantes, si l’une des deux peut rendre une
ressource accessible à l’autre, ou la priver de cette ressource. Finalement deux tâches sont en relation si
l’une des tâches peut faire changer l’autre d’état.
Deux aspects fondamentaux sont à considérer :
la synchronisation proprement dite entre tâches, c’est-à-dire le fait de permettre à une tâche active de
changer d’état ou de faire changer d’état une autre tâche, et la communication de données d’une tâche
à l’autre.

43
2.4.2 La synchronisation entre tâches
Les diverses tâches d’un système temps réel n’évoluent généralement pas indépendamment les unes des
autres. Il existe entre elles des relations qui dépendent de la logique de l’action à accomplir et qui fixent
leur déroulement dans le temps.
On désigne l’ensemble de ces relations sous le terme de synchronisation. Celles-ci ne font pas intervenir
le temps comme mesure de durée mais seulement comme moyen d’introduire une relation d’ordre entre
les instructions exécutées par les tâches.
Le problème de l’accès de plusieurs tâches à une ressource critique est un cas particulier du problème de
la synchronisation entre tâches.
2.4.3 La communication entre tâches
La coopération de plusieurs tâches à l’exécution d’un travail commun nécessite en général un échange
d’informations entre ces tâches.
La synchronisation entre tâches réaliser un mode de communication où l’information transmise est
réduite à la forme élémentaire d’une autorisation ou d’une interdiction de continuer l’exécution audelà
d’un certain point prédéterminé.
Ce mode de communication ne suffit pas à tous les besoins. Ainsi, lorsque les actions exécutées par une
tâche après son activation dépendent de l’identité de la tâche activatrice et de la valeur de certains
paramètres, ces informations doivent pouvoir être transmises à la tâche activée.
Communication par variables communes
La communication entre tâches peut être réalisée par accès à un ensemble de variables communes. Les
tâches en communication doivent s’imposer un mode d’emploi de ces variables communes de façon qu’à
tout instant soit assurée la cohérence de leurs valeurs.
Communication par messages
Ce mode de communication peut être schématisé de la façon suivante :
Une tâche T1 envoie un message à la tâche T2, c’est-à-dire T1 fournit de l’information à T2, et T2 est
prévenue de la disponibilité de cette information.
La tâche T1 peut attendre ou ne pas attendre un accusé de réception ou un compte-rendu de la tâche T2
pour continuer.
La tâche T2 qui attendait un message reçoit le message de la tâche T1. Elle envoie ou n’envoie pas
d’accusé de réception ou de compte-rendu à la tâche T1.
On voit que l’arrivée d’un message provoque le réveil du destinataire en attente ; le protocole de
communication par messages incorpore donc un dispositif de synchronisation.
Ces mécanismes de communication par messages, mécanismes dits de haut niveau par rapport à une
communication par variables communes, permettent l’échange de données entre tâches en évitant au
programmeur les détails de la réalisation de l’exclusion mutuelle et de la synchronisation.

44
Chapitre 3 : Les techniques classiques d’ordonnancement des
tâches
Nous avons vu que le rôle de l’ordonnanceur des tâches (différées) consiste, en fonction d’un algorithme
de choix, à :
 attribuer les processeurs (libres ou libérés) aux tâches prêtes à commencer ou à continuer leur
exécution,
 à reprendre le processeur à une tâche :
soit à sa demande explicite (par exemple, lorsque la tâche se met en attente d’une condition comme la
réception d’un message ou l’occurrence d’un événement),
soit inconditionnellement, alors que la tâche a encore besoin du processeur ; cette opération est appelée
réquisition ou préemption du processeur.
La politique d’ordonnancement des tâches détermine quelle tâche présente dans la file des tâches prêtes
est élue, c’est-à-dire quelle tâche va se voir attribuer un processeur, après qu’éventuellement celui-ci ait
été retiré à une tâche en cours d’exécution. Le rôle de l’ordonnanceur consiste donc à attribuer les
processeurs aux tâches prêtes (ou éligibles) ou à les retirer aux tâches en cours.
L’invocation de l’ordonnanceur a lieu : lors de l’ajout d’une tâche dans l’ensemble des tâches
prêtes, lors de la libération d’un processeur quand une tâche passe de l’état en cours à l’état en attente
ou de l’état en cours à l’état hors service.
La politique d’allocation des processeurs est définie par :

l’algorithme d’entrée et de sortie d’une tâche de l’ensemble des tâches prêtes, l’algorithme
qui détermine la réquisition (ou la préemption) des processeurs.

L’ordonnanceur est constitué de l’ensemble des séquences de programme qui réalisent ces algorithmes.

Définition du problème de l’ordonnancement des tâches

Le système de conduite d’une application temps réel doit piloter le procédé physique en ordonnançant
les tâches avec deux objectifs majeurs :

 en fonctionnement nominal de l’application, à assurer le respect des contraintes temporelles

spécifiées,
 en fonctionnement anormal ou dégradé consécutif à des pannes des matériels ou autres
événements imprévus, à atténuer les effets des surcharges temporelles et à maintenir le procédé
dans un état cohérent et sécuritaire.

Ordonnancer les tâches d’une application temps réel consiste alors à planifier l’exécution des tâches de
façon à ce que soient respectées les contraintes de temps :

 de toutes les requêtes en fonctionnement normal,

 d’au moins les requêtes les plus importantes, c’est-à-dire celles qui sont nécessaires à la sécurité
du procédé, en fonctionnement anormal.
Selon les applications, on cherche en plus à satisfaire certains critères de performance comme minimiser
le temps de réponse ou réduire la gigue de certaines tâches, équilibrer la charge des sites, minimiser la
charge de communication, minimiser le nombre ou le retard cumulé des tâches ou des messages. Cette
planification est faite par un algorithme d’ordonnancement qui fournit une description de la séquence à
effectuer par les tâches, appelée séquence de planification.
45
3.2. Notions de base pour l’ordonnancement temps réel
3.2.1 États d’une tâche
Les états d’une tâche et les transitions entre ces états peuvent être représentés de la façon suivante :

4 en cours 7
(ou élue)
2

5 6 en attente
inexistante hors service
1 (ou bloquée)

3 prête 8

(ou éligible)
(1) création de la tâche (5) allocation d’un processeur

(2) destruction de la tâche (6) réquisition du processeur

(3) démarrage de la tâche (7) blocage de la tâche

(4) fin de la tâche (8) réveil de la tâche

Tâche inexistante : la tâche n’est pas encore créée ; elle est donc ignorée de l’exécutif temps réel.
Tâche hors service (ou passive) : la tâche n’a pas encore fait l’objet d’une opération de démarrage ou
lancement ; ou si elle a fait l’objet d’une telle opération son exécution est entièrement terminée.
Tâche prête (ou éligible) : la tâche demande un processeur pour s’exécuter ; éligible pour l’octroi d’un
processeur, elle attend d’être élue.
Tâche en cours (élue ou courante) : un processeur est alloué à la tâche ; possédant donc un processeur,
cette dernière peut s’exécuter.
Tâche en attente (ou bloquée) : la tâche est bloquée en attente d’une ressource, d’un message ou d’un
événement.
3.2.2 Notion de priorité d’une tâche
La priorité d’une tâche est une information qui permet de classer cette tâche parmi d’autres lors d’un
choix (par exemple, lors de l’ajout ou du retrait d’une file d’attente).
La priorité d’une tâche peut être définie de diverses façons : priorité fixe :
priorité définie a priori, priorité héritée de la tâche mère, etc.
priorité variable au cours du temps : priorité fonction du temps d’attente écoulé, du service déjà
rendu, etc.
La priorité est un entier positif, défini a priori ou hérité de la tâche mère, qui ne peut être modifié, dans
le cas d’un ordonnancement par priorité fixe, que par l’appel d’une primitive spécifique ou par des
mécanismes répondant tous à des critères de déterminisme (héritage temporaire de priorité lors d’une
demande de service, par exemple).
L’ordonnancement des tâches selon leur priorité permet de répondre aux contraintes de déterminisme
d’une application temps réel. En effet, pour être assuré que le système respectera les contraintes de temps
que lui impose l’environnement avec lequel il est en interaction, l’on doit savoir avec précision, pour
46
chaque traitement, quand il commencera et quand il se terminera, et ce, quelque soit le contexte ou l’état
du système à ce moment là. En d’autres termes, l’on doit être en mesure de préciser à partir de quand et
pour combien de temps, chaque tâche disposera de manière exclusive du processeur. L’ordonnancement
par priorité permet justement de déterminer de façon sûre l’ordre dans lequel les tâches prêtes obtiennent
le processeur.

3.1.3 Typologie des algorithmes d’ordonnancement

Les algorithmes d’ordonnancement peuvent être classés en fonction de différents critères.
Algorithmes hors ligne et en ligne
Un algorithme d’ordonnancement hors ligne construit une séquence complète de planification de
l’exécution des tâches sur la base de tous leurs paramètres temporels. Cette séquence, connue donc avant
l’exécution des tâches, peut ensuite être mise en œuvre très efficacement. Mais cette approche statique
de l’ordonnancement des tâches suppose que tous les paramètres, y compris les dates de réveil, soient
figés. Très rigide, elle ne peut donc s’adapter aux changements de l’environnement qui peuvent survenir
lorsque le système est en fonctionnement.
Un algorithme d’ordonnancement en ligne est capable, à tout instant de l’exécution de l’application, de
choisir la prochaine tâche à ordonnancer. Pour cela, il utilise comme informations les paramètres
temporels des tâches déclenchées à cet instant. Ce choix peut être remis en cause lors de l’occurrence
d’un événement nouveau sans que la date de cette occurrence n’ait à être connue à l’avance. Complexe
à mettre en œuvre, cette approche permet de gérer l’arrivée imprévisible de tâches et autorise la création
progressive de la séquence d’ordonnancement. Pour pouvoir traiter les tâches apériodiques et les
surcharges anormales, l’ordonnancement temps réel se fait le plus souvent en ligne. Algorithmes
préemptifs et non préemptifs

Un algorithme d’ordonnancement est soit préemptif soit non préemptif.

Avec un algorithme d’ordonnancement préemptif, une tâche élue peut perdre le processeur au profit
d’une autre tâche jugée plus urgente ou plus prioritaire ; elle passe alors à l’état prêt pour attendre d’être
élue ultérieurement sur le même processeur ou sur un autre processeur. Un algorithme préemptif n’est
utilisable que si toutes les tâches sont préemptibles.
Les ordonnanceurs non préemptifs n’arrêtent pas l’exécution des tâches élues. Celles-ci conservent
l’usage du processeur jusqu’à ce qu’elles fassent appel à un service de l’exécutif temps réel. Il peut en
résulter des fautes temporelles qu’un ordonnancement préemptif aurait permis d’éviter.
Sur support d’exécution monoprocesseur, l’utilisation d’un ordonnanceur non préemptif conduit à une
simplification de la gestion des ressources critiques ; il n’es plus nécessaire en effet de mettre en œuvre
les mécanismes d’exclusion mutuelle pour l’accès aux ressources critiques. Cependant, cette
simplification n’est plus possible avec un support d’exécution multiprocesseur.
Algorithmes centralisés ou répartis
L’ordonnancement est centralisé s’il s’exécute sur une architecture centralisée ou sur un site privilégié
de l’architecture distribuée qui contient l’ensemble des paramètres des tâches.
L’ordonnancement est réparti lorsque des décisions d’ordonnancement sont prises sur chaque site par
un ordonnancement local après une éventuelle coopération pour effectuer un ordonnancement global.
Dans ce dernier cas, peuvent aussi intervenir le placement des tâches sur un site et leur migration d’un
site à un autre.

47
3.2 Politiques d’ordonnancement classiques
3.2.1 Ordonnancement selon la stratégie « Premier arrivé, premier servi »
Dans l’ordonnancement selon la stratégie « premier arrivé, premier servi » (en anglais « First In, First
Out » ou FIFO) les tâches prêtes sont rangées suivant leur ordre d’arrivée dans une file d’attente unique.
La gestion de la file ne fait intervenir aucune notion de priorité entre les tâches ou, ce qui revient au
même, la gestion de la file est faite en considérant que toutes les tâches ont la même priorité.
Les tâches prêtes se voient attribuer un processeur uniquement en fonction de leur ordre d’arrivée dans
la file : la première arrivée est la première à laquelle est alloué un processeur.
La tâche en cours d’exécution sur un processeur s’exécute jusqu’à son terme ou jusqu’à ce qu’elle se
mette en attente d’une condition. La tâche en tête de la file des tâches prêtes devient alors la prochaine
tâche en cours.
Afin de ne pas monopoliser le processeur et donc de permettre aux autres tâches de commencer ou de
continuer leur exécution, la tâche en cours peut, alors qu’elle en a encore besoin pour son exécution,
libérer volontairement le processeur. Dans ce cas, elle est replacée en queue de la file des tâches prêtes.

Libération volontaire du

Fin de la tâche ou
T2 T5 T1 T6
Blocage de la tâche
Arrivée d’une Tâche en
File d’attente des tâches
prêtes cours
nouvelle
Attention ! Ce type d‟ordonnancement est un ordonnancement sans réquisition du processeur. La
libération du processeur par la tâche en cours ne peut se faire que lors de l’exécution d’une primitive. La
transition (6) (cf. Diagramme des états de la vie d’une tâche) correspond à une libération volontaire du
processeur par la tâche.

3.2.2 Ordonnancement circulaire ou selon la méthode du tourniquet

Dans cette stratégie d’ordonnancement le processeur est alloué successivement aux tâches prêtes pour
une durée fixe Q, appelée quantum.

Si une tâche se termine ou se bloque avant la fin du quantum de temps, le processeur est immédiatement
alloué à la tâche suivante dans la file des tâches prêtes.

Si, par contre, à l’expiration du quantum de temps, la tâche possède toujours le processeur, ce dernier lui
est retiré et elle est placée en queue de la file des tâches prêtes. Le processeur est ensuite alloué à la tâche
qui est en tête de la file.

Cette méthode d’ordonnancement est appelée la méthode du tourniquet (« Round robin »).
L’intervalle de temps Q est le paramètre essentiel de cette politique d’ordonnancement. Si Q tend vers
l’infini, on retrouve l’ordonnancement selon la stratégie « premier arrivé, premier servi ».

Ce type d’ordonnancement peut être mis en œuvre en insérant les tâches prêtes suivant leur ordre
d’arrivée dans une file d’attente unique. Comme dans la précédente méthode d’ordonnancement, l’on
considère que toutes les tâches ont la même priorité.

48
Attention ! Ce type d’ordonnancement est un ordonnancement avec réquisition du processeur.
L’expiration du quantum de temps peut intervenir à n’importe quel point d’exécution de la tâche en
cours. Les tâches doivent donc être préemptibles.

Cette politique du tourniquet est usuellement utilisée dans les systèmes à temps partagé. Sa performance
dépend largement de la valeur du quantum de temps. Ce dernier se situe généralement entre 10 ms et
100 ms.

3.2.3 Ordonnancement par priorité avec une seule tâche par niveau de priorité
Un niveau de priorité constant et différent est affecté à chaque tâche. A un instant donné, la tâche élue
est toujours la tâche de plus forte priorité.

Dans cette stratégie d’ordonnancement le processeur est alloué à la tâche prête la plus prioritaire. Cette
dernière conserve le processeur tant qu’elle n’est pas terminée ou bloquée, et tant qu’elle reste la tâche
prête la plus prioritaire.
Dès qu’une tâche plus prioritaire qu’elle passe dans l’état prêt, le processeur lui est retiré pour être alloué
à la nouvelle tâche prête.
Les tâches sont insérées dans la file des tâches prêtes en fonction de leur niveau de priorité.

Niveaux

-----

.
Fin de la tâche
Arrivée d’une . T3
ou nouvelle tâche 4 T3 Tâche en
cours
T5
3

File d’attente

Figure 18 : ordonnancement par priorité avec une seule tâche par niveau

On considère que le niveau 1 est le niveau le moins prioritaire.

3.2.4 Ordonnancement par priorité avec plusieurs tâches par niveau de priorité Cette
stratégie d’ordonnancement n’est qu’une généralisation de la précédente.

L’ensemble des tâches prêtes est mémorisé dans plusieurs files, une pour chacun des niveaux de
priorité

Une tâche qui passe dans l’état prêt est rangée en queue de la file associée à son niveau de priorité.

L’allocation des processeurs aux tâches prêtes de même niveau de priorité est faite :
49
 soit selon la stratégie « premier arrivé, premier servi », soit
selon la méthode du tourniquet.

L’ordonnancement par priorité avec plusieurs tâches par niveau de priorité, gérées selon la stratégie «
premier arrivé, premier servi », peut être décrit de la façon suivante :

Les tâches prêtes de même priorité sont rangées suivant leur ordre d’arrivée dans la file d’attente
associée à leur niveau de priorité.
La tâche en tête de la file de plus haute priorité s’exécute jusqu’à sa fin ou jusqu’au moment où
elle se bloque.
Quand une tâche de priorité supérieure passe dans l’état prêt, il y a réquisition du processeur : la
tâche de plus base priorité en cours d’exécution se voit retirer le processeur pour qu’il puisse
être attribué à la nouvelle tâche prête.
Une tâche qui modifie sa priorité ou qui libère volontairement le processeur est replacée en queue
des tâches de cette priorité prêtes à s’exécuter.

Dans le cas d’une politique d’ordonnancement par tourniquet, le quantum peut être différent selon le
niveau de priorité.
La libération volontaire du processeur par la tâche en cours peut se faire en utilisant la primitive
changerPriorité avec les paramètres : tâche := tâcheEnCours nouvellePriorité := anciennePriorité

50
Chapitre 4 : Réalisation de l’exclusion mutuelle
Nous avons vu que les tâches sont en exclusion mutuelle (ou encore en compétition) pour l’usage d’une
ressource critique (ressource partageable à un seul point d’accès).

Exemples de ressources critiques :

 compte d’un client

 imprimante
 tronçon de voie unique de chemin fer où les trains peuvent circuler dans les deux
sens
Dans le cas d’une imprimante dont l’usage est partagée par plusieurs tâches, l’emploi de cette
imprimante par une tâche exclut son emploi par une autre, tant que le travail d’impression pour la
première n’est pas terminé.

4.1 Problème d’accès à une variable partagée

Examinons en détail le problème d’accès en lecture et écriture à une variable globale, commune à
plusieurs tâches. Considérons, par exemple, deux tâches T1 et T2 qui doivent chacune mettre à jour une
variable commune m. Les opérations correspondent s’écrivent dans les programmes de T1 et de T2 :

Tâche T1 Tâche T2

A1 : m := m + m1 A2 : m := m + m2

Chacune de ces opérations est réalisée par une séquence d’instructions machine, comme par exemple :

Tâche T1 Tâche T2

LOAD R1, m (1) LOAD R2, m (1’)

ADD R1, m1 (2) ADD R2, m1 (2’)

STO R1, m (3) STO R2, m (3’)

R1 et R2 désignent des registres locaux respectivement à T1 et T2. Si

ces instructions machine sont exécutées dans l’ordre :

1 1’ 2’ 3’ 2 3

ou dans celui-ci : 1 2 1’ 2’ 3’ 3

leur effet global est d’exécuter m := m + m1 et non m := m + m1 + m2.

L’une des mises à jour a été perdue et la valeur finale de m est incohérente.

Pour éviter cette incohérence, les opérations A1 et A2 doivent être exécutées en exclusion mutuelle. On
dit aussi qu’elles constituent pour T1 et T2 des sections critiques.
Il faut que : fin (A1) < début (A2) ou bien que : fin (A2) < début (A1).
Cette condition de sérialisation qui revient à rendre les actions A1 et A2 atomiques et indivisibles est
identique à celle requise pour l’accès à une ressource physique critique.
Pour résoudre les problèmes que posent les accès concurrents aux ressources critiques, ont été définis
un certain nombre de mécanismes de gestion de ces accès. Nous allons les décrire en détail. Mais avant
de le faire, nous allons tenter de bien formaliser le problème de l’exclusion mutuelle.

4.2 Formalisation du problème de l’exclusion mutuelle

Soit (T1, …, Tn) un ensemble de tâches que nous supposons cycliques. Le programme de chacune d’elles
comporte une section critique.
On appelle section critique d’une tâche pour une ressource critique, une phase de la tâche pendant
laquelle la ressource est utilisée et donc inaccessible aux autres tâches.
L’exclusion mutuelle est assurée par deux séquences de programme (prologue et épilogue) qui
encadrent la section critique de chaque tâche. Nous supposons que toute tâche qui entre en section
critique en sort au bout d’un temps fini.
La solution du problème de l’exclusion mutuelle doit posséder les propriétés suivantes :
Exclusion mutuelle : A tout instant, une tâche au plus exécute la section critique de son programme (cf.
définition de la section critique).
Absence de blocage intempestif : Si aucune tâche n’est en section critique, aucune tâche ne doit être
bloquée par le mécanisme d’exclusion mutuelle.
Tolérance aux défaillances : La solution mise en œuvre doit rester valide en cas de défaillance d’une
ou plusieurs tâches en dehors de leur section critique.
Absence de privation : Une tâche qui a demandé à entrer en section critique ne doit pas attendre
indéfiniment (en supposant que toutes les tâches ont même priorité).
Symétrie : Le prologue et l’épilogue doivent être identiques pour toutes les tâches, et indépendants de
leur nombre.
Compte tenu de ces spécifications, nous cherchons à construire une solution de la forme :
< initialisation > commune à l’ensemble des tâches

< programme de la tâche Ti >

Répéter

< prologue > Entrée en section critique

< section critique >

< épilogue > Sortie de section critique

< reste du programme >

A l’infini

Décrire un mécanisme d’exclusion mutuelle, c’est en donner les trois séquences : initialisation,
prologue et épilogue.

52
4.3 Mécanismes élémentaires d’exclusion mutuelle
4.3.1 Description des mécanismes élémentaires
Au niveau même du matériel on dispose de mécanismes élémentaires pour réaliser l’exclusion mutuelle
d’accès à une ressource critique. Nous allons en décrire trois :

Lecture et mise à jour d’un emplacement mémoire

L’exclusion mutuelle pour l’accès à une variable partagée peut être assurée grâce à l’indivisibilité de
l’accès en lecture et écriture à un emplacement mémoire.

Tâche T1 Variable partagée Tâche T2

m := m + 1 m := m - 1
m
Si chacune des instructions m := m + 1 et m := m –1 est réalisée par une seule instruction
machine, alors l’exclusion mutuelle pour l’accès à cette variable partagée m est assurée du fait même
de l’indivisibilité (atomicité) des instructions machine.

Masquage des interruptions

Les instructions machine de masquage et de démasquage des interruptions peuvent dans certains cas
être utilisées pour réaliser l’exclusion mutuelle.

Dans la mesure où le processeur est seul à accéder à la mémoire, le masquage des interruptions est un
moyen pour la tâche qui effectue cette opération d’avoir la possession exclusive du processeur, et donc
l’accès exclusif à la mémoire. Sur machine monoprocesseur, le masquage des interruptions est donc une
condition suffisante pour garantir l’accès exclusif à des ressources critiques.

Avec cette méthode, la possession du processeur est en effet exclusive vis-à-vis des tâches différées
comme des tâches immédiates. En d’autres termes, avec le masquage des interruptions la préemption
du processeur est interdite tant au profit d’une tâche différée que d’une tâche immédiate.

Prologue : < masquer les interruptions >

Section critique

Épilogue : < démasquer les interruptions >

Instruction TEST and SET

Pour contrôler l’accès à la section critique on utilise une variable appelée verrou dont l’accès est
indivisible (elle occupe un seul emplacement de mémoire).

Par convention, si le verrou est à 0, la section critique est libre, s’il est à 1 elle est occupée.
Avant de pénétrer dans une section critique, la tâche teste le verrou qui en contrôle l’accès. S’il est égal
à 0, elle le positionne à 1 et entre sans tarder dans la section critique. Lorsqu’une autre tâche désire
entrer dans une section critique dont l’accès est contrôlé par le même verrou, elle trouve le verrou

53
positionné à 1 et se trouve forcée d’attendre qui celui-ci passe à 0. Cette façon d’attendre est appelée
attente active.

Pour éviter des aléas de fonctionnement, le test et le positionnement de la variable verrou doivent être
réalisés de manière indivisible.

Certaines machines possèdent une instruction qui réalise de manière indivisible la consultation et la mise
à jour d’un mot mémoire ; cette instruction est souvent appelée l’instruction Test and Set (TAS).

L’exclusion mutuelle peut alors être programmée de la façon suivante :

Initialisation : verrou := 0

Prologue : TAS verrou

si verrou = 1
BMI –1

section critique

Épilogue : verrou := 0

4.3.2. Caractéristiques et limites des mécanismes élémentaires

Dans tous ces mécanismes, l’utilisation directe des instructions de la machine est nécessaire pour réaliser
l’exclusion mutuelle. On ne peut donc pas utiliser les instructions d’un langage évolué. Le premier
mécanisme ne peut être mis en œuvre que si la taille de la variable partagée est telle que la lecture et la
mise à jour sont réalisables en une seule instruction machine.

Le mécanisme par masquage des interruptions présente l’inconvénient d’allonger le temps de réponse
aux interruptions. Ce temps peut alors se trouver modifié dans des proportions telles que les contraintes
de temps liées aux tâches immédiates ne peuvent plus être respectées. Il est donc impératif de limiter le
nombre d’instructions constituant la section critique au strict minimum, autrement dit, il faut construire
des sections critiques les plus courtes possibles.

Le mécanisme d’exclusion avec attente active n’est pas une solution économique pour des tâches
pseudo-parallèles car elle consomme inutilement du temps processeur1. L’attente active présente d’autre
part un risque d’interblocage.

Supposons que la tâche dans la section critique se voit retirer le processeur au profit d’une tâche plus
prioritaire qui désire accéder à une section critique contrôlée par le même verrou que celui contrôlant la
section critique dans laquelle se trouve la tâche interrompue. Que se passe-t-il ? La section critique ne
sera pas libérée et le verrou restera à 1.

4.3.3 Quand utilise-t-on les mécanismes élémentaires ?

1Elle est admissible sur machine multiprocesseur pour des séquences brèves ou lorsque le processeur
mobilisé par l’attente n’est pas réutilisable pour une autre activité.
54
Les mécanismes élémentaires d’exclusion mutuelle sont utilisés lors d’une implantation directe du
logiciel d’application sur une machine « nue », c’est-à-dire lorsqu’on n’utilise pas un exécutif temps
réel.

Dans la réalisation du noyau d’un exécutif temps réel, les mécanismes élémentaires d’exclusion mutuelle
sont utilisés pour garantir :

l’accès exclusif aux objets manipulés par les opérations élémentaires du noyau, la non-préemption du

processeur pendant tout le temps où l’on dispose de l’accès exclusif à ces objets.

Sur machine monoprocesseur l’indivisibilité des opérations élémentaires (ou primitives) du noyau est
réalisée en utilisant le masquage des interruptions.

Sur machine multiprocesseur, l’indivisibilité des opérations élémentaires du noyau est réalisée en
utilisant conjointement :

le masquage des interruptions et

des verrous dont le test et le positionnement à 1 doivent se faire de manière indivisible (cf. instruction
TAS).

Prologue : Masquer les interruptions

E TAS verrou
Si verrou = 1 alors : aller en E finSi

Épilogue : verrou := 0
Démasquer les interruptions

Lorsque le logiciel d’une application temps réel fait appel aux services d’un exécutif temps réel, Les
tâches différées utilisent des mécanismes d’exclusion mutuelle plus élaborées pour l’accès à des
ressources critiques.

Les taches immédiates utilisent les mécanismes élémentaires d’exclusion mutuelle dans le cas où il y a
interaction entre tâches immédiates :

Cas d’une machine monoprocesseur : l’exclusion mutuelle est réalisée en utilisant les instructions de
masquage et de démasquage des interruptions ;

Cas d’une machine multiprocesseur : l’exclusion mutuelle se fait en combinant les instructions
atomiques et indivisibles suivantes :

masquer et démasquer les interruptions (le masquage permet l’appropriation exclusive du processeur),
prendre et libérer un verrou (la prise du verrou permet l’appropriation exclusive d’une zone de la
mémoire commune).
Remarque

55
L’imbrication de sections critiques protégées par masquage des interruptions pose un problème
particulier.

Considérons par exemple les deux sections critiques imbriquées suivantes : Entrée

en section critique 1

Entrée en section critique 2

…
Sortie de section critique 2
…
Sortie de section critique 1
Pour éviter que les interruptions soient démasquées lors de la sortie de la section critique 2, il est
indispensable de sauvegarder le registre d’état d’avant d’interdire les interruptions, et de restaurer ce
registre en quittant la section critique.
Dans le cas de sections critiques imbriquées protégées par masquage des interruptions, nous avons donc
:
Prologue : Sauvegarder le registre d’état dans la pile
Masquer les interruptions
Section critique

Épilogue : Restaurer le registre d’état à partir de la pile.

4.4 Exclusion mutuelle par inhibition de l’ordonnanceur

Pour assurer l’atomicité d’une séquence d’opérations, on peut également avoir recours au « masquage
logiciel » qui consiste à inhiber l’ordonnanceur (des tâches différées) pendant le déroulement de la
section critique.
Durant toute la section critique, les interruptions sont gérées normalement ; les traitements immédiats
sont donc effectués. La séquence en section critique n’est atomique qu’au regard des tâches différées,
ce qui est suffisant dès lors qu’un gestionnaire d’interruption n’utilise pas les données sur lesquelles
travaille la tâche en section critique.
Ce mécanisme est bien adapté au cas où la séquence protégée comprend des appels à l’exécutif temps
réel susceptibles d’être à l’origine d’une préemption de la tâche courante. On l’utilisera notamment pour
démarrer plusieurs tâches, ou faire simultanément plusieurs signalisations.
Prologue : Inhiber ordonnanceur

Section critique
Épilogue : Valider ordonnanceur.

Les deux primitives Inhiber et Valider sont fournies par l’exécutif temps réel.
Dans la section critique, le mode d’exécution de la tâche courante est non préemptible pour
l’ordonnanceur des tâches différées.

56
A la sortie de la section critique le mode d’exécution de la tâche est celui qu’elle avait avant la dernière
exécution de l’opération Inhiber.
Lorsque, à la suite d’un appel de la primitive Valider, le mode d’exécution de la tâche courante redevient
préemptible, l’ordonnanceur est invoqué. En conséquence, si une tâche plus prioritaire que la tâche
courante a été activée durant la section critique, l’ordonnanceur va préempter le processeur au profit de
cette tâche plus prioritaire.

4.5 Exclusion mutuelle en utilisant un sémaphore

4.5.1 Les sémaphores : définition et propriétés
Les sémaphores font partie des mécanismes disponibles pour résoudre les problèmes de synchronisation
entre tâches. Ils peuvent également être utilisés pour résoudre le problème de l’exclusion d’accès à une
ressource critique.
En effet, comme nous l’avons déjà indiqué, ce problème de l’exclusion d’accès à une ressource critique
constitue un cas particulier du problème plus général de la synchronisation entre tâches. Un sémaphore
s est un objet composé : d’un compteur c (valeur du sémaphore) et d’une file d’attente f, et qui peut être
manipulé à l’aide de deux primitives V(s) et P(s).

Le compteur c peut prendre des valeurs entières positives, négatives ou nulles. A la création du
sémaphore, le compteur reçoit une valeur initiale C0 non négative (C0 >= 0), et la file f est vide. La
gestion de la file d’attente est fonction de la politique d’ordonnancement choisie (file FIFO ou bien file
à priorité).
La valeur du compteur et l’état de la file sont inaccessibles aux tâches qui utilisent le sémaphore. Un
sémaphore s ne peut être manipulé que par les deux opérations P(s) et V(s). Ces deux opérations sont
indivisibles (ou atomiques). Elles sont appelées primitives parce qu’au niveau des tâches appelantes,
elles se comportent comme des instructions élémentaires.
Comme toute instruction élémentaire, une primitive est indivisible pour l’observateur.
La primitive P(s) décrémente le compteur et suspend la tâche si celui-ci devient négatif. La primitive
V(s) incrémente le compteur et relance une tâche si celui-ci est inférieur ou égal à zéro, c’est-à-dire si
des tâches sont dans la file d’attente.

Primitive CréerSémaphore (s, C0)

c := C0 séquence

atomique
Initialiser la file d’attente f
Primitive P(s) : Prendre une unité de sémaphore

c := c – 1

Si c < 0 alors :

Mettre la tâche ayant effectué la requête

séquence
dans l’état En attente ;

57
 atomique
La ranger dans la file d’attente f ;

finSi

Primitive V(s) : Rendre une unité de sémaphore

c := c + 1

Si c <= 0 alors :
séquence
Sortir une tâche de la file d’attente f ; atomique

La mettre dans l’état Prêt ;

finSi

Ces opérations P(s) et V(s) sont exécutées en exclusion mutuelle.

Remarques
 La description de la primitive V(s) n’indique pas comment se fait le choix de la tâche retirée
de la file car ce choix dépend de la gestion des files d’attente : FIFO, par priorité,…
 Seule l’exécution de la primitive P(s) est susceptible de bloquer une tâche ; celle-ci ne pourra
alors être réveillée que par une autre tâche exécutant la primitive V(s) sur le même
sémaphore. L’exécution de la primitive V(s) n’est jamais bloquante.
 Si c > 0, c donne le nombre de tâches qui pourront exécuter P(s) sans se bloquer (dans
l’hypothèse où aucune opération V(s) n’est exécutée entre temps). Si c < 0, |c| donne le
nombre de tâches en attente dans la file f.
On peut assimiler un sémaphore à un distributeur d’autorisations nécessaires pour franchir une barrière.
Une autorisation est matérialisée par un jeton qui doit être obtenu à l’entrée puis restitué à la sortie de
l’espace ainsi contrôlé. Le nombre des personnes autorisées à séjourner dans cet espace doit être, à tout
instant, inférieur ou égal à une valeur préalablement fixée (c’est C0, la valeur initiale donnée au
compteur). Une opération P(s) correspond à une demande de jeton, et une opération V(s) à la restitution
d’un jeton.

4.5.2 Sémaphore d’exclusion mutuelle

Le problème de l’exécution mutuelle de n tâches pour l’accès à une ressource critique se résout comme
suit avec un sémaphore :

On introduit un sémaphore mutex initialisé à 1.

La primitive P(mutex) est exécutée par chaque tâche qui désire utiliser la ressource critique.

La primitive V(mutex) est exécutée par la tâche qui a fini d’utiliser la ressource critique.
Chaque tâche qui désire utiliser la ressource critique s’exécute selon le programme :

58
P(mutex)

Section critique

V(mutex)

On montre :

qu’à tout instant une tâche au plus se trouve dans sa section critique,

que lorsqu’ aucune tâche ne se trouve dans sa section critique, il n’y a pas de tâche bloquée derrière le
sémaphore d’exclusion mutuelle.

Initialisation : CréerSémaphore (mutex, 1)

Prologue : P(mutex)

section critique

Épilogue : V(mutex)

4.5.3 Problèmes rencontrés lors de l’utilisation de sémaphores d’exclusion mutuelle

La solution donnée ci-dessus (cf. 5.5.2) n’élimine pas tous les problèmes posés par l’exclusion mutuelle
d’accès à une ressource critique.
Voici les principales difficultés rencontrées dans la pratique.
Sections critiques imbriquées. Interblocage
Considérons deux tâches T1 et T2 dont le programme comporte deux sections critiques distinctes
correspondant à l’utilisation de deux ressources critiques.
Tâche T1 Tâche T2
… …
P(mutex1) (1) P(mutex2) (1’)
… …
P(mutex2) (2) P(mutex1) (2’)
… …
V(mutex2) V(mutex1)
… …
V(mutex1) V(mutex2)
Si l’exécution des tâches T1 et T2 se fait selon la séquence :
(1) (1’) (2) (2’)
on aboutit à une situation où les deux tâches sont bloquées indéfiniment, car chacune d’elles ne peut être
réveillée que par l’autre.

59
Cette situation est appelée interblocage, ou étreinte fatale (en anglais, deadlock).

On vérifiera que l’interblocage ne peut se produire si les différentes sections critiques sont imbriquées
dans le même ordre pour toutes les tâches où elles apparaissent.

Attente indéfinie en section critique

La validité de la solution présentée au § 5.5.2 repose sur le fait que toute tâche sort d’une section critique
au bout d’un temps fini. On vient de voir que cette hypothèse peut être mise en défaut par l’imbrication
de sections critiques.

D’autres causes d’attente peuvent se présenter. Ainsi le blocage ou la défaillance d’une tâche en section
critique, ou son entrée dans une boucle infinie peuvent paralyser toutes les autres tâches en compétition
avec elle pour l’accès à une ressource critique.

Privation

L’algorithme d’exclusion mutuelle garantit que, si plusieurs candidats se présentent alors que la section
critique est libre, une tâche et une seule entre en section critique.

Toutefois une tâche particulière peut être indéfiniment retardée : c’est le phénomène de privation. En
effet l’ordre de réveil - par l’opération V(mutex) - des tâches candidates en attente dans la file f(mutex)
dépend de la politique de gestion de cette file.

Dans le cas très fréquent où les files d’attente des sémaphores sont gérées dans l’ordre premier arrivé,
premier servi, sans priorité, le risque de privation est éliminé. En effet, toute tâche devient au bout d’un
temps fini la plus ancienne de sa file ; elle va donc obtenir le sémaphore mutex dès que la tâche qui le
possède le restituera, en admettant que cette dernière sorte de la section critique au bout d’un temps fini.

4.6 Exclusion mutuelle en utilisant un allocateur de ressources

Le problème de l’exclusion d’accès à une ressource critique peut être résolu en mettant en œuvre une
tâche spécialisée dont la fonction est d’allouer la ressource aux tâches qui en font la demande. Une telle
tâche est appelée un allocateur de ressource.

Dans cette solution du problème de l’exclusion mutuelle, est mise en œuvre une gestion centralisée par
un agent actif de l’allocation de la ressource aux tâches. L’allocateur peut mettre en œuvre des
algorithmes variés pour satisfaire les requêtes des tâches ; sa réaction à une requête d’allocation de la
ressource peut prendre des formes diverses : allocation de la ressource demandée, refus avec ou sans
blocage de la tâche requérante, etc. Cependant l’objectif d’un système d’allocation de ressources est de
satisfaire les requêtes de manière équitable, en conservant des performances acceptables pour
l’application.

Les tâches clientes disposent de deux requêtes pour s’adresser à l’allocateur de ressource : Demander
et Restituer.

Prologue : Demander (ressource critique)

section critique

Épilogue : Restituer (ressource critique)

60
Ce mécanisme de réalisation de l’exclusion mutuelle qui consiste à faire appel à une tâche spécifique
chargée de gérer l’allocation de la ressource rejoint le problème de la communication entre tâches. Le
type de communication entre les tâches utilisatrices de la ressource critique et l’allocateur de la ressource
relève du schéma général de communication de type clients/serveur. La tâche allocateur joue en effet le
rôle de serveur vis à vis des tâches clientes qui s’adressent à elle pour obtenir la ressource puis pour la
restituer.

61
Chapitre 5 : Mécanismes de synchronisation et de communication entre
tâches

5.1. Mécanismes de synchronisation entre tâches

Nous avons vu que les diverses tâches d’une application temps réel n’évoluent généralement pas
indépendamment les unes des autres. Elles coopèrent pour réaliser un objectif commun.

Ainsi entre les tâches il existe des relations qui dépendent de la logique du travail à accomplir et qui
ordonnent dans le temps l’exécution de leurs actions.

Nous avons désigné l’ensemble de ces relations sous le terme de synchronisation bien qu’elles ne
fassent pas intervenir le temps comme mesure de durée mais seulement comme moyen d’introduire une
relation d’ordre entre les actions exécutées par les tâches.

5.1.1 Formulation du problème de la synchronisation entre tâches

Le problème de la synchronisation entre tâches consiste donc à construire un mécanisme, indépendant
des vitesses d’exécution des actions, qui permette à une tâche active Ti :

de bloquer une tâche Tj ou de se bloquer elle-même en attendant un signal d’une autre tâche,
d’activer une autre tâche Tk en lui transmettant éventuellement de l’information.

Dans ce dernier cas, la tâche Tk à laquelle est destiné le signal d’activation peut déjà se trouver dans
l’état actif. Il est donc nécessaire de préciser l’effet de l’opération d’activation lorsqu’on se trouve dans
cette situation.

Deux possibilités se présentent alors :

le signal d’activation n’est pas mémorisé, et par conséquent il est perdu si la tâche Tk ne l’attend pas,

le signal est mémorisé et la tâche Tk ne se bloquera pas lors de la prochaine opération d’attente du
signal.

Les mécanismes qui permettent de réaliser ces opérations de synchronisation peuvent être classés en
deux groupes :

Les mécanismes de synchronisation directe

La tâche agit sur elle-même ou bien agit sur une autre tâche en la désignant par son nom : la
synchronisation est dite directe. L’identité de la tâche est donc un paramètre nécessaire de l’opération
de blocage et de l’opération d’activation.

Les mécanismes de synchronisation indirecte

La tâche actionne un mécanisme qui agit sur d’autres tâches : la synchronisation est alors indirecte.
L’identité des tâches impliquées dans le mécanisme de synchronisation peut être inconnue de la tâche
agissante.
5.1.2 Un mécanisme de synchronisation directe

Nous allons décrire un mécanisme de synchronisation directe réalisé à l’aide des deux primitives
suivantes :

La tâche qui fait appel à cette primitive est suspendue.

DORMIR
Cette primitive permet d’envoyer un signal de réveil à une tâche. Le
signal est perdu si la tâche ne l’attend pas, c’est-à-dire si elle n’est pas
REVEILLER (tâche) suspendue.

Le mécanisme de synchronisation qui résulte de l’utilisation de ces deux primitives est bien adapté à la
réalisation de pilotes de périphériques fonctionnant par interruption.

carte
Tâche différée
… interruption
Tâche immédiate
…
(gestionnaire
Initialiser l’échange ;
d’interruption)
Dormir

Conclure l’échange ; Gérer l’échange physique ; Si

fin de l’échange alors :

La tâche différée lance une opération d’entrée/sortie puis se bloque pour éviter de faire de l’attente
active. Pour cela, elle exécute la primitive Dormir. Lorsque l’échange physique est terminé, la tâche
immédiate réveille la tâche différée à l’aide de la primitive Réveiller (tâche).

5.1.3 Synchronisation par sémaphore

Les sémaphores ont été utilisés pour résoudre le problème de l’exclusion d’accès à une ressource critique
(voir chapitre 5 : Réalisation de l’exclusion mutuelle).

Ils sont également utilisables pour résoudre les problèmes de synchronisation entre tâches : un signal
d’activation est envoyé en appelant la primitive V(), il est attendu en appelant la primitive P().

Un sémaphore s est un sémaphore privé d’un tâche Ti si seule cette tâche peut exécuter l’opération
P(s), les autres tâches ne pouvant exécuter que l’opération V(s). La valeur initiale du compteur c est
fixée à 0 (c0 = 0).

63
Ainsi, une tâche dont l’activation est subordonnée à l’émission d’un signal par une autre tâche se bloque
au moyen de la primitive P() derrière son sémaphore privé initialisé à zéro. Le signal de réveil de la
tâche bloquée est obtenu en faisant exécuter par une autre tâche une opération V() sur le même
sémaphore.

CréerSémaphore (signal, 0)

Tâche Ti Tâche Tj
… …

… …

P(signal) V(signal)

Dans cet exemple, deux cas peuvent se présenter :

ou bien la tâche Ti est déjà bloquée sur la primitive P(signal) lorsque le signal d’activation est
émis. La tâche est alors immédiatement réveillée. ou bien la tâche Ti est active lorsque le signal
d’activation est émis. Tout se passe alors comme si le signal d’activation était mémorisé. En
effet la valeur du compteur du sémaphore signal est passée à 1, et lorsque la tâche Ti exécutera
la primitive P(signal) elle ne se bloquera pas.

Si la tâche Tj exécute n fois l’opération V(signal) avant que la tâche Ti n’exécute l’opération P(signal),
la tâche Ti dispose alors d’un potentiel de n activations.

Ainsi le sémaphore apparaît comme un outil de synchronisation qui permet de mémoriser un nombre
quelconque d’activations pendant que la tâche à laquelle elles sont destinées se trouve encore à l’état
actif.

5.1.4 Synchronisation par événement

Un événement est un signal indiquant qu’une condition est devenue vraie. C’est un outil de
synchronisation entre tâches.

Considérons une tâche Ti qui effectue une action A nécessaire à une tâche Tj pour effectuer une action
B.

64
Un événement permet de réaliser la synchronisation des deux actions : il permet d’établir une relation
d’ordre dans l’exécution des deux actions.

Tâche Ti Tâche Tj
… …

Action A …

Envoi du signal Attente du signal

Un tel mécanisme garantit que, dans tous les cas, l’action B est exécutée après l’action A. Les

événements peuvent présenter des caractéristiques diverses :

un événement peut être attendu par une seule et même tâche ou bien par plusieurs tâches ; un

événement peut être mémorisé ou non mémorisé.

Événement mémorisé
Un événement mémorisé est représenté par une variable booléenne. A un instant donné, la valeur 1 ou
0 de cette variable traduit le fait que l’événement est ou n’est pas arrivé.

La tâche se bloque si et seulement si l’événement qu’elle attend n’est pas arrivé. La signalisation d’un
événement débloque la tâche ou les tâches en attente de cet événement.

L’événement mémorisé peut être remis à zéro, c’est-à-dire dans l’état non-arrivé :

soit explicitement par une tâche au moyen d’une primitive particulière ; soit

implicitement dès qu’une tâche qui l’attend est rendue active.

Événement non mémorisé

Lorsqu’il n’y a pas mémorisation, un événement signalé alors qu’aucune tâche ne l’attend est perdu. Par
contre, si au moment où il se produit, une ou plusieurs tâches sont en attente de l’événement, ces tâches
sont rendues actives.

L’utilisation des événements non mémorisés est très délicate car le mécanisme de synchronisation
devient alors dépendant de la vitesse d’exécution des actions et de la stratégie d’ordonnancement des
tâches. Elle peut donner lieu à des aléas de fonctionnement.

65
Illustration d’une telle situation :

Tâche Ti Tâche Tj
… …

Signaler (e1) Attendre (e1)

Attendre (e2) ….

Dans certains cas, l’événement e2 est perdu, c’est-à-dire il est signalé avant que la tâche Ti ait pu
exécuter la primitive Attendre (e2).

5.2. Mécanismes de communication entre tâches

La coopération de plusieurs tâches pour réaliser un objectif commun (la commande d’un procédé
industriel par exemple) nécessite en général un échange d’informations entre les tâches.

On peut considérer que les mécanismes de synchronisation entre tâches réalisent un mode de
communication où l’information transmise est réduite à la forme élémentaire d’une autorisation ou d’une
interdiction de continuer l’exécution au delà d’un certain point prédéterminé. Ce mode de
communication ne suffit pas en général à tous les besoins. Ainsi, lorsque les actions exécutées par une
tâche après son activation dépendent de l’identité de la tâche activatrice et de la valeur de certains
paramètres, ces données doivent pouvoir être transmises à la tâche activée.

Les principaux modes de communication entre tâches sont :

le mode de communication par variables communes, le

mode de communication par messages.

Nous allons successivement présenter ces deux modes de communication.

5.2.1 Communication par variables communes

La communication entre tâches peut être réalisée en rendant un ensemble de variables communes
accessibles aux diverses tâches.

L’utilisation de la mémoire commune permet ainsi de réduire le protocole de communication à des

opérations de synchronisation et à des manipulations de données partagées contenues dans cette
mémoire commune.

L’accès simultané de plusieurs tâches à de telles variables pose des problèmes de cohérence que nous
avons développés lors de l’étude de l’exclusion mutuelle d’accès aux ressources critiques (voir chapitre
5 : Réalisation de l’exclusion mutuelle).

66
Les tâches doivent donc s’imposer une règle du jeu plus ou moins élaborée suivant la nature de la
communication, c’est-à-dire qu’elles doivent s’imposer un mode d’emploi des variables communes qui
garantisse à tout instant le bon fonctionnement de la communication.

Le modèle des lecteurs et des rédacteurs (cf. Système d’explotation) schématise ce mode de
communication par consultation et modification de variables communes. Il illustre les principaux
problèmes que pose la communication par accès à des variables partagées.

Du fait que les règles de communication que doivent observer les tâches ne peuvent leur être imposées,
l’on n’a aucune garantie contre le non respect de ces règles par une tâche défectueuse (voir §
4.5.3 : « Problèmes rencontrés lors de l’utilisation de sémaphores d’exclusion mutuelle » : Interblocage. Attente
indéfinie en section critique. Privation).

Pour des raisons d’efficacité et de sécurité, on préfère en général, dans les logiciels d’application, utiliser
des outils de communication plus structurés que la communication par variables communes. Ces
mécanismes d’échanges, dits de haut niveau et qui relèvent de la communication par envoi de messages,
comportent un contrôle de la communication et évitent au programmeur les détails de la réalisation de
l’exclusion mutuelle et de la synchronisation.

Schéma de communication par variables partagées

entre une tâche Ti et une tâche Tj

Mémoire commune

(1)

Tâche Variables Tâche

Ti Tj
… …
(2)

… …

Écrire ( ) Lire ( )
(1) Écriture ou mise à jour
Rédacteur Lecteur (2) Lecture ou consultation

Figure 19 : Schéma de communication par variables partagées

5.2.2 Communication par messages

5.2.2.1 Principes de la communication par message

67
On peut décrire schématiquement ce mode de communication de la façon suivante :

une tâche Ti envoie un message à une tâche Tj, c’est-à-dire Ti fournit de l’information à Tj et
prévient Tj que cette information est disponible ;
la tâche Ti peut attendre ou ne pas attendre un accusé de réception ou un compte-rendu de la
tâche Tj pour continuer son exécution ; la tâche Tj qui attendait un message, reçoit le message
de la tâche Ti ; elle envoie ou n’envoie pas un accusé de réception ou un compte-rendu à la
tâche Ti.
L’arrivée d’un message provoque le réveil du destinataire en attente. On voit donc qu’un dispositif de
synchronisation est incorporé dans le protocole de communication.

L’échange de messages entre tâches, outre sa fonction de transmission d’informations peut donc aussi
servir à ordonner les actions exécutées par les tâches, puisque l’émission d’un message précède toujours
sa réception.

On est ainsi tout naturellement conduit à considérer les opérations d’échange de message comme des
mécanismes de base de la communication et de la synchronisation entre tâches.

Les primitives de base de la communication par messages sont :

Envoyer (destinataire, message)

Recevoir (expéditeur, message)

Pour spécifier ces primitives il est nécessaire de préciser :

le mode de désignation du destinataire et de l’expéditeur,

la nature des messages, le mode de synchronisation des
tâches, le traitement des erreurs.

Nous allons examiner successivement ces quatre aspects.

5.2.2.2 Le mode de désignation des tâches

Les tâches qui échangent des messages peuvent se désigner mutuellement par leur nom (désignation
directe) ou utiliser le nom d’un objet intermédiaire appelé boite aux lettres (désignation indirecte).

Ces noms sont utilisés pour les paramètres destinataire et expéditeur des primitives Envoyer et Recevoir.

Désignation directe des tâches

Le paramètre expéditeur de la primitive Recevoir peut être interprété de deux façons :

soit comme une donnée : le récepteur indique explicitement qu’il attend un message d’une tâche
particulière (réception sélective),
soit comme un résultat : le récepteur reçoit, avec le message qui lui est adressé, l’identité de
l’émetteur.

Désignation indirecte des tâches

L’association des tâches aux boites aux lettres peut être statique ou dynamique.

68
Dans le cas d’une association dynamique, deux primitives Connecter et Déconnecter permettent
respectivement d’associer une tâche, comme récepteur, à une boite aux lettres, et d’annuler cette
association.

Dans certains exécutifs temps réel, un récepteur au plus peut être associé à une boite aux lettres donnée.
Une telle boite aux lettres à laquelle est associée une seule tâche réceptrice est souvent appelée porte.
Une tâche peut être associée, en revanche, à plusieurs portes distinctes.

Si l’association entre tâche réceptrice et porte est statique, un nom de porte désigne sans ambiguïté une
tâche réceptrice, comme dans le cas d’une désignation directe.

5.2.2.3 La nature des messages

Selon le niveau d’expression auquel est défini le mécanisme de communication les messages peuvent
être spécifiés par leur taille physique ou par leur type. Le type d’un message est analogue à celui des
objets d’un langage de programmation.

La taille d’un message peut être fixe ou variable. Pour des raisons de simplicité de mise en œuvre, on
préfère souvent utiliser des messages de taille fixe, et transmettre par référence les messages de taille
variable en passant l’adresse physique ou l’identification de l’information à transmettre.

5.2.2.4 Le mode de synchronisation des tâches

Divers modes de synchronisation peuvent être spécifiés pour les primitives de communication.

Ces modes de synchronisation sont ceux utilisés, avec quelques variantes, dans la relation producteur–
consommateur et la relation client-serveur.

Modèle du producteur et du consommateur (cf. système d’exploitation)

Dans ce schéma de communication la boite aux lettres est réalisée par un tampon.

En l’absence de message dans le tampon, l’exécution de la primitive Recevoir bloque généralement le

consommateur. Cependant, certains exécutifs temps réel fournissent une primitive supplémentaire de
réception qui, en l’absence de message dans le tampon, ne bloque pas la tâche mais lui indique que le
tampon est vide.

L’émission d’un message n’est pas bloquante, sauf dans le cas où le tampon est plein. Cependant, dans
certains exécutifs temps réel l’émission d’un message ne conduit jamais à une mise en attente de la tâche
émettrice, même lorsque le tampon est plein. Quand ceci se produit, il y a retour dans la tâche avec
l’indication « Tampon plein ». La tâche peut alors exécuter le traitement qu’elle juge le plus approprié
en la circonstance, par exemple : tentative de ré-émission du message à l’expiration d’un délai,
déclenchement d’une alarme, etc.

69
Notons que l’usage de tampons de taille variable avec allocation dynamique de cases réduit la
probabilité de remplissage du tampon.

Schéma de communication par messages

selon le modèle relationnel producteur-consommateur

Figure 20 : Schéma de communication par message selon P-C

(1) Si tampon plein, mise en attente de la tâche jusqu’au retrait d’un message.
(2) Si tampon vide, mise en attente de la tâche jusqu’au dépôt d’un message.

Modèle des clients et du serveur (cf. Système d’exploitation))

Les demandes de service adressées au serveur sont généralement rangées dans la boite aux lettres suivant
leur ordre d’arrivée. Elles sont alors gérées en file d’attente sans priorité selon la politique « Premier
arrivé, premier servi » (en anglais « First In, First Out, ou FIFO).

Cependant, certains exécutifs temps réel fournissent une primitive supplémentaire d’envoi de messages
avec priorité. Si la boite aux lettres n’est pas vide le nouveau message est inséré dans la file d’attente à
une place qui dépend de la priorité de la tâche émettrice.

En l’absence de demande de service, l’exécution de la primitive Recevoir bloque le serveur. Ce dernier

reste bloqué tant qu’il n’a pas de demande de service à traiter.

L’émission d’un message n’est pas bloquante pour le client. Si la boite aux lettres est pleine, c’est
indiqué à la tâche cliente.

Le client doit transmettre au serveur, dans la requête, le nom d’une porte sur laquelle il se bloque en
attendant l’envoi du résultat, ce résultat pouvant consister en un simple compte-rendu d’exécution du
service.

Dans ce schéma de communication, on peut concevoir qu’un client effectue plusieurs demandes
successives de service à des serveurs différents avant de se mettre en attente des comptes rendus
d’exécution.

70
Exemple :
…

Envoyer (serveur Tj, demande service A)

Envoyer (serveur Tk, demande service B)

Attendre (résultat service A, résultat service B)

Ainsi, lorsqu’une tâche est associée en réception à plusieurs portes, on peut définir un mode de
synchronisation, dit attente multiple, où l’arrivée d’un message sur l’une quelconque de ces portes
réveille le récepteur.

Client(1) Si boite aux lettres vide, blocage de la tâche jusqu’au dépôt d’un
message.Serveur

(2) Attente du message réponse.

Figure 21 : Schéma de communication entre deux tâches Ti et Tj

5.2.2.5 Le traitement des erreurs

Le traitement des erreurs a pour but d’éviter le blocage indéfini des tâches. Cette attente indéfinie d’une
ou plusieurs tâches peut se produire dans diverses circonstances :

Envoi d’un message à un destinataire (tâche ou porte) qui n’existe pas ou qui est hors service.
Dans ce cas, la primitive n’est pas bloquante ; l’erreur est traitée par renvoi d’un code d’erreur
ou par déroutement.

71
 Destruction d’une tâche dont d’autres attendent un message ou une réponse ; les tâches en attente
sont débloquées et reçoivent un code d’erreur.

La situation ci-dessus n’est pas toujours détectable. Aussi une technique usuelle consiste à fixer un délai
maximal à l’attente d’un message, et à réveiller au terme de ce délai la tâche en attente.

5.3. Mise en œuvre de schémas de communication entre tâches

Dans le paragraphe 5.2. Mécanismes de communication entre tâches, nous avons donné les principes de
la communication par variables communes et par messages. Et, dans le cas de la communication par
messages, pour préciser les modes de synchronisation possibles entre tâches communicantes nous avons
décrit deux modèles relationnels entre ces tâches, à savoir : le modèle producteur-consommateur et le
modèle client-serveur.

Lorsque l’exécutif temps réel utilisé n’offre pas de mécanismes de communication par messages (c’est
le cas pour la version 6.5 de RTX), il est nécessaire d’implémenter cette communication par messages,
tout comme la communication par variables communes, en faisant appel aux objets dits « de bas niveau
» que propose tout exécutif temps réel, à savoir :

les zones de mémoire partagée les sémaphores à compte les événements les

sémaphores d’exclusion mutuelle.

En faisant appel à de tels objets, nous allons décrire en détail la mise en œuvre :

d’un protocole de communication par variables communes, d’une boite aux lettres

de type porte, d’un schéma de communication entre plusieurs producteurs et un

consommateur, d’un schéma de communication entre plusieurs clients et un

serveur.

Si l’implémentation de tels mécanismes de communication à l’aide d’objets « de bas niveau » obligent

à entrer dans le détail de la communication, elle offre cependant l’avantage de pouvoir s’adapter
parfaitement aux exigences de l’application à développer.

Ainsi, pour chacun des 4 types de communication que nous allons examiner en détail, présenterons nous
un certain nombre de variantes par rapport au mécanisme de base décrit. Lors du développement d’une
application multitâches particulière, devra être choisie la variante qui correspond le mieux à la
communication à mettre à œuvre, quitte même à l’adapter pour qu’elle réponde parfaitement aux besoins
de l’application.

Pour les objets de type sémaphore à compte, sémaphore d’exclusion mutuelle et événement,
voici les correspondances entre les primitives décrites dans les chapitres précédents et les
fonctions de l’API temps réel de RTX :

72
Support de cours sur les STR Ardence RTX

Sémaphore à compte : objet semaphore :

P(s) : Prendre une unité de sémaphore RtWaitForSingleObject ( ) ou

RtWaitForMultipleObjects( )

V(s) : Rendre une unité de sémaphore

RtReleaseSemaphore ( )
Sémaphore d’exclusion mutuelle : objet mutex :

P(mutex) : entrée en section critique RtWaitForSingleObject ( ) ou

RtWaitForMultipleObjects( )

V(mutex) : sortie de section critique

RtReleaseMutex ( )
Événement : objet event :

Signaler (événement) RtSetEvent ( ) ou

RtPulseEvent ( )

Attendre (événement)
RtWaitForSingleObject ( )

ou RtWaitForMultipleObjects ( )
Convention d’écriture pour la suite de ce chapitre : RtWFSO = RtWaitForSingleObject

5.3.1 Protocoles de communication par variables communes

Nous allons décrire la mise en œuvre de protocoles de communications par variables communes d’une
part entre tâches appartenant à un même processus, et d’autre part entre tâches appartenant à des
processus différents.

Si les tâches sont susceptibles de vouloir à n’importe quel instant accéder aux variables partagées, il est
nécessaire de protéger l’accès à ces variables par un sémaphore d’exclusion mutuelle ou par tout autre
mécanisme décrit dans le chapitre 5 : Réalisation de l’exclusion mutuelle.

Par contre, s’il y a entre les tâches une synchronisation des opérations d’écriture et de lecture des
variables, c’est-à-dire s’il y a une relation d’ordre implicite ou explicite entre les opérations d’écriture
et de lecture, un sémaphore d’exclusion mutuelle peut ne pas être nécessaire pour garantir à tout instant
le bon fonctionnement de la communication, et notamment la cohérence de la valeur de chaque variable.

5.3.1.1 Communication par variables communes : exemple 1

Considérons qu’au sein d’un même processus, un ensemble de tâches effectuent de façon totalement
asynchrone un certain nombre d’actions. De façon, à pouvoir examiner a posteriori la séquence des
actions effectivement réalisées par les tâches, chacune d’elles, au début d’une action, concatène à la
chaîne de caractères mémorisés dans une variable globale son identifiant de tâche (un chiffre), le code

73
de l’action qu’elle entreprend (une lettre) et le caractère espace. Cette variable conserve ainsi la trace
des toutes les opérations effectuées par l’ensemble des tâches. A la fin de l’activité des tâches, en
visualisant la valeur de cette variable on peut voir quelle a été l’activité des tâches et dans quel ordre se
sont enchaînées les opérations qu’elles ont réalisées.

Cette variable, que nous appellerons trace est typiquement une variable commune : à tout moment les
tâches peuvent vouloir y accéder pour en modifier la valeur, en l’occurrence concaténer une chaîne de
3 caractères à la fin de la chaîne présentement mémorisée dans la variable.

L’accès à cette variable doit donc être protégé par un sémaphore d’exclusion mutuelle de façon à garantir
qu’à tout instant une seule tâche modifie la valeur de la variable.

5.3.1.2 Communication par variables communes : exemple 2

Lorsqu’un processus crée un autre processus, le processus père a le plus souvent à transmettre au
processus fils une certain nombre de données à partir desquelles se feront la configuration et
l’initialisation générale du processus fils. Après cette phase de configuration et d’initialisation générale
de son activité, le processus fils devra en transmettre un compte-rendu au processus père.

Dans un tel contexte, la communication entre le thread primaire du processus père et le thread primaire
du processus fils se fait l’intermédiaire de variables communes créées dans une zone de mémoire
partagée. A cet objet de type shared memory, se rajoute un objet de type event à reset automatique,
l’objet evCRprocess, utilisé par le processus fils pour signaler au processus père la fin de la phase de
configuration et d’initialisation générale de son activité, ainsi que le dépôt dans la zone de mémoire
partagée : d’une part, des informations d’identification et de caractérisation du processus fils
(version, date, auteur, etc.) ;

et d’autre part, des informations de compte rendu pour la phase de configuration et

d’initialisation générale du processus fils, avec notamment indication si cette phase a pu
arriver à son terme normal ou si elle a échoué, ce qui, dans ce cas, va entraîner la terminaison
immédiate du processus fils.

Lorsque le processus fils a pu démarrer son activité normale à l’issue d’une phase de configuration et
d’initialisation générale réussie, le processus père devra, à un moment ou à un autre, pouvoir commander
la terminaison du processus fils. La méthode préférée de fermeture d’un processus fils est celle où le
processus père demande explicitement au processus fils de se terminer, et non celle où le processus père
force de l’extérieur la fin du processus fils. Pour transmettre cette demande au processus fils, le processus
père utilise un objet de type event à reset automatique : l’objet evCdeFinProcess.

Lorsqu’il reçoit du processus père une demande de se terminer, le processus fils répond en indiquant s’il
peut ou non prendre en compte cette demande. En effet, le processus fils peut refuser de se terminer s’il
se trouve alors dans un état de fonctionnement qui ne lui permet pas de le faire « proprement », c’est-à-
dire de façon compatible avec son activité actuelle. Le processus fils utilisera l’objet evCRprocess de
type event à reset automatique pour signaler au processus père le dépôt dans la zone de mémoire partagée
de sa réponse : acceptation de se terminer immédiatement ou bien refus de le faire pour la raison
indiquée.
En définitive, pour cette communication entre les 2 processus, d’une part, au moment du lancement du
processus fils, et d’autre part, au moment de sa terminaison, sont utilisés les objets suivants :

Un objet de type shared memory où sont créées des variables communes, accessibles par
les 2 processus, dans lesquelles sont mémorisés :

74
les données de configuration du processus fils (en écriture pour le processus père, et en lecture seule
pour le processus fils),

les données d’identification et caractérisation du processus fils (en écriture pour le processus fils, et en
lecture seule pour le processus père),

le compte rendu de la phase de configuration et initialisation générale du processus fils (en écriture pour
le processus fils, en lecture seule pour le processus père),

le compte rendu de la demande de se terminer (en écriture pour le processus fils, en lecture seule pour
le processus père).

L’objet evCdeFinProcess de type event à reset automatique utilisé par le processus père pour demander
que le processus fils se termine si ce dernier est dans un état compatible avec cette opération.

L’objet evCRprocess de type event à reset automatique utilisé par le processus fils pour signaler au
processus père la mise à jour des variables de compte rendu.

Compte tenu du protocole de communication entre les 2 processus, il n’est pas nécessaire d’utiliser un
sémaphore d’exclusion mutuelle pour protéger l’accès aux variables communes. En effet la
synchronisation des opérations d’écriture et de lecture est telle que la lecture de l’une quelconque de ces
variables intervient toujours après son écriture. C’est ce que le diagramme de séquence suivant met bien
en évidence :

75
 temps
5.3.1.3 Communication par variables communes : exemple 3

Considérons une application de contrôle/commande composée :

76
d’une part, d’un processus RTSS qui assure le contrôle/commande proprement de la
partie opérative,

et d’autre part, d’un processus Win32 RTX qui assure la supervision de

ce contrôle/commande à partir des directives de l’opérateur.

Le processus RTSS doit périodiquement transmettre au processus Win32 RTX l’état de la partie opérative
et de l’automate de commande. Ceci est fait par l’intermédiaire de variables communes, images de
certaines variables d’état. Ces variables communes sont créées dans une zone de mémoire partagée.

A cet objet de type shared memory, se rajoute un objet de type event à reset automatique utilisé par le
processus RTSS pour signaler au processus Win32 RTX chaque mise à jour des variables communes
créées dans la zone de mémoire partagée.

Si l’on suppose d’une part que le processus Win32 RTX ne lit la valeur des variables que suite à la
réception du signal, et d’autre part que cette lecture est terminée lorsque la processus RTSS procède à
une nouvelle mise à jour, il n’est alors pas nécessaire de protéger par un mutex l’accès à cette zone de
mémoire partagée.

Ainsi en synchronisant, grâce à un événement, les opérations de lecture par rapport aux opérations
d’écriture, on s’affranchit des conflits d’accès aux variables communes, et donc de la nécessité d’utiliser
un mutex pour les résoudre (cf. § 6.4 Synchronisation par événement).

Il n’est pas donné en annexe le code source de cet exemple dans la mesure où il est très
semblable à celui de l’exemple précédent.

5.3.2 Transmission de messages par l’intermédiaire d’une boite aux lettres

5.3.2.1 Spécifications de base de cette communication
Pour cette implémentation d’une communication par messages en utilisant une boite aux lettres les
hypothèses suivantes ont été faites :

La boite aux lettres est associée à une seule tâche réceptrice (il s’agit donc d’une porte).

Plusieurs tâches sont susceptibles d’envoyer des messages à cette tâche.

Le nombre maximum de messages pouvant être présents à un instant donné dans la boite
aux lettres est connu.

Tous les messages rangés dans la boite aux lettres sont de taille fixe.

Un message, après avoir été déposé dans la boite aux lettres, n’est retiré qu’une seule fois
de celle-ci par la tâche réceptrice.

Si la tâche réceptrice est en attente parce que la boite aux lettres est vide, elle est réveillée
dès qu’un message est déposé dans la boite aux lettres.
La tâche réceptrice peut limiter son temps d’attente de l’arrivée d’un message, et,
lorsque ce temps d’attente est nul, teste simplement la présence ou non d’un message
dans la boite aux lettres.

Les tâches émettrices n’attendent pas d’accusé de réception ou un compte–rendu de la part

de la tâche destinataire de leurs messages.
77
5.3.2.2 Mise en œuvre de la communication
La mise en œuvre d’une communication respectant les spécifications précédentes peut être décrite à
l’aide du schéma suivant :

evBAL

MP_BAL

(objet mémoire partagée)

tampon
envoyer codeMessage [ ] recevoir

parametre1 [ ]

Tâche Tâche

émettrice n° i réceptrice

mutexBAL

Cette mise en œuvre nécessite les trois objets suivants :

un objet MP_BAL de type mémoire partagée où sont rangés d’une part les messages, et d’autre part les
variables de gestion du tampon de stockage de ces messages.

Un tel objet de type mémoire partagée ne sera effectivement créé que si les tâches
émettrices et la tâche réceptrice n’appartiennent pas à un même processus. Si elles
appartiennent au même processus, l’implémentation de la boite aux lettres sera faite avec
des variables statiques du processus (externes aux tâches, ces variables sont visibles par
toutes les tâches créées à l’intérieur du processus).
un objet mutexBAL de type sémaphore d’exclusion mutuelle qui protège l’accès à la mémoire partagée
MP_BAL. Il est en effet possible que les tâches émettrices et la tâche réceptrice veuillent accéder en
même temps à cette ressource critique.

La boite aux lettres doit en effet être considérée comme une ressource critique. A un instant
donné, une seule tâche est autorisée à effectuer une opération sur cet objet : y déposer ou
en retirer un message.
un objet evBAL de type événement qui permet à la tâche émettrice qui vient de ranger un message dans
la boite aux lettres vide de réveiller la tâche réceptrice.
La tâche réceptrice peut se mettre en effet en attente de ce signal après avoir lu puis traité
tous les messages contenus dans la boite aux lettres.
Compte tenu de la gestion qui est faite de la boite aux lettres, on utilise un objet event à
reset manuel. L’événement evBAL sera mis dans l’état arrivé (ou signalé) chaque fois
qu’une tâche émettrice trouvera la boite aux lettres vide avant d’y déposer un message. Il
sera remis dans l’état non arrivé (ou non signalé) par la tâche réceptrice lorsque celle-ci
aura retiré le dernier message présent dans la boite aux lettres.

78
Il n’est pas nécessaire d’utiliser un objet de type sémaphore à compte pour contrôler le nombre de
messages que peut contenir à un instant donné la boite aux lettres. En effet, puisque a priori est connu
le nombre maximum de messages qui peuvent, à un instant donné, être présents dans la boite aux lettres,
il suffit de dimensionner suffisamment la boite aux lettres pour que jamais celle-ci ne soit pleine.

5.3.2.3 Organigramme général des primitives envoyerMessageBAL() et

recevoirMessageBAL()

Primitive envoyerMessageBAL ()

Cette primitive permet aux tâches émettrices de déposer un message dans la boite aux lettres. Si le
message est déposé dans une boite aux lettres vide, l’objet evBAL de type event à reset manuel est mis
dans l’état signalé.

envoyerMessageBAL (codeMessage, parametre1, parametre2, …)

RtWaitForSingleObject (hMutexBAL, INFINITE)

Écrire le message en queue du tampon

Si tampon vide avant écriture du message alors :

RtSetEvent (hEvBAL)

finSi compteur :=

compteur + 1

RtReleaseMutex (hMutexBAL)

Primitive recevoirMessageBAL()
Cette primitive permet à la tâche réceptrice de retirer un message de la boite aux lettres. Pour le cas où
la boite aux lettres serait vide au moment de l’appel de cette primitive, est donnée la possibilité à la tâche
réceptrice d’indiquer ce qui doit alors être fait :

soit attendre indéfiniment le dépôt d’un nouveau message (dureeAttente = -1), soit attendre pendant

un temps fini le dépôt d’un nouveau message (dureeAttente > 0), soit simplement tester la présence

ou non d’un message dans la boite aux lettres (dureeAttente = 0).

Lorsque est retiré le dernier message présent dans la boite aux lettres, l’objet evBAL de type event à
reset manuel est remis dans l’état non signalé.
La primitive retourne FALSE si aucun message n’a été lu, et TRUE si un message a été lu et retiré de
la boite aux lettres.

BOOL recevoirMessageBAL (dureeAttente, &codeMessage, &parametre1, &parametre2, …)

valRetour := FALSE

79
Si dureeAttente = -1 alors :

RtWaitForSingleObject (hEvBAL, INFINITE)

sinon

Si RtWaitForSingleObject (hEvBAL, dureeAttente) = WAIT_TIMEOUT alors :

Retourner valRetour

finSi

finSi

RtWaitForSingleObject (hMutexBAL, INFINITE)

Si compteur <> 0 alors :

Lire et retirer le message en tête du tampon compteur := compteur –

Si compteur = 0 alors :

RtResetEvent (hEvBAL)

finSi valRetour :=

TRUE

finSi

RtReleaseMutex (hMutexBAL)

Retourner valRetour

5.3.2.4 Variantes dans la transmission de messages par l’intermédiaire d’une BAL

La mise en œuvre décrite précédemment d’une transmission de messages par l’intermédiaire d’une boite
aux lettres peut, selon l’application développée, présenter l’une ou l’autre, ou les deux variantes
suivantes.

Variante 1 : La tâche réceptrice ne se met jamais en attente d’un message

Lorsque la tâche réceptrice est une tâche dont l’activité est périodique, elle ne peut jamais se mettre en
attente sur la boite aux lettres, c’est-à-dire attendre qu’un message lui soit envoyé.
Une telle tâche teste alors, lors de chacune de ses activations, la présence ou non de messages dans la
boite aux lettres. Si cette dernière contient des messages, le message en tête de la boite aux lettres est lu
et retiré. Si la boite aux lettre est vide, la tâche poursuit son exécution périodique sans attendre l’arrivée
d’un nouveau message.

80
L’objet evBAL de type event n’est plus alors nécessaire. Il peut donc être supprimé.

De plus, on définit une primitive lireMessageBAL() différente de la

primitive recevoirMessageBAL().

Variante 2 : Filtrage d’un certain type de messages

Le principe de ce filtrage est le suivant. On veut qu’à un instant donné, au plus un message d’un certain
type (c’est-à-dire, dont le code message a une certaine valeur) soit présent dans la boite aux lettres. Ceci
signifie que si un message de ce type se trouve déjà dans la boite aux lettres, on refusera de ranger dans
la boite aux lettres tout autre message du même type tant que celui qui est présent dans la boite aux
lettres n’aura pas été retiré par la tâche réceptrice.

Avec une telle variante de communication par l’intermédiaire d’une boite aux lettres, il est nécessaire
que l’expéditeur soit informé du fait que le message qu’il voulait envoyer ait ou non pu être rangé dans
la boite aux lettres.

5.3.3 Communication entre plusieurs producteurs et un

consommateur
5.3.3.1 Spécifications de base de cette communication

A celles données en annexe 2 : Modèle du producteur et du consommateur du chapitre 7, s’ajoutent les

spécifications complémentaires suivantes :

Plusieurs tâches peuvent produire des messages destinés à être traités par la tâche consommateur.

La boite aux lettres où sont rangés les messages envoyés par les tâches producteur est associée à la seule
tâche consommateur (il s’agit donc d’une porte pour cette tâche).

En une seule opération de lecture de la boite aux lettres, la tâche consommateur peut lire plusieurs
messages, sans pour autant que le nombre de messages lus dépasse une valeur fixée a priori par la
tâche.

5.3.3.2 Mise en œuvre de la communication

La mise en œuvre d’une communication respectant les spécifications précédentes peut être décrite à
l’aide du schéma suivant :

81
nécessite quatre objets IPC, à savoir :

un objet MP_BAL de type mémoire partagée où sont rangés d’une part les messages constituant le flot
des données produites par les tâches producteur, et d’autre part les variables de gestion du tampon de
stockage de ces messages.

Un tel objet de type mémoire partagée ne sera effectivement créé que si les tâches
producteur et la tâche consommateur n’appartiennent pas à un même processus. Si elles
appartiennent au même processus, l’implémentation de la boite aux lettres sera faite avec
des variables statiques du processus (externes aux tâches, ces variables sont visibles par
toutes les tâches créées à l’intérieur du processus).
un objet semaBAL de type sémaphore à compte pour contrôler le nombre de messages que peut contenir
à un instant donné la boite aux lettres.

C’est grâce à un dimensionnement suffisant du tampon que l’on donne aux tâches
producteur et consommateur la possibilité de travailler chacune à son propre rythme, et que
l’on peut obtenir un écoulement du flot de données sans blocage des producteurs. Il faut
cependant prévoir le cas où pour une raison ou une autre les producteurs trouvent le tampon
plein alors qu’ils veulent y écrire. En contrôlant le nombre de messages stockés dans la
boite aux lettres, le sémaphore semaBAL permet de détecter cette situation et de la gérer
en bloquant les producteurs jusqu’à ce qu’au moins un message ait été retiré par le
consommateur.
un objet mutexBAL de type sémaphore d’exclusion mutuelle qui protège l’accès à la mémoire partagée
MP_BAL. Il est en effet possible que parmi les tâches producteur et consommateur plusieurs d’entre
elles veuillent accéder en même temps à cette ressource critique. Ceci peut en effet se produire car les
opérations de production et de consommation des données ne sont pas synchronisées.

un objet evBAL de type événement qui permet au producteur qui vient de ranger un message dans une
boite aux lettres vide de réveiller le consommateur.

82
 En utilisant un objet de type événement à reset manuel on donne la possibilité à la tâche
consommateur de lire un ou plusieurs messages sans avoir pour autant à vider la boite aux
lettres au cours d’une seule et même opération de lecture. En contre partie de cette
possibilité, la tâche consommateur devra remettre l’objet evBAL dans l’état non signalé
lorsqu’à l’issue d’une opération de lecture la boite aux lettres sera vide.

5.3.3.3 Diagramme de séquence de la communication

Le diagramme de séquence entre un producteur et le consommateur se présente ainsi :

Remarques :
1. Lorsqu’il veut ranger un message dans la boite aux lettres, un producteur doit :
1. d’abord s’assurer que la boite aux lettres n’est pas pleine ; pour cela il se met en
attente sur le sémaphore à compte semaBAL :
RtWFSO (hSemaBAL, INFINITE)
2. puis demander à disposer du sémaphore d’exclusion mutuelle mutexBAL, c’est-à-
dire demander à avoir un accès exclusif à la mémoire partagée MP_BAL pour y
écrire le message :
RtWFSO (hMutexBAL, INFINITE)
Une inversion de ces 2 instructions conduit immanquablement à une situation de
blocage lorsque la boite aux lettres est pleine. En effet, le consommateur ne peut alors
vider la boite aux lettres puisque le producteur, bloqué sur le sémaphore à compte, ne

83
 peut pas restituer le mutex qu’il possède, empêchant ainsi le consommateur d’obtenir le
mutex pour vider la boite aux lettres.

3. Notons que dans le cas d’une communication entre un producteur et un

consommateur, le schéma de communication décrit précédent ne peut faire l’objet
d’aucune simplification : tous les 4 objets IPC sont nécessaires.

5.3.3.4 Variante d’une communication producteur/consommateur

Par rapport à la mise en œuvre précédente du schéma de communication producteur/consommateur,

cette variante diffère sur les points suivants :

Communication entre un producteur et un consommateur.

Non blocage du producteur lorsque ce dernier trouve la boite aux lettres pleine.

Lorsqu’il ne peut obtenir immédiatement une unité du sémaphore à compte semaBAL du

fait que la boite aux lettres est pleine, le producteur déclenche une alarme qui va conduire
à une interruption et annulation de la communication en cours. En effet, la boite aux lettres
ayant été suffisamment dimensionnée pour permettre l’écoulement du flot de données sans
blocage du producteur, si ce dernier la trouve pleine c’est qu’un dysfonctionnement s’est
produit au niveau du consommateur.
Non blocage du producteur lorsque ce dernier trouve le mutex mutexBAL occupé.

Si pour l’envoi d’un message il trouve l’objet mutexBAL occupé alors qu’il l’avait trouvé
libre pour l’envoi du précédent message, le producteur stocke provisoirement le message à
envoyer.
Si ensuite, pour l’envoi du message suivant, le producteur trouve toujours l’objet
mutexBAL occupé, alors il déclenche une alarme qui va conduire à une interruption et
annulation de la communication en cours. Si par contre, il trouve le mutex libre, le
producteur envoie d’abord le message qu’il avait précédemment et temporairement stocké
puis l’actuel message à envoyer.
Ainsi, si deux fois de suite lorsqu’il a à envoyer un message, le producteur trouve le mutex
mutexBAL occupé (ce dernier est alors nécessairement occupé par le consommateur puisqu’il n’y a
qu’un seul producteur), on considère qu’un dysfonctionnement s’est produit au niveau du
consommateur. Indication au consommateur de la fin de la production des données.

Quand il a fini la production des données, le producteur le signale au consommateur de

façon que ce dernier n’ait plus à se mettre en attente de nouveaux messages et puisse clore
son activité de traitement des données qu’il reçoit de ce producteur.
Le producteur signale la fin de l’opération de production des données en indiquant s’il s’agit
d’une fin normale de l’opération ou bien d’une fin consécutive à une interruption et
annulation de l’opération à la suite d’une alarme.

5.3.4 Communication entre plusieurs clients et un serveur

5.3.4.1 Spécifications de cette communication

84
A celles données en annexe 3 : Modèle des clients et du serveur du chapitre 7 , s’ajoutent les
spécifications suivantes :
La boite aux lettres où sont rangés les messages envoyés par les tâches clientes est associée à la
seule tâche serveur (il s’agit donc d’une porte pour cette tâche).
Une tâche cliente n’adresse une nouvelle demande de service à la tâche serveur qu’après avoir
reçu de cette dernière le message de compte rendu à sa précédente demande de service.
Pour chaque demande de service qu’elle reçoit, la tâche serveur envoie d’abord un message de
prise en compte ou non de la demande de service. Ainsi, elle n’effectuera le service demandé
qu’après avoir envoyé à la tâche requérante un message indiquant qu’elle accepte et traite sa
demande.
La tâche serveur peut prendre en compte une nouvelle demande de service avant d’avoir traité
entièrement les précédentes demandes de service qui lui ont été adressées et qu’elle a acceptées,
et donc avant d’en avoir envoyé, pour chacune d’elles, le message de compterendu.

Le respect du point n° 2 fait que ces différentes demandes de service en cours de traitement au sein
de la tâche serveur émanent nécessairement de tâches clientes différentes.
1. Après avoir adressé une demande de service à la tâche serveur, les tâches clientes peuvent différer,
autant qu’elles le souhaitent, l’instant où elles se mettent en attente d’abord du message de prise en
compte ou non de leur demande, puis, si cette dernière est acceptée, du message de compte rendu
envoyé après la réalisation du service demandé.
On donne ainsi la possibilité à la tâche cliente qui vient d’adresser une demande de service à la tâche
serveur, d’effectuer des traitements ou même d’adresser des demandes de service à d’autres tâches
serveur, avant de se mettre en attente du ou des messages d’abord de prise en compte puis de compte
rendu.

5.3.4.2 Mise en œuvre de la communication

La mise en œuvre d’une communication de type clients/serveur conforme aux spécifications précédentes
peut être décrite à l’aide du schéma de la page suivante.

Si N est le nombre de tâches clientes, cette mise en oeuvre nécessite (N + 3) objets IPC, à savoir :

un objet MP_ClientsServeur de type mémoire partagée contenant : la boite

aux lettres BAL où sont rangés les messages de demande de service, les

messages de prise en compte ou non des demandes de service, les messages

de compte-rendu pour les services demandés et réalisés.

Il est prévu autant de zones de rangement pour les messages de prise en compte et de
compte rendu qu’il y a de tâches susceptibles d’adresser des demandes de service à la tâche serveur.
un objet semaBAL de type sémaphore à compte pour contrôler le
nombre de messages de demande de service que peut contenir à un instant
donné la boite aux lettres BAL.

Cette boite aux lettres est dimensionnée pour ne contenir qu’un seul message. Étant donné
que la tâche serveur ne lit et examine qu’un seul message de demande de service à la fois,
dimensionner la boite aux lettres pour que plusieurs messages puissent y être rangés

85
 compliquerait – le plus souvent inutilement - sa gestion, d’autant que les messages peuvent
ne pas être de taille fixe (les paramètres d’une demande de service peuvent en effet différer
en nombre et en type selon la nature du service demandé).
Ainsi, les tâches clientes qui souhaitent adresser une demande de service à la tâche serveur
restent bloquées sur le sémaphore semaBAL tant que la tâche serveur n’a pas lu le message
présent dans la boite aux lettres puis restitué une unité du sémaphore semaBAL. Cependant,
cela peut conduire à un dysfonctionnement lorsque les tâches clientes n’ont pas toutes le
même niveau de priorité .
un objet evBAL de type événement à reset automatique permet au client qui a rangé un message dans la
boite aux lettres BAL de le signaler au serveur afin que celui-ci retire le message.

N objets semaPCR de type sémaphore à compte privé permettent au serveur de signaler à chaque tâche
cliente la disponibilité d’abord du message de prise en compte ou non de la demande de service qu’elle
vient de lui adresser, et ensuite, si cette demande est acceptée, du message de compte rendu pour le
service réalisé.

Chaque tâche cliente dispose d’un sémaphore à compte privé qui permet au serveur de lui
adresser les 2 signalisations (celle du dépôt du message de prise en compte, puis celle du
dépôt du message de compte rendu) sans qu’aucune de ces signalisations ne soit perdue, et
cela, quel que soit l’état de la tâche cliente au moment de leur occurrence.

evBAL

MP_ClientsServeur

semaBAL (objet mémoire partagée)

BAL

codeDde

idClient
Message
d’acception/refus

pour tâche cliente n° i

Message de CR

pour tâche cliente n° i

Tâche
semaPCR n° i Tâche serveur
cliente n° i

Bien que la mémoire partagée MP_ClientsServeur soit en écriture/lecture aussi bien pour les clients que
pour le serveur, il n’est pas nécessaire de protéger par un objet de type sémaphore d’exclusion mutuelle
l’accès aux variables communes implantées dans cette zone mémoire. En effet, la synchronisation des
opérations d’écriture et de lecture est telle que jamais plusieurs tâches n’ont à accéder en même temps
à la même variable commune. C’est ce que le diagramme de séquence suivant met bien en évidence :

86
Lorsque plusieurs tâches clientes de priorité différente sont en attente sur le sémaphore
semaBAL, c’est la tâche la plus prioritaire qui se voit attribuer l’unité de sémaphore
restituée par le serveur après lecture du message de demande de service. Or cela peut
conduire à une situation de famine pour les tâches clientes les moins prioritaires : il se peut
qu’elles n’arrivent jamais, ou très rarement, à déposer dans la boite aux lettres leur message
de demande de service.

87
5.3.4.3 Variantes dans le schéma précédent de communication clients/serveur La mise en œuvre
du schéma de communication de type clients/serveur qui vient d’être décrite peut, selon l’application
développée, présenter une ou plusieurs des variantes suivantes :

La boite aux lettres BAL peut contenir N messages

Si les messages de demande de service sont de taille fixe, et si, en outre, on juge préférable
d’éviter l’éventuel blocage des tâches clientes sur le sémaphore semaBAL, notamment
parce que celles-ci ont des niveaux de priorité différents, la boite aux lettres BAL peut être
dimensionnée pour recevoir N messages. La gestion de la boite aux lettres conduit à
supprimer l’objet semaBAL, et à ajouter l’objet mutexBAL de type mutex pour protéger
l’accès à la boite aux lettres.
Lorsque la boite aux lettres peut contenir N messages, la situation de famine est très
improbable. En effet, les messages sont alors rangés dans la BAL, et donc traités ensuite
par le serveur, en fonction de leur ordre d’arrivée et non de la priorité de la tâche émettrice.
Cependant, comme la priorité des tâches intervient pour l’attribution du mutex mutexBAL,
cette situation de famine n’est pas totalement écartée.
Communication entre un client et un serveur.

Dans ce cas, l’objet semaBAL de type sémaphore à compte n’est plus nécessaire ; il peut
être supprimé. La tâche cliente ne viendra en effet écrire dans la boite aux lettres un
nouveau message de demande de service qu’après avoir reçu le message de compte rendu
à sa précédente demande de service.
Possibilité d’interrompre le service demandé.

On donne la possibilité au client d’interrompre l’exécution du service qu’il a demandé au serveur. Cette
possibilité est intéressante lorsque, dans le cas d’une communication entre un client et un serveur, un
ou plusieurs des services demandés correspondent à des opérations non immédiates (c’està-dire des
opérations dont la durée d’exécution est relativement longue). Pour l’implémentation de cette
fonctionnalité, il est alors nécessaire de créer :
1. soit, un indicateur booléen (d’interruption du service en cours) que le serveur testera
régulièrement durant l’exécution du service.
2. soit, un objet de type event dont le serveur viendra tester régulièrement l’état durant
l’exécution du service.
Quand le serveur trouve l’indicateur dans l’état VRAI ou l’objet event dans l’état signalé
il interrompt l’exécution du service puis envoie à la tâche cliente le message de
compterendu.

5.3.4.4 Contexte d’utilisation du schéma précédent de communication clients/serveur

Le schéma de communication de type clients/serveur qui vient d’être décrit a pour principale
caractéristique que toute demande de service donne lieu, de la part du serveur, à l’envoi d’abord d’un
message de prise en compte ou non de la demande de service, puis, si la demande est acceptée, d’un
message de compte-rendu d’exécution du service demandé.

L’utilisation d’un tel schéma de communication ne se justifiera en définitive que lorsque des demandes
de service correspondent à des opérations dont l’exécution peut prendre un temps significatif, et que
l’on ne veut pas que la tâche cliente reste bloquée durant toute la durée d’exécution d’une opération, en
attente du message de compte-rendu.

88
 Dans les applications de contrôle/commande, un exemple typique d’opération non
immédiate, c’est-à-dire d’opération dont le temps d’exécution peut être important, est
l’opération qui correspond au déplacement d’une partie mobile d’une machine.
Quand une demande de service va conduire à l’exécution d’une telle opération, on veut que
la tâche cliente puisse, si cela est nécessaire, demander au serveur d’arrêter le mouvement
en cours, avant qu’il aille à son terme, celui initialement prévu. Cela suppose que la tâche
cliente :
1. d’une part, soit informée, grâce au message de prise en compte ou non de la demande de service, du
démarrage ou non de l’opération ;
2. d’autre part, que, non bloquée sur l’attente du message de compte-rendu, elle puisse détecter les
situations conduisant à demander l’interruption de l’opération de déplacement.
Le schéma de communication de type clients/serveur décrit dans les paragraphes précédents
permet de répondre à de telles exigences.
Autre caractéristique importante que présente l’implémentation de ce schéma de communication : il est
nécessaire de connaître a priori le nombre N de tâches susceptibles d’adresser des demandes de service
à la tâche serveur.

En effet, dans l’implémentation précédemment décrite, chaque tâche cliente doit posséder
un sémaphore à compte privé, objet qu’utilise la tâche serveur pour adresser d’abord le
message de prise en compte ou non de la demande de service, puis le message de
compterendu.
Dans le paragraphe suivant, nous allons décrire un schéma de communication de type client/serveur
dans lequel une demande de service ne donne pas lieu, de la part du serveur, à l’envoi d’un message de
prise en compte puis d’un message de compte-rendu, mais seulement d’un message de compte-rendu.
L’utilisation de ce nouveau schéma se justifie lorsque les demandes de service conduisent à l’exécution
par le serveur d’opérations brèves et que, durant l’exécution de l’opération, les tâches clientes peuvent
rester bloquées en attente de la fin du service demandé.

5.3.4.5 Autre schéma de communication du type clients/serveur

A celles données en annexe 3 : Modèle des clients et du serveur , s’ajoutent les spécifications suivantes
:

La boite aux lettres où sont rangés les messages envoyés par les tâches clientes est associée à
la seule tâche serveur (il s’agit donc d’une porte pour cette tâche).

Immédiatement après avoir adressé une demande de service à la tâche serveur, la tâche
cliente se met en attente du message de compte-rendu.

Pour chaque demande de service qu’elle reçoit, la tâche serveur n’envoie qu’un seul message
à la tâche cliente : soit immédiatement après avoir pris connaissance de la demande de
service lorsque celle-ci ne peut être traitée, soit à la fin de l’exécution du service demandé.

La tâche serveur ne traite une nouvelle demande de service qu’après en avoir fini avec la
précédente demande de service, c’est-à-dire après en avoir envoyé le message de compte-
rendu à la tâche cliente concernée.

Un schéma de communication conforme aux spécifications précédentes peut être mis en œuvre avec
seulement 4 objets IPC, à savoir : un objet MP_ClientsServeur de type mémoire partagée pouvant
contenir :

89
un message de demande de service, et un message de compte-rendu. un objet mutexServeur de
type sémaphore d’exclusion mutuelle qui, lorsqu’une tâche
cliente en est propriétaire, permet à cette dernière d’avoir l’accès exclusif à la zone de
mémoire partagée MP_ClientsServeur.

un objet evDS de type événement utilisé par la tâche cliente pour

informer le serveur qu’elle a rangé un message de demande de service dans la
zone de mémoire partagée.

un objet evCR de type événement qui permet au serveur d’informer la tâche cliente de la
fin du traitement de sa demande de service et de la disponibilité du message de compte-
rendu dans la zone de mémoire partagée.

Voici le diagramme de séquence décrivant le déroulement des échanges entre une tâche cliente et la
tâche serveur lors d’une demande de service :

90
 Lire le message de compte-rendu de la
demande de service

RtReleaseMutex (hMutexServeur)
temps temps
Remarques :
1. Le schéma de communication de type clients/serveur qui vient d’être décrit est tout à fait similaire
au modèle du RPC (Remote Procedure Call). En effet, dans ce modèle, une tâche (le client) demande
un service (exécution d’une procédure) à un serveur, et se met ensuite en attente de la réponse.
2. Dans le schéma de communication décrit, la tâche serveur est en fait considérée par les tâches
clientes comme une ressource critique dont il faut d’abord acquérir la propriété pour pouvoir ensuite
lui adresser une demande de service. La tâche cliente qui a obtenu la propriété exclusive du serveur
ne la restitue qu’après avoir lu le message de compte-rendu à sa demande de service.
3. Lorsque ceci est parfaitement compatible avec le fonctionnement général de l’application, une tâche
cliente peut enchaîner les demandes de service adressées au serveur sans qu’elle ait chaque fois à

91
 restituer puis à redemander la propriété du mutex mutexServeur. Elle acquiert alors la propriété du
mutex juste avant de commencer la série de demandes de service, et la restitue seulement après avoir
lu le message de compte-rendu à la dernière demande de service de la série. ATTENTION ! Une
tâche cliente ne doit ainsi conserver le mutex d’une demande de service à l’autre que si cela ne
pénalise pas l’activité des autres tâches clientes.
4. Lorsque toutes les demandes de service adressées à la tâche serveur sont acceptées par cette dernière,
et que les tâches clientes n’ont besoin de connaître que la fin d’exécution du service, le message de
compte-rendu se réduit alors à un simple signal, celui émis lorsque le serveur exécute RtSetEvent
(hEvCR).
5. Dans ce schéma de communication, le nombre de tâches clientes peut être quelconque et n’a pas
besoin d’être connu a priori.
6. Cependant, dans le cas où il n’y a qu’une seule tâche cliente, l’objet mutexServeur de type
sémaphore d’exclusion mutuelle n’est plus nécessaire ; il peut être supprimé. La tâche cliente ne
viendra en effet écrire un nouveau message de demande de service dans la zone de mémoire partagée
qu’après avoir reçu le message de compte rendu à sa précédente demande de service.

5.3.4.6 Variante des précédents schémas de communication clients/serveur

Cette nouvelle variante du schéma de communication clients/serveur présente des caractéristiques à la

fois du schéma décrit aux § 8.4.1 et 8.4.2, et de celui décrit au § 8.4.5.

En effet, ce schéma est implémenté à partir des spécifications suivantes qui viennent s’ajouter, comme
pour les précédents schémas, à celles données en annexe 3 : Modèle des clients et du serveur du chapitre
7 :

La boite aux lettres où sont rangés les messages envoyés par les tâches clientes est associée à la
seule tâche serveur (il s’agit donc d’une porte pour cette tâche).
Une tâche cliente n’adresse une nouvelle demande de service à la tâche serveur qu’après avoir
reçu de cette dernière le message de compte-rendu à sa précédente demande de service. Toutes
les demandes de service sont prises en compte et traitées par la tâche serveur. Aussi, cette
dernière n’envoie qu’un seul message à la tâche cliente : un message de compte-rendu envoyé
à la fin de l’exécution du service demandé.
La tâche serveur peut prendre en compte une nouvelle demande de service avant d’avoir traité
entièrement les précédentes demandes de service qui lui ont été adressées, et donc avant d’en
avoir envoyé, pour chacune d’elles, le message de compte-rendu.

Le respect du point n° 2 fait que ces différentes demandes de service en cours de traitement au sein
de la tâche serveur émanent nécessairement de tâches clientes différentes.
1. Après avoir adressé une demande de service à la tâche serveur, les tâches clientes peuvent différer,
autant qu’elles le souhaitent, l’instant où elles se mettent en attente du message de compte rendu
envoyé à la fin de la réalisation du service demandé.
La mise en œuvre d’une communication de type clients/serveur conforme aux spécifications précédentes
peut être décrite à l’aide du schéma de la page suivante.

Si N est le nombre de tâches clientes, cette mise en oeuvre nécessite (N + 3) objets IPC, à savoir : un

objet MP_ClientsServeur de type mémoire partagée contenant :

92
la boite aux lettres BAL où sont rangés les messages de demande de service, les

messages de compte-rendu pour les services demandés et réalisés.

Il est prévu autant de zones de rangement pour les messages de compte rendu qu’il y a de
tâches susceptibles d’adresser des demandes de service à la tâche serveur. un objet semaBAL
de type sémaphore à compte pour contrôler le nombre de
messages de demande de service que peut contenir à un instant donné la boite aux lettres
BAL.

Cette boite aux lettres est dimensionnée pour ne contenir qu’un seul message (voir à ce
propos la remarque de la page 95). un objet evBAL de type événement à
reset automatique permet au client qui a rangé un message dans la
boite aux lettres BAL de le signaler au serveur afin que celui-ci retire le message.

N objets evCR de type event à reset automatique permettent au serveur, à la fin de

l’exécution du service demandé, de signaler à chaque tâche cliente la disponibilité du
message de compte-rendu.

93
 temps
temps

Remarque
Dans certaines mises en œuvre de ce schéma de communication, le message de compte-rendu peut, pour
toutes les demandes de service adressées au serveur, se réduire à un simple signal de fin d’exécution du
service demandé. Dans ce cas, peuvent être supprimées les boites aux lettres PorteClient[i].

94
Chapitre 6 : Cycles de vie de développements 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.

6.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é.

6.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».

95
Figure 22 : 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, nous pouvons 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 communication, le

96
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. 6.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.

6.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 oeuvre 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.

97
. 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.

6.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.

98
Figure 23.a : Modèle en Cascade affiné Figure 23.b : Itérations dans la phase de
Conception

Le modèle de vie en «Cascade» affiné est présenté sur la Figure 23.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 23.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 23a ou 23b., 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
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

99
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.

6.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 9c).

Figure 23c. : 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 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

100
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.

6.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.

101
Figure 23d. : Modèle en Prototype Rapide

6.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 23e).

102
Figure 23e : Modèle incrémental

6.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 23f).

103
Figure 23f. : Modèle en Spirale

6.2.3.d. Programmation orientée-objet (Object-Oriented Programming)

Figure 23g. : Modèle « Round-Tripping » de Booch

104
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 9g. 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.

6.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.

6.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 6.3.3 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 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,…).

105
Figure 23h. : 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»).

Malgré ces inconvénients, l’approche traditionnelle est encore très utilisée pour les applications
embarquées.

6.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

106
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 23i. : 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 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

107
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».

6.3.3. Le cycle de développement en «W» dans l’approche traditionnelle

Le modèle en «W» (voir Figure 23j) 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.

108
Figure 23j. : 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.

109
Figure 23k : 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.

6.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 23l : « 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

110
être mise à jour aisément par la partie logicielle 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.

6.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 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.

6.5. Principales normes temps réel

6.5. a. La norme POSIX

111
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…).

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

112
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.

POSIX définit les exécutifs comme étant dirigés par les événements.

6.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

113
(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, quand à 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 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

114
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.
6.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é).

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.

115
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).

6.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 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é.

116
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.

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.27). 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.
117
Figure 23m : 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.

118
 Chapitre 7 : Le développement des systèmes temps réel et embarqués
7.1 Introduction 7.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 10.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 24.1 Représentation schématique d’un système de contrôle commande.

Exemple 1 : la figure 1.2 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ôlecommande 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
119
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 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 24.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.

Un système temps réel est un système informatique soumis à des contraintes de temps. Une définition du
temps réel peut être :

« Un système est dit temps réel si l’exactitude des applications ne dépend pas seulement du résultat mais aussi
du tempsauquel ce résultat est produit. ».

Une autre définition du temps réel peut être :

« Un système est dit temps réel s’il doit s’exécuter suffisamment vite par rapport à la dynamique du procédé
contrôlé. La notion relative de vitesse s’exprime par des contraintes temporelles. »

120
La notion « suffisamment vite » est relative à la dynamique du procédé contrôlé. Par exemple, le drone
de la figure 10.2, 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
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 10.3) :

▶ 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.

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

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é.

7.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 1.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 :

122
▶ 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, prévisibilité, déterminisme, continuité
de service, tolérance aux fautes, redondance, ségrégation des moyens de calcul et de communication,
etc.).

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

7.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,

123
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…).

▶ 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.

7.1.4 Quelques exemples d’applications

Nous pouvons citer quelques exemples d’applications temps réel de contrôle commande :

124
▶ 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).

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.

7.2 Architecture des applications temps réel

7.2.1 Architecture logicielle des applications temps réel

7.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

125
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 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 24.5 Architecture logicielle d’une application de contrôle-commande multitâche.

126
▶ 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 pour les
entrées/sorties. De plus elles peuvent être liées par des relations de ty pe (voir figure 10.6) :

▶ 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 24.6 Représentation schématique de l’architecture multitâche d’une application de contrôle-

commande.

7.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
127
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é.

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 24.7 Modèle d’exécution synchrone d’une application de contrôle-commande.

128
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 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 24.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.

Pour terminer cette section, nous rappelons trois définitions importantes utilisés dans ce cours : tâche préemptible
ou tâche non-préemptible.

129
Une tâche est dite non-préemptible lorsqu’elle ne peut être interrompue qu’à des endroits spécifiques et
à la demande de la tâche elle-même : fin_de_tâche, attente_signal… Dans ce cas, la programmation est
plus simple et aucun mécanisme de partage de ressources critiques n’est à préoir. En revanche, des
temps de réponses longs peuvent se produire.

Une tâche est dite préemptible lorsque’elle peut être interrompue à n’importe quel instant et le processeur
peut être affecté à une autre tâche. Dans ce cas, les temps de réponse à un événement externe peuvent
être très courts ; mais nous avons alors une programmation plus complexe avec un besoin de mécanisme
de partage de ressources critiques.

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 abligatoirement 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 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é.

7.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;

130
▶ 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…) ;

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).

131
Figure 24.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

10.10).

Figure 24.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 :

132
▶ 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
10.11):

Figure 24.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

133
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.

134
Chapitre 8 : Modélisation des Systèmes complexes avec SysML
8.1. Introduction

Le but de ce chapitre est de présenter de façon non-exhaustive le langage de modélisation SysML pour
des systèmes complexes.

L'Ingénierie Système (IS), ou Systems Engineering en anglais (SE), est une démarche
méthodologique pour répondre à des problèmes complexes par la réalisation de solutions
logicielles et matérielles.

L'Ingénierie Système s'adresse aux secteurs suivants de l'activité industrielle :

Automobile
Ferroviaire
Aéronautique
Espace
Militaire
Systèmes embarqués (ex : encodage/décodage vidéo et audio, set top box)
Télécoms
Santé/médical
Production d'énergie, etc.

UML, langage de modélisation très répandu pour les développements logiciels spécialement
pour des systèmes d’information des entreprises, a été utilisé et adapté pour définir un langage
de modélisation des systèmes : SysML ou Systems Modeling Language. Dans cet article nous
présentons l'Ingénierie Système, un bref historique sur SysML, puis des explications sur les
modèles définis par SysML, illustrés par des exemples.

8.2. Système et Ingénierie Système

Un système est un ensemble de composants interreliés qui interagissent les uns avec les autres
d’une manière organisée pour accomplir une finalité commune.
L’ingénierie système est une démarche méthodologique générale qui englobe l’ensemble des
activités adéquates pour concevoir, faire évoluer et vérifier un système apportant une solution
économique et performante aux besoins d’un client tout en satisfaisant l’ensemble des parties
prenantes. Depuis longtemps, les ingénieurs système ont utilisé des techniques de modélisation.
Parmi les plus connues, on trouve SAD et SA/RT, qui datent des années 80, ainsi que de
nombreuses approches basées sur les réseaux de Pétri ou les machines à états finis. Mais ces
techniques sont limitées par leur portée et leur expressivité ainsi que par la difficulté de leur
intégration avec d’autres formalismes, ainsi qu’avec les exigences système.

Les méthodes de l'Ingénierie Système (IS) reposent sur des approches de modélisation et de
simulation pour valider les exigences, et pour vérifier ou évaluer le système. La modélisation a
donc couramment été utilisée pour l'IS, que ce soit pour des représentations concrètes avec des
plans ou modèles réduits, ou plus abstraites avec des systèmes d'équations.

135
En général l'IS tend à modéliser les aspects suivants du système: décomposition fonctionnelle,
flux de données, et décomposition structurelle. Exemples de techniques de modélisation
employées :

Le diagramme de flux de données (DFD ou Data Flow Diagram) pour définir les données
traversant un système et leurs traitements éventuels
Le diagramme de flux fonctionnel de bloc (FFBD ou Functional Flow Block Diagram) proche
du diagramme UML d'activité ou du « flowchart »

Les spécifications issues de l'IS relèvent souvent d'une documentation dense due à une approche
orientée documentation (« document-based approach »), qui comporte généralement une
sélection inconsistante de différents types de diagrammes.

L'alternative consiste à effectuer une transition vers une « approche orientée modèles » («
model-based systems engineering » ou MBSE), permettant de réaliser un modèle cohérent du
système, stocké et géré dans un référentiel, par exemple avec l'outil AGL Enterprise Architect
de Sparx Systems.

Cette approche permet la réalisation d'un ensemble organisé de modèles, s'appliquant à

différents niveaux de granularités tels que l'aspect opérationnel (contexte et utilisation du
système), l'aspect fonctionnel (structure et sous-fonctions du système), et l'aspect physique
(architecture). La modélisation permet de maitriser la complexité du système étudié, car chaque
modèle donne accès à une représentation abstraite de différents aspects du système.

8.3. SysML : Historique

_ .La modélisation avec le langage UML est une pratique bien établie dans l'industrie logicielle.
Bien que le langage UML permette par son caractère à usage général d'adresser de nombreux
besoins pour l'IS, il est nécessaire d'adapter ce langage de modélisation par la définition de «
profils UML ». Plusieurs projets ont été menés pour réaliser des profils UML sur des domaines
spécifiques de l'IS :

MARTE : profil UML pour des systèmes embarqués en temps-réel Profil

UML SoC (System on a Chip)

Le besoin de définir un langage basé sur UML pour l'IS a été initié en 2001 par l'organisation
internationale de l'ingénierie système INCOSE(International Council on Systems Engineering),
qui s'est mise en relation avec l'OMG (Object Management Group), organisme responsable
d'UML, pour créer le groupe d'intérêt spécialisé dans les domaines de l'IS ou « SE DSIG »
(Systems Engineering Domains Special Interest Group).

Suite à de nombreux ateliers, l'INCOSE et l'OMG ont défini et publié la demande de proposition « UML
pour l'IS » en 2003 (UML for SE RFP - Request For Proposal).

Plusieurs membres de l'industrie (BAE, Motorola, oose, Boeing.), éditeurs d'outils (IBM, Sparx
Systems.), universités et organisations (INCOSE, AP233) ont travaillés sur la définition du
langage de modélisation système SysML (Systems Modeling Language).
Juillet 2006 : OMG annonce l'adoption de SysML
Septembre 2007 : spécifications de la version 1.0 rendues officielles
Décembre 2008 : SysML v1.1
Juin 2010 : SysML v1.2 (version actuelle)
136
Les spécifications de SysML, tout comme UML, sont disponibles gratuitement en anglais depuis le
site de l'OMG : www.omg.org ou www.omgsysml.org.

SysML (Systems ModelingLanguage) est basé sur UML et remplace la modélisation de classes
et d'objets par la modélisation de blocs pour un vocabulaire plus adapté à l'Ingénierie Système.
Un bloc englobe tout concept logiciel, matériel, données, processus, et même la gestion des
personnes.

Comme représenté sur le diagramme suivant, SysML réutilise une partie d'UML2 (« UML 4
SysML » ou « UML pour SysML »), et apporte également ses propres définitions (extensions
SysML). SysML n'utilise donc pas les 13 diagrammes définis par UML 2, permettant ainsi
d'accéder à un ensemble de diagrammes accessibles et adaptés à l'IS.

L’essor d’UML dans le domaine du logiciel et l’effort industriel de développement d’outils qui
l’accompagne ont naturellement conduit à envisager son utilisation en ingénierie système.
Cependant, du fait de sa conception fortement guidée par les besoins du passage à la
programmation par objets, le langage était, tout au moins dans ses premières versions, peu
adapté à la modélisation des systèmes complexes et donc au support de l'ingénierie système
(IS).

La version 2 d’UML, officialisée en 2005, a introduit plusieurs nouveaux concepts et

diagrammes utiles pour l’IS. En particulier, le diagramme de structure composite avec les
concepts de classe structurée, partie, port et connecteur, permet maintenant de décrire
l’interconnexion statique des parties d’un système complexe. Les avancées du diagramme
de séquence permettent également de décrire des scénarios d’interaction de façon
descendante en ajoutant progressivement des niveaux d’architecture. Mais il restait toujours
la barrière psychologique du vocabulaire orienté informatique : classe, objet, héritage, etc.
La communauté de l’IS a voulu définir un langage commun de modélisation pour les
ingénieurs système, adapté à leur problématique, comme UML l’est devenu pour les
informaticiens. Ce nouveau langage, nommé SysML, est fortement inspiré de la version 2
d’UML, mais ajoute la possibilité de représenter les exigences du système, les éléments non-

137
logiciels (mécanique, hydraulique, capteur…), les équations physiques, les flux continus
(matière, énergie, etc.) et les allocations.
SysML permet la modélisation des systèmes complexes, incluant du logiciel et du matériel,
que ce soit dans l’aéronautique, l’astronautique, l’automobile, l’énergie, le transport,
l’armement, etc. Il est clair qu’une connaissance préalable du langage de modélisation UML
est un atout supplémentaire pour bien saisir toutes les subtilités de SysML, mais cela n’est
absolument pas un prérequis.
SysML s’articule autour de 9 types de diagrammes, chacun d’eux étant dédié à la
représentation des concepts particuliers d’un système. Ces types de diagrammes sont répartis
par l’OMG en trois grands groupes :

 4 diagrammes comportementaux :
a. diagramme d’activité (montre l’enchainement des actions et décisions au sein d’une
activité complexe) ;
b. diagramme de séquence (montre la séquence verticale des messages passés entre
blocs au sein d’une interaction) ;
c. diagramme d’états (montre les différents états et transitions possibles des blocs
dynamiques) ;
d. diagramme de cas d’utilisation (montre les interactions fonctionnelles entre les
acteurs et le système à l’étude) ;  1 diagramme transverse :
Le diagramme d’exigences (montre les exigences du système et leurs relations) ; 
2 diagrammes structurels :
a. diagramme de définition de blocs (montre les briques de base statiques : blocs,
compositions, associations, attributs, opérations, généralisations, etc.) ;
b. diagramme de bloc interne (montre l’organisation interne d’un élément statique complexe)
;
c. diagramme paramétrique (représente les contraintes du système, les équations qui le
régissent) ;
d. diagramme de packages (montre l’organisation logique du modèle et les relations entre
packages).

8.4. Différences UML 2 /SysML Certains diagrammes d’UML2 ont subir une légère
modification (diagrammes
d’activités, classe (diagramme de définition de bloc) et diagramme composite (diagramme de
bloc interne)) et qui n’ont pas été retenus par SysML, principalement par souci de simplification,
sont :

 le diagramme d’objets ;
 le diagramme de composants ;
 le diagramme déploiement ;
 le diagramme de vue d’ensemble des interactions ;  le diagramme de communication ;  le
diagramme de temps.
Récapitulons : 13 diagrammes (UML 2) – 6 + 2 (exigences, paramétrique) = 9 diagrammes

138
SysML !

8.5. Les 9 diagrammes de SYSML

8.5.1. Diagramme de cas d‘utilisation

8.5.1.1. Introduction
Les cas d'utilisation (use cases) ont été formalisés par Ivar Jacobson. Ils décrivent sous forme
d'actions et de réactions, le comportement d'un système du point de vue d'un utilisateur. Avant
UML, ils n'étaient pas formalisés par les autres méthodes objet telles que OMT.

Les cas d'utilisation sont utiles lors de l'élaboration du cahier des charges ou du document de
spécifications des besoins du logiciel. Le modèle des cas d'utilisation comprend les acteurs, le
système et les cas d'utilisation.

L'ensemble des fonctionnalités du système est déterminé en examinant les besoins de chaque acteur,
exprimés sous forme de famille d'interactions dans les cas d'utilisation.

Les acteurs se représentent sous forme de petits personnages qui déclenchent les cas. Ces derniers se
représentent par des ellipses contenues dans un rectangle représentant le système.

8.5.1.2. Représentation du diagramme des cas d'utilisation

La représentation d'un cas d'utilisation met en jeu trois concepts :
– l'acteur ;
– le cas d'utilisation ;
– l'interaction entre l'acteur et le cas d'utilisation.

Formalisme de base de représentation d'un cas d'utilisation.

139
L'interaction entre un acteur et un cas d'utilisation se représente comme une association. Il
existe quatre catégories d'acteurs :
– les acteurs principaux,
– les acteurs secondaires, – le matériel externe, – les autres systèmes.

Chaque acteur doit être décrit en 3 ou 4 lignes de manière claire et concise.

Les cas d'utilisation constituent un moyen de recueillir et de décrire les besoins des acteurs du
système. Les cas d’utilisation peuvent être aussi utilisés ensuite comme moyen d'organisation
du développement du logiciel, notamment pour la structuration et le déroulement des tests du
logiciel.
De plus, un cas d'utilisation peut avoir une ou plusieurs instances représentées par des scénarios.
Chaque scénario fait l'objet lui-même d'un diagramme de séquence ou de collaboration.

Exemple :

Dans cet exemple, l'acteur A déclenche le cas X et l'acteur B déclenche le cas Y.

8.5.1.3. Identification et représentation des cas d'utilisation

Tout système peut être décrit par un certain nombre de cas d'utilisation représentant les besoins
exprimés par l'ensemble des utilisateurs.
À chaque utilisateur, vu comme acteur, correspondra un certain nombre de cas d'utilisation du
système. L'ensemble de ces cas d'utilisation se représente sous forme d'un diagramme. Chaque
cas d'utilisation doit être décrit sous forme textuelle afin de bien identifier les traitements à
réaliser par le système en vue de la satisfaction du besoin exprimé par l'acteur.
Chaque cas d'utilisation produit un ou plusieurs résultats. Le travail d'identification des cas
d'utilisation suppose que les acteurs eux-mêmes soient déjà connus ou doivent l'être
complètement à la fin de l'opération de description des cas d'utilisation.

Un acteur est un utilisateur type qui a toujours le même comportement vis-à-vis d'un cas
d'utilisation. Ainsi les utilisateurs d'un système appartiennent à une ou plusieurs classes d'acteurs
selon les rôles qu'ils tiennent par rapport au système.
Exemple :
– L´administrateur d'un système de messagerie peut être aussi utilisateur de cette même
messagerie.
– Il sera considéré, en tant qu'acteur du système, dans le rôle d'administrateur d'une part et
dans celui d'utilisateur d'autre part.

140
Exemple : Un système de messagerie comporte quatre cas d'utilisation.

8.5.1.4. Relations entre cas d'utilisation

Afin d'optimiser la formalisation des besoins en ayant recours notamment à la réutilisation de cas
d'utilisation, trois relations peuvent être décrites entre cas d'utilisation :
– relation d'inclusion (« include») ; – relation d'extension (« extend») ; – relation de
généralisation.

1) Relation d'inclusion
Une relation d'inclusion d'un cas d'utilisation A par rapport à un cas d'utilisation B signifie qu'une
instance de A contient le comportement décrit dans B.

Formalisme
Exemple d'une relation d'inclusion
entre cas d'utilisation.
2) Relation d'extension
Une relation d'extension d'un cas d'utilisation A par un cas d'utilisation B signifie qu'une
instance de A peut être étendue par le comportement décrit dans B. Deux caractéristiques sont
à noter :
– le caractère optionnel de l'extension dans le déroulement du cas d'utilisation standard (A) ;
– la mention explicite du point d'extension dans le cas d'utilisation standard.

Formalisme Exemple d'une relation d'extension entre cas d'utilisation.

141
 3) Relation de généralisation
Une relation de généralisation de cas d'utilisation peut être définie conformément au principe de
la spécialisation/généralisation déjà défini pour les classes.
La figure suivante donne un exemple d'une relation de généralisation de cas d'utilisation.

4) Relations entre acteurs

Il est possible de définir une relation d'héritage entre acteurs afin d'éviter de surcharger les diagrammes.
Un acteur qui hérite d'un autre acteur hérite de toutes ses interactions.

Exemple : Gestion bibliothécaire

5) Description textuelle des cas d’utilisation

Pour chaque cas d’utilisation, on réalise une fiche descriptive comportant généralement les quatre
volets suivants :
– Identification,
– Description des scénarios,
– Fin et post-conditions, – Compléments.
Identification :
Dans le volet identification, on indique :
– Le numéro du cas d’utilisation,
– le nom du cas d’utilisation,

142
 – l’acteur ou les acteurs pour les cas d’utilisation principaux ou le nom du cas d’utilisation principal
pour les cas d’utilisation internes,
– Une description succincte du cas d’utilisation,
– la date de rédaction de la fiche et l’auteur,
– les pré-conditions : conditions obligatoires pour le bon déroulement du cas d’utilisation. Par
exemple, il faut obligatoirement s’authentifier pour pouvoir Consulter le catalogue produit,
– les événements à l’origine du démarrage du cas d’utilisation.

Description des scénarios Les scénarios explicitent la chronologie des actions qui seront
réalisées par l’utilisateur et le système. Il existe 3 parties :
– Le scénario nominal: déroulement idéal des actions (quand tout va pour le mieux).
– Les scénarios alternatifs: éventuelles étapes différentes liées aux choix de l’utilisateur (cas des
étapes liées à des conditions).
– Les scénarios d’exception: déroulement causé par la présence d’un événement anormal. Par
exemple, lorsqu’une recherche de client ne trouve aucun client correspondant aux critères fournis.
Ces scénarios sont décrits en utilisant une description textuelle ou sous forme de tableau. Ils sont
généralement présentés sous forme de liste numérotée : 1, 2, 3, ... pour le déroulement du
scénario nominal et 1a, 1b, 2a, 2b, … pour les scénarios alternatif et d’exception.

Exemple :
Cas d’utilisation «Retirer de l’argent à partir d’un GAB» Scénario nominal
1. Le GAB demande le code de la carte
2. L’utilisateur saisit son code confidentiel
3. Le GAB vérifie que le code saisi est correct
4. .…
Scénarios alternatifs
– Si le code est invalide …
Scénarios d’exception
– Au bout de trois mauvaises
tentatives …

6) Fin et post-conditions
La description détaillée d’un cas d’utilisation concerne :
– la fin du cas d’utilisation ; –
les post-conditions.
La fin permet de récapituler toutes les situations d’arrêt du cas d’utilisation.
Les post-conditions indiquent un résultat vérifiable après l’arrêt du cas d’utilisation témoignant du bon
fonctionnement.

7) Compléments
Les compléments peuvent porter sur des aspects variés :
– l’ergonomie ;
– la performance attendue ;
– des contraintes (techniques ou non) à respecter ;
– des problèmes non résolus (ou questions à poser au client et aux futurs utilisateurs).

143
8.5.2. Diagramme d’activités

8.5.2.1. Introduction
Un diagramme d'activités (activités et transitions) est une variante du diagramme
d'étatstransitions (états et transitions). Les deux types de diagrammes permettent d'avoir deux
vues différentes sur des automates donnés.
Toutes les propriétés des diagrammes d'activités UML sont également disponibles avec SysML.
SysML a rajouté quelques spécificités :
• Notion de contrôle pour activer ou désactiver les actions en cours.
• Spécification de la nature du débit sur le flot : système continu ou discret
• Définition de taux et de probabilité sur les flots

Un diagramme d'activités visualise un graphe d'activités qui modélise le comportement

interne d'une méthode (une réalisation d'une opération), d'un cas d'utilisation ou plus
généralement d'un processus impliquant un ou plusieurs classificateurs (classes / cas d'utilisation
/ paquetages /...).

Un diagramme d'activités représente l'état d'exécution d'un mécanisme, sous la forme d'un
déroulement d'étapes regroupées séquentiellement dans des branches parallèles de flots de
contrôle. Il ne représente ni la collaboration ni le comportement des objets. Il est utile pour la
représentation des processus métiers et les cas d'utilisation.
Le diagramme d'activités comprend :
– des activités (une activité= une étape d'exécution, état-activité). Une activité représente une
exécution d'un mécanisme, un déroulement d'étapes séquentielles. Le passage d'une activité vers
une autre est matérialisé par une transition.
– des transitions qui sont automatiques entre activités, il est inutile également de préciser les
événements. Les transitions sont déclenchées par la fin d'une activité et provoquent le début
immédiat d'une autre.
En théorie, tous les mécanismes dynamiques pourraient être décrits par un diagramme d'activités, mais
seuls les mécanismes complexes ou intéressants méritent d'être représentés.

Activités et transition, notation :

8.5.2.2. Action
Une action est le plus petit traitement qui puisse être exprimé en UML. Une action a une
incidence sur l’état du système ou en extrait une information. Les actions sont des étapes
discrètes à partir desquelles se construisent les comportements. La notion d’action est à
rapprocher de la notion d’instruction élémentaire d’un langage de programmation (comme C++
ou C#).
Une action peut être, par exemple :
– une affectation de valeur à des attributs ;
– un accès à la valeur d’une propriété structurelle (attribut ou terminaison d’association)

144
 ;
– la création d’un nouvel objet ou lien ;
– un calcul arithmétique simple ;
– l’émission d’un signal ;
– la réception d’un signal ;

8.5.2.3. Activité & Groupe d’activités

Une activité définit un comportement décrit par un séquencement organisé d’unités dont les
éléments simples sont les actions. Le flot d’exécution est modélisé par des nœuds reliés par des
arcs (transitions). Le flot de contrôle reste dans l’activité jusqu’à ce que les traitements soient
terminés. Une activité est un comportement et à ce titre peut être associée à des paramètres. Un
groupe d’activités est une activité regroupant des nœuds et des arcs. Les nœuds et les arcs
peuvent appartenir à plus d’un groupe. Un diagramme d’activités est lui même un groupe
d’activités.
8.5.2.4. Etat-action
Un état-action modélise une étape dans l'exécution d'un algorithme.
Il consiste en un état simplifié dans lequel figure une action d'entrée et avec au moins une
transition automatique vers un autre état, déclenchée par la fin de l'action d'entrée. Il correspond
à l'exécution d'instructions atomiques.

8.5.2.5. Etat-activité
Un état-activité correspond à une exécution non atomique. Un état d'activité peut être décomposé en
d'autres états-activité et/ou états-action.

8.5.2.6. Définition & Exemple

Un état-action ou un état-activité est une étape particulière du traitement englobant. Ces étapes
sont reliées par des transitions de complétude : transition automatique sans déclencheur ou
aussi transition de terminaison (fin de l'activité actuelle déclenche automatiquement l'activité
suivante).

8.5.2.7. Transition conditionnelle

Il est possible de représenter des transitions conditionnelles en utilisant des gardes(appelées aussi
décisions) qui doivent être mutuellement exclusives.
145
8.5.2.8. Transition composite

Une décision peut aussi utiliser des transitions composites et créer un point de jonction. Le point de
jonction (décision) :
– matérialisé par un losange
– en entrée une seule transition en sortie plusieurs transitions

À un point de jonction peuvent se rejoindre des chemins séparés par de précédentes décisions.
Ce point reçoit plusieurs transitions gardées ou non en entrée (flots entrant) mais il permet une
seule transition en sortie (flot sortant). Il n'est pas utilisé pour synchroniser des flots concurrents
mais pour accepter un parmi plusieurs

8.5.2.9. Noeuds de contrôle

146
Un noeud de contrôle est un noeud d’activité abstrait utilisé pour coordonner les flots entre les noeuds
d’une activité.
Il existe plusieurs types de noeuds de contrôle :
noeud initial (initial node) ; noeud de
fin d’activité (final node) ; noeud de
fin de flot (flow final node) ; noeud de
décision (decision node) ; noeud de
fusion (merge node) ; noeud de
bifurcation (fork node) ; noeud d’union
(join node).

8.5.2.10. Types de nœuds contrôle

Noeud initial
Un noeud initial est un noeud de contrôle à partir duquel le flot débute lorsque l’activité
enveloppante est invoquée. Une activité peut avoir plusieurs noeuds initiaux. Un noeud initial
possède un arc sortant et pas d’arc entrant. Graphiquement, un noeud initial est représenté par
un petit cercle plein .

Noeud final
Un noeud final est un noeud de contrôle possédant un ou plusieurs arcs entrants et aucun arc sortant.

Noeud de fin d’activité

Lorsque l’un des arcs d’un noeud de fin d’activité est activé, l’exécution de l’activité
enveloppante s’achève et tout noeud ou flot actif au sein de l’activité enveloppante est
abandonné.

Graphiquement, un noeud de fin d’activité est représenté par un cercle vide contenant un petit cercle
plein.

Noeud de fin de flot

147
Lorsqu’un flot d’exécution atteint un noeud de fin de flot, le flot en question est terminé, mais
cette fin de flot n’a aucune incidence sur les autres flots actifs de l’activité enveloppante.
Graphiquement, un noeud de fin de flot est représenté par un cercle vide barré d’un X.

Un noeud de décision : est un noeud de contrôle qui permet de faire un choix entre plusieurs
flots sortants. Il possède un arc entrant et plusieurs arcs sortants. Ces derniers sont généralement
accompagnés de conditions de garde pour conditionner le choix. Graphiquement, on représente
un noeud de décision par un losange.

Noeud de fusion (merge node)

Un noeud de fusion est un noeud de contrôle qui rassemble plusieurs flots alternatifs entrants en
un seul flot sortant. Il n’est pas utilisé pour synchroniser des flots concurrents (c’est le rôle du
noeud d’union) mais pour accepter un flot parmi plusieurs. Graphiquement, on représente un
noeud de fusion, comme un noeud de décision, par un losange .

Noeud de bifurcation ou de débranchement (fork node)

Un noeud de bifurcation, également appelé noeud de débranchement est un noeud de contrôle
qui sépare un flot en plusieurs flots concurrents. Un tel noeud possède donc un arc entrant et
plusieurs arcs sortants. Graphiquement, on représente un noeud de bifurcation par un trait plein

Noeud d’union ou de jointure (join node)

Un noeud d’union, également appelé noeud de jointure est un noeud de contrôle qui synchronise
des flots multiples. Un tel noeud possède donc plusieurs arcs entrants et un seul arc sortant.
Graphiquement, on représente un noeud de union, comme un noeud de bifurcation, par un trait
plein.

8.5.2.11. Synchronisation : Disjonction & Conjonction d'activités

Il est possible de synchroniser les transitions à l'aide des "barres de synchronisation" (comme
dans les diagrammes d'états-transitions). Une barre de synchronisation permet d'ouvrir et de
fermer des branches (chemins) parallèles au sein d'un flot d'exécution d'une méthode ou d'un
cas d'utilisation. Les transitions qui partent d'une barre de synchronisation ont lieu en même
temps.
Union : Une barre de synchronisation ne peut être franchie que lorsque toutes les transitions en
entrée sur la barre sont déclenchées.
Bifurcation : Les transitions de débranchement au départ d'une barre de synchronisation sont
déclenchées simultanément.

Exemple : Synchronisation

Dans un diagramme d'activités, la même action peut être exécutée plusieurs fois.

148
8.5.3. Diagramme d'état-transition (DET)
Le diagramme d'états transition a pour objectif de représenter des traitements permettant de
gérer le domaine étudié. Les traitements sont positionnés par rapport à des classes et plus
précisément par rapport à des états de classes.
Le diagramme d’états-transitions met en évidence l'enchaînement des différents états d'une classe. Le
diagramme d'états transition est associé à une classe pour laquelle on gère
différents états :
il permet de représenter tous les états possibles,
ainsi que les événements provoquant un changement d'état.

Le diagramme d'états est utilisé avec SysML de la même manière qu'avec UML2,
c'est-à-dire qu'il de représenter le cycle de vie auquel doivent se conformer toutes les instances
d'un bloc donné, ce au travers de la modélisation de tous les états possibles. Il modélise
l'évolution de l'état d'un block en fonction des événements qui peuvent se produire.
Seuls les blocs qui sont importants d'un point de vue métier, ou qui sont de nature complexe, possèdent
un diagramme d'état.
8.5.3.1. Etat
Le nom de la classe peut être qualifié par un «stéréotype» avec d'éventuelles
autres précisions (auteur de la classe par exemple).
Un état est une situation durable dans laquelle peuvent se trouver les objets d'une classe et à
laquelle on associe des règles de gestion. Les objets de certaines classes n'ont qu'un seul état
149
pendant toute la durée de leur existence. Pour d'autres classes, au contraire, on détermine
différents états.
Un état d’un objet est une situation stable dans la vie de l’objet où il effectue une activité ou il
attend un événement. A un instant donné, un objet est dans un état. L'état est présenté dans un
rectangle aux angles arrondis.

Il s’agit de tenir compte uniquement les états caractéristiques d’un objet

Exemple : Un objet de la classe «Commande» a les états suivants : En préparation et En cours.

La définition d'un état peut être complétée :
par un ensemble de valeurs prises par les attributs de l'objet
L'état En préparation de la commande est vérifié par une date d'expédition non servie ou
supérieure à la date du jour.
par sa participation effective à une association.
Un salarié est dans l'état Affecté lorsqu'il est associé à un poste de travail.

Un objet passe d'un état à un autre suite à un événement. Cependant, quand un objet est dans un
état donné, seuls certains événements provoquent un changement d'état ; d'autres événements
sont sans effet.

8.5.3.2. Transition
On appelle transition, une relation entre deux états signifiant qu'un passage de l'un à l'autre est
possible. En d'autres termes, une transition est une relation orientée entre deux états, à laquelle
est attaché un événement et qui indique qu'un objet dans le premier état passera dans le second
si certaines conditions sont remplies.

La transition est représentée par une flèche entre deux états, accompagnée du nom de l'événement.

L'événement Expédition, assure la transition entre l'état « En préparation » et l'état « En attente » de la

commande.

Exemple :
Par exemple, on décide de gérer cinq états pour un objet de la classe Police d'assurance : « En
cours de souscription », « Abandonnée », « Ouverte », « Suspendue » et « Résiliée ». Les
passages entre états correspondent aux événements suivants :
Signature du client, Expiration du délai avant signature,
Demande de suspension, Date de suspension, Demande de fin de suspension, Délai de
suspension expiré,

150
 Demande de résiliation et Nombre de sinistres trop élevé. Les transitions sont indiquées dans la
figure suivante :

Transition
Condition de garde
La transition peut être soumise à la vérification d'une expression appelée condition de garde.

Sur l'exemple suivant, l'indication Nombreux sinistres [nombre=5] indique que la classe Police
d'assurance passe de l'état «Ouverte» à l'état «Résiliée» à l'issue du 5ème sinistre.

Etat
Etats prédéfinis
État initial : Il est obligatoire et unique. On le considère comme un pseudo-état. L'action de création est
généralement associée à l'événement de sortie de cet état.

État final : Un objet peut avoir plusieurs états finaux. Les événements conduisant à un état final sont
fréquemment associés à une action de destruction ou d'archivage.

151
8.5.3.3. Action
Une action est une opération élémentaire et instantanée. L'action peut figurer sur une transition ou dans
un état. Une action est une réaction du système à un événement.

Si l'on veut que l'action soit déclenchée au moment où l'événement associé à la transition se produit, on
l'indiquera directement sur la transition, précédée d'un " / ".

Lorsque l'événement se produit, si la condition est vérifiée, alors l'action est effectuée.

Par exemple, on peut associer l'action «Comptabiliser l'échec» à l'événement Refus Client qui fait
passer la police dans l'état «Abandonnée».

Les actions figurant dans un état sont déclenchées par trois types d'événements :
L'entrée dans l'état
La sortie de l'état
Un événement, appelé transition interne, qui laisse l'objet dans le même état.

152
Événements internes à l'état :
Événement à l'entrée : Entry
Événement à la sortie : Exit
Événement sans changement d'état : event
Activité : Do

Les actions associées à l'état « En préparation » d'une commande.

Lorsqu'une commande entre dans l'état « En préparation », les actions suivantes sont à réaliser
: choix du fournisseur, détermination des quantités initiales à commander et valorisation de la commande.
Durant l'état « En préparation », le fournisseur peut modifier ses tarifs. Dans ce cas, il convient
de refaire la valorisation. L'expédition de la commande intervient le dernier jour ouvrable du
mois. Cet évènement va faire changer l'état de la commande.

A la sortie de l'état « En préparation », la date d'expédition est enregistrée et un exemplaire de

la commande est envoyé au fournisseur. Une activité est une opération qui dure. Elle ne peut
être attachée qu'à un état (et non à une transition).

Sa syntaxe est analogue à celle d'une action : la mention de l'évènement déclenchant l'action est
remplacée par le mot clé Do. L'activité dure tant que l'objet est dans l'état. Elle n'est pas
interrompue par les transitions internes. Elle ne s'arrête qu'à la sortie de l'état.

8.5.3.4. États composites

153
Pour appréhender plus facilement la complexité des traitements décrits, nous pouvons utiliser
les concepts de généralisation/spécialisation, déjà employés pour décrire la complexité des
classes. Un état (le super état) va pouvoir se décomposer en plusieurs états (les sous états).

Objectifs :
Hiérarchiser les états
Structurer les comportements complexes
Factoriser les actions

Simplification par décomposition hiérarchique et factorisation

8.5.3.5. Utilisation

En phase d'analyse :
Description de la dynamique du système vu de l'extérieur
Synthèse des scénarios liés aux cas d'utilisation
Événements = action des acteurs

En phase de conception :
Description de la dynamique d'un objet particulier
Événements = appels d'opérations

8.5.4. Diagramme de séquences (DSE)

8.5.4.1. Scénario
Un scénario peut être considéré comme :
Une suite spécifique d'événements survenant dans le système.
Une séquence spécifique d'actions et d'interactions entre les acteurs et le système.

Exemples :
Un achat réussi d'articles à travers une carte de crédit, ou
Un échec d'achat d'articles à cause d'un refus de paiement à crédit.

Deux types de scénario existent :

Principal : description du chemin normal d’exécution du cas d’utilisation. Exemple
: Retrait-distributeur pour un client existant et fiable

Secondaires : description de cas alternatifs (plusieurs choix), de cas exceptionnels ou de cas

d’erreur.
Exemple : Retrait-distributeur pour un client donnant un code erroné
154
Il est possible d’avoir trois représentations possibles pour un scénario :
description textuelle en langage naturel
diagramme de séquence
diagramme de collaboration

8.5.4.2. Scénario - description textuelle en langage naturel

Exemple: Retrait-distributeur (cas normal) : Monsieur

X insère sa carte,
le distributeur D1 accepte la carte et lit le numéro du compte et de la banque,
D1 demande le code de Monsieur X;
X entre son code „xxxxxx’,
D1 demande au consortium C1 de vérifier le numéro de compte et le code saisi,
C1 retourne son acceptation à D1,
D1 demande à Monsieur X le montant du retrait,
Monsieur X indique le montant Y

Décrivent les interactions entre les acteurs et les objets du système selon un point de vue
temporel l'accent est mis sur la chronologie des envois de messages.

Typiquement utilisés pour représenter l’interaction détaillée qui prend place dans un cas d’utilisation ou
pour une opération.

Les diagrammes de séquence représentent des échanges de messages entre objets. Ils doivent rester
aussi simples que possible et seuls les messages pertinents doivent être représentés.

Comme les diagrammes de séquence sont toujours lus du haut vers le bas, ils illustrent l'ordre dans
lequel les messages sont envoyés entre les objets.

155
 L‟axe vertical représente le temps.
L‟axe horizontal représente les objets/acteurs impliqués dans l'interaction.
Une ligne verticale est attachée à chaque objet/acteur et représente sa ligne de vie
«lifeline».

8.5.4.3. Les objets/acteurs

Sur un diagramme de séquence, les objets apparaissent toujours dans la partie supérieure, ce qui
facilite l'identification des classes qui participent à l'interaction.

8.5.4.4. Les messages

Les messages sont représentés par des flèches directionnelles. Cette représentation est similaire
à celle d'une association sur un diagramme de classes ; cependant, les messages servent à
représenter la communication entre les objets, et non la relation structurelle présente entre les
classes.
Au-dessus des flèches directionnelles figure un texte informant du message envoyé entre les objets.

156
Les messages peuvent être numérotés selon l'ordre dans lequel ils sont envoyés. Sur les
diagrammes de séquence, cette numérotation est quelque peu redondante, car l'ordre des
messages est toujours déterminé par l'ordre dans lequel ils apparaissent dans le diagramme, du
haut vers le bas.

Il est possible de montrer un objet qui s'envoie un message à lui-même à l'aide d'un message
réflexif. Il n'y a aucune restriction quant au sens des messages. Sur les diagrammes de séquence,
les messages peuvent être dirigés de droite à gauche ou de gauche à droite.

8.5.4.5. La ligne de vie de l'objet/acteur

Ce concept représente la vie d'un objet dans le contexte de la séquence d'événements. Les objets
qui sont créés vers la fin de la séquence n'apparaissent pas toujours en haut du diagramme, mais
peuvent apparaître à l'endroit où ils sont créés.
La ligne de vie peut se terminer à l'endroit où l'objet est détruit. De même, la création d'un objet peut
être représentée simplement par l'envoi d'un nouveau message à un objet.

8.5.4.6. Le point de contrôle (barre d’activation)

Ce concept illustre la période pendant laquelle un objet effectue une action. La quantité de temps
réelle, mesurée en unités telles que les secondes, n'est pas pertinente.

La seule chose qui nous intéresse est de savoir pendant quelle période une méthode donnée
détient le contrôle sur la séquence des événements. La mention du point de contrôle est
facultative.

Sur les diagrammes de séquence, ce point de contrôle peut être représenté graphiquement en plaçant
un rectangle au-dessus de la ligne de vie de l'objet.

157
8.5.4.7. Exécution simultanée
158
Contrainte temporelle

Pour représenter de manière graphique une exécution conditionnelle d'un message, on peut
documenter un diagramme de séquence avec du pseudo-code et représenter des bandes
d'activation conditionnelles.

Le pseudo-code peut aussi être utilisé pour indiquer des itérations (avec par exemple incrémentation d'un
paramètre dans le message).

Exemple :

Sur l'exemple suivant, un client demande un devis, un commercial recherche le prix de base du
produit et les ristournes accordées et communique le devis au client.

Utilisation
Description simplifiée d’un processus (le workflow, les échanges entre acteurs ou avec
le système d’information)
Représentation des collaborations entre objets selon un point de vue temporel
Description de scénarios typiques (scénario d’un cas d’utilisation)
Les diagrammes de séquences et les diagrammes d'état-transitions sont les vues dynamiques les
plus importantes d'UML.
…

8.5.5. Le diagramme des exigences

159
C'est un outil qui permet d'exposer les différentes contraintes que doit respecter le système. Il est
une traduction du cahier des charges sous forme d’une décomposition en exigences.

Le diagramme d’exigences capture les hiérarchies d’exigences, ainsi que leurs

relations de dérivation, de raffinement, de satisfaction et de vérification. Ces relations
fournissent la capacité de relier les exigences les unes aux autres, ainsi qu’aux éléments de
conception et aux cas de tests.
Que ce soit pour l'ingénierie système ou pour des réalisations logicielles, les
exigences sont couramment utilisées pour formaliser les pré-requis du système, se traduisant par
des fonctionnalités ou conditions qui doivent ou devraient être satisfaites par le système (selon
les éventuelles priorités associées aux exigences).

L’objectif de ce diagramme:
a. Recenser toutes les exigences auxquelles le système doit se plier.
b. Morceler toutes les exigences afin d’en avoir une vue plus précise, et surtout plus logique et moins
éparpillée, à travers différents documents.
c. Améliorer la communication entre différents services afin de s’écarter le plus possible du langage
naturel, source d’ambiguïté.

8.5.5.1. Méthodologie
Pour commencer à écrire les diagrammes, nous allons utiliser la méthode
suivante :

1. Nous plaçons des groupes d’exigences qu’on risque de retrouver surement à chaque fois, c’est-
à-dire :
Exigences marketing
Exigences fonctionnelles
Exigences environnementales
Exigences techniques
Exigences économiques

2. Vous posez par la suite les premières exigences générales pour chacune de ces catégories puis
vous continuez en précisant par d’autres exigences secondaires si nécessaires.

8.5.5.2. Traduction littérale du diagramme des exigences

a. L'exigence
Une exigence se représente par un rectangle :

On trouve plusieurs informations:

 Le type d'exigence (<<requirement>>).
160
  L'identifiant (Id) représentant l'ordre affecté à cette exigence.
 Le texte, qui décrit l’exigence, doit être concis. On doit y retrouver tous les éléments du cahier
des charges.

b. Les liens entre les blocs d'exigence

Ces liaisons posent un lien logique entre 2 exigences.

 Le lien de contenance : il indique que l’exigence du côté du rond contient l’exigence à l’autre
extrémité. Il se représente par :

 La liste suivante représente les "stéréotypes" décrivant les liens disponibles dans les
diagrammes exigences SysML :

<< stéréotypes >> Exemple : << refine >>

Les stéréotypes sont tous les mots encadrés par des doubles chevrons comme
ceci : <<block>>. On les trouve à côté de plusieurs types d’éléments graphiques SysML.
L’objectif étant d’être facile à lire (en plus d’avoir une syntaxe précise), il est hors de question
d’inventer des symboles pour chacun d’eux. On va donc retrouver plusieurs fois le même
symbole mais avec un stéréotype différent, ce qui permet de les différencier. On trouvera par
exemple des flèches identiques mais accompagnées d’un stéréotype :

Allocate: Creates an Allocate dependency / Crée une dépendance d’attribution : „alloué

à’
Part: Creates a Part dependency / Crée un lien 'partition'.
Derive: Creates a Derive link / Crée un lien de dérivation

Copy: Creates a Copy dependency / Crée un lien de „copie’

Satisfy: Creates a Satisfy dependency / Crée un lien de satisfaction
Verify: Creates a Verify dependency / Crée un lien de vérification
Refine: Creates a Refine dependency / Crée un lien de précision
Trace: Creates a Traceability link / Crée un lien de tracabilité
Problem : commentaire dont la description pose le problème, ou au sujet du besoin qui a donné
lieu à la création de l'association (ou de l'élément associé)
Rationale: commentaire dont la description indique la raison ou la justification par rapport à
l'association (ou à l'élément associé)
Note : Crée un commentaire
Constraint : Crée une contrainte.

c. Les stéréotypes

161
 d. Lien entre les exigences
1. Exigences marketing DesignRequirement
2. Exigences fonctionnelles FonctionalRequirement
3. Exigences environnementales 'Rationale' (rappel des normes...)
4. Exigences techniques
UsabilityRequirement
PerformanceRequirement
PhysicalRequirement
5. Exigences économiques BusinessRequirement

Exemple de diagramme d’exigences d’une Balance:

Normalement ce diagramme comprend de nombreuses exigences (techniques,
marketing, financières, etc...). Dans un premier temps, afin de mieux les organiser, on peut les

162
disposer comme proposé ci-dessous dans une vue arborescente.

Le diagramme des exigences ne sert pas seulement à placer des contraintes dans le modèle. Il
permet aussi de ramener des éléments venant d’autres diagrammes du modèle et ainsi de vérifier
qu’une exigence a bien été prise en compte de quelque manière que ce soit, que ce soit:

1. par un cas d’utilisation (donc prise en compte d’une exigence par une fonctionnalité),

2. par un bloc (prise en compte par un élément structurel),

3. ou autre (rise en compte par un élément comportemental par exemple).

163
Exemple

Caractéristiques :

Précision de 1 g ;

Charge maximale = 3 kg ;

Dimensions : 24 x 19,5 x 3,5 cm

Interface Homme/Machine :

• Bouton Marche/Arrêt/Tare

• Bouton Conversion g/ml

• Afficheur LCD 4 digits

Design épuré aux formes circulaires ;

Gamme de 5 coloris tendances ;

Conforme aux directives DEEE et RoHS.

Exigences de Marketing

Mise en situation :

Lancement du produit : « Afin de continuer à innover et de garder sa place sur le

segment des balances culinaires, nous souhaitons proposer une balance d'entrée
de gamme au design innovant » ;

L’exigence de Marketing principale vous est donnée.

Travail demandé : A partir de la mise en situation, ainsi que des caractéristiques disponibles :

Proposer au moins 3 exigences contenues dans celle-ci, en spécifiant leur type. Exigences

de Marketing (corrigé)

164
Exigences de pesée

Mise en situation :

Vous disposez d’un diagramme d’exigences incomplet.

Travail demandé : réusiner les exigences présentes et faire apparaitre sur ce diagramme :

Les relations des exigences déjà présentes ;

Une exigence de raffinement (à créer) ;

Une relation de « satisfy » par un bloc (bloc à aller chercher dans l’arbre de
confinement).
Exigences de pesée (corrigé)

8.5.6. Diagramme de définition de blocs (Diagramme de classe en UML)

Ce chapitre présente le diagramme de définition de blocs. Le bloc SysML
(« block ») constitue la brique de base pour la modélisation de la structure d’un système. Il peut
représenter un système complet, un sous-système ou un composant élémentaire.

Les blocs sont décomposables et peuvent posséder un comportement. Le

165
diagramme de définition de blocs décrit la hiérarchie du système et les classifications
système/composant.

Le diagramme de définition de bloc (BDD, ou Block Definition Diagram en

anglais) représente la vue boîte noire d'un bloc. Ainsi le bloc principal et la hiérarchie des blocs qui
le composent, qu'ils soient logiciels ou matériels, sont spécifiés dans ce diagramme.

Par rapport à UML, le BDD de SysML redéfinit le diagramme de classe en remplaçant les classes par
des blocs.

Le BDD est similaire à la première page d'une notice de montage d'un meuble,
indiquant la liste des éléments et des pièces à assembler avec leurs quantités respectives.

Il répertorie les constituants du système ou d'un block en précisant

éventuellement leur rôle et leur quantité. Chaque block peut faire l'objet d'une description plus
précise en indiquant ses constituants, ses propriétés et les opérations qu'il peut effectuer ainsi
que les contraintes ou limites auxquelles il est soumis.

Le diagramme de définition de bloc est utilisé pour représenter les blocs, leurs
propriétés, leurs relations et les comportements.

Les propriétés sont les caractéristiques structurelles de base des blocs. Elles
peuvent être de deux types principaux :

 les valeurs (value properties) décrivent des caractéristiques quantifiables en terme de value
types (domaine de valeur, dimension et unité optionnelles) ;
 les parties (part properties) décrivent la hiérarchie de décomposition du bloc en termes
d’autres blocs. Il s’agit d’une relation de composition entre blocs, aussi appelé relation « tout-
partie », dans laquelle un bloc représente le tout, et les autres ses parties. Une instance du tout
peut contenir plusieurs instances d’une partie, grâce à la notion de multiplicité, évoquée
précédemment. nom partie : nom bloc [multiplicité]

« block »

nom

Valeur et attribut opération

 Opération : Tout bloc possède

également des propriétés comportementales, les principales étant appelées opérations.

Les opérations sont montrées dans un compartiment supplémentaire avec leur signature (nom, paramètres
et type de retour) :

nom_opération (liste de paramètres) : type_retour

Chaque bloc (ou type) définit un ensemble d’instances partageant les

propriétés du bloc, mais possédant chacune une identité unique. Par exemple : ma voiture, de
numéro d’immatriculation : A7310 et de kilométrage : 92.000 , est une instance du bloc Voiture.

166
Quels sont les problèmes de ce premier bdd ?

Nous voyons donc clairement que le modèle proposé n’est pas du tout satisfaisant. C’est
justement pour cela que SysML propose le diagramme de bloc interne : pour représenter des
liaisons contextuelles entre des parties à l’intérieur d’un certain bloc englobant.

8.5.7. Le diagramme de bloc interne (diagramme composite en UML)

Ce chapitre présente le diagramme de bloc interne. Le diagramme de bloc
interne (internal block diagram ou ibd) décrit la structure interne du système en termes de parties, ports
et connecteurs.

ibd [bloc] nom du bloc [nom du diagramme]

Contrairement au Diagramme de définition de bloc où l’on va trouver un schéma

architecturale entre les blocs conteneurs et les blocs contenu, le Diagramme de bloc interne
intègre les blocs contenus dans le bloc conteneur.

a. Parties (parts en anglais)

On peut représenter la connexion entre les éléments d’un bloc au moyen d’un
diagramme de bloc interne. Ce diagramme montre principalement les relations entre éléments de même
niveau, ainsi que les éventuelles multiplicités des parties.

Dans l’exemple de la voiture, nous pouvons commencer par représenter les roues avant et
arrière ainsi que le moteur. La relation de composition du bdd se traduit de la façon suivante
dans l’ibd :

• le cadre de l’ibd représente le bloc englobant. Il fournit le contexte pour tous les
éléments du diagramme ;

• chaque extrémité d’une relation de composition, ou élément du compartiment parts,

apparaît comme un bloc à l’intérieur du cadre. Le nom du bloc est identique à ce qui
apparaitrait dans le compartiment parts, soit :

nom_partie : nom_bloc [multiplicité].

167
La multiplicité peut également être représentée dans le coin supérieur droit du rectangle.

S’il n’y a pas d’indication de multiplicité, elle est supposée valoir exactement 1.

Les associations simples et les agrégations sont représentées de façon

similaire aux compositions, sauf que le rectangle du bloc est en pointillé. Ainsi, les bagages peuvent
apparaître dans l’ibd, mais aussi la route empruntée, si nous le souhaitons (il est clair que les bagages
sont dans la voiture et qu’il est intéressant de les représenter, pour la route c’est plus discutable...).

Il est important de noter qu’on peut représenter plusieurs niveaux de décomposition ou de

référence sur un même ibd. Dans notre exemple, si nous voulons exprimer le fait que les
bagages sont dans le coffre de la voiture, il suffit d’ajouter une partie coffre à la voiture, et de
déplacer la référence bagages à l’intérieur de cette nouvelle partie.

Le diagramme de bloc interne est surtout utile pour montrer les connexions
contextuelles entre les parties d’un bloc, ce qui ne peut pas être représenté sur un bdd. b.

Connecteur

168
 Le connecteur est un concept structurel utilisé pour relier deux parties et leur
fournir l’opportunité d’interagir, bien que le connecteur ne dise rien sur la nature de cette
interaction. Les connecteurs permettent également de relier plus finement les parties à travers
des ports. L’extrémité d’un connecteur peut posséder une multiplicité qui décrit le nombre
d’instances qui peuvent être connectées par des liens décrits par le connecteur.

Soyons précis :
 une association (agrégation, ou composition,…) relie des blocs ;
 un connecteur relie des parties ;  un lien relie des instances.
Un connecteur peut être typé par une association. Il peut ainsi posséder une
flèche unidirectionnelle. Son nom complet est de la forme :

nom_connecteur : nom_association

NB : Une partie peut être connectée à plusieurs autres parties, mais il faut représenter un connecteur
séparé pour chaque liaison.

Dans notre exemple, à l’intérieur du bloc Voiture, le moteur est relié aux deux
roues avant, mais pas aux roues arrière. Les quatre roues sont (normalement...) reliées à la
route. Sur le diagramme suivant est représenté l’ibd d’un bateau à moteur. Notez que le moteur,
du même type que dans le cas de la voiture, est cette fois-ci connecté à des hélices, parce que
nous sommes dans le contexte d’un bateau.

La multiplicité est ici représentée sur le connecteur, et pas dans la partie, pour montrer l’autre possibilité.

c. Ports et interfaces

c1. Types de ports

Le diagramme de bloc interne permet également décrire la logique de connexion, de
services et de flots entre blocs grâce au concept de « port ». Les ports définissent les
points d’interaction offerts (provided) et requis (required) entre les blocs. Un bloc
peut avoir plusieurs ports qui spécifient des points d’interaction différents. Les ports
peuvent être de deux natures :
• flux (flow port) : ce type de port autorise la circulation de flux physiques entre les
blocs. La nature de ce qui peut circuler va des fluides aux données, en passant par
l'énergie ;
• standard : ce type de port autorise la description de services logiques entre les blocs,
au moyen d’interfaces regroupant des opérations.
La distinction entre ces deux types de ports est souvent d’ordre
méthodologique. Les flow ports sont bien adaptés pour représenter des flux continus d’entités
physiques, alors que les ports standards sont bien adaptés à l’invocation de services,
typiquement entre composants logiciels. Une combinaison des deux est souvent utile, mais
les ports standards ne peuvent être connectés directement aux flow ports et réciproquement.
Dans notre exemple de radio-réveil, les boutons de marche-arrêt du projecteur
et de la radio sont typiquement des ports standards. L’entrée d’énergie électrique comme les ondes
radio, la projection de lumière ou la diffusion de son sont typiquement des flow ports.

169
On peut également associer une multiplicité à un port. Il est ainsi possible d’exprimer de façon
concise qu’un ordinateur possède plusieurs ports USB identiques, ou qu’un radioréveil peut
avoir un ou deux haut-parleurs. La notation complète d’un flow port est donc de la forme :
nom_port : nom_item [multiplicité].
Exemple : haut-parleur : son[0-3] ; alimentation :électricité

Les ports faisant partie de la définition des blocs, il est tout à fait possible de les faire apparaître
dès le bdd. Dans ce cas, ils peuvent être représentés soit graphiquement comme précédemment,
soit sous la forme d’un compartiment supplémentaire.

Item flow (Les éléments de flot)

Les éléments de flot (item flows) permettent de décrire ce qui circule réellement sur les
connecteurs, alors que les flow ports définissent ce qui peut circuler. La distinction n’est pas
toujours utile, mais peut se révéler néanmoins très pratique dans certains cas. Prenons
l’exemple d’un réservoir de liquide. Il a typiquement deux ports atomiques typés Liquide, l’un
en entrée, l’autre en sortie, voire même un seul port d’entrée-sortie (un jerrycan par exemple).

Des instances de Jerrycan utilisées dans des contextes différents acceptent différents types c2.

Interface Une interface est un ensemble d’opérations abstraites (sans algorithmes)

constituant une sorte de contrat qui devra être réalisé par un ou plusieurs blocs.
Graphiquement, une interface est soit représentée comme un bloc avec un mot-clé
« interface » ou le symbole d’un cercle, soit directement comme un cercle dans la notation condensée.
Pour décrire un comportement basé sur l’invocation de services, le port
standard est tout à fait adapté. Mais au lieu d’assigner directement des opérations aux ports, il
est plus intéressant de les regrouper en ensembles cohérents appelés interfaces.
170
 Pour le radio-réveil, nous pouvons par exemple commencer à définir (dans un
bdd) des interfaces pour la gestion du volume de la radio, le réglage et la mémorisation des stations,
la mise à jour des heures et des minutes, etc.

Une interface fournie (provided interface) sur un port spécifie les opérations que le bloc
fournit. Une interface requise (required interface) spécifie les opérations dont le bloc a besoin
pour réaliser son comportement. En général, un autre bloc les lui fournira au moyen d’une
interface fournie.
Un même bloc peut fournir et/ou requérir plusieurs interfaces. Dans l’exemple ci-après, les
deux blocs B1 et B2 fournissent l’interface I2, par contre B2 utilise l’interface I1 qui est fournie
par B1, et l’interface I3. Le bloc B1 fournit les deux interfaces I1 et I2 : il possède donc au
moins la réunion des opérations des deux
interfaces.

??????

III.8 présentation du diagramme paramétrique et des blocs de contraintes (parametric diagram)

Le diagramme paramétrique est utilisé pour exprimer les contraintes physiques entre les blocs
avec des équations et des paramètres qui permettent de simuler le fonctionnement du système.
Il peut ensuite être utilisé pour faire des simulations qui vérifieront si le système répond ou non
aux spécifications.

Les variables (nommées parameters) et les relations mathématiques (appelées constraints) sont
définies dans un BDD.

Objectif : représenter un système d’équations par :

 contraintes : relations mathématiques
 paramètres : variables de ces relations
 caractéristiques des blocs

171
 Ce diagramme est une extension du diagramme de blocs interne et il partage
donc les mêmes éléments graphiques. Il présente la particularité de pouvoir connecter entre
elles des contraintes ajoutées au diagramme de blocs par le biais d'un bloc particulier, dit "de
contraintes" qui contient des paramètres et une relation (mathématique) les reliant.

L’objectif principal du diagramme paramétrique est de supporter des analyses

plus poussées d’ingénierie avec des outils comme Matlab/Simulink, etc. Un autre objectif est
de relier ces analyses aux exigences, en montrant comment une contrainte ou équation peut
servir à vérifier une exigence particulière.

Exemple :

Imaginons que nous avions identifié une exigence non fonctionnelle sur le
radio-réveil concernant la dissipation de chaleur occasionnée. Nous pouvons maintenant relier
la contrainte portant sur l’effet Joule à cette exigence, puisque la formule de l’équation permet
justement de calculer cette dissipation en fonction des paramètres électriques (P = UI ou

P = RI2, puisque U = RI).

Les blocs de contrainte fournissent un mécanisme pour intégrer les fonctions d'ingénierie comme la
performance et la fiabilité.

Les blocs de contrainte peuvent être utilisés pour spécifier un système de contraintes qui
représentent des expressions mathématiques comme {F=m*a} et {a=dv/dt}, qui contraint les
propriétés physiques d'un système. De telles contraintes peuvent aussi être utilisées pour
identifier des paramètres de performance critiques et leurs relations à d'autres paramètres, qui
peuvent être suivis à la trace partout dans le cycle de vie de système.

172
Un bloc de contrainte inclut la contrainte, comme {F=m*a} et les paramètres de la contrainte comme
F, m et a.

Des définitions de contrainte réutilisables peuvent être spécifiées sur des diagrammes de
définition de bloc et mis dans des bibliothèques de modèles universelles ou spécifiques à un
domaine. De telles contraintes peuvent être des expressions mathématiques ou logiques
arbitrairement complexes.

Les contraintes peuvent être imbriquées pour permettre à une contrainte d'être définies en termes de
contraintes de base comme des opérateurs mathématiques primitifs.

Les diagrammes paramétriques incluent les utilisations de blocs de contrainte pour contraindre les
propriétés d'un autre bloc.

L'utilisation d'une contrainte lie les paramètres de la contrainte, comme F, m et a, aux propriétés
spécifiques d'un bloc, comme une masse, qui fournit des valeurs pour les paramètres.

Les propriétés contraintes, comme la masse ou le temps de réponse, ont typiquement les types
de valeur simples qui peuvent aussi porter des unités, des types de quantité, ou des distributions
de probabilité.

Ceci permet à une propriété de valeur (comme un déplacement de moteur) qui peut être
profondément imbriquée dans une hiérarchie de conteneur (comme le véhicule, l'installation
électrique, le moteur), d'être référencée au niveau conteneur extérieur (comme des équations de
niveau de véhicule).

Le contexte, pour les utilisations de blocs de contrainte doit aussi être spécifié dans un
diagramme paramétrique pour maintenir l'espace de nom approprié pour les propriétés
imbriquées.

Le temps peut être modélisé comme une propriété dont d'autres propriétés peuvent dépendre.

Une référence de temps peut être établie par une horloge locale ou globale qui produit une propriété de
valeur de temps continue ou discrète.

D'autres valeurs de temps peuvent être tirées de cette horloge, en présentant des retards et ou biaiser
dans la valeur de temps.

Les valeurs discrètes de temps aussi bien que le temps de calendrier peuvent être tirées de cette
propriété de temps globale(mondiale).
SysML inclut le modèle de temps d'UML.

Un état du système peut être spécifié en termes des valeurs de certaines de ses propriétés.

Par exemple, quand la température d'eau est au-dessous de 0 degrés Celsius, il peut passer du liquide
au solide.

Dans cet exemple, le changement de l'état aboutit à un ensemble différent d'équations de contrainte.

Ceci peut être satisfait en spécifiant les contraintes qui sont conditionnées sur la valeur de la propriété
d'état.
173
Des diagrammes paramétriques peuvent être utilisés pour modéliser les inter dépendances entre les
paramètres.

Un bloc de contrainte peut définir une fonction objective pour comparer des solutions alternatives.

SysML identifie et nomme des blocs de contrainte, mais ne spécifie pas de langage informatique
exécutable pour eux.

On doit fournir l'interprétation d'un bloc de contrainte donné (par exemple, une relation mathématique
entre ses valeurs de paramètre).

Un bloc de contrainte est défini par un mot-clé "constraint" appliquée à une définition de bloc. Les

propriétés de ce bloc définissent les paramètres de la contrainte.

Un diagramme paramétrique est une forme limitée de diagramme de bloc interne qui montre
seulement l'utilisation de blocs de contrainte avec les propriétés qu'ils contraignent dans un
contexte.

8.5.9. Le diagramme de packages (diagramme composite)

Un paquetage est un élément "conteneur" permettant le regroupement de tout
élément graphique (blocs, interfaces, acteurs...) et peuvent être imbriqués les uns dans les autres.

Le diagramme de packages montre l’organisation logique du modèle et les

éventuelles relations entre les packages.

Le diagramme de package permet de d'organiser le modèle comme ci-dessous à

gauche. De plus SysML fournit des vues qui permettent à chaque collaborateur du projet d'avoir
une représentation qui corresponde à ses besoins comme ci-dessous à droite la vue de l'analyse.

174
8.6. Outils SysML

Le langage SysML a été intégré dans de nombreux outils AGL, commerciaux ou open source:

Sparx Systems Enterprise Architect (plugin SysML ou version Ultimate requise)

IBM Rational Software Modeler (plugin d'une société tierce disponible)
Magicdraw (plugin SysML requis)
Open source : Topcased (environnement Eclipse)

175
Chapitre 9 : LES SYSTEMES EXPERT TEMPS REEL (SETR)
9.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é.

Ace 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 qualifie 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 dernontre 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 ce 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 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].

176
9.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 operateur 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).

9.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 approprie 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].
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 systeme
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.
177
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 coté, 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 definit 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;

 Ie 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.

9.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

178
 Système Expert

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)

9.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

179
 3. Concevoir le système

4. Programmer le logiciel

5. Tester le logiciel

6. Déployer

7. Maintenir le système

9.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.

ÉTAPES
La définition des besoins et des exigences correspond à l’étape dans
Définition des laquelle nous discutions avec le client et les futurs utilisateurs afin de
besoins et des comprendre de quoi ils ont besoin : QUI doit pouvoir faire QUOI ?
exigences
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.
DESCRIPTIF

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
Analyse du système
logiciel (COMMENT cela doit-il fonctionner ?).

La conception du système correspond à la définition de choix

techniques.

La programmation est l’étape dans laquelle les informaticiens se

La programmation donnent à cœur joie ! Ils réalisent le logiciel à l’aide de langages de

du
Conception
système

180
 Durant les tests, les informaticiens vérifient que le logiciel fonctionne
Les tests
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 correspond à la période qui suit l’installation et
du pendant laquelle les anomalies et problèmes doivent être corrigés. Ces
La maintenance
système programmation, de systèmes de gestion de bases de données, etc.
é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. Les différents cycles de cycle de vie ont été
développés dans les chapitres précédents .

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

a2) Les tâches de sortie

181
 a3) Les tâches de traitements

Cette partie de tâches constituent le cœur de l’application avec les algorithmes de :

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.

182
A5) Les tâches de communication : ce sont des tâches destinées à échanger de l’information entre le
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…

a6) Les tâches de sauvegarde : elles permettent d’enregistrer régulièrement les états du système pour :

b) La conception du système : Elle permet de faire le choix d’architecture (une architecture mono-
tâche ou une architecture multitâches). L’architecture multitâches est la plus utilisée, elle permet
de bien mettre en œuvre l’ensemble des tâches préalablement définies, en garantissant :

Deux modèles sont utilisés : synchrone et asynchrone. b1.)

Enchaînement des tâches modèle d’exécution synchrone

183
 b2.) Enchaînement des tâches modèle d’exécution asynchrone

c)

L’implémentation de l’application

Comme nous l’avons dit au chapitre 7, 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):

184
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 :

185
• 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
ciaprè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.

186
 • 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 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), les convertisseur
187
analogique/numérique (CAN) intégré, gestion d’une liaison série ou 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.

188
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).

189
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 »

190
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
 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 bon 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..).

191
 Détail de la barre de boutons

11.4.2. Méthodologie de développement

9.5. Exemple d’un Système expert temps réel

11.5.1. Architecture d’un système expert temps réel d'aide a la conduite.

L’architecture suivante concerne un système expert temps réel d'aide à la conduite :

192
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étaille 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.

9.5.2. Le Système d'Acquisition, de Contrôle et de Traitement de données

en temps réel (SACT)

9.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;

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
193
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 2. 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 2), 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.

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 3):

194
Figure 3. Technique des tampons homogènes dans Ie temps

9.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.

Figure 4. Architecture du système expert temps réel d'aide à la conduite

195
9.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).

196
 Références

BONNET Ch., DEMEURE I. : Introduction aux systèmes temps réel, Hermes, 1999

COTTET F., DELACROIX J. et alias : Ordonnancement temps réel, Hermes, 2000

KRAKOWIAK S. : Principes des systèmes d’exploitation des ordinateurs, Dunod, 1987

Projet SCEPTRE : Proposition de standard de noyau d’exécutif temps réel, Rapport BNI n° 26/2, Septembre 1982

Projet SCEPTRE 2 : Rapport sur les services offerts aux applications temps réel à contraintes strictes par
les exécutifs temps réel, Groupe SCEPTRE, Trialog Informatique, Juin 1992

CALVEZ J.P. : Spécification et conception des systèmes, une méthodologie, Masson, 1992

DORSEUIL A. : Le temps réel en milieu industriel, Dunod, 1991

MONTOIS J.-J. : Gestion des processus industriels temps réel, Technosup, 1999

ATTOUI A. : Les systèmes multi-agents et le temps réel, Eyrolles, 1997

AUSLANDER D.M. : Control Software for Mechanical Systems. Object-Oriented Design in a Real-––
Time World, Prentice Hall (en dépôt à la librairie Privat Arts et métiers)

Nicolescu, A. Jerraya, Global specificaiton and validation of embedded systems, Springer, 2007.

Bruce Powel Douglass, Doing hard real-time, Developing real-time systems with UML, objects,
frameworks and patterns, Addison-Wesley, 1999.

Real-Time UML Second Edition: Developing Efficient Objects for

Embedded
Systems, Bruce Powel Douglass, 1998.

Alan C. Shaw, Real-time systems and software, John Willey & Sons, Inc., 2001. J.W.S.Liu,Real-

TimeSystems,PrenticeHall,2000.

197
 TABLE DES MATIERES

DESCRIPTION ....................................................................................................... .......................... 2

OBJECTIFS COURS TEMPS REEL ............................................................................................... 2
CONTENU DU COURS .................................................................................................................... 2
CHAPITRE 1 : INTRODUCTION AUX SYSTEMES TEMPS REEL ET SYSTEMES
EMBARQUES ................................................................................................................... ............................. 4
1.1 LA NOTION DE « SYSTEME TEMPS REEL »................................................................................... 4
1.2 CARACTERISTIQUES D’UN SYSTEME TEMPS REEL ......................................................................... 4
1.2.1 C’est un système informatique en interaction avec son environnement............................. 4
1.2.2 C’est un système qui doit effectuer des traitements simultanés .......................................... 6
1.2.3 C’est un système qui effectue ses activités en respectant des contraintes de temps ............ 6
1.2.4 C’est un système dont le comportement est à la fois prévisible et déterministe .................. 8
1.2.5 C’est un système qui possède une grande sûreté de fonctionnement ................................. 9
1.3. ARCHITECTURE MATERIELLE D’UNE APPLICATION TEMPS REEL........................................... 10
1.3.1. CALCULATEUR .................................................................................................................... 10
1.3.1.1 ASIC ET FPGA ................................................................................................................. 10
1.3.1.2 MICROPROCESSEURS, MICROCONTROLEURS .................................................................... 10
1.3.1.3 MEDIAS DE COMMUNICATION ........................................................................................... 11
1.3.2 TRANSDUCTEURS ................................................................................................................. 11
1.3.2.1 CAPTEUR ........................................................................................................................... 1 1 1.3.2.2
ACTIONNEUR ..................................................................................................................... 11
1.4. NOTION DE « SYSTEME TEMPS REEL EMBARQUE » .................................................................... 13
1.4.1. DEFINITIONS ....................................................................................................................... 13
1.4.2. SPECIFICITE DES SYSTEMES TEMPS REEL EMBARQUES ........................................................ 13
1.4.3. MAITRISE DES COUTS MATERIELS ....................................................................................... 14
1.5. DOMAINES D’APPLICATIONS DES SYSTEMES TEMPS REEL ET EMBARQUES ............................. 16
1.6. DECOMPOSITION DES SYSTEMES EMBARQUES ........................................................................ 16
1.7. ARCHITECTURE DES SYSTEMES EMBARQUES ......................................................................... 17
1.7.1. LES SYSTEMES EMBARQUES DE PREMIERE GENERATION ........................................................ 17
1.7.2. LES SYSTEMES EMBARQUES DE DEUXIEME GENERATION ....................................................... 18
1.7.3. LES SYSTEMES EMBARQUES DE TROISIEME GENERATION : ..................................................... 18
1.7.4. LES SYSTEMES EMBARQUES SPECIFIQUES ............................................................................. 19
1.8. MODES DE FONCTIONNEMENT DES SYSTEMES EMBARQUES .................................................... 19
1.8.1. FONCTIONNEMENT GENERAL : BOUCLE INFINIE .................................................................... 19
1.8.2.. FONCTIONNEMENT CYCLIQUE :.............................................................................................. 20 1.8.3.
FONCTIONNEMENT EVENEMENTIEL : ....................................................................................... 20
1.9. QUELQUES EXEMPLES DE SYSTEMES TEMPS REEL CONTROLE - COMMANDE .......................... 21
1.9.1. EXEMPLE DE SYSTEME TEMPS REEL DE CONTROLE COMMANDE ......................................... 21
1.9.2. EXEMPLE DE SYSTEME TEMPS DE CONTROLE COMMANDE (BOITE DE VITESSE ROBOTISE) .. 22
1.9.5. SYSTEMES TEMPS REEL EMBARQUES ......................................................................... 23
1.10. CONSTRUCTION D’UN SYSTEME INFORMATIQUE TEMPS REEL .......................................... 25 1.10.1.
L’APPROCHE MONOTACHE DE CONSTRUCTION D’UN STR ................................................ 25
1.9.1.1 Interaction par scrutation cyclique des E/S (polling) .................................................. 26
1.10.1.2. Interaction par interruption ...................................................................................... 27
1.10..1.3 Architecture possible d’un système monotâche temps réel ......................................... 28 1.10.1.4
Avantages et limites de l’approche monotâche ........................................................... 30
1.10.2 L’APPROCHE MULTITACHE .................................................................................................. 31
CONCLUSION ................................................................................................................................. 31
2.1 Les tâches .......................................................................................................................... 33
2.1.1 Qu’est-ce qu’une tâche ? ................................................................................................ 33 2.1.2 Les
éléments constitutifs d’une tâche .............................................................................. 33
2.1.3 Contexte d’exécution d’une tâche ................................................................................... 34
2.1.4 Les opérations élémentaires sur une tâche ...................................................................... 34 2.1.5.
LES CARACTERISTIQUES DES TACHES TEMPS REEL .................................................................. 34
2.2 L’ORDONNANCEMENT DES TACHES .......................................................................................... 40
2.2.1 Qu’est-ce qu’un ordonnanceur ? .................................................................................... 40

198
 2.2.2 Préemption du processeur ............................................................................................... 41
2.2.3 L’ordonnanceur câblé .................................................................................................... 41 2.2.4
L’ordonnanceur programmé ........................................................................................... 42
2.2.5 Les états d’une tâche ....................................................................................................... 42
2.2.6. EXECUTIF OU NOYAU TEMPS REEL ...................................................................................... 43
2.2.7. GESTION DES TACHES.......................................................................................................... 44 2.3
L’ACCES CONCURRENT DES TACHES A DES RESSOURCES PARTAGEES.......................................... 45
2.3.1 Notion de ressource ........................................................................................................ 45
2.3.2 Accès aux ressources ...................................................................................................... 46
2.3.3 Problèmes posés par l’accès à des ressources critiques ................................................... 46
2.3.4 Les procédures réentrantes ............................................................................................. 47
2.4 LA SYNCHRONISATION ET LA COMMUNICATION ENTRE LES TACHES ........................................... 47
2.4.1 Relations entre tâches ..................................................................................................... 47
2.4.2 La synchronisation entre tâches...................................................................................... 48
2.4.3 La communication entre tâches ...................................................................................... 48
CHAPITRE 3 : LES TECHNIQUES CLASSIQUES D’ORDONNANCEMENT DES
TACHES ...................................................................................................................... ................................. 49
3.2. NOTIONS DE BASE POUR L’ORDONNANCEMENT TEMPS REEL ..................................................... 50
3.2.1 États d’une tâche ............................................................................................................ 50
3.2.2 Notion de priorité d’une tâche ........................................................................................ 50
3.1.3 Typologie des algorithmes d’ordonnancement ................................................................ 51
3.2 POLITIQUES D’ORDONNANCEMENT CLASSIQUES ........................................................................ 52
3.2.1 Ordonnancement selon la stratégie « Premier arrivé, premier servi » ............................. 52
3.2.2 Ordonnancement circulaire ou selon la méthode du tourniquet...................................... 53
3.2.3 Ordonnancement par priorité avec une seule tâche par niveau de priorité ...................... 53
3.2.4 Ordonnancement par priorité avec plusieurs tâches par niveau de priorité ..................... 54
CHAPITRE 4 : REALISATION DE L’EXCLUSION MUTUELLE .......................................... 57
4.1 PROBLEME D’ACCES A UNE VARIABLE PARTAGEE ...................................................................... 57 4.2
FORMALISATION DU PROBLEME DE L’EXCLUSION MUTUELLE ..................................................... 58 4.3
MECANISMES ELEMENTAIRES D’EXCLUSION MUTUELLE ............................................................ 59
4.3.1 Description des mécanismes élémentaires ........................................................................ 59
4.3.2. Caractéristiques et limites des mécanismes élémentaires................................................ 60
4.3.3 Quand utilise-t-on les mécanismes élémentaires ? .......................................................... 61 4.4
EXCLUSION MUTUELLE PAR INHIBITION DE L’ORDONNANCEUR .................................................. 62 4.5
EXCLUSION MUTUELLE EN UTILISANT UN SEMAPHORE............................................................... 63
4.5.1 Les sémaphores : définition et propriétés ........................................................................ 63
4.5.2 Sémaphore d’exclusion mutuelle .................................................................................... 64 4.5.3
Problèmes rencontrés lors de l’utilisation de sémaphores d’exclusion mutuelle ............. 65
4.6 EXCLUSION MUTUELLE EN UTILISANT UN ALLOCATEUR DE RESSOURCES .................................... 66
CHAPITRE 5 : MECANISMES DE SYNCHRONISATION ET DE COMMUNICATION ..... 69
ENTRE TACHES ............................................................................................................... ............ 69
5.1. MECANISMES DE SYNCHRONISATION ENTRE TACHES ........................................... 69
5.1.1 FORMULATION DU PROBLEME DE LA SYNCHRONISATION ENTRE TACHES ................................. 69
5.1.2 UN MECANISME DE SYNCHRONISATION DIRECTE .................................................................... 70
5.1.3 SYNCHRONISATION PAR SEMAPHORE ..................................................................................... 70 5.1.4
SYNCHRONISATION PAR EVENEMENT ..................................................................................... 71
5.2. MECANISMES DE COMMUNICATION ENTRE TACHES .......................................... 73
5.2.1 COMMUNICATION PAR VARIABLES COMMUNES ...................................................................... 73
5.2.2 COMMUNICATION PAR MESSAGES .......................................................................................... 74
5.2.2.1 Principes de la communication par message ................................................................. 74
5.2.2.2 Le mode de désignation des tâches ................................................................................ 75
5.2.2.3 La nature des messages ................................................................................................ 76
5.2.2.4 Le mode de synchronisation des tâches ........................................................................ 76
5.2.2.5 Le traitement des erreurs ............................................................................................. 78
5.3. MISE EN ŒUVRE DE SCHEMAS DE COMMUNICATION ENTRE TACHES . 79
5.3.1 PROTOCOLES DE COMMUNICATION PAR VARIABLES COMMUNES ............................................. 80
5.3.1.1 Communication par variables communes : exemple 1 .................................................. 80
199
 5.3.1.2 Communication par variables communes : exemple 2 .................................................. 81
5.3.1.3 Communication par variables communes : exemple 3 .................................................. 84
5.3.2 TRANSMISSION DE MESSAGES PAR L’INTERMEDIAIRE D’UNE BOITE AUX LETTRES .................... 84
5.3.2.1 Spécifications de base de cette communication ............................................................ 84
5.3.2.2 Mise en œuvre de la communication ............................................................................ 85
5.3.2.3 Organigramme général des primitives envoyerMessageBAL() et
recevoirMessageBAL() .......................................................................................................................... 86
5.3.2.4 Variantes dans la transmission de messages par l’intermédiaire d’une BAL ................ 87
5.3.3 COMMUNICATION ENTRE PLUSIEURS PRODUCTEURS ET UN CONSOMMATEUR ............ 88
5.3.3.1 Spécifications de base de cette communication ............................................................ 88
5.3.3.2 Mise en œuvre de la communication ............................................................................ 88
5.3.3.3 Diagramme de séquence de la communication ............................................................. 90 5.3.3.4
Variante d’une communication producteur/consommateur ......................................... 91
5.3.4 COMMUNICATION ENTRE PLUSIEURS CLIENTS ET UN SERVEUR ............................................. 91
5.3.4.1 Spécifications de cette communication ......................................................................... 91
5.3.4.2 Mise en œuvre de la communication ............................................................................ 92
5.3.4.3 Variantes dans le schéma précédent de communication clients/serveur ....................... 95
5.3.4.4 Contexte d’utilisation du schéma précédent de communication clients/serveur ............ 95
5.3.4.5 Autre schéma de communication du type clients/serveur ............................................. 96
5.3.4.6 Variante des précédents schémas de communication clients/serveur ............................ 99
CHAPITRE 6 : CYCLES DE VIE DE DEVELOPPEMENTS DES APPLICATIONS TEMPS
REEL ........................................................................................................................ .................................. 102
6.1. Architecture des systèmes de contrôle-commande ............................................................ 102
6.1.a. Architecture logicielle muti-tâches des systèmes de contrôle-commande ....................... 102
6.1.b. Architecture matérielle des systèmes de contrôle-commande ........................................ 104
6.2. Cycles de vie développement d’un logiciel ........................................................................ 104
6.2.1. Le cycle de vie en «Cascade» ........................................................................................ 105
6.2.2. Le cycle de vie en «V» ................................................................................................... 107
6.2.3. Les autres cycles de développement d’un logiciel .......................................................... 108
6.2.3. a. Le modèle en «Prototype Rapide» (Rapid Prototyping Model)................................... 108
6.2.3.b. Le modèle Incrémentiel et Itératif (Incremental and Iterative Model) ........................ 109
6.2.3.c. Le modèle en «Spirale» .............................................................................................. 110
6.2.3.d. Programmation orientée-objet (Object-Oriented Programming) ................................ 112
6.3. Le cycle de vie Logiciel/Matériel ...................................................................................... 112
6.3.1. L’approche de développement «Logiciel/Matériel» traditionnelle ................................. 113
6.3.2. L’approche de développement «Logiciel/Matériel» en Co-design .................................. 114
6.3.3. Le cycle de développement en «W» dans l’approche traditionnelle ............................... 116
6.3.4. «Time-to-market», un point clé à succès ....................................................................... 118
6.4. Gestion du temps ............................................................................................................. 118
6.5. Principales normes temps réel ......................................................................................... 119
6.5. a. La norme POSIX ......................................................................................................... 119
6.5.b. La norme OSEK/VDX ................................................................................................... 121
6.5.c. La norme Ada ......................................................................................................... ....... 123
6.6. Méthodes de développement d’un logiciel ........................................................................ 124
CHAPITRE 7 : LE DEVELOPPEMENT DES SYSTEMES TEMPS REEL ET EMBARQUES127
7.1 INTRODUCTION ..................................................................................................................... 127
7.1.1 DEFINITIONS ...................................................................................................................... 127
7.1.2 PRINCIPALES CARACTERISTIQUES DES SYSTEMES TEMPS REEL .......................................... 130
7.1.3. CARACTERISTIQUES TEMPORELLES DES SYSTEMES TEMPS REEL ...................................... 131
7.1.4 QUELQUES EXEMPLES D’APPLICATIONS ............................................................................. 133
7.2 ARCHITECTURE DES APPLICATIONS TEMPS REEL .................................................................. 134
7.2.1 ARCHITECTURE LOGICIELLE DES APPLICATIONS TEMPS REEL ........................................... 134
7.2.1.1. ARCHITECTURE MULTITACHE ....................................................................................... 134
7.2.1.2. MODELES D’EXECUTION ET ORDONNANCEMENT ............................................................ 136
7.2.1.3. EXECUTIF OU NOYAU TEMPS REEL ................................................................................. 139
7.2.1.4. IMPLEMENTATION DES APPLICATIONS DE CONTROLE-COMMANDE ............................... 141
10.2.2 ARCHITECTURE MATERIELLE DES APPLICATIONS DE CONTROLE COMMANDE ................. 142
CHAPITRE8:MODELISATIONDESSYSTEMES
C O M P L E X E S A V E C S Y S M L ......................................................................................... .... 143

200
 8.1. INTRODUCTION .................................................................................................................... 143
8.2. SYSTEME ET INGENIERIE SYSTEME ...................................................................................... 143
8.3. SYSML : HISTORIQUE ......................................................................................................... 144
8.4. DIFFERENCES UML 2 /SYSML ................................................................................. 146
8.5. LES 9 DIAGRAMMES DE SYSML ............................................................................. 147
8.5.1. DIAGRAMME DE CAS D‘UTILISATION ........................................................................ 147
8.5.1.1. INTRODUCTION ............................................................................................................. 147
8.5.1.2. REPRESENTATION DU DIAGRAMME DES CAS D'UTILISATION ......................... 147
8.5.1.3. IDENTIFICATION ET REPRESENTATION DES CAS D'UTILISATION .................. 148
8.5.1.4. RELATIONS ENTRE CAS D'UTILISATION ................................................................ 149
8.5.2. DIAGRAMME D’ACTIVITES ........................................................................................... 152
8.5.2.1. INTRODUCTION ....................................................................................................... ...... 152
8.5.2.2. ACTION ............................................................................................................................ 153
8.5.2.3. ACTIVITE & GROUPE D’ACTIVITES ......................................................................... 154
8.5.2.4. ETAT-ACTION ................................................................................................................ 154
8.5.2.5. ETAT-ACTIVITE ............................................................................................................. 154
8.5.2.6. DEFINITION & EXEMPLE ............................................................................................ 154
8.5.2.7. TRANSITION CONDITIONNELLE ............................................................................... 154
8.5.2.8. TRANSITION COMPOSITE ........................................................................................... 155
8.5.2.9. NOEUDS DE CONTROLE .............................................................................................. 156
8.5.2.10. TYPES DE NŒUDS CONTROLE ................................................................................. 156
8.5.2.11. SYNCHRONISATION : DISJONCTION & CONJONCTION D'ACTIVITES ........... 157
8.5.3. DIAGRAMME D'ETAT-TRANSITION (DET) ................................................................. 158
8.5.3.1. ETAT ................................................................................................................................. 159
8.5.3.2. TRANSITION ......................................................................................................... .......... 159
8.5.3.3. ACTION ............................................................................................................. ............... 161
8.5.3.4. ÉTATS COMPOSITES .................................................................................................... 163
8.5.3.5. UTILISATION ........................................................................................................ .......... 163
8.5.4. DIAGRAMME DE SEQUENCES (DSE) ............................................................................ 163
8.5.4.1. SCENARIO ........................................................................................................... ............ 163
8.5.4.2. SCENARIO - DESCRIPTION TEXTUELLE EN LANGAGE NATUREL .................... 164
8.5.4.3. LES OBJETS/ACTEURS ................................................................................................. 165
8.5.4.4. LES MESSAGES ................................................................................................. ............. 165
8.5.4.5. LA LIGNE DE VIE DE L'OBJET/ACTEUR .................................................................. 166
8.5.4.6. LE POINT DE CONTROLE (BARRE D’ACTIVATION) .............................................. 166
8.5.4.7. EXECUTION SIMULTANEE .......................................................................................... 168
8.5.5. LE DIAGRAMME DES EXIGENCES ............................................................................... 169
L’OBJECTIF DE CE DIAGRAMME: ......................................................................................... 169
8.5.5.1. METHODOLOGIE ................................................................................................... 170
8.5.5.2. TRADUCTION LITTERALE DU DIAGRAMME DES EXIGENCES................... 170
A. L'EXIGENCE .................................................................................................................. .. 170
B. LES LIENS ENTRE LES BLOCS D'EXIGENCE ........................................................... 170

201
 C. LES STEREOTYPES ........................................................................................................ 171
D. LIEN ENTRE LES EXIGENCES ..................................................................................... 171
8.5.6. DIAGRAMME DE DEFINITION DE BLOCS (DIAGRAMME DE CLASSE EN UML) 175
8.5.7. LE DIAGRAMME DE BLOC INTERNE (DIAGRAMME COMPOSITE EN UML) ..... 176
A. PARTIES (PARTS EN ANGLAIS) ................................................................................... 177
B. CONNECTEUR ................................................................................................................. 178
C. PORTS ET INTERFACES ................................................................................................ 179
C1. TYPES DE PORTS .......................................................................................................... ....... 179
ITEM FLOW (LES ELEMENTS DE FLOT)............................................................................... 180
C2. INTERFACE .......................................................................................................................... 180
III.8 PRESENTATION DU DIAGRAMME PARAMETRIQUE ET DES BLOCS DE
CONTRAINTES (PARAMETRIC DIAGRAM)....................................................................................... 181
8.5.9. LE DIAGRAMME DE PACKAGES (DIAGRAMME COMPOSITE) .............................. 184
8.6. OUTILS SYSML ........................................................................................................... 185
CHAPITRE 9 : LES SYSTEMES EXPERT TEMPS REEL (SETR) .......................................... 186
9.1. DEFINITION ......................................................................................................................... 186
9.2. CARACTERISTIQUES DES SETR ........................................................................................... 187
9.3. LES APPLICATIONS DES SETR ............................................................................................. 187
9.4. METHODOLOGIE DE CONCEPTION ET DE DEVELOPPEMENT DES SETR ................................ 188
9.4.1. LES ETAPES DE DEVELOPPEMENT LOGICIEL ...................................................................... 189
9.4.2. LES ETAPES D'UN PROJET .................................................................................................. 190
9.5. EXEMPLE D’UN SYSTEME EXPERT TEMPS REEL .................................................................... 203
9.5.2. LE SYSTEME D'ACQUISITION, DE CONTROLE ET DE TRAITEMENT DE DONNEES EN
TEMPS REEL (SACT) ................................................................................................................................ 204
9.5.2.1. LES OBJECTIFS DU SACT ............................................................................................... 204
9.5.2.2. PRINCIPALES CARACTERISTIQUES DU SACT .................................................................. 205
REFERENCES .............................................................................................................................. 208
TABLE DES MATIERES .......................................................................................................... ... 209

202