Université LARBI BEN M’HIDI, OUM EL BOUAGHI

Faculté des Sciences Exactes, Sciences de la Nature et de la vie

Département des Mathématiques et Informatique

N° d’ordre : ……

MÉMOIRE DE FIN D’ÉTUDE

En vue de l’obtention du diplôme MASTER recherche en Informatique

Spécialité : Architectures Distribuées

ÉTUDE DE L’APPORT DE LA METHODE B

DANS LA CONCEPTION DES APPLICATIONS EMBARQUEES
CRITIQUES POUR L’AUTOMOBILE
ÉTUDE DE CAS : CONCEPTION ET VERIFICATION FORMELLE
D’UN REGULATEUR DE VITESSE D’AUTOMOBILE

Présenté et soutenu par

MÉROUANI Imad

Le 13/06/2018

Devant le jury composé de :

Pr. MOKHATI Farid ………………………………. Présidant

Dr. BOUTEKKOUK Fateh ………………………... Encadreur

Dr. BOUNEB Zine El Abidine ……………………. Examinateur

Année universitaire 2017/2018

Résumé
La méthode B, ainsi que son extension Event-B, sont des méthodes formelles utilisées pour
le développement de systèmes informatiques dont l’exactitude doit être formellement
établie. Un développement B événementiel est une spécification incrémentale de plusieurs
machines/contextes. Il débute par une spécification mathématique abstraite du système et
s’achève par le code informatique correspondant. Un grand atout d’Event-B est la plate-
forme RODIN, qui est basée sur Eclipse et qui peut être étendue à l’aide de plug-ins.

Le plugin iUML-B est la combinaison de la notation UML et de la méthode Event-B. Il

permet de générer un code Event B de façon automatique à partir de deux vues : statique
(diagrammes de classes) et dynamique (diagramme états transition). La vue fonctionnelle
n’est pas prise en compte par RODIN. Pour remédier à ce problème, nous proposons un flot
de spécification et de vérification formelle basé sur la notation UML et l’Event B. Ce flot se
procède par raffinement successif en partant d’une spécification très abstraite purement
fonctionnelle basée sur le diagramme des cas d’utilisation d’UML jusqu’à l’obtention d’une
machine concrète implémentable sur un ordinateur.

Pour valider notre démarche, nous avons appliqué notre flot à une étude de cas réelle à
savoir « le système de régulation de vitesse de l’automobile ».

‫ملخص‬
‫ هي الطرق الرياضية المستخدمة لتطوير أنظمة الكمبيوتر أين‬،‫ التي تعتبر امتدادا لها‬Event-B ‫ باإلضافة إلى‬،B ‫الطريقة‬
‫يبدأ مع مواصفات‬. ‫ سياقات متعددة‬/ ‫ هو عبارة عن مواصفات متصاعدة من آالت‬Event-B ‫ التطوير‬.‫تكون الدقة مطلوبة‬
، RODIN‫ هو منصة‬Event-B ‫أحد منصات التطوير لل‬. ‫رياضية للنظام تكون مجردة وتنتهي مع برامج كمبيوتر قابلة للتنفيذ‬
.‫ ويمكن تمديدها باستخدام المكونات اإلضافية‬Eclipse ‫التي تعتمد على‬

Event-B ‫ وهو يسمح بإنشاء رموز‬Event-B ‫ وطريقة‬UML ‫ هو عبارة عن مزيج من ترميز‬iUML-B ‫المكون اإلضافي‬
‫لمعالجة هذه‬. ‫ ال تأخذ بعين االعتبار وجهة النظر الوظيفية‬RODIN ‫لكن منصة‬. ‫ثابتة وديناميكية‬: ‫تلقائيًا من وجهتي نظر‬
‫ يتم تنفيذ هذا التدفق من خالل تحسين متتالي بد ًءا من آلة‬. Event-B ‫و‬UML ‫ نقترح تدفقًا استنادًا إلى المكون‬،‫المشكلة‬
.‫مواصفات مجردة جدًا ووظيفية تما ًما حتى الحصول على آلة ملموسة قابلة للتنفيذ على جهاز الكمبيوتر‬

."‫ قمنا بتطبيق هذا التدفق على دراسة حالة حقيقية وهي "نظام التحكم في السرعة السيارات‬،‫للتحقق من صحة نهجنا‬

I
 Je dédie ce Mémoire

À mes parents, à ma famille, à mon entourage et aux personnes qui m’ont soutenu et aidé

II
Remerciements
Je remercie tout d’abord, ALLAH qui m’a donné force et courage pour terminer ce modeste
travail.

Je remercie vivement mon encadreur Dr. Fateh Boutekkouk pour les efforts énormes qu’il
m’a consentis, pour le précieux temps qu’il m’a réservé, pour les estimables informations
qu’il m’a fournies et enfin pour les conseils et les orientations quelle m’a prodiguées.

Je tiens à remercier vivement les membres de jury, et tous les enseignants du département
Math et Informatique.

Je remercie mes parents, pour m’avoir soutenu moralement et matériellement, que grâce à
eux, je suis arrivée à ce niveau.

Je dis merci à tous mes amis et ma famille pour leurs encouragements et leur soutien.

Enfin mes plus chaleureux remerciements pour tout personne ayant participé de près ou
de loin à la réalisation de ce Modeste travail.

III
Table des matières

Résumé ........................................................................................................................................ I
Remerciements ........................................................................................................................ III
Table des matières .................................................................................................................. IV
Introduction générale ............................................................................................................... 1
1. Contexte du travail............................................................................................................................. 1
2. Problématique ..................................................................................................................................... 1
3. Objectif et Contribution ................................................................................................................... 2
4. Organisation du mémoire ............................................................................................................... 2
Chapitre 1 : Véhicules intelligents ......................................................................................... 4
1. Histoire de développement de l’automobile............................................................................ 4
2. Définition de la voiture intelligent............................................................................................... 6
3. Niveaux d’intelligence ...................................................................................................................... 7
3.1 Niveau 0 .................................................................................................................................... 7
3.2 Niveau 1 .................................................................................................................................... 8
3.3 Niveau 2 .................................................................................................................................... 8
3.4 Niveau 3 .................................................................................................................................... 8
3.5 Niveau 4 .................................................................................................................................... 8
4. Technologies ........................................................................................................................................ 9
4.1 Perception ................................................................................................................................ 9
4.2 Planification .......................................................................................................................... 10
4.3 Action ....................................................................................................................................... 10
4.4 Communication .................................................................................................................... 10
5. Régulateur de vitesse intelligent ................................................................................................ 11
5.1 Régulateur de vitesse conventionnel (CC) ................................................................ 12
5.2 Régulateur de vitesse Adaptatif (ACC) ....................................................................... 12
5.3 Régulateur de vitesse Adaptatif et Coopératif (CACC) .......................................... 13
Chapitre 2 : Méthodes formelles .......................................................................................... 14
1. Pourquoi utiliser les méthodes formelles ? ............................................................................ 14
2. Classification des Méthodes Formelles .................................................................................... 15
2.1 Classification de J. Wing .................................................................................................... 15
2.2 Classification de Meyer ..................................................................................................... 16
2.3 Autre classification ............................................................................................................. 17
3. Comparaison des classifications................................................................................................. 19
4. Travaux similaires .............................................................................................................................. 19
4.1 Travail de Jagannath Aghav and Ashwin Tumma................................................... 19
4.2 Travail de Petter Nilsson et al. ....................................................................................... 20
4.3 Travail de T.A.W. (Erwin) Bronkhorst ........................................................................ 20
4.4 Travail du Sarah M et al. ................................................................................................... 20
4.5 Travail du Rob Hieronsa et al. ........................................................................................ 20
4.6 Travail du Olf Stursberga et al. ...................................................................................... 21
4.7 Travail du Anthony Spiteri Staines .............................................................................. 21
4.8 Travail du John Hudak et Peter Feiler......................................................................... 21
4.9 Travail du DeJiu Chen ........................................................................................................ 21
4.10 Travail du John Eriksson ............................................................................................... 21
Chapitre 3 : Méthode Event-B ............................................................................................... 24
1. Langage B événementiel ................................................................................................................ 24
1.1 Contexte .................................................................................................................................. 24
IV
 1.2 Machine ................................................................................................................................... 25
1.3 Principe de raffinement .................................................................................................... 27
1.4 Les obligations de preuve ................................................................................................ 27
1.5 Event-B par rapport à B classique ................................................................................ 27
2. Plateforme RODIN ............................................................................................................................ 28
3. iUML-B .................................................................................................................................................. 29
3.1 Diagrammes de classes ..................................................................................................... 30
3.2 Diagrammes états-transitions........................................................................................ 30
4. Contribution de la méthode B au domaine des applications critiques pour
l’automobile ...................................................................................................................................... 30
4.1 Travail du Rainer Gmehlich et al. .................................................................................. 31
4.2 Travail du Alexander Krupp et al. ................................................................................. 32
4.3 Travail du Richard Banach et Michael Butler .......................................................... 32
4.4 Travail du Stefan Hallerstede et Michael Leuschel ............................................... 32
Chapitre 4 : Conception et implémentation ....................................................................... 33
1. Modélisation UML de système de régulateur de vitesse ................................................... 33
1.1 Diagramme de cas d’utilisation ..................................................................................... 34
1.2 Diagramme de classe ......................................................................................................... 35
1.3 Diagramme d’état-transition .......................................................................................... 35
2 Transformation du diagramme de cas d’utilisation vers EventB.................................... 37
2.1 Éditeur graphique pour les diagrammes de cas d’utilisation ............................ 38
2.2 Outil de transformation UC2EventB ............................................................................ 39
3. Processus de raffinement .............................................................................................................. 40
4. Animation et vérification des modèles .................................................................................... 42
4.1 Animation des diagrammes d’état-transition UML ............................................... 42
4.2 Model-Checking ................................................................................................................... 44
4.3 Vérification des propriétés LTL..................................................................................... 44
Conclusions et perspectives .................................................................................................. 47
1. Conclusion ........................................................................................................................................... 47
2. Perspectives ....................................................................................................................................... 47
Références ................................................................................................................................. 48

V
Introduction générale
1. Contexte du travail
De nos jours, les systèmes informatiques sont devenus de plus en plus très répandus à
cause de leur omniprésence dans plusieurs domaines (avionique, automobile, ferroviaire,
nucléaire, médicale, etc.). Ces systèmes sont caractérisés par leurs aspects critiques,
réactifs et dynamiques.

Par conséquent, l’analyse de tels systèmes est un défi majeur, car l’impact d’un système se
révélant défectueux peut se mesurer en vies humaines ou en pertes financières colossales.
En fait, et malheureusement, nous avons vu plusieurs exemples ayant des conséquences
catastrophiques dues à des erreurs lors de la phase de conception. Dès lors, plusieurs
efforts ont été consacrés pour développer des techniques et des outils permettant
l’amélioration de la qualité et la sûreté de fonctionnement de ces systèmes, dont une
catégorie largement reconnue est la vérification formelle.

Les méthodes formelles permettent de définir des modèles mathématiques décrivant

rigoureusement le comportement de ces systèmes. Ces modèles sont généralement décrits
avec un langage formel muni d’une sémantique précise. Une fois, le système est décrit, ces
méthodes peuvent prouver la correction du modèle en s’assurant que le comportement du
système développé satisfait bien les propriétés spécifiées. Cette vérification peut prendre
plusieurs formes mais les deux formes les plus connues sont la preuve de théorèmes
(theorem proving) et l’approche basée sur les modèles (model checking).

La vérification par preuve de théorèmes (ou assistant de preuves) permet de vérifier de

manière paramétrique un système qui est décrit sous forme d’axiomes. Les propriétés sont
exprimées à l’aide de théorèmes qu’il faut prouver par l’application des règles d’inférence.
D’autre part, la technique de vérification par modèles consiste à vérifier un ensemble des
propriétés recherchées sur le modèle d’un système en explorant de manière exhaustive
l’ensemble des états accessibles, appelé communément espace d’états.

Ce travail du Master s’inscrit au domaine général de la spécification et vérification formelle

des systèmes critiques et en particulier il s'intéresse à l'étude des méthodes formelles de
spécification et de vérification basées sur la méthode B dans le cadre des applications
critiques pour l’automobile.

2. Problématique
La spécification/vérification formelle est une tâche délicate qui demande de solides
compétences et un haut niveau d’expertise. Afin de rendre cette tâche plus aisée, l’idée
adoptée par la plupart des travaux de recherche voisins est d’utiliser la notation UML
comme étant un langage « front-end » puis de générer une spécification formelle de façon
plus au moins automatique. Par conséquent, au lieu de se pencher dans le développement
des spécifications formelles elles même, l’utilisateur se concentre sur la modélisation UML
de son système. Le grand effort dans ce cas est consacré à la génération de façon
automatique une spécification formelle à partir de cette spécification semi-formelle (UML).

La méthode B offre un atelier pour développer des programmes corrects par construction
allant d’une spécification/vérification très abstraite, passant par une suite de raffinements
successifs pour arriver à la fin à une implémentation correcte. La méthode de vérification
1
adoptée par la méthode B est la preuve des théorèmes. La méthode B s’utilise
essentiellement pour spécifier les systèmes orientés données.

L’Event-B est une extension de la méthode B pour spécifier les systèmes réactifs à base
d’événements. L’Event-B a introduit deux nouveaux concepts qui sont l’événement et le
contexte. Ces concepts sont bien implémentés dans l’environnement RODIN.

De plus, RODIN intègre le plugin iUML-B qui permet de générer un code Event B de façon
automatique à partir de deux vues : statique (diagrammes de classes) et dynamique
(diagramme états transition). La vue fonctionnelle n’est pas prise en compte par RODIN.
Pour cette raison et afin d’enrichir l’environnement RODIN, nous proposons d’intégrer la
vue fonctionnelle en rajoutant un module qui génère de code Event B à partir des
diagrammes des cas d’utilisation d’UML.

3. Objectif et Contribution
L’objectif de notre travail est d’étudier l’apport de la méthode B dans les applications
critiques pour l’automobile et en particulier le système de régulation de vitesse, mais la
contribution effective réside dans la proposition d’un flot de spécification et de vérification
formelle basé sur la notation UML et l’Event-B. Notre flot se procède comme suit :

• À partir d’une spécification très abstraite purement fonctionnelle décrite à l’aide d’un
diagramme des cas d’utilisation d’UML, une spécification Event-B est générée
automatiquement, en se référant aux technologies de transformation des modèles
(MDA) de la plateforme Eclipse. À ce stade, nous pouvons formellement vérifier
quelques propriétés comme les inclusions cycliques entre les cas d’utilisations.
• La deuxième étape consiste à raffiner la machine abstraite et son contexte initial en
introduisant les informations sur le domaine d’application en utilisant le plugin iUML-B
pour générer de manière automatique un code Event B à partir des diagrammes de
classe d’UML.
• En troisième étape, nous raffinons les cas d’utilisations en introduisons l’aspect
comportemental. Pour ce faire, nous utilisons le plugin iUML-B pour générer de
manière automatique un code Event B à partir des diagrammes d’états transitions
d’UML.
• Les étapes ultérieures du flot proposé sont des raffinements successifs des diagrammes
d’états transition jusqu’à l’obtention d’une machine implémentable sur un ordinateur.

