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.

FIG 3: Configuration panel for the first OrchestraFramework

FIG 4: Configuration panel for the second OrchestraFramework

FIG 5: Configuration panel for the third OrchestraFramework

In the figures above, you may notice that the option “Sync client at first step” is unchecked. This means that the Wait-To-Go feature will be enabled.

In the figures above, you may notice that the option “Sample time (s)” is either set at 0.001 (the time step of the model) or 0.0 (FIG 5). The 0.0 value is the default value, meaning that the Sample time will be set at the default value of the time step of the model.

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.

FIG 6: Configuration panel for the first OrchestraClient

FIG 7: Configuration panel for the second OrchestraClient

FIG 8: Configuration panel for the third OrchestraClient

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.

FIG 9: Simulink model handling the data routing of the three OrchestraFramework

Alternative model using the Wait-To-Go feature:

FIG 10: Alternative to the Orchestra framework Simulink 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.

The constant connected to the wait-to-go OpOutput block is set to 1: blocking the corresponding clients. The value of this constant block will need to be modified manually from RT-LAB to let the simulation works properly.

In this case, a single OpOuptut block is used to handle the three wait-to-go signals. This is allowed by the connection handling system, further explained in the project configuration category.

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”

As shown in the framework’s signal routing: Client3 will perform its operation on the result from Client1.

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

FIG 12: Simulink model for Client2

FIG 13: Simulink model for Client3

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:

FIG 14: OrchestraClient assignment for Client1

FIG 15: OrchestraClient assignment for Client2

FIG 16: OrchestraClient assignment for Client3

FIG 17: OrchestraFramework assignment for Client1

FIG 18: OrchestraFramework assignment for Client2

FIG 19: OrchestraFramework assignment for Client3

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)
FIG 20: Client OpInput Value
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.
FIG 21: Client Subscribe
Select and drag the signal Client3->sm_master->OpOutput->OpOutput->Signal1 (Data Points row) (FIG 22)
FIG 22: Client OpOutput Value
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.
FIG 23: Client Publish

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.

FIG 24: Framework in/out model

FIG 25: Framework Publish/Subscribe I/O

Note that the OpOutput designed to handle the wait-to-go feature was connected to the three signals from each OrchestraFramework I/O.
This allows to release the wait-to-go feature of each domain simultaneously.

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.