A generic modular architecture for the control of an autonomous spacecraft G´ erard Verfaillie & Marie-Claire Charmeau ONERA & CNES, Toulouse, France

IWPSS 2006, Baltimore, MD, USA, 23-25/10/06

The AGATA project

CNES-ONERA-LAAS AGATA project : Autonomy Generic Architecture: Tests and Applications. Objective : to build a ground demonstrator of an autonomous spacecraft, in order to explore the technical challenges and to convince project teams that autonomy is possible and useful.

IWPSS 2006, Baltimore, MD, USA, 23-25/10/06

1

First objective

To define an autonomous control architecture.

IWPSS 2006, Baltimore, MD, USA, 23-25/10/06

2

Existing architectures

The most usual in the robotics and space domain: based on three levels: 1. deliberative: mission tracking, generation and maintenance of activity plans; 2. reactive: execution triggering and tracking; 3. functional: encapsulation of all the basic system functionalities. Main identified drawbacks:

Deliberative Reactive Fonctional

1. no explicit place for situation tracking (system and environment state tracking); 2. potential lack of reactivity: no action outside planning, which is the core of the control system; 3. lack of modularity, except for the functional level. IWPSS 2006, Baltimore, MD, USA, 23-25/10/06

3

Expected qualities of an autonomous control architecture

1. genericity; 2. adequacy for closed-loop control: (a) (b) (c) (d) (e)

state tracking; objective tracking; decision making; decision execution; control supervision;

3. possible guarantees in terms of control quality and reactivity; 4. control modularity; 5. control and data encapsulation. IWPSS 2006, Baltimore, MD, USA, 23-25/10/06

4

Main features of the proposed architecture (1)

Inspired from GENOM [LAAS-CNRS] and IDEA [NASA-Ames].

1. decomposition of the control into control modules; 2. hierarchical organization of the modules; 3. encapsulation of control and data inside each module; 4. communications between modules via : (a) system control requests; (b) information about request and system states;

IWPSS 2006, Baltimore, MD, USA, 23-25/10/06

5

Main features of the proposed architecture (2)

5. organization common to all modules: (a) system control part: i. system state tracking; ii. received request tracking; iii. decision making; iv. emitted request tracking; (b) model part: static and dynamic models; (c) information processing part; (d) module supervision part; (e) standard communication part.

Close to works from Brian Williams & al. [MIT]. IWPSS 2006, Baltimore, MD, USA, 23-25/10/06

6

Schema of a generic control module Control module Communication

Supervision

Received request tracking

Control modes and parameters

Received request state

Model Static and dynamic model

Reasoning tasks

Reasoning tasks

System state tracking

Decision making

Current belief on system state

Current decision Emitted request state

Information processing services

IWPSS 2006, Baltimore, MD, USA, 23-25/10/06

Emitted request tracking

7

Example of decomposition of the control of an Earth surveillance and observation satellite

Satellite

Attitude

Orbit

Data compression memorization

Data downloading

Board−ground communications

Detection

Observation

Attitude sensors and actuators

Orbit sensors and actuators

Energy

Mass memory

Antennas

Detection instrument

Sight mirror sensors and actuators

IWPSS 2006, Baltimore, MD, USA, 23-25/10/06

Observation instrument

8

Exchanges of control requests between modules

Satellite

Attitude

Orbit

Data compression memorization

Data downloading

Board−ground communications

Detection

Observation

Attitude sensors and actuators

Orbit sensors and actuators

Energy

Mass memory

Antennas

Detection instrument

Sight mirror sensors and actuators

Observation instrument

Control requests

IWPSS 2006, Baltimore, MD, USA, 23-25/10/06

9

Exchanges of information about request and system states between modules

Satellite

Attitude

Orbit

Data compression memorization

Data downloading

Board−ground communications

Détection

Observation

Attitude sensors and actuators

Orbit sensors and actuators

Énergy

Mass memory

Antennas

Detection instrument

Sight mirror sensors and actuators

Observation instrument

Information about request and system states

IWPSS 2006, Baltimore, MD, USA, 23-25/10/06

10

Example of module at the lowest functional level: the sight mirror control module (sensor + actuator) Observation module

Soft

Mirror Request Request orientation status result request

Received request tracking Mirror position

Motor state

Mirror orientation request

System state tracking

Mirror position measure

Request result

Decision making Mirror movement request

Motor state

Emitted request tracking

Request result

Movement computation request