Chaque étape dans notre flot est accompagnée par une vérification des obligations des
preuves, ces obligations sont générées automatiquement par l’outil de développement
RODIN afin d’assurer la cohérence de chaque machine abstraite/contexte et machine
abstraite/raffinement. Le dernier raffinement sert à générer un code écrit dans un langage
de programmation comme le C, C++, Java, etc. Cette approche nous permettra de générer
un programme correct par construction. En utilisant le plugin ProB nous pouvons encore
vérifier des propriétés (de nature désirables et non désirables) dans notre modèle par la
technique de vérification des modèles.

4. Organisation du mémoire
Ce manuscrit est structuré comme suit :

2
• Une introduction générale qui présente le contexte et la problématique de notre
mémoire et décrit brièvement notre solution.
• Le chapitre 2 sera consacré à la présentation de notre domaine d’étude : les voitures
intelligentes. Un intérêt particulier est donné au système qui nous intéresse plus
particulièrement à savoir : le système de régulateur de vitesse.
• Le chapitre 3 sera consacré à une étude bibliographique des méthodes formelles en
général ainsi que les principaux travaux portant sur l’application de ces méthodes aux
systèmes embarqués pour l’automobile.
• Le chapitre 4 sera consacré à la présentation de notre contribution où en détaillant le
flot de spécification et de vérification formelle basé sur la notation UML et l’Event-B. Ce
flot, comme nous l’avons indiqué plus haut a été évalué sur une étude de cas réelle à
savoir, le système de régulateur de vitesse.
• Nous terminerons ce document par une conclusion générale qui discute les apports de
notre travail. Ainsi que les perspectives envisagées en vue d’ouvrir de nouvelles
directions de recherche.

3
Chapitre 1 : Véhicules intelligents
Les véhicules ont été l’une des plus grandes inventions dans l’histoire moderne, car ils ont
révolutionné notre mode de vie et ont énormément contribué au développement de nos
sociétés. Depuis plusieurs décennies, des chercheurs ont fait et continuent de faire des
efforts pour incorporer divers types d’intelligence dans les véhicules traditionnels ce qui
conduit au terme de véhicules intelligents. Grâce à des systèmes de navigation autonome et
des systèmes dédiés à la sécurisation de la conduite, ces véhicules ont pour mission d’aider
le conducteur à une meilleure compréhension et interprétation de l’environnement tout en
l’assistant dans la prise de décision sans toutefois le déresponsabiliser. Le régulateur de
vitesse est un système embarqué dans l’automobile qui permet de contrôler
automatiquement la vitesse du véhicule.

Dans ce chapitre, nous commencerons par introduire l’histoire de développement de

l’automobile. Ensuite, nous aborderons le développement et la conception de la voiture
intelligente, en définissant ce concept et les différents niveaux d’intelligence. Par la suite, la
question des technologies utilisées pour cette innovation sera abordée. Pour terminer, le
système de régulation de vitesse dit « intelligent » sera présenté.

1. Histoire de développement de l’automobile

Les véhicules ont été l’une des plus grandes inventions dans l’histoire moderne, car ils ont
révolutionné notre mode de vie et ont énormément contribué au développement de nos
sociétés. Comme la plupart des inventions, il n’existe pas de point précis dans le temps qui
constitue l’invention de l’automobile. Celle-ci est le fruit d’une évolution d’idées et d’actions
qui a débuté avec des plans de véhicule à moteur dessinés par Léonardo da Vinci (1452-
1519) et Isaac Newton (1642-1727) (Figure 1.1).

Un véhicule automobile est « mû par un moteur » [1]. Partant de cette définition, la

première automobile a été inventée par le Français Nicolas-Joseph Cugnot en 1769. Il
s’agissait d’une voiture à trois roues équipée d’un moteur à vapeur et destinée à l’armée
française (Figure 1.2).

Figure 1. 1 - Voiture à vapeur de Newton, Figure 1.2 - La première automobile

en 1680 construit par Cugnot, en 1769.

Le premier moteur à essence est inventé par Daimler et Maybach en 1885 et est incorporé
dans un véhicule à trois roues conçu par Karl Benz. Il est le premier à demander un brevet
pour un véhicule à essence. Daimler et Benz ne sont pas considérés comme des fabricants
de voitures. Ils créent des moteurs et dessinent des véhicules uniquement dans le but de les
tester. Les premiers véritables constructeurs automobiles sont Français : Panhard et
Levassor (1889) et Peugeot (1891). Benz devient, à son tour, constructeur en 1894 et crée
4
le premier modèle standardisé avec 134 productions, il devient ainsi le plus gros
constructeur automobile dans le monde en 1900. Aux États-Unis les premières voitures à
essence qui circulent sont des modèles importés d’Europe. En 1908, la sortie de la Ford T
de Henry Ford remporte un grand succès. Il a pour ambition de créer des voitures
abordables pour l’ensemble de la population. C’est pourquoi il améliore les performances
de la ligne d’assemblage par la réduction du temps de production et par conséquent des
coûts.

Figure 1. 3 - Henry Ford et la «Ford T»

Avec l'augmentation du prix des carburants et ses impacts terribles sur l'environnement,
les véhicules électriques ont vu le jour. Les propulsions électriques ont un meilleur
rendement que celles à combustion (Diesel, essence, hydrogène) ; dans une vision globale
du véhicule, l'énergie embarquée dans les batteries très lourdes grève l'efficacité et le
rendement pour une charge utile donnée. Au début des années 2000, ces véhicules arrivent
à un très bon niveau d’autonomie, et par conséquent, la vente de ce type de véhicules a
progressé dans le monde.

En 2010, Google présente un prototype de voiture électrique sans conducteur, appelée plus
tard la Google Car (figure 1.4). Depuis cette présentation, les constructeurs automobiles se
lancent dans la recherche et le développement de la voiture complètement autonome.

Figure 1. 4 - Google Car

Début 2015, Mercedes a dévoilé son camion et sa voiture autonome sans conducteur
(Figure 1.5), capables de prendre le contrôle sous certaines conditions limitées. En plus,
plusieurs autres voitures autonomes sont développées par les grands constructeurs
comme (BMW, Audi...), ouvrant la porte la concurrence en terme de voiture intelligentes. En
2020, il se pourrait que les premières voitures totalement autonomes soient mises en
vente.

5
 Figure 1.5 - La voiture et le camion autonomes de Mercedes

2. Définition de la voiture intelligent

Depuis plusieurs décennies, des chercheurs ont fait et continuent de faire des efforts pour
incorporer divers types d’intelligence dans les véhicules traditionnels ce qui conduit au
terme de véhicules intelligents. Grâce à des systèmes de navigation autonome et des
systèmes dédiés à la sécurisation de la conduite, ces véhicules ont pour mission d’aider le
conducteur à une meilleure compréhension et interprétation de l’environnement tout en
l’assistant dans la prise de décision sans toutefois le déresponsabiliser.

Connus sous l’acronyme ADAS ou Advanced Driver Assistance System (systèmes d’aides à la
conduite), il s’agit de systèmes permettant d’améliorer la sécurité routière tout en
pourvoyant confort au conducteur. Ils sont développés pour sécuriser le trafic routier en
assistant le conducteur pour une meilleure interprétation de son environnement. Grace aux
informations issues des différents capteurs sur le véhicule, les ADAS permettent [2]:

• D’alarmer le conducteur lors de l'apparition d'une situation dangereuse risquant

d'aboutir à l'accident ;
• De libérer le conducteur d'un certain nombre de taches qui pourraient atténuer sa
vigilance ;
• D’assister le conducteur dans sa perception de l’environnement (détecteur de
dépassement, détecteur de risque de gel, etc.).

Quelques exemples de systèmes d’aide à la conduite :

• Direction assistée
• Changement de rapport automatique
• Le système de navigation (GPS)
• L’assistance au changement de voie
• Les systèmes d’évitement des collisions (Precrash system)
• Le régulateur intelligent de vitesse (CC, ACC et CACC)
• La vision nocturne
• Le contrôle adaptatif de lumière
• Système d'alerte de sortie de voie
• Assistance au parking
• Reconnaissance des panneaux de signalisation
• Détection des angles morts

6
La Figure 1.6 illustre différents ADAS pouvant être développés pour les véhicules
intelligents.

Figure 1. 6 - Applications développées pour les véhicules intelligents [2]

De nouvelles applications sont en cours de développement telles que : le contrôle de l’état

du conducteur (fatigue, inattention, distraction, influence d’une drogue ou d’alcool,
glycémie...).

Certaines technologies d’aide à la conduite sont déjà commercialisées. Cependant, ces

systèmes ne représentent que le niveau primaire d’autonomisation que l’on souhaite
atteindre. Pour qu’une voiture soit totalement autonome, elle nécessite de nombreuses
technologies matérielles ainsi que logicielles.

3. Niveaux d’intelligence
Les avancées technologiques dans le secteur de l’automobile créent un continuum entre la
voiture conventionnelle, c’est-à-dire la voiture qui nécessite le contrôle du conducteur en
permanence et la voiture totalement autonome, qui ne requiert - à aucun moment (sauf
pour définir la destination) - l’intervention du conducteur [3].

L’agence fédérale américaine des États-Unis chargée de la sécurité routière « National

Highway Traffic Safety Administration » (NHTSA), a créé cinq niveaux afin d’aborder les
discussions avec les parties prenantes avec plus de clarté [4].

3.1 Niveau 0

Le conducteur est maître du véhicule à tout moment. Il contrôle les fonctions primaires
telles que les freins, le volant, l’accélérateur et il reste le seul responsable du comportement
de la voiture. Il doit surveiller la route et manœuvrer le véhicule de manière sûre. Les
véhicules équipés de systèmes d’alerte mais sans autorité sur les fonctions primaires sont
considérés comme appartenant au niveau 0. Les voitures de niveau 0 sont équipées
d’allumage de phares automatique ou de capteurs de recul, par exemple.

7
3.2 Niveau 1

Il existe une automatisation d’une ou plusieurs fonctions du véhicule. Il est impossible que
ces fonctions soient automatisées en parallèle. Le conducteur garde le contrôle général du
véhicule et reste responsable de la conduite de celui-ci mais il cède un certain contrôle des
fonctions primaires. La voiture prend le contrôle d’une fonction ou apporte un
support/contrôle supplémentaire au conducteur. En aucun cas, la voiture ne remplace la
supervision de l’être humain, ni devient responsable du comportement du véhicule. C’est
pourquoi deux fonctions primaires ne sont pas contrôlées par le véhicule simultanément.
Cela empêche le conducteur de se détourner entièrement de la conduite en lâchant le
volant et en ne posant plus les pieds sur les pédales. Les voitures du niveau 1 sont équipées
d’un régulateur de vitesse (Cruise Control), du freinage automatique et/ou d’un système de
maintien sur une bande, par exemple.

3.3 Niveau 2

Les véhicules de niveau 2 disposent de fonctions primaires programmées pour agir en

parallèle. Le véhicule et le conducteur se partagent l’autorité dans certaines situations. Le
conducteur reste responsable du comportement de la voiture et reste disponible pour
reprendre le contrôle rapidement car le système peut le lui céder sans l’alerter
préalablement. Les voitures du niveau 2 autorisent, par exemple, l’activation du régulateur
de vitesse adaptatif (Adaptative Cruise Control ACC) et le maintien sur une bande en même
temps lorsque le trafic est dense et que la vitesse ne dépasse pas les 30 km/h. La différence
avec les voitures de niveau 1 est que le conducteur peut maintenant se désengager
physiquement de la conduite du véhicule en lâchant le volant et en enlevant ses pieds des
pédales. La NHTSA précise que le désengagement est physique car le conducteur doit
continuellement surveiller la route et reprendre le contrôle lorsque les limitations requises
ne sont plus rencontrées. Dans notre exemple, le conducteur reprend le contrôle lorsque la
circulation se fluidifie et qu’il peut rouler à plus de 30 km/h.

3.4 Niveau 3

Les véhicules de niveau 3 ont la capacité de contrôler l’ensemble de leurs fonctions sous
certaines conditions environnementales et de trafic limitées. C’est au système de la voiture
de surveiller les changements de ces conditions qui requièrent la retransmission du
contrôle au conducteur. Ce dernier reste disponible pour des reprises de contrôle
exceptionnelles mais dans un délai raisonnable. La spécificité du niveau 3 est que le
conducteur ne surveille pas la route en permanence : la voiture détecte à l’avance les
éléments perturbateurs à sa conduite autonome et le prévient qu’une reprise de contrôle
sera nécessaire. Avec les véhicules de niveau 3, le conducteur entre sa destination et la
voiture s’occupe du reste. Elle déterminera l’itinéraire, accélérera, freinera et se dirigera
d’elle-même. Ces véhicules savent désormais se diriger dans les carrefours, s’arrêter aux
feux de circulation et utiliser les ronds-points. L’action du conducteur est requise lorsque la
voiture approche de zones d’incertitude comme une zone de travaux, par exemple.

3.5 Niveau 4

Le véhicule est capable de contrôler l’ensemble des fonctions (primaires et secondaires) et

de s’adapter aux conditions de route durant l’entièreté du trajet. Le conducteur se charge
uniquement d’introduire sa destination mais ne doit pas surveiller ce qu’il se passe. Ces
véhicules peuvent se déplacer sans passager à bord. Le véhicule est responsable de sa

8
conduite. À bord d’une voiture de niveau 4, nous introduirons la destination et rien d’autre.
La voiture se charge des fonctions primaires et secondaires (clignotants, phares, essuie-
glace). Elle choisit également l’itinéraire le plus rapide en fonction des conditions de
circulation : elle évite les zones congestionnées par exemple. Une fois arrivée à destination,
la voiture laisse descendre ses passagers et elle part se garer.

4. Technologies
La voiture intelligente peut être considérée comme un robot. En effet, un robot est défini
comme « un appareil automatique capable de manipuler des objets ou d’exécuter des
opérations selon un programme fixe, modifiable ou adaptable ». Un robot doit être capable
d’effectuer trois fonctions (perception, planification et action) de manière efficace.

Le modèle perception-planification-action (Figure 1.7) est le modèle fondateur de la

plupart des systèmes robotiques [3]. L’être humain réalise ces fonctions naturellement,
sans même y penser. Or, pour qu’un système autonome exerce ces fonctions, cela requiert
un travail complexe en ingénierie. Vu la complexité et l’incertitude liées à la conduite, les
trois fonctions constituant le modèle doivent être opérées en même temps et plusieurs
modèles doivent tourner de manière asynchrone [5].

Figure 1. 7 - Le modèle perception-planification-action

4.1 Perception

Un robot, a la capacité de percevoir les éléments primordiaux de son environnement. Cela

