ADatP-3 (STANAG 5500): формати текстових повідомлень НАТО — як це працює

ADatP-3 — Allied Data Publication 3, оприлюднена угодою STANAG 5500, — це система форматування текстових повідомлень НАТО, відома як FORMETS: правила, конструкції та словник, якими створюється кожне форматоване повідомлення НАТО — від доповіді про обстановку до наказу на застосування авіації. Близько 400 повідомлень, побудованих за цими правилами, каталогізовано в APP-11 — 407 форматів текстових повідомлень у чинній редакції — і з 2008 року кожне з них існує також у формі XML-MTF.

Що таке ADatP-3 (STANAG 5500)?

Офіційно публікація має назву NATO Message Text Formatting System (FORMETS) — Concept of FORMETS (CONFORMETS). Зустрічаються написання ADatP-3 або ADatP-03 — обидва позначають ту саму Allied Data Publication. Чинна версія — Edition A Version 4, оприлюднена 1 липня 2021 року в межах угоди STANAG 5500 Edition 8. Супроводжує стандарт Команда НАТО з можливостей форматів текстових повідомлень (MTF CaT), а оприлюднені редакції перелічені у відкритій базі даних Офісу стандартизації НАТО.

Що саме стандартизує цей документ, найкраще видно з підсумку самого НАТО: FORMETS надає «синтаксис і правила, що регулюють подання узгоджених концептуальних визначень (полів) та впорядкування цих полів у речення (набори) і тексти повідомлень», і призначений для всіх символьно-орієнтованих форматованих повідомлень у системах командування та управління НАТО. Іншими словами, ADatP-3 — це граматика форматованих повідомлень НАТО. Він не визначає окремі повідомлення — це завдання каталогу APP-11, описаного нижче.

Довговічність пояснює сама проєктна мета. Форматоване повідомлення має бути читабельним для оператора за найпростішим терміналом, розбираним програмою на сучасному сервері та достатньо компактним для обмеженого тактичного каналу. Символьно-орієнтований текст із роздільниками-косими рисками задовольняє всі три вимоги — саме тому трафік ADatP-3 і в 2026 році продовжує рухатися поруч з усім іншим у стеку стандартів сумісності НАТО.

ADatP-3, APP-11, ADatP-34, APP-6: який стандарт за що відповідає

Ці чотири документи постійно плутають — зокрема в маркетингових матеріалах вендорів, — тому наводимо коректне розмежування, перевірене за відкритими реєстрами стандартизації НАТО:

Співвідношення перших двох документів є точним. Згідно з описом NISP від самого НАТО, база даних ADatP-03 містить усі формати текстових повідомлень під конфігураційним контролем робочої групи з форматів повідомлень, а «узгоджені MTF після публікації в базовій лінії регулярно включаються до STANAG 7149, Каталогу повідомлень НАТО — APP-11». ADatP-3 — це граматика; APP-11 — словник повідомлень, написаних цією граматикою. ADatP-34 стоїть на рівень вище за обидва: NISP вказує програмам та спіралям Federated Mission Networking (FMN), які стандарти використовувати — зокрема ADatP-3 і APP-11 — і сам не визначає жодного повідомлення. Про роль NISP у виборі профілів ми докладно пишемо в нашій статті про структури даних ADatP-34, а про символіку — у порівнянні APP-6 і MIL-STD-2525.

Структура форматованого повідомлення: набори, поля, роздільники

Кожне повідомлення MTF — це послідовність наборів; кожен набір — це ідентифікатор набору і далі поля. Три конвенції несуть майже весь синтаксис:

• Набір починається з ідентифікатора — мнемоніки на кшталт MSGID, REF чи NARR — за якою йде коса риска.
• Поля розділені однією косою рискою /. Поле — це кодований запис фіксованого формату (група дата-час на кшталт 011800Z, позиція на кшталт 4040N01100E) або кодований запис із міткою, як LM:4040N01100E.
• Набір завершується подвійною косою рискою //. Довгі набори продовжуються в наступних рядках без повторення ідентифікатора.

Приклад нижче — тактична доповідь у стилі відкритої документації USMTF, спрощена для наочності і не є оперативним повідомленням — демонструє всі три:

MSGID/TACREP/CTF 124//
MAROP/011800Z/1/US/SUB/CL:WASHINGTON/NAME:SEAROVER/
LM:4040N01100E//
OPSUP/ACTTYP:ASW//
AIROP/020200Z/6/US/FTR/F15/TN:401/LM:4130N01000E/
CRS:180/SPD:600KPH/ALT:12000FT//

