CHAPITRE 11 

: MODULARISER UNE APPLICATION POUR LA CONCURRENCE.

1. Introduction.
De nombreuses activités ont besoin d’être terminées lors de la conception d’un système temps
réel. Un groupe d’activité nécessite d’identifier certains éléments. Certains des éléments
importants à identifier sont :

 Les besoins du système.

 Les entrées et les sorties.
 Les deadlines temps réel.
 Les événements et les temps de réponse à ces événements.
 Les types d’arrivées des évènements et leur fréquence.
 Les objets nécessaires et les autres composants.
 Les taches qui ont besoin d’être en concurrence.
 L’ordonnancement du système.
 Les protocoles de synchronisation nécessaire pour les communications inter taches.
En fonction de la méthodologie de conception et des outils de modélisation employés par
l’équipe de conception, la liste précédente peut varier, ainsi que son ordre d’exécution.
Indépendamment de la méthodologie retenue, éventuellement une équipe peut être
spécifiquement dédiée à la décomposition de l’application en taches concurrentes.

Ce chapitre présente les lignes directrices de la décomposition d’une application temps réel
embarqué. De nombreuses équipes utilisent des techniques de développement avec un
formalisme orienté objet, comme l’UML, pour modéliser les systèmes temps réel. Dans ce
chapitre, on n’utilisera pas le formalisme UML, mais nous insistons sur une approche
complémentaire qui est la décomposition des applications en taches pour réaliser la
concurrence. Si deux lignes directrices sont contradictoires, un compromis devra être réalisé
en fonction de l’application.
A la fin du processus de décomposition, la robustesse du système doit valider l’ordenncabilité
des taches nouvellement créées. Une analyse quantitative de l’ordonnecabilité sur le système
temps réel détermine si le système est ordonnecable. Un système temps réel est considéré
ordonnançable si chaque tache du système peut respecter sa deadline.

2. Une approche « de l’extérieur vers l’intérieur » pour décomposer l’application.

Dans la majorité des cas, les concepteurs insistent sur un ensemble de contraintes avant de
commencer à travailler sur le système temps réel. Si ces contraintes ne sont pas totalement
définies, une des premières activités est de s’assurer que ne nombreuses contraintes sont
figées. Les zones d’ambiguïté ont besoin d’être complétées. Les contraintes détaillées doivent
apparaitre dans un document, tel que la spécification des contraintes software. Uniquement à
partir de ce moment, l’équipe de concepteurs peut raisonnablement débuter la conception du
système. Un exemple de haut niveau de conception d’un téléphone mobile sera utilisé pour
montrer la manière de décomposer une application en unités concurrentes d’exécution.
L’approche retenue « de l’extérieur vers l’intérieur » suit un processus d’identification des
E/S du système et les exprime dans un diagramme simple de haut niveau. Un diagramme de

1
contexte pour le téléphone mobile est présenté ci-dessous. Le cercle u centre du diagramme
représente le software de l’application. Les boites rectangulaires représentent les dispositifs
d’E/S pour cette application. De plus, les flèches, avec des labels, représentent la circulation
des communications d’E/S. Par souci de simplicité, tous les composants ne sont pas
représentés (par exemple, la batterie, les écouteurs main libre, l’entrée du chargeur, le bouton
ON/OFF, …).

Le diagramme précédent montre que le mobile fournit des interfaces pour les E/S suivantes :

 Antenne.
 Haut-parleur.
 Contrôle du volume.
 Clavier.
 Microphone.
 Ecran LCD.
Les entrées identifiées sont :

 L’entrée RF.
 L’entrée volume.
 L’entrée clavier.
 L’entrée microphone.
Les sorties identifiées sont :

 La sortie RF.
 La sortie Haut-parleur.
 La sortie écran LCD.
Après l’identification des E/S, une première décomposition de l’application peut être réalisée.
La figure suivante montre un cercle étendu identifiant certaines taches potentielles. Ces taches
sont en périphérie du cercle, ce qui indique qu’elles doivent interagir avec le monde extérieur.
Notez que ces taches ne sont pas les seules requises, mais la description donne un bon point de

2
 départ. Plus loin dans l’analyse, d’autres taches pourront être identifiées ou bien des taches
existantes pourront être combinées lorsque plus de détails seront pris en compte.

