Managing High Levels of Variation in a Simulink Library

2 Ansichten (letzte 30 Tage)
I am a blockset author similar the authors of "Aerospace Blockset" and "Powertrain Blockset." I build mathematical models of hydraulic pumps used in offroad vehicle models. The products I model have a high amount of configuration. One library contains one 1 subsystem at top level that represents a whole family of pumps. Possible combinations are something like 1e6 or more but only about 1e3-1e4 configurations are used in practice. Using a Simulink library seems the most appropriate way to maintain my mathematical models. With a library, it is general bad practice to use the base workspace because of conflicts with other copies of the library in a single Simulink model file. Variant Subsystems depend on the base workspace or a data dictionary usually. Libraries cannot use data dictionaries I have learned. Variant Subsystem requires configuration one of three ways:
  1. Variant object or Parameter object in the base workspace or data dictionary.
  2. Conditional expression that can be evaluated from variables in the base workspace.
  3. Or using the “OverrideUsingVariant” with set_param configure a Variant subsystem.
I do not want to use the first two ways because they require the base workspace or data dictionaries which I have already established I cannot use. Therefore option 3 is my only option. There is a problem that I ran into. You cannot configure nested variant subsystems except from above or at the top level variant subsystem. i.e. If you have 4 levels of variant subsystems nested, level 1 (or above) must configure level 2, 3, and 4. I would prefer to do the configuration of level 3 from level 2 because of the flexibility that allows. Configuring multiple levels from the top level makes changes have very broad reaching effects. When I must configure using OverrideusingVariant down 4 levels, any change to the name or location of the blocks between 1 and 4 breaks the chain of configuration at the top level. This is not desirable. This is painful.
  1. Is this an appropriate place to use a "configurable subsystem” instead of a Variant Subsystem?
  2. Thoughts or approaches to manage high levels of configuration in a library model?
I posted this question to Guy on Simulink too.
  1 Kommentar
Jason Nicholson
Jason Nicholson am 29 Mär. 2018
Answer to question 1: No, this is not a place the configurable subsystem. The configurable subsystem doesn't allow nesting of other configurable subsystems. So sad. :(

Melden Sie sich an, um zu kommentieren.

Akzeptierte Antwort

Jason Nicholson
Jason Nicholson am 30 Mär. 2018
Bearbeitet: Jason Nicholson am 30 Mär. 2018
Mathworks responded to my question. Here is the response.
________________
Answer to question 1:
Don't use the configurable subsystem. Mathworks would like to deprecate it. Variant Subsystems is an improvement. Mathworks is improving and refining the Variant Subsystem. It is not actively developing the Configurable Subsystem. Translation, you will get better support and response to questions related Variant Subsystem.
________________
Answer to Question 2:
To use nested Variant Subsystems, use set_param to set a parameter at the level 2 from level 1. Level 1 has a mask and is the top level of a Simulink library. When the level 1 mask is configured and the user clicks "Apply" or "Okay," the initialization for level 1 is executed. Use set_param in the level 1 initialization to set the value of a parameter at level 2. This causes Simulink to run the level 2 initialization script once the level 1 initialization script finishes. Thus, at the time the level 1 mask is configured, the level 2 Variant Subsystem is configured. Level 2 uses "OverrideUsingVariant" (as I said in option 3 of my question above) to configure itself.
If you try to set a variable in the level 1 initialization that is then referenced at level 2, this is not resolved until Simulink tries to run the model. Simulink does not allow configuring of the Variant Subsystem once the Simulink model is executed in the current version,2018a, or in previous versions. The Variant Subsystem must be configured before you execute the model. The tricky part is that you will only get a failure/error when you try to set an active variant at level 2 that is DIFFERENT than current active variant at level 2. For example, if option A is active at level 2, then if you try to run the model and option A is what you want (configured on the level 1 mask), then the model will run. If you try to switch to option B by configuring the level 1 mask and passing a variable, you will get an error when you try to run the model.
Mathworks provided me an example model. I will post here once they reply if it is okay to share it here.
  1 Kommentar
Jason Nicholson
Jason Nicholson am 30 Mär. 2018
Inspect the mask of each of the Variant Subsystems. You will find that set_param is used at "L1" Variant Subsystem to set the parameters at level 2 for the "A" and "B" Variant Subsystems.
Credit: Guy Rouleau is the original author of this model.

Melden Sie sich an, um zu kommentieren.

Weitere Antworten (0)

Kategorien

Mehr zu Component-Based Modeling finden Sie in Help Center und File Exchange

Produkte

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by