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 |
|---|---|---|
|
|
(optional) Period in micro seconds to publish the MUDPI samples. The accuracy depends on the system where the component is running. Default: 1s. |
|
|
(optional) MUDPI Sample ID increment step. Default: 1. |
|
|
(optional) Maximum number of MUDPI samples to be generated. -1 indicates no maximum, i.e. generate forever. Default: -1. |
|
|
(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. If not specified together with multicast_group configuration, it is used for publishing unicast traffic to given IP. |
|
|
(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 to send data to. |
|
|
MUDPI Topic ID. |
|
|
(optional) Buffer size in bytes to host whole MUDPI frame; includes MUDPI header (=32), MUDPI payload and MUDPI checksum (=2). Default: 8972. |
|
|
(optional) Flag that indicates whether MUDPI checksum should be calculated or set to 0. Default: true. |
|
(optional) NUMA policies for the MUDPI publisher thread. |
dynamic
Configuration Path |
Type |
Description |
|---|---|---|
|
|
(optional) Total size in bytes of the sample payload. Default: 47000. |
|
|
(optional) Selected payload pattern: |
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:
OLDB Path |
Type |
Description |
|---|---|---|
|
|
Number of published MUDPI samples. |
|
|
Frequency estimate for published MUDPI samples [Hz]. |
|
|
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.