Towards more Insight with Functional Digital MockupPeter Schneider1, Christoph Clauß1, André Schneider1, André Stork2, Thomas Bruder3, Tibor Farkas4 1Fraunhofer-Institut für Integrierte Schaltungen IIS, Institutsteil EAS, Dresden2Fraunhofer-Institut für Graphische Datenverarbeitung IGD, Darmstadt3Fraunhofer-Institut für Betriebsfestigkeit und Systemzuverlässigkeit LBF, Darmstadt4Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS, Berlin

SYNOPSIS

Digital Mock-Up (DMU) is a widely introduced technology to virtually investigate geometricaland mechanical product properties. Functional Digital Mock-Up (FDMU) is a combination oftraditional DMU with behavioural simulation in mechatronics. Enhanced with functionalaspects considerably more insight in product properties can be achieved. To enable FDMUtwo main tasks have to be solved: Established simulation approaches of the areas of mechan-ics, electronics, and software simulation must interact. This implies to solve the task of simula-tor coupling. Furthermore, the simulation results must be visualized using the geometricmodels of DMU. In the paper the development of a prototypic FDMU framework is presented.Given geometric models (e.g. VRML files) as well as physical models are combined to so-called functional building blocks (FBB). The interface of FBB is prepared to be connected toother FBB. According to the complete product to be simulated FBB are combined within theframework to built the FDMU simulation model (FSM). During simulation a simulator couplingalgorithm controls the simulation processes of each FBB. Depending on FBB’s physicaldomain appropriate simulators can be used for simulation. The FDMU framework provideswrappers for multi-physics, electronic, software, multi-body, and FEM simulation tools(Dymola, Saber, Rhapsody, SimPACK, ANSYS). The visualization enables user interactions,e.g. pushing buttons. If it is prepared parameters can be changed before each simulation run.The paper introduces the components of FDMU framework and illustrates the approach withan application example.

1 MOTIVATION

In industrial product development, mechatronic components play a rapidly increasing role.Mechatronic components are characterized by the fact, that electronic and software controlledsystems influence mechanical parts. In the development of mechatronic products the domainssoftware engineering, mechanical engineering, and electronic engineering are considered.

For the geometric integration of product models, Digital Mock-Up (DMU) has been establishedas an inherent part of virtual product development in industrial practice. However DMU and theassociated software tools are nowadays mostly limited to the integration of geometry. Possibil-ities of a functional integration are missing.

In order to put mechatronic products on a solid base in an early stage of the development proc-ess, an extension of DMU with functional aspects towards a Functional Digital Mock-up and thesupport of cooperation between the domains of mechanics, electronics and software develop-ment is imperative.

2 OBJECTIVES

The objective of the described work is the development of a methodology and a framework forthe cooperative development and validation of functional prototypes of complex mechatronicproducts. This flexible framework will permit experiencing functional virtual models. The objec-tives are in detail:

• functional integration and validation of virtual mechatronic systems;

• visualization of the interplay of mechanics, electronics and software as a fast and easy wayto experience system behavior;

• combination and superimposition of different behavioral models and efficient analysis ofvariants;

• early identification and communication of conflicts of objectives;

• identification of best possible alternatives for finding cross-domain optima.

3 COUPLING OF SIMULATION DOMAINS VIA FDMU MASTER SIMULATOR

The basic idea of Functional DMU is

• to couple functional and geometry models within a total system model and

• to combine functional simulation and 3D visualization.

One challenge in this context is to find and create basic model components which support aflexible co-simulation and online-visualization. For this reason the concept of Functional Build-ing Block (FBB) has been developed. An example is illustrated in Figure 2. The FBB Motor cov-ers a functional model describing the electro-mechanical behavior and 3D CAD data describingall geometrical/visible components of the motor.

BehavioralModel for Part 1

BehavioralModel for Part 2

BehavioralModel for Part 3

BehavioralModel for Part 4

BehavioralModel for Part n

Assembly 13D Geometry

Product3D Geometry

Assembly 13D Geometry

Part 13D Geometry

Part 23D Geometry

Part 33D Geometry

Part 43D Geometry

Functional Model

Part n3D Geometry

Functional Model Functional Model

SoftwareCode

ElectricalCircuit

SimulationResults

Measurementand Control

...

Figure 1: Approaches of Digital Mock-up and Functional Digital Mock-up

DMU

FunctionalDMU

An FBB shows the main advantage of the Functional DMU approach: 3D CAD models are nolonger ’dead’ models. With a functional simulation in background they can demonstrate a phys-ically correct behavior.

Of course, the FBB is only one part of the concept. The second challenge of Functional DMUis to provide a FDMU Framework as runtime-environment for FBB. At least three aspects areimportant:

• Simulation and visualization tools should be integrated in the framework via open inter-faces.

• The framework has to organize the data exchange between all FBB within a total FDMUSimulation Model (FSM).

• The framework has to provide appropriate co-simulation algorithms for simulators/FBB.

Figure 3 shows main components of the FDMU Framework. The FDMU Master Simulator pro-vides all data exchange facilities and co-simulation algorithms. Each integrated tool is encap-sulated by a small adaptor program called FDMU Wrapper. All wrappers have a common inter-face. They perfom all interactions with the Master Simulator.

Figure 2: Example for Functional Building Block (FBB).

Modelicamotor.mo

VRMLmotor.wrl

Pin p

Flange a

u, i

Pin nu, i

ϕ, τ

behavioralmodel

3Dgeometry

FBB Motor (Electronic, Mechanics)

Figure 3: Components of the FDMU Framework.

Wrapper

MasterSimulator

for Simulator 1Wrapperfor 3D Visualization

Wrapperfor Simulator 2

Wrapperfor Measurement Data

Interface Signal, signal

Slot

Stimuli, Parameter

FBB 2

FBB 1 FBB 4

FBB 3

Main task of Master Simulator is to send and receive data to and from Wrappers/FBB. A Slotserves as a unique communication endpoint within the Master Simulator. An example is shownin Figure 4. FBB Switch sends the signal up to FBB Controller. Inside the Master Simulator thisconnection is represented by the output slot Switch.up and the input slot Controller.up. Outputmeans here the FBB sends signals and input means the FBB receives signals. To establish aconnection as shown in Figure 4 the Master Simulator has to connect slot Switch.up with slotController.up.

3.1 Data Transfer Handlers

The most simple case for connecting two slots is performing a direct data transfer. In this caseeach data value received by the Master Simulator at an output slot (e.g. Switch.up) will be sentwithout any processing to the connected input slot (e.g. Controller.up). The FDMU Master Sim-ulator supports data transfer with more complex behavior too. Dedicated transfer handlers pro-vide resampling functionality and protocol conversion. Figure 5 illustrates some examples fordown- and up-sampling and conversion between event-based and sampled data flows. The redarrows are the timelines (simulation time) and signal values are available at the black markers.

In the future the concept of transfer handlers will be further improved. Currently the stream han-dlers connect one output slot to one input slot. It is planned to remove such restrictions and toimplement more complex handlers for any number of output/input slots. These new kind of han-dlers will be fundamental for realizing dedicated co-simulation algorithms. A first version for cal-culating optimal step-size (sample rates) for single couplings between FBB is currently inexperimental stage already and will be evaluated for application examples in the near future.

The set of all directed slot-to-slot connections can be described as a routing table. All neces-sary information can be derived from the FDMU Simulation Model (FSM), which consists of allFBB and connections between them. The Master Simulator supports static and dynamic rout-ing. In case of static routing the Master Simulator loads a routing table at startup time. Further-more, during a running FDMU session a wrapper/client can dynamically establish new connec-tions via API functions addSlot() and connectSlots().

As described above the Master Simulator and their slots play a key role for connecting FBB. Inaddition to data transfer the synchronization between different FBB is another task of Master

Figure 4: Data exchange between FBB via Master Simulator.

Window

MasterSimulator

ControllerSwitch

up down U I hupdown UI

RhapsodyiFX

Simulator. While the main part of synchronization is implicitly performed through the (sampled)data flow between FBB, the Master Simulator tries to decouple the co-simulation of all FBB asgood as possible. For this reason all transfer handlers work in parallel in different threads. Toavoid unnecessary blocking during the data transfer all slots can buffer incoming data values.From the wrappers’s (simulator’s) point of view data can be sent as fast as possible and withoutwaiting for free processing time in the Master Simulator. Of course, simulator coupling typicallyslows down the performance. Therefore, the FDMU framework allows to combine several FBBwithin one wrapper and to simulate them with the same simulator instance. So unnecessarycouplings will be avoided and the overall performance will be improved.

3.2 Data Exchange

The next highlight of FDMU approach is that a great variaty of data items can be exchangedbetween FBB. The Master Simulator differentiates between the following categories: type, car-dinality, and mode. Type means one of basic type like DOUBLE, FLOAT, INTEGER, LONG,BOOLEAN, and STRING. Cardinality describes whether a single value (SCALAR) or an arrayof values (ARRAY) are transfered. And there are two modes: VALUE and SAMPLE. Samplemeans data items with timestamp information – transfered as ordered pair (timestamp, value)and value means data items without any explicitly attached time information.

As explained above slots support queueing of data. With this feature in mind all slot-relateddata access functions provide an appropriated time semantic. For sending and receiving datathe following groups of API methods are available:

• put...() Inserts the specified value or sample into the queue of slot named by id, waiting if necessary for space to become available.

• take...() Retrieves and removes the head value or sample of the queue of slot named by id, waiting if necessary until an element becomes available.

• offer...() Inserts the specified value or sample into this queue, waiting up to the specified wait time if necessary for space to become available.

• poll...() Retrieves and removes the head value or sample of the queue of slot named by id, waiting if necessary until an element becomes available.

Figure 5: Transfer Handlers for resampling and protocol conversion.

Switch.up

Controller.upTransferHandler

Direct Data Flow

Up-Sampling

Down-Sampling

Protocol Conversion

Direct Event Flow

Output Slot Input Slot

• peek...() Retrieves, but does not remove, the head value or sample of this queue, or returns null if this queue is empty.

• drain...() Removes at most the given number of available values or samples from the queue of the slot named by id, and adds them to the return value array.

Depending on type, cardinality, and mode the user can derive the method name. The followingexamples illustrate the schema:

• void putDoubleValue(String slot, double value) Sends a double value and waits, if the slot-internal queue is full.

• double takeDoubleValue(String slot) Waits until a new double value is available and receives the value.

• void putBooleanArrayValue(String slot, Vector<Boolean> value) Sends an array of boolean values and waits, if the slot-internal queue is full.

• boolean offerStringSample(String slot, Sample<String> sample, long timeout) Tries to send a string with timestamp and waits, if the slot-internal queue is full. After time-out the function will be aborted and the data will be lost.

• Vector<Double> drainDoubleValues(String slot) Waits for new double values. If double values are available, all values will be received asarray.

Based on the Master Simulator’s data exchange API explained above many data transfer andsynchronisation protocols can be implemented. The API is powerful enough to provide flexibleco-simulation and fast online visualization within the FDMU framework.

3.3 Wrappers

While an FBB contains functional and/or geometry models, a simulation and visualization envi-ronment is needed at runtime. If, for example, FBB Motor contains a MAST model for describ-ing the electro-mechanical behavior, at runtime the Saber simulator is used for simulating thefunctional model of FBB. Same holds for geometry/CAD data – here a scenegraph viewer likethe FDMU Visualization iFX [4] for showing all motor components in 3D is used. An FDMUWrapper helps to integrate such tools (legacy code) into the FDMU Framework. Main tasks ofa wrapper are:

• provide a common interface and hide all tool-specific properties;

• perform startup and shutdown of encapsulated tool;

• error and exception handling;

• conversion of input and output data if needed

As an example the wrapper for the Saber simulator will be explained in detail. The wrapper isimplemented in Java. Its interface provides functions for configuration, initialization, start, stop,suspend, resume, and termination of the encapsulated Saber simulator. The wrapper startsSaber as a separate batch process. All user interactions are disabled. Saber receives simula-tion control commands via pipe from the wrapper and performs the simulation. All logging infor-mation are catched by the wrapper via standard output and standard error stream (stdout/stderr).

For using Saber models as FBB within the FDMU framework, the models have to be preparedslightly:

• All external input and output signals have to be identified. Pins with conservation semantic(e.g. KIRCHHOFF pins) have to be splitted in signals with directed signal flow.

• Each input and each output signal is connected to an external connector block whichimplements the communication to the wrapper inside.

The implementation for an external connector block depends on the modeling language andthe used simulator. For the FDMU framework solutions for Modelica (Dymola) and MAST (Sab-er) have been developed. Many modeling languages support integration of external C functionsor external user models implemented in C. As an external connector can be integrated as Ccode, a pipe-based or TCP/IP-based communication between simulation model and wrappercan be implemented. The task of the wrapper is to convert data and protocol and provide thedata up and down streams to and from the Master Simulator.

SaberWrapper

Saber

XCS/PSL

MAST/xconnector

XCS/PSL

MAST/xconnector

TCP/IP TCP/IP

HTTP HTTP

stdin/stdout

Figure 6: Integration of Saber simulator (Synopsys) via FDMU wrapper.

ProtocolConversion

ProtocolConversion

Figure 7: External connectors for Modelica (Dymola) and MAST (Saber).

# FBB Motor (MAST template)

motor.1 p 0 flange 0 = k=1.0,r=0.1var2v.1 U p 0 = 1i2var.1 p 0 I = 1tq_ang2var.1 flange 0 tau = 1var2ang.1 phi flange 0 = 1

real_output_connector.1 I = name="I"real_input_connector.1 U = name="U"real_output_connector.1 tau = name="tau"real_input_connector.1 phi = name="phi"

4 INTERACTIVE 3D VISUALIZATION

3D visualization plays a key role in the FDMU framework. The implementation of the visualiza-tion components is based on the iFX scene graph viewer software [4]. iFX is a flexible andextendable framework for the interactive visualization of simulation data. It supports coopera-tive work over low-bandwith network connections and it is based on OpenSG [2] and handleshuge models with millions of elements. iFX runs on Linux and Windows operating systems andsupports multi core processors. iFX’s architecture was designed to be extendable from groundup. User specific extensions can easily be integrated.

The iFX software has been integrated in the FDMU framework via wrapper. It allows to load thegeometry data from FBB and to visualize 3D object transformations (translation, rotation, scal-ing, ...) according to simulated signal values online.

Comparing to 2D XY diagrams the user gets a deep impression on the behavior of system mod-el and can observe system response after changing input/stimuli signals without any complexor difficult result interpretation process.

Of course, the FDMU framework supports additional viewer software too. Similar to integratingsimulation tools any 2D or 3D viewer tool can be plugged in via wrappers.

5 FDMU APPLICATION EXAMPLE: WINDOW REGULATOR

The application example Window Regulator demonstrates the co-simulation of functional mod-els from the three different physical domains software, electronics, and mechanics. Further-more, the example allows user interactions during a simulation run and shows the results withina 3D visualization immediately. If a user pushs the UP or DOWN button of the window regulator,the window moves up or down in the 3D CAD model respectively (see Figure 9).

Inside a car door a mechanism, operating like shears, moves a car side window up and down(h). It is driven by a gear of an electric motor (τ, ϕ). An engine control unit (ECU) provides thevoltage U of the motor and is monitoring the current I of the motor at the same time. If the cur-rent of the motor exceeds a threshold I_max, the voltage is switched off by the control (U=0).Furthermore the ECU obtains signals up or down from pushbuttons for opening and closing theside windows. The evaluation of the signals is carried out by software inside of the ECU.

