Putting Everything Together for a Minimalistic SRTC System

This tutorial explains how to create, configure and run a simple SRTC system consisting of multiple, collaborating RTC Components.

To make life easier for developers, two working examples are provided with the RTC Toolkit in directory _examples/exampleEndToEnd:

  • The fileBased example uses ordinary files to host the Runtime and Persistent Configuration Repositories, and the Online Database. The example was created to demonstrate basic functionality with little dependencies to the CII.

  • The ciiBased example is a more realistic variant that uses CII OLDB as backend for both the Runtime Configuration Repository and for the Online Database. In addition the ciiBased example can also be deployed using Nomad.

  • The ciiBasedConfigNG example is an extension which uses CII OLDB as backend for both the Runtime Configuration Repository and for the Online Database and the CII config service for the persistent repo using a local file store, this version also has a Nomad variant.

Note

The CII based examples were created to demonstrate that the RTC Toolkit now also works with the CII OLDB. The example is set up and configured so that it can be run on a single virtual development machine. The examples are not optimised for throughput. Special configuration and additional code optimisation are necessary to use CII OLDB in a real-scale RTC.

The end to end examples consists of the following component types:

Executable

Description

rtctkMudpiPublisher

Simple MUDPI data generator (standalone executable not based on Tk component infrastructure)

rtctkTelRepub

Acquiring MUDPI frames and publishing Agnostic DDS Samples

rtctkExampleTelSub

Receiving Agnostic DDS samples and storing Example Topic samples in shared memory

rtctkExampleDataTaskTelemetry

Retrieving Example Topic samples from shared memory, processing them and storing results in RTR

rtctkRtcSupervisor

Guiding state of other components in response to commands and publishing global state in RTR

The components realise a simple Telemetry Data Path and they are being supervised by an RTC Supervisor. Sequencer functionality is being emulated using a shell script.

The system makes use of most of the components and libraries provided by the RTC Toolkit and introduces additional supporting tools like data sources, etc.

The examples are composed into the following waf modules:

  • config - Contains configuration of the example system

  • scripts - Helper scripts for deployment and control

Running the Example

After installing the RTC Toolkit (see Installation) the executables of the working example should be present in $INTROOT/bin and they should already be globally available via $PATH.

To run the fileBased example, use the following command:

$ rtctkExampleEndToEnd.sh run

To run the ciiBased example, first ensure that CII services are started (see Installation) and then use the following command:

$ rtctkExampleEndToEndCii.sh run

To run the ciiBased example with Nomad (single node) deployment, first ensure that CII services and the Nomad Agent are started (see Installation) and then use the following command:

$ rtctkExampleEndToEndCiiNomad.sh run

The variants using the CII config service to host the persistent repo can be started using the following commands:

$ rtctkExampleEndToEndCiiConfigNG.sh run

$ rtctkExampleEndToEndCiiNomadConfigNG.sh run

The command with bring up all components and let them run for about 30 seconds, then it will terminate gracefully.

For more flexible use developers can step manually through the component life-cycle using the following sequence of commands:

# Deploy and start the example applications
rtctkExampleEndToEnd.sh deploy
rtctkExampleEndToEnd.sh start
rtctkExampleEndToEnd.sh start_data

# Use the client to step through the life-cycle of the respective component instance
rtctkExampleEndToEnd.sh send rtc_sup Init
rtctkExampleEndToEnd.sh send rtc_sup Enable

rtctkExampleEndToEnd.sh send tel_repub_1 Run
rtctkExampleEndToEnd.sh send tel_sub_1 Run
rtctkExampleEndToEnd.sh send data_task_1 Run

# Follow how components work
rtctkExampleEndToEnd.sh send data_task_1 Idle
rtctkExampleEndToEnd.sh send tel_sub_1 Idle
rtctkExampleEndToEnd.sh send tel_repub_1 Idle

rtctkExampleEndToEnd.sh send rtc_sup Disable
rtctkExampleEndToEnd.sh send rtc_sup Reset

# Gracefully terminate the applications and clean-up
rtctkExampleEndToEnd.sh stop_data
rtctkExampleEndToEnd.sh stop
rtctkExampleEndToEnd.sh undeploy

Note

The name of the script above differs when using the CII based or the Nomad based example.

