Platform
Modules
By sector
By sector
By standard
Blog
News
Events
ATP-3.3.4.10
Engineers and system developers building automated (unmanned) tanker and receiver air-to-air refuelling capability, and the Air Vehicle Operators who would direct it
NATO's concept of operations for automated (unmanned) air-to-air refuelling: shared standard positions, data-link messages and phases of flight that let tanker and receiver systems interoperate, with the interface and airworthiness standards still to be written.
ATP-3.3.4.10, Automated Air-to-Air Refuelling (A3R), is a NATO Allied Tactical Publication covering "air-to-air refuelling events involving at least one unmanned or automated tanker and/or receiver" (Chapter 1, paragraph 1). It is a concept of operations, not a finished interface specification: its stated purpose is "to provide guidelines for the development of A3R systems to ensure the solutions are interoperable within the international community" (Chapter 1, paragraph 1). It is rooted in an Aerial Refuelling Systems Advisory Group document, number 42-13-17, dated 9 June 2017, and is understood to become the basis of a future A3R section within the existing manned publication ATP-3.3.4.2 (Chapter 1, paragraph 1). Edition A, Version 1 was promulgated in October 2021. This edition covers only one tanker refuelling one receiver; combinations with multiple tankers or multiple receivers are left to a future version (Chapter 1, paragraph 4).
The document addresses the people who would build an A3R capability, "the international air refuelling community" developing these systems (Chapter 1, paragraph 1), and, through the roles and messages it defines, the Air Vehicle Operators (AVOs) and tanker crews who would direct an A3R system once one exists. It reaches a supplier or manufacturer the way any Allied Publication does, through a nation's own programme or a contract, not by existing on its own. NATO nations can ratify with a limitation: Estonia's recorded reservation states it "will implement the standard with the following limitation: Estonia will conduct only the procedural part - air-to-air refuelling operations management and coordination via CRC Tallinn."
A3R does not start from a blank page. The document is built to "strive to use existing operational procedures as laid out in ATP-3.3.4.2 to the greatest extent possible," and it repeatedly hands off to that publication rather than redefining ground it already covers: standard AAR positions ("all AAR positions are as defined in ATP-3.3.4.2 unless otherwise noted in Table 3-1"), the seven types of rendezvous, and the Loss of Visual Contact, breakaway, overrun and toboggan-manoeuvre procedures. The one position ATP-3.3.4.10 introduces that ATP-3.3.4.2 does not have is the Transition Point, used to check an unmanned receiver's relative navigation performance before it moves closer to the tanker.
Chapter 2 describes an A3R system as four segments: the unmanned tanker or receiver (counted once, since either role uses the same systems), the manned tanker, the manned receiver, and the AVO stations. Table 2-1 lists the notional systems needed: a precision navigation system for guidance, navigation and control; voice and data communications; an automated boom system; and an automated probe/drogue system. The datalink is described as needing to be "a robust datalink will be needed with the capability of sending and receiving high volumes of relative navigation data with low latency and high integrity." Three tanker/receiver combinations are addressed; a manned tanker refuelling a manned receiver needs no new systems or procedures and is not covered.
Table 3-1 names the standard A3R positions: Transition Point, Echelon Left, Astern (Left, Right, Centre), Contact, Echelon Right, Breakaway, Safe Position(s), and AAR Exit Point. Tables 3-2 through 3-5 set out functional message sets, Tanker Messages, Receiver Messages, Precision Navigation System Messages and Network Status Messages, that "translates the existing voice command and control messages/procedures as described in ATP-3.3.4.2 into data link messages." These tables are functional descriptions for CONOPS purposes, and the document says so plainly: "specific format and content of the messages will need to be defined in a NATO standard." Section 3.5 walks one rendezvous type, RV Alpha, through a full message sequence from network join to departure, as a worked example of how the message tables and the standard positions fit together.
Eight phases of flight are defined, Rendezvous, Approach, Formation, Astern, Contact, Departure, Breakaway, and Tanking (unmanned tankers only), each triggered by a specific message so that "the response of the air vehicle in each phase of flight is precisely defined, predictable and consistent." Chapter 4 covers contingencies: Breakaway, degraded communication and navigation, Overrun, Boom Flight Control Malfunction, Controlled Tension Disconnect, Fuel Leakage, Toboggan Manoeuvre, Manual Boom Latching and Pressure Refuelling. Most of these hand off to ATP-3.3.4.2 for the actual procedure. One contingency is specific to the automated system itself: because of the latency inherent in beyond-line-of-sight links, "due to latencies involved with BLOS, the receiver automatically executes a breakaway" on loss of the tanker-to-receiver command and control link, without the AVO commanding it.
Safety-critical commands are the one message category the CONOPS insists on sending "direct tanker to receiver communications implemented without AVO intervention," a deliberate exception to the AVO-in-the-loop model the rest of the document assumes. Two exclusions are worth knowing before relying on this document for anything more: it "does not address Boom Drogue Adapter for A3R operations," and it does not itself fix message content, message format, or the accuracy, integrity, continuity and availability of navigation data a real interface would need, stating those "will need to be developed." New A3R airworthiness criteria are left to future work in the same clause. A reader treating ATP-3.3.4.10 as a complete, buildable interface specification has read further into it than the document claims for itself.
ATP-3.3.4.10 is published by the NATO Standardization Office and, like all NATO standardization documents, it is free of charge. NATO's Standardization Document Database is the authoritative source; we credit NATO for the catalogue and do not sell or host a copy of the document ourselves.
ATP-3.3.4.10 is operational and technical, a concept of operations for an emerging capability, not a management-system standard. The actual work it describes, designing a precision relative navigation system, building a robust low-latency datalink, engineering the automated boom or probe/drogue systems, and validating that an unmanned tanker or receiver behaves correctly through each phase of flight and each contingency, is systems engineering and flight test work. It happens in engineering documentation, simulation and flight test programmes, not in a compliance platform, and this page will not pretend otherwise.
What ComplyTrain supports is the documentation and evidence trail around that work: a controlled requirements record that traces an organisation's A3R design, its positions, its message set, its phase-of-flight logic, back to the specific clauses of ATP-3.3.4.10 it follows, and to the points, such as a national reservation like Estonia's, where a programme has departed from or narrowed the base CONOPS; training records showing AVOs and tanker crews understand the safety-critical, no-AVO-intervention message category the document defines; and a controlled register of the contingency procedures an organisation has built, each traceable to the clause it implements.
What ComplyTrain does not do: it does not design, build, certify or flight test an A3R system, it does not set or assess airworthiness criteria, and it offers no guidance of its own on flying, rendezvous, refuelling or contingency procedures. Those stay matters for the aircrew, the design authority and the applicable airworthiness process. Which tier of interoperability standard applies to a given programme, and how far a nation has ratified it, is set by the contract and the customer's programme office, never by this page. Explore the related standards to see what sits alongside ATP-3.3.4.10, including ATP-3.3.4.2 and STANAG 7239, or talk to us about the evidence trail an A3R development programme needs to hold.
Tell us how you need to work with ATP-3.3.4.10 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. Our catalogue records it as covered by STANAG 7239, and like any Allied Publication it reaches an organisation only once a nation's programme or a contract invokes it. Nations can also ratify with a limitation, as Estonia has done, restricting its own implementation to the procedural part of the CONOPS.
ATP-3.3.4.2 is the existing publication covering manned air-to-air refuelling procedures. ATP-3.3.4.10 is built to reuse those procedures, positions and rendezvous types as closely as possible for events involving at least one unmanned or automated tanker or receiver, and is intended to become the basis of a future A3R section inside ATP-3.3.4.2 itself.
No. The document states plainly that "fully autonomous AAR from rendezvous (RV) through refuelling is not being considered at this stage as the technology is yet to mature." It describes an Air Vehicle Operator directing the unmanned aircraft through each phase of flight, not an unsupervised system.
No. It describes a functional message set for CONOPS purposes and says directly that "specific format and content of the messages will need to be defined in a NATO standard." The detailed interface, message content, format, accuracy, integrity, continuity and navigation-data availability, is left to standards still to be written.
No. Designing, building, testing and certifying an A3R system is systems engineering and airworthiness work carried out by the design authority and the applicable certifying process. ComplyTrain holds the documentation and evidence trail around that work: requirements traceability back to ATP-3.3.4.10, training records, and controlled contingency procedures.
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.