Reading RTI Monitor data from a DDS application

What is the Monitoring Library and how do I enable it?

RTI Monitoring Library is a plug-in that enables an RTI Connext DDS application to provide monitoring data. This data can be visualized using the RTI Monitor application or read by a separate, user-created application.

In RTI Connext DDS, monitoring data are a series of topics that contain two categories of information about the currently running Connext DDS application. The list of published topics can be found here, in general they can be split into two categories:

  • Statistical data
  • QoS and static system information

There are two ways to enable  Monitoring Library in an application:

Once you have configured your application such that it is publishing the monitoring topics, you can create an application to read the data, or visualize it using the RTI Monitor application. Is possible to confirm that your application is generating monitoring data by using one of the following:

  • RTI Monitor application
  • RTI DDS Spy application
  • RTI Administration Console (you will need to disable the “Filter all RTI internal Topics” filter via the blue funnel icon).

Reading monitoring topics

A DomainParticipant that has Monitoring Library enabled can not read its own monitoring topics. This is due to the fact that when Monitoring Library is enabled, the DomainParticipant internally creates monitoring topics in order to publish them - since they already exist you cannot create them again. If you try to create the topic again you will get the following error:

DDS_Topic_createI:!create presentation topic
DDSTopic_impl::createI:!create topic
create_topic error

There are, however, two options that you can implement to have both the Monitoring Library enabled and a DomainParticipant which is subscribed to those monitoring topics from within the same application:

  • Create a new DomainParticipant within the same application that subscribes to the monitoring topics
  • Use property rti.monitor.config.new_participant_domain_id. This property will cause the application to internally create a new DomainParticipant which will be used to publish the monitoring topics. An example of this written in C++ is attached to this article.

Whether you should publish the monitoring topics in a different domain to the one your application is running in will depend on your use-case. By creating a new DomainParticipant (via the rti.monitor.config.new_participant_domain_id property) you will incur the overhead of another DomainParticipant in your machine (see this Best Practice for why this isn't desirable). However, if you choose to use the same domain within which you application is running in, you will be adding additional DDS traffic to the network, which could affect the issue you are trying to debug.

Here is an example QoS snippet showing how to enable Monitoring Library in your Connext DDS application (note that this snippet includes the optional rti.monitor.config.new_participant_domain_id property).

<participant_qos>
    <property>
        <value>
            <element>
                <name>rti.monitor.library</name>
                <value>RTIDefaultMonitor_create</value>
            </element>
            <element>
                <name>rti.monitor.create_function</name>
                <value>rtimonitoring</value>	
            </element>
            <element> 
                <name>rti.monitor.config.new_participant_domain_id</name>
                <value>34</value>
            </element> 
        </value> 
    </property> 
</participant_qos> 

Attached you will find examples for C, C++ and C#. These examples demonstrate using rti.monitor.config.new_participant_domain_id to internally create a new DomainParticipant.

To create an application that subscribes to monitoring topics using the attached examples, follow these steps:

  • (Skip this step if you use the attached examples) Generate the code for dds_rtf2_dcps.idl:

    • You will find this IDL in the following path: <NDDSHOME>\resource\idl\dds_rtf2_dcps.idl

    • Generate the code for this IDL with rtiddsgen:

      <NDDSHOME>\bin\rtiddsgen -example <your_architecture> -language <C/C++/C#> dds_rft2_dcps.idl  
    • You will need, for this example, the following generated files:
      • dds_rtf2_dcps.h
      • dds_rtf2_dcpsPlugin.h
      • dds_rtf2_dcpsSupport.h
      • dds_rtf2_dcps.cxx
      • dds_rtf2_dcpsPlugin.cxx
      • dds_rtf2_dcpsSupport.cxx
        Note: In the attached examples you will find these files already generated for the x64Win64VS2013 architecture.
  • For this example, you will also need the dds_typedefs.h file, which can be found in: <NDDSHOME>\resource\idl\dds_typedefs.h
  • Generate the code for monitoring.idl (which is where all the monitoring topics are defined):
    • You will find this IDL in the following path: <NDDSHOME>\resource\idl\monitoring.idl
    • Generate the code with rtiddsgen:

      <NDDSHOME>\bin\rtiddsgen -example <your_architecture> -language <C/C++/C#> monitoring.idl
  • Modify the monitoring solution if you are you are using Windows or the makefile if you are you are using Linux.

    • You will need to add the files generated for dds_rtf2_dcps.idl and the dds_typedefs.h file to the monitoring example manually.

  • (Skip this step if you are using the given examples) Modify the subscriber if needed.

    • Modify the subscriber so it subscribes to the desired topic.

      Note: In the given example, we already provide the modified subscriber code to read the “rti/dds/monitoring/topicEntityStatistics” monitoring topic.

  • Compile the code and run the subscriber while an application with monitoring topics enabled is running.

You should be able to see the monitoring data in your DataReader. 

Product:
Platform:
Programming Language: