Wdrożenie interoperacyjności NATO — przewodnik krok po kroku, część 2: wdrażanie taktycznych łączy danych — Link 16, CoT i MIP4

Część 1 ustaliła obwiednię konformancji. Część 2 wdraża taktyczne łącza danych stanowiące fundament większości platform interoperacyjnych z NATO: Link 16 dla operacji powietrznych i obrony powietrznej, Cursor on Target dla taktycznego edge, MIP4-IES dla wymiany C2 wojsk lądowych oraz STANAG 4559 dla wymiany produktów ISR. Każde ma własny wzorzec inżynierski, własną dyscyplinę konformancji i własne tryby awarii. Część 2 przechodzi przez nie kolejno.

Ramy architektoniczne znajdują się w Kompletnym przewodniku po interoperacyjności NATO. Towarzysząca seria o silniku fuzji C2 — Budowanie potoku fuzji obronnej — opisuje warstwę adapterów konsumującą te łącza danych wewnątrz platformy.

Krok 1: integracja Link 16

Link 16 to kanoniczne taktyczne łącze danych NATO dla operacji powietrznych i obrony powietrznej. Jest to również standard najczęściej źle rozumiany przez inżynierów oprogramowania wchodzących do obronności. Protokół opiera się na slotach czasowych (Time Division Multiple Access), katalog komunikatów (komunikaty J-series) jest niejawny, reguły uczestnictwa są zarządzane pasmem, a integracja niemal zawsze odbywa się przez sprzętowy MIDS terminal, a nie przez radio programowe.

Pragmatyczny wzorzec wdrożeniowy dla oprogramowania:

Integruj przez API MIDS terminal. Terminal sprzętowy obsługuje protokół ze slotami czasowymi; oprogramowanie obsługuje marshalling komunikatów ponad nim. Terminal udostępnia dostarczane przez producenta API — najczęstszym jest SIMPLE (Standard Interface for Multiple Platform Link Evaluation) — przez które oprogramowanie zgłasza komunikaty J-series do transmisji i odbiera przychodzące J-series do przetworzenia.

Traktuj interfejs SIMPLE jako stabilny kontrakt. Interfejs ewoluuje powoli; katalog komunikatów ewoluuje szybciej. Wersjonuj integrację wokół wydań katalogu komunikatów, a nie wersji SIMPLE. Aktualizacje katalogu to zaplanowane wydarzenia z własnym ponownym testowaniem konformancji.

Marshalluj komunikaty ze ścisłym typowaniem. Komunikaty J-series mają sztywne struktury zdefiniowane w niejawnym katalogu. Wdróż je jako typy generowane z kodu (tam, gdzie dostęp do katalogu na to pozwala) lub jako ręcznie pisane typy z rozbudowaną walidacją. Luźne typowanie w marshallingu Link 16 jest źródłową przyczyną większości niepowodzeń konformancji na CWIX.

Buforuj wychodzące, waliduj przychodzące. Komunikaty wychodzące są kolejkowane według priorytetu; platforma nie może zalewać terminala. Komunikaty przychodzące są walidowane wobec katalogu przed propagacją; źle sformułowane J-series są odrzucane z ustrukturyzowanym logowaniem, a nie po cichu przepuszczane dalej.

Głębsze spojrzenie inżynierskie, w tym topologia integracji i najczęstsze pułapki, znajduje się w Taktyczne łącza danych Link 16: spojrzenie inżynierskie.

Krok 2: integracja Cursor on Target

CoT to de facto taktyczna lingua franca poza formalnymi katalogami NATO. Powstał w Siłach Powietrznych USA, przyjęty w ekosystemie ATAK/WinTAK, coraz częściej wymagany w operacjach koalicyjnych niezależnie od formalnego statusu NATO. Platforma interoperacyjna z NATO działająca obok sił USA lub sojuszniczych wyposażonych w ATAK napotka CoT niezależnie od tego, czy formalna obwiednia konformancji go obejmuje, czy nie.

CoT jest technicznie prostszy niż Link 16 — oparty na XML, dobrze zdefiniowany schemat, brak niejawnego katalogu komunikatów, brak protokołu ze slotami czasowymi. Wymagany rygor inżynierski jest jednak ten sam.

Wzorzec wdrożeniowy:

Walidacja schematu na granicy. Każdy przychodzący komunikat CoT jest walidowany wobec schematu przed dalszym przetwarzaniem. Źle sformułowane komunikaty są głośno logowane i odrzucane; ciche akceptowanie to zły domyślny wybór.

Ścisła obsługa znaczników czasowych. Komunikaty CoT niosą czas obserwacji, czas wygaśnięcia świeżości komunikatu oraz czas wygaśnięcia (stale time). Dyscyplina trzech znaczników czasowych z wcześniejszych przewodników inżynierskich obowiązuje — czas obserwacji napędza korelację, stale time napędza decyzje cyklu życia, mylenie ich jest powracającym źródłem błędów.

