Announcing the DDS-XRCE Specification: A Protocol for Sensor Networks

XRCE stands for eXtremely Resource-Constrained Environments. The new DDS-XRCE protocol was just adopted by the Object Management Group (OMG) to deliver the benefits of the DDS databus to resource-constrained devices. It enables access to DDS data in deployments where it was not previously possible due to limited resources.

XRCE primarily targets fielded sensor network applications, such as those found in agriculture, mining, environmental monitoring and underwater robotics. However, the characteristics of the protocol also make it suitable for other resource-constrained applications in areas, such as robotics (e.g., underwater or space robots), and even micro-controller-based applications like those found in motor-controller boards.

These systems exhibit one or more of the following characteristics:

• Limited power (e.g., battery-powered devices)
• Intermittent connectivity. This may be caused by the network itself or the need to undergo power-saving sleep cycles
• Low-bandwidth communication links/transports
• Transports with extremely small payload size
• Small memory devices
• Low computational power

Specifically, DDS-XRCE has been designed to be able to run in systems with the following minimal resources:

• Processor: Classic CPUs, 32-bit or 16-bit microcontrollers. Can also be implemented in DSPs and FPGAs
• Memory: As low as 32 KB of RAM and 250 KB Flash memory
• Communications: Transports that can carry at least 48 Byte messages. No minimum required bandwidth. Examples include ZigBee, IEEE 801.15.4, WiFi, LoRa, Bluetooth Low Energy (BLE) and many other resource-constrained transports. Of course it can also run over cellular (3G/4G) connections and regular WiFi.
• Power: Requires very low CPU usage. Can run single-threaded. No chatter. Compatible with deep sleep-cycles where no data can be transmitted/received.

These characteristics allow systems to deploy in popular microcontroller platforms, such as STMicroelectronics ultra low power STM32L4) or Arduino Zero.

Why Another Protocol?

The standard wire protocol used by DDS applications is called RTPS which stands for Real-Time Publish-Subscribe protocol.

RTPS is a binary protocol that was built for IoT applications. While it is more efficient than other IoT/IIoT protocols, such as AMQP and MQTT, it still exceeds some of the resources available in extremely resource constrained systems.

RTPS was designed to meet the needs of independent (autonomous) peer-to-peer systems, scale to large (internet-scale) systems, and operate in dynamic environments. It supports open-ended systems where applications can appear and disappear, move to new IP addresses and remain in continuous operation for long periods of time (perhaps years). It was also built to support protocol revisions without breaking interoperability.

To accommodate the above requirements RTPS includes features, such as 16-Byte globally-unique identifiers (GUIDs) for all Endpoints (Writers and Readers) in the system, 8-byte sequence numbers, automatic discovery, propagation of type information, support for protocol and data evolution, etc. These headers and “metadata” cause too much overhead in transports, such as ZigBee that can only carry a 66 Byte payload.

More significantly, a peer-to-peer protocol for autonomous systems requires the “continuous” presence of the different participants to support discovery, maintain liveliness and perform application data exchanges. If participants are not centrally coordinated and can go into sleep cycles or become disconnected, then this type of peer-to-peer communication becomes impractical. When a participant wants to send a message, the destination peer might be sleeping and vice versa. Systems that can undergo sleep-cycles require external Agents that relay the messages. When a participant wakes up, it sends the message to the Agent. The agent stores it and relays it to the destination participant when it wakes up.

The XRCE Architecture

DDS-XRCE is designed as a Client-to-Agent protocol.

The resource-constrained applications that use DDS-XRCE to communicate with each other and also with DDS systems are called XRCE Clients.

XRCE Clients use the DDS-XRCE protocol to communicate with a separate “infrastructure service” application which is called the XRCE Agent. The XRCE Agent is typically deployed on a separate computer node that is not resource constrained, unlike the nodes where the XRCE Clients run. The XRCE Agent node should not be subject to sleep cycles.

The XRCE Agent can communicate back with other XRCE Clients (again using DDS-XRCE) or communicate with DDS Participants using the standard DDSI-RTPS protocol.

