This is machine translation

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

Note: This page has been translated by MathWorks. Click here to see
To view all translated materials including this page, select Country from the country navigator on the bottom of this page.

Determine Where to Store Variables and Objects for Simulink Models

Model data are objects and variables that you create in workspaces such as the base workspace or a data dictionary. Model data include:

  • Numeric values for block parameters, such as Simulink.Parameter objects and MATLAB® variables

  • Signals, such as Simulink.Signal objects

  • Data types

  • Model configuration sets

  • Simulation input and output data

You can store, partition, and share model data in a location that is appropriate for your design. The storage locations that you choose can depend on:

  • Your modeling goals.

  • The model architecture (referenced models, subsystems, and other partitioning strategies) and component structure.

  • The types of data that you use.

Types of Data

  • Simulation data is the set of input data that you use to drive a simulation and the set of output data that a simulation generates. For example, you can use variables to store input data that a simulation acquires through Inport blocks. A simulation can export output data through, for example, Outport blocks, To Workspace blocks, and logged signals.

    You can store simulation data for your current MATLAB session in the base workspace. To permanently store this simulation data, save it in a MAT-file or script file. For more information about loading, generating, and storing simulation data, see Comparison of Signal Loading Techniques and Export Simulation Data.

  • Design data is the set of variables that you use to specify block parameters and signal characteristics in a model. For example, design data includes numeric MATLAB variables, parameter and signal data objects, data type objects, and bus objects.

    You can store design data in the base workspace, model workspaces, or the Design Data section of a data dictionary. To permanently store local design data with a model, use model workspaces. To share design data between models, use data dictionaries or the base workspace. Data dictionaries permanently store the data, and you can control the data scope to establish ownership, partition the data to ease readability and maintenance, and track changes. If you use the base workspace, to permanently store the data, you must save it in a MAT-file or script file.

  • Configuration sets are sets of model configuration parameters. By default, configuration sets reside in the model file, so you do not need to store the sets separately from the model. However, you cannot share these sets with other models.

    To share configuration sets between models, you must create Simulink.ConfigSet objects. Each object represents a standalone configuration set. You can store these objects in the base workspace or in the Configurations section of a data dictionary. If you use data dictionaries, you can define the scope of each configuration set, compare different configuration sets, and track changes. A data dictionary inherently partitions configuration sets from other kinds of data.

Store Data for Your Design

The table shows the techniques you can use to store, partition, and manage design data and configuration sets.

Modeling ScenarioScenario DescriptionStorage Locations and Techniques

Rapid prototyping and model experimentation

You want to create temporary data, such as variables to specify numeric block parameters, while you learn to use Simulink®.

You want to experiment with modeling techniques. You do not need to permanently store the data that you create.

Store data in the base workspace so you can quickly create and change the data.

Standalone model

You have a single model that does not depend on other systems for data. The model stands alone because it is not a piece of a larger system.

Store data in the model workspace to improve model portability. Use a data dictionary to store data that you cannot store in the model workspace.

Alternatively, store all of the model data in a data dictionary. If you use a dictionary, you can partition the data by using referenced dictionaries.

Standalone hierarchy of referenced models

You have a hierarchy of referenced models that does not depend on other systems for data. The hierarchy stands alone because it is not a piece of a larger system.

Store local model data in each model workspace.

Store data that the models share, such as bus objects and configuration sets, in a data dictionary. Link all of the models in the hierarchy to the dictionary.

For examples, see Migrate Model Reference Hierarchy to Use Dictionary and Using a Data Dictionary to Manage the Data for a Fuel Control System.

System of components

One or more teams maintain the components of a system of models. A component is a single model or a hierarchy of referenced models that represents a piece of a larger system.

Store local model data in model workspaces.

Store data that the models in a component share, such as bus objects and configuration sets, in a data dictionary. Link all of the models in the component to the dictionary.

Use additional referenced dictionaries to store data that the components share.

For an example, see Partition Data for Model Reference Hierarchy Using Data Dictionaries.

Storage Locations

Choose any of these locations to store data:

  • The MATLAB base workspace. Use the base workspace to store variables while you experiment with temporary models.

  • A model workspace. Use a model workspace to permanently store data that is local to a model.

  • A data dictionary. Use data dictionaries to permanently store global data, share data between models, and track changes made to data.

The chart shows the capabilities and advantages of each storage location.