Konserwatywne parsowanie pól opcjonalnych. Rozszerzenia CoT są powszechne; nie wszystkie są udokumentowane. Parsuj to, co udokumentowane; ignoruj to, co nie (z logowaniem); nigdy nie pozwól na crash na nieoczekiwanej zawartości.

Elastyczność transportu. CoT porusza się przez multicast UDP, TCP point-to-point, TCP przez TAK Server oraz (coraz częściej) MQTT. Warstwa adapterów obsługuje wszystkie cztery z wspólną ścieżką przetwarzania w dół potoku.

Szczegółowe ujęcie inżynierskie CoT znajduje się w Cursor on Target (CoT): standard XML stojący za taktycznymi aplikacjami świadomości sytuacyjnej. Perspektywa rozwoju wtyczek ATAK jest w Rozwój wtyczek ATAK.

Krok 3: wdrożenie MIP4-IES

Do wymiany z krajowymi systemami C2 powyżej szczebla brygady schematem jest MIP4-IES. Jest gęsty, kontrolowany wersyjnie i bezlitosny w testach konformancji. Multilateral Interoperability Programme definiuje model; Information Exchange Specification serializuje go.

Wzorzec inżynierski, który się sprawdza:

Traktuj MIP4 jako ścisły interfejs, a nie wewnętrzny model. Wewnętrzny model danych platformy to cokolwiek zaprojektuje zespół inżynierski; MIP4 to format wire, którym platforma mówi na granicy koalicji. Mapowanie między nimi jest dwukierunkowe i bezstratne dla pól operacyjnie istotnych.

Zachowanie round-trip jest testem. Komunikat MIP4 zmarshallowany na zewnątrz platformy, a następnie zunmarshallowany z powrotem, musi wytworzyć ten sam model wewnętrzny (modulo celowa kanonikalizacja). Niepowodzenia round-trip ujawniają stratne mapowania, błędy koercji typów i błędy aliasowania pól.

Generowanie kodu na podstawie schematu. Schemat MIP4-IES jest na tyle duży, że ręcznie pisany kod marshallingu dryfuje. Generuj typy z opublikowanego schematu; kod mapujący utrzymuj oddzielnie i recenzuj go jawnie.

Pinowanie wersji z jawnymi przejściami. Wydania MIP4 się zmieniają. Platforma jest przypięta do konkretnego wydania dla swojego bieżącego wdrożenia operacyjnego; przejścia to zaplanowane projekty z ponownym testowaniem konformancji.

Pogłębione spojrzenie inżynierskie na MIP4-IES, w tym anatomię modelu danych i rzeczywistość testów konformancji, znajduje się w MIP4-IES: standard wojsk lądowych NATO.

Krok 4: wymiana ISR przez STANAG 4559

STANAG 4559 (NSILI — NATO Standard ISR Library Interface) reguluje wymianę obrazów i produktów ISR między koalicyjnymi platformami C2. Wymagany dla każdej platformy konsumującej lub wytwarzającej obrazy z krajowych źródeł w kontekście koalicyjnym.

Rzeczywistość wdrożeniowa:

Najpierw strona konsumenta. Większość programów oprogramowania obronnego to konsumenci NSILI — odpytują koalicyjne biblioteki obrazów i integrują wyniki — a nie dostawcy NSILI. Interfejs po stronie konsumenta jest dobrze zdefiniowany i wykonalny; wdrożenie po stronie dostawcy to cięższy program z dodatkowym narzutem akredytacyjnym.

Pobieranie świadome pasma. Obrazy ISR są duże. Pobieranie przez łącza taktyczne musi być świadome pasma — najpierw miniatury podglądu, pełna rozdzielczość na żądanie operatora, progresywne pobieranie dla największych produktów. UI platformy uwidacznia stan pasma, aby operatorzy rozumieli kompromis.

Oddzielenie magazynu obrazów. Pobrane obrazy żyją w dedykowanym object store, a nie w operacyjnej bazie tracków. Metadane mapują obrazy do kontekstu tracka; sam obraz jest referencjonowany, a nie osadzony.

Oznaczanie klasyfikacją na obrazach. Pobrane obrazy niosą klasyfikację źródła zgodnie ze STANAG 4774/4778. Klasyfikacja podąża za obrazem przez całą platformę — warstwę wyświetlania, ślad audytowy, analizy w dół potoku. Zerwanie powiązania „dla wygody” to dokładnie ten skrót, którego recenzenci akredytacji szukają w pierwszej kolejności; część 3 tej serii omawia tę dyscyplinę szczegółowo.

Pogłębiony wzorzec wdrożeniowy STANAG 4559 znajduje się w Wdrożenie STANAG 4559: NSILI w praktyce.

Krok 5: powiązanie profilu ADatP-34

