An architecture for autonomous embedded systems methods and tools for dependability
Download
1 / 49

An Architecture for Autonomous Embedded Systems: - PowerPoint PPT Presentation


  • 275 Views
  • Updated On :

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. General Context and Examples. Perception. Decision. Action.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'An Architecture for Autonomous Embedded Systems:' - LionelDale


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
An architecture for autonomous embedded systems methods and tools for dependability l.jpg

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


General context and examples l.jpg
General Context and Examples

Perception

Decision

Action

Personal Robots

Exploration Robot

Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE


Our current point of view on robotics and dependability l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
LAAS Architecture

IxTeT

Propice

Kheops

Transgen

GenoM

ComLib

  • Conceptual

  • Methodology

  • Tools

    • ComLib

    • GenoM

    • Propice

    • Transgen

    • Kheops

    • IxTeT

    • GDHE


Example diligent l.jpg
Example: Diligent

Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE


Example diligent8 l.jpg
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 multi robots l.jpg
Example: Multi-Robots

Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE


Example multi robots10 l.jpg
Example: Multi Robots

Decision Level

Functional Level

Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE


Example autonomous satellite l.jpg
Example: Autonomous Satellite

Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE


Example autonomous satellite12 l.jpg
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 l.jpg
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 level modules l.jpg
    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 l.jpg
    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 l.jpg
    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 l.jpg
    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 l.jpg
    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 l.jpg
    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 architecture20 l.jpg
    LAAS Architecture

    Kheops

    Transgen


    The execution control level l.jpg
    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 l.jpg
    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 l.jpg
    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 architecture24 l.jpg
    LAAS Architecture

    IxTeT

    Propice


    Decision level l.jpg
    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 level26 l.jpg
    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 l.jpg
    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 l.jpg
    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 l.jpg
    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


    Example of procedure l.jpg
    Example of procedure

    Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE


    Example of procedure31 l.jpg

    ;;;;;;;;;;;;;;;;;;;;;;;;;

    ;;; |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


    Propice main loop l.jpg
    Propice Main Loop

    Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE


    Dependability aspects of the decisional level supervisor l.jpg
    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 l.jpg
    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 l.jpg
    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 l.jpg
    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 l.jpg
    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 l.jpg
    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 representation39 l.jpg
    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 l.jpg
    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 l.jpg
    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


    A planning operator42 l.jpg
    A planning operator

    Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE


    Problem description l.jpg
    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 l.jpg
    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 l.jpg
    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


    Example of an ixtet plan l.jpg
    Example of an IxTeT plan

    Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE


    Dependability aspects of the decisional level planning l.jpg
    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 l.jpg
    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 l.jpg
    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


    ad