Ag 3510

Architectures de pilotage
de procédés industriels
par Pascal BERRUET
Maître de Conférences à l’Université de Bretagne Sud
Jean-François PETIN
Maître de Conférences au Centre de recherche en automatique de Nancy CRAN-UMR 7039
Nancy Université, CNRS
Fabien RIGAUD
Ingénieur commercial – ARC Informatique
Armand TOGUYENI
Professeur des Universités à l’École Centrale de Lille (EC Lille)
et Éric ZAMAÏ
Maître de Conférences HDR à l’Institut National Polytechnique de Grenoble
1. Architectures de contrôle et de commande..................................... AG 3 510 - 3

1.1 Équipements d’acquisition et de traitement ............................................. — 3
1.2 Réseaux informatiques ............................................................................... — 3
1.3 IHM................................................................................................................ — 3
1.4 Architectures de conduite ........................................................................... — 3
1.4.1 Architecture monoposte..................................................................... — 3
1.4.2 Architecture multiposte en parallèle ................................................. — 4
1.4.3 Architecture client-serveur................................................................. — 4
1.4.4 Architecture client-serveurs multiples .............................................. — 5
1.4.5 Architecture clients banalisés via WTS ............................................. — 5
1.4.6 Architecture clients Web banalisés.................................................... — 5
2. Système de pilotage de la production MES ..................................... — 6
2.1 Définition et objectifs d’un MES................................................................. — 6
2.2 Fonctions du MES........................................................................................ — 7
2.3 Flux d’informations ..................................................................................... — 8
2.4 Architectures d’intégration ......................................................................... — 9
3. Réactivité face à des pannes ................................................................ — 10
3.1 Commande................................................................................................... — 11
3.2 Surveillance.................................................................................................. — 11
3.3 Supervision .................................................................................................. — 11
3.4 Organisation des modules.......................................................................... — 11
3.5 Terminologie surveillance, supervision, commande................................ — 11
3.5.1 Fonctions de la surveillance [17] ....................................................... — 11
3.5.2 Fonctions de la supervision ............................................................... — 11
3.5.3 Fonctions de la commande................................................................ — 12
3.5.4 Récapitulatif des fonctions................................................................. — 12
4. Processus de reconfiguration............................................................... — 12
4.1 Définition ...................................................................................................... — 12
4.2 Contexte de la reconfiguration ................................................................... — 12
4.3 Mise en œuvre du processus de reconfiguration au niveau
de la commande .......................................................................................... — 13
4.3.1 Étape décisionnelle............................................................................. — 13
4.3.2 Étape opérationnelle .......................................................................... — 14
5. Conclusion ................................................................................................. — 16
Références bibliographiques ......................................................................... — 19
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. − © Editions T.I. AG 3 510 − 1
Dossier délivré pour

DOCUMENTATION
03/10/2008
ARCHITECTURES DE PILOTAGE DE PROCÉDÉS INDUSTRIELS ____________________________________________________________________________________
epuis ces trente dernières années, le souci principal des industriels s’est
D porté sur une automatisation à outrance des procédés industriels afin
d’améliorer sans cesse la performance de l’outil de production. Tirant parti des
progrès technologiques dans le domaine de la communication, des
automatismes industriels (interfaces ou services Web embarqués dans les auto-
mates programmables industriels) ou encore dans les domaines de l’électroni-
que et de l’informatique (RFID, réseaux de capteurs, composants logiciels
embarqués...), ces systèmes automatisés intègrent aujourd’hui une part de plus
en plus importante de technologies de l’information et de la communication
distribuées au cœur même des processus de production et des produits. Mais
cette automatisation a un prix, celui de la complexité du système de pilotage
tant sur le plan des éléments matériels hétérogènes (calculateurs dédiés,
réseaux de communication, chaînes d’actions et de captage...) qui le compose
que sur celui des fonctions logicielles (ordonnancement, commande, suivi,
diagnostic, reconfiguration, supervision...) qu’il abrite. Aussi, le besoin de
méthodes, ou au moins de retours d’expertises, permettant de mettre en
relation l’ensemble de ces éléments afin qu’ils contribuent encore à améliorer
les performances des entreprises devient prépondérant.
Afin de répondre à un tel besoin d’intégration de ces composants industriels,
le concept d’architecture de pilotage a été proposé.
Aussi, dans ce dossier, le lecteur découvre dans une première partie une
analyse de la nature même des architectures de contrôle et de commande de
procédés industriels. La deuxième partie décrit quant à elle les différentes
fonctions qui interviennent au cœur de ces architectures afin de contribuer au
processus global de pilotage temps réel. La troisième partie se focalise sur une
des facettes de ce processus de pilotage à savoir sa capacité à réagir aux aléas
de fonctionnement. Enfin, la quatrième partie donne un aperçu des approches
à ce jour proposées pour donner au processus de pilotage des capacités à
reconfigurer toute ou une partie de l’architecture physique et logicielle de
pilotage.
(0)
Sigle Développé Sigle Développé
AMR Advance Manufacturing Research OPC OLE (Object linking and Embedding) for Process
Control
B2B Business to Business
PID Proportionnel Intégral Dérivé
B2MML Business to Manufacturing Markup Language RDC Remote Desktop Connection
CIM Computer Integrated Manufacturing RdP Réseau de Petri
CPV Central Process Unit RTC Réseau téléphonique commuté
Customer Relationship Management SCADA Supervisory Control and Data Acquisition

CRM
SCM Supply Chain Management
EAI Enterprise Application Integration
SFP Systèmes flexibles de production
ERP Enterprise Resource Planning
SIL Software Integration Level
IHM Interface Homme-Machine
TOR Tout ou rien
MES Manufacturing Execution System
UML Unified Modeling Language
MESA MES Association WSDL Web Services Description Language
MRPII Manufacturing Resources Planning II WTS Windows Terminal Serveur
OAGIS BOD Open Application Group Integration Specification, XML SOAP eXtended Markup Language Simple Object Access
Business Objects Definition Protocol

AG 3 510 − 2 est strictement interdite. − © Editions T.I.

DOCUMENTATION
03/10/2008
___________________________________________________________________________________ ARCHITECTURES DE PILOTAGE DE PROCÉDÉS INDUSTRIELS
1. Architectures de contrôle de pesée dialoguant sur InterBus-S...). Ces informations sont

