This is machine translation

Translated by
Mouseover text to see original. Click the button below to return to the English version of the page.

Model Reference Variants13

Posted by Seth Popinchalk,

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)');


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 .

UPDATE - 10/15/2013: New capabilities starting in R2013b.

Joachim Schlosser replied on : 1 of 13

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!

wei replied on : 2 of 13

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

Paul J. replied on : 3 of 13

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?

wei replied on : 4 of 13

@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?

Muhammad Hasan replied on : 5 of 13

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?

Guy replied on : 6 of 13

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.

Guy

Paul J. replied on : 7 of 13

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

Guy replied on : 8 of 13

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.

Guy

Paul J. replied on : 9 of 13

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

wei replied on : 11 of 13

@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.

Mark Chadwick replied on : 12 of 13

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

Prabhakaran replied on : 13 of 13

Is it possible to edit the Variant choices of the Model Reference block programatically? (i.e. Using set_param())