Retour à la page d'accueil de l'action TOLÈRE
INRIA Rocquencourt, le 8-10 mars 2000
Les pannes des capteurs peuvent être classifiées, comme les pannes des processeurs, dans trois classes, les deux premières pouvant paraître dans le même temps :
valeurs erronées envoyées par le capteur à la suite d'une perturbation accidentelle,
réponse retardée sur une demande d'échantillonage, et
non-réponse sur une demande d'échantillonage.
La litterature propose comme solutions la redondance des capteurs, c'est-à-dire que chaque capteur est répliqué un nombre de fois égal à 1 plus le nombre de pannes à tolérer. Cette solution est combinée avec les algorithmes dits « d'agrément byzantin » dans le cas du premier type de pannes, et avec l'emploi de « chiens de garde » dans les deux autres cas. Donc les solutions que l'on peut envisager d'implanter automatiquement sont les mêmes que les solutions trouvées pour la tolérance aux pannes des processeurs. Cependant, on doit observer que les solutions proposées ont des implications au niveau de la spécification, car elles impliquent la modification de l'architecture en ajoutant des capteurs.
Par contre, les pannes des actionneurs sont beaucoup moins traitées au niveau général. Les références portent seulement sur des problèmes spécifiques, tels que l'articulation d'un robot ou un véhicule automatique, et les solutions proposées viennent exclusivement de l'automatique. Par exemple, la redondance partielle des actionneurs dans l'articulation d'un robot, ou la possibilité que chaque roue sur un véhicule soit actionnée par un moteur différent. De plus, dans certains cas on ne peut pas envisager une redondance totale : pour des raisons de sécurité, la panne d'un moteur sur un véhicule provoque le blocage de l'axe ; donc même si on met deux moteurs sur le même axe, la redondance n'apporte rien. On peut conclure que la tolérance aux pannes des actionneurs ne peut être transparente au niveau de la specification du problème, ni même qu'une procédure automatique (par exemple l'ordonnanceur SynDEx) ne peut aider au développement d'une spécification tolérante aux pannes. Par conséquent, ce problème ne peut être résolu qu'au niveau de la specification.
La même chose se passe avec les modes degradés de fonctionnement. Catalin n'a trouvé aucun traitement général de ce problème. Il argumente que c'est dû au fait qu'un mode degradé doit être pris en compte aussi au niveau de la spécification. Pour un logiciel qui doit faire un ordonnancement tolérant aux pannes d'un graphe algorithme générique sur un graphe architecture, un mode degradé ne represente qu'une branche conditionnée dans le graphe.
Catalin ouvre la discussion sur le problème du calcul des valeurs des chiens de garde, pour lequel on doit prendre en compte une certaine dérive entre les dates de début des opérations initiales dans chaque cycle de l'algorithme (i.e. opérations qui ne sont précédées, dans la relation de dependence de données, d'aucune autre opération). Cristophe explique comment on fait de la resynchronisation dans certains cas : le principe est d'avoir un certain processeur maître qui est chargé de « compter le cycle » et d'émettre, chaque fois qu'il déclenche un nouveau cycle, un message à tous les autres processeurs afin que ceux-ci se resynchronisent. Les autres processeurs eux aussi comptent les cycles et remettent à zéro leur timer à la fin de chaque cycle. Lorsqu'un processeur reçoit le message de resynchronisation, il compare la valeur de son timer et fait l'ajustement nécessaire au cas où les valeurs sont différentes. Catalin argumente que si on veut tolérer des pannes dans les processeurs, on devra faire un « agrément byzantin » sur les valeurs des timers.
On se met d'accord sur le fait que les valeurs des chiens de garde se calculent à partir de la date la plus ancienne d'exécution d'une opération, et de la dérive maximale qui peut apparaître entre les dates des débuts des cycles calculés par chaque processeur. Les valeurs calculées ainsi se rapportent au début du cycle et non à l'intervalle entre la fin d'une opération sur un processeur et le début de l'opération qui suit dans l'ordonnancement sur le même processeur.
On se met d'accord que les résultats des recherches bibliographiques de Catalin doivent se trouver dans un rapport de recherche. Ce rapport va servir comme réference pour les heuristiques de tolérance aux pannes qu'on envisage de mettre en oeuvre en SynDEx. Le rapport sera divisé en quatre parties, chacune dediée à un des domaines sur lesquels les recherches bibliographiques ont été faites : pannes des processeurs, pannes des média de communication, pannes des capteurs/actionneurs et modes dégradés.
Du 12 au 14 mars aura lieu un quatrième séjour de travail de Catalin à Rocquencourt. Ce sejour sera consacré aux discussions sur la mise en oeuvre des heuristiques et est nécessaire pour Catalin pour se rendre compte de la structure des données dans la version préconisée de SynDEx. Ce séjour doit se dérouler impérativement avant le depart du Christophe.
Envoyez vos commentaires à Alain Girault à Alain.Girault@inrialpes.fr.
Dernière modification : 14 mars 2000