Platform
Modules
By sector
By sector
By standard
Blog
News
Events
AEP-84
Unmanned aircraft and Vehicle Specific Module manufacturers and Core UCS developers building STANAG 4586 interoperable control systems, and the operators who use them
AEP-84 is NATO's two-volume interface control document for STANAG 4586, defining the data link, command and control, and human computer interfaces a UAS control system uses, graded across five Levels of Interoperability.
AEP-84 is NATO's Allied Engineering Publication that works as the interface control document for STANAG 4586, the Standardization Agreement covering unmanned aircraft system (UAS) interoperability. Where STANAG 4586 is the agreement nations ratify, AEP-84 is where the actual interfaces are specified, in two separate volumes, each with its own NATO Naval Armaments Group promulgation letter. Both volumes are organised around the same three interfaces: the Data Link Interface (DLI) between the Core UCS (CUCS) and a vehicle's own Vehicle Specific Module (VSM), the Command and Control Interface (CCI) to external C4I systems, and the Human Computer Interface (HCI) the CUCS presents to its operator. Whoever builds a Core UCS, or supplies the VSM for an unmanned aircraft, is the document's direct audience: the CUCS "shall support the requirements of the DLI, CCI, and HCI" (clause 3.1), and the VSM that does the vehicle-specific translation work is one "the UA manufacturer would generally provide" (Chapter 3, section 3).
Volume I and Volume II share the same six-chapter shape: an introduction and agreement clause, terms and definitions, a top-level architecture description, then the DLI, CCI and HCI chapters in turn. Both were promulgated on the same day, but they are not duplicates. Volume II's Data Link Interface defines a substantially bigger, renumbered set of messages than Volume I's, spanning flight vehicle command and status, payload, data link, mission, subsystem, autonomy, configuration and draw-interface message groups. Rather than retire Volume I outright, Volume II's own data link status messages keep a legacy status and control report specifically for "backwards compatibility to AEP-84 Volume 1", so an older data link is not automatically excluded from a Volume II implementation.
Both volumes grade conformance through five Levels of Interoperability (LOI 1 to 5), defined independently for the DLI and the CCI, so the LOI "can be different for a specific UAS design" (Chapter 3, section 2.3.1). Nations that ratify STANAG 4586 "agree to implement the standards presented herein in whole or in part... to achieve the desired Level of Interoperability", and once a set of standards is identified as mandatory for a target LOI, AEP-84 requires it "as a whole": a CUCS or VSM cannot claim a Level of Interoperability by implementing part of its message set and leaving the rest for later. Chapter 5's clause 1.6 adds a qualifier for the Command and Control Interface specifically: a message type marked mandatory for an LOI still has to be exchanged only "provided that operating procedures require the exchange of this type of data".
The DLI is the interface "between the UA/data link and the CUCS element" (clause 1.3), and it carries most of the manufacturer-facing detail. The Vehicle Specific Module translates between the CUCS's generic message representation and the vehicle's own proprietary formats, acts as the repository and server for vehicle-specific data, packs and unpacks data-link traffic, and manages the UA's performance, data-link operation, and launch and recovery interfaces. The CUCS is kept out of that work by design: it "shall not contain... processes" needed to support the UA and data-link operation, so the real-time, vehicle-specific functions stay with the VSM. The message catalogue this interface defines covers system identification, flight vehicle command and status, payload command and status, data link set-up and status, mission upload and waypoints, subsystem health, autonomy, general configuration, and draw-interface (map annotation) messages; its common message set also includes stores and weapons command and status messages as one of its groups. Data representation itself is fixed across every implementation rather than left to each manufacturer, so a message from any compliant VSM means the same thing to any compliant CUCS.
The CCI governs how the CUCS talks to external C4I systems, and it binds the CUCS only: "this chapter specifies standards to be implemented in the CUCS, and does not impose any requirements on C4I systems" (clause 1.1). It ties categories of data, tasking, airspace and air traffic control, collateral battlefield data, mission plans and progress, resource availability, imagery and other payload data, target data, and mission reporting, to ADatP-3/APP-11 message formats and, for imagery and sensor data, to named NATO standards: motion imagery over STANAG 4609, still and SAR imagery over STANAG 4545 or STANAG 7023, ground moving target indicator data over STANAG 4607, image library access over STANAG 4559, and ELINT reporting conforming to STANAG 4633 (not yet a separate record in our catalogue). Several obligations are graded by LOI: transmitting and receiving mission plans is "recommended for LOI 3 and shall be provided (mandatory) for LOI 4" (clause 3.5), and air traffic service messages need the ICAO format only "for LOI 4 and 5" (clause 3.3).
Chapter 6 sets what the CUCS has to let its operator do, again graded by LOI: entering and synchronising time with the UAS and connected C4I systems; generating, editing and sending the message types STANAG 4586 defines; switching measurement units between imperial and metric; creating, editing, importing and uploading mission plans, and updating one already in progress "at any time before or during flight"; controlling the UA in every flight mode it supports and handing control to another qualified operator; displaying imagery from external sources; providing controls and monitoring for payloads validated with the CUCS; and displaying warnings, cautions and advisories. The chapter states plainly that it "specifies the requirements levied upon the UCS, and does not impose any requirements on Human Factors (HF) and ergonomics" (clause 1.1), leaving screen design, layout and workflow to the implementer. Chapter 6 also defines a "qualified operator" as one determined by the operational system user, not the acquisition or development organisation, and says that qualification decision sits outside the acquisition organisation's own test and validation scope.
There is no certification against AEP-84 itself. Neither volume names a certification body, an accredited scheme, or an audit cycle that assesses a company or a product against the document. Conformance means a CUCS or VSM declaring, and demonstrating, that it implements the mandatory message sets and HCI functions tied to a stated Level of Interoperability; the clearest test mechanism named in either volume ties one specific DLI capability to "the minimum test set described in the SRD AEP-84.2 Validation/Test Guideline Document" (clause 4.2.1), a companion document rather than a certificate. What AEP-84 leaves outside its own scope is airworthiness: it states plainly that it "does not address or imply the overall requirements and required certifications that may be necessary to operate UA in controlled air space", and separately assumes that "air safety regulations will require the certification of... combining the operation of assets from different UASs" (clause 1.1). Certifying a fielded aircraft, or a combination of UAS assets, is a national or international air safety regulator's decision, not something AEP-84, NATO, or any company can be certified against.
Beyond STANAG 4586 itself, the parent agreement AEP-84 implements, the document leans on STANAG 5500 and STANAG 7149 (ADatP-3 and the NATO Message Catalogue) for tasking and status messages, STANAG 5516 (Link 16) for specific identification fields, STANAG 2103 alongside ATP-45 for CBRN reporting, STANAG 3150 and STANAG 3151 for the codified stock numbers that identify payload types, STANAG 1059 for country coding, and STANAG 7085 for the data link its Volume II message set is built to fully control. It also cites STANAG 4193, STANAG 4660, STANAG 2019 and STANAG 7194, and several codes not yet separate records in our catalogue: STANAG 3377, STANAG 4250, STANAG 7074, STANAG 7024, STANAG 4633, AEDP-4, the MISB motion-imagery metadata standards, and ICAO's Doc 4444 Rules of the Air and Air Traffic Services.
AEP-84 is an operational and technical interface standard, not a management system: the work it describes, translating messages, building a VSM, implementing HCI displays, is systems engineering and integration, not something a compliance platform does. There is no certification against it to prepare for; conformance is a Level of Interoperability a programme declares and demonstrates against the mandatory message sets and HCI functions that LOI carries.
What ComplyTrain supports is the paperwork trail around that engineering work: the requirements traceability that ties a declared Level of Interoperability to the specific DLI messages, CCI data formats and HCI functions it requires; the design and interface-control records that show a VSM or CUCS implements them; the training and qualification records behind an operator's "qualified operator" status; and the record of interoperability test results kept as evidence for a customer or a programme office. It does not write DLI message-handling code, build a VSM, or run the interoperability test itself.
Where AEP-84 sits alongside the standards it references, and which of its Levels of Interoperability a specific programme is contracted to reach, is set by the contract and the customer's quality clause. The standards explorer shows what sits alongside it; if you are working out what a contract actually calls for, we are glad to talk it through.
Tell us how you need to work with AEP-84 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.
Not by itself. AEP-84 is the interface control document for STANAG 4586, the NATO Standardization Agreement through which member nations ratify and agree to implement it. It reaches a manufacturer or a CUCS developer once a national requirement, a tender or a contract invokes STANAG 4586 and a target Level of Interoperability.
STANAG 4586 is the agreement nations ratify; AEP-84 is the technical publication it covers, where the Data Link, Command and Control, and Human Computer Interfaces are actually specified, and where a nation's agreement to use it is recorded.
No. Neither volume names a certification body or scheme. Conformance is a Level of Interoperability a CUCS or VSM declares and demonstrates against the mandatory message sets and HCI functions that level requires; certifying a fielded aircraft or a combination of UAS assets is left to national air safety regulation, outside AEP-84's own scope.
One of five grades (LOI 1 to 5) that AEP-84 uses to determine which Data Link, Command and Control, and Human Computer Interface requirements apply to a given UAS design. A higher LOI carries more mandatory message sets and HCI functions, and the LOI for the DLI and the CCI can differ on the same system.
Both cover the same three interfaces under the same chapter structure, but Volume II defines a substantially larger and renumbered set of Data Link Interface messages. Volume II's own data link status messages retain a legacy report specifically for backward compatibility with Volume I, so the two are not mutually exclusive.
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.