Learn more about Real-Time Workshop

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 product offers several options.

The most powerful solution is to use Model blocks. Each instance of a Model block represents another model, called a referenced model. For code generation, the referenced model effectively replaces the Model block that references it. For details, see Referencing a Model and Creating Model Components.

When developing embedded systems using the Real-Time Workshop Embedded Coder product, you can interface the code for several models to a common harness program by directly calling the entry points to each model. However, Real-Time Workshop Embedded Coder target has certain restrictions that might not be appropriate for your application. For more information, see the Real-Time Workshop Embedded Coder documentation.

The GRT malloc target is a another possible solution. Using 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

To summarize by target, your options are as follows:

Target	Support for Combining Multiple Models?
Generic Real-Time Target (grt.tlc)	Yes (using Model blocks)
Generic Real-Time Target with dynamic memory allocation (grt_malloc.tlc)	Yes
Real-Time Workshop Embedded Coder (ert.tlc)	Yes
S-function Target (rtwsfcn.tlc)	No

Using GRT Malloc to Combine Models

This section discusses how to use the GRT malloc target to combine models into a single program.

Building a multiple-model executable is fairly straightforward:

1. Generate and compile code from each of the models that are to be combined.

2. Combine the makefiles for each of the models into one makefile for creating the final multimodel executable.

3. Create a combined simulation engine by modifying grt_malloc_main.c to initialize and call the models correctly.

4. Run the combination makefile to link the object files from the models and the main program into an executable.

Sharing Data Across Models

It is safest to use 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

You must generate all the models you are combining with the same solver mode (either all single-tasking or all multitasking.) In addition, if the models employ continuous states, the same solver should be used for all models.

Because each model has its own model-specific definition of the rtModel data structure, you must use an alternative mechanism to control model execution, as follows:

• The file rtw/c/src/rtmcmacros.h provides an rtModel API clue that can be used to call the rt_OneStep procedure.

• The rtmcmacros.h header file defines the rtModelCommon data structure, which has the minimum common elements in the rtModel structure required to step a model forward one time step.

• The rtmcsetCommon macro populates an object of type rtModelCommon by copying the respective similar elements in the model's rtModel object. Your main routine must create one rtModelCommon structure for each model being called by the main routine.

• The main routine will subsequently invoke rt_OneStep with a pointer to the rtModelCommon structure instead of a pointer to the rtModel structure.

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.

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

Back to Top

Creating Component Object Libraries and Enhancing Simulation Performance

Block Support Considerations

© 1984-2009- The MathWorks, Inc.    -   Site Help   -   Patents   -   Trademarks   -   Privacy Policy   -   Preventing Piracy   -   RSS