An Architecture for Autonomous Embedded Systems: methods and tools for dependability

An Architecture for Autonomous Embedded Systems:methods and tools for dependability R. Alami, R. Chatila, S. Fleury, M. Ghallab, M. Herrb, F. Ingrand LAAS-CNRS RIA Group Raja Chatila & Félix Ingrand, LAAS/RIA, © 2000, Club SEE

Our Current Point of View on Robotics and Dependability • Complex systems • Emphasis on Software • Specification (formal and semi formal) • Validation • On board computation • Diverse types of software • Personal and service robots • Not limited to robots Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

Introduction • The organization of an Autonomous Embedded System (AES) determines its capacities to achieve tasks and to react to events. • The control structure of an AES must have both • decision-making and • reactive capabilities. • The system must react in a timely fashion to events. • Tasks must be instantiated and refined at execution time according to the actual context. • Situations must be anticipated and the adequate actions decided by the system accordingly. Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

Architecture properties • Programmability • multiple environment or task, • abstract level • Adaptability • Reactivity • Consistent behavior • Robustness • Extensibility / Reusability • Dependability / Provability Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

LAAS Architecture IxTeT Propice Kheops Transgen GenoM ComLib • Conceptual • Methodology • Tools • ComLib • GenoM • Propice • Transgen • Kheops • IxTeT • GDHE

Example: Diligent • Functional Level: • 11 modules • 11 posters • ellipsoids stick to the producer • thin arrows toward the consumers • Request to modules • thick arows “client -> server” Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

Example: Autonomous Satellite • Observation Satellite (PROBA) -> redundancy • 1 module per sensor-actuator • hierarchical modules organization in 4 sub-systems: • trajectory control • orbit prediction • power management • imager control Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

The Functional Level A set of elementary actions: processing functions and task-oriented servo-loop embedded in modules. • Real-time distributed system • Controllable / Observable • Open • Complex experimental systems • Incremental design • The organization of the modules is not fixed. Their interactions depend on the task being executed and on the environment state. Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

Functional LevelModules Request(param) Reply(report) database data data processes poster services library other modules / hardware devices • Acts on asynchronous requests • Client/server relationships not fixed • Data flow via posters Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

GenoM[Fleury, Herrb, Chatila] • Generator of Modules • No need to know the underlying OS, one can concentrate on the functionalities to implement Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

GenoM, Generic Module Structure • Asynchronous Control (external requests or internal event) • Execution task • Cyclic • Upon requests • Standard interface • Requests • Posters • Each module is aninstance of this one Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

GenoM, Internal Automata Per activity • Control Graph • Conflicts, interruptions, etc • Execution Graph • Codels sequencing • Events received/produced Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

GenoM Example /* ---- Module Declaration ---- */ module demo { number: 9000; internal_data: DEMO_STR; }; /* ---- Data Structures Definitions ---- */ #include "demoStruct.h" #include "demoConst.h" /* ---- Module Data Base ---- */ typedef struct DEMO_STR { DEMO_STATE_STR state; /* Current state */ DEMO_SPEED speedRef; /* Speed reference */ double distRef; /* Distance reference */ double posRef; /* Position reference */ double monitor; /* Positions monitors */ }DEMO_STR; /* ---- Requests Declaration ---- */ /* Control Requests */ request SetSpeed { type: control; input: speed::speedRef; c_control_func: controlSpeed; fail_msg: INVALID_SPEED; }; /* Execution Requests */ request MoveDistance { type: exec; input: distance::distRef; c_control_func: controlDistance; fail_msg: TOO_FAR_AWAY; c_exec_func_start: startEngin; c_exec_func: gotoPosition; c_exec_func_end: stopEngin; c_exec_func_inter: stopEngin; incompatible_with: MoveDistance, GotoPosition; exec_task: MotionTask; }; /* ---- Posters ---- */ poster Mobile { update: auto; data: state::state, ref::distRef; exec_task: MotionTask; }; /* ---- Execution Tasks ---- */ exec_task MotionTask { period: 40; delay: 0; priority: 100; stack_size: 4000; c_init_func: InitDemoSDI; }; Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

Dependability Aspects of the Functional Level Done: • Semi-Formal description • Automatic code generation (safer code, safer integration) Todo: • Explicit specific automata • Time to execute codels (for worst case evaluation) • Explicit request between modules • Explicit resources management • Distribution of real-time modules on multiple boards Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

LAAS Architecture Kheops Transgen

The Execution Control level Pivot between functional/decision levels • Purely reactive system that reacts to: • decision level requests • functional level replies • State controller of function level: • maintains functional level state • filters decision level requests • detects and manages conflicts • recovers failures locally Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

Executive with KHEOPS • Input: a set a propositional rules (if ... then ...) • inter module conflicts • resource conflicts (could be synthesised) • manip dependant conflicts (from an expert) • Automatic automaton synthesis: • Complete? (all inputs X state combinations) • Consistent • Optimised (limited and known tree depth) Eg: 130 rules -> 6000 branches -> 213 nodes -> 8 depths Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

