Methodes Formelles - Application Au Domaine-Trp3309

Réf.
: TRP3309 V1
Méthodes formelles :
Date de publication :
10 février 2016 application au domaine
ferroviaire
Cet article est issu de : Ingénierie des transports | Systèmes ferroviaires
par Jean-Louis BOULANGER
Mots-clés Résumé Depuis le développement de la première application ferroviaire à base de

méthode formelle | vérification | logiciel, nommée SACEM, les méthodes formelles ont été largement utilisées et mises en
logiciel critique | système
embarqué œuvre par des industriels à différents niveaux (spécification, conception, code) et pour
différents types d’applications (métros automatiques, sous-systèmes de signalisation,
applications trains développées avec ControlBuild par exemple). La norme CENELEC
50128 dédiée à la réalisation des applications logicielles pointe l’intérêt de mettre en
œuvre des méthodes formelles. Cet article présente le processus de développement des
applications logicielles tel que mis en œuvre dans le domaine ferroviaire, et les évolutions
induites par la mise en œuvre des méthodes formelles.
Keywords Abstract Since the development of the first railway application software , named
formal method | verification | SACEM , formal methods have been widely used and implemented by industry at different
critical software | embedded
system levels (specification, design and code analysis) and for different types of applications
(automated metro , signaling subsystems, railway applications developed with
ControlBuild for example). The CENELEC 50128 standard dedicated to the realization of
advanced software applications highlights the benefit of implementing formal methods.
This paper presents the development process of software applications as implemented in
the railway sector, and the changes induced by the implementation of formal methods.
Pour toute question :

Service Relation clientèle
Techniques de l’Ingénieur
Immeuble Pleyad 1 Document téléchargé le : 01/03/2017
39, boulevard Ornano
93288 Saint-Denis Cedex Pour le compte : 7200104131 - systra // brigitte VERCHERE // 213.41.116.170
Par mail :
infos.clients@teching.com
Par téléphone :
00 33 (0)1 53 35 20 20 © Techniques de l'Ingénieur | tous droits réservés
Ce document a ete delivre pour le compte de 7200104131 - systra // brigitte VERCHERE // 213.41.116.170
Méthodes formelles : application

au domaine ferroviaire

Evaluateur-Certificateur
Certifer (Anzin, France)
1. Développement du logiciel................................................................. TRP 3 309 - 2

2. Normes ferroviaires .............................................................................. — 8
3. Méthodes formelles, semi-formelles, structurées

et techniques formelles....................................................................... — 11
4. Mise en œuvre des méthodes formelles lors de la réalisation

d’une application logicielle ................................................................ — 13
5. Réalisation mettant en œuvre les approches formelles............. — 22
6. Logiciel paramétrable .......................................................................... — 25
Parution : février 2016 - Ce document a ete delivre pour le compte de 7200104131 - systra // brigitte VERCHERE // 213.41.116.170
7. Qualification ........................................................................................... — 29
8. Conclusion............................................................................................... — 30
9. Glossaire .................................................................................................. — 31
Pour en savoir plus ........................................................................................ Doc. TRP 3 309
B ien que les techniques d’analyses formelles de programme (voir les

travaux de Hoare [10] et de Dijkstra [11]) soient assez anciennes, leurs
mises en place datent des années 1980. Les méthodes formelles permettent
d’analyser le comportement d’une application logicielle décrite dans un
langage de programmation. La correction (bon comportement, arrêt du pro-
gramme, etc.) d’un programme est alors démontrée au travers d’une preuve
de programme basée sur le calcul de la plus faible précondition [12].
Il a fallu attendre la fin des années 1990 [7] pour que les méthodes formelles,
Z [16], VDM [15] et/ou la méthode B [1] [14], soient utilisées sur des applica-
tions industrielles. Les méthodes formelles se basent sur des notations
mathématiques pour décrire de façon précise les propriétés qu’un logiciel doit
avoir.
L’un des écueils étant l’impossibilité de les mettre en œuvre dans le cadre
d’une application industrielle (application de grande taille, contrainte de coût et
de délais, etc.), la mise en œuvre – passage à l’échelle – ne peut se faire qu’au
2 - 2016
travers d’outils « suffisamment » matures et performants.

L’utilisation des méthodes formelles bien qu’en plein essor reste marginale,
au vu du nombre de lignes de code. En effet, il y a à l’heure actuelle bien plus
de lignes de code Ada (ANSI:1983, ISO 8652:1995, [17]), C ([18], ISO 9899:1999)
ou C++ qui ont été produites manuellement qu’au travers d’un processus
TRP 3 309
formel.
C’est pourquoi d’autres techniques formelles ont été mises en place afin de
vérifier le comportement d’une application logicielle écrite dans un langage de
programmation tel que le C ou l’Ada. La principale technique, nommée inter-
prétation abstraite [5] [19] de programme, permet d’évaluer l’ensemble des
comportements d’une application logicielle au travers d’une analyse statique.
Copyright © – Techniques de l’Ingénieur – Tous droits réservés TRP 3 309 – 1
tiwekacontentpdf_trp3309 v1 Ce document a ete delivre pour le compte de 7200104131 - systra // brigitte VERCHERE // 213.41.116.170
MÉTHODES FORMELLES : APPLICATION AU DOMAINE FERROVIAIRE __________________________________________________________________________
Ce type de techniques a donné naissance, à plusieurs outils tels que Codepeer,

POLYSPACE, Caveat, Absint, FRAMAC et/ou ASTREE.
L’efficacité de ces techniques d’interprétation abstraite de programme a for-
tement progressé avec l’augmentation de la puissance des ordinateurs. Il est à
noter que ces techniques nécessitent en général d’intégrer dans le code
manuel des informations complémentaires telles que des préconditions, des
invariants et/ou des postconditions.
À noter que la version 2012 du langage Ada introduit la possibilité de définir
des préconditions, des invariants et des postconditions et qui peuvent être
vérifiés durant l’exécution, et que l’environnement SPARK 2014 met à disposi-
tion un ensemble d’outils permettant de faire la preuve de ces propriétés.
Le domaine ferroviaire est réglementé et il est nécessaire de respecter les
normes CENELEC EN 50126, 50129 et 50128 lors de la réalisation d’un système
ferroviaire. Le référentiel CENELEC identifie les méthodes formelles comme
moyen à mettre en œuvre.
Cet article fait le point sur l’utilisation des méthodes formelles dans la réali-
sation des applications ferroviaires de type signalisation, CBTC et
contrôle/commande (unité de gestion de la traction, du freinage et/ou applica-
tion TCMS pour Train Control/Management System).
Nota : le CBTC, pour Communication Based Train Control, est un système composé d’équipements embarqués à bord des
trains et d’équipements fixes communicants entre eux (en général par radio). Le CBTC fait l’objet d’une norme [53].
1. Développement du logiciel
Développement
Vérification Fabrication
1.1 Réalisation d’une application et validation
logicielle
Afin de fixer les idées, nous proposons ci-dessous une définition
pour caractériser une application logicielle.
Définition 1 – Application logicielle – Ensemble des pro-
Installation Maintenance
grammes, des procédés et des règles et éventuellement de la
documentation, relatifs au fonctionnement d’un ensemble de trai-
tement de l’information.
Il est à noter que nous parlons ici de la réalisation d’une applica-
tion logicielle et non du développement d’une application
logicielle : la notion de réalisation d’une application logicielle
couvre en effet les activités de développement mais aussi les acti- Retrait
vités de vérification, de validation, de production, d’installation et
de maintenance de l’application logicielle (figure 1).
Dans le cadre des applications critique de sécurité, les activités
de vérification et de validation sont importantes et seront plus ou Figure 1 – Étapes de réalisation d’un logiciel
moins développées en fonction du niveau de sécurité requis (cela
est vrais pour l’ensemble des domaines). Concernant les activités
de production et d’installation, elles sont cruciales et nécessitent la version. Le déploiement nécessite de garantir que le système soit
mise en place de processus spécifiques, mais qui n’impliquent pas fonctionnel après l’installation de la nouvelle version du logiciel.
le développement de l’application logicielle. La norme CENELEC EN 50128:2011 est la seule à introduire explici-
Le retrait d’une application logicielle est mentionné, mais il ne tement l’activité de déploiement.
pose aucun souci contrairement au retrait d’un système complexe
La maintenance d’une application logicielle se confronte à une
comme une centrale nucléaire ou une installation ferroviaire.
difficulté : la durée de vie de cette application logicielle. En effet,
La maintenance de l’application logicielle reste l’activité la plus pour le domaine ferroviaire, la durée de vie est de quarante à cin-
délicate. En effet, suite à une évolution, il faut maintenir un niveau quante ans, pour l’aéronautique, elle est de quarante ans, pour le
de sécurité tout en maîtrisant le coût de l’évolution et en minimi- nucléaire cinquante ans, pour l’automobile quinze ans. Au vu de
sant l’impact sur le système en service. La maintenance dans le ces durées de vie, il faut donc prendre des mesures pour garantir
cadre du logiciel introduit la nécessité de déployer une nouvelle le maintien du service et la maintenance de l’application logicielle.
TRP 3 309 – 2 Copyright © – Techniques de l’Ingénieur – Tous droits réservés
__________________________________________________________________________ MÉTHODES FORMELLES : APPLICATION AU DOMAINE FERROVIAIRE
La durée de vie est une contrainte qui nécessite de prendre en métadonnées UML basé sur XML) pour les modèles UML et les
compte l’obsolescence des machines, des systèmes d’exploitation nombreux problèmes de compatibilité) ?
(voire leur disparition) et des outils. Ainsi, il ne suffit pas seule- – sera-t-il possible de redévelopper un outil (nécessite la norma-
ment de mettre en place une gestion de configuration mais bien lisation d’une syntaxe, l’existence d’une sémantique, la définition
un processus qui garantisse une génération identique (dans le du format d’export, etc.) ?
meilleur des cas) de l’exécutable.
Il faut donc mettre en place des mesures pour garantir le main-
tien du service et la maintenance de l’application logicielle. Ces 1.2 Processus de développement
mesures doivent tenir compte du type de machine utilisée pour le
développement, des outils mis en œuvre, de la documentation à La réalisation d’une application logicielle est décomposée en
produire pour réaliser la maintenance et la reprise en cas de néces- étapes (spécification, conception, codage, tests, etc.) : on parle de
sité. cycle de vie. Ce dernier est nécessaire pour décrire les dépen-
Le SACEM (Système d’aide à la conduite, à l’exploitation et à la dances et les enchaînements entre les différentes activités.
maintenance) est un système qui a été mis en service en 1986 et
Le cycle de vie doit prendre en compte l’aspect progressif du
qui est régulièrement mis à jour. Le choix d’un langage comme
développement ainsi que les possibles itérations. Comme le
Ada ou C permet de se prémunir a priori des problèmes d’obsoles-
montre la figure 2, il existe plusieurs cycles : cycle en « V »
cence des machines, des systèmes d’exploitation et des outils. En
(figure 2a ), cycle en cascade (figure 2b), cycle en spirale
effet, comme ces langages sont normalisés, il est possible de
(figure 2c ), etc., pour la réalisation d’une application logicielle.
développer des versions pour différentes machines.
Mais qu’en sera-t-il de la maintenance du logiciel mettant en Les cycles de vie présentés dans le cadre de la figure 2 sont des
œuvre des environnements de développement formel tels que cycles de vie théoriques : la pratique montre cependant qu’il est
ControlBuild (produit de Dassault Systèmes), l’atelier B et/ou nécessaire de mettre en place des itérations sur certaines phases,
SCADE (à étendre pour tous les outils de modélisation) : le cycle théorique n’apparaissant qu’à la fin de la réalisation.
– sera-t-il possible de porter le modèle d’un outil vers un autre ; Dans la suite, nous allons prendre comme référence le cycle en
voir les travaux autour du format XMI (XMI pour XML Metadata « V », car c’est le cycle utilisé par les différentes normes (CENELEC
Interchange est un standard pour l’échange d’information de EN 50128, DO 178:C, IEC 61508:2008, ISO 26262:2011).
Tests
Spécification
fonctionnels
Tests
Architecture
d’intégration
Analyse des besoins Conception

Tests
préliminaire
unitaires
et détaillée
Spécification
Conception préliminaire
Codage
Détermination Conception détaillée

d’objectifs Analyse a
des alternatives de risque
Codage
et des contraintes
Tests unitaires
Prototypage
Tests d’intégration
Début
Simulation
Planification Tests fonctionnels

de la phase suivante
Phase
du cycle en « V » Exploitation/maintenance
classique
Figure 2 – Trois cycles de vie possibles d’une application logicielle
La figure 3 présente le cycle en « V » tel que présenté en géné-

ral. L’objectif de l’analyse des besoins est de vérifier l’adéquation
entre les attentes du client et la faisabilité technologique. La phase Analyse Exploitation
de spécification a pour objectif de décrire ce que le logiciel doit des besoins maintenance
faire (et non comment il le fera). Dans le cadre de la définition de
l’architecture, on cherche à réaliser une décomposition hiérar-
chique de l’application logicielle en modules/composants et on
identifie les interfaces entre ces éléments. La description de Tests
Spécification
chaque module/composant (données, algorithmes, etc.) est réali- Fonctionnels
sée dans le cadre de la conception. Souvent la phase de concep-
tion est séparée en deux étapes : la première étape, dite
conception préliminaire, vise à identifier les données manipulées Tests
et les services nécessaires ; la seconde étape, dite conception Architecture
d’intégration
détaillée, vise à décrire explicitement et en détail l’ensemble des
services. La phase de conception donne ensuite lieu à la phase de
codage. Conception
Tests
La figure 3 montre qu’il existe différentes phases de tests : préliminaire
unitaires
et détaillée
– tests unitaires (TU) (réalisés sur des morceaux de code), tests
modulaires (réalisés sur des fonctions, des procédures et/ou des
paquetages) et tests de composants (le composant est une unité
de code autonome ayant une interface bien définie) ; Codage
– tests d’intégration (TI) (focalisés sur les interfaces logicielles et
les interfaces matérielles). Il y a donc deux étapes, des tests d’inté-
gration logiciel/logiciel (S/S) et des tests d’intégration logi-
ciel/matériel (S/H) ; Figure 3 – Cycle en « V »
– tests fonctionnels (TF), aussi appelé test de validation (TV)
mais maintenant appelés tests d’ensemble du logiciel (TE), qui
cherche à montrer que le produit est conforme à sa spécification ; dante vise à réaliser l’application logicielle et la phase remontante
on parle aussi de tests de validation du logiciel. vise à montrer que l’application logicielle a été correctement réali-
Concernant la phase d’exploitation/maintenance, elle concerne sée et qu’elle répond au besoin exprimé et aux attentes.
la vie opérationnelle et la maîtrise des éventuelles évolutions.
Les activités de la phase remontante (exécution des TU, TI et TF)
Il faut noter qu’il existe une correspondance horizontale (flèche
doivent être préparées lors de la phase descendante, en définis-
pointillée) entre les activités de spécification, de conception et les
sant le plus en amont possible les plans de test correspondants.
activités de tests.
Le cycle en « V » (figure 4) est donc décomposé en deux phases, Nota : dans la suite, TU doit être remplacé par TU, TM ou TC en fonction du niveau de
la phase descendante et la phase remontante. La phase descen- granularité pris en compte dans le développement.
Analyse Exploitation
des besoins maintenance
Spécification Exécution
Spécification des tests des tests
fonctionnels fonctionnels
Spécification Exécution
Architecture des tests des tests
d’intégration d’intégration
Conception Spécification Exécution

préliminaire des tests des tests
et détaillée unitaires unitaires
Codage
Figure 4 – Cycle en « V » incluant la spécification des tests
1.3 Avantages/désavantages Définition 2 – Analyse d’impact – L’analyse d’impact d’une ano-

malie consiste à identifier les modifications à réaliser sur la phase
descendante (impact sur les documents, impact sur le code, impact
Le cycle en « V » (figures 3 et 4) permet la détection des défauts sur la description et l’implémentation des tests) de la réalisation.
introduits dans le développement de l’application logicielle lors de
la phase remontante, ce qui a un impact direct sur le coût et sur les Définition 3 – Analyse de non-regression – L’analyse de
délais. Les retours d’expériences concernant la réalisation d’appli- non-régression consiste à déterminer un ensemble de vérifications
cations critiques montrent que les activités de tests représentent permettant de démontrer que la modification réalisée n’a pas
de 50 à 75 % du coût de la réalisation et que la présence de défaut d’effet sur le reste de l’application logicielle.
peut multiplier par deux ou trois le délai de réalisation. Nota : il est à noter qu’une analyse de non-régression peut être réalisée sur l’applica-
tion logicielle ou sur un élément plus important comme un équipement, un sous-système
La principale difficulté du développement de l’application logi- et/ou un système.
cielle réside dans la présence d’un grand nombre de défauts au
sein des premières versions. Il est donc nécessaire de réaliser des En complément, il est à noter que le coût de la correction d’un
corrections lors de la réalisation de la version de référence et défaut est directement lié à la phase durant laquelle il a été identi-
durant la phase de maintenance. fié. En effet, la détection d’un défaut en phase de tests fonctionnels
coûte de 10 à 100 fois plus cher (voire plus dans certain cas) qu’un
Ainsi, durant la réalisation de l’application logicielle, la décou- défaut identifié en phase de tests unitaires. Ce coût est lié aux
verte des anomalies, leur identification, l’analyse de leur effet moyens mis en œuvre jusqu’à la découverte du défaut et à la diffi-
(impact sur la sécurité et/ou la fiabilité du système final), la sélec- culté de réaliser des tests fonctionnels (utilisation d’un équipement
tion des anomalies à corriger, l’analyse des modifications à réali- cible, nécessité de tenir compte du temps réel, difficulté d’observa-
ser, la mise en œuvre des corrections et la vérification des tion, technicité des personnes impliquées, etc.).
corrections (en général la vérification de la bonne mise en œuvre Notre retour d’expérience (en tant qu’évaluateur/certificateur de
des modifications passe par une campagne d’essais mais il sera système ferroviaire) nous amène à conclure que les phases de
nécessaire de vérifier qu’aucune modification complémentaire n’a tests unitaires et de tests d’intégration ne sont généralement pas
été mise en œuvre) accroissent le délai de réalisation et les coûts. efficaces, étant donné que les industriels considèrent que :
Rappelons qu’il a été constaté depuis plusieurs décennies [54] [55]
[56] que la moitié des logiciels coûtent le double du coût initial et – les tests unitaires ne servent à rien : en règle générale, ils ne
que l’autre moitié est abandonnée. découvrent pas ou peu de défauts car ils sont définis à partir du
code, et il est nécessaire de disposer d’une description de la
La figure 5 présente le cycle de gestion des anomalies, qui est conception de l’application logicielle pour identifier les tests
unitaires ;
important pour la maîtrise tant de la qualité de l’application logi-

cielle que de la maintenance. À partir de l’étape « classification », il – l’intégration logiciel/logiciel peut se résumer à une intégration
est possible de passer à l’état « ouverte » (anomalie qui doit être big-bang (intégration de l’ensemble du code au lieu d’une intégra-
analysée) ou à l’état « fermée » (faux problème, anomalie déjà tion module par module) : au mieux l’ensemble du code est com-
connue, etc.). Aussi à partir de l’état vérification et validation pilé d’un seul coup et l’intégration se résume à une vérification des
(V&V), il est possible de « fermée » l’anomalie si tout est en ordre interfaces par le compilateur ;
et de retourner dans l’état « ouverte » si la V&V n’est pas satisfai- – l’intégration logiciel/matériel est prise en charge par les tests
sante. fonctionnels sur cible : l’ensemble du logiciel s’exécutant correcte-
ment sur la machine cible, l’intégration est déclarée correcte.
L’analyse des anomalies est réalisée au travers d’une analyse Bien entendu, les affirmations précédentes sont inexactes et la
d’impact (définition 2) et d’une analyse de non-régression (défini- mise en œuvre d’une stratégie de tests efficaces (basée sur des
tion 3). Dans certains cas la non-régression est dite totale, et il est documents d’entrée de bon niveau et sur l’intégration dans un pro-
alors nécessaire de réexécuter l’ensemble des essais d’une ou de cessus global) permet d’avoir de bons résultats.
toutes les phases. L’analyse de non-régression a pour objectif de
minimiser le coût d’une nouvelle version. En effet :
– les tests unitaires (TU ou TM ou TC), lorsqu’ils sont identifiés à
partir de la conception, permettent de vérifier la conception et leur
exécution permet de vérifier l’implémentation correcte du code ;
Identification
– les tests d’intégrations logiciel/logiciel (L/L), lorsqu’ils sont
identifiés à partir de l’architecture, permettent de vérifier l’architec-
ture et de vérifier que toutes les interfaces L/L sont correctes ;
– les tests d’intégrations logiciel/matériel doivent être réalisé au
Classification
plus prêt du matériel car il est difficile de pouvoir tester certaines
interfaces au travers du logiciel complet sur le matériel.
La maîtrise des coûts et des délais passe donc par deux
Ouverte Sélection prérequis :
1) Diminuer le nombre de défauts introduits dans l’application
logicielle durant la phase de descente du cycle en « V » ;
Analyse Fermée 2) Identifier au plus tôt les défauts introduits au sein de l’applica-
tion logicielle.
Mise en œuvre 1.4 Vérification et validation
1.4.1 Présentation
Vérification
et validation La réalisation d’une application logicielle doit prendre en compte
la conception de l’application logicielle mais elle doit prendre aussi
en compte les activités permettant de démontrer que l’application
Figure 5 – Cycle de gestion des anomalies logicielle atteint un certain niveau de qualité. L’atteinte d’un niveau
de qualité passe par la démonstration qu’aucun défaut n’a été

