Description de l’approche mod´ elisation formelle/simulation

3.2.1 L’apport des m´ethodes formelles

Les travaux sur la conception et l’´evaluation de la performance de protocoles en en-vironnement v´ehiculaire, y compris pour les communications v´ehicule-`a-v´ehicule, ont ´et´e largement abord´ees au chapitre 2.

La fiabilit´e des syst`emes critiques peut ˆetre am´elior´ee en utilisant des m´ethodes for-melles pour d´evelopper leurs sous-syst`emes critiques [132]. Des preuves math´ematiques permettent de s’assurer que les sp´ecifications r´epondent aux exigences. L’´evolution de la g´en´eration automatique du code ex´ecutable directement `a partir des sp´ecifications for-melles r´eduit le besoin de recourir aux tests unitaires, car la correction de la construction est garantie par des preuves math´ematiques. La formalisation compl`ete d’un syst`eme a souvent ´et´e soulign´ee commme une tˆache difficile et coˆuteuse [133]. Diverses m´ethodes for-melles l´eg`eres [134, 135] ont ´et´e propos´ees pour r´ealiser des sp´ecifications partielles dans des applications cibl´ees. On peut citer par exemple les langages formels pour la sp´ ecifica-tion de la qualit´e de service, notamment E-LOTO [136]. Les m´ethodes formelles peuvent ˆetre appliqu´ees `a diff´erents stades du processus de d´eveloppement, notamment lors de la sp´ecification, de la v´erification et de la g´en´eration du code.

Plusieurs travaux r´ecens´es notamment dans [137, 138] proposent des mod`eles formels pour l’analyse des protocoles de routage pour les r´eseaux ad hoc. Certains ont ´et´e men´es avec la m´ethode B [139] qui est souvent utilis´ee pour raisonner sur des syst`emes complexes. Les auteurs de [140] pr´esentent une approche pour v´erifier des propri´et´es de s´ecurit´e dans les protocoles de communication embarqu´es dans les syst`emes de v´ehicules. Une m´ ethodo-logie pour int´egrer la v´erification des propri´et´es de s´ecurit´e dans les protocoles de r´eseau d`es la conception est propos´ee par [141]. Une extension ´ev´enementielle de la m´ethode B, Event-B, utilise la notion d’´ev´enement pour d´ecrire les actions et non plus des op´erations, ce qui la rend tr`es pratique pour la mod´elisation et l’analyse des protocoles de routage. A titre d’exemples, outre dans [140, 141], Event-B a ´et´e utilis´e pour la mod´elisation formelle des protocoles AODV [142], DSR [143] et OLSR [144].

3.2.2 L’approche propos´ee

3.2.2.1 Justification

Deux probl`emes persistent n´eanmoins aux approches formelles et plaident en faveur d’une approche combin´ee avec la simulation. Le premier concerne l’´evaluation conjointe des composants qui s’adaptent `a la mod´elisation formelle avec les autres composants de l’ITS qui ne s’y prˆetent pas. Des outils tels qu’Event-B permettent d’´evaluer uniquement des mod`eles formels, alors que les outils de simulation offrent la possibilit´e de connecter des mod`eles et des mat´eriels h´et´erog`enes dans un seul processus d’´evaluation. Le second est li´e au fait que, bien que permettant d’animer un nombre limit´e d’objets afin de v´erifier le comportement d’un syst`eme en pr´esence d’interactions, les outils formels n’offrent pas cette possibilit´e `a grande ´echelle. Une premi`ere solution dans cette direction [145] propose d’int´egrer les m´ecanismes de simulation `a ´ev´enements discrets dans un outil de mod´ elisa-tion formelle. Cette approche r´esout en partie les probl`emes li´es `a l’animation des mod`eles et au passage `a l’´echelle, mais pas ceux concernant les interactions avec des mod`eles non formels.

3.2.2.2 D´emarche

La multi-mod´elisation est un paradigme qui permet de relier des mod`eles h´et´erog`enes, individuellement bas´es sur un formalisme diff´erent, en une seule simulation. Les travaux d’Eric Ramat sur la multi-mod´elisation bas´ee sur le formalisme DEVS (Discrete Event Sys-tem Specification) [146] ont ´et´e appliqu´es avec succ`es dans plusieurs analyses bas´ees sur la simulation de syst`emes complexes, notamment grˆace `a l’outil VLE (Virtual Laboratory Environnement) qu’il a contribu´e `a d´evelopper [147]. Au lieu d’introduire des m´ecanismes de simulation DEVS dans un outil formel, comme dans [145], notre id´ee consiste `a int´ e-grer des mod`eles formels dans un laboratoire virtuel bas´e sur la multi-mod´elisation [4]. L’approche propos´ee est de proc´eder en trois ´etapes intervenant d`es la conception du protocole :

