FEATURE PROCESS AUTOMATION EXCHANGING DATA IN THE DIGITAL AGE • IIoT sensors exchanging data with
diagnostic tools; • IIoT sensors sending data to
datalogging devices; • IIoT sensors sending data to remote servers for device monitoring. The size of the different software systems, the number of devices connected and the distance over which they need to communicate all affect the complexity of the challenge and the resulting cost, timeframe and risk involved. Communications middleware such as DDS allows these different devices to exchange information in real time, regardless of their programming language. The DDS API supports a wide spectrum
The IIOT has brought with it the need to manage distributed networks of devices that exchange data with complex communication profiles. Nick Pridham, of Hamersham, says it’s important to find a low cost solution for automating network communications, and discusses one option: DDS – Data Distribution Service
T
oday’s system designers are busy inventing and implementing Industrial
Internet of Things (IIoT) applications and use cases. At some point in the design process, the system designer will consider how the data communication is to work and have some important issues to address. These include how to ensure all the
required device platforms can connect to each other, which networking technology is best to use, and how to simplify the scaling of the network so that thousands of devices can automatically join or leave. One solution that provides logical
answers to many of these questions is to delegate data networking and data exchange to a middleware solution. The communications middleware concept is designed to separate application tasks from networking tasks. Networking expertise is a specialist area and often the most effective business solution is to deploy a proprietary software product. Tried and tested networking software solutions that work according to the middleware concept are widely available. Data Distribution Service – or DDS – is one of the most capable and mature middleware networking software technologies available. It is a dynamic, publish-subscribe communications software technology that can improve the flexibility and scalability in a range of applications including industrial machinery. DDS is fully peer to peer and exchanges data on the basis of Data Topics. DDS does not need a message
18 DECEMBER/JANUARY 2019 | PROCESS & CONTROL
broker to exchange data and therefore expensive messaging servers are not required for large scale networks. Despite not being as widely understood
as some middleware types such as MQTT, its configurability through a QOS (Quality of Service) feature set makes it suitable for use in the IIoT applications. DDS supports 25 QOS functions allowing the network architect to specify things like, reliability, filtration, ownership strength, delivery deadlines and durability. DDS’s purpose is to simplify the design,
programming and managing of software applications by streamlining the way they receive and process data. Suitable for use in a range of embedded software systems, it can connect disparate system configurations including chip architectures such as ARM, X86 and PPC and in operating systems like Windows, Linux and QNX. DDS also supports share memory applications. This means a wide range of embedded devices can be configured to support DDS. When such a wide range of different devices configurations is supported, it enables system designers to have a truly integrated approach to their digital data communication strategy across all of their device types. In the current IIoT business space, there
is a wide range of embedded systems configurations in use. IIoT devices using DDS can now connect to any other device type, meaning typical use cases could be: • IIoT sensors exchanging data with other IIoT sensors;
Hamersham is the UK and European distribution partner for Twin Oaks Computing
DDS’s purpose is to simplify the design, programming and managing of software applications by streamlining the way they receive and process data
of language bindings including C, C++, C#, and Java, ensuring DDS has the flexibility to be integrated into any embedded system regardless of whether it is operating at the edge or in the cloud. DDS handles the transfer of information between PUBLISHERS – producers and senders of messages – to SUBSCRIBERS, or those who consume and read messages, regardless of whether they are using different operating platforms or systems. A system participant with information to
offer publishes information on request via a DATA WRITER. A system participant requiring information subscribes to information via a DATA READER. A data writer and data reader exchange information on a TOPIC. The discovery of publishers and subscriber is automatic meaning IP addresses and port number configuration is not required. The publish subscribe methodology for data exchange means DDS is truly peer- to-peer. Neither a message broker nor a cloud server is needed for information to be exchanged, reducing service costs. DDS automatically knows how to send and receive messages between users, concluding which should receive messages, where they are located and how to proceed if the receiver is unavailable. This simplifies data distribution, reducing the code required to deliver messages, which in turn makes data delivery faster and more efficient. CoreDX DDS in particular provides further benefits, such as a small code footprint; just 500 KB including standard and additional QoS policies. It also has the ability to run on machines with less than 250KB of memory. CoreDx DDS has been designed to run with minimal resources meaning whether devices are located at the edge or the cloud, both locations use exactly the same DDS implementation.
Hamersham
hamersham.com
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52
