iDDS – Background and Overview

Data Distribution Service, or DDS, provides the backbone of the iDDS model. DDS is an Object Management Group (OMG) standard that defines a system, application programming interface, and wire protocol for network communications. DDS was designed specifically to meet the performance and quality of service requirements of real-time and embedded systems. It has been adopted in Internet of Things (IoT), time-critical applications, and mission-critical architectures across multiple industries. iDDS source time stamping reduces the negative effects of latency because of non-optimal network design since the data can be time aligned at the time of processing.

^{Figure 1: iDDS Architecture}

The DDS network is managed by a middleware service. Middleware software is available from RTI, Twin Oaks, or OpenDDS. Middleware pre-allocates resources on the DDS network so that dynamic resource allocation is minimized and the need to make multiple copies of data is reduced.

iDDS adds data definitions to DDS, specific to instrumentation, including the following items:

• Channel metadata—This allows instruments to announce the data type, engineering units, and other information so that the subscriber services can process the data without specific knowledge of the publishing device.
• IEEE 1588 Precision Timing Protocol time stamping—IEEE 1588 provides time synchronization to device clocks over the same physical connection as the Ethernet network. iDDS-compliant instruments include the time stamp with the data providing “time stamping at source.” A timing generator is required to act as the grandmaster clock in the system.
• Configuration system—Measurement engineers use the configuration system to plan the measurements to be taken and to define measurement ranges, rates, calibration, and other important test information. 
• System health monitoring—This monitoring helps engineers track the usage data on the system, parameter, or hardware failures; and it provides a way to continue to run with missing parameters.

The iDDS network is composed of nodes. Publishers are nodes on the network that generate data to the network. Subscribers consume that data. Nodes may connect across the network to any other node on the network, and any node may subscribe to any parameter. 

DDS domains map to multicast addresses. Network segregation can be managed with standard network infrastructure. This makes the system scalable to a variety of facility types, from simple laboratory experiments to large test cells. Tests have shown that more than 10,000 parameters can be published across the same network.

^{Figure 2: Multi-Domain Architecture}

In this example, the real-time network has no physical partition, so any node can connect to any router. Any network issues on the systems network would be isolated from interfering with the real-time network. Domains may be associated by data type—low-speed, high-speed, and control, for example.

The configuration server manages the overall network. It publishes the backbone-specific configuration data required by the nodes. The configuration server sends a configuration file to the node and the file is stored by the node to maintain configuration.

iDDS was developed in response to the monolithic, single-supplier systems developed in the early 2000s. These systems minimized risk of problems with interoperability among vendors, but customers realized that these systems were difficult to modify or maintain over time, especially as hardware became obsolete. 

iDDS puts data first using a data-centric model. This abstracts the data away from any specific instrument features, providing the benefit of multi-vendor interoperability. This simplifies the exchange of hardware devices to ensure that no system becomes dependent on a single vendor or device. 

The iDDS architecture provides these benefits to measurement systems:

• Interoperability—Engineers can create systems with publisher and subscriber nodes from different vendors, to maximize the performance for each module on the system independently.
• Interchangeability—Engineers can swap out modules with another with the same interface with minimal effort. This allows engineers to upgrade system components without impacting the rest of the system, providing a path to longer-life systems—even when components become unavailable.
• Flexible Architecture—Engineers can arrange the modules to meet the exact needs of each test without major changes to other modules or the architecture.
• Scalability. This architecture can accommodate architectures from dozens of parameters to 10,000+ parameters, using the same fundamental building blocks.
• Loose Coupling—System modules can share data and communicate without specific knowledge of other systems. This minimizes rework and configuration effort on the overall system. 
• Support for all capability systems (i.e., high- and low-performance CPU)—Engineers can select from low-performance CPUs on signal conditioning to high-performance CPUs on servers depending on the test needs.
• Granularity to a single measurement parameter—Engineers can configure the system to transmit and receive streaming data down to a single data parameter. This allows node applications to deal with only the parameters they need in a data centric manner.
• Time-stamped data as close as possible to source—Measurement data is tagged with a corresponding time from a single source to allow correlation of data from different systems down to the fastest data sampling rate.
• Abstract away subsystem specific operations—Engineers can issue commands to operate (e.g., “zero,” “calibrate”) on a measurement parameter basis rather than address a particular channel on a particular device.

Together, these benefits give test system designer the flexibility to manage a system that maximizes performance per measurement, increases the useful life of the system, reduces the overall cost of the system, and minimizes the long-term risk of obsolescence of the system. 

Most iDDS tools today run on Linux platforms. NI has successfully tested these on NI Linux Real-Time with CompactRIO and PXI devices. 

In NI’s testing, we acquired data using NI-DAQmx calls to acquire the data. The data was then packaged per iDDS standards and published to the iDDS network.

^{Figure 3: iDDS Implementation}

Using this architecture, NI engineers demonstrated compliance with iDDS systems running thousands of data parameters from various vendors.

For more information on iDDS implementations on NI hardware, contact NI support.

• Learn more about CompactRIO
• Learn more about PXI
• See how iDDS is used in Jet Turbine Engine Test

References

External: “Test Execution and Data System” – Standardisation, Flexibility & Scalability of a Real Time Data Acquisition System, Neill Forrest (Rolls Royce)