Certaines E/S peuvent nécessiter plus d’une tache pour le traitement. Réciproquement, dans
certains cas, une unique tache peut gérer plusieurs dispositifs. Prenons le cas de l’antenne qui
a deux taches. Une tâche pour gérer le canal audio entrant et une autre pour le canal audio
sortant. L’afficheur LCD est relativement simple à gérer, une tache suffit. De manière
identique, échantillonner la voie d’entrée depuis le microphone peut être réalisé avec une taille
unique, mais peut nécessiter une seconde tâche si le traitement est important dû à une
augmentation de la fréquence d’échantillonnage de la voix. Notez qu’une tache peut gérer à la
fois le clavier et le contrôle du volume. Finalement, une tache est dédiée à l’envoi d’un signal
audio vers le haut- parleur.
Cet exemple illustre la raison pour laquelle elle est appelée méthode « de l’extérieur vers
l’intérieur » : une équipe de concepteur peut continuer, de cette manière, à décomposer
l’application entière en taches.

3. Conseils et recommandations pour identifier la concurrence.

L’approche précédente pour décomposer une application est un exemple pratique pour
identifier les types de taches concurrentes qui interagissent avec les E/S. L’exemple du
téléphone portable montre un diagramme de contexte de haut niveau pour déterminer les
taches évidentes nécessaires pour gérer certains évènements ou actions. Une analyse plus
détaillée ferai apparaitre d’autres taches.
3.1. Unités de concurrence.
Il est important d’encapsuler la concurrence dans une application en unités gérables. Une
unité de concurrence (unit of concurrency) peut être une tache ou un process. Elle peut être
n’importe quel thread d’exécution qui peut entrer en compétition pour avoir du temps
processeur. Bien que l’ISR n’est pas ordonnancée pour fonctionner en concurrence avec
d’autres routines, elles doivent aussi être prise en compte dans la conception de la concurrence
car elles suivent une politique préemptive et sont des unités d’exécution qui entre en
compétition pour obtenir du temps CPU. L’objectif primaire de ce processus de décomposition

3
 est d’optimiser l’exécution parallèle pour maximiser les performances de l’application temps
réel et la réactivité. Si cela est réalisé correctement, le système peut respecter toutes ses
deadlines et être réactif. Dans le cas contraire, le système devient souvent inacceptable.

3.2. Pseudo et vrai exécution concurrente.

Les taches concurrentes dans une application temps réel peuvent être ordonnancées pour
fonctionner sur un ou plusieurs processeurs. Les système mono processeurs peuvent réaliser
une exécution pseudo concurrente, dans laquelle une application est décomposée en de
multiples tâches maximisant l’utilisation d’une unique CPU. Il est important de noter que dans
un système à une seule CPU, seulement un compteur programme (program counter ou
instruction pointer) est utilisé, et par conséquent une seule instruction peut être exécutée à un
instant. La plupart des applications dans ces environnements utilisent la possibilité de
l’ordonnanceur pour entrelacer l’exécution de taches multiples. On parle alors de pseudo
exécution concurrentes (pseudo concurrent execution).
En revanche, la vrai exécution concurrente (true concurrent execution) peut être obtenue
lorsque de multiples CPU sont utilisées dans la conception du système temps réel embarqué.
Par exemple, lorsque deux CPU sont utilisées dans un système, deux taches concurrentes
peuvent s’exécuter en parallèle à un instant donné, comme indiqué ci-dessous. Ce parallélisme
est possible car deux compteurs programme, un pour chaque CPU, sont utilisés, ce qui permet
à deux instructions différentes d’être exécutées au même instant.

Dans le cas des systèmes à multiples CPU, Le RTOS est distribué (distributed) , ce qui
signifie que des composants variés, ou des copies de composants RTOS, peuvent s’executer
sur différentes CPU. Dans de tells systèmes, de multiples taches peuvent être contraintes de
fonctionner sur chaque CPU, juste comme elles le font sur une seule CPU. Dans ce cas, même
si deux CPU ou plus permettent une vraie exécution concurrente, chaque CPU peu en fait
travailler de manière pseudo concurrente. A moins que ce soit explicitement mentionné, ce
cours ne distingue pas les termes pseudo exécution et vraie exécution parallèle, on utilise
uniquement le terme d’exécution concurrente par souci de simplicité.
En suivant l’approche « de l’extérieur vers l’intérieur », certains types de taches peuvent
être identifiées près de la frontière de l’application (c’est-à-dire une application a besoin de
créer une interface avec un dispositif d’E/S), alors que d’autres peuvent être interne à
l’application. Dans l’exemple du téléphone mobile, si l’équipe de designers décompose plus
l’application, ces taches internes seront identifiées. Des applications, telles que les
programmes de calculs ou de calendrier, sont des exemples de taches internes ou des
groupements de taches qui peuvent exister dans le téléphone mobile. Ces taches internes sont

