ADatP-34 (NISP): Standardy i profile interoperacyjności NATO — objaśnienie

ADatP-34 to numer dokumentu Standardów i profili interoperacyjności NATO (NISP) — głównego katalogu Sojuszu z technicznymi standardami i profilami interoperacyjności, których muszą używać systemy łączności i systemy informacyjne, aby ze sobą współpracować. Nie jest to katalog wiadomości ani standard łącza danych: to trzytomowa publikacja referencyjna, która mówi programowi, które standardy wdrażać, w którym wydaniu i jak mocno każdy z nich wiąże. Jeśli szukaliście formatów wiadomości NATO — one żyją w ADatP-3 (STANAG 5500) i APP-11, a ADatP-34 mówi, przeciwko któremu wydaniu je budować.

Czym jest ADatP-34: Standardy i profile interoperacyjności NATO

Formalnie ADatP-34 to Allied Data Publication, którego treścią jest NISP. Dokument przepisuje techniczne standardy i profile konieczne do osiągnięcia interoperacyjności systemów łączności i systemów informacyjnych (CIS) na potrzeby misji i operacji NATO oraz daje wytyczne trzem rolom, które żyją z niego na co dzień: planistom zdolności, kierownikom programów i menedżerom testów. Aktualne publicznie wydane wydanie to ADatP-34 Edition N Version 2 (NISP version 15, 18 sierpnia 2023 r.), notowane przez Radę C3 NATO i wydane jako zamiennik Edition N Version 1 (NISP v14, 2021).

NISP wywodzi się z Technicznej Architektury NC3 NATO (NC3TA), której ostatnią wersję ukończono w latach 2005–2006; pierwszy NISP ukazał się w grudniu 2006 roku i od tamtej pory dokument jest rewidowany w cyklu mniej więcej rocznym. Tam gdzie NC3TA była dokumentem architektonicznym, NISP jest katalogiem z prawnymi zębami: zgodnie ze Strategią C3 Sojuszu wszystkie podmioty NATO Enterprise stosują obowiązkowe standardy i profile z jego tomu 2, a te standardy wiążą systemy finansowane wspólnie przez NATO (szerszy krajobraz STANAG/APP opisuje materiał standardy interoperacyjności NATO dla oprogramowania).

NISP jest publikowany jako trzy tomy w HTML i PDF, wsparte wyszukiwalną bazą standardów oraz eksportem danych w formacie ArchiMate dla narzędzi architektonicznych. Baza stojąca za wydaniem 2023 roku zawiera około 1 280 standardów od blisko 70 organizacji — specyfikacje IETF RFC, W3C, OASIS, OGC i ISO obok STANAG-ów NATO i publikacji sojuszniczych — plus około 400 profili usług. Większość z tego nie powstała w NATO: NISP przejmuje dojrzałe standardy spoza NATO i wiąże je w profile NATO.

Kto utrzymuje ADatP-34: Rada C3, IP CaT i STANAG 5524

NISP jest rozwijany przez Interoperability Profiles Capability Team (IP CaT) pod zwierzchnictwem Rady NATO ds. konsultacji, dowodzenia i kontroli (C3B) — najwyższego wielonarodowego komitetu polityki C3 i interoperacyjności NATO. W grudniu 2023 roku Rada Północnoatlantycka zatwierdziła zmianę nazwy Rady C3 na Komitet Polityki Cyfrowej (DPC), a zespół profili interoperacyjności kontynuuje pracę pod tym komitetem; w bieżących wykazach NATO występuje jako zespół DPC ds. standardów i profili interoperacyjności (baza NISP notuje go jako "DPC IP iCaT"). Wczesne wydania NISP produkowała Grupa Robocza NATO ds. Systemów Otwartych, zanim praca przeszła do dedykowanego zespołu zdolności.

Rytm utrzymania jest roczny i przewidywalny, co ma znaczenie przy planowaniu drogi rozwoju:

