Coordination et interaction dans une soci

1
Coordination et interaction dans une société d'
agents autonomes

• GOUAICH Abdelkader
• gouaich(at)lirmm.fr
• LIRMM, Montpellier

2
Plan

• Partie I Environnement de déploiement dagents
  autonomes -gt MIC
• Partie II Protocoles de coordination et
  protocoles de conversation dans un système
  multi-agents
• Partie III Intégration du modèle de coordination
  et MIC

3
Partie IEnvironnement de déploiement dagents
autonomes MIC
4
Motivation

• Ingénierie de systèmes informatiques selon les
  principes du paradigme multi-agents cohérence
  paradigmatique.
• Rappel des propriétés fondamentales des agents
  dans le paradigme multi-agent
• Autonomie
• Sociabilité et interaction
• Pro-activité

5
Pourquoi avons-nous besoin de représenter
explicitement lenvironnement déploiement dans un
SMA?

• (a) Garantir lautonomie des agents
• Interprétation de lautonomie
• Indépendance sociale (SDN) Scc. 94
• Capacité dun système à contrôler et modifier ses
  propres lois (internes) Steel 95, Castel. 95
  
• Autonome vs. Automatique
• Intégrité structurelle de lagent est posée comme
  une condition nécessaire pour garantir
  lautonomie
• Intégrité structurelle
• Aucun agent (système externe) ne peut accéder, ni
  modifier létat interne dun autre agent
• Paradoxe! Les agents ne peuvent pas interagir
• Pour lever ce paradoxe on introduit
  lenvironnement de déploiement
• Lenvironnement de déploiement nest pas un agent
  autonome, cest un système automatique qui va
  acheminer les interactions entre les agents.
• Aucun agent na accès directement à la structure
  dun autre agent gt intégrité structurelle
  inter-agents est garantie

6
Pourquoi avons-nous besoin de représenter
explicitement lenvironnement déploiement dans un
SMA?

• (b) Établir la responsabilité des agents
  autonomes
• Les actions des agents sont considérées comme des
  tentatives pour changer lunivers
• Ces tentatives ne sont validées que si elles sont
  conformes aux lois/normes de lenvironnement de
  déploiement

7
Modèle route et rail

• Systèmes à entités autonomes interactionnelles.
• Interaction locale entre les entités
• Le système est régi par des conventionsqui
  garantissent sa sécurité (cohérence)
• On observe des différences entre les
  deuxsystèmes
• Le modèle  rail semble garantirmieux les
  règles de cohérence que le modèle  route
• Pourquoi?
• Le modèle rail représente explicitement les
  règles de cohérencecomme des propriétés de
  lenvironnement
• Le modèle route délègue la gestion des règles
  de cohérence à des entités autonomes

8
Nos objectifs

• Séparation explicite dun système informatique en
  un environnement de déploiement et des entités
  qui le peuplent.
• Étudier les concepts fondamentaux de cette
  structure sans considérer un modèle particulier
  des agents

9
Concepts Fondamentaux de MIC

• Description statique
• Objet dinteraction
• Espace dinteraction
• Processus de calcul (Agent)
• Dynamique de la structure
• Le mouvement
• Linteraction
• Le calcul

10
Objet dinteraction

• Objets dinteraction
• Linteraction est conduite à travers des objets
  dinteraction o ? O.
• (O,) possède une structure de groupe commutatif.
• Les objets dinteraction peuvent être composés x
  y.
• 0 ? O, Lobjet dinteraction neutre.
• Pour x ? O, -x ? O.

11
Espace dinteraction

• Espace dinteraction
• Abstraction qui définit une localisation/contexte
  où différentes entités interagissent.
• Entité active, qui régit les règles dinteraction
  entre les différentes entités.
• Par exemple Lespace dinteraction peut altérer
  les objets dinteraction émis par les agents.

12
Processus

• Processus (Agent)
• Entité autonome qui perçoit et réagit aux
  interactions externes par un calcul local et
  lémission de nouveaux objets dinteraction.
• Les interactions de lagent ne sont effectives
  que si elles sont en adéquation avec les règles
  de lespace dinteraction.

13
La structure statique de MIC

• (O, ) un groupe abélien qui représente les
  objets dinteraction.
• I, J deux ensembles représentant les processus et
  les espaces dinteraction.
• (L_i)i?I une famille densembles pointés où L_i
  représente les termes du langage interne du
  processus i.
• Soit lensemble des familles éléments de O
  .
• Soit lensemble des familles avec élément
  de L_i.
• Un environnement MIC est défini comme suit

14
Matrices associées à MIC
P0
P1
L_1
P2
?
Boite démission
Boite de réception
O
15
Composition des termes MIC
T
T
P0
Q
P1
P2

-
P0
P1
P2
Q
16
Règles dévolutionLe mouvement

• Le mouvement est une application ? qui vérifie
  les propriétés suivantes
• ? ne modifie pas les boites de réception ni la
  mémoire.
• ? conserve globalement les boites démission
  dun processus donné.
• Les boites démission après mouvement dun
  processus donnéne dépendent que des boites
  démission avant mouvement du même processus.

17
Règles dévolutionLe Calcul

• Le calcul est une application ? qui vérifie les
  propriétés suivantes
• ? consomme les objets dinteraction présent dans
  le vecteur de réception dun processus.
• Les valeurs des boites démission et de la
  mémoire après calcul dun processus donné ne
  dépendent que des valeurs des boites démission,
  de réception et de la mémoire avant calcul de ce
  processus.

P0
P1
P2
18
Règles dévolutionLinteraction

• Linteraction est une application ? qui vérifie
  les propriétés suivantes