ensuite traitées cycliquement et séquentiellement par la partie
et de commande intelligente de l’automate (CPU) et mises à disposition dans une
table d’échange.
Le traitement, basé généralement sur un langage compatible
Piloter un processus automatisé, surveiller une gestion avec la norme IEC 61131-3 (Grafeet, Iadder... [22]), sera par exemple
technique centralisée, contrôler une ventilation de tunnel, un PID pour assurer la régulation de température d’un four, ou plus
superviser une détection incendie, voilà de nombreux cas parmi simplement une action directe sur un organe de conduite (démar-
tant d’autres où il est nécessaire de définir quelle architecture de rage moteur, pompe...). Les informations remontées dans notre
contrôle/commande [14] il est nécessaire de mettre en place. exemple seront donc la température du four ou l’état du moteur et
de la pompe (on/off). C’est ensuite la partie coupleur de communi-
cation de l’automate qui va jouer l’interface avec le réseau infor-
Mais tout d’abord faut-il définir ce que l’on entend par architec- matique pour faire circuler l’information vers les interfaces de
ture de contrôle/commande. Nous décrivons dans un premier conduites (superviseur, Panel PC...).
temps la partie automate ou plus généralement l’équipement qui
fait l’acquisition des informations terrains (vitesse d’un moteur,
position d’une vanne, état d’un ventilateur...) pour ensuite apporter 1.2 Réseaux informatiques
quelques précisions sur le réseau informatique permettant de faire
circuler l’information depuis l’automate jusqu’à un ou des PC. Il y a encore cinq ans nous aurions listé dans ce paragraphe de
Nous parlons ensuite de cette partie IHM (Interfaces Homme- nombreux types de réseaux informatiques permettant de
Machine) permettant d’afficher l’information, de l’enregistrer, de la connecter les équipements d’acquisition aux interfaces de
diffuser, de la traiter... Cette brève description de l’environnement conduite. L’arrivée au niveau industriel du réseau Ethernet TCP/IP
nous permet ensuite de dresser le portrait des architectures de est venue simplifier grandement la définition de ce paragraphe !
contrôle/commande que l’on retrouve dans l’industrie. En effet, ce réseau a fait son arrivée massive dans le monde indus-
Toute la difficulté lors de la conception d’un système de triel pour plusieurs raisons, entre autres le coût hardware du point
contrôle/commande est de choisir la bonne architecture permettant de connexion, la fiabilité et la disponibilité des matériels, la bana-
de respecter les multiples contraintes imposées par l’installation. lisation dans les PC standards de la connectique Ethernet...
Parmi les contraintes « habituelles », nous pouvons lister de façon La plupart des installations sont donc maintenant réalisées avec
non exhaustive : ce type de réseau, mixant éventuellement les protocoles couche 7
— les contraintes budgétaires ; du modèle ISO suivant les constructeurs d’automates [S 7 574].
— les contraintes d’exploitations (combien d’opérateurs pilotent
l’installation, de quel endroit, 24 h/ 24 h ou avec des phases
d’arrêts...) ; 1.3 IHM
— les contraintes fonctionnelles (tel traitement sécuritaire possi-
ble avec tel automate, taux de disponibilité de l’installation, capa- L’IHM (Interface Homme-Machine) est la définition que l’on
cité de gérer les modifications en ligne, unicité des bases de donne pour tout équipement (PC, Panel PC, pupitre opérateur, affi-
données automate/ supervision, rapidité et déterminisme du cheur multiligne...) capable d’afficher des informations sur le pro-
réseau de terrain...) ; cess en provenance du terrain. Pour assurer cette première
— la volonté d’utiliser les technologies les plus modernes des fonction de récupération des données, tous ces IHM ont une carac-
principaux systèmes d’exploitation comme Microsoft ou Linux afin téristique commune, celle d’intégrer un protocole de communica-
de garantir un maximum de pérennité de l’installation... tion sur réseau informatique (Ethernet ou autres). Ensuite, on
Malgré toutes ces contraintes, la définition de l’architecture de distingue, de par les fonctions couvertes par l’équipement, diffé-
contrôle/commande serait encore relativement simple si dans la rents niveaux de complexités et d’ouvertures.
plupart des cas toutes ces contraintes ne s’interposaient pas les L’équipement le plus simple est l’afficheur multiligne, ensuite le
unes contre les autres. pupitre opérateur qui peut afficher des synoptiques plus
Exemple : nous retrouvons souvent la volonté de piloter l’installa- complexes, gérer des alarmes, des courbes de tendances... Enfin,
tion depuis plusieurs postes ou de gérer une redondance mais le bud- le superviseur, qui fonctionne sur un PC, est lui capable d’archiver
get ne le permet pas... alors que le responsable qualité l’impose !! des informations, de fonctionner en clients/serveurs, de s’interfa-
cer avec un système niveau 3...
Nous nous attachons malgré tout dans ce dossier à lister les
architectures les plus fréquemment rencontrées dans le monde
industriel. Les architectures de contrôle/commande que nous décrivons
dans le paragraphe 1.4 sont donc celles mises en place avec un
Toutefois, il est à signaler que les technologies de l’informatique superviseur industriel.
grand public, évoluant à très grande vitesse, imposent un rythme
élevé d’innovations et d’évolutions qui se répercutent directement
dans le monde industriel, faisant donc évoluer jour après jour les
architectures de contrôle/commande ! 1.4 Architectures de conduite
Après avoir donc introduit les différents éléments qui composent
1.1 Équipements d’acquisition ces architectures de contrôle/commande, il devient intéressant de
et de traitement présenter comment ces éléments peuvent s’interconnecter, échan-
ger de l’information tout en respectant les contraintes listées en
introduction.
API, PLC, Automates [S 8 015]... tous ces termes désignent le
même objet : l’équipement d’acquisition et de traitement. Ces équi-
pements récupèrent l’information terrain via des cartes d’Entrées/ 1.4.1 Architecture monoposte
Sorties Analogique ou TOR (Tout ou rien) ou directement sur des
organes de conduites communiquant sur un bus de terrain (varia- Historiquement, la plus simple mais aussi la plus communément
teur de vitesse communicant sur Profibus DP ou Modbus, système utilisée parce qu’elle répond déjà à de nombreux critères cités en


DOCUMENTATION
03/10/2008
Réseau informatique - Messagerie TCP/ IP

Superviseur
Serveur Client Client

Réseau industriel
Réseau
industriel
Automates
Figure 1 – Architecture monoposte Automates
Figure 3 – Architecture client-serveur

Réseau informatique - Messagerie TCP/IP
1.4.2 Architecture multiposte en parallèle

SCADA SCADA
Pour répondre aux contraintes de disponibilité, il peut être néces-
saire de disposer de plusieurs postes de conduite (figure 2). Il s’agit
Réseau de la façon la plus simple et la moins onéreuse de fournir un mode
industriel
redondant. Plusieurs superviseurs banalisés, formant en général
une association, assurent la supervision et la conduite du procédé.
Des applications identiques s’exécutent en parallèle sur chaque
poste. Afin de garder une synchronisation entre les postes de super-
vision, les actions opérateurs (passage de commande, passage de
Automates consigne) et les acquis d’alarmes sont diffusés vers tous les postes
de l’association sur TCP/IP via le réseau local informatique.
SCADA Supervisory Control and Data Acquisition
Figure 2 – Architecture multiposte en parallèle Avantages de cette architecture :

— très bonne disponibilité par la redondance des postes ;
— plusieurs opérateurs peuvent conduire l’installation ;
introduction, l’architecture monoposte se définit de la façon — assez simple à mettre en œuvre.
suivante (figure 1) : Inconvénients :
— un superviseur ou pupitre opérateur ; — le protocole utilisé entre la supervision et les automates
— un ou plusieurs automates ; doit être multimaître ;
— l’ensemble interconnecté via un réseau de terrain de type — légèrement plus coûteux qu’une architecture monoposte ;
Ethernet par exemple. — des archives/historiques qui peuvent être désynchro-
nisées quand un des postes est arrêté.
Dans une configuration traditionnelle monoposte, le superviseur
gère l’ensemble des données automates ainsi que les opérations
de contrôle-commande opérateur. Le superviseur supporte en
général une base de données de plusieurs dizaines de milliers de 1.4.3 Architecture client-serveur
variables sur un seul poste.
L’architecture client-serveur est une solution pour les applica-
L’acquisition de données se fait grâce aux protocoles standards tions nécessitant plusieurs postes opérateurs, mais avec une seule
du marché principalement sur Ethernet TCP/ IP mais également via connexion aux réseaux industriels (figure 3).
des Serveurs OPC (OLE for Process Control) du commerce.
Le serveur est un producteur de données qui communique avec
Dans des situations où les événements doivent être horodatés à les automates et diffuse les informations vers les postes clients
la source comme par exemple la supervision de distribution élec- souvent appelés postes consommateurs. La communication inter-
trique, le superviseur doit gérer des protocoles de communication postes TCP/IP fonctionne idéalement en mode événementiel et
véhiculant les données et leurs horodates avec une précision de la transmet par paquets les informations significatives.
milliseconde.
Le poste serveur peut être un poste d’exploitation ou un simple
Pour ce type d’architecture, au niveau du poste de conduite la frontal de communication, cela afin d’assurer un traitement rapide
majeure partie des éditeurs utilisent un environnement Microsoft des échanges avec le terrain. Il exécute tous les traitements
type Windows XP Pro. communs à l’application.
Avantages de cette architecture : Avantages de cette architecture :

— un coût réduit pour des fonctionnalités avancées par — capacité de gérer un process étendu physiquement avec
rapport à un pupitre opérateur ; plusieurs opérateurs de conduite ;
— une mise en œuvre simple et généralement robuste ; — réseau de communication entre le serveur et les automates
— une solution toutefois évolutive en fonction des produits moins chargé car un seul poste de supervision communique sur
utilisés. celui-ci.
Inconvénients : Inconvénients :
— une disponibilité relative faible (le PC hors service — un peu moins simple à mettre en œuvre ;
entraîne la perte de la supervision, l’installation) ; — point critique si le serveur est hors service car tous les
— un seul opérateur à la fois peut contrôler le process. postes clients deviennent « aveugles ».


DOCUMENTATION
03/10/2008
SCADA SCADA Superviseur Terminal Terminal

client client sur WTS 2003 banalisé banalisé
Réseau informatique
Messagerie TCP/IP
Accès Réseau informatique RDC

distant Messagerie TCP/IP
Serveur Serveur
Serveur actif Serveur en

Réseau stand-by
industriel
Réseau
industriel
Automates
Automates
Figure 4 – Architecture client-serveurs multiples
Figure 5 – Architecture clients banalisés via WTS
1.4.4 Architecture client-serveurs multiples

Dans cette configuration (figure 4), deux ou plusieurs serveurs, serveur et des postes à distance (clients banalisés) viennent
fonctionnant en parallèle, sont dédiés à la communication avec des « récupérer » les informations écran/ clavier/ souris via le RDC.
automates différents, chacun gérant des parties distinctes de Depuis un terminal banalisé, il est donc possible d’ouvrir une ses-
l’application. sion sur ce poste WTS et de lancer une instance du superviseur.
Chaque superviseur client est abonné aux serveurs et peut
Le poste WTS doit donc être dimensionné de manière à pouvoir
s’abonner à l’ensemble des variables de l’application.
supporter le nombre de sessions simultanées souhaité. Les termi-
Au-delà d’apporter une certaine flexibilité sur les accès aux infor- naux banalisés ne nécessitent aucune installation particulière, ce
mations par les personnes d’astreinte, il peut être nécessaire de qui facilite le déploiement de l’application sur site.
connecter un client via un service accès distant à un serveur situé
Sur les grosses et moyennes installations, plusieurs aspects de
dans un autre lieu géographique. Une liaison par ligne téléphoni-
cette architecture intéressent les exploitants :
que spécialisée, RTC (réseau téléphonique commuté) est possible.
— la simplicité de maintenance. En effet, l’application est sur un
Pour améliorer la disponibilité globale de l’installation (installa-
seul poste ; il n’est donc pas nécessaire de faire des mises à jour
tion sensible comme le nucléaire, la protection des personnes...), il
sur tous les clients ;
peut être nécessaire de doubler le réseau local informatique et/ou
— l’utilisation de terminaux banalisés ; cela signifie que ces
le réseau industriel afin d’accéder depuis un poste client, aux infor-
postes n’ont pas d’application particulière, qu’ils peuvent fonction-
mations des automates via deux chemins entièrement différents,
ner sur différents systèmes d’exploitations (Windows 95, 98, Linux,
c’est que l’on nomme généralement du bimédium.
CE, NT, XP...) et que le type de hardware peut être très varié (Pocket
Sur réseau industriel Ethernet, les superviseurs gèrent égale- PC, PDA, console Wyse, PC standard...) ;
ment la redondance d’automate, cela afin d’obtenir des systèmes — la capacité de déployer des postes clients globalement plus
avec une très haute disponibilité où le niveau de sécurité doit être nombreux pour un coût moindre. Un poste WTS peut par exemple
optimal (par exemple : norme SIL (Software Integration Level ) 2, être codé pour autoriser 10 clients mais le site industriel possède
3... IEC 61508 [23]). 50 terminaux banalisés qui se partageront les 10 accès.
Avantages de cette architecture : Avantages de cette architecture :

— pratiquement l’ensemble des avantages des architectures — identique à la précédente avec en plus un coût hardware
précédentes avec simplement une mise en œuvre légèrement plus réduit sur les postes clients car les machines peuvent être
plus délicate. plus légères (Palm, anciens PC avec Windows 98...) ;
Inconvénient : — maintenance fortement simplifiée pour une architecture
— le coût matériel et logiciel. avec de très nombreux clients car les évolutions de l’applica-
tion ne sont à réaliser que sur le poste WTS.
Inconvénients :
1.4.5 Architecture clients banalisés via WTS — si les machines clientes sont plus simples, les serveurs eux
doivent être de plus grosses machines car ils supportent
Alors que les différentes architectures présentées précédemment l’ensemble des traitements sur leurs CPU/Mémoire...
sont encore les plus fréquemment implémentées, l’architecture sur
base Windows Terminal Serveur WTS gagne du terrain et intéresse
de plus en plus d’exploitants (figure 5).
1.4.6 Architecture clients Web banalisés
Le principe de fonctionnement des clients Windows Terminal
Serveur s’appuie simplement sur le transfert sur réseau informati- Un client sert de serveur Web pour des postes munis d’un simple
que des informations écran/clavier/souris (RDC Remote Desktop navigateur Internet (figure 6). Il fournit via un serveur IIS (Internet
Connection ). Plusieurs sessions du superviseur fonctionnent sur le Information Service) ou Apache par exemple différents services


DOCUMENTATION
03/10/2008
Appplication
SCADA client sur PC
web serveur Messagerie Pocket PC utilisant avec navigateur
avec IIS XML SOAP Compact.net Internet
framework
Réseau informatique
Messagerie TCP/IP
Serveur actif Serveur en

stand-by
Réseau
industriel
Automates
Figure 6 – Architecture clients-serveurs avec
clients Web banalisés
Web publics ou privés via les protocoles HTTP (Hypertext Transfer

Protocol) et XML SOAP (eXtended Markup Language Simple, 2. Système de pilotage
Object Access Protocol ). Les postes banalisés ne nécessitent
aucune installation particulière, ce qui facilite le déploiement de
de la production MES
l’application sur et hors site. Ils doivent juste disposer d’un naviga-
teur Web permettant d’afficher une interface de conduite du
process : on parle alors de client léger par opposition aux clients MES Manufacturing Execution System
« lourds » des architectures client-serveur classiques.
Sur la base de telles architectures opérationnelles de
IIS est le serveur Web Microsoft intégré nativement à contrôle-commande, de nouvelles solutions de pilotage ont
Windows XP Pro. récemment vu le jour. Nous parlerons en particulier du concept de
MES (Manufacturing Execution System ).
Des terminaux mobiles peuvent accéder via les services Web

publics du client aux valeurs temps réel des variables et aux
différentes listes d’alarmes, d’historiques... 2.1 Définition et objectifs d’un MES
Des terminaux évolués avec navigateur Web et supportant Java
permettent de visualiser via les services Web et les applets Java, À un niveau planification, les progiciels de gestion intégrée des
les synoptiques, les courbes historiques, les listes d’alarmes... entreprises (ERP Enterprise Resource Planning, CRM Customer
Relationship Management, SCM Supply Chain Management )
offrent un ensemble d’applications logicielles paramétrables
Avantages de cette architecture : couvrant les grandes fonctionnalités d’une entreprise depuis la pla-
— le client léger permet de ne rien installer sur la machine nification de la production, jusqu’à la gestion financière, commer-
cliente et donc de pouvoir déployer des postes facilement sur ciale, ou logistique. La formalisation des processus impliqués et
un réseau TCP/ IP ; des informations qu’ils partagent aboutissent à la définition de
— par rapport à la solution WTS, le client léger présente référentiels « entreprise » au cœur de ces progiciels. Dans le
aussi l’avantage d’être moins onéreux. domaine de la production, ces référentiels contiennent des infor-
Inconvénient : mations relativement statiques telles que la définition des produits
— généralement des limites technologiques (ActiveX et Java et composants, leur nomenclature et gamme de fabrication ou
non compatible, par exemple) entraînent une capacité de encore la caractérisation des moyens de production mais égale-
conduite sur client léger restreinte et parfois moins fiable ment des informations plus dynamiques, élaborées ou recueillies
(Internet Explorer...). de manière événementielle ou périodique, telles que des plans de
production ou des déclarations de production (produits fabriqués,
matière consommée, temps passés...).
L’utilisation des nouvelles technologies de l’information et de la À un niveau opérationnel, les automatismes industriels assurent
communication dans la commande des installations industrielles le contrôle, la commande et la conduite des équipements de pro-
[S 7 090] favorise un accès en temps réel à l’information de terrain duction permettant de réaliser les transformations spatiales, tem-
par l’ensemble des acteurs de l’entreprise. Ces évolutions ouvrent porelles et morphologiques des produits requises par le procédé
la voie à une véritable entreprise « numérique » construite autour de fabrication. La distribution actuelle de l’intelligence logicielle au
d’entités distribuées et autonomes pour lesquelles les systèmes plus près des moyens de production augmente considérablement
d’informations et de communication jouent un rôle central. les capacités de traitements, de stockage et de communication de


DOCUMENTATION
03/10/2008
ERP
Systèmes de gestion d’entreprise Niveau
de planification
MES
Systèmes de pilotage de la production Niveau
d’exécution
SIMATIC® IT
Contrôle
Systèmes de contrôle/commande Niveau
de contrôle
SIMATIC®
a d’après Siemens
Systèmes de pilotage logistique

Niveau 4 Programme de production usine ERP
et gestion opérationnelle
Systèmes de contrôle de production

Niveau 3 Supervision de zone, Programme détaillé de production MES
Ordonnancement, Assurance qualité, Traçabilité
Systèmes Systèmes Systèmes

de contrôle de contrôle de contrôle
Niveaux 2,1,0 procédés procédés procédés Automatismes
discontinus continus discrets
b d’après ANSI/ISA-95 Figure 7 – Structuration en trois niveaux de

l’entreprise
l’information de ces équipements. Cela conduit à faire évoluer les

fonctions traditionnelles des automatismes industriels vers la ges- La MESA a proposé une définition du MES en 1996 que l’on
tion technique des installations industrielles et le suivi de la pro- peut traduire de la manière suivante : le MES fournit les infor-
duction en conférant aux équipements de commande un rôle de mations nécessaires à l’optimisation des activités de production
véritables serveurs d’informations. allant de la création de l’ordre de fabrication au produit fini. Par
l’utilisation d’informations à jour et précises, le MES guide,
initie, réagit aux activités de l’atelier au fur et à mesure de leur
Le manque de communication et de partage d’information entre déroulement, et fournit des rapports sur ces activités. Sa forte
ces deux niveaux ne permet pas de répondre au besoin de réacti- réactivité à l’évolution des conditions de fabrication, associée à
vité des entreprises, notamment face à une demande croissante de un objectif de réduction des activités à faible valeur ajoutée,
variabilité des produits et aux exigences normatives, législatives conduit à un fonctionnement plus efficace de l’atelier de fabrica-
ou sociétales en termes de traçabilité. En effet, d’une part, les pro- tion. Le MES accélère le retour sur investissement, fiabilise les
giciels de gestion de production basés sur le MRPII [AG 5 115] temps de fabrication, diminue les stocks et augmente les
[AG 5 120] ont un manque de réactivité face aux aléas et d’autre marges. En alimentant un flux bidirectionnel d’informations, le
part les systèmes de supervision n’ont pas les capacités suffisantes MES fournit à toute l’entreprise et à sa chaîne logistique, les
pour gérer toutes les informations nécessaires au pilotage d’un données critiques sur les activités de fabrication.
atelier complet. Ce constat a conduit, au début des années 1990
sous l’impulsion de deux organisations américaines (AMR
Advance Manufacturing Research, MESA MES Association ), à La vision des systèmes d’entreprise, partagée par la plupart des
l’émergence du concept de MES (Manufacturing Execution acteurs du marché de l’entreprise, se traduit donc par un modèle
System ) ayant pour vocation d’assurer l’interface entre la gestion en trois couches à l’image de ceux présentés par la figure 7.
d’entreprise et la conduite des systèmes de production. Les MES,
développés à l’origine pour des applications très spécifiques (phar- 2.2 Fonctions du MES
macie, semi-conducteurs) ont été adaptés pour des applications
plus larges couvrant les différents types de procédés (continu, L’appellation MES regroupe l’ensemble des outils assurant une
batch et manufacturier). partie ou la totalité des onze fonctions définies par la MESA.


DOCUMENTATION
03/10/2008
Bill of resources
(external) Product production Bill of material
rule (external)
* has associated
*
has associated
*
* *
Product segment Corresponds to
Product segment Process segment Manufacturing bill
Dependency *
* 1..*
has an execution * 1
dependency on
is defined as a collection of
* * * * 1..*
Product parameter Personnel Equipement Material specification
specification specification
* * *
Personnel Equipement Material specification
specification property specification property property
Personnel Model Equipement model Material Model
Figure 8 – Extrait des diagrammes de classes UML de la norme ANSI/ISA-95
— Allocation et contrôle des ressources (resource allocation and attendus et les résultats réels au niveau de la production, au niveau
control ) : gestion et suivi en temps réel des ressources de fabrica- de l’utilisation des ressources, de leur disponibilité, du temps de
tion (machines, outils, matériaux, documents...) et toute autre cycle de chaque produit...
entité nécessaire aux opérations à réaliser sur les ressources. — Contrôle des documents (document control ) : contrôle des
— Ordonnancement (operations and detailed scheduling ) : enregistrements et des documents qui doivent être conservés avec
séquencement basé sur les priorités, attributs, caractéristiques, et l’unité de production (instructions de travail, recettes, plans, procé-
règles de production associées aux équipements de production et dures standards, morceaux de programmes...).
aux caractéristiques des produits. — Gestion du personnel (labour management ) : gère et enregis-
— Cheminement des produits et des lots (dispatching tre les activités du personnel, affectation de tâche en interaction
production ) : détermine le cheminement des produits et des lots avec l’allocation des ressources.
dans l’atelier conformément aux recettes ou gammes de fabri- — Gestion de la maintenance (maintenance management ) : pla-
cation utilisées et en tenant compte de l’état réel de l’atelier nifie les tâches permettant d’assurer la disponibilité des équipe-
(pannes, retards, etc.). ments et des outils pour la fabrication (actions correctives,
— Acquisition et collecte de données (data collection and acquisition ) : périodiques ou préventives), aide au diagnostic.
obtention en temps réel et historisation des données opérationnelles
associées aux équipements et aux procédés de production.
— Gestion de la qualité (quality management ) : analyse en 2.3 Flux d’informations
temps réel des indicateurs qualité, identification et signalement
des problèmes potentiels, recommandation d’actions correctives La nature et les échelles de temps des flux physiques et informa-
ou préventives. tionnels traités aux niveaux de la gestion d’entreprise et de la con-
— Gestion du procédé (process management ) : surveillance de duite des procédés étant très différentes, il s’avère nécessaire
la production, permettant soit de corriger automatiquement, soit d’identifier un référentiel commun qui formalise les processus mis
de fournir une aide à la décision aux opérateurs pour corriger et en jeu à chacun des niveaux, les informations manipulées et les
améliorer les fonctions en cours d’utilisation. modèles utilisés. En ce sens, la norme ANSI/ISA-95 « Enterprise-
— Traçabilité et généalogie produit (production planning and Control system integration » (IEC/ISO 62264) [24], propose, dans
tracking ) : fournit et enregistre les informations sur l’état de la pro- ses parties 1 et 2, une formalisation des processus de gestion et
duction et des travaux (affectation du personnel, composants utili- d’exécution, dans le formalisme flux de données, ainsi que les
sés dans la production, alarmes...). structures d’informations et leurs attributs, sous la forme de dia-
— Analyse de performances (performance analysis ) : fournit des grammes de classes UML (Unified Modeling Language, figure 8).
comptes-rendus sur les écarts constatés entre les résultats La partie 3 de cette norme définit les modèles des activités de


DOCUMENTATION
03/10/2008
gestion des opérations de production qui permettent l’intégration

du système de l’entreprise et celui de contrôle.
Les principales informations gérées par les MES peuvent se Business Planning
regrouper en trois familles (figure 9) : & Logistics information
Plant Production scheduling,
— les informations relatives aux produits (Product Definition Operational management, etc
Information) ;
— les informations relatives aux capacités de production (Pro-
duction Capability Information) ;
Product
— les informations relatives à la production (Production Infor- Production Production
Definition
mation). Capability Information
Information
Information (What to
(How to
Les flux d’informations échangés entre les systèmes de contrôle (What is
make a
make and
et de commande et le MES d’une part, et le MES et les systèmes available) results)
product)
de gestion intégrée des entreprises d’autre part, sont résumés par
la figure 10 : l’ERP élabore un planning prévisionnel de production
de type MRPII qu’il communique au MES afin que celui-ci définisse Manufacturing Operations
les actions nécessaires à la production de ces commandes. Les & Control information
caractéristiques de ces actions (découpage des ordres de fabrica- Area supervision, Production, Scheduling,
Reliability, Assurance, etc
tion OF pour tenir compte des capacités effectives de l’atelier, allo-
cation des ressources, paramètres de fabrication, modes
opératoires) sont transmises vers le système de contrôle-
commande. Pour répondre aux requêtes du MES, le système de
Figure 9 – Extrait de la norme ANSI/ISA-95
contrôle-commande effectue en temps réel le pilotage des opéra-
tions de fabrication. Il remonte au MES les valeurs des mesures
acquises sur le procédé ainsi que l’état d’avancement des opéra-
tions en cours. Sur la base de ces informations éventuellement reposent sur la définition de connecteurs (middleware) et de
complétées par les opérateurs de conduite, le MES fournit au sys- Web-services qui définissent non seulement la sémantique des
tème de gestion intégrée d’entreprise, les résultats de fabrication objets échangés et leur transformation pour les mettre à un format
(quantité produite, matière consommée, temps passé par opéra- interprétable par l’application destinataire (WSDL Web Services
tions). Description Language ) mais aussi les protocoles nécessaires pour
transporter et router ces messages (XML SOAP). Dans cet objectif,
la partie 5 de la norme ANSI/ISA-95, en cours d’élaboration, doit
2.4 Architectures d’intégration compléter la standardisation des objets des parties 1 et 2 par la
définition de protocoles inspirés des transactions définies par
Plusieurs types d’architectures sont envisageables pour per- l’OAGIS BOD (Open Application Group Integration Specification,
mettre l’échange d’informations entre les niveaux ERP/MES/Auto- Business Objects Definition ) (figure 11).
matismes. La première, que l’on peut qualifier de statique, est
basée sur un échange de fichier entre ces différentes applications.
Cela suppose la définition d’un protocole d’échange commun entre
toutes les applications concernées. Ce format repose aujourd’hui Messages
d’une part sur les objets standardisés de la norme ANSI/ISA-95 et
d’autre part sur les technologies XML au travers du langage B2MML Zone d’identification
de l’application
(Business to Manufacturing Markup Language ).
Il est à noter que ni la norme ANSI/ISA-95 dans son état actuel,
ni le langage B2MML ne définissent de sémantique de transactions Basé sur les Verbes Noms Implémentation
verbes de (transactions) (objets) d’objets
pour les messages. La partie 5 de la norme, actuellement en l’OAGIS BOD S95 (B2MML)
révision, prévoit cependant de s’orienter vers l’utilisation de tech-
niques utilisées dans le domaine de l’interopérabilité des applica-
tions d’entreprise (B2B : Business to Business ). En particulier l’EAI Figure 11 – Échanges dynamiques de messages pour l’intégration
(Enterprise Application Integration ) et ses différentes déclinaisons ERP/MES/Automatismes
Traçabilité et généalogie produit

Quantité produite Suivi des opérations
Temps passé par opérations (date/lot/postes de charge, …)
Matière consommée Alarmes
État des ressources État du procédé
État du personnel Suivi des matières
Gestion intégrée Systèmes de
d’entreprise MES contrôle et
(ERP) de commande
OF planifiés Ordonnancement
Recettes et gammes Allocations des ressources
Ressources Actions de maintenance
Qualification du personnel Modes opératoires
État des stocks
Figure 10 – Principaux flux d’informations échangés entre ERP/MES/Contrôle-commande


DOCUMENTATION
03/10/2008
ERP
CRM SCM
CRM ERP SCM
EAI
CRM SCM
Connecteur ERP
S95/OAGIS BOD
Synchronisations
statiques (B2MML)
MES MES SCADA
Collecteur
MES EAI de données
Collecteur Collecteur OPC
SCADA de données SCADA de données
OPC OPC Connecteur
S95/OAGIS BOD
Automates Automates Automates

E/S déportées E/S déportées E/S déportées
Réseau de terrain Réseau de terrain Réseau de terrain
IHM IHM IHM
Figure 12 – Évolutions des architectures
Ces technologies conduisent à une évolution d’architectures inté- vice acceptable, la sûreté de fonctionnement ne doit plus être
grées statiques (B2MML) vers des architectures EAI autorisant des considérée comme superflue, mais être intégrée aux systèmes de
échanges dynamiques entre ERP et MES, voire même entre ERP, production afin d’être un atout supplémentaire dans l’environne-
MES et automatismes pour peu que ces derniers puissent intégrer ment concurrentiel des entreprises. Cette intégration prometteuse
dans leurs équipements (automates programmables, serveurs se traduit en phase d’exploitation, par le développement et l’inte-
OPC) des connecteurs S95/OAGIS BOD (figure 12). raction de modules de surveillance supervision commande per-
Au-delà de l’impact technologique que souligne la figure 12, mettant au système de se reconfigurer afin de poursuivre tout ou
l’intégration des automatismes aux systèmes de pilotage de la une partie de ses missions. Cette notion de reconfiguration sera
production (MES), voire aux systèmes de gestion d’entreprises traitée en détail dans le paragraphe 4.
(ERP, CRM, SCM) conduisent à étendre leurs fonctions tradition- Un aléa, qu’il soit une variation de la demande ou l’effet d’une
nelles de commande des installations industrielles par des panne, ayant pour conséquence une réduction du potentiel produc-
fonctions de gestion technique aptes à fournir les informations tif du système, était souvent traité par l’arrêt complet du système.
requises (surveillance produit/procédé, enregistrement des états Dans un cas comme dans l’autre, la remise en cause brutale de
machines et opérateurs, identification et traçabilité produit...) sur l’ordonnancement dès qu’une marge décisionnelle est perturbée a
lesquelles pourront se baser des fonctions de prise de décision et pour conséquence une diminution de la qualité de service. Le sys-
de mise en œuvre de nouvelles configurations. Ce point fait l’objet tème est en effet moins disponible pour délivrer les lots à temps.
du paragraphe 3. L’intégration en conception et la prise en compte en ligne des flexi-
Par ailleurs, les automatismes étant en prise directe avec les sys- bilités tendent à permettre d’absorber ces perturbations. Des dis-
tèmes de pilotage de la production, ils devront pouvoir s’adapter positifs sont alors utilisés afin de mettre en œuvre la réactivité.
plus rapidement à des changements de production (modification En approfondissant la notion de réactivité face à des pannes, il
de gammes opératoires, lancement de nouveaux produits, person- apparaît qu’une réaction unique ne suffit pas mais que des boucles
nalisation des produits) afin de favoriser la réactivité du système de réaction adaptées doivent être envisagées en fonction de la
de production aux aléas de fonctionnement afin de minimiser les nature de l’aléa qui influe sur le système.
perturbations vis-à-vis des plans prévus par le MES. Ce point fait Nous pouvons faire un parallèle avec la théorie de la
actuellement l’objet de travaux portant sur la reconfiguration dyna- cybernétique [20] en présentant la réaction face à une panne
mique des automatismes et est présenté dans le paragraphe 4. comme une boucle de réaction intégrant des modules information-
nels, décisionnels et opérationnels. La terminologie dans le
domaine des systèmes de production flexible fait référence à des
notions de surveillance, supervision et commande que nous allons
3. Réactivité face à des pannes détailler. La plupart des définitions sont admises par la
communauté scientifique nationale. Un effort de structuration et de
Il est illusoire de prétendre que les systèmes dont nous avons définition des frontières entre ces modules se trouve dans le traité
présenté les architectures de pilotage sont exempts des variations IC2 [15] synthétisant des travaux du GT ASSF du GDR MACS. Ces
de leur environnement [16]. Afin de maintenir une qualité de ser- définitions sont reprises et commentées.


DOCUMENTATION
03/10/2008
3.1 Commande
Nature des tâches

Il convient de préciser que nous ne nous intéressons pas ici à la
commande effective dont le rôle consiste à envoyer électriquement
des ordres aux actionneurs. Sous le terme commande se retrou- Opérationnel
vent les fonctions dont le rôle est principalement opérationnel.
La commande sert à faire exécuter un ensemble d’opérations au Décisionnel
procédé en fixant des consignes de fonctionnement. Il peut s’agir
de réaliser :
Informationnel
— une séquence d’opérations constituant une gamme de
production ; Temps
— une séquence d’actions correctives suite à l’occurrence d’une
défaillance ;
— des actions prioritaires (traitement des urgences) pour Figure 13 – Tâches de surveillance, supervision, commande
assurer une sécurité ;
— des opérations de test et de réglage.
Plus particulièrement, elle a la charge d’exécuter les modèles qui
lui sont fournis. Elle peut donc être vue comme un interpréteur de rée, comme par exemple une marche forcée pour laquelle la
lois de commandes. commande continue à envoyer des ordres vers le procédé alors
qu’un diagnostic est en cours, existent et peuvent coexister. La
boucle représente bien une succession de tâches qui ne suivent
3.2 Surveillance pas une séquence bien figée [21].
La figure 13 schématise l’intervention des tâches de surveillance,
La surveillance regroupe les fonctions principalement infor- supervision et commande supportant des aspects informationnels
mationnelles permettant de fournir de l’information pertinente qui décisionnels et opérationnels. Il est intéressant de noter que le pro-
sert de base aux décisions prises par la supervision : cessus commence toujours par une phase informationnelle, qu’il
— recueillir en permanence tous les signaux en provenance du se termine par une phase opérationnelle. Le décisionnel se termine
procédé et de la commande ; après l’informationnel. L’opérationnel se termine après le décision-
— reconstituer l’état réel du système commandé ; nel. Des zones communes d’activation existent entre ces trois
— faire une liste de toutes les inférences nécessaires pour modules. C’est notamment le cas lorsqu’une première décision de
produire les données utilisées pour dresser des historiques de mise en repli du système est envisagée puis des compléments
fonctionnement et le cas échéant, pour mettre en œuvre un d’information sur les causes de la panne permettent de décider et
processus de traitement de défaillance. de mettre en œuvre une réaction plus appropriée.
La surveillance n’agit ni sur le procédé ni sur la commande et a
donc un rôle passif vis-à-vis du système de commande et du pro-
cédé. 3.5 Terminologie surveillance,
supervision, commande
3.3 Supervision Cette partie liste les différentes fonctions de surveillance, super-
vision et commande en les classant selon leur module d’apparte-
La supervision a pour rôle de décider de l’exécution d’une opé- nance. Le tableau 1 liste les entrées, sorties et le type de modèle
ration ou d’un travail effectué (sans rentrer dans les détails de utilisé. (0)
l’exécution). Elle recouvre l’aspect fonctionnement normal ou
anormal.
3.5.1 Fonctions de la surveillance [17]
1. En fonctionnement normal son rôle est de prendre en temps
réel les dernières décisions. Elle est amenée à faire de l’ordon- Détection : rend compte du fonctionnement normal ou anormal
nancement temps réel, de l’optimisation et de gérer le passage du système. Elle génère des symptômes dont le degré de sévérité
d’un algorithme de surveillance à l’autre. peut ensuite être évalué.
2. En présence de défaillance, la supervision va prendre toutes Diagnostic : a pour rôle d’établir un lien de cause à effet entre un
les décisions nécessaires pour le retour vers le fonctionnement symptôme observé et la défaillance qui est survenue, ses causes et
normal [15]. ses conséquences. Cette fonction peut être précisée selon trois
Que ce soit en fonctionnement normal ou anormal, la super- autres sous-fonctions :
vision a donc un rôle principalement décisionnel, consistant à — localisation : détermine le sous-système fonctionnel à
déterminer un certain nombre de paramètres en fonctions des l’origine de la défaillance. Pour cela, elle circonscrit l’origine de la
informations qui lui sont fournies. Elle a aussi pour rôle de générer défaillance à une zone du système ;
ou d’élaborer des lois (modèles qui seront ensuite exécutés). — identification : détermine précisément les causes qui ont
Il est à noter que la décision se fonde souvent sur un modèle engendré la défaillance constatée ;
indéterministe qu’elle rend déterministe afin d’être ensuite exécuté — pronostic : détermine les conséquences immédiates ou non
par la commande. de la défaillance sur le fonctionnement futur de l’installation.
3.5.2 Fonctions de la supervision

3.4 Organisation des modules
Décision : détermine un état accessible pour le retour au nou-
Les études concernant la réaction face à des aléas permettent de veau fonctionnement normal (recouvrement) [1] et les différentes
constater que plusieurs boucles allant de la boucle réflexe (détec- actions correctives modifiant la configuration du procédé et de la
tion, diagnostic, décision, reprise) à une réaction davantage élabo- commande (restauration) [11].


DOCUMENTATION
03/10/2008
Tableau 1 – Récapitulatif des fonctions

Fonction Entrées Sorties Type de modèle Type de moteur Critères décision
Détection • Ordres commande • Symptôme • Déterministe • Exécution • Sécurité
• Compte rendu par opération • Temporel • Autres...
d’opération + capteurs • Mesure de possibilité • Séquencement
• Événements du associée (Référence)
procédé
Diagnostic • Symptômes • Nature de la • Déterministe • Inférence
localisation par opération défaillance • Séquencement (parcours arrière)
identification • Cause de la temporel
défaillance • Fonctionnel
Diagnostic • Nature et cause • Conséquences • Déterministe • Inférence
pronostic de la défaillance sur les ressources • Fonctionnel (parcours avant)
• Produits • Conséquences sur les • Information
dans le système autres produits sur produits
• Passage • Indicateur de respect
par les ressources (ou non respect) de
(ordonnancement l’ordonnancement
initial) initial et liste des
produits défectueux
Décision • Nature défaillance et • État objectif + lots de • Indéterministe • Décisionnel • Qualité du service
recouvrement conséquence produits à rendu,
• État du procédé traiter = configuration • Disponibilité du
• Gammes en cours système...
Détermination • État actuel du process • Modèle de • Indéterministe • Décisionnel • Cohérence des états
modèle de • État objectif du process restauration intermédiaires
restauration (séquence de reprise)
Mettre en œuvre • Modèle de restauration • Ordres vers le procédé • Déterministe • Exécution
le transitoire vers
la nouvelle
configuration
Urgence • Modèle de reprise • Ordres vers le procédé • Déterministe • Exécution
Exécution • Modèle de commande • Ordres vers le procédé • Exécution
commande exécutable
Gestion des modes : gère des phases transitoires complexes charge tend elle-même à devenir difficile, voire même impossible.
entre l’état actuel du système et l’état objectif déterminé par la Pour ces raisons, de nombreux travaux de recherche visent à déve-
décision [1] [5]. lopper et proposer des solutions visant à aider l’opérateur humain
Il est à noter que ces deux fonctions participent à l’élaboration dans les phases de reconfiguration.
graduelle de nouveaux modèles.
3.5.3 Fonctions de la commande 4. Processus

Les fonctions qui suivent sont des moteurs d’exécution [11] et se de reconfiguration
distinguent par les modèles qu’elles exécutent ainsi que les priori-
tés qui leur sont affectées.
4.1 Définition
Exécution d’urgence : mise en œuvre avec un haut niveau de
priorité de séquences opératoires prédéfinies exécutées immédia-
tement après la détection d’un symptôme critique. Une procédure Dans les systèmes flexibles de production (SFP), le processus
d’urgence permet de replacer le système dans une position de repli de reconfiguration est un processus de réorganisation maté-
ou d’attente à partir de laquelle les évolutions dangereuses sont rielle et/ou logicielle du système. L’objectif de cette réorganisa-
évitées. tion est de pouvoir assurer la production dans des délais
Exécution d’une commande : exécute tout ce qui n’est pas de compatibles avec le cahier de charges en dépit d’un contexte
l’urgence que ce soit une séquence calculée hors ligne ou en ligne. indéterminé. L’indéterminisme résulte soit de la nécessité de
produire des produits qui n’étaient pas prévus initialement, soit
de la nécessité de faire face à des aléas de fonctionnement.
3.5.4 Récapitulatif des fonctions
Alors que l’automatisation de ces fonctions est évidemment
nécessaire à la surveillance et à la supervision temps réel des ins- 4.2 Contexte de la reconfiguration
tallations industrielles, il n’en demeure pas moins qu’une bonne
partie de ces fonctions reste bien souvent à la charge de l’opéra- Le processus de reconfiguration peut être déclenché par deux
teur humain qui doit intervenir lui-même sur le procédé pour le catégories d’événements liés soit aux produits, soit aux ressources
replacer dans un état de fonctionnement normal. Compte tenu de de production : les changements de production ou les chan-
la complexité toujours croissante des procédés industriels, cette gements d’états des ressources.


DOCUMENTATION
03/10/2008
racine
+
repos préparation
(IN/Act./Dégradé)
P7 = 8
production
arrêt
clôture repli 其 Modes de marches
(IN/Act./Dégradé)
elever_temperature
Légende d’un nœud :
(IN/Act./Dégradé) nom_service
elever_temperature_v1 (statut_configuration,statut_activation,statut_sûreté)
(IN/Act./Normal) Statut_configuration : [INOUT]

(IN/Active/Dégradé) Statut_activation : [ActiveNon_active]
eviter_fourniture_eau chauffer_eau Statut_sûreté : [NormalDégradéDéfaillant]
+
(OUT/Act./Défaillant)
(IN/Act./Normal)
chauffer_eau_v1 chauffer_eau_v2
mesurer_pression_p7 chauffer mesurer_temperature_t6

(OUT/Act./Défaillant) (IN/Act./Normal) (IN/Act./Normal)
(activer)
Figure 14 – Identification de l’état objectif à l’aide du graphe fonctionnel
■ Un changement de production peut être relatif à la nature de la En cas de réparation d’une ressource, il peut être envisageable
production, la qualité ou la quantité des produits. En effet, dans de l’intégrer (ou de la réintégrer) dans le système de production de
l’industrie manufacturière, les systèmes de production flexibles ont manière à augmenter ses capacités de production ou de réaction à
été conçus afin de répondre à la production de petites ou moyennes une panne de ressource.
séries de produits. Cela entraîne qu’il peut être nécessaire sur un Notons que les deux types d’événements susceptibles de déclen-
horizon de production donné, de lancer la fabrication de produits cher un processus de reconfiguration ne sont pas nécessairement
qui n’avaient pas été ordonnancés. Cela n’est possible que si les res- découplés. En effet, une défaillance de ressource peut entraîner un
sources engagées dans la production ne fonctionnent pas à charge changement de production en raison de l’impossibilité à retrouver
maximale ou si l’on peut engager de nouvelles ressources en pro- les capacités de production nécessaires dans les délais requis.
duction. Un changement de production peut également être relatif à
la qualité des produits. L’exigence d’une qualité supérieure à celle
initialement prévue peut nécessiter l’engagement de ressources de 4.3 Mise en œuvre du processus
transformations capables de l’obtenir. Il en est de même pour la
quantité dont les exigences peuvent varier en cours de production. de reconfiguration au niveau
Dans tous les cas, ces changements peuvent induire l’ajout ou la de la commande
suppression de certaines ressources matérielles (par exemple, des
machines ou des robots dans un système manufacturier ou l’utilisa- D’une manière générale, le processus de reconfiguration
tion de pompes, cuves ou vannes différentes dans un système comprend au moins deux étapes [6] : une étape décisionnelle de
continu) par rapport à l’ensemble de celles engagées dans la pro- détermination d’un état objectif dans lequel on souhaite mettre le
duction en cours. système et une étape opérationnelle permettant de mettre en
œuvre un certain nombre d’opérations de configuration qui per-
■ Les changements d’états des ressources de production sont mettront d’atteindre cet état objectif. Lorsque le processus est initié
quant à eux caractérisés par deux grands types : les défaillances et par un événement de type défaillance d’une ressource, ces deux
les réparations. étapes sont précédées par une étape de surveillance ayant permis
En cas de défaillance(s), le processus de reconfiguration doit la détection et l’identification de la défaillance (§ 3).
d’abord chercher à substituer la (les) ressource(s) défaillante(s) par
une autre ressource du système de production. L’objectif dans ce 4.3.1 Étape décisionnelle
contexte est d’utiliser des redondances actives ou passives pour
remédier à la défaillance. On peut distinguer trois types de Dans ce contexte, la reconfiguration doit permettre d’adapter les
reconfigurations [1] : services offerts par le système de production aux objectifs de pro-
duction. L’état du système est donc caractérisé par les services
— la reconfiguration mineure : elle consiste à utiliser des res- offerts par le système. L’état courant correspond aux services
sources actives. Cela n’est possible que si les ressources concer- actuels et l’état objectif est caractérisé par les services souhaités.
nées ne fonctionnent pas à charge maximale et si leur taux Afin d’établir l’état objectif, le Laboratoire d’automatique, génie
d’engagement courant permet d’absorber la charge initialement informatique & signal (LAGIS, Lille) propose une représentation
affectée à la ressource défaillante ; arborescente appelée graphe fonctionnel (figure 14) qui permet
— la reconfiguration significative : elle consiste en l’utilisation d’établir des relations causales entre les fonctions élémentaires
de ressources démarrées mais non engagées dans la production des composants de base du système et ses fonctions principales.
courante ; Ce modèle permet d’exploiter des algorithmes de parcours de
— la reconfiguration majeure : elle consiste à mettre en marche graphe qui, étant donné le changement d’état d’une fonction
et à engager en production des ressources qui avaient été laissées donnée, va identifier un état objectif en exploitant les redondances
à l’arrêt pour la production courante. fonctionnelles existant dans le modèle [8] [18].


DOCUMENTATION
03/10/2008
Pre_Alloc/ Alloc/ Alloc/ Pre_Alloc/ Pre_Alloc/ Rest/ Rest/ Alloc/

Ack(M1) Req(M1) Ack(M1) Req(f2) Ack(M3) Req(M1) Ack Req(M3)
f1 – f2– f1 – f2– f1 – f2– f1 – f2– f1 + f2– f1 + f2– f1 + f2– f1 + f2–
I->Z2 Z2 Z2->M1 M1 M1 M1->Z2 Z2 Z2->Z4
Pre_Alloc/
Req(f1) I->Z2 I->Z2 Z2->M1 Z2->M1 M1/ M1/ M1->Z2/ M1->Z2/ Z2->Z4/ Z2->Z4/
/Req /Ack /Req /Ack Run(f1) Ack(f1) Req Ack Req Ack
f1 – f2– f1 – f2– f1 + f2–
I I Z4
Pre_Alloc/ Alloc/ Alloc/ Pre_Alloc/ Pre_Alloc/ Rest/ Rest/ Alloc/

Ack(M2) Req(M2) Ack(M2) Req(f2) Ack(M3) Req(M1) Ack Req(M3)
f1 – f2– f1 – f2– f1 – f2– f1 – f2– f1 + f2– f1 + f2– f1 + f2– f1 + f2–I
I->Z3 Z3 Z3->M2 M2 M2 M2->Z3 Z3 Z3->Z4
I->Z3 I->Z3 Z3->M2 Z3->M2 M2/ M2/ M2->Z3/ M2->Z3/ Z3->Z4/ Z3->Z4/
/Req /Ack /Req /Ack Run(f1) Ack(f1) Req Ack Req Ack
I indique la localisation physique du produit dans le système de production

(ici le stock d’entrée des pièces)
f1 – f2– indique l’état d’avancement du produit dans sa gamme d’usinage

(ici, état brut initial)
Req, Ack, Rest plages d’interface pour la synchronisation avec d’autres modèles
Z1 à Z4 noms des stocks intermédiaires
Figure 15 – Gamme opératoire flexible
Pour mettre en œuvre cette étape de décision, le Laboratoire tions fonctionnelles à appliquer au produit pour le faire passer de
d’électronique des systèmes temps réel (LESTER, Lorient) propose, l’état brut à l’état fini. On parle alors de gamme logique quand elle
à partir d’une description physique et logique d’un système recon- est décrite par un modère RdP coloré [4]. Cette commande peut
figurable, l’élaboration d’un modèle de type graphe ou réseau de également préciser à la fois les opérations de transformation et les
Petri RdP représentant l’accessibilité entre les différentes fonctions opérations de transferts que subit le produit. On parle alors de
de transformation du système de production [7]. L’analyse a priori gammes opératoires [4]. La commande des ressources consiste en
de ce modèle permet, hors ligne, l’évaluation de la criticité [1] des la modélisation d’opérations exécutables par les ressources et de
différentes ressources qui composent le système. Ainsi en cas de l’ensemble des transferts permettant de les interconnecter. Dans ce
défaillance d’une ressource critique, la décision peut immédiate- cadre, on distingue deux types de techniques utilisées par l’étape
ment déterminer qu’il n’existe pas d’alternative. Dans ce cas, seule opérationnelle : l’adaptation en ligne de la commande et la syn-
une modification des objectifs permet une poursuite de la produc- thèse dynamique de lois de commande.
tion. Ce modèle est également utilisable en ligne afin de détermi-
ner un état objectif de reprise. En effet, en se basant sur les ■ L’adaptation en ligne de la commande est basée sur l’idée que
accessibilités résiduelles, il permet de déterminer les séquences de l’ensemble des potentialités de contrôle du système a été
transformation pouvant encore être mise en œuvre sur le système pré-intégrée à la commande. Dans ce cadre, le LAGIS propose une
de production. Le choix des gammes opératoires détermine alors approche [12] basée sur l’exploitation des RdP colorés. À chaque
l’ensemble des ressources disponibles à mettre en production. produit est associé une gamme opératoire modélisant la nature des
Celles qui ne sont plus nécessaires doivent être arrêtées. flexibilités du processus de fabrication (Job Shop ou Open Shop) et
les redondances fonctionnelles du procédé. Les deux branches de la
figure 15 illustrent que l’opération de transformation « f1 » peut
4.3.2 Étape opérationnelle être réalisée (f1 +) soit la machine M1 soit sur la machine M2. Elle
montre également que le choix d’une ressource est réalisé dynami-
L’obtention de l’état objectif nécessite la conception d’une quement par la requête de demande de pré-allocation d’une res-
commande reconfigurable. Dans les systèmes manufacturiers, la source. Cette pré-allocation est fonction de l’état des ressources et
définition d’une telle commande résulte souvent de la complémen- de l’ordonnancement prévisionnel réalisé hors ligne. Si par exem-
tarité entre deux points de vue : une commande basée sur le point ple, seule la machine M1 était engagée en production dans le mode
de vue produit (point de vue logique du système reconfigurable) et normal ; en cas de panne, l’allocateur peut remplacer la machine M1
la commande des ressources de production (point de vue physique par M2, et cela de manière transparente pour la gamme. Dans
du système reconfigurable). La commande selon le point de vue l’approche du LAGIS, les gammes opératoires fonctionnent de
produit consiste en général à décrire les séquences de transforma- manière complémentaire avec les graphes de commande des


DOCUMENTATION
03/10/2008
PMAg
OUT IN
Z1->PMAg PMAg->Z1
Z1->OUT IN->Z1
Z4->IS4 IS4 IS4->Z1 Z1 Z1->IS1 IS1 IS1->Z2
M3->Z4 IS6->Z1 Z1->IS5 Z2->M1
M3 Z4 IS6 IS5 Z2 M1
Z3->IS6 IS5->Z3
Z4->M3 M1->Z2
IS3->Z4 Z3->IS3 IS2->Z2 Z2->IS2

IS3 Z3 IS2
M2->Z3 Z3->M2
M machine
IS stock intermédiaire M2
Z zone de déplacement
PMAg magasin de palettes
Figure 16 – Prégraphe dans l’approche du LAGIS [13]
ressources. Par exemple, l’ensemble du système de transport est

contrôlé à l’aide d’un RdP coloré décrivant toutes les accessibilités
L1->L2
entre les différentes ressources du système. Ce modèle est obtenu
en deux étapes. La première étape fournit le prégraphe (figure 16),
modèle préliminaire dans lequel chaque place modélise un lieu phy- <o> * L1->L2/NOP
sique opératoire et chaque transition un transfert entre ces dif-
férents lieux. La deuxième étape permet d’obtenir le modèle de L1/REQ L2/CONS
L1->L2/t1
<o>
commande par structuration du prégraphe à l’aide de primitives
L1
génériques (figure 17). Cette commande principalement de coor- L1->L2/TRSF-START
dination peut faire appel à des commandes de plus bas niveaux
L1/ACK <o>
compatibles avec les formalismes de programmation de la norme L2
L1->L2/t2
IEC 61131-3 [25] qui sont par exemple disponibles en bibliothèque <o>
comme dans l’approche par composant développée au LESTER [2].
Lieu amont L1->L2/TRSF-END
■ Une approche similaire est proposée par le CRAN [26] en se basant <o> L2/PROD
sur une technique de synthèse de contrôleurs développée par L1->L2/t3
Ramadge et Wonham. L’approche du CRAN est centrée sur le produit.
<o>
Chaque produit est muni de fonctions d’information et de décision. Lieu aval
L’approche de reconfiguration (figure 18) du CRAN est basée sur le
couplage entre : L1, L2 lieux opératoires
NOP pas d’opération (repos)
— des contrôleurs de produit qui gèrent le routage des produits CONS emplacements disponibles
au travers du système compte tenu des spécifications des produits TRSF transfert
et des capacités des ressources ; <o> étiquette caractéristique de l’objet transféré
— des contrôleurs de ressources qui gèrent l’exécution d’opé-
rations flexibles selon les requêtes émises par les produits.
Figure 17 – Primitive générique de structuration des transferts [3]
La coopération entre les deux types de contrôleurs est assurée
par le partage d’un alphabet commun résultant des événements
associés aux requêtes et comptes rendus échangés, et par un
modèle relatif aux capacités des ressources. Les contrôleurs des tage des produits est généré en ligne par l’utilisation de techniques
produits ont pour objectifs de fournir un contrôle de bas niveau de synthèses, chaque fois qu’un produit donné est introduit en
ayant des capacités de reconfiguration. En effet, le contrôle du rou- entrée du système de production.


DOCUMENTATION
03/10/2008
RP 01 RP 09 RPdec
Synthèse du contrôle des produits

Gamme logique
Superviseurs
RW Synthèse
des produits
Services proposés
par les ressources RPpos2
RQpos2 RQpos2 RQpos4 RQpos0

RQpos5
RPpos4 RQpos0
RQpos4
RPpos0
RQpos4 RQpos2
RQpos5 RQpos5 RQpos0
RP op 2 RQpos0 RQpos0 RQpos0
RQ pos 1 RPpos5
RQpos4
RQ01 RP09 RQpos4
RQ op 2 RPpos0
RP pos 1 RQpos5
RQ09 RPpos4
RP op 1 RP pos 2 RQpos5
RQ pos 2 RQpos2 RPpos2
RQpos4
RP09
RP01 RQpos5 RQdec RPdec
RQ op 1 RQpos2 RQpos4 RQ09 RPpos5
RQ op 3 RQpos5 RPpos2
RP op 3 RQpos4 RQpos0 RQpos2
RPpos4
RQpos0 RQpos2 RQpos2
RQpos2
RQpos5 RQpos4
RQpos5 RQpos0
RPpos5
RPpos0
Dynamique des Synthèse du contrôle des ressources

ressources
Superviseurs
RW Synthèse
des ressources
Services attendus
des ressources
Figure 18 – Architecture de synthèse d’une commande reconfigurable proposée par le CRAN [26]
■ La seconde technique utilisée pour obtenir une commande recon- compte de contraintes opérationnelles comme l’exclusion mutuelle.
figurable consiste en la synthèse hors ligne ou en ligne d’une loi de Une dernière phase, non représentée sur la figure 20, permet de
commande déterministe prenant en compte les caractéristiques du transformer le graphe cyclique obtenu en code de type grafcet ou
produit et les ressources disponibles. RdP. L’intérêt principal de cette approche est de pouvoir adapter, en
Dans ce cadre, le LAG (Laboratoire d’automatique de Grenoble) temps réel, la commande aux caractéristiques réelles du système
propose une approche [11] de synthèse de lois de commande en de production.
contexte incertain des systèmes automatisés de production. L’incer-
tain est ici caractérisé d’une part par les variations imprévues des
demandes client, mais également par les aléas de fonctionnement
déclarés au niveau de la partie opérative. L’approche, localisée au
niveau 1 du CIM (Computer Integrated Manufacturing), et en parti-
5. Conclusion
culier au sein des modules de coordination des chaînes fonction-
nelles, s’intègre au sein d’un système plus général de supervision, Le pilotage des procédés industriels est en pleine évolution, prin-
surveillance et commande. L’approche se distingue en considérant cipalement due à une recherche permanente de réduction des
la globalité du processus qui mène à la reconfiguration des lois de coûts, deuxièmement à l’évolution très rapide du monde de l’infor-
commande. En effet, elle propose non seulement une méthode de matique, troisièmement aux attentes des exploitants en termes
modélisation de la partie opérative utilisant un formalisme particu- d’outils de conduite et d’aide à la conduite de ces procédés de plus
lièrement adapté à la complexité des procédés considérés mais en plus complexes et enfin aux incertitudes liées à la fois aux
aussi une technique de synthèse de lois de commande basée sur demandes des clients mais également aux aléas de fonctionne-
un mécanisme de recherche de chemins dans un graphe. La modé- ment issus du procédé considéré. Ces changements se traduisent
lisation proposée (figure 19), proche de celle utilisée en planifica- par une conduite plus complexe des procédés, nécessitant le trai-
tion automatique, est basée sur un ensemble d’opérations qui tement, avec toujours moins de préavis et davantage d’incertitu-
décrivent la dynamique des chaînes fonctionnelles et leurs effets sur des, de toujours plus d’informations. Afin de faire face à une telle
le flux de produits tout en prenant en considération les contraintes problématique, un agencement efficace des composants issus des
sécuritaires et environnementales associées. Toute l’originalité du technologies de la communication et de l’information doit être réa-
mécanisme de synthèse proposé réside dans le compromis réalisé lisé pour assurer, dans tous les cas, un fonctionnement efficace du
entre la complexité du graphe manipulé et les performances de la système, en ayant toujours à l’esprit l’importance d’une maîtrise à
solution obtenue. Ce mécanisme (figure 20) est basé sur l’analyse chaque instant de sa sécurité et de sa productivité. Au cœur de
des effets sur le procédé d’opérations caractérisant les possibilités cette problématique du pilotage d’ateliers, ce dossier apporte sa
fonctionnelles de ses composants. Ces opérations sont de trois contribution en termes de préconisations de choix d’architectures
types : transformation, transitique et préparation. Pour chaque pro- de pilotage, d’organisation des fonctions requises au niveau Manu-
duit, un algorithme en trois phases permet de générer une loi de facturing Execution System MES et enfin d’ouverture à des
commande optimale. La première phase détermine un graphe méthodes de reconfiguration permettant de faire face aux aléas de
acyclique intégrant progressivement des séquences contenant les fonctionnement. De telles méthodes sont en cours d’articulation au
trois types d’opérations. Les deux étapes suivantes consistent à travers notamment de projets scientifiques afin de tendre vers leur
imbriquer et à fusionner les différents graphes acycliques en tenant intégration future au sein de structures MES.


DOCUMENTATION
03/10/2008
Opération d’action i : OAi Identificateur

Chaîne fonctionnelle : CFi Service : Sei Grandeurs
de commande
Durée, coût financier, etc Caractéristique (s)
Évolution de la chaîne fonctionnelle eci
Condition Cd (eci) Pré-contrainte PeC (eci)
Effet transitoire EfT (eci) Contrainte Ct (eci)
Effet final EfF (eci)
1re évolution associée du flux de produits eai, 1
Dynamique
e
j évolution associée du flux de produits eai, j
Condition Cd (eai, j) Pré-contrainte PeC (eai, j)
Effet Transitoire EfT (eai, j) Contrainte Ct (eai, j)
Effet final EfF (eai, j)
Ne évolution associée du flux de produits eai, N
Figure 19 – Modèle d’une opération par le

LAG [10]


DOCUMENTATION
03/10/2008
Modèle du système contrôlé Demande
Évolution requise
Évolution induite
Opération d’information
Plusieurs produits A Plusieurs produits B
Opération
OpÈrationd’action
d’action
Algorithme de synthèse de lois de commande
verrou
! 1 produit A 1 produit B
Transformation
autorisées ?
évolutions
étape 1
Tour Fraiseuse
Perceuse
Conception de lois de commande acyclique

où les intégrer ?
Tour V2 V3 Magasin
Transitique
étape 2
Tapis 1 Tapis 1
Perceuse Fraiseuse
V1
Phase A
Démarrer Démarrer tapis
Préparation
geler les // ?
étape 3
Rentrer V1 pour Rentrer V3 pour

!
autoriser tournage autoriser fraisage

retrouver tous
Parallélismes
Tournage Démarrage
du tapis et
étape 4
et
les // ?
démarrage du tapis rentrée de V3

!
de commande multiproduit
Plusieurs Multiproduits (A et B)
de commande cyclique
produits (A)
Imbrication - Phase B
! commutation entre les produits ?

Conception de lois
Conception de lois
Fusion - Phase C
Imbrication
Assemblage de produits
Fusion
! flux qui ne traversent pas le système

Reprise suite à une défaillance
contraintes interproduits ?
! ! présence de produits dans l’état initial
- répondre à la demande
Loi de commande
- satisfaire les contraintes de sécurité et d’écologie
Figure 20 – Principe de l’algorithme de synthèse proposé par le LAG [11]


DOCUMENTATION
03/10/2008
Références bibliographiques
[1] BERRUET (P.). – Contribution au Recouvre- (WODES’02), Zaragoza (Spain), p. 289-294, techniques et moyens de prévention opéra-
ment des Systèmes Flexibles de Production oct. 2002. tifs – Systèmes de commandes – Utilisation
Manufacturière : Analyse de la Tolérance et [9] PÉTIN (J.-F.), GOUYON (D.) et MOREL (G.). – des machines. Collection Technique. Groupe
Reconfiguration. Thèse de doctorat, Univer- Supervisory synthesis for product-driven Schneider (1997).
sité des sciences et techniques de Lille, déc. automation and its application to a flexible [17] TOGUYÉNI (A.K.A.). – Surveillance et dia-
1998. assembly cell. IFAC Control Engineering gnostic en ligne dans les ateliers flexibles de
[2] BERRUET (P.), LALLICAN (J.L.), ROSSI (A.) et Practice journal, Volume 15, Issue 5, Elsevier l’industrie manufacturière. Thèse de docto-
PHILIPPE (J.-L.). – A component based Science Publisher, ISSN 0967-0661, mai 2007. rat, Université des Sciences et Technologies
approach for the design of FMS control and [10] HENRY (S.), DESCHAMPS (E.), ZAMAÏ (E.) et de Lille, nov. 1992.
supervision. IEEE SMC 2005, Hawaii. p. JACOMINO (M.). – Control Law Synthesis [18] TOGUYÉNI (A.K.A.). – Reconfigurability Ana-
3005-3011, oct. 2005. Algorithm for Discrete-Event Systems. IFAC lyser For Automated Production Systems.
[3] BOUREY (J.P.). – Structuration de la partie Conference on Management and Control of INCOM’2004, Salvador de Bahia (Brazil), avr.
procédurale du système commande des cel- Production and Logistics (MCPL’04), Santiago 2004.
lules flexibles dans l’industrie manufactu- (Chili) (2004).
rière. Thèse de doctorat, Université des [19] TOGUYÉNI (A.K.A.). – Design of modular and
[11] HENRY (S.). – Synthèse de Lois de
sciences et techniques de Lille, mars 1988. hierarchical controllers for reconfigurable
Commande pour la Configuration et la
manufacturing systems. CESA’06, Beijing
[4] CRUETTE (D.). – Méthodologie de conception Reconfiguration des Systèmes Industriels
(China), oct. 2006.
des systèmes complexes à événements Complexes. Thèse de Doctorat, Institut Natio-
discrets : application à la conception et la nal Polytechnique de Grenoble, 7 oct. 2005. [20] WIENER (N.). – Cybernetics : or Control and
validation de la commande des cellules flexi- [12] HUVENOIT (B.), CRAYE (E.) et GENTINA Communication in the Animal and the
bles de production dans l’industrie manufac- (J.C.). – Élaboration de la commande de cel- Machine. 2nd edition. New York : MIT Press
turière. Thèse de doctorat, Université des lules de production flexibles dans l’industrie (1961).
sciences et techniques de Lille, févr. 1991. manufacturière. Actes de la Conférence [21] ZAMAÏ (E.). – Architecture de Sur-
[5] DANGOUMAU (N.). – Contribution à la Ges- Automatisation Industrielle, vol. I, p. veillance-Commande pour les Systèmes à
tion des Modes des Systèmes Automatisés 6.21-6.25, Montréal (Canada), juin 1992. Événements Discrets complexes. Thèse de
de Production. Thèse de doctorat, Université [13] KAPUSTA (M.). – Une première étape de doctorat, Université Paul Sabatier, Toulouse,
des sciences et techniques de Lille, déc. conception assistée du modèle de la partie FRANCE, sept. 1997.
2000. commande de cellules flexibles de produc- [22] IEC 61131-3. – Programmable controllers –
[6] DANGOUMAU (N.), TOGUYÉNI (A.K.A.), tion dans l’industrie manufacturière. Thèse Part 3 : Programming languages, janv. 2003.
DUPAS (M.) et CRAYE (E.). – Reconfiguration de doctorat, Université des sciences et tech-
[23] IEC 61508. – Functional safety or electri-
Process for automated Production Systems. niques de Lille, févr. 1988.
cal/electronic/programmable electronic
MCPL’2000, Grenoble (France), 3 au 8 juill. [14] KRAMER (T.R.) et SENEHI (M.K.). – Feasibility safety - related systems, janv. 2005.
2000. study : Reference architecture for machine
control systems integration. Nist ir 5297, [24] IEC/ISO 62264 (ISA/ANSI-95). – Enterprise –
[7] DE LAMOTTE (F.), BERRUET (P.) et PHILIPPE
national institute of standards and techno- control system integration – Part 1 : Models
(J.L.). – Using model transformation for the
logy, gaithersburg, md (1993). and terminology, déc. 2003 – Part 2 : Object
analysis of the architecture of a reconfigura-
model attributes, juill. 2005.
ble system. IMACS 2005 world congress, [15] NIEL (E.) et CRAYE (E.). – Maîtrise des Ris-
Paris, juill. 2005. ques et Sûreté de Fonctionnement des Systè- [25] IEC 61131-3. – Programmable controllers –
[8] GHARIANI (A.), TOGUYÉNI (A.K.A.) et CRAYE mes de Production. Éd. Hermes, sous la Part 3 : Programming languages, janv. 2003.
(E.). – A Functional Graph Approach for direction de C. FOULARD, section Producti- [26] GOUYON (D.), PETIN (J.F.) et GOWIN (A.). –
Alarm Filtering and Fault Recovery for an que du Traité IC2 (B. DUBUISSON) (2002). Pragmatic approach for modular control syn-
Automated Production System. 6th Interna- [16] SOURISSE (C.) et BOUDILLON (L.). – La sécu- thesis. IEEE SMC’04, La Hague (Pays-Bas),
tional Workshop on Discrete Event Systems rité des machines automatisées. Tome 2 : octobre 2004.


DOCUMENTATION
03/10/2008

Ag 3510

Transféré par

Droits d'auteur :

Formats disponibles

Ag 3510

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ag 3510

Transféré par

Droits d'auteur :

Formats disponibles

Architectures de pilotage

1. Architectures de contrôle et de commande..................................... AG 3 510 - 3

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

Dossier délivré pour

Sigle Développé Sigle Développé

CIM Computer Integrated Manufacturing RdP Réseau de Petri

CPV Central Process Unit RTC Réseau téléphonique commuté

Customer Relationship Management SCADA Supervisory Control and Data Acquisition

MRPII Manufacturing Resources Planning II WTS Windows Terminal Serveur

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

Dossier délivré pour

1. Architectures de contrôle de pesée dialoguant sur InterBus-S...). Ces informations sont

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

