B événementiel et temps-réel

permettant de définir une répétition infinie d’étapes, soit de manière implicite (Lustre, OCCAM, CSP) ou explicite (ESTEREL, et d’une manière générale tout langage permettant les boucles

while (true) do. . . ).

De ce fait pour pouvoir traiter de modèles ou le système ne doit jamais terminer, nous de-vrons affaiblir les contraintes pour la boucle en ne requérant plus la décroissance d’une quantité liée à la condition de boucle.

3.4 B événementiel et temps-réel

3.4.1 Mécanismes du B événementiel

Les mécanismes de B événementiel lui fournissent cependant une expressivité proche des logiques temporelles discrètes, comme LTL par exemple, si l’on considère les événements comme des points d’observation. La continuité peut être modélisée implicitement par des vari-ables qui représentent des horloges et par des gardes qui bornent ces varivari-ables à certains in-tervalles. Des propriétés de vivacité peut aussi être exprimées, sans changement fondamental [AM98] ou en modifiant les mécanismes de raffinement du B événementiel [ACM05].

Abrial et Mussat ont démontré que B pouvait être utilisé pour spécifier facilement des sys-tèmes distribués [Abr96b], avec l’exemple d’un protocole de transmission [AM97]. Cette util-isation de B est déjà un premier pas vers le B événementiel. Ce pas est continué plus tard en montrant que ce que les auteurs appellent « contraintes dynamiques » peuvent être exprimées avec le B événementiel. Dans d’autres méthodes ou domaines, ces contraintes portent le nom de contraintes temporelles, ou de contraintes de vivacité. Ces contraintes dynamiques [AM98] sont traitées en quatre temps :

– Autoriser le raffinement à complexifier le système en y rajoutant de nouveaux états (et donc de nouveaux événements qui les traitent)

– Spécifier les évolutions possibles des états du programme

– Spécifier les états que le système peut atteindre, i.e. l’atteignabilité de certains états – Empêcher les blocages.

Ces quatre points correspondent à la modélisation d’un système, ses contraintes de sûreté ainsi que sa vivacité. Cette dernière est obtenue en spécifiant l’atteignabilité de certains états désirables du système et l’impossibilité pour le système de se bloquer. Les trois derniers points ramènent aux définitions de la section 3.3.1, respectivement la sûreté, la vivacité (voire l’équité) et l’absence d’interblocage. Nous allons maintenant voir brièvement comment ces mécanismes sont obtenus par Abrial et Mussat [AM98].

Raffinement

Le problème du raffinement dans un système dynamique est l’introduction de nouveaux événements pour le système. Pour ceux-ci, la question suivante se pose : à quel événement du système abstrait correspondent-ils ? En fait, il est dit que ces “nouveaux” événements raffinent un événement qui ne fait rien (skip en B). En effet, au niveau abstrait, ces événements ne sont pas visibles, et donc sont “contenus” dans un événement invisible, qui semble ne rien faire.

Chapitre 3. Méthode B et temporalité

D’ailleurs, Abrial [AM98] compare ces événements invisibles aux « stuttering steps » de TLA, connus depuis longtemps, dont la fonction est similaire.

Pour garantir que le raffinement est correct, il faut donc s’assurer que les nouveaux événe-ments ne s’exécutent pas indéfiniment. Si c’était le cas, cela signifierait que dans le système abstrait, skip s’exécuterait indéfiniment, ce qui empêcherait les événements déjà présents d’être déclenchés. Le mécanisme proposé par Abrial et Mussat [AM98] pour empêcher cela est d’in-troduire une clauseVARIANTcontenant une quantité qui doit forcément décroître à chaque dé-clenchement des nouveaux événements. De cette manière le dédé-clenchement des événements déjà présents dans le système abstrait est garanti.

Notons toutefois que si le fonctionnement de cette clause VARIANTest similaire à la clause homonyme de la boucleWHILEde B, son rôle est différent :

– Dans le premier cas, il s’agit d’empêcher un fonctionnement indéfini des nouveaux événe-ments. Rien n’interdit aux anciens événements de faire croître la quantité diminuée par les nouveaux événements. Dans ce cas le système dans son ensemble peut fonctionner indéfiniment