Information processing tasks

Sight mirror module

Soft

Mirror Request Request movement status result request

Physical mirror (sensor and actuator)

IWPSS 2006, Baltimore, MD, USA, 23-25/10/06

Hard

11

Example of module at a higher level: the observation control module Soft

Satellite module

Soft Observation Request Request requests status result

Orbit module

Received request tracking Observation requests

Energy module

Request result Decision rules

Pre−computed policy

Orbital position Information Observation Decision Energy level processing parameters making computation Memory level tasks Mirror orientation On−line On−line planning decision making Motor state Instrument state Requests

Soft

Mass memory module

Emitted request tracking Observation module

Soft

Mirror orientation request

Sight mirror module Soft

IWPSS 2006, Baltimore, MD, USA, 23-25/10/06

Soft Instrument activation request

Observation instrument module Soft

Data compression and memorization request

Data compression and memorization module Soft

12

Dynamic behavior of each module (1)

Each component inside a module (system state tracking, received request tracking, decision making, emitted request tracking . . . ) is reactive i.e, able to react at the rythm of its environment (requests, information . . . ).

It can be defined using synchronous languages, like for example Esterel.

Some of them may need the support of deliberative tasks (a planning task for the decision making component, a diagnosis task for the system state tracking component . . . ).

IWPSS 2006, Baltimore, MD, USA, 23-25/10/06

13

Dynamic behavior of each module (2)

When a reactive component needs the support of a deliberative task, it must be able at any time: 1. to activate the deliberative task; 2. to give it a deadline for an answer; 3. to check an answer against the current state of the system and of the requests; 4. to produce itself a default answer when the deadline occurs in case of no answer or incorrect answer.

IWPSS 2006, Baltimore, MD, USA, 23-25/10/06

14

Dynamic behavior of each module (3)

In the other direction, the deliberative task must produce an (as good as possible) answer by the deadline, for example by using an anytime algorithm able to produce better and better solutions as computing time increases.

Example for a planning task: to reason on longer and longer horizons or on more and more precise data, in order to produce an (as good as possible) decision when time is up to decide, for example when the satellite enters a ground area visibility window in case of an observation decision.

IWPSS 2006, Baltimore, MD, USA, 23-25/10/06

15

Interaction between a reactive decision making component and a deliberative planning task

events

Environment (reactive) actions

IWPSS 2006, Baltimore, MD, USA, 23-25/10/06

Decision making (reactive)

run/abort deadline request and system state candidate decisions

Planning (deliberative)

16

Controversial message to the IWPSS community

In the setting of the autonomous control of a spacecraft in a dynamic and uncertain environment (physical system and environment state, user requests . . . ), with reactivity requirements and limited computing resources, the core of the control system is not planning, but decision making. Planning is only a support for decision making. By anticipating the possible future, it can help decision making to make a good decision at a given time. But decision making must be possible without planning, for example by using default decision rules. Anyway, what is important is the decision, not the plan.

IWPSS 2006, Baltimore, MD, USA, 23-25/10/06

17

Conflicts between modules (1)

A decision making component inside each module → possible conflicts between decisions, for example for the access to common resources (energy, memory . . . ).

Two main ways of managing such conflicts: 1. at a low level, by the modules that manage these resources → high reactivity, weak anticipation ability; 2. at a high level, by a module M higher in the hierarchy than the potentially conflicting modules M1 and M2 → lower reactivity, stronger anticipation ability.

IWPSS 2006, Baltimore, MD, USA, 23-25/10/06

18

Conflicts between modules (2)

A system state tracking component inside each module → possible conflicts between system state estimations, for example by two sensors of the same feature (orbital position, attitude . . . ).

Need for a module M higher in the hierarchy than the potentially conflicting modules M1 and M2, able to merge local beliefs produced by M1 and M2 and to produce a global belief about the state of this feature F . → Any other module in the architecture that would need to know the current state of F (in fact, the current belief about the state of F ) must ask M for that, and not M1 or M2.

IWPSS 2006, Baltimore, MD, USA, 23-25/10/06

19

What about FDIR?

FDIR = Fault Detection, Identification, and Recovery. Detection and identification → System state tracking. Recovery → Decision making. → FDIR inside each module, with the same rules to manage conflicts in terms of system state tracking and decision making (see above). → No strict frontier between normal and anormal behavior.

IWPSS 2006, Baltimore, MD, USA, 23-25/10/06

20