Dossier délivré pour

Réseau informatique - Messagerie TCP/ IP

Serveur Client Client

Figure 1 – Architecture monoposte Automates

Figure 3 – Architecture client-serveur

1.4.2 Architecture multiposte en parallèle

Figure 2 – Architecture multiposte en parallèle Avantages de cette architecture :

Avantages de cette architecture : Avantages de cette architecture :

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

Dossier délivré pour

SCADA SCADA Superviseur Terminal Terminal

Accès Réseau informatique RDC

Serveur actif Serveur en

Figure 5 – Architecture clients banalisés via WTS

1.4.4 Architecture client-serveurs multiples

Avantages de cette architecture : Avantages de cette architecture :

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

Dossier délivré pour

Serveur actif Serveur en

Web publics ou privés via les protocoles HTTP (Hypertext Transfer

Des terminaux mobiles peuvent accéder via les services Web

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

Dossier délivré pour

Systèmes de pilotage logistique

Systèmes de contrôle de production

Systèmes Systèmes Systèmes

b d’après ANSI/ISA-95 Figure 7 – Structuration en trois niveaux de

l’information de ces équipements. Cela conduit à faire évoluer les

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

Dossier délivré pour

Personnel Model Equipement model Material Model

Figure 8 – Extrait des diagrammes de classes UML de la norme ANSI/ISA-95

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

Dossier délivré pour

gestion des opérations de production qui permettent l’intégration

Traçabilité et généalogie produit

Figure 10 – Principaux flux d’informations échangés entre ERP/MES/Contrôle-commande

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

Dossier délivré pour

Automates Automates Automates

Figure 12 – Évolutions des architectures

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

Dossier délivré pour

Nature des tâches

3.5.2 Fonctions de la supervision

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie