UNIVERSITE D’ANTANANARIVO

ECOLE SUPERIEURE POLYTECHNIQUE

D’ANTANANARIVO

Département : ELECTRONIQUE

MEMOIRE EN VUE DE L’OBTENTION

DU

DIPLOME D’ETUDES APPROFONDIES

Spécialité : Électronique

Option : Systèmes embarqués

Présenté par : ANDRIANANTENAINA Zo Ambinintsoa

Date : 01 Avril 2014

Encadré par : Mme RABEHERIMANANA Lyliane

MODELISATION FORMELLE D’UN NOYAU

POUR SYSTEME D’EXPLOITATION EMBARQUE

ET VERIFICATIONS SOUS Z/EVES

Année Universitaire : 2006-2007

UNIVERSITE D’ANTANANARIVO

ECOLE SUPERIEURE POLYTECHNIQUE

D’ANTANANARIVO

Département : ELECTRONIQUE

MEMOIRE EN VUE DE L’OBTENTION

DU

DIPLOME D’ETUDES APPROFONDIES

Spécialité : Électronique

Option : Systèmes embarqués

Président du Jury : M. RASTEFANO Elisée

Examinateurs : M. RAKOTOMIRAHO Soloniaina

M. RATSIMBA Mamy

M. ANDRIAMIASY Zidora

Rapporteur : Mme RABEHERIMANANA Lyliane

MODELISATION FORMELLE D’UN NOYAU

POUR SYSTEME D’EXPLOITATION EMBARQUE

ET VERIFICATIONS SOUS Z/EVES

Soutenu le : 01 Avril 2014

Année Universitaire : 2006-2007

i

REMERCIEMENTS

A l’Eternel,

« J’ai planté, mais Dieu a fait croître. Car nous sommes ouvriers avec Dieu. Vous êtes le champ de Dieu, l’édifice de Dieu »

1Cor 3, 6 ; 9

Notre respectueuse considération pour :

M. ANDRIANARY Philippe, Directeur de l’Ecole Supérieure Polytechnique

d’Antananarivo

Malgré vos maintes obligations, vous nous avez fait l’immense honneur de nous accueillir au sein de l’ESPA . Veuillez accéder à l’expression de nos sincères remerciements

Nos vifs remerciements à :

M. RASTEFANO Elisée, Président du Jury

M. RAKOTOMIRAHO Soloniaina, examinateur et membre du jury

M. RATSIMBA Mamy, examinateur et membre du jury

M. ANDRIAMIASY Zidora, examinateur et membre du jufy

Vous nous avez fait l’honneur de résider parmi les membres du jury de ce mémoire. Veuillez recevoir la marque de notre ineffable considération

Nos remerciements les plus sincères à :

Mme RABEHERIMANANA Lyliane, rapporteur de ce travail

Veuillez, Madame, recevoir la marque de notre continuelle reconnaissance

Et :

Notre indicible reconnaissance pour tous les enseignants du Département

ELECTRONIQUE, pour l’effort que vous avez dispensé.

Que soient remerciés aussi, en tout premier lieu ma femme pour son soutien

indéfectible et inébranlable, toute ma famille d’avoir été toujours présente et en

derniers mais non les moindres mes amis et collègues.

Résumé

Ce travail de mémoire traite des méthodes formelles. Pour faire court, les méthodesformelles sont des techniques basées sur les mathématiques et pouvant être utilisées àtoutes les étapes du développement logiciel. Par formelles, on désigne des méthodes dontle but principal est de rendre précises des idées de développement auparavant vagues ousimplement intuitives. Contrairement à d’autres méthodes de design, les méthodes for-melles se basent sur les preuves mathématiques pour assurer un comportement correct.A la mesure où les systèmes deviennent de plus en plus complexes, et la sécurité unequestion de plus en plus importante, les approches formelles offrent alors un autre niveaud’assurance. Les méthodes formelles diffèrent d’autres systèmes de conception par l’utili-sation d’une vérification formelle, c’est-à-dire que les principes de base du système doiventêtre correctement prouvés avant qu’ils soient admis. Dans le cadre de ce mémoire, cettevérification formelle est effectuée par l’outils Z/EVES. La démarche adoptée a été en effetde concevoir un modèle formel d’un noyau (kernel en anglais) d’un système d’exploitationet ensuite de vérifier que le modèle est consistent et qu’aucune erreur n’a été introduite.

ii

Table des matières

Remerciements i

Résumé ii

Listes diverses v

Introduction 1

1 Aperçu sur les applications des méthodes formelles 21.1 Approches générales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Référentiel normatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3.1 Domaine aéronautique . . . . . . . . . . . . . . . . . . . . . . . . . 71.3.2 Domaine spatial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3.3 Domaine ferroviaire . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3.4 Domaine automobile . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3.5 Domaine nucléaire . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.4 Utilisation actuelle et tendance . . . . . . . . . . . . . . . . . . . . . . . . 91.4.1 Analyse des données . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Notions de base du langage Z 142.1 Logique propositionnelle et logique des prédicats . . . . . . . . . . . . . . . 14

2.1.1 Logique propositionnelle . . . . . . . . . . . . . . . . . . . . . . . . 142.1.2 Logique des prédicats . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Théorie des ensembles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.1 Rappel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.2 Extension Z de la théorie des ensembles . . . . . . . . . . . . . . . . 17

2.3 Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3.1 Notions générales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3.2 Fonctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4 Schémas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.4.1 Taxonomie et morphologie des schémas . . . . . . . . . . . . . . . . 22

iii

2.4.2 Notation des schémas . . . . . . . . . . . . . . . . . . . . . . . . . . 222.4.3 Interaction des schémas . . . . . . . . . . . . . . . . . . . . . . . . 232.4.4 Aide à la présentation . . . . . . . . . . . . . . . . . . . . . . . . . 232.4.5 Schémas génériques . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.5 Object-Z . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 Modélisation formelle du noyau 263.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2 Types primaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.1 Processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2.2 Registres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.3 Interruption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3 Abstractions nécessaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.4 Gestion des priorités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.5 Processus courant et processus prêts . . . . . . . . . . . . . . . . . . . . . 393.6 Messages et sémaphores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4 Preuves automatiques du modèle en utilisant Z/EVES 454.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2 Expansion d’un schéma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.3 Vérification de la syntaxe et de la cohérence des types . . . . . . . . . . . . 474.4 Analyse de l’application des fonctions dans leur domaine . . . . . . . . . . 494.5 Vérification des conditions initiales . . . . . . . . . . . . . . . . . . . . . . 514.6 Théorème des préconditions . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Conclusion 56

Annexes 58Annexe 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Annexe 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

iv

AECB Atomic Energy Control Board of Canada

AMDEC Analyse des Modes de Défaillance, de leurs Effets et de leurs Criticités

ASIC Application Specific Integrated Circuit

ASIL Automotive Safety Integrity Level

ASM Abstract States Machine

CASE Computer Aided Software Engineering

CEI Commission Electrotechnique Internationale

CENELEC Comité Européen de Normalisation Electrotechnique

CICS Customer Information Control System

CNS/ATM Communication Navigation Surveillance/ Air Traffic Management

DFCS Digital Flight Control System

ECSS European Cooperation for Space Standardization

ESA European Space Agency

FAA Federal Aviation Authority

FAR Federal Aviation Regulations

FMDS Fiabilité, Maintenabilité, Disponibilité et Sûrété

FPGA Field Programmable Gate Array

IBM International Business Machine

ISO International Standard Organisation

JAA Joint Aviation Authorities

JAR Joint Aviation Requirement

KLOC Kilo Lines Of Code

MATRA Mécanique Aviation TRAction

MGS Multinet Gateway System

MISRA The Motor Insdustry Software Reliability Association

NASA National Aeronautics And Space Administration

PSS Product Assurance and Safety Standard

RATP Régie Autonome des Transports Parisiens

SACEM Système d’Aide à la Conduite, à l’Exploitation et à la Maintenance

SIL Safety Integrity Level

SSIL Software Safety Integrity Level

STP Shostak’s Theorem Prover

VDM Vienna Development Methods

Liste des symboles et notationsspéciaux

Symboles SignificationsZ Ensemble des entiersN Entiers naturels¬ Négation∧ Conjonction∨ Disjonction⇒ Implication⇔ Équivalence∅ Ensemble videP Ensemble des partiesF Ensemble des parties finies∪ Union∩ Intersection⊂ Inclusion⊆ Inclusion ou équivalencen ′ Variable n dans son état

final (modifiée par affecta-tion)

n? Variable paramètre d’entréedu schéma, dans son étatinitial

n! Variable paramètre de sor-tie du schéma, dans son étatfinal

∆n Préfixe équivalent à la dé-claration de n et n ′

Ξn Préfixe équivalent à la dé-claration n ′ = n

Symboles Significations↔ Relation→ Fonction totale7→ Fonction partielle� Fonction totale injective7� Fonction partielle injective→→ Fonction totale surjective7→→ Fonction partielle surjective�→ Fonction bijective7 7→ Fonction finie7 7� Fonction finie injective

x 7→ y Couple (x , y)pre Préconditions d’un schémadom Domaineran Ensemble image

o9 Composition de fonctionC Restriction de domaineB Restriction d’image−C Soustraction de domaine−B Soustraction d’imageR∼ Relation inverse⊕ Combinaison des fonctionsa Concaténation

head s Premier élément de slast s Dernier élément de stail s Tous éléments de s sauf le

premier

vii

Liste des figures

1.1 Domaine d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2 Types d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3 Dates de début des projets . . . . . . . . . . . . . . . . . . . . . . . . 111.4 Taille des projets en nombre de lignes de code . . . . . . . . . . . . 121.5 Techniques utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.6 Impacts des méthodes formelles sur le temps, coût et la qualité . 12

3.1 Définition de NullProcRef et IdleProcRef . . . . . . . . . . . . . . . 283.2 Définition de maxreg et GENREG . . . . . . . . . . . . . . . . . . . . 293.3 Définition de GENREGSET . . . . . . . . . . . . . . . . . . . . . . . . 293.4 Définition de ProcessQueue . . . . . . . . . . . . . . . . . . . . . . . . 313.5 Définition de QUEUE[X] . . . . . . . . . . . . . . . . . . . . . . . . . . 323.6 Définition de Lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.7 Définition de ProcessTable . . . . . . . . . . . . . . . . . . . . . . . . . 353.8 Définition de PROCPRIOQUEUE . . . . . . . . . . . . . . . . . . . . 373.9 Définition de Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.10 Définition de Mailbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.11 Définition de SemaphoreTable . . . . . . . . . . . . . . . . . . . . . . . 44

viii

Liste des tableaux

I Historique des publications majeures . . . . . . . . . . . . . . . . . . 5II Tableau comparatif des niveaux de sécurité d’un logiciel . . . . . . 6

III Opérations exportées par Scheduler . . . . . . . . . . . . . . . . . . . 39

ix

Liste des listings

1 Expansion de schéma effectué par Z/EVES . . . . . . . . . . . . . . 472 Exemple de spécification écrite en Z/LATEX . . . . . . . . . . . . . 473 Message d’erreur affiché par Z/EVES pour une erreur de syntaxe 494 Message d’erreur affiché par Z/EVES pour une erreur de type . . 495 Théorème $domainCheck généré automatiquement par Z/EVES . 506 Paragraphe zproof de Z/EVES . . . . . . . . . . . . . . . . . . . . . . 507 Exécution de la commande de preuve par Z/EVES . . . . . . . . . 518 Théorème d’initialisation de ProcessQueue . . . . . . . . . . . . . . 529 Commande Z/EVES pour prouver InitialisationProcessQueue . . 5210 Preuve Z/EVES du théorème d’initialisation de ProcessQueue . . 5311 Théorème des préconditions et paragraphe zproof . . . . . . . . . . 5412 Preuve Z/EVES du théorème des préconditions . . . . . . . . . . . 54

x

Introduction

Les applications industrielles, englobant les applications du domaine de l’IntelligenceArtificielle, disposent habituellement d’une documentation dense et, parfois, massive. Tou-tefois leur comportement s’avère éventuellement imprédictible et quelquefois surprenant.La programmation est, en soi, une tâche difficile du fait que, d’une part, le programmeurest obligé de réduire un problème du monde réel à un ensemble de règles qu’un calculateurpeut exécuter aveuglement. Et d’autre part, chaque composant, chaque module interagitentre eux créant ainsi des propriétés indésirables. Le résultat est qu’ensuite les besoinspremiers ne sont pas satisfaits. D’ailleurs il est difficile de prévoir et d’anticiper de tellesinteractions, tout comme il est délicat d’intégrer, de façon sûre, des nouvelles fonctionna-lités. Aussi, des erreurs de conception peuvent ne pas être découvertes que trop tard, lesrendant chères ou même impossible à corriger. Des praticiens dans l’industrie soutenuspar des chercheurs sont convaincus qu’actuellement le meilleur moyen de relever ces défisest d’avoir recours aux méthodes formelles. Et ceci est d’autant plus vrai surtout en cequi concerne la conception et mise en production des systèmes dits critiques.

Les méthodes formelles constituent une technique utilisée pour la modélisation dessystèmes en se basant sur les mathématiques. En réalisant un modèle mathématiquementrigoureux d’un système, il est possible de vérifier les propriétés du système d’une manièreplus complète. Ce travail de mémoire est axé là-dessus. Il s’intitule « Modélisationformelle d’un noyau pour système d’exploitation embarqué et vérification sousZ/EVES » . Nous avons choisi un modèle formel d’un noyau pour système d’exploitationembarqué, vu l’importance que revêtent actuellement ces systèmes dits embarqués.

Pour ce faire, ce rapport de mémoire comportera quatre parties. Le premier cha-pitre sera consacré à une présentation de l’état de l’art des applications des méthodesformelles.Dans le second chapitre, nous présenterons la notation Z et quelques notionsfondamentales nécessaire à la compréhension du modèle. Le troisième chapitre sera dédiéeà l’édification du modèle proprement dit. Et enfin au quatrième chapitre, nous utiliseronsZ/EVES pour les vérifications des théorèmes applicables à notre modèle.

1

Chapitre 1

Aperçu sur les applications desméthodes formelles

Ce chapitre abordera en premier lieu les principes généraux et utilisations faites desméthodes formelles. Il sera présenté ensuite un historique des principales publications quiont été déjà effectuées à ce sujet. Une présentation succincte du référentiel normatif relatifau développement des systèmes dits critiques sera aussi donnée. Et à la fin du chapitre,nous exposerons les tendances actuelles en termes d’applications des méthodes formelles.

1.1 Approches générales

