C2SIM Integration: From XML Messages to Simulation Sessions

C2SIM integration connects structured command-and-control information with simulation systems. Its name expands to Command and Control Systems to Simulation Systems Interoperation. For an engineering team, the critical distinction is between translating a message and establishing a working exercise session. A document adapter can preserve identifiers, interpret reports and emit supported XML without connecting to a server, synchronising participants or proving that another system uses the information correctly.

The SISO C2SIM standard provides the wider exchange framework. SynapseCommand's public adapter offers a concrete case study in how to define and test a bounded part of that framework.

At a glance

These implementation claims come from the C2SIM manifest, corroborated by the current adapter catalogue. L4 is a scoped engineering-evidence level. It is not a product readiness level, a standards-body certificate or proof of compatibility with every simulator.

The document and the session are different contracts

C2SIM describes an exchange environment involving information producers, consumers and supporting services. Its Land Operations Extension adds domain-specific content to the Core and Standard Military Extension, as described in SISO-STD-020-2020. That scope is broader than a library converting one document into another representation.

For this implementation, the responsibilities divide as follows. The table is an editorial interpretation of the published adapter and exercise-client boundaries.

The architecture overview helps locate the public integration layer within SynapseCommand. Its existence does not remove the need for a separately configured and assessed connection to an exercise environment. Responsibilities should be assigned explicitly before a successful local import is reported as a completed integration.

What the published adapter translates

The adapter source defines a specific mapping. Initialisation content can produce canonical Entities for force sides, units and supported platform classes, plus Route PlanObjects for route graphics. Other admitted object classes may remain untyped in residual content rather than becoming dedicated canonical objects.

Position reports produce Events associated with their subjects. Observation reports and task-status content also become Events, with source vocabulary retained. The distinction matters: a report about a unit is a record concerning that unit, not automatically a new unit identity.

Orders use a named payload contract and a PLAN_INJECT Event. The supported task-action forms are limited to `MoveToLocation` and `HoldInPlace`. Unsupported actions are refused rather than silently replaced. This is a message-coverage statement, not guidance for conducting an exercise or employing forces.

Several body types, including acknowledgement, request, plan and system-command bodies, are refused by this adapter. An integration that needs them must identify the component responsible for their treatment. The existence of those forms in the wider standard does not make them implemented here.

Consumers can inspect the canonical data model documentation alongside the source-specific payload definitions. A generic Event label is insufficient to describe the complete contract. The typed payload, relevant identifiers, source fields and limitations still matter.

An exercise clock cannot be guessed

An exercise has more than one relevant time. The time represented by a simulation report can differ from the message's sending time and the receiving system's clock. Substituting one for another can produce plausible timestamps while changing the meaning of the record.

The adapter resolves a `SimulationTime` against a caller-supplied exercise epoch. Without that context, it cannot assign an absolute observation instant where one is required. Relative-time expressions are retained in supported contexts but are not resolved by this adapter. The time-handling tests explicitly distinguish simulation time, message time and epoch, and cover refusal when the needed context is unavailable.

For an integration team, the practical questions are who supplies the epoch, which initialisation it belongs to and how that basis remains associated with the translated reports. The system should not silently interpret scenario seconds as seconds since the Unix epoch or substitute wall-clock receipt time.

A replay adds another reason to retain this distinction. Receiving an old scenario report today does not turn its observation into today's event. The consumer needs the scenario instant and its provenance, while receipt time remains useful for understanding the delivery history.

Identity and affiliation need explicit context

Message identity, report identity and subject identity serve different purposes. The source implementation keeps the message identifier in provenance and derives report-event identity from the report identifier and content index. A subject reference links the event to the entity it concerns.

That allows two different reports about one subject to remain separate observations. It also prevents the mistaken assumption that a report's own identifier names the unit. A receiving application should validate those associations directly rather than matching records by display name.

Affiliation introduces a different kind of context. The adapter can interpret stated force-side relationships relative to a caller-supplied own-side identifier. Without that viewpoint, affiliation remains UNKNOWN. It does not infer affiliation from a unit name, symbol or screen colour. The original relationship codes remain available even where they do not map to a more specific canonical affiliation.

