Contrôle d’exécution dans une architecture hiérarchisée pour systèmes autonomes

Les systèmes autonomes 

 Qu’est-ce qu’un système autonome ? 

Un système autonome peut être vu comme une entité agissant dans un environnement fortement variable avec une intervention humaine réduite. Dans cette définition, on considère deux axes symbolisant les besoins liés `à l’autonomie : et – La capacité d’agir avec une intervention humaine réduite : les objectifs fournis au système sont généralement de très haut niveau avec un horizon temporel lointain. Par conséquent, le système doit être capable de prendre toute décision nécessaire au bon déroulement de sa mission et à la réalisation des objectifs visés. – La variabilité de l’environnement : elle menace en permanence le plan de notre système. Il doit donc exister des mécanismes offrant une robustesse à cette menace. Un système ne satisfaisant qu’une seule de ces deux propriétés ne peut  être considérérer comme autonome. Par exemple, un robot industriel agit avec une intervention humaine quasi nulle. Par contre l’environnement dans lequel il ​évolue et les tâches qu’il doit effectuer sont parfaitement connues. Ceci simplifie grandement la problématique et les logiciels embarqués se limitent à des automates déterministes sans réelle prise de décision. Les actions à effectuer ainsi que leur séquence sont connues a priori et ne seront pas remises en cause directement par le système. De meme, les systèmes teleopérés évoluent dans un environnement dont le système ne connaıt pas a priori l’évolution mais le choix des actions ainsi que leur ordonnancement est laissé à un opérateur humain. Ainsi la prise de décision est quasi inexistante pour ce type de système et il ne fait qu’exécuter les commandes de bases initiées par un agent externe. Pour pouvoir agir correctement en tenant compte de ces deux aspects, un système autonome va se trouver avec des besoins nouveaux qu’on ne trouvera pas dans des systèmes plus classiques. Premièrement, de tels systèmes auront des capacités décisionnelles adaptées à leur haut niveau d’autonomie. Les objectifs données ne pouvant ̂ es directement, ce système doit être capable de déduire les actions à effectuer ainsi que leur ordre pour atteindre les buts fixés. Afin de traiter ce type de problème, de tels systèmes embarquent des outils complexes prenant en compte le temps, les ressources ou encore l’incertitude du monde. De nombreux travaux d’intelligence artificielle offrent de telles possibilités. On trouve par exemple des planificateurs symboliques intégrant le temps et les ressources capables de produire des plans avec exécution parallèle des actions. Le second point porte sur la robustesse de notre système vis-à-vis de l’environnement. Le terme de robustesse a longtemps   et e exploité  en robotique pour exprimer la capacité qu’a un système d’effectuer sa tâche malgré les situations adverses. Dans [Lussier 04], les auteurs tentent d’offrir une base plus formelle `à ce terme en le différenciant des autres concepts li és à la surete de fonctionnement. Ainsi ils définissent chacun de ces deux concepts de la façon suivante : La robustesse est la capacité é de rendre un service correct dans une situation I.1. Les systèmes autonomes 11 adverse non prévisible issue de l’environnement (obstacle inattendu, porte fermée, etc.). La tolérance aux fautes est la capacité de rendre un service correct indépendamment de fautes affectant les éléments composant le système (mauvais fonctionnement d’un senseur, faute logicielle, . . .). Cette définition permet de bien différencier la robustesse et la tolérance aux fautes. Toutefois, les techniques utilisées pour chacun restent assez proches ; par exemple, on trouvera fréquemment des redondances fonctionnelles ou des mécanismes de reprise d’exécution dans les deux cas. On ajoute qu’un tel système, pour ˆetre exploitable, doit respecter les propriétés suivantes : Réactivité De par la nature mˆeme de l’environnement, le système doit ˆetre capable de réagir à une situation non prévue dans un délai garantissant l’exécution sˆure de la tˆache qu’il doit accomplir. Sˆureté Les systèmes autonomes sont utilisés dans des situations critiques : ils peuvent ˆetre en interaction avec des humains (robots guides de musée, robots personnels, . . .) ou encore intervenir dans des domaines sensibles (centrales nucléaires, sauvetage, . . .). Il est nécessaire d’offrir des garanties quant à leur bon fonctionnement. Ceci est d’autant plus vrai que l’autonomie est grande. En effet, la prise de décision étant à la charge du système, il devient dès lors critique de pouvoir certifier que les actions décidées ne sont pas une menace quant à son intégrité ainsi que celle de son environnement. Programmabilité, tra¸cabilité, . . . Ces propriétés sont moins critiques et/ou spécifiques aux systèmes autonomes. Toutefois elles sont nécessaires lors de la phase de développement et d’intégration de ce type de plate-forme. On y trouve une multiplicité d’outils exploitant des formalismes et techniques très éloignés les uns des autres. Par conséquent, l’intégration de l’ensemble est difficile et doit être supportée par des outils durant les différentes phases de la conception du système. 

 Tour d’horizon des architectures 

Il est intéressant de constater que c’est la communauté robotique qui offre le plus de travaux sur les architectures g en eriques pour systèmes autonomes. Plusieurs études ont été faites afin d’offrir une plate-forme logicielle g en erique et évolutive intégrant les capacités décisionnelles suffisantes pour que le système puisse agir de façon autonome dans son environnement. Nous présentons ici deux classes d’architectures représentatives de ce qui a pu ̂ être proposé é. Ce bref aperçu nous permettra d’avancer certains avantages des architectures hiérarchique ées pr esentees dans la section I.2. Les architectures comportementales Les architectures comportementales ont la sp cificité de ne pas offrir – du moins pas de façon centralisée – un raisonnement prédictif et un modèle global du monde. L’idée est de diviser le système en un ensemble de comportements relativement simples. Le comportement global du système face à une situation n’est pas explicitement planifié, mais résulte de la composition de ces comportements. Chaque niveau de comportement réagit aux entrées, données par l’environnement, afin de produire une sortie correspondant au comportement associé indépendamment des autres niveaux. Un arbitrage est effectué sur les sorties dans le cas où des décisions de deux niveaux seraient conflictuelles. Parmi les travaux les plus notables dans ce domaine, on trouve ceux de Brooks [Brooks 91] qui s’appuient principalement sur son architecture de subsomption [Brooks 86], repent e dans la figure I.1. On décompose ici le système en plusieurs niveaux avec chacun un ensemble fixe de modules dont le comportement est similaire `à un automate `à ​états finis. La politique de gestion de conflits fait en sorte que les niveaux les plus élevés peuvent bloquer les entrées ou inhiber les sorties des niveaux qui lui sont inférieurs. Ainsi, les niveaux les plus bas correspondront à des actions de bas niveau (par exemple ´évitement basique des obstacles) alors que ceux de plus haut niveau ajoutent des fonctionnalités plus complexes.