Leçon 4: Pilotage du procédé: entre MES et SCADA, où placer la frontière?

Nous l’avons noté dès l’émission d’introduction de cette série consacrée au MES, les premiers projets de MES étaient surtout destinés à faciliter le traitement des opérations manuelles en raison de leur complexité ou pour des raisons de suivi réglementaire. Mais ils se sont étendus bien au-delà, et en particulier dans des installations automatisées. 

Dans ce type d’installation, le logiciel de référence est le superviseur, SCADA en langue anglaise, situé juste au-dessus des automatismes et partie intégrante avec eux de ce que l’on appelle le contrôle-commande.

Paradoxalement, nous avons vu que les industriels se préoccupent beaucoup du lien entre ERP et MES, qui même s’il soit être convenablement étudié, ne pose pas vraiment de problème technique et peut s’appuyer sur les travaux de l’ISA-95 pour l’interface. Le lien entre SCADA et MES lui, est très rarement évoqué, alors que nous allons voir qu’il ne va pas de soi.

Le terme SCADA, signifiant Supervisory Control And Data Acquisition, soulève déjà à lui seul le problème : le SCADA serait déjà chargé de l’acquisition de données, une des fonctions identifiées par l’ISA-95 comme étant une des fonctions essentielles du MES. 

Alors essayons d’y voir un peu clair…

Pour essayer de mieux comprendre les positionnements respectifs du SCADA et du MES, revenons à la hiérarchie classique des systèmes automatisés, ce que l’on appelle souvent la « pyramide du CIM ».

A l’origine, cette pyramide distingue 4 niveaux :

• Le niveau 0, niveaux des capteurs et des actionneurs
• Le niveau 1, niveau des automatismes
• Le niveau 2, qui traite de la localisation des produits, des mouvements physiques et de la gestion des lots
• Le niveau 3, qui gère les produits et les stocks, ainsi que les clients, commandes et factures

Ni le SCADA ni le MES n’apparaissent dans cette pyramide du CIM, les superviseurs étant encore embryonnaires à l’origine du concept de CIM, sans parler du MES bien sûr, terme qui n’apparaitra que dans les années 90.

Les SCADA apparaissant vers le haut des automatismes, il était tentant d’introduire un niveau supplémentaire, ce qui donne la pyramide suivante, qui est aujourd’hui la plus souvent représentée. Dans cette pyramide, le niveau 2 est occupé par le SCADA, le niveau 3 est occupé par le MES, et le niveau 4 par l’ERP, ce qui est cohérent avec la hiérarchisation ISA- 95.

Pourtant cette représentation pose un problème, car elle suppose implicitement que chaque niveau échange des informations uniquement avec les niveaux immédiatement au-dessus ou au-dessous de lui.

Cette hypothèse est à la fois dictée historiquement par une analogie avec les structures managériales traditionnelles et l’existence de types de communication matérielle très différents à chaque niveau. Dans les années quatre-vingt, les réseaux de capteurs, les réseaux automates, et les réseaux informatiques étaient de types très différents, incapables de cohabiter sur le même support physique.

Aujourd’hui, Ethernet et TCP/IP se sont imposés comme couche universelle de base de la plupart des réseaux, qu’il s’agisse de réseaux de capteurs et d’actionneurs, d’automates ou de systèmes informatiques, sans oublier la connexion à l’internet mondial. Sans aller jusqu’à prétendre que la pyramide du CIM a éclaté, le moins que l’on puisse dire est que cette représentation s’impose beaucoup moins naturellement qu’à cette époque.

Mais comme cette représentation perdure, elle parvient à véhiculer subrepticement un découpage qui ne correspond ni à une contrainte technique, ni même à une réalité sur le terrain ! C’est ce que j’ai eu l’occasion d’appeler « le secret des pyramides ».

En effet voyons ce qu’il en est sur le terrain.

