Throughout it all, one thing has remained constant: the need for interoperability between distributed simulations and applications that mimic real-world operational environments.

At the Military Virtual Training and Simulation Summit, I shared why the industry must move beyond legacy assumptions about interoperability, and how a modular, open systems approach built around a Common Synthetic Environment is proving itself across major defense programs today. As promised in my presentation teaser, I’d like to shed some light on this topic that’s so near and dear to my heart. (And please join my upcoming webinar on March 10 at 11:30am Eastern where I'll dive into this live!)

When Network Interoperability Was “Good Enough”

In the early days of networked simulation, interoperability meant something very specific and very limited. Training devices typically shared a single, hand-modeled terrain database. Scenarios were largely static, often set at midday, under clear skies. If platforms could exchange position and interaction data, that was enough to create a shared view of the operational environment.

For its time, that approach worked. But the operational and training demands we face today have fundamentally changed. 

Why Network Interoperability Alone No Longer Works

Modern simulation applications don’t just consume static, hand-modeled databases like in days past. Beautifully realistic immersive worlds are procedurally generated from source data such as DTED, GIS feature data, Open Street Map (OSM) data, land use data, etc. Terrain is deformed based on battlefield effects, such as craters, ditches, or berms. Exercises operate at all times of the day in all weather, including rain, snow, and fog. Weather is local and affects not just the visualization domain, but also the simulated entities slowing mobility and affecting sensors and visibility. Military scenarios include civilian clutter such as traffic, civilian air (via ADSB), and civilian naval (via AIS). All of this complexity has led to more realistic training environments, but at the expense of interoperability. 

In this context, simply exchanging entity state over a network is no longer sufficient. 

The Case for a Common Synthetic Environment

Without a Common Synthetic Environment, training systems drift out of sync, realism degrades, and integration costs increase. 

A modern collective training system, depicted in the diagram below, is an ecosystem comprised of a representation of the synthetic environment (terrain and weather), a Computer Generated Forces (CGF) application used as an Instructor Operator Station (IOS) and Threat Generation, and Virtual Trainers used by soldiers, airmen, and marines during the training event. IOS and Virtual Systems share a similar architecture. This architecture includes:

• A Synthetic Environment Engine (terrain engine) to procedurally generate an immersive twin of the operational environment representing terrain, features, and weather for both simulation and visualization.
• A Simulation Engine for computer-generated and controlled platforms, weapons, sensors, and communications. 
• A Visualization Engine for 2D tactical and 3D immersive out-the-window and sensor views. 

What makes each collective training component unique are the use case-specific models, content, behaviors and user interfaces used within the application to transform each CGF and virtual trainer into an emulation of the trainee’s operational environment.  

What if each component of the collective training environment used the Same Synthetic Environment engine, the Same Simulation Engine, and the Same Visualization Engine? The CGF and Virtual Trainers would share the same representation of weather, time of day, location of procedural trees and clouds. They would share the same simulation engine, allowing seamless hand-off between a CGF-controlled entity and a virtual player. They would load the same scenario, use a shared model set, and be seamlessly controlled by the same IOS, without any additional development. Their visual representation would be identical. 

By using the same Common Synthetic Environment, they achieve true interoperability.

To make this dream a reality, the chosen Common Synthetic Environment must follow an open design with well-supported and documented open APIs, allowing for both platform-specific customization and third-party and partner integration. 

Just as important, it must be built on open standards, not proprietary lock-in. Programs need the freedom to bring in new platforms, new vendors, and new capabilities over time without rearchitecting the entire system.

This is the philosophy behind MAK ONE: open systems, open standards, and open APIs, with a terrain-agile, single simulation engine that supports both virtual and constructive training, at both the entity and aggregate level. 

The Gladiator program for the UK Royal Air Force is a great example. Awarded in 2019 and achieving IOC in 2023, Gladiator established a MAK ONE–based Common Synthetic Environment first. Platform-specific trainers from multiple vendors were then developed on top of that shared foundation. The result was a scalable, multi-vendor training ecosystem that earned NTSA’s 2023 Acquisition Program of the Year. More details about Gladiator here.

The Australian Defence Force’s LS Core 2.0 program followed the same acquisition strategy. A common environment was delivered first, followed by successive trainer developments for platforms like M1A2, Boxer, and Redback. Today, LS Core is entering sustainment, with OEMs continuing to build and evolve trainers on the same shared synthetic backbone. More details about LSCore here. 

Different countries and different platforms. Same acquisition approach and same outcome.

An Ecosystem That Encourages Innovation

One of the most powerful advantages of an open Common Synthetic Environment is the ecosystem it enables. With MAK ONE, the sum is greater than the parts. The MAK ONE Ecosystem is a thriving environment where third parties have developed powerful MAK ONE-compliant modules that appear to the end user to be seamlessly integrated into the MAK ONE environment. These MAK ONE-compliant modules were independently developed by the third party solely using the MAK ONE API. 

Examples of the MAK ONE ecosystem include:

• Full fidelity Tactical Data Link (TDL) Modular, TDL for VR-Forces, developed by CogSim 
• Electronic Warfare and Radar Module, EWAS for VR-Forces, developed by RT Dynamics
• AI-based Course of Action (COA) Analysis tool, HIVE for VR-Forces, developed by Cervus 

Can’t forget about AI

AI is not a replacement for sound simulation architecture. But when it’s used within an open system, open API Common Synthetic Environment, it becomes a force multiplier.

The MAK ONE Ecosystem is exploding with AI-based applications that provide natural language-based scenario generation and AI-driven entity behaviors, and apply reinforcement learning to refine entities' actions in real-time. Examples of AI-based MAK ONE Modules include:

• Scenario AI’s IDEA: Generate executable scenarios from high-level operational orders 
• MAK’s NICO AI-Generated Behaviors: Create AI-driven behaviors that transform OPORDs into complex, dynamic plans 
• RT Dynamics’s RL-based Dog Fighting: Apply reinforcement learning to domains like air combat, enabling adaptive adversary behavior 

The Open Path Forward

Programs that prioritize open systems, shared common synthetic environments, and modular acquisition strategies are proving they can scale faster, integrate more partners, and adapt to emerging technologies, all without sacrificing realism or control.

After more than 30 years in this field, I’m convinced of one thing: the future of collective training belongs to programs that design for openness from day one.

And the good news is that we’re already seeing that future in action.

If you're interested in learning more about the MAK ONE ecosystem, reach out anytime to This email address is being protected from spambots. You need JavaScript enabled to view it.