Service-Oriented Sensor Modeling

Overview

In this example, the model slexServiceInterfaceExample consists of a controller component, Controller, and two sensor components, Sensor1 and 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 reset or 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.

Client-Server Ports

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, reset and fetchData.

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.

Function Scheduling

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 reset function, resetData. By default, resetData is false, and thus the reset function does not reset the sensors until the controller sets resetData to true. In this example, the controller component is configured to set resetData to 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.

Code Generation

To generate code for the model, which includes the service interface sensorCmd, use this command.

rtwbuild('scServiceInterfaceExample');

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.