Pojedyncze łącza danych — Link 16, CoT, MIP4, STANAG 4559 — wdrażają konkretne standardy. Dopasowanie do profilu ADatP-34 wymaga, aby platforma wdrażała właściwe kombinacje tych standardów oraz aby kombinacje te spełniały scenariusze interoperacyjności profilu.

Dyscyplina powiązania profilu:

Scenariusze testowe wynikające z profilu. Dla każdego profilu ADatP-34, który platforma adresuje, zestaw testów konformancji obejmuje scenariusze ćwiczące łącza danych w kombinacji. Scenariusz może wymagać: odebrać aktualizację tracka powietrznego z Link 16, skorelować z trackiem naziemnym CoT z ATAK, odpytać NSILI o obraz obszaru, zfuzować całą trójkę w jeden ekran COP. Scenariusz testuje kombinację, a nie pojedyncze standardy.

Katalogi komunikatów wynikające z profilu. Profil definiuje, które komunikaty J-series są wymagane, które typy komunikatów MIP4 muszą być wymieniane, których rozszerzeń CoT się oczekuje. Platforma wdraża wymagany podzbiór, a nie cały katalog.

Śledzenie ewolucji profilu. Profile ADatP-34 ewoluują. Platforma śledzi bieżący profil operacyjny oraz profil następnej spirali. Praca inżynierska celująca w profil bieżący, ale antycypująca następny, to dyscyplina, która przeżywa przejścia wersji.

Krok 6: mosty dwustronne i poza-NATO

Platformy działające w rzeczywistych wdrożeniach koalicyjnych potrzebują mostów wykraczających poza katalog NATO. Integracja z ukraińskim Delta, protokoły wyłącznie FVEY, rozszerzenia specyficzne dla partnerów — każdy z nich to most stojący obok formalnych łączy danych NATO.

Wzorzec inżynierski formatu Delta jest w Format Delta i integracja z ukraińskim wojskiem. Szersze wzorce dzielenia się w koalicji, łącznie z kwestiami politycznymi, znajdują się w Wyzwania wymiany danych w koalicji.

Reguła architektoniczna: mosty dwustronne to oddzielne adaptery, a nie modyfikacje kodu łączy danych NATO. Most do Delta nie dotyka marshallingu Link 16; most do krajowego protokołu USA nie dotyka przetwarzania CoT. Izolacja adapterów rozciąga się na protokoły, nie tylko typy sensorów.

Krok 7: zbuduj uprząż konformancji wcześnie

Testy konformancji to praca, która odróżnia platformy przechodzące CWIX od tych, które oblewają. Uprząż uruchamiająca te testy to infrastruktura inżynierska tak samo istotna jak sama platforma.

Komponenty uprzęży:

• Zestawy testów per-standard. Round-trip komunikatów J-series Link 16; poprawność formy i semantyczna CoT; wymiana encji i round-trip MIP4; zapytania, pobieranie i mapowanie metadanych STANAG 4559. Każdy zestaw jest zautomatyzowany, gatowany w CI i produkuje ustrukturyzowane raporty.
• Odtwarzanie przechwyconych danych. Przechwycony ruch wire z prawdziwych ćwiczeń i wdrożeń operacyjnych odtwarzany wobec platformy. Ground truth dla testów regresyjnych.
• Symulatory systemów partnerskich. Tam, gdzie rzeczywiste systemy partnerskie nie są dostępne do testów jednostkowych, symulatory stają na ich miejscu. Wymieniają zgodne komunikaty z platformą i weryfikują, że odpowiedzi pasują do standardu.
• Testy integracyjne oparte na scenariuszach. Scenariusze profili ADatP-34 ćwiczone end-to-end. Platforma odbiera wejścia, wykonuje fuzję, produkuje wyjścia, które uprząż testowa weryfikuje wobec oczekiwanej ground truth.
• Śledzenie przygotowania do CWIX. Przypadki testowe, które platforma planuje zgłosić na CWIX, są śledzone oddzielnie, ze statusem pass/fail widocznym dla kierownictwa programu na długo przed ćwiczeniem.

Koszt zbudowania tej dyscypliny wcześnie jest realny, ale ograniczony; koszt pominięcia jej ujawnia się jako wielomiesięczne opóźnienia w trakcie samego okresu konformancji. Programy, które dostarczają platformy interoperacyjne z NATO na czas, to programy, które zbudowały uprząż konformancji już w pierwszym roku.

Co dalej

Część 2 wdrożyła taktyczne łącza danych. Link 16 przez MIDS terminal, CoT przez adapter walidujący schemat, MIP4-IES przez mapowanie zachowujące round-trip, STANAG 4559 przez konsumenckie API zapytań — wszystko spięte profilem ADatP-34 i ćwiczone przez uprząż konformancji.

Część 3 obejmuje mechanizmy klasyfikacji i releasability — powiązanie STANAG 4774/4778, wdrożenie silnika polityk, przepływy danych między enklawami oraz dyscyplinę releasability w koalicji, która sprawia, że platforma jest wdrażalna w kontekstach niejawnych.