Окремі універсальні набори повторюються в оперативному та адміністративному трафіку: MSGID (ідентифікація повідомлення — тип, автор, серійний номер), EXER і OPER (ідентифікація навчань та операції), REF із парним йому NARR (посилання та їхній наративний розгорнутий виклад), SUBJ, POC і GENTEXT, що несе загальний текст під специфікатором вмісту (GENTEXT/REMARKS/…//). Точний склад наборів кожного повідомлення — які набори, у якому порядку, як часто — визначено для кожного повідомлення в APP-11.

Кожен набір у записі каталогу несе відомості про входження (обов'язкове або умовне — залежно від іншого вмісту) та про повторюваність (скільки разів він може з'являтися — повідомлення з трьома посиланнями несе три набори REF). Поля мають приписані формати, а для кодованих полів — визначені таблиці значень. Фізично набори викладаються лінійно (поля йдуть за ідентифікатором, як у прикладі) або стовпчиковими рядками — рядки завдань наказу на застосування авіації є класичним стовпчиковим прикладом: один вирівняний рядок із роздільниками на кожен політ чи виліт. Усе це текст у верхньому регістрі, символьно-орієнтований, в обмеженому наборі друкарських символів — саме це дозволяє йому виживати на будь-якому терміналі й у будь-якому каналі.

Базові лінії та редакції: на який каталог орієнтується ваш парсер

«Який у вас ADatP-3?» — це перше питання сумісності. Каталог повідомлень розвивається через версіоновані базові лінії, а розгорнутий парк систем розкиданий по двох десятиліттях таких ліній:

Цю хронологію складено з відкритої історії редакцій, яку публікує спільнота супроводу каталогу, та з відкритих реєстрів НАТО. Для розробників важливі дві зміни APP-11(E): WGS 84 став єдиним геодезичним датумом, дозволеним для позиційної інформації (можливість обрати інший датум вилучено), а раніше кодовані географічні об'єкти стали вільним текстом, що регулюється списками конкретної операції. За каталогом сам звід правил пройшов шлях від STANAG 5500 Edition 4 (епоха базової лінії 1999 року) через Edition 7 (2010) до чинної Edition 8, в межах якої у 2021 році оприлюднено ADatP-03 Edition A Version 4.

В оперативному плані чинну базову лінію визначає ланцюг постановки завдань — план операції, морські чи повітряні оперативні накази або специфікація спіралі FMN, до якої приєднується операція. Наприклад, профіль повітряних операцій FMN перевів підтримку форматованих повідомлень із застарілих визначень ATO/ACO базової лінії 11 (задокументованих у старіших союзних публікаціях) на APP-11(E). Та сама дисципліна постановки завдань керує операціями з каналів передачі даних, де OPTASK LINK визначає параметри всієї мережі — див. як OPTASK LINK керує Link 16.

XML-MTF: те саме повідомлення в XML

До 2008 року форматовані повідомлення існували лише як текст із косими рисками. Відтоді каталог APP-11 містить також визначення XML-MTF зі свідомо узятим відображенням «один до одного» між текстовим і XML-поданням — зберігається перевага текстової форми за смугою пропускання, але стає придатним стандартний XML-інструментарій. Концептуальна частина ADatP-3 (CONFORMETS) специфікує сімейство технічних специфікацій XML-MTF у тому вигляді, в якому вони застосовуються до MTF ADatP-03 для отримання еквівалентних похідних XML-форматів.

Для інженерів це має два практичні наслідки:

• Працює стандартний XML-інструментарій. Схеми каталогу можуть керувати валідуючими парсерами, вибіркою XPath і відображенням XSLT замість власноруч написаного коду обробки повідомлень.
• Найменування кероване. НАТО зареєстрував формальний простір імен URN (urn:nato:) у RFC 7467, з артефактами форматів текстових повідомлень як іменованим типом ресурсу, тож XML-простори імен і схеми отримують стабільні ідентифікатори без конфліктів.

XML-подання — це ще й шлях супроводу: чинна робота над каталогом включає оновлення XML до найновіших правил найменування та проєктування НАТО і запровадження JSON-варіанту повідомлень. Якщо ви з середовища TAK, зауважте, що XML-MTF — значно важча конвенція, ніж XML Cursor on Target, яким обмінюються застосунки тактичної обізнаності, — розібрані приклади CoT показують, наскільки мінімальним є цей формат на порівнянні, а шлюзи між двома світами — це окремий інтеграційний проєкт.

USMTF (MIL-STD-6040): американський аналог і зв'язок між ними

Сполучені Штати ведуть власну програму форматування текстових повідомлень — USMTF, що регулюється MIL-STD-6040 (від 2008 року — серією MIL-STD-6040B, з каталогом у вигляді XML-MTF-схем) і керується інструкцією Голови Об'єднаного комітету начальників штабів CJCSI 6241.04E (жовтень 2023 року). Інструкція прямо визначає відповідність: еквівалентом правил і конвенцій MIL-STD-6040 у НАТО є ADatP-3, а APP-11 — еквівалент Каталогу повідомлень USMTF. USMTF обов'язковий для всіх вимог обміну символьно-орієнтованими форматованими повідомленнями в американських системах, якщо лише багатонаціональною угодою прямо не передбачено інше.

Два набори правил близькі: опубліковані настанови спільноти супроводу описують їх як дуже подібні, з лише незначними відмінностями, і низку повідомлень гармонізовано між двома каталогами. Розгорнуті базові лінії USMTF (1998, 2000 і 2004 роки в застарілих системах) паралельні історії базових ліній НАТО. Для розробника практичний висновок такий: один рушій MTF може обробляти обидва формати — але його має вести правильний пакет каталогу, APP-11 НАТО або USMTF, для тієї базової лінії, яку партнер фактично використовує. І не плутайте жоден із них із VMF (MIL-STD-6017) — двійковим бітоорієнтованим форматом для радіоканалів, а не символьно-орієнтованим форматом повідомлень.

Як ПЗ обробляє MTF: парсер, валідатор, генератор — і шлях у картину C2

Формалізований трафік повідомлень — це корисне навантаження, а не транспорт: він рухається системами військової обробки повідомлень (MMHS, STANAG 4406), застарілою ретрансляцією ACP 127 або просто як вкладення електронного листа чи чату — профілі FMN прямо дозволяють форматовані повідомлення як корисне навантаження поверх кількох транспортів. Наша супровідна стаття про військовий обмін повідомленнями НАТО розглядає шар обробки. Те, що система C2 зобов'язана зробити з повідомленням після надходження, — це конвеєр обробки:

• Розбір на основі граматики. Розбийте текст на набори за ідентифікаторами, розділяйте поля за роздільником, з'єднуйте рядки продовження та будуйте дерево повідомлення. Граматика стабільна для всього каталогу, тож один парсер обслуговує кожен тип повідомлень.
• Валідація на основі каталогу. Визначте тип повідомлення з MSGID, далі перевірте порядок наборів, входження та повторюваність, формати полів і кодовані значення проти визначень узгодженої базової лінії. Помилки треба повідомляти з позначенням набору та позиції поля, бо відправнику треба їх знайти.
• Перетворення та відображення. Конвертуйте між текстом із косими рисками та XML-MTF (один до одного), далі відображайте поля в модель даних системи. НАТО супроводжує для цього еталонні моделі — Інформаційну модель C2 НАТО (NCIM) і специфікації MIP — і конкретні відображення вже існують у стандартах: стандарт відстеження дружніх сил ADatP-36 визначає відображення між форматами текстових повідомлень FFI та NFFI, а профіль медіації FMN перекладає FFI MTF у модель даних піхотинця.
• Генерація через той самий каталог. У вихідному напрямку редактори з формами, згенеровані з шаблонів каталогу, контролюють обов'язкові поля й таблиці значень на етапі введення; генератор серіалізує в текст або XML-MTF, перевіряє повний цикл і проставляє групу дата-час, пріоритет та адресацію.

Оскільки обидва напрямки керуються тими самими машиночитаними визначеннями, каталог фактично є контрактом між відправником і одержувачем — саме тому обмін форматованими повідомленнями є повноцінним тестовим пунктом на щорічному заході з сумісності НАТО, де відпрацьовуються профілі FMN для авіаційних, морських, кібернетичних форматованих повідомлень та повідомлень медичної евакуації. Підготовка до нього — окрема дисципліна: див. наш посібник із сертифікації CWIX і те, як ми показуємо результати коаліційних випробувань у Interoperability Dashboard.

Підводні камені, що ламають сумісність MTF

Більшість збоїв форматованих повідомлень не є екзотичними:

• Невідповідність базової лінії. Партнер, що досі на APP-11(D), надсилає повідомлення, яке ваш валідатор APP-11(E) відхиляє — або приймає, тихо неправильно читаючи виведене з ужитку поле. Перехід на APP-11(E) вивів з ужитку 40 повідомлень і зробив WGS 84 єдиним дозволеним датумом; парсер, який досі приймає інші датуми, спотворить координати. Зафіксуйте базову лінію в інструкціях зі зв'язку операції та виявляйте базову лінію відправника з ідентифікації повідомлення.
• Національні розширення. Країни додають набори й поля в національних варіантах. Стійка стратегія — «приймати і позначати»: розбирати те, що каталог знає, карантинувати і журналювати те, чого він не знає, і показувати відмінність оператору — ніколи не пропускати тихо.
• Зловживання вільним текстом. Запхання структурованих даних у прозу GENTEXT або NARR через те, що кодовані поля «не вміщаються», руйнує машинну обробку для кожного одержувача. Якщо інформація важлива для автоматизації — її місце в кодованих полях; якщо нове кодоване поле справді потрібне, це пропозиція зміни до каталогу, а не локальний хак.
• Застарілі шаблони редактора. Форми, не згенеровані заново з чинної базової лінії, дозволяють операторам пропускати нові обов'язкові поля; валідація тоді зазнає невдачі далі за ланцюгом — у партнера, а не на етапі введення.