Contexte
This internship is part of the TACOS 1 and CRISTAL 2 projects, which aim to explore the design of innovative urban transportation systems based on self-service electric autonomous vehicles.
A system consists of several vehicles, each operating autonomously Each vehicle is equipped with technology to detect the speed and position of other vehicles Key specifications include a maximum convoy speed of 40 km/h, a maximum speed of 50 km/h for trailers, an empty weight of 900 kg, and a loaded weight of 2000 kg The vehicles can accelerate at a maximum rate of 1 m/s² and decelerate at up to 1.3 m/s², with an emergency deceleration capability of up to 3 m/s².
In this system, the goal is to form vehicle convoys, typically consisting of vehicles traveling in the same direction, with the number of vehicles in each convoy limited to a predetermined maximum The first vehicle in the convoy, known as the leader, is operated by a human driver Importantly, there is no physical connection between the convoy members Each vehicle in the convoy receives information from the preceding vehicle to adjust its speed and maintain an appropriate distance from it.
Fig 1.1: Véhicules se déplacent en convoi
Un véhicule peut quitter un convoi (décrochage) pour en rejoindre un autre (ac-
After detaching from a convoy, the vehicle is manually operated until it reattaches to another convoy, at which point it switches back to automatic mode Therefore, there are four operational modes for a vehicle: SOLO, PLATOON, and others.
Fig 1.2: Modes des fonctionnement du système
Dans le mode stable SOLO, les véhicules se déplacent indépendamment les uns des autres Ils sont conduits manuellement.
Dans le mode stable P LAT OON, les véhicules se déplacent en convoi Chaque véhicule suit celui qui le précède Le leader du convoi est conduit manuellement.
Le mode transitoireJ OIN T représente le processus d'accrochage d'un véhicule à un convoi Il intervient pour faire basculer le véhicule du mode SOLO au mode
Le véhicule fonctionne dans le mode transitoireDISJ OIN T quand il veut décrocher d'un convoi.
L'équipe DEDALE a utilisé CSP||B pour modéliser le fonctionnement d'un convoi. Dans ce modèle, deux modes de fonctionnement du véhicule,SOLOetP LAT OON, ont été spéciés.
The CSP||B 3 approach emerged in the 2000s as a fusion of two formal methods: the B method and CSP algebra This innovative combination leverages the theoretical foundations and supportive tools from both methodologies, offering significant advantages for system design and verification.
Objectifs initiaux du stage
1.2 Objectifs initiaux du stage À partir du modèle existant, nous allons continuer à réaliser les modesJ OIN T et DISJ OIN T.
1 Modélisation du comportement d'un convoi avec l'accrochage et décrochage de véhicules à partir de la spécication CSP||B existante.
2 Introduction des contraintes de position et d'intégrité pour prendre en compte les propriétés de non-collision.
3 Convergence de ces deux évolutions dans un même modèle.
Résultats
The advantage of the existing model lies in its straightforward and explicit internal processes for the PLATOON and SOLO modes However, the vehicle requires more complex processes for coupling and decoupling We have restructured this model to create a vehicle system model that encompasses four operational modes, which is detailed in Chapter 3 and is documented in CSP||B.
Verifying a CSP||B modeling presents a challenge due to the manual verification step involved A CSP||B model consists of several CSP||B components, each comprising a B machine and a CSP controller While tools exist for verifying B machines (such as AtelierB, ProB, and B4free) and CSP controllers (like FDR2, ProB, and Arc), there is currently no tool to ensure consistency between B machines and their corresponding CSP controllers To address this issue, we have developed software based on Helen Treharne's Control Loop Invariant technique, enabling fully automated verification of CSP||B modeling.
Structure du rapport
La suite du rapport contient 4 chapitres et des annexes.
Chapitre 2 - Approche CSP||B C'est un résumé de l'approche CSP||B Nous avons présenté également un exemple 2.4 pour mieux comprendre cette ap- proche.
Chapter 3 - Vehicle System Model This chapter briefly outlines the existing model and introduces our proposed model, detailing its structure, vehicle operation modes, and verification processes.
Chapitre 4 - Vérication de la cohérence entre la machine B et le con- trôleur CSP Ce chapitre présente la théorie de la cohérence entre la machine
B et le contrôleur CSP dans un composant CSP||B L'essentiel du chapitre est consacré à présenter un logiciel qui a pour but d'automatiser cette vérication. Chapitre 5 - Conclusion et perspective
Annexes Elles contiennent les spécications développées au cours du stage ainsi qu'une documentation sur l'implantation du traducteur.
Ce chapitre rappelle les bases théoriques de l'approche CSP||B qui est utilisée dans notre travail Elle est la combinaison de deux méthodes formelles : la méthode B et l'algèbre CSP.
Dans la section Introduction, nous ne détaillons pas la méthode B et l'algèbre CSP ; nous présentons seulement des notions principales qui sont utilisées dans l'approche CSP||B.
In the second section, CSP parallel B, we provide an overview of modeling a system using CSP||B We also elaborate on the two components of the CSP||B models: the B machine and the CSP controller.
The section on verifying a CSP||B model discusses how to ensure the correctness of a model It highlights a significant challenge: there is currently no tool available that can automatically verify CSP||B modeling.
Some aspects can be verified using existing tools, while others require manual verification We will address this issue and its solution in Chapter 4, which focuses on the consistency verification between Machine B and the CSP controller.
Introduction
Méthode B
Method B is a formal software development approach that allows for the abstract modeling of a program's behavior using the B language Through successive refinements, it leads to a concrete model that can be translated into C or Ada This method is based on predicate logic and set theory and has proven effective in system validation, particularly in the railway sector Notable implementations include the METEOR project for the automatic door control of Metro Line 14, the Rosissy VAL metro system's alarm control unit, and the CACoLac project for the automatic control of a mobile access bridge on Metro Line 5.
The B method, developed by Jean-Raymond Abrial in the 1980s, builds on the foundational work of E.W Dijkstra and C.A.R Hoare This programming language, an evolution of language Z, is designed for industrial applications and encompasses the entire development cycle In 1996, Abrial published "The B Book," which serves as the first comprehensive reference on the B method.
Le processus de développement en B est présenté dans la Figure2.1.
The abstract machine is a fundamental concept in B, akin to the class of object-oriented languages It defines a system through a set of state variables and operations that evolve this state Typing and constraints govern these variables, expressed as first-order predicates The set of operations represents the dynamic aspect of the system, with specifications detailing their behavior.
Cahier de charge Machine abstraite
Figure 2.1 illustrates the development of B substitutions, where the fundamental substitution involves assigning a value to a variable The advancement of this language facilitates the definition of more complex substitutions, including non-deterministic substitutions such as CHOICE and ANY, as well as pre-conditioned substitutions denoted by PRE.
Le ranement est le processus de transformation de spécications abstraites en spécications plus concrètes Il y a deux types de ranement.
Ranement algorithmique : c'est la transformation d'une substitution ab- straiteS en une substitution moins abstraiteS 0 (ex : remplacement d'une substitution simultanée par une substitution séquentielle).
Ranement de données : c'est le remplacement d'une donnée abstraite
D par une donnée concrète D 0 (ex : ranement d'un ensemble par un tableau).
Both types of transformations are not mutually exclusive and can occur simultaneously during the same transformation stage It is clear that any data transformation leads to an algorithmic transformation In fact, since the substitutions no longer operate within the same variable space, they must be rewritten in relation to the new variable space.
L'implémentation est le dernier niveau de ranement d'une machine abstraite.
The language used to describe this implementation employs data and control structures supported by the chosen programming language Consequently, translating this implementation into the target language is a straightforward process and can potentially be automated Currently, there are several options available.
2.1 Introduction 9 générateurs automatiques de code permettant de traduire en ADA, C ou C++ l'implémentation d'une machine abstraite.
Method B ensures comprehensive verification of all phases in system development Proof obligations (PO) are generated during the specification phase and for each refinement step These proofs help maintain the internal consistency of the abstract specification and verify the correctness of a refinement against its more abstract versions.
Communicating sequential processes - CSP
CSP est une algèbre de processus Elle permet de modéliser l'interaction entre com- posants C'est un langage de description.
C.A.R Hoare introduced Communicating Sequential Processes (CSP) in a 1978 article, with its first book published in 1985 CSP has been effectively utilized in industrial settings as a formal specification tool for concurrent system execution Formal Systems Europe, Ltd has developed CSP tools to support this application.
CSP typechecker eectue le contrôle statique d'une spécicaiton.
ProBE est un animateur pour des processus CSP Il permet à l'utilisateur d'ex- plorer un processus CSP en suivant pas à pas les événements.
Failures-Divergence Renement - FDR est un système de vérication de processus CSP par model-checking.
Dans la suite, nous allons présenter les notions principales de CSP.
A process consists of a series of events For instance, to illustrate how a simple vending machine operates, it receives money (coins) and then dispenses a product (such as chocolate) This sequence of actions outlines the core functionality of the vending machine.
L'opération→prend toujours un événement à gauche et un processus à droite.
An event signifies communication or interactions and can be categorized as either an atomic name (e.g., coin, collision) or a channel event (e.g., getInfo ?speed, setAccel !10) For instance, in a data copying process, the value x is taken from the producer and provided to the consumer.
1 http://www.fsel.com/software.html
COP IE=producteur?x→consommateur!x→COP IE
A channel serves as a communication link between two processes, where a value is extracted from the producer channel and sent to the consumer channel In a CSP channel, it can hold either an input value (e.g., consumer!x), an output value (e.g., producer?x), or both (e.g., getSpeed!id?speed) A channel transforms into an event once all its values—either inputs or outputs—are fulfilled; otherwise, the process enters a waiting state, potentially leading to a deadlock A simple channel, which contains no values, is designed to facilitate synchronization as it remains available to become an event The example from COP IE will be illustrated as shown in Figure 2.2, depicting the roles of the producer, consumer, and intermediate acknowledgment (ack).
Fig 2.2: Exemple de copie de donnée
EM ET T EU R = producteur?x → intermediaire!x → ack → EM ET T EU R
RECEP T EU R = intermediaire?x → consommateur!x → ack → RECEP T EU R
COP IE = EM ET T EU R[|intermediare, ak|]RECEP T EU R
A trace is a sequence of events, and a trace tr represents the record of a process P if P produces the sequence of events in tr For instance, a trace of virtual machines (VMs) could be represented as tr = coin, hit, while another example might be tr = coin, hit, coin, hit A process P is identified by the set of all traces it can generate.
Divergence La divergence d'un processus P est une suite d'événements tr telle que, quandP exécutetr, il aboutit à un état divergent.
Un état du processus P est divergent quand après avoir passé cet état : le processus P va entrer dans une boucle innie ou l'événement suivant du processus P est indéterminé.
A process is considered divergence-free if it exhibits no divergence Stable failures refer to a pair (tr, X), consisting of a trace tr and a set of events X This pair (tr, X) qualifies as a stable failure of a process P if there exists an execution of P where tr is a trace of P, and this execution concludes in a state where all events in X are rejected.
CSP parallèle B
Machine B
Dans CSP||B, on utilise des opérations sans garde parce qu'elles sont toujours disponibles à l'exécution Une opération est présentée sous les formes PRE P
In the context of the B method, "THEN S END" or "BEGIN S END" represents a predicate (P) and a set of substitutions (S) that update the state This operation occurs even when the predicate P is false, but in such cases, the correctness of the execution S is not guaranteed Here, P is referred to as a pre-condition The B machine adheres to the syntax of the classical B method.
Dans ce stage, nous utilisons l'AtelierB 2 comme un outil support pour rédiger et vérier les machines B.
Contrôleur CSP
In CSP||B, a segment of CSP algebra is utilized, which is not predetermined but rather contingent upon the controller's description Below, we outline the syntactic features of CSP that are employed in our internship.
Le processusc?x→P (etc!v→P) spécie que le canal de communicationcaccepte l'entréex (et la sortie v).
A machine channel facilitates communication between the machine and its controller For each operation v ← ope(x) within machine B, there is a corresponding channel ope?v!x in the controller to invoke this operation The output v in the CSP description represents the input of the operation in machine B, while the input x corresponds to the output of that operation.
L'exécution du processus gardé b&P dépend de la valeur logique b.P est exécuté quandb=true, sinon, il ne peut pas être exécuté.
Le choix externe P 1 P 2 est utilisé pour choisir entre les processus P 1 et P 2 Le choix est déterminé par le premier événement Par exemple : dans le choix a →
P 1 b→P 2 , siaa lieu avant balorsP 1 va être exécuté Cependant si tous les deux ont lieu simultanément, le choix devient indéterministe (non-determinism).
Le choix if b then P1 else P2 dépend de la valeur logique b : si b= true, P1 sera exécuté, sinon,P2 sera exécuté.
La syntaxe P 1 [|canaux|]P 2 représente que deux processus autonomesP 1 et P 2 ont un ensemble de canaux communs (canaux) et qu'ils utilisent ces canaux pour syn-
2.2 CSP parallèle B 14 chroniser leur fonctionnement.
L'alternance (interleaving)|||id:{1 n}@P i représente des processusPiautonomes (avec1≤i≤n).
Et enn, nous avons l'appel récursifS(p).
In this internship, we utilize Emacs with csp-mode to write the CSP controller and FDR2 for verification To effectively use FDR2, it is essential to adhere to specific syntax constraints, including the definition of channel prototypes and data types.
Vérication d'une modélisation CSP || B
Un composant CSP||B est correct quand le contrôleur CSP est correct, la machine
B est correcte et la cohérence (consistency) entre la machine B et son contrôleur est montrée La vérication se déroule en trois étapes :
1 La machine B est correcte Une machine est correcte quand sa syntaxe est correcte et quand toutes ses POs sont prouvées.
2 Le contrôleur CSP est correct Un contrôleur est correct quand sa syntaxe et les deux propriétés de deadlock-free et divergence-free sont établies.
3 La cohérence entre la machine B et son contrôleur CSP Il faut prouver que toutes les opérations de la machine B ne sont appelées que lorsque leur pré- conditions sont satisfaites En utilisant la technique du Control Loop Invariants (CLI) 3 , nous avons une démarche de vérication :
(a) le contrôleur CSP est traduit en une machine B : la machine de contrôle, (b) on ajoute un invariant CLI dans la machine de contrôle,
(c) on doit alors prouver que la machine de contrôle est correcte.
A CSP||B modeling consists of multiple parallel CSP||B components, represented as ||i : {1 n}@(P i ||M i ), where P i is the CSP controller and M i is the B machine of the i-th component To ensure the system's reliability, it is essential to verify two key properties: divergence-free and deadlock-free.
1 La modélisation est divergence-free Quand chaque (Pi||M i ) est correct, alors par le théorème 8.1 de [16], nous déduisons que la modélisation est divergence- free
3 Voir en détail dans le Chapitre 3
Discussion
2 La modélisation est deadlock-free Quand || n i (Pi) est deadlock-free, alors, en utilisant le théorème 8.6 de [16], nous avons deadlock-free
Nous constatons qu'une modélisation CSP||B est vériée presque automatiquement par des outils existants Il nous reste la vérication de la cohérence entre la machine
The translation of a CSP controller into a control machine and the identification of a CLI invariant is a manual process We have developed a tool that automates the translation of a CSP controller into a control machine while providing suggestions for the CLI format Generating a CLI requires high-level expertise During this internship, the translator can determine whether a CLI is necessary; when it is required, the tool specifies its structure.
Modèle du système des véhicules
3.2.1 Scénario 20 3.2.2 Modes de fonctionnement du véhicule 21 3.3 Structure du code CSP || B 25 3.3.1 Composant V ehicle 26 3.3.2 Composant DrivingSystem 26 3.3.3 Composant N et 27 3.4 Vérication 28
Dans ce chapitre, nous présentons le modèleP LAT OON existant : sa structure, ses avantages, ses désavantages et comment il peut s'appliquer dans notre travail.
Dans le système envisagé, un véhicule fonctionne dans un des 4 modes : SOLO,
The existing model outlines two operational modes: PLATOON and SOLO To incorporate the additional modes JOIN T and DISJOIN T, the vehicle model requires expansion through the integration of additional processes and properties We have enhanced the initial model to create a comprehensive framework that encompasses all four vehicle operating modes The modes PLATOON and SOLO have been modified accordingly The vehicle system section elaborates on this updated model.
La section Structure présente la structure des composants CSP||B de la modéli- sation Elle présente également l'interface de communication entre des composants.
Le texte du modèle complet en CSP||B se trouve dans l'AnnexeA.
Modèle P LAT OON existant
The DEDALE team has introduced a CSP||B modeling of the PLATOON mode, where vehicles travel in convoy formation In this system, the convoy leader is manually operated, receiving acceleration input (hciAccel) from the user and adjusting its speed (hciSpeed) accordingly.
In a convoy, there is no physical interaction between its members; instead, the operation relies on direct perception among vehicles Each vehicle in the convoy operates autonomously, gathering information from the preceding vehicle This perception is represented in CSP||B by the communication channel Utilizing the data obtained from this perception, each vehicle adjusts its speed to maintain an optimal distance from the one ahead.
Fig 3.1: Modèle du convoi sans Net
An alternative approach to managing a convoy is the global approach, where a centralized system, akin to a conductor, makes decisions for all vehicles However, this method is not suitable for the purpose of this work, which focuses on specifying autonomous vehicles, and therefore was not pursued.
La modélisation du fonctionnement des véhicules dans un convoi est décomposée en trois étapes :
Fig 3.2: Activité de véhicule dans le convoi
Perception Dans cette ộtape, chaque vộhicule perỗoit les informations : sa vitesse
(speedi), sa position (xposi) et les informations du véhicule précédent (nom- mées perceived_speedi etperceived_xposi).
Based on this information, the vehicle can determine its distance (p_distancei) from the preceding vehicle It will then adjust its acceleration value (accel_decisioni) to maintain this distance, which can either be a positive value (indicating acceleration) or a negative value (indicating deceleration).
The ideal distance between a vehicle and the one in front should be sufficiently large to prevent collisions in case of an issue, yet close enough to ensure that the convoy does not occupy excessive space on the road This distance can be calculated using the formula: ideal_distance = CRITICAL_DISTANCE + speed The new acceleration is determined by the perceived position and speed of the vehicle, leading to an acceleration decision that must remain within the defined minimum and maximum acceleration limits If the new acceleration exceeds the maximum, it is adjusted to the maximum value; if it falls below the minimum, it is set to the minimum value.
Réaction Il applique accel_decision i
The speed and position of the object are updated based on the acceleration decision If the new speed is within the range of 0 to MAX_SPEED, the position is adjusted by adding the current speed and half of the acceleration decision If the new speed exceeds MAX_SPEED, the position is modified to account for the maximum speed limit Conversely, if the new speed is less than 0, the position is decreased accordingly, ensuring that the speed does not drop below zero.
The advantage of this approach lies in its simplicity and clarity Each vehicle in a convoy receives information directly from the preceding vehicle via a communication channel, without direct interaction between them, relying instead on the perception of the rear vehicle However, this model requires that the two vehicles at the ends of the communication channel be predetermined Additionally, a limitation of the CSP modeling is that the communication channel is static, meaning that vehicles cannot be added or removed during the process.
The existing P LAT OON model features 19 channels Since the internship focuses on the process of attaching (or detaching) a vehicle to a convoy, it is essential to know how to add or remove a channel when utilizing this model.
Une évolution du modèle[5] introduit une entité de perception intermédiaire entre les véhicules Elle s'appelle Net.
Fig 3.3: Modèle du convoi avec Net
Le rôle de N et est rudimentaire Il transfère les informations du canal de sortie (comOut) d'un véhicule au canal d'entrée (comIn) du véhicule qui le suit :
1 channel comIn : Ids Speeds Positions
2 channel comOut : Ids Speeds Positions
4 ( ( id ! = id2) & comOut.id ? speed ? xpos → comIn.id2 ! speed ! xpos → Net(id, id2) )
6 ( ( id == id2) & comOut.id ? speed ? xpos → Net(id,id2) )
The COM channel plays a crucial role in our work, serving as an intermediary within vehicles and having knowledge of all vehicles in the system The endpoints of the COM channel are a vehicle and N, or the point of connection between two vehicles In this case, the number of channels can be fixed and predetermined, allowing for efficient communication and data exchange.
L'architecture en CSP||B d'unCristal déni dans [6] comporte deux composants 2 :
The Vehicle component models the physical aspects of the vehicle, providing essential information such as speed (getSpeed) and position (getXpos) to the DrivingSystem It also applies the new acceleration (setAccel) received from the DrivingSystem.
The DrivingSystem transfers internal information about the vehicle (vehicleInfo) and data from the previous vehicle through the comIn channel to machine B (setPerception) Machine B then calculates the new acceleration value (getInfluences), which is subsequently sent as vehicleAccel.
2 le nom d'un composant CSP||B est V ehicle, alors sa machine est nommée V ehicle et son contrôleur est nommé CtrlV ehicle
Système des véhicules
Scénario
On va considérer un système qui se compose des véhicules Le nombre de véhicules dans ce système est xé et connu Un véhicule peut voir tous les autres.
In this system, all vehicles initially operate in SOLO mode Subsequently, certain vehicles can form one or more convoys, with each convoy identified by its leader's identity The number of members in a convoy is limited to a predefined maximum.
In a convoy, a member may wish to detach in order to connect to another convoy The vehicle will then switch to DISJOINT mode for the detachment process Once this process is complete, the vehicle operates in SOLO mode From there, it can transition to JOINT mode to attach to a new convoy.
In this system, N consolidates information from all vehicles, ensuring that the data is always up to date Each vehicle is represented as a tuple consisting of three fields: ID, speed, and position Additionally, N maintains a collection of convoys, each identified by a unique identity and comprising a list of members.
: SOLO : P LAT OON : J OIN T : DISJ OIN T
: Canal de communication : Accrocher : Décrocher
Modes de fonctionnement du véhicule
Initially, a vehicle operates in SOLO mode Mode changes can occur either automatically or manually The user initiates a mode change in two scenarios: transitioning from SOLO to JOINT and from PLATOON to DISJOINT Automatic changes occur when moving from JOINT to PLATOON (if successful) or back to SOLO (if unsuccessful), and from DISJOINT to SOLO (if successful) or to PLATOON (if unsuccessful).
In this article, we explain how a vehicle operates in each mode, highlighting that it consistently follows a cycle comprising three key stages: Perception, Decision, and Reaction Additionally, we introduce a fourth stage, Mode Change, which facilitates the automatic or manual transition between different operating modes of the vehicle.
Quand le véhicule fonctionne dans le modeSOLO, son processus interne est simple car le contrôle est assuré par l'utilisateur.
Perception l'accélération donnant par l'utilisateur sa vitesse
Décision utilisation de cette accélération
Réaction application de l'accélération, mise à jour de la vitesse et de la position Changement du mode
Si l'utilisateur décide de changer de mode et initie l'ordre d'accrochage, alors le véhicule va passer dans le mode J OIN T
Si non, le véhicule poursuit en modeSOLO
But changement du modeSOLOau mode P LAT OON
Le véhicule est dans le modeSOLO
Il y a une demande de changement de l'utilisateur
Si le processus d'accrochage échoue, alors le véhicule retourne au mode SOLO s'il réussit, alors
Le véhicule va passer dans le mode P LAT OON le véhicule occupe la dernière place dans le convoi
Quand la pré-condition est satisfaite, le processus d'accrochage va passer par 4 étapes :
3 La permission est refusée quand
Le convoi cible n'a plus de place : le convoi est de taille maximale. il existe un autre véhicule qui est en train d'accrocher ou de décrocher de ce convoi.
Dans ce cas, le véhicule doit retourner au modeSOLO.
Dans le cas inverse, il va entrer dans la boucle du processus d'accrochage
Perception sa vitesse et sa position la vitesse et la position du véhicule précédent Décision nouvelle accélération pour approcher le convoi cible
Réaction application de l'accélération et mise à jour de la vitesse et de la position
Changement du mode il calcule la distance avec le véhicule précédent Si la distance correspond à la distance de formation du convoi, le véhicule passe au modeP LAT OON.
Si après un certain temps (timeout) l'accrochage n'a pas eu lieu, alors le véhicule retourne au mode SOLO.
Le processus du véhicule dans ce mode est basé sur le modèle existant.
Perception sa vitesse, sa position la vitesse, la position du véhicule précédent
Décision calcul d'une nouvelle accélération pour maintenir la distance avec le véhicule précédent
Réaction application de l'accélération, mise à jour de la vitesse et de la position
Si l'utilisateur décide d'un changement du mode, alors le véhicule passe au mode DISJ OIN T
Sinon, il poursuit dans le modeP LAT OON
But changement du modeP LAT OON au mode SOLO
Le véhicule fonctionne dans le mode P LAT OON
Il y a une demande de changement par l'utilisateur
Si le processus de décrochage échoue, alors le véhicule retourne au mode
P LAT OON s'il réussit, alors
Le véhicule passe dans le modeSOLO la dernière place dans le convoi est libérée
Quand la pré-condition est satisfaite, le processus de décrochage va passer par 3 étapes :
2 La permission est refusée quand
Ce véhicule n'est pas le dernier véhicule du convoi
Il existe un autre véhicule qui est en train d'accrocher ou de décrocher de ce convoi.
Dans ce cas, le véhicule doit retourner au modeP LAT OON
Dans le cas inverse, il entre dans la boucle du processus de décrochage.
Perception sa vitesse et sa position la vitesse et la position du véhicule précédent Décision nouvelle décélération pour s'éloigner du convoi
Réaction application de la décélération, mise à jour de la vitesse et de la position
Changement du mode calcule la distance avec le véhicule précédent ; si la distance est susamment importante pour un fonctionnement sûr dans le modeSOLO, le véhicule va passer au modeSOLO.
Si après un certain temps (timeout) le décrochage n'a pas eu lieu, le véhicule retourne au mode P LAT OON.
Structure du code CSP || B
Composant V ehicle
The Vehicle component supplies physical vehicle information, such as speed and position, to the DrivingSystem via the getVehicleInfo channel It receives acceleration data from the DrivingSystem through the vehicleAccel channel and applies it to the physical vehicle.
V ehicle(id) getSpeed , getXpos , setAccel vehicleInf o vehicleAccel
The interface between the Vehicle machine and the Vehicle controller consists of three key operations: speed←−getSpeed, which returns the vehicle's speed; xpos←−getXpos, which provides the vehicle's longitudinal position; and setAccel(accel), which applies the new acceleration.
Composant DrivingSystem
The DrivingSystem component is an extension of [5,6] Key additions include communication channels for interaction with N, the hciMode channel for receiving user-decided mode changes, and the hciParam channel for indicating the convoy to attach Additionally, two machine channels (getReachModeSolo and getReachModePlatoon) have been implemented to support the mode change process.
The DrivingSystem machine offers four key operations The setPerceptions function inputs values for the vehicle's speed and position, as well as those of the preceding vehicle The system then determines a new acceleration value through the getInfluences function, which varies based on the operating mode In the PLATOON mode, the goal is to maintain a safe distance within the convoy, while in the JOIN mode, the vehicle aims to close the gap with the last vehicle in the convoy.
The DrivingSystem interface includes various functions such as getInfluences, getReachModeSolo, and getReachModePlatoon, which help in managing vehicle information and acceleration parameters It facilitates requests for vehicle information and permissions, including requestVehicleInfo, requestPermissionJoint, and requestPermissionDisjoint Additionally, the system emits vehicle information and results through emitVehicleInfo, emitResultJoint, and emitResultDisjoint, while also handling responses with responseVehicleInfo and responsePermissionJoint.
In the DISJOIN mode, the ComposantDrivingSystem moves away from the preceding vehicle The function getReachModeSolo is utilized to determine if the vehicle can operate in SOLO mode while disengaging.
There are three scenarios regarding vehicle operation: first, the distance between the vehicle and the one ahead is adequate for it to function in SOLO mode; second, it cannot operate in SOLO mode as it cannot detach from its convoy; and third, the time limit for the detaching process has been exceeded (TIMEOUT) The function getReachModePlatoon serves a similar purpose as getReachModeSolo but is specifically designed for the coupling process.
Composant N et
CtrlN et transfère les demandes de CtrlDrivingSystem à la machine N et et les réponses de la machineN et au CtrlDrivingSystem.
There are six machine channels: The function updateVehicleInfo(vehicleId, speed, xpos) updates the vehicle's information The function getVehicleInfo(vehicleId) returns the information of the vehicle preceding vehicleId within the same convoy The permission for coupling is obtained through getPermissionJoint(vehicleId, platoonId), which allows a vehicle (vehicleId) to attach to a convoy (platoonId) if there are available spots, no ongoing attachments, and no ongoing detachments within that convoy.
Vérication
The article discusses various functions related to vehicle information and permission management, including retrieving and updating vehicle information, handling joint and disjoint permissions, and emitting results Key functions include getVehicleInfo, updateVehicleInfo, requestPermissionJoint, requestPermissionDisjoint, and their corresponding emit and response functions These operations facilitate efficient management and communication of vehicle data and permissions in a structured manner.
Fig 3.11: ComposantN et permis ←− getP ermissionDisjoint(vehicleId) : La permission de décrochage.
A vehicle can detach from a convoy if it is the last vehicle, there is no ongoing coupling, and no detachment is currently occurring The function setResultJoint(vehicleId, result) updates the outcome of the coupling process for the specified vehicle, while setResultDisjoint(vehicleId, result) updates the result of the detachment process.
Nous avons appliqué les techniques de vérication qui sont présentées dans la section 2.2.3 La modélisation CSP||B du système de véhicules est vériée.
Machine B is validated using AtelierB, where all proof obligations (POs) are demonstrated Out of a total of 57 POs, 7 must be proven interactively The proof strategies associated with the Interactive Proof tool of AtelierB are detailed in Appendix B.
The CSP controller is verified to be correct Using FDR2, we demonstrate that the CSP controllers, including CtrlVehicle, CtrlDrivingSystem, CtrlN, and CristaletCtrlSystem, are free from deadlocks and divergences Detailed structures of the CSP for the Cristal and CtrlSystem, along with the verification process, are provided in Appendix C.
La cohérence entre la machine B et son contrôleur CSP Dans cette étape,nous avons des machines de contrôle qui sont traduites automatiquement par
Discussion
Fig 3.12: Vérication de la machine B
Fig 3.13: Vérication du contrôleur CSP le traducteur Nous avons montré que toutes ces machines sont correctes Ainsi, nous avons la cohérence entre les machines B et leur contrôleur CSP.
One disadvantage of CSP||B modeling is that the communication and machine channels within the system are predetermined, limiting flexibility Both ends of a channel are also fixed, preventing the addition or removal of channels Consequently, it is impossible to extend the existing convoy model to incorporate coupling and decoupling processes If the current model were applied, adding or removing a communication channel between the last vehicle in a convoy and the current vehicle would be necessary when a vehicle couples or decouples This limitation is why the component N was introduced within the Cristal components, as it allows for the fixing of channels in the system.
Additionally, when a vehicle intends to attach to a convoy, it must gather essential information about the convoy, such as whether there is available space and if there are any other vehicles present.
3.5 Discussion 30 en cours d'accrochage sur ce convoi ? Dans ce cas, il va interrogerN et.
Is the role of N et akin to that of a conductor? This leads us to a more holistic perspective In our model, the operation of the vehicles is not controlled by N et; rather, the vehicles are autonomous They only receive necessary information from N et to determine the mode of operation Therefore, N et is not truly a conductor N et would be considered a conductor only if it controlled the functioning of all vehicles and if the role of the Crystal component was merely to execute N et's commands.
This model operates at an abstract level and requires ranking, resulting in either a centralized or decentralized structure based on the ranking One approach to enhance the model is to introduce a new sub-component, Perception, to each Crystal component This sub-component will gather information from vehicles within the system to create an increasingly detailed representation of the environment Consequently, the source of necessary information for the DrivingSystem component will be the Perception component.
P erception au lieu du composant N et En conséquence, dans le nouveau modèle,
P erception va répondre aux questions de DrivingSystem (comme la permission d'accrochage/décrochage, les informations sur le véhicule précédent) et N et est un intermédiaire d'échange des informations entre les véhicules.
Vérication de la cohérence entre la machine B et le contrôleur CSP
4.1 Cohérence entre la machine B et son contrôleur CSP 32
4.1.1 Control Loop Invariant - CLI 32 4.1.2 Les règles de traduction 34 4.2 Comment ỗa marche ? 34
4.3.1 Non pertinence 36 4.3.2 Variables homonymes 37 4.3.3 Typage 38 4.3.4 Recherche de la forme du CLI 38 4.4 Programmation en Ocaml 39 4.5 Test 41
This chapter addresses the issue of automatic verification of modeling in CSP||B The first section outlines the theoretical foundation for this verification, aiming to establish the consistency between the B machine and its CSP controller, as well as the methods for proving this consistency manually.
The CSP controller is effectively translated into a B machine, and coherence is achieved when this machine is proven In the following sections, we outline the implementation steps for software designed to automate the process of proving coherence between the B machine and the CSP controller.
Cohérence entre la machine B et son contrôleur CSP
4.1 Cohérence entre la machine B et son contrôleur CSP
The coherence between machine B and its CSP controller is dictated by the CSP||B approach, which mandates that a machine must execute any operation requested by its controller Operations within machine B are defined using a precondition structure: PRE THEN END According to B's semantics, these operations are always executable; however, their outcomes are not guaranteed if the precondition is not satisfied Therefore, ensuring coherence between machine B and its controller involves verifying that operations are invoked only when the preconditions are met.
When examining the relationship between machine B and its CSP controller, it can be viewed as a sequence of operation calls This allows for the translation of a CSP controller into a machine B Each CSP process is represented as a BBODY P, which contains the operation calls in the same order as those in the CSP controller The newly created machine B is verified using tools such as Atelier B.
Un contrôleur CSP est écrit sous la forme :
Où Ri contient des appels d'opérations B et l'ordre d'exécution de ces opérations. À la n de R i , il y a également un appel récursif S P avec0≤P ≤n.
We will translate CSP into a corresponding BBODY P The translation rules are outlined in the following section A CSP controller is translated as a machine B, referred to as the control machine In this control machine, we will introduce a variable cb that takes values from the set {0, 1, , n} This variable is termed the control variable as it signifies the execution order of CSP processes.
Sicb prend la valeuri, alors le processusR i sera exécuté.
Nous présentons ci-dessous le prototype de cette nouvelle machine de contrôle Elle se compose d'une machine abstraite et d'un ranement Il y a trois types de machines
4.1 Cohérence entre la machine B et son contrôleur CSP 33
B possibles : machine abstraite→ranement→implémentation Il y a trois raisons pour lesquelles la machine de contrôle est présentée sous cette forme.
Les événements dans le contrôleur CSP sont traités successivement Une machine abstraite n'autorise que les substitutions parallèles ; le traitement séquentiel n'est possible que dans les ranements et les implémentations.
In the implementation phase, all data and processes must be clearly defined The use of AN Y and CHOICE syntaxes, essential for translating CSP into B, is prohibited in implementations; however, these syntaxes are permissible in a refinement context.
Un ranement ne peut pas exister sans référer à une machine abstraite.
REFINEMENT BExecutive_ref REFINES BExecutive
INCLUDES M SEES Types VARIABLES cb, V INVARIANT cb ∈ 0 n ∧ I ∧ CLI INITIALISATION cb := 0 k
OPERATIONS Controls = BEGIN SELECT cb = 0 THEN BBODY0 cb := i WHEN cb = n THEN
Fig 4.1: Le prototype de la machine B traduite d'un contrôleur CSP
In the recursive process S_i, entering process S_i0 relies on the system's state established by process S_i Thus, the validity of the pre-condition for BBODY i0 is contingent upon the system's state upon exiting BBODY i To ensure that a BBODYP is correct concerning a process SP, it is essential to identify an invariant CLI that must be satisfied when transitioning from one BBODY to another.
(cb=x0 ⇒P0)∧(cb=x1⇒P1)∧ ∧(cb=xn⇒Pn)
Où P i est un prédicat qui se compose des états des variables (et du cb) P i est la pré-condition deBBODY i
Comment ỗa marche ?
Nous présentons ci-dessous les règles de traduction d'une structure CSP du con- trôleur en une structure B de la machine de contrôle :
{E name → P} = name; {P} {E name !w b → P} = name(w b ); {P} {Ename?xc → P(xc)} = xc ← name(); {P(xc)} {E name ?x c !w b → P(x c )} = x c ← name(w b ); {P(c x )}
{E name ?x c → P(x c )} = AN Y x c W HERE x c IN T T HEN {P(x c )}EN D
Où T est le type de xc Il est déni par la structure channelEname:T dans le chier de dénition des canaux. la compostion des processus :
{if x c then P else Q} = IF x c T HEN {P} ELSE {Q} EN D
Oùcb est la variable de contrơle.
The operational steps of the translator are illustrated in Figure 4.2 Starting from a CSP||B component, the translation process results in a machine B, which consists of an abstract machine and its implementation.
In this stage, the data processing step was developed using the tools Ocamllex and Ocamlyacc We need to create a file that describes the B and CSP languages in terms of sets of regular expressions and grammar rules for Ocamllex and Ocamlyacc By incorporating data processing functions, we compile a list of the necessary data required to build the control machine.
Machine abstraite La machine abstraite est simple (voir Figure 4.1) Quand on connaợt le nombre des processus CSP, on peut construire la machine abstraite.
1 Voir en détaille dans la section 4.4
Construire la machine abstraite Machine abstraite Éviter des non pertinences Éviter des homonymes Typage
Fig 4.2: Traduction de CSP en B
To construct the performance model, four key steps must be followed First, it is crucial to avoid non-relevant variables by ensuring consistency between machine B and its CSP controller, which confirms that all operators B are invoked with valid preconditions Consequently, the focus should solely be on the communication channels within the CSP processes The role of these communication channels is to relay information to other processes; if the information from a communication channel is only utilized by other channels, it does not need to be represented in the performance model Second, it is important to avoid ambiguities, as the variables in the performance model originate from the CSP controller and may also include variables from other machines B due to the use of clauses such as SEES, USES, and INCLUDES, thereby introducing potential risks.
Les problèmes à résoudre
In the CSP controller, variables can be declared without specifying their type However, in machine B, it is necessary to declare the type alongside the variable Therefore, when translating variables from the CSP controller to the control machine, it is essential to infer their types.
In this internship, the translator is unable to provide a complete Command Line Interface (CLI) due to the extensive work required to develop software akin to a language B compiler However, it is feasible to determine whether a CLI is necessary for the process If a CLI is deemed necessary, the translator will present its structure, aiding the user in easily creating and manually implementing the CLI.
Nous détaillons ces étapes dans la section suivante.
When verifying the consistency between machine B and its CSP controller, the only relevant information pertains to the machine channels Consequently, there are two types of irrelevance to consider.
In the example of the communication channels illustrated in Figure 2.5, the displaySpeed channel is deemed irrelevant This irrelevance arises because some channels only accept inputs, such as displaySpeed, which takes in speed, and displayInfo, which takes in position, speed, and distance Additionally, certain channels may include output parameters; however, these parameters are not utilized by any machine channel, further contributing to their lack of relevance.
Processus = getPrecedantSpeed ? v → getDistance ? d → setSpeed ! v → displayInfo ! v ! d → Processus
Où getPrecedantSpeed, getDistance et displayInfo sont les canaux de commu- nication, et
4.3 Les problèmes à résoudre 37 setSpeed est un canal de machine.
Alors, dans ce cas, les deux canaux getDistance et displayInfo sont non pertinents.
In a CSP process, parameters, such as those found in the Action(distance, speed) process within the exampleRobot, play a crucial role A parameter is considered irrelevant if it is utilized solely by non-relevant channels.
Dans la machine de contrôle, il y a deux types des variables,
Les variables globales : elles ont pour origine les paramètres des processus CSP. Pour éviter les homoymies, elles sont préxées par le nom de la machine.
Local variables are generated by the output parameters of a channel For instance, in the channel getSpeed !id ?speed (which queries the speed of a vehicle with the identifier id), the variable id already exists, while the variable speed is newly declared and is immediately utilized In this context, it is prefixed by the channel's name.
Le code CSP La traduction en B
Le canal de communication : getSpeed?speed → AN Y getSpeed_speed
W HERE getSpeed_speed :∈ SP EEDS
Le canal de machine : getSpeed?speed → V AR getSpeed_speed IN getSpeed_speed ←− getSpeed()
EN D Dans cette étape, le nom des variables est changé également quand il est dans un des cas ci-dessous :
Il se compose d'un seul caractère Dans ce cas, il est doublé car un nom de variable en B se compose d'au moins 2 caractères.
Il est identique à un mot clé de B Les mots clé de B sont sensibles à la casse.
Nous modions donc la casse de certaines lettres des identicateurs pour les diérencier Ainsi la variable id, un mot clé de B, est traduite en Id.
It is essential to infer the variable types within the control machine Identifying the types of local variables is straightforward, as they are specified in the channel prototypes, detailing the parameter types For instance, in the channel getSpeed ?speed, the variable type for speed is SPEEDS, which can be derived from the prototype of the channel getSpeed: SPEEDS.
Pour inférer le type d'une variable globale, nous nous basons sur son utilisation.
Elle est utilisée dans une expression : on peut déduire son type d'après la table des opérations ci-dessous
In programming, operations such as addition (+), subtraction (-), multiplication (*), and division (/) are fundamental, along with comparison operators like greater than (>), greater than or equal to (>=), less than ( MIN_DISTANCE_2PLATOON)
Composant N et
118 ELSE IF (preXpos − myXpos < MAX_DISTANCE_2VEHICLE)
122 ELSE IF (preSpeed = MAX_SPEED)
A.4.1 Le contrôleur CSP : Net.csp
15 −−− Mise a jours les informations des vehicules dans la base de donnees
17 emitVehicleInfo id ? speed ? xpos → updateVehicleInfo ! id ! speed ! xpos →
21 requestVehicleInfo id → getVehicleInfo ! id ? speed ? xpos →
27 getPermissionJoint ! id ! platoon_id ? permi →
35 requestVehicleInfo id → getVehicleInfo ! id ? speed ? xpos →
41 emitResultJoint id ? result → setResultJoint ! id ! result →
47 requestPermissionDisjoint id → getPermissionDisjoint ! id ? permi →
55 requestVehicleInfo id → getVehicleInfo ! id ? speed ? xpos →
61 emitResultDisjoint id ? result → setResultDisjoint ! id ! result →
13 / ∗ Liste IDS platoon, chaque platoon se compose des vehicules ∗ /
16 / ∗ Taille d'un platoon ne peut pas passer un nombre xe ∗ /
17 ∀ ind.( ind ∈ (PLATOONS) ⇒ size(PlatoonSET(ind)) ≤ MAX_LENGTH_PLATOON) ∧
18 / ∗ Etat d'un platoon ∈ TRUE (il y a processus d'accrochage ou de decrochage), sinon FALSE ∗ /
21 SpeedSET ∈ IDS → SPEEDS ∧ / ∗ Liste des vitesses des vehicules ∗ /
22 XposSET ∈ IDS → POSITIONS / ∗ Liste des positions ∗ /
31 / ∗ Mise a jours des informations de " vehiculeId " ∗ /
42 / ∗ Acquierir des informations d'un vehicule
43 qui est precedent de ' vehicleId '
49 IF ( ∃ pId (pId ∈ PLATOONS ∧ vehicleId ∈ ran(PlatoonSET(pId)))) ∧ / ∗ Existe dans un platoon ∗ /
50 ( ∀ pId (pId ∈ PLATOONS ⇒ vehicleId 6= rst(PlatoonSET(pId)))) / ∗ Pas le leader ∗ /
58 WHERE / ∗ L'index de vehicule precedent ? ∗ /
62 xpos := XposSET(PlatoonSET(platoonId)(preIndex)) k
63 speed := SpeedSET(PlatoonSET(platoonId)(preIndex))
72 / ∗ Un vehicule peut joindre a un platoon ? ∈
73 − La taille du platoon ≤ MAX_LENGTH_PLATOON
74 − Il n'y a pas d'autre vehicule qui est entrain de joindre a ce platoon
75 − Il n'y a pas de decrochage dans ce platoon
84 ELSIF ∃ pId.(pId ∈ PLATOONS ∧ vehicleId ∈ ran(PlatoonSET(pId))) / ∗ existe dans un platoon ∗ /
95 IF size (PlatoonSET(platoonId)) < MAX_LENGTH_PLATOON ∧
100 PlatoonSET(platoonId) := PlatoonSET(platoonId) ← - vehicleId
107 / ∗ Un vehicule peut disjoindre d'un platoon quand ∈
108 − Il est a la n du platoon
109 − Il n'y a pas d'autre vehicule qui est entrain de joindre a ce platoon
115 IF ( ∃ pId (pId ∈ PLATOONS ∧ vehicleId ∈ ran(PlatoonSET(pId)))) / ∗ Existe dans un platoon ∗ /
122 IF vehicleId 6= last(PlatoonSET(platoonId)) ∧ / ∗ A la n du platoon ? ∗ /
123 platoonId / ∈ PlatoonBusy / ∗ Platoon est libre ? ∗ /
136 / ∗ Si le processus d'accrochage est echoue,
137 On doit supprimer le vehicule qui a accroche dans la liste de platoon
144 / ∗ ( ∃ pId (pId ∈ PLATOONS ∧ vehicleId ∈ ran(PlatoonSET(pId)))) ⇔ Existe dans un platoon ∗ /
154 PlatoonSET := {platoonId} C − PlatoonSET k / ∗ Supprimmer un platoon ∗ /
156 ELSIF size(PlatoonSET(platoonId)) ≤ MAX_LENGTH_PLATOON THEN
157 / ∗ PlatoonSET(platoonId) := PlatoonSET(platoonId) B − {vehicleId} ∗ /
158 PlatoonSET(platoonId) := (PlatoonSET(platoonId) /| \ PlatoonSET(platoonId) −1 (vehicleId)
− 1) a (PlatoonSET(platoonId) \ |/ PlatoonSET(platoonId) −1 (vehicleId))
182 ELSIF size(PlatoonSET(platoonId)) ≤ MAX_LENGTH_PLATOON THEN
183 / ∗ PlatoonSET(platoonId) := PlatoonSET(platoonId) B − {vehicleId} ∗ /
184 PlatoonSET(platoonId) := PlatoonSET(platoonId) /| \ PlatoonSET(platoonId) −1 (vehicleId)
− 1 a PlatoonSET(platoonId) \ |/ PlatoonSET(platoonId) −1 (vehicleId)
Nous présentons ci-dessous les commandes de preuve en utilisant outil Interactive Proof de l'AtelierB pour démonter les PO qui requièrent une preuve interactive : Machine N et :
- PO01 : (0) & mp & ah(platoonId : IDS & vehicleId : IDS) & pr & pr & pp(rp.1)
- PO06 : (0) & mp & ah(vehicleId : IDS) & pp(rp.1) Dans l'opérationsetResultJ oint
- PO06 : (0) & mp & pp(rp.1) & pr Dans l'opérationsetResultDisjoint
- PO06 : (0) & mp & pp(rp.1) & pr Machine V ehicle : Dans l'opération setAccel
15 (CtrlDrivingSystem(id) [| Vehicle_DrivingSystem |] CtrlVehicle (id))
26 (CtrlNet) [| DrivingSystem_Net|] ( 9 id :IDS @ Cristal (id) )
La vérication de la cohérence des composants
La machine traduite du contrôleur CSP CtrlV ehicle
2 Il faut ajouter une invariance
D.1 La machine traduite du contrôleur CSP CtrlV ehicle 65
27 / ∗ Vehicle_ref_Id := Vehicle_ref_Id; ∗ /
30 WHEN cb = 1 THEN / ∗ CtrlVehicle_perceptions ∗ /
38 / ∗ Vehicle_ref_Id := Vehicle_ref_Id; ∗ /
50 / ∗ Vehicle_ref_Id := Vehicle_ref_Id; ∗ /
57 WHEN cb = 2 THEN / ∗ CtrlVehicle_actions ∗ /
62 / ∗ Vehicle_ref_Id := Vehicle_ref_Id; ∗ /
La machine traduite du contrôleur CSP CtrlDrivingSystem
D.2 La machine traduite du contrôleur CSP CtrlDrivingSystem
2 Il faut ajouter une invariance
28 WHEN cb = 1 THEN / ∗ CtrlDrivingSystem_process ∗ /
31 IF (DrivingSystem_ref_mode = SOLO)
D.2 La machine traduite du contrôleur CSP CtrlDrivingSystem 67
38 IF (DrivingSystem_ref_mode = PLATOON)
45 IF (DrivingSystem_ref_mode = JOINT)
52 IF (DrivingSystem_ref_mode = DISJOINT)
74 ANY vehicleInfo_myXpos, vehicleInfo_mySpeed
75 WHERE vehicleInfo_myXpos ∈ POSITIONS ∧ vehicleInfo_mySpeed ∈ SPEEDS
77 ANY reponseVehicleInfo_preSpeed, reponseVehicleInfo_preXpos
78 WHERE reponseVehicleInfo_preSpeed ∈ SPEEDS ∧ reponseVehicleInfo_preXpos ∈ POSITIONS
80 setPerceptions (vehicleInfo_myXpos, vehicleInfo_mySpeed, reponseVehicleInfo_preXpos, reponseVehicleInfo_preSpeed);
D.2 La machine traduite du contrôleur CSP CtrlDrivingSystem 68
118 WHEN cb = 5 THEN / ∗ Joint_process ∗ /
119 ANY vehicleInfo_myXpos, vehicleInfo_mySpeed
120 WHERE vehicleInfo_myXpos ∈ POSITIONS ∧ vehicleInfo_mySpeed ∈ SPEEDS
122 ANY reponseVehicleInfo_lstSpeed, reponseVehicleInfo_lstXpos
123 WHERE reponseVehicleInfo_lstSpeed ∈ SPEEDS ∧ reponseVehicleInfo_lstXpos ∈ POSITIONS
125 setPerceptions (vehicleInfo_myXpos, vehicleInfo_mySpeed, reponseVehicleInfo_lstXpos, reponseVehicleInfo_lstSpeed );
D.2 La machine traduite du contrôleur CSP CtrlDrivingSystem 69
137 IF getReachModePlatoon_result = NEVER ∨ getReachModePlatoon_result =
165 WHEN cb = 7 THEN / ∗ Disjoint_process ∗ /
166 ANY vehicleInfo_myXpos, vehicleInfo_mySpeed
167 WHERE vehicleInfo_myXpos ∈ POSITIONS ∧ vehicleInfo_mySpeed ∈ SPEEDS
169 ANY reponseVehicleInfo_lstSpeed, reponseVehicleInfo_lstXpos
170 WHERE reponseVehicleInfo_lstSpeed ∈ SPEEDS ∧ reponseVehicleInfo_lstXpos ∈ POSITIONS
172 setPerceptions (vehicleInfo_myXpos, vehicleInfo_mySpeed, reponseVehicleInfo_lstXpos, reponseVehicleInfo_lstSpeed );
184 IF getReachModeSolo_result = NEVER ∨ getReachModeSolo_result = TIMEOUT
La machine traduite du contrôleur CSP CtrlN et
D.3 La machine traduite du contrôleur CSP CtrlN et
2 Il faut ajouter une invariance
3 CLI = ((cb = 7) ⇒ P_7) ∧ ((cb = 6) ⇒ P_6) ∧ ((cb = 5) ⇒ P_5) ∧ ((cb = 4) ⇒ P_4) ∧ ((cb = 3) ⇒ P_3) ∧ ((cb = 2) ⇒ P_2) ∧ ((cb = 1) ⇒ P_1)
D.3 La machine traduite du contrôleur CSP CtrlN et 71
42 / ∗ Net_ref_Id := Net_ref_Id; ∗ /
45 / ∗ Net_ref_Id := Net_ref_Id; ∗ /
48 / ∗ Net_ref_Id := Net_ref_Id; ∗ /
51 / ∗ Net_ref_Id := Net_ref_Id; ∗ /
56 ANY emitVehicleInfo_speed, emitVehicleInfo_xpos
57 WHERE emitVehicleInfo_speed ∈ SPEEDS ∧ emitVehicleInfo_xpos ∈ POSITIONS
59 updateVehicleInfo (Net_ref_Id, emitVehicleInfo_speed, emitVehicleInfo_xpos);
60 / ∗ Net_ref_Id := Net_ref_Id; ∗ /
65 VAR getVehicleInfo_speed, getVehicleInfo_xpos IN
66 getVehicleInfo_speed, getVehicleInfo_xpos ←− getVehicleInfo (Net_ref_Id);
67 / ∗ Net_ref_Id := Net_ref_Id; ∗ /
D.3 La machine traduite du contrôleur CSP CtrlN et 72
73 WHERE requestPermissionJoint_platoon_id ∈ IDS
76 getPermissionJoint_permi ←− getPermissionJoint(Net_ref_Id, requestPermissionJoint_platoon_id);
79 / ∗ Net_ref_Id := Net_ref_Id; ∗ /
82 / ∗ Net_ref_Id := Net_ref_Id; ∗ /
88 WHEN cb = 5 THEN / ∗ ManageJoint_process ∗ /
89 VAR getVehicleInfo_speed, getVehicleInfo_xpos IN
90 getVehicleInfo_speed, getVehicleInfo_xpos ←− getVehicleInfo (Net_ref_Id);
93 / ∗ Net_ref_Id := Net_ref_Id; ∗ /
100 setResultJoint (Net_ref_Id, emitResultJoint_result);
101 / ∗ Net_ref_Id := Net_ref_Id; ∗ /
111 getPermissionDisjoint_permi ←− getPermissionDisjoint (Net_ref_Id);
114 / ∗ Net_ref_Id := Net_ref_Id; ∗ /
117 / ∗ Net_ref_Id := Net_ref_Id; ∗ /
122 WHEN cb = 7 THEN / ∗ ManageDisjoint_process ∗ /
123 VAR getVehicleInfo_speed, getVehicleInfo_xpos IN
D.3 La machine traduite du contrôleur CSP CtrlN et 73
124 getVehicleInfo_speed, getVehicleInfo_xpos ←− getVehicleInfo (Net_ref_Id);
127 / ∗ Net_ref_Id := Net_ref_Id; ∗ /
134 setResultDisjoint (Net_ref_Id, emitResultDisjoint_result );
135 / ∗ Net_ref_Id := Net_ref_Id; ∗ /
Pré-requis
The project aims to translate CSP code into B text and to explore the structure of CLI It is essential to understand the syntax of CSP and B languages, as well as the description of mly and mll files used by ocamllex and ocamlyacc for syntax recognition in these languages Additionally, knowledge of CLI theory, including translation rules and CLI structure found in section 4.1 of the report, is necessary, along with proficiency in the OCaml programming language.
We developed this project using OCaml version 3.11.1 with Eclipse and the OCaml mode 1 The translator functions effectively on Ubuntu versions 8.04, 8.10, 9.04, 9.10, as well as on Windows XP Additionally, we utilize the tools ocamllex and ocamlyacc, which are included in the OCaml distribution.
Structure du projet
Le code du projet est contenu dans le répertoire src qui se compose de deux paquetages b et csp :
Mode d'emploi
The modules.ml package csp is designed to analyze the CSP controller found in a csp file, eliminate irrelevant elements, perform typing, and determine the structure of the CLI.
Il comporte l'essentiel du traducteur. le paquetage b a pour but d'analyser la machine B (qui est dans un chier mch)
Using Eclipse with OCaml mode, compilation is seamlessly executed with a simple mouse click The output is the executable file named "main," which is located in the bin/src directory.
To utilize a CSP component, it is essential to have two files: X.csp for the controller and X.mch for the machine Both files must share the same name, such as Vehicle.csp for the controller and Vehicle.mch for the machine, to ensure proper functionality.
Nous utilisons le chier main pour générer la machine de contrôle à partir de ce composant CSP||B :
After execution, we obtain the control machine, which consists of the abstract machine detailed in the file Vehicle_abs.mch and the refinement outlined in the file Vehicle_ref.ref.
Les modules
Il faut d'abord dénir la structure d'un contrôleur CSP (chier csptypes.ml) et d'une machine B (chier blast.ml) Par exemple :
10 | GroupeChannel of string ∗ ( string list )
A CSP controller consists of three main components: Include, which specifies the name of the included file; Definition, which encompasses essential definitions such as data types and channel prototypes; and Process, which illustrates the controller's processes This article will elaborate on these definitions, particularly focusing on the Definition section in the provided example.
Quand on a dénit la structure d'un contrôleur CSP, on peut déclarer une variable de ce type pour contenir les données d'un contrôleur qui est lu de chier csp.
The process of reading csp files and transferring the results into a variable is automatically managed by the tools Ocamllex and Ocamlyacc These tools require mll and mly description files as input, where the mll file contains the lexical description and the mly file contains the grammar description Specifically, this is applicable for CSP with csplexer.ml and cspparser.mly, as well as for B with blexer.mll and bparser.mly For detailed usage of these tools, refer to the official OCaml documentation at [caml.inria.fr](http://caml.inria.fr/pub/docs/manual-ocaml/manual026.html).
After this step, we can read a file (.mch or csp) and store the results in a variable For instance, after executing this code, we have the variable 'amn' which contains the data of the machine as described in the file Vehicle.mch.
1 print_string ("\nLecture du chier B : [ Vehicle mch]\n");
2 let amn = Bparser.amn Blexer.token (Lexing.from_channel (open_in ("Vehicle.mch"))) in
3 print_string " == i OK\n"; ush stdout;
La machine abstraite est construite facilement :
1 let write_machine_abs le_name ((name,params), clause) cproc_lst =
3 let f = open_out (le_name ^ "_abs.mch") in
5 let out = (Printf fprintf ) in
6 let len = (List length cproc_lst) − 1 in
7 let spc = (get_space 1) in
8 out f "MACHINE %s_abs" le_name;
10 let str = (B2string list2string ", " B2string id2string params) in
15 let rec print_clauses cl =
19 match List.hd(cl) with
20 Blast Constraints c → out f "CONSTRAINTS\n%s %s\n" spc (B2string.predicat2string c)
23 print_clauses ( List tl cl )
29 out f "INVARIANT\n%s cb : 0 %d\n" spc len;
33 out f "%sBEGIN cb :: 0 %d END\n" spc len;
In this context, ((name, params), clause) denotes machine B, identified by the name 'name', with specified parameters 'params' and substitutions 'clause' Additionally, cproc_lst refers to a collection of CSP processes within the controller.
Après cette étape, nous avons un chier indiqué par la variable f ile_name Ce chier contient la machine abstraite.
Cette partie du code est contenue dans le chier redondance.ml Nous détaillons les fonctions dans ce chier :
First, we have functions designed to assess the necessity of variables For instance, the function is_necessary_in_body takes a string and a list of process_body elements, returning a boolean value Its purpose is to determine whether a variable is essential within a given list of process_body.
1 val is_necessary_in_body : string → Csptypes.process_body list → bool
3 val is_necessary_in_body_list : string → Csptypes.process_body list list → bool
5 val is_necessary_in_ope : string → Csptypes.process_body → bool
7 val is_necessary_in_channel : string → string → Csptypes.channel_param list → bool
9 val is_necessary_in_expr_list : string → Csptypes.expr list → bool
11 val is_necessary_in_expr : string → Csptypes.expr → bool
13 val is_necessary_in_if : string →
15 Csptypes.process_body list → Csptypes.process_body list → bool
17 val is_necessary_in_lambda : string → Csptypes.expr → Csptypes.process_body list → bool
Ensuite, nous évitons les non pertinences
1 val remove_redondance_in_body : Csptypes.process_body list → Csptypes.process_body list
3 val remove_redondance_in_body_list : Csptypes.process_body list list →
4 Csptypes.process_body list list
6 val remove_redondance_in_ope : Csptypes.process_body →
7 Csptypes.process_body list → Csptypes.process_body list
9 val remove_redondance_in_channel : string →
11 Csptypes.process_body list → Csptypes.process_body list
13 val remove_redondance_in_process : string ∗ string list ∗ Csptypes.process_body list →
14 string ∗ bool list ∗ Csptypes.process_body list
16 val remove_redondance : (string ∗ string list ∗ Csptypes.process_body list ) list →
17 ( string ∗ string list ∗ Csptypes.process_body list ) list
L'élimination des homonymes est traitée dans le chier change_name.ml.
First, we develop functions to rename variables within structures, such as the body of the CSP process (change_name_variable_in_body) and the body list (change_name_variable_in_body_list), among others.
2 val change_name_variable_in_body : string → string → Csptypes.process_body list → Csptypes. process_body list
4 val change_name_variable_in_body_list : string →
5 string → Csptypes.process_body list list → Csptypes.process_body list list
7 val change_name_variable_in_ope : string → string → Csptypes.process_body → Csptypes. process_body
9 val change_name_variable_in_expr : string → string → Csptypes.expr → Csptypes.expr
11 val change_name_variable_in_channel : string →
12 string → string ∗ Csptypes.channel_param list → Csptypes.process_body
14 val change_name_variable_in_set : string → string → Csptypes.set → Csptypes.set
Next, we avoid homonyms The function change_name_variable adds a prefix (string) before the parameters of a CSP process Meanwhile, the function change_name_parametre_channel_in_body adds a prefix (which is the channel name) before the parameters of each channel within a CSP process.
1 val change_name_variable : string →
2 ('a ∗ string list ∗ Csptypes.process_body list ) list →
3 ('a ∗ string list ∗ Csptypes.process_body list ) list
5 val change_name_parametre_channel_in_body : Csptypes.process_body list → Csptypes.process_body list
Tout le code est contenu dans le chier variable.ml.
We have functions designed to determine the type of a variable For instance, the function get_type_from_body identifies the variable type within a CSP process body.
1 val get_type_from_body : string → Csptypes.process_body list → string
3 val get_type_from_body_list : string → Csptypes.process_body list list → string
5 val get_type_from_ope : string → Csptypes.process_body → string
7 val get_type_from_channel : string → string → Csptypes.channel_param list → string
9 val get_type_from_expr_list : string → Csptypes.expr list → string
11 val get_type_from_expr : string → Csptypes.expr → string
13 val get_type_of_expr : string → Csptypes.expr → string
15 val get_type_from_denition : string → string
17 val get_type_from_if : string →
19 Csptypes.process_body list → Csptypes.process_body list → string
21 val get_type_from_lambda : string → Csptypes.expr → Csptypes.process_body list → string
Using basic functions, we develop a function designed to identify the type of all global variables This function returns three forms of variables utilized in the VARIABLES, INVARIANT, and INITIALISATION substitutions of the B machine.
1 val get_variable_global : ('a ∗ string list ∗ Csptypes.process_body list ) list →
The function get_cli_in_process_list is used to search for the CLI within the CSP process list of the controller The function cli2string converts the found CLI from the previous function into a string, which is then written to the control machine's file.
Le code se trouve dans le chier cli.ml du paquet csp
1 val get_cli_in_process_list : ( string ∗ string list ∗ 'a) list → ( string ∗ int ∗ string list ) list
3 − name : string (nom de processus)
6 CLI : ((cb = index) = i P( variable_list )) & ((cb = index) = i P( variable_list )) &
9 val cli2string : ('a ∗ int ∗ string list ) list → string
En utilisant les fonctions ci-dessus, nous pouvons construire le ranement de la machine de contrôle :
2 write_renement le_name ((name,params), clause) cproc_lst cdef_lst =
3 let f = open_out (le_name ^ "_ref.ref") in
4 let out = (Printf fprintf ) in
5 print_string "\n eliminer des non pertinences\n"; ush stdout;
6 let channel_communication_lst = get_channel_communication clause cdef_lst in
8 Redondance.channel_communication_prototype := channel_communication_lst;
9 let cproc_lst = Redondance.remove_redondance cproc_lst in
11 print_string "\n changer le nom des variables \n"; ush stdout;
12 ( ∗ changer les noms des variables ∗ )
13 let cproc_lst = Change_name.change_name_variable (le_name ^ "_ref") cproc_lst in
15 print_string "\n chercher les types des variables \n"; ush stdout;
17 let chan_lst = List.map (fun x → match x with Csptypes.Channel (n,p) → [(n,p)] | _ → ) cdef_lst
19 Variable cdef_lst := cdef_lst ;
20 Variable cchan_lst := List fold_left List append chan_lst;
22 let (var , inv , ini ) = Variable.get_variable_global cproc_lst in
24 print_string "\n chercher le CLI : "; ush stdout;
26 let cli = Cli.get_cli_in_process_list cproc_lst in
27 let cli = Cli cli2string cli in
30 print_string "Oui, il doit ajouter une invariance \n";
32 out f " Il faut ajouter une invariance \n CLI = %s\n" cli ;
35 else print_string " Non, il n'a pas besoin d' ajouter une invariance \n";
37 let bope = ref ( : string list ) in
38 let spc = (get_space 1) in
41 let str = (B2string list2string ", " B2string id2string params) in
47 print_string "\n ecriture du chier de ranement\n"; ush stdout;
49 out f "REFINEMENT %s_ref%s\n" le_name params_str;
51 out f "REFINES %s\n" (le_name ^ "_abs");
53 out f "INCLUDES %s%s\n" le_name params_str;
55 let rec print_clauses cl =
59 match List.hd(cl) with
61 out f "SEES\n%s %s\n" spc (B2string.list2string ", " B2string id2string s)
63 bope := List map (fun (name, i, o, b) → (B2string id2string name) ) ope_lst
66 print_clauses ( List tl cl )
71 let clen = (List length cproc_lst) − 1 in
72 out f "VARIABLES\n%scb%s\n" spc var;
73 out f "INVARIANT\n%scb : 0 %d%s\n" spc clen inv;
74 out f "INITIALISATION\n%scb := 0%s\n" spc ini;
78 let spc2 = (get_space 2) in
80 let cproc_arr = Array of_list cproc_lst in
82 Csp2string csp_process_prototype := cproc_lst;
83 Csp2string channel_communication_prototype := channel_communication_lst;
86 let (name, params, body) = cproc_arr.(i) in
88 out f "%sSELECT cb = 0 THEN / ∗ %s ∗ / \n" spc2 name
90 out f "\n%sWHEN cb = %d THEN / ∗ %s ∗ / \n" spc2 i name
92 let lst = Csp2string process_operation_list body in
93 List iter (fun x → (out f "%s%s" spc2 x)) lst;