Pour comprendre exhaustivement la réalité du terrain, il faut prendre conscience d’un autre présupposé de la pyramide du CIM : emportés par leur élan vers une automatisation complète des installations industrielles, les concepteurs du CIM ne font aucunement apparaître les opérations manuelles, pourtant nombreuses voire prépondérantes suivant le type d’industrie. Le SCADA apparaît comme logiciel incontournable au- dessus des automatismes, qui eux-mêmes pilotent capteurs et actionneurs.

Les automates et les logiciels SCADA n’ont pas été spécialement conçus pour la gestion des opérations manuelles. Mais faute de mieux, les industriels ont longtemps considéré qu’un SCADA était nécessaire pour réaliser des Interfaces Homme-Machine (IHM), alors que cette fonction n’appartient en propre à aucun logiciel.

Il n’est pas rare également que l’on interface sans autre complément logiciel d’autres périphériques dits de traçabilité, comme les imprimantes et les lecteurs CAB, soit directement avec le SCADA soit au travers des automatismes. Parfois même, on a envisagé un échange spécifique avec l’ERP.

Dans la pratique donc, lors de l’arrivée des logiciels de MES, ceux-ci ont pris en compte directement, généralement par des interfaces de saisie, les opérations manuelles, et de l’autre côté l’interface avec l’ERP. Pour faciliter la collecte d’information et la traçabilité, les lecteurs codes à barre et imprimantes d’étiquettes sont gérés par le logiciel MES soit directement, soit par l’intermédiaire des automates, mais pratiquement jamais au travers du logiciel de supervision.

Présenter le SCADA comme un étage entre le terrain et le MES par l’intermédiaire des automatismes ne correspond donc que très rarement à une réalité. Dans la pratique, supervision et MES suivent des vies totalement parallèles.

Les outils sont, de plus, souvent attachés à des cultures différentes : les développements de supervision reflètent une vision « automatismes » de la production, très orientée « bits et mots », c’est à dire « entrées/sorties élémentaires », alors que les développements de MES en reflètent une vision « opérationnelle », plus structurée et généralement plus « informatique ». De ce fait, aucun échange structuré n’a réellement été défini entre SCADA et MES, et il est plus simple pour les logiciels de MES de collecter les données à la source.

Le diagramme fonctionnel de l’ISA-95 met aussi en évidence que le MES travaille à quelques exceptions spécifiques près sur les mêmes échelles de temps que le SCADA.

Ce schéma rend compte d’une beaucoup plus grande confusion des rôles entre SCADA et MES que ne le laisse présager la représentation pyramidale, et qui explique pour une bonne part les questions que les industriels peuvent se poser sur le rôle de chacun de ces logiciels.

La seule voie raisonnable pour déterminer la frontière entre SCADA et MES est donc d’ordre fonctionnel. En l’absence de MES, les logiciels SCADA ont en effet

« occupé le terrain ». Disposant presque tous d’un langage de script permettant d’accéder à des bases de données, ils permettent de développer en spécifique des fonctions appartenant logiquement au MES. Evidemment ces développements spécifiques sont difficiles à mettre au point et à maintenir, et généralement éloignés par les contraintes du logiciel des bonnes pratiques de l’ISA-95.

Quand un MES est installé, le logiciel SCADA doit donc être centré sur ses fonctions premières : l’acquisition des données de contrôle-commande, l’affichage de synoptiques animés qui informent en temps réel de l’état de l’installation, la gestion des alarmes, et ce que l’on appelle les recettes de supervision, c’est à dire l’envoi à l’automate de listes de consignes pour l’exécution d’une opération automatisée.

De son côté, le MES gérera l’acquisition de données de production, la planification détaillée ou ordonnancement, la gestion des ressources, le lancement et le suivi des OF et des lots, ainsi que l’analyse de performance (en particulier le TRS).

