This year I published a paper and an implementation on translating between MIL-STD-1553B and STANAG 4586, and wrote about how the project came to exist. What I did not expect was that almost none of the conversation afterwards was about the engineering. It was about why a problem everyone has known about for decades is still open.

That is the more interesting question, and the answer is not technical. It is that the integration layer sits between budget lines, and nothing between two budget lines ever gets bought.

The problem in one paragraph

A modern military operates platforms designed across a span of fifty years. A combat aircraft from the 1980s uses an avionics bus standardised in 1973. An unmanned system entering service now uses a NATO standard written around 2004 with a completely different architecture. A ground vehicle, a naval asset and a satellite each use something else again.

Every one of these was procured separately, to its own requirement, on its own timeline, from its own vendor. Each is internally coherent. Together they cannot exchange the operational data that would make them useful as a system.

Why the standards diverged

Worth being precise here, because the obvious explanation, that nobody thought about it, is not correct.

MIL-STD-1553B is built around a bus controller with complete authority over all communication. Everything is scheduled. The bus is deterministic, which is exactly what you want for flight-critical avionics where a message must arrive within a bounded time. It is a 1973 standard and it has worked for fifty years, which is a remarkable engineering record.

STANAG 4586 is built around a disaggregated architecture, with a vehicle-specific module handling the platform side and a core control system handling the operator side, connected over a network. It is designed for a different problem: letting one ground station command unmanned vehicles from different manufacturers.

These are not competing solutions to one problem. They are correct solutions to different problems, and they embody different assumptions about where authority lives in a system. That is why translating between them is harder than remapping fields. Some concepts in one have no counterpart in the other, and the honest engineering response is to record what was dropped or approximated rather than to pretend the mapping was clean.

The arithmetic

If you connect systems pairwise, N systems require on the order of N squared translators. Ten systems is ninety directed pairs. Adding one system means building translators to every existing one.

The alternative is a hub: define a protocol-agnostic common internal representation, and build one adapter from each system to it. N systems then need 2N adapters, and adding a system means writing two.

This is not a novel insight. It is the same structure as an intermediate representation in a compiler, and it has been rediscovered in every domain with a proliferation of formats. It is the correct answer, it is available, and it is cheap relative to a single platform it would connect.

Which raises the actual question.

Why it stays unsolved

It is nobody’s programme. A procurement buys a platform. The requirement specifies what the platform does. Interoperability with a system bought by a different service in a different decade is somebody else’s requirement, and in practice it is nobody’s, because it lives between two budget lines.

It has no announcement. A new aircraft is a photograph, a ceremony and a headline. A translation layer that lets two existing systems share targeting data is a diagram. Both matter to capability. Only one produces a moment. Attention and funding follow the moment, and this is not cynicism about defence specifically, it is true of every large organisation.

Vendors have the opposite incentive. Proprietary gateways are a product. Opaque, expensive, non-auditable and functional. A vendor with an installed base of gateways has no reason to want an open translation standard, and the customer’s dependency is the business model. That is the dependency reduction argument for building domestically, and it applies well beyond defence.

It requires deep knowledge of two things nobody knows both of. Somebody has to understand 1553 avionics at the level of a systems engineer who has worked with it, and 4586 the same way. Those are different careers. Reading both specifications in parallel is a strange experience and there is no natural population of people who have done it.

The failure is invisible until it matters. Two systems that cannot exchange data still work individually. Nothing is broken in peacetime. The cost appears only when they need to operate together, which is exactly when there is no time to fix it.

The part that is genuinely hard

I want to be careful not to make this sound easy just because it is unglamorous.

The syntactic part, moving bits between formats, is straightforward engineering. The semantic part is not.

The same word means different things in two standards. Position, in one system, might be a location at a stated time in a stated frame with a stated accuracy. In another it might carry different frame conventions, different time references and different implicit assumptions about latency. Mapping one to the other requires deciding what to do when the concepts do not align, and there is often no correct answer, only a documented choice.

Timing models differ. One standard assumes deterministic delivery within a bounded window. The other assumes a network. A translation layer sits between two different theories of when a message exists.

And the errors are silent. A translation that drops a field or approximates a value produces output that looks valid. Nothing throws an exception. The receiving system acts on a number that lost meaning in transit.

This is why the audit logging turned out to matter more to practitioners than the architecture. If you are the person who has to explain to a review board why a value was approximated, a per-field record of every translation decision, including the lossy ones, is worth more than an elegant design. That was the most useful thing I learned from publishing, and I would not have learned it from writing more code.

Why I keep working on it

It is a solved problem in the sense that the architecture is known and the engineering is tractable. It is unsolved in the sense that it has not been built, openly, in a form anyone can audit and extend.

The gap between those two states is not technical. It is that nothing in the incentive structure of large procurement rewards building the layer between the things being procured.

Which makes it a good problem to own. The hard parts are known, the value is real, the credit is low, and that combination means the field is not crowded. Unglamorous and structurally underfunded is a description of a market, not a warning. I intend to keep building in it.

Related: