Les systèmes temps réel

Difficile d'ouvrir un magazine d'informatique ou de technologie ou encore d'écouter une conversation entre ingénieurs ou techniciens, sans entendre l'expression "temps réel" ! Même les journalistes s'y mettent, qui affichent les sondages et autres informations en "temps réel". Dans les entreprises qu'il m'arrive de fréquenter, j'entends parler de données "temps réel", de bases de données "temps réel" et même d'images "temps réel", sans parler des entrepôts de données "temps réel" sur lesquel on fait du "big data" !

Pourquoi une telle inflation de cette expression "temps réel", qui n'en demandait pas tant ! La langue française serait-elle si pauvre qu'il n'existerait pas de termes plus appropriés pour désigner toutes ces choses ? Dans quels cas l'expression est-elle correcte, dans quels cas est-ce un abus de langage ? Et plus généralement, qu'est-ce qu'un système "temps réel" ?

Essayons de proposer quelques éléments de réflexion sur ce qu'est réellement un système "temps réel" et sur l'usage de l'expression "temps réel".

Les différentes définitions du "temps réel"

La notion de temps

L'expression "temps réel" est apparue aux débuts des années 1950 chez les informaticiens scientifiques et militaires. Il ne s'agissait pas de l'expression "temps réel" mais de son équivalent anglais "real-time". Aussi, il m'a paru nécessaire de chercher sa définition anglaise, dans le Collins : "denoting or relating to a data-processing system in which a computer receives constantly changing data, such as information relating to air-traffic control, travel booking systems, etc, and processes it sufficiently rapidly to be able to control the source of the data". On trouve aussi la définition suivante pour "in real time : at once, instantaneously".

Dans le dictionnaire de la délégation Générale à la Langue Française, le terme "temps réel" est défini par : "Mode de traitement qui permet l'admission des données à un instant quelconque et l'obtention immédiate des résultats."

Ces définitions doivent interpeller notre culture physicienne : que signifie "sufficiently rapidly" ou encore "instantaneously" ? Comment quantifier un délai "suffisamment rapide" , "immédiat" ou pire l'instantanéité, alors que la physique nous apprend qu'elle n'existe pas....

Lorsqu'on parle de "temps" dans l'expression "temps réel", parle-t-on du temps physique et donc par définition du temps local de l'observateur ? Ou bien du temps logique, rythmé par la cadence d'horloge de l'ordinateur, un temps discret par définition, instable (il a la stabilité du quartz qui le génère) et fini ? Evidemment, il s'agit de la seconde hypothèse. Et cela borne en les minorant la notion de "suffisamment rapide" et d'"immédiat". Le délai de temps le plus petit mesurable est le pas temporel de l'horloge de l'ordinateur, variable entre quelques nanosecondes et quelques microsecondes selon les machines.

Et que dire du mot "réel" ? Existerait-il en informatique un temps imaginaire ? Quelle est la réalité du temps ? En physique comme en informatique, nous mesurons des durées, c'est à dire des intervalles de temps et dans un ordinateur, chaque intervalle est un multiple du pas temporel d'horloge de l'ordinateur. En physique, nous ne savons pas si notre temps est discret, ni même ce qu'est réellement le temps.