Un arbitrage devra être réalisé pour l’acquisition des données et une partie du contrôle des opérations qui sont en doublon entre les deux blocs logiciels, dont les écrans seront présentés chacun de leur côté aux mêmes opérateurs. Si l’automatisation est locale, pour des fabrications en ilots de production par exemple, cet arbitrage sera relativement aisé, le MES sera essentiellement centré sur les opérations manuelles et le suivi d’avancement des opérations de chaque ilot au sein d’un ordre de fabrication, et sur l’analyse de la performance d’ensemble. Toutes ces fonctions impliquent relativement peu de liens avec le terrain.

Pour des process continus ou semi-continus, ou des process automatisés en unités de production complètes, une grande partie des informations nécessaires au suivi des opérations sont en réalité présentes soit au sein des automatismes, soit au sein du SCADA, nécessitant un flux d’échange d’informations important dont la structure reste complètement à définir. Des logiciels complémentaires d’enregistrement des données – les historians – peuvent aider le MES dans la collecte de ces informations.
L’ISA-95 n’aborde pas cette question. L’ISA-88, centrée sur les procédés semi-continus, apporte une réponse par la standardisation des échanges avec l’automate pour la commande des opérations, mise en œuvre dans ce que l’on appelle les moteurs batch, qui ont implémenté avant la lettre la plupart des fonctions de MES, à l’exception de l’analyse de performance.

Si de tels logiciels ne sont pas présents, on se trouve dans la nécessité de réaliser tout le séquencement des opérations au niveau des automatismes. Cela nuit à la flexibilité (car l’exécution est en quelque sorte figée dans l’automate) et rend difficile une traçabilité fine des opérations (car pour cela il faut prévoir des remontées spécifiques d’informations de l’automate vers le MES au niveau de chaque étape, et il n’y a rien dans le SCADA qui faciliterait ce travail).

Ce n’est sans doute pas un hasard si le MES est alors souvent cantonné à l’analyse de performance, et en particulier au suivi du TRS.

Des écrans s’adressant aux mêmes opérateurs, des informations acquises auprès des mêmes périphériques, des cycles de traitement relativement proches et des fonctions en redondance… on peut légitimement se demander si l’on n’aurait pas intérêt à envisager de regrouper SCADA et MES au sein d’une même plateforme.

De telles solutions existent, et voici quelle est leur structure, avec le même environnement que précédemment.

On voit que l’architecture est beaucoup plus simple. La plateforme logicielle SCADA/MES (qui pourra éventuellement être modulaire pour répondre au plus près des besoins de chaque industriel) est connectée aux automates et aux différents périphériques. Elle propose des fonctions unifiées d’IHM.
Cette structure est plus exigeante quant aux performances de la plateforme, puisque celle-ci devra assurer des temps de réponse qui sont ceux de la supervision, même si des contraintes moindres auraient pu être exigées de la partie MES. En revanche, outre sa clarté, elle amène des avantages tangibles :

• Unicité de l’interface logicielle avec les opérateurs
• Simplification du déploiement (un seul logiciel à déployer)
• Suppression des interfaces redondantes avec les automatismes et la périphérie
• Centralisation et intégrité des données de l’application industrielle
• Simplification des évolutions de l’installation, qui n’ont pas à être reportées dans deux logiciels différents

Je vous propose de résumer ce que nous avons vu aujourd’hui sur le thème de la frontière entre SCADA et MES.

Tout d’abord, nous avons vu pourquoi la pyramide du CIM supposait un dialogue naturel entre supervision et MES.

Puis en examinant plus attentivement la réalité du terrain, nous avons vu que la situation était plus complexe, et que SCADA et MES vivaient souvent des vies parallèles, voire concurrentes.

Pour éviter des développements en double, ou des difficultés opérationnelles, il faut particulièrement soigner la répartition fonctionnelle, et on aura parfois besoin de logiciels complémentaires.

Enfin nous avons vu qu’il existait des plateformes communes SCADA & MES, susceptibles de faciliter l’architecture et la mise en place des fonctions pour les process continus et semi-continus, ainsi que les process automatisés de manière globale.