DIS 7 Integration: Session Identity, Time Context and Replay

Distributed Interactive Simulation (DIS) exchanges information between simulation applications. For the DIS 7 Entity State subset implemented by SynapseCommand, integration depends on three explicit inputs: the entity-state message, its session context and a caller-supplied state instant. Translating that message and replaying its unchanged bytes do not establish a connected simulator session or support for every DIS interaction.

The adapter catalogue states this scope directly. The useful engineering question is how to preserve a simulation entity's identity, time and original representation without silently adding assumptions that the message adapter does not own.

At a glance

The release-pinned DIS 7 manifest is the baseline for these claims. The package examined here is synapse-cdm v3.3.0; the adapter's own version is 1.0.0.

Start with the Entity State subset

An Entity State PDU is one message type within a much broader simulation protocol. IEEE's 1278.1-2012 catalogue entry describes application protocols spanning multiple families. Accepting one type does not establish support for simulation management, radio communications or other interactions.

The inspected adapter refuses other protocol versions, PDU types and protocol families. It accepts one PDU, not a capture file or a datagram containing several PDUs, and it does not open a network connection. Its input cap is 4,224 bytes for the supported Entity State layout, including the permitted variable parameter records. That is an implementation cap for this subset, not a universal maximum for DIS traffic.

The C2SIM integration analysis makes a related distinction for XML messages: a message adapter and an exercise session have different responsibilities. Here, the host application remains responsible for obtaining the PDU, identifying its exercise context and managing any transport or simulator connection.

Standards status also needs precise wording. IEEE currently lists 1278.1-2012 as Inactive-Reserved and lists the P1278.1 revision project as an Active PAR. A revision project is not a published replacement specification. Neither listing changes the implementation's declared subset or establishes certification.

Session context separates reused entity identifiers

The wire entity identifier consists of site, application and entity components. Those components are useful within their context, but reusing the same numbers in another exercise run should not automatically merge the two records into one historical entity.

The inspected adapter source derives identity using a namespace containing the caller's session and the wire exercise identifier, together with the site/application/entity tuple. The session is required. It is not discovered from the network or inferred from a filename.

This creates a concrete responsibility for the integration owner: choose and retain a session value that matches the intended scope. Reusing a session, exercise identifier and entity tuple reproduces the same canonical identity. Changing the session separates otherwise identical wire identifiers. The adapter does not decide when a new training run, reset or replay should constitute a new session.

The caller also supplies the synthetic flag. That flag records the classification supplied to the adapter; it is not independently established by inspecting the PDU. Likewise, force ID is retained without being turned into friendly or hostile affiliation. Canonical affiliation remains unknown because the adapter has no exercise viewpoint with which to make that judgement.

The state instant comes from an explicit time context

A field called “timestamp” can invite an unjustified conversion into wall-clock time. This adapter avoids that conversion: it preserves the DIS timestamp and uses an explicit caller-supplied time context for the canonical state instant.

The context contains an instant and a non-empty explanation of its basis. With raw PDU bytes, the adapter needs that context supplied through construction. With the structured envelope, context accompanies the decoded representation and original wire bytes. If both the adapter and envelope provide context, conflicting values are refused rather than silently preferred.

The adapter tests exercise missing and conflicting context and check that the adapter does not call the clock. A configured clock is therefore not a substitute for the required state-time explanation.

The preceding CAT062 provenance analysis examined time-of-day and processing context in surveillance tracks. DIS 7 has a different contract here: the state instant is explicitly provided rather than derived from the preserved wire timestamp. Applying another adapter's time rule would change the meaning.

For reproducibility, retain the instant and its basis with the session and original bytes. A valid date-time string establishes that the context is well formed, not that the caller chose the correct simulation instant. That remains an acceptance question for the host integration.

Coordinate conversion is not dead reckoning

The adapter converts an accepted Earth-centred, Earth-fixed position into WGS-84 latitude, longitude and height above the ellipsoid. The resulting canonical position is marked estimated. A zero ECEF vector is retained without inventing a geographic position at zero latitude and longitude.

Velocity handling is conditional. For the declared world-coordinate dead-reckoning algorithms 2 through 5, the adapter converts the supplied velocity into local horizontal speed, course and vertical rate where position can be projected. For other algorithm values, it preserves the velocity without performing that projection. The codec and projection helpers make this rule inspectable.