• Każdy podmiot — państwo, organ NATO albo program — składa do IP CaT Request for Change (RFC).
• RFC otrzymane do 1 września są kierowane do następnego wydania; IP CaT rozpatruje je w dialogu z właściwymi organami standaryzacyjnymi.
• Nowa wersja jest przekazywana Radzie C3 (obecnie DPC) do końca roku po wewnętrznym przeglądzie.
• Po zatwierdzeniu NISP staje się standardem NATO objętym STANAG 5524, który odnotowuje zgodę państw uczestniczących na stosowanie jego obowiązkowych standardów i profili.

Żywa baza IP CaT — a nie raz w roku publikowany PDF — jest definitywnym źródłem bieżącego statusu każdego standardu czy profilu: wersje robocze są aktualizowane na bieżąco między oficjalnymi wydaniami.

Tomy NISP: co zawierają tomy 1, 2 i 3

Od połowy lat 2010. NISP ma stabilną strukturę trzech tomów (starsze wydania dzielono inaczej — standardy krótko- i długoterminowe, profile oraz reguły projektowania w osobnych tomach). Każdy tom ma własną rolę:

• Tom 1 — Wprowadzenie. Podstawowe pojęcia (czym jest standard w rozumieniu NISP, czym jest profil), ramy zarządzania i kontroli konfiguracji, proces RFC oraz wytyczne rozwoju profili w załączniku. Przeczytajcie go raz: jest krótki i definiuje słownik, który pozostałe tomy zakładają.
• Tom 2 — Uzgodnione standardy i profile interoperacyjności. Rdzeń normatywny: standardy i profile obowiązkowe dla systemów finansowanych wspólnie przez NATO, zorganizowane według taksonomii C3 NATO (baseline 5.0) w działach takich jak User Applications, COI Services, Core Services i Communications Services. Znajdują się tam również uzgodnione profile, w tym profile Federated Mission Networking (FMN) Spiral 3 i Spiral 4 oraz kilkadziesiąt profili interfejsów usługowych.
• Tom 3 — Kandydackie standardy i profile interoperacyjności. Wskazówki informacyjne: standardy i profile dość dojrzałe, by planować względem nich programy startujące w ciągu najbliższego roku–dwóch, ale jeszcze nieobowiązkowe.

Tom 2 jest normatywny dla systemów finansowanych wspólnie przez NATO; tom 3 jest informacyjny. To jedno zdanie najczęściej umyka dokumentom zakupowym.

Obowiązkowe versus kandydackie: kategorie, które przesądzają, co musicie zbudować

NISP przypisuje każdemu ujętemu standardowi lub profilowi status obowiązkowości o precyzyjnym znaczeniu:

• Obowiązkowy (tom 2) — zastosowanie standardu lub profilu jest wymuszane dla systemów finansowanych wspólnie przez NATO na etapie planowania, wdrażania i testowania. Państwa są zobowiązane stosować NISP przy rozwijaniu zdolności wspierających misje NATO i zapraszane są do stosowania tych samych reguł na poziomie narodowym.
• Kandydacki (tom 3) — standard lub profil wolno stosować wyłącznie do testów i planowania programów. Musi być wystarczająco dojrzały i oczekuje się, że w dającej przewidzieć przyszłości stanie się obowiązkowy; własna reguła kciuka NISP mówi, że kandydat nie powinien tkwić w tomie 3 dłużej niż trzy lata.

Dwa dalsze rozróżnienia chronią zespoły przed błędną lekturą katalogu. Po pierwsze, obowiązkowość to nie to samo, co cykl życia: własną dojrzałość standardu (badanie/ratyfikacja, ogłoszony, zastąpiony — a dla standardów spoza NATO emerging/mature/fading/obsolete) śledzi organ go rozwijający, a dla standardów NATO wiążący status i zastrzeżenia narodowe żyją w bazie Biura Standaryzacji NATO, nie w NISP. Po drugie, stosowność to nie zgodność: Podstawowy Profil Standardów NISP wiąże standardy z elementami taksonomii C3, ale jeśli standard dotyczy usługi, którą realizujecie, stopień zgodności ocenia się w kontekście waszego projektu — sam NISP zauważa, że wymiana danych między systemami C2 i logistyki może wymagać jedynie podzbioru pojęć JC3IEDM (STANAG 5525).

