Distributed monitoring & control using DDS

Ulstein has developed control systems for the maritime sector for decades, and are continuously seeking to improve their solutions and products to solve the demanding challenges their customers face. Recently, their search for an improved control system platform led them towards the Data Distribution Service (DDS). Find how their use of DDS simplifies both system architecture, development and testability.

X-bow Ship with illustration of screen and DDS system.

Technical DDS

The OMG Data-Distribution Service for Real-Time Systems (DDS) is the first open international middleware standard directly addressing publish-subscribe communications for distributed real-time and embedded systems. It offers abstracted communication schemes, where the different systems and applications can cooperate without a typical client/server architecture. Currently more than 10 companies or groups provide DDS middleware / products.

DDS goal is to provide the right data, at the right place and at the right time, providing a global data space for systems, ranging from machine domain (Edge) to Cloud. This is done via middleware, providing a portable application API and an underlying reliable and real time interoperability protocol (RTPS). It uses quality (Quality of Service – QoS) schemas to ensure that data transfer between participants is done according to mutually agreed standards.

Control system data should often be limited or filtered to be the right data, based on rate, content, etc. Being a data centric solution DDS understands the schema of the shared data, allowing for such advanced filtering (For instance: Filtering on a publisher to send ONLY temperature data when it’s above 300 C is possible)

DDS dynamically discovers publishers and subscribers, the data they want to share and how they want to do so. Its self-forming nature then ensures that data is delivered to the right place even if consumers arrive late. It also detects loss of data or data producers (It implements QoS – enforced logical channel between each publisher – subscriber pair).

The balance of scarce system resources is needed to deliver the data at the right time. DDS middleware utilises QoS policies, for instance set by applications at runtime, to balance efficiency and determinism (For example, if a subscriber requires an update every 10ms and its matched publisher does not deliver, the system declares an error, enabling remedial action). QoS covers many characteristics such as urgency, importance, reliability, persistence and liveliness.

DDS provides a self-forming, scalable and distributed middleware, which gives the applications a global shared data space, and when you add characteristics such as deterministic performance, low latency / high throughput and high fault tolerance, it seems ideal for mission critical IoT and distributed control systems.

Also due to the dynamic and loosely coupled nature of these systems, DDS significantly reduces maintenance cost, since individual systems may be modified, added or upgraded without impact on the existing system.

Some underlying technical concepts

Relational data modelling: DDS addresses data in a manner similar to relational databases. It can manage data by both structuring related topics (by key-fields) and allows for ad-hoc queries and filters on content and time, so applications can extract specific data as needed.

Pub-sub messaging: DDS uses the publish/subscribe paradigm for dynamic discovery and primary management of data-flows between relevant DDS entities, including publishers, subscribers, durability services, recording and replay-services, and connected databases. Request-reply and other patterns are built on this powerful substrate.

Reliable multicast: The DDS standard wire protocol implements reliable multicast over plain UDP sockets, allowing systems to efficiently benefit from modern networking infrastructures.

Life cycle awareness: Unlike message-centric products, DDS offers explicit application support for information life cycle awareness. For instance, it detects, communicates, and informs applications about first and last appearances of data (topic instance) updates. This facilitates timely responses to new and outdated information.

In use

For large control systems with +10000’s of I/O (sensors and the like), data exchange needs to be smart, reliable and efficient. DDS has been tested for this purpose in several mission critical systems within industries and domains such as power, medical, aviation and space, and the US Navy have used this standard for more than 10 years.

DDS can easily merge today’s trends with yesterday’s standards in a perfect manner. Interfaces, tools and libraries can easily convert data to and from DDS, to other fieldbus types, for instance Modbus, OPC (DA, UA), etc.

Using it from your application code is easy, and done via a standardised API. Thinking in a data centric way, one starts off by defining a set of Topics (holding data types, structures, etc) that you want to have on your data bus, then you create a Participant (to listen to data within a domain / your separate data space) which again hold DataReaders and/or DataWriters to write or read that Topic.

DDS Communications model

Example

I want to send and have someone receive the price of my delicious homemade strawberry ice cream. A «double» can hold the price such an item, but it would make no sense if I just sent that double on the wire, without any contextual information. So a Topic is created (I call it «IceCreamPrice»), using «double» as the data type, and thus enabling me to send, and someone to receive, this price. Then I create Data-Writers and -Readers (with some QoS settings) to send and receive that Topic. A simple setup, and now I’m ready to open my ice cream store.

 

 

Ulstein’s experience with DDS

BY: Rune Volden, R&D Manager , Ulstein Power & Control AS

Ulstein’s experience with DDS started in 2013. May 14 that year, I got an email from a colleague regarding an alternative middleware. June 18th we had requested pricing n Open Splice/RTI Connext. We then started using Prism Tech’s Open Splice DDS the first months for graphical user interface (GUI). November 5th 2013 we purchased RTI Connext licenses. My colleague then worked with RTI Connext DDS to implement the communication between GUI and the control system throughout 2014.