CapabilityBase WorkspaceModel WorkspaceData Dictionary
Data-model linkageimplicitimplicit
Unified interface for defining data
Model-data dependency
Data entry comparison
Data entry persistence 
Options to remedy a missing variableAdditional options
Shared data 
Data grouping  
Change tracking for data entries  
Change tracking for configuration sets  
Data entry merging and reconciliation  
Storage and partitioning of auxiliary data  
Requirements linking  

For information about the way that models interact with workspaces and workspace variables, see Symbol Resolution.

Temporary Data: Base Workspace

Use the base workspace to temporarily store data:

  • While you learn to use Simulink

  • When you need to quickly create variables while experimenting with modeling techniques

  • When you do not need to store the data permanently

To create variables in the base workspace, you can use the MATLAB command prompt or the Model Explorer. All open models can use the data that you create in the base workspace.

If you use variables to specify numeric block parameters in the model, you can programmatically change the parameter values during simulation by using commands at the command prompt. To programmatically change the values of parameters that you store in the model workspace or data dictionaries, you must use the function interfaces for those storage locations.

To permanently store base workspace data before you end a MATLAB session, you can save the data in a MAT-file or a script file. During a later session, you can load the data from the file. However, if you make changes to the data in the base workspace, you must save the data to the file again. Consider instead using a model workspace or data dictionary to permanently store data.

Local Data: Model Workspace

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

  • Constant parameters, for example, numeric variables that you use to specify block parameter values.

  • Data objects, such as Simulink.Signal and Simulink.Parameter objects, that you use to control signal and parameter characteristics. However, signal objects in a model workspace can use only the Auto storage class. If you store an AUTOSAR.Parameter object in a model workspace, the code generator ignores the storage class that you specify for the object.

  • Simulink.NumericType objects that you use to specify data types. However, you cannot use the object as a data type alias. You must set the IsAlias property to false.

  • 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 a unique variable value for each model.

You can use the Model Explorer to manipulate model workspace data. Alternatively, you can use the command prompt or scripts in conjunction with the model workspace programmatic interface.

For more information about using model workspaces to store local data, see Model Workspaces.

Global and Shared Data: Data Dictionary

A data dictionary is a standalone file that permanently stores data. Use data dictionaries instead of the base workspace to partition data, track changes, control access, and share data. If you link a model to a data dictionary, you can still use variables in the base workspace by configuring access from either the model or the dictionary.

As you can with model workspaces, you can use data dictionaries to directly associate data with a model. You can use this association to scope the data and to establish ownership.

When you use dictionaries, you can partition the data by storing it in additional referenced dictionaries. However, each entry in a dictionary must use a unique name. You must manage each dictionary as a separate file.

Use a data dictionary to store data that multiple models or system components share. This data can include:

  • Numeric variables that multiple models use to specify block parameter values.

  • Simulink.AliasType and Simulink.NumericType objects that you use to specify data types in multiple models at once.

  • Data objects, including signal objects (such as Simulink.Signal) that use a storage class other than Auto. If you have a Simulink Coder™ license, these objects can represent signals and tunable parameters that appear as global variables in the generated code.

  • Simulink.Bus objects that you use to define signal interfaces between referenced models.

  • Simulink.ConfigSet objects that you use to maintain configuration parameter uniformity across multiple models.

  • Enumerated type definitions, which you store using Simulink.data.dictionary.EnumTypeDefinition objects.

You can use the Model Explorer to manipulate dictionary data. Alternatively, you can use the command prompt or scripts in conjunction with the data dictionary programmatic interface.

For basic information about data dictionaries, see What Is a Data Dictionary?.

Considerations for Code Generation

If you intend to generate C code from a model (Simulink Coder), take these considerations into account.

  • If you apply a storage class other than Auto to a signal object (such as Simulink.Signal) to control the appearance of a signal or block state in the generated code, you cannot store the object in a model workspace. Store the object in the base workspace or a data dictionary. For more information about storage classes for signals and states, see Apply Storage Classes to Individual Signal, State, and Parameter Data Elements (Simulink Coder).

  • If you apply a storage class other than Auto to a parameter object (such as Simulink.Parameter), you can store the object in the base workspace, a model workspace, or a data dictionary. However, if you store the object in a model workspace, the code generator assumes that the containing model owns the parameter. For more information, see Code Generation Impact of Storage Location for Parameter Objects (Simulink Coder).

Related Topics