Сертифікація сумісності NATO: CWIX, JITC та отримання сертифікату для оборонного програмного забезпечення

Для постачальника оборонного програмного забезпечення побудова системи, що реалізує правильні протоколи, є необхідною, але недостатньою умовою. Офіси із закупівель NATO та союзників дедалі частіше вимагають задокументованих доказів того, що система тестувалася на однорангових реалізаціях в умовах, що наближаються до бойових. Такі докази надходять із двох основних джерел: CWIX (Coalition Warrior Interoperability eXploration, eXperimentation, eXamination, eXercise) і JITC (Joint Interoperability Test Command). Розуміння того, як ці процеси працюють, що вони насправді тестують і як їхні результати враховуються при відборі джерел, дає постачальникам суттєву перевагу у закупівлях оборонного програмного забезпечення від RFI до контракту. У цій статті детально розглянуто обидва шляхи — від початкової роботи з відповідністю до виконання тестів, аналізу відмов і зобов'язань щодо підтримки версій, що виникають після сертифікації.

Чому сертифікація сумісності важлива для рішень щодо закупівель NATO

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

Практичний вплив на рішення щодо закупівель є значним. Для програм, що регулюються Системою інтеграції та розвитку об'єднаних можливостей (JCIDS) у США або еквівалентними рамками закупівель NATO, сумісність із об'єднаними та союзними системами є Ключовим параметром ефективності (KPP), а не факультативною вимогою. KPP є пороговою вимогою типу «прийнятно/неприйнятно» при відборі джерел: система, яка не може продемонструвати відповідність відповідному KPP, виключається з кола конкурентів незалежно від того, як вона оцінюється за іншими чинниками. Сертифікація JITC або еквівалентні задокументовані докази тестування зазвичай є прийнятним способом демонстрації відповідності KPP. Для постачальників, які ще не інвестували у формальне тестування сумісності, наслідком є не нижча оцінка — це виключення з конкурсу.

Окрім порогових вимог, історія тестування сумісності впливає на те, як оцінювачі сприймають технічну зрілість. Система, що брала участь у кількох заходах CWIX, включно з тими, де були виявлені та згодом усунені недоліки, має більш детальну тестову історію, ніж система з єдиною чистою лабораторною демонстрацією. Оцінювачі з досвідом в оборонних закупівлях розуміють, що будь-яка складна реалізація протоколу матиме недоліки на першому тестовому заході; вони шукають докази того, що постачальник має дисциплінований процес виявлення та усунення цих недоліків. Задокументований недолік CWIX, який був проаналізований до першопричини, виправлений і повторно перевірений на наступному заході, є позитивним сигналом, а не негативним.

CWIX: що тестує захід Coalition Warrior Interoperability eXploration і хто бере в ньому участь

CWIX — щорічний захід, що проводиться в Об'єднаному центрі навчання сил (JFTC) у Бидгощі, Польща, зазвичай у червні. Його організовує Командування трансформації Альянсу (ACT), а JFTC є організатором і постачальником тестової інфраструктури. Захід збирає разом реалізації систем C2 з усіх країн NATO та країн-партнерів, організованих у Технічні спільноти (TC), кожна з яких зосереджена на певному наборі стандартів — TC C2 тестує системи на відповідність NFFI (NATO Friendly Force Information) і JC3IEDM (Joint Consultation, Command, and Control Information Exchange Data Model), TC зв'язку тестує реалізації Link 16 та інші тактичні лінії передачі даних тощо. Обсяг кожного конкретного року CWIX публікується в щорічному документі про обсяг CWIX, де зазначаються версії профілів STANAG, тестові сценарії та мінімальні конфігурації систем, необхідні для участі.

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

Результатом участі у CWIX є набір звітів про тестування, зафіксованих в Інструменті оцінювання CWIX, який формує щорічний Підсумковий звіт, що розповсюджується серед усіх держав-учасниць. Кожна пара система-до-системи, що тестується, генерує результат відповідності для кожного застосовного тестового випадку: прийнятно, неприйнятно або не тестувалось. Ці результати не публікуються, але циркулюють серед офісів закупівель союзників. Система, що накопичила кілька років участі у CWIX із покращенням показників успішності між версіями протоколів, перебуває в матеріально сильнішій позиції у закупівлях союзників, ніж система, яку взагалі не можна знайти в реєстрі CWIX.