– Dans le second cas, il s’agit de garantir que la boucle s’arrête forcément. Dynamique

Une clause appelée DYNAMICS contenant un prédicat est introduite pour pouvoir spécifier l’évolution des variables. De l’aveu d’Abrial [AM98], cette clause est redondante avec les événements eux-mêmes (qui sont au fond des prédicats exprimés différemment). Elle permet cependant d’éclaircir un modèle en B événementiel, et éventuellement de faciliter la preuve par l’expression des propriétés importantes.

Modalités

Les auteurs retiennent pour modalitésLEADSTO ; etUNTIL pour exprimer des propriétés de vivacité, invoquant la constatation qu’elles suffisent pour exprimer la plupart des contraintes temporelles usuelles. La modalité P ; Q, P et Q étant des prédicats, est exprimée par le biais d’une substitution gardée par P, et contenant une boucle dont la garde est la négation de Q. Le corps de la boucle est composé d’un choix borné entre les événements du système. Des contraintes supplémentaires (que nous ne détaillerons pas ici) et les obligations de preuve de cette substitution, une fois prouvées, garantissent que la formule ; dont est issue la substitution est vérifiée.

Le UNTIL est spécifié de la même manière : en fait il est même exprimé à partir d’une construction particulière deLEADSTO.

Absence de blocage

Le raffinement de modèles B événementiel pose un problème supplémentaire : comment garantir qu’un événement n’est pas trop raffiné, c’est-à-dire que sa garde est tellement renforcée qu’elle en devient impossible à déclencher ? En effet dans ce cas, si un événement (voire tous) ne peut plus être déclenché, le système peut se bloquer. La solution proposée par Abrial [AM98] est de s’assurer que la garde de l’opération se retrouve dans la disjonction de la nouvelle garde

3.4. B événementiel et temps-réel

et des gardes de nouveaux événements. En d’autres termes, on s’assure que le déclenchement est toujours possible quelque part, dans l’événement raffiné ou dans les nouveaux événements introduits.

Travaux ultérieurs

Des travaux ultérieurs de Abrial, Cansell et Méry [ACM05] sur le B événementiel résolvent des problèmes posés par les mécanismes introduits plus haut :

– Les introductions successives de nouveauxVARIANTS au cours des raffinements rend la preuve de décroissance de plus en plus difficile : en effet certains nouveaux événements peuvent avoir besoin de modifier les variables déjà présentes. Ils interfèrent avec les an-ciens variants.

– La multiplication des nouveaux événements peut rendre le modèle plus difficile à analyser et à traiter

– Les nouvelles constructions traitant de contraintes temporelles (LEADSTOetUNTIL) peu-vent peut-être être évitées.

Ces problèmes et interrogations sont résolus des manières suivantes :

– Le problème vient en fait de la manière dont sont introduits les nouveaux événements : sont-ils plutôt liés aux nouvelles variables introduites, ou modifient-ils l’évolution des variables déjà présentes (et donc sont liés aux variants) ? Abrial [ACM05] propose de lier plutôt les nouveaux événements aux variants en introduisant des événements anticipatifs dans la version abstraite du modèle. Autrement dit, il s’agit d’introduire dans le modèle des événements dont on ne sait presque rien, sauf qu’ils modifieront les variables du mod-èle. Abrial [ACM05] définit pour ces événements anticipatifs les contraintes suivantes : – Ils raffinent skip (comme attendu)

– Ils modifient de manière non-déterministe la variable qu’ils manipuleront plus tard de manière déterministe dans le raffinement

– Ils ne modifient pas leVARIANT pour cette même variable dans le modèle courant. Ces trois contraintes sur les événements anticipatifs permet donc de simplifier le raffine-ment dans un modèle complexe

– Un mécanisme de fusion des événements est défini. Il revient simplement à faire la dis-jonction de gardes d’événements dont le corps est identique.

