Observation et visualisation de modèles de coordination Bach De B2Scala à Godot par format de transport temporisé

Défense de mémoire - Fadi AMRANI

Mon travail s’inscrit dans la continuité des recherches menées à l’Université de Namur sur les langages de coordination, et plus particulièrement sur la famille Bach et son environnement d’exécution B2Scala. Il est redevable à ce cadre théorique et logiciel, dont il prolonge l’usage en s’intéressant à l’observation des exécutions et à leur visualisation.

L’objectif principal du mémoire est de coupler l’exécution de modèles Bach à un « format de transport » comprenant plusieurs flux : l’un décrit les données, un autre les actions effectuées, c’est-à-dire les interactions avec le blackboard, et un troisième les transitions formelles. Ces trois formats — bien que les deux premiers suffisent — permettent de représenter complètement une simulation.

Ils opèrent donc comme une trace diffusable ou rejouable. À partir de ce format de transport, constitué de streams, je propose un dispositif de visualisation externe permettant de rejouer et d’inspecter les exécutions. Les données de visualisation ne sont donc plus intégrées au modèle lui-même : la visualisation est prise en charge par un outil indépendant, qui reçoit les informations nécessaires au moyen d’une communication par socket TCP. Cette séparation permet de maintenir une distinction claire entre la logique formelle du modèle et sa représentation graphique.

Dans l’implémentation que je propose, l’interface de visualisation est réalisée avec Godot, un moteur de jeu. Le protocole de communication développé demeure cependant générique et indépendant du moteur de rendu. Il peut ainsi être réutilisé par d’autres visualiseurs. Il expose non seulement l’état des agents autonomes, mais aussi le déroulement des transitions formelles opérant sur l’espace de données partagé.

Le mémoire porte donc principalement sur une extension du moteur d’exécution Bach afin qu’il puisse « diffuser » son état, sur la structuration et le transport des informations générées à partir de l’event listener, ainsi que sur l’exploitation de ce format de transport par un visualiseur externe. Dans une quatrième phase, j’ai construit quelques visualisations afin d’illustrer le fonctionnement de l’ensemble.

Voici quelques notes que j’ai prises qui détaillent mon cheminement autour de mon sujet, j’y détaille aussi quelques réalisations effectuées:

N’hésitez pas à effacer cette  partie si vous la jugez redondante ou non nécessaire.

Je m’intéresse au langage de coordination Bach, et plus particulièrement, ces derniers jours, à sa version b2scala.

Je me suis intéressé à la fois à la version Timed et à celle reposant sur les primitives classiques. J’ai notamment exploré la création de scénarios en Timed b2scala, dont un scénario que j’ai nommé Roster, avec différentes contraintes logiques. Par exemple :

·     Relaxed : un horaire peu respectueux du burnout ;

·     Sick leave : un horaire dans lequel une personne s’absente le quatrième jour ;

·     un horaire très déterministe, où les personnes sont toujours assignées dans le même ordre ;

·     etc.

Du côté du langage de coordination, je mets en place un event listener découplé de la partie coordination, qui s’appuie sur le moteur d’exécution existant.

Ce listener génère deux streams génériques horodatés :

1.   un stream décrivant la séquence des différentes actions et échanges avec le blackboard ;

2.   un stream reprenant les formules validées à chaque étape.

Je veille à ce que cet event listener reste le plus générique possible. J’ai notamment constaté que les primitives comm permettent de tracer la notation / les échanges de manière efficace.

Ces formats de transport sous forme de streams servent ensuite d’interface générique vers un outil de visualisation. J’utilise TCP pour envoyer ces flux vers un socket. De l’autre côté, une visualisation écoute le flux entrant et le traduit pour Godot.

J’ai aussi reproduit les le scenario Rush Hour en b2scala.

pour Rush Hour, le l’interface structurée peut recevoir (en streaming jsonl) :

·     une liste structurée de véhicules ;

·     une configuration initiale ;

·     un flux de mouvements.

(soit la partie data, et les interractions)

Je parviens ainsi, dans Godot, à rejouer une séquence avec sept véhicules, et le véhicule principal sort bien de la grille.

J’ai simulé de manière similaire le scénario Roster, qui rejoue la séquence des agents autonomes. Un rendu coloré permet de se faire une idée du respect des contraintes temporelles. On y voit également le blackboard ainsi que les formules durant l’exécution.

J’ai aussi une troisième visualisation, basée sur une carte OpenStreetMap, sur laquelle il est possible de commander un personnage. Celui-ci peut se déplacer selon différents modes :

·     comme un piéton, sur les trottoirs ;

·     comme un cycliste, sur les pistes cyclables ;

·     comme un véhicule, dans la rue.

Je comptais initialement simuler un trajet autour d’un rond-point ou un passage piéton avec plusieurs agents. C’était mon premier choix, mais je me suis finalement d’abord attardé sur la définition d’un format de transport générique et sur des invariants de représentation plus faciles à établir avec Rush Hour et Roster.

Plus accessoirement, j’ai aussi migré b2scala vers Scala 3. ScalaFX y fonctionne, je parviens à faire tourner Needham-Schroeder, et mon système de streaming fonctionne également pour ce cas. En revanche, je n’ai pas encore développé de visualisation dédiée pour celui-ci.

Contact : Sara Medugno - sara.medugno@unamur.be
Télecharger : vCal