The Answer for Large Scale Modeling: Model Reference 21

Posted by Seth Popinchalk,

Your model is someone else’s component.  The Model block allows you to treat a Simulink model as a component within a larger system.  In this post I will discuss the basic concepts of model reference and look at what is new for R2008b.

What is Model Reference?

Model reference is the Model block from the Ports & Subsystems library.

The Simulink model reference block

When you use the Model block you must specify the model that you are referencing.  This is how your model becomes a component in a larger simulation.

Model block requires the name of a model

Models can reference models, which can reference models, and so on. (That reminds me of this Simpsons title sequence.)

A model block has a model inside

Benefits of Hierarchy

Model reference lets you break up the hierarchy into separate models.  These models can be simulated and built stand alone, which means teams can independently develop components in parallel.   The benefits of breaking up the hierarchy in this way include:

  • Fewer blocks in the top level system
  • Simulation and testing of component models
  • Incremental update diagram and code generation
  • Interface specification for parallel development

The cost to update a diagram is roughly proportional to the number of blocks in the model.  If you have a system of 10,000 blocks that implement your model, you might be able to add a layer of model reference to encapsulate some systems, and reduce the number of blocks in the top model.  When a model reference component runs in accelerator mode, it is a single block in the top model.  That single block can hide hundreds or thousands of blocks beneath it.  The initial cost to update that reference component will be proportional to the number of blocks in that model, but once it is up to date, the top model can update more quickly.

This leads to another major benefit, incremental rebuilds.  When you make a change to a reference model, only that model needs to rebuild.  This is true for simulations and for Real-Time Workshop code generation.  When you make a change to a model, only that model and other models that depend on it will require a rebuild.  This is where you can save time if you are only changing a small portion of the model reference hierarchy.

Modes of Simulation

Each model block can define its simulation mode.  This tells Simulink how that instance of the model runs.

Specify the Simulation mode on each model block instance

Normal Mode – The reference model runs in interpreted mode, the same way a normal model runs when you are first building it.  This mode for model reference is helpful for debugging and when making changes to a reference component.  Normal mode was added to the model reference block in R2007b.  Normal mode is indicated by the empty triangles on the corners of the model block.

Accelerator Mode – To a parent model, the accelerated model behaves like a single block.  Simulink uses code generation technology to convert the referenced model into a MEX-file (simulation target), which the parent calls during the simulation.  There is a one-time cost to generate that MEX-file but subsequent simulations can be faster than normal mode.  Accelerator mode is indicated with filled corners on the model blocks.

Normal and accelerator model reference blocks

Processor-in-the-loop (PIL) Mode – NEW in R2008b – PIL mode allows co-simulation of the reference model on another processor. This enables the development of combination plant/controller models using model reference for components.  When prototype controller hardware is available, you can generate production code for that target using Real-Time Workshop Embedded Coder.  In PIL mode Simulink creates a MEX-file that handles the execution of the production code.  The top-level simulation is still in Simulink, but the code for the controller can be running on the actual hardware or in an instruction set simulator/emulator.  PIL mode model blocks have filled triangles on the corners and include (PIL) below the name of the model.

Processor-in-the-loop mode model reference

Model reference PIL mode is a new capability however; people have been successful applying these workflows using xPC and other rapid prototyping techniques with RTW for many years.  The convenience of this approach comes from preserving a single system model and just modifying the simulation mode of the model reference block.  One might use normal mode when debugging the algorithm, accelerated mode for coverage testing and rapid test vector generation, and finally PIL mode to verify the code running on the actual hardware.  Each of these steps requires minimal modifications to the original system model. There are some problems that only PIL mode can detect

Some History

Simulink included the model reference block in R14.  At the time, people were finding that their models would grow so large that they couldn’t fit them into the memory on their systems.   The performance of update diagram and RTW build was hitting limits of available RAM, and models continue to grow in size.  Model reference breaks up these problems and provides a scalable long-term solution for working with large models.

How many levels of model reference hierarchy do you work with?  Leave a comment here and tell us your experience with model reference.

21 CommentsOldest to Newest

Samil replied on : 1 of 21

Being able to break up the hierarchy into separate models is especially important when you want to unit test each component and make sure they meet basic correctness criteria.

Model reference is fine until you create a model where Simulink thinks you have an algebraic loop where in reality there is no algebraic loop. This happens for atomic subsytems like model reference or enabled subsystem blocks. Unfortunately, none of the methods in Simulink documentation (e.g. checking minimize algebraic loops box) help. Only when you convert the atomic subsytem into a virtual subsystem the error disappears and you can run the model in accelerator mode.

I wonder if there is an elegant solution to the dreaded algebraic loops with atomic subsystems. My plan for the time being is to write a parser that will compile the submodels into an integrated mdl file where all the submodels are represented as virtual subsystems. However, that would be a serious usability limitation for the model reference block.

Seth replied on : 2 of 21

@Samil – You are not alone in your frustration about using model reference and finding that you have algebraic loops. The problem comes from a competing requirements that you have imposed on your system. Model reference blocks are atomic units, so their contents must execute at one. If the feedback path is all direct feed-through blocks, you have an algebraic loop. The condition where you have an “artificial” algebraic loop happens when the model reference block is not actually direct feed through, and introduces some kind of state in to the loop. In this case, checking “minimize algebraic loops” might resolve it. Simulink performs an optimization during analysis of the model to determine if the output ports are direct feed-through or not.

Instead of asking for an “elegant solution” to this problem, I find it is helpful to try and understand why the system is being specified as atomic. This is a rich topic I hope to address in more detail in a future post. Samil, thanks for sharing your comment with us.

Paul J. replied on : 3 of 21


I agree with Samil on the algebraic loop issue. It’s frustrating to get one because the model reference is atomic, even though you know that there really is not an algebraic loop mathematically. I haven’t had much success with the “minimize algebraic loops” option. I think I understand why references are atomic, but I’m looking forward to your future post that explains it.

Another issue with model references that I’ve found troubling is the Model Arguments used to customize each instance of a referenced model. If a referenced model requires 100 parameters, it’s unwieldy to have to list each one individually in the Model Arguments and Model Argument Values dialogs. For the latter, I tried putting several values into a cell array and then tried to enter the cell array in the dialog using p{:}, which should result in a comma separated list of values. But that didn’t work either. This issue becomes more troublesome when model references are nested where it’s desired to have all of the model argument values defined at the topmost model and passed down to nested models. Maybe allowing the use of structures as model arguments would be helpful, similar to the way a non-virtual bus can be defined to lock down an interface. Looking forward to your thoughts on this issue or clarifying any aspects that I have misunderstood. Also, I’m still back on 2007b. Any changes in 2008b wrt Model Arguments?


Kevin L. replied on : 4 of 21


I agree with Samil on the algebraic loop issue too.
Another issues with model references that I’ve found troubling in work with a large scale system more than 10,000 models.

First,if we have about 100 refferenced models, how to manage their simulation mode efficiently. e.g., somen times we use Normal mode to debuging, sometimes we want to simulate in Accelerate mode or PIL mode, but the change of simulation mode must be done not one by one.

Second, we have a large scale system created by refference models. A quickly running speed is important. And some variables values want to be recorded. By the way, variables are in different sample groups. Which variables to be saved may be selected in a variable list. So each run they may be different. How can I do with it use simulink?

Looking forward to your thoughts on the issues.

Thanks a lot,

Kevin L. replied on : 5 of 21


Another problem in using model refference is that simulink debugger is disable. I think it’s frustrating in model-based design.

Looking forward to your reply.
Thanks a lot,

Mike Tocci replied on : 6 of 21

Hi, my name’s Mike Tocci and I’m a developer at The MathWorks working on Model Reference. Here’s a few answers to some of the questions asked so far:

@Paul – there haven’t been any changes to model arguments as of R2008b, but we are currently working on allowing structures to be passed as model arguments.

@Kevin L – One thing you can do to make changing the SimulationMode easier is to script it. set_param accepts a cell array of blocks, and find_mdlrefs and find_system will return a cell array of blocks. For example, to change the SimulationMode of all the Model blocks contained in a model and all of its referenced models, you could use something like,

>> [refMdls, mdlBlks] = find_mdlrefs(model);
>> set_param(mdlBlks, ‘SimulationMode’,’Normal’);

One caveat is that find_mdlrefs doesn’t load all the referenced models, so you may have to load those models before doing a set_param.

@Kevin L – signals can be logged in referenced models by right-clicking on the Model block and selecting “Log Referenced Signals”. Let me know if you need any more information on this feature.

