Vérification formelle par model-checking

Transkript

1 Vérification formelle par model-checking Introduction, principes et utilisation du logiciel UPPAAL Steve LIMAL doctorant

2 Planning de la journée Problématique Principe du model-checking définitions principe général Modèle de comportement - Difficulté de génération - application à UPPAAL Modèle de propriété - la logique CTL - exemple de propriété Traitements de cas Évaluation 2

3 Problématique Les systèmes automatisés Objectif : contrôle automatique d un processus. Processus : constituants mécaniques, électriques, pneumatiques, électroniques,... actionneurs. capteurs ou détecteurs. Commande : Automate Programmable Industriel (API): contrôleur industriel monotache cyclique. Entrées API Processus Sorties Enjeu : l état du processus n est connu de la commande qu à partir d informations discrètes (entrée). 3

4 Problématique Les API Caractéristiques Robuste Stable temporellement Rapide Fonctionnement : Mono tache cyclique collecte des informations du processus (entrées) traite les données reçues donne des ordres au processus (sorties) initialisation Lecture des entrées Traitement Émission des sorties Programmation : 5 langages normalisés (IEC ): textuels : ST, IL graphiques : SFC, LADDER, FBD 4

5 Problématique Ladder Diagram Caractéristique langage graphique normalisé (Norme IEC ) Constitution réseaux exécutés séquentiellement - contacts - bobines - blocs fonctionnels mémoires temporisations détecteurs d événements RS_pce rec bas RS pce L S Q ( )--+ ava bas R1 auto / TON_L1 bas bs_1s L IN TON Q ( )--+ #1sec- PT ET RS_ava rec haut RS haut O_ava L S Q ( )--+ ava R1 auto Bobine +- / --+ RS_rec ava haut RS haut O_rec L S Q ( )--+ rec R1 auto / --+ RS_des rec pce haut RS rec O_desc L / S Q ( )--+ ava pce ava bs_1s R1 auto / --+ pce O_asp L ( )--+ RS_pce rec bas RS pce L S Q ( )--+ ava bas R1 auto / Bloc fonctionnel TON_L1 bas bs_1s L IN TON Q ( )--+ #1sec- PT ET Contact 5

6 Problématique Besoins Comment prouver que le contrôle du processus : est exempt de bugs? est conforme aux attentes du cahier des charges? Scénario de test sur le réel? très proche de l utilisation nominale ; vue très limitée des possibilités du contrôle ; nécessite du matériel spécifique. Simulation par modèle? long ; n atteint pas tous les cas d utilisations possibles. Vérification formelle prouve que le programme de commande est conforme ; taux de couverture de 100% du comportement logiciel. MAIS vérification de modèles de programme et non de programmes. 6

7 Vérification formelle du comportement d un système Problématique Comportement Désiré (CD) Ce que le système doit faire Comportement Interdit (CI) Ce que le système ne doit pas faire Comportement du système (CS) Ce que fait le système Vérification formelle : Prouver que CD CS CI I CS = CD CD Comportement Interdit CD CD CD Comportement du Système CDCD Comportement CDésiré CD 7

8 Intégration dans développement de programme de commande Cahier des charges CD Comportement CD CD CD Interdit CD Propriétés à vérifier Problématique Conception du logiciel de commande CD Comportement Désiré Vérification formelle Propriétés vérifiées ou non Contrôleur Comportement du Système processus 8

9 Model-checking Définitions «Model... connaître ou caractériser tous les états d'évolution du programme de contrôle nécessaire à la vérification. Ex : le graphe des situations accessibles d un GRAFCET ou d un réseau de Pétri Checking» vérifier des propriétés sur ces états ou la relation entre ces états. État Valeur des variables à un instant donné. 9

10 Model-checking Principe Programme de contrôle Moniteur I E T S Propriétés il est toujours vrais que... pas de blocage. tel événement suit toujours celui-ci. Modélisation Formalisation Modèle de comportement (Automate à états) AG(APB AF ~horn) AG(~d1 AF ~lig) Logique temporelle (LTL, CTL, ) MODEL CHECKER Propriétés vérifiées ou diagnostic en cas d échec 10

11 Modèle : automates à états Modélisation du comportement de l exécution du programme LD par un API Etat de l automate 4 possibilités Etat d avancement du cycle de l API - Lecture des entrées - Exécution du programme utilisateur Exécution de L1 Exécution de L2 - Ecriture des sorties A B A B S L / --( )-+ S S T T L / ----( )-+ API en exécution cyclique S T Valeur des variables présentes dans le programme - A, B, S, T 16 combinaisons Formalisation Taille maximale de l automate : 64 états Automate à états finis 11

12 Génération de l automate à états finis 35 états, 56 transitions Valeurs des variables T S B A B A B S L / --( )-+ S S T T L / ----( )-+ A A B S T S T Début cycle API Cycle API Lecture des entrées Initialisation? Initialisation Exécution de la ligne 1 Exécution de la ligne 2 Ecriture des sorties Fin cycle API 12

13 Modèle : automates à états Codage dans un outil de Model-Checking A B A B S L / --( )-+ S S T T L / ----( )-+ API en exécution cyclique S T Identification des éléments clés Modélisation du comportement des éléments clés Moniteur d exécution Variables du programme Entrées Variables calculées Formalisation Passage direct difficile à formaliser et peu opérationnel Variables calculées synchronisation Entrées Automate à états finis Construction de l automate à états Outil spécialisé Moniteur d exécution 13

14 Introduction à UPPAAL UPPAAL Caractéristiques : outil pour modéliser, simuler et vérifier des systèmes en temps réel. modélise les systèmes comme une collection d automates : - non déterministes; - temporisés par des horloges à valeurs réelles; - communiquant par des canaux de messages ou des variables partagées. UPPAAL se compose de trois parties: un éditeur graphique un simulateur un model-checker 14

15 Editeur graphique Outils Arborescence des automates Configuration Déclaration de variables Construction d automate 15

16 Editeur graphique Affectation de variable Introduction à UPPAAL Etat initial Etat Emission synchronisation Garde Reset d horloge Invariant Réception de message 16

17 Simulateur Choix d évolution Historique des évolutions choisies États des automates communicants Évolution des automates et synchronisations États des variables 17

18 Les automates à états finis temporisés Les états À tout moment un et un seul état est actif dans un automate. 3 états spéciaux : Initial état unique et obligatoire, activé à l initialisation. Committed état qui, une fois actif, doit être désactivé au prochain pas d évolution. Urgent état qui, une fois actif, doit être désactivé dans un temps nul. Invariant : condition associable à un état. si l état est actif, la condition doit être respectée. 18

19 Les automates à états finis temporisés Transition 4 éléments configurables : Sélection (select) Valeur non déterministe d une variable dans un set donné: permet de regrouper la définition de plusieurs transition entre deux états. Garde (guard) condition de franchissement : si fausse, la transition ne peut être franchie. Synchronisation (synchronization) élément de communication entre automate : permet le franchissement simultané de transitions entre automates. Normale (1 émetteur, 1 récepteur) Broadcast (1 émetteur, n récepteur(s)) n Ν automate1 automate2 automate1 automate2 automate3 Affectation (update et select) modification de la valeur de variables par calcul, avec une formule (update) Semaine de regroupement ATELIER 2 11/10/

20 Les automates à états finis temporisés Les variables Quatre types élémentaires: int : variable entière, par défaut dans la plage [-32768, 32767] et initialisée à 0. Plage et initialisation configurable. bool : variable booléenne, initialisée par défaut à 0. Initialisation configurable. clock : variable réelle dédiée au temps. Test et affectation uniquement avec des valeurs entières. chan : canal de communication, de type normal par défaut. 3 autres types possibles : urgent, broadcast et urgent broadcast. Déclaration : Globale Locale Implicite : Pour chaque état Ei de chaque automate Ai, une variable de type bool représentant son activité est créée : Ai.Ei 20