introduit pendant la conception et que le produit correspond aux Fonctions codées
besoins qui ont été identifiés.
Avant toute chose, il faut rappeler ce que sont la vérification et la
validation.
Définition 4 – Vérification – Confirmation par des preuves
tangibles que les exigences spécifiées ont été satisfaites à chaque
étape du processus de développement.
Définition 5 – Validation – Confirmation par des preuves tan-
gibles que les exigences définissant une utilisation spécifique ou
une application prévues ont été satisfaites.
Les deux définitions précédentes sont extraites de la norme
Fonctions spécifiées
ISO 9001:2008. Elles introduisent les notions d’exigences [29] et les
notions de preuves (en anglais, le terme evidence est utilisé). Afin Figure 6 – Problématique du développement logiciel
d’être plus précis, nous pouvons reprendre la présentation faite
par I. Sommerville [20]. Il cite Boehm qui, en 1979, énonce que :
– la vérification s’assure que le produit est conforme à sa
spécification ;
– la validation s’assure que le système implémenté correspond
aux attentes du futur utilisateur. Validation
De par sa définition, la validation vise donc à démontrer l’adé- Tests
Spécification
quation du produit avec le besoin initial. fonctionnels
La figure 6 représente la problématique principale de la réalisa-

tion d’une application logicielle. En effet, il existe un besoin à réali-
ser et il existe une réalisation, la vérification est là pour montrer
que l’ensemble des besoins est pris en compte par la réalisation et
qu’il n’existe pas d’élément non prévu. L’équipe de développement Tests
Architecture
aura toujours de bonnes raisons pour introduire des morceaux de d’intégration
code non désirés (fonctions à réutiliser, ajout de service, etc.) et

pour ne pas prendre en compte l’ensemble des besoins (difficulté
technique, oubli, etc.). Conception
Tests
Au vu des définitions, nous pouvons en conclure (figure 7) que préliminaire
unitaires
la vérification s’applique à toutes les étapes du cycle en « V » et et détaillée
que la validation est une activité visant à montrer que la spécifica-
tion est respectée par le produit final, et concernant les tests fonc-
tionnels appelés aussi tests de validation.
Codage
Comme le montre la figure 7, la vérification concerne la
recherche des défauts au sein du cycle en « V », et la validation
concerne la démonstration que le produit correspond à son besoin, Vérification
d’où sa localisation au niveau de la partie haute du cycle en « V ».
1.4.2 Vérification
Figure 7 – Vérification et validation sur le cycle en « V »
La norme ISO 9001:2008 recommande que chaque production
soit systématiquement vérifiée. La norme CENELEC EN 50128:2011
renforce ce point en indiquant que le rôle de la vérification est de
montrer que l’on réalise correctement le produit (pas d’introduc-
tion de défaut). Comme le montre la figure 8, sur la base des
entrées et des activités, il nous faut montrer que les éléments de
sorties sont corrects.
La vérification d’une phase nécessite de vérifier la mise en Entrées
œuvre des exigences qualité (application des procédures, respect
des formats, etc.), l’application des processus (respect des plans,
respect de l’organisation, etc.), la correction des activités et la
Vérification
bonne prise en compte des exigences de sécurité.

Phase
Vérification
La vérification a pour objectif de montrer que l’on a réalisé
correctement le produit. La question associée est donc : « le
travail est-il bien fait ? » Sorties
Dans le contexte de la norme CENELEC 50128:2011, la vérifica-

tion est l’activité qui consiste, pour chaque phase du cycle de vie,
à démontrer par analyse et/ou essai que, pour les entrées spéci-
fiques, les éléments livrables remplissent en tout point les objectifs
(identifiés dans les plans) et les exigences fixés pour la phase. Figure 8 – Vérification
Voici une liste non exhaustive d’activités de vérification : En complément de la vérification du produit, il ne faut pas
– les revues relatives aux sorties d’une phase, destinées à assu- oublier la vérification de la qualité du produit, qui sera réalisée par
rer la conformité avec les objectifs et les prescriptions de la phase, l’équipe qualité au travers d’audits qualité (sur le produit, sur le
prenant en compte les entrées spécifiques à cette phase ; projet ou sur l’application d’un processus), de revues des éléments
produits (documentation, etc.) et d’activités de contrôle (suivi des
– les revues de conception (analyse du code, vérification des
anomalies, suivi des non conformités, suivi des retours client, etc.).
règles de codage, etc.) ;
– les tests d’ensemble réalisés sur le produit afin de s’assurer
que le fonctionnement est conforme à la spécification ; 1.4.3 Validation
– les tests d’intégration réalisés lors de l’assemblage élément
par élément de différentes parties d’un système, à partir d’essais La validation, dans le contexte du cycle de vie d’un système,
d’environnement, afin de s’assurer que toutes les parties fonc- regroupe les activités qui assurent et qui construisent la confiance
tionnent les unes avec les autres conformément aux dans le système et dans son aptitude à satisfaire les utilisations
spécifications ; prévues, l’atteinte des buts et objectifs assignés.
– le test des composants réalisé sur un composant (à ce point de Comme le montre la figure 9, la validation est une activité qui
la présentation, nous ferons le lien entre test de composant et test permet de montrer que l’application logicielle rend le service
de module et/ou test unitaire). prévu. Le service prévu étant défini par les exigences, il est néces-
Le chapitre 6.2 de la norme présente l’activité de vérification. saire de montrer que l’application logicielle sur le matériel cible
Cette activité doit être décrite dans le plan de vérification et valida- réalise les exigences au travers d’une activité de test. Si on consi-
tion (PVV) ou dans un PVéL et elle doit être justifiée. Le plan de dère l’activité de test comme une activité de vérification, la valida-
vérification doit être vérifié et le Rapport de vérification de la quation est la confirmation, par examen et apport de preuves
lité (RVQ) doit contenir les résultats de cette vérification. Cette véri- tangibles, que le logiciel répond à la spécification des prescriptions
fication du plan doit permettre de montrer le respect du Manuel de sécurité du logiciel.
d’Assurance Qualité (MAQ) de l’entreprise et le respect des objec- La norme CENELEC EN 50128:2011 introduit la notion de tests
tifs de la norme pour le SSIL (Software Safety Integrity Level ) d’ensemble du logiciel en place et lieu du terme de tests de vali-
objectif. La notion de SSIL sera décrite dans le cadre de la dation. Au vu de la figure 7, toutes les phases sont soumises à
section 2. une activité de vérification (combinaison de revues, d’analyse sta-
Les vérifications étant réalisées pour chaque phase, il est néces- tique, de tests, etc.).
saire de prévoir un rapport de vérification pour chaque phase. La La validation d’une application logicielle consiste donc à combi-
production de ce rapport de vérification peut être couplée avec une ner l’ensemble des vérifications et à statuer sur le fait que l’appli-
revue de fin de phase. cation logicielle respecte ou non les exigences de la spécification
Dans les colonnes SSIL du tableau 1, 5 niveaux apparaissent : M du logiciel. Un rapport spécifique dénommé rapport de validation
(mandatory – technique obligatoire), HR (Highly Recommended – du logiciel (RVL) est à produire.
techniques à justifier si non mise en œuvre), R (Recommended – son
Au vu des définitions 4 et 5, la validation peut être considérée
utilisation est à la discrétion du concepteur) et « – » (n’est pas
comme une vérification externe du produit.
demander), NR (Not Recommended – ne doit pas être mis en œuvre).
Le chapitre 6.2 de la norme CENELEC EN 50128 s’appuie sur la
table A.5 (tableau 1) qui identifie deux familles d’activités : Validation
– les vérifications statiques (ne nécessitant pas d’exécution) : La validation consiste à montrer que c’est le bon produit qui
lignes 1, 2, 4, 5, 6 ; a été réalisé.
– les vérifications dynamiques (nécessitant une exécution) :
lignes 3, 7, 8, 9, 10.
1.4.4 Avantages/désavantages
Tableau 1 – Table A.5 de la norme CENELEC Le développement d’une application logicielle certifiable est
EN 50128:2011 contraint par les exigences des normes associées à chaque
domaine (aéronautique DO 178:C, automobile ISO 26262:2011, fer-
SSIL1 SSIL3 roviaire CENELEC EN 50128:2011, nucléaire IEC 880, générique
Mesure SSIL0
SSIL2 SSIL4 IEC 61508:2008).
1. Preuve formelle – R HR Ces exigences normatives recommandent la mise en œuvre d’un
processus de développement de type « cycle en V » qui se base
2. Analyse statique (A.19) – HR HR sur des activités de vérification et de validation basées sur la réali-
3. Analyse et tests dynamiques sation de tests (TU, TM, TC, TI S/S, TI H/S, TV, TE).
– HR HR
(A.13)
4. Métriques – R R
5. Traçabilité R HR M
Application logicielle
6. Analyse des effets des erreurs
– R HR Exigences
du logiciel
du logiciel
Architecture cible
7. Couverture de test pour le code R HR HR
8. Tests fonctionnels et boîte noire HR HR M
9. Tests de performance – HR HR
10. Tests d’interface HR HR HR Figure 9 – Validation
La mise en œuvre des activités de tests souffre de plusieurs pro-

blèmes qui sont :
– le coût et la lourdeur des activités de tests ; Spécifications 1. identification
Propriétés
– le détection tardive de défaut ; Architecture
– la difficulté à réaliser tous les tests. Principes de réalisation
C’est pourquoi il est nécessaire de mettre en œuvre d’autres pra- 3. Analyse

tiques qui doivent permettre de détecter au plus tôt et de façon 2. Modélisation
plus large les défauts de l’application logicielle. Une des orienta-
tions possibles consiste à mettre en œuvre des méthodes for-
melles (par exemple la méthode B [1], SCADE [9], VDM [15], Z [16],
etc.) qui, sur la base d’un modèle et d’un ensemble de propriétés,
permettent de démontrer que le logiciel produit vérifie les dites
propriétés.
Nota : l’intérêt de la méthode B réside dans le fait que l’atelier B (fourni par la société
Clearsy) est disponible en version gratuite.
Comme le montre la figure 10, le travail de vérification consiste

Figure 10 – Identification, modélisation et analyse
a minima à :
– identifier les propriétés ; un des éléments en entrée (spécifica-
tion, architecture, principes de réalisation, code, etc.) a pour objec- propose un environnement de développement permettant la
tif d’identifier les propriétés (voir la définition 6). Les propriétés preuve du respect des préconditions, postconditions et des inva-
peuvent être classées en deux familles : les propriétés de sûreté riants.
(voir la définition 7) et les propriétés de vivacité (voir la définition
Il est à noter qu’une des difficultés dans la mise en œuvre de ces
8) que doivent vérifier les éléments en entrée ;
techniques réside dans l’absence de reconnaissance de ces tech-
– modéliser. Après avoir choisi une technologie (technique + niques au sein des normes actuelles. En effet, certaines normes
outillage), il est alors nécessaire de réaliser un modèle M qui (voir le tableau 1 extrait de la norme CENELEC 50128:2011 par
pourra être interprété par les outils et qui permettra de mettre en exemple) préconisent la mise en œuvre des méthodes formelles
œuvre la technique de vérification choisie (model checking [8], mais elles ne mentionnent pas la notion d’interprétation abstraite
preuve, simulation, etc.) ; (ou de méthodes dérivées).
– analyser : la troisième phase consiste à réaliser la vérification Les différentes versions de la norme CENELEC 50128 recon-
elle-même. naissent les méthodes formelles et la preuve comme des tech-
niques et méthodes pouvant être mises en œuvre mais l’utilisateur
Définition 6 – Propriété – Une propriété est une caractéris- doit démontrer leur efficacité et doit justifier le retrait d’activité
tique qu’un composant (matériel ou logiciel) doit vérifier. comme les tests unitaires. Dans le cadre de la norme DO-178:C, le
Les propriétés sont classiquement séparées en deux ensembles : fascicule DO 333 [57] décrit les conditions de mise en œuvre des
les propriétés de sûreté et les propriétés de vivacité. méthodes formelles et les contraintes à respecter.
Afin d’améliorer l’efficacité des activités de vérification et de
Définition 7 – Propriété de sûreté – Une propriété de sûreté validation, il conviendrait de :
(au sens du terme anglais safety ) exprime que quelque chose de 3) Réaliser des vérifications formelles de type interprétation abs-
mauvais ne se produit jamais au cours de l’exécution. traite sur le code ;
Comme exemple de propriété de sûreté, nous pouvons citer
l’absence de blocage, l’exclusion mutuelle, etc. (et dans le cas du 4) Remplacer des activités de tests par des activités de preuve
ferroviaire, ce sera l’absence de collision entre les trains). formelle ;
5) Disposer de modèle permettant de faciliter la production des
Définition 8 – Propriété de vivacité – Une propriété de viva- tests (génération de cas de test, exploration de modèles, etc.).
cité (liveness) exprime que quelque chose de bon se produit
immanquablement au cours de l’exécution.
La vérification de propriétés au travers d’un modèle formel est
une approche intéressante mais au vu du nombre de lignes de 2. Normes ferroviaires
code développé manuellement, il peut être intéressant sur la base
des langages de développement classiques (comme le C) d’explo-
rer les comportements du programme et de démontrer qu’il vérifie
un certain nombre de propriétés. Il s’agit là d’une démonstration a 2.1 Référentiel CENELEC
posteriori.
Le référentiel ferroviaire CENELEC 5012x est une déclinaison de
La démonstration qu’un code vérifie des propriétés n’est pos- la norme générique IEC 61508 qui tient compte des spécificités du
sible qu’au travers de l’ajout d’annotations décrivant des condi- domaine ferroviaire et des expériences réussies (SACEM, TVM,
tions locales (préconditions, postcondition, invariants) et d’un SAET-METEOR, etc.).
mécanisme de propagation et/ou de preuve. Cette analyse des
comportements peut se faire au travers de la mise en œuvre de Concernant la maîtrise de la sécurité, dans le domaine ferro-
techniques d’analyse statique de code basée sur l’interprétation viaire, le référentiel normatif est constitué des normes suivantes
abstraite [19] et la preuve de programme [5] [10] est dédié à l’inter- (figure 11) :
prétation abstraite. – la norme CENELEC EN 50126 décrit le cycle de vie de la sécu-
Le langage C permet l’ajout d’assertion mais la version 2012 du rité sur l’ensemble d’un projet et les méthodes à mettre en œuvre
langage Ada [17] introduit explicitement les notions de précondi- pour spécifier et démontrer la fiabilité, la disponibilité, la mainte-
tion, postcondition et d’invariant et l’environnement SPARK 2014 nabilité et la sécurité (FMDS) ;
– la norme CENELEC EN 50128 décrit les actions à entreprendre Les premières utilisations des logiciels ont permis de rendre
pour démontrer la sécurité des logiciels utilisé dans les sous-sys- plus souples les principes de signalisation (report en cabine de
tèmes liés à la signalisation ; l’information de signalisation, découpage virtuel de la voie, etc.).
– la norme CENELEC EN 50129 décrit la structure du dossier de La seconde étape a consisté à embarquer du logiciel dans les
sécurité et les moyens à mettre en œuvre pour maîtriser la sécurité trains pour gérer les informations non sécuritaires et pour déve-
des éléments matériels (hardware ) ; lopper des fonctions spécifiques de petite taille. La nécessité de
maîtriser le poids et le coût a amené les industriels à remplacer le
– la norme CENELEC EN 50159 décrit les principes de sécurisa-
cuivre et les relais par des logiciels (TCMS par exemple).
tion à mettre en œuvre si l’on utilise des réseaux fermés et/ou
ouverts ; En complément, le besoin d’évolution rapide (sans remplace-
ment de l’équipement) et les innovations (moteur à aimant perma-
– la norme CENELEC 50155 décrit le processus de réalisation
nent) ont entraîné l’utilisation du logiciel pour les équipements
pour les équipements qui doivent être installés dans les trains.
classiques comme le manipulateur de conduite, la traction, le frei-
Cette norme couvre la qualité, la réalisation du matériel, la réalisa-
nage, etc.
tion du logiciel et les essais de type et de série.
Une des restrictions (figure 11) sur ce référentiel ferroviaire
Dans le cadre de l’article sur la maîtrise du SIL et la gestion des CENELEC 5012x est liée au domaine d’application des normes
certificats dans le domaine ferroviaire [D 5 560], nous avons pré- CENELEC EN 50128, CENELEC EN 50129 et CENELEC EN 50159 qui
senté le processus de management de la sécurité tel qu’identifié sont normalement limitées aux sous-systèmes de signalisation.
dans les normes CENELEC 50126 et 50129. Pour les architectures matérielles utilisées dans le cadre d’autres
Le référentiel ferroviaire CENELEC 5012x est applicable aussi sous-systèmes, il existe d’anciennes normes qui restent appli-
bien aux applications ferroviaires de type « urbaines » (métro, RER, cables (NF F 00-101, etc.). Des travaux sont en cours au sein des
etc.) qu’aux applications ferroviaires classiques (ligne grande groupes de certification pour étendre et généraliser ces deux
vitesse, train conventionnel, fret). normes au système ferroviaire dans son ensemble.
La figure 11 montre que le domaine ferroviaire est partitionné Parmi les actions de réduction de risque permettant d’atteindre
en deux parties : les applications liées à la signalisation et les un niveau de risque acceptable, la norme CENELEC
applications embarquées au sein des trains. En fait, il est néces- EN 50129 [D 5 560] décrit l’allocation d’objectifs de sécurité aux
saire d’ajouter une troisième famille, « les autres », recouvrant des fonctions du système et de ses sous-systèmes. À partir de l’événe-
moyens de gestion de l’énergie, des systèmes de gestion des tapis ment redouté et du taux de défaillance, il est ainsi possible de défi-
et escaliers roulants, des systèmes d’informations, les applications nir le niveau d’intégrité de sécurité associé aux fonctions système,
de gestion des systèmes annexes (ventilation en tunnel, détection aux sous-systèmes et aux équipements. Le niveau d’intégrité de
d’incendie, etc.), en fait tout ce qui peut être connecté au système sécurité (SIL pour Safety Integrity Level ) est défini comme un des
ferroviaire. Les systèmes annexes ne sont pas moins important : à niveaux discrets pour spécifier les exigences d’intégrité de sécurité
titre d’exemple, le système de détection d’incendie et de ventila- des fonctions de sécurité allouées aux éléments de sécurité. Le
tion en tunnel pourrait enfumer le tunnel lors d’une évacuation, et niveau d’intégrité de la sécurité varie de 1 (bas niveau de sécurité)
a donc un impact sur la sécurité. à 4 (haut niveau de sécurité).
Système complet
50126
Sous-système signalisation Train
50129
50159
Équipement Équipement
Hardware Logiciel Hardware Logiciel
50128
50155
Figure 11 – Normes applicables aux systèmes ferroviaires
La norme CENELEC EN 50128 permet de gérer la sécurité des 2.2 Choix du SSIL
applications logicielles. Dans le cadre de [BM 8 071] nous avons pré-
senté les techniques de mise en sécurité d’une application logicielle.
Cette norme est plus particulièrement dédiée aux aspects dévelop- Le SSIL des fonctions du logiciel est donc identifié sur la base
pement des applications logicielles pour le domaine ferroviaire. des analyses de sécurité système. C’est un objectif à atteindre lors
Concernant les logiciels, le SSIL (Software SIL) défini permet de de la réalisation du logiciel. Une fois qu’il est déterminé, il est uti-
déterminer différents niveaux de criticité, de 0 (pas de danger) à 4 lisé pour choisir les méthodes et techniques à mettre en œuvre
(critique). lors de chaque phase du cycle de réalisation. L’annexe A de la
norme CENELEC EN 50128 introduit des tables (voir par exemple le
La norme CENELEC EN 50128 s’applique pour des domaines liés tableau 1) qui identifient pour chaque SSIL les techniques appli-
à la sécurité ou non – c’est pourquoi elle introduit le SSIL0 qui est cables (M, HR) ou non (R, -, NR). C’est pourquoi la norme CENELEC
lié aux applications logicielles sans besoin sécuritaire –, et exclusi- EN 50128 introduit la notion d’évaluation indépendante qui a pour
vement aux logiciels et à l’interaction de l’application logicielle but de faire confirmer l’atteinte de l’objectif par une personne
avec le système dans son ensemble. externe au projet [62] nommé ISA (Independant Safety Assessor ).
Elle introduit explicitement la notion d’évaluation. Comme nous
l’avions montré dans [2] [3] [6], pour les applications logicielles, l’éva- Une analyse approfondie de la norme CENELEC EN 50128
luation logicielle consiste à démontrer que l’application logicielle montre que pour un SSIL1 et un SSIL2 on réalise le même type
atteint les objectifs de sécurité (au sens safety ) qui lui ont été attribués. d’activité et qu’il en est de même pour un SSIL3 et un SSIL4. On
peut rappeler que le SSIL1 n’est pas lié à des impacts sur la vie
humaine mais plutôt à des impacts sur les équipements, c’est
SSIL pourquoi il est en général utilisé trois niveaux de SSIL : le SSIL0, le
Le SSIL est un objectif d’intégrité de la sécurité qu’il faut SSIL2 et le SSIL3/4. En cas d’identification d’un SSIL1, il est recom-
atteindre. Cet objectif n’est pas mesurable, c’est pourquoi la mandé de le reclasser en SSIL0 ou en SSIL2 en fonction de la gra-
norme CENELEC EN 50128 introduit la notion d’évaluation. Une vité des risques associés.
personne indépendante de l’équipe en charge de réaliser le
logiciel va évaluer l’atteinte de cet objectif. Il faut rappeler que
la principale mesure pour réaliser un logiciel de sécurité
consiste à maîtriser le nombre de fautes systématiques et pour 2.3 Structure de la norme CENELEC
ce faire, il faut maîtriser le processus de réalisation et la com- EN 50128
plexité du logiciel. Le SSIL est lié à la notion de confiance, et la
question posée à l’évaluateur est donc : « Avez-vous confiance
dans la maîtrise de ce logiciel ? ». La version 2011 de la norme CENELEC EN 50128 introduit la

