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

Présentation au sujet: "Processus de validation basée sur la notion de propriété"— Transcription de la présentation:

1 Processus de validation basée sur la notion de propriété
Marcel Gallardo RATP

2 Sommaire Présentation de METEOR Processus de développement MTI
Processus de validation RATP Essais accrédités par le COFRAC Conclusions

3 Présentation de METEOR
Sur un dossier aussi complexe, d'une telle importance pour la RATP et aussi novateur, Présentation de METEOR

4 le coeur de l'automatisme deMETEOR s'appelle le SAET : Systême d'Automatisation de l'Exploitation des Trains le SAET de METEOR, c'est ... Un système automatique complexe fortement intégré matériel roulant, équipements électriques, infrastructures, automatismes, ... Six sous-systèmes : - Moyens audio et vidéo - Poste de Commande Centralisée - Logique traction - Portes palières - Pilotage automatique - Signalisation tout n'a pas le même niveau de sécurité

5 le SAET de METEOR, c'est ... 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

6 et METEOR est aussi devenu la ligne 14 du métro parisien
Mise en service le 15 octobre 1998 7,2 km de ligne exploitée, de Madeleine à Bibliothèque François Mitterrand pour 7 stations dès maintenant une capacité de 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
ici, un schéma très synthétique concernant l'automatisme 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 Une architecture répartie de calculateurs redondés

9 Présentation du processus de développement
Sur un dossier aussi complexe, d'une telle importance pour la RATP et aussi novateur, Présentation du processus de développement

10 le rôle des acteurs, côté logiciels
là encore , des équipes indépendantes et des méthodes diversifiées, tant à la RATP que chez le constructeur 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

11 Séparation du code et des données

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

13 Processus d’élaboration des données

14 Présentation du processus de validation RATP
Sur un dossier aussi complexe, d'une telle importance pour la RATP et aussi novateur, Présentation du processus de validation RATP

15 Cycle de vie en V

16 Processus RATP Certification du calculateur de base
Validation fonctionnelle indépendante de celle de l’industriel Contrôle RATP des activités de l’industriel

17 Certification du calculateur
Pour Météor la RATP a Vérifié les démonstrations de sécurité Mené ses propres analyses : - Identification des fonctions de sécurité - Prise en compte et déclinaison des exigences de sécurité

18 Méthode de validation RATP (1)
Formalisation des activités et responsabilités par un Plan de Validation des logiciels Formalisation de la méthode de détermination des tests par des Plans de tests de niveau équipement Formalisation de la méthode de validation des données par des Plans de validation des données de niveau équipement

19 Méthode de validation RATP (2)
Réflexion depuis les niveaux sous-système et équipement Modélisation dynamique des spécifications : - validation des spécifications - préparation des cahiers de tests Validation du logiciel sur calculateur cible Mesure de la couverture des tests / spécifications

20 Méthode de validation RATP (3)
Validation des principes fonctionnels basée sur la détermination de propriétés de sécurité Validation des interfaces entre équipements par l’analyse de fonctions transversales Validation des données par reconstruction à partir des codes sources des données géographiques

21 Principe de Modélisation

22 OBSERVATEUR On observe le résultat de l’application des principes définis dans les spécifications sur les événements issus de l’environnement. * Vérification des séquences de calcul et de l’état atteint * Vérification des équations de la fonction observée IL PERMET LE LIEN AVEC LA CONCEPTION FORMELLE B Les propriétés de CORRECTION et de COMPORTEMENT <--> INVARIANTS B IDENTIFICATION SYSTEMATIQUE DE SCENARII : * Situations physiques (trains, matériel), * Définition des étapes transitoires (séquencement des états de calcul), * Valeurs attendues

23 EVALUATEUR IL VERIFIE L’ENSEMBLE DES PROPRIETES DE SECURITE :
Il évalue, A PARTIR DE SA PROPRE BASE DE REGLES, la correction et la cohérence des sorties produites en fonction des entrées issues de l’environnement. IL CONSTITUE UNE AIDE AU DEPOUILLEMENT DES RESULTATS DES TESTS SUR CIBLE : Les propriétés sont vérifiées sur les résultats produits lors de l’exécution des scénarii de test.

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

25 Outils de modélisation
ASA , ASA+ : SADT Automate étendue communicant Noyau de vérification ELSIR : Réseau de pétri

26 La Validation des données
disposer d'un code prouvé sûr par rapport à sa spécification serait vain si nous n'avions pas procédé avec la même vigilance à la vérification des données traitées en effet, si par exemple un point d'arret d'un train était mal spécifié et que ce train s'arrête de façon sure quelques mêtres trop loin conduirait évidemment à un risque d'accident le processus mentionné ici dans ses grandes lignes est celui qui a été suivi les données ont ensuite fait l'objet d'une double saisie qui a utilisé deux outils distincts pour la génération et la validation 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)

27 Outils de validation des données

28 Exemple de contrainte sur les données
P4 : L’ensemble des circuits de voie forme une partition de la voie. P10: Il existe une cible (unique) par sens autorisé pour un CV. Le sens de ralliement de la cible est nécessairement celui du CV. P15: Il doit y avoir deux DN de substitution par CdV substituable.

29 Accréditation par le COFRAC
Sur un dossier aussi complexe, d'une telle importance pour la RATP et aussi novateur, Accréditation par le COFRAC

30 Accréditation COFRAC Action stratégique décidée par la direction du département ESE sous l ’impulsion des tutelles Référentiel qualité du laboratoire basé sur les normes EN et EN Procédures métiers basées sur la démarche de validation RATP Élargir le périmètre des marchés et Garantir au client compétence, indépendance et impartialité

31 Essais accrédités (1) Accréditation sur 5 essais du programme 152 du COFRAC : - Essai SUR1 : Vérification orientée Sûreté de Fonctionnement de la documentation de spécification du logiciel - Essai SUR2 : Modélisation orientée Sûreté de Fonctionnement de la spécification du logiciel

32 Essais accrédités (2) - Essai SUR 11 : Mesure de couverture des exigences de Sûreté de Fonctionnement par les tests - Essai SUR 13 : Tests de validation orientée Sûreté de Fonctionnement - Essai SUR 14 : Analyse orientée Sûreté de Fonctionnement de l’impact des modifications du logiciel

33 Sur un dossier aussi complexe, d'une telle importance pour la RATP et aussi novateur,
CONCLUSIONS

34 Quelques éléments statistiques sur le développement
1 150 composants B lignes de code B obligations de preuve lignes de code ADA (données comprises) pour les 3 équipements

35 sur le processus RATP 20 Dossiers de principe 23 Modèles
30 Cahiers de tests Plus de tests en environnement temps réel simulé.

36 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)

37 mesdames, messieurs, je vous remercie de votre attention
le bilan sur METEOR ce dernier transparent présente un bilan axé principalement sur l'aspect "logiciels de sécurité", où se situaient les plus grosses difficultés, et sur les bénéfices retirés de leur développement formel de façon plus large, on peut dire aujourd'hui que la RATP continuera à imposer le développement formel pour ses systèmes les plus critiques la ligne 14 du métro fonctionne de façon irréprochable depuis sa mise en service, et le trafic qu'elle assure dépasse même nos éspérances. mesdames, messieurs, je vous remercie de votre attention Un processus 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é