4
 découplées des E/S. elles n’ont pas besoin d’information spécifique au dispositif pour
fonctionner.
3.3. Certains conseils.
Conseil 1 : Identifier les dépendances du dispositif.

 Conseil 1a : Identifier les dispositifs d’E/S actifs.

 Conseil 1b : Identifier les dispositifs d’E/S passifs.
Conseil 2 : Identifier les dépendances d’évènements.
Conseil 3 : Identifier les dépendances temporelles.

 Conseil 3a : Identifier les activités urgentes et critiques.

 Conseil 3b : Identifier les différentes fréquences des exécutions périodiques.
 Conseil 3c : Identifier la cohésion temporelle.
Conseil 4 : Identifier les limites de traitement.
Conseil 5 : Identifier la cohésion fonctionnelle.
Conseil 6 : Identifier les taches qui servent à des buts spécifiques.
Conseil 7 : Identifier la cohésion séquentielle.

Conseil 1 : Identifier les dépendances du dispositif.

Toutes système temps réels s’interface avec le monde physique au travers de dispositifs,
comme des capteurs, des actionneurs, des claviers ou des afficheurs. Une application peut
avoir un nombre de dispositif d’E/S s’interfaçant avec elle. En revanche, pas la totalité des
dispositifs fonctionnent à la fois avec des dispositifs d’entré et des dispositifs de sortie.
Certains dispositifs peuvent agir juste comme des entrées ou des sorties. D’autre font les deux
à la fois.
L’approche « de l’extérieur vers l’intérieur » se concentre sur la recherche des dispositifs
d’E/S dans un système et sur l’affectation d’une tache à un dispositif. Le concept de base est
que les dispositifs non synchronisés ont besoin d’un traitement séparé. Pour des interactions
simples entre dispositifs, le traitement par ISR peut être suffisant. En revanche, pour un
traitement plus conséquent des dispositifs, une tache séparée ou un ensemble de taches
peuvent être utilisés. A la fois les dispositifs actifs et passifs d’E/S doivent être considérés
pour identifier les zones potentielles d’une application qui sont susceptibles d’être
décomposées en taches concurrentes.
La figure suivante montre que les dispositifs hardware d’entrées / sorties peuvent être
catégorisés en deux types :

 Les dispositifs d’E/S actifs.

 Les dispositifs d’E/S passifs.

5
Les dispositifs d’E/S actifs génèrent des interruptions pour communiquer avec l’application.
Ces dispositifs peuvent générer des interruptions de manière périodique ou synchrone avec
d’autres dispositifs actifs. On emploiera dans ce cours le terme de dispositifs synchrones. Les
dispositifs actifs peuvent aussi générer des interruptions de manière apériodique, ou
asynchrone, par rapport aux autres dispositifs. On emploiera dans ce cours le terme de
dispositifs asynchrones.
Les dispositifs d’E/S passifs ne génèrent des interruptions. Donc, l’application doit initier la
communication avec le dispositif passif d’E/S. L’application peut communiquer avec le
dispositif passif de manière périodique ou apériodique.
Les dispositifs actifs génèrent des interruptions si ils envoient des entrées vers la CPU ou
reçoivent des sorties depuis la CPU. Les dispositifs d’entrée actifs émettent des interruptions
vers la CPU lorsque le dispositif a une nouvelle entrée prête à être traitée. La nouvelle entrée
peut être un grand buffer de données, une petite unité de donnée, ou même aucune donnée (par
exemple, un capteur qui génère une interruption chaque fois qu’il détecte un évènement). D’un
autre côté, un dispositif de sortie actif émet une interruption vers la CPU lorsque le dispositif a
terminé de délivré la précédente sortie depuis la CPU vers le monde physique. Cette
interruption annonce à la CPU et à l’application que le dispositif de sortie a terminé la requête
précédente et est prêt à gérer la prochaine requête.

Les dispositifs à entrées ou sorties passifs requièrent que l’application génère les requêtes
nécessaires pour interagir avec eux. Les dispositifs d’entrée passifs produisent une entrée
uniquement sur une requête de l’application. L’application peut rendre ces requêtes
périodiques ou apériodiques. Dans le cas de requêtes périodiques, l’application fonctionne
dans une boucle périodique et fait une requête à chaque parcours de boucle, on parle de
scrutation du dispositif (polling device). Pour des requêtes apériodiques, l’application fait
une requête uniquement lorsqu’elle a besoin de donnée, basée sur un évènement asynchrone
de l’application elle-même, telle qu’une interruption d’un autre dispositif ou d’un message
émanant d’une autre tâche en exécution.

