Définitions de Base
Définition 3.1 (Système temps réel) Un système temps réel est un système dont l'exactitude (correctness) dépend non seulement des résultats logiques, mais également des instants où ces résultats
sont fournis.
Cette définition permet de mettre de côté les définitions courantes qui s’attachent à le définir aussi comme un système constitué de processus dont l’exécution est très rapide. Un système ayant des délais à respecter exprimés en heures peut être considéré comme un STR (Chaudières à vapeur par exemple). Ce n'est donc pas uniquement la « rapidité des temps de réponse » (au sens valeurs très faibles des durées) qui caractérise un STR. Néanmoins, la plupart des STR ont des temps de réponse exprimés en milli-secondes (ms). Le respect de telles contraintes de promptitude rend complexe le développement des systèmes et constitue une des caractéristiques importantes des STR.
Cette définition s’explique essentiellement par le fait que les STR sont des systèmes appartenant à la classe des systèmes dits réactifs. Par exemple, et de manière simplifiée, le rôle du système réactif de pilotage automatique d’un avion sera justement d’empêcher sa chute, c’est-à-dire de le maintenir à une altitude tolérable (ce que nous appelons le comportement maîtrisé).
22
3.3.2 Temps et contraintes temporelles
Le concept de temps est une notion difficile à définir, ainsi que le rappelle saint Augustin :
« Qu'est ce donc que le temps ? Si personne ne me le demande, je le sais ; mais si on me le demande et que je veuille l'expliquer, je ne le sais plus. » (Confession, 11, XV).
Pour notre part, nous ne donnons pas une définition philosophique ou mathématique du temps. De manière pragmatique, nous considérons simplement le temps comme un moyen d'exprimer des synchronisations entre des activités concurrentes au sein d'un STR, mais aussi entre ces activités et celles de l'environnement. Nous utilisons, ici, le terme "activité" au sens de fait temporel. Nous définissons l'occurrence d'un événement comme la manifestation (généralement le début ou la fin) d'une activité.
Les indications sur l’ordonnancement des événements temporels sont précisément les contraintes temporelles (CT).
3.3.2.1 Les types de temps
La communauté informatique distingue deux grands types de temps [AH92]:
• Le temps continu. C'est un temps que l'on suppose généralement dense (et complet), au sens mathématique du terme. Il est supposé qu’entre deux instants t et t', il y ait toujours un troisième instant t'', ce qui engendre en générale par coupure une infinité de temps intermédiaires entre deux temps. L'observation de la simultanéité d'événements n'est donc pas possible. C’est l’ensemble des réels qui s’emploie à le définir mathématiquement.
• Le temps logique (ou discret). Correspond à une succession d'instants discrets, prédéfinis et ordonnés. Ces instants peuvent être caractérisés par des événements ou par leur périodicité. Le temps logique entre deux instants n'est pas défini, il est non dense. La simultanéité des événements est donc possible, c'est un temps échantillonné aussi appelé discret pour les systèmes informatiques. Il est en général matérialisé par l’ensemble des entiers naturels.
• Temps local/global. Cette définition n'a de sens que dans un contexte où plusieurs horloges, généralement distribuées existent dans le système. Elle décrit le fait que l'écoulement du temps ne soit pas mesuré de la même façon dans chacun des nœuds du système. Il s'agit d'un temps global si l'écoulement du temps est le même pour tous les nœuds du système sinon il s'agit d'un temps local à un nœud.
• Temps relatif/absolu. Il dépend de la référence initiale de ce temps selon que cette référence est partagée par tous les temps (temps absolu) ou est spécifiques à chacun des temps.
3.3.2.2 Les types de contraintes temporelles a) Par rapport aux types de temps utilisés
Les contraintes temporelles (CT) pouvant être exprimées avec les différents types de temps, nous retrouvons les mêmes catégories que celle du temps. Par exemple, l’ordonnancement des événements peut être formulé :
• En reliant les évènements temporels à des dates (utilisation d’un temps physique ou échantillonné),
• En les reliant à des événements de référence (utilisation d’un temps logique absolu),
• Où en les reliant entre eux par des relations d'ordre (utilisation d’un temps logique relatif). Souvent, on parle de contraintes temporelles implicites (ou qualitatives) lorsqu’elles sont exprimées avec un temps sans métrique (temps continu ou logique). On parle de contraintes temporelles explicites (ou quantitatives) lorsqu’elles sont exprimées à l’aide d’un temps avec métrique (physique ou échantillonné).
23
b) Par rapport à leurs origines
Lors du développement de STR, il est courant de différencier les contraintes temporelles suivant leurs origines. On parle alors de CT externes et des CT internes :
•
Les CT externes sont issus des besoins du système. Elles expriment des relations d'ordre entre le système et des entités qui lui sont extérieures. Elles constituent un ensemble d'informations permettant de caractériser le procédé à piloter. Elles vont se traduire par des exigences sur la façon d'observer et/ou de piloter l'environnement. Ce sont des contraintes définissant le comportement naturel et maîtrisé du procédé. Cela peut être des lois de commande, des vitesses de réaction, des temps de réponse (délai entre la réception d'un stimulus et la génération d'une réponse pour le système). Elles peuvent aussi provenir de besoins non plus dictés par l'environnement mais plutôt par les clients et utilisateurs.•
Les CT internes expriment des relations d'ordre entre les entités internes au système. Ce sont des CT inhérentes au fonctionnement du système. Par exemple : la périodicité (ou non) des actions à effectuer, des synchronisations entre activités, des délais d'attente entre chaque communication (protocole de communication avec attente limité), la validité temporelle d'une donnée, mais aussi des informations concernant les processeurs, leurs vitesses, le système d'exploitation utilisé, les délais de communication, le débit du réseau de communication, etc.3.4 Les classes de systèmes temps réel
Une distinction est faite entre les STR suivant la criticité des temps de réponse de ces systèmes. On parle alors de :
• STR critiques ou strict (hard real-time), • STR fermes ou durs (firm real-time),
• STR souples, lâches ou mous (soft real-time).
D'autres critères de différenciation existent entre ces catégories : par exemple, des critères statistiques sur les temps moyens des contraintes temporelles. Cependant, la criticité des contraintes temporelles est une condition nécessaire et suffisante pour distinguer les trois types de STR présentés.
Naturellement, le développement de STR stricts ou fermes nécessite impérativement des activités de vérification et de validation du système en construction.
La validation (au sens de validation des besoins) consiste à s'assurer que le système en construction est bien celui attendu par les clients. Le "bon" système est construit. La vérification (au sens de vérification des propriétés mathématiques) consiste à s'assurer que le système est cohérent. Le système est "bien" (correctement) construit.
Dans ce qui suit nous présentons rapidement quelques approches pour mieux élucider certaines caractéristiques, ce sont :
3.5 L’Approche Synchrone
Les langages synchrones ont été introduits pour faciliter la tâche du programmeur en lui fournissant des primitives, permettant de raisonner comme si le programme réagissait instantanément aux événements externes. Chaque événement interne du programme est précisément daté par rapport au flot des évènements externes, et le comportement du programme est complètement déterministe, tant de point de vue fonctionnel que temporel. En pratique, l’hypothèse revient à supposer que le programme réagisse assez vite pour percevoir tous les évènements externes en bon ordre. Il est bien connu que les langages synchrones sont susceptibles d’être implantés de manière très efficace. Le code produit n’est
24
autre qu’un automate fini, dont une transition correspond à une réaction du système. Comme le code d’une transition est linéaire (il ne comporte pas de boucle) et son temps d’exécution est maximal est donc par conséquent calculable, on peut ainsi vérifier le bien-fondé de l’hypothèse de synchronisme. La notion de synchronicité ne peut être bien établie que si l’on considère les algèbres de processus telle que CCS.
Les principaux langages synchrones sont ESTEREL [BB91] qui est un langage impératif bien approprié aux applications dont la partie « contrôle » est prédominante (système à alarme, protocole de communication …), c’est aussi un langage orienté automate. SIGNAL [BCG99] et LUSTRE [
HCR+91a, HCR+91b
] sont des langages déclaratifs « flots de données » appropriés pour les applications dont la partie « calculs » prédomine (contrôle de processus, traitement de signal…) et les Statecharts [Har85] langage purement graphique très puissant.3.6 L’Approche Flot de Données
Dans le domaine des systèmes réactifs, il existe une frange d’utilisateurs de spécialité tout à fait différentes de l’informatique, telles que l’électronique et l’automatique, qui nécessitent dans leurs études ou bien dans leurs recherches un outil (i.e modèles) qui soit adapté à leurs exigences. Dans ce cas de figure, il est important de leur offrir un concept leur permettant d’interpréter leurs doléances. L’approche flot de données (modèles étudiés en informatique sous le nom de « flots de données » [Kah74, McG82]) constitue justement une très bonne démarche qui permet de mettre en place l’aspect théorique et pratique de tels systèmes (électronique, automatique, etc.). On parlera dans ce cas, de langages flot de données. Ces langages présentent des avantages non négligeable et se caractérisent par :
1. Il s’agit d’un modèle parallèle à grain fin : conceptuellement, dés qu’un opérateur possède les données nécessaires, il peut élaborer les sorties correspondantes. Ainsi, les seules contraintes de séquencement et de synchronisation sur les actions sont les contraintes de dépendance entre les données. Une description à parallélisme rend possible toute une variété d’implantations, allant du séquentiel pur jusqu’à l’exécution sur architectures massivement parallèles.
2. Le modèle possède en général une propriété mathématique qui fait défaut aux langages impératifs classiques, dans lesquels les notions de mémoire et d’affectation introduisent la possibilité d’effet de bord complexe. Ce caractère mathématique facilite l’application de méthodes formelles pour vérifier, construire et transformer les programmes.
3. La description sous forme de réseaux d’opérateurs fournit directement une représentation graphique des programmes. Une notion de hiérarchie est présente aussi de façon à représenter un sous-réseau comme un opérateur. L’existence d’un formalisme textuel, équationnel équivalent au formalisme graphique, permet aussi de combiner ces deux représentations.
Le langage LUSTRE est un langage synchrone fondé sur le modèle flot de données. Dans ce cas, un programme peut être vu comme un réseau d’opérateurs, et l’hypothèse de synchronisme consiste à supposer que chaque opérateur de ce réseau réponde instantanément à ses entrées. Dans le langage LUSTRE il est fournit les moyens d’écrire la spécification de vérifier son comportement à travers les opérateurs temporels disponibles, de générer différents codes, entre autres l’automate correspondant, et de minimiser le code et le graphe associé à cet automate.
25
3.7 L’Approche Asynchrone
La majeure partie des systèmes distribués est naturellement asynchrone du fait qu’ils ne peuvent garantir un délai fixe pour assurer les communications entre leurs différents composants. Ce sont différents processus (tâches, activités, agents …) qui s'exécutent en parallèle à des vitesses différentes (pas d'horloge centrale) n'ayant pas forcément de mémoire commune avec des délais de communication pouvant varier. En général, la modélisation de ces systèmes nécessite de considérer les horloges générant des tick à grains fins, c’est-à-dire que les évènements peuvent être générés dans un espace temporisé dense (continu).
3.7.1 L’Approche Synchrone / Asynchrone
Les méthodes algébriques de spécification des systèmes distribués sont considérées comme un puissant outil pour d’un côté décrire mathématiquement les différents aspects des processus communicants, mais aussi de vérifier leur comportement. Algébriquement, deux processus a et b qui s’exécutent en parallèle sont interprété par (a || b). Il existe deux models de base qui permettent de différencier les systèmes distribués, c’est le synchronisme et l’asynchronisme. L’exemple suivant permet de mieux cerner leur différence.
– Synchrone : a || b = (a, b) – Asynchrone : a || b = a. b + b. a exemple:
1. composition parallèle de deux processus synchrones (l’opérateur est noté double barres verticales « || ») :
a.a’ || b.b’ ≡ (a, b) . (a’, b’)
2. composition parallel asynchrone (entrelacement = interleaving)
3.8 Langages et automates
On appelle un ensemble fini de symboles représentant des signaux (de communication) X = {x0, … ,xn-1} un alphabet de dimension n. Un évènement synchrone x de X est un ensemble de
signaux. La dénomination synchrone signifie que tous les signaux d’un événement sont supposés survenir au même instant.
26
Une exécution d’un programme synchrone est vue par un observateur extérieur comme une suite d’événements composés par des signaux de son interface. On définit ainsi une exécution d’un programme comme étant une trace (ou mot synchrone) sur X. Un mot m définit sur X est une suite finie ou infinie d’événements synchrones sur X ( m = (x0,x1, … ) | ∀i, xi ∈ 2X). La longueur d’un mot m est notée |m| (0≤ |m| ≤ ∞). On note ε le mot de longueur nulle.
Exemple 3.1
Soit X = {x1,x2,x3}. Alors {x1}, {x1, x3}, {x1,x2,x3} et ∅ sont des événements synchrones sur X. ({x1}, {x2, x3}, {x1,x2,}, ∅,∅,{x1, x2}, … ) est un mot synchrone sur X.
Définition 3.2 Un ensemble fini ou infini de mots est appelé un langage. Un programme est décrit