Intersim

Latency is a geometry problem

In distributed flight simulation, communications latency cannot be treated merely as a desirable network-performance number. It directly becomes positional uncertainty.

If one simulator receives another aircraft's position late, it is not displaying where that aircraft is now. It is displaying, or extrapolating from, where that aircraft was when the transmitted state was generated. As closure rate increases and separation decreases, even a small amount of state age can produce a significant spatial error.

Therefore an interoperability profile should not simply specify "low latency." It should define a maximum permitted aircraft-state age derived from the operational geometry, permitted positional error, relative velocity, maneuver rate, clock uncertainty, and prediction error.

One-way state age

The quantity that matters for aircraft positioning is the age of the source state when it becomes usable by the receiving simulator. Round-trip ICMP ping time is not sufficient to establish this.

The end-to-end budget includes:

• source simulation integration and scheduling delay;
• state extraction and serialization;
• operating-system and network-stack delay;
• network propagation and queueing;
• receive buffering and deserialization;
• interpolation or dead-reckoning delay;
• application scheduling; and
• presentation to the receiving simulation.

Timestamp the source state

Each aircraft-state message should identify the simulation time at which the transmitted state was valid. Receiving systems should calculate age from that timestamp rather than assuming that packet arrival time is the state time.

That requires sufficiently synchronized simulation clocks and an agreed time representation. The permitted clock uncertainty must itself be part of the latency/error budget.

Distributed simulation commonly predicts remote entity motion between updates. This reduces visible discontinuities and allows useful operation at update rates lower than the visual frame rate.

However, prediction cannot make communications latency disappear. Prediction works best while velocity and acceleration remain close to the assumed motion model. Error grows when an aircraft begins an unexpected turn, roll, flare, rotation, braking maneuver, control input, or other change that the remote simulator has not yet received.

Therefore a standard should specify both the prediction method and the maximum time for which predicted state may substitute for fresh state. When that interval is exceeded, the receiving system should identify the aircraft state as stale rather than silently presenting increasingly uncertain geometry as authoritative.

Every shared aircraft state should define

• a unique entity identifier;
• the coordinate reference system;
• position and altitude;
• linear velocity;
• orientation;
• angular velocity where required;
• acceleration where required by the prediction model;
• the source-state timestamp;
• the prediction or dead-reckoning model in use;
• the validity or freshness interval; and
• quality or uncertainty information where available.

Every interoperability profile should define

• the operational interaction class;
• maximum permitted positional error;
• maximum permitted orientation error;
• maximum source-state age;
• maximum jitter or latency variation;
• minimum state-update behavior;
• clock synchronization accuracy;
• packet-loss behavior;
• stale-state behavior;
• prediction-error thresholds; and
• the conformance test used to verify all of the above.

Continuous aircraft motion can often be predicted for a short period. Discrete events cannot always be predicted. Gear contact, arrestment, weapons release, collision, docking, refueling contact, failures, and other event transitions may require separate delivery and ordering rules.

An interoperability standard should therefore define latency and reliability requirements by information class rather than treating all simulation traffic identically.

This work need not replace established distributed-simulation architectures. IEEE Distributed Interactive Simulation (DIS) defines network Protocol Data Units for exchanging simulated entity state and interactions, while IEEE High Level Architecture (HLA) provides a common framework for interconnecting interacting simulations.

A Flight Simulator Interoperability Profile can build on such transport and federation mechanisms while defining the flight-specific semantic, timing, geometry, freshness, and conformance requirements needed for aircraft operating in close proximity.

The central question is therefore not simply: Can two simulators exchange aircraft data? The stronger interoperability question is: Can they exchange sufficiently current, sufficiently precise, unambiguous aircraft state to preserve the required relative geometry throughout the intended flight operation?