Кожен військовий картографічний дисплей у NATO відображає одні й ті самі основні речі: дружню піхотну роту, ворожий бронетанковий батальйон, невідомий надводний контакт, заплановану зону ураження. Те, як ці речі виглядають, регулюють два стандарти — APP-6 від NATO та MIL-STD-2525 від США. Вони мають спільного предка, збігаються приблизно на дев'яносто п'ять відсотків і розходяться саме там, де це ламає ваш рендерер. Якщо ви розробляєте програмне забезпечення C2 для коаліційної аудиторії, рано чи пізно ви випустите код, який має «розмовляти» обома. Це інженерне порівняння: походження, ландшафт версій, код ідентифікації символу, набори символів, ампліфікатори, рендеринг та крайові випадки конвертації, які кусають.

1. два стандарти, один предок

MIL-STD-2525 — це стандарт Міністерства оборони США для спільної бойової символіки. APP-6 — Allied Procedural Publication 6, оприлюднений у межах STANAG 2019, — це стандарт NATO. Вони походять від тих самих зусиль 1990-х років надати об'єднаним та коаліційним силам єдину візуальну мову для спільної оперативної картини, і протягом більшої частини своєї історії їх свідомо тримали синхронізованими. MIL-STD-2525A та APP-6A були близнюками; 2525B узгодили з APP-6B. Документ США зазвичай вів перед, NATO ратифікувало близько узгоджену версію через рік-два, а національні системи впроваджували ту, яку вимагав їхній ланцюг акредитації.

Розходження, яке має значення, відбулося на межі поколінь. США опублікували MIL-STD-2525C у 2008 році як зрілий кінцевий стан початкової архітектури. Потім NATO взяло на себе провідну роль у редизайні наступного покоління, і дві спільноти спільно розробили нову модель, що вийшла як MIL-STD-2525D (2014) та APP-6(D) (2017). Тож лінія перевертається: для застарілого покоління вели США; для сучасного покоління стандарти знову зійшлися на спільно сконструйованому дизайні. Практичний наслідок полягає в тому, що 2525D та APP-6(D) набагато ближчі до побайтової еквівалентності, ніж будь-яка попередня пара, — але у вас усе ще є велика встановлена база систем 2525C та APP-6(B) у полі, які використовують зовсім іншу структуру коду.

2. ландшафт версій

Розглядайте стандарти як дві родини. Застаріла родина — це MIL-STD-2525B/2525C та APP-6(A)/(B): 15-символьний код ідентифікації символу, ієрархічна літерно-цифрова схема та каталог символів, організований навколо бойових вимірів. Сучасна родина — це MIL-STD-2525D/2525E та APP-6(D): 20-цифровий числовий код, пласка архітектура наборів символів та суттєво розширений каталог сутностей.

Семантично узгоджені пари — це 2525C ↔ APP-6(B) на застарілому боці та 2525D ↔ APP-6(D) на сучасному боці. 2525E (2022) розширює сучасну модель додатковими наборами символів — зокрема багатшими сутностями космосу, кіберпростору та безпілотних систем — не порушуючи 20-цифрову структуру, тож рендерер APP-6(D) коректно читає більшість кодів 2525E і просто відкочується до невідомої сутності для нових. Знання того, яку пару впроваджує дана партнерська система, — це перше питання, на яке слід відповісти під час будь-якої інтеграції, бо воно вирішує, чи робите ви чисте відображення поле-в-поле, чи трансляцію між поколіннями.

3. структура SIDC

Код ідентифікації символу (SIDC) — це серце обох стандартів, і він повністю змінився між поколіннями. Застарілий SIDC — це 15-символьний рядок. Позиція 1 — це схема кодування, позиція 2 — належність (дружній, ворожий, нейтральний, невідомий, плюс варіанти припущений/підозрюваний), позиція 3 — бойовий вимір (повітря, земля, морська поверхня, підводний простір, космос, SOF), позиція 4 — статус. Позиції 5–10 — це ідентифікатор функції — ієрархічний літерний код, де кожен символ звужує сутність, тож бронетанкова механізована піхотна одиниця та узагальнена піхотна одиниця мають спільний префікс і відрізняються кінцевими символами. Решта позицій несуть модифікатори символу та індикатор ешелону. Він компактний і читабельний для людини, щойно ви його запам'ятаєте, але він жорсткий: не залишається місця, щоб додавати нові сутності, не перевикористовуючи слоти.