The conversion does not advance an entity through time. It is not an implemented dead-reckoning simulation, interpolation service or state-history manager. Course can also remain absent, including the defined zero-speed and pole cases, rather than being replaced by an arbitrary heading.

This distinction affects downstream displays. A projected coordinate and speed describe the supplied state under a documented transformation. If an application extrapolates motion, it introduces its own behavior and must identify that behavior separately. The architecture overview provides the broader separation between an adapter and the systems consuming its output.

Unchanged-byte replay is a specific output contract

The word “bidirectional” needs a narrower explanation for this adapter. Its output path takes one unchanged Entity produced from DIS 7 and replays the original PDU bytes. It is not a general-purpose route from arbitrary canonical entities to newly authored simulation messages.

Replay checks the stored representation, provenance and canonical projection for consistency. The raw bytes, decoded PDU and time context are retained in structured residual data. An output request cannot simply discard that data and expect the adapter to reconstruct the original message from latitude, longitude and speed.

The package also contains a lower-level PDU codec. Its ability to encode a decoded PDU must not be conflated with the canonical adapter's unchanged-Entity replay contract. The DIS 7 developer documentation is the appropriate API reference; this article concerns the integration boundary rather than replacing that reference.

Preserved bytes and source hashes have different roles

Not every preserved field becomes canonical meaning. Marking bytes, variable parameter records and unprojected dead-reckoning information remain available in the structured representation. Keeping those bytes supports inspection and replay; it does not establish that every field has been interpreted into a status, confidence or behavioral model.

The same precision is needed for source hashes. The core adapter can carry a supplied SHA-256 record and validate its format, but it does not calculate that digest over the PDU or independently establish its correctness. The inspected tests deliberately exercise a well-formed but wrong supplied digest being carried unchanged. A hash-shaped value is therefore not proof of verified content integrity.

The separate host tooling can supply additional services, but their existence must be distinguished from the adapter's own behavior. Replay consistency checks are not a cryptographic signature, authenticated simulator identity or tamper-proof historical record. Those properties require separately specified and tested controls at the appropriate boundary.

These distinctions are documented in the implementation record. It also records an opt-in comparison with a pinned OpenDIS implementation. The manifest states that the IEEE standard text was not consulted and identifies OpenDIS as the layout authority. That provenance should remain visible rather than being replaced by an unsupported normative-conformance claim.

A synthetic two-session handover

Consider two synthetic exercise runs carrying the same exercise identifier and the same site/application/entity tuple. In the first run, the host supplies session `rehearsal-a`; in the second, it supplies `rehearsal-b`. Each input includes a stated time context.

The two sessions should produce different canonical entity identities even if their PDU bytes happen to match. Reprocessing the first input with the same context should reproduce its identity. Neither outcome means the adapter opened a session with a simulator: the names are caller-supplied identity scope.

Next, retain the first Entity unchanged and request replay with matching context. The expected result is the original PDU bytes. Then change its canonical position and repeat the replay request. The expected behavior is refusal, not generation of a modified simulator update.

Finally, inspect whether the state instant and its explanatory basis survived. A byte match alone would not establish that the host supplied the right time or chose an appropriate session boundary. This is an illustrative acceptance exercise, not a report of a deployed simulator test or a new test run conducted for this article.

What the evidence and acceptance contract establish

The open integration package provides source, tests and packaged fixtures. The fixture documentation identifies the supplied vectors as synthetic, with a fixed fixture session and time context. They do not derive from recorded exercise traffic.

The manifest declares L4 based on this repository's evidence: a path-bound preservation ledger and byte-level fixture roundtrips. The generic fixture constructor supplies the packaged context and refuses live classification. Its harness verdict therefore applies to those fixtures; an unrelated exercise requires an adapter constructed with that exercise's actual context.

Source and tests were inspected for this analysis; no new tests or simulator exchanges were run. An opt-in implementation comparison and fixture replay evidence do not establish acceptance by a particular simulator, full DIS 7 support or IEEE certification. The trust and assurance boundary remains separate from the adapter's declared maturity level.

A useful DIS 7 handover makes the host's assumptions as reviewable as the message bytes. Session scope, state time and replay restrictions should be explicit before the receiving application treats a translated Entity as part of an exercise.