le différencie d’une simple machine La fonction de perception de la voiture autonome
rassemble les informations sur l’environnement externe ainsi que sur son système interne,
elle les fusionne afin de construire un modèle qui représente et décrit le robot, son
environnement et la relation entre les deux [5]. Dans le cas des véhicules intelligents, la
collecte de données est très vaste, elle reprend les conditions météorologiques, de trafic, les
caractéristiques du véhicule ainsi que des informations sur le comportement du
conducteur.

Cette fonction de perception pose plusieurs difficultés. Premièrement, il est nécessaire que
les informations viennent de plusieurs capteurs différents car un capteur unique ne détecte
que ce qui est à sa portée et dans son angle. Par conséquent, les informations seront plus
fiables si elles proviennent de plusieurs capteurs de différents types. Deuxièmement, les
informations viennent de plusieurs sources et il est nécessaire qu’elles soient traitées
rapidement pour éviter une accumulation d’informations non traitées. Troisièmement, le
système doit pouvoir différencier les bonnes et les mauvaises informations.
Quatrièmement, les données venant de divers capteurs et à différents moments créeront
des contradictions. Le système doit être capable de les réconcilier et de créer un modèle
9
assez précis pour permettre au véhicule de conduire prudemment et de manière efficace
[5].

Les hardwares nécessaires à cette fonction de perception sont les caméras, les radars, les
capteurs ainsi que les émetteurs et récepteurs GPS. Il existe certaines limites à cette
combinaison de technologies. Pour commencer, certaines d’entre elles sont sensibles aux
conditions climatiques : elles sont moins fiables par temps de pluie ou de brouillard.
Ensuite, les différents revêtements du sol ont un impact : leur réflexivité varie. Les
différents capteurs sont donc calibrés en fonction de ceux-ci. Or, la détermination du type
de revêtement n’est pas toujours possible par les différentes technologies. Pour terminer, il
existe des zones où il n’existe ni marquage au sol ni panneaux de signalisation entraînant
une difficulté pour la voiture à suivre sa trajectoire.

4.2 Planification

Le robot utilise un programme spécifique pour planifier son comportement. Il se sert des
informations fournies par la fonction de détection pour donner les instructions concernant
ce comportement. Dans le cas de la voiture intelligente, le système applique un algorithme
qui analyse le modèle créé par la fonction de perception et détermine un ensemble
d’actions en vue d’atteindre son objectif [6]. Le système de la voiture intelligente est
complexe, la phase de planification est primordiale. Cette fonction fournira une série de
comportements semblables au comportement d’un humain (ex : changer de bande) ainsi
que les actions à mettre en place pour effectuer ceux-ci (ex : tourner le volant de x degrés)
[5].

La technologie de cette fonction de planification est complexe. Il s’agit d’un système

d’exploitation qui gère et met en relation l’ensemble des logiciels et algorithmes liés à cette
fonction. Ces logiciels sont chargés de compiler les informations fournies par l’ensemble
des outils de perception et de les transformer en plan d’actions. Le système d’exploitation
se perçoit comme le cerveau de la voiture.

4.3 Action

Le robot agira pour mener à bien le plan. Dans le cas de la voiture intelligente, il s’agit du
logiciel qui actionne les freins, l’accélérateur, le volant et autres fonctions [5].

4.4 Communication

Le plus gros enjeu du modèle perception-planification-action est d’arriver à comprendre

l’environnement et d’adapter le comportement de la voiture en fonction de celui-ci. Le
comportement de la voiture intelligente s’adapte aux conditions météorologiques (neige,
verglas, etc.) et aux types de revêtement (chemin de terre, pavés, etc.), par exemple. Pour
ce faire, elle doit développer sa propre intelligence [3]. Pour y remédier, elle sera
également équipée de systèmes de communication V2V et V2I [7].

Ces deux systèmes de communication utilisent la DSRC, Dedicated Short-Range

Communications. La DSRC est une plateforme de communication sans fil allouée aux
communications V2V et V2I uniquement qui autorise la transmission d’une grande quantité
d’informations via les fréquences radio.

10
4.4.1 Vehicle to Vehicle (V2V) : La V2V est un échange d’informations entre les véhicules
utilisant les réseaux sans fil. Cette communication concerne la position, la direction, les
ralentissements et la vitesse des voitures. Cela permet aux véhicules de contrôler le
comportement des véhicules environnants et d’agir en fonction. L’objectif du
développement de cette communication est la coordination des comportements des
véhicules ainsi que leur interopérabilité. Les voitures communiquent sur leur position et
leurs intentions afin que les autres véhicules anticipent leurs actions. Les véhicules
coordonneront leur comportement aux carrefours par exemple pour éviter de s’arrêter et
de créer des files. Pour être efficace, la V2V requiert un taux de pénétration élevé de
véhicules équipés de cette technologie.

4.4.2 Vehicle to Infrastructure (V2I) : La communication entre les véhicules et

l’infrastructure consiste en l’échange d’informations dont le but premier est d’améliorer la
sécurité. Cependant, elle fournit également des avantages en termes de mobilité et
d’environnement. La V2I est une solution à certaines limites de la fonction de perception.
L’infrastructure sera équipée de capteurs et d’émetteurs et communiquera sur les
conditions de routes, qui nécessiteront une adaptation de la conduite telles que le verglas
ou sur le type de revêtement, pour permettre au système de calibrer correctement ses
technologies. Elle communique également les conditions de congestion pour que le système
en tienne compte dans la planification de son itinéraire [3].

Le régulateur de vitesse adaptatif et coopératif (Cooperative Adaptive Cruise Control -CACC)

[8, 9] est un exemple de combinaison du modèle perception-planification-action et de la
communication V2V. Il s’agit d’une association entre le régulateur de vitesse adaptatif ACC
et le système de communication V2V. Le CACC fournit des informations sur le véhicule qui
nous précède mais également sur ceux devant ce dernier. Cela implique que lorsque qu’une
voiture en tête de file freine, l’information est transmise via la V2V au système de notre
véhicule, ce qui lui permet d’anticiper le comportement futur du véhicule qui le précède. La
différence avec l’ACC réside dans l’anticipation, le véhicule prévoit le comportement de la
voiture qui le précède car il sait que l’automobile devant celle-ci a ralenti.

5. Régulateur de vitesse intelligent

Durant ces deux dernières décennies, plusieurs études ont été menées sur les véhicules
intelligents afin de résoudre des problèmes tels que la réduction de la charge du
conducteur, la prévention des accidents, la diminution des congestions sur les routes, la
consommation de carburant, etc. Cependant les recherches sur la sécurité ont eu plus
d’ampleur en mettant l’accent sur les limites de la perception de l’environnement par les
conducteurs et leurs réactions quant à l’apparition d’évènements soudains. Le contrôle de
la distance inter-véhiculaire lors d’un déplacement sur autoroute afin d’éviter une collision
en est un cas précis. Les systèmes de régulateurs de vitesse communément appelés Cruise
Control (CC), ont été développés afin de soulager le conducteur lors de longs déplacements.
Le Cruise Control régule uniquement la vitesse et devient obsolète dans une situation où
d’autres véhicules sont présents devant le véhicule hôte ou dans une situation de
congestion. Le régulateur de vitesse adaptatif ACC (Adaptive Cruise Control) quant à lui a
été développé pour palier à ces situations. Il s’agit alors d’un système qui contrôle aussi
bien la vitesse relative et la distance relative entre véhicules.

Grace à l’émergence des communications inter-véhiculaire, les véhicules peuvent échanger

plusieurs informations sur leurs états telles que leur position, leur vitesse, leur
accélération, leurs futurs actions…. Ces informations peuvent être utilisées pour améliorer

11
l’ACC. On parle alors de CACC pour Coopérative ACC. En échangeant l’information de
position, il est possible d’obtenir la distance inter véhiculaire ce qui rend plus fiable
l’information de distance même en cas de défaillance du capteur de perception. Dans cette
section, on présentera brièvement les trois systèmes : le CC, l’ACC et le CACC.

5.1 Régulateur de vitesse conventionnel (CC)

Inventé en 1945 par l'inventeur et ingénieur mécanicien américain Ralph Teetor, le premier
régulateur de vitesse a été installé dans la Chrysler Imperial en 1958. Au XXIe siècle. Le
régulateur de vitesse (ou Cruise Control ou Autocruise ou Auto croisière) est un système
destiné à stabiliser automatiquement la vitesse des véhicules automobiles. Le conducteur
fixe la vitesse à laquelle il veut rouler puis l'automatisme prend le relais et maintient la
vitesse définie. Ce régulateur de vitesse maintient une vitesse fixe sans aucun contrôle du
conducteur sur l'accélérateur. Freiner ou débrayer désactive le régulateur de vitesse, il faut
ensuite le réactiver. Cependant, activer le régulateur à une vitesse préprogrammée plus
élevée que la vitesse actuelle provoque l'accélération du véhicule seul, sans appuis sur
l'accélérateur de la part du conducteur, jusqu'à la vitesse préprogrammée, que le
régulateur maintient ensuite.

Un régulateur de vitesse est différent d'un limiteur de vitesse. Le limiteur de vitesse est un
bridage électronique de la vitesse maximale du véhicule, qui permet de conduire
normalement, ralentir, s'arrêter, repartir, sans dépasser la vitesse limite programmée, et en
conservant la fonction active. Ainsi on peut l'utiliser partout même en ville en
programmant la vitesse au maximum autorisé. En laissant le pied sur l'accélérateur, le
conducteur maintient aussi le véhicule à la vitesse limite programmée, et obtient par ce
truchement le même résultat qu'avec le régulateur de vitesse. Le système est constitué
principalement de :

• Un capteur de la vitesse du véhicule, placé au niveau de la sortie de la boîte de vitesses

(couplé éventuellement au détecteur de blocage ABS) ;
• Un ECM (Engine Control Module, ou en français « unité de contrôle du moteur »).

L'ECM reçoit la mesure effectuée par le capteur de vitesse, ce dernier effectue seul les
corrections du régime du moteur en fonction de la consigne fixée par l'utilisateur et la
vitesse mesurée. Il contrôle le régime du moteur en se substituant au pied droit du
conducteur pour actionner l'accélérateur. Les véhicules les plus récents n'ayant plus de
câble d'accélérateur, c'est le micromoteur de commande des gaz qui est directement
commandé par le calculateur général du véhicule, lequel assure désormais de nombreuses
autres fonctions en gérant toute l'électronique.

Le conducteur dispose d'une ou plusieurs commandes, de préférence au volant sur une

seule manette, lui permettant d'activer le régulateur, de choisir sa vitesse de croisière, et de
revenir au mode classique.

Différentes fonctions peuvent être ajoutées, comme le retour en mode régulation après un
passage en mode classique, le choix du mode limiteur plutôt que régulateur, par exemple.
Une alarme de dépassement de la vitesse programmée peut éventuellement être activée.

5.2 Régulateur de vitesse Adaptatif (ACC)

Il s’agit d’une extension du système présenté dans le paragraphe précédent. Mais

contrairement au Cruise Control, la présence ou non d’un autre véhicule aura une influence
12
sur la vitesse du véhicule test (Figure 1.8). On appellera véhicule test ou véhicule hôte le
véhicule équipé d’un système ACC. Le véhicule qui le précède (celui en avant du véhicule
test) est la cible ou encore obstacle.

Figure 1.8 - Adaptive Cruise control

Ce système apporte confort et commodité aux passagers du véhicule en plus de diminuer

les risques de collision. L’ACC contrôle la position et la vitesse du véhicule hôte, l’objectif
étant de minimiser voire annuler l’erreur sur la vitesse et la position. Le signal de référence
correspond à la vitesse et/ou position du véhicule précédent et dans le cas échéant à celui
prédéfinit par le conducteur.

5.3 Régulateur de vitesse Adaptatif et Coopératif (CACC)

Grace à l’émergence des communications inter-véhiculaire, les véhicules peuvent échanger

plusieurs informations sur leurs états telles que leur position, leur vitesse, leur
accélération, leurs futures actions, etc. Ces informations peuvent être utilisées pour
améliorer l’ACC. On parle alors de CACC pour Coopérative ACC.

Le système CACC (Cooperative Adaptive Cruise Control) est conçu comme un système
embarqué à utiliser dans les véhicules. Les principaux objectifs du système sont : offrir des
mesures de commodité et de sécurité aux conducteurs de véhicules et à leurs passagers en
utilisant une autorité accrue en matière d'automatisation et de contrôle.

Le système CACC tentera de maintenir une vitesse du véhicule constante telle que spécifiée
par le conducteur. Le système peut utiliser une combinaison de capteurs radar et caméra
pour détecter un autre véhicule (véhicule cible) dans sa trajectoire vers l'avant et peut
ajuster sa propre vitesse via les commandes d'accélération et de freinage afin de maintenir
une certaine distance, également spécifiée par le conducteur. Le véhicule reçoit des
informations GPS (emplacement, vitesse et direction) des véhicules qui le succèdent et
diffuse ses propres informations GPS aux véhicules qui les précédent à l'aide du
communicateur radio dédié de communication à courte distance (DSRC). Cette information
supplémentaire peut être utilisée pour mettre en place un convoi de véhicules qui suivent
un véhicule en tête du convoi à la même vitesse et maintenir l'espacement entre chaque
véhicule. Le système est également responsable de l'arbitrage des situations dans
lesquelles les actions de divers composants fonctionneraient les unes contre les autres (par
exemple lorsqu'un composant a l'intention d'accélérer le véhicule, tandis qu'une autre
recommande une décélération) [8, 9].

13
Chapitre 2 : Méthodes formelles
Dans l’informatique, les méthodes formelles sont une sorte particulière de techniques
mathématiques pour spécifier, développer et raisonner sur les systèmes. Les méthodes
formelles peuvent être utilisées dans toutes les étapes du développement. Elles peuvent
être utilisées de la définition des besoins du client, à travers la conception du système,
l’implantation, le débogage, l’entretien, la vérification et jusqu’à l’évaluation. Les méthodes
formelles permettent de révéler des ambiguïtés, des problèmes de non complétude et
d’inconsistance. Quand elles sont utilisées tôt dans le processus de développement, elles
peuvent découvrir des failles de conception qui autrement seront, peut-être, découvertes
seulement avec de couteuses étapes de preuve et de débogage.

Les méthodes formelles ont été proposé pour la première fois issues des travaux
Programming Research Group d’université d’Oxford qui consistaient à utiliser les concepts
mathématiques pour la spécification des systèmes informatiques afin d’ajouter un
formalisme rigoureux et valider les logiciels produits.

L’objectif de ce chapitre, est d’introduire les méthodes formelles d’une manière générale.
Dans la section 2 nous commençons par la définition d’une méthode formelle, ensuite nous
présentons l’utilisation de ces méthodes. La section 3, exprime les différentes classifications
proposées pour les méthodes formelles. Enfin, dans la section 4, nous discutons les
principaux travaux portant sur l’application de ces techniques aux systèmes embarqués
pour l’automobile.