– La méthode pour obtenir la vérification d’une contrainte d’atteignabilité (qui correspond en fait à une contrainte de vivacité) est elle illustré par une technique étayée d’un exem-ple. En quelques mots, l’atteignabilité est déjà spécifiée dans le modèle abstrait par un événement dit « one-shot » (en un coup). Il suffit donc de partir du principe que la pro-priété recherchée est obtenue en une seule fois, et de raffiner pour compléter le système avec les événements manquants.

L’exemple étudié par Abrial, Cansell et Méry [ACM05] est celui d’un client dans un restaurant. Pour garantir qu’il sera forcément servi (absence de famine, il s’agit donc bien d’une contrainte de vivacité), le modèle abstrait montre un événement où il est servi immédiatement. Puis les étapes successives de raffinement ajoute des événements sup-plémentaires où les autres clients sont servis, jusqu’au raffinement final. Les techniques utilisées pour parvenir à ce résultat sont celles décrites dans le même article, pour la simplification des raffinements et la fusion des événements.

Chapitre 3. Méthode B et temporalité

Ce dernier article montre donc que le B événementiel peut traiter de problèmes temporels simples sans faire appel à des mécanismes extérieurs. Cependant ces problèmes temporels sim-ples peuvent aussi vus comme de simsim-ples problèmes de causalité, puisque la notion de temps n’apparaît jamais. Il est évidemment possible de déclarer des variables qui représenteront le temps, un compte d’horloge,etc mais on en revient aux problèmes de complexité que l’on retrouve pour les approches similaires en B classique (cf section 3.3.3.0).

3.4.2 Automates temporisés

Hammad [HJMO03] présente une approche créée spécifiquement pour exprimer en B les systèmes réactifs temps-réel. Cette démarche est à rapprocher des démarches en section 3.3.3. L’exemple retenu pour l’illustrer est celui du passage à niveau.

Le principe est de coupler l’utilisation d’automates temporisés à un modèle en B événe-mentiel. Un automate temporisé à invariants est un automate dont les états sont étiquetés par un invariant. Celui-ci doit être vérifié pour un état donné tant qu’une transition ne le fait pas passer dans une autre transition. Cet automate est temporisé parce qu’il définit des horloges, sur lesquelles des contraintes peuvent être définies dans les invariants d’états, et que les transitions peuvent remettre à zéro ces horloges.

À partir des ces automates temporisés à invariants, Hammad [HJMO03] définit une traduc-tion en automates des régions. Ces automates sont à états finis et permettent de rendre discret un automate temporisé : il suffit de regrouper dans de mêmes états les configurations dont les évolutions ne modifient pas l’état du système. L’avantage immédiat d’une telle traduction est de pouvoir utiliser les outils sur les automates « classiques », puisque les automates des régions sont à états finis. Un de ces outils fait notamment la traduction en un modèle B événementiel.

La traduction se passe de la manière suivante :

– Les différentes régions de l’automate forment un domaine auquel appartiendra une vari-able décrivant le temps. Il peut y avoir plusieurs varivari-ables si plusieurs horloges avaient été définies dans l’automate

– Les événements décrivent les différentes transitions de l’automate : leurs gardes sont des prédicats indiquant l’état courant dans l’automate temporisé ainsi que la région du temps dans laquelle ils se trouvent. Il y a deux sortes d’événements : les événéments qui modélisent les états de l’automate, et un événement qui fait avancer l’horloge. Donc à tout moment, deux événéments sont activables, un événement de transition, et un événement d’horloge. Les événements de transition remettent l’horloge à 0. L’événément d’horloge est activable dans les limites imposées par les contraintes sur les transitions. Donc à un moment donné, seul un événément de transition sera activable

– Un événement supplémentaire, tic, fait avancer le temps, i.e. fait passer le système d’une région du temps à l’autre, toujours en utilisant les régions temporelles déclarées dans le modèle. La garde de cet événement assure qu’il n’est activé que lorsque nécessaire. Ainsi dans la pratique, les transitions de l’automate sont entrecoupées d’autant d’événements

tick qu’il y a de régions temporelles à traverser pour un état donné.

Il s’avère que le modèle B obtenu correspond à l’automate des régions minimisé de l’automate initial.

Hammad [HJMO03] suggère ensuite d’étendre le B événementiel pour simplifier la notation de ces machines temporisées :