Compte rendu de la réunion de l'ARC TOLERE

Participants :

• Alain Girault (BIP)
• Christophe Lavarenne (SOSSO)
• Mihaela Sighireanu (SOSSO)
• Yves Sorel (SOSSO)

Ordre du jour :

• Les outils Orccad et SynDEx
• Format d'entrée de SynDEx
• Méthode de compilation en SynDEx
• Démonstration de SynDEx
• Architecture matérielle et logicielle du CyCab
• Stage post-doctoral de Mihaela Sighireanu
• Collaborations
• Références bibliographiques

Les outils Orccad et SynDEx

Les projets INRIA impliqués dans l'action de recherche coopérative TOLERE ont mis au point deux logiciels, ORCCAD et SynDEx, qui concernent deux niveaux distincts de la réalisation des systèmes critiques embarqués. Ainsi :

• L'environnement Orccad (pour Open Robot Controller CAD), développé conjointement par les projets Icare à Sophia-Antipolis et Bip à Grenoble, est un logiciel de haut niveau dédié à la spécification d'applications temps réel embarquées orienté métier (robotique). Actuellement, à partir d'une spécification Orccad, deux utilisations sont possibles :
• la vérification des aspects logiques
• la génération de code mono-processeur
• L'environnement SynDEx (pour Synchronized Distributed Executive), développé par le projet Sosso à Rocquencourt, est un logiciel d'aide à l'implantation multi-composants d'applications spécifiées à l'aide de langages synchrones. Le format d'entrée de SynDEx est basé sur le format DC (voir la section suivante).

L'interconnexion entre les logiciels ORCCAD et SynDEx doit suivre l'approche illustrée sur le schéma suivant :

Cette interconnexion permettra de disposer d'un environnement logiciel unique depuis la spécification de l'application robotique jusqu'à son implantation répartie optimisée fonctionnant en temps réel.

Le problème de l'interconnexion ORCCAD-SynDEx est la génération à partir d'une spécification Orccad donnée (comprenant des lois de commande et des comportements de contrôle) d'une spécification DC unique, ayant la même sémantique que la spécification Orccad. Actuellement, les lois de commande et les comportements de contrôle d'une spécification Orccad sont traduits séparément vers deux spécifications DC. Toutefois, la composition de ces deux spécifications DC ne correspond forcément à la sémantique de la spécification Orccad initiale.

Format d'entrée de SynDEx

Actuellement, le format d'entrée actuel de SynDEx est le format SynDEx v5. Bien que la syntaxe du format SynDEx v5 soit différente de celle du format DC, sa sémantique est équivalente à celle du DC. Il s'agit donc d'un réseau flots de données ayant les caractéristiques suivantes :

• le réseau est plat (non hiérarchique)
• les conditions d'activations sont présentes dans tous les noeuds (opérations) du réseau
• les opérations sont en général "safe", avec deux exceptions :
  • les opérations de rétard qui sont "memory safe"
  • les pilotes d'entrée et de sortie qui font des effets de bord sur l'environnement

Méthode de compilation en SynDEx

Afin d'obtenir un code final réparti optimisé minimisant le matériel, l'outil Syndex utilise méthodologie "Adéquation Algorithme/Architecture" [Sor94] développée à Rocquencourt dans le projet SOSSO.

• [LS97] présente le modèle graphe factorisé utilisé en SynDEX pour la spécification et l'optimisation des applications temps réel embarquées.
• [LS93] et [Sor94] présentent les heuristiques d'ordonnancement utilisées en SynDEX pour l'optimisation de la répartition du code.

Démonstration de SynDEx

L'outil SynDEx est disponible à l'adresse http://www-rocq.inria.fr/syndex/.

Architecture matérielle et logicielle du CyCab

L'architecture du projet CyCab est présentée en détail à l'adresse http://www-rocq.inria.fr/praxitele/cabby.html.

