military-lvc-sim

How it is built

Architecture overview

A live-virtual-constructive (LVC) training system lets real units, simulators and software-driven forces share one battlespace. Live means real people and vehicles on a range, carrying instruments that report position and events. Virtual means crews in simulators (a cockpit, a vehicle trainer) who are real operators of simulated equipment. Constructive means computer-generated forces (CGF) whose entities act on scripted or rule-based behaviour, steered by a few staff operators. None of these programs knows how the others work internally. They are glued together by a shared object model, a network protocol that carries entity state and interactions, and a clock all of them agree on.

The one idea that makes it work is separation of the exercise from the programs. Each program (a federate, in HLA terms) owns its own entities and publishes their state in a common vocabulary; everyone else subscribes to what they need. Nothing assumes a central world server. Two standard families carry the traffic: the High Level Architecture (HLA, IEEE 1516) with an RTI that manages joins, subscriptions and time, and the older Distributed Interactive Simulation protocol (DIS, IEEE 1278.1) where each simulator broadcasts entity-state packets and listeners filter. DDS is a third option with the same publish-subscribe shape and tunable quality of service. Proprietary products (Bohemia VBS4, OneSAF, JCATS) implement these ideas and add content; this page is about the shared mechanics.

Two problems then dominate. Scale: thousands of entities each publishing at a few hertz would flood every participant, so traffic is cut by dead reckoning and interest management. Time: a constructive model may run faster than real time, a live range cannot, and the hybrid must stay causally consistent.

Parts:

• Federation middleware — joins, publish/subscribe, ownership, time management — hla-rti-federation (no page yet), data-distribution-service (no page yet), IP multicast, Message sequence numbers
• Interest and data reduction — decide who receives which update — Interest management, Spatial hashing, quadtree-octree (no page yet), d-ary heap
• Time and clocks — a common wall clock and a logical simulation clock — Clock synchronization, PID controller, Phase-locked loop (digital), Robust statistics
• Constructive engine — event-driven models and agent behaviour — discrete-event-simulation (no page yet), agent-based-modeling (no page yet), PRNGs (PCG, xoshiro), Structure of arrays and hot/cold splitting
• Behaviour and movement — decisions, routes, line of sight — behavior-trees (no page yet), Hierarchical state machine, navigation-mesh-pathfinding (no page yet), A* search, Bounding volume hierarchy, delaunay-triangulation (no page yet), polygon-tessellation (no page yet)
• Platform physics and geography — movement of one vehicle, coordinates on the Earth — Rigid-body dynamics, Semi-implicit Euler, Quaternion rotations, map-projections (no page yet), Geodesic distance (haversine, Vincenty, Karney), floating-origin-rebasing (no page yet), ray-primitive-intersection (no page yet)
• Wire format and state sharing — compact packets, smooth remote entities — Bitstream serialization, Entity interpolation, Fast hash functions
• Outcome models and analysis — kill probabilities, repeatable runs, after-action review — Monte Carlo integration, record-replay (no page yet), rejection-sampling (no page yet)

 live range           simulator (virtual)         CGF / constructive
 instrumented units   cockpit, vehicle trainer    event engine + behaviours
       │ GPS+radio          │                          │
       ▼                    ▼                          ▼
   gateway ───────►  federate / DIS node  ◄────  federate (entities, PRNG streams)
       │                    │                          │
       └─────── publish entity state, interactions ────┘
                      HLA RTI  |  DIS multicast  |  DDS
              ┌───────────────┴────────────────┐
        interest management            time management / wall-clock sync
        (grid cells, regions)          (lookahead, LBTS, NTP/PTP)
              └───────────────┬────────────────┘
                      per-receiver filtered stream
                              │
              display / sensor model / AAR recorder ──► replay store

How the parts fit together

Federation middleware: HLA, DIS or DDS

The choice sets how much the middleware does for you. In HLA, federates join a named federation execution through a runtime infrastructure (RTI) and agree on a federation object model (FOM) that names the object classes, attributes and interactions. They declare what they publish and subscribe to; the RTI routes updates and also provides ownership transfer, save and restore, and time management (IEEE 1516-2010 defines the interface and object model template). hla-rti-federation (no page yet) is the block that covers this. DIS has no middleware: each simulator sends entity-state packets over UDP, typically broadcast or multicast, and every listener decides what to keep. It is simple, needs no central process and has no built-in time management, which suits real-time training and not much else.

