Page Content

1 Description
2 Example System
3 I/O Configuration
- 3.1 DDF
- 3.2 General I/O Config
- 3.3 Orchestra Frameworks
- 3.4 Orchestra Clients
4 Modeling
- 4.1 Orchestra Framework
- 4.2 Orchestra Client
5 Project Configuration
- 5.1 Assignments
- 5.2 Configuration Panel
- 5.3 Model Archive

Description

This document provides an example of the usage of the Orchestra I/Os with internal Simulink models.

The intent is to show how to implement a relatively simple model using as much as possible the different I/Os. Thus, external Orchestra client will not be used in this example.

Example System

Three models executing simple mathematical operations are connected together through the use of a fourth model. The distribution is as follow:

The first Orchestra client - Client1:
- subscribes to a single data “BaseValue“
- increases the subscribed value by one
- publishes the result as “CorrectedValue“
The second Orchestra client - Client2:
- subscribes to a single data “BaseValue“
- decreases the subscribed value by one
- publishes the result as “CorrectedValue“
The third Orchestra client - Client3:
- subscribes to a single data “BaseValue“
- divides the subscribed value by two
- publishes the result as “CorrectedValue“
The Orchestra framework - Framework:
- forwards the two “CorrectedValue“ from Client1 and Client2
- ignores the “CorrectedValue“ from Client3

The framework Simulink model centralizes the three Orchestra frameworks. It has access to the three connected domains and their data.

As such, we may route the signal however we want within the model, as long as the data are still compatible when linked back to their expected output in the Orchestra system.

Therefore, as the output from Client3 is ignored by the Framework, we still need to connect a new input for the Client3. That’s why the “CorrectedValue“ from Client1 is duplicated towards Client3.

FIG 1 shows a representation of the data exchange between the different Simulink models expected.

FIG 1: Representation of the data exchange between the different actors of this Orchestra system

I/O Configuration

DDF

As explained in Orchestra, it is mandatory to have a DDF (Data Description File) in a given Orchestra system to specify the simulation data exchange between the framework and its client.

Following the data flow explained in the previous part, here is the DDF file used for our example, using 3 domains for the data exchanges:

<?xml version="1.0" encoding="ISO-8859-1"?>
<orchestra>
   <domain name="domain1">
      <synchronous>yes</synchronous>
      <states>no</states>
      <multiplePublishAllowed>no</multiplePublishAllowed>
      <connection type="local" />
      <set name="PUBLISH">
         <item name="BaseValue">
            <type>float64</type>
            <length>1</length>
         </item>
      </set>
      <set name="SUBSCRIBE">
         <item name="CorrectedValue">
            <type>float64</type>
            <length>1</length>
         </item>
      </set>
   </domain>
   <domain name="domain2">
      <synchronous>yes</synchronous>
      <states>no</states>
      <multiplePublishAllowed>no</multiplePublishAllowed>
      <connection type="local" />
      <set name="PUBLISH">
         <item name="BaseValue">
            <type>float64</type>
            <length>1</length>
         </item>
      </set>
      <set name="SUBSCRIBE">
         <item name="CorrectedValue">
            <type>float64</type>
            <length>1</length>
         </item>
      </set>
   </domain>
   <domain name="domain3">
      <synchronous>yes</synchronous>
      <states>no</states>
      <multiplePublishAllowed>no</multiplePublishAllowed>
      <connection type="local" />
      <set name="PUBLISH">
         <item name="BaseValue">
            <type>float64</type>
            <length>1</length>
         </item>
      </set>
      <set name="SUBSCRIBE">
         <item name="CorrectedValue">
            <type>float64</type>
            <length>1</length>
         </item>
      </set>
   </domain>
</orchestra>

Here, the focus is made on the list of items for each domain: the “Publish” and “Subscribe” sets.

The other information (from “Synchronous” to “Connection type”) were set arbitrarily as they depend on deeper intent that we may give to the simulation. This is not discussed in this part.

General I/O Config

The previous DDF depicts three domains. Hence, three OrchestraFramework I/Os need to be created.

The intended system also expects internal models for each client: three OrchestraClient I/Os also need to be created.

The following figure shows the list of Orchestra I/Os once created.

FIG 2: I/O Interfaces section

Quick verification check: the arrow appearing on the left of each I/O proves that the configuration was successful.

In FIG 2, model’s subsystems were already associated with each I/O. These models were created and compiled ahead of the I/Os' creation.

However, you may create the I/Os prior to the models and let the model assignment pending.

Orchestra Frameworks

Using the “DDF Importer” feature, you will be invited to select the previous DDF file wherever it was saved and the domain of interest.

Repeating this manipulation for each OrchestraFramework will produce the following configurations as showed in figures 3 to 5.

Orchestra Clients

The three OrchestraClient I/Os may be configured following the exact same procedure as for the OrchestraFramework’s configuration.

They are shown in figures 6 to 8.

Modeling

Orchestra Framework

The model used on the frameworks side is relatively simple.
Inside a subsystem named “sm_master”, three OpInput blocks are created to receive the data from the three different external models (simulated by Simulink), and three OpOutput blocks are used to send data back to those same models:

OpInput1 and OpOutput1 are expected to be connected to “Client1”
OpInput2 and OpOutput2 are expected to be connected to “Client2”
OpInput3 and OpOutput3 are expected to be connected to “Client3”

It allows us to highlight the interconnectivity between the models thanks to Orchestra and the framework model.

Alternative model using the Wait-To-Go feature:

The wait-to-go feature is represented by a signal read by the OrchestraFramework I/O. As such, an OpOutput block is used to send the data from the model to the I/O.

Orchestra Client

The models used on the client side are relatively simple. Each model is basically composed of one subsystem named “sm_master” and handling one data (Received from the framework via an OpInput), performing one simple operation on it, and sending the result back to the framework (via an OpOutput):

Client1 increases by “1”
Client2 decreases by “1”
Client3 divides by “2”

Figures 11 to 13 give the Simulink representation for each client.

Project Configuration

Once the I/Os created and the RT-LAB models compiled, we may perform the last needed configurations: the subsystem assignment and the datapoints connection/routing.

Assignments

Each Orchestra I/O needs to be assigned to each corresponding model/subsystem:

Configuration Panel

Last remain the data routing between the datapoints of the I/O and the datapoints of the models (represented by the list of OpInput and OpOuput).

Select and drag the signal Client3->sm_master->OpInput->In1->Value (Data Points row) (FIG 20)
Drop it on OrchestraClient3->SUBSCRIBE->BaseValue (Connections row) (FIG 21). A path to the linked data point should appear in both model and interface Data Points connection row.
Select and drag the signal Client3->sm_master->OpOutput->OpOutput->Signal1 (Data Points row) (FIG 22)
Drop it on OrchestraClient3->PUBLISH->CorrectedValue (Connections row) (FIG 23). A path to the linked data point should appear in both model and interface Data Points connection row.

To connect the orchestraFramework3 I/O to the Framework model, you may follow similar steps as for the client side, but with the framework datapoints. See FIG 24 & FIG 25.

Model Archive

The motel presented in this documentation can be downloaded, and with minor modifications, to be adapted to the user system (for example, the DDF paths in the I/O configurations), it can be used.