Platform
Modules
By sector
By sector
By standard
Blog
News
Events
AEDP-18
Engineering teams and system integrators building or supplying the CSD Stream Server, sensor and exploitation-system software a NATO or coalition ISR network needs to interoperate
AEDP-18 is NATO's specification for the CSD Stream Server, the interface through which coalition ISR systems publish, discover, query and replay live and recorded motion imagery, GMTI and Link 16 streaming data.
AEDP-18, NATO Standard ISR Streaming Services, is the Allied Engineering Documentation Publication that specifies the "CSD Stream Server", the service through which NATO and coalition intelligence, surveillance and reconnaissance (ISR) systems share streaming sensor data. It covers three kinds of stream: motion imagery (full motion video), ground moving target indicator (GMTI) tracks, and Link 16 tactical data. It complements AEDP-17, NATO Standard ISR Library Interface, by adding a streaming-specific interface on top of that document's catalogue and query model, and both are proposed for agreement under STANAG 4559. This is Edition A, Version 1, promulgated 28 March 2018.
Unlike many of the standards in this catalogue, AEDP-18 is not a management-system or audit document. It is an engineering specification for software: it defines XML schemas, WSDL service contracts, data models and wire formats that a CSD Stream Server, a sensor feed, or an exploitation system has to implement. The organisation it reaches is whoever designs, builds or configures one of those components, typically a defence contractor or system integrator working on a coalition ISR programme, and it reaches that organisation through a contract or interoperability requirement that invokes STANAG 4559 or AEDP-18 directly, not through a general obligation.
A CSD Stream Server must support at least one of the three stream types and provides up to six interfaces. Five are mandatory: Publish, through which sensors declare a new Live Stream and post periodic metadata updates; Query, through which exploitation systems discover Live Streams and search Recorded Streams using the Boolean Query Syntax; Controller, through which exploitation systems request relay of a Live Stream or replay of a Recorded Stream; an NSILI Bridge, which records minimal proxy metadata in an associated NSIL library so a task or an intelligence report can be linked back to the stream it came from; and Replication, through which servers exchange metadata with each other so each holds a representation of the full stream catalogue for the coalition enterprise. The sixth, Notification, is explicitly optional, and its requirements apply only where a server chooses to implement it.
Every metadata attribute in the CSD Stream Server Data Model falls into one of three categories: fixed by definition, fixed by business rule, or genuinely dynamic during the life of the stream. The Publish Interface enforces this distinction directly: a notification is discarded if it is missing a mandatory attribute, or if it tries to change an attribute the data model treats as fixed. A stream's status of NEW, CHANGED or OBSOLETE tells a receiving server whether a sensor is starting, updating or ending a stream, and every server must support the feature the document calls "<forward compatibility>", meaning it can accept and carry metadata extensions it does not itself define, without silently dropping them.
The three stream types are not interchangeable. Downloaded motion imagery must be encoded to the STANAG 4609 motion imagery standard, and replay follows the clip-boundary rules in AEDP-8 so a receiving client can begin decoding immediately. Downloaded GMTI data must be STANAG 4607-format binary data with no padding between packets, and on replay the releasability, mission and job segments must arrive ahead of the dwell data they describe. Link 16 is the outlier: because there is no single originating sensor, the local CSD Stream Server records Link 16 traffic automatically rather than through the Publish Interface, this version of AEDP-18 does not support replicating Link 16 metadata between servers at all, and there are no specific replay requirements for it. Getting these differences right matters for anyone building a server or client that has to handle more than one stream type.
Because a coalition ISR network spans multiple nations and sites, AEDP-18 spends a full annex on how CSD Stream Servers keep each other's catalogues in sync over a Wide Area Network. Every server must implement the Replication Service Interface, exchanging only the change in metadata since the last message rather than full state, and must support Bridgehead Routing so a message received from one peer is also forwarded to every other configured peer. Three deployment modes are mandatory to support: Standalone, with no outbound replication at all; Bridgehead, running in a full or partial mesh; and Read Only, accepting incoming replication only. The specification also sets a concrete non-functional requirement, a sustained throughput of up to 475,200 replication messages per day, derived from an example deployment of five motion imagery sensors updating once a second and five GMTI sensors updating every ten seconds, and it defines an eight-step process for bringing a new server into an existing network using a one-off synchronisation file rather than waiting for it to catch up organically.
The Stream Controller Service Interface, defined in a dedicated annex, is what an exploitation system actually calls to start or stop watching a stream: every operation must carry a username and password under the security profile from AEDP-19, replay of multiple streams together must preserve their original relative timing rather than playing them one after another, and a second call to stop a replay that has already stopped has no effect.
AEDP-18 names no certification body, no notified body and no government surveillance scheme, and it does not describe an interoperability testing programme of its own; its only conformance language is the standard software-engineering convention of RFC 2119 key words (MUST, SHALL, SHOULD, MAY and so on), which an implementer applies to its own design. It also assumes, rather than defines, a working NSILI environment under AEDP-17 and the pub-sub and security services of AEDP-19, and it assumes sensors and exploitation systems that already produce or consume STANAG 4609, STANAG 4607 or STANAG 5516 data in the first place.
AEDP-18 is published by the NATO Standardization Office. Like every NATO standardization document it is free of charge; the Standardization Document Database is the authoritative source, and NATO nations' own standardization authorities can also provide a copy. We credit NATO for the catalogue and neither sell nor host a copy ourselves.
Meeting AEDP-18 is systems engineering: designing the CSD Stream Server's data model correctly, writing conformant WSDL and XML-Schema interfaces, and proving interoperability with other servers on the network. That work happens in software development and system integration, not in a compliance platform, and ComplyTrain makes no claim of mapping to AEDP-18's interfaces.
What ComplyTrain supports is the evidence discipline around that engineering programme: a controlled place to hold interface control and design documentation recording which AEDP-18 baseline and schema version a system implements, the configuration record of which optional capabilities and stream types a deployed server actually supports, training records for the engineers responsible for it, and the audit trail showing a delivered system matches what a contract or coalition programme specified.
What ComplyTrain does not do: it does not design, build or test a CSD Stream Server or any of its interfaces, and it does not verify wire-level interoperability with other coalition systems, because AEDP-18 describes no scheme for us to map to. Which stream types and optional capabilities a given programme actually requires is set by the contract and the customer's quality clause, not by us. See what else sits alongside AEDP-18 in the standards explorer, and talk to us about the evidence trail behind a streaming ISR interoperability programme.
Tell us how you need to work with AEDP-18 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 directly. AEDP-18 is a technical specification that reaches a company through a contract or a coalition programme's interoperability requirement, typically because it invokes STANAG 4559, the agreement under which NATO nations use AEDP-18. It does not create an obligation on its own, and which tier of interoperability actually applies is set by the contract, not by the document itself.
No. STANAG 4559 is the agreement by which NATO nations record their use of the underlying ISR interoperability architecture; AEDP-18 is one of the technical publications proposed for agreement under it, specifically the one defining the CSD Stream Server and its streaming interfaces. AEDP-17, the companion library interface, is proposed for agreement under the same STANAG; AEDP-19, the workflow architecture AEDP-18 also draws on, is a separate NATO ISR publication.
AEDP-17 defines the NATO Standard ISR Library Interface (NSILI), including the catalogue entry encoding and query service that AEDP-18 reuses for streaming data. AEDP-19 defines the ISR Workflow Architecture, supplying the publish/subscribe notification service and the security profile AEDP-18's interfaces depend on. AEDP-18 adds the streaming-specific pieces, publishing, querying, controlling and replicating Live and Recorded Streams, on top of both.
No. Motion imagery and GMTI streams follow the general publish, query, replay and replication model, each downloaded in its own STANAG format (4609 for motion imagery, 4607 for GMTI). Link 16 is handled differently throughout: it is recorded automatically rather than published by a sensor, and this version of AEDP-18 does not support replicating Link 16 metadata between servers at all.
No. AEDP-18 names no certification body, notified body or government surveillance scheme, and describes no assessment cycle. Its only conformance language is the RFC 2119 key words (MUST, SHALL, MAY and similar) that a development team applies to its own design; in practice, interoperability is proven by exchanging data with other CSD Stream Servers, not by an audit against this document.
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.