When is subsystem reference a better choice than model reference?

I am trying to understand the difference between "model reference" and "subsystem reference". I came across this documentation page, but no matter how many use-cases I reviewed, I never seem to end up with a "subsystem reference". From the flow chart shown in that page, the only way conclude with "subsystem reference" is when the block does not have a defined interface, or is not re-used or does not change. These are the antithesis of arguments for any creating any type of subsystems. Can someone comment on practical situations when a "subsystem reference" will be useful over "model reference"? Are there computational costs associated with "model reference"? I am inclined to believe that in practical cases in the industry, "subsystem references" are rarely used.

Answer 1

[Jonas]

Subsystem References is new functionality to Simulink, it is only supported since R2019b. So industry will only slowly evolve to using the functionality.

I will try to explain use-cases for using Subsystem Reference, and contrast it with Model Reference. Both are saved into their own .slx file, and are referenced by a parent model. The difference is that with Model Reference, the signal interfaces are fixed, such as data types and signal dimensions. With a Subsystem Reference, these interfaces do not need to be fixed. Look at this documentation page. You can use a Subsystem Reference in multiple instances where one instance receives a scalar while another instance receives a vector signal. This is similar to using a library block: the same library block can be used for different instances with different signal dimensions or data types. A Model Reference only accepts signals of a fixed data type and dimensions.

Besides this, a Model Reference can have its own Configuration Parameters and Model Workspace, while a Subsystem does not have it and inherits this from the parent model.

I would say that a Subsystem Reference is more closely related to a library subsystem, with the advantage that:

• The subsystem is inside its own .slx file, which can be versioned through GIT. This means a different team member can develop this subsystem reference inside the .slx file without disturbing other systems. If you do this with a library, the whole library will be affected.
• A subsystem reference can be tested and developed inside a harness.

In a model-based design project, I would say typically a Model Reference is used for:

• A controller
• A plant model

which are then referenced in harnesses for:

• Code generation
• Real-time prototyping
• Simulation

while Subsystem References are used for:

• Speed controller subsystem inside the controller
• Position estimator subsystem inside the controller
• ...
• Induction motor model inside the plant model
• Synchronous motor model inside the plant model
• ...

This link also provides a comparison overview.

[svanimisetti]

@Jonas - Thank you very much for a detailed response. Since this is a new feature, I think applications will gradually come. One issue I struggled with in the past was having to re-set the model reference properies to match the main model. Based on what you mentioned, it seems that subsystem references are more convenient and suitable for codegen using distributed models.

Can I mix and match model / subsystem references? More precisely, can I nest a subsystem reference within a model reference, which is in turn used within a normal simulink model?

[Jonas]

Yes, you can mix and match both.

Regarding your comment for the model reference properties, I reckon you mean the Configuration Parameters. When you have for example a controller in a dedicated .slx model file, which you add inside a simulation harness using a Model Reference, you will have grt.tlc for simulations. Then you have another harness for code generation which references the same model, but then you need ert.tlc The .tlc file of the Model Reference model indeed needs to change according to the harness it is used in. You can solve this as follows.

Create a Data Dictionary with two Configuration Parameter objects: one for simulations (grt.tlc) and another for code generation (ert.tlc). Then, create a third object which is a Configuration Parameter Reference object. Let this reference object point to one of the two beforementioned configuration parameter objects.

Now, make sure this data dictionary is referenced in the data dictionaries linked to the simulation, code generation and controller models (such that these three objects are known to all models). For these three models, set their configuration parameter also as a reference configuration parameter, which points to the very first configuration parameter reference. Now, by changing the first configuration parameter reference to point to the grt.tlc configuration parameter object, you can run a simulation, by changing the reference to the ert.tlc object, you can do code generation. Because the configuration parameters of all models point to one single configuration parameter reference object, you change the configuration parameters in one go.

If this is unclear I can explain in more detail, or try to create a sample model.

[Jonas]

I explained it once a bit differently with some screenshots in this question: https://nl.mathworks.com/matlabcentral/answers/615878-using-model-reference-with-different-system-target-files?s_tid=srchtitle

Maybe it helps.

[svanimisetti]

Thanks @Jonas - This is really great information!

[Walter Roberson]

@Jonas -- very nice information!

[wu lei]

@Jonasthank you very much for your help！