1. Pourquoi utiliser les méthodes formelles ?

Les méthodes formelles sont une sorte de techniques permettant de raisonner
rigoureusement sur des programmes informatiques afin de démontrer leurs conformités
(corrections) en se basant sur des raisonnements de logique mathématique. En pratique,
une méthode formelle est basée sur une notation formelle permettant d’atteindre des
exigences de qualité élevées du système à modéliser.

Définition : Une méthode formelle permet à offrir un cadre mathématique permettant de

décrire d’une manière précise et stricte les programmes que nous voulons construire. Ce cadre
formel vise d’éliminer les ambiguïtés existant au niveau du cahier des charges et du langage
naturel [10].

Dans l’ingénierie de logiciel, les méthodes formelles peuvent être appliquées aux différentes
étapes du développement, dans la définition des besoins du client, passant par la conception
du système, l’implantation, le débogage, l’entretien, la vérification et jusqu’à à l’évaluation.
Comme elles peuvent être aussi utilisées dans l’ingénierie inverse pour modéliser et
analyser les systèmes existants.

Un éventail de langages et de techniques formels existe pour traiter différents types de

propriétés à différents niveaux de développement des systèmes. En ajoutant que l’utilisation
de ces méthodes ne garantit pas l’absence des erreurs, mais elle peut augmenter le degré de
correction de ces systèmes. Si on utilise ces méthodes dans le cahier des charges, et les
phases de conception on n’a pas seulement la détection des défauts, mais on peut aussi
réduire le coût de réparation et de maintenance de ces systèmes. Les principaux avantages
des méthodes formelles peuvent être résumés dans les points suivants [11]:

14
• Le non ambiguïté : l’utilisation d’une méthode formelle basée sur des notations
mathématiques et précises permet d’éviter les ambiguïtés et les redondances dans la
phase de spécification.
• La détection d’erreurs : l’application de vérification, de validation et de preuve
formelles au processus de développement garantie la détection des bugs de conception
le plus tôt possible dans ce processus.
• La réutilisation : le raffinement des spécifications formelles et leurs décompositions
successives permettent de mettre des niveaux d’abstraction intéressants pour la
résolution du problème et pour promouvoir la réutilisation des spécifications.

2. Classification des Méthodes Formelles

Il existe différentes classifications basées sur des critères spécifiques. Dans ce qui suit, nous
présentons trois classifications qui nous semblent importantes :

2.1 Classification de J. Wing

J. Wing [12] considère qu’il y a deux grandes catégories de méthodes formelles (Figure 2.1).
La première catégorie concerne les méthodes orientées propriétés. La deuxième catégorie
représente les méthodes orientées modèle qui sont basées sur l’utilisation d’un modèle
formel du système.

Figure 2.1 - Classification de J. Wing

2.1.1 Méthodes Orientées propriétés

Les Méthodes Orientées propriétés définissent le comportement du système de manière

indirecte en établissant un ensemble de propriétés. Généralement, sous forme d’axiomes
que le système doit satisfaire. On distingue dans cette classe, deux sous-catégories :

• Méthodes Axiomatiques: Le traitement axiomatique du logiciel pourrait bien être

le type le plus ancien de méthodes formelles. Un exemple de ces méthodes la
Logique de Floyde-Hoare [13] qui est généralement appelée la logique de Hoare. Elle
est basée sur le traitement axiomatique (utilisation de la sémantique axiomatique).
Le but de cette logique est de formaliser la preuve de la correction des programmes.
Elle utilise le triplet de Hoare qui se présente de la manière suivante Q P R. Où P est
programme et le Q c’est la pré-condition et le R est la post-condition. Si Q est vrai au
début de P, alors R sera vrai à la fin du programme P.
• Méthodes Algébriques: Les Méthodes Algébriques sont apparues en 1970. Ces
méthodes se basent sur la spécification algébrique qu’elle utilise les axiomes pour
15
 spécifier les propriétés des systèmes, mais les axiomes sont restreints à des
équations. Parmi les méthodes les plus connues, on peut notamment citer:
Larch[14], OBJ [15] et Lotos[16] sont des exemples de langages de spécification
algébriques.

2.1.2 Méthodes Orientées Modèles

Les méthodes orientées modèle définissent le comportement d’un système en construisant

un modèle du système en termes de structures mathématiques telles que les tuples, les
relations, les fonctions, les ensembles, et les suites. Dans le domaine des programmes
séquentiels et des types abstraits de données, on trouve les méthodes VDM[Harry, 1997],
Z[18]et B [19]. Pour le domaine des systèmes concurrents et distribués, on cite les Réseaux
de Petri [20], CCS de Milner[21], Raise [22] (qui combine VDM et CSP).

• Méthode B: La méthode B est une méthode formelle introduite au milieu des

années 80 par Jean Raymond Abrial afin de développer des logiciels sûrs. Elle est
définit par Abrial comme suit «B est une méthode pour spécifier, développer et coder
les logiciels». Les utilisations de cette méthode ne se limitent pas à la phase de
description mais elle permet d’établir une chaîne de production qui va de la
spécification du programme au code source associé. Cette méthode a rapidement
donné une naissance à deux outils : l’Atelier B [23]et le B-Toolkit [24].
• Méthode VDM : VDM (Vienna Development Method) est une des méthodes formelles
la plus largement connues et utilisées pour le développement des logiciels et des
systèmes complexes et critiques. elle est plus ancienne par rapport à la méthode B
et à la méthode Z et a été développée dans un environnement industriel. Mural [25]
est l’outil de mise en œuvre de cette méthode.
• Méthode Z: La méthode Z a été développée par un groupe de recherche de
l’université d’Oxford avec la participation de Jean-Raymond Abrial après la méthode
VDM dans les années 70 .Cette méthode est basée sur la théorie des ensembles et le
calcul des prédicats. CZT [26] est l’un des outils les plus connus de cette méthode.
• Réseaux de Petri: Les réseaux de Petri (RdPs) sont des techniques graphiques et
mathématiques pour modéliser le comportement dynamique des systèmes
concurrents à événements discrets comme les systèmes manufacturiers, les
systèmes de télécommunications, les réseaux de transport,...etc. Leur représentation
graphique exprime d’une manière naturelle le parallélisme, la synchronisation, le
partage de ressources, et les choix (conflits). Leur représentation mathématique
permet d’utiliser les équations d’états, à partir des quelles il est possible de préciser
les propriétés du modèle et de les comparer avec le comportement du système
modélisé. TINA[27] est un exemple d’outils de cette méthode.
• CCS de Milner: Le langage CCS (Calculus of Communicating Systems) est un langage
de traitement concurrent avec une structure algébrique. Ce langage a été introduit
par Robin Milner en 1980. Sa syntaxe utilise les processus pour décrire les termes.
Ces processus peuvent avoir des capacités d’interaction qui correspondent à des
demandes de communication sur des canaux nommés.

2.2 Classification de Meyer

La classification de Meyer [28] depuis 2001, regroupe les méthodes formelles en quatre
catégories : les méthodes algébriques, logiques, dynamiques et ensemblistes (Figure 2.2).

16
 Figure 2.2 - Classification de Meyer

2.2.1 Méthodes logiques

Généralement, les méthodes logiques se basent sur la théorie des types et des logiques
d’ordre supérieur afin d’ajouter une démonstration de programme en appliquant les
théories de démonstration automatiques ou semi-automatique de théorèmes. Ces
méthodes supportent plusieurs outils pour la mise en œuvre tel que l’assistant de preuve
Coq [29].

2.2.2 Méthodes dynamiques

Les méthodes dynamiques sont utilisées dans le domaine des protocoles qui se base sur les
interactions entre les processus. Ces méthodes peuvent être utiles pour le traitement des
systèmes de transitions comme les automates, les réseaux de Petri, les algèbres de
processus (CSP) et la logique temporelle.

2.2.3 Méthodes ensemblistes

Les méthodes ensemblistes utilisent les types abstraits prédéfinis afin de préciser l’état du
système. Chaque opération est décrite par son effet sur l’état du système. La syntaxe des
méthodes ensemblistes correspond aux types et aux opérations de ce modèle abstrait, leur
sémantique repose sur la théorie correspondante à ce modèle abstrait (théorie des
ensembles, théorie des types, logique du premier ordre). VDM, Z et B sont des exemples de
langages de spécifications ensemblistes.

2.2.4 Méthodes hybrides

Toutes les méthodes présentées précédemment sont souvent combinées afin de former des
méthodes hybrides pour profiter au mieux de leurs avantages respectifs. La méthode Raise
est un exemple de ce type de méthode.

2.3 Autre classification

J. Wing [12] propose aussi une autre classification qui se base sur l’utilisation des
méthodes formelles (Figure2.3). Deux catégories de méthodes formelles sont proposées où
la première catégorie se base sur la spécification des systèmes comme les méthodes Z, B et
VDM et la deuxième catégorie s’intéresse à la vérification du produit final tels que le model
cheking [30] et la preuve de théorème.

17
 Figure 2.3 - Autre classification de J.Wing

2.3.1 Méthodes de Spécification Formelle

Dans cette catégorie, l’accent est mis sur la spécification des systèmes. Certaines méthodes
formelles comme Z, VDM, et larch sont basées sur la spécification du comportement de
systèmes séquentiels. D’autres méthodes telles que CSP, CCS et la logique temporelle sont
basées sur la spécification du comportement des systèmes concurrents.

2.3.2 Méthodes de Vérification Formelle

Ces méthodes s’intéressent à la vérification formelle afin de garantir la sûreté de

fonctionnement des systèmes complexes et critiques. Pour ce faire, il faut exprimer
clairement le comportement souhaité du système. Les méthodes formelles englobent deux
types de méthodes pour la vérification formelle : le modèle checking et la preuve de
théorème.

• Vérification de modèles (Model Checking): Le model checking est une technique

de vérification automatique des systèmes dynamiques. Elle permet de vérifier si un
modèle du système satisfait une propriété souhaitée d’une façon automatique. Si
cette propriété n’est pas satisfaite, un contre-exemple est fourni pour aider à
expliquer la source de l’erreur. L’avantage principal de cette méthode est que la
vérification de propriétés est complètement automatisée. Parmi ses différents outils,
on cite: SPIN [31], et UPPAAL [32].
o SPIN: Simple Promela INterpreter est un outil conçu pour la vérification
générique des systèmes distribués. Cet outil utilise comme un langage de
spécification le langage Promela (Protocol Meta Language). Ce dernier conçu
pour spécifier les systèmes parallèles et asynchrones.
o UPPAAL: UPPAAL est un outil de vérification automatique des systèmes
temps réel.
• Preuve de théorèmes (Theorem proving): La preuve de théorèmes est une technique
ou le système et les propriétés recherchées sont exprimés comme des formules dans
une logique mathématique. Cette logique est décrite par un système formel qui
définit un ensemble d’axiomes et de règles de déduction. La preuve de théorème est
le processus de recherche de la preuve d’une propriété a partir des axiomes du
système. Les étapes pendant la preuve font appel aux axiomes et aux règles, ainsi
qu’aux définitions et lemmes qui ont été possiblement dérives. Il existe de nombreux
outils de preuve semi-automatique tels que Coq, Isabelle et PVS.
o Assistant de preuve Coq: Coq est un système de manipulation de preuves
mathématiques formelles. Avec cet assistant, il est possible d’énoncer des
théorèmes, des spécifications de programme, et de développer
interactivement leurs preuves à l’aide de tactiques. Le programme est écrit
18
 par le langage fonctionnel Gallina qui se base sur le calcul des constructions
inductives, étendu avec un système de développement modulaire des
théories.
o Assistant de preuve Isabelle: Isabelle [33] est un système de preuves
développé par Paulson et Nipkov .La majorité des assistants de preuve sont
basés sur un unique calcul formel, en général la logique d’ordre supérieur.
Isabelle a la capacité d’accepter une variété de calculs formels.
o Assistant de preuve PVS: PVS (Prototype Verification System) [34] est un
outil de vérification intégrant le langage de spécification PVS qui se base sur
la logique classique d’ordre supérieur. Cet assistant de preuves est écrit dans
le langage de programmation Lisp.

3. Comparaison des classifications

Dans cette section, nous présentons une comparaison entre les différents types de
classification des méthodes formelles présentées dans les sections précédentes. On Illustre
à chaque fois une classification en fonction de critères différents. La première classification
se fait selon la structure de raisonnement basée sur le type du système à résoudre (système
séquentiel ou concurrent). La deuxième classification a été établit à base de la sémantique
des langages des méthodes, et la troisième classification a été proposée en prenant en
compte la nature de la tâche à résoudre.

Au contraire du theorem proving, le model-checking est complètement automatique et

rapide. Il produit aussi des contre-exemples qui représentent des erreurs subtiles dans la
conception et ainsi il peut être utilise pour aider le débogage. En contrepartie, le theorem
proving peut s’utiliser avec des espaces d’états infinis, à l’aide de techniques comme
l’induction structurelle. Son principal inconvénient est que le processus de verification est
normalement lent, sujet à l’erreur, demande beaucoup de travail et des utilisateurs très
spécialisés avec beaucoup d’expertise.

4. Travaux similaires
Cette section est consacrée à l’étude et l’évaluation des travaux de recherche les plus
pertinents portant sur l’application des méthodes formelles aux systèmes embarqués pour
l’automobile et en particulier le système de régulateur de vitesse.

4.1 Travail de Jagannath Aghav and Ashwin Tumma

L'objectif de ce travail [35] est de mettre au point un système d'alerte aux collisions
sécurisé qui s'attaquera aux collisions en arrière et assurera également le contrôle du
véhicule lorsque la menace est à un niveau très élevé. L’adaptation en fonction des
conditions environnementales est également une caractéristique importante du système.
Le système de sécurité fournit des avertissements aux conducteurs pour aider à éviter les
accidents en arrière avec d'autres véhicules. Initialement, le système fournit une alarme de
bas niveau et, à mesure que la gravité de la menace augmente, le niveau des alertes
augmente également. Au niveau de menace le plus élevé, le système entre dans un mode
régulateur de vitesse, dans lequel le système contrôle la vitesse du véhicule en contrôlant
l'accélérateur du moteur et, si cela est permis, le système de freinage du véhicule. Pour
prouver la faisabilité, la robustesse et la fiabilité du système, les auteurs ont prouvé
certaines des propriétés du système en utilisant la logique temporelle avec une
implémentation de référence écrite en langage ESTEREL.
19
4.2 Travail de Petter Nilsson et al.

Ce travail [36] applique des méthodes formelles au régulateur de vitesse adaptatif (ACC). À
partir d'une spécification de logique linéaire temporelle pour l'ACC, obtenue en
interprétant les normes d'ACC pertinentes, les auteurs discutent deux méthodes différentes
de synthèse de logiciel de contrôle. Chaque méthode produit un contrôleur correct-par-
construction. Les deux méthodes reposent sur des calculs à virgule fixe de certains
mappages à valeur fixe. Cependant, l'une des méthodes effectue ces calculs sur l'espace
d'état continu alors que l'autre méthode opère sur une abstraction d'états finis. Alors que la
synthèse des contrôleurs est basée sur un modèle à faible dimension, chaque contrôleur est
testé sur CarSim, un simulateur de véhicule standard industriel. Les résultats démontrent
plusieurs avantages par rapport aux techniques de conception de contrôle classiques.

