Propositions

Nous rappelons que cette thèse CIFRE intervient dans un contexte industriel. Notre objectif général est d’intégrer la vérification formelle dans un contexte SCADA et de faciliter son utili- sation par les concepteurs métiers. À la lumière de ces résultats, nous optons pour les solutions suivantes :

– L’utilisation des modèles métiers (DSL et langages de programmation) pour la spécifica- tion du système. Ces langages semi-formels sont maitrisés par les concepteurs et faciles

2.8. Conclusion et Discussions 59

à utiliser par ces derniers.

– La transformation automatique des modèles métiers en modèles formels supportés par des outils formels inspirés de concepts de l’ingénierie dirigée par les modèles.

– L’utilisation du Model-Checking pour la vérification. Le Model-Checking et l’obtention automatique des modèles formels permettront aux concepteurs métiers de procéder à des vérifications formelles des modèles métiers, sans être obligés de manipuler des formules mathématiques complexes. Nous souhaitons ainsi faciliter l’utilisation des méthodes for- melles dans l’industrie.

– La vérification des propriétés de sûreté, de vivacité et d’absence du blocage au niveau comportemental. Les propriétés de cohérence et de correction sont à vérifier au niveau structurel.

– L’objectif général de la vérification formelle est de vérifier des codes et des modèles de conception existants.

Les parties suivantes présentent les contributions méthodologiques et techniques de cette thèse. Ces contributions sont illustrées et détaillées dans les chapitres 3, 4, 5 et 6. Les chapitres 3 et 4, de la deuxième partie, portent sur l’intégration de la vérification formelle dans un flot de conception automatisé.

Le chapitre 3 présente une approche pour la vérification formelle du comportement des composants de conceptions standardisés. En effet, le comportement de ces composants a été modélisé par des automates temporisés déduits à partir des codes existants. Des propriétés de sûreté, de vivacité et d’absence de blocage sont écrites en CTL et vérifiées par le Model-

CheckerUPPAAL.

Dans le chapitre 4, nous présentons une approche pour la vérification formelle de l’archi- tecture structurelle d’un système sociotechnique. L’architecture en question a été modélisée par le langage Alloy et vérifiée automatiquement. Les modèles Alloy ont été déduits à partir d’un modèle métier normalisé, le P&ID.

Dans la troisième partie, qui comprend les chapitres 5 et 6, nous décrivons l’implémentation et la validation des deux approches. Dans le chapitre 5, les différentes transformations dévelop- pées pour la génération automatique des modèles formels sont détaillées et expliquées. Nous reportons ensuite, dans le chapitre 6, les évaluations de l’application de nos deux approches pour la vérification d’un cas d’étude industriel.

Deuxième partie

Approches de vérification formelle :

propositions méthodologiques

3

Vérification formelle d’une chaîne de

contrôle-commande élémentaire

Résumé : Ce chapitre présente la mise en œuvre de vérifications formelles sur une biblio- thèque d’éléments standards utilisés pour la conception des systèmes de contrôle-commande. La vérification de cette bibliothèque permettra de s’assurer que la conception des composants respecte les propriétés nécessaires. L’originalité des travaux porte sur la vérification conjointe de la chaîne de contrôle-commande complète des éléments standards. En utilisant l’IDM, le programme de commande et l’interface de supervision sont transformés automatiquement en automates temporisés. Le comportement de l’élément physique est modélisé manuellement par des automates temporisés. De même, le comportement de l’utilisateur face à l’interface de supervision, initialement capturé par des modèles de tâches, ensuite, est transformé automati- quement en automates temporisés. Les exigences que l’élément doit satisfaire sont écrites en CTL et vérifiées par Model-Checking (UPPAAL).

Sommaire 3.1 Introduction . . . 62 3.2 Exemple illustratif : V2VM . . . 62 3.2.1 Comportement de l’utilisateur . . . 63 3.2.2 L’interface de supervision . . . 63 3.2.3 Le programme de commande . . . 64 3.2.4 La partie opérative . . . 64 3.2.5 Les exigences de conception . . . 65 3.3 Contexte et travaux connexes . . . 65 3.3.1 Vérification formelle des programmes de commande . . . 65 3.3.2 Vérification formelle des interfaces de supervision . . . 66 3.3.3 Manques dans les travaux existants et problématique associée . . . 67 3.4 Vérification formelle d’une chaîne de contrôle-commande élémentaire . 67 3.4.1 Concepts utilisés . . . 68 3.4.2 Approche générale . . . 70 3.4.3 Formalisation d’une chaîne de contrôle-commande élémentaire . . 72 3.4.4 Vérification formelle d’une chaîne de contrôle-commande élémentaire 83 3.5 Conclusion . . . 83

3.1

Introduction

Dans le cadre de la génération automatique des programmes de commande et des interfaces de supervision, plusieurs auteurs s’appuient sur une bibliothèque de composants de concep- tion standardisés pour la spécification du système et la génération des applicatifs [Mouchard 2002,Lallican 2007, Bignon 2012, Bévan 2013]. Le système est conçu ainsi par agrégation de ces composants standardisés. Chaque composant se compose de vues représentant chacune une facette de la conception. Par exemple, la vue de supervision d’un composant correspond au composant logiciel permettant de le représenter sur l’IHM de supervision [Bignon 2012,

Goubali et al. 2014]. Cependant, une réutilisation efficace n’a d’intérêt que si les composants standardisés ont les qualités requises.

L’objectif des travaux présentés ici est de proposer une démarche de vérification formelle des composants standardisés en intégrant leur caractère multi-vues. Nous espérons garantir ainsi la qualité de la chaîne de contrôle-commande complète de chaque composant. Nous por- tons une attention particulière à la modélisation formelle des différentes vues et à la génération automatique des modèles formels à partir de ces vues du composant.