Les méthodes formelles sont des techniques, basées sur les mathématiques, pouvantêtre utilisées à toutes les étapes du développement logiciel. Par formelles, on désigne desméthodes dont le but principal est de rendre précises des idées de développement aupara-vant vagues ou simplement intuitives [1]. Contrairement à d’autres méthodes de design,les méthodes formelles se basent sur les preuves mathématiques pour assurer un compor-tement correct. A la mesure où les systèmes deviennent de plus en plus complexes, et lasécurité une question de plus en plus importante, les approches formelles offrent un autreniveau d’assurance. Les méthodes formelles diffèrent d’autres systèmes de conception parl’utilisation d’une vérification formelle, c’est-à-dire que les principes de base du systèmedoivent être correctement prouvés avant qu’ils soient admis. Les méthodes de conceptiontraditionnelles utilisent des tests intensifs pour vérifier le comportement des systèmes,mais les tests ne peuvent aboutir qu’à des conclusions limitées. Notons en effet que lestests révèlent seulement où le système n’échouera pas, mais ils ne peuvent décrire en au-cun cas le comportement du système en dehors du scénario d’essai. En revanche, du pointde vue formel, une fois qu’un théorème est prouvé être vrai, il reste vrai. Toutefois, il està souligner que la vérification formelle n’obvie pas au besoin d’essai. Dans plusieurs cas,des ingénieurs ont rapportés des défauts dans leur système une fois après ils passaient en

2

revue, d’une manière formelle, leurs conceptions. D’une façon générale, une conceptionbasée sur les méthodes formelles peut être subdivisée en trois étapes :

1. Spécification formelle : Phase durant laquelle on définit rigoureusement un sys-tème en utilisant un langage de modélisation. Ce dernier permet de modéliser unestructure complexe à partir de règles et de types prédéfinis. Cette phase consiste àconvertir les spécifications informelles en notation algébrique.

2. Vérification : Comme souligné ci-dessus, les méthodes formelles diffèrent des autressystèmes de spécification de par leur emphase sur les preuves et l’exactitude. Uningénieur spécifiant un système par les méthodes formelles développe en fait un en-semble de théorème concernant son système. En prouvant que ces théorèmes sontcorrects, il démontre que son système est exempt de défaut. La phase de vérificationest un processus long et difficile. Même les plus simples des systèmes disposent en ef-fet de plusieurs théorèmes, dont chacun doit être prouvé. Vu aussi que même les plusbasiques des preuves mathématiques sont quelquefois complexes, les systèmes for-mels utilisent des outils automatisés comme moyen d’assistance à la démonstrationpreuves.

3. Implémentation : Une fois qu’un modèle est spécifié et prouvé, il est alors mise enoeuvre. La spécification précédemment définie est converti code.

Il faut savoir en effet que la rigueur mathématique peut être utilisée à tous les stadesdu cycle de développement : analyse des besoins, spécification, conception architecturale,conception détaillée, implémentation, test et maintenance.

La première étape essentielle dans un processus de développement d’application dehaute qualité est l’analyse des besoins. Les méthodes formelles peuvent êtres utiles si onveut rendre l’expression des besoins explicite, claire et précise. Les outils dont ces méthodesdisposent peuvent être utilisés pour la vérification de la complétude, de la traçabilité, dela vérifiabilité et de la réutilisabilité des documents d’analyse (de besoin).

Comme déjà introduit ci-dessus, les méthodes formelles sont utilisées pour la spéci-fication logiciel, en élaborant des comportements précis non ambigus tout en évitant lesdétails et contraintes sur la façon suivant laquelle le logiciel doit être implémenté. ASM(Abstract States Machine), VDM (Vienna Development Methods), la méthode B et lanotation Z en constituent des exemples concrets.

Les systèmes complexes requièrent une organisation soigneuse de leur structure ar-chitecturale. Un modèle du système, supprimant tous détails d’implémentation, permetà l’architecte développeur de se concentrer sur les analyses et décisions les plus crucialesconcernant la structure du système. Le but reste évidemment de pouvoir toujours mieuxrépondre aux exigences imposées. WRIGHT est un exemple de langage de description ar-chitecturale utilisable dans ce domaine. Il est basé sur la formalisation du comportement

3

abstrait des composants architecturaux et de leurs connecteurs.

Les méthodes formelles se retrouvent aussi à l’étape de conception par l’utilisationdes techniques de raffinement. Plusieurs auteurs et chercheurs ont mis en évidence le rôlecentral de ce genre de techniques : Hoare C. en 1972, Jones C. B. en 1990 en introduisantVDM, Dijkstra E. W. en 1975 et MORGAN C. en 1988 pour aboutir aux principes descalculs de raffinement.

Durant le stade d’implémentation, les méthodes formelles peuvent être utilisées commemoyen de vérification. Chaque association programme-spécification suppose implicitementl’existence d’un théorème formulant que si certaines conditions sont satisfaites, le pro-gramme aboutira aux résultats attendus et décrits par sa documentation. La vérificationdont il est question est une tentative de preuve de ce théorème, ou du moins une argu-mentation des causes de l’échec de ce théorème. La méthode dite d’assertion inductive aété introduite par Floyd R. et Hoare C. vers la fin des années soixante. Cette méthodeconsiste à introduire des assertions mathématiques au sein du programme, et ensuite decontrôler la véracité de ces assertions au fur et à mesure de l’exécution du programme. Ducode peut être aussi généré automatiquement à partir d’un modèle formel, B et SCADEen sont des exemples [1], [2].

Les méthodes formelles peuvent encore être utilisées durant la phase de test. GaudelM.-C. en démontre la faisabilité dans la référence [3]. Dans la référence [4], Hoare C.décrit l’emploi des assertions formelles, non pas à fin de preuve, mais pour dans le butd’effectuer des tests. Hierons et al. [5] effectuent un plus large inventaire de ce qui se faitactuellement quant à l’utilisation des méthodes formelles à fin de tests.

Des exemples d’applications des méthodes formelles sont données à l’Annexe 1.

Dans ce qui suit, le référentiel normatif en vigueur cadrant la réalisation d’un sys-tème critique sera d’abord exposé. Ensuite, une évaluation de la situation actuelle dansl’application industrielle des méthodes formelles sera faite, ceci en se concentrant sur leurutilisation croissante dans les premières phases du cycle de développement (spécificationet conception).

1.2 Historique

Cette section présente au tableau I un historique des publications majeures de cestrois dernières décennies. En effet, la mise en oeuvre des méthodes formelles dans des ap-plications industrielles a pris des dizaines d’années. Une condition à laquelle les chercheurset les praticiens doivent satisfaire est que les potentiels qu’offrent les méthodes formellesdoivent être atteints à des coûts raisonnables en respectant les contraintes réelles imposéespar l’industrie. Dès le début des années 90, question est posée si les méthodes formelles

4

sont réellement viable pour l’industrie.

Année Considérations1990 HALL A. dans la référence [6] en considérant les méthodes formelles comme

une approche pouvant être appliquée dans l’ingénierie logiciel, a identifié sept"mythes"

1990 WING J. M. a exposé les concepts et principes fondamentaux des méthodesformelles[7]

1992 Dans la référence [8], BOWEN J. a présenté des preuves quant à la rentabilitéde l’utilisation des méthodes formelles dans des applications industrielles

1993 AUSTIN S. a conduit une étude [9] sur l’utilisation des méthodes formellesdans des applications industrielles, ceci afin de révéler les raisons du faibletaux d’utilisation de ces méthodes dans le domaine de l’industrie. AUSTIN S.a utilisé des questionnaires pour évaluer les utilisations faites de ces méthodesdans la recherche et l’application, et pour sonder l’opinion en ce qui concernela barrière à une adoption plus large des méthodes formelles. Une majorité desréponses analysées (126) a indiqué que ces dernières ont été plutôt utilisées enphase de spécification qu’en phase de vérification

1993 CRAIGEN D. et ses collègues ont conduit une étude [10] couvrant 12 cas,chacun basé sur une application des techniques formelles dans un environne-ment industriel. Une combinaison de questionnaire, de revues de littératureet d’entrevue a été utilisé. L’étude est arrivée aux conclusions positives en cequi concerne la maturité des méthodes formelles et du fait qu’elles avaient étéappliquées à des systèmes critiques.

1993 RUSHBY J. a écrit un rapport technique pour la NASA, expliquant aux concer-nés, ce que sont les méthodes formelles et comment elles peuvent être appli-quées dans le développement et la certification des systèmes critiques [11]

1995 Toujours dans ce cadre, BOWEN J. et HINCHEY M. G. ont sorti un livre [12]contenant une collection de 15 différentes applications des méthodes formelles.

1996 Malgré les conclusions optimistes de quelques études, GLASS R. L. dans laréférence [13], a souligné qu’une divergence d’opinion subsistait entre acadé-micien voyant les méthodes formelles comme « inévitable »et les praticiens lesconsidérant comme un « luxe ».

1999 Une étude plus étendue effectuée par BLOOMFIELD R. [14] inclut des évalua-tions des programmes de recherche, des importantes conférences et des appli-cations des techniques formelles dans l’industrie. Un point principal soulignépar cette étude est que, même si les méthodes formelles ont déjà trouvé leurplace dans les applications critiques, leur adoption générale reste encore unbut à atteindre.

2006 Similairement à ce qu’a écrit Hall en 1990, BOWEN J. et HINCHEY M. G.ont édicté, dans la référence [15], les règles à appliquer pour une utilisationefficiente des méthodes formelles

Tableau I: Historique des publications majeures

Il faut conclure en effet que les études présentées dans cette section ont chacune leurpoint de vue. Certains, comme Craigen, basent leur analyse sur un groupe d’applicationsbien défini. D’autres, tel qu’Austin, ont une vision plus élargie du domaine industriel et du

5

milieu académique. Malgré les différences dans l’approche, il y a quand même un certainaccord sur les défis restant à relever pour une adoption industrielle généralisée réussie.

1.3 Référentiel normatif

Dans le cadre de cette section, nous allons proposer un tour d’horizon de l’aspectnormatif et réglementaire qui contraint la réalisation d’un système dit critique. La réa-lisation d’un système critique doit prendre en compte des exigences liées à la sûreté defonctionnement. Cette notion de sûreté de fonctionnement peut être définie comme laqualité du service délivré par un système, qualité telle que les utilisateurs de ce servicepuissent placer une confiance justifiée dans le système qui le délivre.

Niveau de sécurité. La mise en place d’un ensemble activités liées à la sûreté defonctionnement vise à maîtriser les défaillances induites par les logiciels. Les défaillancesde systèmes à base de logiciel peuvent être dues à deux causes :

• Les défauts systématiques : ce sont des défauts qui ont été introduits lors dela réalisation de l’application logiciel ;• Les défauts aléatoires : ce sont des défauts induits par la(les) défaillance(s) des

équipements supports de l’application logiciel (processeur, mémoire, disquedur, . . .).

Il n’est pas possible de quantifier a priori le nombre de défauts systématiques présentsdans une application logiciel, c’est pourquoi les différentes normes présentées ci-dessousproposent la notion de Niveau de sécurité logiciel. Cette notion est associée à une échellede valeur. Cette échelle de valeur est calquée sur l’ordre de grandeur de l’impact d’unedéfaillance sur le système.

La norme CEI 61508 introduite aux sections suivantes, présente la notion de SIL(Safety Integrated Level). Le SIL est alors un niveau de sécurité requis pour la partieprogrammable d’un système. Le tableau II répertorie les niveaux de sécurité pour chaquenorme.

DO-278 DO-178 (Level) CEI 61508 (SIL) EN 50128 (SSIL) ISO 26262 (ASIL)AL1 A 4 4 -AL2 B 3 3 D- - (3) - C

AL3 C 2 2 BAL4 - - - -AL5 D 1 1 AAL6 E - 0 -

Tableau II: Tableau comparatif des niveaux de sécurité d’un logiciel

6

Chaque domaine d’activité dispose de leur propre référentiel.

1.3.1 Domaine aéronautique

Le domaine du transport aérien a été l’un des premiers à mettre en place un référentielnormatif qui couvre l’ensemble de la réalisation d’un système. Ce référentiel prend encompte les aspects sûreté de fonctionnement.

Tout avion fait l’objet d’une certification. Cette certification vise a démontrer quele système est conforme à la réglementation en vigueur. Cette réglementation impose lerespect d’un référentiel.

Ce référentiel est actuellement composé :• Pour les applications de type avion : de la norme DO-178, intitulé "Software

considerations in airborne systems and equipement certification", pour les as-pects développement logiciel, d’un référentiel métier constitué d’un ensemblede règlements FAR3/JAR4 qui sont applicables à tous les avionneurs et d’unensemble de guides méthodologiques produits par la communauté aéronau-tique• Pour les applications au sol : de la norme DO-278 ("Guidelines for commu-

nication, navigation, surveillance, and Air traffic management (CNS/ATM)Systems software integrity assurance")

La norme DO-178 a été révisée en 2009. Cette révision vise à introduire : les mé-thodes formelles, les nouvelles techniques de vérification du logiciel tel l’interprétationabstraite de programme et les aspects orienté objet.

Le JAA (Joint Aviation Authorities), organisme regroupant les autorités réglemen-taires d’un certain nombre de pays, étudie et rédige des règles communes, dites codesJAR (Joint Aviation Requirement), dans les domaines de la sécurité et de l’exploitationdes aéronefs. Chaque pays adhérent au JAA s’engage à introduire les JAR dans sa propreréglementation (ce qui leur donne force de loi) avec les seules adaptations nécessaires aurespect de son droit national.

Ce référentiel a été récemment complété par la norme DO-254 ("Electronique hard-ware - design assurance guidance for airborne electronic hardware") qui s’applique auxaspects composants numériques tels que les FPGA et autres ASIC. Cette famille de com-posants remplace une partie logicielle et matérielle par un circuit intégré. La problématiqueengendrée est liée au fait qu’il est difficile de vérifier et de valider le comportement deces circuits et que de part leurs natures (logiciel et matériel), il est difficile de démontrerl’absence de faute de conception.

7

1.3.2 Domaine spatial

Dans le domaine de l’aérospatial, les méthodes utilisées ne font pas spécifiquementl’objet de normes. Cependant, le client peut imposer des standards, comme des procéduresde l’ESA (European Space Agency) pour la réalisation d’un système destiné à l’espace.L’ESA a publié un PSS (Product assurance and Safety Standards). Celui-ci fournit unedémarche générale de sécurité et, par exemple, la façon de réaliser une Analyse des Modesde Défaillance, de leurs Effets et de leur Criticité : AMDEC. Ce standard est écrit parl’ESA et un groupe de travail a été formé afin d’améliorer les PSS pour fournir un référen-tiel avalisé par les industriels (ECSS : European Cooperation for Space Standardization).Sous réserve d’une demande expresse des industriels, la norme DO-254 reste applicabledans ce domaine.

1.3.3 Domaine ferroviaire

Depuis la fin des années 90, le domaine ferroviaire s’est doté d’un référentiel normatifcomposé de plusieurs normes. Il est composé des normes CENELEC suivantes :

