Success-Plan Services
Andre Odermatt
Part 3 of the JADC2 Blog Series
The core objective of Joint All-Domain Command and Control (JADC2) is to share live, real-time, unambiguous data into intelligence systems. These systems consume this real-time data and feed-derived situational awareness and possible actions and responses to command and control (C2) teams, and, possibly, to effectors, for immediate response. In achieving this capability, data centricity is JADC2’s greatest architectural ally.
The U.S. DoD Mandate for Data Centricity
The real-time flow of data into the JADC2 enterprise and the resulting actions/decisions align precisely with the U.S. Department of Defense (DoD) Data Strategy as announced on September 30, 2020. This strategy directs DoD leaders to evolve all DoD assets into data-centric assets that treat data as a weapon system, and to position the DoD as a data-centric organization that uses data at speed and scale for operational advantage and increased effectiveness. This data-centric strategy requires sensors and platforms across all domains to be designed, procured, and deployed with open data standards as a threshold requirement. The modern battlefield will drive decision-making superiority by integrating connections between diverse data sources, as well as through using analytic tools for superior situational awareness that will aid the coordination of information that underpin disaggregated-precision effects.
The DoD document outlines the seven goals of this data-centric strategy — to make data Visible, Accessible, Understandable, Linked, Trustworthy, Interoperable and Secure (VAULTIS). Data centricity refers to a system architecture where data is the primary and permanent asset, and applications, missions and warfighting assets come and go. Instead of exchanging messages, software components communicate over networks via shared data objects that appear to be local data to applications that utilize this data. Applications directly read and write the value of these objects, which are cached in each participant, not through brokers or other potential single points of failure in the system.
To reap the rewards of a data-centric architecture network, architects need to:
- Establish metadata tagging criteria;
- Adopt and use standardized data interfaces;
- Implement common data availability and access practices;
- Incorporate data security best practices;
- Establish JADC2-conformant Information Technology (IT) standards;
- Apply VAULTIS goals throughout the enterprise; and
- Curate data by relevant echelon.
To deliver rapid collection, fusion and curating of data, requirements for effective data integration must be considered from the earliest stages of data sharing, with security for individual data topics applied across the warfighting domains, enabling the easy sharing of data with all JADC2 participants.
What is a Data-Centric System?
So we’ve established that DoD directives call for data centricity, but how does one create a data-centric system? Data centricity can be defined by the following three properties:
- The interface is the data. There are no artificial wrappers or brokers to interface such as messages, objects, files or access patterns.
- The infrastructure unambiguously understands that data. This enables filtering/searching, tools and selectivity. It decouples applications from the data and thereby removes much of the complexity from the applications.
- The system manages the data and imposes rules on how applications exchange data.
In a data-centric system, the design starts with the data model that describes the data required by the system/application and how it is represented. Different system components can access shared data and communicate through shared data. Access rules can be put in place so that only authenticated users can access the data. Since the data scheme is defined up front and all applications act on the same data, integration of new components is minimal and, in most cases, no data transformation is required. Another advantage of this approach is that there are no dependencies or coupling between applications because the applications do not directly communicate with each other. All communication is done through accessing (reading or writing) data.
DDS: Real-Time Publish-Subscribe Connectivity Framework
For a real-time system, it is not practical to exchange data by writing and reading data into a central database. In addition to the latency, the database server would be a single point of failure. To facilitate data-in-motion, peer-to-peer communication in a real-time system, the open Data Distribution Service (DDSTM) standard, managed by the Object Management GroupⓇ (OMGⓇ ), was developed. DDS not only supports a data-centric architecture but it also uses a simple publish-subscribe, peer-to-peer communication paradigm. Since a data-centric approach focuses on data and has a data model, it is aware of the data being exchanged. In addition, the publish-subscribe paradigm with the dynamic discovery feature allows new applications to subscribe or publish any of the data defined in the data model without impacting other applications/nodes in the system.
The benefit of the publish-subscribe system is that an application does not need to know where to send the information or from where to request the information. Classic message systems, like email, illustrate this system frailty: participants need to know exactly to whom to send mail. If there is a new person who would like to see this email message, that person needs to let the sender know so the new email address can be added to future sender emails.
Publish-subscribe works more like social media, where one can post any text, photo or video and whoever follows the connection receives the update. If a new person is interested in the status, they can simply follow (subscribe) to the social media account and will then automatically get the updates. One does not need to know how many followers are out there – one post will reach all of them. In networking terms, this is known as multicast.
DDS also has another useful capability – subscribers can apply filters on any of the data elements, and only get posts when their filtering criteria is met. The filter criteria can be changed at any point if the data of interest changes. The publishers do not need to change anything to accommodate these subscriber filters.
With its open standard and data-centric foundation, highly scalable multicast capability, and data filtering, DDS is ideal for handling the management and delivery of massive volumes of data-in-motion across diverse JADC2 systems.
RTI Connext: Driving Data Centricity in JADC2 Systems
RTI Connext®, a commercial implementation of the DDS standard, is the leading software connectivity framework for implementing data-centric architectures in global JADC2 systems. It is built upon a peer-to-peer, data-centric architecture that delivers critical real-time data to AI and ML systems at wire speed, without servers or brokers. Connext is loosely coupled with network discovery functionality, enabling a network component “plug-n-play” capability, where new capabilities can be dynamically inserted and legacy platforms can be retired without triggering system downtime. This allows users to insert new capabilities dynamically into a network that can be automatically discovered by operations technology, without powering down their systems.
The Connext architecture supports VAULTIS by design. Its application programming interfaces (APIs) drive access and visibility across multiple hardware and operating systems platforms in a consistent, understandable format. Its Real-Time Publish-Subscribe (RTPS) wire protocol drives rapid and consistent interoperability, while its open security capabilities enable trusted access across multiple security domains in real time. Connext enables a clear, open standards-based migration from network-centric systems to powerful data-centric environments, in many cases using the same network equipment, enabling the rapid delivery and sharing of data for global JADC2 systems.
Please visit our JADC2 webpage for more information on RTI’s JADC2 commitment.
Stay tuned to this JADC2 blog series as we continue to explore the requirements, challenges and successes of building and deploying JADC2 systems. Subscribe to the RTI Blog at the top of this post to ensure you receive the latest posts.
About the authors
Andre Odermatt is a Technical Marketing Engineer for Real-Time Innovations (RTI). He received his BS in Electrical Engineering from the Lucerne School of Engineering and Architecture, and Diploma of advanced studies in software engineering from the Bern University of Applied Science. Andre has over 20 years of experience in embedded software development and communication software.
Chip Downing is Senior Market Development Director, Aerospace & Defense, Real-Time Innovations, Inc.
Chair, FACE Business Working Group Outreach Subcommittee