AEDP-12 стандарт NATO на дані супроводу цілей для ISR

Що це таке

AEDP-12, технічний документ стандарту NATO на супровід цілей для ISR, - це союзна публікація інженерної документації, яка несе фактичний зміст, що стоїть за STANAG 4676. Ці дві назви часто вживають так, ніби вони взаємозамінні, і сам документ запобігає цьому у власних умовностях: "AEDP-12 refers to the technical standard document, including its data model," тоді як "STANAG 4676" означає "the agreement among the nations to implement the standard." Його заявлена мета - "to promote interoperability for the production, exchange, and exploitation of tracking data among North Atlantic Treaty Organization (NATO) Intelligence, Surveillance, and Reconnaissance (ISR) systems." Конкретно це означає модель даних, виражену в UML, усього, з чого побудований "track": сенсори, виявлення, точки треку, положення та швидкість, свідчення, ідентичність і зв'язки між треками (розділення, злиття, зшивання), - разом із нормативною схемою XML і необов'язковим двійковим кодуванням EXI, які перетворюють модель у файл або потік, що система справді може передати.

Поточне видання, прочитане тут, - це видання B, версія 2, оприлюднене в березні 2022 року. Це не легка редакція: "STANAG 4676 Ed. 2 is incompatible with STANAG 4676 Ed. 1," бо модель даних і синтаксис XML переробили з нуля, щоб задовольнити функційні вимоги та вимоги до обсягу даних, яких попереднє видання виконати не могло. Система, побудована за виданням A, не може обмінюватися даними з системою, побудованою за цим виданням, без свідомого кроку перетворення.

До кого він звертається і як набуває обов'язковості

Документ увесь час говорить до людей, які будують системи, що виробляють або споживають ці дані, - "data producers" і "data consumers" у його власних термінах, а не "suppliers" як таких. Його правила розширення написані прямо для них: "if the data producer has additional data to communicate for an object, it shall use those extension mechanisms to add additional data fields to the object," і будь-яке таке розширення має лежати в "a namespace specific to the program, system or developer of the extension." На практиці це підрядник або програмний офіс, який будує чи інтегрує спроможність супроводу цілей ISR для NATO.

Те, як він набуває обов'язковості, повторює взірець, спільний для кожної союзної публікації: країни ратифікують STANAG, що його охоплює, а AEDP-12 дає технічну суть, яку ця ратифікація вводить у дію. Країна може ратифікувати із застереженнями щодо окремих частин AEDP-12, а не щодо всього документа: власний запис про оприлюднення цього видання показує, що Франція відмовилася впроваджувати додатки B і C "as it stands because they were drafted using a process that does not comply with APP-15," а Бельгія прийняла стандарт для наявних у неї повітряних засобів, відклавши рішення щодо F-35 до його постачання. Сам AEDP-12 не описує, як це доходить до конкретної компанії; це справа договору або національного органу, який вимагає відповідності STANAG 4676/NITS у конкретній програмі, а не того, що визначає технічний документ.

Модель даних і два її профілі відповідності

Кожен відповідний файл або потік даних несе рівно один кореневий об'єкт, NITSRoot - "a conformant instantiation of the model shall contain one and only one NITSRoot object" - який тримає оголошення профілю відповідності, позначку часу створення, рядок видання та версії і блоки, що описують продукт, збирання, задіяні сенсори й трекери, а також сам TrackMessage. TrackMessage - це те, де живе зміст супроводу: виявлення, TrackData, побудовані з одного чи кількох TrackSegments із TrackPoints, записи ProcessedTrack для об'єднаного або згладженого виходу, записи TrackLinkage для розділень, злиттів і зшивань між треками та записи MotionEvent для маневру, що становить інтерес, як-от початок руху, зупинка або колона.

Файл оголошує один із двох профілів відповідності. STANDALONE означає, що кожен об'єкт, на який файл посилається, включений у той самий файл. DATASTREAM означає, що пізніші файли можуть посилатися на об'єкти, надіслані раніше, замість повторювати їх; це компактніше, але накладає справжній тягар на споживача: система, яка не може зберігати дані між файлами або читає потік надто повільно, щоб охопити кожну частину, взагалі не може використовувати вихід DATASTREAM. Який профіль вибирає система - це архітектурне рішення, ухвалене під час її проєктування, а не те, що потім змінюють без наслідків.

Що насправді має надати відповідний виробник даних

Додаток A, хоча документ позначає весь цей додаток як довідковий, проходить полями, які глава 2 вже робить обов'язковими: профіль відповідності, час створення і рядок видання та версії в кореневому об'єкті; ідентифікатор і назва продукту; призначення збирання (операційне, навчальне, випробувальне тощо) та його сутність (реальне, змодельоване чи змішане); назва та вид сенсора; тип, назва і версія трекера; базовий час повідомлення і крок часу; і в кожному блоці даних про положення та рух - система координат і саме положення. "Table A.1-1 are the minimum mandatory data fields that must be supplied." Усе, що менше за це, не є відповідним треком STANAG 4676, що б ще не містив файл.

Виробник даних, який має дані, не охоплені моделлю, повинен використати власний механізм розширення схеми, а не перепризначати наявне поле, і розкрити його повністю: "the complete syntax and semantics of all extensions shall be disclosed to the owning party with sufficient detail to allow a vendor of the owner's choice to correctly parse and interpret the data." Розширення не може перевизначати те, як тлумачать основний стандарт, а споживач, який не розпізнає певного розширення, все одно має правильно витлумачити решту файла навколо нього.

Класифікацію опрацьовують через мітки метаданих конфіденційності за STANAG 4774, а не через щось, що AEDP-12 визначає сам: кореневий об'єкт "must contain the originatorConfidentialityLabel element and may also contain the alternativeConfidentialityLabel element and the metadataConfidentialityLabel element, as required by system requirements." Національні схеми маркування нашаровуються поверх цих елементів, а не замість них.

Щодо кодування, відповідна реалізація передає дані як звичайний текстовий XML або як EXI, двійковий формат XML від W3C: "Conformant implementations shall exchange data using one of these two encodings specified in this standard," і власна рекомендація групи кустодіальної підтримки віддає перевагу EXI над звичайним текстом для всього, що виходить за межі малих даних з низькою швидкістю, бо звичайний текст "will be detrimental to satisfying program requirements" усюди, де важлива низька затримка чи обмежена смуга пропускання.

Як перевіряють відповідність

Для AEDP-12 немає сертифікаційного органу, і документ його не створює: у ньому ніде не описано ні акредитованого органу, ні схеми під керівництвом NATO, ні державного режиму нагляду. Що документ таки визначає - це технічну, придатну до перевірки властивість: "The XML schema defined within the standard is normative for conformance only. Implementations may use any method to write the XML formatted data as long as that resulting data conforms to the schema." На практиці вихід виробника даних або проходить перевірку за цією схемою, а для EXI розкодовується назад у той самий відповідний схемі зміст, або ні; споживач або правильно тлумачить об'єктну модель відповідного файла, або ні. Документ не називає власного циклу періодичного аудиту чи випробувань на інтероперабельність, окрім зауваги, що нові розширення та профілі відповідності варто реєструвати в групі кустодіальної підтримки.

Де він стоїть серед інших стандартів NATO

AEDP-12 підпадає під STANAG 4676 - ратифіковану угоду, яка надає йому чинності. Поза цією обкладинкою він опирається на широкий набір інших союзних і цивільних документів і вказує на них, кожен - для конкретної частини моделі: STANAG 4774 та ADatP-4774 для маркування конфіденційності; STANAG 4607 для полів індикатора рухомих наземних цілей, на які безпосередньо відображаються його радарні класи; STANAG 4609 для стандарту рухомих зображень, з яким узгоджені його класи зображень; STANAG 4545 для формату зображень, з якого походять його поля ідентифікатора станції; STANAG 1241 для значень ідентичності, з яких безпосередньо побудований його клас ідентичності; STANAG 2019, що охоплює APP-6, для таблиці умовних позначень, якою класифікують супроводжуваний об'єкт; STANAG 4162 та AIDPP-01 для процесу поєднання даних розпізнавання, що стоїть за його класами джерел ідентифікації; і STANAG 7194, STANAG 4193, STANAG 5516, STANAG 4559 та його супутні публікації AEDP-17, AEDP-18 і AEDP-19, AJP-2.1 та APP-15, названий у власному записі застережень цього видання як стандарт складання документів, якого, як виявилося, не дотримувалися два його додатки.

Стандарти, на які він посилається

• APP-15Довідково
• APP-06Довідково
• STANAG 3680Довідково
• STANAG 5527Довідково
• STANAG 4774Довідково
• STANREC 4777Довідково
• STANAG 4545Довідково
• STANAG 4607Довідково
• STANAG 4715Довідково
• STANAG 2019Довідково
• STANAG 7149Довідково
• STANAG 1241Довідково
• STANAG 4559Довідково
• AEDP-17Довідково
• AEDP-18Довідково
• AEDP-19Довідково
• STANAG 4609Довідково
• STANAG 5516Довідково
• STANAG 7194Довідково
• AIntP-07Довідково
• ADatP-4774Довідково
• STANAG 4193Довідково
• STANAG 4162Довідково
• AIDPP-01Довідково
• APP-11Довідково
• AJP-2.1Довідково

Інші стандарти в темі «Авіаційні озброєння»

• AEDP-02AEDP-02 - архітектура взаємодії ISR NATO
• AEDP-03AEDP-03 - керівні матеріали з санітарної обробки пам'яті розширених систем зберігання даних
• AEDP-05AEDP-05 - посібник з впровадження інтерфейсу бібліотеки ISR NATO
• AEDP-06AEDP-06 - інтерфейс розширеного зберігання даних NATO (NADSI)
• AEDP-17AEDP-17 - стандартний інтерфейс бібліотеки ISR NATO
• AEDP-18AEDP-18 стандартні служби потокової передачі ISR для NATO