Simulink Execution on the ARM7 target

A simulink model can be deployed on an embedded target when the Realtime Workshop and Embedded Coder plugins are used for Code creation.

Code/Model Execution Semantics

The execution semantic of a dataflow model is a continuous dataflow between the simulink blocks on the channels and each block is continuously processing its input data and generating output data. Since continuous execution is not feasible, it is approximated by updating the model in discrete steps. If the time distance between these steps is chosen small enough, the approximation is good enough.

Generated Code

The Embedded Coder produces code whose execution is triggered by 2 functions:

1. an initialization function, called once before model execution
2. a step function, called in a regular interval to update the model

Interaction with the environment is done via the model's ports. The coder maps these to two structs, one for the inports and one for the outports.

Executing the Generated Code

The following pseudo-code illustrates how the generated code is executed:

call simulink_initialize()
each n milliseconds do
    update model inports from environment
    call simulink_step()
    propagate model outports to environment
done

Automated Model Execution

SimulinkTarget is a tool that provides semi-automatic support for running a simulink model on the ARM7 board. Basically it generates code that can be cross-compiled and stored on a SD card to be loaded and launched by the ARM7 bootloader. Since the simulink model does not (and can not) provide all information needed for its execution on a specific target in a specific environment (it is a platform independent model, PIM), some information needs to be given by the user to make it a platform specific model (PSM).

• Model-inherent information:
  • The names of the two functions (step & initialize)
  • The names and data types of all inport and outport variables. These variables are the elements of the inport and outport C structs.
  • The time that should pass between two executions of the step function
• Environment-specific information:
  • The data source of the model's inports and data sinks of the model's outports. On the Concept Car, the ARM7 board only interacts with its environment via the CAN bus, thus inports mus be bound to incoming CAN messages and outports are distributed via outgoing CAN messages. CAN ids have to be provided for each port.
  • The marshaling between CAN message contents and the port values. On the CAN bus, messages are just plain bytes ... even though all messages on the Concept Car's CAN bus are meant to be 4 bytes long and interpreted as 4 byte integer variables, still a mapping to other data types (like floating point) has to be provided.

SimulinkTarget's Work-flow

SimulinkTarget takes a simulink model and generates code that only needs very limited user interference (basically the user must provide the information specified above). Not all code needs to be generated, some source files can be copied.

1. Create (or load) a project configuration file
2. Load the simulink model
3. Load the RTW generated code
4. Select the base stub code used
5. Define CAN binding and marshaling
6. Define output folder and generate code
7. Optionally compile the generated code

A detailed description of the complete tool workflow is available in Simulink2ARM7‎.

Preconditions for Successful Code Generations

1. Platform independent information can be retrieved
   • The simulink model file is provided
   • Parsing the model suceeded
   • Success in retrieving the function names
   • Success in retrieving the port structures
     • The ports' data types are simple: boolean, integer or floating point
   • The step time is given
2. The Embedded Coder's output is good
   • Code matches model
   • Coder's settings were correct (retrieved from mdl file analysis)
3. The target location is OK
   • Needs to be a new or empty directory
   • Write access
4. The board code is good
   • All files as expected
   • Board code's version correct