1.4 Conclusion
2.1.2 Une alternative : le type d’architecture multi-agents
Le type d’architecture multi-agents, présenté dans le chapitre précédent, a été développé comme alternative au type d’architecture hiérarchisé, et propose des solutions à certains des problèmes évoqués ci-dessus. Le concept multi-agents a été mis en avant avec l’architecture IDEA [Muscettola et al. 2002], mais peu de systèmes l’ont actuellement mis en pratique, d’une part à cause de sa nouveauté, d’autre part parce que son implantation reste complexe.
Un agent de l’architecture IDEA, présenté dans la Figure 2.1, comporte cinq éléments :
• L’enveloppe de communication sert d’interface avec d’autres agents du sys- tème, et éventuellement avec la couche matérielle. Il n’y a pas de restriction sur la topologie des communications entre composants : par exemple deux composants peuvent se commander mutuellement.
• Le modèle contient la représentation du système et de son environnement du point de vue de l’agent. Chaque agent ne possède qu’une partie d’un modèle global unique, généralement trop complexe pour être traité par un seul planificateur.
• Le planificateur produit un plan à partir de l’état du système maintenu dans la base de données du plan, des objectifs fournis par les requêtes de l’utilisa- teur ou d’autres composants IDEA, et des contraintes et heuristiques four- nies par le modèle. Suivant le composant, plusieurs types de planification peuvent être envisagées : une planification à court terme, une planification à long terme, ou une combinaison des deux. Dans ce dernier cas, le planifi- cateur à long terme définit des plans flexibles (notamment temporellement) que le planificateur à court terme complète au fur et à mesure du déroule- ment du plan.
• L’exécutif met à jour la base de données du plan, active le planificateur à la réception d’une requête ou d’un bilan, et exécute la suite de requêtes de- mandées par le planificateur.
• La base de données du plan représente l’état actuel de la partie du système liée à l’activité de l’agent, ainsi que son évolution passée, et le comportement futur prévu par le planificateur. Elle est mise à jour par l’exécutif lors de
2.1 Aspect architectural
41
de l’activité du système requêtes à remplir des requêtes exécuteesenveloppe de communication du plan
requêtes demandees bilans reçus vérification de la informations contraintes et heuristiques
mise à jour du plan nouveaux
objectifs
plan modèle
planificateur
exécutif base de données
et requêtes envoyés et requêtes reçus bilans bilans bilans cohérence des mise à jour
Figure 2.1: Agent IDEA
la réception de bilan, et le planificateur lorsqu’il développe ou complète un plan.
2.1.2.1
Réponses aux limites d’une architecture hiérarchisée
Dans l’architecture IDEA, les différents composants d’un agent partagent la même vision du système, contenue dans la base de données du plan, ce qui limite fortement les désaccords temporels, sémantiques ou syntaxiques à l’intérieur d’un même agent. De plus, les modèles des différents agents sont obtenus à partir d’un modèle global unique du système, ce qui réduit les chances de désaccord séman- tique ou syntaxique entre agents. Des désaccords temporels entre agents sont par contre possibles, puisqu’il faut du temps aux bilans pour être remontés et traités par les différents composants de l’architecture qui sont concernés par une éven- tuelle évolution de l’environnement ou du système.
La réactivité des différents composants du système est plus importante que dans un type d’architecture trois niveaux. En effet, chaque agent, et les fonctions du système que chacun englobe, disposent de mécanismes décisionnels, ce qui as- sure une plus grande robustesse au plus tôt dans le système, en permettant de répondre plus rapidement à une situation adverse imprévue. Le temps de plani- fication, fonction de l’horizon du planificateur, est de plus modulable dans une certaine mesure : les agents possédant un horizon court se retrouvent générale- ment près de la couche matérielle, pour permettre une plus grande réactivité.
En ce qui concerne la criticité du mécanisme décisionnel, l’architecture de type multi-agents n’offre pas de solution satisfaisante. En effet, si le mécanisme déci- sionnel n’est pas centralisé comme dans le type d’architecture hiérarchisé, il reste fondamental à chaque agent, et tout aussi vulnérable. La structure en multiples composants autonomes offre théoriquement des possibilités de confinement d’er-
42
Chapitre 2 - Architectures et Méthodes
reur et de reprise, mais une faute de conception dans les connaissances ou le mé- canisme d’inférence d’un agent se retrouvera également dans les autres agents. Des fautes physiques peuvent être tolérées de cette manière, à la condition coû- teuse que chaque agent s’exécute sur un processeur dédié. La mise en œuvre des mécanismes de détection d’erreur et de rétablissement se heurtent également aux différents problèmes de tolérance aux fautes particuliers aux mécanismes déci- sionnels3.
2.1.2.2
Inconvénients spécifiques au type d’architecture multi-agents
En plus des problèmes liés à la criticité du mécanisme décisionnel, non-résolus dans ce type d’architecture, un système multi-agents nous semble soulever des difficultés particulières de conception et de validation.Tout d’abord, le développement se focalise sur les fonctionnalités de chaque agent, définissant indirectement plutôt que directement les fonctionnalités du sys- tème. Les différentes étapes de conception du système (décomposition en agents, détermination du rôle de chaque agent, développement du modèle global) nous semblent également plus complexes et délicates que dans la conception d’un type d’architecture hiérarchisé. De plus, si le comportement d’un agent ou, à plus haut niveau, d’un groupe d’agents peut être en partie validé séparément par des en- vois de requêtes ou de bilan, la validité de la décomposition du système ne peut être testée qu’une fois le système complètement intégré, et une erreur dans cette décomposition sera très coûteuse pour le développement du système.