Compte rendu de la réunion de l'ARC TOLÈRE

Participants :

• Alain Girault (BIP)
• Remy Kocik (SOSSO)
• Christophe Lavarenne (SOSSO)
• Mihaela Sighireanu (BIP)
• Daniel Simon (BIP)
• Yves Sorel (SOSSO)

Ordre du jour :

• DC2SDX : traducteur DC vers SynDEx
• Etat de l'art sur la tolérance aux pannes
• Tolérance aux pannes en SynDEx
• Conclusion et axes de travail

DC2SDX : traducteur DC vers SynDEx

Mihaela Sighireanu a présenté l'outil DC2SDX, en illustrant les principaux problèmes de l'algorithme de traduction.

• L'utilisation des constantes prédéfinies (cf. section 2.2). Les constantes en SynDEx sont manipulées de façon symbolique : la connexion avec la valeur de la constante se fait en fonction de la machine cible.
• La traduction des équations conditionnelles DC, en particulier les équations de la forme "equ: F1 F2 at: $@1" (cf. sections 2.3 et 3.5). La version 5.1 de SynDEx permettra de spécifier des horloges d'activation pour les opérations. Toutefois, la sémantique des équations de la forme "equ: F1 F2 at: $@1" est que F1 et F2 représentent le même flot. Nous envisageons d'optimiser cela dans l'algorithme de traduction de DC2SDX.
• Les contraintes de nommage en SynDEx. Afin d'éviter les conflits au niveau des identificateurs C générés à la compilation (par concaténation en utilisant le caractère "_") à partir des identificateurs de l'utilisateur, l'emplois du caractère "_" dans les identificateurs SynDEx est déconseillé. Toutefois, la chaîne de compilation en amont de SynDEx (ORCCAD, Esterel) utilise le caractère "_" pour générer des identificateurs non ambigus. Il a été convenu de permettre l'utilisation du caractère "_" au niveau des identificateurs SynDEx et de trouver des solutions (par exemple, préfixage par "sdx_") pour éviter les conflits au niveau des identificateurs C.
• La granularité des descriptions SynDEx obtenues par la traduction des automates de contrôle Esterel (cf. sections 2.6 et 2.7). Les solutions suivantes ont été discutées :
  • Générer une correspondance "générique" de tous les sommets de contrôle vers un seul processeur.
  • Générer un seul bloc contenant tous les sommets de contrôle.
  • Adapter les heuristiques de répartition en SynDEx pour traiter d'une manière spéciale la granularité fine du contrôle.
  • Générer des booléens d'activation des calculs externes au lieu d'appels de procédures dans le programme Esterel.

Une page WEB répertorie les questions posées et les solutions proposées pour la traduction du format DC vers le format SynDEx.

Etat de l'art sur la tolérance aux pannes

Mihaela Sighireanu a présenté l'état actuel de ses recherches bibliographiques sur la tolérance aux pannes. Etant donné le cadre spécifique de l'action TOLÈRE, les recherches bibliographiques sur la tolérance aux pannes ont été orientées selon les directions suivantes :

• La tolérance aux pannes dans les systèmes répartis.
• La tolérance aux pannes dans les systèmes temps-réel.
• Les méthodes formelles (vérification, preuve) et les modèles (automates à modes) pour la tolérance aux pannes.

Le fichier BibTeX qui répertorie les principales références se trouve ici.

Tolérance aux pannes en SynDEx

Parmi les classes de fautes présentées dans [L+92], les classes suivantes ont été identifiées comme étant intéressantes dans le cadre de l'action TOLÈRE :

• fautes de nature accidentelle,
• fautes ayant une cause phénoménologique physique,
• fautes internes au système et
• fautes permanentes.

C. Lavarenne et R. Kocik ont exposé les principaux problèmes de la tolérance aux pannes en SynDEx. De manière générale, dans un système comportant N ressources matérielles il faut être capable de permettre la panne de K ressources. La solution classique pour résoudre ce problème est la redondance des ressources ou des calculs.