@Kevin L – we currently don’t support the Simulink debugger in referenced models, but this is a feature we’re working on for a future release.

Thanks for the comments and questions so far, please keep them coming.

Kevin L. replied on : 7 of 21


Thanks for the reply.
I have try log out signals in referenced models. Signals can be logged out, but the unpacking is so slow when the signals logged out are in deep models. e.g., 6 or more layer.
Can you give me some suggestions on making unpacking faster.

Thanks and happy new year:)

Kevin L. replied on : 9 of 21


I just mean that unpacking goes slowly with log.unpack(‘all’) when signals logged out are in deep models. e.g., 6 or more layer. If sinals logged out are in shallow models, e.g. 2 layer or 1 layer, unpacking may be fast.
I wonder if you understand exactly my question.


S.S. KIRAN replied on : 10 of 21

May i know the how model referencing is different from library linking.
Advantages of model referencing compared to library linking.

J.r replied on : 11 of 21

Sorry to hit an old thread, but this seems like the best place to solicit help on this topic.

Is there supposed to be subtle differences between ‘Minimize algebraic loop occurrences’ for atomic systems and model references. I have created a simple model which exhibits different behavior between the two (in both 2007b and 2009b). I am ultimately trying to determine if I can help Simulink resolve the generic algebraic loop case with model references for those systems which don’t actually have loops. This is for users who have little experience with the subtleties of model references.

My model is a simple loop of subsystems of a control system. The plant has no direct pass-through paths. Here are the two behaviors:

Atomic subsystems: Highlights the loop at update diagram time and does not allow simulation since update diagram fails. Setting ‘MALO’ on the block which is not direct pass-through caused the block order to change to make this block first and the algebraic loop is no longer detected. Viola. Changing the block order through ‘Priority’ also succeeds in clearing up the false loop detection.

Model references: Throws warnings about the false algebraic loop, but allows update diagram to complete. Simulation is possible, but the algebraic loop algorithm is occurring at each time step, slowing the simulation and causing additional IC headaches. Setting ‘MALO’ in the model which is not direct pass-through does nothing except throw additional ‘Unable to remove algebraic loops’ warnings. Block order remains unchanged and ‘Priority’ is also unable to change Simulink’s mind.

I can send you my example if you are interested.

@ J.r – The ability for atomic subsystems and Model Reference to remove the “fake algebraic loop” due to their atomic property depends on where inside the atomic unit the non-directfeedthrough block is.

If you send me a simplified example that demonstrates what you describe, I would be interested to give it a look and try to explain or find a workaround for this behavior.

SteveH replied on : 14 of 21

Is there a script available that allows one to convert a model reference subsystem into a virtual subsystem?

Guy Rouleau replied on : 15 of 21

@SteveH – This is a good question. We have a function called Simulink.SubSystem.convertToModelReference to convert an atomic subsystem into a referenced model, which is the opposite of what you are looking for.

In your case, I recommend using Simulink.BlockDiagram.copyContentsToSubSystem to copy the content of your referenced model into a new subsystem.

You can then replace the Model Reference block by this subsystem using replace_block

Kiran replied on : 17 of 21

Can you tell me how can i debug stateflow chart if it is in model reference block? looking for suggestions…

Mike Tocci replied on : 18 of 21

@Kiran — You can change the Simulation Mode on the Model block to Normal mode, then all of the standard Stateflow debugging techniques should work.

Vivek replied on : 19 of 21

@Guy – I’m not 100% sure if this question belongs here, but it does have something to do with Mask Initialization. I have a lot of blocks in my model and many of them have mask init routines that involve a few get_params, set_params etc. to automatically name wires etc. When I build my code, I noticed that the update diagram portion alone takes about 45s to a minute! Is there a way I can look at which blocks take the longest to update or where the bottleneck is while updating a diagram?

@Vivek, to get information about the update of a model, you can use:

[txtRpt, sRpt] = sldiagnostics(‘sys’)

the sRpt output divides the model update in more than 100 phases to help you figure out where is the bottleneck. This is not a block-by-block basis information, but an overview of the phases the engine go through during update diagram.

Nice post. I used to be checking constantly this weblog and I am inspired!
Extremely useful information specifically the remaining part :) I maintain such information a lot.

I used to be looking for this particular info for a very lengthy time.

Thank you and best of luck.

Add A Comment

What is 2 + 5?

Preview: hide