Conception des systèmes de contrôle-commande : contexte industriel

Conception des systèmes de contrôle-commande : contexte industriel

Les systèmes de contrôle-commande

Un système de contrôle-commande permet le pilotage d’un procédé industriel physique au travers des fonctions de commande, de surveillance et de supervision (figure 1.1). La commande a un rôle opérationnel qui consiste à faire exécuter un ensemble d’opérations pour agir sur le procédé physique [Niel et Craye 2002]. La surveillance a un rôle informationnel qui porte sur le recueil des signaux provenant du procédé et de la commande, reconstituer l’état du système, dresser des historiques et le traitement de défaillance. La supervision a un rôle décisionnel qui permet d’optimiser, en présence ou non de défaillances, le fonctionnement du système. L’interaction du système de contrôle-commande avec le procédé physique est réalisée, d’une part, par des observations, à travers des capteurs et, d’autre part, par des actions réalisées par l’intermédiaire d’actionneurs [Cottet et Grolleau 2005] (figure 1.1). Les capteurs permettent de transformer les grandeurs physiques du procédé matériel en signaux électriques interprétables par le système de contrôle commande. Les actionneurs (moteurs, transformateurs…) permettent de transformer les commandes électriques du système de contrôle-commande, en ordres qui permettent d’agir sur le procédé physique en changeant son état.

L’architecture SCADA 

Les systèmes SCADA  ou télésurveillance et acquisition des données sont des systèmes de contrôle-commande qui se focalisent plutôt sur la supervision [Daneels et Salter 1999]. Un système SCADA est caractérisé par une architecture matérielle et une architecture logicielle. L’architecture matérielle d’un SCADA (figure 1.2) est généralement composée des stations clients, des serveurs de données, des Automates Programmables Industriels (API) et du système physique contrôlé. Les stations clients gèrent principalement l’interaction homme-machine. Les serveurs de données ont pour rôle la gestion et l’acquisition des données à partir des automates programmables. À partir des données des capteurs, les automates programmables agissent sur le procédé physique à travers les actionneurs.

L’architecture logicielle d’un système SCADA est composée des logiciels embarqués dans les différents composants de l’architecture physique. Le client SCADA est constitué d’une Interface Homme-Machine (IHM), généralement appelée « IHM de supervision » qui affiche toutes les informations liées aux états du système contrôlé et qui permet aux opérateurs de suivre l’état du système et de le contrôler à distance. Le client contient aussi un gestionnaire d’alarmes et de scripts (figure 1.2). Le serveur SCADA est le coordinateur entre l’IHM et les programmes de commande. Il est constitué d’un gestionnaire d’événements et intègrent plusieurs protocoles de communications tels que OPC, etc. Le gestionnaire d’événements se charge du transfert de données entre le client SCADA et les API. En effet, le gestionnaire d’événements assure, d’une part, l’acquisition des données provenant des API et, d’autre part, il permet de transformer les consignes des opérateurs sur l’IHM de supervision, en données interprétables qui sont ensuite envoyées aux programmes de commande. Les API englobent des programmes de commande écrits dans la norme IEC 61131-3 [IEC 2013] et s’exécutent d’une manière cyclique. Dans chaque cycle, les données provenant des serveurs de données et des capteurs du système physique sont capturées. À partir de ces données, le programme de commande calcule les sorties qu’il envoie, d’une part, aux actionneurs pour manipuler le système physique et, d’autre part, aux serveurs de données pour afficher l’état du système à l’utilisateur sur l’IHM de supervision.

Approches traditionnelles pour la conception des systèmes de contrôlecommande

La conception des systèmes SCADA porte sur la conception de l’architecture matérielle et également logicielle. La conception de l’architecture matérielle consiste à définir les composants constitutifs du système physique, les serveurs de données, les API et les outils SCADA à utiliser pour l’exploitation (exécution) des IHM de supervision. La conception de l’architecture logicielle porte sur deux axes : la conception des IHM de supervision et la conception des programmes de commande. Ces deux axes sont détaillés ci-après.

Conception des IHM de supervision

