Exporting Models & Licensing

Introduction

This article looks at the different model export methods, their limitations and the respective Dymola licensing requirements.

Ways to Export a Model 

Models can be exported in several different forms:

Executable

Whenever a model is translated, an executable file is created, called dymosim.exe. When the model is simulated (run) the dymosim.exe file is executed. This file can be run from the Windows Command Prompt¹.

It is also possible to generate and simulate dymosim.exe from the Matlab®, Java, Python or JavaScript interfaces². DDE and OPC embedded servers are supported as described in the “Additional Features” Section below.

DLL

The model can be exported as a Dynamic Linked Libraries file, or DLL, with the API given by <Dymola installation directory>/source/dymosim.h³. The parallelisation features of DYMOLA are not supported. Note that this feature will be removed in future versions of DYMOLA and it is recommended that FMI is used instead.

C code

A model’s C code can be generated and utilised directly by the user. The user must provide the solver; but an example project in MS Visual Studio is provided in <Dymola installation directory>\binary\export\StandAloneDymosim.zip which contains a Euler solver, and a variable-step solver⁴.

FMU

Functional Mock-up Interface, or FMI is an open standard for model exchange and co-simulation⁵. In Model Exchange Mode, the simulation tool with which the exported model is run, provides the solver. Conversely, Co-simulation Mode includes the solver in the exported model.

Models exported using this standard are called “FMU” denoting “functional mock-up unit”, many modelling and simulation environments support these⁶. An FMU also can be simulated from:

• C projects⁷ 
• Python⁸

FMI exported models can also be interfaced with Simulink and MS Excel using the Claytex FMI Blockset. Read more about this here on our website: https://www.claytex.com/products/fmi-blockset/

Simulink® S-Function

A toolbox is provided for Simulink that provides an easy way to import DYMOLA models⁹.

vTAG/PTWinSim