notion d’assurance logiciel qui vise à réaliser un logiciel avec un
minimum de défauts et qui se base sur la maîtrise de l’assurance
Cette norme recommande la mise en place d’un cycle en « V »
qualité, la maîtrise des compétences, la vérification et la validation,
qui va de la spécification des exigences du logiciel aux tests des
et l’évaluation indépendante. Elle introduit une séparation claire
exigences du logiciel sur la cible finale. L’un des points particuliers
entre les données de l’application et le logiciel qui est alors noté
de la norme CENELEC 50128 réside dans la nécessité de démontrer
application générique.
la mise en œuvre de moyens. C’est pourquoi il est dit que c’est
une norme de moyens au contraire des normes aéronautiques qui Un des points importants de la nouvelle norme CENELEC
sont des normes d’objectifs. EN 50128:2011 réside dans l’ajout de la clause 9 qui est dédiée à la
Il est à noter que le référentiel CENELEC et en particulier la maîtrise de la maintenance et du déploiement du logiciel. La
norme CENELEC EN 50128 ne traite pas les aspects sécurité-confi- figure 12 présente la structure de la version 2011 de la norme
dentialité (au sens security ). CENELEC EN 50128.
EN 50128
SSIL Clauses 4
Rôle Clauses 5 Annexe B
Données de l’application
Clauses 8
Clauses 6 Clauses 9
Clauses 7
Assurance logiciel Maintenance
Déploiement
Logiciel générique
Annexe A Annexe D
Techniques Bibliographies liées aux techniques
Figure 12 – Structure de la norme CENELEC EN 50128:2011
Comme cela a été indiqué, la norme CENELEC EN 50128:2011

introduit une séparation claire entre la notion de logiciel générique 3. Méthodes formelles,
et les données de paramétrage. La clause 7 est dédiée à la réalisa-
tion du logiciel générique et la clause 8 à la réalisation du proces-
semi-formelles,
sus de production des données. structurées et techniques
formelles
2.4 Cycle de développement de la norme
CENELEC EN 50128 3.1 Définitions
La norme CENELEC EN 50128:2011 identifie un processus de réa-
lisation d’un logiciel pour les applications ferroviaires et identifie 3.1.1 Modèle
les moyens qui doivent être mis en œuvre afin d’atteindre le
La définition d’un modèle M est un moyen pour comprendre
niveau d’assurance sécurité identifié.
et/ou appréhender un problème/une situation. En général, la phase
Elle introduit de nouveaux besoins comme la séparation entre le de spécification qui permet de s’approprier le cahier des charges
logiciel générique et les données de paramétrage, la qualification passe par la création d’un modèle M.
des outils, le besoin de documenter et le besoin de maîtriser la Un modèle peut être plus ou moins proche du système étudié,
maintenance et le déploiement des nouvelles versions du logiciel. on parle alors d’abstraction. Plus la modélisation est proche, plus
Dans le cadre de [TRP 3 305], nous avons présenté la mise en les résultats obtenus seront proches de ceux qui seront observés
œuvre de la norme CENELEC 50128:2011 avec un focus sur les sur le système final.
clauses 6, 7 et 9. Pour la clause 8 qui concerne la préparation des
Si le modèle est utilisé pour l’élicitation des exigences, il sera
données, il faut se référer à [TRP 3 306] et pour la qualification des
plutôt un prototype du système à réaliser. S’il est utilisé pour la
outils à [TRP 3 304].
vérification des exigences (cohérence, complétude, etc.) il aura la
Comme le montre la figure 13, le cycle de la norme CENELEC forme d’une collection de modèle, chaque modèle permettant de
EN 50128 est celui qui a été présenté dans le cadre de la figure 4, modéliser une ou plusieurs exigences.
mais avec pour chaque phase une étape de vérification. Une autre caractéristique des modèles provient du fait que le lan-
gage support dispose ou non d’une sémantique. En l’absence de
sémantique, il s’agit de modèle pour conceptualiser et raisonner sur

le besoin. En présence de sémantique, il sera possible de vérifier des
2.5 Bilan propriétés, voir de générer tout ou partie du code finale.
La présence d’une sémantique permet de mettre en œuvre des
La norme CENELEC 50128 dans sa version 2011 introduit de techniques de raisonnement qui garantissent la correction (au sens
nombreux changements (organisation, besoin de formaliser les vérification) des résultats obtenus. La sémantique permet effective-
compétences, séparation entre logiciel générique et paramétrage, ment de vérifier que le logiciel respecte des propriétés (d’ou le
déploiement, etc.), mais elle renforce aussi la possibilité d’utiliser retrait de certaine phase de tests comme les TU et les TI L/L) mais
les méthodes formelles et les techniques formelles lors de la réali- il reste nécessaire d’exécuter le logiciel sur la machine cible afin de
sation du logiciel et de sa vérification. vérifier que l’ensemble (logiciel + matériel support) est conforme
aux exigences. La machine cible pouvant compromettre l’exécu-
Dans toutes ces versions, la norme CENELEC 50128 ne fournit
tion du logiciel.
pas de guide sur la mise en œuvre des méthodes formelles.
Dès le niveau SSIL 1, la nouvelle version de la norme CENELEC
Dans le cadre de [58], nous avons présenté la norme CENELEC EN 50128:2011 – table A.3 recommande que l’architecture de
50128 et sa mise en œuvre. l’application logicielle se base sur une méthode structurée (SADT,
OMT, etc.). Mais il est possible de mettre en place une modélisa-
tion qui se base sur les techniques de la table A.17 (tableau 2).
Il ressort des différents projets (réalisé depuis le SACEM) que la
Spécification modélisation est un besoin essentiel pour les différentes phases de
Spécification Exécution des TE
des tests d’ensemble réalisation d’une application logicielle. La principale évolution de
ces dernières années réside dans la reconnaissance de la nécessité
Vérification Vérification de réaliser des modèles. La figure 14 présente un exemple de
modèle SIMULINK.
Architecture Spécification des TI Exécution des TI
Vérification Vérification
1
ln 1
AND
Conception
Spécification des TC Exécution des TC
des composants 2
ln 2
Vérification Vérification Logical
operator
OR 1
3
ln 3 Logical Out 1
Codage operator 1
Figure 13 – Cycle en « V » de la norme CENELEC EN 50128 Figure 14 – Exemple de modèle Simulink
Tableau 2 – Nouvelle version de la norme CENELEC 50128:2011 – table A.17

SSIL0 SSIL1 SSIL2 SSIL3 SSIL4
Modélisation de données R R R HR HR
Organisation des données – R R HR HR
Diagramme du flux de commande R R R HR HR
Automates à états finis/schémas de transition – HR HR HR HR
...
Méthodes formelles R R R HR HR
Diagrammes de séquences R HR HR HR HR
3.1.2 Méthode semi-formelle norme CENELEC 50128 identifiait SADT [13], OMT, JSD, CORE,
Yourdon temps réel, MASCOT. À noter que seule les approches
D’après la norme IEC 61508 (B.2.3), une méthode semi-formelle SADT et SART sont utilisées dans le domaine ferroviaire.
offre un moyen de développer une description d’un système à un La spécification structurée est une technique qui vise à mettre en
stade de développement (spécification, architecture et/ou concep- évidence les relations visibles les plus simples entre les exigences
tion). La description peut être analysée ou animée afin de vérifier partielles de la spécification fonctionnelle. L’analyse est affinée par
que le système modélisé satisfait aux exigences (réelles et/ou spéci- étapes jusqu’à obtenir de petites exigences partielles claires. On
fiées). Il est indiqué que les diagrammes d’états (automates finis) et obtient alors une structure hiérarchique d’exigences partielles qui
les réseaux de Petri temporels sont deux méthodes semi-formelles. permettront de spécifier les exigences complètes. La méthode met
Dans le cadre de la nouvelle norme CENELEC EN 50128:2011, les l’accent sur les interfaces entre les exigences et permet d’éviter les
méthodes semi-formelles disparaissent en tant que techniques. défaillances d’interfaces.
Cela est dû à l’ambiguïté qui existait, entre formel et semi-formel,
certains industriels considérant que l’existence d’un outil de modé-

lisation était suffisant pour revendiquer la mise en place d’une 3.1.5 Outils de spécification assistée
méthode semi-formelle. par ordinateur
Dans le cadre de la section B.2.4 de la norme IEC 61508, il est
3.1.3 Méthode formelle indiqué que la mise en œuvre d’outils de spécification assistée par
ordinateur permet d’obtenir une spécification sous forme de base
La section B.30 de la norme IEC 61508 indique qu’une méthode de données qui peut être inspectée automatiquement pour évaluer
formelle (HOL, CSP, LOTOS, CCS, logique temporelle, VDM [15] et la cohérence et la complétude. L’outil peut permettre l’animation.
Z [16]) permet de réaliser une description, non ambiguë et cohé- L’application peut se faire sur les différentes phases : spécification,
rente, d’un système à un stade de développement (spécification, architecture et/ou conception. Pour la phase de conception, l’utili-
architecture et/ou conception). La description prend une forme sation est recommandée dès lors qu’il existe des outils, mais il
mathématique et peut être soumise à une analyse mathématique. sera nécessaire de démontrer la correction de l’outil (retour
Cette analyse mathématique peut être outillée. d’expérience et/ou vérification indépendante des résultats).
Nota : dans la norme IEC 61508, les références à VDM incluent VDM++ qui est une
3.2 Méthode formelle versus technique

extension temps réel et orienté objet de VDM. À noter que dans la norme IEC 61508, la
méthode B [1] [14] est vue comme une méthode associée à Z.
Une méthode formelle offre en générale une notation, une tech-

formelle
nique pour élaborer une description dans cette notation et un pro- Dans le cadre de la section précédente, nous avons repris les défini-
cessus de vérification pour contrôler la correction des exigences. tions utilisées dans les normes IEC 61508 et CENELEC EN 50128:2011,
À noter que la norme IEC 61508 indique qu’il est possible de afin de disposer d’une première base de discussion. Plusieurs termes
faire des transformations jusqu’à, d’après les termes de la norme, associés à la notion de « formelle » sont utilisés sans qu’il soit facile
« une conception de circuit logique ». de bien comprendre de quoi l’on parle effectivement.
Par techniques formelles, nous entendons les différentes
3.1.4 Méthode structurée approches basées sur les mathématiques permettant de démontrer
qu’une application logicielle respecte un certain nombre de pro-
Le but des méthodes structurées (CENELEC EN 50128 – B.60) est priétés. Les techniques formelles (simulation, model checking [8],
de promouvoir la qualité de développement du logiciel en portant interprétation abstraite, preuve, etc.) ne sont pas nouvelles. En
l’attention sur les premières phases du cycle de vie. Ce type de effet, les premiers papiers qui traitent du sujet datent des années
méthode fait appel à des notations précises et intuitives (en géné- 1970 (voir par exemple [10] [12] [21]). Mais la mise en place de
ral assistées par ordinateur) afin de produire et de documenter les méthodes formelles date des années 1980 [15] [16] [22] avec des
exigences et les caractéristiques d’implantation du produit. utilisations industrielles dans les années 1990 [7] [23] [24] [25].
Les méthodes structurées sont des outils de réflexion. Elles se Le terme méthode formelle regroupe [26] [27] :
basent sur un ordre de réflexion logique, une analyse du système, – des langages :
en prenant en compte l’environnement, la production de la docu- • ayant un vocabulaire et une syntaxe formellement définis,
mentation du système, la décomposition des données, la décompo-
sition des fonctions, les éléments à vérifier. Elles doivent imposer • dont la sémantique est définie mathématiquement ;
une faible servitude intellectuelle (méthode simple, intuitive et prag- – des techniques (formelles) de transformation et de vérification
matique). Parmi les méthodes structurées, la version 2001 de la basées sur la preuve mathématique.
À noter que l’utilisation standard des méthodes formelles

consiste à réaliser des modèles de spécifications et/ou de concep- Tableau 3 – CENELEC EN 50128 – table A.2
tion mais que, de plus en plus, les techniques formelles sont vues SSIL1 SSIL3
comme une possibilité de réaliser une vérification (analyse sta- SSIL0
SSIL2 SSIL4
tique de code, démonstration du respect de propriété, bonne ges-
tion des calculs sur les flottants, etc.) sur le code (manuel ou Méthodes formelles (basées sur – R HR
généré). une approche mathématique)
Modélisation R R HR
Méthodologie structurée R R HR
4. Mise en œuvre Table de décision R R HR
des méthodes formelles
lors de la réalisation
S1
d’une application logicielle E1
S2
E2
4.1 Spécification des exigences
du logiciel E3
4.1.1 Besoin I1 I2 I3
Concernant les exigences du logiciel, elles doivent respecter au

moins trois points :
– être claires, précises, univoques, vérifiables, testables, mainte-
Figure 15 – Environnement de l’application logicielle
nables et réalisables ;
– être traçables avec les éléments d’entrée ;
– être non ambiguës et ne pas être susceptibles d’être mal com-

prises.
Concernant la gestion des exigences, nous avons présenté les Boot
concepts et les méthodes dans le cadre de [29] mais [28] reste une
référence pour la gestion des exigences.
Le tableau 3 introduit des exigences complémentaires au corps
de la norme. Ainsi la norme CENELEC EN 50128 recommande que
la spécification d’une application logicielle soit composée d’une
description textuelle du problème (les exigences) et de toutes les
notations nécessaires (modèle, diagramme, formule mathéma- Init
tique, etc.).
4.1.2 Spécification
La spécification d’une application logicielle est constituée au
minimum d’un ensemble d’exigences.
Maintenance Normal Dégradé
Mais cela n’est pas suffisant car l’environnement de l’application
logicielle est composé des interfaces avec les moyens matériels
(mémoire, adresse spécifique, entrées/sorties, watchdog, etc.),
avec d’autres applications logicielles (logiciel de base, application Figure 16 – Différents états applicables au logiciel
connexe, etc.) et/ou avec le système d’exploitation. Et cet environ-
nement doit être identifié au sein de la spécification des exigences.
La figure 15 fait apparaître un environnement de l’application
logicielle qui est composé de trois entrées Ei , de deux sorties Sd et Cahier des charges Analyse de sécurité
de trois interfaces Ik avec les moyens matériels (exemple accès à
une adresse mémoire spécifique).
À la mise sous tension d’un équipement, il y a une phase d’ini- Exigences
tialisation qui sera suivi par le passage en mode normal et suite à Exigences fonctionnelles extrafonctionnelles
la détection d’une défaillance, on pourra passer dans le mode Processus
dégradé. La figure 16 présente un exemple représentant les diffé- d’élaboration
rents modes de fonctionnement. Il faudra au niveau du logiciel de la spécification
identifier le comportement de l’application logicielle pour chaque
mode.
La figure 17 présente le processus d’élaboration de la spécifica- Spécification
tion. Une première analyse du cahier des charges fourni par le
client et/ou de la spécification système doit permettre d’identifier
les exigences fonctionnelles. Figure 17 – Élaboration de la spécification
En parallèle de ce travail, il est possible de débuter les analyses La réussite du développement d’une application logicielle main-
liées à la sûreté de fonctionnement qui ont pour objectif d’identi- tenable doit passer par au moins deux étapes :
fier les mitigations à mettre en place pour maîtriser les risques. Les – une phase de formalisation des exigences (figure 20). Cette
mitigations feront apparaître des exigences fonctionnelles et non phase de formalisation peut s’appuyer sur des méthodes structu-
fonctionnelles : exigences de sécurité mais aussi exigences de dis- rées (par exemple la figure 19 en SADT permet de mettre en place
ponibilité, de fiabilité ou autre. une analyse fonctionnelle, etc.), des méthodes semi-formelles ou
formelles (automate, réseau de Pétri, Grafcet, méthode B, SCADE,
Finalement, la spécification doit identifier : etc.) ;
– les interfaces avec l’environnement ; – une phase d’architecture (§ 4.2).
– la notion d’état en mettant en place une partition entre les Nota : la méthode SADT [13] (Structured Analysis and Design Technic ) a été mise au
point par la société Softech aux États-Unis ; il s’agit d’une méthode d’analyse par
états de bon fonctionnement, les états de repli et les états niveaux successifs d’approche descriptive d’un ensemble quel qu’il soit.
dangereux ; Dans le cadre du chapitre 2 de [30], nous avons présenté un exemple de l’utilisation
de SADT et de la méthode B [1] [24] dans le cadre du projet SAET-METEOR [4].
– la notion de comportement correct et de comportement Comme exemple d’utilisation de SCADE [9] on peut se référer à la réalisation du CBTC
dangereux ; de la ligne 5 d’Ansaldo STS, ou à la réalisation de logiciel du CBTC de la ligne 13 déve-
loppée par THALES.
– la notion d’exigence liée à la sécurité, ce type d’exigence doit
permettre de caractériser les comportements dangereux ; La phase de formalisation est importante car elle permet de tra-
duire une exigence abstraite en éléments modélisables, ainsi la
– le niveau d’intégrité du logiciel (noté SSIL).
propriété P1 suivante :
P1 : « il ne doit pas y avoir de risque de collision »
4.1.3 Mise en œuvre peut se traduire en logique ensembliste du premier ordre en
qui est le
Sur de nombreux projets (suite à des problèmes de coût et/ou domaine de marche du train i et [T ] qui est l’ensemble des trains.
de délais), les concepteurs d’applications logicielles passent direc- Le modèle B explicitant cette propriété, est donné en exemple à
tement des exigences textuelles au code sans avoir pu vérifier la la figure 20.
cohérence des exigences et sans toujours maîtriser l’ensemble des
exigences (figure 18). Le passage des exigences textuelles au modèle est présenté à la
figure 21.
…
Req_11: … Activation cycle
Req_12: … *
*
Req_13: …
Activation Déplacement Suite
+
… traitement
train train 1
int xx; + Désactivation

main () Déplacement
train
{ train 2
…
}
Figure 19 – Exemple de statique introduisant différents types

Figure 18 – Des exigences au code de communication
MACHINE
Exemple
SETS
TRAIN
POSITION
VARIABLES
Domaine
INVARIANT
Domaine : TRAIN-->POW(POSITION)
& !(t1,t2). ((t1,t2: TRAIN*TRAIN) => ((Domaine(t1) ∧ Domaine(t2) = {}) & (t1/=t2)))
INITIALISATION
Domaine:( Domaine : TRAIN - ->POW(POSITION)
& !(t1,t2). ((t1,t2: TRAIN*TRAIN) => ((Domaine(t1) ∧ Domaine(t2) = {}) & (t1/=t2)))
)
END
Figure 20 – Modèle B explicitant la propriété P
– acquérir le besoin ;
… – formaliser le besoin et vérifier la cohérence et la complétude
Req_11: … du besoin ;
Req_12: … – aider à sélectionner les cas de tests de validation.
Req_13: … Comme le montre la figure 22, la modélisation peut être utilisée
… comme moyen de vérification des exigences. Les exigences en
entrée de la spécification du logiciel proviennent des spécifications
systèmes et des analyses de sécurité (analyse de sécurité système,
analyse de sécurité des interfaces, etc.). Sur la base de toutes les
exigences en entrée, il est possible de réaliser un modèle pour
vérifier qu’elles forment un ensemble cohérent, il sera aussi pos-
sible de travailler sur la complétude de cet ensemble d’exigences.
Dans la partie basse de la table A.2 (tableau 3) de la norme
CENELEC EN 50128:2011, il est indiqué qu’il est obligatoire de dis-
poser d’une expression textuelle des exigences et qu’il est possible
d’y associer tous les éléments de modélisation nécessaire. Comme
le montre la figure 23, tout ou partie des exigences peut être
modélisée afin de réaliser des vérifications de complétudes et de
Figure 21 – Formalisation des exigences cohérences. Il est possible d’avoir un ou des modèles.
La réalisation d’une spécification d’une application logicielle
4.1.4 Synthèse nécessite de :
6) Réaliser un modèle associé aux exigences ;
Dans le cadre du domaine ferroviaire, les méthodes structurées, 7) Disposer d’un moyen de faire des vérifications sur le modèle
semi-formelles et formelles sont utilisées pour : afin de vérifier la cohérence et/ou la complétude.
S1
E1
S1 …
E1 S2
… E2 Req_11: …
S2 Req_12: …
E2 Req_11: …
Req_12: … E3 Req_13: …
E3 Req_13: …
I1 I2 I3
I1 I2 I3
Figure 22 – Formalisation des exigences
…
Req_11: …
Req_12: …
Req_13: … Analyse
Figure 23 – Exigences, modèle et vérification
Au niveau de la spécification des exigences du logiciel, ce

modèle n’est pas obligatoire mais il permet de travailler sur la S1
cohérence et la complétude des exigences. E1 C1 – {Ex1} C2 – {Ex2}
S2
4.2 Architecture
4.2.1 Présentation E2 C3 – {Ex3}
Une fois la spécification de l’application logicielle réalisée, il est
alors possible de mettre en place une architecture. Cette architec-
ture vise à « décomposer » l’application logicielle en composants
Figure 24 – Exemple d’architecture d’une application logicielle
(ou modules suivant le vocabulaire utilisé).
La figure 24 présente un exemple d’architecture, l’application
logicielle a été décomposée en trois composants (C1 , C2 , C3). Il 4.2.3 Avantages/désavantages
existe des interfaces entre l’environnement (E1 , E2 , S1 , S2) et les
composants et des interfaces entre les composants. Pour chaque Une architecture est par nature une collection de boîtes (compo-
composant, une liste des exigences à prendre en compte est don- sants), chaque boîte étant associée à des interfaces et les inter-
née et identifiée. Les exigences associées à chaque composant faces reliées par des connexions. Une architecture est donc un
sont traçable avec la spécification des exigences de l’application modèle au moins structuré (figure 26).
logicielle. L’architecture d’un logiciel est en soit un modèle (des compo-
sants, des interfaces et des liens entre interfaces). Ce modèle per-
4.2.2 Modèle met de vérifier la cohérence (toutes les interfaces sont connectées,
toutes les exigences sont tracées, etc.).
La nouvelle version de la norme CENELEC EN 50128:2011 – table
A.3 recommande que l’architecture de l’application logicielle se La réalisation d’une architecture d’une application logicielle
base sur une méthode structurée (SADT, etc.). Mais il est possible (mais on peut dire de même pour la phase de conception) néces-
de mettre en place une modélisation qui se base sur les techniques site de :
de la table A.17 (tableau 2). 6) Réaliser un modèle ;
La réalisation d’un modèle M est un moyen pour comprendre 7) Disposer d’un moyen de faire des vérifications sur le modèle
et/ou appréhender un problème/une situation. En général, la phase afin de vérifier la cohérence et/ou la complétude ;
de spécification qui permet de s’approprier le cahier des charges 8) Pouvoir poursuivre le processus de la phase de spécification
passe par la création d’un modèle M. Un modèle peut être plus ou jusqu’à la phase de conception, voire la phase de codage ;
moins proche du système étudié, on parle alors d’abstraction. Plus – etc.
la modélisation est proche, plus les résultats obtenus seront Par rapport à l’étape de spécification, ici le modèle d’architecture
proches de ceux qui seront observés sur le système final. est une partie du document d’architecture. La vérification du
Une autre caractéristique des modèles provient du fait que le modèle concerne la vérification des interfaces mais peut aller
langage support dispose ou non d’une sémantique. La présence jusqu’à la vérification de la cohérence des exigences.
d’une sémantique permet de mettre en œuvre des techniques de
raisonnement qui garantissent la correction des résultats obtenus.
Un modèle est en général composé de deux parties
4.3 Codage
complémentaires :
4.3.1 Présentation
– une modélisation statique (figures 18 et 23) décrivant les enti-
tés constituant le système et les états pouvant lui être associés ; Le processus classique de développement d’une application
– une modélisation dynamique décrivant les changements d’état logicielle se base sur l’utilisation de langage de programmation
autorisés. comme par exemple le langage Ada, C et/ou C++. Même si ces lan-
La figure 25 présente un exemple de modèle UML [31] d’un sys- gages sont d’un certain niveau d’abstraction par rapport au code
tème ferroviaire mettant en œuvre différentes modélisations : cas exécuté sur le calculateur final, ils nécessitent l’écriture de ligne de
d’utilisation, diagramme de séquences, diagramme états/transi- code.
tions et diagramme de classes. Il y a eu plusieurs essais de mise Il n’est pas possible d’analyser tous les langages de programma-
en œuvre de la notation UML (ligne 13 du métro parisien) qui n’ont tion existant et pour tous les domaines, aussi dans le reste de ce
pas été couronné de succès. paragraphe, nous analyserons l’évolution qui a pu avoir lieu dans
L’utilisation de la notation UML n’est donc pas sans soulever le domaine du ferroviaire.
certaines questions [32] [33]. Comment utiliser une notation Le but de cette section est de rappeler les points forts et les
n’ayant pas de sémantique ? Comment évaluer une application points faibles des langages utilisés afin d’expliquer pourquoi il est
fondée sur la notation UML ? Quels sous-ensembles d’UML pour nécessaire de s’orienter vers la génération de code automatique.
les applications critiques ? Plusieurs travaux visent à proposer des
réponses à ces questions, comme par exemple [35] [36] [38] [37] 4.3.2 Bilan
et/ou [34].
La notation UML [31] n’est pour l’instant pas reconnue comme 4.3.2.1 Langage Ada
une méthode structurée et/ou semi-formelle dans l’ensemble des Les premières applications ferroviaires en France ont été pro-
standards même si beaucoup veulent la mettre en œuvre complè- grammées, au milieu des années 1980, avec le langage Modula 2.
tement ou partiellement. Dans le cadre de [39] [43] et du chapitre Mais depuis, le langage Ada 83 est devenu le langage de référence
19 de [40], nous avons montré comment la notation UML peut être pour le développement des applications critiques [86]. Comme le
utilisé pour réaliser des modèles de systèmes critiques. Dans le montre le tableau 4, dans le cadre des applications ayant un haut
cadre des projets RT3-TUCS, ANR-SAFECODE et niveau de criticité (SSIL3/SSIL4), le langage Ada lui-même n’est
ANR-RNTL-MEMVATEX nous avons étudié différentes pistes pour que recommandé (R), il faut mettre en place un sous-ensemble du
introduire UML comme moyen de modéliser un système critique langage pour que l’utilisation du langage Ada soit hautement
(voir par exemple [33] [41] [42] [44] [45] [46]). recommandé (HR).
System
Start
the train
Conductor Physical
Train
Conductor Train
Start Start
Accelerate
Accelerate\speed=speed+x
Stop Start Start
Deccelerate[speed/=0]
Deccelerate[speed=0]
Train
Speed Wagon
1
Start *
Accelerate
Deccelerate
Package
Hight speed Low speed

train train
Figure 25 – Exemple de modèle UML
E1 … S1
Req_11: …
E2 S2
Req_12: …
E3
Req_13: …
l1 l2 l3
E1 S1
S2
E2
E3
l1 l2 l3
Figure 26 – Exigences de l’architecture
Tableau 4 – CENELEC 50128:2001 – table A.15

Ada R HR HR R R
Modula-2 R HR HR R R
Pascal R HR HR R R
C ou C++ sans restriction R – – NR NR
Sous-ensemble de C ou C++ R R R R R
Le langage Ada (figure 27) a été conçu à l’initiative du départe-

with Ada.Text_IO;
ment de la défense des États-Unis pour fédérer plus de 400 langages
procedure Hello is
ou dialectes utilisés par cet organisme dans les années 1970. begin Ada.Text_IO.Put_Line("Hello, world!");
Le langage Ada est très largement utilisé dans le cadre des end Hello;
applications logicielles embarquées en avionique (Airbus), dans le
spatial (fusée Ariane) et dans le domaine ferroviaire. La principale Figure 27 – Exemple de code Ada
caractéristique de ces systèmes c’est qu’ils requièrent une correc-
tion de l’exécution.
Suite à la définition de la version 2012 du langage Ada qui intro-
Le langage Ada 83 a évolué vers une seconde norme majeure duit la notion de précondition, invariant et postcondition, il est
Ada 95 qui est le premier langage objet normalisé. Il apporte la possible de décrire l’algorithme mais aussi les propriétés que
possibilité de construire des modèles orientés objets. La dernière celui-ci doit respecter et donc de vérifier durant l’exécution les pro-
version en date est appelée Ada 2012. priétés. Les outils SPARK Ada dans leur version 2014 constituent
Concernant la certification des compilateurs Ada, l’existence un environnement de preuve. Cet environnement de preuve per-
d’une norme et d’une sémantique assez fine du langage Ada a permet de démontrer que l’algorithme respecte les propriétés annon-
cées. Nous sommes très proche de ce que propose la méthode B
mis de définir un processus de certification d’un compilateur. Ce

processus a été mis en œuvre sur différents compilateurs. Ce pro- mais au niveau du code. À noter, qu’il existe une version libre des
cessus repose sur une suite de tests nommée ACATS (Ada Confor- outils SPARK Ada.
mity Assessment Test Suite), voir la norme ISO 18009:1999. Pour
en savoir plus, on peut consulter [47].
4.3.2.2 Langage C
Pour l’instant, ces nouvelles versions du langage Ada n’ont pas
été adoptées par le domaine des systèmes embarqués, à cause de Le langage C [18] est un des premiers langages qui a été mis à
l’aspect orienté objet. Mais les compilateurs Ada 95, au vue de disposition des développeurs pour réaliser des applications com-
leurs efficacités, sont utilisés lors de la compilation sachant que plexes. La principale difficulté du langage C réside dans la défini-
l’on reste sur un sous-ensemble du langage qui n’utilise pas les tion partielle du langage ce qui fait que différents compilateurs
traits « orienté objet ». génère un exécutable avec différents comportements. Il a été
L’aspect « orienté objet » n’était pas pris en compte par les depuis soumis à un processus de normalisation par l’ANSI
normes applicables CENELEC EN 50128:2001, DO 178:B, ISO 9899:1999.
CEI/IEC 61508:2008, ISO 26262:2011 aux applications critiques.
Concernant l’utilisation du langage C, en fonction du niveau de
Afin de contourner cet écueil, la norme ISO 15942:2000 définit
sécurité souhaité, la norme CENELEC 50128:2001 recommande de
une restriction sur les constructions du langage Ada 95 et définit
définir un sous-ensemble du langage, dont l’exécution soit maitri-
des règles d’utilisation (style de programmation) qui permettent de
sable.
réaliser une application dite certifiable.
Dans sa première version, le langage SPARK Ada [48] est un lan- Le tableau 5 (extrait de la nouvelle version de la norme CENE-
gage de programmation qui est un sous-ensemble de Ada. Toutes LEC EN 50128:2011) montre qu’il a été considéré que l’on disposait
les structures complexes d’Ada considérées comme risquées ou ne d’un retour d’expérience suffisant pour les langage Ada, C et C++
permettant pas une démonstration aisée de la sécurité ne se ce qui permet de ne plus mentionner explicitement la notion de
retrouvent pas dans SPARK Ada. Un mécanisme permettant sous-ensemble du langage car il est considéré comme acquis.
Tableau 5 – Nouvelle version de la norme CENELEC 50128:2011 – table A.15 (partielle)

Ada R HR HR HR HR
Modula-2 R HR HR HR HR
Pascal R HR HR HR HR
C ou C++ R R R R R
C# R R R R R
Java R R R R R
La figure 28 présente un morceau de code C qui peut donner

