Systèmes temps réel et embarqués

Transcription

M2P GLRE
Génie Logiciel, logiciels Répartis et Embarqués
Systèmes temps réel et embarqués
Concepts de base, expression des contraintes temporelles
Z. Mammeri
1. Introduction
Aujourd’hui, les applications temps réel et embarquées sont de plus en plus variées et elles prendront de
plus en plus de place dans notre vie quotidienne de demain. Réservés, il y a quelques années, aux
applications industrielles, les systèmes temps réel et embarqués font leur apparition dans beaucoup d’autres
secteurs tels que le transport, le multimédia, les consoles de jeux, ... En termes de complexité, les systèmes
temps réel et embarqués couvrent un large spectre allant du simple microcontrôleur (pour le contrôle de la
fermeture/ouverture d’une vanne, par exemple), jusqu’aux systèmes répartis (pour le contrôle du trafic
aérien, par exemple). Les enjeux économiques et les intérêts scientifiques liés aux systèmes temps réel et
embarqués sont multiples. C’est la raison pour laquelle on assiste, depuis les années soixante-dix, à une
profusion de langages, de méthodes, d’algorithmes, de protocoles de communication, etc., pour le temps réel
et l’embarqué.
Les travaux développés sur le temps réel et l’embarqué concernent des sujets diversifiés notamment : la
spécification et la conception d’applications, les exécutifs, les langages, les protocoles de communication, la
vérification et validation d’applications et de protocoles, le contrôle de procédés, l’automatique, les bases de
données, les systèmes experts et le multimédia. La diversité des compétences qui interviennent aujourd’hui
dans les applications dites temps réel et embarquées est telle qu’il est parfois difficile, surtout pour un
profane, de saisir parfaitement le sens du terme temps réel et embarqué. Le temps réel exprime une qualité
de service à fournir, pour certains, une nécessité de garantir des délais de réponse connus à l’avance,
pour d’autres.
Toutes les applications temps réel ont une caractéristique commune qui réside dans l’existence de
contraintes temporelles dont il faut tenir compte. Ces contraintes peuvent prendre diverses formes
(échéances, intervalles de temps, durée de validité, etc.) et s’appliquer à des objets variés. En effet, dans les
applications temps réel, les données ont une durée de vie limitée et deviennent obsolètes après un certain
temps, les événements apparaissent à des instants particuliers et doivent être pris en compte au bout de délais
connus à l’avance et les traitements (ou actions) ont souvent des instants de débuts, de fin et des durées
d’exécutions fixés.
Nous voulons, dans ce chapitre, clarifier le concept de contraintes de temps, en particulier leurs origines,
les formes d’expressions qu’elles prennent et le problème lié à leur dérivation tout au long du cycle de
conception et de développement d’une application temps réel. Les différents aspects des contraintes
temporelles sont traités à l’aide d’exemples simples pris dans différents domaines d’activités qui font appel
aux applications et systèmes temps réel.
2. Applications et systèmes temps réel et embarqués
2.1. Domaines d’applications
Jusqu’à une date récente, les systèmes temps réel et embarqués étaient destinés quasi-exclusivement aux
applications de contrôle/commande de procédés (ou de phénomènes) physiques (tels que des laminoirs ou
des usines de fabrication de voitures) et applications militaires. La notion de temps réel se confondait alors
avec ce type d’applications. Le développement de l’informatique aidant, les applications temps réel et
embarqués sont présentes aujourd’hui dans des domaines très variés comme le montre la liste suivante, même
si elle n’est pas exhaustive :
− télécommunications (transport de la parole, systèmes de commutation, …),
− domaine médical (assistance et supervision de malades, …),
− contrôle de différents équipements dans les voitures, bus, trains, avions, …,
− contrôle et régulation de trafic en milieu urbain,
Contraintes temporelles - Z. Mammeri
2
− 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.
2.2. Définitions
La diversité des domaines d’applications rend difficile l’élaboration de définitions sur lesquelles tout le
monde s’accorde.
1. Systèmes embarqués
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 dont les
programmes sont stockés en ROM. A priori, tous les systèmes qui ont des interfaces digitales (i.e. montre,
caméra, voiture…) peuvent être considérés comme des SE. Certains SE ont un système d’exploitation et
d’autres non car toute leur logique peut être implantée 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
3
2. Systèmes temps réel
Selon l’aspect abordé dans les systèmes temps réel, on choisit une définition qui s’approche le plus de la
problématique traitée. Ainsi, on assimile, selon le cas, un système temps réel à un système rapide, à un
système en interaction directe avec un procédé physique, à un système réactif, à un système qui ne fournit
pas de réponse en différé, à un système avec un comportement prédictible, à un système qui travaille sur des
données fraîches, à un système robuste, etc.
Cependant, toutes les applications temps réel (dites aussi applications contraintes par le temps ou encore
applications temps contraint) ont en commun la prépondérance du facteur temps. Elles doivent réagir en
tenant compte de l’écoulement du temps (on parle de timeliness property, en anglais). Cette caractéristique
fondamentale qui distingue globalement les applications temps réel des autres types d’applications
informatiques (de gestion ou autres) est exprimée par la définition suivante qui est la plus couramment
référencée dans la littérature :
A real-time system is defined as a system whose correctness of the system depends not only on the logical
results of computations, but also on the time at which the results are produced [STA 88].
Cette définition a conduit, en quelque sorte, à l’adage suivant que toute personne intervenant dans le cycle
de vie d’une application temps réel connaît ou devrait connaître : Un résultat juste mais hors délai est un
résultat faux.
En plus de l’existence de contraintes de temps, et selon les domaines d’applications, les définitions
consacrées à la notion d’applications temps réel font apparaître des propriétés fondamentales, notamment la
prédictibilité des comportements et la tolérance aux fautes. En effet, dans les applications temps réel dites
temps critique (telles que la commande de procédés industriels ou d’engins militaires), le respect des
contraintes de temps est une nécessité en toute circonstance (y compris les situations de surcharge des
processeurs et du réseau), et on parle alors de propriété de prédictibilité du comportement (ou predictability,
en anglais) du système. Il faut noter que le degré de prédictibilité varie d’une application à l’autre. Certaines
applications exigent une prédictibilité absolue (100%), d’autres se contentent d’un seuil fixé en dessous
duquel on considère que la qualité de service rendu est remise en cause.
Des définitions, comme celle que l’on trouve dans le Petit Larousse introduisent la notion d’urgence de
traitement (“ … élaboration immédiate de résultats ”). De telles définitions sont trop restrictives. Il est admis
aujourd’hui que le temps réel, dans son contexte général, n’implique pas nécessairement la rapidité, mais
plutôt, une exécution à temps pour tenir compte de la dynamique du phénomène auquel est associée une
application temps réel. Une contrainte du type “ lancer la sirène de l’usine à midi ” est bien une contrainte
temporelle, mais elle n’implique pas nécessairement une réponse immédiate dès que cette contrainte est
connue, mais plutôt une réponse à un instant précis, c’est-à-dire, à midi. La rapidité de réponse d’un système
est un paramètre de performance qu’il faut distinguer du concept de temps réel. Il est évident qu’un système
qui réagit très vite aux événements qu’il détecte a de fortes chances de convenir aux applications temps réel.
Il est à noter aussi que des performances minimales (en termes de temps de réponse, de délais de
communication, etc.) sont souvent exigées d’un système pour que celui-ci puisse être utilisé afin de répondre
à des contraintes de temps spécifiques. Des performances minimales sont nécessaires pour le temps réel,
mais elles ne sont pas suffisantes, il faut savoir les adapter correctement aux contraintes de temps à satisfaire,
en particulier par l’utilisation d’algorithmes d’ordonnancement adéquats. Une pratique courante consiste à
surdimensionner les systèmes utilisés pour être sûr de respecter les contraintes de temps imposées.
Par ailleurs, toute application temps réel est en interaction (forte ou faible selon les cas) avec son
environnement. Lequel environnement peut être un procédé industriel, un moteur d’avion, une ville (si on
s’intéresse à la pollution, par exemple), un malade, un groupe de participants à une téléconférence, un enfant
devant sa console de jeu, etc. La nature de l’environnement à une incidence directe sur la criticité des actions
entreprises dans une application temps réel.
2.3. Notion de criticité et d’importance des opérations
4
La notion de “criticité” (ou criticality en anglais) a été introduite comme critère pour pouvoir classer les
applications temps réel selon la sévérité, en terme de coût engendré par le non-respect des contraintes
temporelles. On parle de faute temporelle, quand les contraintes de temps ne sont pas respectées.
On distingue généralement les fautes bénignes n’affectant pas de manière significative le service rendu
par le système et les fautes catastrophiques conduisant à des pertes de vies humaines, des pertes financières,
de la pollution de l’environnement, etc. [LAP 92]. En utilisant la notion criticité, on a coutume de classer les
systèmes temps réel en trois familles :
− Systèmes à contraintes temporelles critiques (hard real-time systems) où le non-respect des
contraintes de temps peut conduire à des défaillances avec des conséquences pouvant être graves. Si
l’échéance est dépassée, il y a faute. Si l’échéance est dépassée, il y a faute.
− Systèmes à contraintes temporelles souples (soft real-time systems) où le dépassement des échéances
est considéré comme une faute bénigne. Lorsqu’une échéance est dépassée, il n’y a pas faute ; le résultat peut
être exploitable même s’il est fourni après l’échéance.
− Systèmes à contraintes temporelles strictes (firm real-time systems) où le dépassement occasionnel
des échéances est toléré. Il y a faute (bénigne) si l’échéance n’est pas respectée.
EXEMPLES.
1. Les systèmes d’interception de missiles ou de contrôle d’atterrissage d’avions sont considérés comme
étant des systèmes à contraintes temporelles critiques. En effet, dans un système d’interception de missiles, si
un missile n’est pas intercepté à temps, cela peut conduire à des conséquences graves. Si une opération
d’atterrissage d’un avion commencée n’est pas achevée au bout d’un délai borné, un accident grave peut
survenir.
2. Les systèmes de téléconférences et les systèmes de réservation des compagnies aériennes sont considérés
comme étant des systèmes à contraintes temporelles souples. Dans un système de téléconférence, son et
image doivent être synchronisés, mais des dérives de synchronisation (dues à des messages tardifs) sont
souvent tolérées. Pour les systèmes de réservation des compagnies aériennes, si une requête de réservation
dure un peu plus longtemps que prévu, la seule conséquence regrettable peut être la perte d’un client qui
quitte l’agence, car il ne souhaite plus attendre davantage.
3. Certains systèmes de supervision d’installations industrielles sont considérés comme des systèmes à
contraintes strictes. Par exemple, des pièces fabriquées sur une chaîne de production sont déposées sur un
convoyeur et passent devant une caméra qui doit détecter certaines anomalies de fabrication. En fonction des
anomalies détectées par le système de reconnaissance, les pièces sont dirigées vers la cellule de fabrication
appropriée. La détection des anomalies doit se faire pendant que la pièce est en mouvement. Si la détection
d’anomalie ne s’est pas faite dans les temps, la pièce est recyclée sur le convoyeur pour une deuxième
analyse. On accepte que le système recycle une pièce sur dix car s’il recycle trop de pièces la chaîne de
production s’en trouve ralentie.
Les contraintes temporelles critiques doivent être respectées en toute circonstance. Pour les contraintes
temporelles souples, on peut, selon les domaines d’applications et surtout selon les choix du concepteur :
− Soit décider que toutes les opérations à contraintes temporelles souples ont la même importance et en
cas de surcharge du système, les opérations à sacrifier (c’est-à-dire, celles qui vont rater leurs échéances)
sont sélectionnées en fonction de l’ordre d’arrivée des requêtes associées à ces opérations.
− Soit décider d’affecter des niveaux d’importance qui seront utilisés pour choisir les opérations à
sacrifier. Avec cette deuxième approche, le système essaiera de minimiser les opérations tardives, mais aussi
de garantir le respect des opérations les plus importantes d’abord. Dans la pratique, le concepteur évite
souvent (par manque d’informations suffisantes, ou peut-être, parce qu’il considère que tout est important
pour lui) d’affecter des niveaux d’importance aux opérations à effectuer, ce qui rend cette approche peu
utilisée.
2.4. Schéma général de système temps réel
5
Figure 1. Système de contrôle-commande
BVR : boîte vitesse robotisée
Figure 2. Exemple de système de contrôle commande
6
Figure 3. Composants d’un système de contrôle-commande
Capteurs
Actionneurs
Environnement
Système de contrôle
Figure 4. Système temps embarqués et non embarqués
7
2.5. Vues de systèmes temps réel et embarqué
a) Vues métier
- Chimiste
- Médecin
- Pilote
-…
Î
Î
Î
Formes, durées … des réactions chimiques
Types de maladie, paramètres biologiques…
Décollage, atterrissage, manette, altitude…
b) Vues de l’automaticien
Figure 5. Vue de l’automaticien
8
c) Vues de l’informaticien
Figure 6. Vue de l’informaticien
Figure 7. Processus de modélisation
9
Figure 8. Analyse des besoins
Figure 9. Identification de fautes et modes de marche
10
2.6. Objets de base des applications temps réel et embarquées
Toute application temps réel est composée d’un ensemble d’actions qui opèrent sur des données en tenant
compte de l’écoulement du temps et des événements qui apparaissent au niveau du système informatique ou
de son environnement. Les trois concepts (actions, données et événements) sont les composants de base de
toutes les applications temps réel. Les contraintes temporelles sont exprimées sur ces trois types d’objets.
Nous définissons d’abord ces trois types d’objets et nous verrons ensuite les contraintes temporelles que l’on
peut leur associer.
Une action peut correspondre à tout traitement ayant une fonctionnalité bien précise au niveau de
l’application, cela peut être une tâche dans les systèmes temps réel, une transaction dans les bases de données
temps réel, une opération de transmission sur un réseau, un agent dans les systèmes à base de connaissances,
etc. Au cours de la phase de conception, des actions sont introduites, par raffinement d’autres actions. On
peut alors distinguer des actions simples et des actions composées qu’il faut raffiner lors d’une étape
ultérieure.
Une donnée représente toute information simple ou composée utilisée par une ou plusieurs actions pour
s’exécuter. Une mesure de température, un fichier contenant une image ou un paquet véhiculé par un réseau
sont des exemples de données.
Un événement désigne un changement d’état dans le système informatique ou dans son environnement.
“ température > 100° C ”, “ Fin de la tâche T1 ”, “ réception d’une image vidéo ”, “ Fin de transaction ” sont
des exemples d’événements. Les occurrences d’événements peuvent apparaître de manière périodique, à des
instants connus à l’avance ou de manière aléatoire. En général, l’occurrence d’un événement désigne le
passage de vrai à faux (ou de faux à vrai) d’une condition dite condition événementielle. L’action effectuée
pour traiter une occurrence d’événement est dite action événementielle.
11
3. Origines des contraintes temporelles
Pour comprendre les origines des contraintes temporelles imposées à une application temps réel, il faut
remonter à l’environnement dans lequel ladite application est destinée à fonctionner. Pour aider à mieux
comprendre les origines des contraintes temporelles, nous commençons tout d’abord par fixer les idées à
l’aide de quelques exemples :
EXEMPLE. ⎯
1. Pour offrir une bonne qualité vidéo dans une application multimédia, 25 images par seconde sont
nécessaires.
2. Des pièces fabriquées sur une chaîne de production sont déposées sur un convoyeur et passent, avec
une vitesse de 1 m/s, devant une caméra qui doit détecter certaines anomalies de fabrication. En fonction des
anomalies détectées par le système de reconnaissance, les pièces sont dirigées vers une cellule de fabrication
appropriée. La détection des anomalies doit se faire pendant que la pièce est en mouvement. Par conséquent,
le traitement doit s’effectuer au bout d’un temps bien précis tenant compte de la vitesse du convoyeur, pour
permettre à la pièce d’être aiguillée vers la bonne cellule.
3. Un système de contrôle de trafic aérien prend des décisions concernant des avions qui veulent atterrir
en tenant compte de nombreux facteurs, tels que le nombre de pistes, la position des avions et leur réserve en
carburant, la vitesse du vent, les correspondances des passagers, etc. Le temps d’attente d’un avion avant
atterrir tient compte de tous ces facteurs.
4. Le temps d’accès à une base de données pour effectuer une réservation de place sur un vol ne doit pas
excéder deux minutes, pour éviter de longues attentes aux clients.
5. L’application doit être supportée par un réseau de type bus à jeton à 10 Mb/s déjà installé par
l’entreprise.
6. Pendant une répétition musicale distribuée, la musique jouée par un musicien à l’aide d’un instrument
connecté à une station de travail doit être acheminée vers tous les autres membres de l’orchestre au bout de
quelques millisecondes, pour que l’ensemble de l’orchestre soit synchronisé.
Les premiers travaux à avoir tenté de clarifier le concept de contraintes temporelles sont ceux de
Dasarathy [DAS 85] et Taylor [TAY 80] qui ont proposé une classification des contraintes de temps en deux
catégories : des contraintes comportementales qui imposent des limites sur les inter-arrivées de stimuli au
système, des contraintes de performance qui imposent des limites sur les temps de réponse du système,
Cette classification a été améliorée par Ramamritham [RAM 96] pour distinguer :
− des contraintes temporelles liées à l’environnement (c’est-à-dire, ayant des origines externes), c’est le
cas des exemples 1, 2, 3, 4 et 6 ci-dessus,
− et des contraintes temporelles liées à des choix de conception et d’implantation (c’est-à-dire, ayant des
origines internes), c’est le cas de l’exemple 5 ci-dessus.
3.1. Origines externes
Dans ce cas, les contraintes temporelles sont inhérentes à la dynamique de l’environnement et elles
peuvent correspondre, en général, à :
− Des caractéristiques physiques (telles que la vitesse d’un avion) ;
− Des caractéristiques liées aux lois de commande du système physique (telles que les boucles de
régulation) ;
− Une qualité de service requise en terme de délai de réponse tolérable (par exemple, un temps maximum
pour autoriser un avion à se poser, une fois que le pilote a émis une demande d’atterrissage, ou encore une
fréquence d’échantillonnage du son, pour offrir une certaine qualité audio) ;
12
− La perception sensorielle et le temps de réaction de l’homme (par exemple, tenir compte du temps entre
lequel un système de contrôle signale une alarme indiquant que le niveau bas de carburant est atteint et
l’instant de réaction du pilote à cette alarme pour se poser en urgence) ;
− Des contraintes à caractère commercial ou autres (par exemple, les produits commandés doivent être
livrés x jours au plus tard après la réception de la commande).
Les contraintes temporelles ayant leur origine dans l’environnement de l’application temps réel sont
imposées et l’application doit y faire face. La compréhension des origines des contraintes temporelles est
importante. En effet, ce sont ces origines qui nous renseignent sur les contraintes temporelles qu’il faut
impérativement respecter et celles que l’on peut rater de temps à autre.
3.2. Origines internes
Une fois que les contraintes inhérentes à l’environnement sont explicitées, le développement d’une
application temps réel conduit à faire des choix de :
− Conception, c’est-à-dire :
- d’architecture centralisée ou répartie (répartition des données, du contrôle),
- d’actions périodiques (avec les périodes adéquates) ou apériodiques ,
- d’actions critiques ou actions non critiques,
− Une architecture matérielle et logicielle pour supporter l’application, en particulier choix de :
- processeurs avec des vitesses particulières,
- système d’exploitation (intégrant des algorithmes d’ordonnancement),
- réseau offrant des débits et des temps de réponse donnés avec un coût qui tient compte de la nature
de l’application.
Les choix précédents conduisent à introduire des contraintes temporelles en termes de périodes,
d’échéances (ou deadlines), de durées de vie des données, de délais de communication, de temps d’exécution
pour chaque action, de temps de réaction à un événement, etc. Il est clair que les décisions prises à une étape
du cycle de développement ont une incidence directe sur les contraintes imposées à l’étape suivante. Par
exemple, si on décide de placer deux tâches sur deux machines différentes, il va falloir préciser les
contraintes temporelles imposées aux messages à partir de celles imposées aux tâches communicantes. On
parle dans ce cas de dérivation de contraintes d’un niveau à partir de celles du niveau supérieur.
13
4. Types d’expression des contraintes temporelles
Une contrainte temporelle sur une action, une donnée ou un événement peut s’exprimer en faisant
référence au temps quantifié (temps explicite) ou au temps non quantifié (temps logique).
4.1. Expressions à l’aide du temps quantifié
Le temps explicite fait référence aux instants (temps absolu) ou aux intervalles de temps (temps relatif).
Généralement le temps explicite est exprimé en utilisant l’une des formes suivantes :
− un instant (ou une date),
− une fenêtre temporelle (ou un intervalle de temps),
− une durée (ou un délai ou encore une période),
Un instant (ou une date) exprime un point particulier sur l’axe du temps. Ce point peut être une constante
(par exemple "midi") ou l’instant d’occurrence d’un événement (par exemple, "début d’une transaction sur
une base de données").
Une fenêtre temporelle (un intervalle, un délai ou une période) exprime un segment sur la droite du
temps. Une fenêtre temporelle (ou un intervalle de temps) est définie à l’aide d’un couple d’instants qui en
définissent le début et la fin.
Avec la notion de durée (ou de délai), on introduit parfois la notion de minimum, de maximum ou de
moyenne, pour indiquer, non pas une valeur exacte à respecter, mais plutôt une borne inférieure ou
supérieure ou une moyenne à respecter. Ces notions sont, en général, associées à la durée d’exécution des
actions. La durée minimale est exigée pour obtenir des résultats dans le meilleur des cas, la durée maximum,
dans le pire des cas. La durée moyenne est utilisée pour tenir compte de la distribution de la charge du
système et permet, entre autres, de déterminer la probabilité de respect des contraintes de temps des
opérations non temps critique en fonction de la charge du système.
4.2. Expressions à l’aide du temps logique
Le temps logique est utilisé pour exprimer des relations entre intervalles de temps, non nécessairement
mesurés explicitement, durant lesquels s’exécutent des actions, ou entre des occurrences d’événements. Il
permet, par exemple, d’exprimer qu’un événement E1 apparaît avant ou après un autre événement E2. Il a
été introduit par Lamport [LAM 78].
Les opérateurs introduits par Allen constituent une extension de ceux introduits par Lamport et permettent
d’exprimer les relations usuelles entre intervalles de temps (Before, Meets, During, Starts with, etc.) [ALL
83]. Il faut signaler que nous ne traitons pas ici les opérateurs modaux indiquant des aspects temporels tels
que un jour, parfois, infiniment, souvent, toujours, etc., étudiés par les linguistes et en intelligence artificielle
pour raisonner sur le temps, et qui ne sont pas utilisés dans les applications temps réel actuelles.
Il est important de souligner que l’analyse des contraintes exprimées à l’aide du temps logique permet
d’élaborer et de vérifier des propriétés logiques qui apportent des informations très intéressantes sur les
systèmes temps réel, en particulier les propriétés de sûreté et de vivacité.
14
5. Contraintes temporelles associées aux événements, données et actions
5.1. Contraintes temporelles associées aux événements
Une occurrence d’événement représente un changement d’état significatif qui déclenche une action
événementielle explicitement spécifiée. C’est au travers des événements qu’une application temps réel réagit
aux changements d’état de son environnement (on parle dans ce cas d’événements externes ou de stimuli et
réponses) et du système informatique (on parle dans ce cas d’événements internes).
Selon la nature des événements (qu’ils soient internes ou externes), et donc selon le sens des actions
événementielles qui leur sont associées, la prise en compte des occurrences successives peut être interprétée
de plusieurs manières : une seule occurrence à la fois, toutes les occurrences doivent être prises en compte,
etc. Cela a conduit à distinguer trois types d’événements :
− Evénements fugaces : il s’agit d’événements destinés à être traités immédiatement par les actions qui
sont en attente de ces événements. Si aucune action n’est en attente d’un événement fugace, l’occurrence de
celui-ci est perdue.
EXEMPLE. ⎯ Les systèmes de guidage de véhicules en milieu urbain renseignent, en temps réel, les usagers
sur la présence de chantiers, accidents et bouchons concernant toute une ville, un quartier ou un itinéraire.
Quand un accident est signalé par le PC de circulation, seuls les usagers ayant choisi des itinéraires passant
par le point d’accident sont avertis par leurs systèmes embarqués qui leur proposent alors de nouveaux
itinéraires. Dans ce cas, l’événement “ accident de circulation ” est considéré comme fugitif pour les usagers.
Cet événement est, par contre, nettement mémorisé par les personnes subissant l’accident.
− Evénements mémorisés : contrairement à un événement fugace, une occurrence d’événement
mémorisé est enregistrée jusqu’à ce qu’elle soit prise en compte. La question qui se pose ensuite est que se
passe-t-il si plusieurs occurrences sont détectées alors que la première de ces occurrences n’est pas encore
complètement traitée ? Selon la nature de l’événement, on peut :
- soit traiter une seule occurrence à la fois et toutes celles qui arrivent entre temps sont ignorées. On
parle, dans ce cas, d’événement de type booléen.
EXEMPLE. ⎯ On considère un émetteur qui diffuse des messages vers un ensemble de récepteurs. Si un des
récepteurs ne reçoit pas correctement un message, il renvoie un acquittement négatif. La réception d’un
acquittement négatif, par l’émetteur, constitue un événement (appelons-le “ erreur de communication ”).
Après diffusion d’un message, l’émetteur attend pendant un certain temps. Si un ou plusieurs acquittements
négatifs ont été reçus, l’émetteur rediffuse le message concerné à tous les récepteurs. Dans ce cas, on
considère que l’événement “ erreur de communication ” est de type booléen, puisque l’action de
retransmission (c’est-à-dire, l’action de prise en compte de l’événement) est déclenchée une seule fois pour
tous les acquittements négatifs correspondant à un même message.
- Soit traiter obligatoirement toutes les occurrences de l’événement. On parle, dans ce cas,
d’événement à compte.
EXEMPLE. ⎯ Un robot met des bouteilles dans des boîtes. L’arrivée d’une bouteille devant le robot est
signalée via un événement “ présence bouteille ”. Si une bouteille arrive alors que le bras du robot est en
train de mettre la bouteille précédente dans une boîte, cette dernière bouteille est prise en compte dès que le
bras du robot devient libre. Ainsi toutes les occurrences de l’événement sont prises en compte.
Le système informatique perçoit une occurrence d’événement comme un signal défini, du point de vue
temporel, par trois paramètres : un instant de signalisation de l’occurrence, un instant de prise en compte de
l’occurrence (c’est-à-dire, l’instant de lancement de l’action événementielle) et un instant d’acquittement
(c’est-à-dire, l’instant d’effacement de l’occurrence). Les contraintes temporelles, pour la prise en compte de
15
l’événement, peuvent être exprimées sur la durée de vie des occurrences et/ou sur les instants et/ou l’ordre
d’occurrences d’événements.
5.1.1. Contraintes temporelles sur la durée de vie d’événement
Pour tenir compte de la dynamique de l’application, un événement détecté doit être traité au bout d’un
délai maximal connu à l’avance. Ce délai est appelé durée de vie de l’événement et désigne l’intervalle de
temps pendant lequel l’action événementielle doit être exécutée et terminée une fois l’occurrence de
l’événement détectée. Il s’agit ici d’une contrainte exprimée à l’aide du temps quantifié.
EXEMPLE. ⎯ Si on considère qu’un débordement a lieu 10 secondes après que le niveau haut du liquide
dans une cuve est atteint et qu’aucune opération de fermeture de vanne n’a été réalisée, alors l’événement de
détection du niveau haut a une durée de vie de 10 secondes.
Le concepteur peut aussi raisonner sur la durée de vie d’un événement en utilisant le temps logique. Une
occurrence d’événement cesse d’être valide dès qu’un autre événement est détecté.
EXEMPLE. ⎯ Une occurrence de l’événement “ vanne ouverte ” reste valide jusqu’à ce que l’événement
“ vanne fermée ” soit détecté.
5.1.2. Contraintes temporelles sur les instants et l’ordre d’occurrence d’événements
Ces contraintes indiquent à quel instant absolu ou relatif une occurrence d’événement va avoir lieu. Des
expressions usuelles de ce type de sont les suivantes :
− un événement doit avoir lieu à un instant précis.
EXEMPLE. ⎯ La sirène doit sonner trois fois à midi le premier mercredi de chaque mois.
− Un délai minimum, maximum ou moyen entre les occurrences d’un même événement ou de deux
événements différents. Ceci permet d’exprimer des relations entre un stimulus et une réponse, entre deux
stimuli, etc. Les contraintes sur les délais maximum et minimum entre occurrences d’événements décrivent
en quelque sorte le débit d’événements que peut supporter le système temps réel.
EXEMPLE. ⎯ Selon la norme ITU B112, pendant la composition d’un numéro téléphonique, lorsqu’un
chiffre est tapé, le suivant doit l’être après 66 ms au minimum et 10 à 20 secondes (selon le réseau) au
maximum.
− Un événement doit avoir lieu avant (ou après) un autre événement explicite, ou avant (ou après) un
autre événement parmi un ensemble d’événements.
− Un événement doit avoir lieu en même temps qu’un autre événement (la notion de simultanéité
d’événements signifie que les instants d’occurrence d’événements sont distants d’une quantité inférieure à
l’intervalle minimal de datation des événements dans l’application considérée). En particulier, si on se place
dans le contexte des systèmes répartis, la simultanéité d’événements résulte de l’incapacité à définir une
relation avant ou après entre événements apparaissant sur des sites différents, à cause de l’existence de vues
(pouvant être différentes d’un site à l’autre) engendrées par les délais de communication variables.
Il est à noter que les contraintes énumérées précédemment ne s’appliquent qu’aux événements mémorisés.
Les événements fugaces, de par leur nature, n’imposent pas de contraintes temporelles explicites sur leur
prise en compte.
16
5.2. Contraintes temporelles associées aux données
Selon le niveau hiérarchique de l’application auquel on se place, une donnée peut être une mesure d’une
grandeur physique, une variable locale, un fichier, un paquet en cours d’acheminement dans un réseau, etc.
Une donnée est produite à un instant (dit instant de production) par une action, dite producteur, et est utilisée
à un autre instant (dit instant d’utilisation ou de consommation) par une autre action, dite utilisateur ou
consommateur. Pour prendre des décisions correctes tenant compte de l’état réel de l’environnement, les
données manipulées par une application temps réel doivent être cohérentes du point de vue temporel. Les
contraintes de cohérence de données temps réel peuvent s’exprimer de trois manières : par des contraintes
individuelles (ou de durée de validité), des contraintes de production ou des contraintes de groupe
(contraintes de corrélation).
− Durée de validité (ou contrainte de fraîcheur) : la durée de validité d’une donnée temps réel correspond
à l’intervalle de temps maximum séparant l’instant de consommation de l’instant de production de cette
donnée. Une donnée peut avoir, selon la nature de l’application, une durée de validité unique pour tous les
consommateurs, ou bien une durée de validité propre à chaque consommateur (ou à un groupe de
consommateurs).
EXEMPLE. ⎯ Dans un jeu vidéo, des disques sont lancés et le joueur doit les détruire en vol. Un disque n’est
présent à l’écran que pendant une seconde (durée de validité) et le joueur doit réagir vite pour marquer des
points.
− Contraintes de production : elles expriment des contraintes sur le rythme de production de valeurs
d’une donnée. En général, elles s’appliquent aux données produites périodiquement et spécifient les
intervalles de temps minimum ou maximum entre les instants de production de deux valeurs d’une même
donnée.
EXEMPLE. ⎯ Un système de surveillance de l’entrée principale d’un immeuble doit prendre et enregistrer
une image par seconde.
− Contraintes de corrélation : dans une application temps réel, une action peut utiliser plusieurs données,
mais pour fournir un résultat temporellement correct, les données utilisées doivent être produites dans un
même intervalle de temps donné. On parle, dans ce cas de contraintes de corrélation.
EXEMPLE. ⎯ L’animation d’une réunion à l’aide d’un système de téléconférence nécessite que l’application
multimédia sous-jacente utilise des sons et des images échantillonnés en même temps, pour que le geste et la
voix soient coordonnés.
5.3. Contraintes temporelles associées aux actions
Dans une application temps réel, les actions (c’est-à-dire, les tâches, les processus, les agents, etc. selon
le domaine d’application) opèrent sur des données temporelles en tenant compte de l’écoulement du temps et
des occurrences d’événements. Généralement, dans les applications temps réel, les actions sont activées
périodiquement, à des instants fixes ou sur occurrences d’événements. Pour tenir compte des contraintes de
validité des données et de durée de vie des événements, la durée d’exécution des actions est bornée. Par
ailleurs, la coopération entre différentes actions composant une application temps réel, conduit à imposer des
contraintes de précédence à ces actions. Ainsi, les principales contraintes temporelles que l’on peut associer à
une action peuvent avoir les formes suivantes.
5.3.1. Contraintes exprimées sur une seule action
Ces contraintes correspondent en général à :
− une période (pour des actions telles que la scrutation de capteurs),
− un instant pour démarrer la première instance d’une action périodique,
17
− un instant (cet instant peut être un temps absolu ou une occurrence d’événement) au plus tôt pour le
démarrage d’une action,
− un instant au plus tard, pour démarrer une action,
− un instant au plus tard (ou échéance absolue), pour terminer une action,
− un temps maximum d’exécution (ou échéance relative)
− un temps maximal d’attente d’une ressource,
− un temps minimal et/ou maximal d’utilisation d’une ressource,
− un temps minimum d’exécution affecté à l’action pour que celle-ci puisse produire un résultat
approximatif mais correct (ce type de contraintes est employé dans les applications où des actions sont
conçues pour fournir des résultats avec une qualité qui dépend du temps d’exécution qui leur est imparti. De
telles actions sont appelées anytime algorithms).
EXEMPLE. ⎯ Pour éviter une attente trop longue aux utilisateurs du Web, les algorithmes de recherche et
d’affichage d’images fonctionnent selon le principe des anytime algorithms : l’utilisateur reçoit une première
image esquissant les grandes lignes d’une scène, il peut alors, dès la réception de la première version de
l’image, changer de requête, ou bien attendre jusqu’à obtenir une image avec une grande précision. Plus
l’utilisateur attend, plus l’image se précise.
5.3.2. Contraintes de relations entre actions (contraintes de synchronisation)
Il s’agit d’exprimer des contraintes sur les intervalles de temps durant lesquels les actions sont exécutées.
Souvent ce type de contraintes est réduit à des contraintes de précédence. En utilisant les opérateurs d’Allen,
on peut exprimer toute une variété de contraintes (Ik désigne l’intervalle de temps d’exécution d’une action
Ak) :
− I1 Before I2 : l’action A1 doit s’exécuter avant l’action A2 ;
− I1 Meets I2 : l’une des deux actions A1 ou A2 doit commencer immédiatement quand l’autre se termine ;
− I1 During I2 : l’action A1 commence son exécution après le début de l’action A2 et se termine avant la
fin de l’action A2 ;
− I1 Starts with I2 : l’action A1 doit commencer en même temps que l’action A2 ;
− I1 Finishs with I2 : l’action A1 doit se terminer en même temps que A2 ;
− I1 Overlaps I2 : les deux actions A1 et A2 ne commencent pas et ne se terminent pas en même temps,
l’action qui commence la première se termine la première et les deux intervalles I1 et I2 ont une intersection
non nulle ;
− I1 Equal I2 : les actions A1 et A2 doivent commencer et se terminer en même temps.
18
6. Dérivation des contraintes temporelles
6.1. Objectif, principe et formes de dérivation de contraintes temporelles
En étudiant de près les différentes formes d’expression de contraintes temporelles sur les trois types
d’objets de base (actions, données et événements), on remarque beaucoup de similitudes d’expression. Etant
donné les liens étroits entre les trois types d’objets de base, nombreux sont ceux qui se posent la question
suivante : peut-on déduire (manuellement ou automatiquement) les contraintes temporelles associées à un
d’objet à partir de celles déjà imposées à un autre objet ? Cette question n’est pas une simple curiosité, car le
jour où on saura y répondre par l’affirmative, on pourra systématiser le passage d’une phase à l’autre dans le
cycle de développement d’une application temps réel et vérifier plus facilement les aspects temporels des
entités qui apparaissent au niveau de chaque phase.
Le premier niveau de dérivation est celui qui consiste à traduire les caractéristiques physiques et les
contraintes liées à la dynamique de l’environnement en termes de contraintes temporelles sur des objets
informatiques. Par exemple, à partir d’une grandeur physique, telle que la vitesse d’un moteur, on peut
déduire des périodes d’échantillonnage, des périodes des boucles de régulation, etc. Dans le cas général qui
nous intéresse ici, ce passage ne peut être systématique (c’est-à-dire, avec des règles explicites, applicables et
efficaces pour tous les domaines), car il induit beaucoup de choix de dérivation qui dépendent de multiples
facteurs tels que la méthode de conception retenue, les hypothèses initiales sur l’architecture support
(nombre de machines, systèmes d’exploitation, algorithmes d’ordonnancement, protocoles de
communication, etc.), les coûts envisagés pour l’application et l’architecture de l’application (répartition ou
non, mécanismes de redondance et de tolérance aux fautes, etc.). Même pour les exemples simples, tels que
des actions périodiques, la dérivation de contraintes temporelles pour les niveaux inférieurs est complexe.
Par exemple, une contrainte du type “ produire 100 voitures par jour ” conduit à dériver quasiment toutes les
contraintes temporelles que l’on retrouve dans une usine de fabrication de voitures. Il est donc difficile, voire
impossible, d’automatiser complètement la notion de dérivation de contraintes temporelles.
Il existe aujourd’hui beaucoup de méthodologies, de méthodes, d’outils et de langages, pour la conception
et la description d’applications temps réel. Mais, il n’existe pas de travaux proposant une démarche
systématique permettant de déduire les contraintes temporelles des objets informatiques à partir des
caractéristiques de l’environnement considéré. Quelques rares embryons de méthodes ont été proposés
seulement. Une des études les plus conséquentes est celle de Gerber et al [GER 95] qui ont proposé une
méthode de dérivation des contraintes (périodes et échéances) de tâches, à partir de contraintes sur les
données (durée de validité et contrainte de corrélation), avec comme hypothèses : architecture
monoprocesseur, des tâches périodiques, des périodes harmoniques, les tâches ayant des contraintes de
précédence doivent s’exécuter avec la même période. Une autre étude est celle proposée par Törngren [TÖR
98] pour dériver les contraintes temporelles dans les systèmes de contrôle/commande. Törngren montre, en
particulier, la dérivation des périodes d’échantillonnage à partir des périodes de boucles de régulation. Il
étudie aussi les conséquences des variations dues aux systèmes informatiques (variation des délais de
communication et des délais d’ordonnancement, dérive des horloges, etc.) sur la dérivation de contraintes
temporelles des actions composant une application temps réel et distribuée.
Avec trois types d’objets, plusieurs formes de dérivation sont possibles :
− dériver des contraintes temporelles d’une instance d’un type d’objet à partir de celles d’une instance
d’un objet d’un autre type (soit six formes de déduction)
− dériver les contraintes d’une instance d’un type d’objet à partir d’une autre instance du même type
d’objet (soit trois formes de déduction).
On construit souvent une application temps réel par raffinements successifs. En raffinant une action
composée (par exemple, une production de n pièces ou une transaction sur une base de données distribuée),
on introduit de nouvelles actions plus élémentaires (qui deviennent des tâches, au sens des exécutifs temps
réel, à la fin de la décomposition), de nouvelles données et éventuellement de nouveaux événements. Ainsi,
on est souvent amené à déduire les contraintes d’un objet appartenant à un niveau donné à partir des
19
contraintes et caractéristiques du niveau supérieur. Par conséquent, le nombre de formes de dérivations
possibles devient vite très élevé. Souvent, le processus de dérivation des contraintes temporelles des objets a
pour objectif d’aboutir, à la fin de la décomposition de l’application et des différentes dérivations de
contraintes, à des tâches temps réel et éventuellement à des messages échangés entre ces tâches dont il faut
garantir les contraintes temporelles finales en utilisant les algorithmes d’ordonnancement adéquats. Cet
objectif conduit à se focaliser sur certaines formes de dérivation et pas sur d’autres. Ainsi, les formes de
dérivations les plus répandues dans le domaine des applications temps réel sont : (1) la dérivation des
contraintes d’actions à partir de celles de données, d’événements ou d’autres actions, et (2) la
dérivation des contraintes temporelles d’actions, de données et d’événements, obtenus après
décomposition d’une action composée en actions plus élémentaires. Nous allons développer ces deux
formes de dérivation de contraintes. Il est cependant important de noter que les autres formes de dérivation
sont moins répandues, mais elles peuvent être utiles dans certains cas, par exemple dans une base de données
temporelles, la durée de validité d’une donnée, quand elle n’est pas spécifiée, peut être déduite à partir des
contraintes d’actions ou d’événements associés à la manipulation de cette donnée.
6.2. Dérivation de contraintes temporelles entre objets de même niveau
Comme on a trois types d’objets, il existe neuf formes de dérivation de contraintes temporelles entre
objets de même type ou de types différents. Nous nous limitons ici à la dérivation de contraintes temporelles
d’actions à partir de celles de données, d’événements ou d’autres actions.
6.2.1. Dérivation de contraintes temporelles d’actions à partir des données
Les actions constituant une application temps réel manipulent des données contraintes par le temps, par
conséquent les contraintes des données se répercutent directement sur les actions :
− Quand on se place dans le contexte d’actions qui ne peuvent commencer leur exécution que si toutes
leurs données en entrée sont disponibles, l’instant de production d’une donnée détermine la date au plus tôt
pour démarrer l’exécution des actions qui utilisent cette donnée.
− La durée de vie d’une donnée permet de déduire la date au plus tard d’exécution de chaque action
utilisant cette donnée.
− Une contrainte de corrélation entre données imposent à n (n>1) actions (des producteurs) de produire
leurs données dans une fenêtre temporelle de durée fixée V. On peut déduire les contraintes temporelles sur
les actions de plusieurs manières, en particulier selon les deux manières suivantes :
- Si on note t(↓(Ai)) (i=1, n) l’instant de fin d’exécution de l’action Ai, concernée par la contrainte de
corrélation, alors la contrainte suivante doit être respectée :
∀i(1≤i≤n), ∀j(1≤j≤n), i≠j ⇒⏐t(↓(Aj)) - t(↓(Ai ))⏐≤ V.
- Si la liste des données concernées par la contrainte de corrélation est utilisée de manière périodique,
alors peut décider que les n actions correspondantes soient périodiques et fixer ensuite V comme période
pour toutes les n actions. Cela conduit évidemment à un surdimensionnement du système dans certains cas.
− Une contrainte sur la production d’une donnée se traduit, soit en termes de date au plus tôt, soit en
termes de contrainte de période, pour l’action de production (voir exemple suivant).
EXEMPLE. ⎯ On considère la validité temporelle d’une variable X (par exemple, la température d’un four).
La variable X est valide (c’est-à-dire qu’elle reflète bien la température du four) si elle est échantillonnée
selon une fréquence adéquate par une action A. Il faut donc associer la bonne période, P, à l’action A qui
permet de mettre à jour la variable X. On suppose que la valeur produite par l’action A durant une exécution
n’est observable qu’à la fin de cette exécution.
20
Une première possibilité de conception de l’action A est dictée par l’existence d’un exécutif intégrant
l’algorithme d’ordonnancement Rate Monotonic. On peut alors définir une action A avec une durée
d’exécution égale à e unités de temps et une période égale à P unités de temps. Comme l’action A est
ordonnancée par Rate Monotonic, la date au plus tôt pour commencer la kème exécution de A est égale à t0 +
p*(k-1) et la date au plus tard pour terminer cette exécution est t0 + p*k. t0 étant l’instant de début de la
première exécution de l’action A. Dans ce cas, la durée maximale entre deux fins d’exécution successives de
l’action A est égale à 2*P – e unités de temps (voir figure 10a). Ainsi, deux valeurs de la variable X sont
produites à 2*P - e unités de temps d’intervalle dans le pire des cas. Cela veut dire que si on veut avoir une
durée de validité de D unités de temps, il faut choisir (D + e)/2 comme valeur pour la période P.
Une deuxième solution pour l ’action A est dictée par l’existence d’un exécutif qui permet de garantir à
une action périodique d’être activée toujours au même instant par rapport au début de sa période et sans
interruption. Dans ce cas, la période P de l’action A doit être égale à D.
2*P - e
(a)
temps
e
P
P
P
P
P
P
P
(b)
temps
P
Instant de début
d’exécution
P
P
Instant de fin d’exécution = instant de
disponibilité d’une nouvelle valeur
Figure 10. Exemple d’ordonnancement d’une action périodique
6.2.2. Dérivation de contraintes temporelles d’actions à partir d’événements
Dans les systèmes temps réel, en particulier ceux conçus selon l’approche event-diven, les actions sont
exécutées en tenant compte des occurrences d’événements. Par conséquent, les contraintes imposées sur les
occurrences d’événements se répercutent directement sur les actions. La dérivation des contraintes des
actions à partir de celles des événements dépend du type d’événements considérés (c’est-à-dire, événements
booléens ou à compte). On note :
E : un événement.
AE : ensemble des actions événementielles associées à E.
A : une action appartenant à l’ensemble AE.
P(A) : période de l’action A.
D(A) : échéance relative de l’action A.
t(↑(A, j) : date au plus tôt pour lancer la jième exécution de l’action A.
t(↓ (A, j) : date de fin d’exécution de la jième exécution de l’action A.
t(E, k) : instant de la kième occurrence de l’événement E.
δ(E) : durée de vie de l’événement E.
Imin(E) : intervalle minimum entre occurrences de l’événement E.
21
a) Dérivation de contraintes temporelles dans le cas d’événements à compte
Dans ce cas, à chaque occurrence d’un événement E correspond une exécution d’une ou plusieurs actions
événementielles. On peut déduire les contraintes temporelles des actions de la manière suivante :
− Si une action A permet la prise en compte d’un événement E, sa date au plus tôt et sa date au plus tard
sont dérivées à partir de l’instant d’occurrence de l’événement et de la durée de vie de l’événement E.
∀k≥1, ∀A∈AE ⇒ t(E, k) ≤ t(↑(A, k) ∧ D(A) = δ(E).
− Pour les applications à contraintes de temps critiques, la contrainte sur l’intervalle de temps
minimum entre occurrences d’un même événement E permet de dériver la période des actions
événementielles correspondantes.
∀A∈ AE ⇒ P(A) = Imin(E).
− Pour les applications à contraintes de temps non critiques, les intervalles de temps maximum et minimum
entre occurrences d’un même événement permettent de dériver une période moyenne qui permet, à la fois, de
prendre en compte un maximum d’occurrences d’événements et de ne pas trop surdimensionner le système.
− Si un événement E1 correspond à un stimulus et un autre événement E2 correspond à une réponse à ce
même stimulus, la contrainte temporelle sur l’intervalle de temps séparant l’occurrence de E1 de celle de E2,
permet de dériver l’échéance relative de l’action associée à l’événement E1.
b) Dérivation de contraintes temporelles dans le cas d’événements booléens
Dans ce cas, certaines occurrences d’événements peuvent être ignorées. On peut déduire les contraintes
temporelles des actions de la manière suivante :
− Si une action A permet la prise en compte d’un événement booléen E, sa date au plus tôt et sa date au
plus tard sont dérivées à partir de l’instant d’occurrence de l’événement et de la durée de vie de l’événement
E:
∀A∈AE, ⇒ t(E, 1) ≤ t(↑(A, 1) ∧ D(A) = δ(E) ∧
∀i>1, ∃ k, k>i, t(↓(A, i) ≤ t(E, k) ≤ t(↑(A, i+1).
− Le choix d’un événement de type booléen signifie que le concepteur ne s’intéresse pas aux intervalles
de temps minimum ou maximum séparant les occurrences de cet événement, mais seulement à la prise en
compte d’une seule occurrence en cas d’avalanche de l’événement. Les contraintes sur l’intervalle de temps
minimum ou maximum entre occurrences d’un événement booléen sont donc sans importance pour ce type
d’événements.
− Comme dans le cas d’événements à compte, la contrainte sur l’intervalle de temps séparant deux
occurrences (des occurrences prises en compte) de deux événements E1 et E2 (un stimulus et une réponse)
permet de dériver l’échéance relative de l’action associée à l’événement E1.
EXEMPLE. ⎯ On se place dans le cadre de la composition d’un numéro de téléphone, avec un
fonctionnement simple. On suppose que deux chiffres consécutifs doivent être espacés de 66 ms au moins et
de 10 secondes au plus, que l’abonné tape son premier chiffre 10 secondes au plus après avoir décroché et
qu’un numéro de téléphone est composé de dix chiffres. Si ces conditions ne sont pas respectées, un signal
sonore d’anomalie est renvoyé à l’abonné. Nous notons :
Cpt_Chiffres : nombre de chiffres correctement saisis.
Cpt_Attente : temps d’attente du prochain chiffre.
t(E) : instant d’occurrence de l’événement E.
E_Décrocher : événement qui permet de détecter que l’abonné a décroché.
E_Chiffre : événement qui permet de détecter qu’un chiffre a été tapé.
E_Anomalie : événement qui permet de signaler une anomalie.
E_Appel : événement qui permet d’indiquer la fin de numérotation.
22
En optant pour une spécification événementielle, on peut fixer les contraintes initiales suivantes :
(1) Temps minimal entre occurrences successives de E_Chiffre = 66 ms.
(2) Temps maximal entre occurrences successives de E_Chiffre = 10 s.
(3) Temps maximal entre occurrences de E_Décrocher et E_Chiffre = 10 s.
On suppose que l’on a choisi une action A1 qui, à chaque exécution, permet de lire un chiffre tapé et
de vider le registre qui sert d’interface entre cette action et son environnement. Si plusieurs caractères
sont tapés pendant que l’action A1 s’exécute, le résultat de la lecture devient indéterministe (un seul des
caractères tapés est lu). Avec les contraintes précédentes, on peut dériver les contraintes suivantes :
(4) L’action A1 est périodique avec une période de 66 ms.
(5) Echéance relative de A1 = 66 ms.
(6) Date de la première exécution de A1 = t(E_Décrocher).
(7) Date de suspension de A1 = Minimum(t(E_Appel), t(E_Anomalie)).
Ainsi, à chaque exécution de A1, si le registre de saisie n’est pas vide, Cpt_Chiffres est incrémenté de
un et Cpt_Attente est remis à zéro, sinon Cpt_Attente est augmenté de 66 ms. Si Cpt_Chiffres = 10, alors
signaler l’événement E_Appel. Si Cpt_Attente = 20 s, alors signaler E_Anomalie.
6.2.3. Dérivation de contraintes temporelles d’actions à partir d’autres actions
Les actions composant une application temps réel coopèrent pour la réalisation d’une même objectif
global commun. C’est la raison pour laquelle il existe souvent des contraintes de précédence entre les
actions. D’autres types de contraintes exprimées à l’aide des opérateurs d’Allen peuvent aussi apparaître
entre actions d’une application temps réel. Connaissant la contrainte de relation entre deux actions et des
contraintes temporelles d’une des deux actions, on peut dériver des contraintes temporelles de l’autre action
ou des deux actions.
EXEMPLE. ⎯ On considère deux actions périodiques A1 et A2 pour lesquelles les contraintes suivantes ont
déjà été fixées :
(1) A1 précède A2.
(2) Période de A1 = 100 ms.
(3) Chaque exécution de A1 est suivie d’une exécution de A2.
(4) Durée maximum d’exécution d’une action A = Δmax(A).
En se plaçant dans le cas où les deux actions fonctionnent selon un mode synchronisé (qui garantit à toute
action périodique de commencer son exécution à un instant fixe par rapport au début de sa période), on peut
dériver les contraintes suivantes :
(6) ↑(A2,1) ≥ ↑(A1,1) + Δmax(A1)
(5) Période de A2 = 100 ms.
(7) ∀i (i>1), A∈{A1, A2}, ↑(A,i) - ↑(A,i-1) = 100 ms. (↑(A,i) : ième exécution de A).
6.3. Dérivation de contraintes temporelles par décomposition d’actions
La structure fonctionnelle détaillée et les contraintes temporelles d’une application temps réel ne
s’obtiennent pas en général en une seule phase. Les concepteurs d’applications temps réel sont habitués aux
techniques de raffinements successifs pour élaborer les objets de base composant une application. Ce
principe permet d’appréhender la complexité des applications aussi bien dans le domaine du temps réel que
dans d’autres domaines.
A un stade de la conception d’une application apparaissent des actions qui peuvent être élémentaires et
qui ne nécessitent plus de décomposition ou des actions composées (pouvant être des sous-systèmes
complexes) et qui nécessitent une décomposition pour obtenir des actions élémentaires. La décomposition
d’une action ayant ses propres contraintes temporelles conduit à l’introduction de nouveaux objets (des
actions, des données et des événements) ayant des contraintes temporelles dérivées de celles de l’action
23
composée qui leur a donné lieu. Le nombre d’objets introduits par la décomposition d’une action composée
dépend des choix du concepteur. Par conséquent, une dérivation automatique des contraintes temporelles est
loin d’être évidente. A notre avis, le raisonnement pour l’obtention des contraintes temporelles des objets
d’un niveau à partir de celles des objets de niveau supérieur ne peut se faire qu’au cas par cas en prenant en
compte des facteurs directement liés au niveau auquel on se trouve. A titre d’exemple, nous montrons
comment on peut déduire les contraintes temporelles des actions de communication et l’échéance relative de
messages à partir d’une contrainte spécifiée dans une opération d’envoi d’une variable par un producteur
vers un consommateur.
EXEMPLE. ⎯ On se place dans le cadre du modèle producteur-consommateur avec un producteur et un
consommateur interconnectés via un réseau de communication avec trois couches seulement (couche
application, couche MAC et couche physique). Les entités producteur et consommateur utilisent les services
de leur couche application pour communiquer. Le producteur produit une variable Y dont la durée de validité
est Δt et appelle un service pour transmettre la donnée au consommateur.
Si on analyse le déroulement de la communication entre le producteur et le consommateur, on peut identifier
les événements et les actions suivants :
− Evénement E1 : instant de soumission d’un message M contenant une valeur de la variable Y, par le
producteur, à la couche application du producteur.
− Action A1 : Traitement du message M par la couche application du producteur et passage de ce message
à la couche MAC.
− Action A2 : Traitement et attente du message M au niveau de la couche MAC du producteur,
− Action A3 : Transmission et propagation du message M sur le médium.
− Action A4 : Réception et traitement du message M par la couche MAC du consommateur, puis passage
de ce message à la couche application.
− Action A5 : Traitement du message M par la couche application du consommateur, puis passage de ce
message au consommateur.
− Evénement E2 : instant d’arrivée du message M chez le consommateur.
La contrainte temporelle initiale peut s’exprimer sur la variable Y par “ durée de validité = Δt ”. Cette
contrainte permet de déduire de manière triviale la contrainte sur les événements E1 et E2 qui peut s’exprimer
par “ E2 au plus tard Δt après E1 ”, puis les contraintes sur les actions A1 à A5 de la manière suivante :
− tout d’abord il existe une relation de précédence entre toutes les actions. Si on note
↑(Ai)(respectivement ↓(Ai)) l’événement indiquant le début (resp. la fin) de l’action Ai, alors on a la
contrainte : " ↑(Ai+1) Après ↓(Ai)(i=1, ...,4) ".
− Si on note Δt_max(Ai) la durée maximale d’exécution de l’action i, on a alors la contrainte suivante :
" Δt ≥ ∑ i = 5 Δt _ max( Ai ) ". Pour pouvoir respecter cette contrainte, on doit déterminer la durée Δt_max(Ai) de
i =1
chaque action. Il faut noter qu’un tel calcul dépend de beaucoup de facteurs (systèmes d’exploitation,
vitesses des processeurs, protocoles au niveau application et MAC, etc.). On peut faire ce calcul de plusieurs
manières selon les caractéristiques du système considéré et selon les hypothèses que l’on se fixe. A titre
d’exemple, on peut raisonner de la manière suivante :
- On suppose que l’on connaît les machines cibles sur lesquelles sont placées les entités producteur et
consommateur (on connaît en particulier, les vitesses des processeurs, les systèmes d’exploitation et les
protocoles de communication). On peut alors, plus ou moins difficilement selon les cas, fixer les durées
maximales des actions A1 et A5. La durée maximale de l’action A4 peut être calculée facilement si on fait
l’hypothèse que le niveau MAC passe immédiatement toute trame reçue au niveau application.
24
- On suppose que le réseau est connu. Pour un réseau avec un débit et une longueur fixés, on peut
connaître la durée maximale de l’action A3 (cette durée correspond du délai maximum de transmission et de
propagation du message contenant la variable Y).
- Après avoir calculé les durées maximales des actions A1, A3, A4 et A5, il reste à calculer la durée
maximale associée à l’action A2. Ainsi, on peut dériver l’échéance relative du message M au niveau MAC,
Dmac.
Dmac = Δt - (Δt_max(A1) + Δt_max(A4) + Δt_max(A5)).
On dérive ainsi la contrainte temporelle à imposer au réseau à partir de la durée de validité de la variable
Y et de certaines hypothèses sur les machines cibles.
25
7. Techniques de spécification des systèmes temps réel
Dans les sections précédentes, nous avons présenté les contraintes temporelles en insistant sur leurs
origines et la manière de les déduire à partir des objets constituant une application temps réel. Une fois les
contraintes de temps élaborées, ces contraintes doivent être clairement spécifiées et respectées au moment de
l’exécution. Dans cette section, nous abordons les principales techniques de spécification des applications
temps réel. Il faut signaler qu’un aspect important à prendre en compte lors de la conception et la mise en
œuvre d’applications temps réel est la sûreté de fonctionnement, en particulier, la spécification du
comportement d’une application face aux fautes temporelles des tâches ou des messages.
Deux approches sont habituellement utilisées pour classer les techniques de spécification. La première se
base sur le degré de formalisme utilisé par les techniques, la seconde sur les possibilités offertes en termes de
capacité de description et de mécanismes opérationnels. Les techniques opérationnelles sont celles définies
en termes d’états et de transitions, elles sont proches de l’exécution. Les techniques descriptives sont
généralement fondées sur des notations mathématiques permettant de fournir des spécifications rigoureuses
qui peuvent être automatiquement traitées pour vérifier des propriétés telles que la sûreté (c’est-à-dire,
absence d’interblocage, d’erreur, etc.) et la vivacité (c’est-à-dire, terminaison des actions, occurrence des
événements attendus, etc.).
L’évaluation d’une technique prend en compte trois aspects : l’aspect structurel (qui concerne la
décomposition d’un système en sous-systèmes), l’aspect fonctionnel (qui concerne les activités de
transformation des données) et l’aspect comportemental (qui concerne les réactions du système aux stimuli
externes et aux événements internes, c’est-à-dire ce qui concerne les aspects temporels). Selon les
techniques, les contraintes de temps peuvent s’exprimer de manière explicite ou implicite.
7.1. Techniques descriptives
Ces techniques sont souvent fondées sur un formalisme mathématique et produisent des spécifications
précises, rigoureuses et donnent une vue abstraite du système. Le système est décrit par des propriétés,
forçant le spécifieur à exprimer ce que le système doit faire plutôt que de dire comment le système va le
faire. Les spécifications formelles peuvent être traitées automatiquement pour en vérifier la complétude et la
cohérence. Cette vérification fait appel à des prouveurs de théorèmes. Il faut noter que ces techniques sont
peu utilisées dans le domaine du temps réel, comparées aux techniques opérationnelles, à cause, à la fois, du
manque d’outils d’utilisation et des difficultés de spécifier formellement des systèmes complexes que sont
les systèmes temps réel. Plusieurs classifications des techniques descriptives ont été proposées, en voici une :
− Techniques descriptives fondées sur les méthodes algébriques : il s’agit de méthodes basées sur les
types abstraits. Avec ces techniques, un système est décrit avec différents niveaux d’abstraction allant du
plus simple au plus compliqué. Un système est vu comme un type abstrait et sa spécification consiste à
décrire sa syntaxe (décrivant les domaines des opérateurs du type) et sa sémantique (décrite par des
expressions mathématiques). La complétude d’une spécification peut être vérifiée si les propriétés attendues
sont vérifiées par les axiomes. Une des techniques descriptives qui commence à émerger, pour la
spécification de systèmes temps réel, est LOTOS et, plus exactement ses extensions telles que RT-LOTOS et
ET-LOTOS.
− Techniques descriptives fondées sur les logiques mathématiques : ces techniques permettent de décrire
le comportement d’un système à l’aide de règles qui spécifient comment le système peut évoluer. Pour
prendre en compte les aspects temporels, il est fait appel aux logiques temporelles. Plusieurs techniques se
plaçant dans cette catégorie ont été proposées depuis de nombreuses années : RTL (Real-Time Logic), CTL
(Computational Tree Logic), RTIL (Real-Time Interval Logic), TCTL (Timed CTL ), TPTL (Timed
Propositional Temporal Logic).
26
7.2. Techniques opérationnelles
Les techniques opérationnelles se divisent en deux catégories : les techniques fondées sur les modèles à
transitions (machines d’états et réseaux de Pétri) et les techniques fondées sur des notations abstraites.
Les machines d’états finis (MEF) permettent de vérifier des propriétés telles que l’atteignabilité des états.
Il faut noter qu’avec les MEF, le nombre d’états croit avec la complexité du problème traité et la vérification
de propriétés devient complexe aussi. Pour être adaptées aux systèmes temps réel, les MEF doivent fournir
des possibilités d’expression des contraintes de temps (échéances, périodes, etc.). C’est la raison pour
laquelle beaucoup d’extensions de MEF ont été proposées. Par ailleurs, pour appréhender la complexité des
systèmes, une MEF peut être décomposée en plusieurs MEF communicantes. Des langages fondés sur les
MEF, comme PAISLey (Process-oriented Applicative and Interpretable Specification Language), SDL
(Specification and Description Language), Esterel et Statecharts, sont utilisés pour la spécification de
systèmes temps réel.
En ce qui concerne les techniques opérationnelles fondées sur les réseaux de Pétri (RdP), plusieurs
extensions des RdP de base ont été proposées pour prendre en compte des contraintes temporelles. Il s’agit
notamment :
− des RdP temporisés dans lesquels on introduit une durée minimale pendant laquelle une transition doit
rester autorisée pour être tirée et une durée maximale qui indique la durée pendant laquelle une transition
peut rester autorisée avant être tirée,
− des RdP stochastiques dans lesquels une variable aléatoire est associée à chaque transition pour
représenter le délai de tir de la transition,
− d’autres techniques fondées sur les RdP telles que les machines HMS (Hierarchical Multi-State
machines).
Les techniques opérationnelles fondées sur les modèles à transitions ont l’avantage de conduire à des
spécifications exécutables et sur lesquelles on peut prouver certaines propriétés. Des vérifications de
propriétés (telle que l’absence d’interblocage) sont possibles avec les RdP.
Les techniques basées sur des notations abstraites sont adaptées à l’analyse et la conception de systèmes,
par décomposition du système en sous-systèmes. Elles sont souvent destinées à fournir une représentation
visuelle du système pour réduire en quelque sorte l’effort du spécifieur. En général, elles ne modélisent pas
l’aspect comportemental des systèmes et par conséquent elles ne sont pas directement utilisables pour une
simulation ou une exécution du système. Par ailleurs, elles sont souvent informelles ou semi-formelles. Ces
techniques incluent des extensions des méthode SADT (telles que DARTS – Design Approach for Real-Time
Systems) – et SDRTS – Structured Design for Real-time Systems) ou HOOD (telles que HRT-HOOD – Hard
Real-Time HOOD) largement utilisées dans la spécification d’applications non temps réel.
7.3. Techniques mixtes
Un outil idéal pour la spécification de systèmes temps réel devrait avoir les propriétés suivantes :
− il doit être facile à comprendre et à manipuler (une interface graphique est souvent souhaitée pour
construire une spécification),
− il doit permettre la réutilisation de spécification déjà existantes,
− il doit permettre de vérifier formellement et de valider une spécification à tous les niveaux du cycle de
vie d’un système,
− la spécification obtenue doit permettre des validations à l’aide de simulation.
Ces propriétés sont parfois en contradiction les unes avec les autres et ne peuvent être respectées par une
approche qui est soit opérationnelle, soit descriptive. C’est la raison pour laquelle certains travaux proposent
27
des techniques mixtes respectant le plus possible des quatre propriétés précédentes. Il faut noter cependant
que la politique d’extension des outils et méthodes tend à essayer d’intégrer tout dans toutes les techniques,
ce qui conduit inéluctablement à des techniques complexes et difficiles à appréhender et à mettre en œuvre.
Comme exemple de technique mixte, nous pouvons citer ESM/RTTL qui est une approche intégrant les
machines d’états (Extended State Machines) et la logique temporelle RTTL.
Il faut souligner qu’une technique de spécification n’est réellement utile pour un spécifieur que
lorsqu’elle est accompagnée d’outils permettant de décrire, vérifier, simuler des comportements, de générer
des implantations, etc. Au niveau commercial, peu d’outils existent pour appréhender les contraintes
temporelles. Depuis une date récente, la presse spécialisée présente de plus en plus de produits pour le temps
réel, allant des processeurs, jusqu’aux ateliers logiciels. Rares sont les études comparatives qui permettent
de situer les différentes propositions les unes par rapport aux autres. Le marché n’est qu’à ses débuts.
Bibliographie
[ALL 83] ALLEN J.F., “ Maintaining knowledge about temporal intervals ”, Comm. of ACM, vol. 26, n° 11, p. 832-843, 1983.
[DAS 85] DASARATHY B., “ Timing constraints of real-time systems: constructs for expressing them, methods for validating them ”,
IEEE T.S.E., 17:34-44, 1985.
[GER 95] GERBER R., HONG S., and SAKSENA M., “ Guaranteeing real-time requirements with resource-based calibration of periodic
processes ”, IEEE T.S.E., vol. 21, n° 7, p. 579-592, 1995.
[LAM 78] LAMPORT L., “ Time, clocks and ordering of events in distributed systems ”, Communication of ACM, vol. 21, n° 7, 1978,
p. 558-565.
[LAP 92] LAPRIE J.-C., Dependability: basic concepts and terminology, Springer Verlag Editions, 1992.
[RAM 96] RAMAMRITHAM, K. “ Where do time constraints come from and where do they
Management, vol. 7, n° 2, p. 4-10, 1996.
go ? ”, Journal of Database
[STA 88] STANKOVIC J.A., and RAMAMRITHANM K., “ Hard real-time systems: A tutorial ”, IEEE Computer Society Press, 1988.
[TAY 80] TAYLOR B., “ Introducing real-time constraints into requirements and high level design of operating systems ”, Proceed.
of Nat. Telecommunications Conference, Houston, TX, vol. 1, p. 18.5.1-18.5.5, 1980.
[TÖR 98] TÖRNGREN M., “ Fundamentals of implementing real-time control applications in distributed computer systems ”, Journal
of Real-Time Systems, 14, 219-250, 1998.
28

Systèmes temps réel et embarqués

Transcription

Documents pareils

Prix international Dan David

Tables Statistiques usuelle

Emploi d`un tableur dans un cours d`analyse de séries temporelles

Ingenierie De La Formation Iut Univ lille2 Fr

Architectures Logicielles et Matérielles Software and hardware

technicalreport 0446 une experience de tele

Etude de la stationnarité des séries temporelles

Modélisation de séries temporelles multiples et

Introduction aux systèmes temps réel