NATO C2 Information Model: впровадження NCIM та обмін даними

Автор: Інженерна команда Corvus Intelligence · Про команду →

25 червня 2026 12 хв читання

NATO C2 Information Model — NCIM — канонічна семантична основа під стандартами обміну даними командування та керування Альянсу. Там, де структури даних ADATP-34 визначають формати повідомлень, а MIP4 IES NATO ground standard — протоколи обміну для сухопутних військ, NCIM перебуває на один шар вище обох: вона визначає, які речі існують в операції C2, як ці речі пов'язані між собою та які дані слід записувати про кожну з них. Кожен стандарт впровадження НАТО, що обмінюється операційними даними, відображає свої структури на NCIM. Тому розуміння NCIM не є необов'язковим для інженерів, які хочуть орієнтуватися в ширшому ландшафті стандартів C2 НАТО: це спільний орієнтир, який робить решту повного посібника з інтероперабельності НАТО узгодженим.

Що таке NCIM і чому вона існує

Проблема інтероперабельності C2 Альянсу в 1990-х була передусім не проблемою протоколів, а проблемою семантики. Країни НАТО реалізували системи C2, які обмінювалися повідомленнями, але одне й те саме поле в системах двох країн означало різні речі. «Статус підрозділу» OPERATIONAL в одній системі охоплював інший поріг готовності, ніж в іншій. Коли системи обмінювалися даними, байти надходили, але сенс не був спільним. Саме цю проблему створили NCIM, щоб її розв'язати.

NCIM (NATO C2 Information Model) — канонічна концептуальна та логічна модель даних Альянсу для інформації командування та керування. Вона визначає типи сутностей, що беруть участь в операціях C2, зв'язки між цими сутностями та атрибути — з їхніми типами даних і областями значень, — які слід записувати про кожен тип сутності для підтримки обміну операційною інформацією. Вона не визначає формати передавання, мережеві протоколи чи серіалізацію: це відповідальність стандартів впровадження, які посилаються на NCIM як на свою семантичну основу.

Лінія походження NCIM простежується через кількох попередників. JC3IEDM (Joint Consultation, Command and Control Information Exchange Data Model) була першою всеохопною моделлю даних C2 Альянсу, спільно розробленою країнами НАТО наприкінці 1990-х як формально специфікована реляційна модель, що охоплює весь спектр операційних даних. JC3IEDM успадкувала NC2IEDM (NATO C2 Information Exchange Data Model), яка уточнила модель сутностей і розширила її на об'єднані операції в усіх доменах. NCIM представляє поточну еволюцію: модель, структуровану в окремих концептуальному та логічному шарах, узгоджену з принципами сучасної інформаційної архітектури та спроєктовану як батьківську модель, від якої доменні стандарти впровадження походять як профілі.

Зв'язок з іншими стандартами даних НАТО прямий. Модель даних MIP4, що визначає типи сутностей Unit, Equipment, Task і пов'язані з ними для обміну C2 сухопутних військ, — профіль NCIM для наземного домену. Структури повідомлень у ADatP-34 організовані відповідно до семантики NCIM: кожен тип повідомлення ADatP-34 відповідає патерну екземплярів сутностей NCIM. C-BML (Coalition Battle Management Language) — XML-мова для машинооброблюваних наказів, використовує типи сутностей Activity і Plan з NCIM як свою семантичну основу. Тому розуміння ієрархії типів сутностей NCIM та семантики зв'язків дає спільну систему координат для орієнтації в MIP4, ADatP-34 і C-BML як в узгодженій системі, а не як у трьох незалежних стандартах.

Ієрархія типів сутностей NCIM

NCIM визначає шість типів сутностей верхнього рівня. Ці шість типів разом охоплюють кожну категорію інформації, що з'являється в операції C2 НАТО, і кожна сутність у моделі даних рівня впровадження простежується до рівно одного з них.

Activity — тип сутності для запланованих або фактичних дій. Місії, завдання, фази операції, зіткнення та повідомлені події в NCIM — усе це Activity. Activity має підтипи для різних категорій дій: Task (спрямована дія, призначена Organisation або Resource), Mission (директива вищого рівня, що охоплює кілька Task) і Event (спонтанна подія, про яку повідомляють, а не призначають). Ієрархія Activity — основна структура, через яку операційні накази подають у системах на основі NCIM.

OperationalObject охоплює сутності, які відстежують, беруть на приціл або моніторять, але самі не є діячами. Цілі, райони інтересу, номіновані точки, оцінки загроз і розвідувальні повідомлення про підрозділи противника — це OperationalObject. Розрізнення з Organisation і Resource (які представляють свої або нейтральні сутності з відомою ідентичністю) важливе: OperationalObject може мати невизначену ідентичність, невизначене розташування і може бути гіпотезою, а не підтвердженим спостереженням.

Organisation представляє структуровані групи особового складу з відносинами командування. Військові підрозділи всіх рівнів (взвод, рота, батальйон, бригада, дивізія) — це Organisation. Ієрархія Organisation відображає структуру командування через батьківсько-дочірні зв'язки між екземплярами Organisation, причому кожна Organisation має стандартне позначення, організаційний тип із таксономії ORBAT НАТО та відносини командування з батьківською Organisation (командування, підтримка, операційне керування, тактичне керування).

Resource охоплює озброєння, техніку та особовий склад як окремі одиниці, а не як організовані групи. Конкретна машина, система озброєння, засіб зв'язку або окрема особа, що діє в конкретній ролі, — це Resource. Resource пов'язані з Organisation через відносини призначення та оснащення: батальйон (Organisation) має пов'язані машини (Resource), а відносини оснащення несуть статус призначення та часовий діапазон. Розрізнення між Organisation і Resource приблизно відображає розрізнення між підрозділами та обладнанням у переліку складу озброєння.

Location — тип сутності для всієї інформації про позиції та геометрію. Рішення NCIM зробити Location повноцінним типом сутності, а не вбудовувати координати як атрибути інших типів сутностей, має важливі наслідки для впровадження. Екземпляр Location несе геометрію (точка, ламана, полігон, коридор або складена), систему координат, оцінку невизначеності позиції, часове вікно дійсності та індикатор джерела позиції. Інші типи сутностей посилаються на Location за ідентифікатором, а не вбудовують координати. Такий дизайн дозволяє посилатися на ту саму Location з кількох сутностей, підтримує прикріплення метаданих невизначеності та дійсності до позиційних даних і дає змогу моделювати історію позицій як послідовність екземплярів Location, пов'язаних з однією Organisation або Resource.

Plan — тип сутності для продуктів операційного планування. План операції, фрагментарний наказ, наказ про перехід до наступної фази або документ концепції операції в NCIM — це Plan. Тип сутності Plan має підтипи для різних категорій планувальних продуктів і несе зв'язки до Activity, які він спрямовує, Organisation, які він залучає, та Location, які він призначає як цілі.

Структура успадкування в межах кожного з цих шести типів важлива для впровадження. Усередині Activity, наприклад, повний ланцюг успадкування такий: Activity → Task → ControlMeasureTask (завдання, що спрямовує розміщення або зняття засобу керування) — кожен рівень додає атрибути, специфічні для свого підтипу, успадковуючи всі атрибути батьківського. Стандарти впровадження обирають потрібну глибину успадкування: MIP4 реалізовує Task і кілька його підтипів; C-BML реалізовує повну ієрархію Activity до елементарних типів завдань із тактичної таксономії завдань НАТО.

Структури операційних планів у NCIM

Тип сутності Plan та його зв'язки з екземплярами Activity складають основу подання продуктів операційного планування в NCIM. Розуміння цієї структури необхідне для впровадження будь-якої системи C2 НАТО, яка мусить обмінюватися планами, наказами або статусом їхнього виконання.

На верхньому рівні екземпляр Plan представляє повний продукт операційного планування — OPLAN, OPORD, FRAGO або CONOPS. Plan несе унікальний ідентифікатор, мітку грифування та можливості поширення, орган видачі (Organisation, що його видав), період дійсності та статус (чернетка, затверджений, замінений). Плани пов'язані між собою через ланцюг заміни: FRAGO, що змінює наявний OPLAN, посилається на OPLAN, який він замінює, створюючи історію планів, що дозволяє системам відтворити еволюцію операційного задуму.

Plan структурований на екземпляри Phase — кожна Phase представляє окремий період операцій із визначеними умовами переходу. У NCIM Phase — підтип Activity, пов'язаний із Plan через відносини planContains. Екземпляри Phase упорядковані через умови переходу: екземпляр Phase B має startCondition, що посилається або на час (D+3), або на подію (завершення цілі Phase A). Структури рівня фаз з'являються у форматі повідомлень OPLAN з ADatP-34 і безпосередньо реалізовані в поданні наказів C-BML.

У межах кожної Phase екземпляри Task представляють призначені дії. NCIM Task несе: унікальний ідентифікатор, тип завдання з тактичної таксономії завдань НАТО (SEIZE, ATTACK, DEFEND, SCREEN, COVER, SUPPORT BY FIRE та десятки інших), призначену Organisation або Resource, цільову Location (яка може бути точкою, районом або названим місцем), часові обмеження (найраніший початок, найпізніший початок, обов'язкове завершення), орган видачі та посилання на Plan, що видав. Відносини Task-Organisation — вираз у NCIM формулювання «підрозділу X призначено ціль Y», фундаментального обміну інформацією C2.

Екземпляри Objective у NCIM уточнюють мету Task: Objective несе конкретну операційну ціль, для досягнення якої призначене Task, виражену як умову, яку слід встановити (захоплено місцевість, знищено противника, розчищено маршрут), а не лише як географічне розташування. Розрізнення важливе для машинооброблюваних наказів: система C-BML, що отримує завдання, може використати тип умови Objective, щоб визначити, коли завдання виконане, що дозволяє автоматизувати звітність про прогрес без людської інтерпретації.

Екземпляри Constraint прикріплюють обмежувальні умови до Task і Plan. Constraints у NCIM типізовані: часове обмеження обмежує часове вікно діяльності; географічне обмеження обмежує район, у якому ресурс може діяти; обмеження ресурсів обмежує, які засоби можна використати для завдання. На Constraints посилаються як екземпляри Task (обмежуючи конкретне завдання), так і екземпляри Plan (застосовуючись усією операцією). Модель обмежень NCIM — семантична основа для кодування правил застосування зброї в коаліційних системах C2, які мусять забезпечувати інтероперабельність із національними політиками правил застосування зброї.

<!-- NCIM Plan / Phase / Task hierarchy — simplified XSD sketch -->
<xs:complexType name="PlanType">
  <xs:sequence>
    <xs:element name="planId"      type="ncim:UniqueIdType"/>
    <xs:element name="authority"   type="ncim:OrganisationRefType"/>
    <xs:element name="phase"       type="ncim:PhaseType" minOccurs="1"
                                   maxOccurs="unbounded"/>
    <xs:element name="constraint"  type="ncim:ConstraintType"
                                   minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="PhaseType">
  <xs:sequence>
    <xs:element name="phaseId"         type="ncim:UniqueIdType"/>
    <xs:element name="phaseNumber"     type="xs:integer"/>
    <xs:element name="startCondition"  type="ncim:ConditionType"/>
    <xs:element name="task"            type="ncim:TaskType"
                                       minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="TaskType">
  <xs:sequence>
    <xs:element name="taskId"        type="ncim:UniqueIdType"/>
    <xs:element name="taskType"      type="ncim:TacticalTaskCodeType"/>
    <xs:element name="taskedUnit"    type="ncim:OrganisationRefType"/>
    <xs:element name="objectiveLoc"  type="ncim:LocationRefType"/>
    <xs:element name="timeWindow"    type="ncim:TimeWindowType"/>
    <xs:element name="objective"     type="ncim:ObjectiveType"
                                     minOccurs="0"/>
  </xs:sequence>
</xs:complexType>

Моделювання ресурсів і обладнання

Ієрархія типу сутності Resource у NCIM надає структури для подання платформ, комплектів обладнання та підрозділів як окремих одиниць матеріальних засобів і особового складу. Моделювання Resource критичне для коаліційних систем C2, які мусять обмінюватися даними переліку складу озброєння, зокрема статусом обладнання та деклараціями спроможностей.

Platform — основний підтип Resource для фізичних систем: машин, літальних апаратів, суден і систем озброєння. Екземпляр Platform у NCIM несе посилання на тип платформи (з контрольованого словника, узгодженого з кодами класифікації обладнання НАТО), серійний або реєстраційний ідентифікатор, код операційного статусу (повністю готовий до виконання завдань, частково готовий, не готовий) та посилання на поточну Location. Екземпляри Platform пов'язані з екземплярами Organisation через відносини Equipage, які несуть період призначення та тип призначення (штатний, прикомандирований, операційне керування). Це вираз у NCIM запису переліку складу озброєння: Organisation — це батальйон, екземпляри Platform — машини, а відносини Equipage фіксують, які машини наразі призначені яким підрозділам.

Для випадків, коли окремі платформи не відстежують почергово (поширене для стрілецької зброї, засобів зв'язку та деяких матеріальних засобів забезпечення), NCIM надає EquipmentSet: підтип Resource, що представляє кількість однорідних одиниць, а не окремі відстежувані одиниці. EquipmentSet несе тип одиниці, кількість, одиницю виміру та зведений стан готовності. Екземпляри EquipmentSet з'являються в сценаріях логістичної звітності, де загальні кількості є операційно релевантнішими за відстеження окремих одиниць.

OrganisationUnit з'єднує типи сутностей Resource і Organisation для випадків, коли конкретну команду, екіпаж або відділення потрібно подати і як ресурс (з обладнанням), і як організаційний елемент (зі стосунками командування). Екіпаж гелікоптера, наприклад, — це OrganisationUnit: він має призначену машину (відносини Resource) та ієрархію підпорядкування (відносини Organisation). Підтип OrganisationUnit в NCIM дозволяє цю подвійну ідентичність без створення неузгодженості в моделі даних.

Декларація спроможностей — значущий випадок використання для коаліційного моделювання Resource. NCIM підтримує Capability як категорію атрибутів як для Organisation, так і для Resource, використовуючи контрольований словник, узгоджений із таксономією спроможностей НАТО. Декларація спроможностей підрозділу — вказівка, які типи місій він укомплектований і навчений виконувати, — подається як набір посилань Capability на екземплярі Organisation. Під час коаліційного планування процес призначення Task-Organisation використовує посилання Capability, щоб зіставляти завдання з відповідними за спроможностями підрозділами. В автоматизованих системах C2 це зіставлення може виконувати машина; в системах з операторським керуванням дані про спроможності інформують вибір підрозділу оператором у робочому процесі призначення завдань.

<!-- NCIM Resource / Equipage — illustrative XML fragment -->
<ncim:Resource xsi:type="ncim:PlatformType">
  <ncim:resourceId>{a4c12f88-3e7b-4d1a-b962-9f0d55c12e34}</ncim:resourceId>
  <ncim:platformType>NATO_EQPT_CODE:CV90</ncim:platformType>
  <ncim:serialId>SE-CV90-0147</ncim:serialId>
  <ncim:operationalStatus>FMC</ncim:operationalStatus>
  <ncim:currentLocation ref="{loc-uuid-0a1b2c}"/>
  <ncim:confidentiality>NATO RESTRICTED</ncim:confidentiality>
  <ncim:releasability>NATO</ncim:releasability>
</ncim:Resource>

<ncim:Equipage>
  <ncim:organisation ref="{org-uuid-battalion-42}"/>
  <ncim:resource     ref="{a4c12f88-3e7b-4d1a-b962-9f0d55c12e34}"/>
  <ncim:assignmentType>ORGANIC</ncim:assignmentType>
  <ncim:validPeriod>
    <ncim:startDTG>2026-06-01T06:00:00Z</ncim:startDTG>
  </ncim:validPeriod>
</ncim:Equipage>

XML- та JSON-серіалізація

NCIM — концептуальна та логічна модель: вона визначає семантику, а не байти. Серіалізація у формати передавання — відповідальність стандартів впровадження, які використовують NCIM як батьківську модель. Розуміння того, як семантику NCIM відображають на XML і дедалі більше на JSON, необхідне для розробників, які будують шари обміну між коаліційними системами.

Основний формат серіалізації для обміну на основі NCIM — XML. XML Schema NCIM структурована як набір XSD-модулів, по одному на групу типів сутностей NCIM, організованих під спільною ієрархією просторів імен. Простір імен верхнього рівня — urn:int:nato:ncim:3 (для NCIM версії 3.x), із підпросторами для кожного доменного модуля: urn:int:nato:ncim:3:core для основних типів сутностей, urn:int:nato:ncim:3:land для розширень наземного домену тощо. Стандарти впровадження, які є профілями NCIM, визначають власні простори імен, що імпортують відповідні модулі NCIM та додають обмеження рівня впровадження (обов'язкові поля, обмеження контрольованих словників, посилення кардинальності).

Керування просторами імен в XML NCIM — практичний виклик. Типове коаліційне повідомлення C2, що посилається на сутності з кількох модулів NCIM, нестиме від п'яти до восьми активних оголошень просторів імен у кореневому елементі. Ризик — зіткнення префіксів просторів імен, коли повідомлення з кількох джерел збирають у комбіновану картину: два повідомлення можуть обидва оголошувати префікс ncim, але відображати його на різні простори імен модулів NCIM. Правильний підхід — нормалізувати префікси просторів імен під час прийому повідомлення: розв'язати всі оголошення просторів імен до канонічного URI та використовувати карти просторів імен за ключем URI, а не за ключем префікса, у всьому конвеєрі обробки.

Для тактичних мереж з обмеженою смугою пропускання багатослівність XML — суттєвий недолік. Сутність NCIM, серіалізована як повний XML з усіма оголошеннями просторів імен і відкриваючими/закриваючими тегами, може бути в чотири-шість разів більшою за суттєве навантаження даних. На практиці використовують три підходи:

EXI (Efficient XML Interchange): бінарне XML-кодування W3C, яке зберігає повну семантику XML і зменшує розмір на 80–95% залежно від щільності схеми. EXI — кращий підхід для обмежених тактичних каналів, коли потрібна зворотна сумісність XML. Схеми NCIM сумісні з EXI без змін.
Стиснення з урахуванням схеми: застосування схемно-орієнтованого стиснення DEFLATE або LZ4 до байтового потоку XML. Дає хороші коефіцієнти стиснення (зменшення розміру на 60–75%) з нижчими обчислювальними витратами, ніж EXI, але без справжньої переносимості бінарного формату.
JSON-серіалізація: RESTful-прив'язка MIP4-IES використовує JSON для подання окремих об'єктів, відображаючи атрибути сутностей NCIM на властивості JSON-об'єктів. JSON-навантаження на 30–40% менші за еквівалентний XML і природніше інтегруються з сучасними REST-клієнтськими бібліотеками. Компроміс у тому, що засоби JSON-схем для NCIM менш зрілі, ніж засоби XSD, а зворотна валідація проти нормативної моделі NCIM потребує уважного керування схемами.

// NCIM Organisation — JSON representation (MIP4-IES REST binding)
{
  "@type": "ncim:Organisation",
  "objectId": "b7e4a312-9c0f-4a1e-8d53-1f3a8b0c9e21",
  "creatorId": "SYS-NLD-C2-01",
  "createdDTG": "2026-06-25T08:00:00Z",
  "modifiedDTG": "2026-06-25T09:14:37Z",
  "validity": "ACTIVE",
  "designation": "42 BN 1 INF BDE",
  "organisationType": "NATO_ORG:INFANTRY_BATTALION",
  "parentOrganisation": {"ref": "org-uuid-brigade-1"},
  "commandRelationship": "ORGANIC",
  "operationalStatus": "OPERATIONAL",
  "currentLocation": {"ref": "loc-uuid-7f3c2d"},
  "capability": ["CAP:DIRECT_FIRE", "CAP:DEFENSIVE_OPERATIONS"],
  "confidentiality": "NATO CONFIDENTIAL",
  "releasability": ["NLD", "DEU", "POL", "NATO"]
}

Впровадження NCIM у коаліційній системі C2

Більшість коаліційних систем C2 доходять до впровадження NCIM одним із двох шляхів: нова система, від початку спроєктована довкола семантики NCIM, або національна застаріла система, яку адаптують для коаліційної інтероперабельності. Другий випадок значно поширеніший і складніший.

Проєктування адаптера для національних моделей даних — практичний підхід до інтеграції застарілих систем. Замість рефакторингу внутрішньої моделі даних національної системи C2 під NCIM — багаторічних зусиль зі суттєвим операційним ризиком, — патерн адаптера зосереджує всі рішення щодо відображення NCIM в окремому компоненті адаптера. Адаптер перекладає між національною моделлю та відповідними до NCIM представленнями для всіх зовнішніх обмінів даними: вхідні коаліційні дані перекладаються в національну модель для внутрішнього використання; вихідні національні дані перекладаються в NCIM для коаліційного обміну. Адаптер є межею інтероперабельності та єдиним компонентом, який треба змінювати, коли базову лінію NCIM оновлюють.

Найважливіше рішення в дизайні адаптера — визначити, які типи сутностей NCIM потребують повного перекладу, а які — поверхневого. Повний переклад — коли кожен атрибут NCIM має відповідне внутрішнє представлення, — потрібен для типів сутностей, що з'являються в двобічному обміні даними. Поверхневий переклад — коли відображають лише ключові ідентифікатори та коди статусів, — прийнятний для типів сутностей, які система споживає, але ніколи не змінює і не створює. Пріоритет повного перекладу — Organisation, Resource (Platform), Activity (Task) і Location; поверхневого перекладу зазвичай достатньо для Constraint і Objective на рівні адаптера.

Відображення NCIM на CoT потрібне для систем, що обмінюються даними з платформами, які використовують Cursor on Target (CoT) — XML-схему, якою користуються ATAK, WinTAK і пов'язані засоби обізнаності про обстановку. CoT не походить від NCIM, але відображення між ними добре визначене на практиці. Елемент CoT <event> відображається на NCIM Resource (для платформ і особового складу) або OperationalObject (для треків і контактів), причому атрибут type відображається на тип сутності NCIM і посилання на тип платформи. Елемент CoT <point> відображається на NCIM Location (підтип Point) із перетворенням координат за потреби (CoT використовує WGS-84 у десяткових градусах, що узгоджено з базовою CRS NCIM). Основна структурна різниця в тому, що CoT вбудовує позиційні дані в елемент event, тоді як NCIM виносить їх як сутність Location: адаптер мусить створювати екземпляр Location із кожної точки CoT під час вхідного перекладу та вбудовувати координати посиланої Location у точку CoT під час вихідного перекладу.

Міст NCIM-MIP — найпоширеніша коаліційна вимога адаптації для наземних систем C2. Модель даних MIP4 є профілем NCIM для наземного домену, тому відображення — не переклад між непов'язаними моделями, а проекція з ширшої моделі (NCIM) на обмежений профіль (MIP4). Основні відмінності, що потребують логіки відображення: MIP4 використовує OID (глобально унікальний ідентифікатор на основі UUID) як основний ідентифікатор, тоді як NCIM використовує загальний UniqueId, який може мати інше кодування в інших стандартах впровадження; модель інактивації BaseObject у MIP4 (прапорець дійсності) відображається на атрибут дійсності сутності NCIM; а модель Location у MIP4 використовує дещо інше представлення невизначеності, ніж тип GeometricExtent у NCIM. Ці відмінності можна подолати без втрати даних, але вони потребують уважної реалізації крайових випадків.

Тестування семантичної еквівалентності: до будь-якої участі в CWIX системи мають проводити тестування семантичної еквівалентності — обмінюватися стандартизованим набором екземплярів сутностей NCIM із партнерською системою та перевіряти, що внутрішнє представлення отриманих даних у партнера відповідає наміру відправника. Синтаксична відповідність (валідний XML, правильна схема) не гарантує семантичної еквівалентності (того самого сенсу). Операційні помилки, спричинені семантичною невідповідністю, — статус підрозділу, прочитаний як OPERATIONAL, тоді як відправник мав на увазі DEPLOYED AWAITING ORDERS, — важче виявити і вони серйозніші за синтаксичні помилки.

Еволюція та управління NCIM

NCIM підтримує NATO C3 Board (C3B) — орган управління Альянсу зі стандартів засобів зв'язку та інформаційних систем. C3B діє через структуру робочих груп: C2 Information Exchange Working Group (C2IEWG) — орган, відповідальний за підтримку NCIM, за участі міністерств оборони країн НАТО, національних агентств оборонних ІТ та представників промисловості через процес форуму промисловості НАТО.

Життєвий цикл стандартів NCIM відповідає стандартному процесу Альянсу: пропозицію зміни подають до C2IEWG з обґрунтуванням та оцінкою впливу; робоча група розглядає пропозицію на предмет узгодженості із залежними стандартами (оскільки зміна NCIM поширюється на MIP4, ADatP-34 і C-BML, оцінка впливу мусить охоплювати всі три); після схвалення робочою групою пропозиція входить у період коментарів країн-членів; а після опрацювання коментарів зміну включають до наступної ревізії NCIM і публікують через NCIA. Великі інкременти версій (NCIM 2.x до 3.x) мають багаторічні строки через каскадний вплив на стандарти впровадження; незначні ревізії в межах великої версії публікують щороку.

Механізм профілів — основний засіб для специфічних для місії розширень без зміни базової моделі. Профіль — формально визначене обмежене або розширене подання NCIM для конкретного домену або типу місії. Профілі публікує C3B як додатки до NCIM після проходження того самого процесу розгляду та схвалення, що й зміни базової моделі. Перевага механізму профілів у тому, що можна врахувати вимоги, специфічні для місії, — додати атрибути типу судна для морського профілю C2 або атрибути контактів радіоелектронної боротьби для профілю картини РЕБ, — не роздуваючи базову модель і не створюючи несумісностей між системами, що реалізовують різні профілі. Системи, що реалізовують кілька профілів, мусять керувати об'єднанням своїх наборів типів сутностей і коректно обробляти випадок, коли партнерська система реалізовує лише підмножину використовуваних профілів.

NATO Interoperability Test Toolkit (NITT) — основний засіб перевірки відповідності впроваджень на основі NCIM. NITT містить тести, організовані за типами сутностей NCIM та сценаріями обміну (двосторонній обмін наземною картиною, розповсюдження OPORD, звітність про логістичний статус). Кожен тест визначає точні екземпляри сутностей NCIM, які слід обміняти, формат серіалізації та твердження, які мусять виконуватися на приймаючому боці. Результати NITT — основний вхід для оцінок готовності до CWIX: системи, що провалили NITT для сценарію, не допускаються до цього сценарію на CWIX.

Для команд програм, які відстежують еволюцію NCIM, практична порада така: підпишіться на публікації C2IEWG через свій національний орган зі стандартизації оборони; розглядайте запропоновані зміни на предмет впливу на ваш шар адаптера ще на етапі пропозиції (відповідати на зміни значно дешевше, перш ніж їх схвалили); і розглядайте узгодженість версій NCIM як договірний пункт в угодах про коаліційні навчання: зазначення базової лінії NCIM, яку мусять реалізовувати всі учасники, запобігає семантичному дрейфу, що виникає, коли партнери на різних мінорних версіях.

Ширша траєкторія управління NCIM відображає зрушення Альянсу до сервісно-орієнтованих та даних-центричних архітектур. Остання еволюція NCIM зосереджена на узгодженні з сервісними рамками FMN (Federated Mission Networking), явній підтримці JSON-серіалізації на додачу до XML та впровадженні патернів пов'язаних даних (RDF/OWL представлення типів сутностей NCIM), які підтримують інтеграцію семантичної павутини для обміну даними між союзниками через межі грифування. Ці напрямки свідчать, що NCIM і надалі зростатиме в охопленні та значущості, оскільки інформаційна інфраструктура C2 НАТО модернізується, — роблячи її дедалі важливішим орієнтиром для всіх програм оборонного програмного забезпечення, що націлені на коаліційну інтероперабельність.

Обговоріть ваш проєкт

Ми проєктуємо та впроваджуємо відповідні до NCIM шари даних і адаптери інтеграції коаліційного C2 для оборонних програм, націлених на інтероперабельність НАТО.

Розробка C2 → Замовити брифінг

Цей аналіз підготували інженери Corvus Intelligence, які створюють критичне для місії програмне забезпечення для оборонних і державних організацій. Дізнатися про нашу команду →

Часті запитання

Що таке інформаційна модель C2 НАТО (NATO C2 Information Model, NCIM)?

NCIM — канонічна концептуальна та логічна модель даних Альянсу для обміну інформацією командування та керування. Вона визначає типи сутностей, зв'язки та семантику атрибутів, що лежать в основі всіх стандартів даних C2 НАТО, — зокрема MIP4, ADatP-34 і C-BML, — створюючи спільну інформаційну основу, щоб дані, обмін якими відбувається за різними стандартами НАТО, можна було однозначно інтерпретувати в коаліційних партнерів. NCIM не визначає формати передавання; вона перебуває над специфікаціями рівня протоколів як спільний семантичний орієнтир, на який відображаються стандарти впровадження.

Як NCIM пов'язана з MIP4 і ADatP-34?

NCIM — батьківська модель, від якої походять і MIP4, і ADatP-34. Модель даних MIP4, що охоплює типи сутностей Unit, Equipment, Task і пов'язані з ними для C2 сухопутних військ, — це профіль NCIM, обмежений наземним доменом. Каталог повідомлень ADatP-34 структурує свої поля відповідно до семантики NCIM. Розробник, який розуміє ієрархію типів сутностей NCIM, здатний орієнтуватися і в MIP4, і в ADatP-34 значно швидше, ніж розглядаючи їх як незалежні стандарти. Відображення між об'єктами MIP4 та полями повідомлень ADatP-34 суттєво зводиться до обходу зв'язків NCIM.

Які типи сутностей верхнього рівня є в NCIM?

NCIM визначає шість типів сутностей верхнього рівня: Activity (заплановані або фактичні дії, зокрема завдання, місії та події), OperationalObject (цілі, райони інтересу та повідомлені контакти), Organisation (ієрархії командування та організаційні підрозділи), Resource (платформи, комплекти обладнання та особовий склад), Location (географічні позиції, райони, коридори та межі) і Plan (операційні плани, фази та зв'язки між ними). Кожна сутність в обміні даними C2 НАТО простежується до рівно одного з цих шести типів.

Які формати серіалізації підтримує NCIM?

NCIM сама по собі байдужа до формату — це концептуальна модель, а не специфікація серіалізації. Стандарти впровадження визначають власні серіалізації: MIP4-IES використовує XML із RESTful JSON-прив'язкою, ADatP-34 — бінарний VMF для застарілих радіоканалів і NATO XML Message Specification для IP-мереж, а C-BML — спеціалізований формат XML. Будуючи коаліційну систему C2, впроваджувач обирає серіалізацію, відповідну для цільової мережі та систем партнерів, але всі серіалізації відображаються на ті самі базові сутності NCIM.

Як профілі NCIM використовують для специфічних для місії розширень?

NCIM підтримує механізм профілів, що дозволяє розширення, специфічні для місії або домену, без зміни базової моделі. Профіль визначає обмежене або розширене подання NCIM для конкретного випадку використання: наприклад, морський профіль C2 додає до типу сутності Resource атрибути, специфічні для суден, і лишає поза областю застосування атрибути наземного домену. Профілі формально реєструють у NATO C3 Board і вони проходять визначений життєвий цикл. Команди впровадження мусять визначити, які затверджені профілі NCIM стосуються їхньої програми, і реалізовувати лише ті атрибути та типи сутностей, що входять до її області застосування.

У чому різниця між концептуальним і логічним шарами NCIM?

NCIM структурована у два шари. Концептуальний шар визначає типи сутностей високого рівня та зв'язки між ними за допомогою UML-діаграм класів; він відповідає на запитання «які речі існують в операції C2 НАТО?». Логічний шар уточнює кожен тип сутності до атрибутів із визначеними типами даних, обмеженнями кардинальності та посиланнями на області значень; він відповідає на запитання «які дані слід записати про кожну сутність?». Розробники програмного забезпечення працюють переважно з логічним шаром під час реалізації моделей даних; системні архітектори використовують концептуальний шар, щоб перевірити семантичну еквівалентність моделей даних двох систем перед тестуванням обміну даними.

Як NCIM обробляє розташування та геометрію?

Location — повноцінний тип сутності в NCIM, а не атрибут інших сутностей. Unit не має атрибута координати — він має зв'язок із сутністю Location, яка несе координату, оцінку невизначеності, часове вікно дійсності та джерело позиції. Тією самою сутністю Location можуть посилатися кілька сутностей Activity, Organisation і Resource. Типи геометрії включають Point, Polyline, Polygon, Corridor та абстрактний GeometricExtent. Системи координат відповідають ISO 19111, а WGS-84 є базовою CRS для коаліційного обміну.

Що таке C-BML і як він пов'язаний із NCIM?

C-BML (Coalition Battle Management Language) — мова на основі XML для подання військових завдань, наказів і звітів у машинооброблюваній формі, спроєктована, щоб системи C2 могли автоматично розбирати наказ і витягувати з нього завдання. Структури завдань і наказів C-BML засновані на типах сутностей Activity і Plan з NCIM, причому XML-елементи C-BML відображаються безпосередньо на атрибути NCIM. Система, що реалізовує C-BML для обміну наказами та MIP4-IES для обміну наземною картиною, використовує в обох випадках одну й ту саму базову семантику NCIM, що значно полегшує міжпротокольну інтеграцію даних.

Як організовано перевірку відповідності NCIM та тестування?

Відповідність NCIM перевіряють через стандарти впровадження, які її використовують. NATO Coalition Warrior Interoperability Exercise (CWIX) — основний майданчик, де впровадження на основі NCIM тестують одне проти одного. NATO Interoperability Test Toolkit (NITT) надає автоматизовані тести для обмінів MIP4-IES і C-BML, які перевіряють семантичну відповідність визначенням NCIM, а не лише синтаксичну валідність XML. Програми мусять взяти участь щонайменше в одному циклі CWIX, щоб продемонструвати операційну відповідність; попереднє національне тестування відповідності настійно рекомендоване.

Який орган управління підтримує NCIM і як часто її оновлюють?

NCIM підтримує NATO C3 Board (C3B) через C2 Information Exchange Working Group (C2IEWG) за участі міністерств оборони країн НАТО, національних агентств оборонних ІТ та представників промисловості. Великі інкременти версій мають багаторічні строки через каскадний вплив на MIP4, ADatP-34 і C-BML; незначні ревізії публікують щороку. Команди впровадження мають підписатися на публікації C2IEWG через свій національний орган зі стандартизації оборони та розглядати узгодженість версій NCIM як договірний пункт в угодах про коаліційні навчання.

Як NCIM обробляє грифування та можливість поширення даних?

NCIM містить атрибут Confidentiality для кожного типу сутності з міткою грифування, узгодженою з рівнями грифування НАТО (UNCLASSIFIED, NATO RESTRICTED, NATO CONFIDENTIAL, NATO SECRET, COSMIC TOP SECRET), та індикатор Releasability, що визначає, які країни або групи можуть отримати сутність. Ці атрибути — вираз на рівні NCIM міток, які вимагають STANAG 4774 (Confidentiality Metadata Label) і STANAG 4778 (Metadata Binding). Під час серіалізації сутностей NCIM у XML для обміну в коаліційній мережі стандарт серіалізації зобов'язаний нести ці мітки в такому місці й форматі, щоб приймаюча система могла застосувати фільтри можливості поширення до пересилання партнерським системам. Система, що знищує або ігнорує атрибути конфіденційності NCIM, є невідповідною і створює ризик несанкціонованого розкриття інформації.

Чи можна використовувати NCIM поза НАТО — наприклад, в екосистемі C2 України?

Так, і це дедалі поширеніше. Країни, які не є членами НАТО, але діють у коаліції з силами Альянсу, використовують стандарти, похідні від NCIM, для досягнення інтероперабельності обміну даними. Оборонні технологічні програми України, зокрема системи, що беруть участь у кластері оборонних технологій Brave1, використовують інтерфейси MIP4-IES та ADatP-34, — обидва реалізовують семантику NCIM, — для обміну операційними даними із системами партнерів НАТО. Практичний наслідок для розробників поза НАТО такий самий, як для членів Альянсу: узгодьте внутрішню модель даних із типами сутностей і зв'язками NCIM, реалізуйте відповідний профіль для цільового стандарту обміну та валідуйте на CWIX або на заході з інтероперабельності країни-партнера.

Які інструменти доступні для роботи зі схемами та моделями NCIM?

Основний набір засобів для роботи з NCIM — NATO Interoperability Test Toolkit (NITT), який містить валідатори схем, генератори повідомлень та автоматизовані тести для MIP4-IES і C-BML. Для роботи з моделлю даних UML-модель NCIM публікують у форматі XMI; її можна завантажити в моделювальні засоби на основі Eclipse або Sparx Enterprise Architect для навігації та аналізу прогалин. Визначення XML Schema для форматів обміну на основі NCIM поширюють через репозиторій стандартів NCIA. Комерційні засоби від Systematic (SitaWare), General Dynamics Mission Systems і Thales інтегрують відповідні до NCIM шари даних і можуть служити еталонними реалізаціями для розробки адаптерів; хоча їхні API пропрієтарні, спостережувані структури даних, якими вони обмінюються, мусять відповідати семантиці NCIM і можуть використовуватися як еталон відповідності.