4.3 Méthodologie de formalisation
4.3.3 Réalisation d’une matrice des interactions
Une fois notre table des besoins déterminée, nous analysons quelles interactions doivent avoir lieu entre nos agents. Comme évoqué dans la section4, les agents embarqués peuvent utiliser deux types de messages pour la communica- tion : les requêtes et les réponses. Dans ce cadre, les agents possédant des besoins soumettront des requêtes aux agents possédant les moyens nécessaires. Ces derniers renverront par la suite des réponses avec les informations manquantes. Nous résumons ces interactions grâce à une matrice. Inspirée de celle proposée par le modèle IODA, elle expose des types d’agents Source et Cible. Une interaction est toujours initiée par une Source à destination d’une ou plusieurs Cible(s). Un agent appartenant à une famille peut contacter les autres instances d’agents de celle-ci.
Cette matrice nous permet également de lister les compétences de nos agents : les services. Nous utilisons le symbole ; pour les représenter dans la première colonne de notre matrice. Nous indiquons ainsi qu’ils n’ont pas de cible mais représentent les fonctions internes d’une famille d’agents. Les interactions de type requête ou réponse sont toujours liées à un service. Une requête permet de le déclencher et, si elle avait pour but de combler un besoin, le service se conclura par l’envoi d’une réponse.
Application Liste des services
des agents Cible Source
Agent
Affichage
Agent
Mémoire
Agent
TFD
+ Affichage utilisateur + Gestion mémoire + Calcul TFDAgent
Affichage
Agent
Mémoire
Agent
TFD
+ Ask Gestion mémoire + Answer Gestion mémoire + Answer Calcul TFD + Ask Calcul TFD (1) (1) (1)CHAPITRE 4.Formalisation d’un SMA embarqué Z Y 4.3.Méthodologie de formalisation
Lors de cette étape, nous déterminons également les besoins en termes de nombre d’implémentations des agents pour chaque famille spécifiée. A moins que la tâche complexe ne comprenne explicitement un traitement parallèle, une seule instance d’agent dans chaque famille est suffisante. La possibilité d’intégrer plusieurs instances au sein d’une même famille d’agents sera traitée plus en détail dans la partieIIIde notre mémoire, lorsque nous aborderons des expérimentations concrètes pour les apports des SMA dans les SE.
La Figure4.10présente la construction d’une matrice pour le SMA illustrant notre protocole de formalisation. Nous proposons une seule instance d’agent pour chaque famille. Nous retrouvons les interactions nécessaires pour le partage d’informations. La première étape de notre tâche était l’affichage pour l’utilisateur. Par conséquent le service "Affichage utilisateur" représente le point de départ de notre SMA. Il peut être déclenché par une interaction de type requête initiée par une entité non-agent.
Une fois cette matrice réalisée, nous disposons de toutes les informations nécessaires pour la conception de notre SMA embarqué. Il nous reste à proposer une plateforme pour fournir un contexte d’exécution et d’évolution au sein des systèmes embarqués.
Chapitre 5
MERMAID : une plateforme agent
embarquée
"Dans notre langue, l’expression la plus dangereuse est “nous l’avons toujours fait de cette façon”. C’est pourquoi j’ai une horloge sur mon mur qui va dans le sens inverse des aiguilles d’une montre."
Grace Hopper Mathématicienne, Informaticienne (1906 - 1992)
Les plateformes multi-agents permettent de fournir le contexte intégrant des systèmes de communication, une structure organisationnelle avec gestion administrative du SMA, des fonctions génériques et des ontologies (meta- données, identifiant d’un agent, etc.). Dans la partie 3.1.3 nous avons comparé plusieurs plateformes multi-agents existantes selon les critères pertinents pour notre cadre de recherche :
- le langage de programmation. Notre démarche est de pouvoir intégrer le SMA au plus bas niveau matériel possible. Ce souhait nécessite un langage de programmation adapté, tel que le C. Nous mettons ainsi de côté les langages objets courants dans le domaine multi-agents, comme par exemple Java.
- le modèle agent supporté. Notre méthodologie de conception s’appuie sur des modèles orientés interactions et s’inspire notamment du modèle IODA.
- le domaine d’application. Notre plateforme vise une intégration sur des systèmes embarqués hétérogènes. - la normalisation de la plateforme. En section3.2, nous avons souligné l’importance de standardiser nos
communications. Nous suivons la norme FIPA-ACL.
Les plateformes multi-agents existantes étudiées se focalisent sur d’autres critères d’expérimentation. Nous avons donc décidé de proposer notre propre plateforme agent embarqué : MERMAID.
Pour la réalisation de cette plateforme, en plus des critères de sélection établis, nous prenons garde aux besoins du domaine des SE décrit dans la section 2.1(fiabilité, réactivité et optimisation). Nous prenons notamment parti- culièrement garde à :
- l’architecture. Nous souhaitons à terme pouvoir faire fonctionner notre système multi-agents dans un contexte matériel hétérogène. Selon les composants matériels des SE considérés, il peut être nécessaire d’établir des fonctions de communication différentes ou encore d’adapter le langage de programmation afin d’assurer l’optimisation de l’ensemble. Il est par conséquent primordial d’utiliser une plateforme possédant une archi- tecture modulaire avec des bibliothèques de fonctions indépendantes les unes des autres. Par ailleurs, cette séparation permet également une maintenance facilitée et augmente ainsi la fiabilité de notre système. - les moyens de communication proposés. Nous considérons le fait que notre solution multi-agents sera
appliquée à un SE sans modifier les composants de ce dernier. Cette optique implique de rendre notre plate- forme la plus légère possible en termes d’empreinte mémoire afin de limiter son impact en consommation de ressources. Cette démarche s’inscrit également dans l’optimisation de notre ensemble. Nous utilisons donc des moyens de communication existant dans l’embarqué potentiellement déjà intégrés dans le SE considéré. De plus, en évitant d’ajouter une couche logicielle de gestion des communications nous augmentons la réactivité de notre plateforme.
5.1. Architecture Z YCHAPITRE 5. MERMAID : une plateforme agent embarquée
En chapitre1 nous avions formulé une hypothèse renforçant cet apport de moyens de communications adaptés au domaine de l’embarqué :
◆
✓
⇣
⌘
Le suivi des standards d’administration et d’architecture multi-agents nous permettra de proposer de nouveaux modèles de communication pour une plateforme embarquée.
Rappel hypothèse #2
Dans ce chapitre, nous présentons MERMAID à travers son architecture, son administration et l’organisation des différents SE l’intégrant.
5.1
|
Architecture
Une architecture modulaire est primordiale dans le domaine des systèmes embarqués. Elle permet d’augmenter la fiabilité du système en regroupant les fonctions selon leur utilité et leur généricité. En effet, il est alors possible de valider le fonctionnement des librairies au fur et à mesure. Par ailleurs, les bibliothèques de fonctions pourront être ré-utilisées pour d’autres projets. Cette forme d’architecture facilite également l’ajout de systèmes de redondance. De plus, nous souhaitons pouvoir étendre notre système multi-agents à plusieurs SE, homogènes ou hétérogènes. Dans ce cadre, une architecture en plusieurs parties permet d’adapter les couches impactées par le changement matériel sans forcément devoir modifier l’ensemble de la plateforme. Nous avons par conséquent adopté ce type d’architecture pour assurer l’indépendance des différents outils apportés par la plateforme.
L’architecture de la plateforme MERMAID est structurée en deux parties : une couche de communication et une couche d’administration et de gestion. Cette dernière regroupe d’une part une interface de programmation avec toutes les fonctions relatives à l’évolution des agents et d’autre part les agents administratifs de la norme FIPA. En effet, a contrario d’un agent purement applicatif, ces trois agents ne varient pas entre deux SMA. Nous considérons également une couche applicative représentant les agents basés sur MERMAID. La Figure 5.1 présente l’ensemble de notre architecture. La partie administrative de MERMAID avec les agents AMS, ACC et DF issus de FIPA est considérée comme un bloc à part. Les autres blocs sont regroupés sous le terme de noyau de MERMAID. A partir de ce noyau, notre plateforme offre d’ores et déjà un contexte de déploiement avec systèmes de communication et structure organisationnelle. Il doit donc être inclus dans chaque SE intégrant nos agents pour assurer l’interopérabilité de l’ensemble du SMA. Le bloc d’administration, quant à lui, doit être inclus dans une seule plateforme MERMAID dans un contexte multi-cartes.