DDS is Communications Middleware. Software Engineers also refer to DDS as a network stack. It is computer software that enables two otherwise separate software applications to exchange information, either within one device, or between multiple devices.
Todays world of electronic devices have a wide range of Computer Chip Sets. Computer Chipsets have a wide variety of architectures (X86, PPC, ARM) and a wide range of operating systems (Windows, Linux, QNX, IOS).
All of these devices have a growing need to exchange data and so an immediate set of problems arise:
How do you get all of these device combinations to exchange data to a common standard?
How do all of these devices auto connect and auto configure in order to exchange data?
How to make these devices and networks have a long life cycle whilst being low cost to maintain?
DDS answers these questions by suggesting we consider a data centric world where devices exchange information peer to peer. Network end points, IP addresses and port number are not known by devices that need to exchange data. Devices auto connect to the network of choice, auto configure in relation to their peers on this network and then publish or subscribe to desired data topics.
Please take a a moment to view the following explainer and see how data exchange takes place peer to peer without the need for a central message broker:
DDS Described In A Few Words For Techs !
Automatic Discovery Of Network Participants
25 Powerful QOS Settings
Small Foot Print Library – 600KB
RAM Requirements – 400KB
DDS Builds Available for most common architectures & OS
Security Suite Plugin
FOC Evaluations With Full Technical Test Support
Twin Oaks DDS
WHY USE DDS ?
System Wide Device To Device Communication
DDS gets all of your systems working together. Please take a moment to view the following systems video where we show how DDS can bring large number of sub systems into a data centric environment.
Application Functions Are Decoupled From Communication Functions: They do not rely on each other’s systems to send and process information. A publisher can still publish information even if there is no subscriber seeking the information. A subscriber can receive information from other publishers if the original publisher it was getting information from fails.
DDS Communication With Other DDS Users Configures Automatically: By design, DDS is able to conclude which users should receive messages, where these users are located, and what to do if the receiver is unavailable. This simplifies data distribution and lessens the code required to perform message delivery.
Each Instance Of DDS Can Perform The Same Minimum Set Of Functions With The Same Results: This is referred to as an “open standard system”; system components can be replaced and/or take over for each other with minimal, or no, changes to the larger systems in which they operate. This saves costs as it prohibits vendor lock-in.
DDS Works In Near “Real Time”: With very low overhead and efficient processing, messages are sent with minimal latencies (approximately 70 microseconds).
DDS Ensures Consistency:Users of DDS can make changes to one system without the other system being adversely affected. Time is saved as less design time is allocated to determining how to get these systems to “talk” to each other.
DDS Has No Single Point Of Failure:Systems that use DDS to communicate can do so independent of a server or service, and independently of each other. They do not rely on each other’s systems to send and process information. A publisher can still publish information even if there is no subscriber seeking the information, or if a subscriber becomes “lost” for any reason. A subscriber can search for other publishers if the publisher it is getting information from fails, or is lost.
DDS Is Reliable And Robust: Interactions with other services or applications are independent from network services, meaning they are always available for users (the server can’t be “down” because of too many users, etc.) If one path fails, there are other paths to send and receive the information, so the information is not lost. The publisher and subscriber merely try again.
DDS Cuts Development Lifecycle Cost: When new systems need to be integrated, new data can be added to the system data model without it affecting existing DDS Devices. As long as default data is always available alongside new data, then DDS will continue regardless.
A Few Notes For The TECHS!
DDS supports multiple development languages and environments: • Languages: C, C++, Modern C++, C#, Python and Java. • Operating Systems: Linux, Windows, Solaris, QNX, VxWorks, NexusWare, LynxOS, Android. • Hardware Architectures: x86 (32 & 64 bit), UltraSPARC, ARMv5, ARVMv7, ARMv9, PPC, MIPS, Microblaze, FPGAs. • Transports: Wired Ethernet IP, Wifi IP, VME, cPCI, Serial, ARINC 653, Shared Memory and Xbee. • Bridging from any fieldbus protocol to DDS is possible. • Customisations for additional platforms and transports are possible, and usually quick and easy to achieve.
Twin Oaks DDS
WHO USES DDS ?
Jet Engine Testing
Jet Engine Testing is a huge instrumentation challenge. 1000’s of air flow, temperature, pressure, speed and noise sensors have to be monitored and data logged. The industry has some unique challenges:
Networking of 30 years of legacy (still valuable and operational) test equipment.
Automatic configuration of 1000’s of sensors when they are plugged into a network.
Data transfer to aggregators, databases, monitors, within a single facility.
Networking of this entire dataset between different facilities.
This sector is heavily dependant DDS as its core networking technology. DDS provides precise communication pathways for all data publish/subscribe requirements.
The energy sector has huge networking complexity.Wind, Hydro, Solar and Gas devices all have to be controlled remotely in relation grid power demand. This creates an extremely complex networking environment where all devices have to be able to communicate in a safe, data centric way.DDS embedded in all devices ensures a robust, fast and flexible data exchange structure.
Medical Instrumentation networking has demands that require “ many to many” communications.
Devices have to communicate real time with each other.
Devices have to communicate with central diagnostic servers for diagnostics and usage.
Devices have to communicate with external tools for software upgrades and maintenance.
The medical device sector is increasingly turning to DDS to provide a common communication platform.
Twin Oaks DDS
HOW TO GET GOING WITH DDS
Let us get you going with a DDS evaluation. We have an excellent library of documentation and project examples waiting to support your project. Evaluation projects get full commercial and technical Hamersham support from our UK based embedded engineering team.
NGVA is a data model developed for Defence Land Vehicles. Data Transfer of NGVA data between different sub systems on a vehicle is carried out using the DDS network stack.
Defence Vehicle Control Platforms are typically in service for many years and are subject to significant updates though life. Recent experience has shown however, that there is a need to be able to update platforms quickly in order to address new threats and scenarios. The traditional approach to platform design with stand alone sub-systems often results in:
A proliferation of crew controls and displays.
Lack Of Exploitation Of Data.
Lack Of Standardisation Across The Fleet.
The net effect is significantly higher cost of ownership through the life of the vehicle. In an attempt to improve this situation the UK pioneered the Generic Vehicle Architecture (GVA). This is an approach to platform design and integration based on established Systems Engineering principles that define a generic architecture.
The GVA open implementation standard was developed to support cost effective integration of sub-systems on land platforms (electronically, electrically and physically). Through the MilVA group, the GVA initiative was adopted by European nations and has become NGVA.
NATO GVA is an open standards based approach to the design and integration of multiple electronic sub-systems onto a military vehicle, which are controllable from a multifunction crew display and control unit. It has been based on the UK MOD GVA approach, but NGVA strives to enhance and expand it. Adoption of NGVA in Defence Land Vehicles brings huge networking advantages to projects:
Agile and adaptive to mission platforms.
Innovative and faster technology insertion.
System of systems interoperability.
Reduce integration risks and deployment time.
Reduce through life costs.
Reduce complexity for maintenance, drivers, operational crew, passengers and commanders.
The NGVA Community
The NGVA community consists of governmental, industry and academia representatives from key and smaller European countries. These include permanent reps from the UK, Germany, France, Czech Republic, Norway and Sweden. Additionally, reps from Spain, Greece, Italy, Austria and Israel intermittently attend the meetings.
WHAT IS IDDS ?
iDDS is operational software layer built on top of DDS. It is a standard invented by Rolls Royce test department to serve their complex data networking needs. iDDS gives Rolls Royce and and its supplier community a modular methodology for handing legacy, current and future testing data networks. Within Rolls Royce, this is known as TEDS RTS (Test, Execution and Data, Real Time System)
Some Of The Technical and Commercial Drivers to develop this standard were:
Rolls Royce had a significant amount of high quality, high accuracy and trusted legacy equipment that needed to be integrated into their networks.
Test set up and sensor configuration across networks in general was costly and time consuming.
Test and set up expertise was difficult to replace when staff changed jobs/moved on.
There was a wide range range of differing sensor interface standards on the supply side.
The Technical Objectives Of The iDDS standard for a highly complex testing environment are:
Interoperability. To be able to interoperate systems from different vendors.
Auto Configuration – All sensors should be able to be plugged into the system and receive auto configuration instructions.
Interchangeability. To be able to replace one system with another one, implementing the same interface. (e.g. should be possible to swap out a system transmitting pressure measurements for a system of a different make / model.) Allow for system upgrade / use of best in class for use case.
Flexible Architecture. Allows for different arrangement of systems, as per the requirements of each test facility and test vehicle.
Scalability. Able to accommodate architectures with 10’s of parameters to 10,000+ parameters using the same fundamental building blocks.
Loose Coupling. Systems should be able to share data and communicate without specific knowledge of other systems. [Minimise re-work and configuration effort.]
Use on all capability systems (i.e. high & low performance CPU). From low performance CPUs on signal conditioning, to high performance CPUs on servers.
The granularity with which system applications should be able to transmit and receive streaming data shall be a single “measurement 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 shall be 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. To be able to issue commands to operate (e.g. “zero”, “calibrate”) on a measurement parameter basis, rather than address a particular channel on a particular device.
For more information please contact Hamersham and we will be pleased to answer your questions.
Hamersham can kick-start your DDS project with COTS modules that support DDS. We have practical application experience with all modules shown, and can provide them with working DDS licenses pre installed.
TC4 – an innovative connectivity communications platform for use in the most adverse conditions. This controller is suitable for DDS applications requiring communication bridges and limited IO handling.
Supports NGVA and iDDS
Real Time Linux
4 x CAN (Opto Isolated Option)
8GB Data Storage
4 Inputs + 2 Outputs
3XM – an innovative connectivity communications platform for use in the most adverse conditions. This controller is suitable for DDS applications requiring communication bridges and limited IO handling.
Supports NGVA and iDDS
Real Time Linux
8 x CAN
1 x LIN
Analogue Inputs (0-5V)(4-20Ma)
Analogue Outputs(Voltage & Current)
Hamersham likes to get systems talking. We are passionate about getting system networks working properly and have encountered many protocols in our system engineering experience.