Success-Plan Services
Rob Proctor
Part 5 of the JADC2 Blog Series
“Data is wild” —Mark C. Kitz - PEO C3T (former PEO IEW&S) at TechNet Augusta 2023
The idea of a joint fully interoperable military across all armed forces is not a recent phenomenon. So how is the journey of military data interoperability unfolding? In the course of revisiting a previous RTI blog on this topic, it seemed like a perfect time to provide an update on the good, and not quite as good, progress that is being made on avoiding ‘Titanium Cylinders’ within the Joint All-Domain Command and Control (JADC2) environment.
It has been clear for many decades: combined forces that fail to work together hamper overall operations. Success in future battles will require forces across all domains and at every echelon to fight as one. There have been many attempts to solve this issue ever since it was identified. So what is different this time? What is the thinking behind this current incarnation, and will it succeed?
This latest call for combined interoperability started to come into focus around 2020. The Air Force was the first to put out a multiforce concept in no small part due to Dr. William Roper, the now-former U.S. Air Force Assistant Secretary for Acquisition, Technology and Logistics. He envisioned a U.S. DoD-wide military internet of things, and launched the first major push for a JADC2 concept by an armed force, the Advanced Battle Management System (ABMS). Meanwhile, the Army and Navy were scrambling to say, wait a sec, DAF’s JADC2 isn’t exactly going to be our JADC2. The Army created its own JADC2 aligned program, Project Convergence, while the Navy likewise created its own, Project Overmatch. This had longtime military observers seeing the DoD on another knife’s edge. Possibly repeating the same mistakes made on major joint initiatives like JTRS, where each branch protected its silo to the detriment of being truly joint. Would there be silos again, the infamous titanium cylinders of excellence? Or could the Joint Forces be headed for a decisive victory this time around?
Well for starters, the Joint Staff got involved early and created a new division to oversee JADC2 implementation. The new Joint All Domain Command and Control (JADC2) Division within the Joint Staff’s J-6 office will be the central manager for all things JADC2. Next, the different branches made sure to reach out to each other to conduct joint JADC2 exercises. The Air Force had joint on-ramp exercises for early ABMS tests, linking F35s with F22s, something that they could not do before. Similarly, the Army has conducted several Project Convergence exercises, interoperating between multiple different forces. The DoD has made it plain across different armed services Program Executive Offices (PEO) that new programs under their purview will need to interoperate with other systems to make the ‘fight-as-a-single-cohesive-entity’ approach a reality.
The Army has made it clear across several Army Technical Exchange Meetings (TEMs), and the past few TechNet Augustas, that they are all in and on board. Large events like Sea-Air-Space, the Navy League’s Global Maritime Exposition and the AFA’s Air, Space & Cyber Conference put emphasis on the jointness of JADC2 for the Navy and Air/Space Forces respectively. There just might be something sticky about this joint initiative. In short, JADC2 is on its way.
Figure 1: NGC’s successful IBCS test for Project Convergence, Image Source: Northrop Grumman Newsroom, July 15, 2021
A JADC2 Progress Report
Recently, the Army’s Project Convergence combined systems from four major Armed Forces into one successful mission. During the live-fire test, the Army’s IBCS integrated a U.S. Marine Corps G/ATOR radar, two U.S. Air Force F-35 fighters, and the U.S. Navy’s Cooperative Engagement Capability CEC on the IBCS Integrated Fire Control Network (IFCN) to shoot down an incoming cruise missile target. A noteworthy feature of the interception test was that the Army’s IBCS integrated directly with the Navy’s CEC – this was done by using the Joint Track Manager Capability (JTMC) of the AEGIS Weapon System. CEC is a long-term system that has a similar capability to the IBCS, only for the Navy.
RTI has already played an important role in the unfolding of the DoDs JADC2 strategy. As mentioned in my original 2020 JADC2 blog (a prequel to RTI’s JADC2 blog series), I posited that the very systems that made up the aforementioned PC test could be used together for JADC2. That was an easy call, because the hard mission-critical data that these systems use could easily be shared across other similar systems, as they all use RTI Connext® for their internal real-time data requirements. Interestingly, when faced with creating large, multi-node all-sensors to best-shooter systems, these defense contractors all separately came to the same conclusion: better use RTI Connext. Beyond this, RTI was also named to the ABMS IDIQ, which relates to the DAF’s flagship systems that will make up JADC2.
Beyond the main JADC2 initiatives, the forces are working on their own internal systems with an emphasis on joint interoperability. The Army created a Network Cross Functional Team (N-CFT), spanning several Army PEOs. The initial call was for unified network operations in their Unified Network Plan. Programs that fit into the plan include the Command Post Computing Environment (CPCE), which provides an easy-to-use common operational picture (COP). The Joint Battle Command Platform (JBC-P) provides the cornerstone of Joint Forces’ C2, Situational Awareness (SA), and Communications via its Common Operating Environment (COE). Similarly, the Air Force has PlatformOne with sub components such as Iron Bank for modularized hardened containers.
Figure 2, RTI’s TSOA-ID demo in 2022
The Tri-Service Open Architecture Interoperability Demonstration (TSOA-ID), for example, proved that open standards set the stage for JADC2. The event was a collaboration between the NAVAIR Air Combat Electronics program office PMA-209 Avionics Architecture Team (AAT), Army PEO Aviation and DEVCOM Combat Capabilities Development Command C5ISR Center, Air Force Life Cycle Management Center (AFLCMC), and industry partners such as RTI. It highlighted open standards interoperability, reusability and portability to accomplish faster transition, plus the incorporation of innovative capabilities to the warfighter.
Moving from being message-centric to data-centric has been one of the most important steps for JADC2. The DoD has it in their DNA now, incorporating it into their data strategy – so it’s way past being a buzzword. The theme of TechNet Augusta 2023 was ‘Enabling a Data-Centric Army,’ so the need to make data data-centric via VAULTIS is not that uncommon of a phrase anymore. This leads to some of the good, but not quite as good, part of what’s happening with JADC2.
Figure 3: JADC2 concept from GAO-23-105495: Source: GAO analysis of Department of Defense documentation. GAO-23-105495
Next Step: Taking Control of Data at the Edge
One of the fundamental capabilities of JADC2 is the ability to get inside the adversary’s OODA loop and decide and act faster. Shortening the OODA loop is essential and can be attainable by incorporating AI. Sharing the data that comes out of AI at the speed of need in battle is the name of the game, but there appears to be too much emphasis on edge sharing up to C2 systems in the cloud – it’s sort of a north-south data flow, without enough emphasis on the east-west between systems at the edge. Data hopping from two points, of course, takes longer than a direct line. Too often, the refrain heard at TechNet Augusta was implementing a ‘Cloud-first for Data Centricity’ mentality.
This becomes more apparent when viewing what the Army has created, a concept called “master data nodes,'' that was recently tested at APG. These Master Data Nodes are supposed to allow for units and commanders to more easily access the information they need. The master data nodes are part of the Army’s tactical data fabric solution called LTAC, or lower echelon analytics platform tactical. LTAC’s aims are to connect nodes to each other and to master data nodes, which create a web of nodes where you can do data synchronization and distributed queries such that data can show up from millions of sources as if you were doing a Google search.
Querying live state data is a perfect way to describe what the Data Distribution Service (DDS™) standard that Connext is built on has been doing successfully for many years. It’s nice that the Army is embracing it now so robustly.
However, a potential issue arises with the master data nodes concept in which some nodes (masters) are more equal than others. It requires the two-hop solution of sending authoritative data from one source to a master node to make a decision and then having the master node send that new data out again. To be sure, this is a needed data flow pattern, but in reality, all systems should be thought of as master nodes in and of themselves. Connectivity will not be a given at all times to these master nodes. Sometimes, only limited bandwidth connectivity will be available at best. Operating in a perfect battlespace of being able to send all authoritative data to any and all AI/ML decision nodes at all times is just not a reality.
There are certainly lessons to be learned here. Chief among them is that ‘one ring to rule them all’ only works in perfect conditions where everybody uses the same ontology over the same standard, over the same network, etc. Knowing that is never going to happen, JADC2-based systems (i.e., everything) will need to be adaptable and configurable on the fly. The DoD’s JADC2 Strategy document states this plainly in the executive summary:
“…we must anticipate that future military operations will be conducted in degraded and contested electromagnetic spectrum environments. These challenges require a coherent and focused Departmental effort to modernize how we develop, implement, and manage our C2 capabilities to prevail in all operational domains, across echelons, and with our mission partners.”
–Summary of the Joint All-Domain Command and Control (JADC2) Strategy, DoD, March 2022
Using RTI Connext to Make DoD Systems Work as One
The Army – and military writ large – is swimming in a sea of data collected from sensors and personnel. Understanding all that information and getting the right data to the right person at the right time, securely, will require a set of robust software framework capabilities. A recent RAND study, Universal Command and Control Language, explored DDS, OMS, STITCHES, and UCI’s Variable Message Format. It found that flexibility, and using the Quality of Service (QoS) parameters that DDS provides, will be necessary for the task of dealing with the massive amount of data for JADC2.
Put another way, Mark C. Kitz, the PEO of C3T and former PEO of IEW&S said at the 2023 TechNet Augusta: “Data is wild'' and “...data curation is essential for network delivery.” He hits the nail on the head with these observations. The needs of the different systems and master data nodes will vary. There needs to be intelligence built into the data flows; Who needs what data, and how? Curation of the mountain of wild data needs to happen as soon as possible.
This can happen immediately through dynamic intelligent querying of live authoritative data, and this fine-grained control of data through full-featured QoS is a core strength that RTI Connext® delivers. The ability to send different aspects of the same data to different destinations happens because Connext makes the data the interface, enabling true data centricity. When the data is the interface, the behavior of how that data is shared can be changed dynamically – e.g., give me the specific authoritative data that I need given these parameters, now change those parameters again and again based on new data that comes from different sources, live on the fly. The aforementioned major systems are already able to invoke this capability via Connext.
JADC2-based systems will require this intelligence to be built into all of its systems to share data differently to different systems across multiple echelons. These data flow patterns will also vary between many-to-one, one-to-many, and many-to-many. Again, these flows might change on the fly. The RAND study offers guidance on how to address these data flows for a universal C2 architecture.
MOSA INDUSTRY & GOVERNMENT SUMMIT & EXPO
Beyond the ability to change data flows in the field, it is also a requirement that JADC2 systems need to be modular. Portability, as well as interoperability done in a repeatable way, are important. The reason is that new systems and capabilities will come on-line, and different configurations within a system might change based on different mission requirements.
The DoD has wisely determined that there must be open architectures and standards for this requirement. Using a Modular Open Systems Approach (MOSA) requires adhering to MOSA standards, and Connext is built into these MOSA standards already. This was demonstrated again at the inaugural MOSA Industry and Government Summit and Expo event in Atlanta, where RTI integrated several systems as demonstrated at previous MOSA-oriented events. Connext will continue to support the Joint DoD in their efforts to expand and enhance JADC2 by enabling a clear, open standards-based migration from network-centric systems to powerful data-centric environments. For more information on how RTI supports JADC2, please visit our JADC2 webpage and watch our RTI and JADC2 video.
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 page to ensure you receive the latest posts.
About the author:
Rob Proctor is a Staff Field Application Engineer for Real-Time Innovations. He has over 27 years of experience in A&D Embedded Software as a Software Engineer and Field Applications Engineer. Prior to his time as a Field Application Engineer, he developed and implemented real time embedded software at major Aerospace and Defense Corporations. His roles have included developing software and system designs, mission-management and display processing systems. Rob received his BS from Embry-Riddle Aeronautical University in Aerospace Studies and his MS from the University of South Florida in Engineering Management.