• ? ne modifie pas les boites démission ni la
  mémoire.
• si un processus nest pas présent dans un
  espace dinteraction il ne peut interagir.
• Les boites de réception après interaction dun
  processus donné dans un espace dinteraction
  fixé ne dépendent que de leursvaleurs avant
  linteraction et des boites démission des
  processusdans le même espace dinteraction.

P0
P1
P2
19
P0
P1
P2
Inbox
Outbox
Comment contrôler les protocoles dinteraction
(normes sur la coordination) par
lenvironnement de déploiement?
20
Partie II Protocoles de coordination et
protocoles de conversation dans un système
multi-agents
21
Prérequis What is coordination?

• Malone and Crowson mal94 define coordination as
  managing dependencies among activities
• Common dependencies among activities are
• Shared resource
• Producer/Consumer
• Prerequisite
• Transfer
• Usability
• Simultaneity constraint
• Task/Sub-Task

22
Backgrounds What is coordination?

• 1) Focus is made on activity aspect of
  coordination
• What activity to execute?
• When an activity should be executed?
• Model to coordinate distributed tasks such as
  Statecharts, Flowcharts, Process algebra, Lotos,
  SDL, Estelle
• 2) Conversational Aspects of coordination
• What is the structure of the conversation among
  the coordinating entities?
• FSM, Petri-Nets, State Transition Diagrams
• 3) Implementation centric works
• How to implement distributed software systems
  where software components coordinate their
  actions.
• For instance, Linda-family coordination mediums

Implementation Centric
Conversation Centric
Activity Centric
Generalisation efforts
23
Problem statement

• What is the link between the conversation
  protocol and the coordination protocol ?
• To answer this question, the following
  methodology has been adopted
• Step 1 Starting from Malone and Crowson works a
  simple coordination model has been proposed
• Step 2 Starting from this coordination model,
  the conversation protocol is formally induced as
  valid sequences of messages recognised by a
  defined grammar.

Implementation Centric
Conversation Centric
Activity Centric
Generalisation efforts
24
Modélisation
25
(No Transcript)
26
Décomposition du graphe de coordination en rôles
27
Structure de la jointure entre les rôles exemple
La partie observable du processus de coordination
28
Grammaire des ressources pré-requis

• Ensemble utilitaire

29
Grammaire des ressources définition générale
Linterprétation de cette règle est que
lensemble des ressources à gauche produisent
lensemble des ressources à droite, ou
lensemble des ressources à droite consomment
les ressources à gauche.
30
Grammaire des ressources construction de
lensemble des règles à partirdu graphe de
coordination

• Lensemble des règles de réduction (production)
  dérive directement de la structure du graphe de
  coordination comme suit

31
Grammaire des ressources enfin, la définition
finale
32
Grammaire des ressources observablesexemple
33
Grammaire des ressources concrètes observables

• Distinction entre les ressources abstraites
  définies dans le graphe de coordination et les
  ressources concrètes qui circulent entre les
  entités
• Le lien se fait par des fonctions de
  reconnaissance et un mapping des ressources
  abstraites

34
Grammaire des ressources concrètes observables
35
Grammaire des ressources concrètes
observablesexemple
Pattern start.ping.pong.ping.pong
36
Grammaire des ressources concrètes
observablesdéfinition finale..
37
Comment reconnaître des séquences de ressources
concrètes Introduction informelle des réseaux
de Petri à pile

• On utilise une extension des réseaux de Petri,
  les réseaux de Petri à pile Queue Petri Nets
  (QPN)
• Structure dun QPN
• Une pile
• Jetons
• Transitions classiques
• Transitions qui consomment des objets de la pile

38
Définition formelle des QPN
39
Règles dexécution des QPNs
40
Construction du QPN à partir du graphe de
coordinationpré-requis

• Structure de bloc dans un réseau de Petri

Relation de consommation
Relation de production
41
Construction du QPN à partir du graphe de
coordinationalgorithme de génération
42
Construction du QPN à partir du graphe de
coordinationexemple
43
Validation des conversations des agents par
lobservation des objets d interaction.

• On utilise le QPN généré pour un protocole
  coordination
• Il faut attention aux conflits
• Conflit sur les jetons (alternative dans les
  réseaux de Petri classiques)
• Conflit sur la pile quand plusieurs fonctions de
  reconnaissance reconnaissent le premier message
  de la pile
• Solution duplication du QPN
• Une conversation est valide, si au moins un QPN
  vide sa pile
• Une conversation est invalide si tout les QPN
  sont morts
• Une conversation invalide gt Protocole de
  coordination non respecté
• Limitation le QPN généré ne doit pas comporter
  de cycle libre cycle ne contenant aucune
  transition qui consomme un message de la pile

44
Partie III Intégration du modèle de
coordination et MIC

• Encore une 1 heure ?

45
Conclusion

• Environnement de déploiement et son importance
  pour l ingénierie des SMA
• Unification des protocoles dinteraction et
  protocoles de coordination
• Dans les SMA, un protocole dinteraction
  (conversation) nest que la partie visible dun
  processus de coordination
• Validation des protocoles de coordination par
  observation des messages échangés sans contredire
  lautonomie des agents
• Lintégration des deux parties se fait par cadre
  dingénierie social
• Modèle social basé sur le modèle AGR
  Protocole de coordination
• MIC représente dans ce contexte lenvironnement
  social qui implémente et garantisse les normes
  établies sur la coordination.

46
Réalisations

• MIC, projet sur sourceforge, http//mic.sourcefor
  ge.net
• Coordination framework, gamme doutils de
  développement en C
• Formalisme XML
• Outil de génération automatique du
  ProtocolController en C