9. Why Distribution Middleware?
8.0 Training
5.0 Communications
2.0 Sensors
3.0 Fusion
4.0 BMC2
7.0 Visualization
6.0 Sensor Control
1.0 Common Services
Grouping the modules into functional clusters does nothing to change that reality
and ease software integration
Hawkeye has functionally
oriented software modules
Each module talks to many
other modules
RIP TRK MSI
WAC TDA
ESM SAFERDR IFF
SEN DSCL4 L16L11
HMI ACIS
DIA NAV IPCCMCP
MUX
FIL TDM
Adding new
functionality
cascades integration
re-work across many
other modules
CEC
8.0 Training
5.0 Communications
2.0 Sensors
3.0 Fusion
4.0 BMC2
7.0 Visualization
6.0 Sensor Control
1.0 Common Services
RIP TRKCEC MSI
WAC RAIDERTDA
DWC
CHAT
ESM SAFERDR IFF
SEN DSC
DistributedDataFramework
IPv6L4 L16L11
HMI ACIS T4O
DIA NAV IPCCMCP
MUX
FIL TDM aADNS TIS
1.0 Common Services
Changing the communication between the modules can ease integration, when the
new ‘Publish Subscribe’ approach is used – each module publishes its output w/o
regard to who is receiving it, in contrast to the point-to-point approach of traditional
inter-process communication
It’s about an architecture that can assimilate evolving functionality,
rather than remaining set in time
12. Use with New and Existing Systems
New and Updated Apps
Existing, Unmodified Apps and
(Sub)Systems
DDS-RTPS Interoperability Protocol
DDS App
DDS Library
DDS App
DDS Library
Transport Transport
Non-DDS
App
DDS Routing
Service
Adapter
Non-DDS
App
DDS Routing
Service
Adapter
OS & Transport OS & Transport
DDS
API
22. rti.com/downloads
Start using DDS Today!
Download the FREE complete RTI Connext
DDS Pro package for Windows and Linux:
• Leading implementation of DDS
• Includes C, C++, C#/.NET and Java APIs
• Contact RTI for Ada
• Tools to monitor, debug, test, visualize and
prototype distributed applications and systems
• Adapters to integrate with existing applications and
IT systems
Editor's Notes
DDS is a standard for real-time publish/subscribe communication from OMG
Quick historical perspective…
- work started in 2001
- version 1.0 formally adopted by OMG in December 2004
- first commercial DDS implementation in 2005 by RTI
-- leading DDS vendor since
DDS is a data-centric or net-centric integration platform
connection-less architecture
overcomes problems of point-to-point integration
Using DDS, apps are categorized as:
publishers (or providers) of data
subscribers (or consumers) of data
With DDS, apps have no knowledge of each other.
Applications only need to know about:
- topics of data they process
- data types
Applications simply:
publish data they produce
subscribe to data they consume
For example on this slide:
sensor publishes sensor data
control app subscribes to sensor data
will then automatically receive updates
based on received sensor data, control app produces commands for actuator
No hardcoded knowledge in applications about each other
- DDS automatically discovers and connects applications at run-time
- applications very loosely coupled, just as in SOA
<click>
So, in this example, no changes are required to existing applications when you add a new sensor.
<click>
The same when you add a new display application.