This is a useful restraint for shared exercise data. A relationship stated from one side's perspective should not silently become an absolute property for every consumer. The handover should identify the viewpoint used and preserve the source assertion behind the resulting classification.

Bidirectional does not mean every source field returns

This adapter supports both translation directions, but its egress contract is bounded. It requires the source-specific information needed to construct a supported message. A generic Entity without the required C2SIM block cannot simply be exported by guessing missing identifiers, classifications or unit details.

Fresh messages also need an appropriate envelope. Sending and receiving systems, message and conversation identifiers, and any required exercise-specific associations must come from the caller's context. A translator cannot establish those relationships merely because it has a position and a name.

There is also an explicit preservation asymmetry. Elements and attributes outside the pinned vocabulary are retained and identified on ingest, but they are not re-emitted on egress. The published extension-handling test demonstrates that boundary. A re-ingested output therefore cannot be assumed to contain arbitrary original extensions, even when the supported fixture set passes round-trip checks.

Schema validation remains a separate requirement. The test suite includes a case where an unknown status code is carried verbatim and the emitted document is schema-invalid. Preserving a source assertion does not automatically make that assertion normative. An integration should keep the source finding and the schema verdict visible instead of treating any emitted XML as approved exchange data.

A round trip and a peer exercise answer different questions

A local round trip asks whether supported source content survives translation into canonical records, emission and re-ingest under the declared comparison rules. For C2SIM, the manifest declares a value-based tolerance and fixture-level L4 evidence. This should not be described as byte-identical replay of arbitrary XML.

The evidence is useful, but both ends of that local transformation are controlled by the same implementation. A peer exercise asks what an independent system accepts and does with the exchange. It can expose differences in version handling, identity interpretation or report processing that a local fixture cycle cannot establish.

The repository includes a separate exercise client for a pinned OpenC2SIM reference-server configuration. It describes comparisons between expected and observed records. The inspected manifest still records independent-endpoint evidence as absent. Publishing a procedure is not evidence that it was executed successfully.

The OpenC2SIM project distributes server, client and schema artifacts in several versions. Their availability helps make the ecosystem inspectable; it does not prove that SynapseCommand has been accepted by those versions or by the simulator interfaces listed there. Record the actual pairing used in any exercise report.

Version labels also deserve precision. SISO's supporting data files page distinguishes the original v1.0.0 files from a corrected v1.0.1 schema package and identifies a backward-compatibility break. Standard edition, schema artifact, protocol setting and peer-software version should not be compressed into one “C2SIM version” field.

A synthetic report handover

Consider two synthetic position reports concerning the same exercise entity. The first states an observation at 120 scenario seconds; the second states one at 150 seconds. Assume distinct report identifiers, a known subject UUID and an explicitly supplied scenario epoch. These are illustrative records, not operational observations or a newly executed test.

The adapter can keep the two events distinct while associating both with the same subject. The epoch provides the basis for interpreting their observation instants. A later message delivery does not change those instants, and the subject's display name does not become its identifier.

Remove the epoch and a required observation time can no longer be resolved under this contract. Add an unfamiliar extension and it may remain inspectable on ingest without surviving export. Send the valid supported reports to another system and a further question remains: did the peer associate them with the intended subject and interpret the observations as expected?

Those outcomes need separate records. The example does not imply a particular ordering, deduplication or state-update policy in the receiving application. Those policies belong in the agreed session-integration contract and its acceptance evidence.

The earlier adapter-evidence analysis uses a related distinction for surveillance data. Here, the additional C2SIM concerns are explicit exercise context, source-specific message construction and an independently observed peer exchange.

What to agree before accepting the integration

The release baseline reviewed here is synapse-cdm 3.3.0. Teams can inspect its open integration package and reproduce relevant checks. This article reviewed published source and evidence descriptions; it does not report a new adapter test run or a completed server exercise.

Keep the trust and assurance boundary explicit when assessing integration compatibility. The practical deliverable is an exchange whose supported content, required context and peer behaviour can each be examined. That is the evidence needed to move from a translated document to an accepted integration.