Simulation and Visualization Tool Design for Robot Software Zhou - - PowerPoint PPT Presentation

Simulation and Visualization Tool Design for Robot Software

Zhou Lu, Tjalling Ran and Jan Broenink Robotics and Mechatronics, University of Twente August 22, 2016

Outline

◮ Introduction ◮ Design of Simulation ◮ Visualizing Simulation Results ◮ Results ◮ Conclusions and Recommendations [ Z. Lu ] 2/18

Introduction - Context

◮ Cyber-Physical Systems (CPS) co-design: why challenging?

◮ Combine multiple different engineering disciplines/domains ◮ Seamless interaction with physical environments ◮ Concurrency is intrinsically presented in CPS ◮ Most CPS are safety-critical

[ Z. Lu ] 3/18

Introduction - Related Work

◮ Design CPS using Model-Driven Design (MDD)

◮ Models can be formalized and checked ◮ Modelled systems can be tested and simulated off-line ◮ Ease tedious and error-prone concurrent software development

3b Plant model (RT sim) Real plant 4 Target execution platform Target execution platform I/O I/O stub Legend Plant dynamics 1 Time Triggered & Discrete Event software 3a Plant dynamics 2 Control laws (Loop control,CT) (G)UI, Supervisory, Sequence, Safety Software design Controller design Mechanics design Electronics design Plant dynamics & 3D animation ECS software architecture a) b) c) d) e) 20-sim (co) simulation Simulation time Real-time TERRA

[ Z. Lu ] 4/18

Introduction - Problem Statements and Motivation

◮ Iterative and incremental design and development in MDD

◮ Sufficient verification and/or validation of models are required

◮ MDD in CPS: different domain models are involved

◮ Discrete-Event and Continuous-Time domains

◮ Co-simulation is needed to support co-design ◮ Current infrastructure: TERRA

◮ Does not provide sufficient simulation nor visualization facilities

[ Z. Lu ] 5/18

Design of Simulation - Obtain Executable Models

◮ Executable models

◮ Executability: depends more

• n execution tools

◮ Execution tools: depend on

assessment requirements

◮ Required assessments in CPS

◮ Process execution order ◮ Results of algorithms

fi

[ Z. Lu ] 6/18

Design of Simulation - Obtain Executable Models

◮ Executable models

◮ Executability: depends more

• n execution tools

◮ Execution tools: depend on

assessment requirements

◮ Required assessments in CPS

◮ Process execution order ◮ Results of algorithms

◮ Two strategies to obtain

executable models

◮ Model interpretation ◮ Code generation Model Interpretation Strategy

Intermediate Representation

Virtual Execution Environment

Execution (Simulation) Engine

conforms to DSL meta-model

Model

DSL Lexical Analysis DSL Syntactic Analysis

platform specification static libraries shared libraries

Source Code Compiler Source Code

Real Execution Environment Code Generation Strategy

Machine Code (Assemble, Java Bytecode...)

[ Z. Lu ] 6/18

Design of Simulation - Analysis

◮ Model Interpretation

◮ Relies on the existence of a

Virtual Execution Environment (VEE)

◮ Interpretation can be done

dynamically

◮ Code generation

◮ Uses M2T transformation to

generate lower-level system representation

◮ Platform-dependent Model Interpretation Strategy

Intermediate Representation

Virtual Execution Environment

Execution (Simulation) Engine

conforms to DSL meta-model

Model

DSL Lexical Analysis DSL Syntactic Analysis

platform specification static libraries shared libraries

Source Code Compiler Source Code

Real Execution Environment Code Generation Strategy

Machine Code (Assemble, Java Bytecode...)

[ Z. Lu ] 7/18

Design of Simulation - Analysis

◮ From a practical perspective: code generation is preferred

◮ Control algorithms generated from 20-sim must be taken into

account

◮ TERRA is able to generate C++ code ◮ Model interpretation will just be simulation without code

implementation

[ Z. Lu ] 8/18

Design of Simulation - Analysis

◮ Coupling strategies

◮ Loose-Coupling Execution ◮ Generate source code from different models ◮ Generate APIs for interacting purpose ◮ Execution coordinator ◮ Tight-Coupling Execution ◮ Integrate different models by using M2M transformations ◮ Generate code from an integrated model

[ Z. Lu ] 9/18

Design of Simulation - A hybrid simulation approach

◮ Tight-Coupling Execution

◮ Integrate 20-sim controller model into TERRA ◮ Generate code from the integrated model

Controller Model Plant Dynamics 20-sim TERRA TERRA CSP TERRA CSP TERRA CSP LUNA Lib Execution Enviroment

Visualization

LoggerServer Animation Plug-ins SimCon Plug-ins LogInterpretor Plug-ins

Edit Models (Co) Simulation

Platform Specific Executable

Step1 Step2

FMI Wrapper FMU

Step3

[ Z. Lu ] 10/18

Design of Simulation - A hybrid simulation approach

◮ Loose-Coupling Execution

◮ Generate code from C/P models ◮ Generate APIs from TERRA FMI interface model ◮ FMI wrapper as coordinator

Controller Model Plant Dynamics 20-sim TERRA TERRA CSP TERRA CSP TERRA CSP LUNA Lib Execution Enviroment

Visualization

LoggerServer Animation Plug-ins SimCon Plug-ins LogInterpretor Plug-ins

Edit Models (Co) Simulation

Platform Specific Executable

Step1 Step2

FMI Wrapper FMU

Step3

[ Z. Lu ] 11/18

Design of Simulation - A hybrid simulation approach

◮ Visualizing simulation results

◮ Process execution order ◮ Results of algorithms

◮ Iterative and incremental design and development

Controller Model Plant Dynamics 20-sim TERRA TERRA CSP TERRA CSP TERRA CSP LUNA Lib Execution Enviroment

Visualization

LoggerServer Animation Plug-ins SimCon Plug-ins LogInterpretor Plug-ins

Edit Models (Co) Simulation

Platform Specific Executable

Step1 Step2

FMI Wrapper FMU

Step3

[ Z. Lu ] 12/18

Visualizing Simulation Results

◮ Five states for CSP constructs and processes

◮ Activate, Activating other processes, Waiting, Running, Done

Activating

• ther processes

Activate Done Waiting

P ; Q

Activating

• ther processes

Activate Done Waiting

P || Q P [] Q

Waiting Activate Done Running

writer !<variable> reader ?<variable>

◮ Logging facilities were designed to capture state changes

◮ Registration phase ◮ States recording phase time stamp State Index 1 State Index 2 State Index 3

Process ID:1 Process ID:2 Process ID:3

State Index n-1 State Index n

Process ID:n Process ID:n-1 ............

[ Z. Lu ] 13/18

Visualizing Simulation Results

◮ Overall structure of the visualization

◮ Execute models ◮ Logged data will be stored as CSV files ◮ Mapping model elements ◮ Parsing logged data ◮ Publishing states to a graphical view

Execution Enviroment LUNA Executable logger log receiver Development Platform TERRA T

• ol Suite

Console

TERRA TERRA CSP

View

TERRA CSP

T arget Platform

Tree Structure State Changes Signal Values

Animation

Mapping Parsing Publishing

[ Z. Lu ] 14/18

Results

◮ Loop control model for testing

PARALLEL * Controller Plant Step

SEQUENTIAL_Step

!

XXStepModel

SEQUENTIAL_Controller INS

? ?

XXControllerModel

!

v_output v_SP v_MV

SEQUENTIAL_Plant

?

XXLinearSystemModel

!

v_y v_u

[ Z. Lu ] 15/18

Results

◮ Simulation Comparison

2 4 6 8 10 12 14 16 18 0.2 0.4 0.6 0.8 1 1.2

Simulation Comparison

TERRA-LUNA-sim vs 20-sim Step-output 20sim-step-output Controller-output 20sim-controller-output Plant-y 20sim-plant-y Simulation Time (s) Values

Minor differences

1.95 2 2.05 2.1 2.15 2.2 0.02 0.04 0.06 0.08 0.1 0.12 0.14 0.16 0.18

[ Z. Lu ] 16/18

Results

◮ One snapshot of logged process states

0.230 1

Process ID time stamp

1 1 1 3 1 2 4 4

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

◮ Using different colors to represent process states

PARALLEL * Controller Plant Step

[ Z. Lu ] 17/18

Conclusions and Recommendations

◮ Conclusions

◮ The simulation provides comparable results as the ground truth ◮ The animation can sufficiently indicate process execution order ◮ Opportunity to implement a rapid prototyping system ◮ Opportunity to obtain an executable and deployable binary

which can be right-first-time

◮ Recommendations

◮ Signal values are not automatically visualized as state changes ◮ Options to include or exclude processes/states from animations ◮ Timing analysis need to be implemented ◮ FMI interfacing and wrapping facilities

[ Z. Lu ] 18/18

Thanks!

[ Z. Lu ] 18/18

Results

◮ Tree structure of the example model

MainModel ID: 15 PARALLEL ID: 14

PAR

Controller ID: 4 Plant ID: 7 Step ID: 11

XXController Model

ID: 5

XXStepModel

ID: 12 w_output ID: 13 r_u ID: 10 w_y ID: 8

XXLinear SystemModel

ID: 9 w_output ID: 6 r_SP ID: 2 r_MV ID: 3 INS ID: 1

PAR SEQ SEQUENTIAL _Controller SEQ SEQUENTIAL _Plant SEQ SEQUENTIAL _Step

[ Z. Lu ] 18/18