Model Workspaces

Each model has its own workspace for storing variable values. When the model is loaded, the model workspace is initialized from a data source that can be a model file, a MATLAB^® file, or MATLAB code stored in the model file. You can interactively reload and save these data sources. For more information, see Specify Source for Data in Model Workspace.

Variables in a model workspace are visible only in the scope of the model. If both the MATLAB workspace and a model workspace define a variable of the same name, and the variable does not appear in any intervening masked subsystem or model workspaces, the Simulink^® software uses the value of the variable in the model workspace. A model's workspace effectively provides it with its own name space, allowing you to create variables for the model without risk of conflict with other models.

Note

When resolving references to variables used in a referenced model, the variables of the referenced model are resolved as if the parent model did not exist. For example, suppose a referenced model references a variable that is defined in both the parent model's workspace and in the MATLAB workspace but not in the referenced model's workspace. In this case, the MATLAB workspace is used.

To modify variables in a model workspace, see Change Model Workspace Data.

Benefits of Using Model Workspace

Use a model workspace to store data that you use only in the associated model. This data can include:

• Model parameters, such as numeric variables that you use to specify block parameter values

• Data objects, such as Simulink.Parameter objects, that you use to control parameter characteristics

• Model arguments

You can improve model portability and establish data ownership by storing the data in the model workspace. In this case, the model file permanently stores the data.

In a model reference hierarchy, each model workspace acts as a unique namespace. Therefore, you can use the same variable name in multiple model workspaces. You can then assign different values for each model.

Troubleshooting Memory Issues

When you use a workspace variable as a block parameter, Simulink creates a copy of the variable during the compilation phase of the simulation and stores the variable in memory. This can cause your system to run out of memory during simulation, or in the process of generating code. Your system might run out of memory if you have:

• Large models with many parameters

• Models with parameters that have a large number of elements

This issue does not affect the amount of memory that is used to represent parameters in generated code.

Model Workspace Limitations

• To store a signal object in a model workspace, set the storage class of the object to Auto. Signal objects include Simulink.Signal and subclasses that you create.

  If you specify a storage class other than Auto, you must store signal objects in the base workspace or a data dictionary to ensure the objects are unique within the global Simulink context and accessible to all models.

• When you store MATLAB variables and parameter objects (such as Simulink.Parameter) in a model workspace, some tunability limitations apply. See Tunability Considerations and Limitations for Other Modeling Goals. In addition, if you store an AUTOSAR.Parameter object in a model workspace, the code generator ignores the storage class that you specify for the object.

• When you store Simulink.NumericType objects you cannot use the object as a data type alias. You must set the IsAlias property to false.

• Other objects that cannot be stored in a model workspace include:

  • Simulink.Bus

  • Simulink.DataType

  • Simulink.data.DataConnection