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:

1. On the Modeling tab, in the Design gallery, click Model Data Editor.

2. In the Model Data Editor, click the Parameters tab.

3. 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 the SensorData 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 the SensorData bus object.

• The ValideDeviceIDs value type validates the properties of the ClientDeviceIDList bus element of the In Bus Element block labeled ControlData.

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 the ClientDeviceIDList 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 the ValueTypesTirePressureController model.

• The FilteredData value type defines the array of buses for an Outport block. This value type references the SensorData 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'.
### Total of 1 models to build.
### Starting serial model 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 1.6517s

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.