Determine Where to Store Variables and Objects for Simulink Models

Simulink^® data are objects and variables that you create in a workspace such as the base workspace or a data dictionary. Simulink data includes:

Numeric values for block parameters, such as Simulink.Parameter objects and MATLAB^® variables
Signals, such as Simulink.Signal objects
Value types defined by Simulink.ValueType 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 for 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, and you can use Outport blocks, To Workspace blocks, and logged signals to export output data. For more information about loading, generating, and storing simulation data, see Comparison of Signal Loading Techniques and Save Simulation Data.
Design data is the set of variables and data objects that you use to specify block parameters and signal characteristics in a model and its generated code. For example, design data includes numeric MATLAB variables, value type objects, and parameter and signal data objects.
You can store design data in the base workspace, model workspaces, MAT files, or the Design Data section of a data dictionary. To permanently store local design data with a model, use model workspaces. For sharing design data between models, use MAT files, data dictionaries, or the base workspace. MAT files and data dictionaries permanently store the data. You can store data in a MAT file and link it to the model. By using data dictionaries, you can 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 create a MATLAB script that can regenerate the data.
Architectural data is composed of model interfaces, such as port interfaces, data types, and system wide constants and their platform properties that are shared across Simulink and architecture models.
You can store architectural data for your model in the Architectural Data section of a Simulink data dictionary. To add, edit, or remove this data you can use the Architectural Data Editor, see Store Shared Data in Architectural Data Section for more information. You can also use the object API Simulink.dictionary.ArchitecturalData, see Store Data in Architectural Data Section Programmatically for more information. To move design data to the Architectural Data section right-click the design data object in Model Explorer and select Treat As Architectural Data from the context menu.
Configurations
- 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 configuration 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.
- Variant configuration objects store information about variant configurations, active and default variant settings, and definitions of the control variable associated with each configuration. You can use Variant Manager to create and edit variant configuration objects in data dictionaries or the base workspace. For more information, see Variant Manager for Simulink.

Types of Data Storage

Types of data storage include:

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 MATLAB file — Use MAT file to permanently store global data and share data between models. (since R2024b)
A data dictionary — Use data dictionaries to permanently store global data, share data between models, and track changes made to data.

The table compares the characteristics of each storage location.

Data Storage Type	File Storage	Model-Data Separation	Sync with Source File on Disk	Different Data for Different Models	Visibility
Base Workspace	MATLAB code (`.m`) MATLAB file (`.mat`)	Yes	No	No	Global
Model Workspace	Model file (`.slx`), `.m`, or `.mat`	Optional	Yes (synchronization at model initialization)	Yes	Local
MATLAB file (since R2024b)	MAT file (`.mat`)	Yes	Yes	Yes	Shared
Data Dictionary	Simulink Data Dictionary file (`.sldd`)	Yes	Yes	Yes	Shared

You can associate a MAT file or a data dictionary to models to share data between them, depending on your needs and preferences. While MAT files are easy to use, data dictionaries provide:

Change tracking
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 by default. To encapsulate your model, you can choose to disable access to the base workspace (see Continue to Use Shared Data 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 permanently store base workspace data before you end a MATLAB session, 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 linking MAT file to your model as external data source to permanently store data. Alternatively, you can also use model workspace or data dictionary as your project scales up.

Local Data: Model Workspace

Each model has its own workspace for storing variable values. Variables in a model workspace are visible only in the scope of the model. 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.

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.

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: MATLAB file

Since R2024b

You can store data in a MAT file and link it to your model. Linking a MAT file directly to the model permanently stores data with the model. You can associate the MAT file to multiple models to share data between them. You can also link multiple MAT files to a single model.

Use a MAT file to store data that you want to share between a specific set of models. 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 the same time.
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.ValueType and Simulink.Bus objects that you use to define interfaces of model components, such as referenced models.

Use the Model Explorer to view and edit MAT file data associated with the model. Alternatively, use the command prompt or scripts in conjunction with the external data source programmatic interface.

For more information on linking a MAT file to the model, see Link MAT File to Model as External Data Source.

Global and Shared Data: Data Dictionary

A data dictionary is a standalone file that permanently stores data. Similar to a header file, a data dictionary provides a location outside of the model that can store and share data definitions. 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 the base workspace access from either the model or the data dictionary. See Continue to Use Shared Data in the Base Workspace.

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 the same time.
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.ValueType and Simulink.Bus objects that you use to define interfaces of model components, such as 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.

To use the data defined in a data dictionary, you must link the data dictionary to your model. You can use this association to share data between a specific set of models.

When you use data dictionaries, you can partition the data by storing it in additional referenced dictionaries. Because data dictionaries in a hierarchy share the same namespace, each entry in a data dictionary hierarchy must use a unique name. Multiple definitions of the same symbol are allowed only if their class type and property values are the same. For more information, see Data Consistency in Model Hierarchy.

You can also use data dictionaries to associate data with a custom block library. When you define data objects, such as bus and enumeration types, in a data dictionary linked to a library, users of the library automatically gain access to the data types contained in the data dictionary when they drag a block from the library into their model. For more information, see Link Data Dictionary to Custom Libraries.

Use the Model Explorer to edit dictionary data. Alternatively, use the command prompt or scripts in conjunction with the data dictionary programmatic interface.

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

Custom External File Sources

If you use a Simulink.SimulationInput object to simulate a model using different sets of variables, you can store these variable sets in custom external file sources. To load data from an external file:

Write, test, and register a file adapter for your custom file format (for example, .xlsx or XML). For more information, see Create External File Adapter for Loading Variables into Simulink.SimulationInput Object.
Use your custom file adapter to load variables for simulation by using loadVariablesFromExternalSource.

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, a MAT file, or a data dictionary. For more information about storage classes for signals and states, see C Data Code Interface Configuration for Model Interface 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, a MAT file, 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).
If you store an AUTOSAR.Parameter object in a model workspace, the code generator ignores the storage class that you specify for the object.

