Introduction

L'objet de ce stage est de développer le système de contrôle centralisé d'un ensemble de traitements distribués afin de garantir la cohérence globale du système. Ces traitements composent les nombreuses fonctions opératoires qui permettent à un système autonome, tel qu'un robot, d'appréhender son environnement via des capteurs et actionneurs. Ces fonctions temps réel peuvent présenter des conflits lors d'exécutions concurrentes qu'il faut absolument prévenir pour garantir l'intégrité de la machine.

Il s'agit en fait de reprendre le travail réalisé par Adelardo A.D. de MEDEIROS [1] pendant sa thèse pour en faire un système de génération automatique de code ainsi qu'apporter certaines modifications aux hypothèses énoncées initialement. Le logiciel généré doit pouvoir garantir la cohérence du système, détecter des conflits entre diverses demandes de la part des autres composants de l'architecture.

L'exécutif est une couche logicielle se trouvant, sur les robots mobiles et autres systèmes autonomes, dans l'architecture logicielle de contrôle du LAAS (figure 1.1, page ), entre le niveau décisionnel et le niveau fonctionnel, filtrant ainsi les informations envoyées de l'un vers l'autre. Ce sont des couches logicielles s'occupant respectivement de la prise de décision et de la partie matérielle : lecture des capteurs et commande des actionneurs.

L'exécutif permet de détecter et gérer les conflits entre les divers services demandés par le niveau décisionnel au niveau fonctionnel et de remonter les bilans d'exécution et autres informations venant de briques logicielles appelées modules et créées par G ^enoM, filtrant ainsi les informations envoyées par chacun d'eux vers l'autre.

Les sources conflits, que doit détecter l'exécutif, sont de deux types principaux : les conflits d'accès aux ressources du système et les conflits fonctionnels (deux services concurents).

Les services sont des fonctionnalités offertes par le système, et gérés par la couche fonctionnelle. Il faut tout d'abord pouvoir détecter les conflits entre ces services. À cette fin, un outil appelé Kheops (section 2.1), permet de contruire des arbres de décisions en s'appuyant sur les relations de dépendance entre les différents services.

Ensuite, il faut pouvoir faire communiquer l'exécutif avec son environnement. Pour cela nous utilisons le messsages-passer, un système permettant de faire passer des messages entre les différents intervenants de l'architecture LAAS.

G ^enoM, lui, est un générateur de modules qui permet de créer plusieurs services qui pourront être utilisés par le niveau décisionnel. Les modules créés avec son aide contrôlent les ressources matérielles du mobile. Ils implémentent un protocole de communication qui leur permet de communiquer entre eux et avec d'autres parties de l'architecture LAAS. C'est sur eux que s'appuie l'exécutif afin de créer sa liste de services qui seront offerts au niveau décisionnel.

La plupart de ces éléments tournent sous VxWorks, système d'exploitation temps réel, utilisé sur les robots mobiles et satellites.

Le rapport est organisé en trois parties :

1 ^èrepartie :

L'architecture LAAS

Présentation des trois niveaux :

1.

niveau décisionnel / niveau tâche

2.

niveau exécutif

3.

niveau fonctionnel

Structure des modules.

VxWorks et les modules.

2 ^èmepartie :

Les outils

Kheops - Arbre de décision / Application à l'exécutif.

Propice - Messages-passer.

3 ^èmepartie :

L'exécutif

Présentation.

Les conflits.

Mise en uvre :

• Automate de gestion
• Intégration avec les niveau supérieur
• Les réseaux de Petri

Synthèse automatique :

• Expression des conflits
• Lex et Yacc.

Mon but n'est pas de refaire ce qui a déjà été fait par Adelardo A.D. de MEDEIROS, ni de faire un mode d'emploi du logiciel créé, mais de me baser ce qui a été fait (et qui n'était qu'une sorte de prototype) afin d'en faire un système de génération automatique permettant de garantir la cohérence du systéme et de valider les choix.