Zhao [94] parvient à construire un modèle d'exécution temps-réel en s'appuyant sur deux éléments fondamentaux : une synchronisation temps-réel localisée en certains points de l'application et un relâchement des contraintes temporelles le long des chemins de données. Le modèle d'exécution qu'il propose nécessite une analyse topologique des relations temporelles reliant les tâches de l'application. Cette analyse permet de choisir localement l'ordre d'exécution des évènements au sein de chaque processus logique de la distribution.
De façon un peu simplifiée, les choses se formalisent ainsi :
Une application est définie par un ensemble de composants/tâches, munis de ports d'entrées/sorties, et interconnectés entre eux par des signaux. Chaque signal
L'ordonnancement évènementiel temps-réel - 33 transfère les évènements issus d'un port de sortie vers un ou plusieurs ports d'entrées. L'application est distribuée sur plusieurs processus logiques.
La figure 13 donne un exemple d'application comportant 6 composants notés A, B,
C, D, E et F distribués sur deux processus logiques notés LP1 et LP2. Chaque
composant héberge une tâche.
Figure 13. Une application de 6 composants distribués sur deux processus logiques.
Un composant est caractérisé par un délai purement virtuel, éventuellement nul, correspondant au temps minimum qu'il faut à l'information pour le traverser. Ce temps ne correspond à aucune réalité physique. Il a pour rôle de relâcher les contraintes temporelles de l'application en donnant à chaque tâche le temps dont elle a besoin pour être traitée. Par exemple, le composant B de l'application de la figure 13 est caractérisé par un délai δB ; si l'évènement e2 = (v2, t2) est délivré sur
le port p2 et produit, après traitement par le composant B, l'évènement e3 = (v3, t3)
sur le port p3, alors les dates respectives de e2 et e3 sont nécessairement telles que
t3 ≥ t2+δB. Ces délais caractéristiques permettent d'établir la « longueur » du
chemin reliant deux ports situés sur un même processus logique, en fonction des composants traversés. Par exemple, le chemin reliant le port p1 au port p10 a pour
longueur : d1,10 = δB+δE = δB. Grosso modo, cette longueur correspond au délai
dont dispose le système pour exécuter toutes les tâches situées sur le chemin considéré et absorber les latences réseaux.
Cette mesure de longueur permet de construire une relation d'ordre partielle entre les évènements du système. Cette relation d'ordre traduit le fait qu'un évènement situé sur un port de l'application peut être traité dès lors que les chemins de données reliés à ce port n'apporteront plus d'évènement plus ancien. Formellement, soit ei = (vi, ti) e t ej = (vj, tj) deux évènements associés
respectivement aux ports pi et pj. Alors ei < ej si et seulement si ti+di,j < tj. A un
instant donné, les évènements non encore traités par le processus logique sont classés dans une liste du plus « petit » au plus « grand ». Le processus traite alors les évènements en commençant par les plus « petits » de la liste.
34 - Chapitre 1
La latence de communication entre processus logiques est modélisée par un type de port d'entrée particulier dit « port réseaux » auquel est associé un délai. Ce délai majore le retard avec lequel les évènements sont délivrés, par rapport à la date qui leur est associée. Par exemple, la latence de communication entre les processus LP1 et LP2 de la figure 13 est modélisée par le port réseau p5. Celui-ci
est caractérisé par le délai de délivrance Δ5 qui garantit que tout évènement
e5 = (v5, t5) destiné à ce port sera délivré avant que l'horloge murale n'indique la
date t5+Δ5.
Afin de garantir la causalité du traitement des évènements, chaque processus logique doit s'assurer que l'évènement qu'il traite ne pourra être remis en cause par un évènement associé à un port réseau. Prenons le cas concret d'un évènement
e5 = (v5, t5) associé au port p5 de la figure 13. Cet évènement ne pourra être traité
par le processus logique LP2 que si l'horloge murale a dépassé la date T = t5 + Δ5.
De même, un évènement e9 = (v9, t9) associé au port p9 ne pourra être traité que si
l'horloge murale a dépassé la date T = t9 – d5,9 + Δ5. On s'assure ainsi que, compte
tenu de la latence réseau, le port p5 ne délivra pas d'évènement susceptible de
remettre en cause le traitement de l'évènement e9. Si tel n'est pas le cas, le
processus LP2 s'interrompt en attendant que les conditions temporelles de
traitement de e9 soient remplies.
Les capteurs et actionneurs sont modélisés par des composants disposant de port d'entrées/sorties dits « temps-réel ». De tels ports établissent une relation temporelle entre la date des évènements qu'ils traitent et l'horloge murale. C'est par leur intermédiaire que l'application se synchronise en temps-réel. Par exemple, le composant F représente un actionneur et dispose d'un port temps-réel d'entrée nommé p10. Si e10 = (v10, t10) est un évènement traité par le port p10 alors cet
évènement doit être délivré avant que l'horloge murale n'atteigne la date t10. De
cette manière, l'action engendrée sur l'actionneur pourra être effectuée à temps. De façon plus globale, l'application est ordonnançable à condition que la contrainte temporelle associée à chaque port temps-réel soit respectée.
Le cadre élaboré par Zhao conduit à un ordonnancement temps-réel évènementiel parfaitement reproductible puisqu'il est basé sur les relations causales entre les évènements. De ce point de vue, il est pleinement satisfaisant. Cependant, il nécessite une analyse statique de la topologie de l'application extrêmement poussée. Notre cadre de travail nous interdit cette analyse. Contrairement à Zhao, il nous faut donc nous orienter vers les protocoles optimistes qui sont capables de produire un ordonnancement causal en toute circonstance. Reste à évaluer leur capacités exactes du point de vue des contraintes temps-réel.