Start a free trial
Menu

AEDP-4607

AEDP-4607 NATO ground moving target indicator format

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.

Edition
A
Published
2024-02
Evaluated by
self-declaration

What it is

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 and STANAG 4607

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.

Who builds to it

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.

Packets, segments and the Dwell Segment

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.

What AEDP-4607 leaves to other layers

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.

Extending the 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.

How conformance is checked

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.

Standards it references

  • STANAG 4607 - the ratified agreement giving AEDP-4607 its force; the STANAG now records the nations' commitment while this document carries the technical content.
  • STANAG 7023 - Air Reconnaissance Primary Imagery Data Standard. GMTIF data may be embedded in a STANAG 7023 imagery stream, and the two documents share the same platform-orientation reference geometry.
  • AAP-03 - NATO's terminology directive, followed for the naming and abbreviation conventions used throughout this document.
  • STANAG 4545 - NATO Secondary Imagery Format. GMTIF may be embedded within an NSIF stream, and its Basic Character Set defines the alphanumeric character set AEDP-4607 uses.

How we help

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.

Standards it references

Questions

Is AEDP-4607 the same thing as STANAG 4607?

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.

Does NATO certify a system as AEDP-4607 compliant?

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.

What is AEDP-7, and is it still current?

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.

Does GMTIF handle encryption or error correction?

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.

Is a Dwell Segment only sent when a target is detected?

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.