Сучасний SIDC — це 20 цифр, суто числовий і позиційний. Цифри 1–2 — це версія. Цифра 3 — це контекст стандартної ідентичності (реальність, навчання, симуляція). Цифри 5–6 обирають набір символів — найважливіше поле, бо воно маршрутизує все, що йде далі. Цифра 7 несе статус, 8 — індикатор штабу/тактичної групи/манекена, 9–10 — дескриптор ампліфікатора. Цифри 11–16 — це сутність / тип сутності / підтип сутності, трирівнева числова ієрархія. Цифри 17–18 та 19–20 — це два слоти модифікаторів. Ключове розуміння з точки зору парсера: сучасний код — це запис із фіксованим зміщенням, а не розбираний рядок, що робить його набагато простішим для валідації та набагато важчим для зловживання, ніж застаріла ієрархія ідентифікатора функції.

Ключове розуміння: 15-символьний та 20-цифровий коди — це не два кодування одних і тих самих даних, а дві різні моделі даних. Застарілий SIDC зливає належність, вимір і функцію в один ієрархічний рядок; сучасний SIDC розділяє стандартну ідентичність, набір символів та числову ієрархію сутностей на незалежні поля фіксованої ширини. Ви не можете перетворити один на інший за допомогою регулярного виразу. Вам потрібна таблиця пошуку, і саме в цій таблиці живе кожен баг конвертації.

4. набори символів та сутності

У сучасній моделі набір символів (цифри 5–6) — це ключ диспетчеризації. Визначені набори включають повітря, повітряна ракета, космос, космічна ракета, наземна одиниця, наземний цивільний, наземне обладнання, наземна установка, заходи контролю, морська поверхня, морський підводний простір, мінна війна, діяльність, радіоелектронна розвідка, а також кілька безпілотних та кіберпросторових наборів, доданих у пізніших ревізіях. Набір символів визначає геометрію рамки, дійсні коди сутностей та доступні поля ампліфікаторів — усе одразу. Символ наземної одиниці використовує родину рамок прямокутник/чотирикутник; символ морської поверхні використовує рамку корпусу корабля; повітряний символ використовує напівзаокруглену «повітряну» рамку.

Це чистіше розділення, ніж застаріле поле бойового виміру, яке поєднувало форму рамки та домен сутності. У сучасній моделі рамка походить від належності плюс набору символів, тоді як піктограма всередині походить від ієрархії сутностей. Саме ця ортогональність робить рендерер, керований даними, практичним: ви будуєте рамку з кількох вхідних даних і шукаєте гліф піктограми за цифрами сутності незалежно. Це та сама дисципліна розділення обов'язків, яку ми описуємо в нашому детальному розборі інженерії символіки з MIL-STD-2525.

5. ампліфікатори та модифікатори

Гліф — це лише половина військового символу. Інша половина — це набір ампліфікаторів — текстові та графічні прикраси, розміщені навколо рамки, поля з літерами від A до Y у стандарті. Поле B — це індикатор ешелону або мобільності, намальований над рамкою (точки команди/відділення, смуги взводу/роти/батальйону, позначки X бригади/дивізії). Поле T — це унікальне позначення — назва або номер одиниці. Поле H — це додаткова інформація, поле W — група дати-часу, поле J — оцінний рейтинг, поле C — кількість, поле Q — стрілка напрямку руху, поле AA — індикатор спеціального штабного персоналу.

Статус (наявний проти очікуваного/запланованого) відображається як суцільна проти пунктирної рамка — маленька деталь, яку величезна кількість рендерерів робить неправильно, бо вона має застосовуватися до обведення рамки, не впливаючи на заливку чи піктограму. Індикатор штабу подовжує штабну лінію вниз від рамки; індикатор тактичної групи обгортає рамку в дужку; індикатор манекена/удаваного маневру додає пунктирне розширення. Ешелон, штаб, тактична група та статус — це незалежні прапорці в сучасному SIDC, що означає, що ваш рушій ампліфікаторів має їх компонувати, а не перемикатися на єдиний перелічений тип символу.

6. рендеринг

