Vers une approche de spécification formelle de systèmes complexes : Application aux systèmes de...
description
Transcript of Vers une approche de spécification formelle de systèmes complexes : Application aux systèmes de...
-
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