We use the term ‘mosaic’ in the context of what we call Mosaic Warfare. If you look at where the DOD has been heading, it’s moving toward what I’ll call a system of systems type of approach. Instead of having the weapons, the comms, the sensors, the decision aids, all tightly integrated together into one platform, they’re very disaggregated.
… Today, if someone says, ‘Hey, I want to swap out sensor A and bring in sensor B.’ That’s a manual engineering process to do that integration. We’re trying to create the tools and the infrastructure to make that composition of architectures much easier and faster, so that ultimately it doesn’t even require engineers to be involved in designing things. It’s almost more of an operator saying, ‘Here’s the architecture that I want.’ And then technician-level people use Mosaic tools to configure it and make it so. It greatly reduces the time required to create very complex, machine-centered, cyber-physical architectures.
While it’s not in our core mission, from a dual-use perspective there’s an analogy to the commercial world with the so-called Industrial Internet of Things or IIoT. Mosaic Warfare is helping the military deal with a very heterogeneous mix of different domains, different military Services, different ages of equipment, and legacy systems. That’s a very similar problem that the commercial IIoT world is dealing with in areas such as the smart grid, advanced manufacturing, distributed supply chains and advanced transportation.
All of those market verticals trying to get to new levels of digitization and modernization through the IIoT have this problem of building systems and systems architectures without throwing away the legacy, in-place, really expensive electromechanical equipment that still works. We have billions and billions of dollars of sunk cost in legacy equipment. So, the IIoT world needs to be able to digitize and modernize over this very heterogeneous fabric of legacy stuff. And that’s effectively exactly what we’re trying to do for the DOD.
That was DARPA’s Tim Grayson talking about the suite of tools they are developing for ad hoc interoperability as opposed to relying on global standards. Congress and DoD have been obsessing over modular open systems architectures in recent years (and decades).
However, even DoD was completely successful defining standards (e.g., the sensor open system architecture was just released), and then mandating them on every development going forward — the vast majority of the force structure would still be “legacy.” It would require many years of manual development to re-engineer the legacy systems to the new standards — basically unaffordable and not realistic. Grayson mentioned earlier that many of the standards/interfaces of existing systems were so badly documented by the contractors that it took them three to six months to reverse engineer their own products.
That’s perhaps the clearest articulation of the requirement for a federated approach to interoperability. Even the perfect MOSA standards would fail to (1) release DoD from vendor lock on legacy programs; and (2) connect these programs into a larger command and control framework. And even if legacy systems were manually translated into the new standards, by the time all that is finished there will be new technologies that demand new standards and DoD may find itself in a never ending chase for that “perfect” global architecture.
I was interested to hear this from Bill Joo, a Navy engineer working on Military SATCOM and the Digital IF Interoperability Consortium, speaking on the the Constellations Podcast:
So, open standards and interoperability has been sort of the notional, or should we say the windmill that we’ve been seeking for quite some time. But the problem with standards are that there are too many standards. So, you may be implementing an open standard, but that does not guarantee interoperability or the ability to expand the capabilities beyond what you had intended for the system. So, we’ve been pursuing more along the lines of what’s called P3I, which is Preplanned Product Improvement. With P3I, we will actually define a limited set of standards that we plan against for the future versus letting open standards dictate where we go in the future.
Leave a Reply