Une attention particulière doit être envisagée lors du polling d’un dispositif d’entrée passif,
tout particulièrement lors de l’échantillonnage d’un signal qui possède des pics ou creux
pointus. Si la fréquence de polling est trop faible, il est possible de manquer ces pics et creux
pointus. Si la fréquence de polling est trop élevée, on risque de trop utiliser la CPU.

6
 Conseil 1a : Identifier les dispositifs d’E/S actifs.
Les dispositifs d’E/S actifs utilisent des interruptions pour dialoguer avec les applications
temps réels. Chaque fois qu’un dispositif d’entrée actif a besoin d’émettre des données ou
de notifier un évènement à une application temps réel, le dispositif génère une
interruption. L’interruption déclenche une ISR qui exécute le code minimal pour gérer
l’entrée. Si un traitement conséquent est nécessaire, l’ISR délègue le traitement à une
tache associée grâce à un mécanisme de communication inter taches.
De manière identique, les dispositifs à sortie actif génèrent également des interruptions
lorsqu’elles ont besoin de communiquer avec les applications. Les interruptions issues de
dispositifs à sortie actif sont générées lorsqu’elles sont prêtes à recevoir la prochaine
donnée ou notification d’évènements issus de l’application. Les interruptions déclenchent
l’ISR approprié qui délègue le traitement à une tache associée grâce à un mécanisme de
communication inter taches.
Le diagramme pour un dispositif d’E/S actif agissant comme une entrée ou une sortie de
l’application et pour un dispositif générant des interruptions de manière synchrone ou
asynchrone est présenté à la figure suivante.

Certaines taches typiques qui peuvent résulter de l’identification d’un dispositif d’E/S
actif dans une application temps réel sont listées dans le tableau suivant.

Type de tache Description

Tache de dispositif d’E/S actif
asynchrone.
Tache de dispositif d’E/S actif
synchrone.
Tache de dispositif d’E/S de
contrôle de ressource.
Tache de dispositif d’E/S de
dispatcher d’événements.
Affectée à un dispositif d’E/S actif qui génère des
interruptions apériodiques ou dont les opérations sont
asynchrones avec les autres dispositifs d’E/S.
Affectée à un dispositif d’E/S actif qui génère des
interruptions périodiques ou dont les opérations sont
synchrones avec les autres dispositifs d’E/S.
Affectée pour le contrôle des accès aux dispositifs
d’E/S partagés ou a un groupe de dispositifs.
Affectée pour dispatcher les évènements aux autres
taches provenant d’un ou plusieurs dispositifs d’E/S.

Recommandation 1 : Affecter des taches séparées pour des dispositifs d’E/S
asynchrones actifs. Les dispositifs d’E/S actifs qui interagissent avec les applications
temps réel le font à leur propre rythme. Chaque dispositif hardware qui utilise des
interruptions pour communiquer avec une application et dont l’opération est asynchrone
avec les autres dispositifs d’E/S doit être considéré comme ayant leurs propres taches
séparées.

7
Recommandation 2 : Combiner les taches pour les dispositifs d’E/S qui génèrent des
interruptions peut fréquentes avec de longues deadlines. Dans la conception initiale,
chaque dispositif d’E/S actif peut avoir une tache séparée affectée au traitement. Parfois,
cependant, la combinaison du traitement de deux dispositifs d’E/S en une tache unique
peut faire sens. Par exemple, si deux dispositifs d’E/S génèrent des interruptions
apériodiques ou asynchrones peu fréquemment et ont des longues deadlines, une seule
tache peut suffire.
Recommandation 3 : Affecter des taches séparées pour des dispositifs qui ont
fréquences d’entrées et fréquences de sorties différentes. Généralement, une tache qui
prend en charge un dispositif avec une fréquence d’E/S élevée doit avoir qu’une tache qui
gère un dispositif avec une fréquence faible. Les fréquences élevées d’E/S implique des
temps de traitement plus court. Cependant, l’importance des opérations d’E/S, et les
conséquences des E/S retardées, doivent être prise en compte lorsque l’on assigne les
priorités des taches en respectant la fréquence des E/S.
Recommandation 4 : Affecter des priorités plus élevées aux des taches associées avec
des dispositifs générant des interruptions. Une tâche qui a besoin d’être interfacée avec
un dispositif particulier d’E/S doit avoir un niveau de priorité suffisamment élevé de telle
sorte que la tache puisse conserver sa relation avec le dispositif. Cette contrainte existe car
la vitesse d’exécution de la tâche est habituellement contrainte par la vitesse des
interruptions que le dispositif d’E/S associé génère et pas nécessairement le processeur sur
lequel l’application fonctionne.
Pour des dispositifs d’E/S qui génèrent des interruptions périodiques, la période des
interruptions dicte la durée de traitement de la tâche. Si la période est très courte, les
taches associées à ces dispositifs ont besoin d’avoir une priorité élevée.
Pour des dispositifs d’E/S qui génèrent des interruptions apériodiques, il peut être difficile
de prédire la durée de traitement de la tache associée qui traite la requête avant
l’apparition de la prochaine interruption. Dans certains cas, les interruptions peuvent
apparaitre très rapidement. Dans d’autres cas, cependant, les interruptions peuvent
apparaitre avec des intervalles de temps (entre interruptions) beaucoup plus long. La règle
est que ces types de taches ont besoin d’avoir une priorité élevée pour assurer que les
requêtes d’interruptions peuvent être traitées, en incluant celles qui apparaissent durant
des intervalles de temps très court. Si la priorité d’une tache associée est trop basse, la
tache peut ne pas être en mesure de s’exécuter assez rapidement pour satisfaire les besoins
du dispositif hardware.

Recommandation 5 : Affecter des ressources aux tâches de contrôle pour contrôler
les accès aux dispositifs d’E/S. Parfois, de multiples taches ont besoin d’accéder à un
seul dispositif d’E/S. Dans ce cas, le dispositif peut seulement servir une tache à un instant
donné ; sinon, les données peuvent être perdues ou corrompues. Une approche efficace
consiste à assigner une tache de contrôle de ressource (task control ressource ou
resource monitor task) à ce dispositif. Cette tache peut être utilisée pour recevoir de
multiples requêtes d’E/S originaires de différentes taches, de telle sorte que la tâche de
contrôle de ressource peut envoyer les requêtes d’E/S de manière contrôlée et
séquentielle aux dispositifs d’E/S.
Cette tache de contrôle de ressource n’est pas limitée au travail avec un unique dispositif
d’E/S. Dans certains cas, tache de contrôle de ressource peut gérer de multiples requêtes
qui peuvent avoir besoin d’être dispatchées vers un ou plusieurs dispositifs d’E/S.

8
Recommandation 6 : Affecter une taches qui dispache les évènements pour des
requêtes issues de dispositifs d’E/S qui ont besoin d’être manipuler par plusieurs
taches. Les évènements ou requêtes issues d’un dispositif d’E/S peuvent être propagées à
travers de multiples taches. Une unique tache dédiée à une tache de dispatching des
évènements peut recevoir toutes les requêtes des dispositifs d’E/S et peut les dispatcher
vers les taches appropriées.

 Conseil 1b : Identifier les dispositifs d’E/S passifs.

Les dispositifs passifs sont différents des dispositifs actifs car les dispositifs passifs ne
génèrent pas d’interruptions. Ils restent passifs jusqu’à ce qu’une d’une tache
d’application émettent une requête leur demandant de faire quelque chose d’utile. Que la
requête soit destinée à une entrée ou une sortie, la tâche d’application à besoin d’initialiser
l’évènement ou la séquence de transfert de données. La manière dont la tache
communique avec le dispositif est soit la scrutation (polling) périodique ou en faisant une
requête à chaque fois que la tâche à besoin de réaliser une entrée ou une sortie.
Le diagramme pour un dispositif d’E/S passif agissant en entrée ou sortie d’une
application ou pour communiquer avec l’application de manière périodique ou
apériodique est présenté à la figure suivante.

Certaines taches typiques qui peuvent résulter de l’identification d’un dispositif passif
d’E/S dans une application temps réel sont présentées dans le tableau ci-dessous.

Type de tache Description

Tache de dispositif d’E/S passif
apériodique.
Tache de dispositif d’E/S passif
périodique.
Tache de dispositif d’E/S de
contrôle de ressource.
Tache de dispositif d’E/S de
dispatcher d’événements.
Affectée à un dispositif d’E/S passifs et des requêtes
ponctuelles de ces dispositifs
Affectée à un dispositif d’E/S passif et à la scrutation
périodique de ces dispositifs.
Affectée pour le contrôle des accès aux dispositifs
d’E/S partagés ou à un groupe de dispositifs.
Affectée pour dispatcher les évènements aux autres
taches provenant d’un ou plusieurs dispositifs d’E/S.

Recommandation 1: Affecter une tache unique pour l’interfaçage avec les dispositifs
d’E/S passifs lorsque la communication avec de tels dispositifs est apériodique ou
quand les deadlines ne sont pas urgentes. Certaines applications ont besoin de
communiquer avec des dispositifs d’E/S passif de manière apériodique. Ces dispositifs
peuvent être des capteurs ou des afficheurs. Si les deadlines sont relativement longues, ces
requêtes pour un ou plusieurs composants passifs d’E/S peuvent être prises en charge par
une tache unique.

