Évaluation des logiciels critiques: application à la méthode B

matismes de s&wite mis en oeuvre dans les transports guides suit I’accroissement des performances attendues de ces systemes. Desormais, seuls des dispositifs de commande-controle numeriques, oti la part du logiciel est t&s importante, permettent de satisfaire aux exigences fonctionnelles et de securite de ces systemes. 01; aujourd’hui, le logiciel apparait comme un goulot d’etranglement du point de vue de la sirrete de fonctionnement des systemes informatiques. Le probleme est dir a la presence de fautes de conception introduites lors du developpement du logiciei, tres difficiles et co6teuses a corriger Pour remedier a cela, le developpement du logiciel critique necessite de combiner des m&bodes diversifiees, de maniere h reduire au maximum la presence de fautes residuelies et a s’assurer que le logiciel correspond a ces exigences de s&cut-it8 et de fonctionnalite. L’effort consenti par le fournisseur, pour la quake du jogicie! produit, reste insuffisant Pour garantir qu’il ne presente pas

d’erreurs. En effet, faire &valuer le processus et le produit est devenu un argument du fournisseur, pour assurer le client de la qualite du logiciel. Les normes actuelles preconisent et recommandent de faire effectuer de telles evaluations par un organisme independant.

formelles dans plusieurs industries montre que cette approche est prometteuse, puisqu’elle permet de formaliser la specification, d’expliciter la conception et de simplifier la programmation. En France, dans les applications ferrouiaires, la methode B est utilis&e pour les fonctions critiques. Cette utilisation am&e

Pour ameliorer la qualite et la securite du logiciel, on prone depuis quelques an&es l’utilisation des methodes formelles pour le developpement des logiciels de securite. Ces methodes formelles sont fond&es sur la logique mathematique qui permet de raisonner et d’effectuer des calculs sur le produit a developper Le but de telles methodes est d’obtenir un logiciel zero defaut en appliquant un developpement formel. L.a specification formelle permet de decrire ia !&he h realiser de faGon precise, non ambigue et demontrable. Un aspect, egalement important, est l’elimination des fautes le plus tot possible pour ameliorer le processus de developpement du logiciel. Aujourd’hui l’utilisation des mkthodes

les

organismes charges de donner un avis autorise a &adapter leur approche d’evaluation pour la certification des logiciels de securite d&uelopp& par la methode B.

Duns cet article, nous decrivons une approche

mixte

d’&aluation

du logiciel critique. I1 s’agit, d’une part d’examiner le processus ayant servi a l’elaboration du logiciel, d’autre part de krifier la qualite du produit final (logiciel). Duns une premiere partie, on presentera la situation duns le domaine de la normalisation ferrouiaire du logiciel de s&wit& On presentera les principales techniques d’evaluation, en s’attardant sur la technique utilisee par I’INRETS. Dans la deuxieme partie de ce document

de I’apport des on traitera m&thodes formelles telle que la mkthode B dans le dgueloppement du logiciel de sBcurit& L’aspect de 1’6ualuation du logiciel sera trait& en

