Les Architectures Distribuées : Flexibilité au Niveau de la Commande
LES ARCHITECTURES DE PILOTAGE CLASSIQUES
Les Architectures Hiérarchiques
L’approche hiérarchique est basée sur une perception naturelle des systèmes complexes où la partition des ordres de haut niveau en ordres plus spécifiques et de portée plus limitée ne facilite pas seulement leur applicabilité mais aussi leur compréhension. Dans ces systèmes comme dans les organisations sociales humaines, des ordres se transmettent du haut vers le bas et les informations sur la progression de ces ordres ou de l’état du système du bas vers le haut pour générer de nouvelles prises de décision et de nouveaux ordres. Les niveaux les plus hauts se basent sur l’hypothèse d’un comportement prévisible de tous les composants (dans la hiérarchie et dans l’environnement) pour la prise de décision. À cause de ceci et au fait que ces architectures nécessitent une structure fixe lors de leur exécution, ils possèdent certains désavantages :
● Système difficile à modifier, au cas où l’on souhaite étendre le système ou le mettre à niveau avec une nouvelle technologie. Il faut l’arrêter, et mettre à jour toutes les structures d’information de niveaux hauts et leur influence sur le comportement des niveaux plus bas ;
● La modification des structures d’information pendant l’exécution sont quasiment impossibles.
Dû à l’hypothèse sur la nécessité d’un comportement prévisible des composants et de l’environnement, le programme de production devient rapidement invalide en présence d’aléas sur l’un de ces deux domaines. Dans certains cas, les plans de production peuvent même être invalides avant d’être calculés. Dans cette approche très centralisée, une hiérarchie forte existe entre tous les composants du système qui s’appuie sur un flot descendant de commandes et un flot remontant d’informations. Ainsi, un niveau supérieur définit les contraintes et objectifs à atteindre par le niveau suivant. De ce fait, un problème de coordination entre les différents niveaux apparaît, puisqu’il est très fréquent que les problèmes de chaque niveau soient interdépendants. La prise de décision peut porter sur un horizon temporel représentant la durée de validité/applicabilité des décisions.
Les Architectures Hétérarchiques
L’approche hétérarchique a été conçue pour résoudre ce problème d’incapacité à gérer les aléas induits par le système centralisé. Cette architecture est composée d’entités intelligentes, qui peuvent alternativement représenter une ressource dans le système ou bien une tâche du processus. Dû à l’apport d’intelligence locale à ces agents, ils ont la capacité d’adaptation à des situations qui n’ont pas été envisagées auparavant, grâce à des règles de comportement qui leur ont été programmées. Dans cette approche très décentralisée, la notion de maitre esclave trouvée dans le système hiérarchique est de fait plus souple, la relation n’existant pas entre tous les éléments et pouvant évoluer dans le temps . Ainsi, les flux d’informations et de décisions sont multiples et peuvent également évoluer selon l’évolution du système.
Les ordres et informations sont échangés via un protocole de négociation entre les entités. Le protocole de négociation le plus connu est le protocole Contract-Net (Borangiu et al., 2014; Smith, 1980). En schématisant, dans le contexte d’une négociation, les participants peuvent adopter deux rôles: gestionnaires de tâches ou clients. Le contrat se fait alors entre le gestionnaire et le client généralement sur un système d’enchères. En vue de cette négociation, basée sur des informations mises à jour en temps-réel et sans aucune connaissance à priori du comportement des autres agents, simplement des offres qu’ils fournissent, ces systèmes deviennent tolérants aux aléas, tout en étant toujours capables de trouver une solution faisable, mais généralement pas optimale.
Les avantages principaux de ce type d’architecture proviennent de la décentralisation de l’information et surtout de la prise de décision. Ainsi, il est possible de retarder au maximum cette prise de décision afin de bénéficier au mieux de la mise à jour en temps réel des données de l’atelier. Ces systèmes possèdent toutefois aussi des désavantages importants vis-à-vis de l’accessibilité de l’information :
● L’indépendance des agents limite leur accessibilité à l’information globale sur le système. Ils ne considèrent que l’information concernant les agents avec lesquels ils interagissent directement, mais pas de ceux qui l’affectent de façon indirecte ;
● La performance globale est très sensible au réglage des règles de comportement ;
● Il n’y a pas de garantie de performance minimale si le système sort du champ de travail pour lequel les règles ont été ajustées ;
● La performance globale peut être garantie seulement autour d’une valeur moyenne, quand l’agent se situe dans son champ de travail ;
● Le cycle de vie d’un ordre dépend fortement de la nature et de l’état des autres ordres ;
● La gestion des aléas dans le système est effective seulement s’il existe des alternatives.
LES SYSTEMES CONTROLES PAR LE PRODUIT : UNE PERSPECTIVE DE COMMANDE
L’évolution du marché vers des produits de plus en plus personnalisables et une évolution dans les pratiques de la production comme l’émergence des systèmes hétérarchiques demandent et poussent les concepteurs de ces dernières à adopter de nouveaux paradigmes, ou plutôt de nouvelles manières de regarder l’organisation de la production. Ce nouveau paradigme (nouveau quant à sa présence industrielle) est le paradigme des Systèmes Contrôlés par le Produit (SCP). Ce développement est une évolution logique à un contexte où le produit devient de plus en plus individualisé et où la production n’est plus fortement liée à la notion de lot. Dans cette section, on présentera un court état de l’art sur ce paradigme.
Les technologies d’auto-identification
Le pilier fondamental du paradigme des SCP est l’association des produits aux données relatives à son statut. La théorie menant à concevoir de tels systèmes était et reste très attractive, mais elle trouve des complications pour son implémentation, dû à un manque de technologie pouvant associer les informations au produit de manière virtuelle. Cependant, le paradigme a retrouvé son attractivité et sa viabilité grâce à l’émergence des technologies dites « infotroniques » (Pannequin, 2007). Grâce à ces technologies, l’intégration des objets informationnels dans les activités de prise de décision dans un système de production est devenue possible. Parmi ces technologies, on peut mentionner les étiquettes RFID (pour Radio Frequency Identification), la communication Bluetooth ou la communication Zigbee. La technologie RFID est celle qui a trouvé un développement le plus fort dans le domaine de la production. Elle consiste en la création d’étiquettes électroniques, sur lesquelles on peut effectuer de la lecture ou de l’écriture de données au travers d’émissions par radio fréquence. Cette action peut se faire de manière locale, lorsque l’étiquette est présentée à un point de contrôle. D’autre part, les technologies Bluetooth et Zigbee sont deux technologies de communication sans fil développées à fin des années 90 par les sociétés Ericsson et Motorola respectivement. La technologie Bluetooth est conçue pour donner de l’interopérabilité à des produits mobiles permettant des connexions de type ad-hoc de quelques mètres à presque 100m selon la classe. Zigbee pour sa part ajoute à la liste des objectifs la basse consommation et se présente comme un standard ouvert. De plus, les connexions Zigbee sont de type Broadcast et non ad-hoc. (Baker, 2005) présente un comparatif de ces deux technologies dans le cade de leur utilisation dans des applications industrielles. Ces technologies permettent l’identification des produits et leur association aux informations de la production. Cela apporte aux systèmes de production des capacités augmentées de traçabilité de produits, surtout importantes dans la production personnalisée et l’implémentation des stratégies de production en flux tiré.
Perspectives de contrôle
La réactivité de ces systèmes se base sur la prise des décisions en temps réel pendant la production, en se basant sur des règles établies à priori. L’idée derrière est de déplacer le moment de la prise de décision au plus proche du moment de leur application. Cette approche suggère de donner un rôle plus important au produit, passant d’un simple amas de matière circulant au sein du système à un acteur dans la prise de décision, capable d’interagir avec d’autres composants du système. Selon (Pannequin, 2007), dans un tel contexte, le produit devient un Objet Nomade de Production, défini comme « un objet capable de fournir des données aux clients, coopérer avec les autres entités participant à son évolution, adapter ses règles de décision en fonction de l’expérience acquise durant les phases précédentes de son cycle de production et coordonner des processus de décisions ». Avec l’association de la matière et des informations, les systèmes de production évoluent d’un flux de matière et d’informations découplés vers un flux de produits, associant informations et matière à la fois. De telles nouvelles perspectives conduisent à repenser la manière d’organiser et coordonner la prise de décision du système de contrôle vers une organisation où le produit devient le coordinateur de sa production. Ceci implique le passage d’une organisation hiérarchique et intégrée du pilotage vers une organisation permettant de l’interopérabilité et de l’intelligence, postulant le produit comme un vecteur de coordination et le pilote des ressources (Morel et al., 2007; Pannequin, 2007). Un produit délégant de telles responsabilités suggère le besoin de Produits Intelligents.
Qu’est-ce qu’un Produit Intelligent ?
Selon la définition de (Kärkkäinen, 2003) la notion de produit intelligent est associée à la gestion du cycle de vie de chaque produit, de manière individuelle, en intégrant le flux physique et informationnel afin d’offrir des services en utilisant un réseau. On trouve une autre définition dans (Ramirez, 2006) décrivant un produit intelligent comme un objet porteur de données, pointeur vers un système d’information, fournisseur et demandeur de services et comme un objet sensitif et enrichi avec des capteurs et des actionneurs. Une définition du point de vue fonctionnel, probablement la plus référencée dans le cadre de la production et de la « supply chain » est celle de (Wong et al., 2002). Un produit intelligent y est défini comme un objet avec une partie physique et une partie informationnelle dotée de capacités de stockage d’information, de communication, d’action et de décision. Une classification en deux niveaux d’intelligence selon les qualités d’interaction du produit est proposée. Un produit de niveau 1 est doté de capacités à s’identifier, stocker des informations et communiquer avec l’environnement passivement. Ce niveau est considéré comme orientéinformation, où l’activité des produits se résume à donner et garder les informations pour que le système puisse décider de leur traitement. Un produit niveau 2 possède toutes les propriétés d’un niveau 1 plus la capacité à dialoguer avec son environnement et la capacité de participer à la prise de décisions du système. Ils sont considérés comment orientés-décision.
|
Table des matières
Introduction
Chapitre 1 Les Architectures Distribuées : Flexibilité au Niveau de la Commande
1.1 Les Architectures de Pilotage Classiques
1.1.1 Les Architectures Hiérarchiques
1.1.2 Les Architectures Hétérarchiques
1.2 Les Systèmes Contrôlés par le Produit : Une Perspective de Commande
1.2.1 Les technologies d’auto-identification
1.2.2 Perspectives de contrôle
1.2.3 Qu’est-ce qu’un Produit Intelligent ?
1.3 Les Architectures Holoniques
1.3.1 Motivation originelle
1.3.2 Le paradigme holonique
1.3.3 Architectures de référence dans la production
1.4 Les Architectures Orientées-Services (SOA) : Flexibilité au Niveau du Processus
1.4.1 Introduction à SOA
1.4.2 Principes de l’orientation-services
1.4.3 Couches abstraites de SOA
1.4.4 Perspectives de services
1.4.5 SOA dans l’industrie
1.5 Conclusion
Chapitre 2 Adaptation des Services au Contexte de la Production
2.1 Besoin d’Adaptation pour la Production
2.1.1 Adaptation pour la spécification des produits
2.1.2 Adaptation pour la spécification des ressources
2.2 Relation avec les Familles de Produits
2.2.1 Les familles de produits
2.2.2 Les familles de processus
2.3 Les Services de Production (MServices)
2.3.1 Définition
2.3.2 Modèle conceptuel des MServices
2.3.3 Paramétrage des MServices
2.3.4 Accessibilité des MServices
2.4 Les Ontologies de Service
2.5 Modèles de Perspectives de MServices
2.5.1 Meta-Modèle des MServices
2.5.2 Modèle TypeMServ
2.5.3 Modèle SpecMServ
2.5.4 Modèle ProfMServ
2.5.5 Modèle ImpMServ
2.6 « Matching » des MServices
2.7 Processus Orienté-Services (SOP)
2.7.1 Modèle de Processus-Produit orienté services (ProcesProd-S)
2.7.2 Modèle de Processus-Dispositif orienté services (ProcesDisp-S)
2.8 Conclusion
Chapitre 3 Système Holonique de Production Orienté-Services (SOHMS) : Un Nouveau Paradigme
3.1 Incorporation des MServices aux Systèmes Holoniques
3.2 SOHMS : Une Méthodologie de Modélisation
3.3 Type de Systèmes d’Application
3.4 Etapes de la Méthodologie
Identification des agents holons
Définition d’une OdApp
Sélection des comportements
3.5 Architecture SOHMS
3.5.1 Les holons
3.5.2 Les couches abstraites
3.5.3 Création d’un nuage de services
3.6 Conclusion
Chapitre 4 Modélisation de Gammes Flexibles Orientées-Services
4.1 Introduction aux Gammes Flexibles de production
4.1.1 Spécification produit et gammes flexibles
4.1.2 Besoin d’un modèle computationnel de gamme
4.1.3 Etat de l’art : formalismes de modélisation
4.1.4 Etat de l’art : Gammes Flexibles
4.1.5 Choix de l’outil de modélisation
4.2 Modèle de Gammes Flexibles en Réseaux de Petri
4.2.1 Présentation du modèle
4.2.2 Le formalisme
4.2.3 Discussion sur les propriétés du réseau obtenu
4.3 Méthodologie de Modélisation
4.3.1 Définition de structure de produit
4.3.2 Définition d’une Table de Précédences
4.3.3 Approche orientée-produit
4.4 Génération du Modèle
4.4.1 Relations de précédence
4.4.2 Règles de modélisation
4.4.3 Algorithme de génération
4.5 Cas d’Etudes
4.5.1 Cas d’étude n°1
4.5.2 Cas d’étude n°2
4.6 Conclusion
Chapitre 5 Orchestration des Plans de Production Orientés-Services
Conclusion
