The document discusses FunctionalDMU, a framework for simulating the behavior of mechatronic systems directly within digital mockups (DMUs). It aims to integrate heterogeneous behavior models from different domains and tools through a co-simulation approach. Wrappers adapt the native behavior models for communication, while a master simulator coordinates the simulation. This allows behavior models to be simulated alongside 3D geometry without data conversion. The framework has been applied to examples like simulating the thermal effects of an electric motor's electronics. Benefits include earlier detection of multi-domain issues and integrated visualization of functional and geometric aspects of mechatronic designs.

1. FunctionalDMU:
towards experiencing behavior of mechatronic systems in DMU
Dr.-Ing. André Stork
Fraunhofer Institut für Graphische Datenverarbeitung IGD
Fraunhoferstraße 5
64283 Darmstadt
Tel.: +49 (0) 6151 155 – 469
Fax.: +49 (0) 6151 155 – 139
E-Mail: andre.stork@igd.fraunhofer.de
http://www.igd.fraunhofer.de

2.  Video

3. What is going on behind the scenes?
 FunctionalDMU run-time environment
Mastersimulator
Wrapper Wrapper Wrapper
Rhapsody Dymola Simpack

4. DMU
 In DMU multi-CAD data is typically converted into one representation …
 … to provide functionality such as … © Siemens AG
 detecting collisions
 checking possibility to assemble / disassemble parts
 measuring
 annotating

5. FDMU
 In addition to geometry models
behavior models of the mechatronic domains:
 software
 electronics
 mechanics
integration
behavior models in diffe-
DMU geometry models rent modelling languages

6.  So the question arises:
What is the equivalent for geometric integration with respect to behavior
models?
 Approaches
 mapping of the heterogeneous behavior models into one standard?
 no existing standard with full representative power
 execution of such an integrated behavior model in a ‚super simulator‘?

7.  Co-simulation matrix (Prof. Dr.-Ing. Marcus Geimer, Universität Karlsruhe)
number of
modeling tools
integration of
>1 co-simulation
models
integrating
„classic“
=1 different
simulation
simulators
=1 >1
number of
simulation algorithms

8.  We decided to go for a
 flexible
 open
 extensible
 vendor-independent
 co-simulation framework:
the FDMU framework Mastersimulator
Wrapper Wrapper Wrapper
Rhapsody Bild
Dymola Simpack

9.  We want to use the native behavior models …
 as unchanged as possible
 but some small adaptations are needed
 in / out values
 parameters to be changed
native model connector communication-enabled model

10.  FDMU connector library for
 Modelica (Dymola)
 MAST (Saber)
 MATLAB/Simulink

11.  Connectors to map native syntax to standardized syntax
 Which standards?
 SysML
 Modelica
 VHDL-AMS
 SysML (Systems Modeling Language)
 Modeling language for systems engineering
 XML base
 UML/XML tools exist to create and process SysML
 Requirements and systems modeling

12.  Mapping of internal interfaces to a standardized form
 Encapsulation of behavior models (example: controller)
Controller (SysML)
Unified description
of interface
variables of the
behavior model
Controller (native)
native interface of
behavior model

13.  ‚Glueing‘ functional building blocks together to create
a simulation model
U 
up f
down s
I 
 and adding geometry models to embed them in an OO way

14.  Next: the simulators
Spice
Rhapsody
Dymola
simulators

15.  They are as heterogeneous as the behavior models with respect to:
 programming languages and APIs
 communication schemes
 platforms
simulators Rhapsody Dymola
Dymola Simpack
Simpack
 How to cope with their heterogeniety?

16.  Solution strategy: Wrapper
 controlling the simulator
 communicating and mapping data
 standardizing interfaces
Wrapper Wrapper Wrapper
simulators Rhapsody Dymola Simpack

17.  Which information does a wrapper receive?
interface
Wrapper Wrapper Wrapper
description
simulators Rhapsody Dymola Simpack
behavior models

18.  Wrapper
 different communication strategies
 based on configuration of connectors

19.  Wrapper
 simulator control commands, e.g.
 configure
 initialize
 run Wrapper
 start data
control
commands exchange
 suspend
 resume
 stop Simulator
 terminate

20.  What else do we need?
 a master for communication and co-ordination 
 Which information does the Mastersimulator need?
