Guy and Seth on Simulink

September 1st, 2010

By Guy Rouleau

In a previous post, Seth introduced the concept of Model Reference and the advantages it brings for dealing with large models. Since MATLAB R2009b, Model Reference Variants make it easy to reconfigure your model for different design variants.

What are Model Reference Variants?

In Model-Based Design, you want your design process to be centered around a single model, however, design variations may require different implementations for different purposes. For example, imagine that you want to model a vehicle that has three possible engine configurations:

• 4 cylinder gas
• 6 cylinder gas
• 4 cylinder diesel

Using model reference variants, you could implement each engine model as a separate reference model and then switch between them based on the value of some variables in your workspace.

How does that work?

To begin, drag a Model block from the Simulink Library Browser and double-click on it. Instead of entering the name of one model you want to reference, click the Enable Variants button.

The Model Reference dialog window will change to enable you to define Variant choices

For each variant specified in the Model Reference block, create a Simulink.Variant object. The Simulink.Variant object specifies a Boolean expression called a variant condition. When running the model, the Model Reference block evaluates the variant conditions of the Simulink.Variant objects to determine which model is active.

For the example described above, define variants for all three options:

Eng4cGAS = Simulink.Variant('(cyl==4) && (fuel==1)');
Eng6cGAS = Simulink.Variant('(cyl==6) && (fuel==1)');
Eng4cDIESEL = Simulink.Variant('(cyl==4) && (fuel==2)');

Define variables in the base workspace needed by the variant conditions:

fuel = 1;
cyl = 4;

In the parent model, the model block displays the name of the active model and an additional icon .

Now it’s your turn!

Are you using the model reference variants? Leave a comment here.

16:18 UTC | Posted in Model Reference, What's new? | Permalink | 13 Comments »

You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

13 Responses to “Model Reference Variants”

1. Joachim Schlosser replied on September 4th, 2010 at 06:18 UTC :
   

   And it’s becoming even better: Since last Friday, you have about the same possibilities using subsystems in one model, with the so-called brand new “subsystem variants” functionality. Now, users, get rid off configurable subsystems!

2. wei replied on September 5th, 2010 at 00:27 UTC :
   

   @Joachim, A future entry on different apporaches on variant management would be nice.

3. Parasar Kodati replied on September 8th, 2010 at 15:14 UTC :
   

   Here is a video on using Model Variants together with Variant Subsystems for managing variants at different component levels:

   http://www.mathworks.com/videos/simulink/variant_subsystems.html

4. Paul J. replied on September 12th, 2010 at 15:46 UTC :
   

   One of my issues with configurable subsystems is that changing the active subsystem caused code to be regenerated and the model recompiled, which can be a little slow when using the accelerator. I thought that using Variants was supposed to solve this problem, but now I’m not so sure. After watching the video, it appears that the active subsystem is selected at compile time via the preprocessor, not during runtime as I would have expected. If I change the active variant and hit the run button, will the simulation start running relatively quickly, or will I have to wait for things to recompile (I realize new code would not be generated)? How does the behavior change if “Generate preprocessor conditionals” is not checked?

5. wei replied on September 13th, 2010 at 01:01 UTC :
   

   @Parasar, In previous releases there is nice feature called See highlights and screen shots (a link to a pdf file) which is quite helpful. Will 2010b keep this tradition?

6. Muhammad Hasan replied on September 13th, 2010 at 08:47 UTC :
   

   Hi , I am writing you to get some proper help on simulating electric vehicle for electronic stability control. How can I have an example model for this?

7. Guy replied on September 13th, 2010 at 13:18 UTC :
   

   Hi Paul J,

   Let’s says your main model contains 1 Model Reference block which can possibly refer 2 variants: “Ref1.mdl” and “Ref2.mdl” and the simulation mode for the Model Reference block is set to “Accelerator”

   The first time you run each configuration, a MEX-file will be created. For example on Windows 32-bits you will see “Ref1_msf.mexw32″ and “Ref2_msf.mexw32″ in your current folder.

   The next times you will run the main model, in normal or accelerator mode, the referenced models will not be rebuilt if they did not change.

   I hope this answers your question.

   Guy

8. Paul J. replied on September 13th, 2010 at 21:55 UTC :
   

   Guy,

   I understand that the references will not have to be rebuilt when the active variant changes. But my question is: does the code for the top model have to be recompiled if the active variant changes? Also, does the answer change for a model variant vs. a subsystem variant? If the active variant implemented in the top model is controlled via the preprocessor, then I don’t see how the recompilation can be avoided. When I first read about model variants, I assumed the IF statement that selected the active model was in the executable code (not done by the preprocessor), but now it appears otherwise based on the link in Parasar’s message, at least for subsystem variants. Does the “Generate preprocesor conditionals” option factor into any of this if all I’m interested in is running simulations in the Simulink environment?

   Thanks,
   Paul

9. Guy replied on September 14th, 2010 at 12:32 UTC :
   

   Hi Paul,

   You are right. Only the active variant is built and present in the executable, so you cannot change it at run-time. This is the case for both subsystem variants and model reference variants.

   To include 2 versions of a subsystem in the executable, both need to be in the model. Typically you arrange your two subsystems in parallel and choose the active one using either a Switch or If Action Subsystems.

   I hope this answers.

   Guy

10. Paul J. replied on September 14th, 2010 at 16:54 UTC :
    

    Guy,

    Yes, that answers the question. Can you shed any light as to why the selection of the active variant is note done in the executable code? In other words, why doesn’t the generated code implement something like the Switch or If Action for me? That way I have a clean diagram that’s easier to understand and maintain and things would be more efficient when the active variant changes since no code would have to be recompiled.

    Thanks,
    Paul

11. Parasar Kodati replied on September 17th, 2010 at 18:35 UTC :
    

    @Wei: Yes. The tradition continues for R2010b…here is the link to PDF file you were referring to:

    http://www.mathworks.com/products/new_products/Simulink_R2010b.pdf

    The link is also up on the Simulink What’s New page:
    http://www.mathworks.com/products/simulink/whatsnew.html

    Thanks
    Parasar

12. wei replied on September 21st, 2010 at 02:09 UTC :
    

    @Parasar, Thank you for letting me know. I also noticed that Stateflow added one now. Do you think that rtwec will do so as well?

    Here is a suggestion. Right now I have to click 3 times to navigate from one product’s Overview to another: (1) Products and Services, (2) Product List, (3) Link to chosen product. It could be faster if Overview has a product pull-down list which leads to other product’s Overview page. Better yet if one can open multiple overviews once.

    Hopefully Doucmentation Center team has multiple products in its mind.

13. Mark Chadwick replied on December 8th, 2010 at 13:56 UTC :
    

    Another question about model variants…

    I am current trying to create a small pallete/library of model variant blocks which I can use in my model. One idea is to have one model reference block to represent a sensor. This block points to several sensor variant models (y=mx+c,lookup, equation, polynomial, etc). I want to define a variable structure in the workspace but passed to the model reference block in a mask and use values from that to drive which model variant is chosen. e.g.

    workspace variables:
    PX1.calibrationData=[1 2]; %y=mx+c
    PX1.calibrationType=’straight line’;
    PX1.calibrationLimits=[0 10]; %limits for sensor operation
    PX1.sensorType=’Pressure Sensor’;

    TX2.calibrationData=[1 2 3 4 5;10 20 30 40 50]; %lookup
    TX2.calibrationType=’lookup’;
    TX2.calibrationLimits=[1 5]; %limits for sensor operation
    TX2.sensorType=’Temperature Sensor’;

    PX1 is then passed into the model reference through the mask parameter “PX1″ and the variant chosen is driven by the string PX1.calibrationType. Since I want to use one model reference block for several sensors, there will be many other instants of the model reference block and sensor structures defined in the workspace, TX1, FM2, etc and each of these will be placed in the mask of their model reference block. Each of their calibrationType properties should again drive which variant is activated for that sensor type.

    Any idea?
    Cheers,
    Mark

Leave a Reply

<pre class="code">
a = magic(3);
sum(a)
</pre>

These postings are the author's and don't necessarily represent the opinions of The MathWorks.