Model Service-Oriented Communication Between Sensors

Open Live Script

This example shows how to model service-oriented communication starting from a System Composer™ software architecture and implementing component behavior with Simulink®. Modeling service-oriented communication from the architectural level allows you to design your service interface and components independent of the implementation of their functionality. For more information, see Service Interfaces Overview.

In this example, the model slexServiceInterfaceExample consists of a controller component, Controller, and two sensor components, Sensor1 and Sensor2. You model the two sensor components as two different instances of the same referenced model, scSensorModelRef. Both instances of the referenced sensor model output a sine wave with different amplitudes. The referenced model defines two services: reset, which resets the sensor from drifting over time, and fetchData, which reads the latest sensor values. You specify a single service interface 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.slx');

A software architecture with 3 components, Sensor1, Sensor2, and Controller.

Component-to-Component Interaction Through Client and Server Ports

The controller component interacts with the sensor components using server ports and client ports. The ball and socket icons represent server and client ports respectively.

Define Service Interface

A service interface defines the functional interface between client and server components. You define the service interface sensorCmd 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.

The sensorCmd service interface contains two function elements, reset and fetchData. In the Interface Editor, you can specify the function prototype to define input and output arguments. The function prototype of the reset function is reset(resetData) which specifies one input function argument, resetData. The function prototype of the fetchData function is data = fetchData() which specifies one output function argument, data. For each function argument, you can specify a value in the Type, Dimensions, Units, Complexity, Minimum, Maximum, and Description columns.

The Interface Editor open with the scServiceInterfaceSensorExampleDD data dictionary expanded. The sensorCmd service interface is expanded to show the reset and fetch data function elements.

Implement Function Behavior in Simulink

The behaviors of the functions specified in the service interface are defined in referenced models. In service-oriented architectures, you implement these function behavior models in either rate-based or export-function models.

Server Component Model

The scSensorMdlRef model is an export-function model representing the behavior of the sensors. In scSensorMdlRef, you define the two functions reset and fetchData in their respective Simulink Function blocks. The reset function has a Boolean input argument, resetData. By default, resetData is false, and thus the reset function does not reset the sensors until the controller sets resetData to true.

A Simulink model with two Simulink Function blocks to represent the definition of the reset and fetchData functions.

Client Component Model

The scControllerMdlRef model is an export-based model representing the behavior of the controller. In scControllerMdlRef, each sensor has a requestReset and requestFetchData Function-Call Subsystem.

A Simulink model with 4 Function-Call Subsystem blocks to represent two calls per function.

For more information on the structure and functionality of the server and client models, see Model Client and Server Components Using Function Ports.

Schedule Functions and Simulate

To run the model, use the sim function.

sim('scServiceInterfaceExample');

To view the sequence of function calls throughout the simulation of the model, open the Sequence Viewer.

Go to the Simulation tab, in the Review Results section, select Sequence Viewer.

The Sequence Viewer tool open with 3 components, Controller, Sensor1, and Sensor2. The sequence of interactions between the components are displayed in sequential order.

Test Service Interface of `Controller` Component

A Simulink® Test™ license is required to create a test harness. To create a test harness for the Controller component, right-click the Controller component, click Test Harness, and select Create for 'Controller'. In the Create Test Harness dialog box, click OK.

When you create a test harness, Simulink Test generates a test harness model and a mock architecture model.

The test harness model, scServiceInterfaceExample_HarnessN, provides a model to configure testing scenarios in the Simulink Function scheduler block.
The mock architecture model, scServiceInterfaceExample_MockArchitecture1, contains the mock component, scServiceInterfaceExample_MockServers1, for implementation of services communicating with your component under test, Controller.

A Simulink model containing the test harness. In this model, there are Signal Spec. and routing subsystems, a Model block referencing the mock architecture model, two outputs for sensor data, and a Simulink Function scheduler block.

To open the mock architecture model, double-click the scServiceInterfaceExample_MockArchitecture1 block in the test harness model.

A software architecture model representing the mock architecture. The architecture contains a reference component referencing the Controller component and another reference component referencing the new mock servers model.

Implement Behavior of Mock Components

Open the mock servers model by double-clicking the MockServers component in the scServiceInterfaceExample_MockArchitecture1 architecture model.

The controller calls the reset function and the fetchData function. To keep the test output of the mock servers component as expected, you must supply the test input and output to the mock servers.

`reset` Function

To implement the mock behavior of the reset function, you can add an Outport block to log the value of resetData.

fetchData Function

To implement the mock behavior of the fetchData function, you can add a Switch block to control the output of the function. You can connect the resetData port to the control input signal and add two Constant blocks for the data input signals.

Simulate Test Harness

In the test harness model, there are two Outport blocks which log the signals of Sensor1 and Sensor2.

To simulate the test, you must add a step transition. Open the Test Sequence (Simulink Test) block in the test harness model, in the Transition column of the Run step, add true as the condition for transitioning to the next step.

Click Run in the Simulation tab to simulate the harness.
Open the Simulation Data Inspector to observe logged output of the Sensor1 and Sensor2 components.

In this example, the component under test is Controller, so in the Simulation Data Inspector, you can observe the signals from the sensors to ensure the Controller was able to call the reset and fetchData functions as expected.

In the Inspect tab, select and deselect sensor1Data:1 and Output Conversion Subsystem:1 signals to observe if the signals match.
Similarly, select and deselect sensor2Data and Output Conversion Subsystem:2 signals to observe if the signals match.

If the signals match between the sensors and client component, your test is complete. For more information on testing service interfaces, see Test Your Service Interface Using Simulink Test.

Generate Code

An Embedded Coder® license is required to generate code.

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

slbuild('scServiceInterfaceExample');

The generated code includes the service interface sensorCmd as an abstract class, which enables implementation to be separate from the interface. In additional, there is an entry-point for each function of the component.

Model Service-Oriented Communication Between Sensors