Vous êtes sur la page 1sur 80

N dordre :

REPUBLIQUE TUNISIENNE
MINISTERE DE LENSEIGNEMENT SUPERIEUR
ET DE LA RECHERCHE SCIENTIFIQUE

UNIVERSITE DE MONASTIR

FACULTE DES SCIENCES DE MONASTIR

MMOIRE
Prsent pour lobtention du diplme de :

Mastre de recherche en informatique


Spcialit :

Systmes de Raisonnement Automatique


Par :

Ezzine MISSAOUI
Sujet :

Vers une approche de spcification formelle de systmes


complexes : Application aux systmes de transport
voluant dans un environnement dynamique

Soutenu le ../../2014, devant le jury compos de :


Dr. Mohamed Ali MAHJOUB

Prsident

Matre de Confrences, ENISO

Dr. Mohamed GRAIET

Rapporteur

Matre Assistant, ISIMM

Dr. Belhassen MAZIGH

Encadrant

Matre Assistant, FSM

Remerciements
Je tiens tout dabord remercier mon encadrant de mmoire, M. Belhassen MAZIGH,
Matre-assistant la Facult des Sciences de Monastir (FSM), pour son encadrement
exemplaire. Je le remercie d'avoir accept de me confier le prsent travail et pour les conseils
prcieux quil ma donn.
Je souhaite aussi remercier M. Mohamed GRAIET, Matre-assistant l'Institut
Suprieur d'Informatique et de Mathmatiques de Monastir (ISIMM), pour mavoir fait
lhonneur de rapporter sur mon travail de mmoire et davoir consacr son temps lexamen de
mon mmoire de mastre. Merci galement M. Mohamed Ali MAHJOUB, Matre de
confrences cole Nationale d'Ingnieurs de Sousse (ENISO), davoir prsid le jury de mon
mmoire de mastre.
Un grand merci pour Mohamed GAROUI. Merci pour toutes les aides que tu mas apports,
surtout au dbut de mon travail de mmoire. Merci aussi pour ta gnrosit scientifique, ta
disponibilit et ton amiti.
Je voudrais remercier aussi les amis du laboratoire Prince - Monastir pour leurs soutiens
sincres, leurs encouragements et leurs sympathies.
Finalement, merci toute ma famille qui ma toujours support et encourag avec une
confiance inconditionnelle.

Rsum
Ce travail se situe dans le cadre du projet SafePlatoon, qui a pour objectif d'tudier la
scurit des systmes de transports constitus de vhicules qui se dplacent en convoi
("platoon") dans un environnement dynamique. Pour lanalyse de la scurit de ce type de
systme, des mthodes formelles doivent tre proposs. La validation sera effectue sur des
systmes de transport constitus de vhicules lectriques autonomes.
Chaque vhicule du platoon change des informations avec le vhicule qui le prcde pour
ajuster sa vitesse afin de maintenir une distance convenable par rapport son prdcesseur,
dont l'objectif est que la scurit du convoi soit garantie. La gestion du systme peut tre
centralise ou dcentralise. Dans le cas centralis, une entit indpendante, appele point
d'accs (Access Point), est responsable de la centralisation des informations de lensemble du
convoi et de prendre les dcisions pour modifier les caractristiques de l'ensemble des
vhicules. Par contre, dans le cas dcentralis, les vhicules voluent en se basant sur les
connaissances locales et en communiquant avec les autres vhicules en utilisant la
communication sans fil (WIFI) ou bien des capteurs embarqus.
Les domaines dapplication du projet SafePlatoon visent les systmes de transport urbain,
les convois dans les milieux agricoles ainsi que les convois militaires. Donc, il devient
impratif que le cycle de conception comporte une phase de certification dans ces types
dapplications. Lobjectif de ce travail est dtablir, avec la force dune preuve que chaque
application doit satisfaire un ensemble de proprits de sret.
La vrification formelle apparat comme une mthode possible pour la certification de ces
proprits de sret. Tout dabord, nous avons proposs un modle gnrique d'un systme de
platoon, en tenant compte :
(i)
des diffrents domaines d'application (urbain, agricole et militaire),
(ii)
de diffrentes configurations gomtriques (ligne, colonne et chelon)
(iii) et de l'intgration des capacits d'volution du platoon (insertion/jection,
changement de configuration, vitement d'obstacle, etc.).
Nous avons adopts une stratgie de vrification de proprits de scurit, en valuant des
proprits de scurit de base telle que la non-collision des vhicules constituant un platoon.
Cette stratgie comporte les techniques de preuve par thorme (theorem-proving) pour la
conception, la vrification et la validation des systmes en utilisation une mthode formelle,
Event-B, et un outil de mise en uvre, Rodin.
Pour consolider notre proposition, nous avons valids nos spcifications par simulation. La
validation concerne la mise en uvre dun jeux de test, travers la simulation, en utilisant des
outils d'animation. Le comportement observer, durant une animation, est naturellement
dpendant de la nature de la spcification.
Mots cls : approche gnrique, platoon, scurit, vrification formelle, techniques de preuve
par thorme, Event-b, Rodin,
2

Table des matires

1 INTRODUCTION............................................................................................................7
1.1 Contexte ............................................................................................................................... 7
1.2 Objectif ................................................................................................................................ 8
1.3 Structure du rapport............................................................................................................ 9

2 ETAT DE L'ART ........................................................................................................... 10


2.1 Projets lis aux problmatiques des vhicules se dplaant en convoi ................................. 10
2.1.1
2.1.2
2.1.3
2.1.4

Introduction ........................................................................................................................................... 10
Projets de recherche relatifs au domaine des transports ........................................................................ 10
Dautre projets europens et internationaux ......................................................................................... 13
Conclusion ............................................................................................................................................ 14

2.2 Notions de sret de fonctionnement .................................................................................. 14


2.2.1 Dfinition .............................................................................................................................................. 14
2.2.2 Concepts de sret de fonctionnement .................................................................................................. 14
2.2.2.1 Attributs de la sret de fonctionnement ........................................................................................ 15
2.2.2.2 Entraves la sret de fonctionnement .......................................................................................... 15
2.2.2.3 Moyens pour la sret de fonctionnement ..................................................................................... 16

2.3 Les langages formels .......................................................................................................... 17


2.3.1 Introduction ........................................................................................................................................... 17
2.3.2 Les langages formels et les outils de vrification .................................................................................. 17
2.3.2.1 Quelques dfinitions de base .......................................................................................................... 18
2.3.2.2 Quelques langages formels ............................................................................................................ 18
2.3.2.2.1 Le langage Z ......................................................................................................................... 18
3.2.2.2.3 La boite outils SAL ........................................................................................................... 20
3.2.2.2.4 La mthode B ....................................................................................................................... 21
3.2.2.2.5 Event-B ................................................................................................................................. 23
3.2.2.2.6 RODIN : loutil support dEvent-B ..................................................................................... 27
3.2.3 Conclusion ............................................................................................................................................. 28

2.4 Les travaux existants.......................................................................................................... 28

3 APPROCHE PROPOSE .............................................................................................. 30


3.1 Etude informelle ................................................................................................................ 30
3.1.1 Introduction .......................................................................................................................................... 30
3.1.2 Description des perturbations ............................................................................................................... 30
3.1.2.1 Perturbation momentanes ............................................................................................................ 31
3.1.2.2 Perturbation permanentes .............................................................................................................. 31
3.1.3 Description des mtriques .................................................................................................................... 32
3.1.4 Prsentation du comportement d'un platoon ......................................................................................... 33
3.1.5 Les configurations ................................................................................................................................ 37
3.1.6 Prsentation des diffrents algorithmes du comportement d'un convoi ................................................. 39

3.1.7 Modes de fonctionnement du systme .................................................................................................. 42


3.1.8 Conclusion ............................................................................................................................................. 44

3.2 Etude mathmatique .......................................................................................................... 44


3.2.1
3.2.2
3.2.3
3.2.4
3.2.5

Introduction ........................................................................................................................................... 44
Perception, prise de dcision et raction ................................................................................................ 45
quations mathmatiques relatives la perception ............................................................................... 46
quations mathmatiques relatives la dcision ................................................................................... 48
Conclusion ............................................................................................................................................. 49

3.3 Etude formelle.................................................................................................................... 49


3.3.1 Introduction ........................................................................................................................................... 49
3.3.2 Spcification et vrification formelle du modle .................................................................................. 49
3.3.2.1 Prsentation du modle Event-B d'un platoon ............................................................................... 49
3.3.2.2 Prsentation de la machine abstraite : Mouvement_0 .................................................................... 53
3.3.2.2.1 Spcification formelle en Event-B ....................................................................................... 54
3.3.2.2.2 Vrification formelle par l'outil Rodin ............................................................................... 57
3.3.2.3 Premier Raffinement: Mouvement_1 ............................................................................................. 59
3.3.2.3.1 Spcification formelle en Event-B ....................................................................................... 59
3.3.2.3.2 Vrification formelle par l'outil Rodin ............................................................................... 63
3.3.2.4 Deuxime raffinement : Mouvement_2 ......................................................................................... 65
3.3.2.4.1 Spcification formelle en Event-B ....................................................................................... 65
3.3.2.4.2 Vrification formelle par l'outil Rodin ............................................................................... 70
3.3.3 Validation du modle: animation sous Rodin ........................................................................................ 73
3.3.3.1 Lanimation dEvent-B avec PROB ............................................................................................... 73
3.3.3.2 Observations sur lanimation ......................................................................................................... 74
3.3.4 Conclusion ............................................................................................................................................. 74

4 Conclusion et perspectives .............................................................................................. 75


4.1 Conclusion ......................................................................................................................... 75
4.2 Perspectives ....................................................................................................................... 76

Bibliographie ..................................................................................................................... 77

Table des figures

Figure 1 : Approche propose pour lanalyse de la scurit d'un platoon .................................................. 9


Figure 2 : Arbre de la sret de fonctionnement, [4]................................................................................ 15
Figure 3 : Les entres/sorties d'un model-checker ................................................................................... 18
Figure 4 : L'unit de spcification de Z .................................................................................................... 19
Figure 5 : Le schma Classe en Z............................................................................................................. 19
Figure 6 : La structure dun modle Event-B ........................................................................................... 23
Figure 7 : Forme simple d'un vnement ................................................................................................. 25
Figure 8 : Forme garde d'un vnement ................................................................................................. 25
Figure 9 : Forme complte d'un vnement ............................................................................................. 25
Figure 10 : Architecture de la plate-forme Rodin .................................................................................... 27
Figure 11 : Ecarts latral et longitudinal entre deux vhicules dun convoi. ........................................... 32
Figure 12 : Platoon de vhicules dans un repre cartsien (X, Y)............................................................ 34
Figure 13 : Rayon de couverture d'un vhicule ........................................................................................ 36
Figure 14 : La configuration "T" .............................................................................................................. 38
Figure 15: Accrochage et dcrochage d'un vhicule un platoon ........................................................... 42
Figure 16 : Architecture d'un vhicule autonome..................................................................................... 45
Figure 17 : carts latral et longitudinal entre deux vhicules pour diffrents types de convoi .............. 46
Figure 18 : Distance entre vhicule et obstacle ........................................................................................ 47
Figure 19 : Trajectoire .............................................................................................................................. 48
Figure 20: modle Event-B d'un platoon .................................................................................................. 50
Figure 21 : Modle abstrait d'un vhicule ................................................................................................ 54
Figure 22: Les OPs sous Rodin de la machine abstraite........................................................................... 58
Figure 23 : Modle abstrait et raffin d'un vhicule ................................................................................. 59
Figure 24 : Les OPs sous Rodin du premier raffinement ......................................................................... 64
Figure 25 : Les OPs sous Rodin du deuxime raffinement ...................................................................... 72

Liste des tableaux

Tableau 1 : Quelques substitutions du langage B. .................................................................................... 22


Tableau 2 : Diffrentes configurations d'un convoi ................................................................................. 37
Tableau 3 : Nomenclature des diffrentes constantes et ensembles ......................................................... 51
Tableau 4 : Nomenclature des diffrentes variables ................................................................................. 52

CHAPITRE 1
INTRODUCTION

1.1 Contexte
Notre travail se situe dans le cadre du projet SafePlatoon1 en collaboration avec le
laboratoire SeT de l'UTBM2.
Ce projet aborde la problmatique du fonctionnement en convoi de vhicules autonomes.
Son caractre novateur rside dans la conception et la mise au point de capacits de
fonctionnement en convoi tendues et robustes. Premirement, il s'agit de maitriser le
fonctionnement des convois suivant diffrentes gomtries des configurations de vhicules :
linaire, triangulaire, lignes de front, etc. Deuximement, il s'agit aussi de concevoir des
capacits d'adaptation dynamique des convois : changement de configuration, insertion et
dsinsertion de vhicule.
Un aspect important du projet SafePlatoon rside dans le fait que les algorithmes de dcision
et de contrle/commande proposs seront vrifis et valids. La vrification concerne la preuve,
par des outils et mthodes spcifiques, des proprits de sret relatives certains cas de
fonctionnement du systme considr.
Un systme de transport (ST) [1] en convoi peut tre compos de n vhicules. Chaque
vhicule fonctionne de faon autonome et est caractris par un ensemble de paramtres de
dplacement comme la vitesse, lacclration ou la position courante et il est capable de
percevoir son environnement.
Dans un systme se dplaant en convoi (platoon), le vhicule en tte du convoi (leader)
pourra circuler avec ou sans conducteur. Chaque vhicule du convoi pourra changer des
informations avec le vhicule qui le prcde, voir mme avec son environnement, pour ajuster
sa vitesse afin de maintenir une distance convenable avec son prdcesseur, de sorte que la
scurit du convoi soit garantie. Au niveau des vhicules, et pour amliorer le confort et la
scurit, des systmes dassistance la conduite et dvitement de collisions ont t intgrs
dans plusieurs vhicules grand public [2].
Le contrle commande des platoons peut tre centralis ou dcentralis. Dans le modle
centralis, une entit indpendante appele point d'accs (Access Point), est utilise pour les
1
2

web.utbm.fr/safeplatoon/
Universit de Technologie de Belfort-Montbliard

changes des informations entre les diffrents vhicules du platoon ainsi que la prise des
dcisions pour la conduite. Par contre, dans le modle dcentralis, les vhicules changent des
informations via des infrastructures fixes ou mobiles pour circuler ou bien pour changer de
configuration.
Lobjectif du projet SafePlatoon est dtudier la problmatique des convois de vhicules
autonomes en considrant des applications dans les milieux urbains, militaires et agricoles. Le
projet prend en compte plusieurs configurations gomtriques de convois (ligne, colonne ou
chelon). Il intgre aussi la possibilit dadapter de manire dynamique la configuration du
convoi.
Les domaines dapplication du projet SafePlatoon (transport urbain, activits agricoles,
convois militaires) impliquent la prsence des personnes. Donc, pour ce type de systme il est
impratif que le cycle de conception comporte une phase de certification. Il sagit dtablir,
avec la force dune preuve que le systme satisfera un ensemble de proprits de sret, qui a
t pris en charge en tant quobjectif de ce travail. La vrification formelle apparat comme une
approche consistante pour la certification de ces proprits de sret.

1.2 Objectif
Lobjectif principal de ce mmoire peut tre rsum ainsi :
Proposer une approche gnrique de spcification, de modlisation et de vrification
formelle de diffrents scnarios de systme de transport multi-configuration voluant dans un
environnement dynamique, en adoptant la vrification comme technique de preuve. Lapproche
propose doit pouvoir sappliquer des convois de vhicules autonomes voluant dans
diffrents milieux (urbain, agricole et militaire), et pour diffrentes configurations du platoon
(ligne, colonne ou chelon). Cette approche intgrera la possibilit de reconfigurer la structure
du convoi (Solo, Platoon, Joint et Disjoint).
Lobjectif global peut se dcomposer en trois sous-objectifs.
Tout dabord, nous proposons une approche gnrique pour spcifier la structure ainsi que le
comportement dun platoon en tenant compte: (i) des diffrents domaines d'application (urbain,
agricole, militaire), (ii) des diffrentes configurations gomtriques (ligne, colonne, chelon),
(iii) mais aussi du changement de configuration pour des raisons de scurit ou bien de
performance (insertion/jection, changement de configuration, vitement d'obstacle, etc.).
Ensuite, nous allons adopts une stratgie de vrification de proprits de scurit, telle que
la non-collision des vhicules dun platoon. Cette stratgie comportera les techniques de preuve
par thormes (theorem-proving) pour la conception, la vrification et la validation du systme
en utilisant une mthode formelle et un outil de mise en uvre.

Enfin, la validation par simulation qui portera sur la mise en uvre de jeux de test, travers
la simulation, en utilisant des outils d'animation. Le comportement observer durant une
animation est naturellement dpendant de la nature de la spcification.
Ces trois sous -objectifs peuvent tre reprsents par la figure 1.

Figure 1 : Approche propose pour lanalyse de la scurit d'un platoon

1.3 Structure du rapport


La suite du prsent rapport est structure comme suit :
Chapitre 2 - Etat de lart.
Chapitre 3 - Un modle gnrique pour la scurit des systmes se dplaant en platoon
dans un environnement dynamique.
Chapitre 4 - Conclusion et perspectives

CHAPITRE 2
ETAT DE L'ART

2.1 Projets lis aux problmatiques des vhicules se


dplaant en convoi
2.1.1 Introduction
Le concept des vhicules intelligents a conduit la cration de nouvelles thmatiques de
recherche, comme la conduite automatise, la navigation autonome, etc. La conduite en convoi
(platoon), est lun des domaines, qui a fait lobjet de nombreux projets de recherche, durant ces
vingt dernires annes.
Certains de ces projets ont abord la problmatique des convois de vhicules autonomes
dont lobjectif daugmenter la scurit routire et lefficacit du transport dans les milieux
urbains et autoroutiers.

2.1.2 Projets de recherche relatifs au domaine des transports


En France, plusieurs projets de recherche relatifs au domaine des transports ont t
dvelopps. Parmi ces projets, nous citons :

PREDIT3 (Programme national de REcherche et DInnovation dans les Transports) est


un programme de recherche, dexprimentation et dinnovation dans les transports
terrestres, conduit par les ministres chargs de la recherche, des transports, de
lenvironnement et de lindustrie, lADEME (Agence De lEnvironnement et de la
Matrise de lEnergie) et OSEO (tablissement public de lEtat franais, charg de
soutenir linnovation et la croissance des PME). LANR (Agence Nationale de la
Recherche) fait dsormais partie galement de ses financeurs. Stimulant la coopration
entre secteurs publics et privs, ce programme vise favoriser lmergence de systmes
de transport conomiquement et socialement plus efficaces, plus srs, plus conomes en
nergie, et finalement plus respectueux de lhomme et de lenvironnement.

Le PREDIT 3 (2002-2006) est encadr par trois objectifs gnraux :


3

http://www.predit.prd.fr/predit4/homePage.fo

10

Assurer une mobilit durable des personnes et des biens


Accrotre la scurit des systmes de transport
Rduire les impacts environnementaux

Le projet MobiVIP4 (Vhicules Individuels Publics pour la Mobilit en centre ville)


engag sur trois ans (2003-2006), sest intress aux recherches et aux exprimentations
de briques technologiques visant la mise en place de services de mobilit en milieu
urbain bass sur un systme de transport, les Vhicules Individuels Publics (VIP), et sur
un systme dinformation sintgrant dans la politique de gestion globale des
dplacements en centre ville.

Les travaux ont t mens selon deux axes runissant des tudes prospectives, bases sur des
tudes dimpact et des enqutes sur les nouveaux services et TIC (Technologies de
lInformation et de la Communication). Les recherches ont t mens sur plusieurs thmes
transversaux dont la modlisation, la navigation, la conduite assiste, le conduite autonome et
en convoi, les systmes dinformation et de communication.

Le projet CityVIP5, qui est port par le LASMEA (Laboratoire des Sciences et
Matriaux pour lElectronique et d'Automatique), sinsre galement au programme
PREDIT 3. Le projet concerne le dplacement sr de Vhicules Individuels Publics
dans un contexte urbain et plus particulirement les centres urbains accs rglement
qui pourraient tre le lieu privilgi de dploiements de tels vhicules. La faisabilit
dun systme permettant doffrir aux personnes la possibilit dutiliser de petits
vhicules lectriques en mode partag. Ces VIP (Vhicules Individuels Publics)
pourraient tre dclins en version conduite manuelle ou en flotte totalement
automatise. la diffrence du projet MobiVIP, o la problmatique tait considre
dans sa globalit, seules certaines briques ncessaires la mise en pratique sont
prsentes dans ce projet. Les partenaires associent en effet leurs comptences autour
dun programme scientifique en trois parties : localisation, conduite autonome, scurit
des dplacements. Il sagit, pour chaque vhicule, dtre dot dun systme permettant
dune part de le localiser prcisment en temps rel et dautre part dassurer sa
navigation autonome.

Lattention est aussi focalise sur loptimisation de la rpartition de la flotte en fonction de


la demande, mme en cas de conduite manuelle. Dans ce cas un pilote mnerait destination
une flotte de vhicules autonomes pour rapprovisionner les stations, do la ncessit de la
modalit convoi. Les partenaires regroupent essentiellement des laboratoires de recherche, le
LASMEA, lquipe AROBAS de lINRIA, lquipe Lagadic-IRISA de lINRIA,
HEUDIASYC, XLIM, le LCPC, MATIS de lIGN et la socit BeNomad.

http://www-sop.inria.fr/visa/mobivip/
http://www.agence-nationale-recherche.fr/projet-anr/?tx_lwmsuivibilan_pi2%5BCODE%5D=ANR-07-TSFA0013
5

11

Le projet CRISTAL6 (Cellule de Recherche Industrielle en Systmes de Transports


Automatiss Lgers) est un projet de mobilit urbaine innovant soutenu par le FUI
(Fonds Unique Interministriel) qui sinscrit dans un contexte existant
dexprimentations de VIP (Vhicules Individuels Publics). Il ne revendique pas de
grandes avances technologiques mais base son succs commercial sur des innovations
techniques et son ralisme conomique. Le projet est port par LOHR Industrie,
industriel spcialis dans la conception et la ralisation de systmes de transport de
biens et de personnes. Le consortium initial runit aussi le LORIA, VULOG et
TRANSITEC SA et intgre de nombreux partenaires sous-traitant. LINRIA, lUTBM,
GEA SA, le LASMEA, PIMENTIC, GEOLIA et TECNOMADE participent ainsi au
niveau de la recherche et du dveloppement.

Les acteurs du projet ont investi 8 millions deuros pour les diffrentes recherches et tudes
associes la conception du vhicule Cristal, un systme de transport public, individuel ou
semi-collectif, adaptable lvolution de la demande de mobilit dans le temps et dans
lespace. Il sagit dun vhicule compact de 3,40 m de longueur et dune capacit de 6
personnes. Il est destin adapter en continu loffre de transport individuel ou semi-collectif
lvolution de la demande dans un centre urbain.

Le projet RINAVEC7 (Reconnaissance d'Itinraires et NAvigation en convoi de


VEhicules Communicants) vise dvelopper et valuer des fonctions avances de
perception et de modlisation de l'Environnement, pour des vhicules voluant en
convoi sur un itinraire inconnu a priori, en milieu ouvert. Le contexte applicatif
concerne la navigation de convois humanitaires dans des zones de conflit ou accidentes
: pour diverses raisons (mines, autres vhicules ou personnes), la progression de tels
convois est trs difficile et dangereuse. Le but a t d'valuer les progrs rcents en
Perception pour la navigation de vhicules communicants, dans ce contexte trs
exigeant. Chaque vhicule du convoi est quip de capteurs proprioceptifs bas-cot
(GPS, inertiel) et de camras. Le vhicule de tte (leader) modlise la trajectoire suivie
par le convoi, pour viter tout danger, les autres vhicules (suiveurs) doivent emprunter
cette trajectoire, avec une dviation maximale de 10cm. Le leader enregistre sa
trajectoire sous la forme de positions successives, relatives des amers 3D fixes de
l'environnement, dtects et suivis dans les images acquises en mouvement. Le leader
dtecte aussi des objets mobiles proches de l'itinraire, et value leurs tats, positions et
vitesses. Les trajectoire, les positions des amers fixes, les tats des objets mobiles sont
stocks dans une carte stochastique, priodiquement envoye aux suiveurs. Chacun
l'exploite pour se localiser par rapport aux amers dj perus par les prcdents, et pour
corriger sa trajectoire afin de respecter la contrainte de dviation maximale. Chacun
enrichit la carte en fonction de ses propres observations. Ce projet est propos par trois
partenaires: d'une part des quipes du LAAS, CNRS et du LASMEA, expertes dans les

Cellule de Recherche Industrielle en Systmes de Transport Automatiss Lgers


http://www.agence-nationale-recherche.fr/projet-anr/?tx_lwmsuivibilan_pi2%5BCODE%5D=ANR-07-ROBO0006
7

12

domaines Robotique Terrestre ou Vhicules Intelligents, et d'autre part, le dpartement


'Robotique et UAV' de Thales Optronique S.A., rput pour sa capacit intgrer des
systmes robotiques.

2.1.3 Dautre projets europens et internationaux

Le projet CATS8 (City Alternative Transport System) a dbut 2010 et il se droulera


jusqu'au 31 Dcembre 2014. Cest un projet europen de 4,1 millions deuros financ
dans le cadre du 7me programme-cadre pour la recherche et le dveloppement
(PCRD), regroupant onze institutions partenaires situes dans six pays diffrents. Ce
projet vise dvelopper et exprimenter en situation relle une nouvelle gnration de
vhicule urbain permettant de faire le lien entre les vhicules individuels et les
transports en commun.

Le projet PATH9 (Partners for Advanced Transit and Highways) cr par Le


Caltrans (le dpartement de Transport de Californie) et lITSUC (Institute of
Transportation Studies of the University of California) Berkeley en 1993. Le projet
avait trois objectifs : une technologie de propulsion propre, une autoroute automatique
et un contrle automatique.

Le systme de commande des vhicules est bas sur un capteur qui dtecte la position des
vhicules relativement des aimants permanents introduits dans les routes. Les travaux ont
commenc par le dveloppement des modles dynamiques de vhicule et des lois de
commandes, leurs valuations par simulation avant de commencer les exprimentations. Les
travaux du projet PATH ont t tendus pour raliser des tests dun contrleur alternatif,
utilisant la logique floue [3].

8
9
10
11

Le projet SARTRE10 (SAfe Road TRains for the Environment) a pour objectif de
permettre plus de vhicules de circuler en mme temps sur les grands axes une
vitesse constante. Il devrait aussi contribuer la diminution du nombre daccident. Dans
le cadre du projet SARTRE, Volvo a fait circuler cinq vhicules sur une distance de 200
kilomtres en Espagne. La particularit de ce convoi, c'est qu'il n'y avait qu'un seul
conducteur. Les autres automobiles taient pilotes automatiquement.

Le projet SafePlatoon11 a pour objectif dtudier la problmatique des convois de


vhicules autonomes en considrant des applications dans les milieux urbains, militaires
et agricoles. Son caractre novateur rside dans la conception et la mise au point de
capacits de dplacement en convoi tendues et robustes. Premirement, il s'agit de
maitriser le fonctionnement des convois suivant diffrentes configurations gomtries

http://www.parc-innovation-strasbourg.eu/index.php/CATS-Project/welcome-on-cats-webpage.html
http ://www.path.berkeley.edu/
http ://www.sartre-project.eu/en/Sidor/default.aspx

http ://web.utbm.fr/safeplatoon/

13

de vhicules : ligne, colonne, chelon, etc. Deuximement, il s'agit aussi de concevoir


des capacits d'adaptation dynamique des convois : changement de configuration,
insertion et dsinsertion de vhicule. Le projet intgre aussi la possibilit dadapter de
manire dynamique la configuration du convoi.
Un aspect important du projet SafePlatoon rside dans le fait que les algorithmes de dcision et
de contrle proposs seront vrifis et valids. La vrification concerne la preuve, par des outils
et des mthodes spcifiques, de proprits de sret relatives certains cas de fonctionnement
du systme considr. La validation concerne la mise en uvre des tests, effectus soit par
simulation, soit par exprimentation sur vhicules rels. Son but est d'valuer la conformit et
la qualit des approches proposes, relativement aux objectifs.
Le projet SafePlatoon, (20112014), repose sur des acquis de ses partenaires (LASMEA,
CEMAGREF, DGA, Civitec), dans la conception d'algorithmes de dcision, de contrle et de
commande pour la conduite en convoi et dans la conception de vhicules intelligents
exprimentaux. Les partenaires de SafePlatoon ont galement particip des projets
d'applications de la conduite en convoi et des vhicules autonomes au transport urbain,
l'agriculture et au domaine militaire. Ces acquis seront enrichis et consolids dans le cadre du
projet SafePlatoon.

2.1.4 Conclusion
Tous ces projets visent rduire les besoins en ressources humaines pour la conduite des
convois et amliorer leurs scurits.

2.2 Notions de sret de fonctionnement


Avant la mise en place et lutilisation de ces systmes critiques, il est indispensable de
pouvoir valuer leur sret de fonctionnement.

2.2.1 Dfinition
La sret de fonctionnement (SdF) dun systme est dfinie par un ensemble de proprits
permettant dvaluer sa capacit fournir un service de manire efficace, et sans risque. Ces
proprits sont la fiabilit, la disponibilit, la maintenabilit et la scurit du systme.

2.2.2 Concepts de sret de fonctionnement


La terminologie utilise tout au long de cette section est extraite du Guide de la Sret de
Fonctionnement [4].

14

La sret de fonctionnement sarticule en trois axes principaux : les attributs qui la


caractrisent, les entraves qui empchent sa ralisation et enfin les moyens de latteindre (la
prvention, la tolrance, llimination et la prvision des fautes), comme prsent dans la figure
2.

Figure 2 : Arbre de la sret de fonctionnement, [4]

2.2.2.1 Attributs de la sret de fonctionnement


Un ensemble d'attributs est dfini pour exprimer les proprits de SdF du systme.
Limportance de chacun de ces attributs est relative aux applications auxquelles le systme est
destin. On peut distinguer :
La disponibilit, le fait que le systme soit prt lutilisation,
La fiabilit, la continuit du service,
La scurit-innocuit, la non-occurrence de consquences catastrophiques pour
lenvironnement,
La confidentialit, la non-occurrence de divulgations non-autorises de linformation,
Lintgrit, la non-occurrence daltrations inappropries de linformation,
La maintenabilit, laptitude aux rparations et aux volutions.

2.2.2.2 Entraves la sret de fonctionnement


Les entraves la SdF sont les circonstances indsirables, mais non inattendues, causes ou
rsultats de la non-sret de fonctionnement. Dans lensemble des entraves, on distingue :
La faute, considre comme la cause adjuge ou suppose de lerreur,
15

Lerreur, qui est la partie de ltat de systme qui est susceptible dentraner une
dfaillance,
La dfaillance du systme qui survient lorsque le service dlivr dvie de
laccomplissement de la fonction du systme.

2.2.2.3 Moyens pour la sret de fonctionnement


Il sagit des mthodes et techniques permettant de fournir au systme laptitude dlivrer un
service conforme laccomplissement de sa fonction, et de donner confiance dans cette
aptitude. Le dveloppement dun systme sr de fonctionnement passe par lutilisation
combine de ces mthodes qui peuvent tres classes en :
Prvention de fautes : comment empcher loccurrence ou lintroduction de fautes,
Tolrance aux fautes : comment fournir un service mme de remplir la fonction du
systme en dpit des fautes,
limination des fautes : comment rduire le nombre et la svrit des fautes,
Prvision des fautes : comment estimer la prsence, la cration et les consquences des
fautes.
Lactivation dune faute engendre une erreur, qui peut conduire une dfaillance. La notion
de tolrance aux fautes ne se limite pas aux mcanismes mis en place pour assurer une
continuit de service (fiabilit) ; elle stend tout mcanisme servant endiguer la
propagation derreurs dans le but dviter ou diminuer la gravit des dfaillances (scurit
innocuit).
La prvention des fautes et la tolrance aux fautes peuvent tre vues comme des moyens
dobtention de la sret de fonctionnement, cest--dire comment procurer au systme
laptitude fournir des services conformes aux fonctions attendues.
Llimination des fautes et la prvision des fautes peuvent tre vues comme constituant les
moyens de la validation de la sret de fonctionnement, cest--dire comment avoir confiance
dans laptitude du systme fournir des services conformes laccomplissement de sa
fonction.
On focalise sur les mthodes dlimination de fautes, et en particulier la vrification base
modle, la preuve par thormes et les tests. Lvaluation de la sret de fonctionnement dun
systme ncessite donc de le soumettre une srie de tests et danalyses formelles en utilisant
les techniques de preuve par thorme pour la conception et la validation des systmes.
La preuve de thorme (ou theorem-proving) est une mthode qui permet deffectuer des
vrifications sur des modles formels du systme. Elle permet de dmontrer que le modle du
systme obit un ensemble de proprits de la mme faon que la preuve en mathmatique
dmontre lexactitude dun thorme. Elle consiste noncer des propositions et les
dmontrer dans un systme de dduction de la logique mathmatique, en particulier dans le
calcul des prdicats.
16

La preuve par thorme, par rapport la vrification base modle, a lavantage dtre
indpendante de la taille de lespace des tats, et peut donc sappliquer sur des systmes
complexes.

2.3 Les langages formels


2.3.1 Introduction
Un langage de spcification est dit formel lorsque sa syntaxe et ses notations sont
rigoureusement dfinies avec des modles mathmatiques. Une mthode de spcification est
dite formelle lorsquelle utilise un ou plusieurs langages de spcification formels. Les
approches formelles en gnie logiciel se basent sur la construction dun modle formel de
lapplication dvelopper.
Les approches formelles en gnie logiciel sont arrives un certain degr de maturit
industrielle mais ne peuvent pas tre considres comme des approches utilisables un cot
raisonnable pour toutes les classes dapplications. Le principal intrt de ce type dapproche est
sa capacit rsoudre des problmes complexes et critiques tels que les systmes distribus,
les systmes multi-agents et en particulier les systmes de platooning, car ces applications sont
soumises des proprits de sret de fonctionnement du moins celles considres critiques,
tout en conservant une simplicit fonctionnelle. Ce sont des applications dont un dfaut de
conception pourrait se traduire par une faille de fonctionnement, avec des pertes humaines et/ou
matrielles.
Les approches formelles sont invitables dans le domaine des systmes complexes. Car elles
donnent la possibilit de prouver, au sens dune preuve mathmatique, que le modle formel
dune application doit faire lobjet dune certification : on doit pouvoir garantir que les
proprits de sret sont satisfaites, avec la force dune preuve mathmatique. La vrification
sappuie sur un ensemble de formalismes, doutils et de mthodes.
Lobjectif de ce mmoire est dexplorer, en utilisant les outils de vrification disponibles, les
conditions dans lesquelles un Platoon peut satisfaire un ensemble de proprits de sret. Un
tat de lart sur les outils et mthodes de vrification permet ensuite de justifier les choix
effectus pour la vrification de proprits de sret relatives la conduite en convoi.

2.3.2 Les langages formels et les outils de vrification


La vrification sinscrit dans le cadre de la logique mathmatique. Il est donc naturel que les
outils de vrification sinspirent des systmes de dduction et des algorithmiques de dcision.
Ces deux familles sont constitues, dune part, par les outils bass sur la preuve et dautre part,
par les outils de model checking.

17

2.3.2.1 Quelques dfinitions de base


Vrification
Cest lactivit qui sintresse tablir une relation entre un modle formel M dun systme
et une formule P exprimant une proprit de M.
Preuve
Elle se base sur un principe dductif. La validit dune formule est tablie grce des
thormes mathmatiques.
Model-checking
Il est bas sur les procdures de dcision de la validit ou de la satisfiabilit, cest dire la
recherche de modles, au sens logique du terme, par exploration de son espace dtats. La
figure 3 prsente les entres et les sorties d'un Model-checker.

Figure 3 : Les entres/sorties d'un model-checker

2.3.2.2 Quelques langages formels


Les mthodes formelles sont des techniques qui peuvent tre utilises lors de chacune des
phases du cycle de dveloppement logiciel pour aider structurer le raisonnement et apporter
des garanties sur le dveloppement. Pour cela, ces mthodes reposent sur un raisonnement
mathmatique rigoureux fond sur un langage formel.
Les langages formels servent spcifier de manire mathmatique, via la thorie des
ensembles et la logique de prdicat du premier ordre, un systme complexe, ventuellement
distribu.
2.3.2.2.1 Le langage Z
Z [5] est un langage de spcification formelle dont la notation sinspire de la formalisation
de la thorie des ensembles et de la logique du premier ordre. Z est un langage fortement typ :
18

tout composant dune spcification Z possde un type, et donc peut tre associ un ensemble
de valeurs. Z se prsente sous la forme dun langage et dun schma de calcul. Le schma, unit
de spcification de Z, encapsule une partie dclaration et une partie contrainte, comme le
montre la figure 4 :

Figure 4 : L'unit de spcification de Z


Le schma est la notion de base des spcifications Z. Un schma est une boite contenant des
descriptions utilisant les notations Z. Les schmas sont utiliss pour dcrire les tats dun
systme, les tats initiaux ou bien les oprations.
La figure 5 reprsente un schma Groupe_TD, qui permet de dfinir les aspects statiques du
systme, est dnot en Z par :

Figure 5 : Le schma Classe en Z


La premire partie du schma correspond la dclaration des variables effectif_max et
lves. La seconde partie est la dfinition de linvariant. Le nombre des lves est infrieur ou
gale une certaine valeur entire positive. On peut crire un schma sous une forme linaire
quivalente:

Groupe_TD
effectif_max]

[effectif_max : 1 ; lves : ETUDIANT | #lves

Le prdicat #lves effectif_max est la partie contrainte du schma. La contrainte dun


schma dtat est un invariant du modle. Ainsi, les proprits de sret qui pourraient tre

19

associes au modle de spcification Z apparatraient comme des contraintes dans des schmas
dtat [6].
2.3.2.2.2 Object-Z
Object-Z [7] est une extension du langage Z qui permet de spcifier des systmes dans un
style orient objet. Dans une spcification Z, il est difficile de dterminer les consquences des
oprations sur un schma d'tat donn, car les schmas d'opration peuvent agir sur les tats de
plusieurs schmas d'tat. La notion de classe est introduite pour regrouper dans un mme
schma toutes les oprations la concernant.
Le formalisme Object-Z donne un objet Z en permettant dencapsuler lensemble des
schmas qui constituent le modle de spcification dun systme, dans un schma de classe.
Toutes les variables dtat sont dclares et contraintes dans un schma anonyme dit schma
dtat. Les contraintes de ce schma sont les invariants dtat de la classe. Une opration
standard dinitialisation dcrit lensemble dtats initiaux possibles pour la classe. En outre,
comme tout formalisme de type objet, Object-Z propose des mcanismes formels pour
lagrgation et lhritage.
Z et Object-Z, dont les notations se basent sur la formalisation de la logique du premier
ordre, sont adapts la vrification par la preuve. En particulier, les proprits de sret de
fonctionnement, qui, comme nous lavons dit, sintgrent facilement sous la forme dinvariants
dtat, peuvent tre prouvs inductivement :
Prouver que lensemble dtats initiaux satisfait linvariant
Pour chaque opration Op, prouver que si ltait immdiatement avant Op satisfait
linvariant, alors ltat immdiatement aprs Op le satisfait aussi.
N.B : Malgr la place faite la logique, aucun environnement daide la preuve pour Z ou
Object-Z nest arriv une maturit significative.
3.2.2.2.3 La boite outils SAL
Lenvironnement SAL (Symbolic Analysis Laboratory) permet de combiner les diffrents
outils : abstraction, analyse de programme, theorem-proving et model checking, pour la
vrification des proprits dans un systme de transition. Une composante essentielle de cette
boite est le langage utilis pour la description des systmes de transition. Ce langage sert
comme un langage de spcification.
Le langage SAL [8] a t essentiellement conu par David Dill de luniversit de Stanford et
Thomas Henzinger de luniversit de Californie Berkeley. Le langage SAL dcrit des
systmes de transition en termes de commandes dinitialisation et de transition.
Un modle SAL est encapsul par un contexte qui contient des dfinitions de constantes, de
types et de fonctions. Un contexte contient galement un ensemble de modules. Chaque module

20

est un systme de transition dont ltat est dfini par un ensemble de variables locales, globales,
dentre et de sortie.
3.2.2.2.4 La mthode B
La mthode B [9], ne dune volution du langage Z, appartient, comme ce dernier, la
famille des formalismes bass sur la notation formelle de la logique et de la thorie des
ensembles.
La mthode B accompagne le concepteur d'un programme partir d'une spcification
mathmatique abstraite jusqu'au code informatique correspondant. Ce passage de la
spcification abstraite au code concret se fait grce une ou plusieurs tapes de raffinements
successifs.
Lvolution par rapport Z consiste en lintroduction dune unit de spcification bien
structure, qui est la machine abstraite. La mthode B est base sur la notion de machine
abstraite et lutilisation de raffinements formellement prouvs. La preuve de proprits relatives
aux oprations dun systme sinscrit ainsi dans une stratgie de dduction base sur le concept
de plus faible pr-condition. Une spcification B est structure en un ensemble de machines. La
partie statique dune machine B est la dfinition despace des tats qui apparat dans les clauses
VARIABLES (numre les composants dtat) et INVARIANTS (dfinit des restrictions sur
les valeurs possibles que ces composants peuvent prendre). Ltat de la machine ne peut tre
modifi que par des oprations. La partie dynamique est exprime par un langage de
substitutions gnralises.
Lautre volution par rapport Z consiste particulirement en ladoption des substitutions
gnralises comme formalisme de description des transformations opres sur les donnes.
Une substitution dsigne le remplacement dune variable par une valeur quelle peut prendre.
Une substitution gnralise est un transformateur de prdicats permettant dcrire les
oprations qui font voluer ltat du systme modlis. Les principales substitutions du langage
B sont prsentes dans le tableau 1:

21

Notation B

Conditions de dfinition

Signification

x := Exp

x est une variable


Exp est une expression

Substituer Exp x

Skip

Ne rien modifier

PRE P THEN
S END

P est un prdicat
S est une substitution

Sassurer de la pr-condition
P et excuter S

ASSERT P THEN
S END

P est un prdicat
S est une substitution

Excuter S sous
lassertion que P est vrai

SELECT P THEN
S END

P est un prdicat
S est une substitution

Excuter S si
P est vrai

IF P THEN
S END
VAR Z IN
S END

P est un prdicat
S est une substitution
Z une liste de variables
S est une substitution

ANY X WHERE P
THEN S END

X est une liste de variables


P est un prdicat
S est une substitution

Excuter S si
P est vrai (sinon skip)
Les variables locales Z sont
utilisables dans la substitution
S
Slectionner une
valeur de X qui vrifie le
prdicat P et excuter S

S;T

S et T sont des substitutions

Excuter S puis T

S || T

S et T sont des substitutions

CHOICE T OR S END

S et T sont des substitutions

Excuter S et T en mme
temps
Excuter S ou T

Tableau 1 : Quelques substitutions du langage B.


Une opration peut possder galement des paramtres dentre et de sortie. Les oprations
B peuvent tre appeles par des composants extrieurs. Les oprations en B peuvent tre vues
comme des fonctions d'un langage de programmation qui peuvent tre appeles par un
oprateur extrieur.
Le mcanisme de raffinement en B classique consiste reformuler (par des tapes
successives) les variables et les oprations de la machine abstraite, afin darriver finalement
un module qui constitue le programme implmenter. Le mcanisme de raffinement permet de
prserver des proprits du systme dj prouves dans des modles de plus haut niveau. Le
raffinement dune opration est correctement prouv sil tablit le mme rsultat que son
abstraction.

22

B dispose galement doprateurs (INCLUDES, SEES, USES, IMPORTS) permettant de


composer des machines en utilisant dautres machines dans le but darchitecturer le projet B.
La mthode B est, parmi les approches formelles, celle qui a atteint le plus haut niveau de
maturit technologique.
3.2.2.2.5 Event-B
La mthode Event-B [10] est une mthode formelle introduite par Jean Raymond Abrial en
2010. Cest une volution de la mthode B apparue en 1996, dont lobjectif est de modliser
des systmes ferms. Un systme ferm est un systme modlis avec lensemble de toutes les
interactions avec son environnement. Donc il ny a pas besoin de modliser des entres ou
sorties pour communiquer avec l'environnement. Pour cela, les oprations B sont remplaces
par des vnements en Event-B. Contrairement aux oprations B qui sont appeles par des
composants, les vnements Event-B se dclenchent spontanment si une condition (appele
garde) devient vrai. Contrairement au B classique, Event-B offre galement la possibilit
dexprimer certaines contraintes dynamiques telles que des contraintes de vivacit. Ces points
font que le B classique est mieux appropri pour le dveloppement de logiciels (spcification
par contrat) et Event-B pour le dveloppement de systmes ractifs (spcification par
observation), comme le confirme [11].
Un modle Event-B est dcompos en deux parties : le contexte et la machine. La figure 6
prsente les deux composants avec leurs diffrentes clauses telles quelles sont dclares dans
la plateforme RODIN12.
CONTEXT
/* Nom du contexte*/
EXTENDS
/* Liste des contextes vus par le contexte */
SETS
/* Liste des ensembles */
CONSTANTS
/* Liste des constantes du contexte */
AXIOMS
/* Proprits du contexte */
THEOREMS
/* Liste des thormes du contexte */

MACHINE
/* Nom de la machine */
SEES
/* Liste des contextes vus par le modle */
VARIABLES
/* Liste des variables d'tat du modle */
INVARIANT
/* Proprits d'invariance du systme */
THEOREMS
/* Liste des thormes de la machine */
VARIANT
/*Le variant de le machine */
EVENTS
/* Les vnements de la machine */

Figure 6 : La structure dun modle Event-B

12

http://www.event-b.org

23

Contexte
Un contexte dcrit la partie statique d'un modle. Il est constitu de plusieurs clauses:
La clause CONTEXT reprsente le nom du composant qui devrait tre unique dans un
modle.
La clause EXTENDS dclare la liste des contextes qutend le contexte dcrit. Un
contexte peut tendre un autre contexte en rajoutant de nouvelles constantes et de
nouvelles proprits.
La clause SETS contient les ensembles porteurs du modle, ces ensembles sont non
vides et permettent de typer le reste des entits du modle.
La clause CONSTANTS contient la liste des constantes.
La clause AXIOMS contient l'ensemble des proprits des constantes et notamment
leurs types. Un axiome est une dclaration qui est suppos tre vrai dans le reste du
modle.
La clause THEOREMS exprime des proprits qui peuvent tre dduites partir des
proprits prsentes dans la clause AXIOMS.

Machine
Une machine dcrit la partie dynamique du modle et elle est constitue de plusieurs clauses :
La clause MACHINE reprsente le nom du composant qui devrait tre unique dans un
modle.
La clause REFINES dclare le nom de la machine raffine par la machine dcrite.
La clause SEES spcifie la liste des contextes vus par la machine.
La clause VARIABLES contient la liste des variables du modle.
La clause INVARIANTS dfinit les proprits dinvariance du modle telles que des
informations sur les types des variables et des proprits de sret.
La clause THEOREMS exprime des proprits qui peuvent tre dduites, des
proprits dinvariance de la machine et des proprits prsentes dans la clause
AXIOMS.
La clause VARIANT dfinit lexpression du variant du modle.
La clause EVENTS contient la liste des vnements qui oprent une ou plusieurs
substitutions sur la valeur des variables. Un vnement Event-B correspond un
changement dtat dnotant une transition dans le systme modlis. Un vnement est
compos de deux parties : Une garde (la clause WHEN) qui dfinit la condition selon
laquelle l'vnement peut ou non se dclencher. Une action (la clause THEN) qui
dfinit l'volution des variables d'tat.

La notion dvnement
En Event-B, on peut distinguer trois formes dvnements :

24

La forme simple inclut seulement une action. Cela quivaut donc une garde qui est
toujours vraie. Cette forme est reprsente par la figure 7.

Figure 7 : Forme simple d'un vnement


Il existe un vnement obligatoire, nomm INITIALISATION, qui est toujours de la forme
simple.
La forme garde inclut une garde et une action qui ne dpendent que des variables
dtats du modle. Cette forme est reprsente par la figure 8.

Figure 8 : Forme garde d'un vnement

La forme complte inclut des paramtres, une garde et une action. Cette forme est
reprsente par la figure 9.

Figure 9 : Forme complte d'un vnement


La partie action des vnements est constitue d'une substitution qui fait voluer la valeur
des variables.
25

Les substitutions en Event-B ont trois formes possibles :


La substitution gnralise x :| P(x, x). Cest la forme la plus gnrale des
substitutions, o x reprsente la valeur de la variable x aprs la substitution et P est un
prdicat.
Cette forme exprime que la variable x prendra une nouvelle valeur x et qui vrifie que
le prdicat P(x, x) soit vrai.
Loprateur utilis par cette forme est loprateur : | (se lit devient tel que).
La substitution ensembliste x : E(x). Cette forme de substitution indique qu'une
variable x est modifi de faon ce qu'elle devienne un lment d'un ensemble E(x).
Cette forme de substitution peut tre exprime sous la forme gnralise :
x :| (x E(x)).
Loprateur utilis par cette forme est loprateur : (se lit devient appartenant ).
La substitution simple x := Exp(x). Cette forme de substitution ressemble une
affectation o la variable x prend la valeur de l'expression Exp(x).
En Event-B, il est possible aussi davoir plusieurs substitutions en parallle de la forme
(x :| P(x, x)) || (y :| Q(y, y)). Ces substitutions sont excutes en mme temps mais ne peuvent
pas concerner les mmes variables. La forme gnralise de ces substitutions est :
x, y :| (P(x, x) Q(y, y)).

La notion de raffinement
Le raffinement est l'une des notions les plus importantes dans la mthode B vnementielle.
Elle permet de dvelopper le systme de manire incrmentale en partant du modle abstrait
qui constitue une spcification du systme. Les dtails du systme sont rajouts de faon
graduelle dans chaque raffinement. Le raffinement permet de conserver les proprits dj
prouves dans les modles plus abstraits. Lors d'un raffinement, de nouvelles variables peuvent
tre ajoutes et d'autres variables peuvent disparatre. La structure d'un raffinement est similaire
celle d'une machine abstraite avec l'ajout d'une clause REFINES qui indique le nom de la
machine raffine. Chaque vnement abstrait peut tre raffin par un ou plusieurs vnements
concrets. Il peut galement tre utilis pour ajouter des dtails de structures de donnes. Chaque
tape de raffinement est valide par des mcanismes de preuves garantissant leur correction.
Un des points les plus importants de la mthode Event-B est la preuve de la correction des
modles. Pour assurer cette correction, un ensemble dobligations de preuve (notes OP)
doivent tre dcharges. Ces obligations de preuve concernent diffrents aspects du modle tels
que la vrification des proprits dinvariance dune machine Event-B ou la preuve de la
correction dun raffinement.
La mthode Event-B est largement utilise en milieu universitaire et par les industriels grce
la plateforme Rodin13 qui volue rgulirement.
13

http://rodin.cs.ncl.ac.uk/

26

3.2.2.2.6 RODIN : loutil support dEvent-B


Rodin est une plateforme extensible qui permet de dvelopper des modles Event-B, de faire
des preuves et leurs corrections. Cette plate-forme permet de spcifier, de prouver et danimer
des modles Event-B. Il contient des gestionnaires de projet, diteurs, outils de preuve et
danimation, gnrateur dobligations de preuves, gnrateurs de code. L'outil Rodin soutient la
modlisation formelle et la preuve en utilisant un langage mathmatique qui est bas sur la
logique des prdicats et la thorie des ensembles.
La plate-forme Rodin est dcompose en trois ensembles d'outils :
Plate-forme Eclipse,
noyau Rodin,
plugins externes
Cette dcomposition est reprsente par la figure 10.

Figure 10 : Architecture de la plate-forme Rodin


La plate-forme Rodin est une open source sous Eclipse et extensible moyennent lajout de
plugins, tel que:
Vrificateur statique (SC),
Gnrateur dObligation de Preuve (POG),
Prouveurs,
Animateurs,
UI de Modlisation,
UI de Preuve
La plateforme RODIN stocke les modles dans une base de donnes et sarticule sur un
ensemble de plug-in permettant par exemple de :
(1) prouver les modles en utilisant les prouveurs de lAtelier B mais aussi le propre prouveur
de RODIN,
(2) vrifier les modles par les techniques du model checking en utilisant ProB [12],
27

(3) animer les modles en utilisant aussi ProB [12].

3.2.3 Conclusion
Z et Object-Z : Malgr la place faite la logique, aucun environnement daide la preuve
pour Z ou Object-Z nest arriv une maturit considrable. Cest pour cette raison que nous
ne lavons pas retenu pour la spcification et lanalyse des systmes quon se propose dtudier.
La mthode B : La maturit technique de cette mthode et des outils associs, le place parmi
les plus aptes des mthodes formelles. Dautant plus que la preuve de proprits de sret se
fait en B de faon naturelle, par technique inductive de preuve des invariants.
Deux caractristiques principales nous ont conduits adopter la mthode Event-B en tant
que mthode de vrification car, notre connaissance, elle sagit premirement de la seule
approche formelle de spcification et de modlisation des systmes ferms, qui possde une
maturit importante et qui intgre la vrification par la preuve. Deuximement, Event-B est
utilisable industriellement car il existe des outils commercialiss appropris de vrification de
proprits de sret, en particulier la plate forme Rodin. Cest pour ces raisons que nous avons
adopts Event-B comme formalisme de spcification et de modlisation et Rodin en tant
quoutil de vrification.
Du ct des limitations, la mthode Event-B ne possde pas en forme native, une
reprsentation ou formalisation des nombres rels. Dans ces conditions, la confiance que lon
puisse attribuer aux rsultats de la vrification est en relation inverse avec la distance entre le
modle et la ralit. Lautre raison, peut tre la plus importante, est labsence ou linsuffisance
des moyens de reprsentation des aspects comportementaux.

2.4 Les travaux existants


Parmi les travaux qui sont intresss la modlisation et l'analyse de la scurit routire des
systmes de transports, nous avons cit ceux publis par [13], [14] et [15].
Dans [13], Ossama Hamouda et al abordons la scurit des systmes routiers automatiss
(AHS) sur la base des applications de mises en uvre des platoons dans un contexte mobile
avec les rseaux ad-hoc. Un peloton est une srie de vhicules coordonns qui se dplacent
dans la mme direction sur une route [16]. Les vhicules sont conduits par des agents plus ou
moins automatiss, en interaction dans un environnement multi-agents [17]. La mise conduite
manuelle est possible dans certaines circonstances.
Son travail vise laborer des approches et des modles qui permettent d'analyser la scurit
de AHS en tenant compte de plusieurs phnomnes, tels que les occurrences accidentelles de
dfaut, le succs et les checs des manuvres de rcupration, et les stratgies d'valuation de
coordination des vhicules.

28

Ils considrent comme une tude de cas, les architectures dveloppes dans le cadre du
projet PATH (Partners for Advanced Transit and Highways [18]) pour les tests de validation
exprimentales qui ont t ralises. Ces architectures permettent la mise en uvre des
manuvres de rcupration automatique pour assurer la scurit des platoons en prsence de
diffrents types de dfaillances affectant les vhicules et leur environnement. Ils ont dvelopp
des modles, bas en particulier sur les rseaux d'activit stochastiques (SAN [19], [20]), pour
valuer l'impact des dfaillances des vhicules ainsi que l'chec des manuvres et le succs, sur
la scurit des systmes routiers automatiss.
Arnaud Lanoix [14] utilise Event-B pour spcifier les systmes multi-agents. Il voit que le
raisonnement formel est ncessaire pour assurer leur exactitude et de structurer leur
dveloppement. Event-B est un langage formel avec le soutien de l'outil permettant un
dveloppement progressif des systmes distribus ractifs. Ce langage a t utilis par [14]
comme une mthode formelle pour aider la spcification et le dveloppement sr de SMA
situ. Son effort vise servir de guide pour le dveloppement d'autres SMA, en prenant en
compte les spcificits des agents. Le contrle d'un platoon implique le contrle longitudinal
des vhicules, savoir le maintien d'une certaine distance idale entre eux, et de leur contrle
latral, c'est dire chaque vhicule doit suivre la voie de son prdcesseur. Ces contrles
peuvent tre tudis de faon indpendante [21]; il se concentre uniquement sur le contrle
longitudinal.
Dans [15], Madeleine EL-ZAHER prsente une approche multi-agents ractifs pour le
problme du contrle de platoon dans une configuration linaire. Un platoon est un train de
vhicules form d'un vhicule de tte et un nombre variable de suiveurs. Chaque vhicule
suiveur commande son mouvement seulement par l'interaction avec son vhicule prcdent. Le
control d'un platoon a t conu comme un systme multi-agents ractifs, o chaque vhicule
suiveur est un agent. Chaque comportement de l'agent est spcifi par un modle physique
d'interaction inspir, qui permet de calculer la vitesse du vhicule et la direction d'une seule
perception: la distance au vhicule prcdent. Elle prsente le modle physique d'interaction
inspir avec une tude de cas de vrification de scurit et les rsultats de simulations.
Le but de son travail est d'amliorer cette approche locale en utilisant une fonction physique
des paramtres qui varient par rapport la variation du vecteur de distance entre deux
vhicules. En outre, elle considre l'aspect de vrification. L'acceptation des approches locales
bases sur des systmes multi-agents ractifs dpend de la possibilit de s'assurer au pralable
un ensemble de proprits de scurit sont satisfaits. Model-checking apparat comme une
mthode possible, outil pris en charge, pour la vrification de proprits de scurit. Elle
prsente galement une tude de cas de vrification, applique sa dmarche de contrle de
platoon. La proprit de scurit est vrifie, non collision dans le mode de fonctionnement
standard d'un platoon.

29

CHAPITRE 3
APPROCHE PROPOSE

3.1 Etude informelle


3.1.1 Introduction
Un platoon est dfinit comme un ensemble de vhicules autonomes, qui se dplacent en
convoi. Les enjeux des technologies pour la conduite en convoi de vhicules autonomes et
semi-autonomes sont lis aux diffrents champs d'application envisags : transport urbain de
passagers, agriculture, domaine militaire. Pour le transport, il s'agit du dplacement en milieu
urbain des trains de vhicules sans accroche mcanique, configurables par insertion/
dsinsertion en temps rel. Pour l'agriculture il s'agit de faire fonctionner des flottilles de
machines agricoles roulantes, en adaptant en temps rel la gomtrie de la flottille la
topographie d'un terrain agricole. Pour les applications militaires, le dplacement en flottille,
dans des configurations diffrentes, avec adaptation la topographie et pourra contribuer
l'laboration d'approche de dplacement scuris.
La validation du fonctionnement en convois autonomes ou semi autonomes de vhicules
ncessite l'tude et la qualification du systme par rapport un grand nombre de situations. Que
ce soit dans les transports urbains, l'agriculture ou les convois militaires, le caractre
dynamique de l'environnement des vhicules et l'tendu des perturbations possibles nous
obligent considrer de nombreux scenarios difficiles mettre en place en conditions relles.
Ce chapitre prsentera en premire partie, une description des perturbations en provenance
du platoon et/ou bien de son environnement (exemple : les mtriques communes pour
l'ensemble des milieux). Ensuite, une partie dcrira le comportement, les configurations
possibles et le mode de fonctionnement d'un platoon en prsence de ces perturbations.

3.1.2 Description des perturbations


Des perturbations peuvent se produire durant le dplacement d'un convoi. Ces dernires
peuvent tre classes en deux catgories : momentanes ou permanentes. Dans notre cas, nous
tenons compte d'un certain nombre de perturbation qui prsente un impact directe sur la
scurit du convoi.

30

3.1.2.1 Perturbation momentanes


Les perturbations momentanes peuvent apparaitre pendant le dplacement du convoi. Ce
disfonctionnement pourra concerner un voir plusieurs vhicules du convoi. Ces perturbations
peuvent affecter un diffrents modules des vhicules constituent le convoi.
Module de perception: les informations de perception sont dlivres par des capteurs.
Ces derniers peuvent renvoyer des informations errones (mauvaise mesure de la
distance des obstacles, etc.) ou bien ne plus envoyer dinformation. Ceci peut avoir
diffrentes causes internes ou externes affectant le fonctionnement des capteurs ou des
algorithmes de traitement des donnes associs.
Module de communications : dans le cas ou il existe un mcanisme de communication
entre vhicules, ou entre vhicules et infrastructure (fixes ou mobiles), pour l'change
d'informations. Cette communication peut subir des interfrences causant une perte de
dbit et/ou de trames de donnes.
Module de commande : des perturbations peuvent affecter toute la chane de contrlecommande des vhicules (perturbations lectromagntiques, dysfonctionnement de
composants lectroniques, etc.).
Module fonctionnel : les vhicules du convoi peuvent subir des perturbations qui
modifient leur dynamique, telle qu'une perte d'adhrence, des batteries faibles,
crevaison lente, etc.
Module de dcision : les vhicules du convoi peuvent tre amens modifier leur
trajectoire et/ou leur vitesse du fait de la prsence d'un obstacle mobile ou fixe et/ou
dun lment de l'infrastructure comme un feu, un passage piton, etc.

3.1.2.2 Perturbation permanentes


Certaines perturbations peuvent tre permanentes et qui influent sur le fonctionnement du
convoi :
Module de perception : une rupture de la perception peut arriver due une panne
permanente dun capteur ou a un bug du driver.
Agissant sur la communication : une panne de la communication peut entrainer un arrt
permanent des changes de donnes entre vhicule et/ou infrastructure.
Agissant sur la commande : des perturbations peuvent affecter de manire permanente
toute la chaine de contrle-commande (arrt dun moteur ou dun actionneur, etc.).
Agissant sur la dynamique d'un vhicule : une dfaillance matrielle ou la panne dun
vhicule peut entrainer une modification de sa dynamique (crevaison rapide, panne
mcanique ou lectronique, etc.).
Agissant sur la traversabilit de la trajectoire : un arrt d'un vhicule peut tre caus par
un choc avec une entit mobile ou fixe et/ou par un lment de l'infrastructure comme
une voie sans issue.

31

3.1.3 Description des mtriques


Un ensemble de mtrique est utilis pour valuer et qualifier le fonctionnement des convois
de vhicule. Ces mtriques sont lies aux distances entre vhicules mais galement aux
paramtres internes de fonctionnement des algorithmes de perception, de commande et du
processus de communication s'il existe.
Ecarts entre vhicules : les carts mesurs entre les vhicules dpendent du type de
configuration mise en place dans les scenarios. Ils sont dfinis au moyen de deux paramtres :
l'cart latral, est la distance souhaite entre laxe longitudinale dun vhicule et laxe
longitudinale de son leader local, des deux cts adjacents de vhicules, en supposant que ces
axes sont parallles. Le second, l'cart longitudinal, est la distance entre leader local et
vhicule suiveur, en supposant que les axes longitudinaux sont parallles. On dfinit lcart
longitudinal comme la distance sur laxe vertical, rciproquement, lcart latral, la distance sur
laxe horizontal, comme le montre la figure 11.

Figure 11 : Ecarts latral et longitudinal entre deux vhicules dun convoi.


Cette mtrique pourra tre influence par d'autres paramtres (paramtres de commande,
paramtres de contrle, prcision des capteurs et le temps de localisation).

32

Intgrit de positionnement : cette mtrique est destine mesurer la prcision de la


localisation du vhicule de tte et des "vhicules suiveurs" dans le cas ou les vhicules
suiveurs se localisent par rapport la dtection du vhicule leader et aussi du vhicule
prcdent dans le cas ou les vhicules suiveurs se localisent par rapport la dtection du
vhicule prcdent dans le convoi.
Diffrentes techniques pourront tre utilises allant de la qualit des signaux
(GPS/WIFI/Bluetooth) la considration du rapport signal/bruit des informations
tlmtriques ou visuelle. Pour calculer cette mtrique, on sappuiera, sur les travaux
prsents dans [22].
Intgrit de la commande : cette mtrique est destine mesurer la qualit de la
commande des vhicules du convoi. Il s'agit de mesurer la capacit de la stratgie de
commande contrler le vhicule dans un espace de scurit pralablement dfini.
Cette mtrique considrera la saturation des actionneurs mais galement l'observation
des rponses des vhicules par rapport aux consignes envoyes. On s'appuiera par
exemple sur les travaux prsents dans [23].
Intgrit physique : cette mtrique est destine mesurer le risque de collision d'un des
vhicules du convoi avec un lment qui est extrieur au convoi (vhicule, piton, etc.).
Cette mtrique doit considrer l'observation de la zone de scurit ncessaire
l'vitement de la collision soit par un arrt du vhicule ou son vitement ainsi que les
lments dtects dans cette zone et la probabilit priori de dtecter tout lment
pntrant cette la zone. Une grandeur de type TTC (time to collision) pourra tre
calcule.
Communication : la communication entre vhicule est une composante fondamentale du
fonctionnement des convois dans le cas dun contrle dit globale. En effet, la gestion
dun convoi repose sur le fait de pouvoir communiquer aux vhicules les paramtres de
configuration des formations mais galement les paramtres d'tat du convoi (position
et vitesse des autres vhicules, trajectoire suivre, etc.). Cette mtrique s'appuiera sur
les mesures de puissance de rception fournies par les matriels de communication.

3.1.4 Prsentation du comportement d'un platoon


Un platoon est dfinie comme un ensemble de vhicules autonomes, qui se dplacent en
convoi. Le contrle d'un Platoon implique le contrle longitudinal et latral des vhicules.
Le contrleur de vhicule peroit des informations sur son environnement avant de produire
une acclration instantane pass pour le moteur. Le systme de platoon volue suivant un
modle Influence/Raction [24] propos par Ferber & Muller : (i) tous les vhicules effectuent
des perceptions (perceived_spd, perceived_dist, perceived_pre_spd, perceived_Env), (ii) toutes
les influences sont dcides suivant ltat de lenvironnement et la mission du systme, (iii)
tous les vhicules ragissent en combinant toutes les influences. Ce modle permet de dcrire le
comportement dun systme de platoon.

33

Figure 12 : Platoon de vhicules dans un repre cartsien (X, Y)

Le comportement des contrleurs des vhicules peut tre rsum comme suit (voir figure 12) :
i.

ii.

l'tape de perception : le contrleur de chaque vhicule utilise des capteurs pour


obtenir des informations relatives sa vitesse (perceived_spdi), la distance
(perceived_disti) qui le spare du vhicule que le prcde (perceived_pre_spdi et
perceived_yposi).
l'tape de dcision : en se basant sur les informations de l'tape perception, le
contrleur de chaque vhicule peut connatre sa distance (perceived_disti) par rapport
au vhicule que le prcde. Il transmettra une nouvelle valeur l'acclration/ou bien
dclration (accel_decision) pour maintenir la distance requise avec le prcdent.
Cette valeur peut tre positive (acclration) ou ngative (dclration). La distance
34

idale entre le vhicule et son prdcesseur doit tre suffisamment grande pour viter
des collisions en cas de problme et suffisamment courte pour que le train de vhicules
ne prenne pas trop de place dans le trafic. L'acclration accel_decisioni est estime en
fonction des mesures en provenance des capteurs l'aide de formules mathmatiques.
Ideal_dist = Longit_Min + spd /* la distance idale entre deux vhicules */
perceived_disti = perceived_yposi - yposi /* la distance perue par le vhicule i */
new_accel = perceived_disti - Ideal_dist + perceived_spdi - spdi /*la nouvelle acclration
prise par une vhicule i */
si new_accel Min_accel..Max_accel alors /* la nouvelle acclration appartient
l'intervalle [Min_accel..Max_accel] */
accel_decisioni = new_accel /*l'acclration dcide est gale la nouvelle acclration*/

si new_accel > Max_accel alors


accel_decisioni = Max_accel /*l'acclration dcide est gale une acclration maximale*/
si new_accel < Min_accel alors
accel_decisioni = Min_accel /*l'acclration dcide est gale une acclration minimale*/

iii.

l'tape de raction: une acclration instantane dcide accel_decisioni, donc la


position (yposi) et la vitesse (spdi) sont mises jour, en fonction de la vitesse
actuelle (spd) du vhicule [25].

new_spd = spdi + accel_decisioni /* la nouvelle vitesse d'un vhicule est gale sa vitesse actuelle
plus l'acclration dcide de cette vhicule */

si new_spd 0..Max_spd alors


yposi = yposi + spdi + accel_decisioni 2
spdi = new_spd /* mouvement normale de la vhicule i */
si new_spd > Max_spd alors
yposi = yposi + Max_spd - (Max_spd - spdi) (2 accel_decisioni)
spdi = Max_spd /* acclration de la vhicule i */
si new_spd < 0 alors
yposi = yposi - (spdi) (2 accel_decisioni)
spdi = 0 /* dclration de la vhicule i, cas de freinage */

Les vhicules du convoi sont en interaction entre eux et avec lenvironnement


(linfrastructure de lenvironnement). Nous supposons que la communication entre les
vhicules utilisera le protocole WIFI en passant par des points d'accs fixes.
Les vhicules du convoi sont quip par des capteurs sans fil denvoie et de rception des
informations vers les autres vhicules et les infrastructures.

35

Les environnements sont quips aussi par des capteurs dinformation. Ces capteurs sont
ncessaires surtout dans les carrefours pour garantir le dplacement des convois en toute
scurit.
Chaque vhicule du convoi est considr comme point daccs pour pouvoir communiquer.
Il est caractris par un rayon de couverture maximal (Rmax), comme le montre la figure 13.

Figure 13 : Rayon de couverture d'un vhicule

Chaque vhicule du convoi ne communique quavec les entits qui se trouvent dans son
rayon de couverture. Chaque vhicule du convoi reoit directement des informations des
vhicules qui se trouvent dans sa zone de couverture locale, sinon, il passera par un point
d'accs fixe dans sa zone de couverture globale. Actuellement la norme de communication la
plus adapte la communication inter-vhicules et la norme 802.11p. Aussi on utilise la
technologie de communication vhicule--vhicule (V2V), conu pour permettre aux vhicules
de communiquer les uns avec les autres, ou la technologie de communication Vehicle-toinfrastructure (V2I), conu pour permettre aux vhicules de communiquer avec leur
environnement.

36

Le point d'accs (Access point) joue le rle :


d'un centre dinformation : il contient les tats globaux du systme.
d'un dcideur : il prend les dcisions daccrochage/dcrochage, de changement de
configuration, aux vhicules. Lorsquun vhicule souhaite changer son mode de
navigation, il peut demander lautorisation un point d'accs dans sa zone de
couverture globale et il peut obtenir les connaissances des autres vhicules dans sa
zone de couverture locale en interrogeant le point d'accs pour faire ses activits.

3.1.5 Les configurations


Les vhicules dun platoon peuvent prendre plusieurs types de configuration lors de son
dplacement dans son environnement. La configuration du convoi peut diffrer selon son
domaine dutilisation. Ces configurations (ligne, colonne ou chelon) sont caractrises par
deux types variables : lcart longitudinal et lcart latral. Les valeurs de ces deux
caractristiques changent avec le changement dynamique de configuration d'un platoon, comme
le montre le tableau 2.
Nom de la configuration

Ecart longitudinal (L)

Ecart latral (l)

Colonne

Li, i+1 > 0


Pour chaque
vhicule i

li, i+1 = 0
Pour chaque
vhicule i

Ligne

Li, i+1 = 0
Pour chaque
vhicule i

li, i+1 > 0


Pour chaque
vhicule i

Echelon

Li, i+1 > 0


Pour chaque
vhicule i

li, i+1 > 0


Pour chaque
vhicule i

Reprsentation

Tableau 2 : Diffrentes configurations d'un convoi


37

Les configurations colonne, ligne et chelon sont les trois configurations usuelles
couramment utilises dans la littrature, et elles sont dfinies comme suit :
Configuration colonne : Les vhicules sont placs lun derrire lautre. Pour chaque
vhicule, son leader local est son prdcesseur dans le convoi. Lcart longitudinal est
suprieur zro et lcart latral est nul. Cette configuration est connue aussi sous le
nom de train de vhicules.
Configuration ligne : Les vhicules sont placs lun ct de lautre. Pour chaque
vhicule, son leader local est soit le vhicule juste sa droite, soit le vhicule plac juste
sa gauche. Lcart longitudinal est nul et lcart latral est suprieur zro.
Configuration chelon : Les vhicules sont placs sur une ligne diagonale. Pour
chaque vhicule, son leader local est son prdcesseur dans le convoi. Aussi bien lcart
longitudinal que lcart latral sont suprieurs zro.
Toute autre configuration peut tre considre comme une composition de ces trois
configurations. Par exemple, la configuration "T", adopte surtout dans les milieux militaires,
montre dans la figure 14, est la combinaison dune configuration ligne et dune autre colonne.

Figure 14 : La configuration "T"


Les diffrentes configurations peuvent tre dfinies en donnant lcart latral et longitudinal
dun vhicule relativement son leader local. L'cart latral est la distance souhaite entre laxe
longitudinale dun vhicule et laxe longitudinale de son leader local, des deux cts adjacents
de vhicules, en supposant que ces axes sont parallles. L'cart longitudinal est la distance entre
la droite qui fait le ct arrire du leader local et la droite qui fait le ct avant du suiveur, en
supposant que les axes longitudinaux sont parallles. Les distances latral et longitudinal sont
mesures par le module de perception.

38

3.1.6 Prsentation des diffrents algorithmes du comportement


d'un convoi
Dans ce paragraphe, nous allons proposs un ensemble d'algorithmes relatifs la perception
locale et globale, celui de la prise de dcision et pour finir celui ddi la raction. Ces
diffrents algorithmes seront exploits pour garantir la scurit d'un convoi ainsi que lors d'un
changement de configuration.
Le comportement du convoi des vhicules peut tre rsum comme suit :
1. tape de Perception : chaque vhicule utilise des capteurs pour estimer sa vitesse,
lcart longitudinal et latrale entre ces vhicules voisins. Bien sr, le leader na pas
besoin des deux derniers lments dinformation. Les capteurs sont utiliss aussi pour
dtecter les obstacles sur la voie de circulation.
Procdure Perception_Config (Nb_Veh, Config, Longit_Max, Lateral_Max, Rmax,
road_width, veh_width, ypos, xpos)
Variable: platoon_width, longit_dist, lateral_dist
platoon_width = Nb_Veh * road_width + Lateral_Max * (Nb_Veh)
Pour i = 2 Nb_Veh faire
longit_dist(i) = ypos(i-1) - ypos(i)
lateral_dist(i) = xpos(i-1) - xpos(i)
Fin pour
Si (lateral_dist = 0) et (longit_dist > 0) et (longit_dist <= Longit_Max) et
(Longit_Max <= Rmax) alors
Config = colonne
Finsi
Si (longit_dist = 0) et (lateral_dist > 0) et (lateral_dist <= Lateral_Max) et
(Lateral_Max <= Rmax) ET (platoon_width < road_width) alors
Config = ligne
Finsi
Si (longit_dist > 0) et (lateral_dist > 0) et (longit_dist <= Longit_Max) et
(lateral_dist <= Lateral_Max) ET (platoon_width < road_width) alors
Config = chelon
Finsi
Fin

39

Le vhicule leader du convoi peroit son environnement (c.--d. les entits mobiles comme
les pitons et les vhicules voisins). Il collecte les informations sur son environnement laide
de capteurs intgrs dans les vhicules leur environnement.

Fonction Percept_Env (veh) rsultat (dcision)


Dbut fonction
Si Exist() = vraie alors // il existe une entit sur la voie
Dcision (Longit_Min, spd(i), perceived_dist(i), perceived_spd(i))
Finsi
Fin fonction
2. tape de dcision : Chaque vhicule du convoi peut influencer la vitesse en calculant la
distance latrale et longitudinale et transmettre au moteur une acclration instantane.
En outre, sil y a perte de communication cest--dire que le vhicule i est hors
couverture des vhicules voisins donc il faut transmettre une acclration.
Suivant les rsultats du la fonction Percept_Env (veh), le platoon peut modifier sa
vitesse, acclration/dclration et sa configuration dans le but dviter des collisions
entre les vhicules du platoon et tout autre obstacle dans lenvironnement du platoon.
Procdure Dcision (Longit_Min, spd(i), perceived_dist(i), perceived_spd(i))
Variable: Ideal_dist, accel_decision
Ideal_dist = Longit_Min + spd
Pour i = 2 Nb_Veh faire
perceived_dist(i) = perceived_ypos(i) - ypos(i)
new_accel(i) = perceived_dist(i) - Ideal_dist + perceived_spd(i) - spd(i)
Fin pour
Si new_accel Min_accel..Max_accel alors
accel_decisioni = new_accel
Sinon si new_accel > Max_accel alors
accel_decisioni = Max_accel
Sinon si new_accel < Min_accel alors
accel_decisioni = Min_accel
Finsi
Fin
3. tape de raction : xpos et ypos sont estims en fonction de la vitesse, lacclration/
dclration des vhicules et ltat de communication entre les vhicules.

40

Procdure Reaction (Nb_Veh, spd(i), accel_decision(i), decel(i), Rmax)


Pour i = 1 Nb_Veh faire
new_spd = spd(i) + accel_decision(i)
Fin pour
Si (new_spd > 0) et (new_spd < Max_spd) alors
ypos(i) = ypos(i) + spd(i) + accel_decision(i)/2
spd(i) = new_spd
Finsi
Si new_spd > Max_spd alors
ypos(i) = ypos(i) + Max_spd ((Max_spd- spd(i) )2 / (2* accel_decision(i)))
spd(i) = Max_spd
Finsi
Si new_spd < 0 alors
ypos(i) = ypos(i)- (spd(i))2 / (2* accel_decision(i))
spd(i) = 0
Finsi
Notre but est de proposer un algorithme de contrle du comportement sr dun systme de
transport intelligeant multi-configurable dans un environnement dynamique.

Algorithme Comportement_Platoon
Entre : Nb_Veh, Config, Longit_Max, Lateral_Max, Rmax, road_width
Dbut
Perception_Config (Nb_Veh, Config, Longit_Max, Lateral_Max, Rmax,
road_width)
Pour i =1 Nb_Veh faire
Dcision = Percept_Env(i) //chaque vhicule peroit son environnement et
Envoie les informations au module de dcision.
Fin Pour
Raction (Nb_Veh, spd(i), accel(i), Rmax) //suivant la dcision prise, le systme
Ragit dans son environnement en toute scurit.
Fin

41

3.1.7 Modes de fonctionnement du systme


Dans les systmes de transport constitues de vhicules lectriques autonomes, ces derniers
se dplacent en solo (mode Solo) ou en convoi (mode Platoon). Ils peuvent changer de modes,
soit un accrochage, soit un dcrochage.
Un vhicule peut quitter un convoi (dcrochage) pour en rejoindre un autre (accrochage),
comme le montre la figure 15. Aprs avoir dcroch d'un convoi, le vhicule pourrait tre est
conduit manuellement ; il passera nouveau en mode autonome quand il s'accrochera un
autre convoi.

Figure 15: Accrochage et dcrochage d'un vhicule un platoon


Chaque vhicule a 4 modes, deux modes stables : Solo, Platoon et deux modes transitoires :
accrochage, dcrochage. Techniquement, les modes sont marqus par les mots : Solo, Platoon,
Joint et Disjoint.
En mode Solo, les vhicules se dplacent indpendamment.
En mode Platoon, les vhicules se dplacent en convoi. Chaque vhicule suit le
vhicule prcdent en percevant leurs informations et adapte sa vitesse pour garantir la
scurit du convoi.
Les modes Joint/ Disjoint reprsentent les processus de changement du mode Solo vers
mode Platoon et vice versa.

42

Initialement, tous les vhicules peuvent tre en mode Solo ou bien convoi. Chaque
changement du mode est ralis en 4 tapes, selon les modles prcdents : perception,
dcision, raction et changement de mode. On peut noter que :
La transition Solo Joint a choue si et seulement si la taille de convoi atteint le
nombre maximum ou il existe un autre vhicule qui est en train daccrocher/dcrocher
du mme convoi.
La transition Platoon Disjoint dun vhicule a choue si et seulement s'il existe un
autre vhicule qui est en train daccrocher/dcrocher du mme convoi.
Les tapes ncessaires daccrochage d'un vhicule un platoon
Lorsquun vhicule veut accrocher un Platoon :
1. Le contrleur du vhicule vrifie que le mode courant est Solo (mode = Solo)
2. Il se met en mode Joint (mode = Joint), et il envoie une requte daccrochage au
dernier vhicule du convoi, qui se trouve dans sa zone de couverture locale.
3. Les capteurs de vhicule (systme embarqu) vrifient quil est le dernier vhicule du
convoi, en regardant que mode = Solo et que la longueur du platoon n'est pas maximale.
Ainsi, il envoie lautorisation d'accrochage au contrleur du vhicule qui veut
accrocher.
4. Le contrleur, de vhicule qui veut accrocher, reoit lautorisation
Si lautorisation = Nok alors
mode = Solo et quitte le processus daccrochage, retourne au dbut
Si lautorisation = OK alors, continue ltape 5
5. Il envoie une requte au contrleur du dernier vhicule pour demander les informations
du convoi
6. Le contrleur du dernier vhicule reoit cette demande
7. Il rponse les informations ncessaires contrleur de vhicule qui veut accrocher
8. Le contrleur, du vhicule qui veut accrocher, reoit les informations ncessaires
9. Le vhicule fait laccrochage
10. Si laccrochage est chou (timeout ou le vhicule ne peut pas accrocher le convoi), le
contrleur met le mode = Solo, il envoie un message au dernier vhicule pour informer
que le processus daccrochage nest pas russit, et retourne au dbut
11. Dans lautre cas, laccrochage russit, il envoie un message au contrleur dernier
vhicule du convoi pour informer que il a t dans le convoi
12. Si le contrleur du dernier vhicule reoit un message de succs partir de contrleur
de vhicule qui veut accrocher, il envoie un message qui contient la taille de convoi ce
contrleur
13. Ce contrleur reoit le message, qui contient la taille du platoon, il met value = taille +
1, mode =Platoon, finit le processus daccrochage.

43

Les tapes ncessaires de dcrochage d'un vhicule d'un platoon


Lorsquun vhicule veut dcrocher d'un convoi :
1. Le vhicule vrifie, travers son contrleur que le mode courant est Platoon
(mode = Platoon), et quil soit le dernier vhicule du convoi
2. Le contrleur du vhicule met mode = Disjoint, il envoie une requte de dcrochage au
vhicule que le prcde, qui se trouve dans sa zone de couverture, et attende
lautorisation
3. Le contrleur de cette vhicule (contrleur de vhicule que le prcde) envoie
lautorisation au contrleur du vhicule qui veut dcrocher
4. Le contrleur reoit lautorisation
Si lautorisation = NOK alors
Mode = Platoon, quitte le processus de dcrochage et retourne au dbut
Si lautorisation = OK alors, continue ltape 5
5. Il envoie une requte au contrleur de vhicule que le prcde pour demander les
informations du convoi
6. Il rponse les informations ncessaires contrleur
7. Le contrleur du vhicule reoit les informations ncessaires
8. Le vhicule fait le dcrochage
9. Si le dcrochage est choue (timeout ou le vhicule ne peut pas dcrocher du convoi), le
contrleur met le mode = Platoon, il envoie un message au dernier vhicule pour
informer que le processus daccrochage nest pas russit, et retourne au dbut
10. Dans lautre cas, le dcrochage russit, il envoie un message au dernier vhicule du
convoi pour informer qu'il a dcroch du convoi
11. Le contrleur met mode = Solo, value = taille - 1 et finit le processus de dcrochage

3.1.8 Conclusion
Dans cette partie nous avons introduit une nomenclature et des dfinitions spcifiques au
domaine de conduite en convois. Ces dfinitions vont nous servir pour la description formelle
de notre modle.

3.2 Etude mathmatique


3.2.1 Introduction
Dans cette partie, en se basant sur les travaux de Madeleine EL ZAHER [26] et les scnarios
proposs des convois, nous donnons une formalisation du comportement des convois multiconfigurations sous forme mathmatique. Cette formalisation est utilise par la suite pour
analyser le comportement du systme de transport. Les quations prsentes dans ce chapitre
sont inspirs partir des scnarii de comportement de conduite en convoi.

44

Dans notre modlisation mathmatique du dplacement des convois, nous avons utiliss
lapproche dcentralise et de contrle automatique [27].

3.2.2 Perception, prise de dcision et raction


Lors de lvolution dun convoi, les vhicules se dplacent en maintenant une configuration
spatiale spcifique. Cette capacit suppose la mise en uvre de fonctions de perception, de
contrle et de prise de dcision, embarques dans chaque vhicule. Un vhicule autonome est
donc considr comme un systme dot de ces capacits. Larchitecture de ce systme est
reprsente par la figure 16.

Figure 16 : Architecture d'un vhicule autonome


La perception permet au vhicule de se positionner dans son environnement et dy
localiser les diffrents objets (vhicules, obstacles, points de la trajectoire).
La prise de dcision permet au vhicule de calculer les consignes de vitesse, en
sappuyant sur ses perceptions.
La raction agit sur les diffrents organes du vhicule, en appliquant les consignes
calcules. Le contrle, lui mme, ncessite une mesure proprioceptive du mouvement.
Les modules Perception et Dcision de larchitecture sont consolids par des quations
Mathmatiques.
45

3.2.3 quations mathmatiques relatives la perception


Dans notre modlisation mathmatique de dplacement des convois, nous avons utilis
lapproche dcentralise et de contrle automatique [27]. La position dun vhicule
convoi est calcule en utilisant lquation suivante :

du

(1)

Le vecteur ( , ) reprsente la position de vhicule i du convoi. (


position du vhicule et

et

) est la nouvelle

sont respectivement les translations latrales (suivant laxe X)

et longitudinales (suivant laxe Y) qui doivent tre appliqus pour obtenir les nouvelles
positions du vhicules de convoi. Si
colonne, sinon (
et

et

et

> 0 alors on est dans une configuration

) le convoi adopte la configuration ligne. Dans le cas o

, le convoi adapte une configuration chelon.

Dans le modle Perception/Dcision/Raction de vhicules, chacune est quips dun


dispositif de mesure qui permet dvaluer l'inter-distance latrale et longitudinale entre les
vhicules du convoi. Ainsi, chaque vhicule contrle sa vitesse, lacclration et la vitesse du
vhicule qui le prcde.

Figure 17 : carts latral et longitudinal entre deux vhicules pour diffrents types de convoi

Soit deux vhicules voisin


et
comme le montre la figure 17,
o d1 et d2 reprsentent respectivement linter-distance latral et longitudinal entre les
vhicules du convoi. Les distances d1 et d2 sont dfinis comme suit :

46

(2)

Le module de perception permet de localiser les entits et les obstacles sur une voie de
circulation en calculant la distance D_Obs qui spare chaque vhicule d'un obstacle, comme le
montre la figure 18.

Figure 18 : Distance entre vhicule et obstacle

Pour un vhicule

et un obstacle

, la distance D_Obs est

dfinie par lquation suivante :

D_Obs =

(3)

Une autre fonctionnalit, dans le module de perception, est de percevoir la trajectoire de


circulation, comme le montre la figure 19. Une trajectoire est dfinie comme une liste ordonne
de parcelles. La trajectoire T peut tre dcrite comme des mappages dans un intervalle de temps
un espace de position E.

47

Figure 19 : Trajectoire
une trajectoire. Lorigine de la trajectoire est
et la destination
est
. Ces deux points sont appels les extrmits de la trajectoire. Toutes les trajectoires
sont supposes tre au moins continment diffrentiable de sorte que la longueur dune
trajectoire T est bien dfinie comme suit :
Soit

(4)

3.2.4 quations mathmatiques relatives la dcision


La prise de dcision permet au vhicule, en utilisant les donnes de la perception, d'estimer
les consignes de vitesse, acclration/dclration et de direction. Le contrle ou raction
permet de rguler laction des organes moteurs du vhicule, en fonction des consignes. Le
contrle ncessite aussi une mesure proprioceptive du mouvement. Suivant la position de
vhicule leader, la vhicule suiveur calcule la vitesse ncessaire pour reste dans le convoi. Une
quation linaire, reliant la position et la vitesse du vhicule
de son prcdent

avec la position

est utilise :

(5)
O
et
reprsentent respectivement linter-distance latral et longitudinal entre les
vhicules du convoi et reprsente le temps.
La diffrentielle de cette quation peut tre crite sous la forme :
pour une configuration ligne :
(6)

48

pour une configuration colonne :


(7)

3.2.5 Conclusion
Nous avons prsents de faon informelle les diffrentes tapes de perception, dcision et
raction dans le chapitre prcdent. Dans le prsent chapitre nous avons consolids notre
approche par une analyse mathmatique. Dans la suite de notre travail, nous allons prsents
une spcification formelle de notre approche base sur l'utilisation de la mthode Event-B.

3.3 Etude formelle


3.3.1 Introduction
Notre objectif est de dvelopper un cadre formel pour mettre en uvre la spcification et la
vrification d'un systme de platoon et de prouver les proprits de ce modle. Parmi les
proprits qu'on se propose de vrifier, nous pouvons citer : (i) le modle est cohrent
lintrieur de ses limites, cest--dire quaucune action ne le fait sortir de son domaine et
aucune des limites spcifies ne soit viole, (ii) Garantir labsence de collision entre vhicules,
(iii) Garantir que la distance entre les vhicules ne doit pas trop importante, et (iv) aucune
oscillation ne doit se produit.

3.3.2 Spcification et vrification formelle du modle


Pour spcifier le comportement d'un convoi dans un environnement dynamique, nous avons
proposs un modle gnrique (voir figure 21).

3.3.2.1 Prsentation du modle Event-B d'un platoon


La figure 21 donne les diffrents composants de la spcification Event-B du modle d'un
platoon. Le dveloppement se fait suivant des raffinements progressifs bass sur le modle
Influence/Raction (I/R) [24] propos par Ferber & Muller. Les tapes du modle I/R seront
introduites progressivement dans notre approche.
Le modle Event-B reprsente la premire tape de la spcification formelle de systme du
platoon.

49

Figure 20: modle Event-B d'un platoon


50

Le tableau 3 prsente les diffrentes constantes et ensembles de nos contextes.


Nom contexte

Constantes et Ensembles
Nb_Veh
Longit_Min

Dsignation
Nombre de vhicule du convoi
Distance longitudinale minimale entre deux
vhicules voisins
Distance longitudinale maximale entre deux
vhicules voisins
Position initiale sur l'axe Y
Distance idale entre deux vhicules voisins
Vitesse minimale
Vitesse maximal
Vitesse idale
Vitesse initiale
Acclration minimale
Acclration maximale
Acclration initiale

Longit_Max
Initial_ypos
Ideal_dist
Min_spd
Max_spd
Ideal_spd
Initial_spd
Min_accel
Max_accel
Initial_accel

Mouvement

Initial_xpos
Lateral_Min

Road_Width
Rmax
nspd
nypos
Config_colonne
Config_ligne
Config_echelon
veh_width
naccel
Config_type

Position initiale sur l'axe X


Distance latrale minimale entre deux
vhicules voisins
Distance latrale maximale entre deux
vhicules voisins
Largeur de la voie de circulation
Rayon de couverture maximal
Nouvelle vitesse
Nouvelle position longitudinale
Configuration colonne
Configuration ligne
Configuration
Largeur du vhicule
Nouvelle acclration
Les types de configurations possibles

walker

Marcheur sur la voie de circulation, entit

Lateral_Max

Configuration

mobile

vehicle

Vhicule sur la voie de circulation, entit


mobile

stop
Environnement curvature_radius
red

Le panneau de stop, infrastructure


Rayon de courbure, infrastructure
feu rouge, "traffic_light"

green
crossroads
Env

feu vert, "traffic_light"


Carrefour, "traffic_light"
Environnement

Tableau 3 : Nomenclature des diffrentes constantes et ensembles


51

Le tableau 4 prsente les diffrentes variables de nos machines.


Nom
machine

Variables

ypos
longit_dist
perceived_spd
Mouvement_0 perceived_dist
perceived_pre_spd
spd
accel
p_veh
d_veh
lateral_dist
xpos
Obstacle_in_Road
Mouvement_1 ypos_obstacle
perceived_env
config
obstacle
dist_obs_veh
accel_decision
Mouvement_2
timeout
mode

Dsignation
La position sur l'axe Y
Distance longitudinale entre deux vhicules
Vitesse perue
distance perue
Vitesse perue du vhicule prdcesseur
Vitesse
Acclration
Vhicule qui fait la perception
Vhicule qui fait la dcision
Distance latrale entre deux vhicules
Position sur l'axe X (latrale)
Obstacle dans la route
Position de l'obstacle sur l'axe Y (longitudinale)
Perception de l'environnement
Configuration
obstacle, un lment de l'environnement
Distance entre vhicule et obstacle
Acclration dcide
Dlai d'attente
Mode de fonctionnement

Tableau 4 : Nomenclature des diffrentes variables


La figure 21 reprsente diffrentes machines (abstraite et raffinement) avec leurs contextes
respectifs.
1. La machine Mouvement_0 est un modle abstrait du problme du platoon. Le
dplacement des vhicules est globalement considr. L'exigence de scurit de noncollision est exprime ce niveau.
2. Mouvement_1 : C'est le raffinement de la machine abstraite du modle. Les contrleurs
des vhicules peroivent (tape de perception) l'tat local du platoon, (la vitesse d'un
vhicule quelconque (perceived_spd), la vitesse de son prdcesseur
(perceived_pre_speed), et la distance qui spare les deux (perceived_dist)), et l'tat
global du platoon, (les paramtres lis son environnement (perceived_env)), avant de
dcider pour une acclration/dclration en appliquant les lois de contrle/
commande.
3. Mouvement_2 : Cette machine est le deuxime raffinement du modle. L'acclration/
dclration de chaque vhicule est maintenant dcid avant que les vhicules se
52

dplacent. Cela correspond la description de l'tape de dcision. La notion de vitesse


est introduite dans cette tape. Le mouvement de chaque vhicule est dsormais dfini
comme l'application de la vitesse actuelle d'une acclration transmis au moteur (tape
de raction).
En outre, un cadre est ncessaire pour dfinir les constantes globales et les axiomes du
modle, ce sont les CONTEXTS du modle qui dcrivent la partie statique (les constantes et les
ensembles). Chaque Contexte est "vu" (SEES en anglais) par au moins une machine. Ces
contextes sont:
1. Mouvement : Le CONTEXT Mouvement contient les ensembles et les constantes qui
dfinissent les paramtres lis au mouvement de platoon tels que les valeurs, maximales
et minimales, de la vitesse et de l'acclration des vhicules.
2. Configuration : Le CONTEXT Configuration comprend les constantes qui interviennent
dans la vrification et le contrle de la configuration d'un platoon volue dans un
environnement dynamique. Parmi ces constantes, on cite Longit_Max, Longit_Min,
Lateral_Max et Lateral_Min qui spcifie respectivement l'inter-distance longitudinale
maximale et minimale, et inter-distance latrale maximale et minimale entre les
vhicules du peloton.
3. Environnement : Ce CONTEXT contient les ensembles et les constantes qui spcifient
les entits de l'environnement. Ces dclarations sont utilises pour modliser tout type
d'environnement (urbain, agricole ou militaire), les entits et les proprits fixes ou
mobiles. Par exemple, un environnement urbain dynamique comprend plusieurs entits
mobiles et plusieurs infrastructures routires. Les entits mobiles peuvent tre un
piton, vhicule, animal, etc. Les infrastructures routires sont plusieurs dans la rgion
de mouvement, par exemple le panneau STOP, feux de circulation, carrefour, etc.
4. Mode : Le CONTEXT Mode contient les constantes qui dfinissent les paramtres lis
au mode de fonctionnement (Solo, accrochage/dcrochage, Platoon) des vhicules d'un
platoon. Ces dclarations sont utilises pour modliser le processus d'accrochage et de
dcrochage d'un vhicule par rapport un platoon.
Les sections suivantes dtaillent le modle propos, sa spcification en Event-B et leur
vrification l'aide de l'outil Rodin.

3.3.2.2 Prsentation de la machine abstraite : Mouvement_0


Cette machine reprsente un aperu du mouvement du platoon. Initialement le platoon
adopte la configuration colonne. Seules les distances longitudinales inter-vhicules sont
considres. Tous les vhicules se dplacent dans un mouvement simultan. Nous nous
concentrons sur la proprit majeure de la scurit du systme du platoon : aucune collision ne
doit se produire entre les diffrents vhicules.
La machine abstraite "Mouvement_0" contient les variables abstraites et les vnements qui
dfinissent le mouvement de platoon. Les variables ypos, spd et accel prcisent respectivement
la position de chaque vhicule de platoon, la vitesse du vhicule et l'acclration du vhicule.
53

Le dplacement des vhicules, dans un convoi, est reprsent par un cycle en quatre tapes :
Mouvement, Perception, Dcision et Raction (voir figure 21). Chaque tape a t spcifi par
un ensemble de variables, des vnements, et des invariants qui doivent indiquer les proprits
de scurit de toutes les composantes du systme de platoon.

Figure 21 : Modle abstrait d'un vhicule


3.3.2.2.1 Spcification formelle en Event-B
Les positions de vhicules sont exprimes par une variable fonctionnelle
ypos 1..Nb_Veh qui relie l'index d'un vhicule et sa position longitudinale. Le vhicule
de tte est index par 1.
Linvariant de base du modle est que la distance entre deux vhicules soit toujours
suprieure ou gale une valeur positive dite critique.
Ltat du vhicule est alors reprsent par sa positon ypos et sa vitesse spd. La proprit de
sret globale vrifier est le non collision entre les vhicules du convoi. La proprit est
exprime en ajoutant lexpression suivante au INVARIANT du vhicule.