deux codes différents en fonction de l’anomalie (a) ou (b) qui est Soit le fragment de programme
mise en œuvre. Cet exemple met en avant les faiblesses du lan- C suivant :
gage C, de petites erreurs de programmation ne sont pas détec-
tées à la compilation. Il est à noter que ce type d’erreur est détecté
if (TheSignal == clear) if (TheSignal == clear);
si le langage de programmation utilisé est l’Ada. (a)
{ {
Certaine des faiblesses du langage C peuvent être contournées open_gates(); open_gates();
en mettant en place des règles de programmation, à titre Start_train(); défaillance Start_train();
d’exemple, pour éviter une anomalie du type if (a = cond) au lieu
} }
de if (a == cond), on peut mettre en place une règle de la forme
« dans le cadre de la comparaison avec une variable, celle-ci doit
être dans la partie gauche de l’expression ». (b) défaillance
Dès 1994, des retours d’expérience concernant la mise en œuvre
du langage C [87] ont fait apparaître qu’il était possible de définir
un sous-ensemble de C utilisable pour réaliser des applications if (TheSignal = clear)
logicielles devant offrir un haut niveau de sécurité (SSIL3-SSIL4). {
En fait, depuis la fin des années 1990, pour le langage C, la open_gates();
Start_train();
norme MISRA-C est devenu un standard de fait qui a été déve-
loppé par le Motor Industry Software Reliability Association }
(MISRA).
MISRA-C:2004 spécifie des règles de programmation (voir les Figure 28 – Exemple de faute en C
exemples du tableau 6) permettant d’éviter les erreurs d’exécution
provoquées par les constructions mal définies, les comportements
imprévus (certaine structure du langage C ne sont pas complète- cation pour les compilateurs C, même s’il existe des initiatives
ment définies), les malentendus entre les personnes en charge de comme [49].
la réalisation (code lisible, code avec implicite, etc.). Plusieurs
Nota : à noter que [49] présente un travail de vérification d’un compilateur C restreint
outils permettent de vérifier automatiquement les règles MISRA-C. mais que si le terme certification est introduit, il ne s’agit pas d’une certification par un
La norme MISRA-C:2004 reprend des règles (voir par exemple organisme externe. La certification ne s’attèle pas uniquement au fait que la démonstra-
tion que le compilateur est correct mais elle doit aussi s’appliquer au processus mis en
les règles 14.4 et 14.7 énoncées dans le tableau 6) qui sont expli- œuvre, aux éléments produits (documents, sources, etc.) et aux outils utilisés (Ocaml,
cites dans plusieurs normes : Coq et autres outils libres doivent être démontrés comme de sécurité).
– règle 14.4 : dans la norme CENELEC EN 50128 – table A.12 ou
la norme IEC 61508 – table B.1 ; 4.3.2.3 Langage orienté objet
– règle 14.7 : dans la norme CENELEC EN 50128 – table A.20 ou
la norme IEC 61508 – table B.9 ; Comme déjà dit plus haut, l’aspect « orienté objet » n’est pas
– etc. pris en compte par les normes applicables CENELEC
EN 50128:2001, DO 178:B, IEC 61508:2008, ISO 26262:2011 aux
MISRA-C a été créé en 1998 et actualisé en 2004 et en 2012, ce applications critiques.
qui montre que l’on dispose d’un retour d’expérience certain.
L’aspect orienté objet est cité dans la norme CENELEC
La principale difficulté du langage C reste le choix d’un compila- EN 50128:2001, mais les contraintes s’appliquant aux langages ne
teur disposant d’un retour d’expérience suffisant pour la cible choi- permettent pas le développement d’une applications critiques
sie et pour le niveau de sécurité à atteindre. En l’absence d’une (SSIL3 et SSIL4) avec ce type de langage (tableau 7).
norme précise et complète, il n’existe pas de processus de certifi-
Tableau 6 – Quelques règles MISRA-C:2004

Id Statuts Description
Règle 1.1 Requise Tout le code doit être conforme à la norme ISO 9899:1990 « Programming languages – C »,
amendée et corrigée par ISO/IEC9899/COR1:1995, ISO/IEC/9899/AMD1:1995 et
ISO/IEC9899/COR2:1996.
Règle 5.4 Requise Chaque tag est un unique identificateur.
Règle 14.1 Requise Il ne doit pas y avoir de code mort.
Règle 14.4 Requise Pas de branchement inconditionnel (goto) dans les programmes.
Règle 14.7 Requise Une fonction doit avoir un unique point de sortie à la fin de la fonction.
Règle 17.1 Requise L’arithmétique de pointeur ne peut être utilisé que pour des pointeurs qui adressent un
tableau ou un élément de tableau.
Règle 17.5 À traiter Une déclaration d’objet ne doit pas contenir plus de deux niveaux d’indirection de pointeur.
Une règle MISRA peut être « requise » (required ) ou « à traiter » (advisory). Une règle « requise » doit obligatoirement être mise en œuvre par le développeur
et une règle « à traiter » ne peut être ignoré même s’il n’est pas obligatoire de la mettre en œuvre.
MISRA-C:2004 introduit 122 règles « requises » et 20 règles « à traiter ».
Tableau 7 – CENELEC EN 50128:2011 – table A.12

Pas d’objets dynamiques – R R HR HR
Pas de variables dynamiques – R R HR HR
Usage limité des pointeurs – R R R R
Comme le montre le tableau 5, le langage C++ est cité comme Sous diverses pressions (diminution du nombre de program-
applicable mais certaines recommandations concernant son utili- meurs Ada et C par exemple) la mise à jour des normes comme la
sation ne sont pas compatibles avec l’utilisation d’un langage norme CENELEC EN 50128 ou la DO 178 a donné lieu à des initia-
orienté objet comme le montre le tableau 7. tives visant à introduire les langages orientés objets.
Le langage C++ a été développé au cours des années 1980, il Ainsi, la nouvelle version de la norme CENELEC EN 50128:2011 a
s’agit d’une amélioration du langage C. Le C++ introduit la notion étendu la liste des langages orienté objet utilisable à JAVA et aux
de classe, d’héritage, de fonction virtuelle et de surcharge. Il a été C# comme le montre le tableau 5. Mais cette nouvelle version de
normalisé par l’ISO en 1998 et en 2003. la norme introduit quelques restrictions (limitation sur l’héritage)
comme le montre le tableau 8.
Depuis le début des années 2000, plusieurs travaux ont été
entrepris afin de définir un cadre permettant d’utiliser le langage La version C de la norme DO 178 devrait disposer d’une annexe
C++ pour le développement des applications à haut niveau de spécifique visant à définir les contraintes de mise en œuvre d’un
sécurité (SSIL3-SSIL4). langage orienté objet pour la réalisation d’une application critique.
Comme pour le C, le point difficile avec le C++ reste la démons-
On peut citer les travaux : tration que le compilateur pour la cible choisie et les bibliothèques
– de l’OOTIA (Object Oriented Technology in Aviation) qui a associées respectent des objectifs de sécurité qui ont été définie
publié plusieurs guides [35] [36] [37] [38] ; par les études de sécurité. Comme il n’existe pas de certification
– du JSF++ (Join Strike Fighter C++) qui a publié un guide [50] pour les compilateurs C++, il faudra mettre en place une justifica-
concernant le développement en C++. Ce guide reprend les tration basée sur le retour d’expérience et/ou la qualification.
vaux existants et notamment la norme MISRA-C:1998 ;
– de MISRA qui a élaboré la norme MISRA-C++:2008. 4.3.3 Avantages/désavantages
Le langage C++ est donc un langage assez ancien. Des Le langage de programmation utilisé doit faciliter la détection
approches identifiant les points faibles du C++ et proposant des des anomalies et pour cela il est nécessaire de mettre en œuvre un
règles sont apparues assez tôt [88] [89], mais la définition d’un typage fort et une programmation modulaire et structurée.
cadre pour l’utilisation du C++ pour les applications à haut niveau
de sécurité est assez jeune [35] [36] [37] [38] / [90] [91], ce qui Comme le montre le tableau 9, l’une des principales difficultés
explique que l’on trouve des applications en C++ jusqu’au niveau lors de l’utilisation de langage tel que le C ou le C++ réside dans la
de sécurité SSIL2. démonstration du caractère « éprouvé » du traducteur.
Tableau 8 – CENELEC EN 50128:2011 – table A.23

SSIL1 SSIL3
SSIL0
SSIL2 SSIL4
Il convient que les classes n’aient qu’un seul objectif. R R HR
Héritage utilisé uniquement si la classe dérivée est un affinement de sa classe de base R HR HR
Profondeur de l’héritage limitée par des normes de codage R R HR
Neutralisation d’opérations (méthodes) sous contrôle strict R R HR
Héritage multiple utilisé uniquement pour les classes d’interface R HR HR
Héritage à partir de classes inconnues – – NR
Tableau 9 – IEC 61508 [IEC 98 – partie 3] – table A.3

SSIL3
SSIL1 SSIL2
SSIL4
Langage de programmation adéquat HR HR HR
Langage de programmation fortement typé HR HR HR
Sous-ensemble du langage – – HR
Outils certifiés R HR HR
Outils dans lesquels on a une confiance accrue résultant de l’utilisation HR HR HR
Traducteur certifié R HR HR
Traducteur : confiance accrue résultant de l’utilisation HR HR HR
Bibliothèque de modules logiciels et composants éprouvés/vérifiés R HR HR
L’utilisation d’un langage de programmation nécessite de :

9) Définir un sous-ensemble du langage (limitant les difficultés)
Procédures
et de disposer d’un ensemble de règle de conception et de
règles
codage ;
10) Disposer d’un retour d’expérience suffisant pour démontrer
que les outils et plus particulièrement le compilateur est utilisable
pour le niveau de sécurité attendue ;
Documents
11) Disposer d’outil d’analyse du code au lieu de réaliser les ana- de Sources
lyses manuelles, etc. conception
a
4.4 Génération de code
Les normes des différents domaines nécessitant un haut niveau Contraintes Contraintes
de sécurité prennent donc en compte l’utilisation des techniques Outils
formelles lorsqu’elles sont associées à des modélisations qui sont
associées aux documents de conception (spécification, architec-
ture, conception). Modèle
Actuellement, la phase de codage se base sur l’utilisation de lan- de Sources
gage de programmation du type Ada, C et/ou C++. Originellement, conception
ces langages ne sont pas associés à des techniques formelles de
vérification. b
La prise en compte des méthodes formelles passe par une évo- Figure 29 – Analyse formelle d’un code
lution du processus de réalisation qui doit prendre en compte la
phase de modélisation, comme le montre la figure 29.
La figure 30 présente le processus qui pourrait être mis en
Comme le montre la figure 29a, à partir des documents de
œuvre pour remplacer des TC et/ou des TI software/software (S/S)
conception (spécification, architecture, conception, etc.) et des pro-
par une vérification formelle. Il est nécessaire de montrer que la

cédures métiers, dans l’approche classique il faut produire le code.
preuve à la même efficacité que les tests de composants. Pour ce
Le passage par une phase de modélisation (figure 29b ) rend faire, il faut montrer que la preuve couvre bien l’ensemble du
plus important la notion d’outils et la nécessité de qualifier les code, afin de détecter les morceaux de code non spécifiés et/ou les
outils en fonction de leurs impacts sur l’application logicielle. manques dans l’ensemble des propriétés.
E1 … S1
Req_11: …
E2 S2
Req_12: … Tests d’ensemble sur cible
E3
Req_13: …
l1 l2 l3
Tl S/S
Tl H/S
int xx; Tests des composants

main ()
{
…
}
Vérification de l’absence d’erreur d’exécution

Ajout de pré/post Vérification de propriété par preuve
Figure 30 – Activité de vérification formelle du code
4.5 Interprétation abstraite …

Comme nous l’avons dit, il peut être assez difficile de réaliser les Req_11: …
activités de vérification et validation comme la revue et les tests Req_12: …
sur le code final (de type Ada, C ou C++) et il peut alors être inté-
Req_13: …
ressant de mettre en œuvre des techniques formelles telles que
l’interprétation abstraite [19] et/ou la preuve (du type [10]) qui per- …
mettront d’identifier des propriétés respectées par le code et/ou de
démontrer que le code vérifie certaines propriétés.
Dans le cadre de [5] (et plus particulièrement son chapitre 3)
int xx;
nous avons présenté plusieurs exemples de mises en œuvre
main ()
d’analyseur statique (figure 31) de la famille de l’« interprétation
{
abstraite » [19] [21]. Nous avons ainsi présenté des exemples d’uti- …
lisation de FramaC, Polyspace, Astrée et CodePeer. Analyse
}
Il est à noter que les outils d’interprétation abstraite comme
Polyspace ou Astrée ne sont pas nouveaux mais leur efficacité a Figure 31 – Analyse formelle d’un code
beaucoup évoluée. Nous sommes passés d’outils qui, il y a une
dizaine d’années, pouvaient nécessiter une semaine de calcul pour
analyser un code à des outils qui nécessitent quelques dizaines de Spécification informelle
minutes pour arriver à un résultat.
L’intérêt de l’outil Codepeer est de réaliser une analyse incré-
mentale. On part de chaque paquetage Ada et on analyse leurs Conception
comportements et seulement ensuite, on analyse le comportement Jusqu’à l’absence d’erreur
des composants intégrés et cela jusqu’à l’intégration complète ou
jusqu’à l’apparition d’un défaut à traiter. Codage
Exécution
Compilation déboggage
5. Réalisation mettant
en œuvre les approches

formelles Application
« exécutable »
Comme nous l’avons montré, il est nécessaire de mettre en
œuvre d’autres pratiques qui doivent permettre de détecter au plus Figure 32 – Processus classique
tôt et de façon plus large les défauts de l’application logicielle. Si
nous reprenons les besoins identifiés dans les différentes sections,
nous obtenons le tableau 10.
Spécification informelle
Il est à noter qu’une des difficultés dans la mise en œuvre de ces
techniques réside dans l’absence de reconnaissance de ces tech-
niques au sein des normes actuelles. En effet, certaines normes
préconisent la mise en œuvre des méthodes formelles mais elles
ne mentionnent pas les techniques telles que l’interprétation abs- Simulation
traite ou de méthodes dérivées. Spécification formelle Model checking
Preuve
5.1 Intégration des méthodes formelles

dans le cycle de réalisation Traduction
d’une application logicielle
Figure 33 – Processus formel dès la spécification
Le processus de réalisation d’une application logicielle passe en
général par différentes phases nécessitant l’exécution de l’applica-
tion logicielle. Et comme le montre la figure 32, la notion d’exécu-
tion est alors essentielle pour démontrer que l’application logicielle Spécification informelle
fonctionne correctement.
Dans le cadre d’un développement basé sur la notion de modéli-
sation (figure 33), le processus ne repose pas sur l’exécution de
l’application pour démontrer le bon fonctionnement de l’applica- Simulation
Conception formelle Model checking
tion mais sur le processus de réalisation. Ainsi, l’application logi-
Preuve
cielle est alors considérée correcte suite au processus qui a été mis
en œuvre. La correction est donc intrinsèque à la réalisation du
produit.
La figure 33 présente un exemple ou la réalisation d’un modèle
est faite dès la spécification et dans ce cas le modèle est un com- Traduction
plément à une spécification informelle qui peut contenir les exi-
gences. Mais le modèle peut aussi être introduit au niveau de la
conception (figure 34). Figure 34 – Processus formel débutant au niveau conception
Tableau 10 – Impact des méthodes formelles

ID Description Impact des méthodes formelles
N.1 Diminuer le nombre de défauts introduits dans 1. La mise en place d’un modèle formel sur l’ensemble du cycle permet
l’application logicielle durant la phase de des- de réaliser au plus tôt des vérifications et de montrer qu’il n’y a pas de
cente du cycle en « V » défauts qui ont été introduits ;
2. Le point faible est la phase de codage, la mise en œuvre d’une
méthode formelle permet de disposer d’une sémantique et donc de pro-
poser un processus de traduction automatique de la spécification en
code.
N.2 Identifier au plus tôt les défauts introduits au sein La mise en œuvre d’un modèle formel permet de réaliser des vérifica-
de l’application logicielle tions au plus tôt.
N.3 Nécessité de réaliser des vérifications formelles L’interprétation abstraite et la preuve de programme sont maintenant
de type interprétation abstraite sur le code réalisables sur du code C, C++ ou Ada avec un coût temporel raison-
nable.
N.4 Nécessité de remplacer des activités de tests par Il y a deux possibilités :
des activités de preuve formelle – la preuve sur le code ;
– la preuve sur le modèle et l’utilisation d’un processus de génération
de code préservant les vérifications réalisées (générateur de code certi-
fié, double générateur de code, etc.).
N.5 Nécessité de disposer de modèles permettant de Un modèle formel peut être réalisé spécifiquement afin d’être utilisé
faciliter la production des tests (génération de cas pour la production de cas de tests (soit par exploration, soit par généra-
de tests, exploration de modèle, etc.) tion pseudo-automatique).
N.6 Nécessité de réaliser un modèle associé aux C’est l’objectif des méthodes formelles.
exigences
N.7 Nécessité de disposer d’un moyen de faire des La réalisation d’un modèle formel permet de vérifier la cohérence et la
vérifications sur le modèle afin de vérifier la complétude des exigences au travers de techniques telles que la preuve
cohérence et/ou la complétude des exigences ou le model checking.
N.8 Nécessité de pouvoir poursuivre le processus de Les méthodes formelles telles que SCADE ou la méthode B permettent
la phase de spécification jusqu’à la phase de de réaliser des modèles qui couvrent les différentes phases de la phase
conception voir la phase de codage descendante du cycle en « V ».
N.9 Nécessité de définir un sous-ensemble du lan- La mise en œuvre d’une méthode formelle permet de disposer d’une
gage (limitant les difficultés) et de disposer d’un sémantique et donc de proposer un processus de traduction automa-
ensemble de règle de conception et de codage tique de la spécification en code permettant de faciliter la gestion du
sous-ensemble et des règles de conception.
N.10 Nécessité de disposer d’un retour d’expérience C’est un problème récurrent avec les nouveaux standards.
suffisant pour démontrer que les outils et plus La génération de code permet de régler une partie du problème mais il
particulièrement le compilateur est utilisable pour faut être capable de qualifier les outils.
le niveau de sécurité attendue
N.11 Nécessité de disposer d’outil d’analyse du code L’offre actuelle contient de nombreuses alternatives comme Astrée,
au lieu de réaliser les analyses manuelles CodePeer, Frama-C, Polyspace, etc.
Avant 1998, la RATP avait fait réaliser une analyse par interprétation abstraite du code de l’application SAET-METEOR, et il fallait environ une semaine de
traitement pour réaliser un « run ». Actuellement, il est possible de réaliser un « run » (sur un code de taille réelle) en quelques heures.
Dans le cadre de la figure 33, la spécification est indiquée sera nécessaire de justifier que l’activité de preuve est aussi effi-
comme étant non formelle mais il est possible d’avoir un premier cace que les activités de tests de composants et les tests d’intégra-
modèle (formel ou au moins structuré), qui a pour objectif de tion logiciel/logiciel.
structurer les exigences et d’aider à identifier les incohérences et L’efficacité des tests de composants est associé à la possibilité
les incomplétudes. Ce modèle peut ensuite, lors de la phase de de mesurer la couverture des tests, ce qui permet d’identifier des
conception, être associé à un modèle de conception formel. manques dans la construction du cahier de tests et/ou du code non
spécifié. Pour la preuve, il faudrait donc mesurer la couverture des
Si les outils mis en œuvre (simulateur, prouveur, générateur de
preuves par rapport au modèle. C’est une question difficile qui n’a
code, etc.) sont démontrés comme respectant des objectifs liés au
pas de réponse à l’heure actuelle. Cette problématique est essen-
niveau de sécurité à atteindre par l’application, ce type d’approche
tielle car un sous-ensemble de propriétés qui ne couvrirait pas le
permet de remplacer des activités de vérification et validation par
code pourrait ne pas révéler des problèmes pouvant avoir un
d’autres activités (à titre d’exemple les tests unitaires peuvent être
impact sur la sécurité. Parmi ces problèmes, les codes non spéci-
remplacés par une activité de preuve et une qualification/certifica-
fiés et les codes morts sont deux risques inacceptables.
tion du générateur de code, voir par exemple [2]).
L’efficacité des tests d’intégration logiciel/logiciel est basée sur
La figure 35 présente un processus où la preuve remplace les le fait que toutes les interfaces sont soumises à des tests, il faut
tests de composants (ou unitaire ou modulaire) et les tests d’inté- donc démontrer que les propriétés couvrent bien toutes les inter-
gration logiciel/logiciel. Il faut rappeler que la norme CENELEC faces, cela peut être fait par analyse et traçabilité comme pour le
EN 50128 permet de remplacer une activité par une autre mais il code.
E1 … S1
Tests d’ensemble du logiciel
Req_11: …
E2 S2
Req_12: …
E3
Req_13: …
l1 l2 l3
Le preuve remplace :
– TC/TM/TU
– S/S Tl
int xx;
main ()
{
…
} Plusieurs applications :
– méthode B
– SCADE
Figure 35 – Processus formel débutant au niveau conception

