an architecture for autonomous embedded systems methods and tools for dependability l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
An Architecture for Autonomous Embedded Systems: methods and tools for dependability PowerPoint Presentation
Download Presentation
An Architecture for Autonomous Embedded Systems: methods and tools for dependability

Loading in 2 Seconds...

play fullscreen
1 / 49

An Architecture for Autonomous Embedded Systems: methods and tools for dependability - PowerPoint PPT Presentation


  • 281 Views
  • Uploaded 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: methods and tools for dependability' - 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

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
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
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
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
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
LAAS Architecture

IxTeT

Propice

Kheops

Transgen

GenoM

ComLib

  • Conceptual
  • Methodology
  • Tools
    • ComLib
    • GenoM
    • Propice
    • Transgen
    • Kheops
    • IxTeT
    • GDHE
example diligent
Example: Diligent

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

example diligent8
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
Example: Multi-Robots

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

example multi robots10
Example: Multi Robots

Decision Level

Functional Level

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

example autonomous satellite
Example: Autonomous Satellite

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

example autonomous satellite12
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
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
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
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
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
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
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
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
LAAS Architecture

Kheops

Transgen

the execution control level
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
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
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
LAAS Architecture

IxTeT

Propice

decision level
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
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
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
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
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
Example of procedure

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

example of procedure31
;;;;;;;;;;;;;;;;;;;;;;;;;

;;; |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
Propice Main Loop

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

dependability aspects of the decisional level supervisor
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
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
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
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
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
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
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
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
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
A planning operator

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

problem description
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
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
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
Example of an IxTeT plan

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

dependability aspects of the decisional level planning
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
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
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