Dla standardów spoza NATO IP CaT stosuje jawne kryteria przyjęcia — implementacje u wielu dostawców, rozwój w drodze konsensusu, brak obciążeń IP, otwartość, stabilność i testowalność — oraz jedną regułę konfliktów, którą warto zapamiętać: gdy przyjęty standard spoza NATO koliduje z właściwym standardem NATO, definicja NATO prevailuje.

Profile interoperacyjności, SIOP i to, jak spirale FMN korzystają z NISP

Same standardy nie interoperują — interoperują profile. W rozumieniu NISP profile definiują konkretne użycie standardów w punkcie interoperacyjności usług (SIOP) — punkcie referencyjnym architektury, w którym instancjonuje się jeden lub więcej interfejsów usługowych, aby systemy dostarczające tę samą usługę po różnych protokołach mogły ze sobą współpracować. Szczegółowa specyfikacja techniczna SIOP mieszka w profilu interfejsu usługi (SIP). Profil wskazuje swoje wymagania zdolnościowe i wspierające widoki architektoniczne NAF, charakterystyczne protokoły, opcje implementacji, standardy techniczne, SIOP oraz relacje do innych profili — a profile mogą odwoływać się do innych profili, aby maksymalizować ponowne użycie.

Profile są z założenia dynamiczne: muszą być aktualizowane, gdy zmienia się standard, na który się powołują, a właściciele profili mają obowiązek przeglądać je co dwa lata. Właśnie tutaj NISP spotyka się z Federated Mission Networking. Każda Spiral Specification FMN wiąże architekturę, instrukcje, profile i wymagania dla inkrementu federacji, a NISP jest miejscem, gdzie te profile stają się widocznymi zobowiązaniami: profile FMN Spiral 3 i Spiral 4 figurują jako uzgodnione w tomie 2 wydania 2023, a proponowany profil FMN Spiral 5 tkwił w tomie 3 jako kandydat. Grupa Zarządzania FMN zatwierdziła finalną specyfikację Spiral 6 w listopadzie 2025 roku i można oczekiwać, że jej profile wejdą do NISP tą samą drogą — uzgodnione profile w tomie 2 po przyjęciu (jak wygląda zestaw profili spirali w praktyce, opisuje materiał wymagania FMN Spiral 4).

NISP wymienia też miejsca, gdzie zgodność z profilami jest dowodzona: jego kryteria przeglądu pytają strony odpowiedzialne, czy problemy ze standardem ujawniły się podczas wydarzeń testowych typu CWIX i CIAV. Jeśli tam zmierzacie, czytajcie równolegle przewodnik przygotowania do CWIX — ćwiczenie testuje profile, nie PDF.

ADatP-34 a ADatP-3, APP-11, APP-6 i STANAG

Te oznaczenia są nieustannie mylone w dokumentach wymagań, więc oto tabela rozróżniająca. Krótko: ADatP-34 to katalog; ADatP-3 i APP-11 to wojskowa para przesyłania wiadomości, na którą wskazuje; APP-6 to symbolika; STANAG to instrument ratyfikacji. Wszystkie cztery publikacje same z kolei figurują wewnątrz tomu 2 ADatP-34 — z dokładnym wydaniem, którego muszą przestrzegać systemy NATO.

Więc nie ma czegoś takiego jak „wiadomość ADatP-34”. Wiadomości, które parsuje wasza bramka, to tekst ADatP-3/APP-11, słowa J-serii Link 16 (STANAG 5516 — zob. Link 16 i taktyczne łącza danych), VMF albo ładunek usługi typu MIP4; symbolikę, którą renderuje wasza mapa, definiuje APP-6 (porównanie z amerykańskim bliźniakiem w APP-6 kontra MIL-STD-2525). Zadaniem ADatP-34 jest powiedzieć, które wydanie każdego z nich jest aktualne i wiążące, w jakiej kombinacji profili i przy którym interfejsie. O modelu danych sił lądowych, który odgrywa tę samą rolę w świecie wymiany obrazu sytuacyjnego, piszemy w MIP4-IES.

Jak zespół software'owy korzysta z NISP: od profilu do macierzy zgodności