На практиці майже ніхто не малює ці символи з сирих PDF-файлів стандартів. Веб-екосистема стандартизувалася на milsymbol, бібліотеці JavaScript з відкритим кодом, яку підтримує Манс Бекман, що генерує військовий символ як вбудований SVG безпосередньо з SIDC плюс об'єкта опцій зі значеннями ампліфікаторів. Ви передаєте їй 20-цифровий (або застарілий 15-символьний) код та набір значень полів, і вона повертає шаруватий SVG: контур рамки, заливку належності, піктограму сутності та навколишній текст і графіку ампліфікаторів, кожен як окремий елемент, який ви можете стилізувати.

Саме шарування робить його швидким. Оскільки рамка, заливка, піктограма та ампліфікатори — це незалежні шари SVG, рендерер може кешувати дорогі частини (геометрію піктограми сутності) та перераховувати лише дешеві частини (текстові ампліфікатори, колір), коли трек оновлюється. У масштабі C2 — тисячі треків, що оновлюються кілька разів на секунду — ви не регенеруєте весь символ на кожне оновлення позиції; ви трансформуєте кешовану групу SVG та переписуєте лише змінений текст ампліфікатора. Поєднання SVG-виводу milsymbol із шаром символів на canvas або WebGL — це стандартний підхід до рендерингу карти в реальному часі на рухомій спільній оперативній картині. milsymbol підтримує як стилі рамок 2525, так і APP-6 через єдину опцію, що є найдешевшим способом задовольнити коаліційного замовника, який хоче варіант рамки NATO, а не США.

7. пастки взаємоконвертації

Відображення застарілого 15-символьного SIDC на сучасний 20-цифровий код — це конвертація, яку ви напишете, і вона є втратною в обох напрямках. Поле належності відображається досить чисто — дружній, ворожий, нейтральний, невідомий мають прямі відповідники — але припущено-дружня та підозрювана ідентичності, а також варіанти навчань джокер/фейкер не всі переживають повний цикл цілими. Бойовий вимір має бути переоформлений як набір символів, і це не один-до-одного: застарілий вимір «земля» розщеплюється на наземну одиницю, наземне обладнання та наземну установку в сучасній моделі, тож ви не можете вивести цільовий набір символів лише з цифри виміру — вам доводиться перевіряти ідентифікатор функції.

Ієрархія ідентифікатора функції — найгірший порушник. Кілька застарілих сутностей не мають точної сучасної сутності, а кілька сучасних сутностей (особливо новіші кіберпросторові та безпілотні набори) взагалі не мають застарілого коду, тож вони деградують до узагальненої сутності на шляху вниз. Ешелон зазвичай виживає; індикатори мобільності іноді ні. Безпечна інженерна позиція — нести оригінальний SIDC дослівно як збережений атрибут і трактувати конвертований код як похідну часу рендерингу, ніколи як систему обліку — у такий спосіб майбутнє виправлення вашої таблиці відображення перерендерує всю картину без міграції даних.

8. вибір для вашого продукту C2

Рішення рідко полягає в тому, який стандарт «кращий» — вони кодують ту саму доктрину. Воно про те, хто споживає ваш вивід. Якщо ваші оператори та коаліційні партнери працюють із системами NATO, рендерте варіант рамки APP-6 за замовчуванням; якщо ви тісно інтегруєтеся з програмами США, за замовчуванням використовуйте MIL-STD-2525. Релізабельність тут теж має значення: сама символіка є несекретною, але сутності, які ви наповнюєте, та варіанти SIDC, які ви підтримуєте, мають відстежувати те, що насправді рендерять акредитовані системи ваших партнерів, щоб ви не надсилали символ, який з'являється порожнім на екрані союзника.

Патерн, який добре старіє, — це стратегія подвійного рендерингу: зберігайте кожен трек з його сучасним 20-цифровим SIDC як канонічну ідентичність, тримайте прапорець стилю рамки (2525 проти APP-6) як уподобання відображення та дозволяйте шару символів видавати будь-який на вимогу. Оскільки milsymbol перемикає стилі рамок з однієї опції, інкрементальна вартість підтримки обох близька до нуля, щойно ваша модель даних чиста. Будуйте конвеєр символів як тонкий, добре протестований шар відображення над єдиним канонічним кодом, трактуйте таблиці конвертації як версіоновані дані, а не жорстко закодовану логіку, і ви поглинете наступну ревізію — 2525F, APP-6(E) — як оновлення таблиці, а не переписування. Для ширшого архітектурного контексту дивіться наш повний посібник із систем C2.