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