Dans les sections suivantes, nous présentons un exemple illustratif d’un composant stan- dard concret et constitué de plusieurs vues. Nous présentons ensuite, le contexte et les travaux connexes portants sur la vérification formelle des programmes de commande et des interfaces de supervision. Ensuite, nous présentons notre approche de vérification formelle de toute la chaîne de contrôle-commande. Nous terminons ce chapitre par une conclusion.

3.2

Exemple illustratif : V2VM

Nous appuyons nos travaux sur un composant standard des systèmes de gestion de fluide [Bi- gnon 2012]. Il s’agit d’une vanne deux voies motorisée notée V2VM (figure 3.1) dans la suite du chapitre.

V2VM est un composant essentiel et répandu des procédés industriels. Une vanne joue le rôle de sectionnement dans un réseau de tuyauterie, comme l’interrupteur dans un réseau électrique. La vanne peut être actionnée à distance et dispose de détecteurs de position (ouvert ou fermé). La vue de supervision associée à la vanne permet de la commander et d’en afficher l’état. La vue de commande est positionnée entre la supervision et la partie opérative. Elle interprète les requêtes issues de la supervision en ordre de commande permettant de manœuvrer la vanne en tenant compte de son état remonté par ses détecteurs de position.

Pour assurer la communication entre les différentes vues de la vanne, les concepteurs métiers utilisent un ensemble de variables booléennes. Ces dernières, présentées dans le ta- bleau 3.1, assurent l’échange d’informations entre l’utilisateur (opérateur), l’interface de su- pervision, le programme de commande et la partie opérative (système physique) de V2VM.

3.2. Exemple illustratif : V2VM 65

FIGURE3.1 – Les différentes vues de la V2VM

3.2.1 Comportement de l’utilisateur

L’opérateur est celui qui pilote la vanne. Il a pour rôle de la commander à distance. Il in- teragit avec l’interface de supervision à travers des objets graphiques (figure 3.1). L’opérateur peut commander l’ouverture ou la fermeture de la vanne. Il peut aussi surveiller l’état de la vanne. La vanne peut être affichée ouverte, fermée, en défaut matériel ou en défaut de com- mande. Dans le cas de défaut, des alarmes de défaut de commande et de défaut de matériel sont aussi affichées à l’utilisateur.

3.2.2 L’interface de supervision

L’IHM de V2VM se compose de trois zones (figure 3.1) : a) Etat de la vanne, b) Zone d’alarmes, c) Bandeau de commande. Le widget de la vanne est présenté suivant plusieurs états (figure 3.1 a). La vanne est ainsi affichée (Ouverte, Fermée, En défaut de commande, En dé- faut matériel) si les variables booléennes StO, StC, StFCmd, StFMat sont respectivement à 1. La zone d’alarmes (figure 3.1 b) affiche en temps réel les alarmes de Défaut de commande ou de Défaut de matérielsi les variables StFCmd et StFMat sont respectivement à 1. Si l’utilisa- teur clique sur le widget, le bandeau de commande, permettant à l’utilisateur de commander la

Variable Description

CtrlO = 1 Si l’opérateur demande l’ouverture de la vanne = 0 Si l’opérateur demande la fermeture de la vanne

StO Vanne ouverte

StC Vanne fermée

StFMat Vanne en défaut matériel

StFCmd Vanne en défaut de commande

CmdO Ordre d’ouverture vers la vanne physique

CmdC Ordre de fermeture vers la vanne physique

FdcO Fin de course ouverture (la vanne est physiquement ouverte)

FdcC Fin de course fermeture (la vanne est physiquement fermée)

Tableau 3.1 – Les différentes variables booléennes de la V2VM

vanne à distance, est affiché (figure 3.1 c). Il est composé de quatre boutons (Ouverture, Ferme- ture, Valider, Quitter). Les boutons Ouverture et Fermeture sont affichés de manière exclusive, l’un de l’autre.

3.2.3 Le programme de commande

Le programme de commande de V2VM est écrit en LD [IEC 2013] (figure 3.1) et s’exécute de manière cyclique. Il est constitué de plusieurs temporisateurs (2 TON et 2 TOF) et de deux blocs fonctionnels (RTRIG, FTRIG) [IEC 2013]. Lors de chaque cycle, il lit les entrées qui proviennent des capteurs de la vanne physique (FdcO, FdcC) et de la supervision (CtrlO). À partir de toutes ces informations, il calcule les sorties qui commandent l’ouverture (CmdO) ou la fermeture (CmdC) de la vanne. Il met également à jour les variables booléennes transmises à l’interface de supervision (StO, StC, StFCmd et StFMat), qui permettent l’animation du widget de la vanne dans l’interface de supervision.

3.2.4 La partie opérative

La partie opérative représente la vanne physique, ainsi que deux capteurs : le capteur de fin de course ouverture et le capteur de fin de course fermeture. Ces deux capteurs gèrent respectivement les variables booléennes FdcO et FdcC, pour indiquer respectivement l’état d’ouverture ou de fermeture de la vanne. Quand la vanne reçoit un ordre d’ouverture (CmdO=1) du programme de commande, elle commence à s’ouvrir. Quand elle atteint la position ouverte, le capteur fin de course ouverture met la variable FdcO à 1. Si elle reçoit un ordre de fermeture (CmdC=1), elle commence à se fermer et dès qu’elle atteint la position fermée, le capteur de fin de course fermeture met la variable FdcC à 1 et l’envoie au programme de commande pour indiquer la position fermée de la vanne.

3.3. Contexte et travaux connexes 67