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


  • 283 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

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


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
    1. 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

    2. General Context and Examples Perception Decision Action Personal Robots Exploration Robot Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

    3. 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

    4. 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

    5. 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

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

    7. Example: Diligent Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

    8. 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

    9. Example: Multi-Robots Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

    10. Example: Multi Robots Decision Level Functional Level Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

    11. Example: Autonomous Satellite Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

    12. 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

    13. 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

    14. 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

    15. 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

    16. 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

    17. 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

    18. 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

    19. 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

    20. LAAS Architecture Kheops Transgen

    21. 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

    22. 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

    23. 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

    24. LAAS Architecture IxTeT Propice

    25. 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

    26. 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

    27. 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

    28. 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

    29. 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

    30. Example of procedure Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

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

    32. Propice Main Loop Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

    33. 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

    34. 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

    35. 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

    36. 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

    37. 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

    38. 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

    39. 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

    40. 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

    41. 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

    42. A planning operator Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

    43. 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

    44. 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

    45. 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

    46. Example of an IxTeT plan Raja Chatila & Félix Ingrand, © 2000 LAAS/RIA, Club SEE

    47. 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

    48. 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

    49. 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