Real-Time Workshop User's Guide

Combining Multiple Models

If you want to combine several models (or several instances of the same model) into a single executable, the Real-Time Workshop offers several options.

One solution is to use the S-function target to combine the models into a single model, and then generate an executable using either the grt or grt_malloc targets. Simulink and Real-Time workshop implicitly handle connections between models, sequencing of calls to the models, and multiple sample rates. This is the simplest solution in many cases. See Chapter 10, The S-Function Target for further information.

A second option, for embedded systems development, is to generate code from your models using the Real-Time Workshop Embedded Coder target. You can interface the model code to a common harness program by directly calling the entry points to each model. The Real-Time Workshop Embedded Coder target has certain restrictions that may not be appropriate for your application. For more information, see Chapter 9, Real-Time Workshop Embedded Coder.

The grt_malloc target is a third solution. It is appropriate in situations where you want do any or all of the following:

• Selectively control calls to more than one model.
• Use dynamic memory allocation.
• Include models that employ continuous states.
• Log data to multiple files.
• Run one of the models in external mode.

This section discusses how to use the grt_malloc target to combine models into a single program. Before reading this section, you should become familiar with model execution in Real-Time Workshop programs. (See Chapter 6, Program Architecture and Chapter 7, Models with Multiple Sample Rates.) It will be helpful to refer to grt_malloc_main.c while reading these chapters.

The procedure for building a multiple-model executable is fairly straightforward. The first step is to generate and compile code from each of the models that are to be combined. Next, the makefiles for each of the models are combined into one makefile for creating the final multimodel executable. The next step is create a combined simulation engine by modifying grt_malloc_main.c to initialize and call the models correctly. Finally, the combination makefile links the object files from the models and the main program into an executable. Example Mutliple-Model Program discusses an example implementation.

Sharing Data Across Models

We recommend using unidirectional signal connections between models. This affects the order in which models are called. For example, if an output signal from modelA is used as input to modelB, modelA's output computation should be called first.

Timing Issues

We recommend that you generate all the models you are combining with the same solver mode (either all singletasking or all multitasking.) In addition, if the models employ continuous states, the same solver should be used for all models.

If all the models to be combined have the same sample rates and the same number of rates, the models can share the same timing engine data structure. (The TimingData structure is defined in matlabroot/rtw/c/src/mrt_sim.c). Alternatively, the models can maintain separate timing engine data structures, as in the example program discussed below.

If the models have the same base rate, but have different sub-rates, each model should maintain a separate timing engine data structure. Each model should use the same base rate timer interrupt.

If the base rates for the models are not the same, the main program (such as grt_malloc_main) must set up the timer interrupt to occur at the greatest common divisor rate of the models. The main program is responsible for calling each of the models at the appropriate time interval.

Data Logging and External Mode Support

A multiple-model program can log data to separate MAT-files for each model (as in the example program discussed below.)

Only one of the models in a multiple-model program can use external mode.

Example Mutliple-Model Program

An example multiple-model program, distributed with Real-Time Workshop, is located at matlabroot/rtw/c/grt_malloc/demos. This example combines two models, fuelsys1 and mcolon. Both models have the same base rate and the same number of sample times. For simplicity, each model creates and maintains a separate timing engine data structure (although it would be possible for them to share a common structure.) Each model logs states, outputs, and simulation time to a separate model.mat file.

The example files consist of:

• The models, fuelsys1.mdl and mcolon.mdl
• Run-time interface components: modified main program (combine_malloc_main.c) and modified solver (ode5combine.c)
• Control files: modified model.bat and model.mk files

Runtime Interface Components.   The main program, combine_malloc_main.c, is a modified version of grt_malloc_main.c. combine_malloc_main employs two #defines for the models. MODEL1() and MODEL2() are macros that return pointers to the Simstructs for fuelsys1 and mcolon, respectively. The code refers to the models through these pointers throughout, as in the following extract.

SimStruct  *S1;
SimStruct  *S2;
...
S1 = MODEL1();
S2 = MODEL2();
...
sfcnInitializeSizes(S1);
sfcnInitializeSizes(S2);
sfcnInitializeSampleTimes(S1);
sfcnInitializeSampleTimes(S2);
...

combine_malloc_main.c calls initialization, execution, and cleanup functions once for each model.

combine_malloc_main.c also uses the following #defines:

• NCSTATES1 and NCSTATES2 represent the number of continuous states in each model.
• MATFILEA and MATFILEB represent the MAT-files logged by each model.

To see all modifications in the main program, compare grt_malloc_main.c to combine_malloc_main.c.

The solver, ode5combine.c, is also modified to handle multiple models. The UpdateContinuousStates function has been modified to obtain the number of continuous states from each model's Simstruct at runtime. Simstructs are passed in by reference.

Control Files.   combine.bat was created from the generated control files fuelsys1.bat and mcolon.bat. These were modified to invoke the makefile, combine.mk.

combine.mk combines parameters from the generated makefiles, fuelsys1.mk and mcolon.mk. Note the following modifications:

• combine.mk contains the model-specific defines MODEL1, MODEL2, NCSTATES1, and NCSTATES2. Note that these defines are included in the CPP_REQ_DEFINES list.
• The SOLVER parameter specifies ode5combine.c.
• The REQ_SRCS list includes combine_malloc_main.c.
• Two rules have been added in order for make to locate source files in the build subdirectories, fuelsys1_grt_malloc_rtw and mcolon_grt_malloc_rtw.

Building the Example Program.   To try the example:

1. use the build command to generate code and compile object files for the fuelsys1 and mcolon models.
2. Modify the MATLAB_ROOT and MATLAB_BIN path information in combine.mk as appropriate for your installation.
3. At the command prompt, type

combine.bat (on PC)

or

make -f combine.mk (on UNIX)

to build the combine executable.

Guidelines for Implementing the Transport Layer

DSP Processor Support