Co-simulation Design towards Cyber-Physical Robotic Applications - PowerPoint PPT Presentation

Co-simulation Design towards Cyber-Physical Robotic Applications Leveraging on FMI Standard and CSP Semantics Zhou Lu and Jan Broenink Robotics and Mechatronics, University of Twente 22 Aug, 2017

Introduction - Context ◮ Cyber-Physical Systems towards robotic applications ◮ Combination of different engineering domains ◮ Software, control, electrical, mechanical ◮ Variety of formalisms and tools for subsystems in C-P domains ◮ Discrete-Event (cyber), Continuous-Time (physical) 2/29

Introduction - Generic Approach ◮ Merging different subsystems involves ◮ Multi-disciplinary modelling ◮ Different formalisms and tools for subsystems ◮ Model-driven design ◮ Meta-modelling, model-to-model transformation ◮ Co-modelling and Co-simulation ◮ Couple models (simulators) via specifically defined interfaces ◮ Collaborate and coordinate simulations of subsystems ◮ Problems ◮ Application-dependent syntax and semantics ◮ Variables are different in different application domains ◮ Interfaces are defined differently in different tools ◮ Flexibility, extensibility and re-usability are limited 3/29

Introduction - Goal ◮ Couple models in different tools in a standardized way ◮ Standard interfaces to interconnect subsystem models ◮ Functional Mock-up Interface (FMI) standard ◮ State consistency between subsystem models ◮ Data exchange and synchronization ◮ between DE controller models and CT plant models ◮ through CSP semantics 4/29

Background - Functional Mock-up Interface ◮ Tool-independent standard: initiated by automobile industries ◮ To support the exchange, interoperation and coordination ◮ between subsystem models designed with different tools ◮ provides a set of generic APIs that can be adopted ◮ More than 100 tools claim to support FMI standard ◮ openModelica, Dymola, Adams, SimulationX, 20-sim ... ◮ Becoming the de-facto standard for co-sim in CPS co-design 5/29

Background - Functional Mock-up Unit ◮ A model implementing FMI interface is denoted as a FMU ◮ XML model-description file ◮ describes static meta-date following FMI XML schema ◮ includes variable attributes, sim capabilities and configuration ◮ Shared library/C source files ◮ model implementation ◮ FMI API implementation ◮ Interconnected FMUs constitute a co-simulation model ◮ Can be simulated as a whole in a co-sim environment A B C A_out B_in1 B_out C_in FMU FMU FMU B_in2 C_out 6/29

Background - FMI-CS and FMI-ME ◮ FMI for Co-Simulation (FMI-CS) ◮ To couple subsystem models in a co-sim environment ◮ models are provided with their own numerical solvers ◮ FMI for Model Exchange (FMI-ME) ◮ To provide the interface to dynamic models that can be utilized by other tools ◮ described by differential, algebraic and discrete equations ◮ solvers are provided by the simulation tool ◮ In this paper FMI-CS is used 7/29

Background - FMI for Co-simulation ◮ Master-Slave mechanism ◮ Slaves: interconnected FMUs ◮ Communicate with the Master only ◮ Black-box components with exposed IO variables ◮ Master: orchestrates communications between slaves ◮ Performs data exchange and manages synchronization ◮ A sophisticated Master Algorithm (MA) is crucial Co-simulation model FMU 1 Slave Model Solver FMI FMU 2 Slave Master Model Solver FMI ...... FMU N Slave Model Solver FMI 8/29

Background - Tool Chain ◮ TERRA ◮ CSP based modelling tool for software architecture (DE) ◮ Two hierarchical abstraction layers ◮ Architecture layer ◮ Functional layer 9/29

Background - Tool Chain ◮ 20-sim ◮ Plant modelling using bond graphs (CT) ◮ Control laws modelling using iconic diagrams with dynamic queations ◮ Supports exporting FMUs specified by FMI-CS 10/29

Design - Co-sim Design Flow ◮ Co-simulation design flow using our approach and tools ◮ 5 steps towards co-simulation using TERRA and 20-sim ◮ This paper mainly contributes to Step 3 and Step 4 Contol Laws TERRA Plant 20-sim model 1 2 FMU FMU 3 .xml and .so LUNA Execution 4 Framework libLUNA.a 5 CPP-coded Compile/Link Master Executable Simulation Algorithm Co-simulation Results 11/29

Design - Co-sim Design Flow ◮ Co-simulation design flow using our approach and tools ◮ Step 1: architecture design in TERRA ◮ Step 2: functional design in 20-sim and FMU generation Contol Laws TERRA Plant 20-sim model 1 2 FMU FMU 3 .xml and .so LUNA Execution 4 Framework libLUNA.a 5 CPP-coded Compile/Link Master Executable Simulation Algorithm Co-simulation Results 12/29

