Compte rendu de réunion de l'ARC TOLERE


INRIA Rocquencourt, le 14-16 février 2000


Participants :



Les pannes des média de communication dans le cas du CyCab

Les média de communication choisis pour le CyCab sont des CAN (Controlled Area Network). L'étude biliographique démontre que la spécification de CAN comporte quelques facilités de tolérance aux pannes, en assurant aussi la délivrance des données en temps réel. Pourtant il n'est pas garanti que les données sont reçues par le vrai destinataire, est c'est cela qu'on doit prendre en compte dans un niveau supérieur de spécification.

Catalin a trouvé des réferences sur une méthode du détection des coupures dans les réseaux CAN, méthode qui peut être utilisée pour la reconfiguration du réseau et le reroutage des communications.

Christophe observe que les pannes les plus fréquentes dans les réseaux de communication ne sont pas les pannes dues aux coupures dans les fils, mais les pannes dues au connexions mécaniques qui s'usent. Cela a comme effet le fait que tout le réseau CAN tombe en panne et ne peut plus être utilisé. Par conséquent, les solutions qui partagent un média de communication multipoint en plusieurs parties, même si elles sont intéresantes et aident au re-routage des communications, ne doivent pas prises en compte systématiquement dans les heuristiques que l'on recherche.



Résultats des recherches bibliographiques sur la tolérance aux pannes dans les réseaux

Catalin explique un algorithme qui peut être utilisé pour démontrer si un graphe d'architecture peut supporter k coupures des média de communication. Il s'agit d'adapter deux problèmes classiques dans la théorie des graphes : le problème de k-connectivité d'un graphe et le problème de trouver, entre chaque paire de sommets i et j du graphe, k chemins avec la proprieté que chaque chemin n'a aucun sommet en commun (sauf les sommets source et destination). Ces problèmes peuvent être résolus en utilisant les réseaux des flots de Ford et Fulkerson. L'idée est que, pour chaque paire de sommets, les k chemins trouvés peuvent être utilisés pour les communications, le priemiér comme le chemin principal et les autres comme des backups. Si le premier chemin contient un médium qui est tombé en panne, le deuxième chemin sera utilisé pour communiquer les données. Si maintenant le deuxiéme tombe en panne, c'est le troisiéme qui sert pour la transmission des données, et caetera. Il important de noter que les algorithmes pour ce problèmes sont polynomiaux, le plus simple étant d'un ordre de magnitude proportionnel au produit entre le cube du nombre des sommets (i.e., processeurs) et le carré du nombre des arcs (i.e., média de communication) dans le graphe.

Pourtant il y a deux problèmes avec les algorithmes présents dans la litterature :

  1. Ils ne s'occupent que de cas de graphes, c'est-à-dire que le cas des média de communications multipoint n'est pas pris en compte. Nous devons donc les transformés pour prendre en compte ce cas-ci.
  2. Ils peuvent être utilisés seulment pour trouver si une architecture (ou une impementation d'un algorithme sur une architecture) peut supporter k pannes des média des communications, mais pas pour assurer cela.

Pour le deuxième problème on prévoit aussi que si l'architecture ne supporte pas le nombre des pannes désiré on doit répliquer un certain nombre des opérations.

Catalin s'occupera de mettre au point des héuristiques basées sur ces algorithmes pour qu'ils prennent en compte tous ces cas ci-dessus.



Calendrier de travail

Du 8 au 10 mars aura lieu un troisiéme séjour de travail de Catalin à Rocquencourt. On prévoit ce séjour pour discuter l'implantation des héuristiques de tolérance aux pannes. Catalin y apportera aussi les résultats des ses recherches bibliographiques sur la tolérance aux pannes des capteurs/actionneurs et sur les modes dégradé de fonctionnement. Yves argumente que c'est cela qui est le plus intéresant pour les industriels. Yves et Cristophe se mettent d'accord sur le fait que la prise en compte des pannes des capteurs/actionneurs et du mode dégradé doit être fait au moment de la spécification du système, et que le maximum qu'on peut attendre de cet étude est d'isoler une partie qui peut être faite automatiquement, c'est-à-dire implementé dans SynDEx.



Envoyez vos commentaires à Alain Girault à Alain.Girault@inrialpes.fr.

Dernière modification : 28 février 2000


Retour à la page d'accueil de l'action TOLÈRE