Dependability Aspects of the Executive Level Done • Logical interactions between modules • Real time execution / filtering Todo • Complete imputs X states? • Resources management • Complete the synchronous view of the functional modules • Better numerical computation handling (e.g. for resources) Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

LAAS Architecture IxTeT Propice

Decision Level • All processes that require: • anticipation, • global knowledge of the task, • global knowledge of the execution context. • Requirements: • planning capacities • decision making • reaction to incoming events • situations recognition Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

Decision Level • Main components: • Supervision • Situation Recognition • Planning • Structured in supervisor-planner layers missions results goal + state situation-driven procedures supervisor planner plan + modalities signals from processes signals to processes Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

Supervision • Main functions executed in parallel: • Interprets/refines upper missions • Calls planner (if required) • Supervises execution of plans of actions: • Sends requests to lower level • Analyses replies • Requirements: • high-level language (plans, goals,…) • parallel tasks + asynchronous events handling • temporal properties Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

The Procedural Reasoning System PROPICE main components: • a database • which contains facts representing the system view of the world and which is constantly and automatically updated • a library of plans, procedures or scripts • each describing a particular sequence of actions and tests that may be performed to achieve given goals or to react to certain situations, • a task graph • a dynamic set of intentions/tasks currently executing • Intentions (or tasks) are dynamic structures which execute the “intended procedures”, they keep track of the state of execution of these intended procedures, and of the state of their posted subgoals. Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

Goals in Propice The goals in C-PRS can be of different types: • test goal (to test if a statement is satisfied or not) • is the robot loaded with a container? • achieve goal (to realize a statement) • plan a motion to reach a given position • wait goal (to wait until a statement becomes true) • wait until you have received a response from the station or 10 minutes have elapsed • passive maintenance goal (to test if a condition stays true) • keep moving as long as the path is clear • active maintenance (to keep a condition true) • keep moving while maintaining a safe distance from area-23 • assertion goal (to assert a statement in the database) • retraction goal (to retract a statement from the database) Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

;;;;;;;;;;;;;;;;;;;;;;;;; ;;; |Control Band Move| ;;;;;;;;;;;;;;;;;;;;;;;;; (defop |Control Band Move| :invocation (FR BAND BAND_MOVE $RQST-ID $REPORT $DATA) :context (& (NBSUCCESS $NBSUCCESS)(NBBANDCOLLISION $NBBANDCOLLISION) (NBBANDINVALIDSTATE $NBBANDINVALIDSTATE)(NBFAILED $NBFAILED)) :body ((~> (FR BAND BAND_MOVE $RQST-ID $REPORT $DATA)) (~> (IR BAND BAND_MOVE $RQST-ID $ACTID)) (! (kill-all-survloc)) (IF (? (EQUAL $REPORT "OK")) (! (SPEAK "Navigation Mission Completed!")) (! (ABORT-CURRENT-MISSION)) (! (CURRENT-MISSION-COMPLETED)) (=>(NBSUCCESS (+ $NBSUCCESS 1))) ELSEIF (? (EQUAL $REPORT "COLLISION_DETECTED")) (! (ABORT-CURRENT-MISSION)) (? (CURRENT-MISSION $CURRENT-NAV)) (=> (NBBANDCOLLISION (+ $NBBANDCOLLISION 1))) (=> (PP-ADD-OBSTACLE 1)) (IF (! (EXECUTE $CURRENT-NAV)) ELSE (! (CURRENT-MISSION-COMPLETED))) ELSEIF (? (EQUAL $REPORT "JOYSTICK_IN_USE")) (! (SUSPEND-CURRENT-MISSION)) (! (WAIT-JOYSTICK-END)) (! (CHECK-IR-ON)) (! (RESUME-CURRENT-MISSION)) ELSEIF(? (EQUAL $REPORT "INVALID_STATE")) (=> (NBBANDINVALIDSTATE (+ $NBBANDINVALIDSTATE 1))) (! (PRINTF (FORMAT "Control Band Move : INVALID_STATE \n"))) (! (SPEAK "Navigation failed \n")) (=> (NBFAILED (+ $NBFAILED 1))) (! (ABORT-CURRENT-MISSION)) (! (CURRENT-MISSION-COMPLETED)) ELSE ;(! (SPEAK (term-string-cat "Band: " $report))) (=> (band-uncatched-error BAND_MOVE $RQST-ID $REPORT $DATA)) ) ) ) Example of procedure Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

Dependability Aspects of the Decisional Level (Supervisor) Done • Guaranteed reaction time • Colored Petri Net equivalent (but not usable in practice) Todo • Lack of logical properties • Better integration for dynamic planning Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

