Value Types at Component Interfaces
This example shows how you can assign a meaningful name to a set of properties at a component interface and reuse that set of properties with value types.
Open Example
The ValueTypesTirePressure
project defines a model hierarchy that determines whether the tire pressures of a three-wheeled vehicle are within the intended operating range. Each sensor transmits tire pressure data mapped to a unique sensor ID. Of the four sensors in the model, only three of the sensors measure the tire pressure of the target vehicle. A controller filters out the unrelated sensor and determines whether the vehicle tire pressures are acceptable. When a tire pressure is out of range, the controller enables a warning lamp.
Open the ValueTypesTirePressure
project. The ValueTypesTirePressure
model also opens because the project is configured to open this model at startup. To update the line styles and load the referenced models, compile the model. On the Modeling tab of the Simulink® Toolstrip, click Update Model or Run.
openProject("ValueTypesTirePressure"); mdl = "ValueTypesTirePressure"; set_param(mdl,SimulationCommand="Update")
Identify Available Types
The example uses a combination of Simulink.ValueType
objects and a Simulink.Bus
object to define arrays of buses, nonvirtual buses, signals, and instance parameters at component interfaces and Constant blocks.
The
NoisyData
value type defines an array of buses that contains the data transmitted from all four sensors.The
FilteredData
value type defines an array of buses that contains the filtered data, which excludes data from the unrelated sensor.The
SensorTransmission
value type specifies the bus object that contains the sensor reading and unique sensor ID.The
TirePressure
value type defines a signal that represents the tire pressure reading from a sensor.The
DeviceID
value type defines a signal that represents the unique sensor ID.The
ValidDeviceIDs
value type defines a signal that represents the unique sensor IDs for each of the three wheels.The
SensorData
bus object defines a bus that contains a sensor reading and unique sensor ID.
To view the types in the Type Editor, on the Modeling tab, in the Design gallery, click Type Editor. Then, set View to Value
.
Find Value Types Used for Instance Parameters
To find where a model uses a type, click the type in the Type Editor. In this example, block annotations display which blocks use the value types and bus object.
In the top model, three Model blocks use the ValidDeviceIDs
value type.
To view how these Model blocks use the value type:
On the Modeling tab, in the Design gallery, click Model Data Editor.
In the Model Data Editor, click the Parameters tab.
Sort the Data Type column by clicking the column heading.
A Simulink.Parameter
object named ControllerClientIDList
uses the value type. Selecting the parameter object highlights the Model blocks that use the parameter object and value type.
To view how the Model blocks use the ControllerClientIDList
parameter object, in the Model Data Editor, sort the Value column by clicking the column heading.
A Simulink.Parameter
object named LocalDeviceID
uses the ControllerClientIDList
parameter object.
The LocalDeviceID
parameter object is a model argument that the referenced models promote to the parent model. Each instance of a referenced model can specify a different value for these parameters, which are known as instance parameters.
Find Value Types Used for Blocks
Open the ValueTypesTirePressureSensor
referenced model.
The referenced model uses three value types:
The
DeviceID
value type validates the properties of the constant value for a Constant block.The
TirePressure
value type defines the input signal for an In Bus Element block.The
SensorTransmission
value type defines the output bus for an Out Bus Element block. This value type references theSensorData
bus object.
Return to the top model. Then, open the ValueTypesTirePressureController
referenced model.
The referenced model uses two value types at its root level:
The
NoisyData
value type defines the input array of buses for an In Bus Element block. This value type references theSensorData
bus object.The
ValideDeviceIDs
value type validates the properties of theClientDeviceIDList
bus element of the In Bus Element block labeledControlData
.
The In Bus Element block defines the properties of a virtual bus without using a bus object.
Open the Filter
subsystem.
The subsystem uses two value types:
The
ValidDeviceIDs
value type validates the properties of theClientDeviceIDList
element that an In Bus Element block selects. The value type for this element is inherited from the specification at the In Bus Element block in theValueTypesTirePressureController
model.The
FilteredData
value type defines the array of buses for an Outport block. This value type references theSensorData
bus object.
Return to the ValueTypesTirePressureController
referenced model. Then, open the RangeChecker
subsystem. This subsystem is a for-each subsystem that applies an algorithm to each of the buses in the input array of buses.
The subsystem uses one value type. The SensorTransmission
value type defines the input bus for an Inport block. This value type is the same value type that the ValueTypesTirePressureSensor
referenced model uses.
View Simulation Results
Simulate the model. Then, double-click the Scope block.
sim("ValueTypesTirePressure");
### Searching for referenced models in model 'ValueTypesTirePressure'. ### Found 1 model reference targets to update. ### Starting serial model reference simulation build. ### Model reference simulation target for ValueTypesTirePressureSensor is up to date. Build Summary 0 of 1 models built (1 models already up to date) Build duration: 0h 0m 2.191s
The Scope block displays the output signal, which consists of zeros and ones. The value indicates whether a tire pressure is out of range at a given simulation time. When a tire pressure is out of range, the controller enables a warning lamp.
See Also
Simulink.ValueType
| Simulink.Bus