Engineering for Robotics and Autonomous Systems Alessandro Cimatti - - PowerPoint PPT Presentation

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
• f real-time and event-based triggers
• System composed of multiple

heterogeneous subsystems

• Critical Functions:
• ABS, drive-by-wire
• Operate switches, level crossings, lights
• Manage on-board power production
• Conflicting objectives:
• Avoid crashes vs move trains

Source: Prof. Rolf Ernst – CAV 2011

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

• Does the system

satisfy the requirements?

• Requirements

validation:

• Are the requirements

flawed?

• Safety assessment
• Is the system able to

deal with faults?

Design

Requirements analysis Architecture definition Components design Safety analysis 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

System Requirements satisfied by

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 checking Infinite state Model checking

Satisfiability

BDDs, SAT solvers SMT 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 analysis Architecture definition Components design Safety analysis SW/HW implement. Planning Execution Monitoring FDIR Replanning

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

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

Control

State Estimation

Physical Plant Plan Execution Monitoring FDIR

Sensing Actuation Hidden State

Planning/ Deliberation

Goals

Operation of adaptive systems

Plan

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?

MONITORING PLANNING EXECUTION

On-ground On-board

ESA Autonomy Levels

Lev. Description Functions E1 Mission execution under ground control; limited capability for safety issues. Real-time control from ground for nominal operations Execution of time-tagged commands for safety issues E2 Execution of pre-planned ground- defined, mission operations on-board Capability to store time-based commands in an on- board scheduler E3 Execution of adaptive mission

• perations on-board

Event-based autonomous operations; Execution of

• nboard operations control procedures

E4 Execution of goal-oriented mission

• nboard

Goal oriented mission re-planning

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

Autonomous Framework

Mission Goals Mission Activity Plan Control Commands

Decision Layer Executive Layer Functional Layer

Hardware Interfaces

Autonomous Architecture Example

Concretization Example

Non-Determinism and Uncertain Duration

• Non-determinism
• Discrete choice
• Uncertainty
• Continuous
• Controllable
• Start
• Uncontrollable
• Effects
• End

CERTAIN DURATION UNCERTAIN DURATION DETERMINISTIC ACTIONS NON DETERMINISTIC ACTIONS

Controllable start Uncontrollable end Uncontrollable effect

Conclusions / Challenges

Conclusions

• Very complex problem
• Many different angles
• Complex systems
• Adaptive systems
• Robotics
• Autonomy
• Model-based approaches and Formal methods to

provide a unifying view

Challenges

• Verification of plans/programs in closed loop with

complex plants

• Merge model checking for sw and for hybrid systems
• Role of planning, scheduling and optimization
• Even domain modeling is nontrivial
• Activity-based modeling vs automata-based modeling
• Link from real-world execution data to models
• Automated modeling, dealing with degradation
• Validation of Intelligence w/o representation
• Do we trust deep learning?

Questions?