− mod´eliser formellement le protocole `a partir de sa sp´ecification fonctionnelle, per-mettant ainsi de v´erifier et de prouver ses propri´et´es (notamment de sˆuret´e et de s´ecurit´e) en recourant `a des m´ethodes et outils formels (B/Event-B),

− int´egrer le mod`ele formel du protocole dans une simulation plus large, grˆace `a la multi-mod´elisation (en transformant le mod`ele Event-B en mod`ele DEVS ´ equi-valent), en le couplant aux mod`eles des autres composants du syst`eme, notamment ceux qui ne se prˆetent pas `a la mod´elisation formelle,

Figure 3.1 – Principales phases de l’approche mod´elisation formelle/simulation DEVS [4]

− int´egrer `a la simulation DEVS des donn´ees r´eelles et connecter la simulation DEVS avec des simulateurs sp´ecialis´es pour les diff´erents composants (par exemple MAT-LAB pour les mod`eles de propagation, OPNET ou NS3 pour les communications, SUMO pour les mod`eles de mobilit´e). Le but est de plonger virtuellement le syst`eme dans un environnement r´ealiste durant les ´evaluations, comme nous l’avons fait aux chapitres pr´ec´edents.

La figure 3.1 d´ecrit les deux phases majeures de l’approche propos´ee lorsqu’elle est ap-pliqu´ee en utilisant l’outil de mod´elisation formelle Event-B et l’environnement de multi-mod´elisation et simulation DEVS (VLE). A partir des sp´ecifications fonctionnelles du protocole, on r´ealise sa mod´elisation formelle avec Event-B et on obtient, moyennant tous les raffinements n´ecessaires, un mod`ele accompagn´e d’une s´erie d’obligations de preuves d´echarg´ees automatiquement (propri´et´es prouv´ees) par le prouveur, ainsi que des obli-gations de preuves r´esiduelles (OPR), non d´echarg´ees. Il s’agit donc de formaliser ce que deviennent ces trois entit´es dans un mod`ele ´equivalent DEVS. Les propri´et´es prouv´ees, sous r´eserve qu’il n’y ait pas d’erreurs de mod´elisation ou de transformation, sont normalement des axiomes qui peuvent ˆetre consid´er´ees comme des contraintes de fonctionnement dans le mod`ele DEVS. La simulation du mod`ele ´equivalent DEVS devrait conduire, `a travers ses r´esultats, `a l’accumulation de nouvelles connaissances sur le comportement du syst`eme dans diverses configurations qui seront susceptibles d’aider `a confirmer ou infirmer les propri´et´es qui n’ont pas pu ˆetre prouv´ees automatiquement (OPR).

3.2.2.3 Verrou scientifique

Les OPR sont les propri´et´es dont la preuve aurait pu ˆetre r´ealis´ee interactivement dans l’outil formel par l’intervention d’un expert. L’id´ee que nous poursuivons est d’auto-matiser cette tˆache ou tout au moins de pallier les ´eventuels d´eficits de connaissance de l’expert grˆace `a la simulation, voire, pourquoi pas, en y int´egrant un syst`eme expert. La projection des OPR dans DEVS constitue et d´emeure le principal verrou scientifique de notre approche. Dans l’hypoth`ese o`u elles pourraient ˆetre formul´ees comme des pr´edicats dont la valeur logique peut ˆetre ´etablie par une simple affectation de valeurs aux variables grˆace aux r´esultats d’une simulation, notre d´emarche permettrait d’ajouter de nouvelles

Figure 3.2 – Mod`ele DEVS du VANET dans VLE

propri´et´es dans la liste de propri´et´es connues sur le protocole mod´elis´e. Dans les autres cas, plusieurs sujets de recherche restent ouverts.