Retour à la page d'accueil de l'action TOLERE
INRIA Rocquencourt, le 18 décembre 1998
L'architecture matérielle du Cycab est constituée de 5 noeuds de calcul reliés par un bus CAN. Plus un PC pour l'interface utilisateur, mais il ne fait pas partie de l'architecture critique du système. En particulier il ne gère pas le joystick qui permet de contrôler le Cycab. Les 5 noeuds sont réparti ainsi : 1 pour chaque roue (donc 4 au total), et 1 pour le joystick et la direction.
Les pannes qui peuvent se produire sont :
Par panne on entend défaillance matérielle provoquant un arrêt des communications. Dans le cas d'un noeud, cela signifie que celui-ci ne communique plus avec le CAN et donc avec les autres noeuds. Dans le cas du CAN cela signifie que tous les noeuds sont isolés.
Notons toutefois que cette architecture offre une forme limitée de redondance puisque chaque roue est motrice. Cette redondance limitée permet en cas de panne de fonctionner dans un mode dégradé. Par exemple si le noeud d'une roue est en panne et que cette roue est libre, alors on peut toujours faire avancer le Cycab grâce aux trois autres roues, au moins le temps de le mettre sur le côté de la route. Cependant, une telle panne peut aussi entraîner le blocage de la roue par le frein électromagnétique. Dans ce cas, il peut être beaucoup plus difficile et dangereux d'essayer de déplacer le véhicule à l'aide des trois autres roues.
L'architecture matérielle du Vortex est constituée de 2 noeuds de calcul reliés par un réseau Ethernet : 1 noeud pour le bras manipulateur et 1 pour le corps du sous-marin.
Contrairement au Cycab, cette architecture n'offre aucune forme de redondance. Toutefois, la perte du noeud du bras ou du réseau ne doit pas entraîner la perte du sous-marin puisque le corps peut assurer les déplacements du sous-marin indépendamment du bras.
Comme on le constate, les architectures auxquelles on s'intéresse ne sont pas prévues pour la tolérance aux pannes. En particulier elles n'offrent, dans le meilleur des cas, qu'une redondance limitée. Par conséquent la tolérance aux pannes que l'on désire réaliser doit être basée sur le logiciel.
Notre principale contrainte est d'assurer qu'en cas de panne d'un noeud, le reste du réseau et des autres noeuds continue à fonctionner. En effet, les communications inter-noeud sont des lectures/écritures dans une file d'attente à une seule case : l'écriture est bloquante quand la file est pleine, et symétriquement la lecture est bloquante quand la file est vide. Ce mécanisme offre l'avantage de permettre, en une unique communication, à la fois d'échanger une donnée et de synchroniser les deux noeuds. L'inconvénient est que le blocage d'un noeud entraîne de proche en proche le blocage de tout le système.
Nous prévoyons de mettre au point un nouveau protocole de communication permettant à un noeud de savoir si d'autres noeuds sont en panne, et surtout de ne pas être bloqué par la panne éventuelle d'une autre noeud. Les autres aspects de la tolérance aux pannes (fonctionnalités du mode dégradé, type de rattrapage ...) doit être programmé dès le départ dans l'application.
Envoyez vos commentaires à Alain Girault à Alain.Girault@inrialpes.fr.
Dernière modification : 6 janvier 1999