Das functional mockup interface zum austausch ... - QTronic

Das Functional Mockup Interface 

zum Austausch Dynamischer Modelle 

Martin Otter (DLR-RM) 

Torsten Blochwitz (ITI) 

Hilding Elmqvist (Dassault Systèmes – Dynasim) 

Andreas Junghanns (QTronic) 

Jakob Mauss (QTronic) 

Hans Olsson (Dassault Systèmes – Dynasim) 

ASIM Workshop, 4. - 5. März 2010

Contents 

1. Functional Mockup Interface (FMI) – Overview 

2. FMI - Motivation 

3. FMI for Model Exchange – Overview 

4. Model Distribution 

5. Model Description Schema 

6. Model C-Interface 

7. Tool Support for FMI 

8. Comparison with SIMULINK S-Function Interface 

9. Outlook 

10. Acknowledgements 

Functional Mockup Interface > ASIM Workshop, 4.-5. März 2010 > Slide 2

1. Functional Mock-up Interface (FMI) – Overview 

The FMI development is part of the ITEA2 MODELISAR project. 

FMI development initiated, organized and headed by Daimler AG 

Improved Software/Model/Hardware-in-the-Loop Simulation, 

of physical models and of AUTOSAR controller models 

from different vendors for automotive applications with 

different levels of detail. 

Open Standard 

14 automotive use cases for evaluation in MODELISAR 

Engine 

with ECU 

Gearbox 

with ECU 

Thermal 

systems 

Automated 

cargo door 

Chassis components, 

roadway, ECU (e.g. ESP) 

functional mockup interface for model exchange and tool coupling 

etc. 

courtesy Daimler 


Task is complex since the different parts are complex by themselves: 

Model Exchange (ODE/DAE components without integrators) 

Co-Simulation (ODE/DAE components with integrators) 

Co-Simulation with PDE solver (MpCCI) 

AUTOSAR (discrete components with complex communication) 

Simulation Backplane 

In Jan. 2010, the first version of "FMI for Model Exchange" was released. 

It was mainly developed by Dassault Systèmes (Dynasim), DLR, ITI, QTronic. 

www.functional-mockup-interface.org 

specification 

xml schema files 

C header files 

software development kit (QTronic) 


MODELISAR 

ITEA2 project 

3 years (2008 – 2011) 

29 project partners 

Coordinators 

Dassault 

Systèmes 

Daimler AG 

Budget / Funding 

30M€ / 10M€ 

Funded by 

Germany (BMBF) 

France (DGCIS) 

Sweden (VINNOVA) 

Belgium 

Austria 


2. FMI - Motivation 

Problems / Needs 

Component development by supplier 

Integration by OEM 

Many different simulation tools 

Solution 

Reuse of supplier models by OEM: 

DLL (model import) and/or 

Tool coupling (co-simulation) 

Protection of model IP of supplier 

Added Value 

Early validation of design 

Increased process 

efficiency and quality 

slide from Nick Suyam, Daimler (adapted) 

supplier1 supplier2 supplier3 supplier4 supplier5 

supplier1 

tool 1 

supplier1 

supplier2 

supplier2 supplier3 supplier4 supplier5 

tool 2 tool 3 tool 4 tool 5 

FMI 

OEM 

Functional Mockup Interface > ASIM Workshop, 4.-5. März 2010 > Slide 6 

! 

? 

OEM 

OEM 

supplier3

Example Scenario: Power Lift Gate 

supplier1 supplier2 supplier3 

AMESim 

(Modelica) 

OEM, dept. 1 

Dymola 

(Modelica) 

FMI model exchange (DLL) 

model import 

Simpack (multi-body) 

SimulationX 

(Modelica) 

model export 

OEM, dept. 2 

TargetLink (software) 

model export 

FMI tool coupling FMI model exchange (C) 

Silver (system model) + TestWeaver (testing) 

models solved with 

SIMPACK integrators 

(= central integration) 

model import co-simulation 

slide from Nick Suyam, Daimler (adapted) 


3. FMI for Model Exchange - Overview 

Import and export of input/output blocks (FMU – Functional Mock-up 

Unit) 

described by 

differential-, algebraic-, discrete equations, 

with time-, state, and step-events 

An FMU can be large (e.g. 100000 variables) 

An FMU can be used in an embedded system (small overhead) 

FMUs can be connected together 


Signals of an FMU: 

For example: 10 input/output signals (u/y) for connection and 

100000 internal variables (v) for plotting 


