Specify Application-Specific Signal Properties
A signal in a Simulink® model has properties (or attributes) such as data type, dimensions, and numeric complexity. When a signal represents a recurring type of value, such as a wind velocity, tire pressure, or water temperature, you can define the signal properties once and reuse that specification for each signal that represents the same value type.
Simulink.ValueType object specifies a fundamental set of signal properties for a
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 |
|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 |
|Assign or validate the properties of a signal that is an element of a bus.||Use 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
ValueType object for the blocks that represent those ports. If you
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.
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
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
ValueType objects do not appear in the generated code. The signal
properties that the
ValueType objects specify appear in the generated
Create Value Types
To interactively create or edit
Simulink.ValueType objects, use the
ValueType objects created with the Model Explorer are initially stored in
the base workspace or data dictionary.
To create a
ValueType object in the Model Explorer:
Open a model.
In the Simulink Toolstrip, on the Modeling tab, click Model Explorer.
In the Model Hierarchy pane of the Model Explorer, select the storage location for the
Simulink.ValueTypeobject. For example, if the model uses a data dictionary, select the data dictionary. Otherwise, select the base workspace.
In the Model Explorer toolbar, select Add > Simulink ValueType.
ValueTypeobject appears in the Contents pane. The Dialog pane shows the properties of the new
Specify the desired property values for the value type.
To programmatically create and edit
ValueType objects, see Specify Signal Properties for Value Type.
ValueType objects created programmatically are initially stored in the
Specify Value Types
After you create a
ValueType object and specify its properties, use it
to specify signal properties:
To associate a block or object with a value type, set the data type of the block or
ValueType: <object name> and replace
<object name> with the
You can specify the
ValueType object as the data type either before or
after defining the
ValueType object. However, before you simulate 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
When you set the Data type of the Inport block to a
ValueType object that has
m/s as its unit, the block
m/s as the unit.
During model development, you can modify signals to match
objects or modify
ValueType objects to match signals. If you do not want to
ValueType object, you can:
ValueTypeobject that matches the changes to the signal and use the new
ValueTypeobject for the blocks that the changed signal connects to.
Revert the signal changes so that the signal continues to match the associated
ValueType objects do not match at an interface, you can:
Specify the same
ValueTypeobject at both ports.
ValueTypeobject 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
ValueTypeobject than the one it specifies.
Save Value Types
You can save
Simulink.ValueType objects to these locations:
If you do not save
ValueType objects, then when you reopen a model that
ValueType objects, you need to recreate the
Choose where to store
ValueType object based on your modeling
|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
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
|Save and load |
Use a MAT file.
To create a MAT file that contains either
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
When you modify saved
ValueType objects, you must resave them to keep
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
By identifying all of the
ValueTypeobjects that a model requires, you can ensure that those objects are loaded before model execution.
By identifying all models that use a
ValueTypeobject, you can ensure that changes to a
ValueTypeobject do not cause unexpected changes in any of the models that use the
To ensure the necessary
ValueType objects load before model execution,
Projects — Automatically load or run files that define
ValueTypeobjects by configuring the files to run when you open a project. For details, see Project Management.
Data dictionaries — Store
ValueTypeobjects with variables and other objects for one or more models.
To share a
ValueTypeobject 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
ValueTypeobjects by using a model callback, such as
PreLoadFcn. For more information, see Model Callbacks.
If a model uses only a few
ValueTypeobjects, consider copying the
ValueTypeobject 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.