-
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
N dordre :
-
1
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.
-
2
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,
-
3
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 Introduction
...........................................................................................................................................
10
2.1.2 Projets de recherche relatifs au domaine des transports
........................................................................
10
2.1.3 Dautre projets europens et internationaux
.........................................................................................
13
2.1.4 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
-
4
3.1.7 Modes de fonctionnement du systme
..................................................................................................
42
3.1.8 Conclusion
.............................................................................................................................................
44
3.2 Etude mathmatique
..........................................................................................................
44
3.2.1 Introduction
...........................................................................................................................................
44
3.2.2 Perception, prise de dcision et raction
................................................................................................
45
3.2.3 quations mathmatiques relatives la perception
...............................................................................
46
3.2.4 quations mathmatiques relatives la dcision
...................................................................................
48
3.2.5 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
-
5
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
-
6
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
-
7
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 web.utbm.fr/safeplatoon/
2 Universit de Technologie de Belfort-Montbliard
-
8
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.
-
9
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
-
10
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
-
11
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.
4 http://www-sop.inria.fr/visa/mobivip/
5
http://www.agence-nationale-recherche.fr/projet-anr/?tx_lwmsuivibilan_pi2%5BCODE%5D=ANR-07-TSFA-
0013
-
12
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
6 Cellule de Recherche Industrielle en Systmes de Transport
Automatiss Lgers
7
http://www.agence-nationale-recherche.fr/projet-anr/?tx_lwmsuivibilan_pi2%5BCODE%5D=ANR-07-ROBO-
0006
-
13
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].
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
8
http://www.parc-innovation-strasbourg.eu/index.php/CATS-Project/welcome-on-cats-webpage.html
9 http ://www.path.berkeley.edu/
10 http ://www.sartre-project.eu/en/Sidor/default.aspx
11 http ://web.utbm.fr/safeplatoon/
-
14
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].
-
15
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,
-
16
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.
-
17
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.
-
18
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 :
-
19
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 : 1 ; lves : ETUDIANT | #lves
effectif_max]
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
-
20
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
-
21
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:
-
22
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
P est un prdicat
S est une substitution
Excuter S si
P est vrai (sinon skip)
VAR Z IN
S END
Z une liste de variables
S est une substitution
Les variables locales Z sont
utilisables dans la substitution
S
ANY X WHERE P
THEN S END
X est une liste de variables
P est un prdicat
S est une substitution
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 Excuter S et T en mme
temps
CHOICE T OR S END S et T sont des substitutions 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.
-
23
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
-
24
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 :
-
25
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.
-
26
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/
-
27
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],
-
28
(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.
-
29
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.
-
30
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.
-
31
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 contrle-
commande 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.
-
32
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).
-
33
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.
-
34
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. 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).
ii. 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
-
35
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.
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].
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.
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*/
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 */
-
36
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-to-
infrastructure (V2I), conu pour permettre aux vhicules de
communiquer avec leur
environnement.
-
37
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) Reprsentation
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
Tableau 2 : Diffrentes configurations d'un convoi
-
38
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 j