DARPA’s Tim Grayson talks about a federated approach to interoperability, JADC2

I like to say that interoperability goes up and down the stack. A lot of the work, especially particularly in Dave’s office [Chief Data Officer] because that’s their mission as well as at the JAIC’s and other places has focused very much at the data level. Think of it as the message, the data. The application level interoperability there is different than interoperability of networks. And oh by the way, it’s even is different than interoperability at the physical layer of data links. You can shoot two antennas at each other and if they aren’t speaking the same RF, you’re not going to get a link.

 

The way we’ve been approaching interoperability is to break that stack apart and look at how do we create options to add in interoperability later so we don’t have to wait for big bang moments where your spending tons of money? So we don’t have to wait for all the old stuff to go away and new stuff to appear? We don’t have to go spend tons of money changing old things.

 

I hate to call it this because it’s a gross oversimplification, but it is a “glue” kind of attitude. How can I create some things, just enough things even at the physical layer, that can bridge — A little uh foreshadowing, we have a new program about to hit the street called Space BACN that’s looking at creating bridges for satellite crosslinks to connect all these different P-LEO constellations that don’t each talk to each other… All of these P-LEO constellations have been built to very specific standards. Trying to get SDA, Starlink, DARPA Blackjack, Amazon, whoever else is getting that business, to all pause what they’re doing and wait until they all agree on one crosslink — that’s not going to happen.

 

This idea of adding interoperability after-the-fact I think is key. It’s the federated approach. The thing that I will agree wholeheartedly with what Dave said, when we have worked interoperability at the data level what we have found is the biggest problem is legacy programs and their vendors don’t know their own systems. We might have to have them spend three to six months effectively reverse engineering their systems and documenting what their interfaces are, what their message types are, down to the semantics of those data to be able to use it in one of these ad hoc federated interoperability things.

 

Once we get to that point we can add interoperability after the fact without waiting for the big bang, but there has to be some degree of discipline. The good news is I think that’s something that we can define standards, not in terms of some monstrous data format, but in terms of best practices in terms of interface, and message, and data design protocols that make it discoverable — that make it usable, definable — that have a lot lighter lift and are a lot less controversial than saying ‘thou shalt comply with this thousand page data standard document.’

That was Tim Grayson at a Hudson Institute event, “Implementing Mosaic Warfare and Decision-Centric Operations.

This discussion adds a lot of color to my recent post on the competing views of JADC2 and mission integration. Of course I’m no expert in the technology, but the abstract order Grayson describes in after-the-fact interoperability seems far more intuitive, valuable, and practical than some fixed-global architecture that tops the minds of many JADC2 observers. DoD needs to adopt the coordinating principles found in the market, not central planning, because it allows for a vastly more complex action set that produces emergent behaviors far beyond the foresight of a small group of experts.

Proliferated LEO is a good example where commercial and government agencies are moving quickly for their own purposes. Government would have a hard time stopping and changing direction of its own internal developments, let alone commercial firms like SpaceX or OneWeb. A heavy handed approach to an architecture would simply remove commercial options from the DoD toolbox, slow development of military-unique products, and raise costs overall. Providing tools like Space BACN, STITCHES, MINC, etc., are a viable path to achieving speed plus interoperability.

Here’s an interesting chart from Grayson’s discussion on Space BACN:

4 Trackbacks / Pingbacks

  1. The Military’s Insistence on Owning Commercial Intellectual Property is Limiting Innovation - War on the Rocks
  2. The Military’s Insistence on Owning Commercial Intellectual Property is Limiting Innovation – Property News 4U
  3. linux smartsThe Military’s Insistence on Owning Commercial Intellectual Property is Limiting Innovation
  4. The Military’s Insistence on Owning Commercial Intellectual Property is Limiting Innovation - Get the latest news, cyrpto news, sports news - GloballNews.Press

Leave a Reply