Figure 1
Finding a low cost reliable and secure way for embedded systems to exchange data is one of the key problems that has to be addressed by electronic system designers, says NICK PRIDHAM, managing director of Hamersham.
Designing a solution that is only able to support point to point data links would severely inhibit the connectivity capability of a device. A data centric approach is now a prerequisite for any new electronic design. Data centric means that the exchange of data can take place:
• Locally on the device: This means electronic sub systems on the same PCB can exchange data locally;
• Device to device: Different device types can exchange data on a local domain level;
• Device to external: Devices can exchange data across different domains.
If the design solution addresses all of these data exchange scenarios then system stove piping problems are eliminated and many to many data exchange architectures can be realised.
The case for middleware
One of the mature and field-proven approaches to solving this problem is with a middleware solution called DDS (Data Distribution Service). Middleware is a class of software that exists between an application and the Operating System.
In deeply embedded environments, middleware exists between the functional software and a network stack of the device. It provides useful capabilities that are above and beyond those found in standard Operating Systems.
In the case of DDS, the middleware provides a facility for both publish-subscribe and client-server communications. Figure 1 illustrates where middleware components fit in the application, and how they logically bridge across multiple operating systems and hardware architectures.
Utopian Approach
If a truly data centric design is to be realised then there are a number of practical problems to consider when selecting the most appropriate middleware:
• How do I eliminate the requirement for a message broker?
• How can the selected middleware work with a very wide range of architectures and operating systems?
• Can the middleware work in truly embedded operating system environments such as FreeRTOS/Baremetal?
• Is the middleware equally at home on enterprise operating systems such as Windows and Linux?
• What happens if I have very limited memory and processing capability?
• Is data messaging highly flexible and configurable?
• Can I get good, experienced embedded integration support?
• Is DDS an open standard?
• Can I eliminate vendor lock-in for this middleware?
• Can I trial the middleware for free and still get application support?
• Is there European technical support for this middleware?
• Will choosing DDS allow me to scale my system network to many thousands of devices?
• Will it handle control and near real time applications?
• Will it handle data logging applications?
Figure 2
Getting to YES with all of these questions quickly is very easy once DDS is looked into a little. Hamersham offers a DDS implementation manufactured by Twin Oaks Computing and can quickly convince you to say “Yes to DDS”. Hereafter we look into DDS a little give you some technical overview insights.
Figure 3
DDS – the case for publish subscribe
Elimination of the requirement for a message broker is achieved by deploying a publish/subscribe methodology.
Many communication middleware technologies are available. Most are based on a functional model. For example, RPC (Remote Procedure Call) and CORBA (Object Request Broker) are two examples of middleware that allow function calls to be distributed across the network between a client and a server. However, these architectures lead to tight coupling between the client and the server; this makes these systems difficult to extend.
The client-server architecture is appropriate for centralised data processing and works well in some systems and some use cases. In some client-server technologies, the drawbacks are increased integration costs for new capabilities and potential single point of failure.
An alternative to this approach is the Publish-Subscribe architecture embodied in DDS. This architecture promotes a loose coupling between data producers and data consumers.
The architecture is flexible and dynamic; it is easy to adapt and extend systems to changing environments and requirements.
Figure 2 illustrates the DDS Publish Subscribe architecture where multiple Publishers and Subscribers exchange strongly typed data through a common Topic. The communications are controlled by a Quality of Service model.
Figure 3 is an example of how DDS might be applied in a system. This example has several sources of “raw data”, a data processor that performs some processing on the raw data to produce “processed data”, several end users working with the processed data, and an administrative user performing analysis, maintenance, or auditing functions.
In this example, the darker blue boxes represent applications communicating over a DDS network.
These applications might be running together on one host, or they might be distributed over multiple hosts.
A DDS application simply publishes or subscribes to their data, without concern for what, if anything, might be on the other end of its communications. Any of the applications can be dynamically removed (and new applications may be added) without impacting the existing network.
DDS is more than communications middleware
The DDS standards specify the mechanism for moving data – a typical communications middleware technology standard. However, DDS is so much more. In addition to communications, DDS provides advanced data management, storage, organization, filtering, redundancy, extensibility, and security.
With a rich set of features, interoperability across languages, operating systems, hardware platforms, and implementations, DDS provides a robust, secure infrastructure foundation for your small-scale, large-scale, enterprise, embedded, and everything in between software system.
DDS Is flexible and scaleable
Applications communicating with DDS might be running together on one host or they might be distributed over multiple hosts, each with different architectures and operating systems. Applications using DDS for communications do not need to know the details of where their other applications are residing, or even if they exist.
The discovery mechanism built into DDS allows applications to come and go from a DDS network without requiring any changes to the applications or the network. This means a new system can be brought into the network, and start sending or receiving data, without any changes to existing applications.
DDS is fast
The Twin Oaks DDS Implementation was built from the ground up with performance in mind. The engineering staff at Twin Oaks Computing have a long history of writing and maintaining real-time and near real-time software, and this expertise was used in creating CoreDX DDS.
CoreDX DDS is written in ‘C’ (with additional application language bindings available) for low overhead and memory savings. The CoreDX DDS baseline is tested and enhanced for performance at every step of the development process. The result is a quality DDS implementation with extremely low latency and high throughput capacity.
CoreDX DDS data aggregation, multi-core data pipeline and low latency event notification provide for throughput in the +900Mbps range and latencies below 75 usec over a 1Gbps ETHERNET network.
But don’t take our word for it. The CoreDX DDS release includes source code for example benchmarking applications. Use these examples to compile your own benchmark tests and see how CoreDX DDS performs in your environment, with your data.
Free evaluations and free support
Hamersham is offering FOC DDS evaluations that will enable you to thoroughly test DDS on your hardware platform. Hamersham will also provide technical support to your test process. We are looking getting to you saying “Yes To DDS”. To find out more, go to the website www.hamersham.com.
Hamersham | www.hamersham.com