1
Chapitre 1
Introduction
La science du logiciel est jeune, encore balbutiante. Les besoins ayant crû plus vite que les
savoirs, l’industrie a fait face aux problèmes en concentrant d’importantes forces de travail pour la
réalisation de gros projets. Aujourd’hui,un projet logiciel se gère encore souvent comme la construc-
tion d’une cathédrale au moyen âge, ou une ascension himalayenne il y a un demi siècle. Les même
causes entraînant les même effets, la complexité croissante des applications informatiques a mal-
heureusement pour corollaire l’existence de comportements anormaux aux conséquences parfois
irréparables : panne du réseau téléphonique aux USA en 89, rappel de centaines de milliers de
Pentium par INTEL en 96, (discrète) panne du réseau de téléphonie mobile de France Télécom en
région parisienne en janvier 98, destruction de la première fusée Ariane 5 en 99, etc. Pour mesu-
rer la difficulté du problème, il faut savoir que les logiciels envahissent tous les objets de notre vie
courante (30 lignes de code dans le programmateur d’une machine à laver), et que certains grands
logiciels comptent plusieurs dizaines de millions d’instructions (plus d’un million dans un téléphone
portable), et que leur conception obéit à des principes méthodologiques encore rudimentaires. La
délivrance sur le marché d’un logiciel suppose bien sûr une (coûteuse) phase de tests. Mais si ces
derniers se révèlent aptes à identifier une bonne part des erreurs, ils ne constituent en rien une ga-
rantie.
L’erreur est parfois interdite, comme dans le cas de l’aéronautique, de la téléchirurgie, du té-
lépaiement par carte à puce, ou du contôle d’une centrale nucléaire. Les logiciels concernés sont
dits critiques. La vérification de logiciels critiques est un domaine de recherche en plein essor, qui
s’appuie sur une demande industrielle certes récente mais en forte croissance. Très souvent, ces logi-
ciels critiques ont pour objectif le contrôle d’un processus qui communique avec son environnement
par l’intermédiaire de capteurs, themomètres, signaux, claviers, etc. Ces logiciels n’ont pas pour but
de calculer un résultat, mais d’assurer le fonctionnement permanent du processus contrôlé, on les
apppelle des systèmes réactifs . Une autre caractéristique fréquente de ces systèmes critiques est
que leur comportement global dépend de l’interaction de plusieurs sous-systèmes évoluant en paral-
lèle, ce sont des systèmes distribués. Enfin, le paramètre temps intervient généralement de manière
explicite, ce sont des systèmes temps réel.
Qu’ils soient critiques ou pas, c’est à la spécification et à la vérification de systèmes réactifs
temps réels distribués que nous allons nous atteller. Il y a pour cela deux grandes (familles de)
techniques : les méthodes de preuve, où l’ingénieur utilise un assistant de preuve afin de prouver
que le système étudié satisfait ses spécifications; les méthodes de vérification (en anglais, model
checking) qui ont pour but de prouver automatiquement certaines propriétés dites de sureté pour les
plus importantes (ou leur négation ...).
Ce cours a pour but d’aborder les différentes phases, de la conception à la vérification, de la
construction de systèmes distribués réactifs temps réel.
La première étape dans l’élaboration d’un tel système est celle de la spécification. Nous étudie-
rons donc comment spécifier ces systèmes réactifs à l’aide d’automates temporisés et de produits de
J.-P. Jouannaud École Polytechnique