La figure 36 présente un processus ou la simulation au niveau niveau du modèle. Si le générateur de code est certifié, on pourra
du modèle remplace les tests de composants (ou unitaire ou s’arrêter là... mais si le générateur de code n’est pas certifié, il
modulaire) et les tests d’intégration logiciel/logiciel. Il faut dans ce pourra être nécessaire de rejouer tous les tests (composants et/ou
cas là, démontrer que le code simulé est le même que le code exé- intégration) sur le code généré et de mesurer la couverture sur le
cuté sur la cible et il est nécessaire de mesurer la couverture au code.
E1 … S1
Req_11: …
E2 S2
Req_12: … Tests d’ensemble sur cible
E3
Req_13: …
l1 l2 l3
La simulation remplace :
– les tests de composant
– les tests d’intégration S/S
int xx;
main ()
{
…
}
Plusieurs application avec :

– SCADE
– Control-build
Figure 36 – Remplacement des tests par des simulations
Une des difficultés réside dans le fait que la couverture du

modèle ne sera pas celle du code. En règle générale, la couverture
sur le modèle est une mesure de la couverture des conditions et, Spécification Tests
lors de la génération de code, les conditions sont dépliées. informelle de validation
5.2 Vers une approche centrée modèle

Modèle
L’introduction des techniques et des méthodes formelles au sein de spécification
de la réalisation des applications logicielles fait apparaître de nou-
veaux processus qui ne sont plus en phase avec le cycle en « V »
recommandés par les normes. Le cycle de réalisation des
méthodes formelles déplace les activités de vérification vers la Modèle
phase descendante et concentre l’ensemble des informations dans de conception
le modèle (figure 33).
La concentration des informations dans le modèle, nous fait dire
qu’il ne s’agit pas d’une approche « orientée modèle » mais d’une
Traduction
approche « centrée modèle », ce qui n’est absolument pas la
même chose. En effet, dans le cadre d’une approche « centrée
modèle », le modèle devient le support de toutes les activités,
Figure 37 – Processus prenant en compte les modèles
voire il devient le contenant des activités (dans la figure 37, les
traits pointillés correspondent à des activités de vérification).
Les normes de maîtrise de la qualité (ISO 9001:2008 par
exemple) recommandent d’identifier les processus, les activités et 6. Logiciel paramétrable
les documents à produire. Les normes métier comme la norme
CENELEC EN 50128:2011 identifie une liste minimale de docu- Les données statiques peuvent être de deux types :
ments à produire. – des données fixes dites invariantes qui caractérisent l’environ-
Dans le cadre d’une approche centrée modèle, les TU et les TI nement (topologie, trajectoire, etc.), le système (nombre d’objet,
peuvent être remplacés par des simulations et/ou une combinaison limite, etc.) et des caractéristiques (poids, longueur, vitesse, etc.) ;
d’obligations de preuve et de preuves. Mais ces éléments de vérifi- – des données évoluant avec l’état du système.
cation sont alors parties intégrantes du modèle tout comme les Définition 9 (application spécifique) – Une application spéci-
éléments du type : calcul des métriques, vérification de la cohé- fique est une application générique à qui un paramétrage a été
rence du modèle, vérification du respect des règles de codage, etc. associé. Cette application spécifique n’est utilisable que pour une
Ce type d’approche « centrée modèle » est intéressante mais elle seule installation.
fait disparaître de nombreux éléments documentaires qui sont À noter que la notion d’application spécifique (figure 38)
alors dit « non nécessaires » car productibles à la demande. Et couvre les aspects logiciel et matériel.
nous avons là, une potentielle « non-conformité » aux standards
orientés « objectif » tels que la IEC 61508:2008, l’ISO 26262:2011, la
CENELEC EN 50128, etc.
L’approche « centrée modèle » a pour point fort d’aider à la
convergence des métiers comme nous l’avons montré Paramètres
dans [4] [51]. En effet, les différentes équipes (logiciel et matériel,
conception, vérification et validation et sécurité) peuvent mettre en
commun des informations concernant leurs activités, ce qui per-
met de mieux appréhender les difficultés.
En général, l’équipe en charge de la sécurité, qui utilise ces
propres modèles fonctionnels et ces méthodes, peut avoir une Logiciel générique
vision quelque peu différente de l’équipe de conception et les
divergences peuvent avoir un impact fort sur les coûts et les
délais. L’utilisation d’un modèle commun permet de mettre à dis-
position au plus tôt les recommandations et les exigences liées à
la sécurité et il est possible de lier ces éléments à des morceaux de
Plateforme :
modèle.
hardware
L’approche « centrée modèle » fera (nous utilisons le futur car il + OS
n’y a pas d’application centrée modèle qui soit en service depuis + firmware
assez longtemps pour poser des problèmes, mais cela ne peut + middleware
qu’arriver) apparaître trois difficultés :
– l’absence de documents ne permettra pas de redévelopper la
même application logicielle en cas d’obsolescence des outils ;
– les outils deviennent le point central du processus, il est alors
nécessaire de montrer que les outils sont utilisables (notion de
qualification) pour le niveau de sécurité applicable à l’application Application générique
logicielle à réaliser. La qualification des outils devra être mise en
œuvre autant pour les générateurs de code que pour les outils de
vérification ;
– la complexité des techniques mises en œuvre (voir par Application spécifique
exemple les outils d’interprétation abstraite ou les techniques de
preuve [5]) impose un haut niveau de compétence pour les per-
sonnes en charge des activités. Figure 38 – Application spécifique versus application générique
Définition 10 (application générique) – Une application Une application spécifique (voir définition 9) est donc dédiée à
générique est composée d’une plateforme d’exécution (appelée une utilisation. Cette application utilise des données qui peuvent
produit générique) et d’une application logicielle. Cette application être de différentes natures :
logicielle est définie en fonction d’un jeu de données de paramé- – les données d’activation/inhibition de services ;
trage qui devra être instancifié en fonction de l’utilisation finale – les données fixes n’évoluant pas dans le temps, elles décrivent
(dépendant du site, dépendant des services à activer, dépendant les caractéristiques du système (topologie, courbe de vitesse, point
des caractéristiques techniques, etc.). d’arrêts, etc.) ;
– les données évoluant dans le temps, le temps d’évolution étant
L’application générique [TRP 3 305] est alors la composition
le cycle ou une durée plus importante.
d’un logiciel générique et d’une plateforme d’exécution. La plate-
forme d’exécution est appelée produit générique et couvre les Les données évoluant régulièrement (dans le domaine ferro-
aspects matériels et les aspects logiciels (système d’exploitation, viaire, ces données sont nommées « variants ») peuvent être :
logiciel de base, couche middleware pour la gestion des communi- – des entrées que le système acquière régulièrement ;
cations, etc.). – des données que le système calcule comme les variables glo-
bales ou locales et les sorties du système.
Définition 11 (produit générique) – Un produit générique est
composé d’un ensemble d’éléments matériels et d’un ensemble de Définition 12 (données de paramétrage) – Une donnée de
logiciels et a pour objectif de permettre l’exécution d’une applica- paramétrage est une donnée n’évoluant pas durant l’exécution de
tion logicielle. Un produit générique peut être utilisé pour la réali- l’application logicielle.
sation de différents systèmes. Comme l’indique la définition 12, les données de paramétrage
(dans le ferroviaire on parle d’invariants) sont un premier type de
Comme l’indique la définition 11, un produit générique a pour données. Les données de paramétrages regroupent en générale
objectif d’exécuter différents types d’application logicielle, le coté deux familles : les données définissant les caractéristiques tech-
générique permet de ne pas la spécialiser, la notion de produit est niques (vitesse, poids, taille, nombre, etc.) et les données définis-
liée au fait que cet ensemble peut être certifié indépendamment du sant le cadre d’utilisation (la topologie, les courbes de vitesse, les
domaine d’utilisation, c’est par exemple le cas des automates pro- points d’arrêts, etc.).
grammables.
Comme le montre les deux premières lignes du tableau 11, les
Les données invariantes sont connues à la génération du sys- données peuvent être définies sous deux formes :
tème et définissent une configuration du système. Il est ainsi pos- – une forme tabulaire (figure 40a) : il s’agit de tableaux conte-
sible de définir un système de façon générique et de l’implanter au nant des données. Les tableaux peuvent être spécialisés afin
travers d’un paramétrage sur un autre site. d’accélérer les traitements (à partir d’une aiguille, on peut directe-
ment avoir accès aux signaux associés) ;
À titre d’exemple, de la description d’une ligne de métro, il est
– un algorithme (figure 40b) : les données sont décrites sous
possible de déduire un ensemble de données qui seront com-
forme d’algorithme et on peut construire une topologie de la ligne
munes à l’ensemble des équipements du système. Ces données
en connectant les données. Cette forme permet de définir un
dépendent de la topologie de la ligne, des caractéristiques des
« langage spécifique » qui tient compte du domaine.
trains et de choix technologiques (temps de réponse, temps de
calcul du processeur, etc.). Dans le monde du ferroviaire, elles sont La norme CENELEC EN 50128:2011 propose le processus de la
appelées invariants topologiques [4] [52]. figure 41 pour la préparation des données. Ce processus introduit
les phases classiques : planification, spécification et architecture,
Une ligne de métro (voir l’exemple fictif introduit à la figure 39) codage et vérification.
est composée de voies de circulation des trains. Ces voies sont
constituées de circuits de voie (noté CdV). Chaque circuit de voie La figure 42 montre que la préparation des données doit gérer
est une portion de voie qui permet de détecter la présence de deux types d’activités : la production des données de paramétrage
trains sur cette zone. Les circuits de voie sont en général connectés et l’intégration des données avec le logiciel générique. C’est pour-
à deux autres circuits de voie, mais dans le cas où ils sont connec- quoi le PPA (plan de préparation de l’application [TRP 3 306]) est à
tés à trois autres circuits de voie, ils doivent être associés à une réaliser soit pour chaque application spécifique, soit pour une
aiguille qui est un équipement permettant de choisir le chemin. classe d’applications spécifiques. S’il est produit pour une classe
d’applications spécifiques, on validera finalement une famille de
configurations.
La norme CENELEC EN 50128:2011 identifie un certain nombre
de techniques à mettre en œuvre pour la préparation des données
5 au travers de la table A.11 (tableau 11). La table A.11 de la norme
4 fait apparaître deux types de techniques :
3 – les langages (1 et 2) ;
– les moyens de vérification (de 3 à 9).
2 Le premier cas de la figure 43 consiste à ne développer qu’un
seul outil pour produire les données.
d1 1
Le deuxième cas consiste à disposer de deux outils, deux outils
diversifiés – mais disposant de la même spécification – réalisent la
même transformation et un comparateur permet de vérifier que le
résultat est identique (ou similaire si comparaison partielle). Le
6 dernier cas consiste à réaliser un outil qui fait la transformation et
un outil qui inverse la transformation et on complète avec un com-
parateur qui vérifie que le résultat est similaire (en général, les
transformations ne préservent pas toute l’information d’où une
incapacité à vérifier l’égalité).
f1 Le troisième cas de la figure 43 permet de garantir une diversité
plus forte (deux spécifications différentes) entre les deux outils que
Figure 39 – Exemple de topologie le deuxième cas (même spécification).
Tableau 11 – Table A.11 de la norme CENELEC EN 50128:2011

SSIL1 SSIL3
Mesure SSIL0
SSIL2 SSIL4
1. Méthodes de spécification en tableaux R R R
2. Langage spécifique à l’application R R R
3. Simulation R HR HR
4. Tests fonctionnels M M M
5. Listes de contrôles R HR M
6. Inspection de Fagan – R R
7. Examens formels de la conception R HR HR
8. Preuve formelle du caractère correcte des données – – HR
9. Revue de projet structurée R R HR
KagD KagG
KagD et not KagG
left
Not
not KagD et not KagG
controlled
right
Name 1 2 …
Position 10 20 … KagG et not KagD
Position
a cas1 b cas 2
Figure 40 – Deux types de représentation des données
8.4.2 – Spécification des exigences
8.4.3 – Architecture/conception
8.4.6 – Validation et évaluation
8.4.1 – Planification
8.4.4 – Production des données
8.4.5 – Intégration de l'application et tests
8.4.7 – Procédure et outils de préparation

de l'application
8.4.8 – Développement du logiciel

générique : § 7
Figure 41 – Cycle de la préparation de données
combiner avec la possibilité de vérifier manuellement les données

Données de paramétrage d’où le tableau 12.
§ 8 – Préparation des données
La ligne 8 du tableau 11, extrait de la norme CENELEC
Intégration données/logiciel EN 50128:2011, fait apparaître la possibilité de mettre en œuvre la
preuve sur les données, ce point est en accord avec la dernière
ligne du tableau 12. La preuve sur les données a été initialement
mis en œuvre dans le cadre de l’application logicielle de la ligne
§ 7 – Développement logiciel 14 [60] et le concept a ensuite été repris sur d’autres systèmes fer-
Logiciel générique
générique
roviaires (ligne 13, etc., voir [61]). Le processus associé est décrit
au sein de la figure 45.
Figure 42 – Lien entre les deux processus de réalisation La figure 45 fait apparaître deux familles d’outils, les outils
dédiés à la preuve de données comme les outils OVIP et OVADO et
La figure 43 présente les différentes possibilités pour réaliser un les outils généraux comme l’atelier B, Rodin, ProB qui peuvent être
processus de production de données qui prend en compte la véri- utilisés autant pour réaliser une application logicielle que pour la
fication, mais le coût (réalisation et maintenance) de la redondance validation des données.
et de la diversité étant assez important, une autre direction a été
exploré. La figure 44 présente un processus de vérification basé
sur la preuve des données. Nota : l’OVIP a été développé dans le cadre de la ligne 14 du métro parisien afin de
valider les données. Une partie de la validation des données est réalisée au travers de la
On dispose donc d’au moins quatre approches possibles (les preuve de propriété [60]. OVADO (Outil de validation automatique des données) est un
trois de la figure 43 et la preuve des données) mais il faut les environnement de validation des données par la preuve développé par la RATP [61].
1) 2) 3)
Données système Données système Données système

Comparaison
Outil Outil 1 Outil 2

Outil 1
Outil 2
Comparaison
Données
de paramétrage
Données
de paramétrage Données de paramétrage
Figure 43 – Transformation des données
Propriétés
Données
système
Outil
OK/KO
de preuve
Data Tool
Données utilisées
par le logiciel
Figure 44 – Transformation des données
Tableau 12 – Combinaisons pour réaliser un processus de production des données

Vérification des don-
Production Caractéristiques Commentaire
nées
Le nombre de donnée est gérable et permet de se
Manuelle Manuelle (relecture, etc.) Peu de données
passer d’outillage.
Il est possible de montrer que les données sont
correctes au travers de tests d’ensemble du
Manuelle Tests Peu de données logiciel.
Cette approche n’est pas praticable en cas de
grand nombre de données.
Le faible nombre de donnée permet de réaliser
Outillée – cas 1 Manuelle (relecture, etc.) Peu de données
une vérification manuelle.
Un outil unique développé au niveau de SSIL des
Outillée – cas 1 Données SSIL2 ou SSIL3-4
données.
On a une double chaîne ce qui permet d’utiliser
Outillée – cas 2 Données SSIL2 ou SSIL3-4 des outils d’un SSIL inférieur (fonction de la
diversification) au SSIL attendu pour les données.
On a une double chaîne fortement diversifié ce
Outillée – cas 3 Données SSIL2 ou SSIL3-4 qui permet d’utiliser des outils d’un SSIL inférieur
au SSIL attendu pour les données.
La sécurité des données peut reposer sur la mise
– Outillée Données SSIL2 ou SSIL3-4 en place d’un outil de vérification des données
(par exemple par la preuve).
Processus de production
DATA des données
– Id
Application – Famille
générique – Format
– Unité
–… génération
extraction
DATA
– Id
– Famille
– Format
Propriétés Vérification – Unité
par preuve –…
Outils commerciaux : Atelier B, Provers certifier

Outils en open source : rodin, ProB,
Outils spécifiques : OVIP, OVADO
Figure 45 – Preuve sur les données
7. Qualification La version 2011 de la norme CENELEC EN 50128 introduit for-

mellement le besoin de qualifier les outils (voir § 6.7 de la norme).
Comme pour l’IEC 61508 et l’ISO 26262, trois classes d’outils, T1,
T2 , T3, ont été introduite :
7.1 Besoins – la classe T1 est dédiée aux outils qui n’ont pas d’impact sur la
Dans sa version 2001, la norme CENELEC EN 50128 introduisait vérification et qui n’ont pas d’impact sur l’exécutable final ;
une demande de qualification des compilateurs, sans vraiment – la classe T2 est dédiée aux outils ou un défaut pourrait fausser
indiquer ce qui était attendu. les résultats de vérification ou de validation. La classe T2 contient
les outils de vérification de règles de codage, de mesure des

