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