Mathematical description of an FMU: 


4. Model Distribution 

A model is distributed as one zip-file with extension ".fmu". Content: 

XML model description file 

All model information that is not needed during integration of model, 

e.g., signal names and attributes. Advantage: 

No overhead for model execution. 

Tools can read this information (= complicated data structure) 

with their prefered language (C++, C#, Java, ...) 

Model equations defined by a small set of C-functions. In zip-file: 

C source code and/or 

Binary code (DLL) for one or more platforms (Windows, Linux, ...) 

Resources 

Documentation (html files) 

Model icon (bitmap file) 

Maps and tables (read by model during initialization) 


Structure of an FMU zip-file 

modelDescription.xml // Description of model (required file) 

model.png // Optional image file of model icon 

documentation // Optional directory containing the model 

// documentation 

_main.html // Entry point of the documentation 

 

sources // Optional directory containing all C-sources 

// all needed C-sources and C-header files to compile and link the model 

// with exception of: fmiModelTypes.h and fmiModelFunctions.h 

binaries // Optional directory containing the binaries 

win32 // Optional binaries for 32-bit Windows 

.dll // DLL of the model interface implementation 

VisualStudio8 // Microsoft Visual Studio 8 (2005) 

.lib // Binary libraries 

gcc3.1 // Binaries for gcc 3.1. 

win64 // Optional binaries for 64-bit Windows 

... 

linux32 // Optional binaries for 32-bit Linux 

... 

resources // Optional resources needed by the model 

< data in model specific files which will be read during initialization > 


control 

simulator 

GUI 

model.dll 

simulator 

solver 

reads 

run 1 or many 

XML schema (.xsd) 

defined by the 

FMI specification 

references 

modelDescription.xml .fmu 


5. Model Description Schema 

All model information not needed for execution is stored in one xml-file 

(modelVariables.xml in zip-file) defined by xml schema files. 

Advantage: 

Complex data structures give still simple interface, and tool can use its favorite 

programming language for reading (e.g., C++, C#, Java). 

Definition of display units 

Definition of type defaults 

Default stop time, tol. etc. 

Tool specific data 

Variable names and attributes 


Model attributes. Most important 

modelIndentifier is a C-name that is 

used as prefix for the C-functions 

(model interface) 

guid is a globally unique identifier 

("fingerprint" of all releveant information 

in the xml file) that is also stored in the 

C-functions to gurantee consisteny 

Number of continuous states and 

of event indicators; numbers are fixed 

(meaning of states can change dynamically 

during simulation) 


ordered set of scalar variables 

(arrays, records, etc. must be 

mapped to scalars when 

generating code). 

ModelVariables 

data types 


Attributes of ModelVariables 

... 

unique name 

handle to identify 

variable in C-functions 


Data types allow to store all (relevant) Modelica attributes, including units. 

Defaults from TypeDefinitions 


Example 

modelDescription.xml 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

... 

 

 


6. Model C-Interface 

Two C-header files 

Platform dependent definitions (basic types) 

C-function interfaces 

18 core functions 

6 utility functions 

no macros 

C-function name: _, z.B. "Drive_fmiSetTime" 


Example: 

// Set input arguments 

fmiSetTime(m, time); 

fmiSetReal(m, id_u1, u1, nu1); 

fmiSetContinuousStates(m, x, nx); 

// Get results 

fmiGetContinuousStates(m, derx, nx); 

fmiGetEventIndicators (m, z, nz); 


Caching for efficient model evaluation 


Clean Definition of State Events 

A state event occurs when an event indicator z changes its domain from 

Always well defined! 

z > 0 to z ≤ 0 or vice versa 

Usual definition z(t i )*z(t i-1 ) ≤ 0 is not always well-defined 


7. Tool Support for FMI (planned for 2010 in MODELISAR) 

7.1 FMU import and export 

AMESim 

(Modelica) 

CATIA Systems 

(CAD/Modelica) 

Dymola 7.4 

(Modelica) 

already available 


EXITE ACE 

(co-simulation of 

software/AUTOSAR) 

SimulationX 

(Modelica) 


7.2 FMU import 

EXITE 

(co-simulation) 

Silver/TestWeaver 

(FMU integration, 

cosimulation, testing) 

Simpack 

(multi-body) 


8. Comparison with SIMULINK S-Function Interface 

SIMULINK has two interfaces: 

S-Function for offline simulation 

Realtime Workshop for embedded Systems 

FMI is targeted for both offline simulation and embedded systems (one interface) 

Simulink and FMI have different goals and therefore have different solutions: 

S-function targeted to import models in SIMULINK: 

Main interface to implement an S-Functions. 

(many macros to fill S-Function data structure) 

Incomplete interface to call S-Functions. 

Whenever a small detail of the S-Function data structure is changed, 

existing DLLs must be newly build. 

If used in 3 simulation environments → 3 DLLs of the same model 

FMI targeted to import models in many simulation environments 

Only interface to call model in simulation environment. 

Model data structure is secret of model generation environment. 

If used in 3 simulation environments on same platform → 1 DLL 


S-function not suited for embedded systems, due to large memory overhead 

since all information of a model is stored in the Model DLL (therefore 

separate code generation for embedded systems via Realtime Workshop) 

FMI: Only the minimum necessary part is stored in C source code or in Model 

DLL. All information not needed for execution, is provided in an XML file 

(which is needed on host, but not on target microprocessor) 

S-function has very complex definition (> 100 C-functions/macros) 

Generating S-function is fine. However, there is no simulator that can import 

all S-function models (with exception of SIMULINK). 

FMI: Simple definition (20 C-functions, no macros, XML schema file) 

S-function proprietary format, gives legal problems if used in other simulators 

FMI: Wikipedia license for specification, BSD license for schema/header 


Technical issues that are missing in S-Function interface and are available in FMI: 

Reliable state event handling 

Event iteration over simulation model (not only component model) 

Request from submodel to reduce step-size 

(for non-linear equations in model that do not converge) 

Dynamic selection of states 

(as needed for order-reduced higer index systems) 

Alias variables 

(FMI: alias variables are marked; need to be stored only once, not several 

times; important for Modelica models, since many alias variables) 

Caching of computed results 

(FMI: more efficient solution) 


9. Outlook 

"FMI for Model Exchange" released at end of January 2010 

(technical specification finalized; some discussion about precise license text) 

"FMI for Co-Simulation" in a good stage. Will be released in first half year: 

Support for: extrapolation/interpolation of interface variables, 

variable communication step-size, re-doing a step 

→ step-size control possible). 

"FMI for Model Exchange" will be further developed. A lot of requirements 

available, such as: 

Sparse Jacobian 

Direct support for arrays and records in xml schema 

Improved sample time definition (for embedded systems) 

Online changeable parameters 

Saving/restoring model state 

Other tool vendors are encouraged to support FMI, especially: 

VHDL-AMS simulators 

Multi-Body simulators 

Note: Much simpler as SIMULINK S-Function interface and more powerful. 


10. Acknowledgments 

FMI initiated and organized : Daimler AG (Bernd Relovsky, ....) 

Head of FMI development : Dietmar Neumerkel (Daimler AG) 

Head of FMI-for-Model-Exchange: Martin Otter (DLR-RM) 

FMI-for-Model-Exchange Torsten Blochwitz (ITI) 

Core-Design by: Hilding Elmqvist (Dassault Systèmes -Dynasim) 

Andreas Junghanns (QTronic) 

Jakob Mauss (QTronic) 

Hans Olsson (Dassault Systèmes -Dynasim) 

Martin Otter (DLR-RM) 

Other MODELISAR contributors: Ingrid Bausch-Gall, Bausch-Gall GmbH 

Alex Eichberger, SIMPACK AG 

Rainer Keppler, SIMPACK AG 

Gerd Kurzbach, ITI GmbH 

Carsten Kübler, TWT 

Johannes Mezger, TWT 

Thomas Neidhold, ITI GmbH 

Dietmar Neumerkel, Daimler AG 

Peter Nilsson, Dassault Systèmes-Dynasim 

Antoine Viel, LMS International 

Daniel Weil, Dassault Systèmes 

Other contributors: Johan Akesson, Lund University 

Joel Andersson, KU Leuven 

Roberto Parrotto, Politecnico di Milano 

Partially funded by: BMBF, VINNOVA, DGCIS, organized by ITEA2 

Prototypes for FMI evaluation: 

Dymola by Peter Nilsson, Sven Erik Mattsson, 

Carl Fredrik Abelson, Dan Henriksson 

(Dassault Systèmes, Dynasim) 

JModelica.org by Tove Bergdahl (Modelon) 

Silver by Andreas Junghanns, Jakob Mauss 

(QTronic)

Das functional mockup interface zum austausch ... - QTronic

Create successful ePaper yourself

Delete template?

Save as template?