• EN 50126 : Applications ferroviaires - spécification et démonstration de lafiabilité, de la disponibilité, de la maintenabilité et de la sécurité (FMDS)(Janvier 2000)• EN 50128 : Applications ferroviaires - systèmes de signalisation, de télécom-

munications et de traitement logiciels pour systèmes de commande et de pro-tection ferroviaire (Juillet 2001)• EN 50129 : Applications ferroviaires - systèmes de signalisation, de télécom-

munications et de traitement systèmes électroniques de sécurité pour la signa-lisation (Mai 2003).

La norme EN 50126 décrit les exigences de sûreté de fonctionnement applicables auxsystèmes ferroviaires. Les normes EN 50129 (description du contenu du dossier de sécurité)et EN 50128 (exigences liées au développement de systèmes électroniques programmables)sont applicables au sous-système Signalisation.

Le référentiel CENELEC est directement inspiré de la norme CEI 61508 ("Sécuritéfonctionnelle des systèmes électriques/électroniques/électroniques programmables relatifsà la sécurité") qui vise à définir les exigences de sûreté de fonctionnement applicables auxsystèmes à base d’équipements électriques, électroniques et électroniques programmables.

8

1.3.4 Domaine automobile

Bien que le domaine automobile ne dispose pas d’un référentiel applicable, des obli-gations ont été mise en oeuvre pour le développement des logiciels au travers le référentielThe Motor Insdustry Software Reliability Association (MISRA). Un document faisantpartie de ce référentiel est par exemple le guide publié en Novembre 2004 et est intitulé"Guidelines for the Use of the Use of C language in Critical System".

En outre, depuis 2005, le domaine automobile a commencé à rédiger une déclinaisonde la CEI 61508 nommée ISO 26262 ("Road Vehicles - Functional Safety"). Ce documentest devenu applicable depuis 2010.

1.3.5 Domaine nucléaire

La norme CEI 880 ("Logiciel pour les calculateurs utilisés dans les systèmes de sûretédes centrales nucléaires") publié en 1986 par la Commission Electrotechnique Internatio-nale décrit les mesures à mettre en oeuvre pour réaliser un logiciel pour les calculateursutilisés dans les centrales nucléaires.

1.4 Utilisation actuelle et tendance

Les résultats présentés dans cette section ont été tirés d’une enquête réalisée entreNovembre 2007 et Décembre 2008 [16]. Les données ont été collectées sur 62 projetsindustriels issus de la littérature et des listes de diffusion (mailing lists) connus pouravoir utilisé des techniques formelles. Les projets étudiés ont pour origine (dans l’ordredécroissant) l’Europe, l’Amérique du Nord, l’Amérique latine, l’Australie et l’Asie. Forceest de constater en effet l’absence de l’Afrique, y compris Madagascar, dans ce domaine.

1.4.1 Analyse des données

La figure 1.1 présente la ventilation par domaine d’application des projets.

Le secteur du transport constitue un domaine où les techniques formelles sont trèssollicités, et ceci suivi du secteur de la finance. Les autres secteurs étant la défense, lestélécommunications et l’administration. Quelques projets émanaient des domaines du nu-cléaire, de la santé, de l’électronique grand public, du spatial, du web sémantique, duplanning de ressource, du parking automatique, de l’embarqué et de la manufacture. En-viron 20% des projets ont trait avec le développement d’outils logiciel comme les compila-teurs, systèmes d’exploitation, CASE (Computer Aided Software Engineering) et 10% ont

9

Figure 1.1: Domaine d’application

rapport directement à une application informatique du domaine concerné (calcul hauteperformance, optimisation du code à l’exécution, réplication de système de fichier, contrôled’accès, protocole de communication et conception de micro-ordinateur).

La figure 1.2 présente les types d’applications inventoriées par l’enquête.

Figure 1.2: Types d’application

Par ordre décroissant, les types d’applications où les méthodes formelles sont les plusutilisées sont : les applications temps réel, les applications distribuées, les applications

10

transactionnelles et le traitement de gros volume de données. Les autres applications étantles systèmes parallèles, la conception hardware, la contrôle-commande, l’interface homme-machine, les applications orientées service et, pour finir, le traitement d’images. Environ30% des projets ont respecté les normes de certification, notamment la CEI 61508 ("Sé-curité fonctionnelle des systèmes électriques/électroniques/électroniques programmablesrelatifs à la sécurité")de la Commission Électrotechnique Internationale. Les autres tenantcompte du CENELEC EN 50128 pour le domaine ferroviaire et du DO-178B Level A pourl’avionique.

La figure 1.3 répertorie les dates de début des projets étudiés.

Figure 1.3: Dates de début des projets

La figure 1.4 donne une indication sur les tailles des projets sondés. La répartitionreste plutôt équitable entre les trois tranches 1-10 KLOC, 10-100 KLOC et 100-1000KLOC.

Et enfin, la figure 1.5 présente le départage des différentes techniques utilisées : spé-cification, modélisation, exécution (test), inspection (d’une spécification ou d’un modèle).

1.4.2 Résultats

La figure 1.6 montre les impacts issus de l’utilisation des méthodes formelles sur lesparamètres temps, coût et qualité.

Dans l’ensemble, l’effet sur le temps de développement est plutôt positif. Plusieursprojets ont rapporté une réduction globale du temps de développement et du coût. Ceciest dû principalement à l’utilisation d’outils pouvant généré automatiquement du code àpartir de la spécification.

11

Figure 1.4: Taille des projets en nombre de lignes de code

Figure 1.5: Techniques utilisées

Figure 1.6: Impacts des méthodes formelles sur le temps, coût et la qualité

Par contre, presque tous les projets (92%) ont confirmé une amélioration nette de laqualité du produit final. Aucun des projets n’a rapporté une dégradation de la qualité.Les principales raisons avancées sont une amélioration au niveau de la conception (12%),

12

une confiance accrue dans le produit final (10%), une compréhension améliorée du projet(10%), et une identification tôt des erreurs (4%).

Pour conclure, la plupart des gestionnaires de projets sur lesquels l’étude a été axée,ont été généralement satisfaits de l’utilisation des méthodes formelles. Cette étude a mon-tré aussi l’utilisation de plus en plus des techniques formelles parmi une variété d’ap-plications, dont une partie considérable ayant trait au développement d’outils logicieleux-mêmes.

Conclusion

Dans le cadre de ce premier chapitre, nous avons présenté les principes généraux desméthodes formelles et leurs applications. Une revue de la littérature a été aussi effectuée.Dans le chapitre suivant, un langage, utilisé spécifiquement en méthodes formelle, seraétudié.

13

Chapitre 2

Notions de base du langage Z

Le langage Z est basé sur les logiques mathématiques et la théorie des ensembles. Celangage, communément appelé aussi notation Z, a été inventé par Jean-Raymond Abrialet a été développée ensuite par Hayes, Morgan, Spivey, Sufrin et bien d’autres [17]. Aupoint de vue sémantique, Z peut être subdivisé en trois parties :

1. Un langage mathématique utilisant propositions, logique prédicative, ensembles etrelations.

2. Un langage schématique représentant des manipulations algorithmiques de donnéesou des objets.

3. Une théorie de raffinement entre des types abstraits de données.

Ainsi, on parle souvent de Z comme d’un langage de description d’états (states descriptionlanguage) : en utilisant un dialecte mathématique particulier enchâssé dans une notationschématique, il décrit les différents états de données par lequel peut passer un produitlogiciel, et sous quelles conditions [18].

2.1 Logique propositionnelle et logique des prédicats

2.1.1 Logique propositionnelle

Une proposition est une expression qui est soit vraie, soit fausse. Les propositionspeuvent être combinées entre elles par des connecteurs logiques. La signification d’une tellecombinaison est déterminée par la signification des propositions impliquées. Ci-dessousquelques connecteurs des plus utilisés :

• Négation : ¬• Conjonction : ∧• Disjonction : ∨• Implication : ⇒• Equivalence : ⇔

14

a. Priorité des opérations

En Z, les connecteurs logiques ont une priorité d’opération qui diminue selon l’ordredu tableau précédent : la négation a la plus haute priorité, et l’équivalence la plusbasse. Ainsi, la proposition :

¬ p ∧ q ∨ r ⇔ q ⇒ p ∧ r

est équivalente à

(((¬ p) ∧ q) ∨ r)⇔ (q ⇒ (p ∧ r))

b. Propositions atomiques

Une proposition atomique est une proposition qui n’utilise pas de connecteurs lo-giques. En Z, une proposition atomique ne pourra affirmer (ou infirmer) que deuxchoses :

1. que deux éléments sont congrus ou que deux ensembles sont identiques. Il s’agitd’une extension Z de la notion d’égalité à la théorie des ensembles.

2. qu’un élément ou un ensemble maintient une certaine relation (via des opérateursrelationnels) avec d’autres éléments ou ensemble.

Ainsi, les propositions atomiques sont à la base de toutes les constructions ma-thématiques ultérieures en Z : même si elles en sont les éléments constitutifs, elleéchappent au langage en ce sens qu’elles prennent leur sens dans des cadres formelsextérieurs. Par exemple, la proposition atomique fausse « 3+3=8 » a un sens précisqui provient de l’arithmétique : elle n’en sera pas moins acceptée en Z.

2.1.2 Logique des prédicats

a. Prédicat

Un prédicat est une expression contenant des inconnues qui se transforme en propo-sition quand celles-ci sont identifiées. Par exemple, l’expression x>3 est un prédicatarithmétique pour tout x appartenant aux réels.

b. Déclaration

Une déclaration est nécessaire afin d’introduire les variables impliquées dans uneexpression pour connaitre sa valeur prédicative. En Z, on notera ainsi x :a le faitque la variable x sera forcément élément de l’ensemble a.

c. Quantification

Il s’agit d’une des opérations les plus importantes en Z. Soit p, un prédicat impli-quant la variable x, élément de a. On pourra retransformer ce prédicat en proposition

15

en appliquant un quantificateur Q à x. En Z, on notera :

Qx : a • p

Trois quantificateurs sont principalement utilisés en Z :• Quantificateur d’universalité :

∀ x : a • p

• Quantificateurs d’existence

∃ x : a • p

• Quantificateur d’unicité

∃1 x : a • p

d. Contraintes

Il est possible d’ajouter un prédicat r à la déclaration d’une proposition quantifiéepour restreindre le domaine d’une variable.

Qx : a | r • p

La variable x est restreinte aux éléments de a pour lesquels r est vrai.

e. Substitution

Il s’agit d’une facilité de Z permettant parfois d’alléger les notations. . On écrira :

p[t/x ]

pour représenter le prédicat qui résulte de la substitution par t de chaque occurrencelibre de x dans le prédicat p. Cette opération a une priorité plus haute que toutesles opérations logiques vues précédemment.

2.2 Théorie des ensembles

2.2.1 Rappel

Les objets mathématiques sont parfois vus comme des collections d’objets : un rec-tangle est, par exemple, une collection de points dans un plan ; une fonction est unecollection de tuplets. La théorie des ensembles est un des fondements de la notation Z etsa compréhension est une condition nécessaire à une bonne formalisation en Z.

16

a. Définition d’un ensemble

Un ensemble est une collection bien définie d’éléments.

b. Construction d’ensembles en Z

Il existe quatre façons de construire un ensemble en Z :

• Par extension : On se contente d’en faire la liste des éléments

{0, 1, 4, 9, 16}

• Par compréhension : De façon très similaire à la quantification de prédicats,on pourra définir un ensemble sous forme {D | P • E}, pour laquelle D seraune déclaration, P un prédicat dépendant de la déclaration qui définira unecontrainte sur celle-ci et E un expression définissant chacun des termes del’ensemble. Ainsi, l’ensemble précédent peut être réécrit comme suit :

{x ∈ N | x ≤ 4 • x 2}

• Par l’opérateur d’ensemble de puissance P : La notation PA désigne l’en-semble des sous-ensembles de A (incluant ∅, l’ensemble vide). Par exemple :

P{1, 2} = {∅, {1}, {2}, {1, 2}}

• Par produit cartésien : Le produit cartésien A × B désigne l’ensemble despaires ordonnées ayant comme premier membre un élément de A et commesecond membre un élément de B

{x , y} × {1, 2} = {{x , 1}, {x , 2}, {y , 1}, {y , 2}}

c. Appartenance à un ensemble

On écrit respectivement x ∈ A ou x 6∈ A pour affirmer que x est élément ou non del’ensemble A.

d. Inclusion d’ensembles

On écrire A ⊆ B pour affirmer que A est un sous-ensemble de B .

2.2.2 Extension Z de la théorie des ensembles

a. Les types.

Mathématiquement, on dit que les ensembles sont homogènes : ils représentent desvaleurs ayant des caractéristiques communes, souvent rattachées entre elles par unerègle d’inférence. Cette caractéristique qu’auront les éléments d’être de la mêmesorte constitue une importante notion du point de vue de la formalisation de pro-

17

duits logiciels, puisqu’elle cristallise l’idée intuitive des créateurs selon laquelle cer-tains membres d’un système auront des caractéristiques communes [19]. Ainsi ap-paraît naturellement la notion de type. En Z, un type est « un ensemble d’extensionmaximale, tout au moins dans les limites d’une spécification donnée »[18] . Ainsi,chaque élément, chaque objet x présent dans une spécification sera associé à un etun seul type : le plus grand ensemble A existant pour lequel x ∈ A.

b. Déclaration des types.

En Z, la déclaration d’ensembles « types »se fait habituellement de façon axioma-tique, selon une notation particulière, par l’énumération entre crochets carrés deceux-ci au début d’une spécification. Ainsi, la ligne suivante définit deux types,Books et Readers, utilisables par la suite dans une spécification quelconque :

[Books ,Readers ]

c. Abréviation.

Un « objet »e (élément, ensemble, etc) déjà défini dans une spécification formellepeut se voir attribuer un nom x par l’opération x == e. Cette notation est par-ticulièrement utile pour donner des définitions génériques. Ainsi, on nommera al’ensemble des carrées des nombres naturels inférieurs à cinq en écrivant :

a == {x ∈ N | x < 5 • x 2}

d. Types numériques.

L’ensemble des naturels N et des entiers Z sont des types prédéfinis en Z. Tel quementionné précédemment, l’ensemble des propositions atomiques de nature arithmé-tique que ces nombres permettent sont ainsi utilisables en Z : addition, soustraction,multiplication, division entière, reste modulo, puissance, plus petit que, plus grandque, égalité, etc.

2.3 Relations

2.3.1 Notions générales

a. Intérêt des relations

Le typage introduit précédemment, a pour utilité de regrouper un ensemble d’élé-ments ayant des caractéristiques communes. Cependant, il est évident qu’un produitlogiciel fait interagir une séries de composantes (données, objets) qui sont de typesdifférents. C’est là toute l’utilité des relations : modéliser la structure des interac-tions entre des composantes de différentes natures [19].

18

b. Définitions

Couple ordonné. Soit deux éléments distincts x et y . On appellera couple ordonne xvers y la paire ayant comme premier élément x (élément de départ) et comme dernierélément y (élément d’arrivée). On la notera x 7→ y ou encore (x , y).

Relation. Une relation est un ensemble de paires ordonnées telles que leurs élémentsde départ et d’arrivée font respectivement partie d’un même ensemble.

c. Notation Z des relations

Soit deux ensembles, X et Y . Toute relation R ayant X comme ensemble de départet Y comme ensemble d’arrivée sera telle que :

R : P(X × Y )

Par volonté de simplification, on utilise habituellement une notation différente quiaura exactement le même sens :

X ↔ Y == P(X × Y )

d. Domaine, image, relation inverse

Soit deux ensembles, X et Y , et la relation R : P(X × Y ). En Z, les ensemblessuivants sont définis :

domR == {x : X , y : Y | x 7→ y ∈ R • x}ranR == {x : X , y : Y | x 7→ y ∈ R • y}R∼ == {x : X , y : Y | x 7→ y ∈ R • y 7→ x}

e. Restrictions de domaine et d’image

Soit deux ensembles A et B , et les ensembles X , Y et R tels que définis précédem-ment. En Z, on définira :

AC R == {x : X , y : Y | x 7→ y ∈ R ∧ x ∈ A • x 7→ y}R B B == {x : X , y : Y | x 7→ y ∈ R ∧ y ∈ B • x 7→ y}

f. Soustraction de domaine et d’image

Soit les ensembles X , Y , R, A et B définis précédemment. En Z, les ensemblessuivant sont également définis :

A−C R == {x : X , y : Y | x 7→ y ∈ R ∧ x 6∈ A • x 7→ y}R −B B == {x : X , y : Y | x 7→ y ∈ R ∧ y 6∈ B • x 7→ y}

g. Image relationnelle

Avec, encore une fois, les ensembles X , Y , R et A, on définira :

19

R(| A |) == ran(AC R)

h. Composition

Soit trois ensembles X , Y et Z et deux relations R et S telles que R : X ↔ Y etS : Y ↔ Z . On définira en Z la composition par :

R o9 S == {x : X , z : Z | (∃ y : Y • (x 7→ y ∈ R ∧ y 7→ z ∈ S )) • x 7→ z}

i. Itération

Soit, encore une fois, la relation R : X ↔ Y . On définira récursivement :

Rk == R o9 Rk−1

avec R1 == R.

2.3.2 Fonctions

a. Quelques définitions

Une fonction est une relation telle que tous les éléments de l’ensemble de départsont impliqués dans au plus un couple ordonné de celle-ci.

Une fonction totale est une fonction pour laquelle le domaine correspond à l’en-semble de départ.

Une fonction partielle est une fonction pour laquelle le domaine est strictementinclus dans l’ensemble de départ.

Une fonction injective est une fonction pour laquelle à chaque élément du domainecorrespond un élément différent de l’image.

Une fonction surjective est une fonction pour laquelle l’image correspond à l’en-semble d’arrivée.

Une fonction bijective est une fonction à la fois injective et surjective.

Une fonction finie est une fonction dont le cardinal existe.

b. Notations spécifiques de déclaration

Les fonctions décrites précédemment sont symbolisées comme suit :

• → : fonction totale• 7→ : fonction partielle• � : fonction totale injective• 7� : fonction partielle injective• →→ : fonction totale surjective• 7→→ : fonction partielle surjective• �→ : fonction bijective

20

• 7 7→ : fonction finie• 7 7� : fonction finie injective

c. Déclaration de fonctions

En tant que relations (et donc en tant qu’ensembles), les fonctions profitent decertaines méthodes de construction précédemment énumérées (extension, compré-hension

Extension

{0 7→ 0, 1 7→ 1, 2 7→ 4, 3 7→ 9, 4 7→ 16}

Compréhension

{x : N | x ≤ 4 • x 7→ x 2}

Une autre forme de déclaration existe pour les fonction. Dénommée communémentabstraction lambda, il s’agit essentiellement d’un raccourci d’écriture de la déclara-tion en compréhension :

λ x : N | x ≤ 4 • x 2

d. Application d’une fonction

Soit une fonction f et x un élément tel que x ∈ dom f . On définira f (x ) en Z commel’élément y d’arrivée du couple ordonné tel que (x , y) ∈ f . Ainsi :

{x : N • x 2 7→ x}(9) = 3

e. Combinaison de fonctions

Soit deux ensembles X et Y ainsi que deux fonctions f et g telles que f : X 7→ Yetg : X 7→ Y . On définira :

f ⊕ g == g ∪ ((dom g)−C f )

2.4 Schémas

Le langage schématique de Z est utilisé pour composer et structurer une série dedescriptions mathématiques : il permet de grouper ensemble des informations (donnéesou opérations), de les encapsuler et de les nommer pour réemploi. Il ’agit de la secondecomposante de la notation Z, la première étant le langage mathématique vu précédem-ment.

Une spécification formelle en Z est composée de deux parties :

21

• Des déclarations globales : noms de types, d’ensembles, abréviations (équiva-lences syntaxiques et définitions génériques)• Un ou plusieurs (habituellement plusieurs) schémas.

2.4.1 Taxonomie et morphologie des schémas

Les schémas courants sont habituellement de deux sortes :

Orientés données : ils regroupent ou décrivent alors un ensemble de données. Ilsdonnent possiblement leur état initial.

Orientés opérations : ils donnent alors des manipulations abstraites des données dé-finies ailleurs, possiblement dans des schémas orientés données.

Le langage Z permet ainsi de décrire, à un niveau très abstrait (c’est-à-dire fortementdécouplé de toute implémentation logicielle), un produit logiciel sous une perspectiveformelle alignée sur l’information que celui-ci traite. En Z, tout s’articule en effet autoursdes données : le langage décrit formellement celles-ci, et la façon dont elles sont manipulées[20].

Un schéma est toujours composé de trois parties :

• Un nom qui identifie le schéma et ayant une portée globale sur la spécification.• Une partie déclarative (pouvant être vide) qui définit les différentes données

membres du schéma. Les données définies pour la première fois sont de portéelocale. Son contenu est appelée signature.• Une partie prédicative (pouvant être vide) qui énumère les contraintes que

doivent respecter les données accessibles dans la portée courante, localementou globalement.

Dans le cas de schémas « orientés opérations », la partie prédicative se termine habi-tuellement par des expressions qui ne sont pas des prédicats, mais plutôt des affectationsde certaines données membres (utilisant le symbole =). Par le cadre formel, il est à noterque chaque donnée ne pourra subir qu’une seule affectation dans un même schéma ; cesaffectations permettent de décrire les différentes opérations abstraites effectuée par cesschémas.

2.4.2 Notation des schémas

a. Notation horizontale

Cette notation n’est utilisée que pour des schémas de faible envergure, ou les contraintesseront séparées entre elles par le ET (∧) logique.

22

Nom du schma =̂ [Declarations | Contraintes et affectations ]

b. Notation verticale

Nom du schemaDeclarations

Contraintes et affectations

Un schéma peut aussi être dit « générique ». La représentation d’un tel schéma estdécrit aux sections suivantes.

2.4.3 Interaction des schémas

Tout l’intérêt des schémas est qu’ils peuvent être extensivement réutilisés à l’intérieurd’autres schémas d’une même spécification. Sans cette caractéristique, le langage schéma-tique serait tout bonnement inutile. La réutilisation de schémas par d’autres schémaspourra se faire :

• Dans une déclaration : seuls ou après des quantificateurs, dans une construc-tion d’ensemble en compréhension ou dans des expressions µ et λ.• Dans un prédicat : dans ce cas, seule la contrainte à un sens.• Dans une affectation : sous réserve de sens mathématique.

Certaines de ces réutilisations peuvent être relativement subtiles, mais on se conten-tera seulement de donner ici les deux grandes techniques de réutilisation dans les décla-rations :

• Par inclusion schématique. Quand le nom d’un schéma est inclus dans la partiedéclarative d’un autre, celui-ci est tout simplement ajouté au schéma courantpartie par partie : il faut utiliser ce procédé prudemment car il peut facilemententraîner des incohérences.• Par utilisation typée. Rien n’empêche de déclarer des membres d’un schéma

comme éléments d’un type schématique préalablement défini dans la mêmespécification : le membre représente alors une liaison particulière appartenantà ce type schématique.

2.4.4 Aide à la présentation

Décorations schématiques. Il est facile, quand on rédige des spécifications for-melles, d’atteindre rapidement l’illisibilité. Un mécanisme fournit par le langage schéma-

23

tique de Z pour alléger les écritures s’appelle la décoration des membres. La présence dedécorations dans un schéma indique la nature « orientée opération »de celui-ci.

Décorations post-fixées. Soit n un membre d’un schéma donné. On notera :• n : la variable dans son état initial• n ′ : la variable dans son état final (modifiée par affectation)• n? : la variable, paramètre d’entrée du schéma, dans son état initial• n! : la variable, paramètre de sortie du schéma, dans son état final

Décorations pré-fixées. Soit n un membre d’un schéma donné OU un schéma eninclusion dans un autre. On notera, dans sa partie déclarative seulement :

• ∆n : Notation Delta. Pour les membres, il s’agit d’un raccourci pour déclarern et n ′. Pour les schémas en inclusion, cette notation signifie que le schémaactuel modifie l’ancien : tous les membres n et n ′ de cet ancien schéma sontinclus.• Ξn : Notation Xi. Cette notation signifie que le membre ou le schéma en

inclusion n ne sera pas modifié.

2.4.5 Schémas génériques

Redénomination. A l’instar des prédicats, un schéma Z peut subir la substitution devariables. Soit un schéma Schema ayant x pour membre. Il nous sera possible de construireun nouveau schéma strictement identique pour lequel y remplacera x en écrivant :

Schema[y/x ]

On nomme cette opération redénomination.

Schémas génériques. Une façon plus transparente et élégante de gérer la redéno-mination est la rédaction de schémas génériques. De tels schémas sont identiques à desschémas standards, à ceci près que leur nom est complété (ou remplacé) par une séquenced’identificateurs entre crochets carrés, et qu’ils débutent sur un trait double plutôt quesimple. Ils sont représentés comme suit :

[PARAM ]Declarations

Contraintes et affectations

Les schémas génériques non nommés sont spécialement intéressants car ils permettentde définir de nouveaux opérateurs en Z, et ils offrent ainsi une alternative puissanteau processus d’abréviation déjà présenté. Ils utilisent, en plus des caractéristiques déjà

24

énumérées des schémas génériques, une notation déclarative particulière utilisant la barrede soulignement.

[X ,Y ]C : PX × (X ↔ Y )→ (X ↔ Y )

∀ S : PX ,R : X ↔ Y •S C R = {x : X , y : Y | ((x ∈ S ) ∧ (x 7→ y ∈ R)) • x 7→ y}

2.5 Object-Z

Object-Z est une dérivation de la notation Z. Ce langage est orienté objet et est pluscommode pour nos travaux. La notation reste la même sauf qu’Object-Z inclut, en plusla notion de classe et d’objet. Ce sera Object-Z qui sera utilisé par le chapitre suivant.

Conclusion

Ayant parcouru les notions nécessaires de Z, notions qui seront reprises pour toutela suite du document, nous débuterons le chapitre suivant par une brève introduction dunoyau à modéliser dans ce rapport de mémoire.

25

Chapitre 3

Modélisation formelle du noyau

3.1 Introduction

Le noyau modélisé dans ce chapitre est destiné pour les systèmes embarqués néces-sitant un noyau léger [21]. L’un des buts de ce chapitre est de produire un modèle quipourrait être raffiné pas-à-pas jusqu’à l’obtention du produit final : le code. Le modèleexposé dans ce chapitre pourrait être aussi considéré comme une preuve sur la possibilitéde modéliser un noyau d’un système d’exploitation en utilisant seulement des méthodesformelles.

Le modèle du noyau satisfera les points suivants :• il doit être adapté à un contexte embarqué par sa légèreté,• il doit être portable, et ainsi ne doit pas être lié à un matériel spécifique,• il doit implémenter un ordonnancement basé sur la priorité, les priorités des

processus étant assignés via un paramètre avant le chargement,• il n’inclut pas des modules de gestion de mémoire, la mémoire devant être

allouée statiquement,• il inclut la notion de processus, d’ordonnanceur et IPC (inter-process commu-

nication). Ce dernier doit être relativement riche et doit inclure :◦ sémaphores◦ mail-boxes

• il est lié statiquement aux processus utilisateurs s’exécutant au-dessus dunoyau et les primitives devant être fournies sont :

◦ la création des processus◦ la mise en place des processus dans les files de l’ordonnanceur◦ la destruction des processus et la libération des ressources◦ la suspension d’un processus en exécution◦ la création et la gestion des structures IPC(Inter-process commu-

nication)

26

◦ ...

3.2 Types primaires

3.2.1 Processus

Cette section établit les définitions des types de bases utilisés par le modèle.

Les processus doivent avoir chacun une référence. Le type de base de cette référenceest indiqué par ce qui suit :

[PREF ]

Il sera aussi nécessaire de définir les constantes suivantes dénotant les processus nullet idle :

| NullProcRef , IdleProcRef : PREF

Deux autres types de références peuvent être par suite définis :• le premier exclut la référence au processus null :

IPREF == PREF \ {NullProcRef }

• le second exclut les deux processus null et idle :

APREF == IPREF \ {IdleProcRef }

Sans altérer le caractère général de ces types, il est tout de même possible de leurassocier une représentation plus concrète. D’abord, il est nécessaire définir le nombremaximal de processus que notre noyau pourra gérer :

| maxprocs : N

Ceci est, en fait, la taille de la table des processus ou, en d’autres termes, le nombredes descripteurs de taches de la table (communément connu sous la dénomination TCB(Task Control Block) [22]). Les types et les valeurs des constantes désignant les processusnull etidle sont définis par la figure 3.1.

D’une autre manière, PREF (de même que IPREF et APREF ) peut être défini selonles expressions ci-dessous :

27

NullProcRef : PREFIdleProcRef : IPREF

NullProcRef = 0IdleProcRef = maxprocs

Figure 3.1: Définition de NullProcRef et IdleProcRef

PREF == NullProcRef ..IdleProcRefPREF == 0..maxprocs

Ces définitions rendront les ID des processus plus simples et plus maniables.

A tout moment de son existence, chaque processus est décrit par un seul et seulementun seul état. Tous les états possibles sont définis par le type ci-dessous :

PROCSTATUS ::= pstnew| pstrunning| pstready| pstwaiting| pstterm

Le préfixe pst sous-entend « process table ».

Quand un processus est nouvellement créé mais qu’il n’est pas encore mis sur lafile des processus prêt, il est dans l’état pstnew. Quand ce processus dispose de toutesles ressources nécessaires pour s’exécuter et qu’il lui reste seulement le processeur, ondit qu’il est dans l’état pstready. Quand alors il est exécuté, son état est désigné parpstrunning. Les processus bloqués ou suspendus, pour diverses raisons (attendant parexemple un périphérique particulier), sont classés comme en pstwaiting. Et finalement,quand un processus se termine, il entre l’état pstterm.

Dans le noyau modélisé par ce travail, chaque processus dispose de sa propre pile etde ses propres segments de code et de données. Non seulement le TCB sauvegarde lesadresses et les tailles de ces segments, mais il comporte aussi un pointeur sur le haut dela pile. Ces notions sont représentées à l’aide des types :

[PSTACK ,PCODE ,PDATA]

On définira aussi le type suivant pour généraliser tout pointeur vers une zone demémoire :

28

[MEMDESC ]

La priorité assignée aux processus est définie par le type :

PRIO == Z

Plus l’entier représentant la priorité est petite, plus cette priorité est haute. On n’apas imposé des limites à ces entiers pour qu’il soit toujours possible de créer une prioritéplus basse que toutes les autres. Toutefois, dans une implémentation, la priorité la plusbasse est limitée par le matériel utilisé (232 − 1 sur une machine 32 bits). Inversement,la plus haute priorité correspond à l’entier le plus négatif représentable par le matériel(−232 sur une machine 32 bits).

3.2.2 Registres

Le noyau utilisera un processeur disposant de plusieurs registres d’usage général.Supposant que le nombre de ces registres est de maxreg et chaque mot de ces registres estde largeur RWORD, en Z, ceci est décrit par la figure 3.2.

| maxreg : N1

GENREG == {r0, ..., rmaxreg−1}

Figure 3.2: Définition de maxreg et GENREG

Où GENREG représente l’ensemble des registres du processeur. La classe GENREG-SET de la figure 3.3 définie une fonction vers les valeurs contenues dans ces registres.

GENREGSET� (regs)

regs : GENREG → RWORD

INIT

∀ i : GENREG • regs ′(i) = 0RWORD

Figure 3.3: Définition de GENREGSET

29

A part ces registres d’usage général, quelques registres doivent être aussi pris encompte. Il s’agit des registres contenant le pointeur de pile et le pointeur d’instruction etdu registre de statut dont le mot est de type :

[STATUSWD ]

3.2.3 Interruption

Les interruptions peuvent être activées ou désactivées en utilisant le type :

INTERRUPTSTATUS ::= inton | intoff

La valeur inton représente un état où les interruptions sont activées et intoff unétat où elles sont désactivées.

3.3 Abstractions nécessaires

Cette section définit les constructions de base nécessaires pour la modélisation dunoyau. Les constructions sont représentées à l’aide des classes et des méthodes écrites enObject-Z.

Dans ce qui suit, une distinction est faite entre une file d’attente processus (Process-Queue)et une file d’attente message. La première peut être écrite par la figure 3.4.

A part l’initialisation INIT, cette classe exporte les opérations suivantes : IsEmpty,Enqueue, RemoveFirst, QueueFront et RemoveElement.

Une file d’attente messages est modélisée en utilisant la classe générique de la figure3.5.

IsEmptyelts = 〈 〉

Enqueue∆(elts)x? : X

elts ′ = elts a 〈x?〉

30

ProcessQueue� (INIT , IsEmpty ,Enqueue,RemoveFirst ,QueueFront ,RemoveElement)

elts : iseqAPREF

INIT

elts ′ = 〈 〉

IsEmptyelts = 〈 〉

Enqueue∆(elts)x? : APREF

elts ′ = elts a 〈x?〉

RemoveFirst∆(elts)x ! : APREF

x ! = head eltselts ′ = tail elts

QueueFrontx ! : APREF

x ! = head elts

RemoveElement∆(elts)x? : APREF

(∃ s1, s2 : iseqAPREF • s1 a 〈x?〉a s2 = elts ∧ s1 a s2 = elts ′)

Figure 3.4: Définition de ProcessQueue

RemoveNext∆(elts)x ! : X

elts = 〈x !〉a elts ′

QueueFrontx ! : X

x ! = head elts

31

QUEUE [X ]� (INIT , IsEmpty ,Enqueue,RemoveFirst ,QueueFront ,RemoveElement)

elts : seqX

INIT

elts ′ = 〈 〉

IsEmpty =̂ ...Enqueue =̂ ...RemoveFirst =̂ ...QueueFront =̂ ...RemoveElement =̂ ...

Figure 3.5: Définition de QUEUE[X]

RemoveElement∆(elts)x? : X

(∃ s1, s2 : seqX • elts = s1 a 〈x?〉a s2 ∧ elts ′ = s1 a s2)

La classe générique suivante est utilisée pour modéliser les tables de mailbox et desémaphores. GENTBL[K,D] inclut un membre faisant correspondre une clé de type K àun ensemble de donnée de type D

32

GENTBL[K ,D ]� (InitGENTBL[K ,D ],TBLContainsKey [K ,D ],AddTBLEntry [K ,D ],AddTBLEntry [K ,D ],GetTBLEntry [K ,D ],DelTBLEntry [K ,D ])

tbl : K 7 7→ Dkeys : FK

keys = dom tbl

InitGENTBL[K ,D ]GENTBL[K ,D ]′

keys ′ = ∅

TBLContainsKey [K ,D ]ΞGENTBL[K ,D ]k? : K

k? ∈ keys

AddTBLEntry [K ,D ]∆GENTBL[K ,D ]k? : Kd? : D

tbl ′ = tbl ∪ k? 7→ d?

GetTBLEntry [K ,D ]GENTBL[K ,D ]k? : Kd ! : D

d ! = tbl(k?)

DelTBLEntry [K ,D ]∆GENTBL[K ,D ]k? : K

tbl ′ = k?−C tbl

La classe des registres est définie dans l’Annexe 2.

La classe de la figure 3.6 utilise la classe décrite ci-dessus pour inhiber ou autoriserles interruptions matérielles :

Cette classe est utilisée pour assurer l’exclusion mutuelle, mais au dessus de laditecouche, on utilise plutôt les sémaphores. Ces derniers étant modélisés par la classe ci-après.Trois opérations sont exportées par la classe : INIT, Wait et Signal. La classe exploiteune file de processus (waiters) pour la gestion des processus en attente. Elle accède aussià l’ordonnanceur (sched pour scheduler) et à la table des processus (via ptab) pour influer

33

Lock� (INIT ,Lock ,Unlock)

hw : HardwareRegisters

On suppose que les registres sont initialisés

INIT

hwrgs? : HardwareRegisters

hw ′ = hwrgs?

Lock =̂ hw .SetIntsOffUnlock =̂ hw .SetIntsOn

Figure 3.6: Définition de Lock

sur la manière d’ordonner les exécutions ou les suspensions des processus. Les objetsSemaphore auront besoin d’un mécanisme de commutation de contexte avant de pouvoirsuspendre une tâche en exécution. Une référence à la classe Context y a été donc inclue.

Le principe de base d’un sémaphore est l’utilisation d’un compteur (scnt) dont lavaleur est modifiée selon que la ressource correspondante est libre ou non. Pour ce faire,la classe Semaphore fait usage de la classe Lock. Elle est définie dans l’Annexe 2.

Dans le présent modèle, un descripteur de tâche (TCB) est une structure dont leséléments sont : prio (la priorité du processus), regs (les contenus des registres généraux),statwd (le contenu du registre d’état), ip (le pointeur d’instruction), status (l’état duprocessus) et des pointeurs vers la pile (stack) et vers les segments de code et de données(respectivement code et data). On considère que la pile, ainsi que les segments de code etde données sont alloués dans une zone contiguë de la mémoire.

Le descripteur de tâches est modélisé par la classe ProcessDescr donnée dans l’Annexe2. Ses principales méthodes comprennent une opération d’initialisation, des opérations degestion de contexte telles que FullContext (pour l’extraction de contexte du descripteur),SetFullContext (pour la sauvegarde de contexte dans le descripteur) et d’autres opérationsutilisées dans les traitements de priorité et autres.

Par suite, la table des processus est définie comme une structure faisant correspondreIPREF à ProcessDescr. En d’autres termes, c’est un tableau dont les indices sont deséléments de type IPREF et les objets indexés de type ProcessDescr. La classe définissantcette table est donnée par la figure 3.7. La variable known procs représente tous les pro-cessus du système. Les identificateurs de processus non encore utilisés par les processusexistant seront les éléments de freeids. Comme le processeur n’alloue les identificateurs

34

qu’à des tâches « réelles » (excluant donc les processus null et idle), freeids sera un en-semble d’éléments de type APREF. Autre l’initialisation, la classe décrit des opérationsd’ajout (AddProcess), de suppression (DelProcess) et de récupération (DescrOfProcess)de descripteurs.

ProcessTable� (INIT ,CreateIdleProcess ,AddProcess ,DelProcess ,DescrOfProcess)

procs : IPREF 7 7→ ProcessDescrknown procs : F IPREFfreeids : FAPREF

INIT

known procs ′ = {IdleProcRef }freeids ′ = 1..maxprocs − 1(∃ ipd : ProcessDescr • CreateIdleProcess)

CreateIdleProcess(∃ pr : PRIO , stat : PROCSTATUS , stwd : STATUSWD ,

emptymem : MEMDESC , stkdesc : MEMDESC ,ipd : ProcessDescr • stat = pstready

∧ prio = pr ∧ stwd = 0S ∧ ipd .INIT [stat/stat?,stkdesc/pstack?, emptymem/pdata?, emptymem/pcode?]

procs ′ = procs ⊕ {IdleProcRef 7→ ipd})

Addprocess∆(procs)pid? : APREFpd? : ProcessDescr

procs ′ = procs ⊕ {pid? 7→ pd?}

DelProcess∆(procs)pid? : APREF

procs ′ = {pid?} −C procs

DescrOfProcesspid? : APREFpd ! : ProcessDescr

pd ! = procs(pid?)

Figure 3.7: Définition de ProcessTable

La classe Context décrite en Annexe 2 implémente les opérations des commutations

35

de contexte.

3.4 Gestion des priorités

Le noyau modélisé dans ce travail utilise la notion de priorité comme base d’ordon-nancement. Le type PRIO est équivalent aux entiers. Les trois opérations suivantes sontnécessaires pour la gestion des priorités :

≤P : PRIO ↔ PRIO=P : PRIO ↔ PRIO≥P : PRIO ↔ PRIO

∀ p1, p2 : PRIO •p1 ≤P p2⇔ p1 ≤ p2p1 =P p2⇔ p1 = p2p1 ≥P p2⇔ p1 ≥ p2

D’autres opérations peuvent être définies à partir de ces trois opérations :

<P : PRIO ↔ PRIO>P : PRIO ↔ PRIO

∀ p1, p2 : PRIO •p1 <P p2⇔ (p1 ≤P p2) ∧ ¬ (p1 =P p2)p1 >P p2⇔ (p1 ≥P p2) ∧ ¬ (p1 =P p2)

La classe définissant l’ordonnancement des processus par ordre de priorité est décriteà la figure 3.8.

Si la valeur de la priorité d’un processus est plus petite qu’une autre, alors celui-ciest plus prioritaire.

L’opération de mise en file (EnqueuePROCPRIOQUEUE ) est définie comme suit :

36

EnqueuePROCPRIOQUEUE∆(qprio, procs)pid? : PREFpprio? : PRIO

qprio ′ = qprio ∪ {pid? 7→ pprio?}(procs = 〈 〉 ∧ procs ′ = 〈pid?〉)∨ (procs 6= 〈 〉∧ ((qprio(pid?) ≤P qprio(head procs)) ∧ procs ′ = 〈pid?〉a procs)

∨ ((qprio(pid?) >P qprio(last procs)) ∧ procs ′ = procs a 〈pid?〉)∨ (∃ s1, s2 : iseqPREF | s1 a s2 = procs •

((qprio(last s1) ≤P qprio(head s2)) ∧procs ′ = s1 a 〈pid?〉a s2)))

EnqueuePROCPRIOQUEUE utilise la priorité du processus pour determiner sa placedans la file.

PROCPRIOQUEUE� (INIT ,EnqueuePROCPRIOQUEUE ,

NextFromPROCPRIOQUEUE , IsInPROCPRIOQUEUE ,IsEmptyPROCPRIOQUEUE ,PrioOfProcInPROCPRIOQUEUE ,RemoveProcPrioQueueElem)

qprio : PREF 7 7→ PRIOprocs : iseqPREF

dom qprio = ran procs∀ p1, p2 : PREF •

p1 ∈ ran procs ∧ p2 ∈ ran procs ∧ qprio(p1) ≤P qprio(p2)⇒∃ i1, i2 : 1..#procs • i1 ≤ i2 ∧ procs(i1) = p1 ∧ procs(i2) = p2

INIT

PROCPRIOQUEUE ′

procs ′ = 〈 〉

EnqueuePROCPRIOQUEUE =̂ ...NextFromPROCPRIOQUEUE =̂ ...IsInPROCPRIOQUEUE =̂ ...IsEmptyPROCPRIOQUEUE =̂ ...PrioOfProcInPROCPRIOQUEUE =̂ ...RemoveProcPrioQueueElem =̂ ...ReorderProcPrioQueue =̂ ...

Figure 3.8: Définition de PROCPRIOQUEUE

37

Quand le processeur a fini d’executer le processus courant, la selection du processussuivant est décrite par le schéma ci-dessous :

NextFromPROCPRIOQUEUE∆(qprio, procs)pid ! : PREF

procs = 〈pid !〉a procs ′qprio ′ = {pid !} −C qprio

Les deux schémas suivants définissent IsInPROCPRIOQUEUE et IsEmptyPROC-PRIOQUEUE :

IsInPROCPRIOQUEUEpid? : PREF

pid? ∈ ran procs

IsEmptyPROCPRIOQUEUEprocs = 〈 〉

L’opération PrioOfProcInPROCPRIOQUEUE, définie ci-après, retourne la prioritédu processus donné comme paramètre d’entrée :

PrioOfProcInPROCPRIOQUEUEpid? : PREFpprio! : PRIO

pprio! = qprio(pid?)

Un processus marqué non prêt doit être retiré de la file (celle qui est décrite danscette section) via l’opération RemovePrioQueueElem :

RemovePrioQueueElem∆(procs , qprio)pid? : PREF

procs ′ = procs −B {pid?}qprio ′ = {pid?} −C qprio

Il y a des cas où les priorités doivent être recalculées et, par suite, la file des processusdoit être réorganisée. L’opération ReorderProcPrioQueue définie ci-après est utilisée à cet

38

effet. Si n processus ont changé de priorité, alors l’opération doit être itérée n fois.

ReorderProcPrioQueue =̂RemovePrioQueueElem o

9 EnqueuePROCPRIOQUEUE [newprio?/pprio?]

3.5 Processus courant et processus prêts

La classe Scheduler, présentée à la figure 3.9, représente l’ordonnanceur du noyau mo-délisé dans ce travail. Elle comprend une variable indiquant le processus en exécution (cur-rentp) et une file des processus prêts (readyq, instance de la classe PROCPRIOQUEUE ).La classe exporte entre autres les opérations du tableau III.

Opérations DescriptionsCurrentProcess Retourne la valeur de currentpMakeCurrent Modifie la valeur de currentpMakeReady Ajoute un processus à la file des processus prêts

ContinueCurrent Continue l’exécution du processus courantSuspendCurrent Arrête l’exécution du processus courantRunNextProcess Prend le premier élément (ready) de la file des processus prêts et le

marque comme currentp

Tableau III: Opérations exportées par Scheduler

CurrentProcesscp! : PREF

cp! = currentp

MakeCurrent∆(currentp)pid? : PREF

currentp ′ = pid?

MakeReady est définie comme suit :

MakeReady =̂(∃ pd : ProcessDescr •

ptab.DescrOfProcess [pd/pd !]∧ pd .ProcessPriority [prio/prio!]∧ pd .SetProcessStatusToReady∧ readyq .EnqueuePROCPRIOQUEUE [prio/pprio?]) \ {prio}

39

Scheduler� (INIT ,CurrentProcess ,MakeCurrent ,t1MakeReady ,ContinueCurrent , SuspendCurrent ,

RunNextProcess , SCHEDULENEXT )

currentp : PREFreadyq : PROCPRIOQUEUEctxt : Contextlck : Lock

INIT

ct? : Contextlk? : Lock

readyq .INITcurrentp ′ = NullProcReflck ′ = lk?ctxt ′ = ct?

CurrentProcess =̂ ...MakeCurrent =̂ ...MakeReady =̂ ...MakeUnready =̂ ...isCurrentProc =̂ ...reloadCurrent =̂ ...ContinueCurrent =̂ ...SuspendCurrent =̂ ...RunNextProcess =̂ ...selectIdleProcess =̂ ...SCHEDULENEXT =̂ ...

Figure 3.9: Définition de Scheduler

MakeReady insère un nouveau processus dans la file des processus prêts à être exé-cutes. Et encore une fois, la priorité de ce processus est utilisée pour déterminer le pointd’insertion.

reloadCurrentcurrentp ′ = currentpreadyqp ′ = readyqp

ContinueCurrent est tel que :

ContinueCurrent =̂ realodCurrent ∧ ctxt .RestoreState

40

MakeUnready est défini ci-dessous :

MakeUnready =̂lck .Lock o

9

((IsCurrentProc ∧(ctxt .SaveState o

9 RunNextProcess)o9

lck .Unlock)∨ RemovePrioQueueElem)o

9

lck .Unlock

Où IsCurrentProc est donné par :

IsCurrentProcΞSchedulerp? : PREF

p? = currentp

Cette opération est utilisée pour retirer un processus du readyq. Ceci est le cas si ceprocessus doit attendre un périphérique particulier. Il est aussi possible à un processus dese suspendre via l’opération suivante :

SuspendCurrent =̂lck .Lock o

9

((ctxt .SaveState∧ (∃ pd : ProcessDescr •

ptab.DescrOfProcess [currentp/pid?, pd/pd !]∧ ((pd .ProcessPriority [prio/prio!]∧ pd .SetProcessStatusToWaiting)

∧ readyqp.EnqueuePROCPRIOQUEUE [currentp/x?, prio/prio?])

\{prio}))o9

RunNextProcess)o9

lck .Unlock

L’opération RunNextProcess fait appel à l’ordonnanceur et execute le prochain pro-cessus. Avant cet appel, le contexte de l’ancien processus a été sauvegardé.

RunNextProcess =̂ SCHEDULENEXT o9 ctxt .RestoreState

SCHEDULENEXT, interface primaire de l’ordonnanceur, est défini par :

41

SCHEDULENEXT =̂lck .Lock o

9

((∃ pd : ProcessDescr •ptab.DescrOfProcess [p/pid?, pd/pd ![∧ (¬ readyqp.IsEmptyPROCPRIOQUEUE∧ readyqp.NextFromPROCPRIOQUEUE [p/pid !]∧ readyqp.MakeCurrent [p/pid?]∧ pd .SetProcessStatusToRunning [p/pid?]

∨ selectIdleProcess))o9

lck .Unlock

Et selectIdleProcess est décrit par la schéma suivant :

selectIdleProcess∆(currentp)

currentp ′ = IdleProcRef

Cette opération est necessaire quand readyq est vide.

3.6 Messages et sémaphores

Le noyau modélisé ici requiert la notion de file de messages (mailbox ). Un messageest composé d’une partie « donnée »(de type MSGDATA) et d’une partie « source »(detype MSGSRC ).

[MSGDATA]

Un message peut être envoyé par n’importe quelle tâche « active »ou bien par unpériphérique :

MSGSRC == APREF ∪ {hardware}

D’où le type de message MBOXMSG :

MBOXMSG == MSGSRC ×MSGDATA

Les fonctions suivantes ont été introduites pour faciliter la manipulation des mes-sages :

42

msgsender : MBOXMSG → MSGSRCmsgdata : MBOXMSG → MSGDATA

∀m : MBOXMSG •msgsender(m) = fst mmsgdata(m) = snd m

La classe qui implémente le mailbox est définie par la figure 3.10. Dans cette définition,le mailbox est considéré comme une file de messages. La classe exporte trois opérations :

• PostMessage : ajoute un message• NextMessage : recupère le message suivant du mailbox• HaveMessage : determine si le mailbox est vide ou non

Mailbox� (INIT ,PostMessage,HaveMessage,NextMessage)

msgs : QUEUE [MBOXMSG ]lck : Lock

INIT

l? : Lock

msgs .INITlck ′ = l?

PostMessagem? : MBOXMSG

lck .Lock o9 (msgs .Enqueue[m?/x?] o

9 lck .Unlock)

HaveMessagelck .Lock o

9 ¬ msgs .IsEmpty o9 lck .Unlock

NextMessagem! : MBOXMSG

lck .Lock o9 msgs .RemoveFirst [m!/x !] o

9 lck .Unlock

Figure 3.10: Définition de Mailbox

Chaque processus dispose d’au plus un mailbox. La table répertoriant tous les mailboxdu système peut être considérée comme une instance de GENTBL dont l’index est de typeAPREF.

Par contre, chaque processus peut disposer de plusieurs sémaphores selon ses besoinsen terme de synchronisation. De la même manière que les mailbox, l’ensemble des séma-phores du système peut être représenté par une instance de GENTBL[K,D]. Supposant

43

que les sémaphores peuvent être identifiés par des variables de type :

[SEMAID ]

le schéma pour la génération des identifiants pour sémaphore peut être écrit commesuit :

GenSemaIdsid ! : SEMAID

...

et l’ensemble des sémaphores du système est donné par la figure 3.11 ci-après.

SemaphoreTable� (INIT ,NewSemaphore,DelSemaphore,GetSemaphore)

lck : Lockstbl : GENTBL[SEMAID , Semaphore]

INIT

l? : Lock

lck ′ = l? ∧ stbl .INIT

NNewSemaphore =̂lck .Lock o

9

(∃ s : Semaphore, sid : SEMAID •s .INIT∧ GenSemaId [sid/sid !]∧ stbl .AddTBLEntry [sid/k?, s/d?])

o9lck .Unlock

DelSemaphore =̂ lck .Lock o9 stbl .DelTBLEntry [sid/k?, s/d?] o

9 lck .UnlockGetSemaphore =̂ lck .Lock o

9 stbl .GetTBLEntry [sid/k?, s/d?] o9 lck .Unlock

Figure 3.11: Définition de SemaphoreTable

Conclusion

Étant donné ce modèle spécifié à l’aide de la notation Z, nous procéderons au chapitresuivant à des vérifications formelles de quelques schémas, pris comme exemples. Ces véri-fications consisteront surtout à prouver la validité de quelques théorèmes fondamentauxque le modèle doit obligatoirement satisfaire.

44

Chapitre 4

Preuves automatiques du modèle enutilisant Z/EVES

4.1 Introduction

Ce chapitre présente le système Z/EVES. Il s’agit d’un système dédié à l’analyse desspécifications Z. Il est généralement utilisé pour l’analyse syntaxique, la vérification dutypage et de l’application des fonctions dans leur domaine, mais aussi pour l’expansiondes schéma, pour le calcul de préconditions, pour la réalisation d’un raffinement et pourprouver différentes propriétés. Le langage à utiliser pour les interactions avec Z/EVESest dénommé Z/LATEX. Z/EVES est basé sur le système EVES et utilise le prouveur dethéorème de celui-ci pour faire chacune des étapes de ses preuves. Cependant, il n’est pasnécessaire de connaître EVES ou son langage (Verdi) pour utiliser Z/EVES. L’interfaceZ de EVES a été développé par Irwin Meisels conjointement avec le Département de laDéfense des Etats-Unis. Et EVES lui-même a été développé par plusieurs auteurs dontDan Craigen, Sentot Kromodimoeljo, Irwin Meisels, Bill Pase, et ceci sous l’égide duDépartement de la Défense Nationale du Canada.

Ce démonstrateur dispose d’une base de connaissances en théorie des ensembles eten logique du premier ordre. Les règles d’inférence qu’il utilise sont reliées à ces deuxdomaines. En effet, plusieurs théorèmes peuvent être utiles pour faire de la démonstrationde propriétés. Parmi ces théorèmes, on retrouve autant des propriétés utiles que des règlesd’inférence.

Ce chapitre donne un bref aperçu de l’utilité de Z/EVES dans la démarche de valida-tion du modèle proposé dans ce mémoire. Il inclut notamment les usages les plus courantsde Z/EVES à l’aide d’exemples tirés de ce modèle. Dans ce qui suit, Z/EVES sera utiliséprincipalement :

• pour faire l’expansion d’un schéma,

45

• pour vérifier la syntaxe et la cohérence des types,• pour vérifier l’application des fonctions dans leur domaine,• pour vérifier les conditions initiales de chaque opération.

4.2 Expansion d’un schéma

Les schémas en Z contiennent souvent le nom d’un autre schéma dans leur partiedéclarative. Par exemple, le schéma ProcessQueueRemoveFirst suivant inclut les schémasProcessQueue et ProcessQueue’ :

ProcessQueueRemoveFirst∆ProcessQueuex ! : APREF

x ! = head eltselts ′ = tail elts

C’est une caractéristique intéressante de la notation Z car ceci permet de faire desprésentations plus concises et souvent plus faciles à écrire et à comprendre.

Cependant, il est parfois intéressant, voire nécessaire, de voir un schéma écrit dans saversion étendue. Et écrire l’expansion d’un schéma à la main est une tâche parfois ardueet sujette à l’erreur. Z/EVES permet de le faire de façon automatique. D’ailleurs, cetoutils procède d’abord à une expansion avant d’effectuer les vérifications dans les sectionssuivantes. Le listing 1 montre l’expansion du schéma ProcessQueueRemoveFirst réaliséepar Z/EVES.

46

With invocation of PREF, IPREF, APREF, ProcessQueue, \Delta ProcessQueue,ProcessQueueRemoveFirstforward chaining using KnownMember\$declarationPart,ProcessQueue\$declarationPart, knownMember,Delta\$ProcessQueue\$declarationPart, ProcessQueueRemoveFirst\$declarationPart,‘[internal items]‘with the assumptions tail\$declaration, head\$declaration,IdleProcRef\$declaration, NullProcRef\$declaration, select\_2\_1, select\_2\_2,maxprocs\$declaration, ‘&upto$declaration‘, ‘&setminus$declaration‘,‘[internal items]‘ to ...

elts\in \iseq ((0 \upto maxprocs) \setminus \{NullProcRef\}

\setminus \{IdleProcRef\}) \\\land elts’

\in \iseq ((0 \upto maxprocs) \setminus \{NullProcRef\}\setminus \{IdleProcRef\}) \\

\landx!\in (0 \upto maxprocs) \setminus \{NullProcRef\} \setminus \{IdleProcRef\} \\\land x! = head elts \\\land elts’ = tail elts

Listing 1: Expansion de schéma effectué par Z/EVES

4.3 Vérification de la syntaxe et de la cohérence des

types

C’est la façon la plus simple d’utiliser Z/EVES. Cette vérification est nécessaire pourla cohérence même du modèle. Il suffit d’entrer la spécification Z sous forme d’entréeZ/LATEX. Le listing 2, à titre d’exemple, donne une partie du modèle en Z/LATEX.

\usepackage{z-eves}

\begin{axdef}maxprocs: \nat

\end{axdef}

\begin{zed}PREF == 0 \upto maxprocs

\end{zed}

\begin{axdef}NullProcRef, IdleProcRef : PREF

\where

47

NullProcRef = 0\\IdleProcRef = maxprocs\\

\end{axdef}

\begin{zed}IPREF == PREF \setminus \{NullProcRef\} \\APREF == IPREF \setminus \{IdleProcRef\}

\end{zed}

\begin{zed}PROCSTATUS ::= pstnew\\

|pstrunning\\|pstready\\|pstwaiting\\|pstterm

\end{zed}

\begin{zed}[MEMDESC]

\end{zed}

\begin{zed}[PSTACK, PCODE, PDATA]

\end{zed}

\begin{zed}PRIO == \num

\end{zed}

\begin{axdef}maxreg: \nat_1

\end{axdef}

\begin{zed}[GENREG, RWORD, STATUSWD]

\end{zed}

\begin{schema}{GENREGSET}regs : GENREG \fun RWORD\\

\where\# regs \leq maxreg

\end{schema}

\begin{schema}{ProcessQueue}elts : \iseq APREF

\end{schema}

48

\begin{schema}{ProcessQueueInit}ProcessQueue’ \\

\whereelts’ = \langle \rangle

\end{schema}

\begin{schema}{ProcessQueueRemoveFirst}\Delta ProcessQueue \\x! : APREF \\

\wherex! = head~ elts\\elts’ = tail~ elts

\end{schema}

Listing 2: Exemple de spécification écrite en Z/LATEX

Si Z/EVES détecte une erreur de syntaxe, il affiche un message semblable au listing3 suivant.

Checking definition of PREFError UndeclaredName (line 12) [Type checker]: name not declared: maxproc.

Listing 3: Message d’erreur affiché par Z/EVES pour une erreur de syntaxe

Si c’est une erreur de type, le message ressemblera au message du listing 4.

Checking schema ProcessQueueEnqueueError FunctionArgType (line 101) [Type checker]: in application of\Global (\_ \cat \_), argument 2 has the wrong type.

Listing 4: Message d’erreur affiché par Z/EVES pour une erreur de type

Il suffit alors de corriger l’erreur ayant causé le message en question et de fournir laversion corrigée à Z/EVES.

4.4 Analyse de l’application des fonctions dans leur

domaine

Cette sous-section présente comment Z/EVES traite le problème des expressions in-définies en Z. La notation Z permet d’écrire certaines expressions qui n’ont pas de sens.

Il y a deux façons en Z d’écrire des expressions qui n’ont pas de sens. Une de ces façonsest d’appliquer une fonction à l’extérieur de son domaine. L’approche de Z/EVES est devérifier si chaque expression a toujours un sens [23]. Le système examine les paragraphes

49

au fur et à mesure qu’ils sont entrés, vérifie que chaque application d’une fonction se faitdans son ensemble de départ et exprime à l’aide d’un prédicat les conditions sous lesquellesl’application a un sens mathématique. Lors de l’écriture d’une spécification, Z/EVESajoute automatiquement à sa base de connaissances des théorèmes. Les théorèmes ditsde $domainCheck en font partie. Après la lecture du schéma QUEUERemoveElement,Z/EVES a généré le théorème du listing 5.

\begin{theorem}{axiom QUEUERemoveElement\$domainCheck}[X]\Delta QUEUE[X] \\

\land x? \in X \\\land ( s1 \in \seq X \\

\land s2 \in \seq X) \\\implies

(s1, \langle x? \rangle)\in \dom[\power (\num \cross X) \cross \power (\num \cross X),

\power (\num \cross X)] (\_ \cat \_)[X] \\\land (s1 \cat[X] \langle x? \rangle, s2)

\in \dom[\power (\num \cross X) \cross \power (\num \cross X),\power (\num \cross X)] (\_ \cat \_)[X] \\

\land( s1 \cat[X] \langle x? \rangle \cat[X] s2 = elts \\\implies (s1, s2)

\in \dom[\power (\num \cross X) \cross \power (\num \cross X),\power (\num \cross X)] (\_ \cat \_)[X])

\end{theorem}

Listing 5: Théorème $domainCheck généré automatiquement par Z/EVES

Si on peut prouver ce théorème, alors le schéma est bien typé. C’est-à-dire que toutesles fonctions sont utilisées dans leur domaine de définition. Ici, le théorème peut êtreprouvé automatiquement par le listing 6 ci-dessous.

\begin{zproof}[QUEUERemoveElement\$domainCheck]prove by reduce;\end{zproof}

Listing 6: Paragraphe zproof de Z/EVES

En effet, cette commande de Z/EVES produit la sortie du listing 7 suivante :

50

Substituting produces ...

\Delta QUEUE[X] \\\land x? \in X \\\land s1 \in \seq X \\\land s2 \in \seq X \\

\implies(s1, \langle x? \rangle)\in \dom[\power (\num \cross X) \cross \power (\num \cross X),

\power (\num \cross X)] (\_ \cat \_)[X] \\\land (s1 \cat[X] \langle x? \rangle, s2)

\in \dom[\power (\num \cross X) \cross \power (\num \cross X),\power (\num \cross X)] (\_ \cat \_)[X] \\

\land ( s1 \cat[X] \langle x? \rangle \cat[X] s2 = elts \\\implies (s1, s2)

\in \dom[\power (\num \cross X) \cross \power (\num \cross X),\power (\num \cross X)] (\_ \cat \_)[X])

Which simplifieswith invocation of QUEUE, \Delta QUEUEwhen rewriting with catAssociates, catInSeq, unitInSeq, tupleInCross2, domCat,ffun\_type, rel\_type, inPowerSelf, weakening, power\_sub, crossSubsetCross2forward chaining using KnownMember\$declarationPart, knownMember,QUEUE\$declarationPart, Delta\$QUEUE\$declarationPart, ‘[internal items]‘with the assumptions natType, relDefinition, pfun\_type, nat1\_type,‘&seqcat$declaration‘, ‘&dom$declaration‘, select\_2\_1, select\_2\_2,unitSeqType, seq\_type, ‘[internal items]‘ to ...trueProving gives ...true

Listing 7: Exécution de la commande de preuve par Z/EVES

Par contre, certains théorèmes sont plus difficiles à prouver. Un exemple est le théo-rème généré par Z/EVES pour la vérification des domaines dans le schémaGENREGSET :

4.5 Vérification des conditions initiales

Une fois que le domaine a été vérifié pour toutes les fonctions utilisées dans chacunedes déclarations de la spécification, on sait que cette spécification est mathématiquementcorrecte. Il faut maintenant voir si elle décrit des états valides et des fonctions qui n’en-voient le système que sur des états valides. Le premier théorème à démontrer dans cesens est le théorème d’initialisation. Par exemple, dans le cas du schéma ProcessQueue,les schémas concernés sont les suivants.

51

ProcessQueueelts : iseqAPREF

ProcessQueueInitProcessQueue ′

elts ′ = 〈〉

De par le théorème d’initialisation, il faut au moins qu’on aie un état de départ valideaprès l’opération ProcessQueueInit, ce qui peut se traduire par le listing 8 suivant :

\begin{theorem}{InitialisationProcessQueue}\exists ProcessQueue’ @ ProcessQueueInit\end{theorem}

Listing 8: Théorème d’initialisation de ProcessQueue

Z/EVES démontre ce théorème par si on entre le paragraphe du listing 9 :

\begin{zproof}[InitialisationProcessQueue]prove by reduce;\end{zproof}

Listing 9: Commande Z/EVES pour prouver InitialisationProcessQueue

Et la sortie de cette commande est le listing 10 :theorem InitialisationProcessQueue... theorem InitialisationProcessQueueBeginning proof of InitialisationProcessQueue ...\exists ProcessQueue[elts’/elts] @ ProcessQueueInitWhich simplifieswith the instantiation elts’ = \langle \rangle to ...

ProcessQueue[elts := \langle \rangle]\land trueWhich simplifieswith invocation of PREF, IPREF, APREF, ProcessQueuewhen rewriting with weakening, nullSubset, iseq\_subforward chaining using ProcessQueue\$declarationPart,KnownMember\$declarationPart, knownMember, ‘[internal items]‘with the assumptions IdleProcRef\$declaration, NullProcRef\$declaration,select\_2\_1, select\_2\_2, maxprocs\$declaration, ‘&upto$declaration‘,‘&setminus$declaration‘, nullSeqType, ‘[internal items]‘ to ...true

Listing 10: Preuve Z/EVES du théorème d’initialisation de ProcessQueue

52

4.6 Théorème des préconditions

Maintenant qu’on sait que le système démarre dans un état valide, il reste à vérifier siles fonctions spécifiées n’envoient pas le système dans des états indésirables. On veut doncvérfierer qu’à partir d’un état valide, si les préconditions d’une fonction sont satisfaites,alors cette fonction envoie toujours le système dans un état valide. On peut exprimer letout à l’aide du prédicat suivant.

∀ Systeme,Entrees? | Proprietes • (∃ Systeme ′, Sorties ! • Fonction)

Les préconditions de la fonction se trouvent à la dernière partie de ce prédicat. Aussiva-t-on utiliser le raccourci suivant pour noter ce prédicat :

preFonction ⇔ (∃ Systeme ′, Sorties ! • Fonction)

On peut donc résumer le théorème à démontrer à l’aide du prédicat suivant :

∀ Systeme,Entrees? | Proprietes • preFonction

Un exemple est donné par le listing 11 en ce qui concerne le schéma ProcessQueue.La démonstration des préconditions est appliquée ici à la fonction ProcessQueueIsEmpty.En fournissant à Z/EVES les lignes suivantes :

\begin{theorem}{PreconditionsProcessQueueIsEmpty}\forall ProcessQueue | elts = \langle \rangle @ \pre ProcessQueueIsEmpty\end{theorem}

\begin{zproof}[PreconditionsProcessQueueIsEmpty]prove by reduce;\end{zproof}

Listing 11: Théorème des préconditions et paragraphe zproof

Z/EVES sort le résultat du listing 12 :

53

theorem PreconditionsProcessQueueIsEmpty... theorem PreconditionsProcessQueueIsEmptyBeginning proof of PreconditionsProcessQueueIsEmpty ...

ProcessQueue \\\land elts = \langle \rangle \\

\implies ProcessQueueIsEmptyRearranging gives ...

elts = \langle \rangle \\\land ProcessQueue \\

\implies ProcessQueueIsEmptySubstituting elts = \langle \rangle produces ...

elts = \langle \rangle \\\land ProcessQueue[elts := \langle \rangle] \\

\implies ProcessQueueIsEmpty[elts := \langle \rangle]Which simplifieswith invocation of ProcessQueueIsEmpty, PREF, IPREF, APREF, ProcessQueuewhen rewriting with weakening, nullSubset, iseq\_subforward chaining using ProcessQueueIsEmpty\$declarationPart,ProcessQueue\$declarationPart, KnownMember\$declarationPart, knownMember,‘[internal items]‘with the assumptions IdleProcRef\$declaration, NullProcRef\$declaration,select\_2\_1, select\_2\_2, maxprocs\$declaration, ‘&upto$declaration‘,‘&setminus$declaration‘, nullSeqType, ‘[internal items]‘ to ...trueProving gives ...true

Listing 12: Preuve Z/EVES du théorème des préconditions

Ce résultat, true, indique en effet que les préconditions de la fonction ProcessQueueI-sEmpty sont belles et bien satisfaites, nous assurant alors que cette fonction n’aura pasde comportement indésirable.

D’une façon générale, en considérant une spécification en Z d’un système S, avecétat initial SInit , avec les déclarations d1, d2, ..., dm et avec les fonctions f1, f2, ..., fn , ensupposant que l’ensemble des états possibles du système ne soit pas vide et supposant qu’ilexiste un programme codé P satisfaisant l’ensemble de cette spécification ; en supposantde plus que les théorèmes suivants ont été démontrés :

d1$domainCheckd2$domainCheck

...dm$domainCheck

54

S$domainCheckSInit$domainCheckf1$domainCheckf2$domainCheck

... fn$domainCheckInitialisationSPreconditionsf1Preconditionsf2

... Preconditionsfn

alors le programme P ne se trouvera jamais dans un état indésirable.

55

Conclusion

De par ce mémoire, il a été montré que la notation Z peut être utilisée pour lamodélisation des systèmes complexes. Elle peut fournir une spécification claire, lisible etsans ambiguïté. Cette notation a été en effet conçue pour l’homme plutôt que pour lamachine. De ce fait, même une spécification complexe peut toujours être gérée de façonadéquate en utilisant les schémas. L’effectivité d’un recours à un assistant de preuvesa été aussi vue et démontrée dans ce travail. Z/EVES, quoique difficile d’utilisation,reste toujours un outils puissant pour l’automatisation et la vérification des preuves desthéorèmes. Une des facettes intéressante vue dans ce document est qu’à partir d’unespécification écrite en Z/LATEX, on peut directement y formuler des théorèmes et les faireprouver par Z/EVES, et ceci sans passer par une quelconque translation de langage.

Ces méthodes rigoureuses améliorent la fiabilité du système, le temps de conceptionet la compréhensibilité du système mais ceci au coût d’une durée d’apprentissage pluslong et plus ardu. En effet, les disciplines mathématiques utilisées pour la modélisationformelle des systèmes sont en général en dehors du domaine d’éducation traditionnelle.

Malgré leur succès là où elles sont utilisées, les méthodes formelles ne sont pas en-core largement adoptées, exceptés dans le développement des systèmes critiques. Une desprincipales raisons est, d’une part, le manque d’outils facilement assimilable pour pouvoirêtre répandu. D’autre part, les outils disponibles, Z/EVES par exemple, sont difficilementmaitrisable. Pour dompter ce démonstrateur semi-automatique, il faut en effet beaucoupde pratique et, en sus, un temps d’apprentissage très long.

Le modèle proposé dans ce travail reste encore à un niveau abstrait. Une amélioration,qui pourrait être l’objet d’une future étude, est l’introduction des théorèmes de raffinementpouvant conduire à un modèle plus détaillé facile à implémenter. De plus, ces théorèmespourraient être prouvés et validés en exploitant les bases de connaissances de Z/EVES,bases constituées par plus de cinq cents théorèmes.

56

ANNEXES

57

Annexe 1 : Exemples d’applicationsdes méthodes formelles

Même si ce sont les systèmes critiques qui bénéficient le plus des méthodes formelles,ces dernières sont quand même utilisées aussi dans d’autres variétés d’applications in-dustrielles. Les méthodes formelles ont été déjà utilisées dans des systèmes non critiquesdans le but d’améliorer leur qualité. Elles ont prouvé leur potentiel en réduisant le coûtde développement (Ex : le projet CICS d’IBM a économisé 9% en terme de coût, ceci dufait de l’utilisation de Z ) et le délai de livraison (Ex : Le développement du FPU inmosT800 a été réduit de 12 mois ). Les sections ci-dessous donnent une description brève dequelques projets et compagnies impliqués dans le développement de systèmes critiques etayant choisi les méthodes formelles comme technique de développement. La plus utiliséede ces méthodes étant Z.

Aviation

Le projet SIFT constitue un exemple d’application des méthodes formelles dans dessystèmes réels, et représente probablement un des plus importantes expériences des États-Unis dans le domaine des systèmes critiques. SIFT est un système de contrôle d’aéronefqui a été commandé par la NASA vers le milieu des années 70. Les exigences proposéespar la NASA et le FAA étaient très strictes. Le système devrait aboutir à une probabilitéd’accidents mortels d’au plus 10−10 par heure durant dix heures de vol. Les méthodesformelles ont été donc choisies pour le développement du projet SIFT afin d’améliorer laprobabilité de 10−5 qui représentait alors le meilleur résultat obtenu par d’autres tech-niques. SIFT a été conçu pour être opérationnel même en présence d’un défaut matériel.Ceci a été possible en choisissant des processeurs redondants et en utilisant une techniquede vote dite adaptive. Contrairement à d’autres systèmes utilisant les techniques de vote,le mécanisme de vote implémenté pour la détection et l’isolement des défaut matériels deSIFT a été conçu entièrement de façon logiciel. Et c’est ce logiciel qui était l’objet d’unevérification formelle. La vérification était réalisées par des prouveurs comprenant notam-ment le « Boyer-Moore Theorem prover »et le STP (Shostak’s Theorem Prover). Un autreprojet de la NASA implique l’application des méthodes formelles pour la conception du

58

DFCS (Digital Flight Control System) afin que le système final soit tolérant aux défauts.

Airbus a utilisé SCADE [2] pour développer des systèmes de contrôle-commande(incluant le Flight Control Secondary Computer et l’Electric Load Management Unit)pour leurs avions de ligne A340-500/600 afin de satisfaire à l’exigence de sécurité DO-178B Level A. Ces systèmes ont été opérationnels et en exploitation dès 2002. Dans cesprojets, 70% des codes ont été générés automatiquement. Ayant bénéficié des techniquesformelles, Airbus a continué d’utiliser SCADE pour le développement de la plupart dessystèmes critiques embraqués pour le A380 et le A400M.

Nucléaire

Ontario Hydro et l’AECB (Atomic Energy Control Board of Canada), le régulateurcanadien pour le domaine nucléaire, ont développé des systèmes d’arrêt commandés parordinateur pour le DNGS (Darlington Nuclear Generating Station). Quand les difficultésont surgi dans l’obtention de la licence de l’AECB, des méthodes formelles ont été deman-dées par l’AECB pour s’assurer que le logiciel répondrait aux exigences. Le procédé d’analyse mathématique était utilisé après développement. Les spécifications, le code et lespreuves exigeaient des reliures assez conséquentes pour chacun des deux systèmes d’arrêt.L’utilisation de l’approche formelle a finalement convaincu l’AECB de délivrer la licence.

Réseau

Le MGS (Multinet Gateway System) est un équipement Internet fournissant un ser-vice sécurisé de livraison de paquet. MGS a été largement testé par les critères d’évaluationde l’US Trusted Computer System. Ces critères incluent surtout des analyses de sécuritéprotocoles de communications. Des méthodes mathématiques rigoureuses ont été utiliséespour développer et modéliser les aspects sécurité de ces critères. Dix pages ont été néces-saires pour seulement la modélisation sécurité et 80 de plus pour la spécification du MGS.Le système d’exploitation disposait environ de 6000 lignes de code.

Ferroviaire

En 1988, GEC Alsthom, MATRA Transport et RATP ont commencé à travailler surun système de signalisation automatisé pour le contrôle du réseau RER de Paris. L’ob-jectif du projet a été d’augmenter le trafic de 25% sans pour autant nuire à la sécurité.Le système résulant, SACEM, a été livré en 1989 et contrôle aujourd’hui encore les lignesRER de Paris. Ce système de signalisation a pu réduire la séparation des trains de 2mn30s à 2mn sans dégradation de la sécurité. Les développeurs de ce système ont été ap-

59

pelés à montrer au maître d’ouvrage (RATP) que le système est complètement conformeaux exigences de sécurité. Parmi plusieurs techniques utilisées (spécification, vérification,preuve, fault analysis), les méthodes formelles en représentaient une grande partie.

Génie civil

A Rotterdam, le système "Maeslant Kering" est une barrière amovible protégeantle port contre d’éventuelles inondations pouvant résulter des conditions météorologiques.La décision d’ouverture ou de fermeture de la barrière devrait être prise en fonctiondes données météorologiques reçues d’un système informatisé. Cette application a étéclassée en SIL 4 selon la norme CEI 61508. Pour une telle application, l’utilisation destechniques formelles est fortement recommandée. Il a été alors convenu de procéder à unemodélisation formelle et une vérification durant les phases d’analyses, de conception et deréalisation. Les données et opérations ont été modélisées en Z [1] puis encapsulés dans unmodèle Promela. Au total, 20000 lignes écrites en Z ont été produites. Une mise à jourdu système a été réalisé en 2008 et toujours en utilisant des techniques formelles.

60

Annexe 2 : Schémas relatifs auxclasses HardwareRegisters,Semaphore, ProcessDescr et Context

Définition de la classe HardwareRegisters

HardwareRegisters� (SetGPRegs ,GetGPRegs ,GetStackReg , SetStackReg ,SetIntsOff , SetIntsOn,GetIP , SetIP ,GetStatWd , SetStatWd)

hwgenregs : GENREGSEThwstack : PSTACKhwstatwd : STATUSWDhwip : Nintflg : INTERRUPTSTATUS

INIT

hwgenregs .INIThwstack ′ = 0hwstatwd ′ = 0S

hwip ′ = 0

SetGPRegs∆(hwgenregs)regs? : GENREGSET

hwgenregs ′ = regs?

GetGPRegsregs ! : GENREGSET

regs ! = hwgenregs

SetStackRegstk? : PSTACK

hwstack ′ = stk?

61

GetStackRegstk ! : PSTACK

stk ! = hwstack

SetIPip? : N

hwip ′ = ip?

GetIPip! : N

ip! = hwip

SetStatWdstwd? : STATUSWD

hwstatwd ′ = stwd?

GetStatWdstwd ! : STATUSWD

stwd ! = hwstatwd

SetIntsOnintflg ′ = inton

SetIntsOffintflg ′ = intoff

Définition de la classe Semaphore

Semaphore� (INIT ,Wait , Signal)

waiters : ProcessQueuescnt , initval : Zptab : ProcessTablesched : Schedulerctxt : Contextlck : Lock

62

INIT

iv? : Zpt? : ProcessTablesch? : Schedulerct? : Contextlk? : Lock

initval ′ = iv? ∧ scnt ′ = iv? ∧ ptab ′ = pt?sched ′ = sch? ∧ ctxt ′ = ct? ∧ lck ′ = lk?waiters .INIT

NegativeSemaCount =̂ scnt < 0NonPositiveSemaCount =̂ scnt 6 0IncSemaCount =̂ scnt ′ = scnt + 1DecSemaCount =̂ scnt ′ = scnt − 1Wait =̂

lck .Lock o9

(DecSemaCount o9(NegativeSemaCount ∧

waiters .Enqueue[currentp/x?] ∧(∃ cpd : ProcessDescr •

ptab.DescrOfProcess [currentp/pid?, cpd/pd !] ∧cpd .SetProcessStatusToWaiting ∧ctxt .SwitchContextOut) ∧

sched .MakeUnready [currentp/pid?] ∧ sched .RunNextProcess)∨ sched .ContinueCurrent)o

9

lck .UnlockSignal =̂

lck .Lock o9

(IncSemaCount o9(NonPostiveSemaCount ∧

waiters .RemoveFirstProc[cand/x !] ∧(∃ cpd : ProcessDescr •

ptab.DescrOfProcess [cand/pid?, cpd/pd !] ∧cpd .SetProcessStatusToReady) ∧sched .MakeReady [cand/pid?]) \ {cand}

∨ sched .ContinueCurrent)o9

lck .Unlock

63

Définition de la classe ProcessDescr

ProcessDescr� (INIT ,FullContext , SetFullContext ,Priority , SetPriority ,

SetProcessStatusToNew , SetProcessStatusToTerminated ,SetProcessStatusToReady , SetProcessStatusToWaiting)

prio : PRIO , status : PROCSTATUS , regs : GENREGSETstatwd : STATUSWD , ip : N, stack : PSTACKdata : PDATA, code : PCODE

INIT =̂ ...Priority =̂ ...SetPriority =̂ ...ProcessStatus =̂ ...SetProcessStatusToNew =̂ ...SetProcessStatusToTerminate =̂ ...SetProcessStatusToReady =̂ ...SetProcessStatusToRunning =̂ ...SetProcessStatusToWaiting =̂ ...FullContext =̂ ...SetFullContext =̂ ...

INITpr? : PRIOstat? : PROCSTATUSpstack? : PSTACKpdata? : PDATApcode? : PCODE

prio ′ = pr?status ′ = stat?regs .INITstatwd ′ = 0S

ip ′ = 0data ′ = pdata?code ′ = pcode?stack ′ = pstack?

Prioritypr ! : PRIO

pr ! = prio

64

SetPriority∆(prio)pr? : PRIO

prio ′ = pr?

ProcessStatusst ! : PROCSTATUS

st ! = status

SetProcessStatusToNew∆(status)

status ′ = pstnew

SetProcessStatusToTerminated∆(status)

status ′ = pstterm

SetProcessStatusToReady∆(status)

status ′ = pstready

SetProcessStatusToRunning∆(status)

status ′ = pstrunning

SetProcessStatusToWaiting∆(status)

status ′ = pstwaiting

65

FullContextpregs ! : GENREGSETpip! : Npstatwd ! : STATUSWDpstack ! : PSTACK

pregs ! = regspip! = ippstatwd ! = statwdpstack ! = stack

SetFullContextpregs? : GENREGSETpip? : Npstatwd? : STATUSWDpstack? : PSTACK

regs ′ = pregs?ip ′ = pip?statwd ′ = pstatwd?stack ′ = pstack?

Définition de la classe Context

Context� (INIT , SaveState,RestoreState, SwapIn, SwapOut)

ptab : ProcessTablesched : Schedulerhw : HardwareRegisters

INIT

ptb? : ProcessTableshd? : Schedulerhwregs? : HardwareRegisters

ptab ′ = ptb?sched ′ = shd?hw ′ = hwregs?

66

SaveState(∃ cp : IPREF •

sched .CurrentProcess [cp/cp!](∃ pd : ProcessDescr •

ptab.DescrOfProcess [cp/pid?, pd/pd !]∧ (∃ regs : GENREGSET , stk : PSTACK , ip : N,

stat : STATUSWD •hw .GetGPRegs [regs/regs !]∧ hw .GetStackReg [stk/stk !]∧ hw .GetIP [ip/ip!]∧ hw .GetStatWd [stat/stwd !]∧ pd .SetFullContext [regs/pregs?, ip/pip?, stat/pstatwd?,

stk/pstack?])))

RestoreState(∃ cp : IPREF •

sched .CurrentProcess [cp/cp!](∃ pd : ProcessDescr •

ptab.DescrOfProcess [cp/pid?, pd/pd !]∧ (∃ regs : GENREGSET , stk : PSTACK , ip : N,

stat : STATUSWD •pd .FullContext [regs/pregs?, ip/pip?, stat/pstatwd?,

stk/pstack?]∧ hw .SetGPRegs [regs/regs?]∧ hw .SetStackReg [stk/stk?]∧ hw .SetIP [ip/ip?]∧ hw .SetStatWd [stat/stwd !])))

SwapOut =̂(∃ cp : IPREF , pd : ProcessDescr •

sched .CurrentProcess [cp/cp!]∧ ptab.DescrOfProcess [pd/pd !]∧ pd .SetProcessStatusToWaiting∧ SaveState o

9 sched .MakeUnready [currentp/pid?]∧ sched .ScheduleNext)

SwapIn =̂(∃ cp : IPREF , pd : ProcessDescr •

sched .CurrentProcess [cp/cp!]∧ pd .SetProcessStatusToRunning∧ RestoreState)

SwitchContext =̂ SwapOut o9 SwapIn

67

Références

[1] Abrial, J.-R. Formal Methods in Industry : Achievements, Problems, Future, SwissFederal Institute of Technology Zurich, 2006

[2] Berry, G. Synchronous design and verification of critical embedded systems usingSCADE and Esterel, Springer, 2008

[3] Gaudel, M.-C. Testing can be formal too, Springer, 1995

[4] Hoare, C.A.R. Assertions in modern software engineering practice, Proceedings of theIEEE Computer Society, 2002

[5] Hierons, R. M., Bowen, J. P., Harman, M. Formal Methods and Testing - An Outcomeof the FORTEST Network. Revised Selected Papers., Springer, 2008

[6] Bowen, J., Hinchey, M. G. Seven More Myhts of Formal Methods , Fifth EuropeanSoftware Engineering Conference, 1995

[7] Wing, J. M. A specifer’s introduction to formal methods, IEEE Computer 23,9, 8-24,1990

[8] Bowen, J. Safety-critical Systems, Formal Methods and Standards, Software Enginee-ring Journal, 1992

[9] Austin, S., Parkin, G. Formal methods : A survey, National Physical Laboratory,Teddington, Middlesex, UK. Mar., 1993

[10] Craigen, D., Gerhart, S., Ralston, T. An International Survey of Industrial Applica-tions of Formal Methods., U.S. Department of Commerce, Technology Administration,National Institute of Standards and Technology, Computer Systems Laboratory, Gai-thersburg, MD., 1993

[11] Rushby, J. Formal methods and the certification of critical systems, Computer ScienceLaboratory, 1993

[12] Hinchey, M. G., Bowen, J. Applications of Formal Methods., Prentice Hall, 1995

[13] Glass, R. L. Formal methods are a surrogate for a more serious software concern.,IEEE Computer 29, 4 (Apr.), 19., 1996

[14] Bloomfield, R., Craigen, D. Formal methods diffusion : Past lessons and future pros-pects Adelard, Coborn House, 1999

68

[15] Bowen, J., Hinchey, M. G. Ten commandments of formal methods., IEEE Computer39, 1 (Jan.), 40-48., 2006

[16] Woodcock, J., Larsen, P. G., Bicarregui, J., Fitzgerald, J. Formal Methods : Practiceand Experience, ACM Computing Surveys, 2009

[17] Bowen, J. Formal Specification and Documentation Using Z : A Case Study Approach,Revised 2003

[18] Davies, J., Woodcock, J. Using Z, Prentice Hall, 1996

[19] Wordsworth, J. B. Software Development with Z, Addison-Welley, 1996

[20] Spivey, J. M., The Z Notation : A reference Manual, 2nd ed., Pre’ntice-Hall, Oxford,England, UK, 1998.

[21] Cheng, Chen-Mou, An Operating System Architecture for Embedded Systems : Designand Implementation, National Taiwan University, Taiwan, 1998.

[22] Sauermann, J., Thelen, M. Realtime Operating Systems : Concepts and Implementa-tion of Microkernels, 1995.

[23] Saaltink, M. The Z/EVES System, ORA Canada, 1996

69

Auteur : ANDRIANANTENAINA Zo Ambinintsoa

Titre : MODELISATION FORMELLE D’UN NOYAU POUR SYSTEME

D’EXPLOITATION EMBARQUE ET VERIFICATIONS SOUS Z/EVES

Nombre de pages : 70

Nombre de figures : 17

Nombre de tableaux : 3

Nombre de listings : 12

RESUME

Ce travail de mémoire est consacré aux méthodes formelles. Méthodes basées sur

les mathématiques, elles sont surtout utilisées là où les systèmes deviennent de plus en

plus complexes, et la sécurité une question de plus en plus importante, en d’autres

termes, là où un niveau de confiance totale aux systèmes doit être assuré. Ce document

présente un modèle formel d’un noyau (kernel en anglais) pour système d’exploitation

embarqué conçu à l’aide de la notation Z. Des théorèmes que ce modèle doit

obligatoirement satisfaire sont ensuite vérifiés formellement en utilisant l’outil Z/EVES, et

ceci afin de confirmer que le modèle est consistent et qu’aucune erreur n’a été

introduite.

Mots-clés : Méthodes formelles. Notation Z. Langage Z. Intelligence artificielle. Systèmes embarqués. Systèmes critiques. Noyau. Kernel. Système d’exploitation.

Rapporteur : Mme RABEHERIMANANA Lyliane

Adresse de l’auteur : Cité CREMONT Ivato Aéroport – Antananarivo 105

Mail : zo-ambinintsoa.anantena@moov.mg

Année Universitaire : 2006-2007