W praktyce zespół produktu C2 konsumuje NISP w czterech krokach, a artefakt, który przy tym powstaje — macierz zgodności — jest tym, o co faktycznie pytają oceniający, akredytatorzy i planiści CWIX:

1. Zmapujcie interfejsy na SIOP. Każdy zewnętrzny interfejs, który wasz produkt udostępnia lub konsumuje (wymiana śladów, przesyłanie formalnych wiadomości, czat, usługi mapowe, oznaczanie bezpieczeństwa), to punkt interoperacyjności usług. Nadajcie im nazwy: one zakotwiczają wszystko, co następuje.
2. Odszukajcie każdy w tomie 2. Znajdźcie węzeł taksonomii C3 dla tej usługi w tabelach standardów — każdy wiersz podaje tytuł, numer publikacji, profile, w których standard jest używany, oraz stronę odpowiedzialną, która doradza NATO w tej sprawie. Jeśli program celuje w federację FMN, zacznijcie od profilu FMN i weźcie jego listę standardów. Sprawdźcie tom 3 na to, co uderzy was w trakcie programu.
3. Zbudujcie macierz. Dla każdego SIOP zapiszcie standard, dokładne wydanie, zakres zgodności (pełny lub podzbiór, który NISP pozwala uzasadnić), status obowiązkowości i dowody, które wyprodukujecie.
4. Udowodnijcie to. Wplećcie macierz w zestaw testów zgodności, a potem przećwiczcie go na koalicyjnym wydarzeniu testowym. Wiersz macierzy bez dowodów z testów to deklaracja, nie zgodność.

Macierz zgodności dla koalicyjnego produktu C2 względem wydania 2023 wygląda mniej więcej tak:

Wersjonujcie macierz względem wydania NISP, z którego została zbudowana, i rebaseline'ujcie ją co roku — roczny rytm wydań oznacza, że wydania przesuwają się pod długimi programami. Widoki architektoniczne towarzyszące macierzy: elementy profili NISP odwołują się do NATO Architecture Framework (NAF 4), a o warstwę modelu informacji pod MIP4 — NATO C2 Information Model.

Typowe błędy inżynierów przy ADatP-34

• Parsowanie „wiadomości ADatP-34”. Takich nie ma. Treścią wiadomości jest ADatP-3/APP-11 (zob. objaśnienie ADatP-3 / STANAG 5500) albo taktyczne łącze danych; ADatP-34 je tylko cytuje. Budowanie „parsera ADatP-34” to błąd kategorii, który kosztował zespoły realnych miesięcy.
• Powoływanie się na „zgodność z NISP” bez zakresu. Zgodność dotyczy każdego SIOP, każdego profilu, każdego wydania. Oferta z „NISP-compliant” bez macierzy brzmi dla oceniającego jak szum; oferta z macierzą — nie.
• Wdrażanie wszystkiego w pełnej zgodności — albo pomijanie standardów tomu 2 jako opcjonalnych. Stosowność to nie zgodność (podzbiory da się uzasadnić), ale obowiązkowy znaczy obowiązkowy dla systemów finansowanych wspólnie przez NATO przy SIOP.
• Budowanie względem nieaktualnego wydania. Edition M, Edition N Ver 1 i Edition N Ver 2 różnią się cytowanymi wydaniami standardów bazowych; macierz przypięta do zastąpionego wydania nie przejdzie przeglądu. Śledźcie roczne wydania i termin RFC 1 września.
• Ignorowanie tomu 3. Standardy kandydackie to te, które stają się obowiązkowe w trakcie programu — NISP zakłada, że kandydat awansuje w ciągu około trzech lat. Wpiszcie je w drogę rozwoju, a nie w wniosek o zmianę.
• Traktowanie NISP jako rejestru statusów. Stan ratyfikacji i zastrzeżenia narodowe STANAG-ów żyją w bazie Biura Standaryzacji NATO; NISP świadomie ich nie dubluje.

Jak to wszystko zrobicie dobrze, ADatP-34 przestaje być nieprzezroczystym akronimem, a staje się tym, czym go zaprojektowano: jedną listą kontrolną, która zamienia „jesteśmy interoperacyjni z NATO” w weryfikowalne stwierdzenie inżynierskie.