Simulating Dynamic Systems in RF::Viper with FMUs Exported from MATLAB/Simulink

Running FMU models in RF::ViPer: A Practical Use Case Workflow with MATLAB/Simulink

In modern industrial processes and automation, the need to simulate increasingly complex dynamic systems and behaviors is growing. While automated systems offer precision, they also introduce complexities that must be simulated to accurately represent the system’s actual behavior.

Since no single tool is a ‘one-size-fits-all’ solution, some are better suited for simulating complex dynamic behaviors than others. Therefore, it makes sense to use these tools to create models with more intricate dynamics and then export them to a format that can be easily read and executed by other tools.

One such format is FMU (Functional Mock-up Unit). The FMU is a standardized model exchange format used for co-simulation and model exchange across different simulation tools. FMUs are based on the FMI (Functional Mock-up Interface) standard, which allows engineers to share dynamic system models between different software environments (e.g., MATLAB Simulink, Dymola, OpenModelica, ANSYS, etc.).

In general, there are two types of FMUs:

1.  Model Exchange (ME) – Only the model structure is shared (no solver).

2.  Co-Simulation (CS) – Includes both the model and a solver for standalone execution.

Creating and running FMU model in Matlab/Simulink

This case will demonstrate the creation of an FMU co-simulation model in MATLAB/Simulink, followed by running the model in RF::ViPer simulation.

The basic workflow consists of the following general steps:

Step 1: Create Simulink Model

Step 2: Export Simulink Model as a standalone FMU as Co-Simulation (CS) model

Step 3: Add FMI library to the current RF:: ViPer project (currently RF::ViPer supports models according to FMI version 2.0)  

Step 4: Create a function block (FB) in RF::ViPer and run the simulation

As an example, a hydraulic servo system can be modeled as an underdamped oscillatory second order system, described with the following transfer function:

YsUs=Kn2s2+2ns+n2

Where K is a process gain, is a damping ratio and n=2fn is a natural angular frequency of the system.

Step response of the second order system with the following parameters K=10, =0.2, fn=0.1 Hz is given in the following figure:

FMU model is created in Simulink by using Save→Export as Standalone FMU from Simulink standard toolbar. 

The FMU model can be verified in Simulink by comparing its outputs with those of a standard transfer function block, as illustrated in the figure below.

FMU model validation and obtaining meta information from the model description can be done online here: https://fmu-check.herokuapp.com/

The FMU model is stored as a compressed archive with an .fmu extension, containing a modelDescription.xml file. This file includes all relevant information, such as the list of variables, their types, and initial values. The contents of the .fmu file can be accessed and examined using tools like 7-Zip or similar archive utilities. An extract is given in the figure below:

Loading and Running FMU Models in RF::ViPer 

FMU model is loaded to RF∷ViPer within a function block using library function called LoadFmu. Since all variables in this model are of type REAL, their values are set and retrieved using the SetReal and GetReal functions, respectively. Each variable in the model is uniquely identified by a valueReference in the modelDescription.xml, which is of type unsigned integer. The DoStep function advances the simulation of a Functional Mock-up Unit (FMU) within a co-simulation environment. A detailed explanation of these functions, including their input and output values, is beyond the scope of this blog. Therefore, readers are encouraged to consult the RF::ViPer CmpFmiRuntime library documentation for more information.  

A simple structure of the wrapper function block for loading and running an FMU model with basic error handling is provided below::

FUNCTION_BLOCK SecondOrderSystem

VAR_INPUT

u : LREAL;

K, fn, zeta, Ts : LREAL;

END_VAR

VAR_OUTPUT

y : LREAL;

Error : BOOL;

END_VAR

VAR

_fmu : FMI.FmuContext;

// valueReference identifiers

_u : UDINT := 0;

_y : UDINT := 1;

_K : UDINT := 2;

_fn : UDINT := 3;

_zeta : UDINT := 4;

END_VAR

// Implementation part 

IF _fmu.handle = 0 THEN

// Initialize only once

_fmu := FMI.LoadFmu('SecondOrderSystem.fmu');

IF FMI.IsValidFmuHandle(_fmu.handle) THEN

FMI.SetReal(_fmu, _u, u);

FMI.SetReal(_fmu, _y, y);

FMI.SetReal(_fmu, _K, K);

FMI.SetReal(_fmu, _fn, fn);

FMI.SetReal(_fmu, _zeta, zeta);

ELSE

Error := TRUE;

RETURN;

END_IF

ELSE

FMI.SetReal(_fmu, _u, u);

FMI.DoStep(_fmu, Ts);

IF 0 <> FMI.FmiStatus.Ok THEN

Error := TRUE;

FMI.FreeInstance(_fmu);

RETURN;

ELSE

FMI.GetReal(_fmu, _u, u);

FMI.GetReal(_fmu, _y, y);

END_IF

END_IF

To allow flexibility in testing with different parameter values, these can be defined as inputs to the wrapper FB. The user should ensure that the sampling time (step size) matches the cycle time of the task in which the FB is called.

An example of calling the FB from the main program is given below:

Step response of the FMU FB, recorded with the Trace is given below:

This simple example demonstrates how more complex dynamic systems can be relatively easily simulated in RF∷ViPer. Implementing such dynamics from scratch in RF∷ViPer would not be optimal and would require significant time and effort. On the other hand, it is straightforward to use a more suitable tool to create the model and then import it as an FMU into RF∷ViPer.

This enables the simulation of a wide range of devices or complete systems in RF∷ViPer using provided FMU models. As a result, it can lead to significant time savings in the overall workflow and an improvement in the accuracy of the simulation.