Aucun titre de diapositive

Download Report

Transcript Aucun titre de diapositive

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
Perception
Decision
QuickTime™ et un décompresseur
Sorenson Video sont requis pour visualiser
cette image.
Action
Exploration Robot
Personal Robots
Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, 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
• Conceptual
• Methodology
• Tools
Kheops
ComLib
– ComLib
– GenoM
– Propice
– Transgen
– Kheops
– IxTeT
– GDHE
Propice
GenoM
IxTeT
Transgen
Example: Diligent
Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE
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
QuickTime™ et un décompresseur
Vidéo sont requis pour visualiser
cette image.
Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE
Example: Multi Robots
Decision Level
Functional Level
Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE
Example: Autonomous Satellite
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 Level
Modules
Request(param)
data
Reply(report)
database
data
processes
services
library
poster
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 an
instance 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:
input:
c_control_func:
fail_msg:
};
control;
speed::speedRef;
controlSpeed;
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:
data:
exec_task:
};
auto;
state::state, ref::distRef;
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 rulesRaja
->Chatila
6000
branches -> 213 nodes -> 8 depths
& 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
Propice
IxTeT
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
situation-driven
procedures
results
goal + state
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
Example of procedure
Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE
Example of procedure
;;;;;;;;;;;;;;;;;;;;;;;;;
;;; |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)))
Raja Chatila &
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))
Félix
Ingrand, © 2000 LAAS/RIA, Club SEE
(! (CURRENT-MISSION-COMPLETED))
Propice Main Loop
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
• Classical decomposition:
What to do
Objectives
KR
Planning
When & How to do it
Partial order of tasks
Condition/effect operators
Scheduling
Plan
Time and resources
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
actions
Raja Chatila & Félix Ingrand,
© 2000
LAAS/RIA, Club SEE
bricks(?storage)
 [0,
100]
Chronicle Knowledge
Representation
• Predicates: temporally qualified expressions
– Events : instantaneous change of the value of a fluent
event(f(x): (a, b), t)
– Assertions : persistence of the value of a fluent over an
interval
hold (f(x): a, (t1, t2))
– Resource predicates
use (r(x): q, (t, t'))
consume(r(x): q, (t, t'))
produce(r(x):q, (t, t'))
• Constraints
– Temporal constraints
t < t' ; t - t'  [dmin, dmax]
– Atemporal constraints
x = yRaja; Chatila
x ≠&yFélix; Ingrand,
x  ©D2000;LAAS/RIA,
(x  Club
D)SEE
 (y  D')
Planning operators
• Conjunction of
– Predicates : assertions (hold), events and
resource predicates
– Subtasks
– Temporal and atemporal constraints
– Conditional expressions
start
task Incubate (?elt, ?d) {
hold(position(?elt): incubator, (start, end))
end
incubator
incubated
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
?d
-10
A planning operator
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.];
start
t1
t2
}
Load
end
Unload
loaded
state(?rbt)
position(?rbt)
material(?mat, ?strg1)
material(?mat, ?strg2)
?strg1
?strg2
-k
Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE
+k
A planning operator
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 evolution
events 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
Flaws
Constraints
Subgoals
Initial
Chronicle
Threats
Assertions
Resources
Courant partial plan
Insertion resolver
Time-Map
Atemporal
Variables
Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE
Solution plan
Constraints
managers
Example of an IxTeT plan
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