Тестування JITC: процес та строки виконання Командування тестування спільної сумісності США

JITC є призначеним органом тестування Міністерства оборони США для спільної сумісності. Він діє під Агентством оборонних інформаційних систем (DISA) і проводить як розробницьке, так і операційне тестування сумісності для систем C2, зв'язку та розвідки. На відміну від CWIX, який є повторюваним заходом із фіксованим щорічним розкладом, тестування JITC є специфічною для програми діяльністю, ініційованою офісом програми-спонсора. Офіційною точкою входу є запит на тестування, поданий до JITC, зазвичай разом із проєктом Головного плану тестування та оцінювання (TEMP) і документом із описом програми. JITC розглядає запит, визначає обсяг програми тестування та призначає провідного інженера з тестування, який разом із постачальником і офісом програми розробляє детальний план тестування.

Процес тестування JITC для системи C2 або зв'язку проходить кілька фаз, які разом зазвичай займають від 12 до 18 місяців для першої сертифікації. Розробницьке тестування (DT) починається після затвердження плану тестування і зосереджується на відповідності інтерфейсу застосовним стандартам — ця фаза аналогічна запуску набору тестів відповідності, але з залученням інженерів JITC, а не лише внутрішньої команди постачальника. Слідом іде операційне тестування (OT), яке перевіряє систему в місійно-репрезентативних сценаріях відносно однорангових систем, що реально використовуються об'єднаними силами: вузлів C2 поточного покоління, об'єднаних мереж даних і тактичної комунікаційної інфраструктури. Кінцевим результатом є Звіт про сертифікацію сумісності JITC, який або видає Сертифікат мережевої придатності (CoN), або документує недоліки, які необхідно усунути до видачі сертифікату.

Часові тиски при тестуванні JITC є реальними і постачальники, що вперше стикаються з цим процесом, часто їх недооцінюють. Типовою пасткою розкладу є початок розробки TEMP після досягнення системою початкової операційної готовності, а не паралельно з детальним проєктуванням. До того часу, коли розробка TEMP починається після IOC, розклад не залишає достатнього часу для двох-трьох ітерацій тестування, які зазвичай вимагають складні реалізації протоколів до усунення всіх недоліків. Постачальники, що починають розробку TEMP на етапі попереднього проєктного огляду (PDR) і розпочинають запуск відповідних наборів тестів відповідності під час розробки, а не під час інтеграції, стабільно досягають сертифікації JITC за розкладом. Ті, хто розглядає тестування як построзробникову діяльність, стабільно цього не роблять.

Підготовка до сертифікації: набори тестів відповідності, плани тестування та лабораторна робота перед тестуванням

Основою успішного циклу підготовки до CWIX або JITC є набір тестів відповідності для кожного протоколу, що реалізує система. Більшість стандартів NATO зі значною інсталяційною базою мають пов'язаний програмний інструмент тестування. Реалізації NFFI перевіряються за допомогою Інструменту тестування відповідності NFFI (NCTT), який тестує систему як відправника, так і отримувача даних треків NFFI, вводячи крайові варіанти повідомлень і перевіряючи, що відповіді системи відповідають специфікації профілю. Реалізації Link 16 тестуються за допомогою аналізаторів протоколів, які декодують J-серійні повідомлення до бітового рівня і порівнюють закодований вивід зі стандартом. Реалізації сумісності БпЛА STANAG 4586 мають власний набір тестів відповідності для інтерфейсів каналу управління та відеоканалу. Першим кроком у будь-якій програмі підготовки до сертифікації є отримання поточної версії всіх застосовних наборів тестів відповідності та їх повний запуск відносно системи, що тестується, до будь-якого зовнішнього тестового заходу.

Лабораторна робота перед тестуванням — це місце, де відбувається найважливіше скорочення кількості недоліків. Типовий перший запуск набору тестів відповідності відносно реалізації, яка раніше не тестувалася зовні, виявляє від 15 до 40 окремих невідповідностей. Вони варіюються від незначних проблем — поле, закодоване як беззнакове, коли стандарт визначає знакове, або мітка часу з мікросекундною точністю, де визначена мілісекундна, — до серйозніших проблем, таких як послідовності повідомлень, що завершують з'єднання замість переходу в стан відновлення після помилки. Ключовою дисципліною при лабораторній роботі перед тестуванням є аналіз кожної невідповідності до першопричини на рівні протоколу, а не виправлення симптому. Невідповідність, усунута шляхом додавання спеціального випадку в обробнику тестів відповідності без виправлення базової реалізації протоколу, знову з'явиться як інша відмова тесту на фазі однорангового тестування, де реальні однорангові системи надсилатимуть варіанти повідомлень, яких набір тестів відповідності не перевіряв.

