Un exemple de P&ID est présenté dans la figure 4.1.
FIGURE4.1 – Exemple de diagramme P&ID
Le P&ID est le diagramme normalisé qui schématise tous les composants et les connexions d’un procédé industriel. C’est une description abstraite de l’architecture physique du procédé. Chaque composant (exemple : St3, V2VM01 et V2VM02 sur la figure 4.1) est représenté par un symbole définit dans la norme ANSI/ISA-5.1 [ISA 1992]. Ces composants sont reliés par des connecteurs logiciels (liens avec des cercles sur la figure 4.1) et des matériels comme les tuyaux (P-1, P-2 sur la figure 4.1) et les câbles (lien simples sur la figure 4.1) [Bignon et al. 2013]. Les données échangées entre le système physique et le programme de commande (les instrumentations) sont aussi représentées dans ce diagramme.
De nos jours, les concepteurs de systèmes de contrôle-commande suivent des méthodes manuelles et informelles pour décrire l’architecture des systèmes étudiés. La diversité de ces
4.3. Contexte et travaux connexes 89
concepteurs engendre souvent une mauvaise interprétation des spécifications et des problèmes de communication qui se traduisent par des erreurs dans les modèles d’architecture (phase de conception) [Selby et Selby 2007]. L’utilisation de ces modèles d’architecture pour la généra- tion des applicatifs dans une approche descendante ou mixte peut engendrer la propagation de ces erreurs sur les modèles détaillés et les applicatifs. La majorité de ces erreurs sont détectées tardivement dans les phases de tests [Pham 2007], ce qui augmente les coûts de re-conception et correction. Des étapes de vérification doivent être intégrées au niveau des modèles d’archi- tectures, i.e. avant la génération automatique des applicatifs, afin de limiter les erreurs et les coûts de re-conception.
Malgré les efforts de standardisation des diagrammes P&ID par la norme ANSI/ISA-5.1, il n’existe pas une description formelle pour ces diagrammes qui permettrait une vérification automatique. Il est démontré que la vérification au niveau architectural permet de réduire signi- ficativement les coûts et les erreurs de conception [Medvidovic et Taylor 2000]. Nous présen- tons dans ce chapitre, une solution logicielle pour la formalisation et la vérification formelle des diagrammes P&ID.
Dans les sections suivantes, nous présentons l’état des travaux sur la vérification formelle des P&ID, y compris les techniques de modélisation et d’analyse, appliquées aux architectures logicielles. Nous nous inspirons de ces techniques pour proposer une approche automatisée pour la vérification des architectures modélisées sous forme de diagrammes P&ID. Nous uti- lisons le langage formel Alloy pour la spécification d’un style architectural pour la norme ANSI/ISA-5.1. Ensuite, nous générons automatiquement des modèles Alloy à partir des dia- grammes P&ID. Nous utilisons les fonctionnalités offertes par l’outil d’Alloy afin de vérifier la compatibilité, la cohérence, la complétude et l’exactitude des diagrammes P&ID.
4.3
Contexte et travaux connexes
4.3.1 Vérification des P&IDs
Peu de travaux se sont intéressés à la vérification formelle des P&ID. Parmi eux, Yang et al. [2001] proposent une approche semi-automatique pour construire des modèles SMV à partir des diagrammes CDEP et P&ID. Ces modèles sont utilisés pour vérifier des propriétés de sûreté écrites en CTL et vérifiées par Model-Checking. [Krause et al. 2012] proposent une méthode pour extraire, à partir des diagrammes P&ID, des données de sûreté et de fiabilité pour des systèmes industriels. Ces données sont extraites sous forme de deux graphes : Netgraph et le graphe de fiabilité. Le NetGraph représente toutes les données liées aux composants et leurs connexions (structures). Par contre, le graphe de fiabilité représente les données sur la fiabilité de ces composants. Les deux graphes sont ensuite utilisés pour vérifier la fiabilité des systèmes. Les travaux cités ci-dessus supposent que la structure architecturale soit correcte, avant d’initier la vérification formelle de la fiabilité et de la sûreté. La solution de vérification formelle proposée dans ce chapitre se place dans les phases en amont de ces travaux. En effet, nous
traitons la vérification formelle des diagrammes P&ID au niveau structurel, en nous appuyant sur la modélisation et la vérification formelle des architectures logicielles.
4.3.2 Les architectures logicielles
L’architecture est généralement spécifiée comme une configuration (topologie) d’un en- semble de composants et de connecteurs. Les composants représentent les unités de calcul ou de stockage de données dans le système. Ils sont caractérisés par un type, un ensemble d’interfaces pour leurs interactions avec l’environnement, une sémantique (comportement), un ensemble de contraintes, une évolution et des propriétés non-fonctionnelles [Medvidovic et Taylor 2000]. Les connecteurs (appels de fonction, protocole de communication, canalisa- tion...) assurent l’interaction entre les composants. Comme les composants, les connecteurs sont également caractérisés par un type, un ensemble d’interfaces, une sémantique, une évolu- tion, des contraintes et des propriétés non-fonctionnelles [Medvidovic et Taylor 2000]. L’archi- tecture peut être décrite selon plusieurs points de vue : structurel, comportemental, physique, etc. [Oquendo 2004]. Du point de vue structurel, l’architecture est décrite par l’agencement structurel des différents composants et connecteurs constituant le système. Du point de vue comportemental, l’architecture peut être décrite par le comportement de ses connecteurs, ses composants et la façon dont ils interagissent, les actions que le système effectue et les relations entre ces actions [Oquendo 2004]. Le point de vue physique capture les composants physiques et leurs interactions à travers des connecteurs physiques.
Plusieurs langages formels ou semi-formels, appelés ADL2, ou langages de description d’architecture en français, sont utilisés pour décrire les architectures logicielles. Wright [Al- len 1997], par exemple, est un ADL basé sur l’algèbre de processus CSP. Π-ADL [Oquendo 2004] est basé sur le langage Π-calculus et permet la description des architectures mobiles. ACME [Garlan et al. 2010] est l’ADL de base soutenant l’échange de descriptions d’architec- tures.
Tous les ADL cités ci-dessus sont indépendants du domaine. En complément de ces ADL, d’autres ADLs spécifiques à un domaine existent, tels que, EAST-ADL [Debruyne et al. 2005] pour l’automobile embarquée. En ce sens, ANSI/ISA-5.1 pour la description des P&ID est un ADL spécifique aux procédés industriels. Cependant, les diagrammes P&ID avec ANSI/ISA- 5.1 manquent de définition formelle, comme EAST-ADL.
Nous proposons, dans les sections suivantes, une description formelle de la norme ANSI/ISA- 5.1 à travers la définition d’un style architectural. Ce style architectural fournit un vocabulaire de représentation commun et des règles pour les architectures décrites en termes de P&ID [Tay- lor et al. 2009]. Le style est ensuite utilisé pour vérifier plusieurs propriétés sur les diagrammes P&ID.