MUDPI Publisher

Overview

The MUDPI Publisher RTC Component is used to generate and publish MUDPI traffic for potentially multiple MUDPI topics in parallel. The main purpose of the component is testing and troubleshooting, therefore it is not envisioned to run during nominal RTC operation. It can be used to test if MUDPI samples can be transferred with a certain data rate to a Telemetry Republisher (or any other MUDPI receiver) on a particular machine.

Note

The component has a limited capability, in particular about the time aspect of generating and publishing MUDPI frames and samples. If a more accurate timing is needed, another tool needs to be considered/developed.

Running

The MUDPI Publisher can be started similar as any other components by invoking the command:

$ rtctkMudpiPub mudpi_pub_1

The only mandatory command line argument is the *component instance name*.

The component can be stopped either by sending Exit command or by pressing Ctrl-C.

For more information about optional command line arguments, refer to section RTC Component.

Commands

MUDPI Publisher instances can be steered by sending commands to their provided MAL interfaces. One can either rely on the RTC Supervisor to send the appropriate commands or use the rtctkClient command line application to send individual commands manually.

The set of commands that is currently available for the MUDPI Publisher is indicated in the following table, together with the expected behaviour:

Command

Behaviour

Init

Reads the configuration and creates MUDPI publisher objects including corresponding threads.

Exit

Terminates the process.

Stop

Stops the initialisation procedure started by the Init command.

Reset

Resets the state of the component to the state before the Init command was received.

Enable

No particular actions are performed here.

Disable

No particular actions are performed here.

Update

Updates dynamic configuration if not in the Running state.

Run

Requests transition to On::Operational::Running, in which all MUDPI publishers start generating and publishing MUDPI samples.

Idle

Requests transition to On::Operational::Idle, in which all MUDPI publishers stop publishing MUDPI traffic.

Customisation

The component provides a compile-time extension point that allows retrieving simulation data from file. To use this feature, instrument RTC developers need to implement a custom method that extracts data from file, performs certain transformations (e.g. combining columns, inverse blending, inverse wrangling) and returns the result as a single data object.

The custom user method has the following signature:

using namespace std;

auto UserProvidedMethod (const string& file_path_name) -> map<string, vector<vector<uint8_t>>>;

The returned map contains an entry for each named MUDPI publisher object. The values are vectors of MUDPI payloads, where a single MUDPI payload is a vector of bytes.

The method is registered by creating a custom application that invokes the method in its BusinessLogic class during ActivityInitialising.

void RtcComponentMain(const Args& args) {
    auto bl_factory = [](const std::string& name, ServiceContainer& services) {
        return std::make_unique<BusinessLogic>(name, services, UserProvidedMethod);
    };

    RunAsRtcComponent<BusinessLogic>(args, std::move(bl_factory));
}

Note that the vanilla rtctkMudpiPub application is not capable to read data from file, since it was not possible to deliver a user function with a generic default implementation.

Configuration

As for other components, the persistent configuration for the MUDPI Publisher is defined in a YAML file. The configuration file name has to correspond to the name of the component instance.

The configuration can be divided into two parts:

  • Common configuration.

  • Publishers configuration.

Common Configuration

The common configuration part contains attributes relevant for all MUDPI publisher objects.

dynamic

Configuration Path

Type

Description

period_us

RtcInt64

(optional) Period in micro seconds to publish the MUDPI samples. The accuracy depends on the system where the component is running. Default: 1s.

sample_id_increment

RtcUInt32

(optional) MUDPI Sample ID increment step. Default: 1.

max_samples

RtcInt64

(optional) Maximum number of MUDPI samples to be generated. -1 indicates no maximum, i.e. generate forever. Default: -1.

data_file

RtcString

(optional) Pathname of a FITS file containing binary tables with payload data to ingest. Used together with user provided method.

An example of a common configuration block:

dynamic:
  period_us: !cfg.type:int64 1000000  # = 1s => 1Hz
  sample_id_increment: !cfg.type:uint32 10

Publishers Configuration

The MUDPI Publisher component hosts one or more publisher objects that generate and publish MUDPI samples for specified topics. Publishers are specified under the publishers section.

For each MUDPI publisher, the following attributes can be specified:

static

Configuration Path

Type

Description

hostname

RtcString

Hostname. If not specified together with multicast_group configuration, it is used for publishing unicast traffic to given IP.

multicast_group

RtcString

(optional) If specified, multicast publishing is enabled; it provides the multicast group address to be used for publishing. In this case, hostname configuration is used to specify the network adapter used for multicast publishing.

port

RtcUInt16

Port to send data to.

topic_id

RtcInt32

MUDPI Topic ID.

buffer_size

RtcUInt32

(optional) Buffer size in bytes to host whole MUDPI frame; includes MUDPI header (=32), MUDPI payload and MUDPI checksum (=2). Default: 8972.

calculate_checksum

RtcBool

(optional) Flag that indicates whether MUDPI checksum should be calculated or set to 0. Default: true.

thread_policies

NUMA Policies

(optional) NUMA policies for the MUDPI publisher thread.

dynamic

Configuration Path

Type

Description

sample_size

RtcUInt32

(optional) Total size in bytes of the sample payload. Default: 47000.

payload_pattern

RtcString

(optional) Selected payload pattern: alternating_uint8_ramp, alternating_uint16_ramp, alternating_int32_ramp, alternating_float_ramp. Default: alternating_uint8_ramp.

Note

The pattern generation mode and reading data from file are mutally exclusive. This means, if the data_file parameter and a custom user method are provided, the payload_pattern setting is ignored and can even be omitted.

Also note that the sample_size attribute will be ignored when reading data from file. In this case, the size is automatically computed from the return value of the user method.

Example configuration for two MUDPI publishers named pub_ex_1 and my_mudpi_pub:

static:
    # ...
  publishers:
    pub_ex_1:
        hostname: !cfg.type:string "127.0.0.1"
        port: !cfg.type:uint16 50001
        topic_id: !cfg.type:int32 100
        buffer_size: !cfg.type:uint32 8972
    my_mudpi_pub:
        hostname: !cfg.type:string "127.0.0.1"
        port: !cfg.type:uint16 50001
        multicast_group: !cfg.type:string "239.192.1.15"
        topic_id: !cfg.type:int32 101
        buffer_size: !cfg.type:uint32 8972
    # ...
dynamic:
    # ...
  publishers:
    pub_ex_1:
        sample_size: !cfg.type:uint32 147456
        payload_pattern: !cfg.type:string alternating_int32_ramp
    # ...

Monitoring

For each MUDPI Publisher, the following monitoring data points are published to OLDB:

Parameter

Type

Description

state

string

Current component state (retrieved from state machine engine).

Component Metrics

The MUDPI Publisher uses the Component Metrics Service to publish useful metrics to the OLDB.

Under OLDB path /<component-name>/metrics/counter/ the following performance counter metrics can be found:

Table 12 Performance Counter Metrics

OLDB Path

Type

Description

samples_published

RtcInt64

Number of published MUDPI samples.

frequency_estimate

RtcDouble

Frequency estimate for published MUDPI samples [Hz].

max

RtcInt64

Duration estimate for published MUDPI samples, max [us].

Note

For details about Data Points, please refer to Component Metrics OLDB Data Points.

Limitations and Known Issues

  • As this component is only meant to be used for debugging, troubleshooting and testing, it is provided with limited functionality and support.