During 2014 we developed our IAS based on 3rd party control system middleware (CDP), and only used DDS as communication towards the GUI. Earlier we used a Modbus communication based on JSON, but this approach required much development work, not to mention testing, to get a good result.

In 2014 our IAS project met great challenges regarding system scaling, and handling the numbers of signals required by our customers. After repeated attempts with our former middleware, this approach was eventually cancelled. We made a thorough technical investigation from November 2014 to January 2015, as to how to build our future control system.

The DDS glue

The conclusion was to develop our new control system in-house, in cooperation with Data Respons AS, using DDS as the fundamental block in the communication layer. This work started in February 2015. The IAS project was divided into teams working with documentation, Graphical User Interface design, Graphical User Interface implementation, Graphical editor, Control system kernel, Control system application, IO controller application and the Configurator tool.

Our automated systems experts started the documentation work in 2014, and all is done according to the guidelines and structure of the DNVGL’s ISDS standard.

Graphical User Interface

In cooperation with Eggs Design we used the work from an earlier Ulstein Bridge Vision project as a starting point for the realisation of a graphical user interface, starting in January 2015. In March the implementation of the Graphical User Interface started in cooperation with The Qt Company. They also started developing a Graphical editor for us which makes it possible to get the complete control system including all graphics into one readable configuration.

screenshot from the DDs system showing an alert lab image
Alert Lab image (Ulstein Power & Control AS)

Control system

The control system kernel was made from scratch, with a possibility to create and configure all internal components from XML, as a requirement. This was done in close cooperation with Data Respons, where they greatly contributed to get a strong and well tested kernel. The kernel then offers a communication layer towards the fieldbus layer (IO Controller) and graphical user interface.

The communication mostly utilises DDS (Data Distribution Services). We have evaluated several versions of DDS, but currently we use RTI Connext 5.2 in our systems. This is applicable for the control system, IO controller (Fieldbus ++) and graphical user interface also. DDS act’s as the glue between all the different applications on various controllers, PC and workstations.

The control system application is also made in cooperation with Data Respons. In this case, legacy code is ported to the new system kernel, in addition to adding new code and functionality needed.

Configurator tool / Configure to order

To get the delivery of control systems to the end customers as efficient as possible, with the highest possible flexibility, we have developed a configurator tool. This enables the application engineer to set a configuration of the control system in an easy, safe and understandable way, according to the customer’s requirements. For an automation system on a ship this typically means adding pumps, tanks, valves, pipes, switches, generator sets, propellers, motors etc., where each component has a control/remote control, control logics, mimic and user interface design. In the existing SCADA platforms this is a very time consuming and comprehensive work. One of our great challenges is that the changes shall be executed fast and efficient in the final phase of large projects. Typical “last minute changes” can introduce human errors that everybody wants to avoid. The configurator tool we are developing will minimise this risk in an efficient way.

Ballast control system. (Ulstein Power & control AS)

Ballast control system. (Ulstein Power & Control AS)

I/O controller

Data Respons has also been involved in the development of the I/O controller application. This application process all I/O on that I/O controller, which for instance can have serial lines (RS422), CAN, Modbus RTU, analog and digital IO, and sends/receives data via DDS. Via the Configuration tool we can download the configuration of serial buses and CAN to the I/O controller. The configuration can include all required configuration, down to the node level, on a local fieldbus. With this automation, only limited changes are required via vendor specific tools. The I/O Controller application reads from and writes to the IO via the controller’s I/O API. All maritime approved controllers with C++ API are basically of interest.

Our control system is not vendor specific. Currently we have at least three different suppliers of I/O and I/O controllers. Initially we start delivering systems with I/O controllers from Bachman, then Phoenix and Wago. Eventually all I/O Controllers with an environment and an API to create the I/O to DDS data transitions can be used. This gives our product flexibility, since often one supplier can’t offer a complete solution but as a total they can.

Testing

Data Respons recommended us to use test driven development, continuous integration, build servers and analysis tools at an early stage. We can now see that this saves us much time in rework and testing during both development and integration phases.

With DDS replacing components with “bots” or “mocks” for systems test is much easier, since they all use DDS to communicate. We have also started using Docker to run and simulate a multi controller environment network, and thus quite easily running large scale system and integration tests.

Due to the number of applications and controllers making up the system, continuous test and integration could have been a lot of work if not automated and thorough unit and system tests were applied continuously.

Highly adaptable for various markets

Ulstein traditionally makes control systems for large ships, but by using DDS and having the flexibility of our new kernel, the ideas and the actual system can easily be adapted to most mission critical and normal control systems.

The underlying data model of control systems often consist of transporting digital and analog data, in addition to some business specific types. The framework to do so and the knowledge of how DDS works, already exists at Ulstein. We think we are in a position to offer control system expertise and software solutions to customers outside of our traditional domain also.