Service-Oriented Sensor Modeling
This example shows how to use a service interface in a software architecture model to allow a component to call services provided by specific instances of a referenced component.
In this example, the model
slexServiceInterfaceExample consists of a controller component,
Controller, and two sensor components,
Sensor2. The sensor components are modeled as two different instances of the same referenced model,
scSensorModelRef. The referenced model defines two services:
reset, which resets the sensor from drifting over time, and
fetchData, which reads the latest sensor values. A single service interface is specified between the controller and the two sensor instances, which allows the controller to call
fetchData for a specific instance of the referenced sensor component.
Open the model.
model = systemcomposer.openModel('scServiceInterfaceExample');
Both instances of the referenced sensor model output a sine wave with different amplitudes. You can view and specify the amplitudes in the Model Data Editor of the top model. To access the Model Data Editor, go to the Modeling tab, and in the Design section, select Model Data Editor.
A Class Diagram View can be used to visualize the relationship between the controller and the referenced sensor component. To open the Class Diagram View, go to the Modeling tab, and in the Views section, select Architecture Views.
The controller component interacts with the sensor components using client-server ports. Function calls to the services provided by the sensors and their responses are handled through these ports. Each client-server port is mapped to the service interface
sensorCmd, which defines the services.
Service Interface Specification
The service interface
sensorCmd is defined through the Interface Editor. To access the Interface Editor, go to the Modeling tab, and in the Design section, select Interface Editor. The service interface
sensorCmd is used across referenced models and stored in the data dictionary
slexServiceInterfaceExample.sldd. Note that
sensorCmd contains two functions,
In this example, the sensors exhibit a drift that increases over time. The controller calls the
fetchData service to receive the sensor output and calls the
reset service periodically to reset the drift back to 0. To visualize the sensor outputs, go to the Simulation tab, and in the Review Results section, select Data Inspector.
You can schedule the functions of the controller through the Functions Editor. To access the Functions Editor, go to the Modeling tab, and in the Design section, select Functions Editor. In this example, the
reset function is called by the controller every 0.2 seconds, while the
fetchData function is called every 0.1 seconds. Note that there is a Boolean input argument for the
resetData. By default,
false, and thus the
reset function does not reset the sensors until the controller sets
true. In this example, the controller component is configured to set
true every 50 samples of the
reset function, or every 10 seconds.
You can view the sequence of function calls throughout the simulation of the model in the Sequence Viewer. To access the Sequence Viewer, go to the Simulation tab, and in the Review Results section, select Sequence Viewer.
To generate code for the model, which includes the service interface
sensorCmd, use this command.
Note that the service interface
SensorCmd is generated as an abstract class. This action enables implementation to be separate from the interface.
This abstract class is implemented by the generated code for the referenced sensor model.
The generated abstract class is also used to construct the class of the controller.
The service is subsequently called by the controller from the
SensorCmd abstract class.
Function Element | Function Element Call | Simulink Function | Function
Caller | Function-Call Subsystem |
- Define Port Interfaces Between Components
- Author and Extend Functions for Software Architectures
- Software Component Modeling
- Author Service Interfaces for Client-Server Communication
- Call Simulink Functions in Other Models Using Function Ports
- Simulate Asynchronous Services for Vehicle Headlight Management