Home header
Linux temps réel embarqué et outils de développements Technique





Auteurs

Ce composant à été réalisé par le SLA/LLSP du C.E.A.

Objectifs

Les objectifs principaux du lot Tolérance aux Fautes dans OCERA concernent la fourniture de deux types de fonctionnalités : la gestion de modes dégradés dans le cas d'applications mono-noeud et la gestion de redondance dans des environnements distribués.

Le développement des fonctionnalités de tolérance aux fautes sont décomposés en deux classes :

  • Applications Mono-noeud

Dans ce contexte, la tolérance aux fautes consiste à fournir des composants permettant de prendre en charge deux types de situations anormales : dépassement d'échéance (pour les tâches temps réel dur) et disparition anormale de tâches (abort) suite à une erreur logicielle.
Dans une première phase du projet, les fonctionnalités développées concernent la mise en place de mécanismes de gestion de modes dégradés à deux niveaux (niveau tâche et niveau application). La seconde phase, verra la mise en place de la gestion de blocs de recouvrement et la gestion de calcul imprécis. De plus, l'implémentation de la gestion de modes dégradés fournira une base pour l'implémentation d'un modèle plus général de gestion d'applications multi-mode.
Architectures distribuées.
Il s'agit ici de proposer des composants chargés de la gestion de la redondance dans des architectures multi-noeuds. L'objectif est de permettre la continuité de service en présence de défaillance d'un ou plusieurs noeuds (selon le niveau de redondance choisi). Les composants développés dans ce contexte s'appuieront sur les composants de communication.

Pour atteindre ces objectifs, un cadre méthodologique global pour la conception d'une application temps réel tolérante aux fautes ainsi que des outils de support à la programmation sont définis


Etapes de développement

Version V1 : Gestion de modes dégradés

La première version (V1) des composants de tolérance aux fautes propose des fonctionnalités de base pour la gestion de modes dégradés. L'objectif est de mettre en place un cadre général de programmation et une méthodologie de développement pour l'utilisateur. Une fois ce cadre minimal mis en place les fonctionnalités seront étendues. La version initiale concerne les applications limitées à des tâches temps réel dur. Deux composants RTLinux ont été développés : un moniteur d'application (ftappmon) en charge de la gestion des modes à un niveau application et un contrôleur de tâches (ftcontroller) en charge du suivi des tâches, de la detection d'erreur et de la notification de celles-ci. Ensemble, ils mettent en place des mécanismes transparents de recouvrement d'erreur respectivement au niveau application et tâche.


Version V2 : Gestion de redondance

Les développements relatifs à la seconde version (V2) concernent d'une part l'enrichissement des composants de la version V1 et la prise en compte d'architectures plus complexes. Les extensions de la version V1 concernent notamment la prise en compte de deux niveaux de tâches gérés respectivement par le micro noyau RTLinux et par le noyau Linux. Chaque composant de tolérance aux fautes existant devra ainsi être redéfini sous forme de composants coopérants répartis sur chacun des niveaux. Cette coopération nécessite de mettre en place un mécanisme de synchronisation garantissant un temps de réponse borné entre la détection d'un événement anormal et le changement effectif de mode éventuellement nécessaire au niveau application.

Les nouveaux développements concerneront la mise en place des mécanismes de gestion de redondance et de reconfiguration dynamique en cas de perte de noeuds. Deux composants spécifiques seront développés à cet effet : un gestionnaire de redondance (ftredundancymanager) et un gestionnaire de répliques (ftreplicamanager). Le premier sera en charge de la gestion de la redondance à un niveau application , le second, à un niveau tâche sur chaque noeud. Ces composants s'appuieront sur les composants de communication développés par ailleurs.

Composants de la Version V1 : Gestion de modes dégradés

Principes généraux

La gestion de la tolérance aux fautes dans OCERA repose sur la base d'une approche déclarative combinée à la mise en place de mécanismes permettant la gestion transparente du recouvrement d'erreur. De cette façon, le codage de l'application elle-même n'est pas tributaire des évolutions du niveau d'exigence des besoins en matière de tolérance aux fautes ou de qualité de service. L'avantage est double, d'une part, le code écrit par le développeur reste entièrement dédié à l'application elle-même (donc plus simple), d'autre part les évolutions des contraintes ne remettent pas en cause le codage. De plus, la prise en compte de telles contraintes non fonctionnelles a des implications globales qui nécessitent leur prise en compte de manière consistante pour toute l'application. Seule une gestion externe au code peut garantir une telle cohérence dans les évolutions.