métriques, d’analyse statique de code, de gestion et d’exécution 8. Conclusion
des tests, etc. ;
– la classe T3 est dédiée aux outils dont une défaillance pourrait Dans le cadre des normes des domaines automobile (ISO
avoir un effet sur l’exécutable final. Cette classe concerne les com- 26262), ferroviaire (CENELEC EN 50128), générique (IEC 61508) les
pilateurs, les générateurs de code, etc. méthodes formelles sont préconisées comme moyen de décrire le
besoin (passage de l’informel au formel) et d’aboutir à une produc-
La section 6.7 de la norme CENELEC 50128:2011 définit pour tion de code maîtrisée. Dans la nouvelle norme DO 178C, un guide
chaque classe un jeu de recommandations qui permet d’identifier spécifique a été mis en place pour décrire la mise en œuvre des
le contenu du dossier de qualification. méthodes formelles avec une orientation qui est de les utiliser au
niveau du code (vérification que le code C respecte des propriétés).
Dans le cadre de l’article [TRP 3 304], nous avons traité précisé-
ment l’analyse de la qualification des outils (processus et docu- En effet, des méthodes formelles comme la méthode B [1],
ment à produire) comme cela est demandé par la norme CENELEC SCADE [9], VDM [15], Z [16]... permettent de formaliser un besoin,
EN 50128. de construire un modèle, de démontrer le respect de propriétés et
de produire un code qui est l’image du modèle. Pour une liste plus
complète des méthodes formelles, on peut se reporter à [26].
7.2 Difficultés Les techniques formelles et les méthodes formelles sont mainte-
nant utilisées avec succès de manière industrielle sur des projets
de différentes tailles. Les outils associés ont atteint une maturité
L’un des points délicats concernant la mise en œuvre des diffé- permettant de prendre en compte la complexité de telles applica-
rents outils réside dans la démonstration que l’outil est utilisable tions. À noter que la complexité des applications industrielles à
pour le niveau de sécurité qui est visé. très souvent un impact sur le temps de traitement (dans le cadre
du SAET-METEOR, il a fallut plus d’une semaine en 1998 pour ana-
Comme le montre la figure 46, pour réaliser la qualification d’un lyser avec l’outil Polyspace les 100 000 lignes de code Ada, alors
outil, il faut mettre en place une activité de qualification qui peut que maintenant cela prendrait une ou deux heures).
être basé :
La prise en compte des techniques et des méthodes formelles a
– sur un certificat : il existe des certificats pour certains outils un impact sur le processus mis en œuvre et il est donc nécessaire
comme les compilateurs et les générateurs de code (par exemple de construire un nouveau processus (méthode, activité, éléments
le générateur de code C à partir du modèle SCADE est certifié en entrée, éléments en sortie, vérification à réaliser) conforme aux
SSIL3-4 pour la norme ferroviaire CENELEC EN 50128) ; normes qualité en vigueur.
– sur un retour d’expérience : il est possible de construire un La construction de ce processus doit prendre en compte le fait
argumentaire justifiant d’un retour d’expérience (liste de projets, que le modèle peut remplacer des documents qui étaient initiale-
exemple d’applications, nombre d’heures d’exploitation, etc.) ; ment à produire (demande des normes), la durée de vie du sys-
– et/ou sur une démonstration que le logiciel peut être utilisé tème (de 30 à 50 années) et les objectifs de maintenance associés
pour un niveau de sécurité donné (la démonstration peut (suite à la mise en service du système, il y a maintenant plusieurs
s’appuyer sur une démonstration de sécurité, sur une campagne versions qui sont produites). En effet, si l’outil utilisé pour la modé-
de validation, etc.) ; lisation n’est plus maintenu et que le formalisme utilisé pour réali-
ser le modèle est propriétaire (ou si le format des fichiers n’est pas
– l’ajout de contrôle d’exécution, etc. connu), il pourra être difficile voire impossible de mettre à jour
l’application en l’absence du modèle (incapacité à ouvrir le modèle
Pour les outils liés aux techniques formelles (prouveur, model et donc d’avoir accès à la documentation).
checker, interprétation abstraite, etc.), les algorithmes mis en
œuvre ne sont pas triviaux et il sera assez difficile de les valider ; Une autre difficulté des approches « centrées modèles » est de
sachant qu’il y a des outils commerciaux sous licence (impossibi- rendre le niveau de sécurité de l’application logicielle du niveau de
lité de connaître les algorithmes mis en œuvre) et des outils sous sécurité des outils utilisés. Autant il est difficile de montrer qu’un
licence non commerciale (en règle général, développé par des uni- compilateur C est SSIL4 autant il sera encore plus difficile de
versitaires) qui ne disposeront pas de dossier de validation au démontrer qu’un prouveur est SSIL4. Dans le cadre des compila-
niveau attendu. teurs, il était possible de mettre en place des stratégies basées sur
la redondance et la diversité autant pour les outils spécifiques tels
que des prouveurs, des outils de model checking et/ou des outils
d’interprétation abstraite, il est difficile d’avoir deux outils d’effica-
cité similaire sur le même domaine (il nous faut rappeler que pour
Retour d’expérience plusieurs des outils utilisés actuellement, les algorithmes ne sont
Bon comportement pas publiques et sont même sous copyright). Il faut alors mettre en
Certificat place des dossiers de qualification des outils.
Preuve de conformité
Validation Concernant les outils, les différentes normes (DO 178C,

ISO 26262:2011, CEI/IEC 61508:2010, CENELEC EN 50128:2011) font
Double exécution apparaître la notion de « dossier de qualification ». Chaque outil
Vérification de l’exécution doit être qualifié pour son utilisation. La qualification d’un outil
Codage de type PSC (pour le domaine ferroviaire, voir [TRP 3 304]) dépend de son
impact sur le produit final (impact sur l’exécutable, impact sur la
Processus
vérification, aucun impact sur la vérification ou l’exécutable). La
Revue principale difficulté concernant la qualification des outils est liée
Autre aux standards. Les normes de chaque domaines introduisent la
… notion de qualification mais les recommandations sont différentes
et parfois incomplètes. La norme DO178C est le domaine le plus
abouti sur ce sujet, elle introduit en particulier le guide DO 330 [59]
Figure 46 – Preuve de conformité d’un outil qui est dédié à la qualification des outils.
Concernant les techniques formelles et les méthodes formelles, Application générique

la question de la qualification des outils est donc primordiale, car
Une application générique est composée d’une plateforme
la complexité des technologies mises en œuvres (prouveur, model
d’exécution (appelée produit générique) et d’une application logi-
checking, etc.), l’aspect confidentialité (algorithme sous licence,
cielle. Cette application logicielle est définie en fonction d’un jeu
etc.), l’aspect innovation (nouvelle technologie, peu d’utilisateurs,
de données de paramétrage qui devra être instancié en fonction de
etc.) et l’aspect maturité (produit issu de la recherche, produit réa-
l’utilisation finale (dépendant du site, dépendant des services à
lisé sous licence « libre », etc.) ne permettent pas d’établir facile-
activer, dépendant des caractéristiques techniques, etc.).
ment une relation de confiance dans cet outil.
Concernant les perspectives, les normes introduisent la notion Produit générique
de méthodes formelles mais il est nécessaire de mieux définir au Un produit générique est composé d’un ensemble d’éléments
sein des normes ce que sont les techniques formelles (à titre matériels et d’un ensemble de logiciels et a pour objectif de per-
d’exemple, il faut introduire la notion d’interprétation abstraite). Il mettre l’exécution d’une application logicielle. Un produit géné-
est aussi nécessaire d’autoriser que la vérification du comporte- rique peut être utilisé pour la réalisation de différents systèmes.
ment d’une application logicielle ne soit pas uniquement réalisée
au travers d’activité de vérification basée sur les tests (tests des
composants, test d’intégration et test d’ensemble) mais qu’elle
puisse être une combinaison de techniques formelles et de tech- Liste des termes et acronymes
niques de tests. Actuellement, les normes ouvrent la porte à l’utili-
sation des méthodes formelles sans donner d’orientation, seule le AFIS Association française d’ingénierie système
référentiel aéronautique propose au travers du supplément
DO 333:2011 [53] des recommandations pour la mise en œuvre des ASA Automata and Structured Analysis
méthodes formelles.
CARE Common Airbus Requirements Engineering
CBTC Communications-Based Train Control
9. Glossaire CdCF Cahier des charges fonctionnel
Application logicielle CENELEC Comité européen de normalisation electrotech-

nique
Ensemble des programmes, des procédés et des règles et éven-
tuellement de la documentation, relatifs au fonctionnement d’un E/E/EP Électrique/Électronique/Électronique program-

ensemble de traitement de l’information. mable
Analyse d’impact FDM Fiabilité, disponibilité et maintenabilité
L’analyse d’impact d’une anomalie consiste à identifier les modi- FDMS Fiabilité, disponibilité maintenabilité et sécurité
fications à réaliser sur la phase descendante (impact sur les docu-
ments, impact sur le code, impact sur la description et GAME Globalement au moins équivalent
l’implémentation des tests) de la réalisation.
HR Hautement recommandé
Analyse de non-régression
IDM Ingénierie des modèles
L’analyse de non-régression consiste à déterminer un ensemble
de vérifications permettant de démontrer que la modification réali- IEC International Electrotechnical Commission
sée n’a pas d’effet sur le reste de l’application logicielle.
ISO International Organisation for Standardization
Vérification
Confirmation par des preuves tangibles que les exigences spéci- IEC International Electrotechnical Commission
fiées ont été satisfaites à chaque étape du processus de dévelop- ITU International Telecommunication Union
pement.
M Mandatory
Validation
Confirmation par des preuves tangibles que les exigences défi- MISRA Motor Industry Software Reliability Association
nissant une utilisation spécifique ou une application prévues ont
été satisfaites. MAQ Manual d’assurance qualité
Propriété MBD Model Based Development

Une propriété est une caractéristique qu’un composant (matériel METEOR Metro Est Ouest rapide
ou logiciel) doit vérifier.
OMG Object Management Group
Propriété de sûreté
OVADO Outil de validation automatique des données
Une propriété de sûreté (au sens du terme anglais safety)
exprime que quelque chose de mauvais ne se produit jamais au OVIP Outil de validation des invariants
cours de l’exécution.
PAING Poste d’aiguillage informatisé – nouvelle généra-
Propriété de vivacité tion
Une propriété de vivacité (liveness) exprime que quelque chose
de bon se produit immanquablement au cours de l’exécution. PAQL Plan d’assurance qualité logiciel
Application spécifique PVV Plan de vérification et de validation

Une application spécifique est une application générique à qui PVéL Plan de vérification du logiciel
un paramétrage a été associé. Cette application spécifique n’est
utilisable que pour une seule installation. R Recommandé
Liste des termes et acronymes (suite) Liste des termes et acronymes (suite)
RATP Régie autonome des transports parisiens TC Test de composant
RVQ Rapport de vérification de la qualité TE Test d’ensemble du logiciel
RVL Rapport de validation du logiciel TF Test fonctionnel
SACEM Système d’aide à la conduite, à l’exploitation et à TI Test d’intégration

la maintenance
TM Test modulaire
SADT Structured Analysis and Design Technic
TU Test unitaire
SAET Système d’automatisation de l’exploitation des
TV Test de validation
trains
UCM Use Case Maps
SAO Spécification assistée par ordinateur
UML Unified Modeling Language
SCADE Safety Critical Application Development Environ-
ment USR User Requirement Notation
SIL Safety Integrity Level – valeur de 1 à 4 VAL Véhicule automatique léger
S/S Software/Software SysML System Modeling Language
S/H Software/ Hardware V&V Vérification et validation
SSIL Software SIL – valeur de 0 à 4 XMI XML Metadata Interchange
TCMS Train Control/Management System XML eXtensible Markup Language

P
O
U
Méthodes formelles : application R
au domaine ferroviaire
E
Évaluateur-Certificateur
Certifer (Anzin, France)
N
S
Sources bibliographiques
A
[1] ABRIAL Jr., The B Book. – Assigning pro-
grams to meanings. Cambridge University
Press, Cambridge, août 1996. [20]
Paris, France, vol. 19, n° 1-2-3, p. 155-164,
janv. 2000.
SOMMERVILLE (I.). – Software engineering 8 [34]
tional Conference on Software and Data
Technologies, Barcelona Spain (2007).
MOTET (G.). – Vérification de cohérence des
V
[2] BOULANGER (J.-L.) et SCHÖN (W.). – Logi-
ciel sûr et fiable : retours d’expérience. Re-
vue Génie Logiciel, n° 79, p. 37 à 40, déc.
[21]
(2007).
COUSOT (P.) et COUSOT (R.). – Abstract
interpretation : a unified lattice model for sta-
modèles UML 2.0. Première journée théma-
tique Modélisation de Systèmes avec UML,
SysML et B-Système, Association française
O
[3]
2006.
BOULANGER (J.-L.) et SCHÖN (W.). – As-
sessment of safety railway application. ES-
tic analysis of programs by construction or
approximation of fixpoints. Conf. Rec. Of the
4th Annual ACM SIGPLAN-SIGACT Symp. on [35]
d’ingénierie système, Toulouse, France
(2005).
OOTIA. – Handbook for object-oriented tech-
I
[4]
REL (2007).
BOULANGER (J.-L.). – Expression et valida-
tion des propriétés de sécurité logique et
Principles of Programming Languages
(POPL’77), Los Angeles, États-Unis, ACM
Press, New York, p. 238-252 (1977). [36]
nology in aviation (OOTiA). Handbook Over-
view, Revision 0, vol. 1, 26 oct. 2004.
OOTIA. – Handbook for object-oriented tech-
R
physique pour les systèmes informatiques [22] HALBWACHS (N.), CASPI (P.), RAYMOND nology in aviation (OOTiA). Considerations
critiques. Thèse, Université de Technologie (P.) et PILAUD (D.). – The synchronous data- and Issues, Revision 0, vol. 2, 26 oct. 2004.
de Compiègne (2006). flow programming language Lustre. Procee- [37] OOTIA. – Handbook for object-oriented tech-
[5] Sous la direction de BOULANGER (J.-L.). –
Utilisations industrielles des techniques for-
melles – Interprétation abstraite. Collection [23]
dings of the IEEE, n° 9, vol. 79, p. 1305-1320,
sept. 1991.
BEHM (P.), BENOIT (P.), FAIVRE (A.) et
nology in aviation (OOTiA). Best Practices,
Revision 0, vol. 3, 26 oct. 2004. P
[38] OOTIA. – Handbook for object-oriented tech-
[6]
IC2, Hermès (2011).
BOULANGER (J.-L.). – Le domaine ferro-
viaire, les produits et la certification. Journée
MEYNADIER (J.-M.). – METEOR : a success-
ful application of B in a large project. Procee-
dings of FM’99 : World Congress on Formal
nology in aviation (OOTiA). Certification
Practives, Revision 0, vol. 4, 26 oct. 2004.
L
[39] BOULANGER (J.-L.) et BON (P.). – BRAIL :
[7]
« ligne produit », École des mines de Nantes,
15 oct. 2009.
Observatoire français des techniques avan-
[24]
Methods, p. 369-387.
DESFORGES (P.), BUSTANY (F.) et
BEHM (P.). – Utilisation de la méthode B pour
d’UML à la méthode B pour modéliser un
passage à niveau. Revue RTS, n° 95,
U
p. 147-172, avr.-juin 2007.
cées (OFTA). – Applications des méthodes
formelles au logiciel. Arago, Masson, vol. 20,
juin 1997.
la réalisation des logiciels de sécurité du
SAET de METEOR. Revue des chemins de
fer, n° 6, juin 1996.
[40] RAMACHANDRAN (M.). et ATEM de
CARVALHO (R.). – Handbook of software en-
S
gineering research and productivity
[8] BAIER (C.), et KATOEN (J.-P.). – Principles of [25] BEHM (P.). – Application d’une méthode for-
technologies : implications of globalisation.
model checking. The MIT Press (2008). melle aux logiciels sécuritaires ferroviaires.
Information Science Reference, août 2009.
[9] DORMOY (F.-X.). – Scade 6 a model based In Atelier Logiciel Temps Réel, 6e Journées
solution for safety critical software develop- Internationales du Génie Logiciel (1993). [41] BOULANGER (J.-L.) et BERKANI (K.). – UML
ment. In Embedded Real-Time Systems [26] MONIN (J.-F.). – Introduction aux méthodes et la certification d’application. ICSSEA 2005,
Conference (2008). formelles. Hermès, préface de HUET (G.), Paris CNAM, 1-2 déc. 2005.
[10] HOARE (C.A.R). – An axiomatic basis for 2-7462-0140-2 (2000). [42] BOULANGER (J.-L.). – RT3-TUCS : How to
computer programming. Communications of [27] MONIN (J.-F.). – Understanding formal me- build a certifiable and safety critical railway
the ACM, vol. 12(10), p. 576-580 (1969). thods. Springer Verlag, Foreword by application. 17th international Conference on
[11] DIJKSTRA (E.W.). – Guarded commands, HUET (G.), Translation editor HINCHEY (M.), Softwaree Engineering and Data Enginee-
nondeterminacy and formal derivation of ISBN 1-85233-247-6 (2002). ring, SEDE-2008, Los Angeles, États-Unis,
2 - 2016
programs. Communications of the ACM, [28] HULL (E.), JACKSON (K.) et DICK (J.). – Re- p. 182-187, 30 juin-2 juill. 2008,.
vol. 18, n° 8, p. 453-457, août 1975. quirements engineering. Springer, Berlin [43] IDANI (A.), BOULANGER (J.-L.) et
[12] DIJKSTRA (E.W.). – A discipline of program- (2005). PHILIPPE (L.). – Linking paradigms in safety
ming. Prentice Hall (1976). [29] BOULANGER (J.-L.) et BADREAU (S.). – Ingé- critical systems. Revue ICSA, sept. 2009.
[13] LISSANDRE (M.). – Maîtriser SADT. Édition nierie des exigences – Méthodes et bonnes [44] IDANI (A.), BOULANGER (J.-L.) et
Armand Collin (1990). pratiques pour construire et maintenir un ré- PHILIPPE (L.). – A generic process and its tool
[14] Sous la direction de BOULANGER (J.-L.). – férentiel. Dunod, Paris (2014). support towards combining UML and B for
Doc. TRP 3 309
Mise en œuvre de la méthode B. Collection [30] Sous la direction de BOULANGER (J.-L). – safety critical systems. CAINE 2007, San
IC2, Hermès (2014). Techniques industrielles de modélisation for- Francisco, 7-9 nov. 2007.
[15] JONES (C.B.). – Systematic software deve- melle pour le transport. Collection IC2, Her- [45] IDANI (A.), OKASA OSSAMI (D.-D.) et
lopment using VDM. Prentice Hall Internatio- mès-Lavoisier (2011). BOULANGER (J.-L.). – Commandments of
nal, Second Edition (1990). [31] OMG. – Unified modeling language TM UML for safety. In 2nd International Confe-
[16] SPIVEY (J.M.). – The Z notation – A reference (OMG UML). Infrastructure, OMG (2011). rence on Software Engineering Advances
Manual. Prentice Hall International (1989). [32] BOULANGER (J.-L.). – UML et les applica- IEEE CS, Press, août 2007.
[17] BARNES (J.). – Programming in Ada 2012. tions critiques. Proceedings of Qualita’ 07, [46] RASSE (A.), BOULANGER (J.-L.),
Cambridge university press (2014). Tanger, Maroc, p. 739-745 (2007). MARIANO (G.), THIRY (L.) et PERRONNE
[18] KERNIGHAN (B.W.) et RITCHIE (D.M.). – The [33] OKALAS OSSAMI (D.D.), MOTA (J.-M.), (J.-M.). – Approche orientée modèles pour
C programming language. 2nd edition, Pren- THIRY (L.), PERRONNE (J.-M.) et une conception UML certifiée des systèmes
tice Hall, Englewood Cliffs (1988). BOULANGER (J.-L.). – A method to model logiciels critiques. CIFA, Conférence Interna-
[19] COUSOT (P.). – Interprétation abstraite. guidelines for developing railway safety-cri- tionale Francophone d’Automatique, Buca-
Technique et Science Informatique, Hermès, tical systems with UML. ICSOFT’07, Interna- rest, Roumaine, nov. 2008.
Copyright © – Techniques de l’Ingénieur – Tous droits réservés Doc. TRP 3 309 – 1
P MÉTHODES FORMELLES : APPLICATION AU DOMAINE FERROVIAIRE __________________________________________________________________________