Побудова реалістичної тестової мережі є другим критичним елементом підготовки перед тестуванням. Більшість відмов, пов'язаних із часовими обмеженнями, що виникають під час тестування CWIX і JITC, не з'являються в лабораторному середовищі на основі LAN, оскільки LAN вносить менше 1 мс затримки відповіді з майже нульовим джиттером. Реальні тактичні мережі вносять від 50 до 300 мс затримки з пачковим джиттером. Частоти оновлення треків і тайм-аути квитування, що виглядають правильними в лабораторії LAN, можуть спричинити порушення кінцевого автомата протоколу, коли затримка мережі наближається до порогів таймера. Запуск усього попереднього тестування сумісності через мережевий емулятор, налаштований відповідно до очікуваного операційного профілю затримки, є найнадійнішим способом виявлення цих відмов до їх появи на формальному тестовому заході.

Поширені причини відмов: невідповідності схем, проблеми з часом і крайові випадки протоколу

Невідповідності схем є найпоширенішою категорією відмов відповідності при тестуванні сумісності NATO, і вони майже завжди є проблемою версії профілю, а не фундаментальною помилкою реалізації. Середовище стандартів NATO підтримує кілька одночасних версій профілів: NFFI опублікував кілька видань із несумісними змінами до наборів необов'язкових полів і значень перерахувань. Система, яка реалізує NFFI видання 1 і тестується відносно однорангової системи, що працює на виданні 2, генеруватиме порушення схеми для будь-якого поля, доданого або зміненого між виданнями, навіть якщо обидві системи правильно реалізують свої відповідні версії профілів. Вирішення вимагає, щоб обидві сторони домовилися про спільну версію профілю до початку тестування — і ця домовленість повинна відбуватися при координації перед тестуванням, а не в перший день заходу CWIX.

Порушення часових обмежень є другою основною категорією відмов, і їх діагностика непропорційно дорога, оскільки вони є недетермінованими. Система, частота оновлення треків якої незначно перевищує встановлений максимум, відмовлятиме непостійно, а не стабільно, даючи результати тестів, що, здається, проходять при одних запусках і відмовляють при інших. Ця непослідовність спонукає постачальників відкидати відмови часових обмежень як середовищні, а не досліджувати їх на рівні реалізації. Правильним підходом до діагностики є запис усього тестового трафіку з точним джерелом часових міток та його автономне відтворення за допомогою аналізатора протоколів, що вимірює міжповідомленні інтервали з мікросекундною точністю. Відмови часових обмежень, що виглядають непостійними при живому тестуванні, майже завжди є стабільними при аналізі на рівні пакетів, виявляючи систематичне зміщення між заданими та реалізованими значеннями таймера.

Підтримка сертифікації у різних версіях програмного забезпечення та оновленнях протоколів

Сертифікація JITC або позитивний тестовий запис CWIX прив'язані до конкретної версії. Сертифікація документує систему на конкретній збірці програмного забезпечення та версії реалізації протоколу. Коли програмне забезпечення оновлюється — для виправлення безпеки, випуску функціоналу або виправлення недоліку, виявленого в попередньому тестовому циклі, — постачальник повинен оцінити, чи змінює оновлення будь-яку поведінку на рівні протоколу. Зміни в схемах повідомлень, правилах кодування, значеннях таймера, логіці управління з'єднанням або шляхах обробки помилок є суттєвими змінами, що вимагають повторного тестування. Зміни користувацького інтерфейсу, оптимізації продуктивності, що не змінюють вміст повідомлень, або доповнення до нетестованих інтерфейсів зазвичай не є суттєвими. Підтримка чіткої карти між модулями програмного забезпечення та поведінкою протоколу, яку вони реалізують, є операційною дисципліною, що робить цю оцінку здійсненною при кожному випуску.

