Choose Data Configuration Approach

When you generate code from a model, the code includes design data such as signals, states, and parameters, which your application code can read from and write to. When deciding how you want this data represented in the generated code, consider:

What types of data elements do I want to use in my model?
Where do I want to store the data?
What are my code generation objectives?
How can I configure the data to meet my code generation objectives?

The answers to these questions depend on your model architecture (standalone model, standalone hierarchy of referenced models, or a system of components), your application type (reentrant or single-instance), and whether you are integrating your code with existing external code.

Data Element Categories

The possible data elements in your model fall under the data element types listed in this table.

Data Element Type	Description
Inports	Root-level input ports of a model, such as Inport and Bus Element In blocks.
Outports	Root-level output ports of a model, such as Outport and Bus Element Out blocks.
Model-scoped parameters	Model parameter arguments — Variables in the model workspace that you configure as model arguments. These parameters are exposed at the model block to enable the parent model to provide different values for each model instance. Model parameters — Parameters that are defined in the model workspace. Unlike model arguments, these parameters are shared by each instance of the model.
External parameters	Parameters that you define as objects in the base workspace or in a data dictionary. Multiple models in an application can use these parameters.
Data stores	Internal data (local data stores) — Data stores that are accessible from anywhere in a subsystem hierarchy that is at or below the level at which you define the data store. Defined graphically in a model by including a Data Store Memory block or by creating a signal object in the model workspace. Global data stores — Data stores that are defined by a signal object in the base workspace or in a data dictionary. Multiple models in an application can use these data stores. Shared local data stores — Data Store Memory blocks that have the block parameter Share across model instances set. These data stores are accessible only in the system where the Data Store Memory block is located. The data store value is shared across instances of the model.
Internal data	Local data, such as internal signals and block states. Includes local data stores.
Constants	Constant parameters and constant-value block output in a model.

The code configuration options available for your data are dependent on the category of data that you are configuring. Where you store the data determines if you configure it by using a data object or by using a code mapping that is saved with the model.

Where to Store Data Elements Used by Your Model

Where you store data for your model can depend on the type of model architecture that you are using and your modeling goals:

MATLAB^® base workspace — Used for the temporary storage of data while experimenting with modeling techniques.
Model workspace — Used to permanently store data that is local to a single model. Because the data is stored with the model, using this workspace can improve model portability. The model workspace is predominantly used to store parameters, arguments, and numeric variables. These elements are not typically stored in the model workspace:
- Signal objects — You cannot configure a signal object in the model workspace for code generation. You do not need to define a signal object to configure a signal for code generation.
- Data type objects.
Simulink^® data dictionary — Used to permanently store global data, data types, and data that is shared between models.

For more information, see Determine Where to Store Variables and Objects for Simulink Models.

When to Configure a Data Element for Code Generation

Whether you customize the generation of your data for code generation depends on your objectives for the generated code. If you choose not to configure customizations, the code generator determines whether to eliminate or change the representation of the data in generated code for optimization purposes.

There are many reasons you might choose to configure a data item. Configuring data prevents optimizations that might eliminate the data item from the generated code and enables you to configure how the generated code stores and defines the data item. For example, if you configure a data item, you can:

Tune parameters.
Monitor signals and states during execution.
Configure data placement in memory.
Exchange data with external code.
Improve readability and traceability of generated code.

Configure a Data Element for Code Generation

To configure your data for code generation, apply a storage class. A storage class is a code generation setting that enables you to control the appearance and placement of a data element in the generated code and prevents optimizations that might eliminate storage for that data element. You can use storage classes available with Simulink Coder™ and Embedded Coder^®. If you have special requirements that are not met by these storage classes and you are generating code for an ERT-based target, you can define and use a new storage class. For more information on storage classes and storage class properties, see Choose Storage Class for Controlling Data Representation in Generated Code.

When to Configure Data by Using a Data Object

For most model-owned data, you can map a storage class directly to a data item by using the Code Mappings editor or code mapping API. You must configure some data that your model uses for code generation by using a data object, including:

