Guy on Simulink

Simulink & Model-Based Design

Where Does That Variable Come From?

Most Simulink models use workspace variable to define the important parameters.  For example, setting the gain value to K and then defining K in the workspace.  I wrote about initializing these parameters in the base workspace in a recent post.  Have you ever noticed that there are many sources for these parameters?  The value of K might be in the base workspace, or it could be in the model workspace.  The source of K could even be in a mask.

Simulink determines the value of a variable by searching in the workspaces above the block that uses the variable.  Starting from the block, it searches each mask workspace up the subsystem hierarchy until it reaches the root of the model.  Simulink searches the model workspace and the base workspace last, respectively.  This process is hierarchical symbol resolution, and in this post, I will demonstrate these rules that determine how Simulink resolves the value of a variable.

An Example Model

To illustrate the concepts of hierarchical symbol resolution, let’s use a simple model (Download here).  This model consists of nothing but subsystems, constant blocks and displays.  The constant blocks refer to variables in different workspaces and get their value based on where they are in the hierarchy.  Starting at the root of the model, we find the variables k and m.

Variable Resolution Simulink model.

Look in the Workspace above the Block

I think of the model workspace as being at the root of the model.  The model workspace is the first place to search for k and m.  I use the Model Explorer to see the contents of the model workspace.

Model explorer showing the model workspace.

We have found k, but m is not in the model workspace.  The next workspace up in the hierarchy is the base workspace.  The model explorer conveniently shows a tree that reflects the model hierarchy.

Model explorer showing the base workspace.

Mask Workspaces

Masked subsystems introduce mask workspaces in the model hierarchy.  If the block is in a masked subsystem, it first evaluates in the mask workspace then works its way up through the hierarchy until it reaches the root of the model.  Here is the Top subsystem.

Top subsystem, top subsystem mask and the contents of the system.

The mask dialog initializes the variable m with a value of 3000.  The variable k is also appears at this level of the model, but resolves to the variable defined at the model workspace level.

Subsystems Inherit Variables from Their Context

Because of hierarchical symbol resolution, subsystems inherit variables from their context.  The Bottom subsystem refers to k, which comes from its mask.  It also refers to m, which is resolved in the Top Mask.  If the Bottom subsystem were at the root of the model, m would resolve to the base workspace.

Bottom subsystem, bottom subsystem mask and the contents of the system.

This behavior can make the same library blocks behave differently depending on their parent system.  For example, a pendulum subsystem may inherit the acceleration due to gravity (g) from its parent system.  These parent system may define variables for different environments.

A subsystem hierarchy that would allow inheritance of the variable g based on context.

Controlling Hierarchical Resolution

You can control the resolution of variables in your subsystem by setting the Permit hierarchical resolution parameter in the subsystem parameters (right click on the subsystem and select Subsystem parameters…).

Subsystem parameters, Permit hierarchical resolution.

The default setting is All and gives you the behavior described above.  If you don’t want variables to resolve to symbols defined in the hierarchy above your subsystem you can change this to None.   The ExplicitOnly setting controls resolution of signal and state names by only resolving objects that have been set to resolve explicitly.

What about Model Reference Hierarchy?

Hierarchical symbol resolution stops when it gets to the root of the model.  Model reference hierarchy is not considered as part of hierarchical symbol resolution.  Any model must be able to define itself stand alone, or as part of a larger model reference hierarchy.  It is possible to pass variables down into a model workspace through the model reference arguments.  For more on that, see documentation about using model arguments.

Now it’s your turn

If you program in M-code than you might see discussion as similar to the way variables are resolved in nested functions of an M-file.  Do you take advantage of hierarchical symbol resolution?  Leave a comment here and tell us how.

|

Comments

To leave a comment, please click here to sign in to your MathWorks Account or create a new one.