Exemple de tolérance aux pannes en CyCab : L'environnement SynDEx a été utilisé pour l'implantation de l'application temps réel embarquée utilisée par CyCab. Le code généré utilise un protocole simple de tolérance aux pannes : chaque action d'attente de communication est contrôlée par un chien de garde ; quand le temps d'attente expire, tous les processus actifs sont arrêtés. Ce protocole est considéré trop primitif et il doit être raffiné lors des recherches sur la tolérance aux pannes effectuées dans l'action TOLERE.

Stage post-doctoral de Mihaela Sighireanu

Objectifs

• O1. Comprendre les modèles sémantiques de Orccad et SynDEx. Le but est d'identifier les problèmes sémantiques de l'interconnexion Orccad-SynDEx. Pour cela, il est nécessaire de contacter les équipes qui ont développé ces logiciels, notamment les moyens robotiques de Grenoble.

  Bibliographie : [LS93], [LS97], [SECK93], [Sor94].

• O2. Identifier l'état actuel de la définition du format DC. Le but est d'établir une passerelle entre les formats SynDEx v5 et DC. Pour cela, il est nécessaire de contacter Nicolas Halbwachs, DR CNRS au laboratoire VERIMAG, Grenoble.

  Bibliographie : [Hal95].

• O3. Constituer un état de l'art sur la tolérance aux pannes. La littérature sur la tolérance aux pannes est très riche. Le but est d'identifier les notions et les protocoles adéquates à l'implantation des application embarquées en utilisant les langages de spécification synchrones.

  Bibliographie : à établir.

• O4. Proposer un protocole tolérant aux pannes adapté à SynDEx. Cela concerne les aspects suivants :
  • Définir la notion de panne et par conséquent la manière dont une panne est détectée.
  • Définir les différentes fonctionnalités en cas de panne, par exemple, mode dégradé ou replication/rédondance.

• O5. Générer du code tolérant aux pannes. Dans l'état actuel de SynDEx, cet objectif concerne les aspects suivants :
  • Définir les informations supplémentaires nécessaires pour la détection des pannes.
  • Générer du code pour la détection des pannes.
  • Générer du code pour le protocole de traitement des pannes, s'il est nécessaire.

• O6. Etudier les liens possibles avec CADP. L'équipe VASY de l'INRIA Rhône-Alpes développe en collaboration avec le laboratoire VERIMAG la boîte à outils CADP (CAESAR/ALDEBARAN Development Package) pour l'ingénierie des protocoles et des systèmes distribués. CADP offre actuellement l'état de l'art des techniques de vérification basée sur les modèles. Dans le contexte de l'action TOLERE, cet objectif comporte deux parties distinctes :
  1. Etudier la connexion entre Orccad et l'environnement de vérification offert par CADP.
  2. Utiliser CADP pour la vérification des propriétés de bon fonctionnement du protocole de tolérance aux pannes proposé au point O4.

Plan de travail

Les travaux effectués dans la première partie du stage (décembre 1998 - février 1999) seront présentés lors de la prochaine réunion de l'action TOLERE.

Collaborations

Il a été convenu de prendre contact avec les différents projets (INRIA ou extérieurs à INRIA) qui ont étudié la tolérance aux pannes comme, par exemple, l'équipe TRIO de LORIA, le projet REFLECS d'INRIA Rocquencourt, le projet SIRAC d'INRIA Rhône-Alpes, etc.

Références bibliographiques

[Hal95] N. Halbwachs. The declarative code DC. VERIMAG Report, Grenoble, France, october 1995.

[LS97] C. Lavarenne et Y. Sorel. Modèle unifié pour la conception conjointe logiciel-matériel. Traitement du Signal, 14(6):569--578, 1997.

[LS93] C. Lavarenne et Y. Sorel. Performance Optimization of Multiprocessor Real-Time Applications by Graphs Transformations. In ParCo'93, Grenoble, France, september 1993.

[Sor94] Y. Sorel. Massively parallel computing systems with real-time constraints, the "algorithm/architecture adequation" methodology. In Massively Parallel Computing Systems Conference, Ischia, Italy, mai 1994.

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