Conclusion et positionnement de la thèse

Après avoir consacré le deuxième chapitre à la présentation de la migration des processus dans des machines homogènes et hétérogènes, dans ce chapitre, nous nous sommes intéressés au domaine des agents mobiles. Nous avons commencé par définir le concept d’agent. Ensuite, nous avons présenté les efforts de standardisation des plateformes d’agents mobiles, à savoir les normes MASIF et FIPA, pour promouvoir l'interopérabilité. Les deux normes offrent une description textuelle des concepts de:

 Système d’agents, la place, la région, etc. dans le cas MASIF;

 Système de gestion d'agents, le service de transport de messages, la plateforme d'agents, etc. dans le cas FIPA.

Les deux normes offrent aussi des représentations graphiques pour illustrer les liens entre ces concepts.

Nous avons aussi présenté les travaux sur la modélisation des systèmes à base d'agents mobiles selon deux grandes classes:

 La modélisation structurelle qui permet d’illustrer l’architecture générale d’un système, ses composants ainsi que ses différents types de liens d’interactions;

 La modélisation comportementale qui met l’accent sur l’évolution et l’interaction des agents mobiles dans leur environnement réparti.

Dans ce chapitre, nous avons également décrit des exemples de plateformes telles que Voyager, Mobile-C et JADE pour illustrer la mise en œuvre des concepts d’agents mobiles. Des descriptions détaillées des plateformes d’agents mobiles se trouvent dans l’annexe A. Le paradigme agents mobiles est utilisé dans un certain nombre de domaine dont nous avons présenté les exemples d’applications.

Nous avons aussi présenté des évaluations de performances entre le paradigme d’agents mobiles et le modèle traditionnel client-serveur dans deux différents domaines d’application: la recherche d'information et la gestion de réseau.

Les agents mobiles offrent des avantages mais présentent aussi des difficultés par rapport aux paradigmes de programmation plus classiques. Pour illustrer les avantages offerts par l’utilisation des agents mobiles, nous avons présenté les domaines d’application comme la réduction du trafic réseau, les calculs indépendants et la tolérance aux fautes physiques. Ils permettent aussi de mieux caractériser certaines applications.

Certes la technologie des agents mobiles offre des avantages mais elle vient aussi avec son lot d’inconvénients dont les principaux sont:

 Le manque de standardisation entre le grand nombre de plateformes d’agents mobiles. Malgré les efforts de standardisation de MASIF et FIPA, cette vaste gamme de plateformes ne facilite pas l’interopérabilité d’agents issus de différents organismes. Il en résulte une très grande incompatibilité entre les différentes plateformes [Romito, 2012].

 La difficulté de sécuriser les plateformes d’agents mobiles: Le plus gros obstacle actuel à l’utilisation de cette technologie [Roth, 2004] demeure le manque d’une protection d’agents mobiles contre les attaques de plateformes malveillantes.

Dans ce chapitre, nous avons également présenté différents types de migration de programme qui peut être classifiés selon deux grandes caractéristiques. La première est la prise de décision de la migration: proactive ou réactive. Lorsque la migration est provoquée par une unité extérieure de l’application, on parle alors d’une migration réactive. En revanche, si la migration est à l’initiative du code de l’application, nous parlons d’une migration proactive et ceci donne de l’autonomie aux agents. Et c’est précisément cette autonomie qui différencie les agents mobiles de la migration de processus. La seconde caractéristique est le degré de mobilité de l’application, à savoir les migrations forte, faible ou du code seulement. Le choix de degré de mobilité dépend du type de l’application mais nous estimons que la migration forte offre plus de capacité aux agents.

Après avoir étudié la migration de processus (chapitre 2) et les agents mobiles (chapitre 3), nous avons constaté qu’il n’existe pas des plateformes d’agents mobiles pour systèmes embarqués temps réel supportant la mobilité forte. Bien que la plateforme Mobile-C, par exemple, soit conçue spécialement pour les systèmes embarqués temps réel, celle-ci ne supporte pas la mobilité forte. En outre, la plateforme Mobile-C n’est pas destinée pour les systèmes des ressources très limitées. Un programme Mobile-C peut prendre un espace de mémoire de l’ordre de 6 Mo [Mobile-C, 2011]. Cet espace de mémoire est trop gros pour de nombreux systèmes embarqués. En effet, ces systèmes utilisent un espace de mémoire de l’ordre de centaines de kilooctets seulement.

3.7.1 Solutions existantes de migration et les systèmes embarqués temps

réel

Les solutions de migration de processus/agents proposées jusqu’ici ne fonctionnent que sur des machines ayant plus de ressources: un espace mémoire de grande taille, un module matériel pour la gestion de mémoire, etc. La principale caractéristique de ces machines reste

leur fonction de mémorisation. Celle-ci est organisée en plusieurs niveaux de mémoire qui réalisent ainsi une hiérarchie de mémoire dont le but principal consiste à simuler l’existence d’une mémoire rapide de grande capacité. Dans cette hiérarchie, les mémoires les plus proches du processeur sont les plus rapides mais aussi les plus petites en capacité. En revanche, les mémoires les plus éloignées du processeur sont les plus lentes mais aussi les plus grandes en capacité. En effet, les solutions existantes de migration de processus/agents ne sont basées que sur des machines supportant les mécanismes de mémoire virtuelle. Pour déployer un système d’exploitation supportant la mémoire virtuelle comme Windows ou Linux, la machine hôte doit avoir un espace de mémoire disponible de l'ordre des centaines de mégaoctets. De plus, il faut ajouter à cela un espace de mémoire utilisé par une machine virtuelle dans le cas de migration d’agents/processus dans les systèmes hétérogènes.

En somme, les solutions existantes de la mobilité d’agents/processus ne sont pas utilisables dans le contexte des systèmes embarqués en raison de ressources limitées. De manière générale, les systèmes embarqués sont soumis aux contraintes suivantes [Babau, 2005]:

 Le faible espace mémoire disponible;

 Le temps réel lié aux exigences du procédé contrôlé ou aux utilisateurs vis-à-vis des applications supportées;

 L’autonomie limitée en matière d’énergie due à l’utilisation de batterie;

 L’enfouissement: l’absence d’une interface homme-machine ou le manque de connexion à un réseau fixe, etc.;

 L’optimisation du coût de production;

 Les contraintes physiques de l’application (électriques, mécaniques et thermiques);  Ou encore de nature ergonomique à cause de la taille réduite des systèmes pour assurer

leur portabilité ou leur intégration dans un système physique.

L’apport unique et l’originalité du travail accompli dans cette thèse résident dans la conception ainsi que dans la mise en œuvre d'une plateforme d’agents mobiles pour système embarqué temps réel. À titre comparatif, le tableau 3.2 présente une grille d’évaluation entre les caractéristiques principales du système de migration d’agents réalisé dans le cadre de cette

thèse et celles des systèmes existants. Nous avons nommé µC/MAS (pour Microcontroller Mobile Agent System) notre plateforme d’agents mobiles pour systèmes embarqués.

Comme nous avons déjà décrit, les systèmes de migration de processus/agents au niveau application peuvent offrir, dans certains cas, une migration forte. Cependant, comme ces systèmes ne sont pas en mesure d'accéder à l'état d'exécution complet d'un processus ils peuvent, parfois, ne pas tenir en compte des résultats intermédiaires. C’est le cas du système Wasp qui entraine une migration incomplète. Le Tableau 3.2 tient aussi compte de la complétude de l’état d’exécution.

Tableau 3.2 Comparaison des systèmes traitant la mobilité

Caractéristique Système Degré de mobilité Complétude de l’état d'exécution Type de mobilité

Empreinte mémoire Nécessité d’un MMU pour fonctionner Systèmes embarqués temps réel µC/MAS Forte Oui Proactive De l’ordre des dizaines de Ko Non Oui Mobile-C Faible Non Proactive De l’ordre des dizaines de Mo Oui Oui Tui Forte Oui Proactive De l’ordre des dizaines de Mo Oui Non CTS Forte Oui Proactive De l’ordre des centaines de Mo Oui Non ITS Forte Oui Proactive De l’ordre des centaines de Mo Oui Non Wasp Faible Non Proactive De l’ordre des centaines de Mo Oui Non JavaGo Faible Non Proactive De l’ordre des centaines de Mo Oui Non Brakes Faible Non Proactive De l’ordre des centaines de Mo Oui Non JavaGoX Faible Non Proactive De l’ordre des centaines de Mo Oui Non MOSIX Forte Oui Réactive De l’ordre des centaines de Mo Oui Non Charlotte Forte Oui Réactive De l’ordre des centaines de Mo Oui Non Système V Forte Oui Réactive De l’ordre des centaines de Mo Oui Non Accent Forte Oui Réactive De l’ordre des centaines de Mo Oui Non Sprite Forte Oui Réactive De l’ordre des centaines de Mo Oui Non Choices Forte Oui Réactive De l’ordre des centaines de Mo Oui Non Smile Forte Oui Réactive De l’ordre des centaines de Mo Oui Non RHODOS Forte Oui Réactive De l’ordre des centaines de Mo Oui Non Mach Forte Oui Réactive De l’ordre des centaines de Mo Oui Non Voyager Faible Non Proactive De l’ordre des centaines de Mo Oui Non JADE Faible Non Proactive De l’ordre des centaines de Mo Oui Non