Mission rehearsal systems: architecture for pre-operation simulation

A training simulator teaches a unit how to fight in general. A mission rehearsal system (MRS) lets that same unit practise the specific operation it is about to execute – in a faithful digital reproduction of the actual area of operations, against the actual threat, following the actual plan. The distinction is not cosmetic. It changes the data that flows into the system, the speed at which a usable scenario must be produced, and the way success is measured. This article walks the full architecture of a mission rehearsal system: how terrain and threat data are ingested, how the scenario is authored from the mission plan, how distributed participants are synchronized, and how the after-action review is captured so the rehearsal actually improves the plan.

What a mission rehearsal system is – and is not

The doctrine behind rehearsal is old. Before any operation of consequence, leaders rehearse the plan – historically as a sand-table walkthrough or a rehearsal of concept (ROC) drill, with subordinate leaders physically moving markers across a scaled terrain model to confirm the scheme of manoeuvre and synchronize timing. A mission rehearsal system is the digital, higher-fidelity successor to that drill. It preserves the purpose – surface coordination gaps and contingencies before execution – but replaces the static terrain model with an interactive synthetic environment that includes simulated sensors, communications, weather, and a reactive opposing force.

The defining property of an MRS, and the one that separates it from a general training simulation platform, is that it is mission-specific and data-current. A training simulator runs against a stock map and a generic adversary; the goal is repeatable skill development. A mission rehearsal system runs against this valley, with this air-defence laydown, on the night the operation is planned. That requirement – currency over generality – drives every architectural decision downstream, because it forces the system to ingest fresh source data and turn it into a rehearsable scenario on operational timelines, not over the weeks a hand-built training scenario can take.

Architecture overview: five subsystems

A mission rehearsal system decomposes into five subsystems, each of which maps to a stage in the rehearsal lifecycle:

1. Terrain and environment ingestion. Converts source elevation, imagery, and feature data for the area of operations into a correlated synthetic environment. This is the longest-lead-time subsystem and therefore the one most often pre-staged.

2. Threat ingestion and behaviour binding. Imports the current enemy situation template and binds each threat entity to a behaviour model so the opposing force reacts rather than sits static.

3. Scenario authoring. Imports the friendly mission plan – graphics, timeline, triggers – and assembles it into a runnable, versioned scenario.

4. Distributed simulation runtime. Federates all participating sites into one synchronized scenario, maintaining consistent ground truth and time across links of varying quality.

5. After-action capture and review. Records the full run to a time-indexed log and replays it to drive the after-action review, closing the loop back into the plan.

The subsystems are sequential in the lifecycle but coupled in the data model: all of them resolve against a single shared ground truth – the ingested terrain – so that line-of-sight, weapon ranges, sensor footprints, and entity positions are all computed against the same surface the friendly force will move through.

Terrain and environment ingestion

Terrain is the foundation, and it is where mission rehearsal lives or dies on turnaround time. The ingestion pipeline takes elevation data – DTED Level 2 at a minimum, higher-resolution DEM where it is available – together with imagery or vector feature data describing surface materials, vegetation, road networks, and structures. From these it builds a correlated 3D environment: a height field, a classified material map that drives trafficability and radar/EO behaviour, and discrete features such as buildings and bridges that affect cover, concealment, and mobility.

The hard engineering problem is correlation. Every subsystem and every participating client must compute against the same ground truth – if the manoeuvre client and the fires client disagree about the elevation of a ridge by ten metres, their line-of-sight calculations will disagree and the rehearsal will produce phantom or missing engagements. The pipeline must therefore produce a single authoritative terrain database that all nodes load, rather than each client deriving its own surface. The detailed pipeline from source data to a runtime height field is covered in our article on terrain generation for military simulation.

Environment is the other half of fidelity. The execution-window weather and illumination must be applied: lighting and lunar illumination for a night assault, visibility and ceiling for an air movement, precipitation and soil state for trafficability. A rehearsal conducted in clear daylight for an operation planned in fog under no-illumination conditions trains the wrong expectations.

Threat ingestion and behaviour binding

A rehearsal against a static threat is little better than a map exercise. The value of an MRS comes from rehearsing against an adversary that reacts to friendly actions, so that the plan is tested against the enemy's likely responses rather than a frozen snapshot.

The threat subsystem imports the current enemy situation template: known and suspected positions, air-defence envelopes, obstacle belts, fire-support assets, and named areas of interest. Each threat entity is geolocated on the ingested terrain so its sensor coverage and weapon ranges are computed against the real ground. Crucially, each entity is then bound to a behaviour model from a maintained threat library – doctrinally grounded models of how that adversary's units move, emplace, and engage. This is where mission rehearsal connects to the broader discipline of computer-generated forces; the behaviour models used here are the same family discussed in our treatment of doctrine-driven adversary AI, scaled down to the specific units present in this area of operations.

Templated threat libraries

Because mission rehearsal is time-constrained, the threat picture is assembled from a pre-built library rather than authored from scratch. A maintained library holds parameterized adversary unit types – each with its sensors, weapons, mobility, and behaviour profile – so the intelligence cell instantiates and positions them on the terrain instead of modelling each one from nothing. The library is a living asset: as the threat picture evolves, the models are updated and versioned, and each rehearsal records exactly which library version it ran against, so a rehearsal can be reproduced or audited later.

Scenario authoring from the mission plan

The scenario authoring subsystem is where the friendly side of the rehearsal is assembled. Its design objective is to consume the mission plan as it already exists rather than forcing planners to re-create it. The unit's operational graphics – boundaries, phase lines, objectives, axes of advance, fire-support coordination measures – are imported directly into the authoring tool. Re-drawing them by hand is both slow and a source of error, because a hand-redrawn graphic can diverge from the order the unit will actually execute.

On top of the imported graphics, the author encodes the temporal logic of the rehearsal: the timeline, the triggers that initiate each phase, the conditions that advance the scenario, and the branches that must be exercised. A good MRS scenario is not a single linear script but a small decision tree – the rehearsal should be able to follow the primary course of action and also branch into the contingencies the plan must account for. Participants are then assigned to entities and roles, with each position designated as human-controlled or computer-generated.

Versioning is a first-class requirement. The rehearsal will expose problems, and the fixes feed back into both the plan and the scenario. The authoring tool must let an author add a branch or adjust timing without destroying the baseline, and it must record which scenario version produced which rehearsal run.

Distributed simulation runtime

The elements that must rehearse together – ground manoeuvre, aviation, fires, and the command post – are almost never co-located before an operation. Distributed participation is therefore not an optional feature but a core requirement, and it is the source of most of the system's runtime complexity.

The runtime federates all participating sites into a single synchronized scenario using a distributed simulation transport. The established standards are DIS (Distributed Interactive Simulation) and HLA (High Level Architecture); a modern implementation may instead use a publish-subscribe message bus with an interest-management layer. Whatever the transport, two invariants must hold: every node shares the same ground truth, and every node agrees on time. A divergence in either produces the worst class of rehearsal failure – one where participants see different versions of reality and draw confident but contradictory conclusions.

Maintaining those invariants across tactical links of varying latency and bandwidth – sometimes including the degraded networks the unit will actually fight on – is the central engineering challenge. Interest management limits each node's traffic to the entities it can perceive; dead reckoning smooths entity motion between low-rate updates; and a single authoritative time source prevents the clock drift that silently corrupts engagement adjudication. The mission rehearsal use case also benefits from being able to model the actual communications conditions of the operation, so that a rehearsal can deliberately impose the link degradation the unit expects rather than running on an idealized network.

After-action capture and the feedback loop

A rehearsal that is not reviewed is a rehearsal half-done. The capture subsystem records the entire run – every entity track, engagement, communication event, and operator decision – to a time-indexed log. The volume is significant, so the log is structured for selective replay rather than as an opaque dump: an analyst must be able to scrub to a moment, replay it from any participant's perspective and from a god's-eye view, and answer why a coordination failure occurred.

The after-action review is where the rehearsal earns its cost. It surfaces the coordination gaps, timing problems, and missed contingencies that the plan contained, and it does so while they are still cheap to fix. The output is not a grade but a set of changes – to the plan, the synchronization matrix, and the scenario itself. Those changes are folded back in, and the affected branches are re-run to confirm the fixes hold. This closed loop, run on operational timelines, is the entire point of the system. The same capture-and-replay machinery underpins related capabilities such as a digital twin of military equipment, where recorded behaviour drives both training and predictive analysis.

Where mission rehearsal sits in the simulation stack

A mission rehearsal system is not a standalone product so much as a specialized configuration of a broader simulation platform. It shares its terrain pipeline, its distributed runtime, and its after-action tooling with constructive and virtual training systems; what it adds is the discipline of currency – fresh data, mission-specific scenarios, and turnaround measured in hours. An organization that already operates a capable training simulation infrastructure can extend it into mission rehearsal by investing in fast ingestion, a maintained threat library, and a scenario authoring tool that speaks the language of operational graphics. An organization that builds an MRS in isolation, without that shared foundation, tends to rebuild the same subsystems badly.