1diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
Processus de validation basée sur la notion de propriété
Jean-louis Boulanger
RATP
ESE / ICH / AQLM
2diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
Sommaire
• Présentation de METEOR
• Processus de développement MTI
• Processus de validation RATP
• Conclusions
3diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
Présentation de METEOR
4diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
le SAET de METEOR, c'est ...
• un système automatique complexe fortement intégrématériel roulant, équipements électriques, infrastructures, automatismes
• quatre sous-systèmes dans l'automatismeaudiovisuel, PCC et logique traction, portes palières, pilotage automatique/signalisation
• la mixité des circulations trains équipés d’automatismes
mode de conduite automatique intégrale ou
mode de conduite manuel
et trains non équipés
5diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
Une architeture répartie de calculateur redondés
Pilote Automatique de Ligne
PiloteAutomatique
Sol 1
Pilote AutomatiqueEmbarqué1
Pilote AutomatiqueEmbarqué2
PiloteAutomatique
Sol 2
PiloteAutomatique
Sol n
……
Poste de commandecentralisé
6diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
et METEOR est aussi devenula ligne 14 du métro parisien
• Mise en service le 15 octobre 1998
• 7,2 km de ligne exploitée, de Madeleine à la Bibliothèque François Mitterrand pour 7 stations
• dès maintenant une capacité de 25 000 voyageurs par heure et par sens
• 19 trains de 6 voitures (extension à 8 voitures prévue)
• une vitesse commerciale de 40 km/h
• un intervalle de 85 secondes pour les trains en Conduite Automatique Intégrale
7diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
Un automatisme complexe1 - vidéo-surveillance train
2 - inter-phonie train
3 - vidéo-surveillance quai
4 - inter-phonie quai
5 - portes palières
6 - pilotage automatique embarqué
7 - tapis de transmission
8 - transmission sol - bord
9 - signalisation
10 - pilotage automatique fixe
- 1 PA de ligne
- des PA de section
11 - poste de commandes centralisé
8diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
Présentation du processus de développement MTI
9diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
Séparation du code et des données
Spécificationlogicielle
EXECUTABLE
Description de la ligne
Modèle B
Invariant de BesoinCode ADA sécurisé
Caractéristiquedes trains
10diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
le cycle de vie des logiciels B
spécification littéraledu logiciel
tests fonctionnels
ré-expressionformelle en B
conceptionformelle
génération deprogramme
(automatique)
intégrationlogicielle
preuve
preuve
preuve
11diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
la "Méthode B"
• une formalisation mathématique des propriétés de sécurité permettant ensuite la démonstration de leur respect par le logiciel à chaque niveau de raffinement
• exemple :P1: "il ne doit pas y avoir de risque de collision"
devient
12diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
Processus d’élaboration des données
Description de la ligne
InvariantTopologique
PAE
InvariantTopologique
PAL
InvariantTopologique
PAS1
InvariantTopologique
PASn
Outilde
Génération
CaractéristiqueDes trains
13diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
Présentation du processus de validation RATP
14diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
Processus RATP
• Le processus de validation des logiciels critique de la RATP s’appuis sur deux activités:– Un contrôle de l’industriel sur l’ensemble du
processus.
– Une double validation• des logiciels critiques,• des donées manipulées par les logiciels critiques.
15diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
But de la double validation
• La double validation se décompose en – une analyse
– une modélisation
– la production d’un cahier de test fonctionnel
– et l’exécution du cahier de test fonctionnel
16diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
Double Validation
Cahier des charges Fonctionnel
Spécification FonctionnelleEquipement
Spécification Logicielle
EXECUTABLE
Tests FonctionnelsModélisation
La RATP réalise une double validation indépendante du constructeur
17diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
Modélisation
La RATP utilise actuellement deux méthodes pour la modélisation
• ASA , ASA+ :• SADT • Automate étendue communicant• Noyau de vérification
• ELSIR : • Réseau de pétri
18diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
Principe de vérification
Modèle M
S
E
Abstraction de lafonction Observateur de
conformité avec laspécification
Propriétés desécurité
S’
E: entrée S, S’ : sorties booléennes
19diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
Exemple de propriété de sécurité
• P2 : seuls les trains équipés, localisés et ayant un mode de conduite automatique peuvent disposer d’une cible
• P3 : L’état interne du PAS représentant l’occupation de la voie doit être cohérent avec l’ensemble des trains (équipés ou pas) présent dans la zone gérée par ce PAS.
20diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
Complexité des modèlesexemple la onction anticollision
Spécification(automate)
Réalisation
Environnement
39 étatset
135 transitions
Spécification Propriété
65 étatset
240 transitions
9 étatset
6 transitions
8300 lignesde code
2000 lignesde code
1500 lignesde code
21diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
La Validation des données
• Vérification sur le terrain des données initiales
• Validation outillée par la RATP– effectuant la fonction de transfert inverse
– vérifiant le respect des contraintes de sécurité (exprimées formellement dans le langage LPIC)
22diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
Outils de validation des données
Descriptionde la ligne
InvariantTopologique
d'un équipement
Outilde
Génération
DonnéesGénérées
Outilde
Comparaison
Outil deVérification
de Contrainte
OK ou KOOK ou KO
Caractéristiquedes trains
23diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
Exemple de contrainte sur les données
• P4 : L’ensemble des circuits de voie forme une partition de la voie.
24diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
le rôle des acteurs, côté logiciels
Le Constructeur MTI La RATP
conçoit et valide contrôle et validepar
spécificationsdéveloppement dont ..
..méthode Butilisation de l'atelier B
preuve Btranscodage
testsgénération des donnéesgestion de configuration
parmodélisations statiques
analyses de sécuritéprocessus de revues
traçabilitévalidation des règles B
analyse de codetests des exigences .. ..de sécurité
couverture des testsvalidation des données
les méthodesleur application
la traçabilitéles documents
les règles Bles preuves B
parmodélisations dynamiquesanalyse des algorithmes
travaux sur l'atelier Btests fonctionnels et....tests agressifs sur ..
..calculateur ciblecouverture des tests
validation des donnéesrégénération du codegest. de configuration
25diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
de Façon Synthétique
conviction
la même spécification
conception
méthode B et preuves
produit logiciel validation
modélisation & simulation
tests
contrôles decouverture
écarts 0
analyses &modélisation
MTI RATP
cahiers de test
suivi deconception
26diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
Conclusion
27diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
Quelques éléments statistiques sur le développement
• 1 150 composants B
• 115 000 lignes de code B
• 27 800 obligations de preuve
• 150 000 lignes de code ADA (données comprises) pour les 3 équipements
28diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
sur le processus RATP
• 20 Dossiers de principe• 23 Modèles• 30 Cahiers de tests• Plus de 5 000 tests en environnement temps réel
simulé.
29diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
Anomalie/Remarques
• 400 remarques critiques pour la sécurité au niveau des spécifications
• 110 anomalies sur l’ensemble des versions des logiciels de sécurité (3 versions sur 3 applicatifs différents)
30diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
Le bilan sur METEOR
• Un pocessus de vérification de spécification basée sur les propriétés (fonctions + données)
• Un processus de tests sur cibles avec vérification de propriétés
• Un logiciel qui a fonctionné dès sa première installation
• Une maîtrise accrue des évolutions
• et ... la conviction de la sécurité
31diffusion autorisée aux participants de la réunion BUG/SEE du 29 et 30 Novembre 1999
qui a débouché sur
• l’accriditation COFRAC sur 5 essais– SUR1 : lecture critique de spécification
– SUR2 : modélisation
– SUR4: Analyse d’impact
– SUR11 : réalisation d’un cahier de test fonctionnel
– SUR13 : exécution du cahier de test fonctionnel
• ICH premier laboratoire en France ayant obtenue cette accréditation.