Dans la mesure où, par son usage multiple, le paradigme CMMS-IAMS fait œuvre de « patron » en ingénierie, nous en avons revisité les fondements systémiques sans en développer sa représentation syntaxique.
En effet, le paradigme architectural CMMS rompt avec l’approche cartésienne courante consistant à spécifier séparément le sous-système de production, le sous-système de maintenance et le sous-système de gestion de l’information d’un sous-système technique. Chacun de ces éléments a pour finalité de contrôler la transformation dans la forme de l’objet finalisant, de la maintenir dans le temps et à travers l’espace. L’action de gestion organisatrice (Morin, 1980) a en plus pour rôle de réfléchir le comportement SYSTEME de l’ensemble à l’environnement. En ce sens, cette action de gestion complète la vision système courante en ingénierie système consistant à partitionner le SYSTEME d’intérêt en sous-système principal (« End Products ») et en sous-système de soutien (« Enabling Product »), sans expliciter comment ces deux parties sont reliées entre elles et à leur environnement commun.
Ainsi, l’organisation d’un SYSTEME selon le paradigme architectural CMMS lui permet de se contrôler, se maintenir et se relier à son environnement (Le Moigne, 1994), confirmant ainsi l’analogie système proposée par (Mayer, 1995) avec celle des travaux synthétisés en chapitre 3 autour du paradigme holonique. Cette
Partie 2 : Environnement de co-spécification exécutable basée sur des
modèles du système de conduite CISPI
Partie 2 – Page 71
vision holonique d’un SYSTEME est également à la base du concept architectural « Holonic Manufacturing System » (Valckenaers, Van Brussel, Bongaerts, & Wyns, 1997)et de ses variantes de « contrôle par le
produit »35 (G. Morel & Grabot, 2003).
En ce sens, nous intégrons les travaux de (Fliess & Join, 2013) relatifs à la commande sans modèle (CSM) pour spécifier le comportement « générique » d’un agent de conduite. De par sa formulation, la CSM permet de relier partiellement les sous-systèmes de production, gestion de l’information et maintenance, en adaptant le comportement du procédé à conduire aux variations mesurables de son environnement tout en fournissant une information relative à la détection d’une dérive de ce comportement à des fins de surveillance ou de gestion.
De plus, nos travaux revisitent le paradigme architectural du MFA, structurant les activités de conduite d’un agent technique ou humain selon le paradigme holonique. Ainsi, un agent-holon est spécifié à travers son rôle (Figure 56) de :
Commande en regard des services de conduite requis par sa part extérieure à laquelle il doit rendre compte,
Contrôle en regard des actions et observations établies avec sa part intérieure dont il doit aussi préserver l’intégrité pour assurer ces services.
Figure 56 : Patron architectural logico-fonctionnel CMMS-IAMS proposé
Partie 2 – Page 72
Notons que nous retrouvons cette structuration chez EDF au niveau des spécifications du contrôle-commande d’une centrale de production d’énergie électrique sous la forme de :
Diagrammes Fonctionnels Logiques (DFL) en tant que spécification des traitements logiques et
séquentiels, relatifs aux fonctions de commande.
Diagrammes Fonctionnels Analogiques (DFA) en tant que spécification des traitements analogiques et
des régulations, relatifs aux fonctions de contrôle.
Notre proposition de patron architectural système (Figure 56) précise également les activités composant le MFA en se focalisant d’avantage sur les rétroactions mise en œuvre au cours de la conduite, et en les généralisant à un système sociotechnique. Ainsi quel que soit le type d’agent, ce dernier est en mesure d’«
Acter » le service requis et de « Rendre–compte » à l’environnement des rétroactions de commande menées
pour effectuer la mission assignée. Ces rétroactions de commande supervisent des rétroactions de contrôle
visant à « Agir » et « Percevoir » pour maintenir le système dans un état donné en fonction de phénomènes
émergeants de façon générale, et pour satisfaire les rétroactions requises par la commande de façon plus spécifique.
Notons que cette intelligence distribuée (embarquée dans) sur des agents techniques ou humains en exploitation n’est qu’une partie implémentable des connaissances des domaines d’ingénierie spécialistes impliqués dans la co-spécification du SYSTEME de conduite, sous la forme de programmes, algorithmes,… d’un point de vue technique, ou sous la forme de procédures, de réglementations,… d’un point de vue humain. En
ce sens, ce patron architectural permet d’explorer le SYSTEME d’intérêt selon la triade « Communication,
Commande, Contrôle » du conceptagon. L’aspect communication se concrétise à travers trois types
d’interactions différentes qui dépendent de la nature des agents et du procédé en interactions (Bouffaron, Dupont, et al., 2014) :
Interaction Physico-Technologique : pour assurer l’interface entre le procédé et le niveau des automatismes. Elle comprend les actionneurs et les capteurs pouvant intégrer des traitements (IAMS)
et permettant de construire une représentation partielle (dans le monde de la logique) du procédé
(dans le monde de la physique) et restreinte aux performances des capteurs et du problème récurrent de leur localisation.
Interaction Physico-Physiologique : pour assurer l’interface entre la composante humaine du SYSTEME de conduite et le procédé. Les opérateurs interagissent directement avec les équipements du procédé (vannes, pompes, robinet, afficheur numérique, disjoncteur) à travers leur appareil musculo-squelettique pour actionner les équipements et leur appareil sensoriel pour observer les phénomènes, les traiter et remonter l’information concernant l’exploitation du procédé industriel (Galara, 2006). Nous étudions plus en détail cette interaction dans le chapitre 8 de notre mémoire.
Interaction Technico-Physiologique : pour assurer l’interface entre la composante technique et la composante humaine du SYSTEME de conduite, et peut être associée aux interfaces Homme-Machine aussi bien en salle de commande que sur le terrain.
La co-spécification holistique du SYSTEME de conduite implique de bien définir le contexte où le SYSTEME va évoluer et interagir avec les différents objets de contexte avant de décrire sa structure interne. Ainsi, une attention particulière doit être portée sur la modélisation des manifestations externes que le SYSTEME requis doit manifester dans son environnement. L’ensemble des phénomènes contenus dans une interaction peuvent changer dynamiquement son comportement, c’est pourquoi en cours de co-spécification il est important de considérer les interactions entre des éléments comme un objet à part entière (Ducroq, 1996). En ce sens, le
Partie 2 : Environnement de co-spécification exécutable basée sur des
modèles du système de conduite CISPI
Partie 2 – Page 73
patron proposé (Figure 56) vise à spécifier les éléments de cet objet-interaction entre un objet source et un objet puits. L’objectif étant de bien définir les propriétés physiques du flux de matière/énergie provenant de
l’objet source et propagé à travers l’interaction (pouvant être perturbés par son environnement (conditions
externes)) pour que l’objet puits puisse percevoir cette interaction. Cela permet de définir un premier niveau d’exigence pour les interfaces entre les agents techniques et/ou humains et le procédé.