Processus de validation basée sur la notion de propriété

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


Sommaire

• Présentation de METEOR

• Processus de développement MTI

• Processus de validation RATP

• Conclusions


Présentation de METEOR


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


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é


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


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é


Présentation du processus de développement MTI


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


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


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


Processus d’élaboration des données

Description de la ligne

InvariantTopologique

PAE


PAL


PAS1


PASn

Outilde

Génération

CaractéristiqueDes trains


Présentation du processus de validation RATP


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.


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


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


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


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


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.


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


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)


Outils de validation des données

Descriptionde la ligne


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


Exemple de contrainte sur les données

• P4 : L’ensemble des circuits de voie forme une partition de la voie.


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


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


Conclusion


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


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é.


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)


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é


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.

Documents

Processus de validation basée sur la notion de propriété