Vers un modèle holonique pour ORCA

La suite de ce chapitre présente le modèle holonique permettant de représenter ORCA et ses entités. Ainsi la section 3 présente les différents modèles structurels, comportementaux et

d’interactions existants dans la littérature. La section 4 quant à elle présente le modèle de re-présentation holonique d’ORCA retenu et le détaille.

3. Vers un modèle holonique pour ORCA

La modélisation choisie pour représenter l’architecture ORCA est holonique. En effet, la

mo-délisation holonique est générique, intègre explicitement la prise en compte du système

phy-sique et son intérêt n’est plus à prouver dans la communauté manufacturing control depuis la fin des années λ0 (notamment depuis l’architecture PROSA (Van Brussel et al., 1998)). La

programmation de la partie décisionnelle des holons peut être elle réalisée indépendamment à

base d’autonomic element, d’agents ou d’acteurs. Cette partie présente les spécifications rete-nues pour le modèle structurel (i.e. comment est représentée l’architecture à partir du modèle d’entités), comportemental (i.e. comment se comporte l’entité au sein du modèle structurel) et d’interactions (i.e. comment les holons du modèle interagissent entre eux) du modèle

holo-nique représentant ORCA.

3.1. Le modèle structurel

Plusieurs modèles holoniques structurels existent dans la littérature. Les deux modèles prin-cipaux sont PROSA (Van Brussel et al., 1998) et ADACOR (Leitão et Restivo, 2006). Dans PROSA les quatre types de holons suivants sont définis : product, resource, order et staff. Dans ADACOR les holons sont product, task, operational et supervisor. Ainsi la première spécificité de ces approches est que les holons de base sont différenciés. Ainsi un holon order (ou task) et un holon resource (operational) sont totalement différents. Avec une considéra-tion « service », un robot par exemple, peut effectuer un assemblage pour un produit et donc « fournir un service ». Pour effectuer cet assemblage il a besoin de matière première disposée dans un stock ou fourni par un opérateur, il est alors « demandeur de service ». Ce qui signi-fie que ce robot sera représenté de deux manières complètement différentes (order/task ou resource/operational) dans PROSA ou ADACOR, selon un point de vue ou l’autre, ce qui

peut constituer une première limite de ces modélisations. Une autre critique de la littérature (Jarvis et al., 2006) souligne que le concept holonique de récursivité n’est pas bien respecté

dans ces modélisations. Ces architectures ont en effet pris le parti de mettre en valeur quatre

classes différentes d’entités au lieu de définir une classe générique déclinable en sous-classes.

Ainsi les quatre types de holons sont dédiés à des rôles définis a priori et en aucun cas

n’intègrent d’autres holons. Une cellule de production (vue comme un tout), ne peut donc pas

être représentée de manière récursive (pour des détails sur la récursivité holonique, voir (Suárez et al., 2013)). Finalement, le lien entre ces modélisations et la mise en œuvre effec-tive d’un Système Flexible de Production n’est pas direct. Ainsi la mise en œuvre de ces ar-chitectures dans un cadre autre que celui de leur cellule de production d’origine avec des

moyens technologiques différents nécessite un travail de re-conception important. De façon générale, la couche « contrôle de haut niveau – pilotage » est définie très clairement.

Cepen-dant les couches au dessus (business) et en dessous (opérationnelle) sont moins bien prises en compte et déterminées (Jarvis et al., 2011) ce qui tend à gêner la mise en œuvre. En

conclu-37

sion, ces deux modélisations ne semblent pas convenir parfaitement pour notre approche en termes de généricité et récursivité. Il est cependant important de souligner que la modélisa-tion PROSA est la base de la majorité des approches holoniques actuelles et ce sont les tra-vaux décisifs effectués sur PROSA par le passé qui nous permettent désormais d’approfondir d’autres aspects.

Une troisième architecture holonique dans la littérature est appelée HCBA (Holonic Compo-nent-Based Architecture) et a été proposée par (Chirn et McFarlane, 2000). HCBA est une architecture « bottom-up » et donc construite à partir des éléments physiques de bas niveau. Elle considère deux composants : les produits et les ressources. Les produits entrent dans le

système avec un plan détaillé de leur production et essaient d’utiliser les ressources de la

meilleure façon possible en négociant avec elles. Il n’y a pas d’optimisation globale du sys-tème, cependant l’holon produit intègre une partie « coordination » qui créée un agent (Work

In Process) pour négocier avec les ressources. Comme pour les deux architectures précé-dentes, l’entité décisionnelle est déterminée à l’avance dans HCBA. Il s’agit du produit et il n’est donc pas facile de représenter directement un système où les ressources prendraient des

décisions de pilotage. De plus, HCBA n’intègre pas de fonctionnalité de haut niveau de

pilo-tage telle qu’un ordonnancement global de la production.

En s’appuyant sur toutes ces remarques, le choix a été fait de concevoir un nouveau modèle structurel (détaillé section 4.1) pour correspondre aux besoins de généricité d’ORCA. Il

con-serve les caractéristiques de base des holons (autonomie, interaction) tout en intégrant les nouvelles caractéristiques suivantes :

 Élément de base générique (ressource et produit sont des cas particuliers de cet

élé-ment),

 Récursivité au sens de la décomposition tout-partie,

 Mise en œuvre facilitée grâce à l’isomorphisme (i.e. il existe un lien direct entre

enti-tés du modèle et éléments du système réel).

La section suivante présente le modèle comportemental retenu.

3.2. Le modèle comportemental

ORCA étant volontairement conçue de manière générique dans le sens où elle est conçue afin

d’être applicable à différents domaines et cas d’étude, le choix du modèle de comportement ne doit pas imposer de mise en œuvre particulière mais laisser une certaine flexibilité en

fonction du cas d’étude. Cette section présente différents modèles permettant de représenter le comportement d’un holon du modèle d’ORCA. Le comportement d’un holon peut être

dé-crit selon deux grandes catégories de modèles.

La première catégorie de modèles contient ceux pouvant être qualifiés de modèle « gra-phiques ». Dans ces modèles le comportement est la plupart du temps défini par un graphe. Par exemple les réseaux de Petri (Monteiro et Ladet, 2001; Peterson, 1981; Petri, 1980)

38

réseaux de Petri permettent généralement de modéliser le comportement dynamique des sys-tèmes à évènements discrets comme les syssys-tèmes manufacturiers, les syssys-tèmes de télécom-munications, les réseaux de transport. De la même façon, les machines à états finis (Gill, 1970) comme les Statecharts (Harel, 1987) permettent de représenter graphiquement les

dif-férents états d’un système et les transitions possibles entre ces états. Dans ces machines à

états finis, les machine de Moore (Moore, 1956) considèrent que les sorties ne dépendent que

de l’état courant alors que les machines de Mealy (Mealy, 1955) considèrent que les variables de sorties dépendent de l’état courant et la lettre d’entrée. Le Grafcet (David et Alla, 1992)

permet assez similairement de représenter un système sous forme d’étapes et de transitions :

un Grafcet est un réseau de Petri particulier avec un seul jeton par place possible et soumis à des règles spécifiques (notamment en cas de conflit).

La deuxième catégorie de modèles contient les « textuels ». C’est le cas des modèles linéaires

en recherche opérationnelle comme les (M)ILP ((Mixed-)Integer Linear Programming) (Paschos, 2005) ou des modèles de Programmation par Contraintes (Esquirol et al., 1995; Mackworth, 1977) qui permettent de modéliser un système par les contraintes qui le définis-sent. Dans les systèmes multi-agents, la notion de rôles (Ferber et Gutknecht, 1998) peut être utilisée pour décrire la fonction (rôles organisationnels) qu’occupe un agent dans l’organisation ; ou les comportements (rôles fonctionnels) d’un agent (Bauer et al., 2001). Une vision générique qui permet différentes mises en œuvre est la vision « rôles ». Cette vi-sion permet d’une part une mise en œuvre graphique notamment par les JBehaviourTrees

(Bojic et al., 2011) qui proposent des arbres de comportement dédiés au développement sous la plateforme JADE ou AgentUML qui étend les modèles de UML, plus particulièrement le diagramme de séquences et le diagramme de classes afin de permettre la représentation des

rôles joués par les agents logiciels. D’autre part les rôles permettent aussi une mise en œuvre textuelle à l’aide de plateformes multi-agent comme JADE, NetLogo, RePast ou de langages de programmation usuels comme le C++ et Java. Le modèle holonique d’ORCA utilise donc

