réellement de raisonneurs robustes et efficaces pour la logique linéaire (ou le fragment qui nous
intéresse). La question du passage à l’échelle est un réel problème, car le nombre de règles augmentent fortement avec le nombre d’agents (nouvelles variables d’états, nouvelles règles pour
chaque tâche et recettes, . . .), rendant de fait la résolution de plus en plus difficile.
8.2 Vérification de propriétés de sûreté
8.2.1 Définition
Les propriétés de sûreté sont des propriétés qui indiquent que quelque chose de non désiré
ne va jamais arriver. Autrement dit, siP est une propriété de sûreté, on doit pouvoir montrer P
dans toutes les branches d’exécutions possibles,i.e.que¬Pn’est pas un état atteignable. Dans
le cadre de la robotique, cela peut être des propriétés telles que “un robot ne doit jamais heurter un humain” ou “le robot ne doit jamais entrer dans l’eau”.
8.2.2 Quelques approches possibles en logique linéaire
Sémantique de phases
Le problème étant exprimé ainsi, il n’existe pas d’approches évidentes pour le traiter en
logique linéaire. En effet, cela revient à démontrer la non-existence de certaines dérivations, ce
qui est impossible en général, en particulier quand l’espace des cas possibles devient grand. Dans (Fages et al., 2001), les auteurs en proposent toutefois une interprétation logique. Pour cela, ils utilisent la sémantique de phases (Girard, 1987) de la logique linéaire. La sémantique de phase est une sémantique de prouvabilité pour la logique linéaire. En utilisant cette notion de sémantique de phase, les auteurs montrent alors qu’on peut ramener ce problème à la démonstration de l’existence d’un contre-exemple dans l’espace des phases. Ces principes sont alors utilisés pour implémenter un “model checker” (Soliman, 2001) sur des spécifications en logique linéaire.
Une autre approche pour le “model checking”
Une autre approche pour vérifier des propriétés de sûreté a été proposé dans (Bozzano et al.,
2004). En s’inspirant d’algorithmes d’atteignabilité arrière (i.e. calculer à partir d’un état but
l’ensemble des états possibles sources), il propose une procédure d’évaluation de “bas en haut” (bottom-up) pour le fragment de la logique linéaire LO (Andreoli and Pareschi, 1991). Les
au-teurs peuvent alors de manière efficace calculer l’ensemble des buts atteignables à partir d’une
spécification logique. À partir des états interdits (i.e.les propriétés de sûreté que l’on veut
véri-fier), il est alors possible de remonter aux états initiaux qui l’engendrent. Si aucun de ces états initiaux n’apparaissent dans l’ensemble des états initiaux légaux, alors la propriété de sûreté
est garantie. Dans le cas contraire, l’approche offre une instance conduisant à la violation de la
Lien avec les autres modèles de concurrences
Enfin, une autre approche possible est d’utiliser la connexion entre certains fragments de la logique linéaire et d’autres paradigmes de concurrence. On peut alors réutiliser les techniques de vérification connues sur ces paradigmes. Dans (Collé et al., 2005), les auteurs développent des scénarios sous forme de spécification dans un fragment logique linéaire. Ils transforment ces spécifications en réseaux de Pétri (coloriés), et utilisent alors des techniques de vérification sur ces réseaux de Pétri. Dans (Cervesato and Scedrov, 2009), les auteurs font une analyse
appro-fondie des liens entre le fragment de logique linéaire LVobs (que nous avons utilisé dans notre
formalisation) et divers autres formalismes concurrents (π-calcul, réseaux de Pétri, logique de
réécriture). Ils font entre autre un parallèle avec un puissant système de réécriture ω. Celui-ci
peut être encodé dans l’outil Maude (Clavel et al., 2002), qui permet entre autre de vérifier des propriétés de sûreté via des méthodes de “model checking”.
8.2.3 Le problème de la couche fonctionnelle
Il apparait difficile de montrer des propriétés de sûreté de manière complètement
indépen-dante de la couche fonctionnelle. En effet, ce qui nous intéresse, c’est de garantir le
comporte-ment du robot, comportecomporte-ment qui vient en dernier lieu de la couche fonctionnelle. Par exemple,
supposons qu’on puisse “garantir” que le module p3d ne s’approche pas à plus de 50cm d’un
obstacle, un humain étant considéré comme un obstacle. Si les seuls déplacements possibles du
robot sont basés sur les plans générés par le p3d (ce qui se montre au niveau de la couche de
contrôle, donc deroar) alors on peut montrer que le robot ne peut heurter un homme. C’est la
combinaison entre les spécifications du module fonctionnel et les spécifications de coordination qui permet de montrer ce résultat. Cela nécessite donc une modélisation de la couche
fonction-nelle, et en particulier des garanties qu’elle offre (ou en terme de contrat ses invariants). Seule
la combinaison de garanties fonctionnelles et des garanties de coordination permet d’assurer des garanties au niveau du système global.
8.3 Synthèse
Dans cette partie, nous nous sommes intéressés à la vérification de propriétés sur des modèles basés sur la logique linéaire. Nous nous sommes penchés en particulier sur les questions d’attei-gnabilité et de sûreté. Si la première a une interprétation assez évidente en logique linéaire, la
seconde pose plus de difficultés. Il existe toutefois plusieurs approches possibles pour aborder le
problème.
Cette étude prospective nous a permis ainsi d’identifier les voies possibles pour faire de la vérification sur des spécifications en logique linéaire, mais aussi les problèmes à résoudre. En premier lieu, il apparait indispensable d’avoir un modèle des couches fonctionnelles pour prouver des propriétés “intéressantes” sur le système complet. En second lieu, il semble nécessaire de
8.3. SYNTHÈSE 119 linéaire. La littérature sur le sujet est assez importante, mais il ne semble pas y avoir d’outils
réellement efficaces. Enfin, il est probablement nécessaire de simplifier le modèle proposé pour
Chapitre 9
Conclusion
9.1 Résumé des contributions
Dans ce document, nous nous sommes intéressés à la problématique des architectures de contrôle pour un robot autonome. Dans un premier temps, nous avons défini un ensemble
d’exi-gences liées à une telle architecture, qui portent principalement sur une gestion de temps de
délibérations distincts, une gestion aisée de la concurrence, la satisfaction de propriétés de
robustesseet de vérifiabilité, et enfin la satisfaction de besoins demodularité et composabi-lité.
Sur la base de ces exigences et de l’analyse de l’état de l’art, nous avons proposé l’architecture
roarbasée sur des agents encapsulant chacun une ressource et échangeant des contraintes. Cette
décomposition en agents permet de facilement gérer des contraintes différentes sur les temps de
délibération et augmente la robustesse du système, en évitant un unique point de faute. Chaque agent utilise un moteur d’inférence basé sur la logique de premier ordre afin de décider comment satisfaire une contraire et si plusieurs contraintes sont satisfaisables en même temps. Un langage
d’exécution a été défini, afin de décrire de manière aisée différentes stratégies de contrôle. Nous
avons présenté les autres échanges entre les agents, permettant notamment de garantir qu’une contrainte n’est exécutée que si ses pré-requis sont satisfaits et de gérer les fautes d’exécutions ou les problèmes de concurrence.
Nous nous sommes ensuite intéressés à une implémentation pratique de cette architecture. En particulier, nous avons discuté des choix importants de l’implémentation, afin de garantir robustesse et performance. L’architecture a été instanciée dans une couche de supervision pour un robot terrestre, et est désormais systématiquement exploitée pour la réalisation de missions de navigation autonomes. Elle a été testée aussi bien en simulation que sur un robot réel. Diverses
traces d’exécution ont illustré les différentes stratégies développées et ont été exploitées pour
l’analyse des performances. Nous avons ainsi pu montrer que même si l’architecture proposée induit un léger surcoût au niveau atomique, le temps global de mission n’est pas impacté, et même moins que pour d’autres architectures.
Enfin, nous nous sommes intéressés à la formalisation de l’architecture de contrôle proposée. Après avoir rappelé les principaux besoins auxquels répond une telle formalisation, nous avons
analysé différents modèles logiques pertinents. Nous avons choisi la logique linéaire comme base de formalisation, en particulier parce qu’elle permet le mieux l’interaction continue entre
déduction et exécution, et nous avons montré comment les différents concepts deroarpouvaient
être encodés dans ce formalisme. Ce modèle est alors utilisé comme aide à la programmation pour vérifier hors-ligne que certaines situations sont atteignables.