Specify Application-Specific Signal Properties

When a signal represents a recurring type of value, you can define the signal properties once and reuse that specification for each signal that represents the same value type. For example, you can specify the unit, minimum value, maximum value, and dimensions of wind velocity, tire pressure, or water temperature.

A Simulink.ValueType object specifies this fundamental set of signal properties for a value type:

Data type
Minimum value
Maximum value
Unit
Complexity
Dimensions
Dimensions mode (fixed-size or variable-size)
Description

The property specifications for a value type are relevant wherever the type of value appears in a model. ValueType objects do not include instance-specific properties, such as initial values or sample times.

Determine Whether To Use Value Types

You can specify signal properties individually or with a predefined set of property specifications. Depending on your modeling requirement, the way you define a set of signal properties differs.

Modeling Requirement	Source of Property Specifications
Assign or validate the properties of signals based on a set of properties that is fundamental to the application-specific value type of the signal, such as wind velocity.	Use a `Simulink.ValueType` object.
Assign or validate the properties of a signal based on a set of instance-specific properties, including the initial value and sample time.	Use a `Simulink.Signal` object or a Signal Specification block.
Assign or validate the properties of a signal that is an element of a bus.	Use a `Simulink.BusElement` object in a `Simulink.Bus` object.

A ValueType object can define the properties of a signal at an interface. When the ports of model components directly connect to each other, specify the same ValueType object for the blocks that represent those ports. If you specify different ValueType objects that have the same properties but different names, you receive an error. By specifying the same value type at both sides of the interface, you enforce consistency at the interface between the two components. For more information about interface design, see Define Interfaces of Model Components.

The ValueType object propagates through the model until it reaches a block that produces new data as output. For example, the object passes through In Bus Element and Out Bus Element blocks, but it does not pass through Sum or Gain blocks.

Information overlays display the properties specified by the ValueType object. Information overlays do not specify the ValueType object itself. Suppose your value type has units. To see the units, in the Simulink^® Toolstrip, on the Debug tab, select Information Overlays > Units. The units specified by the ValueType object appear on the signal lines.

ValueType objects do not appear in the generated code. The signal properties that the ValueType objects specify appear in the generated code.

Create Value Types

To interactively create or edit Simulink.ValueType objects, use the Type Editor or Model Explorer. ValueType objects created with these tools are initially stored in the base workspace or a data dictionary.

To create a ValueType object in the Type Editor:

Open a model.
In the Simulink Toolstrip, on the Modeling tab, in the Design gallery, click Type Editor.
In the Sources pane of the Type Editor, select the storage location for the Simulink.ValueType object. For example, if the model uses a data dictionary, select the data dictionary. Otherwise, select the base workspace.
In the Type Editor toolstrip, in the Add gallery, select Value Type.
A new ValueType object appears in the Contents pane.
Use the table or Property Inspector pane to specify the desired property values for the value type.

To programmatically create and edit ValueType objects, see Simulink.ValueType. ValueType objects created programmatically are initially stored in the base workspace.

Specify Value Types

After you create a ValueType object and specify its properties, use it to specify signal properties:

At an interface with Inport, Outport, In Bus Element, or Out Bus Element blocks
In a model with Signal Specification blocks
In a Simulink.BusElement, Simulink.Signal, or Simulink.Parameter object

To associate a block or object with a value type, set the data type of the block or object to ValueType: <object name> and replace <object name> with the ValueType object name.

You can specify the ValueType object as the data type either before or after defining the ValueType object. However, before you simulate the model, the ValueType object must be defined and loaded.

The property values specified by the ValueType object override the property values specified by the block, object, or signal. For example, suppose an Inport block sets Unit to ft/s. When you set the Data type of the Inport block to a ValueType object that has m/s as its unit, the block uses m/s as the unit.

During model development, you can modify signals to match ValueType objects or modify ValueType objects to match signals. If you do not want to change the ValueType object, you can:

Create a ValueType object that matches the changes to the signal and use the new ValueType object for the blocks that the changed signal connects to.
Revert the signal changes so that the signal continues to match the associated ValueType object.

When ValueType objects do not match at an interface, you can:

Specify the same ValueType object at both ports.
Remove the ValueType object specification from one of the ports.
Insert a Signal Specification block between the ports. The Signal Specification block returns a mismatch warning instead of an error when it receives a different ValueType object than the one it specifies.

Save Value Types

You can save Simulink.ValueType objects to these locations:

Data dictionary
Script
Function
MAT file

If you do not save ValueType objects, then when you reopen a model that uses the ValueType objects, you need to recreate the ValueType objects.

Choose where to store ValueType object based on your modeling requirements.

Modeling Requirement Location

Store data for large models and model hierarchies.

Modeling Requirement	Location
Store data for large models and model hierarchies.	Use a data dictionary. When you save to a data dictionary from the base workspace, you get all the variables used by the model, not just the `ValueType` objects. For more information, see Migrate Models to Use Simulink Data Dictionary.
Use MATLAB^® for traceability and model differencing.	Use a script or function. Create a script or function that programmatically defines one or more `ValueType` objects. For more information, see Create Scripts and Create Functions in Files.
Save and load `ValueType` objects faster.	Use a MAT file. To create a MAT file that contains either the specified `ValueType` objects from the base workspace or everything in the base workspace, use the `save` function.

Use a data dictionary.

When you save to a data dictionary from the base workspace, you get all the variables used by the model, not just the ValueType objects.

For more information, see Migrate Models to Use Simulink Data Dictionary.

Use MATLAB^® for traceability and model differencing.

Use a script or function.

Create a script or function that programmatically defines one or more ValueType objects.

For more information, see Create Scripts and Create Functions in Files.

Save and load ValueType objects faster.

Use a MAT file.

To create a MAT file that contains either the specified ValueType objects from the base workspace or everything in the base workspace, use the save function.

To save ValueType objects stored in the base workspace, you can use any MATLAB technique that saves the contents of the base workspace. However, the resulting file contains everything in the base workspace, not just ValueType objects.

When you modify saved ValueType objects, you must resave them to keep the changes.

Map Value Types to Models

Before you simulate a model, all the ValueType objects that the model uses must be loaded into the base workspace or a data dictionary used by the model. Mapping ValueType objects to models is important for automation and consistency across models.

By identifying all of the ValueType objects that a model requires, you can ensure that those objects are loaded before model execution.
By identifying all models that use a ValueType object, you can ensure that changes to a ValueType object do not cause unexpected changes in any of the models that use the ValueType object.

To ensure the necessary ValueType objects load before model execution, consider:

Projects — Automatically load or run files that define ValueType objects by configuring the files to run when you open a project. For details, see Project Management.
Data dictionaries — Store ValueType objects with variables and other objects for one or more models.
To share a ValueType object among models, you can link each model to a dictionary and create a common referenced dictionary to store the object. For an example, see Partition Dictionary Data Using Referenced Dictionaries.
Databases — Capture mapping information in an external data source, such as a database.
Model callbacks — Load or run files that define ValueType objects by using a model callback, such as PreLoadFcn. For more information, see Model Callbacks.
If a model uses only a few ValueType objects, consider copying the ValueType object code directly into the callback, instead of loading a file.

To find where a ValueType object is used in an open model, see Finding Blocks That Use a Specific Variable.