Design - Co-sim Design Flow ◮ Co-simulation design flow using our approach and tools ◮ Step 3: coupling different FMUs in TERRA ◮ Step 4: generating CSP-based C++ code implementing MA Contol Laws TERRA Plant 20-sim model 1 2 FMU FMU 3 .xml and .so LUNA Execution 4 Framework libLUNA.a 5 CPP-coded Compile/Link Master Executable Simulation Algorithm Co-simulation Results 13/29

Design - Co-sim Design Flow ◮ Co-simulation design flow using our approach and tools ◮ Step 5: compiling code and performing co-simulation ◮ Simulation results are stored in csv files Contol Laws TERRA Plant 20-sim model 1 2 FMU FMU 3 .xml and .so LUNA Execution 4 Framework libLUNA.a 5 CPP-coded Compile/Link Master Executable Simulation Algorithm Co-simulation Results 14/29

Design - Coupling Models ◮ Coupling different domain models using MDD ◮ Generated FMI XML schema meta-model ◮ fmiModelDescription, CoSimulation, DefaultExperiment ◮ ScalarVariable ◮ Existing TERRA CSP meta-model ◮ CSPModel process with FMU interface configuration ◮ CSPReader, CSPWriter, Port, Variable 15/29

Design - Coupling Models ◮ Epsilon languages and tools: work out of the box with EMF ◮ Epsilon Object Language: ETL(Transformation) EGL (Generation), EVL (Validation) ◮ Transformation rules: parser for FMI model description file 16/29

Design - Coupling Models ◮ Example: a 20-sim plant model to a TERRA CSP model ◮ Fluid level control system: plant model in 20-sim ◮ With 2 exposed IO variables: control and height ◮ Transformed to a TERRA CSP model ◮ CSPReader: variable v control ◮ CSPWriter: variable v height ◮ CSPModel process: with FMU interface configuration 17/29

Design : Master Algorithm ◮ Master behaves as an orchestrator for co-simulation ◮ FMI only specifies the API that FMUs must implement ◮ Does not specify how the Master should preform the co-sim 18/29

Design : Master Algorithm ◮ Master behaves as an orchestrator for co-simulation ◮ FMI only specifies the API that FMUs must implement ◮ Does not specify how the Master should preform the co-sim ◮ FMI API calling sequence from Master to Slaves is important ◮ Must be performed correctly on each FMU ◮ Instantiation and Initialisation phase ◮ fmi2Instantiate , fmi2SetupExperiment , fmi2EnterInitializationMode , fmi2ExitInitializationMode ◮ Simulation phase ◮ fmi2DoStep ◮ currentCommunicationPoint : current Master time ◮ communicationStepSize : proposed communication step size ◮ Termination phase ◮ fmi2Terminate , fmi2FreeInstance 18/29

Design : Master Algorithm ◮ FMU interface meta-model ◮ FMIModel inherits from the CPPCodeBlockConfiguration ◮ Interfacing to the FMU is abstracted as a C++ code block in the form of a CSPModel process 19/29

Design : Master Algorithm ◮ Utilize C++ code generation feature in TERRA ◮ Re-use code generation facilities towards CSP components ◮ EGL templates for FMU interfacing C++ code block ◮ Mapping between class functions and FMI-CS phases FMU Interfacing Model: FMI Co-simulation FMI API Functions Generated C++ Class Functions Phases To Be Invoked FMI FMUName(IO parameter,...) Instantiation and fmi2Instantiate (constructor) (partial) Initialisation fmi2SetupExperiment fmi2EnterInitializationMode execute() (partial) Initialisation fmi2ExitInitializationMode (at the first iteration) (synchronize init values only) execute() Simulation fmi2DoStep (execute iteratively) execute() Terminate fmi2Terminate if stopTime (final time) is reached fmi2FreeInstance 20/29

Design : Master Algorithm ◮ Co-simulation model: TERRA arch model and CSP model ◮ Connections between FMUs are defined by CSPChannels ◮ Data exchange is in a waiting-rendezvous manner ◮ MA determinism can be ensured ◮ The results of different co-simulation runs do not depend on any arbitrary order in which the FMUs might be chosen 21/29

Design : Master Algorithm ◮ Artificial delay in loop control ◮ IO-SEQ pattern results in a deadlock ◮ Deadlock free modification using PARALLEL composition ◮ Communication events happen in an interleaving manner ◮ Artificial delay, wrong simulation results 22/29

Design : Master Algorithm ◮ Algorithm to compensate for the artificial delay 23/29

Experiments ◮ Fluid level control ◮ Plant (CT domain): two tanks coupled through a pipe ◮ Fluid input in tank 1 ◮ Leaking valve in tank 2 ◮ Controller (DE domain): a proportional controller ◮ Keep the fluid level in tank 2 at desired level ◮ Desired level changes at time step 10 . 0 s ◮ Two types of experiments ◮ On functionality and accuracy of the co-simulation ◮ On performance with/without timing compensation 24/29

Experiments ◮ On functionality and accuracy of the co-simulation ◮ With communication step size of 0 . 001 s ◮ Does not cause a too much deviation from correct results 25/29