Dániel Darvas (CERN BE-ICS-PCS) Spécification formelle pour les API CERN-ESTEREL séminaire 21/01/2016, CERN Travail conjoint avec B. Fernández, E. Blanco,

Présentation au sujet: "Dániel Darvas (CERN BE-ICS-PCS) Spécification formelle pour les API CERN-ESTEREL séminaire 21/01/2016, CERN Travail conjoint avec B. Fernández, E. Blanco,"— Transcription de la présentation:

1

2 Dániel Darvas (CERN BE-ICS-PCS) Spécification formelle pour les API CERN-ESTEREL séminaire 21/01/2016, CERN Travail conjoint avec B. Fernández, E. Blanco, R. Speroni, I. Majzik http://cern.ch/plcspecif

3 Notre motivation −Aider le développement et la réingénierie (re- engineering) Notre code évolue depuis 10+ ans Le code et la spécification textuelle sont inconsistants −La vérification n’a aucun sens sans propriétés à vérifier −Faciliter d’exprimer les exigences complexes −Générer (une partie) du code peut être possible

4 Nos exigences −Méthode légère (lightweight) Facile à apprendre Pas besoin de Bac+5 en informatique −Méthode adaptée aux API Facile d’exprimer les exigences communes Sémantique adaptée −Méthode formelle −Outils disponibles  :B, VDM, Z, ST-LTL, …  :UML, Simulink, Spec-TRM, … Plus d’information: D. Darvas, I. Majzik, E. Blanco. Requirements towards a formal specification language for PLCs. http://doi.org/10.5281/zenodo.14907

5 Méthodes de spécification pour les API Trop théoriqueTrop proche du code Exemple: ProcGraph Exemple: ST-LTL Spec2 := ALWAYS( (v >= lowlimit) & (v <= highlimit)); Spec3 := ALWAYS(start -> EVENTUALLY running); Spec5 := ALWAYS( EStop OR NOT Activate -> Not Run ); Spec6 := ALWAYS( Run_risingEdge ONLY_IF Not EStop & Not Error & Reset_risingEdge ); Spec7 := NEVER( Reset & Reset_previous & NOT EStop & Run_risingEdge );

6 Notre proposition: PLCspecif −Spécification simple, formelle, adaptée aux API −Spécification complète – pour des modules d’API −Basée sur la connaissance des développeurs dans la domaine d’API En réutilisant les méthodes semi-formelles fréquemment utilisées Automates finis Circuits logiques Avec sémantiques précises

7 Notre proposition: PLCspecif Méthode hiérarchique −Un arbre de modules Modules internes / composés Modules feuilles −La logique est définie dans les modules feuilles Composite0 Statemachine1Statemachine2Composite1Statemachine3IoConnection1IoConnection2

8 Traitement des entrées Logique principale Traitement des sorties Notre proposition: PLCspecif Logique principale propre (clean core logic) −Beaucoup de traitements d’entrées/sorties dans les programmes API −Tous les modules sont structurés:

9 Notre proposition: PLCspecif Adapté aux API −Événements utilisés comme dans les API −Plusieurs formalismes pour la logique principale Le développeur peut choisir le meilleur −Représentation tabulaire des expressions Beaucoup d’expressions logiques complexes Plus d’information: D. Darvas, E. Blanco, I. Majzik. A formal specification method for PLC- based applications. ICALEPCS 2015. http://icalepcs.synchrotron.org.au/papers/wepgf091.pdf and http://icalepcs.synchrotron.org.au/posters/wepgf091_poster.pdf

10 PLCspecif: exemple (1 module) Logique principale est séparée Sémantique adaptée aux API Soutiens la vérification

11 PLCspecif: exemple (1 module) Logique principale est séparée Plusieurs formalismes semi-formels réunis Sémantique adaptée aux API Spécification détaillée du comportement Soutiens la vérification Structuré, hiérarchique

12 Où sommes-nous maintenant? −Le projet a commencé il y a 1,5 ans −Syntaxe et sémantique (formelle) définies −Méthode de vérification définis −Outil très-très expérimental −Pour le moment, seulement pour des modules d’API (pas pour des applications complètes) Travail futur −Néanmoins, on a déjà essayé dans la vraie vie Plus d’information: D. Darvas, I. Majzik, E. Blanco. Syntax and semantics of PLCspecif. EDMS report 1523877, 2015. https://edms.cern.ch/document/1523877

13 Étude de cas: vérification de SM18 But: assurer la sûreté des tests © CERN Critique pour la sûreté

14 SM18: chronologie de la réalisation Analyse Analyse des exigences (semi-formelles) Analyse de la sûreté Réalisation Réalisation du code (manuelle – API de sécurité) Vérification 1. Vérification formelle (vérification de modèles) 12 problèmes sont identifiés (et fixés) Vérification 2. Développement de la spécification formelle Vérification basée sur la spécification formelle

15 SM18: chronologie de la réalisation 1. Analyse des exigences (semi-formelles) 2. Analyse de la sûreté 3. Réalisation du code (manuelle – API de sécurité) 4. Vérification formelle (vérification de modèles) 12 problèmes sont identifiés (et fixés) 5. Développement de la spécification formelle En raison de vérification 6. Vérification basée sur la spécification formelle

16 Vérification basée sur la spécification formelle Spécification formelle + Vérification de l’équivalence de comportement Spécification formelle nécessaire Difficile à calculer le résultat Complet Pas besoin d’extraire les exigences +2 nouveaux problèmes trouvés! comparaison Code API Spécification PLCspecif Modèle formel Par un vérificateur de modèles

17 Problèmes trouvés Au total 14 problèmes trouvés 4 exigences mal comprises 6 problèmes impossible à trouver en utilisant nos méthodes de tests 2 trouvés seulement en utilisant la spécification formelle

18 Résumé −PLCspecif Spécification formelle pour des modules d’API Complet, léger, adapté aux API Pour le développement du code et la vérification Déjà utilisé pour un projet critique −Travail futur Des outils, des outils, des outils Extension aux applications d’API complètes http://cern.ch/plcspecif

19

20

21

22 Composite0 Statemachine1Statemachine2Composite1Statemachine3IoConnection1IoConnection2 Exemple: Basée sur IEC 61131