Export Function modeling style allows you to integrate functions from your model into your software environment easily and provides a clear mapping from model to code. 

To show how this works, I will start with a model of a Throttle Control System in which the desired software functions have already been modeled using subsystems.

In this model, we have Simulated Pedal Input, going into a Throttle Control, which is then being simulated by a model of a Throttle Body acting as a plant. Inside the Throttle Control Subsystem, we have functions for sensors and sensor management, including one for the primary and secondary throttle sensors, and the sensor monitor. We also have a controller and actuator.

To understand the need for Export Function modeling, let us generate the default code for this model. Although I have modeled the desired functions with subsystems, Simulink optimizes the code and in-lines the functions. In addition, function execution order is determined by Simulink’s built-in scheduler. As a result, the code does not reflect the interface of the functions and does not provide the ability to control execution order. This may not match the needs of your software architecture. 

Let’s look at the Export Function modeling version. The model is now architected differently. First, the Throttle Controller subsystem is now a model block with a fixed-step discrete solver, instead of a variable step solver, because it’s intended for software and integration.

And within the model block, they are in function call subsystems. Export Functions allows you to model the interface, where functions that are to be integrated into the architecture are represented as function trigger ports. If we look at the sample time on the function calls, we can see that they are sampled every 5 milliseconds, except for the Throttle Position Sensor Primary, which is sampled at every 10 milliseconds, and the Acceleration Pedal Position Sensor, which has an event which triggers when this will run.

With Export Functions, no inherent scheduler is assumed, allowing you to more flexibly integrate to a custom environment. You can choose to schedule via the ports or the Schedule Editor to make a simple test harness. For simulation purposes, the software scheduler, in this case, is the Schedule Editor.

The Schedule Editor sends an event to the different function calls every 5 or 10 milliseconds based on when the function call needs to be invoked. The Acceleration Pedal Position Sensor is an explicit aperiodic partition that has scheduled hit times. If you use Stateflow to do the scheduling for run-time software modeling, you can use logical constructs to alter when components are called depending on different situations.

A more extensive test harness for unit testing the controllers can be set up, using the Simulink Test product.

When we generate code for the model block, we get code that separates out the functions, which is taken from the names off the function call ports, making software easier to build. More realistic modeling with scheduling and easier code integration are two of the main reasons we use export functions for real-time software modeling.