Export Simulink Models to Functional Mock-up Units

Export Models

Export Simulink^® models to functional mockup unit (FMU) that supports co-simulation in FMI version 2.0 and 3.0. To check that the exported block is still a valid Simulink model, you can also direct the software to import the FMU back to a Simulink model as part of the export process.

Requirements include:

Simulink Compiler™
FMU Builder for Simulink Support Package
A writable folder into which to place the exported FMU.

Exported models can have:

Input and output data types double, int32, boolean, Enum, and string for FMI 2.0
Input and output data types single, double, int8, uint8, int16, uint16, int32, uint32, int64, uint64, boolean, Enum and string for FMI 3.0
Matrices
Bus Signals
Tunable parameters which can be model arguments, base workspace, or data dictionary variables.
Unit and description.

Enum type in Simulink is int32 based. In FMI 2.0 enumerations are int32 based and in FMI 3.0 enumerations are int64 based.

When you export a model as a standalone FMU, certain metadata from Simulink is also exported with the FMU. The metadata includes:

Model description
Signal unit
Parameter unit
Signal description
Parameter description

Standalone FMU

Simulink models can be exported to standalone co-simulation FMU in version 2.0 and 3.0.

The generated FMU package for FMI 2.0 contains the following files:

modelDescription.xml
model.png (optional)
binaries\win64\modelname.dll, or binaries\linux64\modelname.so, or binaries\darwin64\modelname.dylib

The generated FMU package for FMI 3.0 contains the following files:

modelDescription.xml
terminalsAndIcons\icon.png (optional)
binaries\x86_64-windows\modelname.dll, or binaries\x86_64-linux\modelname.so, or binaries\x86_64-darwin\modelname.dylib
sources\buildDescription.xml

You might experience an expected time delay in the exported FMU for co-Simulation mode. You can use co-simulation FMU 3.0 with event mode to reduce this delay.

FMU Variables

FMU modelDescription.xml file contains interfacing variables converted from Simulink model:

Variables with causality=’input’: converted from root Inport block
Variables with causality=’output’: converted from root Outport block
Variables with causality=’parameter’: converted from referenced Runtime Tunable Parameters
Variables with causality=’local’: converted from internal variables
Independent variable ‘time’

To generate FMU input and output, define root Inport and Outport blocks in Simulink model. The name of the generated variable is converted from root Inport or Outport block name, by removing special and blank characters and avoiding duplicates. If input/output signal carries unit information, it is exported as Unit attribute of the FMU variable. If the input/output block has a non-empty description information under Block Properties > General, it is exported as Description attribute of the FMU variable.

The following input and output data types are supported for FMI 2.0:

double (Real in FMI)
int32 (Integer in FMI)
boolean (Boolean in FMI)
string (String in FMI)
Enum (Enumeration in FMI)

The following input and output data types are supported for FMI 3.0:

single (Float32 in FMI)
double (Float64 in FMI)
int8 (Int8 in FMI)
uint8 (UInt8 in FMI)
int16 (Int16 in FMI)
uint16 (UInt16 in FMI)
int32 (Int32 in FMI)
uint32 (UInt32 in FMI)
int64 (Int64 in FMI)
uint64 (UInt64 in FMI)
boolean (Boolean in FMI)
string(String in FMI)
Enum (Enumeration in FMI)

Enum type in Simulink is int32 based. In FMI 2.0 enumerations are int32 based and in FMI 3.0 enumerations are int64 based.

If model root Inport or Outport block is a non-virtual bus, individual bus elements will be expanded to variables using structured naming convention (‘.’). If model root Inport or Outport block is array or matrix, individual scalar elements will be expanded to variables using array naming convention (‘[]’).

To export referenced variables as FMU parameter, you can:

Define a variable.
Define a Simulink Parameter object.

Ensure that the variable and the parameter object is directly references by tunable parameters of Simulink blocks. In FMU Export dialog, open Parameters tab to configure each parameter. You can:

Unselect Exported option to hide a parameter.
Modify Exported Name so the parameter is displayed with a different name on FMU interface. Do not use special characters and duplicate names.
Set Unit and Description of FMU parameter variable by clicking on parameter name, and directly modifying the parameter object.
If the FMU parameter is Simulink.Parameter, click the hyperlink to modify the Unit and Description of the variable.
If FMU parameter is a regular MATLAB^® variable, clicking the hyperlink opens model explorer. You can convert MATLAB variable to a Simulink.Parameter so that it can carry Unit and Description.
Unit and Description of FMU parameter variable cannot be updated directly in FMU Export dialog. You can configure Unit and Description through model explorer, double-clicking Simulink.Parameter in base workspace, etc.

The following parameter data types are supported for FMI 2.0:

double (Real in FMI)
int32 (Integer in FMI)
boolean or logical (Boolean in FMI)
string (String in FMI)
Enum (Enumeration in FMI)

The following parameter data types are supported for FMI 3.0:

single (Float32 in FMI)
double (Float64 in FMI)
int8 (Int8 in FMI)
uint8 (UInt8 in FMI)
int16 (Int16 in FMI)
uint16 (UInt16 in FMI)
int32 (Int32 in FMI)
uint32 (UInt32 in FMI)
int64 (Int64 in FMI)
uint64 (UInt64 in FMI)
boolean (Boolean in FMI)
string (String in FMI)
Enum (Enumeration in FMI)

Enum type in Simulink is int32 based. In FMI 2.0 enumerations are int32 based and in FMI 3.0 enumerations are int64 based.

If referenced parameter is a struct, individual struct members will be expanded to variables using structured naming convention (‘.’). If referenced parameter is array or matrix, individual scalar elements will be expanded to variables using array naming convention (‘[]’).