The XRCE Agent acts as a relay or proxy between XRCE Clients and DDS Participants. The XRCE Agent appears to other DDS Participants as just another DDS Participant, communicating peer-to-peer in the DDS domain.

It is useful to think of the XRCE Agent as a DDS point-of-presence for the XRCE Clients in the DDS domain. It maintains continuous presence (as needed to participate in peer-to-peer communications), representing the XRCE Clients. The XRCE Agent provides many services to the clients:

• It holds data updates for the clients so that when the clients awaken from their sleep cycle the data is available to them.
• It provides a relay service for Client-to-Client communication allowing them to communicate even when two clients are not simultaneously connected to the network.
• It helps distribute the data from the clients to a large number of consumers as well as aggregates the messages destined to a single client.
• Isolates the clients from having to discover other clients, maintaining liveliness with each other.

Each client only needs to discover and communicate with a single XRCE Agent, or perhaps a couple of Agents for redundancy. This avoids the need for clients to separately maintain reliability and security associations with each other.

All this amounts to big savings in resources and network traffic from the point of view of the XRCE Client.

Using XRCE

A typical deployment will mix applications that use XRCE (i.e., operate as XRCE Clients) with others that use native DDS/RTPS (i.e., operate as DDS DomainParticipants). The decision of where to deploy XRCE Clients versus DDS DomainParticipants is dictated by the resources available to each individual application/node.

Let’s look at an archetypical application in the domain of Pollution Monitoring in a Smart City.

To perform the continuous real-time monitoring it is necessary to deploy sensor nodes throughout the city. From the computational platform point of view, a typical deployment may use three types of nodes:

• Small Nodes using battery power
• Medium Nodes using battery power
• Medium Nodes connected to the electric grid

Small Nodes

The Small Nodes are battery-powered devices with hardware characteristics similar to an STMicroelectronics ultra low power STM32L4 or an Arduino Zero. These use 32-bit ARM Cortex CPUs with 32 to 320 KB RAM and 128 KB to 1MB of Flash. They both have low-power sleep modes.

Small Nodes would be used to read the the pollution sensors and send it to the rest of the system using low-power networks, such as ZigBee.

Because of the memory and transport constraints and the need to undergo sleep cycles, the Small Nodes would need to use DDS-XRCE.

Battery-Powered Medium Nodes

Medium Nodes may use a solar-cell to recharge the battery. They have enough power to run more powerful CPU and connect to a 4G or WiFi network. However they still need to undergo sleep cycles in order to not drain the battery at times the solar cell is not charging it. A typical CPU may be similar to a Raspberry-Pi model 2: ARM Cortex-A7 quad core 32 bit CPU running at 900 MHz and 1 GB RAM.

The CPU, memory, and network resources of these nodes would allow them to run a DDS DomainParticipant and be a full peer on the DDS Domain. However the need to undergo deep sleep cycles would dictate that they also use DDS-XRCE.

Grid-Powered Medium Nodes

The grid-connected medium Nodes are like the battery operated nodes except they run on the Grid. They have all the required resources and do not need to undergo deep sleep cycles, therefore the nodes would be DDS DomainParticipants, run RTPS and appear as peers in the DDS domain. They may deploy Connext DDS Micro or even Connext DDS Pro.

XRCE Agent Configuration

Once a decision has been made regarding which applications will run as XRCE Clients, there are various ways to configure the required XRCE Agents.

A simple option is to use DDS-XML to the XRCE Agent (or Agents). That way the Agent will already know different kinds of applications that may be run on the sensor nodes. This makes the XRCE Client applications simpler and also saves on network traffic.

An example configuration for a Gases monitor node is described in the following DDS-XML file:

XML for the GasesMonitor Node 

<?xml version="1.0" encoding="UTF-8"?>

<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns="http://www.omg.org/dds"
     xsi:schemaLocation="http://www.omg.org/dds dds-xml_system_example.xsd">
 
    <types>      
        <module name="EnvSensors" >                      
            <!--  Units are as follows:
                  CO  - Carbon Monoxide  - ppm  (parts per million) 
                  CO2 - Carbon Dioxide   - ppm  (parts per million) 
                  O2  - Oxygen           - per mille (percentage times 10)
                  NO  - Nitrogen Oxide   - ppb  (parts per billion (10^9)) 
                  NO2 - Nitrogen Dioxide - ppb  (parts per billion (10^9)) 
                  NH3 - Ammonia          - ppm  (parts per million) 
                  CH4 - Methane          - ppm  (parts per million) 
             -->
            <struct name="GasesType" extensibility="mutable">
                <member name="CO"  type="uint16"/>
                <member name="CO2" type="uint16"/> 
                <member name="O2"  type="uint16"/> 
                <member name="NO"  type="uint16"/> 
                <member name="NO2" type="uint16"/> 
                <member name="NH3" type="uint16"/> 
                <member name="CH4" type="uint16"/> 
            </struct>
        </module> 
    </types>
    
    <application_library name="SmartCity">                
        <application name="GasesMonitor">
            <domain_participant name="EMParticipant"
                                base_name="SensorParticipantLib::SensorNode" >
                <register_type name="GasesType"
                                type_ref="EnvSensors::GasesType"/>
               
                <topic name="Gases" register_type_ref="GasesType"/>
                                 
                <publisher name="MyPublisher">
                    <data_writer name="GasesWriter" topic_ref="Gases"/>
               </publisher>
            </domain_participant>
        </application>
    </application_library>
</dds>

XRCE Client Code

The programming language API used by the XRCE Client is not defined as part of the DDS-XRCE specification. This was done to facilitate the creation of various simplified APIs that can be tailored to specific needs of applications and devices, including FPGAs. Therefore, the details may vary across vendors.

The following pseudo-code illustrates the main steps needed for a client to connect to an Agent and send data. They assume the Agent has been configured with the XML description of the “GasesMonitor” node shown above. Note that this example C API requires no dynamic memory allocation and no additional threads.

// Initialization of the Client
XRCE_ClientKey    clientKey    = {0xAA, 0xBB, 0xCC, 0xDD};
XRCE_Client       client;
XRCE_ClientInit(&client, "tcp://192.168.0.10:4100", clientKey);

XRCE_ObjectRef    objRef = "SmartCity::GasesMonitor::EMParticipant::MyPublisher::GasesWriter";
XRCE_Writer       writer;
XRCE_WriterInit(&writer, &client, objRef, XRCE_DEFAULT_STREAM);
EnvSensors_GasesType         sensorData = {0};

// periodic sending of pollution data
while (true) {
    // This represents the code used to fill the sensorData structure 
    // with the data from the sensors
    read_sensor_data(&sensorData);

    // Send data to agent for distribution
    EnvSensors_GasesType_Write(&writer, sensorData);

    // Perform any periodic tasks (e.g. process and repair NACKs) in the main thread
    XRCE_RunPeriodicTasks(&client);

    // Only measure once each 10 minutes
    sleep(1000*60*10)
}

This code also relies on code-generated from the “Gases Node” XML file that creates the type definition for EnvSensors_GasesType as well as the function EnvSensors_GasesType_Write which knows how to serialize this type.

Alternatively the application could manage the serialization of the data. In this case it would call a more generic function (e.g., XRCE_Write) passing the serialized data in a buffer and its length as shown below:

XRCE_Write(&writer, sensorDataSerialized, serializedDataLength);

Dynamic Systems

XRCE does not require the application to be pre-configured in the XRCE Agent. XRCE Clients also have API calls that allow them to create the necessary resources in the Agent and use it to write or read data. For more details, see the links under References.

Conclusion

The new DDS-XRCE protocol specification enables sensor networks and other resource-constrained systems to connect to the DDS databus.

Are you interested? Do you have applications that can benefit from XRCE? Please post any questions you may have to this blog, or email info@rti.com

References

The ultimate reference for the protocol is the OMG Specification available here and here.

You can find a technical overview of the specification in this presentation.

Other references:

• STMicroelectronics ultra low power STM32L4
• Arduino Zero
• Raspberry Pi 2 Model B