21 Les automates à états finis temporisés Règles d évolution Sans synchronisation : Si une transition est franchissable, elle peut être franchie mais sans obligation. Une seule transition peut être franchie à chaque pas d évolution parmi tous les automates. Avec synchronisation : Une synchronisation possible de plusieurs automates (i.e. les transitions correspondantes sont franchissables sans la synchronisation) est : - immédiate ; - prioritaire sur d autres transitions normales. Une synchronisation normale non possible est bloquante pour l émetteur et le récepteur. Une synchronisation broadcast non possible est bloquante seulement pour les récepteurs. Respect des invariants : Les invariants de chaque état actif doivent toujours être respectés. Si un invariant ne peut être respecté, tous les automates sont alors bloqués (deadlock). 21

22 Exemple d évolution et première utilisation de UPPAAL Les automates à états finis temporisés Réaliser des modèles suivants et simuler leur évolution : test : normal chan test : broadcast chan A:=1 A:=1 A:=1 test! A:=1 test! A:=0 A:=0 A==1 Automate 1 A:=0 test? C Automate 1 A:=0 test? C Automate 1 Automate 2 Automate 2 A==0 test? test? Automate 2 Automate 3 Automate 3 22

23 Les automates à états finis temporisés Exercices d utilisation Construire et simuler: 1. Un automate modifiant alternativement la valeur de la variable booléenne A entre 0 et Un automate comptant jusqu à 20 avec une variable B puis mettant la variable A à Un automate attribuant une valeur entre 0 et 5 à la variable entière A comprise entre 0 et Un automate aillant le même comportement que trois automates du (1), à comparer le comportement avec 3 automates. 5. Deux automates jouant au ping-pong avec les messages «ping» et «pong». 6. Trois automates manipulant une variable booléenne chacun, attribuant la valeur 0 ou 1, de façon non déterministe, simultanément au message top! d un quatrième automate. 23

24 Les automates à états finis temporisés Le temps Décompte du temps avec les horloges à valeur réelle. Écoulement du temps simultané sur chaque horloge Tests des horloges dans les gardes ou les invariants par rapport à un entier. Exemples : X := 0 X >=5 X := 0 X >=5 X := 0 X >=5 and X<= X <= X 5 1 t Δt >= 5 2 X 5 1 t Δt = 5 2 X t 5 <= Δt <= 7 24

25 Exercices sur les horloges Construire et simuler : Les automates à états finis temporisés 1.Un automate attendant un temps supérieur à 20 unités de temps puis mettant la variable A à 1. 2.Un automate modifiant alternativement la valeur de la variable booléenne A entre 0 et 1, toutes les 10 unités de temps. 3.Un automate représentant le fonctionnement d une TON. L entrée de la TON sera modélisée par un automate indépendant. 25

26 Les automates à états finis temporisés Temporisation TON TON_L1 L1_Prod L1_pump L IN TON Q ( ) #5sec- PT ET - L1_down ( ) IN t0 t1 t2 t3 t4 t5 PT / + / ET / / / / / / : / / / t0 t1 t2 t3 t4 t Q t0+pt t1 t4+pt t5 Ecoulée +---o +---o En cours +----o +---o +----o Inactive 0-o : o +---o : t0 t0+pt t1 t2 t3 t4 t4+pt t5 26

27 Application Application Modéliser le système suivant... API en exécution cyclique A B A B S L / --( )-+ S S T T L / ----( )-+ S T initialisation Lecture des entrées Traitement Émission des sorties Temps de cycle : 1 unité de temps Processus modélisé par des entrées indéterministes.... en vue de la vérification de la propriété suivante... Lorsque l entrée B est présente, la sortie T doit être absente.... avec l hypothèse suivante. Le temps de cycle s écoule seulement entre l émission des sorties et la lecture des entrées du cycle suivant. 27

28 Application Le moniteur d exécution U Avant initialisation Horloge >= Temps de cycle U U U Début de cycle Read! Après lecture des entrées <Calculs> Après traitement Emit! Fin de cycle 28

29 Application Variable d entrée etat_0 Read? A:=1 etat_1 Variable A Read? Read? A:=0 Read? Read? B:=1 Variable B Read? Read? B:=0 Read? 29

