It’s not the APIs

I’m seeing an increasing number of briefings and articles that essentially say, “New interface technology/formats will solve all our simulation interoperability problems.” They won’t. Simulation interoperability is a much more complex problem that rests on data formats, models internal to simulations, a long list of modeling and simulation federation agreements within simulations that have to align, and a woeful lack of documentation about all the preceding. I know this because I’ve been working on aspects of these problems for more than three decades. In fact, I’m currently working on a textbook on the subject.

The Simulation Interoperability Standards Organization (SISO) has been tackling these challenges since its formation in 1997. Most people who know of SISO are aware of our development and maintenance of the High Level Architecture (HLA) ¹ and Distributed Interactive Simulation (DIS) ² protocol. These two standards are essentially APIs for simulation interoperability. They have different technical approaches, but they both fundamentally move simulation data. And they’ve been doing an excellent job of that for decades.

The remaining major simulation interoperability challenges are either outside the APIs (conceptual modeling) or hidden behind them (composability), and they’re at the heart of federation engineering. For the broader context of where they fit in federation engineering, I refer you to the Distributed Simulation Engineering and Execution Process (DSEEP). ³

On the front end, conceptual modeling is the practice of describing, in a technology-neutral way, the entities, behaviors, and triggers that a simulation needs to model in order to meet the users’ needs. We can’t know if a simulation does what we need it to do until we know what we need the simulation to do. What we need a simulation to do should be captured in a conceptual model. However, almost no one actually does it, which means you’re often left guessing what a simulation actually does, even if you’re the one paying for it. For a new approach to solving this problem, see Multi-Viewpoint Conceptual Modeling (MVCM). ⁴ The conceptual model is the primary bridge between users and engineers. It’s early in the distributed simulation engineering and execution process (DSEEP), and as with all engineering processes, early failures in the process ripple across the rest of the process. APIs are later in the process. If you get the conceptual model wrong, your APIs will be wrong too.

Conceptual modeling leads to simulation composability, which hides on the far side of APIs. The biggest barrier to simulation composability is that you don’t get physics for free. You have to model them, and you have to pay for them. You pay for what you need and probably nothing more, which is sound program management right up until someone else wants to reuse your simulation. To do that, they need to know what physics you paid for and what you didn’t. This all seems reasonable until we come up against one of our recurrent failings: documentation. So much of what’s in our simulations isn’t documented; it only exists buried in the code and the heads of the engineers who wrote the code. We need to bring it out and write it down. I refer you to the Simulation Interoperability Readiness Levels ⁵ (SIRL) and Federation Engineering Agreements Template ⁶ (FEAT) standards. Once we have detailed documentation of the models in our simulations, we can reason about whether connecting their APIs will result in a valid simulation federation that meets our needs.

APIs are a solved problem. We need to focus our time, attention, energy, and money on solving the perniciously hard problems I’ve identified, applying the solutions we already have, and not reinventing the API wheel.