AEDP-05 implementation guide for the NATO ISR library interface

What it is

AEDP-05 (Edition 2, May 2013) is a NATO Allied Engineering Documentation Publication written for the engineers who build software to the NATO Standard ISR Library Interface (NSILI), the interoperability agreement recorded in STANAG 4559. NSILI is the interface NATO nations use to search, discover and retrieve intelligence, surveillance and reconnaissance (ISR) data, including imagery, motion imagery and moving-target-indicator products, held in each other's libraries. AEDP-05 does not set requirements of its own. It walks through, with Java and C++ examples, how implementers have actually built the pieces STANAG 4559 defines, and it records what interoperability testing between 2008 and 2011 turned up about where different vendors' middleware disagreed.

An implementation guide, not the standard itself

The guide is explicit that its job is to support STANAG 4559, not replace it: it "provides updated technical and management guidance for implementing the NATO STANAG 4559: NSILI" as part of the wider architecture. It is also guidance rather than something nations formally ratify. The Letter of Promulgation records only that AEDP-05 "has been approved by the nations in the JCGISR" before NATO's Standardization Agency promulgates it, and the document describes adoption of the guide itself as something "encouraged by the NSILI CST and the JCGISR", not mandated. STANAG 4559 is the agreement a nation implements; AEDP-05 is what an engineering team reaches for once a programme has to deliver a STANAG 4559-conformant library or client, to see how the interface has actually been built elsewhere.

Building the client/server connection

A server publishes the CORBA reference to its Library object as an Initial Object Reference (IOR) string, made available to clients over HTTP(S). A client downloads that string, converts it back to a CORBA object and narrows it to a Library reference to log in. The guide walks through each step in Java and C++ and covers the practical problems of doing this across firewalls and Network Address Translation, including specific middleware settings that have caused interoperability failures during testing - for example, a VisiBroker parameter that defaults to a setting where, in the guide's own words, "a marshalling error is caused when receiving the query results."

Searching and retrieving ISR products

The CatalogMgr interface offers a way to count matching results and a way to retrieve them, each returning a request object that moves through defined states as a search runs. The guide gives worked examples of building a Boolean Query Syntax (BQS) string, including date, wildcard, text-comparison and geospatial queries, and recommends building a proper parser from the BQS grammar in STANAG 4559 rather than trying to convert queries to SQL with plain string substitution. Products can be retrieved directly by URL, or ordered through the OrderMgr, which supports alterations such as chipping (cutting a rectangular subset out of a large image), rescaling and format conversion, with delivery by HTTP(S), e-mail or physical media.

Chipping and metadata: what changes, what must not

Cutting a chip out of a large image forces several image sub-header fields to be recalculated, including dimensions, geolocation and file length. One field is a deliberate exception: "Since chipping does not change the acquisition time, IDATIM must not be changed." The guide also recommends always adding an ICHIPB tag to a chip rather than recalculating every other piece of metadata, "so the other TREs can be included in the chipped image without change."

Callbacks, and where implementers hit deadlocks

Callbacks let a server notify a client asynchronously once a long-running request finishes, but the guide documents two concrete deadlock patterns implementers have hit when a callback's registration and its response are both handled synchronously. Its fix is direct: implement the callback itself asynchronously, or hand it off to a separate thread so registration is never blocked waiting on it.

Security sits outside the interface

STANAG 4559 assumes security is handled outside the API itself, on networks and workstations already protected to the classification level in use; the interface adds no access control of its own. The guide describes two ways coalitions have layered security on top of that assumption in practice: exposing only a "Community of Interest" library carrying pre-released information to outside partners, or routing traffic through an adaptor layer that can add authentication and integrity checks between communities.

How the agreement is governed, and what the interface will not do for you

STANAG 4559 is managed by the Joint Capability Group on ISR, which appoints a Custodian to maintain the text and route proposed changes; disagreements between nations go to the ASIISG sub-group for a decision, and approved changes eventually go to the nations for ratification. AEDP-05's own changes follow the same process but, as an AEDP rather than a STANAG, are approved at JCGISR level and promulgated rather than put through national ratification. The guide is equally direct about a gap in the interface itself: an artifact marked obsolete through the interface only has its status field changed, because "removing, in terms of the artifact completely vanishing from the library (both metadata and files), is not supported via the STANAG4559 interface." True deletion needs an administrative mechanism outside STANAG 4559.

Standards it references

• STANAG 4559Background
• STANAG 4545Background
• STANAG 4607Background
• STANAG 4609Background
• AAP-03Background
• AEDP-02Background
• STANAG 4658Background
• STANAG 4676Background
• STANAG 7023Background
• AEDP-12Background
• AAP-32Background
• STANAG 5516Background