Les interfaces de supervision industrielles sont des systèmes interactifs, c.à.d. que l’utilisateur peut interagir avec le système à travers une IHM. La conception des systèmes interactifs repose sur la séparation entre la partie graphique et l’application [Aït-Ameur et al. 2005]. L’architecture d’un système interactif est généralement composée de trois modules : présentation, dialogue et application (figure 1.3).

La présentation est la partie graphique présentée à l’utilisateur. Elle est composée de plusieurs widgets (boutons, listes déroulantes, etc.) qui permettent à l’utilisateur d’interagir avec l’interface. Le dialogue ou le contrôleur de dialogue est le principal élément dans la conception des systèmes interactifs. Il joue le rôle de coordinateur entre la partie présentation et l’application. En effet, il permet d’invoquer les fonctions nécessaires pour accomplir une tâche demandée par l’utilisateur. Il permet aussi d’afficher l’état du système à l’utilisateur à travers des objets d’affichage. L’application regroupe toutes les données et fonctions qui permettent au système d’évoluer et d’accomplir les tâches demandées par l’utilisateur. Dans les systèmes SCADA, l’application est constituée de serveurs de données, de programmes de commande et du procédé physique. Dans la littérature, plusieurs approches ont été proposées pour, d’une part, intégrer l’utilisateur dans le processus de conception et, d’autre part, cadrer le processus de conception des systèmes interactifs [Kolski et al. 2001]. Parmi ces approches : le modèle en étoile, le modèle de Long et le modèle Nabla. Le modèle en étoile [Hartson et Hix 1989] propose un cycle de développement des systèmes interactifs sous forme d’étoile où l’évaluation est au centre du modèle. L’idée derrière ce modèle est de permettre à l’utilisateur d’évaluer toutes les étapes de développement. Bien que cette approche place l’utilisateur au centre de la conception, le cycle de vie proposé est en inadéquation avec les pratiques séquentielles de développement utilisées dans l’industrie. Le modèle de Long [Long et Denley 1990] utilise le même principe en ajoutant des étapes d’évaluation et des itérations à chaque étape du cycle de développement classique (séquentiel). Le modèle Nabla, proposé par Kolski [1995], intègre aussi l’utilisateur dans le cycle de développement, tout en différenciant la conception de l’interface de celle des modules d’aides. Pour concevoir un système interactif adapté, d’une part, aux besoins informationnels des utilisateurs et, d’autre part, aux besoins en mode de coopération utilisateur-module d’aide, le cycle de vie du modèle Nabla comporte un double cycle en V.

Table des matières

