AEDP-19 NATO ISR workflow architecture

What it is

AEDP-19 is an Allied Engineering Documentation Publication, NATO's name for the technical document that carries the actual requirements under a covering agreement. It sets out the "NATO Standard ISR Workflow Architecture, proposed for agreement under STANAG 4559 Edition 4," and its own Letter of Promulgation records that "the agreement of nations to use this publication is recorded in STANAG 4559." That distinction matters more here than usual: STANAG 4559 is what NATO nations ratify, and AEDP-19 is the specification a nation is agreeing to when it does. It is not a management-system standard, and nobody is certified against it. It is a service-oriented-architecture specification: a set of SOAP and XML web-service interfaces, message schemas and choreography rules that let NATO and national intelligence, surveillance and reconnaissance (ISR) systems exchange the working data of a joint collection cycle. The document states its aim plainly: "to promote interoperability for the exchange of NATO Intelligence, Surveillance and Reconnaissance (ISR) process elements." It is written for the people who build those systems, "intended to be used by engineers during system design, implementation and testing," not for the people who use them operationally day to day.

The service stack

AEDP-19 organises its interfaces into two layers of a wider STANAG 4559 service stack. A Core Services Layer carries three domain-independent services: Simple Persistence as a Service (SPS++), a Pub-Sub notification service, and the Enterprise Event Relay Service (E2RS). A JISR COI-Specific Services Layer carries six services built for the intelligence community specifically: Organization, Requirement, Priority, Tasking, Request, and Geographic Area of Interest. A cross-cutting set of business rules fixes the topic namespace, entity-identifier format and security mechanism that every one of those nine services shares, so a system that implements several of them behaves consistently across all of them.

SPS++ is the storage layer the other eight services persist through. It stores versioned XML business entities, replicates them between distributed nodes, and resolves the write conflicts that distributed replication produces by tracking version trees and letting a consumer mark a losing branch dead. Implementers choose one of three compliance levels; the document states a preference without mandating the top one, since "a SPS++ service provider SHOULD provide 'compliance level 3', however lower levels of compliance could still be operationally sufficient in a specific deployment." A dedicated procedure specifies how a new node synchronises into a mesh of SPS++ instances that has been replicating for years without disrupting the ones already running, and the document sets a concrete throughput target for it, in clause A-3.7.8.2.7: SPS++ "SHALL be able to provide a throughput of up to 64,850 messages per day." The Pub-Sub service tells higher-layer services about new content without polling, and the Enterprise Event Relay Service is its opposite in reliability: it "SHALL NOT persist messages" and "SHALL NOT queue messages," because it exists only to relay high-frequency, low-payload traffic such as system-status heartbeats.

What the JISR-specific services do

The Organization Service manages units, locations, operations, ISR systems and the order of battle (ORBAT) connecting them, and lets systems publish and read asset status and heartbeats. It enforces a publishing order: every unit and system named in an ORBAT structure has to be published before the relationships that build that structure are. The Requirement Service manages Intelligence Collection Plans and the information requirements inside them, allowing only one "Current" plan per unit at a time and moving each requirement through a defined status progression. The Priority Service stores weighted priority values that an administrator sets and a collection manager applies to a request, and calculates a combined priority as a weighted sum of them. The Tasking Service runs a choreography between a tasking unit and a tasked asset, each reporting its own status through a defined state model, covering collection tasks and exploitation tasks and letting one task trigger exploitation of another's product. The Request Service runs a parallel choreography for requests for information and ISR requests through an eleven-state model, enforcing that a request has only one unit actively responsible for it at any time. The Geographic Area of Interest Service is the simplest of the six: it stores the geographic areas the other services reference by identifier.

Security and how conformance actually works

Every operation across every service is gated the same way: access "SHALL be controlled using the 'Username Token Profile 1.1'," and a service throws an access-denied exception if it does not receive sufficient credentials. AEDP-19 names no certification body, accreditation scheme or government audit against itself. The closest it comes is the self-rated compliance level described above for SPS++, and the document is explicit that a lower level than the top one can still be the right choice for a given deployment. In practice, conformance to AEDP-19 is demonstrated by interoperating: a system either exchanges the defined messages correctly with another implementation of the architecture, or it does not.

Standards it references

AEDP-19 sits under [STANAG 4559](/standards/stanag-4559), the agreement NATO nations ratify to commit to it. It is written to complement two sibling publications covered by the same STANAG: [AEDP-18](/standards/aedp-18), NATO Standard ISR Streaming Services, and [AEDP-17](/standards/aedp-17), NATO Standard ISR Library Interface, whose Core Interface every service in AEDP-19 inherits from. The operational procedures this architecture supports are described in [AIntP-16](/standards#q=AIntP-16) (intelligence requirements and collection management) and [AIntP-14](/standards#q=AIntP-14) (joint ISR procedures), and it relates to the doctrine set out in [AJP-2](/standards#q=AJP-2), [AJP-2.1](/standards#q=AJP-2.1) and [AJP-2.7](/standards#q=AJP-2.7). Its reference list also ties [STANAG 6524](/standards#q=STANAG%206524) to AIntP-16.

Standards it references

• AEDP-18Background
• AEDP-17Background
• AIntP-16Background
• AIntP-14Background
• AJP-2Background
• AJP-2.1Background
• AJP-2.7Background
• STANAG 6524Background