4.3 Travail de T.A.W. (Erwin) Bronkhorst

Fait l’objet de travail d’un Master [37], l’auteur a proposé une approche relativement
nouvelle de conception matérielle pour modéliser un système CACC (Cooperative Adaptive
Cruise Control). La nouvelle approche de conception utilisée dans cette investigation utilise
une description mathématique donnée dans le langage de programmation fonctionnel
Haskell pour vérifier l'exactitude du modèle. Après cela, le code Haskell est légèrement
modifié pour être compilé en code VHDL en utilisant le compilateur CλaSH (langage CAES
pour matériel synchrone). Il s'agit d'un compilateur développé dans le groupe CAES
(Computer Architecture for Embedded Systems), qui traduit le code écrit dans un sous-
ensemble de Haskell en code VHDL entièrement synthétisable. Cela permet d'implémenter
le système sur un FPGA (Field-Programmable Gate Array). Le code de Haskell découle
directement de la description mathématique, ce qui facilite l'implémentation du problème
dans un langage fonctionnel. Juste quelques petites étapes ont été nécessaires pour rendre
ce code Haskell conforme à CλaSH.

4.4 Travail du Sarah M et al.

Dans cet article [38], les auteurs ont considéré un système de contrôle de voiture distribué
qui s'inspire des ambitions du projet California PATH, du système CICAS, et des initiatives
du SAFESPOT et du PReVENT. Les auteurs ont développé un modèle formel de système de
contrôle de voiture distribué dans lequel chaque voiture est contrôlée par un régulateur de
vitesse adaptatif. L'une des difficultés techniques majeures est que les modèles fidèles de
contrôle des véhicules distribués ont à la fois des systèmes distribués et une dynamique
des systèmes hybrides. Ils forment des systèmes hybrides distribués, ce qui les rend très
difficiles à vérifier. Dans un système de preuve formel, ce travail vérifie que le modèle de
contrôle satisfait à son objectif de sécurité principal et garantit la liberté de collision pour
beaucoup de voitures circulant dans une rue, même si de nouvelles voitures pénètrent dans
les voies ou sur plusieurs voies.

4.5 Travail du Rob Hieronsa et al.

Cet article [39] décrit une approche de test à partir d'une spécification séquentielle
déterministe écrite en μSZ. En prenant en compte les spécifications Z des opérations, la
machine à états finis étendue (EFSM) définie par l'outil Statechart peut être réécrite pour
produire un système EFSM possédant un certain nombre de propriétés qui simplifient la
génération de tests. Les algorithmes de génération de test sont présentés et appliqués au
régulateur de vitesse adaptatif (ACC).

20
4.6 Travail du Olf Stursberga et al.

Ce travail [40] montre, pour l'exemple d'un système de régulation de vitesse, que
l'approche proposée de la vérification guidée par le contre-exemple peut réduire
considérablement les coûts de calcul. La méthode génère une séquence d'abstractions, pour
lesquelles les contre-exemples sont identifiés. L'article présente une séquence de méthodes
de validation sur mesure visant à vérifier l'existence des contre-exemples pour le modèle
hybride du système de régulation de vitesse.

4.7 Travail du Anthony Spiteri Staines

Dans ce travail [41], l’auteur a développé une approche basée sur les réseaux de Petri pour
modéliser un système de régulateur de vitesse conventionnel. Les réseaux de Petri ont été
utilisés afin d’effectuer l’analyse d’accessibilité et de vérifier un ensemble de propriétés
telles que l’invariance, l’inter blocage (deadlock), la limite (boundness), et le comportement
cyclique (cyclic behavior).

4.8 Travail du John Hudak et Peter Feiler

Ce travail [42] utilise le langage d'analyse et de conception d'architecture (AADL), une

norme industrielle internationale pour l'ingénierie basée sur des modèles de systèmes
embarqués temps réel. L'objectif principal de ce document est de décrire une approche et
la mécanique de la construction d'un modèle architectural qui peut être analysé sur la base
de l'AADL. Les modèles sont construits avec différentes perspectives d'analyse pour
illustrer la sémantique ainsi que la richesse de l'AADL. Une étude de cas sur le système de
régulateur de vitesse conventionnel a été reportée. Un exemple d’une propriété à vérifier
est de déterminer si la latence de bout en bout spécifiée du signal de l'actionneur du frein à
l'accélérateur peut être satisfaite.

4.9 Travail du DeJiu Chen

Dans ce travail [43], les auteurs présentent un nouveau langage dit EAST-ADL qui est un
langage de description d'architecture (ADL) en termes de sécurité et de logiciel spécifique
au domaine des systèmes embarqués critiques. Le langage permet une description formelle
et traçable tout au long du cycle de vie du développement du système. Cela permet
d'exploiter pleinement les méthodes et les outils de pointe pour le développement de
fonctions et de composants de système corrects par construction de manière transparente
et rentable. Un algorithme et son implémentation pour transformer les modèles de
comportement EAST-ADL en SPIN pour la vérification du modèle logique a été également
introduit. Parmi les propriétés vérifiées, on trouve notamment : L’absence d’inter-blocage,
Il peut y avoir au plus 1 leader à tout moment. Lorsqu'un leader est élu et maintenu, les
deux véhicules auront finalement la même vitesse, La vitesse du véhicule est toujours dans
l’intervalle [0, 5].

4.10 Travail du John Eriksson

Dans ce travail [44], l’auteur a proposé une approche de décomposition fonctionnelle des
fonctions complexes multi-arguments pour la vérification formelle de la correction des
programmes C pour les systèmes embarqués pour l’automobile. La vérification formelle est
une preuve de théorèmes basée sur la logique de Hoare. Deux outils de vérification ont été
mentionnés à savoir le VCC et Frama-C.

21
Le tableau ci-dessous résume les travaux mentionnés précédemment.

Travail Type de Langage formel utilisé objectif

régulateur
[35] “Design and CCC Entrée : Vérification formelle
validation of safety ESTEREL pour tester la conformité
cruise control system Sortie : de la conception avec les
for automobiles” Automates finis réduits spécifications.
en utilisant le concept Les propriétés à vérifier
de bi-simulation sont exprimées en LTL
[36] : “Correct-By- ACC Entrée : modèle hybride Synthèse de contrôleur
Construction Adaptive (automate hybride à ACC par l’approche
Cruise Control: Two variable discrète et correcte par construction
Approaches” continue) formalisé en en s’appuyant sur deux
LTL méthodes : l’une est
basée sur l’espace
continu et l’autre sur
l’espace discret.
[37]: “Hardware CACC Haskell Vérification de correction
design of a du modèle et la synthèse
cooperative adaptive VHDL du matériel.
cruise control system
using a functional
programming
language”
[38] : “Adaptive ACC Quantified Differential Preuve de théorèmes que
Cruise Control: Dynamic Logic la spécification souhaitée
Hybrid, Distributed, découle des hypothèses
and Now Formally pour de nombreuses
Verified” voitures volant
arbitrairement.
[39]: “Testing a ACC Langage de Preuve de théorèmes
System specified spécification hybride
using Statecharts and μSZ
Z”
[40] “Verification of a CCC Automates hybrides Vérification dirigée par
cruise control system les contres exemples
using (model checking)
counterexample-
guided search”
[41] “Modeling and CCC Réseaux de Petri Analyse d’accessibilité,
analysis of real time l’invariance, l’inter-
control systems: a blocage, la limite, le
cruise control case comportement cyclique
study”

[42]: “Developing CCS AADL Simulation

AADL Models for
Control Systems: A
Practitioner’s Guide”

22
 [43] : “An CACC EAST-ADL Vérification des modèles
architectural domain specific avec SPIN.
approach to the Architecture
analysis, verification Description Language
and validation of (ADL) for safety-critical
software intensive and software-intensive
embedded systems” embedded systems
[44] : “Formal Systèmes Logique de Hoare Vérification de correction
Requirement Models embarqués des programmes C
for Automotive pour
Embedded Systems” l’automobile

23
Chapitre 3 : Méthode Event-B
La méthode B, inventée par Abrial [19], est une théorie et une méthodologie pour le
développement formel des systèmes informatiques. B est utilisée dans l’industrie, surtout
pour les applications critiques et sécuritaires. B est fondée sur les notions de machines
abstraites et de raffinement.

Event- B (B événementiel) [45] est une extension de la méthode B pour spécifier les
systèmes réactifs à base d’événements. L’Event B a introduit deux nouveaux concepts qui
sont l’événement et le contexte. Ces concepts sont bien implémentés dans un
environnement basé sur Eclipse qui s’appelle RODIN [46]. La plate-forme Rodin permet de
spécifier, d’animer et de prouver des modèles B événementiel. De plus, RODIN est
extensible grâce au mécanisme de plugins, il intègre, entre autres, le plugin « iUML-B » qui
permet de générer un code Event B de façon automatique à partir de deux vues : statique
(diagrammes de classes) et dynamique (diagramme états transition).

Ce chapitre se scinde en deux parties : Dans la première partie, nous développons

d’avantage le cadre général de cette méthode. D’abord, nous présentons le langage Event B.
Ensuite, nous présentons la plateforme RODIN. Parmi les plugins qui supportent la
plateforme RODIN, nous présentons en plus de détail le plugin iUML-B. Dans la deuxième
partie, Nous présentons la contribution de la méthode B au domaine des applications
critiques pour l’automobile et en particulier le système de contrôle de régulateur de
vitesse.

1. Langage B événementiel
Un développement B événementiel est une spécification incrémentale de plusieurs
machines. Il débute par une spécification mathématique abstraite du système et s’achève
par le code informatique correspondant. Ainsi, la machine est un composant indispensable
pour la construction formelle d’un système en B événementiel ; elle spécifie sa partie
dynamique. Elle inclut des éléments comme les variables, les invariants et les événements
qui établissent le changement d’état du système. Souvent, les machines font recours à des
éléments statiques du système tels que les constantes, les ensembles et les axiomes. Ces
éléments sont décrits par un deuxième composant du langage B événementiel appelé
"contexte". Les relations machine-contexte, machine-machine et contexte-contexte sont
définies comme suit : une machine peut voir un ou plusieurs contextes, une machine peut
raffiner une autre machine, et un contexte peut étendre un ou plusieurs autres contextes.
Quand une machine voit un contexte, cela veut dire qu’elle peut utiliser les constantes et les
propriétés de ce dernier mais sans pouvoir les changer. L’extension des contextes consiste
tout simplement à rajouter des nouveaux ensembles, constantes et propriétés. Bien que, le
raffinement soit différent de l’extension, cependant tous les deux sont considérés comme
des constructions similaires d’un point de vue méthodologique.

1.1 Contexte

Le contexte permet de décrire l’ensemble des données statiques du système. Il se compose

des éléments suivants : un nom, les noms des contextes à étendre, une liste d’ensembles
non vides, une liste de constantes, et une liste de propriétés sur les constantes. Les
ensembles, déclarés dans la clause SETS, permettent de typer tous les éléments du modèle.
Un ensemble peut être soit un type énuméré (c’est à dire un ensemble de constantes), soit
un ensemble fini dont les éléments sont inconnus. Les constantes, déclarées dans la clause
24
CONSTANTS, sont typées et définies dans la clause AXIOMS. Dans la clause THEOREMS, nous
examinons des propriétés déduites à partir de celles présentes dans la clause AXIOMS.

Figure 3. 1 - Structure du contexte

1.2 Machine

Une machine est constituée d’un nom, des variables v, des invariants I(v) et d’un ensemble
d’événements. Les variables définissent l’état du système à spécifier. Elles sont déclarées
dans la clause VARIABLES. Les invariants sont des prédicats qui demeurent valides tout au
long de l’exécution du système. Ils servent à typer les variables de la machine et à spécifier
les propriétés du système. Ils sont déclarés dans la clause INVARIANT. Le variant, déclaré
dans la clause VARIANT, est une mesure qui décroît après toute application d’un événement
convergent. Le variant est donc considéré comme un moyen pour prouver la terminaison
du calcul. Les événements permettent de spécifier le comportement dynamique du système
et d’initialiser ses variables. L’initialisation est accomplie par le moyen d’un événement
spécial appelé événement d’Initialisation. Un événement est défini par des gardes et des
actions. Les gardes déterminent les conditions nécessaires pour le déclenchement de
l’événement, et les actions permettent de spécifier le changement des valeurs des variables.
Les actions sont exprimées à l’aide d’un langage de substitutions généralisées. Un
événement ne peut se déclencher que lorsque sa garde est vraie. Cependant, deux
événements différents ne peuvent pas se déclencher en même temps (même si leurs gardes
sont vraies au même moment) ; ils doivent être exécutés alternativement selon un ordre
indéterminé. Les événements sont introduits dans la clause EVENTS.

Figure 3. 2 – Structure d’une machine

1.2.1 Événement

Formellement, nous distinguons trois types d’événement : indéterministe, gardé et simple.

Un événement indéterministe est composé de quatre éléments : un nom, des variables
locales l, des gardes et des actions. Les gardes, désignées par G(v, l), sont des prédicats qui
dépendent à la fois des variables de l’événement et celles de la machine. Les actions,
25
désignées par S(v, l), sont des substitutions généralisées. L’aspect indéterministe de
l’événement est basé sur le principe du déclenchement de ce dernier qui dépend fortement
de l’existence des valeurs de variables locales l satisfaisant G(v, l). La structure de cet
événement est représentée par la figure Fig.3.3 (voir l’événement à gauche). Un événement
gardé est un événement qui ne dispose pas des variables locales ; il est simplement
composé de gardes G(v) et de substitutions généralisées S(v). La structure de cet
événement est représentée par la figure Fig.3.3 (voir l’événement au milieu). Un événement
est dit simple s’il ne contient aucune garde. Autrement dit, la garde est toujours vraie et
l’événement peut toujours se déclencher. Il est important de signaler que l’initialisation est
un événement simple qui ne se déclenche qu’une seule fois. La structure de cet événement
est représentée par la figure Fig.3.3 (voir l’événement à droite).

Figure 3. 3– Différents types d’événements

1.2.2 Substitution généralisée

Nous distinguons trois formes possibles de substitutions généralisées : déterministe, non-

déterministe et vide. Ces différentes formes sont présentées dans le Tableau.3.1.

Une substitution déterministe est une substitution simple qui ressemble beaucoup à une
affectation directe dans un langage de programmation impératif. Elle permet de changer
les valeurs d’un ou de plusieurs variables d’état ; le plus souvent en fonction de leurs états
postérieures. Nous désignons par x l’ensemble des variables qui vont changer de valeurs et
qui appartiennent à v (l’utilisation de la notion d’ensemble est mise en vigueur pour
simplifier la présentation). Les nouvelles valeurs que peuvent prendre x sont désignées par
E(v). En effet, E(v) se réfère à un ensemble d’expressions ayant le même nombre de
variables dans x. De même, chaque expression appartenant à E(v) doit avoir le même type
du variable qui lui correspond dans x.