cette vision « rôles » correspondant à ses besoins de généricité. La partie suivante étudie les

modèles d’interactions permettant de représenter les interactions entre les holons du modèle d’ORCA.

3.3. Le modèle d’interactions

L’architecture ORCA a été conçue afin d’être générique. Ainsi le modèle d’ORCA doit per-mettre l’utilisation de nombreux mécanismes d’interactions entre ses holons. Le mécanisme

définitif ainsi que le type de basculement est à choisir en fonction de chaque cas d’étude (cf.

chapitre IV).

Cette section énumère une bibliothèque de mécanismes d’interactions de base envisageables

pour définir les interactions entre les holons d’ORCA. De façon à « cartographier » ces mé-canismes interactions, le concept d’ «Open Control» développé au sein de l’équipe

TEMPO-PSI a été repris. L’Open Control (Pach et al., 2012b) définit trois types d’interactions : le

39

 Le contrôle explicite représente une relation maître–esclave entre entités. Un

contrô-leur envoie ses ordres à un subordonné qui lui envoie des informations en retour. Ce

contrôle peut s’effectuer soit en modifiant les entrées de l’entité soit en ajustant ses

paramètres. Cela correspond au contrôle hiérarchique de base avec des ordres du ni-veau haut qui sont appliqués à un nini-veau inférieur. Ce contrôle hiérarchique dans le domaine manufacturier est présenté en détails dans (Baker, 1998). Un exemple ty-pique est celui d’un responsable de production qui décide d’arrêter une machine pour

effectuer une maintenance sur celle-ci.

 Le contrôle implicite permet d’influencer le comportement d’une entité sans ordre

di-rect ni relation maître–esclave. Deux types de contrôle implicite sont différenciés : le

contrôle implicite sociétal et le contrôle implicite environnemental.

o Dans le contrôle implicite sociétal les échanges entre entités se font directe-ment. Ainsi ce contrôle intègre les mécanismes d’interactions directs comme le

protocole Contract-Net (Smith, 1980) utilisé notamment dans le domaine de

l’intelligence artificielle distribuée. Dans ce protocole un gestionnaire est res-ponsable de l’exécution d’une tâche et cherche à contacter un ou plusieurs

contractant afin d’obtenir la meilleure qualité de service possible. Un autre exemple d’interactions directes est le Mutual Assistance Protocol (Polajnar et

al., 2012) dans lequel une entité peut aider une autre entité lorsque celle-ci

demande de l’aide. De cette façon, les deux entités agissent dans l’intérêt du

groupe. Le contrôle implicite regroupe l’ensemble des mécanismes

d’interactions basés sur des enchères. Les travaux de (Andersson et Sandholm,

2001) permettent d’avoir une vue générale de plusieurs de ces mécanismes.

Finalement dans (Gascueña et al., 2012), deux types d’interactions sont

propo-sées : une interaction hiérarchique où un gestionnaire de véhicules autonomes leur fournit les tâches les plus appropriées en fonction de leurs estimations ; et une interaction de proche en proche entre véhicules autonomes, correspondant

à un contrôle implicite sociétal, leurs permettant d’échanger sur leurs

estima-tions à réaliser leurs tâches.

o Le contrôle implicite environnemental regroupe les interactions pour les-quelles un intermédiaire (souvent l’environnement) est utilisé. C’est le cas

pour la plupart des approches bio-inspirées. Ainsi la stigmergie utilisée dans les travaux de (Dorigo et al., 2000) permet à des fourmis d’influencer le com-portement des autres en déposant des phéromones dans l’environnement. Les

approches basées sur les hormones (Shen et al., 2004) fonctionnent de la même façon. Les interactions à base de blackboard (Hayes-Roth, 1985) utili-sent un phénomène similaire même si l’information n’est pas déposée directe-ment dans l’environnedirecte-ment mais dans une entité intermédiaire. Finaledirecte-ment, les

champs de potentiel (Khatib, 1986) issus de la robotique mobile, permettent

d’attirer et/ou de repousser des entités grâce à des champs émis en champ libre et atténués par la distance entre l’émetteur et le récepteur.