Les opkations d’6valuation ont pour r6le de consolider la qualiti! du logiciel par le biais d’examens et d’analyses. Elles doivent Gtre accessibles 2 tout organisme sans discrimination et ne doivent pas &tre condition&es par la taille de l’entreprise ou la quantiti! de produits. L’evaluation d’un logiciel de s&curiti! est une opkration qui consiste en un examen technique, selon un ensemble de critkres, par une entiti! ind&pendante du concepteur [Mitra et CASCADE, 19971. Ces crit&res d’evaluation proviennent des normes en vigueur, de 1’6tat de l’art et de l’expkrience . L’objectif d’une tivaluation est de s’assurer que le produit correspond aux besoins de s6curit6 et de fonctionnalite spBcifi&. La t&he du fournisseur est de produire un dossier de sQcuri% [El Koursi et Le Trung, 19941, par lequel il dkmontre que le produit atteint un niveau de skcurii.6 conforme aux normes en vigueiir. ainsi qu’au cahier des charges de l’utilisateur. La t&he de l’expert charge de 1’6valuation est de s’assurer que le dossier de sBcurit6 pr& sente toutes les garanties de s&urite! spkifi6es dans le cahier des charges. Le but est de se forger l’intime conviction gue les analyses

mettant /‘accent sur l’analyse de la traGabilit6 des exigences, I’int&gration et la ualidation des proprikt&s de s6curit8. On terminera cet article par un aperGu sur /es r.^

de skcuriti!

sont ad6quates et que les risques identifi6s sont complets et ~10s. 11s’agit 6galement de vi?& fier que les normes appropriees ont et6 utiliskes et que les mesures pr& conis&es pour accroitre le niveau de s&urit& ont kti! correctement appliq&es. Cette activitk nkessite de combiner un ensemble de m6thodes, techniques et outils susceptibles d’aider l’expert chargi! de l’kvaluation 2 accomplir sa t&he.

mktriques extraites et interpr&es sur un developpement formel. On fera enfin une prksentation succincte des o&i/s d’extraction de metriques utilises ti I'INRETS.

La normalisation relative aux logiciels critiques est en plein developpement dans le cadre europeen. C’est ainsi qu’un ensemble de normes ([Cenelec, 1993, 1994a et 1995b] et [IEC, 1995fi est en tours d’approbation, ce qui se traduit par de longues et fastidieuses revues et corrections. Pour la plupart, ces normes &oquent et demandent une Evaluation des &ments critiques par une entiti! indgpendante. Une evaluation doit se faire en se rkfkrant & des regles et normes reconnues et adoptees. L’expert charge de l’kvaluation aura alors pour r6le essentiel de vkifier que ces normes sont effectivement bien

Un logiciel de skuriti! est un logiciel dont l’exkcution participe 2 des fonctions impliquees dans la s&wit6 d’un systBme AFNOR 7 l-01 1. L’int6griG de s0ret6 est la probabilitg pour qu’un systkme relatif ?I la sQreti? execute de mani&-e satisfaisante les fonctions de s&ret6 requises, selon les conditions indiqkes et dans une p&riode de temps don&e [[EC, 19951. Plus le niveau d’int6gritG de &ret& des systBmes relatifs 2 la s&-et6 est klev&, plus la probabiliti! de defaillance des systkmes dans I’exkution des fonctions requises est faible. La norme europeenne Cenelec Pr EN 50128 [Cenelec, 1994a] definit cinq niveaux d’intkgriti, de s&-et6 du logiciel. Le niveau 0 est le niveau n’ayant pas de car&&e de &curit& Les quatre autres niveaux (1 & 4) sont relatifs 2 des logiciels de s&wit& le niveau d’intggritk de s&-et& 4 poss&dant le pius haut degrk Les exigences (m&odes, techniques et outils) de diveloppement, de validation et d’&aluation sont les m6mes pour les niveaux 1 et 2. Les exigences (techniques, m6thodes et outils) de d&eloppement, de validation et d’gvaluation sont les m6mes pour les niveaux 3 et 4. Nous nous intkessons dans cet article aux niveaux d’int6grit6 3 et 4.

,.--- --.. --_.--.-._

..-

.- _____

appliquees et que les methodes, techniques et outils prescrits sont utilises correctement. Malheureusement, les normes restent subjectives quant a la maniere d’appliquer telle ou telle memode, presentent des manques dans les exigences specifiees et recommandent l’utilisation de techniques sans expliciter la maniere de les utiliser. L’utilisation des exigences avec lesquelles l’expert peut prononcer la conformit du processus et du produit reste sujette a interpretation [Krebs, 19951. Les organismes de normalisation presentent les normes comme un code qui decrit seulement les bonnes pratiques necessaires a l’elaboration d’un logiciel de securite. De plus, les normes sont orientees processus et il n’y a pas de garantie que le suivi d’un bon processus conduise a la construction d’un bon produit. Une bonne norme doit permettre 21 un expert de determiner aisement si elle a et6 correctement appliquee. En general, il est impossible de determiner objectivement la conformite avec les normes en vigueur. Idealement, les normes devraient definir les argumentations necessaires pour qu’une tierce personne puisse etablir que le systeme evalue est suffisamment de securite [Redmill et Anderson, 19941.

L’evaluation est une activite fond&e sur l’application d’un ensemble de techniques, qui a pour objectif la collecte de donnees significatives et pertinentes. L’evaluation du logi-ciel, de m&me que son developpemerit, necessite de combiner un en-semble de techniques. Celles qu’on utilise pour evaluer le produit sent fondees, d’une part sur l’analyse statique qui consiste 2 examiner le fogiciel sans l’executer, d’autre part sur l’analyse dynamique qui Consiste .$Iexecuter le logiciel et extraire des informations utiles [El Koursi et CASCADE, 19971. L’kva-

----

~^I_-~-~

--

S~‘cURl?‘~

luation du nrocessus de develonnement est fondle essentiellement sur la technique d’audit. L’evaluation d’un logiciel de securite necessite de mener une evaluation orientee a la fois vers le processus et vers le produit. 1

I

Nous decrivons sommairement ici les techniques les plus repandues. * Technique par check-list : l’evaluation est conduite en utilisant une liste de criteres preetablis, laquelle est construite a partir des normes de reference identifiees. Les criteres sont generalement deduits des exi-, gences specifiees dans les normes. Cette evaluation peut etre conduite par du personnel ayant une experience professionnelle moindre que celle d’un expert. 0 Technique par modele : cette technique est utilisee pour evaluer les parties les plus sensibles des logiciels critiques [CASCADE,19951. Elle se fonde sur une analyse critique des documents de specification. L’expert charge de l’evaluation realise un modele du logiciel, dont il deduit un ensemble de tests fonctionnels. Cet ensemble de tests, enrichi par des scenarios tires de l’experience vecue et des tests des fonctions non modelisees, sera passe sur le logiciel. L’examen des resultats, men6 en relation avec la specification, fait l’objet d’un rapport d’evaluation. Les conclusions tirees de ces tests sont analysees et renforcees par les verifications internes produites par le constructeur. e Technique de test par element : cette technique est fondee sur la participation de l’expert charge de l’evaluation aux tests de validation du pro duit. Elle consiste 2 effectuer un examen des tests par echantillonnaye. * Technique mixte : appelee aussi technique ouverte, elle est fondee sur l’utilisation d’une check-list OUverte. tenant compte de l’experience de l’expert charge de l’evaluation. Cette technique, avec un protocole simple, permet % l’expert

ii---I_-

KtCHtKCHt

DES AUTOMA1‘lSMES

charge de l’evaluation d’explorer les elements interessants necessitant plus d’investigation. Cette technique est generalement conduite par des evaluateurs experiment&. L’evaluation des systemes de protection automatique des trains pratiquee par ~‘INRETS[El Koursi et te Trung, 19941 s’appuie sur une approche globale qui integre les quatre techniques. Elle est focalisee, pour l’evaluation du logiciel, sur la technique de mode/isation combinant /‘aspect processus et produit [Stuparu, 19941. Differentes techniques, telles que semiformelles et formelles, ont et6 utilisees par ~‘INRETSpour modeliser les logiciels de securite install& dans les systemes de protection automatique des trains. La combinaison de ces methodes (Reseaux de Petri [El Koursi et Ozello, 19921, Lustre [Bied-Charreton et ChopardGuillaumot, 19941 et ASA [Stuparu et al., 19941) couvrent les principales possibilites pour une modelisation du logiciel. Par exemple, une modelisation independante du logiciel de MAGGALY (metro automatique a grand gabarit de l’agglomeration lyonnaise) a eti! utilisee comme une technique complementaire pour l’evaluation [Stuparu et al., 19931.

Pour chaque activiti! d’evaluation, il est indispensable d’identifier la nature du produit a evaluer, son contexte d’utilisation et les limites de l’evaluation. Le niveau de l’evaluation doit tenir compte du niveau de risque presenti! par le produit, Ie plan et les normes de references doivent &tre precises et accept& par toutes les parties impliquees. La procedure d’evaluation ([Mitra et CASCADE, 199’71 et [El Koursi et CASCADE, 19971) doit fournir les informations relatives aux activites a entreprendre durant une @valuation. La proc8dure doit permettre de guider le praticien dans la preparation des activites. L’ob-

TKANSPORTS SfCURlTi N‘ 58

JANVIEK-MAK5 I998

jectif d’une bonne prochdure est de permettre de reproduire l’evaluation - elle doit pouvoir etre reproduite par tout organisme qui appliquerait les meme procedures et criteres. Pour mener a bien une evaluation, on distingue quatre activites. * Redaction du plan de l’evaluation. Ce plan devra detailler les differentes activites d’une evaluation. I1 doit en identifier precisement l’objectif, les contraintes, l’organisation, les responsabilites. I1 doit egalement enumerer les methodes, les techniques et les outils a utiliser. e Specification des besoins de l’evaluation. Ce document vise a identifier et definir les exigences pour l’evaluation. I1 doit rappeler l’objectif et les contraintes, identifier le produit a evaluer, preciser le cadre et enumerer les normes utilisees. Ce document consiste pour l’essentiel a elaborer et decrire les criteres a utiliser et a definir la procedure pour repondre aux criteres et la maniere de resoudre ou clarifier toute nonconformite. 0 evaluation du produit et du processus. L’evaluation du processus s’assure que les activites liees au developpement du produit et supports sont appropriees aux normes applicables et qu’elles sont bien appliq&es et suivies par le constructeur. L’objectif de l’evaluation du produit est de s’assurer que les fonctions de securite sont completes et coherentes avec les exigences de securite au niveau systeme. Elle vise egalement a verifier que les fonctions de securiti! sont correctement construites et implant&es. e Production d’un rapport d’evaluation. 1-e rapport d’evaluatioin doit presenter les raisons pour Icyquelles le prod& ou le processus a ete rejete ou accept&. I-es criteres utilises durant l’evaluation doivent etre fournis selon un format accepti! par toutes les parties impliq&es. Le rapport doit enumerer les

RFCI IFKCtlt

IKAN5POKI 5 5kilKl

ri N” 58

non-conformites recommandations l’evaluation.

constatees et les generees par

Le plan et la specification detailks des besoins de l’ivaluation~sont les elements essentiels pour toute evaluation. Ces deux documents devront 6%e valid& et accept& par le client.

s La specification de l’evaluation doit contenir un ensemble de criteres d’evaluation, avec lesquels l’expert doit prononcer la conformiti! du produit ou du processus a une reference (norme, specification.. .). I-es criteres doivent 6tre produits a partir de norrnes applicables et en tenant compte de l’experience des utilisateurs. Ces crit&es doivent couvrir toutes les

TABLEAU Exemples

de crithes

d’un logi-

Quand cela est possible, la provenance de chaque critere doit etre precisee, de maniere a retrouver la reference d’origine. Ces crit&es sont par la suite raffines en des criteres specifiques selon l’application. Le constructeur du logiciel doit apporter la preuve de la satisfaction des criteres, afin que l’expert charge de l’evaluation puisse prononcer la conformiti! au referentiel. 11est a noter que le jugement n’a que deux attributs, a savoir critere satisfait et critere non satisfait. Les critere< qui peuvent Qtre de deux types, generique ou specifique, sont present& dans le tableau 1.

1 g&Priques

1

Les besoins logiciels doivent &ire identifiks, analyds, trac&s, contn%s et formellement dkcrits dans un document de r&f&ence en rapport avec le niveau d’inkgrik? du logiciei {Mitra et CASCADE,19971, [El Koursi et CASCADE.19971

2

La rigueur du processus de d&eloppement doit Btre en rapport avec le niveau d’int6grif du logiciel (norme Ceneiec 501281

3

La spkification des besoins logiciels doit &tre Claire, non ambiguc, compkte. rlalisable, vhifiable et trqabie par rapport B la spkification fonctionnelle de !‘6quipement [Mitra et CASCADE, 19973 et [El Koursi et CfWADF~ l%7]

4

Le l&iciel doit avoir un niveau Li‘inttgritB (nor me Ceneiei 50128)

L-a colonne spkifiques. La colonne La colonne certdicat de La colonne La colonne

phases de developpement ciel de securite.

1 dkigne le nurn&o du crithe. Ce crith peut &tre rdffine en plusieurs critkres Par exempie, le critke Cl donnera des sous-crittires Cl 1. C12, C13.. 2 prkise i’intitulh du crith. 3 indiquera la ou les preuves apportQes par ie constructeur (document, dhonstration. qualit@.. j. 4 precisera si le critBre est sdtisfait ou non. 5 contiendra un commentaire relatif a la satisfaction du critkre.

JANVICR-MAR5 ,998

-I_~-

notation (AMN pour Abstract Machine Notation). L’implementation de base est appelee BO. Elle permet une traduction automatique de la specification en code c ou ADA. Les m&odes

formelles, qui ont connu un essor important durant ces dernieres an&es, peuvent contribuer a la fois a la prevention et a Teliminatjon des fautes dans le logiciel. La methode B, developpee par JR Abrial [1996], est we methode formelle fondee sur la construction de modeles (par opposition a celles fondees sur une technique algebrique). Par rapport a d’autres methodes voisines et plus anciennes (z, VDM), elfe possede la caracteristique de couvrir tout le cycle de developpement du logiciel, depuis la specification jusqu’a la generation automatique du code source. La methode B est une methode de developpement fondee sur une mise en axiomes explicite de la theorie des ensembles. La methode de developpement est fondee sur des theeries mathematiques completement explicitees : la theorie des substitutions generalisees, la theorie du raffinement, la theorie de la construction de logiciels en couche. La definition de la dynamique des systemes ne se fait pas au moyen d’un predicat avant/apr&s, mais a partir dune generalisation de la notion de substitution, fondee sur la theorie des transformateurs de predicats. La rnethode B contieni. un mecanisme de structuration (composition/d&composition) qui est la machine abstraite (transformee au COLKS du developpement en raffinemerit puis en impl6mentation). La technique procede par raffinements successifs (concretisation) de modeies abstraits, que l’on compose pour former l’architecture globale du logiciel. Cette methode formelle, par raffinements successifs de la specification de haut niveau, permet d’aboutir a un composant susceptible d’etre directement implement6

-----m_xw--

-_

~-~--~~-~

----_.I-_XI----

Pour plus d’informations sur la methode B et les techniques formelles, l’ouvrage Arago 20 [1997] de l’observatoire franGais des techniques avancees est un document b consulter.

en langage de programmation. Une specification B (figure 1) est constit&e dun ensemble de composants de differents niveaux d’abstraction : - le niveau le plus abstrait appele Machines abstraites,

;#$)?l$&&i,:.r ,i.s,
- un ou plusieurs niveaux de raffinement note(s) Raffinements, - le niveau le plus concret appele Impl&mentations. Developpement et verification sont intimement lies, des preuves de coherence etant effect&es entre les differents niveaux de raffinement. La methode B permet de decrire le systeme % differents niveaux d’abstraction en utilisant une seule

Processus

de de’veloppement

D6veloppement Specification des besoins

du logiciel

par

L’intQet dun developpement par la methode B est d’aboutir a un code fide/e a la specification, autrement dit de garantir qu’il n’existe pas de contradictions entre le concret (code source) et l’abstrait (specification formelle). Le processus de developpement d’un logiciel par la methode B, bien qu’utilisant des techniques et des outils specifiques, peut Btre de-

la me’thode

formel technique logiciels

B.

Ddeloppement

I

classique

vi

lnformei

pition

prf+liminaire

Formel

r

Machines

8 2 I

“L

--.---g,

Raffinements

“i-----

lmpl6mentations,

-A

I

_-,--II

RECHtKCHt

Code

IRAtv5t’OKTI

5iCLIKlr~

N” 58

JANVltK-MARS lYY8

]

composi!

en trois phases comme processus de developpement classique. dans

Le raffinement

La spkification

des besoins

Cette phase consiste en la production d’un document initial qui pr6cise les besoins informels du logiciel. A ce stade, la sp&ification peut $tre fond&e sur des techniques de type semi-formel ou orienti! objets permettant d’identifier clairement les services attendus du logiciel. La sp&cification des besoins logiciels doit &tre aussi simple et abstraite que possible, de maniere 2 permettre une validation classique de la spgcification formelle B et & concentrer les efforts sur la validation formelle par preuve des ktapes ult& rieures jusqu’au code. La sp6cification technique des besoins logiciels doit respecter certaines contraintes dans le but d’assurer plus tard une bonne traGabilit6 avec le modQle formel. Cette phase est terminee lorsque toutes les exigences du niveau gquipement ont gte introduites au niveau des besoins logiciels. La spikification

Cette phase est un raffinement de la sp&ification formelle. Elle consiste en un ensemble de composants formels structur& (machines, raffinements, implantations). Tous les raffinements ont & d&rits et prouv& La traCabilit6 avec la specification formelle est assur6e par des preuves de raffinement. Cette t&he peut &tre consid6r6e comme la phase de conception &tail/6e du developpement classique. Elle se termine lorsque la conception formelle peut Gtre automatiquement traduite en langage de programmation (code). C’est une implantation du modele formel. La phase de codage est assez alI6gke dans un d&eloppement formel. En effet, dans la mi?thode B, soutenue par l’atelier B, le code est g&n&i! automatiquement. Les sorties des trois phases sont soumises 21revue et inspection, pour validation par le constructeur. I1 est 2 noter que, pour rkussir la preuve, les rBgles rajout6es doivent subir un examen particulier.

formelle

Cette phase consiste en un ensemble de composants formels structur& (machines, raffinements et implantations). Des raffinements peuvent 2re dgcrits dans cette phase pour mieux identifier certaines imp& mentations. La preuve de ces raffinements se fera dans la phase suivante. C’est une traduction. des exigences en langage formel. A ce stade, on dispose de l’architecture, sous forme d’arbre, identifiant tous les composants du logiciel. Le passage de la spgcification des besoins logiciels 2 la spgcification formelle peut par cons& quent &tre assimile 2 la phase de conce@ion p&lirninaire du developpement classique, Celte phase se ler-mine lorsque toutes les exigences informelles sont prises en compte dans le mod&Ie formel, que tous les composants sont bien identifies et que toute la preuve est faite.

l’atteste l’hmergence d’une communautf? B animee par I’INRETSh travers

un

La m& thode B est actueilement utilis&e pour le developpement de logiciels critiques dans le domaine ferroviaire fran@s. Elle est egalement susceptible d’int6. resser d’autres domaines (nucleaire, militaire, transport a&ien.. .), comme

La sp&ification formelle B couvre largement le cycle de developpement du logiciel en s’appuyant sur les techniques de preuves math&

le Bug B User Group (I), qui regroupe cent cinquante utilisateurs. Cette mgthode a Gt6 utilisee dans les systBmes de transport KVB-KVS, CTDC, LST [Dehbonei et Mejia, 19951 et METEOR [Behm, 19961) et dans des applications IBM (crcs). Elle est utiliske actueliement, par differentes organisations, 2 titre expgrimentai ou sur des applications en tours de d&eloppement dans le domaine du nucleaire, de l’ai?ronautique et des t&?communications [Bieber, 19961, [Arago, 19971. Dans le cadre du programme ASCOT(AutomaJismes de &curiti! et systgmes de contr8le-commande dans les transports guides), les diffsrents partenaires ferroviaires ont coop&+ efficacement pour consolider l’atelier franGais qui soutient la methode B. L’atelier B est commerciaIi& depuis janvier 1995. La m& thode B est actuellement soutenue par les grands acteurs du ferroviaire, RATP,SNCF, GEC-ALSTHOM,CS-Transport, MATRA-Transpqrt international. Certains industriels proposent dej& des produits d&elopp& avec la methode. Aujourd’hui, les partenaires s’int6ressent 2 la normalisation d’une teile methode et un groupe de travail a 8th mis en place 2 cet effet. (1) Site du B User Group : http ://estasl inrets.fr :8001/EWGhome.html

matiques pour les vf?rifications aux diffgrents stades de d&eloppement. Dans le domaine de l’&valuation, il n’est pas concevable de se contenter

----

SECUKi'l'fi

_.~ -~~_-

de ces techniques de v8rification pour attester qu’un logiciel rgpond aux exigences fonctionnelles et de s&curiti! et qu’il est exempt de fautes. Nous avons mis en place une technique d’6valuation pour les logiciels de s6curiti! d@velopp& h l’aide de la methode B. Cette technique a &t6 validee sur des ktudes de cas dans le cadre d’un projet europken esprit denomm6 CASCADE ([Mitra et CASCADE, Koursi et 19971 et [El CASCADE, 19971) Cette technique, fond8e sur 1’6valuation du produit, comprend des analyses statiques incluant l’activiti! de preuve, ainsi que des analyses dynamiques. Elle est renforke par un audit permettant d’kvaluer le processus de dkveloppement.

FIGURE

DES AUTOMATISMES

2

ivaluationdu

logiciel critique de’veloppe’ par la mgthode B

Pour l’&aluation du produit (voir figure Z), quatre activik ont 6t6 util&es, 2 savoir : - l’analyse de la traqabilit6 des exi-

gences,

FIGIJRF

3

Analyse statique par /a technique SADT

- la formulation, integration et preuve des propri&s de skcurit&,

Et-&F

- l’elaboration de scenarios de test compkmentaires, - les metriques (mesures logicielles). MBcanismes

Nous allons h prksent expliciter ces quatre activitk.

Une des exigences de base pour 1’6valuation d’un d&eloppement formel est la traGabilit6 entre la spkification informelle et la spQcification formelle. La tra~abilit~ est la propri& d’une entitk? permcttant la restituHon ou la m6morisation de tout ou partie d’une trace des fonctions accomplies : du point de vue de l’utilisation et du d&eloppement (trac;abiliti! entre ies phases de developpement, documents.. .).

----

~_.~‘”

-,--.

-.“-.-I

----.-..

L’examen de la traGabilit6 des exigences fonctionnelles et de s&&i! est effect& par une analyse structurge des spkifications des besoins logiciels. Cette technique permet de r&6ler les incoherences des spkifications, et de se faire une id6e globale de l’aspect structure1 du syst8me. 11 existe diffkrentes mgthodes d’analvse structu@e qui permettent une anal& descendante. On se propose d’utiliser Ia technique SADT (pour Structured Analysis Design Techniques) qui permet d’glaborer des spkifications fonctionnelles et de verifier par maquettage rapide qu’elles kpondent bien aLu( besoins. A partir de documents de spkification, on peut construire une analyse structurke en suivant la

l^_.-^___l-*~.--...

RKHFRCI

dkomposition en fonctions et sousfonctions du syst&me, ainsi que la des-cription des don&es en entree et en sortie de chaque fonction. On obtient alors un r&eau d’interconnexions de fonctions, rekes par les donnkes qui circulent (figure 3).

Une analyse struck&e de la sp& cification des besoins logiciels par mod&sation peut mettre en kvidence des incoh&ences externes par rapport aux documents, par

ICTRANSPORTS SiCURlTi

N’ ‘58 JANVIER-MARS ,998

--

examen des diagrammes par rapport a la documentation amont (specification fonctionnelle de l’equipement) et aval (specification formelle B : Machines, Raffinements et Implementations). On peut egalement detecter d’eventuelles incoherences internes de la specification des besoins logiciels. On peut ainsi reveler des probkmes de tracabilite entre la specification des besoins concernant par exemple : - l’absence des exigences exprimees au niveau des equipements (donnees, fonctions.. .),

- les liens fonctionnels ont. ete pris en compte dans le modele,

- les proprietes globales ont eti! prises en compte dans la specification,

- le flux de donnees &hang6 bien decrit dans le modele.

- la specification des besoins logiciels est coherente en interne (pas de contradiction dans le document) et en externe (pas de contradiction par rapport a d’autres documents).

est

Cette analyse de tracabilite devra donner lieu 2 une matrice de tracabilite presentant, pour chaque exigence informelle, le diagramme SADT associe et la description formelle en B. Cette matrice de tracabiliti! sera completee par les analyses effect&es dans les activites d&rites ci-dessous. Elle constituera le document de reference qui accompagne toutes les phases de developpement B .

- la non-prise en compte, dans le modele B, des exigences de la specification, - des donnees en entree de certaines fonctions qui n’apparaissent pas en sortie des fonctions dont elles sont censees provenir, - des donnees en sortie de certaines fonctions qui ne se retrouvent pas en entree des fonctions auxquelles elles sont normalement destinees, - une contradiction sur le flux de donnees, certaines donnees, definies de securite, devenant fonctionnelles par exemple.

duns la sp~c~~icut~~~ formelle

La prise en compte des exigences de securite est le fondement du developpement des applications de securite. Pour valider la completude et le suivi des etudes de securite, on propose d’expliciter les exigences de securite sous forme de proprietes et de verifier qu’elles ont et6 integrees et prouvees dans le modele B.

Le principe de formulation des proprietes de securiti! consiste en une succession d’etapes.

- toutes les fonctions ont et6 modelisees sous forme de composants B, .- toutes les exigences et contrainies de securite ont ete implementees dans le modele,

* Un examen de la specification des besoins logiciels afin de verifier que :

RFCHtKCHE IKANSPORTS ~tCiJRiT~ N” 58

Pour la formulation des prop&. tes, on propose de ne pas utiliser la specification formelle, de maniere a dissocier le d&eloppement formel et la validation de la prise en compte des proprietes par une entite independante. Nous donnons ci-dessous une propriete de securiti! (determination dun test des capteurs a exploiter), extraite de la specification des besoins logiciels. test-capteur = V-rot-rph-indet = TRUE or ((V-rot-rph-indet = FALSE) & (VProt-rph I CO-seuil-valid-vit-nul))

Formulation des propri&?s de s&urit&

@ Une analyse des specifications fonctionnelles des equipements. Le but de cet examen est d’identifier les proprietes de type global pouvant couvrir plusieurs fonctions logicielles ; ces proprietes sont a un niveau abs trait, et peuvent par la suite Qtre decomposees en plusieurs proprietes specifiques a integrer dans les font tions logicielles correspondantes.

Cette phase d’analyse statique s’appuie sur l’examen de la specification formelle (conception preliminaire) en prenant pour reference le diagramme SADT de la specification des besoins logiciels. Le but est de verifier que :

l Un contrble du lien entre les analyses de securite et la specification dans le but de verifier l’adiiquation de ces proprietes avec les criteres de securite generes par les analyses de &write.

,AN”,tK-MAKS

,998

nt&g=ation et ~reuv des propri&t& de s&curit& Apres avoir mis en evidence les proprietes de securite, l’objectif essentiel est d’effectuer la preuve de ces proprietes dans la specification formelle B correspondante. Selon le type de proprieti!, deux strategies de preuve peuvent &tre envisagees. M Darts certains cas, les proprietes de securite proposees possedent un champ d’implantation qui couvre plusieurs fonctions ou sous-fonctions. La technique envisageable pourrait etre alors une validation transversale. I1

.-

s’agit de greffer artificiellement sur le projet en tours, une ou plusieurs machines B, dans lesquelles sont exprimees de facon brute les proprietes souhaitees. Ces machines sont reliees au projet en tours, de telle sorte qu’elles aient une visibilite sur les entit&s impliquees dans l’expression de proprietes. Les demonstrations des obligations de preuves constitueront ainsi la preuve de la validite des propri&t&s. Cette technique presente lavantage d’etre facile a mettre en Quvre ; en revanche, il n’est pas sQr que les proprietes s’expriment facilement en fonction des entites deja definies dans le projet. Le lien entre les proprietes globales et les entites deja ecrites n’est pas aise a trouver. *

lidation

ou preuve

verticale

Cette technique consiste a decomposer la propriete globale ou abstraite en sous-proprietes implementables directement dans les machines B. En d’autres termes, il s’agit d’injecter les proprietes voulues dans les machines deja existantes. Cela suppose done que chaque propriete puisse Gtre eventuellement reformulee en plusieurs sousproprier6s, reparties dans des machines differentes. Cette technique presente l’avantage de ne pas ajouter de machines supplementaires. La difficult6 reside dans la preuve de l’equivalence entre propriete globale et ensemble de sous-proprietes. 11est indispensable que cette equivalence soit demontree.

fonctionnels peuvent etre deduits des proprietes de securite [Waeselynck et Boulanger, 19953 pour valider le logiciel par rapport a sa specification. Les proprietes sont des expressions iogiques qui exprirnent des liens logiques entre etats et ne pertnettent pas d’exprimer des contraintes temporelles et de sequentialite. Pour resoudre cette difficult&, un ensemble de scenarios peut &tre ajoute pour completer le role des proprietes.

- - - - - - - -

- _

S~CUHKI7‘fi

mBtrique peut etre definie comme un nombre derive d’un produit, d’un processus ou dune ressource [Fenton, 19921. Cela signifie qu’une mesure concernant un logiciel permet de caracteriser le logiciel luim6me ou le processus qui l’a produit. La collecte de mesures du logiciel est recommandee par les normes et la bonne pratique. De plus l’objectif de la collecte des mesures n’est pas simplement d’avoir des indicateurs pour l’evaluation predictive de la &ret@ du logiciel, mais aussi de fournir un moyen d’identifier les parties critiques du developpement et de la validation. Plusieurs raisons justifient la collecte de mesures :

- les mesures peuvent Btre utilisees pour controler le processus de developpement, pour en ameliorer la qualite, pour reduire les ressources necessaires et les efforts par consequent diminuer le tout, - les mesures peuvent permettre de prevoir, a partir de la capitalisation d’experiences precedentes, les besoins en ressources pour les phases ulterieures du projet et d’evaluer la performance du personnel (programmeurs), -- les mesures peuvent etre utilisees pour orienter le travail de validation ; les donnees collectees peuvent indiquer par exemple les parties ou zones du programme qui necessitent plus d’operations d’inspection et de revue, .- les mesures peuvent Btre utilisees pour guider les operations d’evaluation externe ; elles peu vent indiquer de surcro?t des non conformites mineures ou rnajeures aux specifications des besoins logiciels , -- les mesures permettent d’evaluer l’adequation du produit aux normes de qualiti!, done la confiance qui peut lui etre accordee,

DES

ACJTOMATlSMES

- les mesures peuvent 6tre utilisees pour motiver des ameliorations de la methodologie de developpement du logiciel ; elles peuvent par exemple servir au choix d’une methode par rapport a une autre en comparant les donnees. L’utilisation accrue des methodes formelles dans les developpements industriels s’accompagne dune transformation des problemes de genie logiciel en problemes de genie formel. Dorenavant les problemes ne concerneront plus la manipulation de programmes, mais la manipulation de specifications formelles. Cette evolution concerne aussi bien les activites de documentation ou de gestion de version, que la validation ou l’evaluation.

Types de mesures ir extraire duns Ze cas de la mkthode B Dans le contexte de l’evaluation, l’utilisation des techniques de mesure doit etre adaptee aux specifications formelles. En effet, avec l’introduction de concepts nouveaux comme le non-determinisme, les notations mathematiques et la preuve, les attributs que l’on souhaite mesurer ont largement 6~01~6 et il est done necessaire d’elaborer de nouvelles mesures. L.es mesures adaptees a la methode formelle B que nous proposons [Mariano, 19971, sont definies dans un cadre comprenant : - un objectif &valuer ?

--

que souhaite-t-on

une definition. --- quelle mesure peut-on utiliser 3 ._ une procedure d’extraction comment extraire la valeur ?

^--

- un critere - quelles sont les valeurs acceptables ou interdites ? - une iocalisation ---- quand doit.-on appliquer la mesure ?

Nous avons dhveloppk un outil permettant I’extraction automatique de mesures 21partir d’un dgveloppement B. Cet outil se denomme BEST (pour B Enhanced Specification Tool). Nous rksumons ici les diffkrentes classes de mesures que nous pouvons utiliser : - mesures relatives 2 la taille du projet 03 j - mesures ration (S),

relatives

2 la structu-

- mesures relatives 2 la phase de preuve (P), - mew-es relatives 5 la complexit& (C), mesures relatives globale (Q).

2 la qualiti:

Les mesures adapt6es 2 la m&thode B peuvent done 6tre extraites en utilisant l’outil BEST, ceci afin de donner une vision g&&ale de la quaIit6 du produit. Le tableau 2 donne des exemples de mesures appropri6es pour 1’Bvaluation d’un projet B. La liste ne peut 2tre exhaustive et d’autres mesures sont ajoutkes 2 mesure que s’accroit notre experience des d&eloppements B.

Types

de mew-es

I1 est 2 noter que l’utilisation des mesures ne doit pas etre absolue. I1 est nkcessaire d4nterpr6ter les valeurs en les plaCant dans le contexte particulier du produit correspond&t. I1 est possible que des mesures rie soient pas adaptees 2 un d6veloppement spkifique ou que le critBe correspondant doive dtre modifik Le processus de developpement B est cadence par des phases de preuve qui constituent une vkification interne des spkcifications. L’gvaluation de ces phases repose sur l’examen des obligations de preuve (que doit-on prouver ?) et sur les preuves effectukes. Les obligations de preuves sont automatiquement g6n&kes par un outil sp&iali&. I1existe un lien direct (syntaxique et m&anique) entre le texte des spckifications et le texte des preuves correspondantes. C’est pourquoi l’Gtude des obligations de preuve donne une &aluation de l’adequation entre les sp6cifications formelles et la m&thodologie B. En effet, selon cette derniere, une bonne spkcification B se caract& rise par des preuves simples et peu nombreuses. Apr& la phase de g&&ation des obligations de preuves, on utilise un

demonstrateur automatique qui, 2 l’aide de techniques de preuve classiques [Abrial, 19961, effectue (ou dkharge) une partie des obligations de preuves. A la suite de cette phase, il reste en g&%-al un certain nombre de preuves 5 apporker manuellement. En relation avec la remarque m@thodologique pr& cedente, signalons que le rapport entre le nombre de preuves Wssies (automatiquement) et le nombre de preuves qui reste 21faire, constitue un premier indicateur de qualitk. Les obligations de preuves, non remplies automatiquement, peuvent rk@ler deux probkmes : soit l’khec est la con&quegce d’une mauvaise spkcification, qu’il convient done de modifier ; soit l’khec est la cons& quence d’une insuffisance de l’outil de preuve (prouveur automatique), qu’il convient done de combler. Pour pallier cette insuffisance, on enrichit la base de rBgles par des rBgles ajoutkes, qui permettent de prouver les obligations de preuves restantes. De point de vue de l’kvaluation, nous nous concentrons sur la deuxi&me possibiliti!. L’extension de l’outil de preuve se fait simplement

A extraire

Nombre de lignes B Annotations PO Variables

Longueur des composants (machines, raffinements.. .) Rapport lignes B/lignes de commentaires Nombre d’obligations de preuve Nombre de variables d&finies dans un composant

Taille (T) Qualit& (Q) Taille (T) Structure (S) Tailie (T)

Invariant

Longueur de la clause ~N~jA~I~~T

Skacture

Sees Import ANP GIEL

Nombre de composants *vus Nombre de composants import&s Nombre de PO prouvkes automatiquement Complexit& intuitive des expressions logiques

LARA

Rapport rBglesajout&es/preuves interactives

(S)

Preuve (P) “Z. Structure (S) Structure (S) Preuve (P) Preuve (P) Complexit (Z) Preuve (P)

-

-----

-

TABLEAU Extrait

de critfkes

--

-~___-I

SECUR!TE

DES

AUTOMATISMES

3 re/atifs

,i /‘&a!uation

de /a phase

de vk’ification

et de va/idation

du /ogicie/

4.5.1.1.

La spkification formelle doit &e (trasable) & partir de la spkification des besoins logiciels.

Documents de preuve formelle.

4.5.1.2.

Tous les codes sourcesdoivent &re revus. La rigueur de la revue doit Btre en rapport avec le niveau d’int&riti! du logiciel [Mitra et CASCADE, 19971 et norme Cenelec 50128

Les sources, dossiers des revues. 1

4.5.1.3.

Le logicieldoit &re in&& ( avec d’autres logicielset materiels) en utilisant des procedures de tests appropri~es. La d&monstration que toutes les parties respectent les protocoles d’ichange doit gtre faite. L’intkgration doit &tre considkke comme une partie du processusde test et &e planifike, contr@e et les rksultats enregistk dans une forme accessibleet verifiable [Mitra et CASCADE, 19971

Les diffkrents plans et dossiers de test

4.5.1.4.

Le processus d’intkgration doit &tre documentk de manike B identifier la configuration et la mkthode utikes, les tests conduits et les rksultats obtenus.

Dossiers de test et plans

par I’ajout dune rBgle spkifique a la preuve ZIeffectuer. Cette rkgle suppk mentaire sera int&g@e 2 la base de &gles lors- de la tentative de preuve suivante. Evidemment le risque d’introduire une rggle mathkmatiquement fausse est important, qui conduirait h dkmontrer b tort une obligation de preuve. L’gvaluation d’un developpement B par rapport aux critkes de sQreti! de fonctionnement doit prendre en compte ce facteur. Pour cela, il est possible d’utiliser la mesure LARA, dkfinie par : LARA = RA/PI avec RA le nombre de r&gles (sp&fiques) ajouthes pour aider % faire la preuve, PI le nombre de preuves interactives B faire. La valeur limite prkconisee pour celte mesure [Ivlariano et El Koursi; 19961, peut &re dkfinie en envisageant de transformer toute obligation de preuve non prow&e en une ri?gle rajoutOe sans vkrification supplementaire. En conskquence, si le rapport LARA (voir tableau 2) est sup&ieur 2 I (plus de rBgles ajouti?es que d’obli-

gation de preuves B faire), pour une projet dGvelopp8 en B, nous pouvons conclure que le travail de preuve n’a pas 6te maTtris& NQanmoins, localement, faire la preuve d’un lemme peut nkcessiter l’ajout de plusieurs rkgles, qui permettent de prouver d’autres lemmes. C’est done une moyenne que nous proposons dans le cadre de la totaliti! d’un projet.

L’objectif d’une kvaluation du processus est de vkifier que le processus mis en place pour le d&eloppement du logiciel est conforme % des normes applicables et que les procgdures de qualit soni effectivement utilisges. Cette evaluation est fondke sur la technique d’audit et d’inspection, ainsi que sur l’application d’un ensemble de crittkes extraik des normes et de 1’6valuation du pro duit. Elle couvre : - le processus de conception qui intkgre la modglisation formelle, le processus de raffinement et la traduction du modgle en programme c ou ADA,

- le processus de verification et de validation utilisi! dans toutes les phases de d&eloppement, - le processus de validation taire du logiciel,

securi-

- l’organisation des equipes mises en place pour construire et valider le logiciel. Le principe consiste B examiner, par inspection, la sp&ification des besoins logiciels, l’architecture du logiciel, le mod&le formel, les obligations de preuves, les r&gles rajoutkes, le code source, la spkification et les r&. sultats des tests, les analyses de s&urite et les diffkrents plans et outils de d&eloppement. L’evaluation de d&eloppement et de l’organisation mise en place se refke aux differents plans. Les c&&es utilkks writ pr6sent& s;ous la forme dkn tableau 6 cinq colonnes et couvrent les diffkentes phases de di?veloppement du logiciel. Le tableau 3 donne un exemple synthi?tique des critkes relatifs & l’&aluation de la phase de v&ification et de validation du logiciel.

besoins logiciels et la spQcification formelle, -.

onclusion L’evaluation d’un logiciel de s&uriti! n&essite de combiner des techniques et de diversifier les approches, dans le but de s’assurer que le produit final r6pond aux exigences de s&urite et de fonctionnalit6. L’objectif d’une telle &valuation est de vgrifier la coherence, la compl&de et la consistance des arguments (analyses, tests, inspections, revues.. .) p&sent& par le constructeur dans le dossier de s&uriti?, pour confirmer que l’approche est conforme aux normes et que les techniques et les outils utilis& sont appropri& et ont 6% bien employ&. Les exigences stipulees dans les normes europeennes preconisent de recourir & une entite indBpendante pour effectuer de telles &aluations. Ces normes identifient un ensemble de techniques 2 utiliser pour verifier que le logiciel, d&elopp& par les m6thodes classiques, est conforme 2 sa sp6cification. Cependant, l’apparition des m6thodes formelles introduit une notion supplkmentaire, h savoir la preuve math&matique. Celle-ci doit permettre d’eliminer les fautes r&siduelles de conception dans les logiciels. Cette donnge nous a amen& a developper une approche nouvelle pour 1’6valuation du logiciel de s&curit& en vue de certifier qu’il est conforme 2 sa sp&ification. Dans cet article, 1’6valuation du produit et du processus d’un d&eloppement formel a 8% prGsent6e en combinant I’analyse statique, l’extraction et la formulation des prop+% de @curit& l’utilisation de scenarios complQmentaires et le recours aux mQtriques. Dans le cadre du projet CASCADE, cette approche a 6tB employ&e et a montre que la combinaison de ces techniques est une bonne solution pour 1’Qvaluation des logiciels de s&urit& Aujourd’hui, on peut dire

que les mkthodes formelles, telle que la methode B, qui renforcent l’aspect de vkrification fondee sur la preuve, constituent une solution viable pour l’amelioration de la qualite du logiciel. L’utilisation des methodes formelles favorise l’expression des propricit6s de @curit@ et l’analyse de la traqabilit6 des exigences de s&zurit& La difficult6 de valider le passage de la sp& cification initiale 2 une sp&cification formelle peut $tre contourniie par : - l’utilisation des commentaires appropriks permettant de retrouver la trace des sphcifications initiales, - la constitution d’une matrice de traGabilit& entre la sp&zification des

- l’utilisation d’une liste de propri& t& de sBcurit6 avec une r&f&rence croisee indiquant leur provenance et leur emplacement dans la spkcification formelle ; ce document doit &re annex6 ?I la spgcification formelle. Les mesures, pr&ent&es dans cet article, permettent de suivre l’&olution de la qualit du logiciel. Elles permettent d’kvaluer la complexitg, la taille et la qualiti! de d&eloppement du logiciel critique. Cependant, nous devons noter que l’utilisation des mesures ne doit pas &re absolue. 11est nBcessaire d’interpreter, globalement, les valeurs en les plaGant d&s le contexte particulier du produit correspondant. I1 est possible que certaines mesures ne soient pas adaptees & un d8veloppement spgcifique ou que le critBre correspondant doive &re modifi6.

Abrial J.R. - The B Book-Assigning Programs to Meanings, Cambridge University Press, aoM 1996. Arago - Arago 20, Application des techniques formelles au logiciel, Observatoire fran$ais des techniques avanckes, Paris, juin 1997. Behm P. - Application dune mgthode formelle aux logiciels sgcuritaires ferroviaires, Sixiemes Journges internationales du genie logiciel, Atelier du logiciel temps rkel, 1993. Behm P. - Formal development of safety critical software of METEOR, First conference on the B Method, Nantes, France, 24-26 novembre 1996. Bieber P. - InterprQtation d’un modele de s&curiti?,Techniques et sciences informatiques, vol. 15, no 6, avril 1996 Bied-Charreton D., Chopart-Guillemot G. - Verification of the software requirements specifications of block signal sysm tern with help of the language Lustre, World Congress on Railway Research. Paris, 1994. CASCADE - Generalised Assessment Method, CAS/IC/MK/ D231/V0.3, 28juin 1995 Cenelec - Cenelec prEN 50126, The Specification and Demonstration of Reliability, Availability, Maintainability and Safety (RAMS) of Railway Applications, Part 0. Dependability, version du 6 juin 1993.

Si?ClJKl?-E

I - . _

. . _

‘.__^

. “ . _ -

-

_ . . _

DES

AU’I‘OMA7‘ISMES

. _ . . -

. 1 . - .

_ . - ~ ; =

ix

^ _

. ; , . ,

I ,

_ _ - - - ~ - ~ _ ~

~ ~ ;

Cenelec - Cenelec prEN 50128, Railway Applications-Software for railway Control and Protection Systems, version de fevrier 1994. Cenelec - Cenelec prEN 50129, Railway Applications-Safety-related Electronic Railway Control and Protection Systems, version 1994. Chan K., Fencott C., Hebbron B. - Formal Support for the Safety Analysis of Requirement Models, Safecomp’95, Belgirate, Italie, 11-13 octobre 1995. Dehbonei B., Mejia F. - Formal development of safety-critical softwAre systems in railway signaling, In Hinchey M.G., Bowen J.P. (ed.) Applications of Formal Methods, Prentice Hall International Series in Computer Science, p. 227-252, 1995. El Koursi comp’92, El Koursi comp’94,

M., Ozello P. - Using Petri Nets for Safety Analysis of Unmanned Metro System, SafeZurich, Suisse, 28-30 octobre 1992. M., LeTrung B. - Current Assessment Approach Applied by INRETS for ATP systems, SafeAnaheim, Californie, Etats-Unis, 23-26 octobre 1994.

El Koursi M., Letrung B., Waeselynck H., Baranowski F. .- Safety Case: structure and role, Safecomp’95, Belgirate, Italic, 11-13 octobre 1995. El Koursi M., Mariano G. - Safety Critical Software Assessment: Past Experiences and New Approach, First conference on the B Method, Nantes, France, 24-26 novembre 1996. El-Koursi M., CASCADE - Generalised Assessment Method (Part 2: Guidelines), Rapport technique CAS/IC/MK/D%2/V$ projet ESPRITCASCADE-%%& 15 janvier 1997. Fenton N. - Software measurement: a necessary scientific basis, IEEE transactions on software engineering, 1992. IEC - Functional Safety: safety related systems, Draft IEC 1508, Part1 to 7., juin 1995.

Krebs H. - Assessment on the basis of Standards: Gaps and how to bridge them, Safecomp’95, Belgirate, Italy, 11-13 octobre 1995. Mariano G. - Contribution au dkveloppement de logiciels critiques par la mkthode B : une approche quantitative, These de doctorat soutenue ?Il’universiti! de Valenciennes et du Hainaut-CambrQsis, 1997. Mariano G., El Koursi M. - Formal methods and metrics: Application to B development assessment, Proceedings of the 5th Software Quality Conference, University of Abertay, Dundee, Ecosse,p. 37-55, juillet 1996. Melton A. (ed.) - Software Measurement, International Thomson Computer Press, 1996. Mitra S., CASCADE CAS/LR/WP2.T3/SM/D23.1,

Generalised Assessment Method (Part 1: Rules), Rapport projet ESPRITCASCADE, 24janvier 1997.

technique

Redmill F., Anderson T. - Achievement and Assurance of Safety, The third Safety-critical Systems Symposium/Safety-critical Club, Springer-Verlag, 1994. Schwartz F., Mariano G., El-Koursi M. - Recommandations pour le d&veloppement de logiciels critiques par la m&hode B, Rapport technique INRETS-ESTAS,1996. Storey A.C., Haugton H. - A strategy for the production of verifiable code using the B Method, FME'94, Verlag Springer, p. 46-65, 1994. Stuparu A., Baranowski F., Ozello P - E;‘ilJericnceof the highly critical software validation of MAGC;ALY Subway, Colloque ISSRE%/IEEE, Denver, Etats-Unis, novembre 1993. Stuparu A., Baranowski F., Ozello P. -- La validation fonctionnelle des logiciels de &cur%& du m&o automatique MAGGALY, Recherche Transports SBcurit&, no 42, mars 1994. Stuparu A., Baranowski F., Ozeilo P. - The functional validation of the safety software in MAGGALY, a driverless subway system, Recherche Transports !%curit&, English Issue, no 11, 1995. Waeselynck H., Boulanger J.-L. - The role of testing in the B formal development process, Proceeding of the 6th International Symposium on Software Reliability Engineering (ISSRE'%), Toulouse, France, p. 205-228, 24-27 octqbre 1995.

-

7’HE SAFETY

Assessment of safety critical Application of method From the point of view of safety, the bottleneck in the operation of computerized systems currently appears to be the software. In order to improve the safety of software an independent assessment of its quality has been advocated for several years. The assessment of safety critical software consists of a technical examination on the basis of a set of criteria by a body which is independent from the designer. These assessment criteria are derived from the standards which are in force, the state of the art and experience. The objective of an assessment is to verify that the product meets the specified safety and functionality requirements. In this paper the authors describe a combined approach to the assessment of safety critical software. On the one hand, the process used in order to develop the software is examined, and on the other the quality of the end product (software) is checked. The first part of the paper will present the position of safety critical software in the context of railway standardization as well as the main assessment techniques with particular reference to that used at INRETS.The second part of the paper will deal with the contrii bution of formal methods such as the B method to the development of safety critical software. The software assessment aspect will pay particular attention to assessment of the product -- analysis of the traceability of requirements, integration and validation of safety properties. The paper ends with a brief account of the extraction and interpretation of metrics for a formaI development.

Formal methods which have become increasingly popular in recent years, can assist in both the prevention and the elimination of software faults. The B method, developed by JR Abrial[1996], is a formal method

based on the construction of models (in contrast to models which are algebraically based methods). The B method is currently being used in the development of safety critical software for the French rail industry. It is also of potential interest to other sectors (air transport, nuclear, military, etc.), as is evidenced by the development of the Bug B-User Group run by INRETS(l) which currently has 150 users. This method has been used in transport systems (KVB-KVS,cTDc, L.sT and METEOR)and in IBM applications (CICS).It currently has the backing of the major players in the French rail industry: RATP, SNCF, GEC-ALSTHOM,cs Transport, MATRATransport international. Some manufacturers are already marketing products which have been developed with the B method and the partners are currently considering standardizing a method of this type and have set up a working group for the purpose. The impact development

OF AUTOMATIC

SYSTEMS

software:

in order to make certain at a later stage that satisfactory traceability with respect to the formal model is achieved. This phase is completed when all equipment requirements have been expressed as software requirements, a The formal specification phase consists of a set of structured formal components (machines, refinements installations). It is the expression of re-quirements in formal language. * The formal specification refinement phase consists of set of structured formal components (machines, refinements, installations). All the refinements have been written and proven. Refinement proofs are used to guarantee traceability with respect to the formal specification. In a formal development the coding phase is considerably simplified. In the B method, the code is generated automatically with the assistance of the B tool package.

l

on software

The advantage of using the B method in development is that the generated code is faithful to the specification. In other terms there is a guarantee that there is no contradiction between the concrete (source code) and the abstract (formal specification). The B method software development process can be broken down into four stages in the same way as a conventional development process. @l‘he software requirement5 specification phase consists of producing an initial document which lays down the informal software requirements. The software requirements specification must comply with certain constraints

(1) W&site: http ://estd.inrets.s.fr :8001/ BUGhome.html

One of the fundamental assessment requirements for a forrnal development is that traceability must exist between the informal specification and the formal specification. The traceability of functional and safety requirements is examined by means of a structured analysis of the software requirements specifications. The structured analysis technique reveals inconsistencies in the specifications and provides an overview of the structure of the system. SiuX (Structured Analysis Design Techniques) are used to develop functional specifications and check by rapid modelling that these actually comply with requirements. Working from the specification documents it is possible to construct a

structured analysis on the basis of the breakdown of the system into functions and subfunctions and the description of the input and output data from each function. This traceability analysis should provide a traceability matrix which shows the SADT diagram for the formal description in B for each informal requirement. The traceability matrix will be backed up by analyses carried out in the context of the activities described below and constitutes the reference document which accompanies all the phases of B development.

Taking safety requirements into account is the foundation for the develop ment of safety applications. In order to validate the completeness of safety stu dies and for monitoring purposes, the safety requirements are expressed in the form of properties and their inclusion and proof in the B model is checked. Formulation properties

of safety

There are a number of stages in the formulation of safety properties. An analysis of the functional specifications of equipment. The purpose of this is to identify the overall properties which can apply to several software functions. These properties are at an abstract level and can subsequently be broken down into a number of specific properties to be included in the corresponding software functions. l

a An examination of the software specifications requirements, in order to verify that :

comply with the safety criteria generated by the safety analyses. The formal specification is not used to formulate properties in order to separate formal development from valid dation of the consideration of properties. A separate entity will be used for this purpose. Integration and proof of safety properties After the safety properties have been dernonstrated, the primary objective is to prove these properties in the corresponding B formal specification. Two types of proof are possible depending on the type of property. 0 In horizontal proof one or more B machines are artificially grafted onto the ongoing project. These machines express the desired properties in a raw form. They are linked to the ongoing project in such a way that they are visible in the entities which express properties. This technique has the advantage of being straightforward to implement, but however it is not certain that the properties can be easily expressed in terms of the entities which have already been defined for the project. The link between the overall properties and the entities which have already been written is not easy to discover. 0 The vertical proof technique consists of breaking down the overall or abstract property into subproperties which can be directly implemented in B machines. This technique has the advantage of not adding supplementary machines. The difficulty is in proving that the overall property and the set of subproperties are equivalent. It is imperative for this equivalence to be established.

the specification takes the overall properties into account, the specification of software requirements is consistent both internally (no contradictions in the document) and externally (no contradictions with regard to other documents). * A check of the link between the ana lyses of safety and the specification in order to verify that these properties

The functional tests can be deduced from the safety properties in order to validate the software with regard to its specification. The properties are logical expressions of the logical links between states and are unable to express temporal or sequencing constraints. A set of scenarios can be added in order to overcome this difficulty in order to supplement the role of properties.

A measurement can be defined as a number which is derived from a product process or resource. This signifies that a software measurement can be used to characterize the software itself or the process which produced it. Standards and good practice recommend the collection of software measurements. It should be mentioned that measurements are collected not merely to provide indicators for the predictive assessment of software safety but also to provide a means of identifying the critical parts of development and validation. In the context of assess ment the use of measurement techniques should be in line with the formal specifications With the introduction of new concepts like nondeterminism, mathematical notations and plioof, the attributes to be measured have changed considerablywhich means that new measurements must be developed. We have developed a tool, known as BEST (B-Enhanced Specification Tool), which is able to extract measurements automatically from a B development. The different classesof measurements which are possible are as follows: measurements relating to project size, measurements relating to structuring, measurements relating to the proof phase, ‘measurements relating to complexity, measurements relating to overall quality.

The objective of process assessment is to verify that the software development process complies with the relevant standards and that quality procedures are actually implemented. This assessment is based on the audit and inspection technique and involves the application of a set of criteria obtained from standards and appraisal of the product. The principle consists of inspect& the software requirements specification: the software architecture, the formal model, proof obligations, the added rules, the source code, the specifications and results of tests, the safety analysis, the plans and the development tools. The assessment of development and the organization in place refers to the different plans.