Introduction générale
I Contexte et état de l’art
1 Contexte et problématiques
1.1 Introduction
1.2 L’ingénierie système : contexte académique
1.2.1 La spécification des exigences
1.2.2 La vérification des exigences
1.3 Conception des systèmes de contrôle-commande : contexte industriel
1.3.1 Les systèmes de contrôle-commande
1.3.2 L’architecture SCADA
1.3.3 Approches traditionnelles pour la conception des systèmes de contrôlecommande
1.3.4 Génération automatique des programmes de contrôle-commande
1.4 Problématiques et verrous scientifiques
1.4.1 Problématiques
1.4.2 Verrous scientifiques
1.5 Conclusion
2 État de l’art : systematic mapping
2.1 Introduction
2.2 État de l’art au travers des revues de la littérature existante
2.2.1 Classification des langages formels
2.2.2 Comparaison des langages de spécification
2.2.3 Utilisation des méthodes formelles
2.2.4 Bilan sur les revues de la littérature existantes
2.3 Méthode
2.4 Étape 1 : Définition du protocole
2.4.1 Définition des questions de recherche
2.4.2 Stratégie de la recherche
2.4.3 Sélection des articles
2.4.4 Extraction des données et classification
2.4.5 Évaluation de la validité de l’étude
2.5 Étape 2 : Conduction
2.6 Étape 3 : Rapport de synthèse
2.6.1 Résultats démographiques
2.6.2 Proposition d’une classification des langages formels
2.7 Résultats obtenus
2.7.1 QR1 : Quels sont les langages de spécification utilisés pour la vérification formelle ?
2.7.2 QR2 : Comment a été réalisée la vérification formelle ?
2.7.3 QR3 : Quels sont les objectifs de la vérification formelle ?
2.8 Conclusion et Discussions
2.8.1 Bilan
2.8.2 Propositions
II Approches de vérification formelle : propositions méthodologiques
3 Vérification formelle d’une chaîne de contrôle-commande élémentaire
3.1 Introduction
3.2 Exemple illustratif : V2VM
3.2.1 Comportement de l’utilisateur
3.2.2 L’interface de supervision
3.2.3 Le programme de commande
3.2.4 La partie opérative
3.2.5 Les exigences de conception
3.3 Contexte et travaux connexes
3.3.1 Vérification formelle des programmes de commande
3.3.2 Vérification formelle des interfaces de supervision
3.3.3 Manques dans les travaux existants et problématique associée
3.4 Vérification formelle d’une chaîne de contrôle-commande élémentaire
3.4.1 Concepts utilisés
3.4.2 Approche générale
3.4.3 Formalisation d’une chaîne de contrôle-commande élémentaire
3.4.4 Vérification formelle d’une chaîne de contrôle-commande élémentaire
3.5 Conclusion
4 Vérification formelle des modèles de conception (P&ID)
4.1 Introduction
4.2 Exemple illustratif : P&ID
4.3 Contexte et travaux connexes
4.3.1 Vérification des P&IDs
4.3.2 Les architectures logicielles
4.4 Approche proposée
4.4.1 Concepts utilisés
4.4.2 Vérification formelle des diagrammes P&ID
4.4.3 Un style architectural pour la norme ANSI/ISA-5.1
4.4.4 Génération des modèles Alloy à partir des P&ID
4.4.5 Formalisation des exigences et vérification formelles des P&ID
4.4.6 Aide à l’analyse des résultats
4.5 Conclusion
III Approches de vérification formelle : mise en œuvre et applications
5 Implémentation
5.1 Introduction
5.2 Méthodologie mise en œuvre
5.2.1 Concepts IDM utilisés
5.2.2 Outils et langages utilisés
5.3 Flot de vérification des composants standards
5.3.1 Opération de modélisation de la tâche utilisateur
5.3.2 Opération de transformation de HAMSTERS en AT intermédiaire (AT’)
5.3.3 Opération de transformation des IHM SCADA en AT’
5.3.4 Opération de transformation des programmes LD en AT’
5.3.5 Opération de transformation de AT’ en AT
5.3.6 Opération de modélisation du composant physique en AT
5.3.7 Opération de spécification des exigences en CTL
5.3.8 Opération de vérification formelle
5.3.9 Bilan
5.4 Flot de vérification formelle des diagrammes P&ID
5.4.1 Opération de formalisation de la norme ANSI/ISA-5.1
5.4.2 Opération de construction
5.4.3 Opération de spécification des exigences
5.4.4 Opération d’épuration
5.4.5 Opération de transformation de P&ID en Alloy
5.4.6 Opération de vérification
5.4.7 Opération de visualisation des erreurs
5.4.8 Opération de correction
5.4.9 Bilan
5.5 Conclusion
6 Application à des cas industriels
6.1 Introduction
6.2 Vérification formelle de V2VM : Étude de cas
6.2.1 Opération de modélisation de la tâche utilisateur
6.2.2 Opération de transformation de HAMSTERS en AT
6.2.3 Opération de transformation des IHM SCADA en AT
6.2.4 Opération de transformation des programmes LD en AT
6.2.5 Opération de modélisation du composant physique en AT
6.2.6 Opération de spécification des exigences en CTL
6.2.7 Vérification formelle de V2VM
6.2.8 Validité
6.2.9 Bilan de la vérification formelle de la V2VM
6.3 Vérification formelle du P&ID du système EdS : Etude de cas
6.3.1 Opération de construction
6.3.2 Opération de spécification des exigences
6.3.3 Opération d’épuration et de transformation du P&ID en Alloy
6.3.4 Opération de vérification
6.3.5 Opération de visualisation des erreurs
6.3.6 Validité
6.3.7 Bilan de la vérification formelle du P&ID du système EdS
6.4 Conclusion
7 Conclusion

Télécharger le rapport complet