30 Vérification de propriétés Principe Programme de contrôle Moniteur I E T S Propriétés il est toujours vrais que... pas de blocage. tel événement suit toujours celui-ci. Modélisation Formalisation Modèle de comportement (Automate à états) AG(APB AF ~horn) AG(~d1 AF ~lig) Logique temporelle (LTL, CTL, ) MODEL CHECKER Propriétés vérifiées ou diagnostic en cas d échec 30

31 Vérification de propriétés Vérification de propriétés Recherche dans l automate d états de chemins de circuits ayant des caractéristiques données. Expression des propriétés Logique temporelle Automate ayant un rôle d observateur 31

32 Logique CTL La logique CTL : une logique temporelle CTL : Logique temporelle utilisée pour énoncer formellement des propriétés. Logique temporelle Logique spécialisée dans les énoncés et raisonnements faisant intervenir la notion d'ordonnancement dans le temps. Formule CTL des propositions atomiques : a, b, des opérateurs booléens : des opérateurs temporels : EF, AF, AG, EG, E p U q, A p U q, EX, AX 32

33 Logique CTL La logique CTL, l'opérateur EF (1) EF a : " Il existe un chemin le long duquel il existe un état vérifiant a " E F a q q EF a 33

34 La logique CTL, l'opérateur EF (2) Analogie : Le métro parisien. Logique CTL Chaque station est un état. État initial : Bagneux. Comportement : Chemins possibles. Propriété à vérifier : EF cine_présent Il existe un chemin le long duquel il existe un état vérifiant «cine_présent» Existe t il un chemin depuis Bagneux qui me mène a un ciné présent prés de la station? Réponse : OUI. 34

35 Logique CTL La logique CTL, l'opérateur AF AF a : " Pour tout chemin, il existe un état vérifiant a " A F a q q AF a 35

36 Logique CTL La logique CTL, l'opérateur AG AG a : " le long de tous les chemins, tous les états vérifient a " A G a q q AG a 36

37 Logique CTL La logique CTL, l'opérateur EG EG a : " Il existe un chemin le long duquel tous les états vérifient a " E G a q q EG a 37

38 Logique CTL La logique CTL, l'opérateur E a U b E a U b : " Il existe un chemin où a est vrai jusqu'à ce que b soit vrai" E a U b a q b q E a U b 38

39 Logique CTL La logique CTL, l'opérateur A a U b A a U b : " Sur tous les chemins, a est vrai jusqu'à ce que b soit vrai" A a U b a q b q A a U b 39

40 Logique CTL La logique CTL, les opérateurs EX et AX EX a : " Il existe un chemin le long duquel le prochain état vérifie a " E X AX a : " Tous les prochains états vérifient a " A X a q r q r r EX a AX a EX a 40

41 La logique CTL, emboîtement d'opérateurs Logique CTL AG EF a : "Depuis tout état accessible, il est possible d'atteindre un état vérifiant a" AG EF a q q AG (EF a) 41

42 Logique CTL Egalités remarquables AGa AFa EF a EG a Il est toujours vrais que la propriété a est vérifiée EFa EGa AG a AF a Il n est pas possible d atteindre un état où la propriété a n est pas vérifiée 42

43 Logique CTL Correspondance CTL - UPPAAL CTL A E UPPAAL A E G [ ] F <> AG (p AF q) p --> q &&! imply and or not imply 43

44 Logique CTL Vérification à l aide d observateurs Dans le cas de propriétés complexes : traitant de simultanéité, ou découlant de plusieurs séquentialités, ou dépendantes du temps physique (horloge), ou difficile à exprimer. Utilisation d observateurs : Modification du modèle par : Ajout d un automate supplémentaire (automate observateur) représentant la propriété à vérifier. Read? Read? Automate «obs» Error A==5 Synchronisation de l observateur avec le modèle original. Vérification avec une propriété CTL utilisant l état de l observateur. AG (! obs.error) 44