data-distribution-service (no page yet) is the generic alternative: a data-centric publish-subscribe bus with discovery and explicit quality-of-service policies (reliability, history depth, deadline). The OMG DDS specification defines the model and the DDSI-RTPS specification defines the wire protocol that makes products interoperate. Use it where you want one bus for simulation, sensors and tooling and can express your object model as topics. Its reliability layer rides on IP multicast for fan-out and uses sequence numbers to detect loss (Message sequence numbers), with selective-repeat-arq (no page yet) style repair for reliable topics.

The contract between middleware and application is small: a federate hands over typed attribute updates with a timestamp, and receives callbacks. Everything below that (multicast groups, retransmission, discovery) should be invisible to the model code. The practical consequence is that the same CGF can be moved from a DIS network to an HLA federation by swapping a gateway, and such gateways are a standard part of LVC.

Interest management: send each receiver only what it can use

A battalion-level exercise has far more entities than any one participant can sense. Interest management cuts traffic with a region test: a sensor model subscribes to the cells around its own platforms and receives only the entities whose position falls inside. HLA calls the equivalent service Data Distribution Management; in DIS-style systems the same effect comes from mapping grid cells to multicast groups, so the network, not the receiver, discards irrelevant updates.

The grid itself is Spatial hashing for dense, evenly sized entity populations, or quadtree-octree (no page yet) when density varies a lot (a town next to open terrain). Per-receiver outgoing queues need a priority order so that a near, fast, recently changed entity goes first when the bandwidth budget is exhausted; a d-ary heap keeps that queue cheap. The contract: the producer never knows who is listening, and the filter is conservative (a slightly too large region is acceptable; a missed entity is a visible bug).

Time and clocks: two different problems

There are two clocks. The wall clock has to agree across a range, trailers and simulators so that a live instrument report and a simulator's shot refer to the same instant. Clock synchronization provides the offset estimate (NTP, RFC 5905, or PTP, IEEE 1588-2019, when sub-millisecond agreement is needed), and a PID controller or Phase-locked loop (digital) steers the local clock smoothly instead of stepping it, so timers and interpolation never run backwards. Robust statistics (median filtering of offset samples) keeps one delayed packet from skewing the estimate.

The simulation clock is logical. Real-time exercises simply tie it to the wall clock. Analysis runs and constructive-only federations use conservative time management: each federate declares a lookahead and may advance only to the lower bound of the earliest message another federate could still send (the RTI computes it as the lower bound time stamp), so no event ever arrives in a federate's past. The price is that the slowest federate sets the pace and a small lookahead serialises everything.

Constructive engine: events and agents

CGF models are driven by discrete-event-simulation (no page yet): a time-ordered event queue (a d-ary heap is the usual priority queue) pops the next event, runs it, and schedules more. Determinism matters here: the same seed and the same input must give the same outcome, otherwise an analyst cannot compare two plans. That means a seeded generator per entity or per stream (PRNGs (PCG, xoshiro)) and no dependence on thread timing.

agent-based-modeling (no page yet) adds individuals with local rules (a squad that moves, observes, shoots). Large populations are stored as Structure of arrays and hot/cold splitting so that the per-tick loops over position and health stay cache-friendly. The seam to the network is narrow: the engine owns its entities and publishes their state at an update rate, and subscribes only to what its sensor models need.

Behaviour and movement