The Claytex BuildTools Library can export models as apps that can run on vTAG or PTWinSim (read further at: https://www.claytex.com/products/dymola/model-libraries/vesyma/driver-in-the-loop/). The VeSyMA – Driver-in-the-Loop library provides an interface with the rFpro, professional driver-experience simulation environment, which allows these vTAG or PTWinSim apps to interface with rFpro. However, Linux is not supported.

Figure 1: Feature table of export options.

*This licence is needed; having a full DYMOLA licence or DYMOLA runtime licence is not sufficient.

Additional Features

Inline Real-Time Solver

DYMOLA provides inline integrators that can be used with the Euler solver¹⁷. These inline solvers typically increase simulation speed but can be less accurate, which when working with Hardware-In-the-Loop (HiL) in particular, can be a necessary compromise. The Real-time settings are in Figure 2.

Figure 2: Real-time setting in Simulation->Settings, the type and order of inline integrator can be selected.

DDE

A DDE server can be embedded into¹⁸ the dymosim.exe Executable. The DDE server can be used to set parameters, start and stop a simulation, and to simulate the model in Real-time. It is also possible to “hot link” to variables, so you read the value of a variable while a simulation is running. Currently only the Lsodar, Dassl, Euler, Rkfix2, Rkfix3 and Rkfix4 integration schemes are supported and only Visual Studio compilers can be used with this feature. Parallelisation features of DYMOLA are also unfortunately not supported.

Figure 3: Compiler settings for Simulation->Setup.  These settings include the selection of the Embedded server and the option

to export a model as a DLL (note that a model exported with embedded DDE or OPC server cannot be exported as a DLL).

OPC

The dymosim.exe Executable can be compiled with an embedded OPC server¹⁹. The functionality is like that of the DDE server except that it uses OPC including a graphical interface provided as in Figure 4. The OPC feature currently only compiles as a 32-bit executable. Only Lsodar, Dassl, Euler, Rkfix2, Rkfix3 and Rkfix4 solvers are supported and only MS Visual Studio compilers are supported with this feature. Parallelisation features of DYMOLA are not supported.

Figure 4: OPC graphical interface

HIL Interface Options

Synchronization with real-time, code efficiency and compatibility with HIL test rig hardware is important for code being exported for HIL. Below is another look at the export options with the focus on HIL:

Executable

Dymosim.exe can be run in Real-Time with use of the OPC (only supports 32-bit) or DDE interfaces, as documented in the previous entries.

The Modelica_DeviceDrivers library²⁰ provides support to the following IO: UDP, TCP/IP, LCM shared memory, AD/DA converters, serial port and other devices. It is also possible to interface DYMOLA models with external C or Fortran code, so this provides further options for interfacing with HIL test rigs.

DLL

Similar properties as the “executable” above, however the embedded OPC and DDE server options are not supported so the user would have to control the synchronisation with real-time.

C Code

Many HIL systems can interface with C code.

FMU

dSPACE, PLC, AVL testbeds, ETAS LABCAR-OPERATOR, SimWB and others, can interface with FMU’s.

Simulink

Models can be exported to Simulink using the S-Function interface using a DYMOLA Block or the FMI interface. From here, tools can be used to export the Simulink models to dSPACE, xPC and other platforms.

vTAG/PTWinSim

DYMOLA models can be exported to the vTAG or PTWinSim Apps using BuildTools Library, which you can learn more about at https://www.claytex.com/products/dymola/model-libraries/vesyma/driver-in-the-loop/.

The Simulator Library also provides an interface to rFpro. System Monitor²¹ and ATLAS²² can be used to modify the parameters setup and to log results for models simulated on vTAG.  PTWinSim Monitor²³ and Gredi²⁴ can be used to modify the parameter setup and to log results for models simulated using PTWinSim.

Figure 5: Feature table for HIL options

+ The interface and tools support will depend on the platform selected

* This license is required even if the exported model is simulated on a machine with a DYMOLA license (included the same machine that was used to export the model)

Licensing Options

Below is the list of licenses that are required to run an exported model²⁹. These licenses do not include licenses required by third party libraries³⁰.

Real-Time Simulation license

A Real-Time license is required to use inline integration (mentioned in the “Additional features” Section above). This license is included in the basic configuration shipped with DYMOLA as of the 2017 FD01 edition.

DYMOLA license

Most Functional Mockup Units or FMUs (See Binary Model Export below) and most Simulink models (See Source Code Generation and Simulink interface below) will simply run on a machine that has a DYMOLA (standard configuration) or a Runtime License.

DYMOLA Runtime license

A runtime licence confers upon the user the same ability to run exported models as a DYMOLA software license, but without any independent access to the software. This has provided scope for the use of DYMOLA models, even when these were generated without Binary Model Export, or Source Code Generation licences. This licence will no longer be a separately available product as of DYMOLA 2018. As a result, the possibilities will be restricted to:

1. Models for use without a full DYMOLA licence must be exported using an appropriate licence.
2. Models exported without the Binary Model Export or Source Code Generation licences will require a full DYMOLA licence to be run.

Binary Model Export

This allows the exported executable, DLL, S-Function or FMU models, to run on another machine even if that machine has no DYMOLA Standard, or Runtime license. This licence is required to create DLL models and to create Co-Simulating FMUs that use DYMOLA solvers.

Source Code Generation

This licence includes all the abilities of the Binary Model Export license. It also confers the ability to export source code that can be used in standalone projects. This licence is required to export models to dSPACE and xPC via FMU’s. This license is also required by the Claytex BuildTools, and Simulator Libraries in order to create vTAG and PTWinSim Apps.

Simulink Interface

This option is required to export a model to an S-Function for use in Simulink. Together with the Real-Time Simulation license you can compile the model to dSPACE or xPC using Simulink Coder.

Written by: Garron Fish – Chief Engineer

Please get in touch if you have any questions or have got a topic in mind that you would like us to write about. You can submit your questions / topics via: Tech Blog Questions / Topic Suggestion

¹ see Section 5.4 of the DYMOLA User Manual Vol. 1

² see Section 6.2, 6.6, 6.7 and 6.8 of the DYMOLA User Manual Vol. 2 respectively

³ see Section 6.11.2 of the DYMOLA User Manual Vol. 2

⁴ see Section 6.11.3 of the DYMOLA User Manual Vol. 2

⁵ see https://fmi-standard.org/

⁶ see https://fmi-standard.org/tools

⁷ as documented at: https://resources.qtronic.de/fmusdk/FmuSdk_reference.html

⁸ see https://github.com/CATIA-Systems/FMPy

⁹ see Section 6.2.1 of the DYMOLA User Manual Vol. 2

¹⁰ Licenses required to run the exported model on a machine without a DYMOLA or a DYMOLA Run-time license, excludes licenses required for any 3^rd party libraries that are used

¹¹ Embedded DDE and OPC servers do not support parallelization

¹² Models from FMI compatible tools are supported (e.g. Adams, Simulink, …), and the tools have a wide range of abilities (e.g.  PLC interface, optimization, dSpace interface, …)

¹³ A tool is required to interface the FMU to Simulink, one tool is the FMI Blockset see https://www.claytex.com/products/fmi-blockset/ another is FMI Kit for Simulink see http://www.3ds.com/products-services/catia/products/DYMOLA/fmi which comes with DYMOLA

¹⁴ The Binary Export Model is required to export a Co-Simulation FMU that uses the DYMOLA solvers even if the model is going to run on machine with a DYMOLA License

¹⁵ The Simulink Interface and Real-Time Simulation license is required to create Simulink S-Functions that are to be exported to dSPACE or xPC

¹⁶ Was only available as a beta feature at the time the post was written, this is now supported

¹⁷ see Section 5.7.6 of the DYMOLA User Manual Volume 1

¹⁸  see Section 6.4.3 of the DYMOLA User Manual Volume 2

¹⁹ see Section 6.5 of the DYMOLA User Manual Volume 2

²⁰ see https://github.com/modelica/Modelica_DeviceDrivers

²¹ see http://www.mclaren.com/appliedtechnologies/products/item/system-monitor/

²² see http://www.mclaren.com/appliedtechnologies/products/item/atlas/

²³ see http://www.podiumtechnology.co.uk/ptwinsim.html

²⁴ see http://www.kleinknecht.com/en/software_gredi4.htm

²⁵ Licenses required to run the exported model on a machine without a DYMOLA or DYMOLA Run-time license, excludes licenses required for any 3^rd party libraries that are used

²⁶ Embedded DDE and OPC servers do not support parallelization

²⁷ The Binary Export Model is required to export a Co-Simulating FMU that uses the DYMOLA solvers even if the model is going to run on machine with a DYMOLA license

²⁸ Ability is available as a beta option

²⁹ see Section 6.7.3 of the DYMOLA User Manual Volume 1

³⁰ Libraries requiring licences are either licensed via the same mechanism as the basic software licence, or by third-parties.