Task and Mission Planning • Queried by the supervision • Must deal with: • time constraints (duration, orders, parallelism, …) • resources constraints • predictable events (contingent changes, resources-availability profiles, …) • Requirements: • powerful representation to specify model of tasks Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

Task Planning Integrating Time and Resources • Classical separation States: as sets of fluent values Actions: as state transitions • Not convenient for • Concurrent actions with duration • Actions that preserve a value, e.g., servoing • Goals situated in time with maintenance conditions • Dynamic domain with contingent fluents • Other desirable features • Dynamics as concurrent histories of fluent values over time (timelines) • Elementary actions as change or persistence of fluent values • Planning operators as purposeful set of concurrent elementary actions Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

Planning vs scheduling When & How to do it What to do Partial order of tasks Planning Scheduling Objectives Plan Condition/effect operators Time and resources KR • Classical decomposition: Not convenient if interaction planning/scheduling • Desirable integrated approach: • Homogeneous knowledge representation : • Single search space Example of IxTeT Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

The IxTeT system (Indexed Time Table) • IxTeT kernel: an efficient time-map manager • Time-point algebra relations and restricted interval algebra • IxTeT kernel used in • plan recognition • plan synthesis • Common knowledge representation : chronicles Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

Chronicle Knowledge Representation • Time : linearly ordered discrete set of instants • Multivalued domain attributes • Rigid attributes: connected(room1, room2); situated(printer1, room3) • Flexible attributes: fluents and resources • Contingent fluents day-light; delivery(material) • Controllable fluents, ranging over discrete values, set by actions location(?robot)  SITES • Resources: constant, real values, relatively changed by actionsbricks(?storage)  [0, 100] Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

Chronicle Knowledge Representation • Predicates: temporally qualified expressions • Events : instantaneous change of the value of a fluentevent(f(x): (a, b), t) • Assertions : persistence of the value of a fluent over an intervalhold (f(x): a, (t1, t2)) • Resource predicatesuse (r(x): q, (t, t')) consume(r(x): q, (t, t')) produce(r(x):q, (t, t')) • Constraints • Temporal constraintst < t' ; t - t'  [dmin, dmax] • Atemporal constraintsx = y ; x ≠ y ; x  D ; (x  D)  (y  D') Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

Planning operators start end incubator incubated ?d -10 • Conjunction of • Predicates : assertions (hold), events and resource predicates • Subtasks • Temporal and atemporal constraints • Conditional expressions task Incubate (?elt, ?d) { hold(position(?elt): incubator, (start, end)) event(state(?elt):(?s, incubated), end) hold(temp(incubat): ?d, (start, end)) use(power: 10, (start, end)) (end-start) in [9., 10.] } Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

A planning operator end start t1 t2 Load Unload state(?rbt) position(?rbt) material(?mat, ?strg1) material(?mat, ?strg2) loaded ?strg1 ?strg2 - k + k task Transport-material (?mat, ?q, ?strg1, ?strg2, ?rbt) { timepoint t1, t2 task Load (?mat, ?q, ?strg1) (start, t1)); task Unload(?mat, ?q, ?strg2) (t2, end)); hold (state(?robot) : loaded, (t1, t2)); ?strg1 ≠ ?strg2 ; ?rbt in ROBOTS ?t1 < ?t2 ; end - start in [1., 2.]; } Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

Problem description • Domain description Rigid attributes, fluents, resources, constants and domain constraints • Problem description: input chronicle • Founded expressions on fluents and resources • Initial facts • Expected evolutionevents and assertions on contingent and controllable fluents • Resource availability profiles • Unfounded expressions on fluents (goals) • Temporal and atemporal constraints Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

Resolving flaws Valid plan: its constraints are consistent, and it contains no flaw, i.e. • No Unfounded expressions • Disjunction of new tasks, assertions (hold), constraints • No Inconsistent expressions • Disjunction of temporal constraints and atemporal constraints • No Resource conflicts • Disjunction of temporal constraints (scheduling), atemporal constraints (allocation), and tasks (resource production) Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

IxTeT Main Algorithm Choice of a flaw and resolver Resolvers Operators Constraints Assertions Flaws Subgoals Threats Resources Initial Chronicle Courant partial plan Solution plan Insertion resolver Constraints managers Atemporal Variables Time-Map Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

Dependability Aspects of the Decisional Level (Planning) Done • Sound and logically founded • Time is central Todo • Use a representation of actions which is consistent with the functional level • Better integration of supervision/ plan execution and planning Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

Conclusion • Generic architecture for autonomous systems • 3 hierarchical levels with well defined function and interfaces • functional level (a set of independent modules) • execution control (control of inter-modules execution) • decision level (procedures planing and supervision) • Adapted tools to design and connect every level Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

Dependability Perspectives • Use a consistent action representation from the functional level up to the planning level • Improve the specification/verification from the executive level • Better representation of module interactions • Temporal validations of the functional modules • Better representation of action automaton Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

An Architecture for Autonomous Embedded Systems: methods and tools for dependability