Decisions are written either as behavior-trees (no page yet) or as a Hierarchical state machine; they are alternatives. Trees compose reusable tasks (move to, scan, engage) and are easy for non-programmers to edit; state machines make the allowed transitions explicit and are the better fit when a unit has a strict doctrine such as "halt, observe, report". Movement uses navigation-mesh-pathfinding (no page yet): a walkable mesh of polygons, A* search over polygon adjacency, then a smoothed path. Building that mesh from terrain needs delaunay-triangulation (no page yet) and polygon-tessellation (no page yet). Line-of-sight checks against terrain and buildings use a Bounding volume hierarchy with ray-primitive-intersection (no page yet). Route planning on road graphs is classical shortest-path (Dijkstra's algorithm) and BFS and DFS for reachability.

Platform physics and geography

Each vehicle or aircraft has a modest dynamics model: Rigid-body dynamics, advanced with Semi-implicit Euler and orientation kept as a Quaternion rotations state. Exercises span hundreds of kilometres, so positions are kept in an earth-centred frame for exchange and in a local frame for models. map-projections (no page yet) and Geodesic distance (haversine, Vincenty, Karney) convert and measure; floating-origin-rebasing (no page yet) keeps single-precision rendering accurate near the viewer. A mismatch of datums between participants shows up as a fixed offset between where a simulator and the CGF think the same object is, which is why the coordinate frame is part of the federation agreement and not a local choice.

Wire format and remote entities

State is sent in packed form: Bitstream serialization writes each field in only the bits its range needs, and the sender includes a dead-reckoning model (position, velocity, acceleration, orientation rate) so that the receiver can extrapolate between packets. The sender runs the same extrapolation locally and sends a new update only when the true state drifts past a threshold, or on a periodic heartbeat so that late joiners and lost packets are corrected. The receiver then draws remote entities with Entity interpolation, which smooths the corrections instead of snapping. Fast hash functions map entity identifiers to table slots and to multicast groups.

Outcomes and replay

Engagement results are probabilistic. A hit or kill is drawn against a table that depends on range, aspect and weapon, and an analyst runs the scenario many times: Monte Carlo integration describes why error falls with the square root of the number of runs. rejection-sampling (no page yet) is the filter used to keep only runs that meet a scenario condition. After-action review depends on record-replay (no page yet): record every entity-state message and every non-deterministic input with its timestamp, and the exercise can be replayed for debriefing, or re-executed to reproduce a disputed engagement.

Data and control flow

One entity update, from a tank simulator to a remote display:

1. The simulator's physics step (Semi-implicit Euler) advances the vehicle; its dead-reckoning copy predicts where remote nodes believe it is.
2. If the true position differs from the prediction by more than the threshold, or the heartbeat timer expires, an entity-state update is built.
3. Bitstream serialization packs it with a sequence number (Message sequence numbers); the middleware sends it to the group for the sender's grid cell.
4. The network copies the datagram to every receiver joined to that group (IP multicast); receivers outside the area never see it.
5. A receiver checks the sequence number, discards duplicates, extrapolates to the render time and blends towards the new state (Entity interpolation).
6. The recorder, subscribed to everything, writes the packet with its timestamp for replay.

One time-managed constructive step:

1. Each federate computes its next event time and requests a time advance, declaring its lookahead.
2. The RTI computes the safe bound over all time-regulating federates and grants advances up to it, delivering timestamped messages in order.
3. The federate runs its events up to the granted time, then publishes new state and requests the next advance.
4. The slowest federate or the smallest lookahead determines the exercise's speed.

One live-range join:

1. A range gateway reads instrument reports (GPS position, weapon events) and converts them to entity state in the federation's coordinate frame.
2. It publishes them like any other federate; wall clocks are synchronised first, otherwise live and virtual events cannot be ordered.
3. Simulated effects flowing the other way (a simulated hit on a live vehicle) travel back through the gateway to the instrument, which tells the crew.

Scaling

In the order you hit them:

1. Network fan-out. Updates per second times receivers. Levers: dead reckoning thresholds, Interest management with grid-to-group mapping, lower update rates for distant or slow entities.
2. Receiver CPU. Each participant filters and decodes the traffic it receives. Levers: tighter regions, binary packing, a gateway that aggregates a remote site into one summarised stream (a common design for wide-area links).
3. Federation time pace. Conservative time management is limited by the slowest federate. Levers: larger lookahead, fewer time-regulating federates, run constructive-only analysis offline faster than real time.
4. CGF entity count. Per-tick agent work. Levers: Structure of arrays and hot/cold splitting, level-of-detail (aggregate a platoon into one entity when nobody looks), stepping in parallel with per-thread random streams so results stay repeatable.
5. Analysis volume. Many Monte Carlo runs. Levers: independent runs on many machines, variance reduction, early stopping when the estimate is tight enough.
6. Wide-area links. Latency and loss on the link between sites. Levers: a gateway per site, reliable transport only for state that must not be lost, best-effort for the periodic updates that heal themselves.

Failure modes

Real implementations

Proprietary products from the graph (Bohemia VBS4, OneSAF, JCATS) are named for orientation and are not linked here: they are commercial or government-controlled and I did not verify an official public document for each.

The alternative: a single-process game engine with a custom protocol works for one site and one vendor. LVC standards earn their cost once several vendors, several sites or live instruments must join the same exercise, and when the customer demands interoperability by contract.

Sources

• IEEE 1516-2010, Standard for Modeling and Simulation High Level Architecture. IEEE SA
• OMG, Data Distribution Service specification. spec; DDS Interoperability Wire Protocol (DDSI-RTPS). spec
• S. Deering, Host Extensions for IP Multicasting, RFC 1112, 1989. RFC
• D. Mills et al., Network Time Protocol Version 4, RFC 5905, 2010. RFC
• IEEE 1588-2019, Precision Time Protocol. IEEE SA
• IEEE 1278.1 (DIS), cited by number; its PDU structure is implemented in open-dis-java.
• Portico: README; CDDL text