AMSP-04 NETN-FOM simulation interoperability data model

What it is

AMSP-04 is the NATO Allied Modelling and Simulation Publication that defines the NATO Education and Training Network Federation Object Model, known as NETN-FOM: a shared data model for exchanging information between the simulation systems that take part in a joint distributed training exercise. It is not a management-system standard and it does not set out obligations for a quality function. It is a technical specification for the people who design, build or integrate simulation software, and Edition C, Version 1 (March 2025) is the current version, superseding Edition B, Version 1 (March 2021).

A data model, not a design specification

NETN-FOM works inside the IEEE High-Level Architecture (HLA), the simulation infrastructure NATO covers separately under STANAG 4603. HLA lets independent simulation applications, called federates, interoperate through standard services and interfaces; AMSP-04 defines the specific object and interaction classes federates publish so that other federates in the same federation can understand them. The document describes itself as a reference: it does not replace the need for detailed design work, but gives federation designers a common foundation to build against instead of each inventing their own.

Who builds to it, and when

AMSP-04 addresses those who design and develop simulation federates, not a procurement or compliance function. It reaches a company through a contract, not through NATO membership: the document itself is not mandatory. It is carried by STANREC 4800, a NATO recommendation rather than a ratified agreement, so nations are invited to use it rather than committed to it. For a supplier, the practical trigger is a training programme, exercise directive or contract that names NETN-FOM, or a specific edition of it, as the data model a federate must implement. Because it governs how a federate's data model is structured, it is far cheaper to design for from the outset than to retrofit once a federate is already built.

The FOM modules

NETN-FOM is organised into modules, each covering one aspect of a simulated exercise and built on a shared base:

• NETN-BASE and NETN-SMC provide common datatypes and the request/response pattern other modules use to send control actions to a federation, a federate or a specific simulated entity.
• NETN-ENTITY, NETN-ETR and NETN-ORG cover simulated forces: physical and aggregate entities, the tasks that can be sent to them (move, patrol, fire, attach and more, with status reporting through to completion or failure), and the organisational structure of units, equipment and installations they are built from.
• NETN-MRM and NETN-TMR handle change during an exercise: aggregating and disaggregating units as the level of simulated detail changes, and transferring which federate holds modelling responsibility for an entity.
• NETN-METOC, NETN-CBRN, NETN-DIM, NETN-SE, NETN-AIS, NETN-COM and NETN-LOG cover specific domains: weather and its effects, chemical/biological/radiological/nuclear release and protection, disasters such as flooding and wildfire, engineering objects like minefields and checkpoints, vessel traffic using AIS messages aligned to ITU-R M.1371-5, layered communication-network modelling, and logistics tasks for resupply, repair and transport.

What an implementation has to get right

Every object a federate creates needs a published unique identifier, and a federate receiving a control action has to respond so the sender can tell whether it succeeded. The aggregation, disaggregation, division and merging patterns in NETN-MRM are defined step by step with explicit preconditions - which attribute has to be owned, which status an entity must be in, whether the referenced organisational unit has subunits - which is the kind of detail an implementer checks an integration against, not a paraphrase of intent.

Just as important is what the document leaves open. It says plainly that some choices, such as how logical time is synchronised between federates, belong to the federation's own agreement rather than to NETN-FOM: implementers are told to use their federation agreement to settle it. The same pattern applies to default symbol standards and non-standard equipment subcategories. An implementer's federation agreement, not AMSP-04, is where those gaps get closed.

How it is evaluated

There is no certification against AMSP-04. Where its history mentions certification at all, it is a related but different activity: a NATO technical group once worked on establishing an HLA certification process under STANAG 4603, which is a certification route for HLA itself, not one NATO operates for NETN-FOM. What the document does define is federate-level technical conformance: a federate is "NETN-SMC-compliant" when it correctly implements and responds to the interactions its modules specify, and that is proven through interoperability testing between federates during federation development and exercise events, not by an accredited body auditing an organisation.

Standards it references

STANREC 4800 is the NATO recommendation that carries AMSP-04, and the mechanism by which it acquires whatever force it has. STANAG 4603 covers HLA, the architecture AMSP-04's object model is built inside; AMSP-04 assumes an HLA federation already exists rather than replacing it. Outside our catalogue, AMSP-04 also normatively cites IEEE 1516 (the HLA standard), the SISO Real-time Platform Reference FOM, the SISO C2SIM standard, the Military Scenario Definition Language, ISO/IEC 9834-8:2014 for UUID generation, ITU-R M.1371-5 for AIS message formats, NMEA-0183, and IEEE 1730-2022 for the Distributed Simulation Engineering and Execution Process.

Standards it references

• STANAG 4603Background