The system model is divided in different FBB corresponding to the different physical domains:Switch, Controller, ElectricalUnit, Motor, MechanicalUnit, Window. All FBB exchange their datavia Master Simulator. The (directed) interface signals are up, down, U, I, τ, ϕ, h (see Figure 9).

Figure 8: 3D visualization.

The whole scenario is shown in Figure 10. From the user’s point of view the following questionsmay be interesting, which can be answered by using the FDMU simulation:

• How fast moves the side window?

• Will an obstacle block the movement of the side window?

• Does the system work with changed values of friction?

• Does the controller work correctly?

• Which impact do motor parameters, friction, and current threshild have?

The FDMU framework allows to perform experiments interactively. Some results are shown inFigure 11.

The FDMU framework supports the integration of ODE/DAE-based simulation tools as well assolvers based on partial differential equations (PDE) like FEM and multi-body simulators

Figure 9: WindowRegulator: System model and interactive 3D visualization.

UP

DOWN

Figure 10: WindowRegulator with all FBB connected via Master Simulator.

Visualization Scope DataLogger

Visualization Rhapsody Dymosim SimPack

MasterSimulator

up,down up,down,IU ϕ,I τ,h

U,I,τ,h

τ ϕ

h *

(ANSYS, SimPack). Currently the WindowRegulator example is extended to a more complexsystem model which includes the simulation of thermal effects. Investigations are focused onthe impact of power loss and heat dissipation of electrical unit and the thermal effects aroundthe motor. Figure 12 shows an extended scenario where ANSYS is included for simulatingelectro-magnetic fields and thermal effects inside and around the motor.

Here the question is, how the thermal effects influences the behavior of electrical unit. Design-er’s goal is to guarantee the correct window behavior at all times and situations.

Figure 11: 2D/3D online visualization and interactive parameter configuration.

Figure 12: Extended WindowRegulator with all FBB connected via Master Simulator.

Visualization Scope DataLogger

Visualization Rhapsody Dymosim ANSYS

MasterSimulator

up,down up,down,IU ϕ,I,P T(x,y)

U,I,tau,hh *

SimPack

τ,h ϕτ,T(x,y) U,I,P

6 SUMMARY AND FUTURE WORK

The paper presented the Function Digital Mock-up as a fundamental extension of the wellestablished DMU approach. The main advantages are the co-simulation of different physicaldomains and the combination of functional simulation and 3D geometry visualization in a flex-ible design environment – the FDMU framework. With the concept of Functional Building Block(FBB) users can reuse and combine existing behavioral models and geometry/CAD data. Atotal system model consisting of various FBB can be simulated and visualized within a frame-work. Data exchange and synchronization between FBB is perfomed by a Master Simulator.The FDMU framework provides flexible open interfaces for integration of simulation tools, vis-ualization programs, and other applications supporting virtual product design of mechatronicsystems. Currently, FDMU addresses many important challanges in automotive industry. Morecomplex multi-domain systems can be developed faster. Furthermore, FDMU allows integra-tion tests as early as possible.

In the future additional FDMU services e.g. for deployment, registering, monitoring, and record-ing of FBB and FDMU sessions will be implemented.

REFERENCES

[1] Clauß, C.; Schneider, A.; Schneider, P.; Stork, A.; Bruder, T.; Farkas, T.: Functional Digital Mock-Up für mechatronische Systeme. Multi-Nature-Workshop, Reisenburg-Ulm, 2009

[2] OpenSG: http://opensg.vrsource.org

[3] Schäfer, C.; Voigt, L.; Bruder, T.; Stork, A.; Schneider, P; Clauß, C.; Schneider, A.; Farkas, T.; Hinnerichs, A.: FDMU – Plattform zur Unterstützung der Produktentwicklung mechatro-nischer Systeme. SIMVEC, Baden-Baden, 2008

[4] Stork, A.; Thole, C.-A.; Klimenko, S.; Nikitin, I.; Nikitina, L.; Astakhov, Y.: Simulated Reality in Automotive Design. International Conference on Cyberworlds, Hannover, 2007

Figure 13: ANSYS simulation of temperature distribution over the electrical unit.