Dans ce chapitre, nous avons proposé une modélisation de l’architecture roar en utilisant
un fragment de la logique linéaire. Ce fragment est assez expressif pour encoder précisément la sémantique de notre architecture, aussi bien la partie logique que la partie exécution. La logique linéaire apporte ici deux capacités importantes : la possibilité d’exprimer la concurrence via
l’opérateur⊗et la possibilité de consommer des “ressources” (via l’opérateur⊸). Cette dernière
possibilité permet ainsi facilement de modéliser la notion d’état (d’un système informatique) et ses évolutions, l’utilisation de messages, . . .
7.5.2 Des choix dans la modélisation
Choix du fragment de logique linéaire Plusieurs choix ont été faits au cours de ces travaux. Tout d’abord, nous avons choisi de travailler avec un fragment assez restreint de la logique
li-néaire. Cela en réduit l’expressivité, i.e. l’ensemble de ce que nous pouvons modéliser, mais
de l’autre côté, cela permet de réduire la complexité de raisonner (automatiquement) dans cette ensemble. Notre choix a été principalement guidé par les travaux de (Cervesato and Scedrov,
2009), qui montrent comment ce fragment permet de modéliser facilement différents paradigmes
classiques d’exécutions concurrentes.
Autres opérateurs d’intérêt dans la logique linéaire Deux autres opérateurs de la logique li-néaires pourraient être intéressants pour une modélisation d’un système robotique. Comme nous le disions dans l’introduction à la logique linéaire, l’opérateur de négation linéaire introduit la
notion de dualité (émetteur/récepteur, observateur/acteur, . . .). Dans ACL (Kobayashi and
Yo-nezawa, 1993), les auteurs utilisent la négation linéaire pour noter la dualité entre processus qui
envoient un messagemet un processus qui attend un message m⊥. Notre modélisation pourrait
peut-être être simplifiée en utilisant ce type de techniques. L’autre opérateur intéressant est
l’opé-rateur plus linéaire⊕ qui dénote d’un choix indépendant de notre volonté, d’un indéterminisme
dans l’observation. Si l’on veut considérer un modèle de l’environnement, ou le comportement de
la couche fonctionnelle, cet opérateur semble indispensable pour refléter les différentes situations
possibles, que nous ne pouvons contrôler. Enfin, il est à noter que notre architecture ne nécessite pas l’utilisation de cet opérateur : elle est donc aussi déterministe que possible. La seule cause
d’indéterminisme est l’ordre d’exploration des séquents après l’utilisation de l’opérateur ⊗, qui
correspond à l’indéterminisme lié à la politique d’exécution des différents fils d’exécutions dans
le système “réel”.
Passage par destination Cette méthodologie de modélisation nous a semblé pertinente par son côté modulaire. Chaque type de primitive peut être modélisé indépendamment des autres, puis réutilisé. En particulier, dans la section 7.2, nous avons proposé des modélisations pour
7.5. DISCUSSION 111
de base pour modéliser d’autres langages exécutifs commetdl(Simmons and Apfelbaum, 1998),
prs(Ingrand et al., 1996) ou bienplexil(Jonsson et al., 2006).
7.5.3 Fonctions et appels à la couche fonctionnelle
Dans la modélisation proposée, nous nous sommes concentrés sur les différentes primitives
deroar. Toutefois, nous n’avons pas explicité le cas des fonctions non natives (déclarées dans
les agents) et plus généralement des appels à la couche fonctionnelle. Pour les premières, il est possible de les modéliser dans le fragment proposé, celle-ci ne faisant que manipuler que des types de données relativement simples (pas de types sommes, pas de types récursifs) avec des opérations de base. Pour la seconde, c’est évidemment moins simple.
Une vision naïve de la couche fonctionnelle Naïvement, on peut considérer que, du point de
vue deroar, l’appel à la couche fonctionnelle correspond uniquement à un envoi de message sur
un canal de communication spécifique, puis l’attente de réception de la réponse (indéterministe du point de vue de la couche de contrôle). Autrement dit, un module de la couche fonctionnelle pourrait être modélisé ainsi :
P:readM sg(c)⊸ (writeM sg(c,success)⊕writeM sg(c, f ailure))
Malheureusement, cette approche est souvent insuffisante. En effet, souvent, ce qui nous
inté-resse, ce n’est pas seulement le résultat du service, mais ce sont ses effets de bords, en particulier
la mise à jour de ses ports, en fonction de l’environnement. Pour montrer certaines propriétés ou pour modéliser globalement le système robotique, il est donc nécessaire de modéliser la couche fonctionnelle, au moins à un niveau assez haut.
Chapitre 8
Vérification sur des modèles en logique
linéaire : une prospective
Dans le chapitre précédent, nous avons proposé une mo-délisation de l’architecture roar. Dans cette partie, nous allons discuter plus précisément de la manière d’utili-ser ces modèles pour faire de la vérification. Toutefois, il s’agit surtout d’études préliminaires. Ce chapitre sera composé de deux parties principales, l’une évoquant le problème de l’atteignabilité et l’autre celui des propriétés de sûreté.
8.1 Le problème de l’atteignabilité
8.1.1 Définition et intérêt pour roar
Définition
Le problème de l’atteignabilité est de savoir si il est possible d’atteindre une situation but
G à partir d’une situation initiale A, et d’un ensemble de règles Γ. Cette question est de fait
très proche de la question de la planification : l’unique différence est qu’à priori, d’une question
d’atteignabilité, on attend une réponse “oui ou non”, tandis que d’une question de planification, on attende un plan (si il existe une solution).
Utilisation pourroar
Tests au niveau logique La question de l’atteignabilité dansroarpeut être une aide importante à la programmation d’un système robotique. Lors du développement d’un agent, le développeur peut vouloir vérifier si, dans une situation donnée, l’agent peut activer une tâche ou une recette.
Dans le cas contraire, cela indique probablement une erreur de logique. Le problème peut
en-suite être étendue à une configuration de N agents, afin de vérifier l’impact de un ou plusieurs
nouveaux agents sur le système global. Autrement dit, il s’agit d’un ensemble de tests (unitaires ou d’intégrations) mais au niveau de la spécification logique.
Comparés à des tests classiques On peut arguer que cette problématique pourrait aussi être résolue par une politique de tests classiques, directement sur la version exécutable des agents.
Toutefois, cela s’avère généralement difficile à mettre en place. La situation initiale peut être
dif-ficile, voire impossible à mettre en place sur les agents “normaux”. De plus, les agents “normaux”
vont aller jusqu’au bout de l’exécution,i.e.appeler les composants de la couche fonctionnelle, ce
qui peut avoir un surcoût important si l’on s’intéresse uniquement à la question de l’atteignabilité. Pour ces diverses raisons, l’approche logique pour ce problème semble plus adaptée.
Ensemble d’agents Une autre question intéressante que l’on peut traiter est de déterminer des ensembles d’agents minimaux pour réaliser une tâche. L’idée d’un développement modulaire est la possibilité d’avoir un ensemble de composants (ou ici d’agents) dans une grande bibliothèques et de choisir ceux qui nous intéressent pour une application donnée. En utilisant une méthode qui résout le problème de l’atteignabilité, on peut alors chercher automatique des ensembles d’agents qui permettent de répondre à une certaine tâche, et donc choisir automatiquement un ensemble d’agents répondant à une problématique donnée.
8.1.2 Le problème d’atteignabilité en logique linéaire
Le problème d’atteignabilité, tel que défini précédemment, correspond à la prouvabilité du
séquent Γ,A ⊢ G. De plus, de par la nature constructiviste de la logique linéaire, le problème
d’atteignabilité en logique linéaire est équivalent au problème de planification associé, le plan étant alors la preuve de ce séquent. Un des avantages de la logique linéaire pour le domaine de la
planification est qu’il évite le problème du cadre1(“frame problem”), car la consommation des
ressources est au cœur du modèle.
Planification et recherche automatique de preuves en logique linéaire
Planification Plusieurs travaux se sont intéressés aux questions de planifications et de vérifi-cation automatiques pour la logique linéaire. Un des travaux pionner dans ce domaine est (Ka-novich and Vauzeilles, 2001) : les auteurs étudient ici le problème de la planification au travers du prisme des clauses de Horn en logique linéaire. Même si ce fragment est en général indé-cidable, ils montrent que le problème de planification dans ce fragment l’est, et démontrent la complexité du problème pour plusieurs classes de robot. Dans (Küngas, 2002), les auteurs pro-posent un planificateur basé sur la logique linéaire qui utilise les liens avec les réseaux de Pétri
1. Le problème du cadre est un problème initialement formulé dans le domaine de l’intelligence artificielle. La question sous-jacente est de savoir comment exprimer en logique un domaine dynamique, sans expliciter spécifi-quement les conditions qui ne sont pas affectés par une action.
8.1. LE PROBLÈME DE L’ATTEIGNABILITÉ 115
et le problème de l’atteignabilité pour obtenir un algorithme efficace de résolution. Les travaux
(Cresswell et al., 2000) se concentrent sur des structures de plan plus complexe, en particulier des plans récursifs. Ils utilisent alors le langage basé sur la logique linéaire Lolli (Hodas and Mil-ler, 1991) pour résoudre ces systèmes (se ramenant de fait au problème de la prouvabilité). Dans (Dixon et al., 2006), les auteurs proposent une formalisation de la logique linéaire intuitionniste
dans l’assistant de preuve générique Isabelle (Nipkow et al., 2002) et proposent différentes
tac-tiques pour résoudre efficacement le problème de planification associée. L’utilisation d’Isabelle
permet de garantir la correction du plan, mais aussi de réutiliser les différentes stratégies déjà
disponibles, en particulier, la gestion de contraintes. Les travaux de (Kahramano˘gulları, 2009) sont plus théoriques, mais font le lien entre logique linéaire, planification, et concurrence. Ils montrent comment extraire des plans partiellement ordonnés depuis un problème de planifica-tion en logique linéaire, afin de les exécuter en parallèle. En particulier, il fait le lien avec les systèmes de transition, un modèle classique de concurrence.
Recherche automatique de preuves De nombreux travaux ont été effectués afin de proposer
une mécanisation efficace de la logique linéaire, que ce soit pour le développement de langage de
programmation logique, que pour le développement des assistants de preuves. Un des résultats les plus important est la découverte du principe de focalisation (Andreoli, 1992), qui permet de supprimer certaines causes d’indéterminisme lors d’une recherche d’une preuve en arrière en logique linéaire classique. Un des problèmes importants dans la résolution automatique de preuve en logique linéaire est la gestion des ressources, à savoir comment décomposer correctement les
séquents lors de l’application de la règle ⊗, et assurer que les assertions linéaires ne sont bien
utilisées qu’une fois. Dans (Harland and Pym, 1997), les auteurs proposent plusieurs stratégies de
consommation de ressource, en particulier l’utilisation d’une décomposition paresseuse (i.e.elle
n’est effectuée qu’au moment où on en a réellement besoin). De plus, à chaque formule linéaire,
ils associent un booléen reflétant si il est consommé ou non. Cela leur permet de vérifier que les ressources linéaires ne sont consommées qu’une fois, et de choisir à posteriori comment faire
la décomposition du contexte dans le cas⊗. Si on s’intéresse plus spécifiquement aux assistants
de preuves, un de premiers travaux théoriques est (Mints, 1993) qui proposent principalement une résolution en avant. Cette approche sera implémentée plus tard dans un assistant de preuve pour la logique linéaire propositionnelle dans (Tammet, 1994). Une approche plus complète est proposée par (Chaudhuri and Pfenning, 2005) : il décrit un assistant de preuve pour la logique intuitionniste du premier ordre (qui inclut le segment de la logique linéaire que nous utilisons) en combinant des approches en avant et en arrière, et en utilisant le principe de focalisation de Andreoli.
8.1.3 Atteignabilité et la couche fonctionnelle
Maintenant que nous avons vu comment pouvait se traiter le problème de l’atteignabilité en logique linéaire, et fait une rapide revue des travaux associés, nous allons nous intéresser à son applicabilité dans notre contexte.
Simplification initiale du modèle
Pour traiter du problème de l’atteignabilité, le modèle proposé peut être un peu simplifié. En
effet, dans ce contexte, nous ne sommes pas particulièrement intéressés par la gestion d’erreur :
une erreur est ici considérée comme une branche invalide, logiquement fausse, et on cherchera juste à tester une autre solution. Toutes les branches de gestion d’erreurs peuvent être alors
rem-placés par⊥, ce qui amènera le raisonneur à essayer une autre branche.
Lien avec la couche fonctionnelle
La modélisation de la couche fonctionnelle n’est pas forcément nécessaire pour la probléma-tique de l’accessibilité. Si on s’en tient localement au niveau tâche, il n’y a pas évidemment pas d’appels à la couche fonctionnelle. Dans le cas où on s’intéresse à un système complet d’agents,
le problème est un peu plus complexe. On peut alors s’intéresser à différentes sous-classes de
problèmes.
Configuration entièrement symbolique On peut s’intéresser au cas entièrement symbolique,
i.e.on s’intéresse uniquement aux configurations des agents. On peut alors simplifier le modèle
en considérant que les appels à la couche fonctionnelle terminent toujours correctement, que
les primitiveswaitterminent, et que les assertions des primitivesassertsont toujours vérifiées.
Autrement dit, on se ramène à savoir si on peut trouver une solution à la projection des différentes
contraintes émises par les différents agents.
Configuration mixte L’autre cas qui nous intéresse est de savoir si on peut atteindre une
confi-guration hybride, i.e. généralement une ou plusieurs contraintes sur des valeurs de la couche
fonctionnelle. Par exemple, on pourrait vouloir vérifier si la recette go_to permet réellement
d’aller jusqu’à but. Pour montrer un tel résultat, il faut modéliser assez finement la couche
fonc-tionnelle, en particulier, ses effets (i.e.que le modulep3dgénère un plan qui nous rapproche du
but, et que le modulerflexexécute ce plan, nous rapprochant réellement du but). De plus, dans ce
cadre, il nous faut introduire explicitement l’opérateur⊕pour représenter l’indéterminisme vis à
vis de l’environnement, et explorer les différentes branches qui en résulte.
8.1.4 Synthèse
Dans cette section, nous nous sommes donc intéressés au problème de l’atteignabilité. Nous avons vu qu’en logique linéaire, ce problème est directement lié à la prouvabilité (et à la plani-fication). Ce lien entre déduction en logique linéaire et planification semble très intéressant pour le domaine de la robotique, et est une voie d’étude pour faire plus formellement le lien entre planification et exécution.
Plusieurs simplifications peuvent être faites dans le modèle si l’on s’intéresse uniquement à ce problème. Toutefois, si l’on veut s’intéresser à des configurations non entièrement symboliques, il nous faut un modèle fin de la couche fonctionnelle.
8.2. VÉRIFICATION DE PROPRIÉTÉS DE SÛRETÉ 117