system
behavior model Mastersimulator
interface
Wrapper Wrapper Wrapper
description
simulator Rhapsody Dymola Simpack
behavior models

21.  Mastersimulator
 TransferHandler
 adapt data communication

22.  Mastersimulator
 TransferHandler
 support different protocols
constant data flow
constant data flow with upsampling
constant data flow with downsampling
event based input with sampling
event based input /output

23.  To complete the FDMU framework …

system behavior model
interactive visualization and geometry models
system
behavior model Mastersimulator
interface
Wrapper Wrapper Wrapper
description
simulator Rhapsody Dymola Simpack
behavior models

24.  Video:
SW simulation
with Rhapsody
Mastersimulator
Wrapper Wrapper Wrapper
Rhapsody Dymola Simpack

25. Integration of FE analysis: E-motor example
 Demand to integrate and possible couple with
finite element analysis
 Challenge: FE known to be slow
 A coupling scenario for an E-motor
 E-motor with electronic control
 Electronics on a PCB mounted at heat sources
the backside of the E-motor
 The electric behavior of the parts
on the PCB depends on the thermal
conditions (heat)
 -> thermo-dynamic simulation
warming of the PCB
(transistors, controller)

26. Integration of FE analysis: E-motor example
 General questions that may arise in the design process:
 How warm will the transistors get?
 What is the contribution of the engine to the temperature of the transistors?
 Does the warming have effects on other elements, e.g. the controller?
 What kind of cooling to attach to the transistors?
 What happens if the distance between motor and PCB is changed?
 Etc.

27. Integration of FE analysis: E-motor example
 Physical model
controller load
software
time
motor (converter) time
signal electronics mechanics
signal
power loss
power loss
influence
on behavior thermo-dynamics

28. Integration of FE analysis: E-motor example
 Physically-motivated splitting into partial models
TE1: temperature transistor 1
TE2: temperature transistor 2
TM: temperature motor winding
PE1: power loss transistor 1
PE2: power loss transistor 2
PM: power loss motor

29. Integration of FE analysis: E-motor example
 We started to model the thermal behavior within ANSYS
 approx. 50.000 nodes (volume mesh)
 simulation time in the range of hours
 way too slow for interactive simulation

30. Integration of FE analysis: E-motor example
 Reduced model
 Model order reduction
 reduced systems of equations:
50.00 nodes > 100 nodes
 Execution time
 almost interactive
 little impact on accuracy
(we have not measured
precision yet)

31. Integration of FE analysis: E-motor example
 Mapping of the behavior models to simulators
Saber Dymosim Dymosim
Feed forward control
- Matlab
- direct user input input file
Reduced thermo-dyn.
Model (Dymosim)

32. E-motor example
 Video

33. Other applications

34. Achievements
 FunctionalDMU framework
 open, extensible, flexible
FDMU
visualization
FDMU
 distributed, service-oriented architecture service
s
Berlin
 unique combination of features Saber
 solvers Dresden
Darmstadt
 methodology
 visualization features
Mastersimulator Rhapsody
FDMU-Editor Simulink, Visu
 Wrappers for
Dymola
Simulink SimPack Dymola, Mastersim.
 Rhapsody, SimPack, Saber, Dymola (Modelica), Matlab/Simulink, …
 Methodology for modelling, integrating and running FDMU simulations
 Proof-of-concept scenarios

35. Benefits
 end-user point of view
 earlier multi-domain problem detection
 visual insights and communication
 integrated 2D/3D interactive visualization
 shorter set-up of mechatronic simulations
 re-use of behavior models (FBB) in different configurations
 no transformation of models
 running behavior models as services (without forwarding know-how)
 simulation tool provider point of view
 re-usable components for simulation coupling and
 integrated visualisation

36. Outlook
 Wish list / research issues
 fast and flexible simulations, esp. FEM
 coupling-in more different FE domains
 taking environment conditions and tolerances into account
 real-time requirements
 ‚informed‘ CAD models
 data management -> MechatronicPLM
 optimization
 organizational aspects
 IP issues
 LTP of behavior models

37. Das Produkt muss vollständig als Gesamtsystem simulierbar sein.
(Bernd Ehrenberg, Daimler AG)

38. Contact and consortium
for slides and videos see:
www.functionalDMU.org