La substitution non-déterministe est la forme la plus générale des substitutions. Elle

exprime un changement de valeurs d’un ou de plusieurs variables d’état. Ce changement
est réalisable si, et seulement si, des conditions, portant à la fois sur les variables locales de
l’événement et celles de la machine, soient toutes vraies. Les conditions sont exprimées par
des prédicats P(t,v) où t est un ensemble de variables locales. F(t,v) est un ensemble
d’expressions dont chaque élément correspond à une variable de x. Dans une substitution
aussi bien non-déterministe que déterministe, les variables et les expressions sont
séparées par l’opérateur d’affectation “:=”.

Enfin, une substitution vide est spécifiée par l’opérateur “skip”. Elle désigne une
substitution qui n’opère aucun changement sur les variables de la machine. Autrement dit,
nous parlons ici d’un type d’événements qui n’a aucune action.

26
 Tableau 3.1 – Types de substitutions généralisées

1.3 Principe de raffinement

Le raffinement est la base de l’approche “correcte par construction”. Il constitue le

fondement du développement formel en B événementiel. D’une part, il permet de construire
progressivement et de manière incrémentale des programmes corrects à partir des
spécifications abstraites. D’autre part, il assure que chaque étape préserve bien les
propriétés de correction vis-à-vis de l’étape précédente.

Dans un développement B événementiel, il n’y a que les machines qui peuvent évoluer par
raffinement. En effet, un raffinement d’une machine abstraite permet de renforcer les
invariants et ajouter des détails à la spécification du système. Formellement, il est
matérialisé par (1) l’introduction des nouvelles variables d’état (éventuellement, le
remplacement des variables abstraites) et (2) par l’ajout de nouveaux événements
(éventuellement, la modification des événements abstraits). Le processus de
développement par raffinement génère un ensemble d’obligations de preuves qui
permettent de vérifier sa correction.

1.4 Les obligations de preuve

Une obligation de preuve est une proposition mathématique à démontrer pour prouver que
les différents modules ainsi que le processus de spécification sont corrects. Formellement,
elle est codée par un ensemble d’hypothèses et par une conclusion. La démonstration d’une
obligation nécessite obligatoirement la preuve de correction de sa conclusion eu égard à
ses hypothèses.

La méthode B événementiel contient deux grandes classes d’obligation de preuve : les

obligations de preuve du modèle et les obligations de preuve du raffinement. Souvent, ces
obligations sont générées par l’outil de spécification formelle « RODIN » d’une façon
automatique.

Toutefois, certaines obligations ne peuvent pas être automatiquement démontrées et alors

l’intervention de l’utilisateur demeure indispensable. Dans la suite de cette section, nous
présentons les différentes classes d’obligation de preuves.

1.5 Event-B par rapport à B classique

Les principales différences entre Event-B et B classique sont les suivantes :

• La notion d’opération est remplacée par la notion d’événement. Un événement a une

garde (sans précondition), et peut être déclenché si la garde est vraie,

27
• Le remplacement des notions de structuration de machines (USES, SEES, INCLUDES,
IMPORTS ...) par la seule notion de contexte, qui regroupe les constantes et les
ensembles de bases, ainsi que des axiomes associés,
• La disparition de certains types de données et leurs opérateurs associés, notamment les
séquences (seq), les structures (struct) et les arbres (btree),
• La disparition de certaines substitutions. Chaque événement en Event-B a en fait une
forme très simple. La forme la plus compliquée peut-être exprimée par un seul ANY
contenant des assignations (déterministes et non déterministes) parallèles. Les
variables du ANY sont les « paramètres » de l’événement. Il existe deux formes
simplifiées, une pour des événements sans paramètre et une pour des événements sans
paramètre et sans garde,
• Une notion adaptée du raffinement, permettant l’introduction de nouveaux événements
(qui doivent raffiner skip), de séparer un événement en plusieurs événements dans la
machine raffinée, et inversement, de fusionner plusieurs événements,
• Certains aspects permettant une preuve plus dirigée, comme des labels sur les
invariants et les gardes,

En conséquence, B classique est appropriée pour le développement de logiciels et Event-B

pour le développement de systèmes réactifs.

2. Plateforme RODIN
Rodin est une plateforme extensible qui a pour objectif le développement des modèles B
événementiel et la preuve de leurs corrections. Dans cette section, nous allons expliquer le
mode d’utilisation, ainsi que l’architecture de la plateforme. L’utilisation de Rodin est
extrêmement simple. D’abord, l’utilisateur est invité à écrire ou importer sa spécification,
ce qui déclenche systématiquement une vérification statique. Cette dernière désigne la
vérification lexicale et syntaxique de la spécification et l’analyse des types. Une fois la
vérification statique est terminée avec succès, Rodin peut passer à la génération des
obligations de preuve qui seront par la suite transmises aux preuveurs automatiques. Le
générateur d’obligation de preuve permet de produire des théorèmes spécifiques qui
représentent, une fois démontrés, une preuve de la correction du modèle. Les prouveurs
génèrent des inférences destinées à être utilisées pour démontrer les obligations de
preuve. Cependant, une obligation de preuve ne peut pas être toujours démontrée
automatiquement. Ceci peut être dû à une obligation de preuve incorrecte ou à une preuve
qui n’a pas pu être terminée avec les hypothèses données. Dans un tel cas, il est important
que l’utilisateur interagisse avec la palteforme RODIN. Il doit apporter quelques
modifications au niveau de la spécification dans le cas où l’obligation de preuve est
incorrecte. D’autre part, il est utile d’aider les prouveurs à démontrer les obligations de
preuves en ajoutant d’autres hypothèses dans le cas où l’obligation de preuve est correcte.
Toutefois, Rodin est capable de réutiliser autant de fois des anciennes preuves pour
démontrer d’autres obligations. Enfin, une spécification est dite correcte si, et seulement si,
toutes les obligations de preuves générées sont correctement démontrées. La figure 3.4
illustre bien le processus de développement formel adopté par Rodin.

28
 Figure 3. 4– Structure de la plateforme Rodin

Techniquement, Rodin est basé sur l’environnement Eclipse. Il est composé d’un ensemble
de plug-ins dont les outils de spécification et de preuve et une interface utilisateur. Rodin
se compose des plug-ins suivants :

• Plateforme Rodin1 : ce plug-in maintient les fonctionnalités de base de la

plateforme Rodin : le stockage et la gestion des machines, des contextes, des
obligations de preuve et des preuves.
• Noyau B événementiel : ce plug-in personnalise la plateforme Rodin pour le
formalisme B événementiel. Il définit tous les éléments nécessaires à la modélisation
d’un système B événementiel : Static Checker (vérificateur statique de la syntaxe et
du type), générateur d’obligation de preuves et les proveurs.
• Interface utilisateur : ce plug-in offre deux interfaces graphiques différentes à
savoir l’interface de la spécification et celle de la preuve.
• UML-B : est un outil visant à intégrer certains diagrammes UML dans B. Cette
approche vise à corriger le manque de sémantique formelle reproché à UML et à
rendre la méthode B plus facilement utilisable. À partir de packages, diagrammes de
classes et diagrammes états-transitions UML et de stéréotypes définis dans un profil
UML-B, l’outil UML-B génère des machines B. Une version plus récente qui s’appelle
« iUML-B 2» propose de travailler avec Event-B.
• ProB3 : permet l’animation et le model-checking des spécifications B (classique et
évènementiel). En d’autres mots, ProB permet de visualiser le comportement
dynamique d’une machine B et on peut systématiquement explorer tous les états
accessibles d’une machine B pour vérifier des propriétés temporelles. ProB est
entièrement automatique : l’utilisateur ne doit pas fournir des valeurs pour les
variables, constants ou les paramètres des opérations. Ce plugin intègre aussi un
« LTL counter-example visualization » qui permet de vérifier le système par la
technique de vérification des modèles.

3. iUML-B
UML-B de Snook et Butler [47] est une approche outillée [48] visant à intégrer certains
diagrammes UML dans B. Cette approche vise, selon les auteurs, à corriger le manque de

1 http://www.event-b.org/install.html

2 http://wiki.event-b.org/index.php/IUML-B

3 https://www3.hhu.de/stups/prob/index.php/ProB_for_Rodin

29
sémantique formelle reproché à UML et à rendre la méthode B classique plus facilement
utilisable. À partir de packages, diagrammes de classes et diagrammes états-transitions
stéréotypes définis dans un profil UML-B, l’outil U2B génère des machines B. Une version
plus récente baptisée iUML-B propose également de travailler avec Event-B. Dans la suite,
nous étudions la version iUML-B pour Event-B.

iUML-B est issu de la notation UML-B qui combine l’UML et la méthode EventB. La version
actuellement développée utilise la plateforme RODIN. Dans iUML-B, chaque diagramme a
un but précis :

3.1 Diagrammes de classes

Les diagrammes de classes permettent de spécifier les structures de données de la même

manière que dans la programmation orientée objet. Il est possible de définir des classes et
de leur associer des attributs, des méthodes et des contraintes. On peut également
hiérarchiser les types et définir des associations entre des classes. Dans la traduction en
Event-B, ces associations sont modélisées par des relations sur les ensembles et les
méthodes de chaque classe sont des événements qui permettent de modifier ces
ensembles. La partie de la spécification Event-B résultant directement de la traduction ne
peut être modifiée, mais d’autres spécifications peuvent être ajoutées.

3.2 Diagrammes états-transitions

Les diagrammes états-transitions sont associés aux diagrammes de classes des machines
pour décrire les modifications induites par l’exécution d’une transition sur la spécification.
Les transitions correspondent à des évènements Event-B. Des invariants Event-B peuvent
également être associés aux états.

L’approche permet ainsi de spécifier à la fois en UML et Event-B. Certaines tâches

complexes comme l’ordonnancement des évènements ou la définition d’invariants locaux
sont grandement simplifiées par l’utilisation de diagrammes états-transitions.

Cette notation permet de spécifier graphiquement les contraintes d’ordonnancement des

évènements et s’assurer que le code Event-B généré correspond bien à la sémantique des
diagrammes états-transitions. De même, la visualisation des dépendances entre machines
et contextes est plus simple avec UML. Enfin, les traductions des diagrammes de classes en
Event-B permettent une représentation normalisée des classes UML en Event-B.
L’ensemble agit comme un outil permettant d’améliorer la cohérence de la spécification
avec les modèles UML et d’augmenter la lisibilité d’une spécification formelle Event-B.

Pour terminer, il n’existe pas de documentation officielle sur les règles de traduction
implémentées dans l’outil iUML-B. Il est donc difficile de connaître avec précision la
sémantique formelle d’une spécification UML. Il faut utiliser l’outil pour voir le code Event-
B généré.

4. Contribution de la méthode B au domaine des

applications critiques pour l’automobile
Originalement, conçue pour la spécification et la vérification formelle de l’industrie
ferroviaire, la méthode B se développait afin de couvrir une large classe des applications
industrielles critiques et particulièrement les systèmes où les événements (signaux
30
provenant de l’extérieur) jouent un rôle primordial dans la définition de la sémantique du
comportement réactif du système.

Event B et Hybrid Event B sont deux extensions du langage B pour supporter le

comportement réactif à base d’événement et les systèmes réactifs mixtes à temps discret et
continu.

Bien que Hybrid Event B, n’ait pas encore eu une bonne acceptation auprès de la
communauté logicielle, Event B a attiré beaucoup d’attention auprès des industriels et des
chercheurs académiques.

Cette partie est consacrée à l’étude de la contribution de la méthode B et ses extensions

Event-B et Event-B hybride à la spécification et la vérification formelle des applications
critiques d’automobile et en particulier le système de contrôle de régulateur de vitesse.

4.1 Travail du Rainer Gmehlich et al.

Dans ce travail [49], les auteurs décrivent un processus de développement qui se compose
de cinq phases pour les applications automobiles. Le processus insiste sur la nécessité
d'avoir des notations adéquates (et personnalisées) (cadres de problèmes, langage
machine d'état des exigences et Event B) pour chaque phase de développement, ainsi
qu'une traçabilité directe entre les documents produits au cours de chaque phase. Cela
permet une vérification / validation par étapes du système en cours de développement. Les
idées pour la méthode de développement formel ont évolué sur deux cas d’études
significatifs réalisés dans le projet DEPLOY.

Figure 3. 5– Processus de développement formel [49]