When a Simulink model with model reference block is exported to FMU, you can also export base workspace variables, model arguments and instance parameters that are promoted from the sub model.

On the Simulink toolstrip, under Save, select Export Model to Standalone FMU to view options for exporting an FMU with internal variables.

Screenshot of the Access the Internal Variables of FMU.. dialog

FMU Solver

Models with fixed-step and variable-step solvers are supported for export to a standalone co-simulation FMU that is compatible with FMI 2.0 or FMI 3.0 standards. It is recommended to set a fixed fundamental sample time (Solver > Solver details > Fixed-step size) before exporting a model with fixed-step solver. For simulating a variable-step FMU in your system, you need to have an installation of MATLAB or MATLAB runtime. If you are using MATLAB runtime, its version should be the same as the MATLAB version in which the variable-step FMU was created. When simulating the standalone FMU in another environment, communication step-size must be an integral multiple of the fundamental sample time.

FMU Dynamic Library

A generated FMU contains a dynamic library build for the current platform. The default fmi2TypesPlatform or fmi3TypesPlatform value is used.

All required and optional fmi2 or fmi3 functions defined by FMI standard can be invoked. However, the following functions have no operation and return fmi2OK or fmi3OK immediately:

Model-Exchange functions
Functions accessing or serializing FMUstate
Functions setting or getting input or output derivatives
Functions querying fmi2DoStep or fmi3DoStep status, or cancelling fmi2DoStep or fmi3DoStep
Function computing directional derivatives of variables

Save Source Code with FMU Export

You can export a Simulink model to FMU along with C source code. You can check Save Source Code in the Export Model to FMU Co-Simulation window or use the command exportToFMU('mdlName', 'FMIVersion', '2.0', 'FMUType', 'CS', 'SaveSourceCodeToFMU','on') to export the model to FMU with C source code.

Note

To export a Simulink model to FMU with C source code, install Simulink Coder™

If the Simulink model contains model references with custom data types or fixed-point functions, exporting FMU with source code may cause an error due to duplicate header files in the _sharedutils folder. Follow instructions on Generate Shared Utility Code to set the Code Generation > Interface > Shared Code Placement parameter to 'Shared Location' and regenerate the FMU.

You can export a Simulink model with a FMU Import blocks as nested standalone FMU. When exporting a nested FMU, Simulink packs all dependent inner FMUs into the resources/ folder of the nested FMU. When the nested FMU is instantiated in a simulation environment, all inner FMUs will share the same callback functions provided by the environment, for example, logger and memory allocation functions.

Specify Additional Files

While exporting a Simulink to a standalone FMU, you can specify additional files to be included in the generated FMU, such as resource, DLL etc. The target locations for these files can be:

<fmuroot>/binaries/<arch>/ – dependent DLLs
<fmuroot>/resources/ – data files, lookup tables, etc
<fmuroot>/documentation/ – user provide their own help content

For an example on specifying additional files while exporting a Simulink model, see Export Simulink Model to Standalone FMU with User Specified Files and Archived Project with Harness Model.

Export Protected Model

You can export a Simulink model that is protected to FMI 2.0. For an example on exporting protected models, see Export Simulink Model with Protected Model and FMU Import Block to Standalone FMU.

Limitations

You cannot generate FMU from a Simulink model, due to these limitations:

Variable-step solvers are not supported for FMI 3.0.
Non-zero simulation start time is not supported.

Export a Simulink Model

Use the Export Dialog Box

Export the vdp example using the Simulink toolstrip: Simulation > Save > Standalone FMU.

Open the model vdp.
In the Simulink Editor, navigate to Simulation > Save > Standalone FMU.
In Simulink Editor, select Save > Export to > FMU Co-Simulation.
The export dialog box opens without compiling the model. This allows for faster export when using the default options. You can manually run compilation of the model using the Refresh option in the dialog to view and customize the export of inputs, outputs, parameters and internal variables.
In the export dialog box, specify the path to export the FMU.
Click Create
By default, Simulink creates the FMU and a harness model with its dependencies stored in a MAT file. It then packs them into archived project (.mlproj). You can change the behavior by setting Contents option to Standalone FMU.

Use the Programmatic Interface

Export the vdp example to an FMU using the default exportToFMU function. This command creates the FMU file modelName.fmu. By default, the command also creates a Simulink model modelName_fmu.slx, that contains an FMU Co-Simulation block with the original model. Create this model if you want to check the integrity of the exported FMU.
```
openExample('simulink_general/VanDerPolOscillatorExample');
load_system('vdp')
set_param('vdp', 'SolverType', 'Variable-step')
exportToFMU('vdp', 'FMIVersion', '2.0', 'FMUType', 'CS')
```

Export the vdp example to an FMU using the exportToFMU function, but do not create a Simulink model. This command creates the FMU file modelName.fmu.

openExample('simulink_general/VanDerPolOscillatorExample');
load_system('vdp')
set_param('vdp', 'SolverType', 'Fixed-step')
exportToFMU('vdp', 'FMIVersion', '3.0', 'FMUType', 'CS', ...
 'CreateModelAfterGeneratingFMU','off')

Export the vdp example to an FMU using the exportToFMU function. Create a model for the FMU and use an image of the original model as the block icon. This command creates the FMU file, modelName.fmu and a Simulink model with an FMU Co-Simulation block whose block icon is the original model.
```
openExample('simulink_general/VanDerPolOscillatorExample');
exportToFMU('vdp', 'FMIVersion', '2.0', 'FMUType', 'CS', ...
'AddIcon','snapshot')
```

Examples for Different Workflows

The examples below illustrate how to use FMU export for all different scenarios: