Chapitre 1 Définitions et problématique du temps-réel

1.1 Différentes définitions du temps-réel

La notion de ``temps-réel'' suggère bien évidemment celle de temps. L'acception du concept de temps est très large, mais nous nous concentrons dans ce travail sur la définition du temps en tant que donnée physique mesurable. Intuitivement, les systèmes informatiques ``temps-réel'' seraient donc ceux pour lesquels le comportement temporel, non seulement en terme de séquence d'opérations (propriété logique), mais également en terme de quantification de l'écoulement de ces opérations (propriété physique), a une importance.

Temps-réel et temps logique

Selon la définition officielle du temps-réel par la délégation générale à la langue française et aux langues de France¹ [4], le temps-réel est un ``mode de traitement qui permet l'admission des données à un instant quelconque et l'obtention immédiate des résultats''. Cette définition repose principalement sur l'adjectif ``immédiat''. Elle introduit la notion de temps logique, et s'applique aux systèmes où on s'intéresse aux successions logiques d'événements et de décisions (domaine des systèmes réactifs qui reposent sur l'hypothèse de synchronisme fort) [Hal98, Bon92], mais ne convient pas aux problèmes où on s'intéresse aux propriétés quantitatives de l'écoulement des traitements qui ont un coût temporel non nul.

Temps-réel et temps physique

D'autres définitions existent qui relativisent l'adjectif ``immédiat'' de la précédente, et confèrent une existence physique au temps, dont celle-ci (canadienne) : ``mode de traitement des données selon lequel le traitement s'effectue avec un léger décalage [temporel]'' [3]. Mais sans précision sur l'adjectif ``léger'', l'idée qu'on se fait de tels systèmes ``temps-réel'' est qu'ils sont ``rapides'', c'est à dire que le ``décalage'' est le plus petit possible (on parle aussi de systèmes interactifs). Cette définition n'est pas un grand progrès par rapport à la problématique de la conception de systèmes informatiques classiques, puisqu'un grand pan de l'effort en développement informatique consiste à faire les bons choix algorithmiques afin d'obtenir des temps moyens d'exécution convenables, voire minimaux.

Notion de contrainte de temps

D'autres définitions précisent la précédente en donnant une valeur numérique à l'adjectif ``léger'' (typiquement : 0,5 secondes dans la définition de ``temps-réel dur'' de [3]). Ces définitions introduisent la notion de contrainte temporelle. Cependant, ce relatif progrès en précision se révèle n'être d'aucune utilité : pour certaines applications (contrôle d'un avion par exemple), un ``décalage'' de 0,5 secondes peut être synonyme de catastrophe, et pour d'autres applications il peut se révéler totalement inadapté ou impertinent (contrôle de le température d'une pièce par exemple). Il en découle que les contraintes temporelles sont dépendantes de l'application considérée.

Définition du temps-réel adoptée et problématique

Dans le présent travail, nous reposons sur la définition de temps-réel suivante, largement adoptée dans le domaine [Sta88] : ``la correction du système ne dépend pas seulement des résultats logiques des traitements, mais dépend en plus de la date à laquelle ces résultats sont produits''. Cette définition implique que les contraintes temporelles à respecter (par exemples les échéances des traitements) sont relatives à un temps physique mesurable, et font partie de la spécification du système à implanter. En outre, elle signifie que la seule rapidité moyenne d'exécution du logiciel ne conditionne pas la validité du système. Elle suggère que dans tous les cas, même les pires, toutes les contraintes temporelles doivent être respectées, sans quoi le système est défaillant.

Dans ce contexte, la problématique qui nous intéresse est celle de la conception et de la validation de systèmes informatiques qui sont soumis à des contraintes temporelles en plus des contraintes de correction fonctionnelles usuelles. Parmi les contraintes temporelles courantes, citons par exemple les échéances temporelles strictes des traitements, ou la gigue de démarrage des traitement ; nous reviendrons sur ces notions en 2.1.1.2.

1.2 Classification sommaire des systèmes informatiques temps-réel

L'utilisation de l'outil informatique apparaît de plus en plus fréquemment dans les domaines où l'interaction avec l'environnement constitue une raison d'être essentielle du système. L'intérêt de recourir à l'informatique dans ce genre de système est dû au fait que les fonctionnalités offertes le sont à coût moindre (à fonctionnalités équivalentes), en terme de temps de développement, de temps et de coûts de fabrication, d'encombrement ou de poids, par rapport aux solutions électroniques ou mécaniques. En outre, l'ajout de nouvelles fonctionnalités, la constitution de mises à jour, ou la personnalisation du produit se révèlent souvent être des tâches moins lourdes.

Temps-réel critique

On trouve aujourd'hui des gros systèmes informatiques temps-réel dans les domaines de l'aéronautique, de l'aérospatiale, des transports ferroviaires, du contrôle de procédés industriels, de supervision de centrales nucléaires, voire de gestion de salles de marchés ou de télémédecine. On trouve aussi de beaucoup plus petits systèmes embarqués dans l'automobile (système de contrôle des freins, du moteur) par exemple. Pour ces exemples, une des caractéristiques est que le système informatique se voit confier une grande responsabilité en terme de vies humaines, de conséquences sur l'environnement, voire de conséquences économiques. On parle alors de systèmes critiques, qui sont alors soumis à des contraintes de fiabilité. Cette caractéristique amène les problématiques orthogonales de sûreté de fonctionnement et de tolérance aux fautes [CP99b, CP99a] que nous ne détaillerons pas dans ce travail.

Temps-réel strict et temps-réel souple

La majorité des systèmes temps-réel critiques est exclusivement constituée de traitements qui ont des contraintes temporelles strictes : on parle de systèmes temps-réel strict. C'est à dire qu'en condition nominale de fonctionnement du système, tous les traitements du système doivent impérativement respecter toutes leurs contraintes temporelles ; on parle alors de traitements temps-réel strict ou dur (hard en anglais). Ceci suppose deux choses : i) qu'on est capable de définir les conditions de fonctionnement nominales en terme d'hypothèses sur l'environnement avec lequel le système interagit ; ii) qu'on est capable de garantir avant exécution que tous les scénarios d'exécution possibles dans ces conditions respecteront leurs contraintes temporelles. Ceci suppose à son tour qu'on puisse extraire ou disposer de suffisamment d'informations sur le système pour déterminer tous les scénarios possibles.

Une autre classe de systèmes est moins exigeante quant au respect absolu de toutes les contraintes temporelles. Les systèmes de cette classe, dits temps-réel souple (soft en anglais), peuvent souffrir un taux ``acceptable'' de fautes temporelles (non respect transitoire des contraintes) de la part d'une partie des traitements (eux-mêmes dits ``temps-réel souple''), et sans que cela ait des conséquences catastrophiques. Cette classe comprend entre autres les systèmes où la qualité est appréciée par nos sens : on parle dans ce cas de systèmes et d'applications multimédia (téléphonie, vidéo, rendu visuel interactif par exemple). La mesure du respect des contraintes temporelles prend la forme d'une donnée probabiliste : la qualité de service relative à un service particulier (nombre d'images ou nombre d'échantillons sonores rendus par secondes, par exemple), ou relative au comportement du système dans son ensemble (nombre de traitements qui ont pu être rendus dans les temps, tous services confondus, par exemple), ou les deux combinés. Une problématique de cette classe de systèmes est d'évaluer la qualité de service, avant ou pendant le fonctionnement, que le système offre ou va pouvoir offrir en cours de fonctionnement, en fonction des caractéristiques de l'environnement et du système. On distingue une sous-famille dans celle des traitements temps-réel souple, suivant que le non-respect d'une contrainte temporelle continue d'apporter quelque chose au système, ou non : si le traitement dépasse une contrainte temporelle, et si le continuer dans ces conditions jusqu'à son terme n'apporte rien au système, on parle de traitement temps-réel ferme (firm en anglais).

Il est également possible d'avoir des systèmes temps-réel strict non critiques, ou des systèmes temps-réel critiques qui contiennent des traitements temps-réel souple. Nous nous intéressons dans tout ce qui suit aux systèmes qui possèdent une composante temps-réel strict.

1: Ministère de la Culture, arrêté du 22/12/1981.