En SynDEx, les ressources matérielles sont : les processeurs, les entrées/sorties (capteurs/actionneurs) et les médias de communication. Il résulte donc trois types de tolérance aux pannes :

• Tolérance aux pannes des processeurs (de calcul). Dans ce cas, l'algorithme SynDEx décrit par l'utilisateur peut être réparti automatiquement (avec redondance) sur K + 1 processeurs. Chaque entrée d'une opération de calcul est accompagnée par un élément de vote qui calcule l'entrée finale en fonction des entrées fournies par les calculs répliqués. Cet élément de vote peut détecter la panne d'un des processeurs par absence de l'entrée correspondant à ce processeur.
• Tolérance aux pannes des entrées/sorties. Pour le moment, la redondance des entrées/sorties n'est pas prévue. Par exemple, dans le Cycab, les capteurs/actionneurs ne sont pas répliqués. La panne d'une entrée peut être détectée par les éléments de vote attachés aux entrées des éléments de calcul.
• Tolérance aux pannes de communication. Pour le moment, ce type de panne semble peu important. Par exemple, dans le Cycab, le bus CAN offre un niveau de tolérance aux pannes correspondant à la couche liaison du modèle OSI, donc il est très fiable par rapport aux autres composants matériels. Toutefois, il est possible d'imaginer des architectures avec une redondance des médias de communication afin de supporter les pannes de communication.

Deux approches sont envisageables pour la reprise après la panne d'une partie des ressources matérielles :

• Continuer à utiliser le même algorithme de calcul en tenant compte de ces pannes. Cette approche est basée sur la redondance des calculs. Elle est entièrement automatisable : l'utilisateur doit donner le coefficient K (nombre de pannes de processeurs à tolérer), ce qui doit suffire à l'algorithme de répartition de SynDEx pour générer un système tolérant aux pannes.
• Utiliser un mode dégradé de calcul, éventuellement en parallèle avec le mode nominal (utilisé en absence de pannes). Cette approche semble difficilement automatisable : l'utilisateur doit spécifier lui-même le mode dégradé de calcul.

Les contraintes pour la tolérance aux pannes en SynDEx sont les suivantes :

• Il s'agit du temps-réel dur : les temps de calcul sont strictement bornés par des contraintes de latence (deadline) et de cadence (jitter).
• L'ordonnancement du calcul (scheduling) en SynDEx suit l'approche statique. Toutefois, des travaux sont en cours (travail de thèse de R. Kocik) pour introduire un modèle RMS (Rate Monotonic Scheduling) en SynDEx.

Conclusion et axes de travail

Les discussions portées lors de cette réunion ont conduit aux conclusions suivantes :

• L'interconnexion entre les outils ORCCAD et SynDEx doit être finalisée par la génération d'une description DC unique à partir de spécifications du contrôle et des données ORCCAD (actuellement, uniquement la partie contrôle est connectée à SynDEx). Ce travail est en cours de réalisation par A. Girault (BIP) et R. Pissard (Moyen Robotiques de l'UR Rhône-Alpes).
• La faisabilité des solutions proposées pour réduire la granularité trop fine des descriptions SynDEx obtenues par la traduction des parties contrôle d'ORCCAD (automates Esterel) doit être analysée.
• La recherche bibliographique sur la tolérance aux pannes doit être poursuivie en tenant compte du cadre spécifique de SynDEx (voir [3]). Ce travail doit aboutir à :
  • une présentation en largeur des techniques existantes pour la tolérance aux pannes et
  • une stratégie de recherche dans ces techniques qui tient compte du cadre spécifique des applications SynDEx et ORCCAD.
• Afin d'identifier la stratégie de recherche à suivre pour la tolérance aux pannes, il faudra constituer une description (plus précise que celle donnée au point [3]) des fautes à considérer, éventuellement avec leur probabilité d'apparition. Pour cela, le Cycab sera considéré comme exemple d'étude.

Références

[L+92] J.-C. Laprie et all. Dependability: Basic Concepts and Terminology. Springer-Verlag, 1992.

Envoyez vos commentaires à Mihaela Sighireanu à Mihaela.Sighireanu@inria.fr.