Parameters — Includes parameters in the base workspace, model workspace, or data dictionary. Configure parameters by using a Simulink.Parameter object.
Global data stores — Configure by using a signal object.

Before configuring numeric variables for code generation, you must convert them to Simulink.Parameter objects.

Configure Model-Owned Data by Using Code Mapping

Model-owned data consists of outport blocks, signal lines, block states, data stores, and parameter objects in the model workspace. For this data, you can map a storage class to a data element in the coder app by using the Code Mappings editor or by using the code mappings API. For convenience, you can also configure external data objects in the Code Mappings editor, though for external data objects, the storage class is stored on the data object and not in the model. To see these objects, in the editor, click the Refresh link to the right of the category name.

To configure model-owned data, you first configure default code generation settings for categories of data elements. Using a default mapping saves time and reduces the risk of introducing errors in the code, especially when your model contains a significant number of elements in a particular category.

In the C Code tab, select Code Interface > Default Code Mappings.
On the Data Defaults tab, select a data category, then select a default storage class for that category. If you do not specify a storage class for a category, the Default storage class applies. In this case, the code generator places the code for the category of data elements in standard structures. Other storage class options include:
- Relevant built-in storage classes, such as ExportedGlobal.
- Relevant storage classes in an available package, such as ImportFromFile (requires Embedded Coder).
- Storage classes defined in an Embedded Coder Dictionary (requires Embedded Coder). For more information on available storage classes, see Choose Storage Class for Controlling Data Representation in Generated Code.
In the Property Inspector, configure the properties for that storage class. (For example, header and definition files).

For more information, see C Data Code Interface Configuration for Model Interface Elements.

For certain categories of data, including inports, outports, data stores, and block states, the default mapping is likely the only configuration you need to perform. But for data elements such as parameters and internal signals, you might need to specify an individual mapping to prevent the data from being optimized away. To apply a storage class to an individual data element:

In the Code Mappings editor, find the data element on its corresponding category tab (for example, to configure an individual parameter, select the Parameters tab).
Select a storage class for the data element. To apply the default configuration, select the storage class Model default.
In the Property Inspector, configure the properties for that storage class. (For example, header and definition files).

For more information, see C Data Code Interface Configuration for Model Interface Elements.

Configure External Data

Configure external data objects for code generation by using the Code Mappings editor or the Model Explorer. Select a data object in the Contents pane. Then, in the Dialog pane, on the Code Generation tab, select a storage class and set properties for that storage class. For convenience, you can also configure external data objects in the Code Mappings editor. To view and configure these objects, in the editor, click the Refresh link to the right of the category name.

You can configure external data objects programmatically. For example, to configure a Simulink.Parameter object for code generation by applying the storage class ExportedGlobal, you can use code similar to:

P = Simulink.Parameter;
P.Value = 5;
P.DataType = 'int32';
P.CoderInfo.StorageClass = 'ExportedGlobal';

Load Storage Class Packages into Embedded Coder Dictionary

To apply a storage class from a storage class package other than Simulink (such as a package that you create):

Open the Embedded Coder app.
Open the Embedded Coder Dictionary. On the C Code tab, select Code Interface > Embedded Coder Dictionary.
In the Embedded Coder Dictionary, click Storage Class.
Below the Storage Classes table, click Manage Packages.
In the Manage Packages dialog box, select a package. If the package of interest is not in the list, click Refresh. Then, select your package.
Click Load.
Close the Embedded Coder Dictionary.
Use the Code Mappings editor or code mappings API to configure the model's interface elements.

For more information, see Embedded Coder Dictionary, Code Mappings Editor – C, and coder.mapping.api.CodeMapping.

To apply the storage class by using a data object (required parameters), instead of creating a Simulink.Signal or Simulink.Parameter object, create a myPackage.Signal or myPackage.Parameter object. To create data objects from your package, see Create Data Objects from Another Data Class Package. For an example that shows how to create and apply your own storage class, see Create and Apply Storage Class Defined in User-Defined Package.