45 Exemple de propriétés (1) P1 Lorsque l entrée B est présente, la sortie T doit être absente. Existe-t-il un état de l automate pour lequel : B est présent T est présent lorsque l API est en fin de cycle Combinaisons des variables A B A B S / --( )-+ S S T T / ----( )-+ Non, P1 est vérifiée. Logique CTL S T T S Début cycle API Lecture des entrées Initialisation Cycle API Exécution de la ligne 1 Exécution de la ligne 2 Ecriture des sorties Fin cycle API B A 45

46 Logique CTL Exemple de propriétés (2) Exercice : P1 «Lorsque l entrée B est présente, la sortie T doit être absente» Enoncer la propriété P1 dans le langage CTL. Vérifier la propriété P1 sur le modèle UPPAAL. 46

47 Exemple Gestion d un système de distribution d eau Constitution du système un réservoir deux circuits de pompage (L1,L2) (une pompe et deux vannes) une vanne de distribution générale une vanne de refoulement Règles de fonctionnement Les deux pompes ne doivent jamais fonctionner simultanément. En cas de panne de la pompe principale, la pompe de secours doit assurer la distribution. Permutation des circuits toutes les 24h Bf_valve L1_pump L1_down L2_down L2_pump L1_up L2_up Out_valve 47

48 Exemple Propriétés à vérifier pour ce système (1) Propriété n 1 Les 2 pompes ne doivent jamais fonctionner en même temps. Propriété n 2 Une panne générale provoque l'arrêt des pompes et la fermeture des vannes. Propriété n 3 Une panne d une pompe provoque l'arrêt de cette pompe et la fermeture des vannes associées. 48

49 Exemple Propriétés à vérifier pour ce système (2) Propriété n 4 En cas de panne de la pompe principale, la pompe de secours doit assurer la distribution. Propriété n 5 Dans le cas d'une demande de distribution "bas_debit" seule, la vanne refoulement doit être ouverte. Propriété n 6 La mise en route d'une pompe ne peut se faire qu'après avoir ouvert la vanne en amont pendant 5s. 49

50 Programme de commande Exemple Line_swap L1_prio Act_L1 L1_Prod L1_up L P / ( ) L ( ) L1_prio Act_L ( )---+ TON_L1 L1_Prod L1_pump RS_prio L IN TON Q ( ) #5sec- PT ET - L1_down Act_L1 RS L1_prio ( )----+ L S Q ( ) Act_L2 L2_Prod L2_up R1 L ( ) TON_L2 RS_L1 L2_Prod L2_pump L IN TON Q ( ) L1_prio L2_Prod RS L1_Prod #5sec- PT ET - L2_down L / -+- S Q ( ) ( )----+ L2_fail L1_Prod Out_valve H_flow L_flow L ( ) / / -+- R1 L2_Prod L1_fail SP_fail L1_pump H_flow Bf_valve L / ( ) L2_pump RS_L L1_prio RS L2_Prod VAR_INPUT L / S Q ( ) H_flow, L_flow, L1_fail : BOOL; L1_fail L2_fail, Line_swap, SP_fail : BOOL; END_VAR H_flow L_flow VAR_OUTPUT +-+- / / -+- R1 Bf_valve, L1_down : BOOL; L2_fail L1_pump, L1_up, L2_down : BOOL; L2_pump, L2_up, Out_valve : BOOL; SP_fail END_VAR VAR L1_Prod Act_L1, Act_L2, L1_prio : BOOL; L1_Prod, L2_Prod : BOOL; RS_prio, RS_L1, RS_L2 : RS; TON_L1, TON_L2 : TON END_VAR 50

51 Exemple Temporisation TON Calcul de in TON?!in t < 5 U U TON! Utilisation de Q inactive!in TON? Q:=0 TON? in en cours in && t >= 5 Q:=1 U écoulée 51

52 Traitement de cas Vérifier, sur le modèle de contrôle de distribution d eau donné, toutes les propriétés énoncées en langage naturel : Choix du type de vérification (propriété CTL seule ou avec un automate observateur), Expression de la propriété CTL et de l observateur le cas échéant. Expression de la propriété en langage UPPAAL, Association avec les variables du modèle, Vérification de la propriété formelle sur le modèle avec UPPAAL, Conclusion. 52