v. (((v 2..Nb_Veh) ((v-1) 2..Nb_Veh))

((ypos(v-1) ypos(v)) Longit_Min))

Lexpression exprime que la distance entre deux nouvelles positions de vhicules successifs
doit tre suprieure une distance critique (Longit_Min).
54

L'vnement moves modlise le mouvement simultan de tous les vhicules. L'estimation


des nouvelles positions pour les vhicules, sont choisies en tenant compte de la proprit de
scurit et sont affectes aux positions prcdentes.
moves
STATUS
ordinary
ANY
new_ypos
WHERE
grd1 : new_ypos 1..Nb_Veh
grd2 : v (((v 1..Nb_Veh) ((v+1) 1..Nb_Veh))
new_ypos(v)) Longit_Min))

((new_ypos(v-1) -

THEN
act1 : ypos new_ypos
END
L'vnement perception modlise la perception de chaque vhicule du platoon en respectant
les proprits de scurit du systme.
Les perceptions d'un contrleur de son environnement sont les suivantes :

sa vitesse perceived_spd 2.. Nb_Veh 0..Max_spd,


la distance perceived_dist 2.. Nb_Veh pour son vhicule de tte, et
la vitesse perceived_pre_spd 1.. Nb_Veh 0..Max_spd de son vhicule prcdent.

Pour l'ensemble des vhicules, nous avons dfinie une variable de perception p_veh, tel que
p_veh 2..Nb_Veh.
Selon le rsultat de la perception, chaque vhicule doit prendre sa dcision. L'acclration/
dclration de chaque vhicule est maintenant dcid avant le dplacement des vhicules. Cela
correspond la description de l'vnement decision qui modlise les dcisions prises par des
contrleurs des vhicules.

55

perception
STATUS
ordinary
WHEN
grd2 : p_veh 2..Nb_Veh
grd3 : Perceived_spd {p_veh spd(p_veh)} 1.. Nb_Veh 0.. Max_spd
grd4 : perceived_dist {p_veh ypos(p_veh - 1) - ypos(p_veh)} 1.. Nb_Veh
grd5 : perceived_pre_spd {p_veh spd(p_veh-1)} 1.. Nb_Veh 0.. Max_spd
THEN
act1 : perceived_spd(p_veh) spd(p_veh)
act2 : perceived_dist(p_veh) ypos(p_veh - 1) - ypos(p_veh)
act3 : perceived_pre_spd(p_veh) spd(p_veh - 1)
END

Une variable accel 1..Nb_Veh Min_accel..Max_accel est introduit pour sauvegarder


l'acclration dcide jusqu' ce que le mouvement se produise. Une autre nouvelle variable
d_veh 1..Nb_Veh doit tre mis en place pour identifier le contrleur du vhicule actuel qui
doit dcider pour une acclration.
decision
STATUS
ordinary
ANY
new_accel
WHERE
grd1 : d_veh 2..Nb_Veh
grd2 : new_accel Min_accel..Max_accel
grd3 : accel {d_veh new_accel} 1..Nb_Veh Min_accel .. Max_accel
THEN
act1 : accel(d_veh) new_accel
END

Le dplacement de chaque vhicule est maintenant dfini comme une raction une
acclration instantane transmis au moteur. La vitesse du vhicule doit maintenant tre prise
en compte afin d'appliquer l'acclration et calculer la nouvelle position.

56

reaction
STATUS
ordinary
ANY
new_spd
new_ypos
new_accel
WHERE
grd1 : veh 2..Nb_Veh
grd2 : new_accel Min_accel..Max_accel
grd3 : new_spd 0..Max_spd
grd4 : new_ypos
grd5 : spd {veh nspd} 1.. Nb_Veh 0.. Max_spd
THEN
act1 : spd(veh) new_spd
END

L'vnement reaction modlise la vitesse instantane de chacun des vhicules, une variable
spd 1..Nb_Veh 0..Max_spd est introduit.
3.3.2.2.2 Vrification formelle par l'outil Rodin
Une Obligation de Preuve (OP) est une formule mathmatique dmontrer afin d'assurer
qu'un composant B (CONTEXT ou MACHINE) est correct, c.--d. :
les contraintes des variables d'un composant B sont respectes,
la machine abstraite, le raffinement et l'implmentation sont cohrents.
Les outils, support la spcification en Event-B comme Rodin, peuvent gnrer les OPs et les
prouver.
Corrections guides par la preuve : Une OP non prouve indique une erreur dans le modle.
D'abord la distance perue perceived_dist a t dfinie par une fonction de 2..Nb_Veh dans .
Une OP a t gnre sur la cohrence de la distance perceived_dist.
perceived_dist {p_veh ypos(p_veh - 1) - ypos(p_veh)} 2..Nb_Veh
Rodin n'est pas en mesure de prouver que xpos (p_veh -1) - xpos (p_veh) 0. Nous n'avons
pas l'hypothse qui peut aider la preuve, l'OP indique une erreur. Lorsqu'on change le type de
perceived_dist de vers l'ensemble , l'OP correspondant soit prouve automatiquement.
Vrification par la preuve : Rodin gnre l'ensemble des OPs (27 OPs pour notre modle
abstrait, relatif la figure 22) ncessaires la validation de la cohrence de notre modle, et de
la prservation de l'invariant par ce modle. Tous les OPs sont dchargs automatiquement par
les prouveurs. La seule OP manuel implique l'initialisation de la position de chaque vhicule :

57

v. (v 1..Nb_Veh (v+1) 1..Nb_Veh


Initial_ypos(v+1) Initial_ypos(v) >
Longit_Min)
avec : v. (v 1..Nb_Veh Initial_ypos(v) = (Nb_Veh v) Ideal_dist)

En fin, toutes les OPs sont vrifies (voir la figure 22), alors nous pouvons conclure que les
calculs sont cohrents.

Figure 22: Les OPs sous Rodin de la machine abstraite


58

3.3.2.3 Premier Raffinement: Mouvement_1


La machine abstraite "Mouvement_0" subit deux raffinements successifs afin de prciser le
comportement d'un platoon durant son dplacement. La figure 23 reprsente une partie du
premier raffinement.

Figure 23 : Modle abstrait et raffin d'un vhicule


Les vhicules dun platoon peuvent prendre plusieurs types de configuration lors de son
dplacement dans son environnement. La configuration du convoi peut diffrer selon son
domaine dutilisation. Ces configurations (ligne, colonne ou chelon) sont caractris chacune
par lcart longitudinal et lcart latral entre les diffrents vhicules.
3.3.2.3.1 Spcification formelle en Event-B
Trois nouveaux vnements moves_colonne, moves_ligne et moves_echelon sont
introduits pour la modlisation de changement de configuration d'un platoon. Ces trois
vnements raffinent l'vnement moves de la machine abstraite.
L'vnement moves_colonne modlise le mouvement simultan de tous les vhicules,
placs lun derrire lautre. L'estimation des nouvelles postions pour les vhicules, sont choisies
en tenant compte de la contrainte de scurit et sont affectes aux positions prcdentes :

59

moves_colonne
STATUS
ordinary
REFINES
moves
ANY
new_ypos
WHERE
grd1 : longit_dist Longit_Min..Longit_Max
grd2 : lateral_dist Lateral_Min..Lateral_Max
grd3 : longit_dist > 0
grd4 : lateral_dist = 0
grd5 : new_ypos 1..Nb_Veh
v (((v 2..Nb_Veh) ((v-1) 2..Nb_Veh))
grd6 :
new_ypos(v))> Longit_Min))
THEN
act1 : Config Config_colonne
act2 : ypos new_ypos
END

((new_ypos(v-1) -

L'vnement moves_ligne modlise le mouvement simultan de tous les vhicules, placs


lun ct de lautre. L'estimation des nouvelles positions pour les diffrents vhicules, seront
faite en tenant compte de la contrainte de scurit.

60

moves_ligne
STATUS
ordinary
ANY
new_ypos
xpos
WHERE
grd1 : longit_dist Longit_Min..Longit_Max
grd2 : lateral_dist Lateral_Min..Lateral_Max
grd3 : longit_dist = 0
grd4 : lateral_dist > 0
grd5 : new_ypos 1..Nb_Veh
grd5 : xpos 1..Nb_Veh
grd6 : v (((v 2..Nb_Veh) ((v-1) 2..Nb_Veh))
1))> Lateral_Min))

((xpos(v) -

xpos(v-

grd7 : v (((v 2..Nb_Veh) ((v-1) 2..Nb_Veh))


(new_ypos(v)=new_ypos(v-1)))
THEN
act1 : Config Config_ligne
act2 : ypos new_ypos
END

L'vnement moves_echelon modlise le mouvement simultan de tous les vhicules, placs


sur une ligne diagonale. Le calcul des nouvelles positions pour les vhicules, sont choisies en
tenant compte de la contrainte de scurit.
La proprit est exprime en ajoutant les expressions suivantes au INVARIANT du modle:
v (((v 2..Nb_Veh) ((v-1) 2..Nb_Veh))

((xpos(v-1) - xpos(v)) > Lateral_Min))

Lexpression exprime que la distance entre deux nouvelles positions de vhicules doit tre
plus grande quune distance critique(Lateral_Min).
v (((v 2..Nb_Veh) ((v-1) 2..Nb_Veh))

((ypos(v - 1) - ypos(v)) > Longit_Min))

Cette expression exprime que la distance entre deux nouvelles positions de vhicules doit
tre plus grande quune distance critique(Longit_Min).

61

moves_echelon
STATUS
ordinary
ANY
new_ypos
xpos
WHERE
grd1 : longit_dist Longit_Min..Longit_Max
grd2 : lateral_dist Lateral_Min..Lateral_Max
grd3 : longit_dist > 0
grd4 : lateral_dist > 0
grd5 : new_ypos 1..Nb_Veh
grd5 : xpos 1..Nb_Veh
grd6 : v (((v 2..Nb_Veh) ((v-1) 2..Nb_Veh))
1))> Lateral_Min))
grd7 : v (((v 2..Nb_Veh) ((v-1) 2..Nb_Veh))
new_ypos(v))> Longit_Min))
THEN
act1 : Config Config_echelon
act2 : ypos new_ypos
END

((xpos(v) - xpos(v-

((new_ypos(v - 1) -

Aussi, deux autres nouveaux vnements perception et detection_perturb sont introduits


dans ce raffinement pour modliser les perceptions de l'environnement (perceived_env Env)
et la dtection des perturbations sur la voie de circulation d'un platoon. Ces deux vnements
raffinent l'vnement perception de la machine abstraite.
Dans ce raffinement, l'vnement perception modlise la perception, faite par les
contrleurs des vhicules, de l'tat local du platoon, (la vitesse d'un vhicule quelconque
(perceived_spd), la vitesse de son prdcesseur (perceived_pre_spd), et la distance qui spare
les deux (perceived_dist)), et l'tat global du platoon, (les paramtres lis son environnement
(perceived_env)).

62

perception
STATUS
ordinary
REFINES
perception
WHEN
grd2 : p_veh + 1 1..Nb_Veh
grd3 : perceived_spd {p_veh spd(p_veh)} 1.. Nb_Veh 0.. Max_spd
perceived_dist {p_veh ypos(p_veh - 1) - ypos(p_veh)}
grd4 :
1.. Nb_Veh
perceived_pre_spd {p_veh spd(p_veh-1)}
grd5 :
1.. Nb_Veh 0 .. Max_spd
THEN
act1 : perceived_spd(p_veh) spd(p_veh)
act2 : perceived_dist(p_veh) ypos(p_veh - 1) - ypos(p_veh)
act3 : perceived_pre_spd(p_veh) spd(p_veh - 1)
act4 : perceived_env(p_veh) : Env
END
L'vnement detection_perturb modlise la dtection des perturbations. Une variable
Obstacle_in_Road BOOL a t mis en place pour savoir s'il existe des obstacles sur la voie
de circulation d'un platoon, et d'estimer sa distance par rapport un vhicule donn.
detection_perturb
STATUS
ordinary
WHEN
grd1 : Obstacle_in_Road BOOL
grd2 : Obstacle_in_Road = FALSE
grd3 : perceived_env
THEN
act1 : Obstacle_in_Road TRUE
act2 : dist_obs_veh ypos(p_veh) - ypos_obstacle
END

3.3.2.3.2 Vrification formelle par l'outil Rodin


Vrification par la preuve : Pour le modle tudi, nous avons principalement dmontr la
cohrence du calcul de la nouvelle position lors de changement de configuration. Rodin gnre
un ensemble de OPs pour valider la prservation de l'invariant et le raffinement. La majorit
d'entre eux est prouv automatiquement par le prouveur, et 10 seulement doivent-tre prouv de
manire interactive :

63

La preuve se fait par l'ajout des pr-conditions et prouver successivement ces sousobjectifs ncessaires dans l'outil Rodin par l'arbre de preuve,
Les autres OPs peuvent tre faite facilement en coupant et en collant l'arbre de preuve
prcdente.
Comme tous les OP sont vrifies (voir figure 24 (a)), alors nous pouvons conclure que les
calculs sont cohrents et que Mouvement_1 raffine Mouvement_0 et la proprit de noncollision est prserve.

Figure 24 : Les OPs sous Rodin du premier raffinement


64

3.3.2.4 Deuxime raffinement : Mouvement_2


Les vnements decision et reaction sont dtaills dans ce raffinement. Dans le modle
prcdent, les acclrations instantanes sont transmises au moteur pour dplacer les vhicules.
Dans ce raffinement, nous introduisons les contrleurs des vhicules qui dcident les
acclrations.
Le dplacement de chaque vhicule est maintenant dfini comme une raction une
acclration instantane transmis au moteur. La vitesse du vhicule doit maintenant tre prise
en compte afin d'appliquer l'acclration et calculer la nouvelle position.
3.3.2.4.1 Spcification formelle en Event-B
Une variable accel_decision 1..Nb_Veh Min_accel..Max_accel est introduit pour
sauvegarder l'acclration dcid jusqu' ce que le mouvement se produise. Une autre nouvelle
variable d_veh 1..Nb_Veh doit tre mis en place pour identifier le contrleur du vhicule
actuel qui doit dcider pour une acclration.
Six nouveaux vnements sont introduits dans ce raffinement. Trois d'entre eux,
decision_normale, decision_minimale et decision_maximale, raffinent l'vnement decision,
les trois autres, move_nor, accelerate et decelerate, raffinent l'vnement reaction.
Une bonne acclration est choisie et enregistre dans la variable accel_decision.
L'vnement decision_normale modlise les dcisions normales prises par des contrleurs
des vhicules. L'acclration dcide est gale une nouvelle acclration dans un intervalle
[Min_accel..Max_accel].
L'vnement decision_maximale modlise les dcisions maximales prises par des
contrleurs des vhicules. Dans ce cas, l'acclration dcide est gale une acclration
maximale.

65

decision_normale
STATUS
ordinary
REFINES
Decision
ANY
new_accel
WHERE
grd1 : d_veh 2..Nb_Veh
grd2 : new_accel Min_accel..Max_accel
grd3 : accel {d_veh new_accel} 1..Nb_Veh Min_accel.. Max_accel
grd4 : ypos(d_veh - 1) - (ypos(d_veh)+spd(d_veh)+(new_accel/2)) > Longit_Min
grd5 : new_accel = new_accel(perceived_dist(d_veh) perceived_spd(d_veh)
perceived_pre_spd(d_veh))
THEN
act1 : accel_decision(d_veh) new_accel
END
decision_maximale
STATUS
ordinary
REFINES
decision
ANY
naccel
WHERE
grd1 : d_veh 2..Nb_Veh
grd2 : naccel > Max_accel
grd3 : naccel {d_veh new_accel} 1..Nb_Veh Min_accel.. Max_accel
grd4 : ypos(d_veh - 1) - (ypos(d_veh)+spd(d_veh)+(new_accel/2)) > Longit_Min
grd5 : perceived_dist(d_veh) > Longit_Min
grd6 : naccel = new_accel(perceived_dist(d_veh) perceived_spd(d_veh)
perceived_pre_spd(d_veh))
grd7 :

naccel = 2 (perceived_dist(d_veh) - Longit_Min +


perceived_pre_spd(p_veh) - perceived_spd(p_veh))

WITH
new_accel = Max_accel
THEN
act1 : accel_decision(d_veh) Max_accel
END
66

L'vnement decision_minimale modlise les dcisions minimales prises par des


contrleurs des vhicules. Dans ce cas, l'acclration dcide est gale une acclration
minimale.
decision_minimale
STATUS
ordinary
REFINES
decision
ANY
naccel
WHERE
grd1 : d_veh 2..Nb_Veh
grd2 : naccel < Min_accel
grd3 : naccel {d_veh new_accel} 1..Nb_Veh Min_accel .. Max_accel
grd4 : ypos(d_veh - 1) - (ypos(d_veh)+spd(d_veh)+(new_accel/2)) > Longit_Min
grd5 : perceived_dist(d_veh) > Longit_Min
grd5 : naccel = new_accel(perceived_dist(d_veh) perceived_spd(d_veh)
perceived_pre_spd(d_veh))
grd6 : naccel = 2 (perceived_dist(d_veh) - Longit_Min +
perceived_pre_spd(p_veh) - perceived_spd(p_veh))
WITH
new_accel = Min_accel
THEN
act1 : accel_decision(d_veh) Min_accel
END

Pour modliser la vitesse instantane de chacun des vhicules, une variable


spd 1..Nb_Veh 0..Max_spd est introduit. L'vnement reaction est raffin en tenant
compte d'un paramtre d'acclration new_accel et le calcul des nouvelles positions nxpos et
des nouvelles vitesses nspd rsultant de l'application de cette acclration. Ces lois de la
raction sont donns dans la Section " ". Trois cas doivent tre distingus en fonction de calcul
de la nouvelle vitesse, l'vnement reaction est raffin comme suit:
1. move_nor : le vhicule se dplace l'intrieur des limites de vitesse acceptable
(nspd 0..Max_spd),
2. accelerate : le vhicule viole la vitesse maximale possible / autoris (nspd > Max_spd),
3. decelerate : le vhicule fait marche arrire (nspd < 0).

67

move_nor
STATUS
ordinary
REFINES
reaction
ANY
nspd
nypos
new_accel
WHERE
grd1 : veh 2..Nb_Veh
grd2 : new_accel Min_accel..Max_accel
grd3 : nspd 0..Max_spd
grd4 : nxpos
grd5 : nspd = new_spd(spd(veh) accel(veh))
grd6 : nypos = new_ypos(ypos(veh) spd(veh) accel(veh))
grd7 : ypos(veh) - nypos > Longit_Min
WITH
new_accel = accel(veh)
THEN
act1 : ypos(veh) nypos
act2 : spd(veh) nspd
END

accelerate
STATUS
ordinary
REFINES
reaction
ANY
nspd
nypos
new_accel
WHERE
grd1 : veh 2..Nb_Veh
grd2 : new_accel Min_accel..Max_accel
grd3 : nspd 0..Max_spd
grd4 : nxpos
grd5 : nspd = new_spd(spd(veh) accel(veh))
grd6 : nspd > Max_spd
grd7 : nypos = new_ypos(ypos(veh) spd(veh) accel(veh))
grd8 : spd(veh) + new_accel > Max_spd
grd9 : ypos(veh) - nypos > Longit_Min
WITH
new_accel = accel(veh)
THEN
act1 : ypos(veh) nypos
act2 : spd(veh) Max_spd
END

68

decelerate
STATUS
ordinary
REFINES
reaction
ANY
nspd
nypos
new_accel
WHERE
grd1 : veh 2..Nb_Veh
grd2 : new_accel Min_accel..Max_accel
grd3 : nspd 0..Max_spd
grd4 : nxpos
grd5 : nspd = new_spd(spd(veh) accel(veh))
grd6 : nspd < 0
grd7 : nypos = new_ypos(ypos(veh) spd(veh) accel(veh))
grd8 : spd(veh) + new_accel < 0
grd9 : ypos(veh) - nypos > Longit_Min
WITH
new_accel = accel(veh)
THEN
act1 : ypos(veh) nypos
act2 : spd(veh) 0
END

L'vnement accrochage modlise le changement du mode Solo au mode Platoon, un


vhicule peut accrocher un platoon quand :
La taille du platoon Nb_Veh
/*Taille d'un platoon ne peut pas passer un nombre fixe*/
Il n'y a pas d'autre vhicule qui est entrain d'accrocher ou de dcrocher de
Ce convoi
accrochage
STATUS
ordinary
WHEN
grd1 : accel 1..Nb_Veh Min_accel..Max_accel
grd2 : nb_veh 1
grd2 : nb_veh < Nb_Veh
grd3 : timeout < Max_TimeOut
THEN
act1 : mode Joint
act2 : nb_veh nb_veh + 1
END
69

On calcule la distance avec le vhicule prcdent, si la distance correspond la distance de


formation du convoi, le vhicule passe au mode PLATOON. Si aprs un certain temps
(timeout) l'accrochage n'a pas eu lieu, le vhicule retourne au mode SOLO.
L'vnement decrochage modlise le changement du mode Platoon au mode Solo, un
vhicule peut dcrocher d'un platoon quand :
Il est la fin du platoon
Il n'y a pas d'autre vhicule qui est entrain d'accrocher ou de dcrocher ce platoon
On Calcule la distance avec le vhicule prcdent, si la distance est suffisamment importante
pour passer au mode Solo, le vhicule applique une dclration pour s'loigner du convoi et il
va passer au mode Solo. Si aprs un certain temps (timeout) le dcrochage n'a pas eu lieu, le
vhicule retourne au mode Platoon.
decrochage
STATUS
ordinary
WHEN
grd1 : accel 1..Nb_Veh Min_accel..Max_accel
grd2 : timeout < Max_TimeOut
grd3 : nb_veh 2Nb_Veh
THEN
act1 : mode Disjoint
act2 : nb_veh nb_veh 1
END
3.3.2.4.2 Vrification formelle par l'outil Rodin
Corrections guides par la preuve : Souvent, les OP non prouves indiquent des checs ou
des erreurs dans le modle. La prochaine OP a t gnre :
xpos (d_veh - 1) - (xpos (d_veh) + spd(d_veh) + new_accel / 2)> Longit_Min
Nous sommes incapables de dcharger cette PO. Il montre que nous avons oubli dans
l'vnement decision une condition pralable reliant new_accel et Longit_Min. En ajoutant la
bonne condition, la PO devient automatiquement prouv.
Vrification de la preuve : La plupart des OPs sont dcharges automatiquement par les
prouveurs, pargn pour seulement 10 OPs non prouves. 6 d'entre eux peuvent tre prouv
manuellement en rcrivant l'oprateur et faire une preuve par cas sur (v 2.. (p_veh - 1))
(v = p_veh). Trois OPs impliquent la justesse de la dcision pour une acclration dans le cas
normal (c'est dire la distance perue est plus grand que Longit_Min). Ces OPs ne peuvent pas

70

tre prouvs avec Rodin pour des raisons d'arithmtiques : le prouveur ne peut pas valider la
rcriture propose qui est ncessaire pour atteindre les preuves.
L'un d'eux concerne la prservation de la proprit sans collision par la dcision:
xpos (V-1) - (xpos (v) + spd (v) + (accel

{d_veh new_accel}) (v) / 2)>Longit_Min

Cette OP est dcharge par la rcriture de l'oprateur


v 2.. (d_veh - 1) v = d_veh.

et de faire une preuve par cas sur

Nous avons principalement dmontrer la cohrence du calcul de la nouvelle position lors


de l'application de l'acclration. Tous ces OP sont difficiles manipuler pour le dmonstrateur,
en raison de l'arithmtique, en particulier avec l'oprateur de division, et la rcriture de
(in)galits qui guident la preuve.
Des OPs doivent tre prouvs pour assurer la solidit du calcul de la nouvelle position, dans
le cas normal.
Des OPs doivent tre prouvs pour veiller ce que la nouvelle position est conforme lorsque
le vhicule tente de revenir en arrire. Ces OP sont vacus par la dcomposition de l'objectif
dans certains sous-objectifs avant de les prouver avec Rodin comme prcdemment.
Comme tous les OP sont vrifies (voir figure 25), alors nous pouvons conclure que les
calculs sont cohrents et que Mouvement_2 raffine Mouvement_1 et la proprit de noncollision est prserve.

71

Figure 25 : Les OPs sous Rodin du deuxime raffinement


72

3.3.3 Validation du modle: animation sous Rodin


Le but de cette tape est de valider les proprits de scurit du modle formel propos.
Cette tape prend, comme entre, le modle Event-B du systme et les proprits de scurit
qui sont spcifis dans l'tape prcdente. Ces proprits sont crites comme des invariants
dans la section INVARIANT du MACHINE Mouvement et ses raffinements.
Animer une spcification en Event-B est simple en principe. Il y a trois tapes:
lutilisateur fournit des valeurs pour les constantes et les ensembles porteurs dans les
contextes (explicitement ou en fixant le domaine explor par les gnrateurs),
lvnement INITIALIZATION est dclench pour mettre le systme ltat initial,
lanimateur entre dans une boucle :
calcul des gardes de tous les vnements, activation de ceux dont la garde est vraie.
Largument des vnements activs paramtrs est choisi arbitrairement,
le spcifieur choisit lvnement dclencher ; les substitutions sont calcules,
vrifier linvariant.
La vrification de linvariant est superflue dans le cas o la spcification a t totalement
prouve. Nanmoins, cest une fonction trs intressante lorsquon utilise lanimation sur les
spcifications non prouves, par exemple pour sassurer quune formule est un candidat
plausible pour un invariant.
Dans la pratique, animer se rvle plus compliqu car les animateurs imposent des
restrictions sur la forme des spcifications. Par exemple, les dfinitions non constructives, les
ensembles infinis, les formules avec une quantification complexe ne peuvent pas tre traites.

3.3.3.1 Lanimation dEvent-B avec PROB


Loutil PROB [11] permet lanimation et le model-checking des spcifications Event-B. En
dautres mots, PROB permet de visualiser le comportement dynamique dune machine B et on
peut systmatiquement explorer tous les tats accessibles dune machine B pour vrifier des
proprits temporelles. PROB est entirement automatique : lutilisateur ne doit pas fournir des
valeurs pour les variables, constantes ou les paramtres des oprations. En contre partie, PROB
est restreint traiter des ensembles finis et des entiers dans un intervalle born. Lefficacit de
lanimation est garantie en retardant lnumration des variables et paramtres aussi longtemps
que possible.
PROB contient deux sous-systmes importants :
un noyau qui traite les types de donnes de B (comme les ensembles et les relations), et
qui implmente les oprations sur ces donnes (par exemple, le calcul du domaine dune
relation),
un interprteur pour les substitutions, prdicats et expressions dune machine B.

73

3.3.3.2 Observations sur lanimation


Le comportement observer durant une animation est naturellement dpendant de la nature
de la spcification. Un point particulirement intressant concerne larrt, ou non, de
lanimation. Lanimation dune spcification en Event-B sarrte lorsquaucun vnement,
lexception dINITIALIZATION, nest activ. Dans certain cas, cest ce quon souhaite le
systme a atteint un tat terminal dans dautre cas, cest une anomalie le systme est gel.
Ainsi, un vnement ne peut pas tre activ si son dclenchement brise linvariant. Donc, le
blocage de lanimation signifie que tous les vnements cassent linvariant.

3.3.4 Conclusion
Les diffrents vnements sont introduits par le raffinement, suivant le modle I / R. Les
vnements sont introduits progressivement, en commenant par le dernier, c'est dire le
mouvement normal d'un platoon, pour finir par la raction de son environnement.
Deux niveaux de raffinement sont ddis la spcification de notre modle de platoon. Les
proprits de scurit sont exprimes au dbut. Ils doivent tre conservs par les vhicules: le
raffinement assure galement qu'ils sont conservs tout au long de l'volution du modle.
Dans cette tape, on a utilis l'outil Rodin pour Event-B qui s'applique trois approches
d'analyses de la scurit des logiciels tel que prsent dans [28] : la dmonstration de thormes
(theorem proving en anglais), la vrification de modle (model checking en anglais) et
l'animation. Au lieu de compilation, l'outil Rodin gnre les obligations de preuve (OPs) pour
la validation de la prservation des invariants du modle. Toutes ces obligations de preuve sont
dcharges par l'outil de preuve en utilisant des solveurs automatiques ou interactifs supports
par Rodin. Un dveloppement donne lieu un certain nombre des obligations de preuve qui
garantissent l'exactitude du modle. L'objectif de cette tape est d'obtenir un modle consolid
du systme tudi, systme de platoon.
Si le traitement d'un vnement est complexe, plus d'un raffinement peut tre ncessaire
pour aider le dmonstrateur.
Les OP gnres sont valids pour garantir la correction de la spcification. Comme prvu,
le nombre des OPs augmente chaque tape de raffinement. La majorit d'entre eux sont
automatiquement dcharge par les prouveurs et les autres se font de manire interactive: les
difficults proviennent essentiellement de l'arithmtique.
ProB permet lanimation et le model-checking des spcifications B. ProB montre que
lanimation ncessaire pour la validation des modles Event-B. Nous croyons quun animateur
et un contre-prouveur peuvent fournir un support valable pour le dveloppeur B, en dcelant
des problmes dans un modle qui ne sont pas couverts par des obligations de preuves (tels que
linterblocage ou dautres comportements inattendus).

74

CHAPITRE 4
Conclusion et perspectives

4.1 Conclusion
Tout au long de ce mmoire, nous avons abords la problmatique de suret de
fonctionnement d'un platoon. Pour cette problmatique, nous avons mis en place une approche
de vrification des proprits de sret, base sur la mthode formelle Event-B.
La premire partie dfinit un tat de lart sur les projets lis aux problmatiques des
vhicules se dplaant en convoi. Dans la continuit de ltat de lart, nous nous sommes
intresss la sret de fonctionnement. En effet, pour lvaluation des attributs de sret de
fonctionnement dun systme, ce dernier doit tre soumis une srie de tests et danalyses
formelles en utilisant les techniques de preuve par thorme pour sa validation. Nous nous
sommes intresss par la vrification de deux proprits : une proprit de scurit qui garantie
la non collision entre les lments du platoon : l'absence de collision dans ce systme peut tre
dfinie par le fait qu' tout moment, il n'y a jamais deux vhicules la mme position, et une
proprit de confort qui garantie que le platoon volue avec un certain degr de confort. Pour
cela, un modle formel reprsentant le comportement du platoon a t dfinit. Dans la
continuit du chapitre de l'tat de l'art, nous avons mens une tude sur quelques langages
formels. Cette tude nous a conduits adopter la mthode Event-B en tant que mthode de
vrification et Rodin en tant quoutil de vrification. Et pour finir, nous avons passs en revue
les travaux connexes lis notre sujet de recherche.
La deuxime partie prsente notre contribution. Dans cette partie, nous avons propos une
approche gnrique de spcification, de modlisation et de vrification formelle de diffrents
scnarios du systme de transport multi-configuration voluant dans un environnement
dynamique, en adoptant la vrification comme technique de preuve. Cette partie dbute par
une tude informelle de notre approche. Dans la continuit de ce chapitre nous avons prsent
une tude mathmatique de notre modle. Et on termine ce chapitre, par l'tude formelle qui
se compose de trois sous parties: la spcification en utilisant la mthode Event-B, la
vrification par l'outil Rodin et la validation par ProB.
Les rsultats de nos travaux [29] ont t publis dans une revue.

75

4.2 Perspectives
Les mthodes de modlisation et de vrification formelles bases sur des modles
vnements discrets par exemple Event-B ne permettent pas, ce jour, de prendre en
compte lensemble des aspects quantitatifs des systmes rels. Nous discutons quelques
observations qui peuvent tre intressantes vis--vis d'Event-B.
La premire observation a trait au problme des quantits numriques. Prouveurs, nombres
rels et discrtisation ne font pas bon mnage. Il ny a pas de notion dapproximation pour les
preuves alors que les modles physiques utilisent cette notion.
La deuxime observation traite du problme des proprits temporelles. Cest un point
crucial pour les systmes critiques ; il faut le traiter trs tt dans la spcification.

76

Bibliographie
[1] J. Wang, H. Lu et H. Peng, System dynamics model of urban transportation system and

its application, Journal of Transportation Systems Engineering and Information


Technology, vol. 8, n 13, p. 83 89, 2008.
[2] A. Houenou, Calcul de trajectoires pour la prconisation de manoeuvres automobiles sur

la base d'une perception multi-capteur : application l'vitement de collision, cole


doctorale 71, Sciences pour l'ingnieur, Compigne, 09-12-2013.
[3] T. Hessburg et M. Tomizuka, Fuzzy logic control for lateral vehicle guidance, IEEE

Contr. Sys. Mag., 1994.


[4] J. Laprie, J. Arlat, J. Blanquart, A. Costes, Y. Crouzet, Y. Deswarte, J. Fabre, H.

Guillermain, M. Kaniche, K. Kanoun, C. Mazet, D. Powell, C. Rabjac et P. Thvenod,


"Guide de la sret de fonctionnement", Cpadus-Editions, Toulouse, France, 324 p.,
1995.
[5] J. M. Spivey, Understanding z : a specification language and its formal semantics,

Cambridge University Press, New York, NY, USA, 1988.


[6] J. M. Spivey, The Z Notation : A Reference Manual, Second Edition, Oriel College,

Oxford, 1998.
[7] R. Duke et G. Rose, Formal Object Oriented Specification Using Object-Z,

Cornerstones of Computing. Macmillan, March 2000.


[8] N. Shanker, D. Dill, T. Henzinger et S. Owre, The SAL Language, SRI International,

California, March, 2001.


[9] J.-R. Abrial, The B-Book : Assigning programs to meanings, Cambridge University

Press, 1996.
[10] J.-R. Abrial, Modeling in Event-B : System and Software Engineering, Cambridge

University Press, 2010.


[11] B. Jens, L. Michael, O. Ligot et S. Mireille, La validation de modles Event-B avec le

plug-in ProB pour RODIN, Technique et Science Informatiques, vol. 27, n 18, p. 1065
1084, 2008.
[12] M. Leuschel et M. Butler, ProB: A Model Checker for B, Springer-Verlag, p. 855-874,

2003.

77

[13] O. Hamouda, M. Kaaniche et K. Kanoun, Safety modeling and evaluation of automated

highway systems, in DSN. IEEE, p. 7382, 2009.


[14] A. Lanoix, Event-b specification of a situated multi-agent system: Study of a platoon of

vehicles, in TASE. IEEE Computer Society, p. 297304, 2008.


[15] M. El-Zaher, F. Gechter, P. Gruer et M. Hajjar, A new linear platoon model based on

reactive multi-agent systems, in ICTAI, p. 898899, 2011.


[16] D. N. Godbole, J. Lygeros, E. Singh, A. Deshpande et A. E. Lindsey, Towards a Fault

Tolerant AHS Design Part II: Design and Verification of Communication Protocols,
Institute of Transportation Studies, University of California, Berkeley.
[17] S. Hall, Automated Highway Systems: Platoons of Vehicles Viewed as a Multiagent

System, in Facult des tudes suprieures de l Universit Laval. Qubec, 194 p , 2005.
[18] M. Miller, Societal and Institutional Issues of Automated Highway Systems,

Intellimotion Paper News, vol. 6, n 13, 1997.


[19] W. H. Sanders et J. F. Meyer, Stochastic activity networks: Formal definitions and

concepts," In Lectures on Formal Methods and Performance Analysis, Springer Verlag,


n %1Stochastic activity networks: Formal definitions and concepts, p. 315-343, 2001.
[20] D. Daly, D. D. Deavours, J. M. Doyle, P. G. Webster et W. H. Sanders, Mbius: An

extensible tool for perfomance and dependability modeling, In 11th International


conference, TOOLS 2000, p. 332- 336, 2000.
[21] P. D. M. Parent, Longitudinal and lateral servoing of vehicles in a platoon, In

Proceeding of the IEEE Intelligent Vehicles Symposium, p. 4146, 1996.


[22] C. TESSIER, Systme de localisation bas sur une stratgie de perception cognitive

applique la navigation autonome d'un robot mobile, Doctorat Vision et robotique,


Universit Blaise Pascal Clermont-Ferrand, 165 p, 2007.
[23] O. Hach, Avoiding sterring actuator saturation in off-road mobile robot path tracking via

predictive longitudinal velocity control, IEEE/RSJ International conference on intelligent


robots and sytems (IROS), San Francisco (CA), USA, September, 2011.
[24] J. Ferber et J. P. Muller, Influences and reaction : a model of situated multiagent

systems, In 2nd Int. Conf. on Multi-agent Systems, p. 7279, 1996.


[25] O. Simonin, A. Lanoix, S. Colin, A. Scheuer et F. Charpillet, Generic Expression in B of

the Influence/Reaction Model: Specifying and Verifying Situated Multi-Agent Systems.,


INRIA Research Report 6304, INRIA, Sept. 2007.

78

[26] M. El-Zaher, J.-M. Contet, P. Gruer, F. Gechter et A. Koukam, Compositional

verification for reactive multi-agent systems applied to platoon non collision verification,
Stud. Inform. Univ., vol. 10, n 13, p. 119141, 2012.
[27] M. Parent et P. Daviet, Automated urban vehicles : towards a dual mode prt (personal

rapid transit), In ICRA, p. 31293134, 1996.


[28] H. Zhang et L. Xu, Application of software safety analysis using event-b, in SERE

(Companion). IEEE, p. 137144, 2013.


[29] M. Garoui, B. Mazigh et E. Missaoui, Formal Verification of Safety Properties for Multi-

Agents System in Dynamic Environment: Application to a Platoon System, International


Journal of Software Engineering Research & Practices, vol. 4, p. 6-13, 2014.

79