Development Guide

This section explains how to configure multiple RTC Components to work in concert.

For information on how to develop individual or custom RTC Components refer to section Creating a Simple RTC Component.

All YAML files mentioned in the following sections refer to files that can be found under _examples/exampleEndToEnd/fileBased/config/resource/config/rtctk/exampleEndToEnd/fileBased. These are then deployed to the installation directory when rtctkExampleEndToEnd.sh deploy is run.

Configuration of the Telemetry Data Path

The data path of the example is configured by changing static and dynamic configuration keywords used by the components. The precise location of the keyword definitions depends on the implementation of the particular example, most of the keywords are set by the script rtctkExampleEndToEndPopulate.sh, you can change the values used by modifying this script or changing the parameters after the “deploy” stage has been performed.

For the version of the scripts using the CII service to host the persistent repo the configuration files are archived with the code in the following location. _examples/exampleEndToEnd/ciiBasedConfigNG/config/resource/config/rtctk/exampleEndToEnd/ciiBasedConfigNG/persistent_repo.

The detailed description of the syntax and options available can be found in the CII Configuration manual.

Configuring the MUDPI Publisher

The rtctkMudpiPublisher tool is used as a telemetry data source.

The MUDPI Topic id, destination host and port are specified on the command line which is defined in script rtctkExampleEndToEnd.sh in function do_start_data()

More information about the MUDPI Publisher tool can be found in section MUDPI Publisher.

Configuring the Telemetry Republisher

The rtctkTelRepub configuration is in the tel_repub_1.yaml file.

The number of receivers, receiver IP addresses and port numbers are specified as follows:

static/mudpi_receivers/rcv_00/ip/value: 127.0.0.1
static/mudpi_receivers/rcv_00/ip/port: 50000

If more receivers were required they would be configured as rcv_01, rcv_02, etc.

The mapping from MUDPI Topic Id to DDS Agnostic Topic Name is done as follows:

static/topics/topic_00/name: "SlopesTopic"
static/topics/topic_00/mudpi_topic: 0
static/topics/topic_00/rcv: 0

More information on how to configure the Telemetry Republisher can be found in Telemetry Republisher and Telemetry Republisher Example.

Configuring the Telemetry Subscriber

This tutorial re-uses the rtctkExampleTelSub executable from the Telemetry Subscriber tutorial, but uses different configuration parameters.

Specification of the DDS Topic to be acquired:

static/dds_topics:  [SlopesTopic]

Specification of the shared memory topic to be stored:

static/shm_topic_name: scao_loop

The shared memory topic is populated from the Agnostic DDS topic using blender code coming from exampleTelsub/app/src/main.cpp:RtcComponentMain:blender().

More information on how to configure the Telemetry Subscriber can be found in Telemetry Subscriber and Customise a Telemetry Subscriber.

Configuring the Data Task

This tutorial re-uses the rtctkExampleDataTaskTelemetry executable from the Data Task tutorial, but uses a different configuration file.

The configuration of the name of the shared memory queue to be accessed by the reader is in file common.yaml, this is an example of how configuration data items might be shared between components:

static/loop_1/queue_name: scao_loop

Additional information about the Data Task can be found in Data Task and Creating a Custom Data Task.

Configuration of the RTC Supervisor

The RTC Supervisor is configured with the list of the components to be supervised. The configuration of this list is currently coming from a file depl.yaml.

The belief is that in the future, whatever deployment mechanism is chosen by the ELT will make such information available, for the moment a separate YAML file is used:

Listing 3 depl.yaml
 object_list: "tel_repub_1 tel_sub_1 data_task_1"

The “object_list” defines the list of the components to be supervised and implicitly the order in which state transitions will be performed if the corresponding <transition>_alone flag is set in “rtc_sup.yaml”. The component names are used to retrieve the command request/response URIs and the URIs of the state publication from the “service_disc.yaml” file:

Listing 4 service_disc.yaml
 tel_repub_1:
     req_rep_endpoint:
         type: RtcString
         value: zpb.rr://127.0.0.1:12083/
     pub_sub_endpoint:
         type: RtcString
         value: zpb.ps://127.0.0.1:12084/

More information regarding the RTC Supervisor can be found in RTC Supervisor and in Customising the RTC Supervisor.