Creating topics in the Data Distribution Service explores how to make a topic to allow you to send data around the system.

The Data Distribution Service (DDS) sends data to the components that need it. Topics are the basic unit of information that the DDS system reads and writes. To allow data to flow around the system first you need to define your topics. This article provides an overview of DDS is you are not familiar with it.

Creating Topics in the Data Distribution Service (DDS)

What is a Topic

A topic consists of:

• A topic type
• The topic name
• A set of Quality of Service (QoS) properties

The topic name is a string that uniquely identifies the topic within the domain. The topic type contains the definition of the data stored within the topic. The QoS properties control the behaviour of the data in the system. Topics need to be uniquely defined within a domain. Topics with the same name and different data types are considered to be different.

DDS sends information to components on different operating systems using different programming languages. Topics are defined in a way that these different languages can use. The topic types use the OMG interface definition language (IDL) for their definition. This is a language-independent means of describing data. It is also possible to define topic types in xml and by using google protocol buffers.

This article will look at defining topics using IDL.

How to define a topic in IDL

A DDS topic type is consists of an IDL structure plus a key. The IDL Structure can contain as many fields as required and the types might be:

• IDL primitive types, e.g., octet, short, long, float, string (bound/unbound)
• Enumeration
• Union
• Sequence (bounded or unbounded)
• Array
• Structure (nested)

The tables below show these in more detail:

Primitive IDL Types

These are the basic idl types.

IDL Template Types

An IDL template type is a type that takes an argument at declaration time. The actual type is only created at compile time. The following table shows the IDL template types.

The string type takes a parameter of its maximum length. This specifies the maximum length of the bounded type. If this is not provided the type is assumed to have unbounded length. This means the middleware will allocate as much memory as necessary to store the values provided by the application.

E.g. string<10> defines a string type of maximum length 10.

An IDL sequence data type allows lists of items to be sent between objects. The sequence type takes two parameters, a maximum size the type of the elements contains within the array and the length of the array

IDL Constructed Types

DDS supports three different types of IDL constructed types, enum, struct and union. The table below shows these:

A struct is a data type that allows related items to be packaged together. An enumerated type allows members of a set of values to be depicted by identifiers.   The IDL union type is a space saving type. The amount of storage required for a union is the amount necessary to store the largest element.

A DDS Topic is a struct that contains fields that are made up from these different IDL types. There are language specific mappings from these IDL types into different programming languages such as C++, Java and C#

 

Topic keys, instances and samples

Topic keys

One or more of the data types in the topic type definition can be chosen to be a topic key. The DDS system sorts the incoming data using the topic keys.  This allows applications to retrieve data matching a specific key.

We define the keyfield using #pragma keylist which has two parameters:

• The name of the datatype to which is applies
• A list of the names of all the fields that make up the key separated by spaces.

The keylist definition needs to be within the idl module.

The key should be a IDL primative type, enumeration or a string.

An example topic

Lets look at an example. An outdoor weather sensor is measuring the outdoor temperature and pressure. This sends information on the weather back to the weather office. They correlate all the readings and work out the weather forecast. Each weather sensor has an id so we know which one it is.

This is the idl:

module Weather
{
struct weatherReport
{
long stationId;
long temp;
long pressure;
string msg;
};

#pragma keylist weatherReport stationId
};

 

DDS instances and samples

The topic key allows you to uniquely identify one instance of a Topic from another instances of the same Topic. The key allows you to group related data for the same Topic.

For our weather station example above:

Instance 1 = (Topic: “WeatherReport”) + (Key: “12”)

Instance 2 = (Topic: “WeatherReport”) + (Key: “22”)

Each instance relates to a weather sensor with a different stationid.

The value of the data associated with the Topic can change over time. The different values of the Topic are DDS samples.

For our weather station example above:

Instance 1 = (Topic: “WeatherReport”) + (Key: “12”)

sample a, temperature =10, pressure = 22

sample b, temperature =12, pressure = 25

Instance 2 = (Topic: “WeatherReport”) + (Key: “22”)

sample a, temperature =2, pressure = 10

sample b, temperature =4, pressure = 12

The DDS samples are updates to particular Topic instances.