Стандарти NATO самі по собі розвиваються за циклом, який не синхронізований із жодним дорожнім планом розробника. Стандарт, на відповідність якому система була сертифікована одного року, може опублікувати нове видання наступного року, кероване операційним зворотним зв'язком від коаліційних навчань. Документ про обсяг CWIX, що публікується щороку в січні, визначає, яке видання кожного стандарту тестуватиметься на цьогорічному заході. Постачальники, що відстежують план стандартів NATO через NISP (Стандарти та профілі сумісності NATO) і відповідні технічні робочі групи кастодіана STANAG, можуть передбачити зміни видань за 12–18 місяців до того, як вони стають обов'язковою версією для тестування, надаючи командам розробників достатній час для реалізації та тестування нового видання до сертифікаційного заходу. Постачальники, що виявляють вимогу до нового видання в документі про обсяг CWIX за три місяці до заходу, опиняються у скрутному становищі, незалежно від того, наскільки сильний їхній наявний тестовий запис.

Взаємозв'язок між підтримкою сертифікації та плануванням дорожньої карти продукту є однією з структурних викликів, специфічних для розробки оборонного програмного забезпечення. На відміну від комерційних SaaS-продуктів, де зворотна сумісність із зовнішніми системами керується через версіонування API, оборонна система, що змінює свою реалізацію протоколу, повинна повторно перевірятися відносно фіксованого зовнішнього стандарту, орган тестування якого працює за річним циклом. Включення цього ритму до дорожньої карти продукту — планування заморозки стабілізації перед CWIX, планування запусків набору тестів відповідності як частини процесу випуску та виділення інженерних потужностей для усунення недоліків між заходом і наступним випуском — є організаційною практикою, що відокремлює постачальників із стабільними записами сертифікації від тих, хто стикається з труднощами при підтримці сертифікації при переходах між версіями.

Як результати сертифікації відображаються у RFP і що шукають оцінювачі

У добре структурованому RFP NATO або Міністерства оборони США для системи C2 або зв'язку вимоги щодо сумісності з'являються щонайменше у трьох місцях: у розділі системних вимог (де визначаються стандарти та версії профілів, яким повинна відповідати система), у критеріях оцінювання технічного підходу (де задокументована відповідність є зваженим чинником) і у Переліку вимог до контрактних даних (де визначаються звіти про тестування та сертифікати, які повинен надати підрядник). Розуміння взаємодії цих трьох пунктів є важливим для формування відповіді на пропозицію. Постачальник, який розглядає список стандартів у розділі вимог, але не пов'язує його з доказами тестування в розділі технічного підходу, залишає незабрані оціночні бали, навіть якщо базова система повністю сертифікована.

Оцінювачі з досвідом оцінювання сумісності шукають конкретики. Пропозиція, яка стверджує «наша система сумісна зі стандартами C2 NATO», не посилаючись на конкретні номери STANAG, версії профілів і тестові заходи, отримає нижчий бал, ніж пропозиція, яка цитує конкретну технічну спільноту CWIX і рік, версію набору тестів відповідності та конкретні однорангові системи, що тестувалися. Аналіз прогалин у можливостях та процес вимог, що передує RFP, майже завжди визначає конкретні однорангові системи, із якими нова система повинна взаємодіяти; пропозиція, яка явно називає ці однорангові системи у своїй тестовій історії, демонструє, що вона прочитала і зрозуміла оперативний контекст, а не лише технічну специфікацію. Такий рівень конкретики сильно корелює з балами відбору джерел у програмах, де технічні фактори домінують.

RFP дедалі частіше включають вимоги щодо підтримки сумісності: не лише те, що система сертифікована при постачанні, але й те, що постачальник підтримує сертифікацію протягом контрактного терміну виконання. Ця вимога створює договірне зобов'язання брати участь у щорічних заходах CWIX (або еквівалентних) і підтримувати поточний статус сертифікації JITC. Постачальники, які розглядають сертифікацію як разову передпропозиційну інвестицію і не побудували організаційних процесів для поточної підтримки сертифікації, опиняться в порушенні цих вимог щодо підтримки в міру просування видань протоколів протягом програми. Виявлення цього зобов'язання на ранньому етапі та його включення у тендерну ціну програми — включаючи вартість щорічної участі у CWIX, ліцензування набору тестів відповідності та інженерію усунення недоліків — є важливим для відповідальної підготовки пропозиції.