Platform
Modules
By sector
By sector
By standard
Blog
News
Events
ANEP-82
Developers and integrators of a national CMS-to-IDATS interface, and the CMS vendor responsible for building it
ANEP-82 sets the message protocol NATO navies use to send ship sensor data from a Combat Management System to the FORACS IDATS test system, for the developers and CMS vendors who build that interface.
ANEP-82, "Message Specification for Data Link between Combat Management Systems and IDATS," is a NATO Allied Naval Engineering Publication. It defines the message protocol used to send ship sensor data from a Combat Management System (CMS) to the NATO FORACS programme's Integrated Data Acquisition Test System (IDATS), which the FORACS Project uses "to collect and process sensor data during sensor accuracy tests." It is a wire-format specification for a single test interface, not a management system, a quality-assurance standard or a physical handling procedure.
The document is addressed to "the developer and the integrator of a national interface between the nation's CMS and NATO FORACS IDATS," and it names who carries that job in practice: the filtering system's implementation "is the CMS vendor's responsibility in accordance with the nation's interests and requirements." It reaches that developer through STANAG 4710, the agreement nations ratify to use it; ANEP-82 itself is the technical content that agreement covers, not something a supplier is bound by on its own account.
There are only two message types: a Sensor Data Message, carrying "one observation from one data source," and a Time Synchronization Message, carrying the CMS clock's current time so IDATS can check it has not drifted. Every message is ASCII text built from comma-separated data-item segments, each a colon-separated run of a descriptor token, an optional unit qualifier, and an optional extra descriptor. Two rules cut across the whole syntax: duplicate descriptors are not allowed within one message, and a sensor data message always carries a time-of-validity segment: one that lacks it "cannot be processed" at all.
The interface runs over serial RS-232 (9600 baud minimum, each message opening with $SIIS, and ending on a line feed) or Ethernet, where each UDP packet carries exactly one message to a default port of 4100. Timing is tight in one place: a time-synchronization message has to reach IDATS-IC with a total acquisition-and-transmission latency "not exceeding 20 ms," because IDATS treats the value as the CMS's actual clock reading. A checksum is optional and recommended only for serial links, computed as an 8-bit exclusive-OR across the message.
Most of the document's length is two reference tables: the data-item descriptors (bearing, range, position on each axis, depression/elevation angle, height, latitude and longitude with a choice of geodetic datum, heading, pitch, roll, sound velocity and more) and the units they carry. Reading only the worked examples in Annex A risks missing something Annex B states plainly: pitch and roll still appear in the table but the document says each "remains in the list of descriptors for backward compatibility," while the current tokens, pire and rore, "must be used instead." A CMS can also send data outside the approved list through a user-defined descriptor, which IDATS records but does not otherwise process.
ANEP-82 sets out no certification, accreditation or audit scheme, and no external body assesses an implementation against it. Conformance is functional: an interface either produces messages IDATS-IC can parse correctly, or it does not. The document's own examples of this are blunt. A message missing its time-of-validity segment cannot be processed at all, and a descriptor the CMS invents outside the approved list is simply parsed and filed away, with no further processing applied to it. The only real proof an implementation works is that IDATS receives, timestamps and processes what a ship's interface sends it during an actual FORACS test.
ANEP-82 is explicit that "the interface between CMS and IDATS is not covered by any other NATO publication," so there is no separate standard governing this specific link. It also leans on STANAG 4222, "Method of expressing navigation accuracy," for the axis convention behind several position tokens, and it does not attempt to define that convention itself. Annex A's worked message examples are stated to be indicative, not exhaustive: they do not "cover all the different messages that can be output by a CMS."
ANEP-82 is published by the NATO Standardization Office and listed in the NATO Standardization Document Database free of charge. NATO's documents are not sold by ComplyTrain and we host no copies of them.
ANEP-82 sits at the far technical end of the standards ComplyTrain's customers meet: a wire-format specification for one test interface, not a certifiable standard and not a mapping any software product can honestly claim. The work it calls for is engineering work, done by a developer or integrator writing and testing the filtering system, with the CMS vendor carrying responsibility for getting it right. ComplyTrain does not write, test or validate that software.
What ComplyTrain supports is the paperwork around that engineering effort: a controlled place to hold the interface's design and configuration records, a record of who reviewed and approved a change when a token or message format moves between editions, as several did between Version 3 and Version 4 of this document, and the training records for the staff who maintain the interface. It can also hold the verification evidence produced when a filtering system is checked against ANEP-82 before it goes live on a FORACS test.
What ComplyTrain does not do: it does not implement, test or certify a CMS-to-IDATS interface. A supplier working to ANEP-82 still needs its own engineers, or its CMS vendor, to build and verify that software. Which documents apply to a given ship's interface is a matter for the contract or the national FORACS programme. See the standards explorer for what sits alongside ANEP-82, including STANAG 4710 and ANEP-31, and talk to us about the evidence trail around any defence engineering standard your programme references.
Tell us how you need to work with ANEP-82 and what you need from it. We will come back to you about what ComplyTrain can do.
Thank you. Your list is on its way to your inbox, and we will come back to you on what working with these standards in ComplyTrain involves, usually within one business day.
ANEP-82 is a NATO Allied Naval Engineering Publication that defines the message protocol for sending ship sensor data from a Combat Management System to the NATO FORACS programme's IDATS test system. It sets out message types, ASCII syntax, transport options and a large table of data-item and unit tokens.
Not by itself. Nations ratify STANAG 4710, which is the agreement recorded as covering this ANEP; ANEP-82 supplies the message syntax that agreement points to. It reaches a developer or CMS vendor only when a national FORACS interface project requires it, which is a contractual and programme-level question rather than a general one.
The document names the developer and integrator of the national CMS-to-IDATS interface, and it states that building the filtering system is the CMS vendor's responsibility. It is an engineering task, not a compliance or quality-management one.
No. The document describes no certification, accreditation or audit scheme. Whether an implementation is correct is shown functionally, by IDATS receiving and correctly parsing the messages a ship's interface sends during an actual FORACS test.
Edition A, Version 4, published in July 2026 by the NATO Standardization Office. It supersedes Edition A, Version 3.
From the NATO Standardization Document Database, which lists it free of charge. NATO's documents are not sold by ComplyTrain and we do not host copies of them.
One system for the whole compliance programme. Start with the module you need most.
Collect information the same way every time, and decide in advance what happens next.
Know whether your controls are operating, not just whether a policy says they exist.
Turn the compliance work you already know about into a plan with owners, dependencies and dates.
Know what you can offer, and hold the evidence behind every configuration you offer it in.
Eight built-in reports across every module, scheduled, delivered, and filed where the evidence lives.
The sector news that matters to your organisation - read and rated by AI, and delivered as a scheduled digest in your own language.
AI reads the tender pack and pulls out the requirements, deadlines and rules - then helps you draft the response from your own approved content, with you reviewing every step.
One current register of the suppliers and partners you depend on - each risk-assessed, re-assessing itself on schedule, and wired straight into your risk register.
See every requirement you face - across every standard, plus your own contracts and policies - traced to the documents, evidence and processes that satisfy it.
Identify, score, treat and review your risks in one place - with AI to help anyone run a proper assessment, and a defensible trail behind every decision.
Assign training, prove it was understood, and hold the competence records an auditor asks for.
Draft compliance documents with AI, keep every version under control, and export them beautifully branded - all in one place.
Audits, corrective actions, processes and approvals in one quality system, organised around ISO 9001.
Medical device manufacturers operate under more regulatory pressure than almost any other sector outside pharmaceuticals. The rules govern how you design a device, how you make it, how you track it after it ships, and how you respond when something goes wrong.
Learn how EU dual-use export controls apply to encryption, sensors, and software, how classification works under Annex I, and why sending source code by email can count as an export.
A practical way to turn in-your-head risk management into a register that survives staff turnover and answers the risk questions now showing up in tenders.