Computer-Assisted Engineering for Robotics and Autonomous Systems Alessandro Cimatti cimatti@fbk.eu February 12 – 17 , 2017 Dagstuhl Seminar 17071
Computer-Assisted Engineering for Autonomous Systems: a formal methods perspective
Computer-Assisted Engineering for… complex systems
The Design Challenge • Designing complex systems • Automotive • Railways • Aerospace • Industrial production • Sources of complexity: • Hundreds of functions • Networked control • Real-time constraints • Complex execution model with mixture of real-time and event-based triggers • System composed of multiple heterogeneous subsystems • Critical Functions: Source: Prof. Rolf Ernst – CAV 2011 • ABS, drive-by-wire • Operate switches, level crossings, lights • Manage on-board power production • Conflicting objectives: • Avoid crashes vs move trains
A Wheel Brake System • Control brake for aircraft wheels • Redundancy • Multiple BCSU • Hydraulic plants • Functions • Asymmetrical braking • Antiskid • Single wheel/coupled • depending on control mode
Alessandro Cimatti 6
Life Cycle of Complex Systems • Functional correctness Design • Does the system satisfy the requirements? Requirements • Requirements analysis validation: Architecture definition • Are the requirements Components flawed? design • Safety assessment Safety analysis • Is the system able to deal with faults? SW/HW implement.
CAE for complex systems • Source of complexity: critical systems • Must provide reliable response to very wide range of adverse conditions • Redundancy, reconfiguration • Examples: • Wheel brake system • Power supply on board of a large-sizes aircraft • Key remark: operational conditions and response thoroughly analyzed upfront • Validation of reconfiguration policies • As designed “off - line”
“Old - fashioned” Model Checking • Does system satisfy requirements? • System as finite state model • Requirements as temporal properties Requirements satisfied by System
Models – where do they come from? • Models are directly extracted from design languages • Verilog, VHDL • AADL, SysML, UML • Altarica • C • Proprietary languages Alessandro Cimatti 10
The three main challenges in Formal Verification • Scalability • Scalability • Scalability The ability to analyze large models automatically 11
Formal verification engines • From BDD- based engines… • Fix-point computation • to SAT-based engines • Bounded model checking, induction, interpolation, IC3 • SMT: SAT + decision procedures • Verification Modulo Theories • From finite- state… • Circuits, microcode • To infinite-state • Software, timed systems, hybrid systems, closed loop
Satisfiability vs Verification (or, combinational vs sequential) Boolean Modulo theories Verification Finite state model Infinite state checking Model checking Satisfiability BDDs, SMT solvers SAT solvers
Many levels of expressiveness • Finite state transition systems • Infinite state transition systems • Timed automata • Hybrid automata • Software • Concurrent software • Closed-loop software + hybrid plant
A “modern” view of FM • Requirements analysis • Contract-based design • Delegation of top-level requirements to subcomponents • Correctness by construction • Safety analysis • Construct fault trees, FMEA tables • Timed Failure Propagation Graphs (TFPG) • Tool chains: • COMPASS • http://www.compass-toolset.org/ • OCRA, nuXmv, xSAP • http://nuxmv.fbk.eu/, http://ocra.fbk.eu, http://xsap.fbk.eu • Applications: • AIR 6110 wheel brake system (https://es-static.fbk.eu/projects/air6110/) • NASA nextgen function allocation (https://es-static.fbk.eu/projects/nasa-aac/)
Computer-Assisted Engineering for… adaptive systems
Life Cycle of Adaptive Systems Design Operation Requirements Planning analysis Architecture Execution definition Components Monitoring design Safety analysis FDIR SW/HW Replanning implement.
From design to operation… • Planning • plan how to achieve desired “firing” sequence • retrieve pipes from holds, pre-weld, send to firing line, final weld • Execution Monitoring • welding may fail, activities can take more time than expected • plant may fail • Fault Detection, Fault Identification/Isolation • is there a problem? where is it? • Fault Recovery • put off-line problematic equipment • Replanning • identify alternative course of actions, e.g. reroute pipes
High level Objective • Support Project Designers • Identify plant configurations and operations sequence while fulfilling project requirements • Engineering Tool at support of Supervisor • Evaluation of the performances of the operation sequences and configuration (manually or automatically produced) • Worst case execution time • Production rate • … • Nominal and in presence of faults after re-planning
Project outcomes • Simulator and Evaluator for the CASTORONE plant to be used for evaluation of plans, and compute performance measures before actual deployment for decision making • Planning layer • Nominal planning (no faults) • Re-planning in presence of faults (product or plant) • Monitoring infrastructure to monitor correct execution and predict delays on the completion of the execution of a plan while executing, and identify faults
Simulation and Evaluation GUI
The Monitor (Operations Precedence Network) Operations network for 2 TJs
Factory automation projects • Activity scheduling in galvanic coating factories • Execute precise “recipe” • Quick re-plan for production changes • Fault tolerance • Estimation of expected costs • Helping in design of flexible and efficient plants
Galvanic processes and plants • Sequence of chemical washes • Timing is crucial • Pieces moved in stocks by carriage-mounted forklifts • Once started, cannot be interrupted without quality degradation
Current state of the art
Operation of adaptive systems State Estimation Monitoring FDIR Goals Plan Planning/ Deliberation Plan Control Execution Sensing Actuation Physical Plant Hidden State
Adaptive/reconfigurable systems • Highly optimized functions in controlled environments • Unpredictable sequence of missions • Arrival of urgent production batch • Degraded operational conditions • CAE for • Automated programming • Simulation and cost estimation
Automated planning and monitoring • Plan validation • Does plan achieve required objectives? • Could be manually generated • Planning as generation of suitable course of actions • Actions with possibly uncertain durations • Actions with different costs • Execution Monitoring, FDI • Is execution proceedings as expected? • Fault detection and identification • Can be reduced to analysis of transition systems • Planning as model checking paradigm
Computer-Assisted Engineering for… robotics Many important “low level” issues: RTOS, WCET, scheduling, collision avoidance, high-speed motion control, path/motion planning, … Not covered here
Computer-Assisted Engineering for… autonomous systems
Autonomy levels in operation • Or, where are operation activities carried out? PLANNING EXECUTION MONITORING On-ground On-board
ESA Autonomy Levels Lev. Description Functions E1 Mission execution under ground control; Real-time control from ground for nominal operations limited capability for safety issues. Execution of time-tagged commands for safety issues E2 Execution of pre-planned ground- Capability to store time-based commands in an on- defined, mission operations on-board board scheduler E3 Execution of adaptive mission Event-based autonomous operations; Execution of operations on-board onboard operations control procedures E4 Execution of goal-oriented mission Goal oriented mission re-planning onboard ECSS-E-70-11A Autonomy Level Definitions
Autonomy Levels • E1: Exec under ground control • E2: Exec of pre-planned mission operations on-board • Action sequence planned on ground, lower level execution on-board • Very common, applied to spacecrafts • E3: Exec of adaptive mission operations on-board • High-level tasks planned on ground, adaptive execution on-board • Foreseen in future missions • E4: Exec of goal-oriented mission operations on-board • High-level mission goals on ground, all the rest on board • Currently at prototypical level
Some Remarks • The level of autonomy has a direct impact on the type of plan... • produced by the planning system (or team) • dealt with by the on-board executor • The reasoning processes on-ground and on-board must be tightly related! • E.g. interpret on ground what happened on board • more CPU but less information • Dynamic increase/decrease of autonomy level
A General Autonomy Architecture Mission Goals Control Commands Mission Activity Plan Autonomous Framework Decision Layer Executive Layer Functional Layer Hardware Interfaces
Autonomous Architecture Example
Concretization Example
Recommend
More recommend