Cette approche déclarative force l'utilisateur à spécifier les conditions de transitions (conduisant à des changements de comportement ou de modes de fonctionnement) au niveau des tâches mais aussi à celui de l'application. Ceci permet de définir de manière déclarative la manière de gérer les situations anormales. Les conditions de transitions ainsi définies sont utilisées pour instancier les mécanismes de gestion de handlers.

Le role des composants développés (ft components) est d'assurer de manière transparente et fidèle à la spécification des commutations et de la mise en place de modes de fonctionnements dégradés aux niveaux tâches et application. Une attention particulière est portée au maintien de la cohérence logique et temporelle globale de l'application ainsi qu'à une gestion propre des ressources liées à des tâches défaillantes (libération des ressources associées).

Les principes directeurs de la gestion de modes dégradés sont les suivants : lorsqu'une erreur est détectée au niveau tâche, un changement de comportement de la tâche concernée est appliqué (activation d'un thread jusque là suspendu) par le ftcontroller, celui-ci notifie le niveau application (ftappmon) de l'événement anormal qui prend la décision éventuelle d'effectuer un changement de mode de l'application. Le cas échéant cela revient à sélectionner une nouvelle configuration de tâches et de comportements associés pour l'application et à transmettre les ordres d'activation, d'arrêt ou de commutation au niveau tâche (ftcontroller) pour la mise en oeuvre effective du nouveau mode de fonctionnement.



FT components for Mode Management


L'approche décrite ci-dessus est supportée par trois composants : le ftbuilder, un outil hors ligne de configuration de l'application qui permet de spécifier les contraintes temporelles, les comportements, les modes de fonctionnement de l'application et les conditions de transitions et deux composants run-time : ftappmon et ftcontroller décrits dans la section suivante.



Composants en ligne (run-time)

ftappmon

Le composant FT application monitor (ftappmon), a pour role de maintenir la connaissance sur l'état global de l'application et d'analyser les éventuelles conséquences d'une situation anormale (disparition d'une tâche ou dépassement d'échéance). Il est responsable de la décision de changement de mode éventuel de l'application et de la sélection du nouveau mode à activer. Il fonctionne en étroite association avec le composant ftcontroller à qui il donne les instructions de démarrage, d'arrêt et de commutation de tâches et dont il reçoit les notifications d'événements anormaux. Les deux composants doivent donc être utilisés conjointement.

ftcontroller

Le composant ftcontroller est un composant bas niveau qui gère les situations anormales relatives aux threads de l'application (erreurs temporelles at/ou abort). Il active également un comportement de remplacement prédéfini pour tout thread défaillant. La réalisation pratique de ce composant s'appuie sur le mécanisme de trace POSIX développé par l'Université de Valence (ES). Celui-ci inscrit dans une stream les événements système détectés (et filtrés selon les besoins du ftcontroller). Le ftcontroller analyse ensuite ces traces de manière à détecter tout événement anormal. Le cas échéant, sur destruction d'un thread ou dépassement d'échéance, il active un thread de remplacement avec un mode de fonctionnement dégradé et envoie une notification au composant ftappmon

Composant d'aide à la conception

ftbuilder

Le composant ftbuilder est un outil de spécification qui permet à l'utilisateur de définir les contraintes temporelles associées aux tâches de l'application ainsi que les différents comportements possibles (actuellement normal et dégradé). Il permet aussi de définir des configurations de l'application (appelées modes de fonctionnement) caractérisées par l'ensemble des tâches actives dans un mode donné ainsi que le comportement (normal ou dégrader) à observer pour chacune de celles-ci. Enfin, il permet de définir les conditions de transition de mode.

A partir des informations ainsi réunies, l'outil génère des fichiers qui permettent l'initialisation de tables utilisées par les composants ftappmon et ftcontroller. Ces fichiers sont compilés avec les fichiers écrits par l'utilisateur qui eux concernent plus particulièrement l'écriture du code des tâches (body des comportements normaux et dégradés). Dans la seconde phase du projet, il permettra de définir les tâches répliquées et leur localisation.


©M.N.I.S Société | Produits | Services | Formations | Support | Partenariat | Presse | Téléchargements ©M.N.I.S