Managing Data Storage for Your Project

For small projects, the base workspace can be a convenient way to store design data. In particular, the base workspace works well for:

Informal workflows
Rapid prototyping
Quick parameter tuning
Single-developer projects

The base workspace provides ease of access and global visibility. However, data storage in the base workspace is temporary and to preserve that data between sessions you must save it to a script or MAT file.

Other options for small projects include:

Model workspace — Improves standalone model portability by providing permanent design data storage within the model.
MATLAB file and data dictionary — Provides permanent design data storage outside the model.

You can use the model workspace, link MAT file and data dictionary simultaneously to the model with the base workspace. Doing so provides a bridge for migrating your data from base workspace as your project grows in complexity.

While the base workspace is convenient for small, single-user projects and rapid prototyping, this solution does not scale well for more complex projects that require encapsulation, distributed development, and scoped data. Complex projects involve a hierarchy of referenced models or subsystem references. Regardless of the type of models your hierarchy contains, you can distribute your design data based on the intended visibility of the data. In order to build scalable systems, distribute design data with the goal of keeping data visibility as local as possible.

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

Modeling Scenario	Scenario Description	Storage 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 data in a MAT file and link it as an external data source. Use a data dictionary to store data that you cannot store in the MAT file.
A system decomposed into multiple models	A large system is decomposed into multiple models in a hierarchy of referenced models, where data definitions are shared between parent and child models.	Store local model data in each model workspace. Store system-wide definitions, such as common types, parameters, and constants, in a MAT file and link it as an external data source in all the models. Alternatively, use data dictionary that is referenced by all of the models (either directly or through another data dictionary). 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 data dictionary.
System of components	Reusable components, such as libraries or model references, which are designed for high reuse across teams or organizations.	Store local model data in model workspaces. Parameterize the library block or model block by using mask parameters or model arguments. For each reusable component, store the data types required for the interfaces of that component in a separate data dictionary and associate the model or library to that data dictionary.

Data Consistency in Model Hierarchy

Data dictionaries in a model hierarchy can contain multiple definitions of the same symbol. For a model to update, duplicate symbol definitions visible to a single model (coming from the base workspace, connected Simulink data dictionaries, or visible library dictionaries) must be consistent. Symbol definitions are consistent when their symbol names, class types, and property values are the same.

For example, model M1 can see definitions of variable K in two storage locations. In this case, the definitions of K must be consistent.

Model M1 with a definition of k in two storage locations

If definitions for the same symbol are consistent, you can simulate the model in the normal, accelerator, and rapid accelerator modes, and generate code for the model. Duplicate symbols defined in the interface dictionary or in a data dictionary linked to an architecture model are not supported.

Note

When a model can see multiple consistent definitions of a symbol, only one of the definitions is displayed by the Model Data Editor and returned by Simulink.findVars. It is this definition that is used by the model during simulation.

As long as duplicate symbols visible to a single model are consistent, the current model and the models below it in the model hierarchy can use symbols with the same name but different values by setting the model property EnforceDataConsistency to off. In the Model Properties dialog box, on the External Data tab, clear the Enforce consistent data definitions across referenced models check box. Alternatively, you can set the parameter to off programmatically by using the set_param function.

set_param(bdroot,'EnforceDataConsistency','off');

For example, models M2 and M3 each have a single definition of variable K, but there are multiple definitions of K in the model hierarchy. By turning data consistency checking off in model M1, models M2 and M3 can maintain different values for variable K.

A model hierarchy. Model M1 has 2 submodels, M2 and M3, each with a different definition of variable K.

You might turn data consistency checking off to integrate components from different vendors that use similar names for variables. You might leave data consistency checking on to integrate components within an organization to ensure the components operate under the same conditions.

By default, the EnforceDataConsistency parameter is set to on. You cannot set EnforceDataConsistency to on for a model unless each of its referenced models and their variants also have EnforceDataConsistency set to on.

Setting EnforceDataConsistency to off results in an error for:

Code generation
Software-in-the-loop (SIL) and processor-in-the-loop (PIL) simulations
Simulation of a protected model

When creating a model reference simulation target (for accelerator and rapid acceleration modes during simulation), if there are multiple consistent definitions of a symbol, Simulink generates unique identifiers for the symbol by concatenating the data dictionary name with the symbol name. If this generated identifier exceeds the maximum allowed length of 64 characters, Simulink enforces data consistency regardless of the EnforceDataConsistency setting.