Le point de départ de processus est une idée abstraite du système et / ou des exigences
initiales vagues (voir l'étape 1 de la figure 3.5). Afin de produire un document d'exigences
pour un développement ultérieur, ces exigences initiales vagues doivent être analysées et
des exigences concrètes doivent être développées. Pour cette analyse et le développement
PFA (Problem Frames Approach) est appliqué. La phase suivante du processus est la phase

31
de spécification dans laquelle le comportement fonctionnel souhaité du système et de
l'architecture est décrit de manière précise à l'aide de RSML (Requirements State Machine
Language. Après la phase de spécification, la phase de modélisation formelle suit (voir
l'étape 3 de la figure 3.5). Pendant cette phase, la spécification est traduite en un modèle
formel écrit dans un langage formel (par exemple, Event-B). Les principales activités de
cette phase sont la formalisation du comportement fonctionnel. La phase suivante de cette
approche est la phase de vérification formelle (voir l'étape 4 de la figure 3.5). Dans cette
phase, les raffinements du modèle formel ainsi que les exigences formalisées sont vérifiés
sur le modèle en utilisant des techniques de vérification formelles telles que le prouve de
théorèmes et la vérification de modèles. Le résultat de la phase de vérification est un
modèle formel vérifié en ce qui concerne les exigences formalisées. La dernière phase de
l’approche est la génération de code avec le compilateur EB2C.

4.2 Travail du Alexander Krupp et al.

Dans ce travail [50], les auteurs ont présenté une étude de cas de régulateur de vitesse
adaptatif des voitures Volvo en utilisant la méthode B puis la transformation des
opérations B, des types de données et des invariants vers le langage d'entrée RAVEN pour
la vérification formelle à base de model checking. En plus de vérifier les invariants B
restreints, RAVEN est capable de vérifier les contraintes, qui impliquent des séquences
d'états. Parmi celles-ci figurent des propriétés qualitatives supplémentaires telles que les
contraintes de sécurité, d'accessibilité, de réponse, d'inévitabilité et de vivacité pour la
vérification basée sur l'état. Spécialement avec Event-B, il est utile de pouvoir vérifier
d'éventuelles séquences d'états. En outre, RAVEN effectue une analyse quantitative et
temporelle. Il permet de déterminer les temps de réaction minimum ou maximum, et de
vérifier les valeurs minimales et maximales des entiers dans un certain ensemble d'états.

4.3 Travail du Richard Banach et Michael Butler

Ce travail [51] présente une étude de cas sur le régulateur de vitesse d’automobile
conventionnel. Ce système est spécifié dans Hybrid Event-B qui est une extension de Event-
B pour supporter la modélisation des systèmes à temps continu. Hybrid Event-B traite les
comportements discrets et continus de la même manière.

4.4 Travail du Stefan Hallerstede et Michael Leuschel

Dans ce travail [52], les auteurs introduisent une nouvelle approche basée sur les
contraintes pour découvrir les inter-blocages en utilisant le solveur de contraintes ProB
afin de trouver des valeurs pour les constantes et les variables des modèles formels qui
décrivent un état de blocage. Ce travail discute les principes de la technique mise en œuvre
dans le noyau Prolog de ProB et présente quelques résultats d'une étude de cas de système
de régulateur de vitesse conventionnel. La vérification de l'absence d’inter-blocage est
importante dans de nombreuses applications critiques. Selon les auteurs, l'utilisation de la
vérification de modèle pour trouver des inter-blocages dans des modèles formels est
limitée parce que, dans de nombreuses applications industrielles, l'espace d'état est infini
ou beaucoup trop grand pour être exploré de manière exhaustive.

32
Chapitre 4 : Conception et implémentation
Les exigences qui s’appliquent aux développements des systèmes justifient l’utilisation des
meilleures techniques disponibles pour garantir la qualité des spécifications et conserver
cette qualité lors du développement du code. Les méthodes formelles, et parmi elles la
méthode EventB, permettent d’atteindre ce niveau de qualité. En effet, elles ont été
élaborées afin d’assurer un niveau aussi élevé que possible en matière de précision et de
cohérence. Les principales caractéristiques de ces méthodes sont : (i) Elles permettent de
vérifier la correction d’un logiciel par rapport à sa spécification. (ii) Elles nécessitent une
forte connaissance des mathématiques.

Le premier point, qui représente l’avantage majeur des méthodes formelles, relève du fait
que les modèles mathématiques permettent un raisonnement rigoureux sur la cohérence
du système. Le second point, qui se présente, certes, comme l’essentiel frein à l’adoption
des méthodes formelles, est fortement lié aux notations, souvent complexes, des langages
formels. Ces deux caractéristiques ont fait que les méthodes formelles restent dédiées aux
systèmes dits critiques, pour lesquels la sûreté et la sécurité sont indispensables.

L’une des solutions proposées par plusieurs travaux de recherche est de spécifier le
système en se basant sur un langage semi-formel (e.g. UML) et de le traduire ensuite en un
langage formel. Les spécifications formelles, résultant de cette traduction, peuvent alors
être exploitées en vue de poursuivre un raisonnement rigoureux du même système.

Dans notre travail, il s’agit d’utiliser des diagrammes UML conjointement avec la méthode
EventB pour spécifier et vérifier le système de régulateur de vitesse, et ce, en proposant un
flot de spécification et de vérification formelle basé sur la notation UML et l’Event B. Ce flot
se procède par raffinement successif en partant d’une spécification très abstraite purement
fonctionnelle basée sur le diagramme des cas d’utilisation d’UML jusqu’à l’obtention d’une
machine implémentable sur un ordinateur.

Le système décrit dans ce chapitre est le système de régulateur de vitesse communément

appelé CCS (Cruise Control System) avec ces trois variations : CC (Cruise Control), et ACC
(Adaptive Cruise Control) et CACC (Cooperative and Adaptive Cruise Control).

Ce chapitre est organisé comme suit : D’abord dans la section 1, nous commençons par
présenter notre conception UML en vue de modéliser les trois aspects (fonctionnel,
statique et dynamique) de système de régulateur de vitesse. Ensuite, au niveau de la
section 2, nous présentons notre outil, qui permet de générer automatiquement un code
Event B à partir des diagrammes des cas d’utilisation. Quant à elle, la section 3 sera
consacrée au processus de raffinement de notre machine abstraite et son contexte initial
(générés à partir de diagramme de cas d’utilisation) en utilisant le plugin iUML-B de
l’environnement RODIN. Enfin, dans la section 4, nous présentons la tache de vérification
des spécifications EventB générées en utilisant la technique de vérification des modèles
(model-checking).

1. Modélisation UML de système de régulateur de

vitesse
Dans cette section, nous allons donc adopter cette démarche de modélisation afin de
construire efficacement notre modèle :

33
− Pour la spécification et l’analyse des besoins, nous allons utiliser le diagramme de cas
d’utilisation.
− Pour les activités de conception statique et dynamique, nous allons utiliser le
diagramme de classe et les diagrammes d’état-transition respectivement.

Notez que toutes les diagrammes UML développés dans cette section sont inspirés à partir
de la documentation officielle de système de régulateur de vitesse CACC [8, 9].

1.1 Diagramme de cas d’utilisation

Les besoins sont le point de départ pour le développement du nouveau système, ils doivent
traduire ce qu’il va apporter aux utilisateurs, en montrant les différentes fonctionnalités.
Bien souvent, la maîtrise d'ouvrage et les utilisateurs ne sont pas des informaticiens. Il leur
faut donc un moyen simple d'exprimer leurs besoins. C'est précisément le rôle des
diagrammes de cas d'utilisation qui permettent de recueillir, d'analyser et d'organiser les
besoins, et de recenser les grandes fonctionnalités d'un système. Il s'agit donc de la
première étape d'analyse dans le processus de conception de notre système.

Dans cette section nous allons utiliser le diagramme de cas d’utilisation pour bien collecter
les besoins du nouveau système. Le diagramme complet de cas d’utilisation est représenté
dans la figure 4.1. La description textuelle est fournie en annexe de ce mémoire (Annexe A).

Figure 4. 1 – Le diagramme de cas d’utilisation pour le système CACC

34
1.2 Diagramme de classe

Ci-dessous le diagramme de classes pour le système « Régulateur de vitesse ». Ce

diagramme représente les objets physiques du système et les différentes relations entre
eux. Les principaux composants sont :

− Les actionneurs « Actuators », sous forme de freins, d'accélérateur, d’écran de

tableau de bord et émetteur réseau.
− Les contrôleurs « Controllers » sous forme de contrôleur principal, contrôleur de
convoi (Platoon), et contrôleur de vitesse.
− Les capteurs « sensors » sous forme de boutons, radars, caméra, tableau de bord et
récepteur réseau.

Figure 4. 2 – Le diagramme de classe pour le système CACC

La description textuelle de diagramme de classe -sous forme d'un dictionnaire de données-

est donnée en annexe (Annexe B).

1.3 Diagramme d’état-transition

Les diagrammes d'états-transitions d'UML décrivent le comportement interne d'un objet à

l'aide d'un automate à états finis. Ils présentent les séquences possibles d'états et d'actions
qu'une instance de classe peut traiter au cours de son cycle de vie en réaction à des
événements discrets (invocations de méthode).

Ci-dessous le diagramme d'état-transition global pour le système « Régulateur de vitesse »

(figure 4.3), en sachant que, les états CACC, ACC et CC sont des états composites (voir les
figure 4.4, 4.5 et 4.6).
35
Figure 4. 3 – Le diagramme d'état global du système

Figure 4. 4 – L’état composite CC

Figure 4. 5 – L’état composite ACC

36
 Figure 4. 6 – L’état composite CACC

Vous trouverez dans l’annexe C, la description textuelle des diagramme d'état ci-dessus.
Nous allons décrire chaque état fonctionnel du système et les événements qui provoquent
des transitions entre ces états.

2 Transformation du diagramme de cas d’utilisation

vers EventB
RODIN est une plateforme extensible qui a pour objectif le développement des modèles B
événementiel et la preuve de leurs corrections. Il est basé sur l’environnement Eclipse. Il
intègre le plugin « iUML-B » qui permet de générer un code Event B de façon automatique à
partir de deux vues : statique (diagrammes de classes) et dynamique (diagramme états
transition). La vue fonctionnelle n’est pas prise en compte par RODIN. Pour cette raison et
afin d’enrichir l’environnement RODIN, nous proposons d’intégrer la vue fonctionnelle en
rajoutant un plugin qui génère de code Event B à partir des diagrammes des cas
d’utilisation d’UML.

La plateforme Eclipse depuis sa version 3.2, nous ayons offert les plugins EMF (Eclipse
Modeling Framework) et GMF (Graphical Modeling Framework) afin de générer des éditeurs
graphiques (sous forme de plugins) stables et réutilisables en utilisant l’architecture MDA
(Model Driven Architecture). Cette génération est très confortable car elle permet de se
concentrer sur la modélisation du méta-modèle de donnée et non pas sur la
programmation proprement dite.
37
Dans le cadre de ce travail, nous avons construit un éditeur graphique pour la création et la
manipulation des diagramme d’état-transition, en se basant sur EMF et GMF. EMF est un
cadre de modélisation et de génération de code pour la construction d’outils. GMF permet
aux développeurs de créer rapidement un éditeur graphique à partir d’un modèle
d’application existant.

Ensuite pour la génération d’un code EventB, Nous avons utilisé le framework Xpand qui
fait parti des outils Model to Text (M2T) d'Eclipse. Il s'agit de transformer un modèle
(diagramme de cas d’utilisation) en fichier texte (code EventB).

2.1 Éditeur graphique pour les diagrammes de cas d’utilisation

La figure ci-dessus (figure 4.7) présente le processus que nous allons le suivre pour la
génération de notre éditeur graphique (pour plus de détail, voir l’annexe D).

Figure 4. 7 – Processus de génération de l’éditeur avec GMF

Nous partons d'un fichier Ecore qui modélise le méta-modèle pour notre diagramme en
utilisant le framework EMF. Ce méta-modèle (figure 4.8) est représenté par la classe
principale « UCDiagramme ». Cette classe est composée d’un nombre illimité des cas
d’utilisation (UseCase), d’un nombre illimité des acteurs (Actors) et les associations entre
les deux éléments. Ainsi que les relations d’inclusion (Include) et d’extension (Extend)
entre deux cas d’utilisation. Chaque classe fils contient un attribut « nom » de type string.

38
 Figure 4. 8 – Méta-modèle pour les diagrammes de cas d’utilisation

À la fin de ce processus nous avons obtient notre éditeur graphique pour les diagrammes
de cas d’utilisation (figure 4.9). Maintenant, on peut entamer à la création de diagramme à
l'aide des palettes situées à droite de la plate-forme.

Figure 4. 9 – Editeur graphique pour les diagrammes de cas d’utilisation

2.2 Outil de transformation UC2EventB

Il s'agit lors de cette première étape de notre flot de spécification et vérification. De générer
d'une manière systématique la spécification EventB qui est sémantiquement équivalente au
diagramme de cas d’utilisation élaboré avec notre éditeur graphique.

L'ensemble des règles de transformation entre le diagramme de cas d’utilisation et la

description EventB sont déjà définie par le travail [53] et seront présentées en détails dans
l’Annexe E.

39
Dans le cadre de notre travail, nous avons utilisé le framework Xpand pour implémenter les
règles de transformation entre les concepts de diagramme de cas d’utilisation et les
spécifications EventB. Xpand repose sur plusieurs types de fichiers. Pour ce travail, deux
d'entre eux sont utilisés : les fichiers Template (*.xpt) et les fichiers workflow (*.mwe). Les
fichiers Template vont définir les règles de transformation du modèle vers le format texte.
Nous avons défini deux Templates : Une pour la génération de fichier « Contexte » (figure
4.10) et la deuxième pour la génération de fichier « Machine » (figure 4.11). Les fichiers
workflow sont chargés de lancer les transformations en indiquant quels modèles doivent
être lus et quels fichiers Template doivent être utilisés. Pour rappel ces fichiers sont fournis
en Annexe (E) de ce mémoire.

Figure 4. 10 – Partie de template de génération de fichier « Context » avec Xpand

Figure 4. 11 – Partie de template de génération de fichier « Machine » avec Xpand

Notre outil qui s’appelle UC2EventB utilise le méta modèle «UCDiagramme.ecore » (figure
4.8) et le fichier xmi qui contient le jeu de données pour ce modèle créé avec notre éditeur
(figure 4.9) pour générer en sortie les fichiers M0 et C0 (qui contient, respectivement, les
descriptions textuelles de la machine abstraite et son contexte initial).

3. Processus de raffinement
La deuxième étape dans notre flot consiste à raffiner la machine abstraite et son contexte
initial en introduisant les informations sur le domaine d’application et l’aspect
comportemental.
40
 Figure 4. 12 – La transformation de diagramme de classe vers EventB via l’outil iUML-B

Pour ce faire, nous avons utilisant le plugin iUML-B de l’environnement RODIN pour
générer de manière automatique la machine « M1 » et son contexte « C1 » à partir des
diagrammes de classe (figure 4.12) et le diagramme global de cas d’utilisation (figure 4.13).

Figure 4. 13 – La transformation de diagramme d’état global vers EventB via l’outil iUML-B

En troisième étape, nous raffinons encore le diagramme d’état-transition globale en

introduisant les états composites de diagramme afin de générer la machine « M2 » et son
contexte « C2 ».

41
Figure 4. 14 – La transformation de diagramme d’état enrichi vers EventB via l’outil iUMLB

4. Animation et vérification des modèles

En plus de la vérification de l’ensemble d’obligations de preuves générés par
l’environnement RODIN lors de processus de développement par raffinement qui
permettent de vérifier la correction de notre spécifications EventB. En utilisant le plugin
ProB conjointement avec iUMLB, nous pouvons encore (1) Animer nos diagramme d’état-
transition UML avec quelques scénarios de l’utilisation de notre système, et (2) Vérifier des
propriétés d’absence d’interblockage et de violation des invariants par la technique de
vérification des modèles (model-checking) et (3) Spécifier et vérifier quelques propriétés
LTL (de nature désirables et non désirables) dans notre spécifications EventB.

4.1 Animation des diagrammes d’état-transition UML

Avec l’environnement RODIN, nous pouvons animer les diagrammes d’état transition c.à.d.
voir l’enchaînement des évènements dans un scénario d’exécution. Pour ce faire, nous
avons exécuté avec succès trois scénario d’exécution nominal pour notre système de
régulateur de vitesse (voir les figures 4.15, 4.16 et 4.17).

42
Figure 4. 15 – Scénario 1 : Le conducteur active le système, et choisir le niveau « CC ».

Figure 4. 16 – Scénario 2 : Le conducteur active le système, et choisir le niveau « ACC ».

43
 Figure 4. 17 – Scénario 3 : Le conducteur active le système, et choisir le niveau « CACC ».

4.2 Model-Checking

Rodin à travers son plugin ProB offre la possibilité de parcourir l’ensemble des états de
système en largeur (BFS) en tentant de trouver via la technique Model-checking les
éventuelles interblocage (deadlock), les violations des invariants (Invariant violations), les
violations des théorèmes (Theorem violations), etc. Dans notre travail, nous avons vérifié
l’absence de ces propriétés en appliquant le model checking de RODIN et les résultats sont
donnés dans la figure 4.18.

Figure 4. 18 – Application de model-checking sur notre système

4.3 Vérification des propriétés LTL

En plus, dans cette étape, nous définissons quelques propriétés LTL (logique
temporelle linéaire) afin de vérifier notre système de régulateur de vitesse, toujours par la
technique de model-checking, via le plugin ProB.
44
4.3.1 Propriété 1 : OFF-> O (ON)

Cette propriété a pour objectif de vérifier si le système est dans son état Off, il sera alors
dans son état On dans le prochain état (O pour Next). Cette propriété était de nature
désirable au sein du système étudié. Le résultat d’exécution (figure 4.19) confirme cette
hypothèse.

Figure 4. 19 – Résultats d’exécution de propriété 1

4.3.2 Propriété 1 : <> (CC/\ACC/\CACC)

Cette propriété a pour objectif de vérifier si, éventuellement (<>), le système est dans son
état CC au même moment dans son état ACC et au même moment dans son état CACC. Cette
propriété est donc de nature non désirable.

Cette propriété était de nature non désirable au sein du système étudié. Comme le résultat
obtenu est un contre-exemple (figure 4.20), cela signifie que la propriété en question n'a
pas été vérifiée et, par le fait même, cette situation est impossible au sein du système.

Figure 4. 20 – Résultats d’exécution de propriété 2

4.3.3 Propriété 3 : <> (CCAccelerating /\CCDecelerating )

Cette propriété a pour objectif de vérifier si, éventuellement, le système est dans son état
d’accélération au même moment dans l’état décélération. Cette propriété est donc de
nature non désirable.

Figure 4. 21 – Résultats d’exécution de propriété 3

45
4.3.4 Propriété 4 : [](InvtingDriver->CommunicatiogWithGPS)

Cette propriété tente de vérifier si le système est dans son état InvtingDriver, l’état
CommunicatiogWithGPS sera son prochain état toujours ([]). Cette propriété est donc de
nature non désirable. Noter que "[]" est l'opérateur temporel Benceforth.

Figure 4. 22 – Résultats d’exécution de propriété 4

4.3.5 Propriété 5 : (SlowingDown) -> <>(CommunicatingWithGPS)

Cette propriété tente de vérifier que si le système est dans son état SlowingDown, il sera
éventuellement dans son état CommunicatingWithGPS. Noter que <> est l'opérateur
temporel Eventually. Le résultat d’exécution (figure 4.23) confirme cette propriété.

Figure 4. 23 – Résultats d’exécution de propriété 5

46
 Conclusions et perspectives
1. Conclusion
Dans ce mémoire, nous avons proposé une nouvelle approche formelle basée UML/EventB
pour spécifier et vérifier les systèmes critiques de l’automobile en combinant les avantages
de formalisme de modélisation graphique semi formelle UML et le langage de spécification
formelle EventB.

La nouveauté qu’apporte notre approche est de considérer à la fois l’aspect fonctionnel qui
donne les grandes fonctionnalités (besoins) de système en terme de diagramme de cas
d’utilisation, et l’aspect structurel (statique) c.à.d. les informations sur le domaine
d’application en terme de diagramme de classe, et l’aspect comportemental (dynamique)
de système en termes de diagramme d’état-transition.

Le flot de développement de notre approche comme nous l’avons indiqué, est organisé en 4
étapes :

i. La première étape consiste à transformer une spécification très abstraite purement

fonctionnelle décrite à l’aide d’un diagramme des cas d’utilisation d’UML en une
spécification Event B sémantiquement équivalente. Pour ce faire, nous avons conçu et
implémenté un outil qui fait cette transformation de façon automatique.
ii. La deuxième étape consiste à raffiner la spécification EventB résultante en introduisant
les informations sur le domaine d’application en terme de diagramme de classe, ainsi
qu’une description comportementale abstraite de système en terme de diagramme
d’état transition. Comme nous l’avons déjà mentionné, la transformation est faite de
manière automatique via le plugin iUML-B.
iii. En troisième étape, nous raffinons les cas d’utilisations en introduisons l’aspect
comportemental à partir des diagrammes d’états transitions d’UML en obtenant une
machine suffisamment concrète capable de générer un code source écrit dans un
langage de programmation donné.
iv. La quatrième étape, quant à elle, est celle de la vérification. En plus de la vérification de
l’ensemble d’obligations de preuves générés par l’environnement RODIN lors de
processus de développement par raffinement, nous avons utilisé aussi la technique de
model-checking pour vérifier quelques propriétés dans notre système.

2. Perspectives
Malgré que l’approche proposée dans ce travail bénéficie de beaucoup de puissance vue
qu'elle propose un cadre formel par lequel il serait possible de spécifier et vérifier
formellement les systèmes critiques. Il reste encore des pistes à explorer afin de compléter
notre approche :

i. Ajouter d’autres vues dans le flot de développement, en introduisant les diagrammes de

séquences, d’activités, etc.
ii. Étendre cette approche afin de générer un code source écrit dans un langage de
programmation comme le C, C++, Java, etc.
iii. Appliquer cette approche sur d’autres études de cas réelles des systèmes critiques.

47
Références
[1] Le Robert Micro. Paris: Dictionnaires Le Robert. 1997.
[2] Abdoulaye Amadou Maranga. « Techniques Mixtes de Positionnement et la Navigation
Véhiculaire ». Mémoire de maîtrise Spécialité : génie électrique. Université De Sherbrooke.
Canada. 2015.
[3] Anderson, J., Kalra, N., Stanley, K.D., Sorensen, P., Samaras, C., &Oluwatobi, A.O.
« Autonomous vehicle technology: A guide for policy makers ». RAND corporation 2014.
[4] Alexia Biglia. « Analyse prospective sur l’implémentation de la voiture autonome :
impact sur l’industrie automobile et le citoyen ». Mémoire-recherche En vue de l'obtention
du titre de Master en sciences de gestion, Université Catholique de Louvain. 2015.
[5] Kalra, N., Anderson, J., &Wachs, M. “Liability and regulation of autonomous vehicle
technologies”. RAND Corporation. 2009.
[6] DiClemente, J., Mogos, S., & Wang, R. « Autonomous car policy report”. Pittsburg:
Carnegie Mellon University. 2014.
[7] Lutin, J., Kornhauser, A., & Lerner-Lam, E. « The revolutionary development of
selfdriving vehicles and implications for the transportation engineering profession”. ITE
journal, 28-32. 2013.
[8] Anthony Curley, Justin Mrkva, Devan Sayles, Grayson Wright. “Cooperative Adaptive
Cruise Control System”. Software Requirements Specification (SRS). 2015.
[9] Alex Crimin, Joseph Hollopter, Roy Barnes, Chengzhu Jin, Jimmy Mkude. “Cooperative
Adaptive Cruise Control System: team 2”. Software Requirements Specification (SRS). 2015.
[10] Anne E.Haxthausen. “An Introduction to Formal Methods for the Development of Safety-
critical Applications”. Technical University of Denmark, 2010.
[11] Bilel Gargouri, Mohamed Jmaiel ,and Abdelmajid Ben Hamadou. “Vers l’utilisation des
méthodes formelles pour le développement de logiciels ». In Proceedings of the 17 th
international conference on Computationa llinguistics-Volume1, pages438–443. Association
for Computational Linguistics,1998.
[12] Jeannette M Wing. “Formal Methods”. Encyclopedia of Software Engineering, pages 504–
517,1994. Revisionin Second Edition.
[13] Charles Antony Richard Hoare. “An axiomatic basis for computer programming”.
Communications of the ACM,12(10) :576–580, 1969.
[14] John V Guttag, James J Horning, Stephen J Garland, Kevin D Jones, Andres
Modet, and Jeannette M Wing. “Larch :languages and tools for formal specification” .In
Textsand Monographs in Computer Science. Citeseer,1993.
[15] Kokichi Futatsugi , Joseph A Goguen, Jean-Pierre Jouannaud, and José Meseguer.
« Principles of OBJ2”. In Proceedings of the 12th ACM SIGACT-SIGPLAN symposium on
Principles of programming languages, pages 52–66. ACM, 1985.
[16] Tommaso Bolognesi and Ed Brinksma. “Introduction to the ISO specification language
LOTOS”. Computer Networks and ISDN systems,14(1):25–59,1987.
[17] Andrew Harry. Formal Methods: Fact File: “VDM and Z”. John Wiley & Sons, Inc.,
1997.
[18] Jonathan Peter Bowen. “Formal specification and documentation using Z: A case study
approach”, volume 66. International Thomson Computer Press London, 1996.
48
[19] Jean-Raymond Abrial. “The B-book: assigning programs to meanings”. Cambridge
University Press, 1996.
[20] Carl Adam Petri. “Communication with automata”. Technical Report RADC-TR-65-377,
1966.
[21] Robin Milner. “Lectures on a calculus for communicating systems”. In Control Flow and
Data Flow: concepts of distributed programming , pages205–228. Springer, 1986.
[22]RAISE Language Group. “The RAISE specification language”. Prentice Hall, 1992.
[23] “Atelier B”. Website. http://www.atelierb.eu/,2012. Clearsy System Engineering.
[24] Kevin Lanoand, Howard Haughton. “Specification in B: An introduction using the B
toolkit”. World Scientific, 1996.
[25] Cliff B Jones, Kevin D Jones, Peter Alexander Lindsay, Richard Moore, J Bicarregui,
M Elvang-Gøransson, RE Fields, R Kneuper, B Ritchie, and AC Wills. “Mural–A Formal
Development Support System”, 2004.
[26] Petra Malikand, Mark Utting. CZT: “A framework for Z tools”. In ZB 2005: Formal
Specification and Development in Z and B , pages 65–84. Springer, 2005.
[27] “Time petri Net Analyzer”. Website. http://projects.laas.fr/tina. LAAS/CNRS
[28] Eric Meyer. « Développement formel par objets: utilisation conjointe de B et UML ». PhD
thesis, Université de Nancy,2001.
[29] INRIA. “The Coq Proof assistant”. http://coq.inria.fr/.
[30] Edmund M Clarke, Orna Grumberg ,and Doron Peled. “Model checking” .MIT press, 1999.
[31] Jean-Charles Grégoire, Gerard J Holzmann, and Doron Peled. « The SPIN Verification
System”: The Second Workshop on the SPIN Verification System: Proceedings of a DIMACS
Workshop, August5, 1996, volume32. American Mathematical Soc.,1997.
[32] Johan Bengtsson, Kim Larsen, Fredrik Larsson, Paul Pettersson, and Wang Yi . “UP-
PAAL a tool suite for automatic verification of real-time systems”. Springer, 1996.
[33] Tobias Nipkow, Lawrence C Paulson, and Markus Wenzel . ”Isabelle/HOL : a proof
assistant for higher-order logic” , volume 2283. Springer ,2002.
[34] Sam Owre, Natarajan Shankar, John M Rushby, and David WJ Stringer-Calvert.
“PVS Language Reference”. SRI International, 2001. Version 2.4.
http://pvs.csl.sri.com/doc/pvs-language-reference.pdf.
[35] Jagannath Aghav and Ashwin Tumma. “Design And Validation Of Safety Cruise Control
System For Automobiles” . in Ijcsea 2011
[36] Petter Nilsson et al. “Correct-by-Construction Adaptive Cruise Control: Two
Approaches”. IEEE Transactions on Control Systems Technology ( Volume: 24, Issue: 4, July
2016 ) Page(s): 1294 - 1307
[37] T.A.W. (Erwin) Bronkhorst. “Hardware design of a cooperative adaptive cruise control
system using a functional programming language”. Master’s thesis. Faculty of Electrical
Engineering, Mathematics and Computer Science (EEMCS), August 18, 2014
[38] Sarah M. Loos , André Platzer , Ligia Nistor. « Adaptive Cruise Control: Hybrid,
Distributed, and Now Formally Verified”. International Symposium on Formal Methods FM
2011: FM 2011: Formal Methods pp 42-56

49
[39] Rob Hieronsa, Sadegh Sadeghipourb, and Harbhajan Singhc: “Testing a System
specified using Statecharts and Z”. Information & Software Technology, Volume 43,
Number 1, January 2001
[40] Olf Stursberga, Ansgar Fehnkerb, Zhi Hanb, Bruce H. Kroghb: “Verification of a cruise
control system using counterexample-guided search” Control Engineering Practice
12(10):1269-1278 · October 2004
[41] Anthony Spiteri Staines: “Modeling and analysis of real time control systems: a cruise
control case study” In book: Recent Advances in Technologies, November 2009
[42] John Hudak and Peter Feiler: “Developing AADL Models for Control Systems: A
Practitioner’s Guide” Technical report, july 2007
[43] DeJiu Chen · Lei Feng · Tahir Naseer Qureshi, Henrik Lönn, Frank Hagl: “An
architectural approach to the analysis, verification and validation of software intensive
embedded systems”. Journal Computing, Volume 95 Issue 8, August 2013, Pages 649-688.
[44] John Eriksson. “Formal Requirement Models for Automotive Embedded Systems”.
Degree Project In Computer Science And Engineering, Second Cycle, 30 Credits, Stockholm,
Sweden, 2016
[45] Jean-Raymond Abrial. “Modeling in Event-B - System and Software Engineering”.
Cambridge University Press (2010).
[46] Michael Jastram, « Rodin User's Handbook », Deploy Project, 2012.
[47] C. Snook et M. Butler, « UML-B : Formal modeling and design aided by UML» ACM
Transactions on Software Engineering and Methodology (TOSEM), vol. 15, no. 1, pp. 92–
122, 2006.
[48] C. Snook et M. Butler, « U2B - A tool for translating UML-B models into B, » dans UML-
B Specification for Proven Embedded Systems Design, J. Mermet, éditeur, 2004.
[49] Rainer Gmehlich, KatrinGrau, Alexei Iliasov, Michael Jackson, Felix Loesch, Manuel
Mazzara. “Towards a Formalism-Based Toolkit for Automotive Applications”. 1st FME
Workshop on Formal Methods in Software Engineering (FormaliSE), May 25, 2013, San
Francisco, CA, USA
[50] Alexander Krupp · Ola Lundkvist· Tim Schattkowsky · Colin Snook Chapter: “The
Adaptive Cruise Controller Case Study”. In UML-B Specification for Proven Embedded
Systems Design book, Jan 2004
[51] Richard Banach and Michael Butler. “Cruise Control in Hybrid Event-B” ICTAC 2013:
Theoretical Aspects of Computing – ICTAC 2013 pp 76-93
[52] Stefan Hallerstede, Michael Leuschel, Heinrich Heine. “Finding Deadlocks of Event-B
Models by Constraint Solving”. 2011 B Workshop.
[53] Thiago C. de Sousa, Luciano Kelvin, Constantino Dias Neto, Carlos Giovanni N. de
Carvalho. « A Formal Semantics for Use Case Diagram Via Event-B », Journal of Software ,
Volume 12, Number 3, March 2017.

50
51