Das Functional Mockup Interface zum Austausch - QTronic

Das Functional Mockup Interfacezum 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

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

Contents1. Functional Mockup Interface (FMI) – Overview2. FMI - Motivation 3. FMI for Model Exchange – Overview4. Model Distribution5. Model Description Schema6. Model C-Interface7. Tool Support for FMI8. Comparison with SIMULINK S-Function Interface9. Outlook10. Acknowledgements


1. Functional Mock-up Interface (FMI) – OverviewThe FMI development is part of the ITEA2 MODELISAR project.

FMI development initiated, organized and headed by Daimler AGImproved Software/Model/Hardware-in-the-Loop Simulation, of physical models and of AUTOSAR controller modelsfrom different vendors for automotive applications withdifferent levels of detail.Open Standard14 automotive use cases for evaluation in MODELISAR

Enginewith ECU

Gearboxwith ECU

Thermalsystems

Automatedcargo door

Chassis components,roadway, ECU (e.g. ESP)

etc.

functional mockup interface for model exchange and tool couplingcourtesy 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.orgspecificationxml schema filesC header filessoftware development kit (QTronic)


MODELISAR

ITEA2 project

3 years (2008 – 2011)

29 project partners

Coordinators

Dassault Systèmes

Daimler AG

Budget / Funding 30M€ / 10M€

Funded byGermany (BMBF)France (DGCIS)Sweden (VINNOVA)BelgiumAustria


2. FMI - Motivation

Problems / NeedsComponent development by supplierIntegration by OEMMany different simulation tools ?

supplier1 supplier2 supplier3 supplier4 supplier5

OEM

supplier1

tool 1

supplier2 supplier3 supplier4 supplier5

tool 2 tool 3 tool 4 tool 5

FMI OEM

SolutionReuse of supplier models by OEM:

DLL (model import) and/orTool coupling (co-simulation)

Protection of model IP of supplier

!supplier1

supplier2

supplier3

OEMAdded Value

Early validation of designIncreased processefficiency and quality

slide from Nick Suyam, Daimler (adapted)


Example Scenario: Power Lift Gate

AMESim(Modelica)

supplier1 supplier2 supplier3

FMI model exchange (DLL)

Dymola(Modelica)

SimulationX(Modelica)

OEM, dept. 1

Simpack (multi-body)

model export

model import

Silver (system model) + TestWeaver (testing)

TargetLink (software)

OEM, dept. 2

FMI tool coupling FMI model exchange (C)

model export

model import co-simulation

models solved with SIMPACK integrators(= central integration)

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 fileAll 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, ...)

ResourcesDocumentation (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 icondocumentation // Optional directory containing the model // documentation _main.html // Entry point of the documentation <other documentation files>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.hbinaries // Optional directory containing the binaries win32 // Optional binaries for 32-bit Windows <modelIdentifier>.dll // DLL of the model interface implementation VisualStudio8 // Microsoft Visual Studio 8 (2005) <modelIdentifier>.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 >


XML schema (.xsd)defined by theFMI specification

simulatorsolver

model.dll

simulatorGUI

run 1 or many

reads

references

control

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).

Variable names and attributes

Definition of display units

Definition of type defaults

Default stop time, tol. etc.Tool specific data


Model attributes. Most important

modelIndentifier is a C-name that isused as prefix for the C-functions(model interface)

guid is a globally unique identifier("fingerprint" of all releveant informationin the xml file) that is also stored in theC-functions to gurantee consisteny

Number of continuous states andof event indicators; numbers are fixed(meaning of states can change dynamicallyduring simulation)


ordered set of scalar variables(arrays, records, etc. must be mapped to scalars when generating code).

data types

ModelVariables


Attributes of ModelVariables

...

unique name

handle to identifyvariable in C-functions


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


Example<?xml version="1.0" encoding="UTF8"?><fmiModelDescription fmiVersion="1.0" modelName="Modelica.Mechanics.Rotational.Examples.Friction" modelIdentifier="Modelica_Mechanics_Rotational_Examples_Friction" guid="{8c4e810f-3df3-4a00-8276-176fa3c9f9e0}" ... numberOfContinuousStates="6" numberOfEventIndicators="34"/> <UnitDefinitions> <BaseUnit unit="rad"> <DisplayUnitDefinition displayUnit="deg" gain="57.2957795130823"/> </BaseUnit> </UnitDefinitions> <TypeDefinitions> <Type name="Modelica.SIunits.AngularVelocity"> <RealType quantity="AngularVelocity" unit="rad/s"/> </Type> </TypeDefinitions> <ModelVariables> <ScalarVariable name="inertia1.J" valueReference="16777217" description="Moment of inertia" variability="parameter"> <Real declaredType="Modelica.SIunits.Torque" start="1"/> </ScalarVariable> ... </ModelVariables></fmiModelDescription>

modelDescription.xml


6. Model C-InterfaceTwo C-header files

Platform dependent definitions (basic types)

C-function interfaces18 core functions6 utility functionsno macrosC-function name: <ModelIdentifier>_<name>, z.B. "Drive_fmiSetTime"


// Set input argumentsfmiSetTime(m, time);fmiSetReal(m, id_u1, u1, nu1);fmiSetContinuousStates(m, x, nx);

// Get resultsfmiGetContinuousStates(m, derx, nx);fmiGetEventIndicators (m, z, nz);

Example:


Caching for efficient model evaluation


Clean Definition of State Events

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

z > 0 to z ≤ 0 or vice versa

Always well defined!

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


AMESim(Modelica)

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

7.1 FMU import and export

CATIA Systems(CAD/Modelica)

Dymola 7.4(Modelica)

already available


EXITE ACE(co-simulation of software/AUTOSAR)

SimulationX(Modelica)


Simpack(multi-body)

Silver/TestWeaver(FMU integration, cosimulation, testing)

7.2 FMU import

EXITE(co-simulation)


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 modelFMI 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

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 not suited for embedded systems, due to large memory overheadsince 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


Reliable state event handlingEvent 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)

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


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 simulatorsNote: Much simpler as SIMULINK S-Function interface and more powerful.


10. AcknowledgmentsFMI 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)

Documents

Das Functional Mockup Interface zum Austausch - QTronic