En bref, la notion de "temps" en informatique n'a pas grand chose à voir avec le temps des physiciens ... Mais l'avantage, c'est qu'on peut le quantifier rigoureusement car il possède une origine (la mise sous tension de l'ordinateur) et une unité fondamentale, le pas d'horloge de l'ordinateur.

L'expression "temps réel" désigne finalement le plus souvent une image du monde réel, ou du moins d'une de ses parties, à un instant donné.

Les systèmes "temps réel"

Dans un système "temps réel" ou système TR, ce qui importe ce n'est pas tant qu'il réponde "immédiatement" ou "suffisamment rapidement" à une information, le même selon qu'il s'agisse de piloter un missile à 3 Mach ou une voiture à 100 km/h. Mais par contre, il est essentiel que le traitement de l'information soit fait dans le délai imparti. Imaginez que le régulateur de vitesse de votre voiture, qui est un système TR, réagisse en une milliseconde ou une seconde au grès de la température ou de la pression atmosphérique !

Un système TR est un système qui réagit, dans un temps spécifié, aux informations provenant de son environnement. Le délai que le concepteur lui accorde pour réagir déterminera la classe de systèmes TR à laquelle il appartient. La définition que le CNRS donne à un système TR et qui habituellement utilisée chez les informaticiens scientifiques et militaires est : "le comportement d'un système informatique est qualifié de "temps réel" lorsqu'il est assujetti à l'évolution d'un procédé qui lui est connecté et qu'il doit piloter ou suivre en réagissant à tous ses changements d'états" (CNRS - Le temps-réel. TSI - Technique et Science Informatique. 1988 vol 7 p 493-500)

J'insiste sur le fait qu'un système TR qui produirait un résultat de calcul logiquement correct mais en dehors du délai accordé pour exécuter ce calcul serait un système défaillant. Cette condition a des répercussions importantes sur la conception et la validation des systèmes TR.

Autre caractéristique essentielle d'un système TR : il doit être déterministe. En l'espèce, cela signifie qu'il doit être possible lors de la conception du système de prévoir avec certitude son comportement temporel en fonction des contraintes de charges et environnementales. En fait, cette caractéristique découle de l'impératif de garantir le respect des dates d'échéance de traitement. Cette caractéristique implique des contraintes fortes sur les architectures matérielles des systèmes TR.

Enfin, levons une croyance souvent partagée par les non-spécialistes : un système TR n'est pas obligatoirement un système rapide ! C'est le respect des contraintes temporelles qui qualifie un système TR, pas sa rapidité de traitement. Mais bien sur, si les contraintes temporelles sont élevèes, une puissance et une rapidité de traitement seront indispensables.

Classification des systèmes "temps réel"

On distingue deux grandes classes de systèmes TR: le temps réel "dur" et le temps réel "mou". La différence ne tient pas tant dans la valeur du délai de réaction spécifié que dans le respect de ce délai.

Considérons une tâche d'acquisition Ai, périodique de période Ti. Soit Si le début de la tâche Ai et Di la date d'échéance de Ai, c'est à dire la date à laquelle les résultats doivent être disponibles. Le délai de réaction du système spécifié sera donc Di - Si, avec évidemment Di-Si < Ti. Soit Ci la durée du traitement.

Le temps réel "dur"

Un système TR sera dit "dur" lorsque la totalité du traitement sera achevé avant Di, c'est à dire strictement inclus dans l'intervalle [Si, Di]. Si le traitement s'achève après Di, le système sera en défaut. L'essentiel est de respecter l'échéance de mise à disposition des résultats.

On trouve les systèmes TR durs dans tous les systèmes embarqués destinés au pilotage, dans les systèmes de mesures des machines de physique de particules, dans les robots de chirurgie et autres systèmes critiques.

Ces systèmes doivent être parfaitement déterministes afin de garantir le temps de calcul. Cela exclut l'usage de réseaux non déterministes comme Ethernet, mais aussi les mémoires caches et les processeurs parallèles. Les systèmes d'exploitation des ordinateurs doivent garantir un ordonnancement des tâches compatibles avec ces exigences. Ce sont les OS "temps réel", par exemple VxWorks, VRTX, LynxOS, qui sont normalisés Posix temps réel P1003.4, ou plus vieux RTE ou RTX-11.

Le temps réel "mou"

Un système TR sera dit "mou" lorsque il est toléré que le traitement débute dans l'intervalle [Si, Di] mais s'achève après Di mais avant Ti. Si le traitement s'achève après Ti, le système sera en défaut. Le dépassement de l'échéance Di ne doit pas être systématique, les tolérances étant spécifiées lors de la conception du système.

Les systèmes de supervision et une bonne partie des systèmes de contrôle/commande (SCADA) sont des systèmes temps réel mous, avec des tolérances de dépassement de l'échéance Di plus ou moins sévères selon le procédé sous contrôle.

En temps réel mou, on peut utiliser sous condition des OS non temps réel comme Unix, Linux (y compris RT-Linux qui n'est pas vraiment temps réel) ou Windows.

La conception des systèmes temps réel

Spécification et conception des systèmes temps réels

Rappelons que spécifier un système, c'est établir les exigences fonctionnelles et non fonctionnelles applicables au système. Rappelons aussi qu'une exigence doit pourvoir être testée pour en vérifier la conformité aux caractéristiques attendues et que cette conformité doit être indépendante de l'implémentation qui est faite de l'exigence.

Sur le plan fonctionnel, les phases de spécification et de conception ne différent pas sensiblement entre les systèmes TR et les autres. Mais dans les spécifications des systèmes TR, la composante temporelle est essentielle.

Elle est essentielle sur deux plans :

Il ne s'agit pas simplement d'émettre des exigences de performances comme "le système doit acquérir 1000 mesures de tension par seconde", mais de préciser dans quelles conditions temporelles d'acquisition et de traitement cette fonction doit fonctionner. En cela, les spécifications et la conception d'un système TR différent très sensiblement avec les spécifications d'un système transformationnel ou interactif et nécessitent des outils particuliers.

Ces difficultés se répercutent sur les moyens de test et de validation des systèmes TR, qui demandent des procédures et des outils très particuliers.

Les architecture temps réel

Précisons d'abord que dans un système TR, toutes les parties du système ne sont généralement pas temps réel, c'est à dire avec les contraintes temporelles propres au temps réel. Prenons l'exemple d'un système d'acquisition de données qui pilote des instruments de mesures rapides, système que l'on trouve en physique des particules sur les grands instruments. Ce système possède trois grandes fonctions : l'acquisition des données et le pilotage des intruments, le stockage des données, la restitution des données vers les systèmes consommateurs de données. Seules les deux premières fonctions relèvent du temps réel dur, la restitution relevant de systèmes transformationnels ou interactifs.

Les architecture TR coûtent très cher. On limitera donc au strict nécessaire les parties TR d'un système. Ces architectures sont caractérisées par:

Lorsqu'il s'agit d'un système d'acquisition des données sur un grand instrument de physique des particules (ATLAS du LHC par exemple) qui reçoit 1 Go/s par salve, alors il faut en plus de l'électronique ultra-rapide dont le temps de cycle est de l'ordre de la nanoseconde.

Les autres objets "temps réel"

Nous venons de voir que le qualificatif "temps réel" s'applique à un système de traitement de l'information et plus spécifiquement à son architecture technique et à son système d'exploitation. Que penser alors d'expressions comme "donnée temps réel" ou "image temps réel" utilisées par beaucoup de personnes ? Existe-t-il d'autres objets que l'on peut qualifier avec justesse de "temps réel" ? Oui, il en existe : les bases de données ! Pour le reste, nous verrons ce qu'il faut en penser...

Les bases de données temps réel

Une base de donnée est un objet informatique qui stocke de manière structurée des informations. Il en existe plusieurs types : hiérarchique, relationnelle, objet, etc. De façon générale, les bases de données sont in fine des fichiers stockés sur des disques. En passant, non Excel n'est pas une base de données, ni ses classeurs !

Qu'est-ce qu'une base de données "temps réel" (BDTR) ? Examinons les différences entre une base de données conventionnelle (BD) et une BDTR :

Les BDTR sont des mécanismes compliqués, difficiles à concevoir et encore plus à mettre au point et à valider.

Remarque pour les puristes : ci-dessus, j'assimile BD et SGBD. Ce n'est pas très rigoureux, pardonnez-moi...

Que faut-il penser des données "temps réel" et des images "temps réel"

Dans un système TR, une donnée pourra être qualifiée de "temps réel" si elle respecte les contraintes de validité et de corrélation mentionnées plus haut. Ce qui implique que cette donnée soit stockée en BDTR. Ce sont des critères très restrictifs. Dans la plupart des cas, l'expression "donnée temps réel" est utilisée pour désigner une donnée provenant du procédé auquel est connecté le système d'acquisition de la donnée, qui d'ailleurs est souvent non-temps réel. Dans ces cas, le qualificatif "temps réel" est inapproprié et il est préférable de parler de données "terrain" ou "procédé".

Il en est de même pour les images qualifiées de "temps réel", pour désigner des images capturées sur le "terrain". Le qualificatif de "temps réel" pour une image est encore plus difficile à justifier, car les process de traitement des images sont très rarement déterministes.

En résumé, ce sont souvent des abus de langage, qu'il conviendrait aux ingénieurs d'éviter pour ne pas introduire de confusion.

Contenu et design par Dominique Lefebvre - www.tangenteX.com février 2017 -- Pour me joindre sur PhysiqueX ou

Licence Creative Commons

Cette œuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Pas de Modification 3.0 France.