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

1. Processus de validation basée sur la notion de propriété Jean-louis Boulanger RATP ESE / ICH / AQLM

2. Sommaire • Présentation de METEOR • Processus de développement MTI • Processus de validation RATP • Conclusions

3. Présentation de METEOR

4. 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'automatisme audiovisuel, 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

5. Une architeture répartie de calculateur redondés

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

7. Un automatisme complexe 1 - 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é

8. Présentation du processus de développement MTI

9. Séparation du code et des données

10. preuve le cycle de vie des logiciels B spécification littérale du logiciel tests fonctionnels preuve ré-expression formelle en B intégration logicielle conception formelle preuve génération de programme (automatique)

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

12. Processus d’élaboration des données

13. Présentation du processus de validation RATP

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

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

16. Double Validation La RATP réalise une double validation indépendante du constructeur

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

18. Principe de vérification E: entrée S, S’ : sorties booléennes

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

20. Complexité des modèlesexemple la onction anticollision

21. 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)

22. Outils de validation des données

23. Exemple de contrainte sur les données • P4 : L’ensemble des circuits de voie forme une partition de la voie.

24. le rôle des acteurs, côté logiciels Le Constructeur MTI La RATP conçoit et valide contrôle et valide par spécifications développement dont .. ..méthode B utilisation de l'atelier B preuve B transcodage tests génération des données gestion de configuration par modélisations statiques analyses de sécurité processus de revues traçabilité validation des règles B analyse de code tests des exigences .. ..de sécurité couverture des tests validation des données par modélisations dynamiques analyse des algorithmes travaux sur l'atelier B tests fonctionnels et.. ..tests agressifs sur .. ..calculateur cible couverture des tests validation des données régénération du code gest. de configuration les méthodes leur application la traçabilité les documents les règles B les preuves B

25. écarts 0 de Façon Synthétique la même spécification MTI RATP conception analyses & modélisation modélisation & simulation contrôles de couverture méthode B et preuves cahiers de test produit logiciel validation tests suivi de conception conviction

26. Conclusion

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

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

29. 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)

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

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