Le Contract Net Protocol [Smith, 1980], proposé par Smith en 1980, est un protocole de haut niveau pour la communication entre les nœuds d’un résolveur de problèmes distribué. Il facilite le contrôle distribué de l’exécution de tâches coopératives avec une communication efficace entre les nœuds. Selon Smith, la négociation comporte quatre composantes importantes :
1) c’est un processus local qui n’implique pas un contrôle centralisé, 2) l’échange d’information a lieu dans les deux sens,
3) chaque partie dans la négociation évalue les informations de sa propre perspective, 4) l’accord final est réalisé par une sélection mutuelle.
L’ensemble des nœuds est dénommé un Contract Net et l’exécution d’une tâche est traitée par un contrat entre deux nœuds. Chaque nœud dans le réseau peut prendre l’un des rôles relatifs à l’exécution d’une tâche individuelle : manager ou contractant. Un manager est responsable de la surveillance de l’exécution d’une tâche et du traitement des résultats de son exécution. Et, un contractant est responsable de l’exécution effective de la tâche. La figure 6.3 décrit l’ensemble des états de traitement d’un contrat.
6.3.1 Description générale
Le Contract Net est le protocole d’interaction le plus utilisé dans les systèmes multi- agents. Il repose sur un mécanisme d’allocation de tâches régi par le protocole d’appel d’offre qui est utilisé dans les organisations humaines. Le modèle est basé sur une communication par envoi de messages. Dans les réseaux contractuels, un agent peut avoir deux rôles par rapport à une tâche : initiateur ou participant. Le protocole est composé de trois phases (voir figure 6.3) :
− annonce d’une tâche : l’initiateur fait une annonce de tâches (ou contrat) aux agents du système.
− offre d’un service : les agents évaluent leur intérêt en fonction de leurs ressources. − attribution d’une tâche : l’initiateur choisit un ou plusieurs agents candidats pour
95
Les contrats sont traités selon le diagramme présenté à la figure 6.4, qui utilise la terminologie des systèmes d’exploitation. Le processeur de contrat d’un nœud est responsable de la transition du contrat à travers le diagramme. Donc, la progression standard entre les états est décrite par les lignes pleines. Les progressions optionnelles sont décrites par les lignes pointillées.
Lorsqu’un contrat est affecté à un nœud(IN), il est placé dans l’état READY où il attend que le processeur de tâches soit libre. Il est placé dans l’état EXECUTING et son exécution est entamée. Si des sous-contrats sont générés, ils sont placés dans l’état ANNOUNCED. Un sous-contrat peut être soit affecté à un autre nœud(OUT), soit au même nœud (READY).
Dans le cas ou l’exécution d’un contrat ne peut continuer jusqu’à ce qu’un évènement se produise, le contrat est alors placé dans l’état SUSPENDED, et un autre contrat dans l’état READY est choisi pour être traité. Lorsque le traitement d’un contrat est terminé, il est placé dans l’état TERMINATED, et un autre contrat se trouvant dans l’état READY est alors choisi pour être lancé.
96
97
Le contrat Net est un protocole basé sur l’échange de contrats, qui met en relation un agent(le manager) avec plusieurs agents (les contractants). C’est donc une négociation de 1 vers n agents.
La figure 6.5 décrit la spécification BNF du protocole du Contract Net. Les symboles non terminaux sont entourés par des chevrons, les terminaux sont écrits sans délimiteurs et les non terminaux dont l’expansion n’est pas utile pour la discussion sont entourés par les crochets. Les termes devant être remplis par des informations codées dans le langage
98
commun entre les nœuds sont entourés d’accolades. Les types de message qui n’ont pas besoin d’être inclus dans une implémentation basique sont suivis d’une étoile.
6.3.2 L'algorithme du Contract Net
L'algorithme suivant présente le Contract Net Protocol (CNP). Sa description détaillée en sept étapes, regroupe les traitements du gestionnaire et des contractants, ainsi que les échanges entre eux. Pour appliquer ce protocole, le concepteur doit détailler le contenu des messages échangés, le temps d'expiration ainsi que les fonctions « évalue-annonce » et « évalue-soumission ».
Étant donnés une tâche, un gestionnaire et un groupe de (n - 1) soumissionnaires : 1. Le gestionnaire envoie un message de type « annonce-tâche » à un groupe d'agents, 2. Chaque agent évalue la tâche annoncée à l'aide d'une fonction locale « évalue-
annonce »,
3. L'évaluation précédente permet à certains agents de soumettre une proposition à l'aide d'une « soumission-tâche » au gestionnaire,
4. Si une proposition est jugée satisfaisante (à l'aide de la fonction « évalue- soumission ») alors le gestionnaire envoie un message de type « acceptation » à celui dont la proposition est retenue. Il envoie également un message de type « refus » aux autres agents dont les propositions n'ont pas été retenues,
5. Le gestionnaire peut mettre fin à la période d'acceptation de proposition si le temps d'expiration est dépassé.
6. Si aucune proposition n'a été retenue, alors le gestionnaire fait parvenir à tous les agents non retenus un message de type _refus_ pour indiquer le rejet de chacune des propositions,
7. Il peut alors se retirer de la négociation, retenir la proposition la plus acceptable, redémarrer un nouvel appel d'offre (nouveau « annonce-tâche ») ou prolonger le temps d'expiration de la période d'acceptation de proposition,
8. L'agent ayant obtenu le contrat, remet un rapport d'exécution lorsque la tâche est complétée.
6.3.3 Traconet (TRAnsportation COoperation NET),
Ce projet de Tuomas Sandholm [Sandholm, 1993] est destiné à résoudre le problème de routage de véhicules (VRP). Pour cela, il propose une extension du Contract Net qui formalise le processus de décision d’enchérissement et d’attribution de tâches. Cette formalisation se base sur le calcul de coûts marginaux relativement aux critères locaux de l’agent. De cette façon, les agents ayant des critères locaux très différents (basés sur leur propre intérêt), peuvent interagir afin de distribuer les tâches pour que le système global
99
fonctionne plus efficacement. Dans ce modèle, des agents compétitifs aussi bien que coopératifs peuvent interagir. De plus, le Contract Net Protocol est étendu afin de permettre, pour un regroupement de tâches, de traiter un grand nombre possible de messages d’annonce et d’enchère et d’effectivement traiter les situations où de nouvelles enchères et attributions se déroulent alors que les résultats des enchères précédentes sont inconnus. Le protocole est vérifié par le système Traconet (TRAnsportation COoperation NET), où les centres de distribution de différentes compagnies coopèrent automatiquement pour le routage de véhicules. L’implémentation est asynchrone et distribuée et elle procure aux agents une autonomie étendue. Comme le Contract Net, Traconet permet de réaliser une négociation de 1 vers m agents.
6.3.4 Fishmarket
Fishmarket [Noriega, 1998] est une agence d’enchères électroniques pour vendre du poisson, où les agents peuvent être soit humains, soit virtuels et qui a été développée à l’Institut de Recherche en Intelligence Artificielle en Espagne par Pablo Noriega.
Le marché au poisson est une place où se déroulent différentes scènes qui ont lieu en même temps mais dans des pièces différentes et qui ont une continuité causale. Chaque scène implique divers agents qui agissent selon des règles bien définies à ce moment précis. La scène principale est l’enchère où les acheteurs font des offres pour des caisses de poisson présentées par un commissaire-priseur qui annonce les prix dans l’ordre décroissant (protocole d’enchères descendantes). Cependant, avant que ces caisses de poisson ne soient vendues, les pêcheurs ont dû livrer le poisson au marché (dans la scène d’admission des vendeurs) et les acheteurs ont dû s’enregistrer dans le marché (dans la scène d’admission des acheteurs). De la même façon, une fois une caisse de poisson vendue, l’acheteur doit la retirer en passant par la scène des règlements des acheteurs, pendant que les vendeurs doivent retirer leur paiement dans la scène des règlements des vendeurs une fois leur lot vendu.
6.3.5 Zeus
Zeus [Nwana et al., 1999] est une API Java qui permet de programmer une application multi-agents, développée par British Telecom. Le but de Zeus est de proposer une boîte à outils qui puisse être appliquée. La réalisation de l’application avec Zeus est facilitée par support logiciel : le Zeus Agent Generator. Il permet de définir l’ontologie, les agents et les tâches. Puis le Code Generator permet de générer le code correspondant aux définitions réalisées avec l’Agent Generator. Zeus propose une modélisation de rôles pour 5 applications dans trois (3) domaines :
− le domaine de gestion d’informations,
100
La négociation s’effectue de 1 agent vers 1 autre agent. Il n’est pas possible avec Zeus de négocier de 1 vers n agents avec le protocole fourni. Ce protocole réalise des contrats entre 2 agents uniquement, il peut exécuter plusieurs négociations de 1 vers 1 simultanément, mais 1 seule sera confirmée, les autres seront annulées.
6.3.6 Magnet
Magnet (Multi AGent NEgotiation Testbed) [Collins et al., 1998] est un banc de tests pour la négociation multi-agents, implémenté sous la forme d’une architecture généralisée de marché et développé à l’université du Minnesota par John Collins et al. Il fournit un support pour un large panel de transactions, du simple achat/vente de biens à la négociation complexe de contrats entre agents. Le but des auteurs est de concevoir, implémenter et analyser une architecture de marché multi-agents généralisée, qui peut fournir un support explicite et intégré pour les interactions complexes entre agents, comme dans la prise de contrats automatisée, tout comme pour d’autres types de protocoles de négociation, incluant les enchères à offres scellées et la vente et l’achat à prix public ou offres publiques. Les auteurs introduisent également un protocole de prise de contrats flexible qui peut prendre complètement avantage de l’architecture de marché proposée pour faciliter les interactions entre agents. Magnet introduit un intermédiaire explicite dans la négociation qui aide à contrôler les fraudes, décourage les contre spéculations et est organisé autour de trois composants de base : l’échange, le marché et la session.
L’échange est une collection de marchés spécifiques à un domaine dans lesquels les services et les biens sont échangés, agrémentée par des services génériques requis par tous les marchés, comme la vérification des identités des participants à une transaction.
Chaque marché au sein d’un échange est un forum pour le commerce d’une commodité particulière ou d’un secteur d’activités. Il y a des marchés voués à la publication, à la construction, au transport, etc. Chaque marché inclut un ensemble de services et d’aménagements spécifiques à son domaine et chaque marché s’appuie sur les services communs de l’échange.
6.3.7 GenCA (Generic Negotiation of Contracts API)
Tout en étant un modèle général de négociation, GenCA est une implémentation sous forme d’une API Java. Conçu à l’origine par Verrons en 2004 pour permettre à un utilisateur souhaitant développer une application de négociation de pouvoir utiliser un modèle qui lui facilitera le travail. Le modèle a une architecture qui repose sur trois niveaux, séparant la partie communication entre agents, la partie stratégie de négociation d’une application de la partie négociation. La particularité de ce modèle réside dans la façon par laquelle communiquent les agents, celle-ci n’a pas d’influence sur la manière
101
adoptée pour négocier, et en plus différents moyens de communication peuvent être utilisés pour une même application de négociation qui serait exécutée dans des environnements différents. Pour valider le modèle, l’auteur a utilisé une API pour réaliser plusieurs applications comme un système de vente aux enchères, un système de prise de rendez- vous, et un système pour négocier le choix d’un restaurant pour une sortie commune. 6.3.8 Synthèse
La plupart des systèmes présentés dans ce chapitre utilisent des protocoles propres à leur application. Parmi ces systèmes, certains sont spécialisés dans les enchères comme Fishmarket, Kasbah, GNP et AuctionBot, d’autres sur les services comme ADEPT, mais peu se présentent comme étant générique. De plus, ils n’offrent pas tous les mêmes possibilités de communication, seul GenCA sépare la communication, pour les autres, elle est figée comme par exemple SilkRoad et GNP qui communiquent via une interface web. Certains utilisant un modèle bilatéral de négociation, par exemple Kasbahet Zeus, d’autres un modèle de 1 vers n agents, par exemple Magnet et Traconet. Enfin, ils utilisent des actes de langages spécifiques, ce qui limite leur portabilité. Le tableau 6.2 reprend les différentes plateformes présentées et apporte une comparaison sur différents critères qui nous paraissent importants pour une plateforme de négociation générique.
Plateforme Cardinalité Rétraction Contre- propositions
Réponse par défaut
Renégociation automatique
Traconet 1m ? Non Refus
implicite
Non
Fishmarket 1m non Non refus
implicite
non
Zeus 11 non Non refus
implicite
non
Magnet 1m oui Non refus
implicite
non
GeNCA nm oui Oui oui oui
102
6.4 Conclusion
Ce chapitre présente la coordination d’actions et de résolution de conflits dans un système multi-agents en introduisant deux méthodes de base qui sont la coordination et la négociation. Dans le premier volet, nous avons donné une description générale de la coordination, passant par différentes définitions, mécanismes, et techniques pour terminer par un état de l’art de tous les travaux sur la coordination notamment dans le domaine industriel, et plus précisément la gestion de production. Quant au deuxième volet de ce chapitre, il est consacré à la négociation : le Contract Net protocol est présenté, ainsi que les différentes extensions du CNP. Plusieurs limites d’utilisation de ce type de protocole ont été dégagées, nous pouvons citer par exemple :
− il n’y a pas de modèle formel pour la prise de décision concernant l’annonce des tâches, les offres et les attributions,
− une seule tâche est annoncée à la fois,
− le problème portique de la congestion des messages d’annonce.
Ainsi, notre choix s’est porté sur le CNP car il est très simple à utiliser et la plupart des projets en gestion de production à base d’agents, ont recours à des stratégies de négociation à base de ce protocole. Les notions les plus importantes pour commencer notre étude ont été présentées globalement, nous décrivons par la suite le système implémenté avec ses différents constituants.