9
 Recommandation 2 : Affecter des taches de scrutation séparées pour envoyer des
requêtes périodiques aux dispositifs d’E/S passifs. Fréquemment, une application temps
réel peut avoir besoin d’échantillonner un signal ou certaines données issues de dispositifs
d’E/S passifs. Ce traitement peut être réalisé dans une boucle de scrutation périodique.
Dans le but d’éviter un sur échantillonnage ou sous échantillonnage des données, on
affecte une tache séparée à chaque dispositif d’E/S passif qui a besoin d’être scruté à une
fréquence différente.
Recommandation 3 : Déclenchement des requêtes de scrutation via les évènements
timers. Plusieurs méthodes existent pour réaliser des boucles de scrutation temporelles.
Une erreur fréquente est d’utiliser un retard dans la boucle qui est égal à la période
d’échantillonnage. Cette méthode peut poser des problèmes car la boucle ne met pas le
même temps pour s’exécuter à chaque passage, la boucle est sujette aux interruptions et
préemption de tache de priorité plus élevée. Une méthode plus efficace est utiliser un
timer pour déclencher un évènement après chaque cycle. Une période plus précise peut
être obtenue grâce à cette approche.
Recommandation 4 : affecter une priorité relative élevée aux taches de scrutation
ayant des périodes relativement courtes. Les taches configurées pour scruter les entrées
des dispositifs d’E/S le font à des rythmes différents. Si la période est très courte, il y a
moins de temps disponible pour le traitement avant le prochain cycle. Dans ce cas, ces
taches avec des boucles de scrutation rapides ont besoin d’avoir des priorités plus élevées.
Les concepteurs, cependant, ont besoin de noter que ce traitement doit être réalisé avec
précaution, car une scrutation intense utilise des cycles CPU supplémentaires et augmente
la charge.

Conseil 2 : Identifier les dépendances d’évènements.

Les événements des applications temps réel peuvent se propager au travers de multiples
taches. Que l’évènement soit généré de manière externe ( en provenance du dispositif
d’E/S) ou interne (depuis une application), on a besoin de créer une tache ou un groupe de
taches qui peuvent gérer proprement l’évènement lors de sa propagation au travers de
l’application. Les évènements générés de manière externe ont été présenté dans les
paragraphes précédents, donc nous présentons ici le cas des évènements internes. Des
exemples d’évènements qui peuvent être générés de manière interne à l’application sont
des arrivées de conditions d’erreur ou des fautes détectées. Dans ce cas, un évènement est
généré et propagé vers l’extérieur en direction du dispositif d’E/S ou bien une action
corrective interne est exécutée.

Conseil 3 : Identifier les dépendances temporelles.

Avant la conception d’une application temps réel, on doit prendre du temps pour
comprendre et classer chacune des deadlines nécessaires à l’application. Une fois les
deadlines identifiées, des taches séparées peuvent être affectées à des deadlines séparées.
Les priorités des taches peuvent être affectées sur la base de la criticité ou de l’urgence de
chaque deadline.

10
  Conseil 3a : Identifier les activités urgentes et critiques. Notez la différence entre
criticité et urgence. Les taches critiques sont des taches dont l’échec est désastreux. La
deadline peut être longue ou courte mais doit impérativement respectée, sinon le
système ne respecte pas les spécifications. Une tâche urgente est une tâche avec une
deadline relativement courte. Le respect de cette deadline peut être critique ou non
critique. Les taches qui sont à la fois urgentes et critiques ont habituellement les
priorités relatives les plus élevées.

 Conseil 3b : Identifier les différentes fréquences des exécutions périodiques.

Chaque activité périodique fonctionne à un rythme différent des autres activités
périodique. Les activités périodiques peuvent être identifiées puis groupées dans des
taches avec des rythmes identiques.

 Conseil 3c : Identifier la cohésion temporelle.

Les systèmes temps réels peuvent contenir des séquences de code qui s’exécutent
toujours au même moment, même si elles ne sont pas fonctionnellement reliées. De
telles séquences présentent une cohésion temporelle (temporal cohesion). Par
exemple, des activités différentes pilotées par le même stimulus externe (ex : timer).
Le regroupement de telles séquences dans une seule tache réduit la surcharge du
système.

Conseil 4 : Identifier les limites de traitement.

Certaines activités dans les applications temps réel nécessitent beaucoup de temps
CPU comparé à d’autres opérations, comme réaliser une E/S. Ces activités, connues
sous le terme computationally Bound activities, peuvent être des activités de calcul et
ont typiquement de longues deadlines. Ces types d’activités ont habituellement des
priorités inférieures afin de ne pas monopoliser la CPU. Dans certains cas, ces types
de taches peuvent être découpées en tranche temporelle avec un niveau de priorité
commun, où chacune possède du temps pour l’exécution tant qu’une tache plus
critique n’a pas besoin de tourner.

Conseil 5 : Identifier la cohésion fonctionnelle.

La cohésion fonctionnelle (functional cohesion) nécessite de collecter des groupes de
fonctions ou séquences de code qui réalise des activités assez proches dans une unique
tache. De plus, si deux taches sont fortement couplées (transfèrent beaucoup de
données entre elles), elles doivent être combinées dans une unique tache. Le
regroupement de ces activités proches ou couplées dans une tache unique peut aider à
alléger la surcharge due à la synchronisation et à la communication.

Conseil 6 : Identifier les taches qui servent à des buts spécifiques.
Les taches peuvent aussi être regroupées en fonction des buts spécifiques qu’elles
servent. Un exemple de tache servant un but précis est une tache de sécurité. La

11
 détection des problèmes possibles, la mise en place des alarmes, et l’envoie de
notifications à l’utilisateur, ainsi que la mise en place et l’exécution des mesures
correctives, sont juste des exemples qui peuvent être coordonnés dans une tache de
sécurité ou un groupe de taches. D’autres taches peuvent aussi exister dans un système
temps réel qui peuvent servir un but spécifiques.

Conseil 7 : Identifier la cohésion séquentielle.

La cohésion séquentielle (sequential cohesion) regroupe en une seule tache les
activités qui doivent apparaitre dans une séquence donnée. Un exemple typique est
une séquence de calculs qui doit être effectuée dans un ordre prédéfini. Par exemple,
le résultat du premier calcul fournit l’entrée du second calcul, et ainsi de suite.

4. Analyse de l’ordonnancement – Analyse Rate Monotonic.

Après la décomposition de l’application embarquée en ISR et en taches, les taches doivent être
ordonnancées pour s’exécuter dans un ordre afin d’atteindre la fonctionnalité souhaitée du
système. L’analyse de l’ordonnancement détermine si toutes les taches peuvent être
ordonnancées selon un algorithme d’ordonnancement pour s’exécuter et respecter leur
deadline tout en réalisant une utilisation optimale du processeur. Notez que l’analyse de
l’ordonnancement concerne uniquement la manière de respecter les contraintes temporelles,
mais pas les contraintes fonctionnelles.
Une méthode analytique couramment employée pour les systèmes temps réels est la RMA
(Rate Monotonic Analysis). Ce modèle est développé à partir d’un mécanisme
d’ordonnancement appelé RMS (Rate Monotonic Scheduling), qui est un algorithme
d’ordonnancement préemptif. Il s’agit d’attribuer un niveau de priorité à une tache en fonction
(monotone) de sa fréquence d’exécution. En d’autres termes, plus la période entre chaque
exécution est courte, plus la priorité de la tâche sera élevée. Il existe des variantes du RMA.
Celle de base est nommée RMA basic ou RMA simple.
Un ensemble d’hypothèse est associé au RMA simple :

 Toutes les taches sont périodiques.

 Toutes les taches sont indépendantes les unes des autres et aucune interaction apparait
entre les taches.
 La deadline d’une tache est le début de la période suivante.
 Chaque tache à une durée fixe d’exécution, cette durée ne varie pas dans le temps.
 Toutes les taches ont le même niveau de criticité.
 Les taches apériodiques sont limitées au travail d’initialisation et de rétablissement
après erreurs, ces taches apériodiques n’ont pas de deadlines dures.

4.1. Test d’ordonencabilité de la RMA simple.

L’équation suivante est utilisée pour le test d’ordonençabilité d’un système utilisant le RMA
basique.

( )
1
C1 C
+ …+ n ≤ U ( n )=n . 2 n −1 et 1 ≤i ≤n .
T1 Tn

12
 Avec :
C i : le pire temps d’exécution associé à la tache périodique i .

T i: la période associée à la tache i .

n : le nombre de taches.

U(n) est le facteur d’utilisation. Le côté droit de l’équation est la borne de l’utilisation
théorique du processeur. Si l’utilisation du processeur pour un ensemble de taches données est
inférieure à la borne de l’utilisation théorique, l’ensemble des taches est ordonençable. La
valeur de U décroit lorsque n augmente et converge vers 69% lorsque n tend vers l’infini.
Prenons un exemple, la table suivante résume les propriétés de trois taches qui sont
ordonnancées selon RMA.

Taches Durée d’exécution (en ms) Période (en ms)

périodiques
Tache 1 20 100
Tache 2 30 150
Tache3 50 100

( )
1
C1 Cn
En reprenant la formule + …+ ≤ U ( n )=n . 2 n −1 , on obtient :
T1 Tn

( )
1
20 30 50
+ + ≤U ( 3 )=3. 2 3 −1
100 150 300
donc 56,67 % ≤ U ( 3 )=77.98 % .

L’utilisation totale est de 57 %, ce qui est inférieur à la limite théorique de 77%. Ce système
de trois taches est donc ordonnençable, ce qui signifie que chaque tache peut respecter sa
deadline.

4.2. Test d’ordonencabilité de la RMA étendue.

Le RMA basique impose des limites. La seconde hypothèse du RMA basique n’est pas
réalisable car les taches des systèmes temps réels ont des interdépendances, et les méthodes de
synchronisation entre taches font partie de la conception des systèmes temps réels. La
synchronisation, cependant, dépasse le cade du RMA basique.
Le déploiement des méthodes de synchronisation inter taches implique que certaines taches du
système vont être dans l’état bloqué, qui est la suspension de l’exécution d’une tache en
attente de ressources. Dans ce cas, le RMA basique est étendu pour prendre en compte la
synchronisation des taches. L’équation suivante concerne le test d’ordonençabilité dans le cas
du RMA étendue.

13
 ( )
1
C1 C i Bi
+ …+ + ≤ U (i ) =i. 2 i −1 et 1 ≤i ≤n .
T1 Ti Ti

Avec :
C i : le pire temps d’exécution associé à la tache périodique i .

T i: la période associée à la tache i .

Bi : la plus grande durée de blocage expérimentée par la tache périodique i .

n : le nombre de taches.

Cette équation est plus compréhensible avec un exemple. Reprenons le cas des trois taches du
tableau précédent et ajoutons deux ressources partagées comme indiqué à la figure suivante.
La ressource 1 représente une mémoire partagée et la ressource 2 est un bus d’E/S.

La tache 1 utilise la ressource 2 pendant 15 ms une fois toutes les 100ms.La tache 2 est un peu
plus complexe. C’est la seule tâche qui utilise les deux ressources. La ressource 1 est utilisée
durant 5ms et la ressource 2 est utilisée durant 10 ms. La tache 2 a une période de 150 ms. La
tache 3 s’exécute toute les 300 ms et utilise la ressource 2 durant 18 ms.
Le test d’ordonençabilité du RMA étendu donne trois équations séparées qui doivent respecter
chacune une limite d’utilisation.

( )
1
La première équation donne 20 + 18 ≤ U ( 1 )=1 . 2 1 −1 =1
100 100
donc 38 % ≤ U ( 1 )=100 %.

La tache 2 ou la tache 3 peut bloquer la tache 1 en utilisant la ressource 2. Le facteur de

blocage B1 est supérieur au temps de détention de la ressource par la tache 2 ou la tache 3, qui
est 18ms, à partir de la tache 3. En appliquant ce nombre à l’équation RMA étendue, on trouve
un résultat inférieur à la limite d’utilisation de 100% de la tache 1. La tache 1 est donc
ordonneçable.

14
En considérant la seconde équation, la tache 2 peut être bloquée par la tache 3. Le facteur de
blocage B2 est de 18 ms, qui est le temps que la tache 3 contrôle la ressource 2, ce qui donne :

( )
1
20 30 18
+ + ≤U ( 2 )=2 . 2 2 −1
100 150 150
donc 5 2 % ≤ U ( 2 ) =82 .84 %.

La tache 2 est également ordonneçable comme le résultat est inférieur à la limite d’utilisation
des deux taches.

Considérons maintenant la dernière équation et notons que Bn est toujours égal à 0. Le facteur
ce blocage pour la tache de plus bas niveau est 0, puisque aucune autre tâche peut la bloquer
(elles peuvent toutes la préempter en cas de besoin). On obtient :

( )
1
20 30 50
+ + ≤U ( 3 )=3. 2 3 −1
100 150 300
donc 5 6,67 % ≤ U ( 3 )=77 . 98 % .

Une fois de plus, le résultat est inférieur à la limite d’utilisation pour les trois taches. Toutes
les taches sont donc ordonneçables.
D’autres extensions du RMA basique pour prendre en compte les autres hypothèses associées
au RMA basique, telles que les taches apériodiques dans les systèmes temps réel.

15