O
U [47] Ada Resource Association. – Operating de maîtrise des risques et sûreté de fonction- [77] ROQUES (P.). – UML 2 – Modéliser une ap-
R procedures for Ada conformity assessments.

Version 3.0, avr. 2001
http://www.ada-auth.org/procs/3.0/ACAP30.p
[62]
nement, Dijon, 21-23 oct. 2014.
BOULANGER (J.-L.). – Le domaine ferro-
viaire, les produits et la certification. Journée
plication Web. Eyrolles, Paris (2007).
[78] SCHNEIDER (S.). – The B-method : an intro-
duction. PALGRAVE (2001).
df « ligne produit », École des mines de Nantes, [79] WORDSWORTH (J.). – Software engineering
[48] BARNES (J.). – High integrity software : the 15 oct. 2009. with B. Addison-Wesley (1996).
SPARK approach to safety and security. Ad- [63] BOULANGER (J.-L.) et GALLARDO (M.). – [80] BAUFRETON (P.), BLANQUART (J.-P.),
E dison-Wesley (2003).
[49] LEROY (X.). – Formal verification of a realistic
Processus de validation basée sur la notion
de propriété. LamnbdaMu, 12, p. 28-30, mars
BOULANGER (J.-L.), DELSENY (H.),
DERRIEN (J.-C.), GASSINO (J.), LADIER (G.),
compiler. Communication of ACM, vol. 52, 2000. LEDINOT (E.), LEEMAN (M.), QUERE (P.) et
N n° 7, p. 107-115, juill. 2009.
[50] LOCKHEED (M.). – Joint strike fighter air
[64] BOULANGER (J.-L.) et BON (P.). – B-rail : ana-
lyse et modélisation des exigences. Revue
RICQUE (B.). – Comparaison de normes de
sécurité-innocuité de plusieurs domaines in-
vehicle C++ coding standards for the system Génie Logiciel, n° 79, p. 18 à 24, déc. 2006. dustriels. Revue REE, n° 2 (2011).
development and demonstration program. [65] Sous la direction de BOULANGER (J.-L.). – [81] BOULANGER (J.-L.) et SCÖHN (W.). – As-
Document n° 2RDU00001, Revision C, déc. Sécurisation des architectures informatiques sessment of safety railway application. ES-
2005. – Exemples concrets. Hermès-Lavoisier REL (2007).
S [51] BOULANGER (J.-L.), DELEBARRE (V.) et
NATKIN (S.). – METEOR : validation de spé- [66]
(2009).
Sous la direction de BOULANGER (J.-L.). –
[82] SABATIER (D.) et al. – Utilisation de la mé-
thode formelle B pour un système SIL3 : la
cification par modèle formel. Revue RTS, Sécurisation des architectures informatiques commande des portes palières sur la ligne 13
A n° 63, p. 47-62, avr.-juin 1999.
[52] GEORGES (J.-P.). – Principes et fonctionne- [67]
industrielles. Hermès-Lavoisier (2011).
Sous la direction de BOULANGER (J.-L.). –
du métro parisien. LambdaMu’15, Lille, 28
nov. 2008.
ment du système d’aide à la conduite, à l’ex- Outils de mise en œuvre industrielle des [83] LEUSCHEL (M.). – Validation of railway pro-
V ploitation et à la maintenance (SACEM). Ap-
plication à la ligne A du RER. Revue Générale
techniques formelles. Collection IC2, Her-
mès-Lavoisier (2011).
perties with ProB. Workshop on B Dissemi-
nation, Natal, Brazil, 8 nov. 2010.
des Chemins de fer, 6, juin 1990. [84] LECOMTE (T.) et al. – Formal methods in
O [53] IEEE 1474.1. – IEEE standard for Communica-
tions-based Train Control (CBTC) perfor-
[68] Edited by BOULANGER (J.-L.). – Industrial
use of formal method, formal verification.
ISTE-WILEY (2012).
safety-critical railway systems. SBMF 2007,
Ouro Preto, Brazil (2007).
mance and functional requirements (2004). [85] LECOMTE (T.). – Safe and reliable metro plat-
I [54] The Standish Group. – The chaos report.
Technical report (1995).
[69] Edited by BOULANGER (J.-L.). – Formal me-
thods, industrial use from model to the code.
ISTE-WILEY (2012).
form screen doors control/command sys-
tems. FM’2008, Turku, Finland (2008).
[55] The Standish Group. – Extreme chaos. Tech- [86] RICHARD-FOY (M.) et LE GOFF (G.). –
R nical report (2001).
[56] The Standish Group. – Chaos manifesto
[70]
[71]
BOWEN (J.P.) et HINCHEY (M.G.). – Applica-
tions of formal methods. Prentice Hall (1995).
De la BRETESCHE (B.). – La méthode APTE :
On-board with safety critical software: Imple-
ment safety critical software for high-speed
2012. Technical report (2012). railway transportation. Alsys World Dia-
[57] RTCA DO-333. – Formal methods supple- analyse de la valeur, analyse fonctionnelle. logue, 8(2), 1994.
ment to DO-178C and DO-278A, déc. 2011. Pétrelle, Paris (2000). [87] HATTON (L.) et SAFER ( C.). – McGraw-Hill,
[58] BOULANGER (J.-L.). – Mise en œuvre des [72] LANO (K.). – The B language and method : a 1904.
P normes CENELEC 50128 et IEC 62279.
BOULANGER (J.-L.) (Editor), Wiley-ISTE,
guide to practical formal development.
Springer Verlag London Ltd (1996).
[88] MEYERS (S.). – Effective C++ : 50 Specific
Ways to Improve your programs and design.
ISBN : 978-1-78405-009-2, 350 p., juil. 2014. [73] MEINADIER (J.P.). – Le métier d’intégration Addison Wesley 2nd Edition (1998).
L [59] RTA DO 330. – Software tools qualification
consideration to DO-178C and DO-278A, déc. [74]
de systèmes. Hermès, Paris (2002).
POHL (K.). – Requirements engineering : fun-
[89] SUTTER (H.) et ALEXANDRESCU (A.). – C++
coding Standards, 101 rules, guidelines and
2011. damentals, principles, and techniques. Sprin- best practices. Addison Wesley, Boston
U [60] DELEBARRE (V.), GALLARDO
JUPPEAUX (E.) et NATKIN (S.). – Validation
(M.),
[75]
ger, Berlin, juin 2010.
RAMACHANDRAN (M.). – Knowledge en-
(2005).
[90] LOCKHEED (M.). – Joint strike fighter air
des constantes de sécurité du pilote automa- gineering for software development life vehicle C++ coding standards for the deve-
S tique de METEOR. ICSSEA’99, Paris, CNAM.
[61] HOUTMANN (C.), ABO (R.), HUMBERT (P.),
cycles : support technologies and applica-
tions. IGI Publishers, avr. 2011.
lopment and demonstration program. Docu-
ment 2RDU00001, rev C (2005).
MOTA (J.-M.) et BONVOISIN (D.). – Proving [76] ROQUES (P.). – UML 2 par la pratique – [91] MISRA. – MISRA C++: 2008 guidelines for the
static data correctness using OVADO for the Études de cas et exercices corrigés. Eyrolles, use of the C++ language in critical systems.
Paris métro ligne 13. Congrès Lambda Mu 19 Paris (2006). Motor Industry Research Association (2008).
À lire également dans nos bases

BOULANGER (J.-L.). – Sécurisation des systèmes BOULANGER (J.-L.). – CENELEC EN 50128:2011 Lo- CHAPAS (P.). – Composantes et applications élec-
mécatroniques. Partie 1. [BM 8 070] Transports giciel pour les transports ferroviaires. triques du système ferroviaire. [D 5 510] Trans-
(2010). [TRP 3 305] Transports (2013). ports (2003).
BOULANGER (J.-L.). – Sécurisation des systèmes CHAPAS (P.). – Traction ferroviaire – Équipements
BOULANGER (J.-L.). – Qualification des outils dans
mécatroniques. Partie 2. [BM 8 071] Transports d’exploitation et sécurité. [D 5 540] Transports
la norme 50128. [TRP 3 304] Transports (2013).
(2011). (2007).
BOULANGER (J.-L.). – Maîtrise du SIL et gestion BOULANGER (J.-L.). – Préparation des données au
des certificats – Domaine ferroviaire. [D 5 560] sens de la norme 50128. [TRP 3 306] Transports
Transports (2011). (2014).
Sites Internet
CENELEC ERTMS
http://www.cenelec.eu/Cenelec/Homepage.htm http://www.ertms.com
COFRAC IEC
http://www.cofrac.fr http://www.iec.ch/
EPSF ISO
http://www.securite-ferroviaire.fr/ http://www.iso.org/iso/home.html
ERA MODUrban
http://www.era.europa.eu http://www.modurban.org/
Doc. TRP 3 309 – 2 Copyright © – Techniques de l’Ingénieur – Tous droits réservés

P
O
OMG ASTREE
U
http://www.omg.org/
STRMTG
http://www.astree.ens.fr/
ADA 2012 R
http://www.strmtg.equipement.gouv.fr/ http://www.ada2012.org/
UGTMS SPARK 2014
http://www.ugtms.jrc.cec.eu.int/ http://www.spark-2014.org/
CodePeer
http://www.adacore.com/codepeer/
SCADE est distribué par la société Esterel-Technologies
http://www.esterel-technologies.com E
Polyspace VDM
http://www.mathworks.com/products/polyspace/
Caveat
http://www.vdmportal.org/
UML pour les dernières versions applicables : OMG
N
http://www-list.cea.fr/labos/fr/LSL/caveat/index.html http://www.omg.org
Absint MISRA
http://www.absint.com/ http://www.misra.org.uk/
FRAMAC
http://frama-c.com/
OOTIA
http://www.faa.gov/aircraft/air_cert/design_approvals/air_software/oot/ S
Événements
A
ERTSS Embedded Real Time Software and System
http://www.erts2012.org/
LambdaMU
http://www.imdr.fr
V
ESREL
http://www.esrel2011.com/
Qualita
http://www.rufereq.asso.fr/QUALITA O
Normes et standards
I
AFNOR EN 50155 12-01 Applications ferroviaires. Équipements
électroniques utilisés sur le matériel
ARINC DO 178:C 2001 Software Considerations in Airborne Sys-
tems and Equipment Certification, publi-
R
roulant shed by ARINC, DO 178B, and EUROCAE,

ED12, édition C
ANSI:1983,
ANSI/MIL-STD-1815A-19831983 Langage de programmation Ada
P
L
U
S
Copyright © – Techniques de l’Ingénieur – Tous droits réservés Doc. TRP 3 309 – 3
GAGNEZ DU TEMPS ET SÉCURISEZ VOS PROJETS
EN UTILISANT UNE SOURCE ACTUALISÉE ET FIABLE
Techniques de l’Ingénieur propose la plus importante

collection documentaire technique et scientifique
en français !
Grâce à vos droits d’accès, retrouvez l’ensemble
des articles et fiches pratiques de votre offre,
leurs compléments et mises à jour,
et bénéficiez des services inclus.
   
RÉDIGÉE ET VALIDÉE MISE À JOUR 100 % COMPATIBLE SERVICES INCLUS
PAR DES EXPERTS PERMANENTE SUR TOUS SUPPORTS DANS CHAQUE OFFRE
NUMÉRIQUES
 + de 350 000 utilisateurs

 + de 10 000 articles de référence
 + de 80 offres
 15 domaines d’expertise
Automatique - Robotique Innovation
Biomédical - Pharma Matériaux
Construction et travaux publics Mécanique
Électronique - Photonique Mesures - Analyses
Énergies Procédés chimie - Bio - Agro
Environnement - Sécurité Sciences fondamentales
Génie industriel Technologies de l’information
Ingénierie des transports
Pour des offres toujours plus adaptées à votre métier,

découvrez les offres dédiées à votre secteur d’activité
Depuis plus de 70 ans, Techniques de l’Ingénieur est la source

d’informations de référence des bureaux d’études,
de la R&D et de l’innovation.
www.techniques-ingenieur.fr
CONTACT : Tél. : + 33 (0)1 53 35 20 20 - Fax : +33 (0)1 53 26 79 18 - E-mail : infos.clients@teching.com
LES AVANTAGES ET SERVICES
compris dans les offres Techniques de l’Ingénieur
  
ACCÈS
Accès illimité Téléchargement des articles Consultation sur tous

aux articles en HTML au format PDF les supports numériques
Enrichis et mis à jour pendant Pour un usage en toute liberté Des contenus optimisés
toute la durée de la souscription pour ordinateurs, tablettes et mobiles
 
SERVICES ET OUTILS PRATIQUES
Questions aux experts* Articles Découverte Dictionnaire technique multilingue

Les meilleurs experts techniques La possibilité de consulter des articles 45 000 termes en français, anglais,
et scientifiques vous répondent en dehors de votre offre espagnol et allemand
 
Archives Impression à la demande Alertes actualisations
Technologies anciennes et versions Commandez les éditions papier Recevez par email toutes les nouveautés
antérieures des articles de vos ressources documentaires de vos ressources documentaires
*Questions aux experts est un service réservé aux entreprises, non proposé dans les offres écoles, universités ou pour tout autre organisme de formation.
ILS NOUS FONT CONFIANCE
www.techniques-ingenieur.fr
CONTACT : Tél. : + 33 (0)1 53 35 20 20 - Fax : +33 (0)1 53 26 79 18 - E-mail : infos.clients@teching.com

Methodes Formelles - Application Au Domaine-Trp3309

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Methodes Formelles - Application Au Domaine-Trp3309

Transféré par

Droits d'auteur :

Formats disponibles

Réf.

Cet article est issu de : Ingénierie des transports | Systèmes ferroviaires

par Jean-Louis BOULANGER

Mots-clés Résumé Depuis le développement de la première application ferroviaire à base de

Pour toute question :

Méthodes formelles : application

par Jean-Louis BOULANGER

1. Développement du logiciel................................................................. TRP 3 309 - 2

3. Méthodes formelles, semi-formelles, structurées

4. Mise en œuvre des méthodes formelles lors de la réalisation

B ien que les techniques d’analyses formelles de programme (voir les

travers d’outils « suffisamment » matures et performants.

Copyright © – Techniques de l’Ingénieur – Tous droits réservés TRP 3 309 – 1

MÉTHODES FORMELLES : APPLICATION AU DOMAINE FERROVIAIRE __________________________________________________________________________

Ce type de techniques a donné naissance, à plusieurs outils tels que Codepeer,

TRP 3 309 – 2 Copyright © – Techniques de l’Ingénieur – Tous droits réservés

__________________________________________________________________________ MÉTHODES FORMELLES : APPLICATION AU DOMAINE FERROVIAIRE

Analyse des besoins Conception

Détermination Conception détaillée

Planification Tests fonctionnels

Figure 2 – Trois cycles de vie possibles d’une application logicielle

Copyright © – Techniques de l’Ingénieur – Tous droits réservés TRP 3 309 – 3

MÉTHODES FORMELLES : APPLICATION AU DOMAINE FERROVIAIRE __________________________________________________________________________

La figure 3 présente le cycle en « V » tel que présenté en géné-

Conception Spécification Exécution

Figure 4 – Cycle en « V » incluant la spécification des tests

TRP 3 309 – 4 Copyright © – Techniques de l’Ingénieur – Tous droits réservés

__________________________________________________________________________ MÉTHODES FORMELLES : APPLICATION AU DOMAINE FERROVIAIRE

1.3 Avantages/désavantages Définition 2 – Analyse d’impact – L’analyse d’impact d’une ano-

important pour la maîtrise tant de la qualité de l’application logi-

Mise en œuvre 1.4 Vérification et validation

Copyright © – Techniques de l’Ingénieur – Tous droits réservés TRP 3 309 – 5

MÉTHODES FORMELLES : APPLICATION AU DOMAINE FERROVIAIRE __________________________________________________________________________

de qualité passe par la démonstration qu’aucun défaut n’a été

La figure 6 représente la problématique principale de la réalisa-

code non désirés (fonctions à réutiliser, ajout de service, etc.) et

bonne prise en compte des exigences de sécurité.

Dans le contexte de la norme CENELEC 50128:2011, la vérifica-

TRP 3 309 – 6 Copyright © – Techniques de l’Ingénieur – Tous droits réservés

__________________________________________________________________________ MÉTHODES FORMELLES : APPLICATION AU DOMAINE FERROVIAIRE

Copyright © – Techniques de l’Ingénieur – Tous droits réservés TRP 3 309 – 7

MÉTHODES FORMELLES : APPLICATION AU DOMAINE FERROVIAIRE __________________________________________________________________________

La mise en œuvre des activités de tests souffre de plusieurs pro-

C’est pourquoi il est nécessaire de mettre en œuvre d’autres pra- 3. Analyse

Comme le montre la figure 10, le travail de vérification consiste

TRP 3 309 – 8 Copyright © – Techniques de l’Ingénieur – Tous droits réservés

__________________________________________________________________________ MÉTHODES FORMELLES : APPLICATION AU DOMAINE FERROVIAIRE

Sous-système signalisation Train

Hardware Logiciel Hardware Logiciel

Figure 11 – Normes applicables aux systèmes ferroviaires

Copyright © – Techniques de l’Ingénieur – Tous droits réservés TRP 3 309 – 9

MÉTHODES FORMELLES : APPLICATION AU DOMAINE FERROVIAIRE __________________________________________________________________________

dans la maîtrise de ce logiciel ? ». La version 2011 de la norme CENELEC EN 50128 introduit la

Rôle Clauses 5 Annexe B

Techniques Bibliographies liées aux techniques

Figure 12 – Structure de la norme CENELEC EN 50128:2011

TRP 3 309 – 10 Copyright © – Techniques de l’Ingénieur – Tous droits réservés

__________________________________________________________________________ MÉTHODES FORMELLES : APPLICATION AU DOMAINE FERROVIAIRE

Comme cela a été indiqué, la norme CENELEC EN 50128:2011

sémantique, il s’agit de modèle pour conceptualiser et raisonner sur

Architecture Spécification des TI Exécution des TI

Figure 13 – Cycle en « V » de la norme CENELEC EN 50128 Figure 14 – Exemple de modèle Simulink

Copyright © – Techniques de l’Ingénieur – Tous droits réservés TRP 3 309 – 11