Platform
Modules
By sector
By sector
By standard
Blog
News
Events
AEDP-4607
Engineers and organisations building radar sensor platforms or ground exploitation systems that produce or consume NATO GMTI data
AEDP-4607 is NATO's binary message format for exchanging Ground Moving Target Indicator (GMTI) radar detection data between sensor platforms and exploitation systems, covered by STANAG 4607.
AEDP-4607 is the NATO Allied Engineering Documentation Publication that defines the Ground Moving Target Indicator Format, GMTIF: a binary, message-oriented data format for transmitting Ground Moving Target Indicator (GMTI) radar detection data. It lets a radar sensor on an aircraft, a UAV, a satellite or a ground-based platform, and the systems that request, receive and exploit its data, exchange dwell-by-dwell target detections, high-range-resolution radar data, mission and platform information, and a record of how the data has been processed, in a common binary layout. The current edition is Edition A, Version 1, promulgated February 2024.
AEDP-4607 has no force by itself. NATO's Letter of Promulgation states: "The agreement of nations to use this publication is recorded in STANAG 4607." The STANAG is the ratified commitment among nations, and AEDP-4607 is the technical content it points to. This is a relatively new split: earlier editions of the format were published directly inside the STANAG 4607 document itself, and today "the STANAG document simply describes the agreement to use the standard now captured in AEDP-4607" (clause 1.3). A system needs to implement GMTIF because a NATO or national programme, tender or contract requires interoperable GMTI dissemination, traced back to a nation's ratification of STANAG 4607, not because the format exists in a catalogue.
The document speaks in engineering terms, not compliance terms. It refers to "the sensor manufacturer" who "needs to stipulate how its sensor system is best used" (Annex C-1.6), and to "the radar management operator (or the automated equivalent)" who schedules and tasks radar dwells (Annex C-1.6). Its optional Job Request and Job Acknowledge Segments similarly name a Requestor tasking sensor service and a platform approving, modifying or denying that request.
Every transmission is a packet: a Packet Header followed by one or more Message Segments, each preceded by its own Segment Header naming the segment type and byte length. Every data field is typed Mandatory, Conditional or Optional, and an "Existence Mask" lets a segment omit fields it is not sending, so a field cannot be assumed present just because the segment type is.
The Packet Header carries a version code, packet size, a nationality digraph (NATO platforms use "XN"), a security classification, an exercise indicator distinguishing real, simulated and synthesized data, and platform, mission and job identifiers. The Mission Segment, sent at least every two minutes, carries the mission and flight plan and the reference date against which every dwell time in the packet is measured.
The Dwell Segment is the core of the format: it is sent for every logical grouping of target reports, "even if no targets are detected", and carries sensor position, the dwell area scanned, and, for each detection, a Target Report with location, radial velocity, classification and measurement uncertainty. The HRR Segment carries High Range Resolution and Range-Doppler data referenced back to a Target Report, useful for target-length and recognition work beyond a basic detection. The Job Definition Segment defines the sensor job itself, including the four-corner area tasked and the radar mode, and "shall be sent before the first visit of a job" and re-sent "at least once every 30 seconds thereafter". A Processing History Segment, sent every three minutes, records every processing or modification operation a downstream system has applied to the data, so a receiving exploitation system can see what has already been done to what it is looking at.
The format is narrowly scoped to the data content itself. As the document states: "The format does not specify error detection/correction, encryption, or the physical transmission of the data. The format requires these functions to be accomplished by the lower layers of the communications media that transmit the data" (clause 2.2). GMTIF assumes the packets it describes arrive error-free; how they get there, and how they are protected in transit, is left entirely to the communications system carrying them.
Positions throughout the format are geodetic, referenced to the WGS-84 earth model; data is transmitted big-endian with two's-complement signed integers and a binary-angle encoding for latitude, longitude, heading, pitch and roll; and the character set is the Basic Character Set defined by STANAG 4545, the NATO Secondary Imagery Format.
New platform or sensor types, and segments beyond those Edition A defines, are registered with the standard's Custodian and published in a Registry of Controlled Extensions, rather than invented locally by an implementer. AEDP-4607 "shall be used in conjunction with" a companion NATO Ground Moving Target Indicator Format Implementation Guide, published separately as "a Standards Related Document (AEDP-7)" (clause 1.3), which carries the fuller implementation guidance, test and validation procedures, and configuration management plan that this document itself does not include. AEDP-7 is due to be replaced by AEDP-4607.1 once revised; until then, the document says to treat AEDP-7 as current.
AEDP-4607 names no certification scheme and no accredited or notified body, and nothing in the document describes a third party assessing a system's conformance to award a certificate. What it names instead is a test and validation process, carried in the companion Implementation Guide, which "provides implementation guidance, test and validation procedures, a configuration management plan, and amplifying information for this standard" (clause 1.3). In practice, conformance is something an implementing organisation demonstrates and holds evidence for using that guide's procedures, closer to self-declaration than to any audited scheme.
AEDP-4607 is not a management-system standard, and not something a single team complies with the way it would ISO 9001. It is a data-interface specification that a radar sensor or ground-exploitation system either encodes and decodes correctly or does not, and the work of meeting it is systems engineering: building the packet, segment and field structure into a system's software, and testing that implementation against the Implementation Guide's procedures.
What sits around that engineering work is where ComplyTrain fits: the record of which systems and platform or sensor registrations conform to which edition, the design and test/validation records the Implementation Guide calls for, training records for the engineers who build to the format, and the corrective-action trail when an interoperability test finds a nonconformance. Those live as controlled, versioned records with an owner and a review history, rather than scattered across engineering notebooks between programmes.
What ComplyTrain does not do: it does not write, encode, decode, test or validate GMTIF messages, and it does not perform the radar signal processing or systems-integration work the format assumes. That stays the sensor and exploitation-system supplier's engineering work.
Which programmes and contracts call for AEDP-4607, and what else in the NATO ISR standards family sits alongside it, is set by the customer's tender and quality clause. See what else covers GMTI and related sensor data in the standards explorer, and talk to us about the evidence trail behind your engineering programme.
Tell us how you need to work with AEDP-4607 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.
No. STANAG 4607 is the agreement by which NATO nations commit to use the GMTI format; AEDP-4607 is the technical document that actually defines it. Earlier editions of the format sat directly inside the STANAG text, but current editions separate the two: the STANAG records the commitment, and AEDP-4607 carries the packet and field definitions.
No. The document names no accredited or notified certification body and describes no scheme for certifying a system against it. Conformance is tested and validated by the implementing organisation using the procedures in the companion Implementation Guide, closer to self-declaration than to any audited certification.
AEDP-7 is the NATO GMTI Format Implementation Guide, a companion document AEDP-4607 is meant to be used alongside for implementation guidance, test and validation procedures, and a Registry of Controlled Extensions. It is due to be replaced by AEDP-4607.1 once revised; until that happens, AEDP-4607 itself says to treat AEDP-7 as the current version of the guidance.
No. The document is explicit that it does not specify error detection, error correction, encryption or the physical transmission of the data, and leaves those functions to the communications layers that carry GMTIF packets. GMTIF assumes the packets it describes arrive error-free.
No. A Dwell Segment is sent for every logical grouping of target reports, and the document states it "shall be sent even if no targets are detected", so the absence of a segment is not itself meaningful the way an empty one is.
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.