Dans le Chapitre 2, nous avions distingué trois types de modification du graphe de composant :
1. La reconfiguration : Changement de l’état d’un composant (Le Secondaire du PBR qui devient Primaire suite à la défaillance de celui-ci) ;
2. L’adaptation entre deux FTM : Transition d’un FTM vers un autre en cas de changement de contexte applicatif (AC, RS)
3. La composition de FTM : Assemblage de deux FTM pour tolérer un nouveau modèle de fautes en plus de l’ancien.
Ces trois types de modification impliquaient trois méthodes distinctes, respec- tivement une manipulation des communications inter-répliques pour la reconfigu- ration, une substitution des composants Before et After d’un FTM par ceux d’un autre pour l’adaptation, et enfin la substitution du composant Proceed par un en- semble P-BPA pour la composition.
L’approche par objets ordonnançables va permettre d’uniformiser les différentes méthodes et va faire de la reconfiguration et de la composition des sous-ensembles de l’adaptation. Comme nous avions pu le voir sur la sous-machine d’état de transition (figure 4.8 page 122 de la section 1.5), l’adaptation consiste en trois opérations :
1. Suppression des plugins contenant les actions de SdF obsolètes ; 2. Instanciation des plugins valides ;
3. Mise à jour de la map contenant l’algorithme d’ordonnancement.
La reconfiguration et la composition reprennent les opérations 2 et 3 pour la com- position et l’opération 3 pour la reconfiguration.
Ainsi, lors d’une demande d’adaptation du Moniteur après validation de l’Opé- rateur, l’Adaptive Entity va changer la valeur d’une variable (un flag) qui va per- mettre de rentrer dans l’état de transition. Nous n’avons pas implémenté la partie
de formatage de la liste d’objet et de transition mais avons directement prévu la modification du graphe dans le Gestionnaire d’Objets. Ainsi, l’Adaptive Entity va transmettre au Gestionnaire d’Objets le FTM à mettre en place et ce dernier va effectuer les modifications demandées.
Prenons trois scénario et analysons les méthodes utilisées dans ces trois scénarios puis construisons notre Adaptation Entity et complétons notre Gestionnaire d’objet à partir de ceux-ci.
Le premier scénario correspond à la perte du Primaire dans le cas du PBR. En fonctionnement nominal, le Primaire et le Secondaire sont identiques dans leur constitution. Le Primaire a cependant une table d’orchestration complète alors que le Secondaire n’effectue que l’action de mise à jour d’état sur réception d’un message de checkpoint. Le Primaire subit un crash de sa plate-forme matérielle, le WatchDog du Secondaire le détecte et envoie un message au composant de Recouvrement identique à la première approche. Le composant de Recouvrement envoie un message à l’Adaptation Entity du Secondaire. Ce dernier signale au Gestionnaire le besoin d’une reconfiguration, le Gestionnaire reconstruit la map du Secondaire identique à celle du Primaire puis l’Ordonnanceur la récupère.
Le deuxième scénario correspond à la composition d’un PBR et d’un TR. Le PBR est constitué des objets de communication et d’un Gestionnaire d’État avec checkpoint. Le TR est constitué d’un Gestionnaire d’État sans checkpoint et d’un Comparateur. Le Moniteur envoie un ordre de composition à l’Adaptive Engine qui sélectionne les mécanismes à composer. Ce dernier envoie à l’Adaptation En- tity les mécanismes à mettre en place et sélectionne les objets du TR à ajouter au graphe d’action puis transmet la liste au Gestionnaire. Le Gestionnaire instan- cie dynamiquement les plugins du TR, reconstruit la map et la transmet à l’Ordonnanceur.
Le troisième scénario correspond à l’adaptation entre un PBR+TR et un LFR+TR. Pour effectuer cette adaptation, il faut supprimer le Gestionnaire d’État avec checkpoint, instancier dynamiquement les plugins de Synchroni- sation et reconstruire la map avant de la transmettre à l’Ordonnanceur comme l’illustre la figure 4.10.
Ainsi, les opérations utilisées pour l’adaptation sont réutilisées pour la compo- sition et la reconfiguration. Il n’y a donc plus de différence significative concernant les méthodes des objets statiques du FTM entre ces trois modifications. Si nous voulons faire une reconfiguration, nous reconstruisons seulement la map. Si nous voulons faire une composition, nous effectuons instancions dynamiquement les plu- gins et nous reconstruisons la map.
Avec ces trois scénarios, nous avons défini les actions de l’Adaptive Entity. Il faut que celui-ci puisse recevoir des messages de la part du Moniteur qui sélectionne les mécanismes à mettre en place mais également du composant de Recouvrement dans le cas d’une détection de crash comme l’illustre la figure 4.11. De plus, il lui faut qu’il puisse sélectionner les plugins en fonction des mécanismes choisis et une action de transmission de la modification du graphe d’actions au Gestionnaire.
3. Implémentation des FTM sous ROS 139
alt
Monitor +
Opérateur Adaptive Entity Object Manager Scheduleur
System Adaptation checkBandwidth() bandwidth adapt(LFR) checkCurrentFTM() selectObject(LFR) adapt(LFR) Application SIGSTOP deleteObject(List) launchObject(List) constructMap(LFR) setMap(map) success getMap(map) SIGCONT schedule() FTM: PBR - Action de SdF: State Management FTM: LFR. - Action de SdF: Transfert de Requête Synchronisation
Figure4.10 – Diagramme de séquence d’une adaptation
Recovery
Moniteur
Ordre
adaptation compositonOrdre
Opérateur Adaptative Entity demande pour adaptation décision pour adaptation Ordre de reconfiguration Arrêt du graphe d'actions
Figure4.11 – Interaction entre les processus externes et l’Adaptation Entity
Nous allons maintenant comparer cette approche avec celle du Chapitre 2 et examiner notre réponse aux problèmes de ressources. De plus nous auront une analyse critique de cette approche pour en déterminer les défauts qui pourraient la rendre moins appropriée à l’utilisation que l’approche par composants substituables.
4
Analyse critique de la nouvelle approche
Dans cette section, nous allons évaluer si cette approche résout les problèmes soulevés par l’approche par composants substituables concernant les ressources uti- lisées. Nous avons déjà pu constater que cette approche intègre facilement et natu- rellement l’optimisation faite sur la réutilisation de code et l’affinage de la granu- larité du Chapitre 3. Il nous faudra également avoir un point de vue critique sur cette approche et analyser si cette approche ne soulève pas d’autres problèmes de conception ou d’implémentation.
Nous analyserons, en premier lieu, les différences fondamentales entre un nœud ROS et un plugin ROS. En second lieu nous comparerons les avantages conceptuels de cette approche par objet ordonnançable vis-à-vis de l’approche par composants substituables. Enfin, en troisième lieu, nous évaluerons les aspects négatifs de cette approche.