Opracowanie fal SDR dla taktycznych systemów łączności

Tradycyjne radio wojskowe pakuje swój protokół komunikacyjny w dedykowany sprzęt — każdy standard modulacji, schemat kodowania i sposób rozłożenia sygnału jest zakodowany w układach analogowych, których nie można zmienić bez fizycznej wymiany sprzętu. Implikacja operacyjna jest znaczna: flota pojazdów wyposażona w starszy system radiowy jest zablokowana w tym systemie tak długo, jak działa sprzęt, a wdrożenie nowego waveformu lub interoperacyjność z inną formacją wymagają nowego pozyskania. Programowalne radia (SDR) rozwiązują to przez przeniesienie implementacji protokołu na warstwę oprogramowania. Ta sama platforma sprzętowa radioprzyjmuje wiele waveformów w ciągu całego cyklu życia przez aktualizacje oprogramowania, a nowe protokoły komunikacyjne mogą być opracowywane, testowane i wdrażane bez fizycznej wymiany każdego radia w flocie.

Jednak możliwość ta jest realizowana przez opracowanie waveformu — złożoną, wyspecjalizowaną dziedzinę inżynierii oprogramowania, która obejmuje przetwarzanie sygnałów, programowanie układów FPGA, testowanie protokołów i certyfikację wojskową. Niniejszy artykuł bada architekturę procesu opracowania waveformu SDR, rolę FPGA, ramy przenośności SCA/JTRS, cykl certyfikacji JITC i wymagania dotyczące interoperacyjnych waveformów koalicyjnych obsługujących standardy STANAG.

Architektura SDR: łańcuch od anteny do aplikacji

Platforma SDR dzieli radioprzetwarzanie na warstwy. Warstwa sprzętu zapewnia szerokopasmowy analog front-end — filtry, wzmacniacze, przetworniki częstotliwości — razem z parą przetworników ADC/DAC konwertujących analogowy sygnał na liczby cyfr i z powrotem. Przetworzone próbki cyfrowe trafiają do komponentu przetwarzania sygnałów cyfrowych, zazwyczaj zaimplementowanego na FPGA, który wykonuje operacje obliczeniowo intensywne: demodulację, synchronizację symboli, korekcję kodu i formowanie spektrum. Wynikowe dane wynikowe przechodzą do procesora, gdzie waveform aplikacyjny obsługuje tworzenie wiadomości, zarządzanie siecią i interfejs do systemów wyższego rzędu. Każda warstwa może być wymieniona lub zaktualizowana względnie niezależnie — zmiana waveformu FPGA nie wymaga zmiany front-end analogowego, a aktualizacja protokołu aplikacyjnego nie wymaga przeprogramowania FPGA.

Dla inżynierów oprogramowania wchodzących z tradycyjnych środowisk programistycznych, część FPGA łańcucha jest miejscem, gdzie opracowanie waveformu wybiega daleko poza konwencjonalne inżynieria oprogramowania. FPGA nie jest procesorem ze stałą architekturą ISA — jest macierzą konfigurowalnych bloków logicznych, które mogą być ze sobą połączone, żeby tworzyć dowolne układy cyfrowe. Programowanie FPGA oznacza opisanie architektury sprzętu w języku opisu sprzętu (HDL) — VHDL lub Verilog — lub w coraz większym stopniu używanie narzędzi syntezy wysokiego poziomu, które kompilują algorytmy C++ lub MATLAB do HDL. Stopień rownoleglości dostępny w FPGA — tysiące operacji wykonywanych jednocześnie — jest tym, co umożliwia FPGA obsługę wymagań przetwarzania sygnałów w czasie rzeczywistym, których sekwencyjne procesory nie mogą spełnić przy wymaganych szybkościach symbolowych.

Software Communications Architecture i przenośność waveformu

Software Communications Architecture (SCA) to ramy oprogramowania wywodzące się z programu JTRS (Joint Tactical Radio System) US DoD, definiujące jak waveformy SDR powinny być strukturyzowane, spakowane i uruchamiane tak, żeby ten sam waveform działał na wielu platformach radiowych od wielu dostawców. Waveform zgodny z SCA kapsułkuje logikę protokołu jako komponenty konfigurowane przez mechanizm CORBA (Common Object Request Broker Architecture), z WRE (Waveform Runtime Environment) zarządzającym ładowaniem komponentów, wstrzykiwaniem zależności i cyklem życia. Konfiguracja waveformu — parametry kanału, ustawienia mocy, tryb szyfrowania — jest przechowywana oddzielnie od logiki aplikacji, umożliwiając rekonfigurację bez ponownego kompilowania kodu waveformu.

Dla programów obronnych wartość SCA jest dwojaka. Po pierwsze, waveform opracowany jako zgodny z SCA może potencjalnie być licencjonowany i wdrażany na wielu platformach radiowych bez przepisywania integracyjnego, redukując koszt cyklu życia. Po drugie, platforma radiowa zgodna z SCA może być aktualizowana w nowe możliwości waveformu przez aktualizacje oprogramowania — na przykład ładowanie nowego waveformu obsługującego nowy standard szyfrowania lub prędkość danych po prostu przez serwis oprogramowania bez fizycznej wymiany każdego radia. W praktyce zgodność SCA napotyka tarcie: implementacje na różnych platformach radiowych wprowadzają rozszerzenia specyficzne dla dostawcy, a pełna przenośność waveformów od producenta A do producenta B wymaga staranności testowania nawet z rzekomą zgodością z SCA. Niemniej jednak ramy znacząco redukują koszty portowania w porównaniu z waveformami kompletnie specyficznymi dla platformy.

Opracowanie waveformu na platformie USRP i wczesna prototypizacja

Dla wczesnego opracowania i walidacji waveformu przed przejściem do certyfikowanego sprzętu wojskowego, środowisko Universal Software Radio Peripheral (USRP) w połączeniu z GNU Radio lub podobnymi platformami przepływu sygnałów zapewnia przystępne testerskie łóżko prototypowania. USRP zapewnia konfigurowalny analog front-end zdolny do pracy w szerokich pasmach częstotliwości; GNU Radio zapewnia bibliotekę bloków przetwarzania sygnałów wizualnie połączalnych w grafy przepływu, umożliwiając szybkie iterowanie schematów modulacji i struktur kodowania bez kompilowania kodu FPGA na każdym kroku. Kiedy algorytm waveformu jest stabilizowany i zwalidowany na USRP, inżynierowie mogą przejść do implementacji FPGA, ufając, że specyfikacja protokołu jest poprawna — izolując implementację sprzętu jako odrębny krok od projektowania algorytmu.

Cykl certyfikacji JITC i planowanie walidacji

Joint Interoperability Test Command (JITC) to agencja US DoD odpowiedzialna za testowanie i certyfikowanie systemów komunikacyjnych przed ich dopuszczeniem do użytku w sieciach wojskowych. Dla waveformu SDR planowanego do wdrożenia na sieciach obronnych, certyfikacja JITC weryfikuje że waveform prawidłowo implementuje swoje specyfikacje protokołu, interoperuje z innymi certyfikowanymi systemami i spełnia wymogi bezpieczeństwa i kryptograficzne mandatowane dla planowanych poziomów klasyfikacji. Certyfikacja JITC nie jest sprawdzianem końcowym — jest procesem wieloetapowym wymagającym udokumentowania architekturalnego, testowania laboratoryjnego, testowania interoperacyjności z innymi certyfikowanymi systemami i testowania walidacji operacyjnej w warunkach realistycznej sieci.

Harmonogram jest znaczącą zmienną programową. Waveform złożony obejmujący wiele konfiguracji protokołowych i obsługujący szyfrowanie może potrzebować 18–24 miesięcy od złożenia do certyfikacji. Programy, które nie finansują cyklu JITC jako głównej aktywności torującej ścieżkę, odkryją, że dojrzałość techniczna systemu wyprzedza gotowość certyfikacyjną — i nie mogą wdrożyć do sieci operacyjnych aż do zakończenia certyfikacji. Najlepszą praktyką jest angażowanie JITC wcześnie — na etapie wymagań systemu i przeglądów wstępnego projektu — żeby zrozumieć dokładnie co zostanie przetestowane, w jakiej konfiguracji i z jakimi innymi certyfikowanymi systemami. Wiele programów przechodzi wymagane poprawki projektowe wynikające z wczesnych spotkań JITC, które są znacznie tańsze do rozwiązania podczas projektowania niż po złożeniu systemu.

Waveformy koalicyjne: STANAG 4285, 5066 i Link 22

Interoperacyjność łączności koalicyjnej zależy od implementowania uzgodnionych standardów protokołowych, żeby systemy radiowe różnych narodów i dostawców mogły niezawodnie wymieniać wiadomości taktyczne. Kilka STANAGów (Umów Normalizacyjnych NATO) definiuje wymagania waveformów dla różnych reżimów taktycznych.

STANAG 4285 definiuje standardową metodę modulacji i kodowania dla systemów transmisji danych HF, na której opiera się korespondencja danych na falach krótkich na dalekich odległościach. Określa szczegółowo modulację, strukturę ramki, zestawy punktów konstelacji i procedury synchronizacji — zapewniając, że systemy HF różnych producentów i różnych narodów mogą niezawodnie wymieniać dane na trudnych, refleksyjnych propagacjach HF obserwowanych w komunikacji za horyzontem. Waveformy SDR implementujące STANAG 4285 muszą obsługiwać jego cztery standardowe prędkości danych, procedury automatycznej identyfikacji linku i wymagania zarządzania kluczami szyfrowania.

STANAG 5066 definiuje protokół warstwy łącza danych dla systemów radiowych HF, zapewniając niezawodną transmisję danych i zarządzanie błędami powyżej warstwy fizycznej waveformu. W połączeniu z STANAG 4285 dla warstwy fizycznej, stos 5066 zapewnia kompletny fundament transmisji danych HF używany w systemach BRASS i siatkach wymiany danych HF. STANAG 5066 definiuje Punkt Dostępu Usługi (SAP) standaryzujący jak aplikacje wyższe żądają transmisji danych i odbierają potwierdzenia, umożliwiając aplikacjom taktycznym działanie bez wiedzy o podsprzętowym medium radiowym.

Link 22, standaryzowany przez MIL-STD-6016 (który definiuje Link 16), rozszerza możliwości taktycznej wymiany danych o nowe tryby siatkowe i wsparcie dla szerszej gamy środowisk transmisji. Link 22 wspiera siatki HF i UHF, wymieniając dane taktyczne formatem wiadomości J-series — tymi samymi formatami wiadomości, które napędzają wymianę danych taktycznych Link 16, ale z ulepszonymi możliwościami siatkowania i redukcją wymagań łącza HF. Waveform SDR implementujący Link 22 musi zachowywać i przetwarzać wiadomości J-series z dokładną składnią i semantyką pola, interoperować z hostami Link 16 dla wymiany danych taktycznych i zarządzać synchronizacją siatkową w warunkach spornego widma.

Cykl życia opracowania waveformu: od wymagań do rozmieszczenia

Cykl życia opracowania waveformu SDR przebiega przez kilka odrębnych faz, z których każda ma specyficzne produkty i punkty wyjścia. Faza wymagań ustanawia specyfikację techniczną waveformu: obsługiwane STANAGi i MIL-STD, wymagane prędkości danych, ograniczenia mocy i widma, kompatybilność szyfrowania i docelowe platformy sprzętowe. Ta faza powinna angażować użytkowników operacyjnych wcześnie — operatorzy, którzy będą używać waveformu w warunkach polowych, mają wymagania dotyczące łatwości obsługi, zachowania wyjątkowego i zarządzania kluczami, które są trudne do zmodernizować po zakończeniu implementacji.

Faza projektowania systemu dekomponuje waveform na model komponentów SCA, definiuje interfejsy wewnętrzne między przetwarzaniem FPGA a logiką aplikacji procesora i projektuje procesy rekonfiguracji dynamicznej, jeśli waveform musi obsługiwać wiele trybów operacyjnych. Faza implementacji buduje i testuje komponenty iteracyjnie, z symulatorami pętli zamkniętej kanałów radiowych validującymi wierność sygnałów przed integracją sprzętową. Faza integracji sprzętu łączy implementację FPGA z procesorem aplikacyjnym i zestawia system na docelowej platformie radiowej lub testowym łóżku sprzętowym. Testowanie JITC zaczyna się na tej fazie, z dokumentacją architektury dostarczaną i wstępnymi testami laboratoryjnymi prowadzonymi wobec certyfikowanych urządzeń partnerskich.

Rozmieszczenie operacyjne po certyfikacji JITC zamyka pętlę: waveform jest wdrażany do operacyjnych jednostek radiowych przez aktualizację oprogramowania, z procesami zarządzania kluczami kryptograficznymi obsługiwanymi przez infrastrukturę zarządzania kluczami (KMI), a nie przez fizyczne dystrybucje sprzętu. Zdolność aktualizacji over-the-air lub przez sieć logistyczną jest jedną z kluczowych wartości operacyjnych platformy SDR wobec radia o stałym waveformie — i jest realizowana dokładnie przez dyscyplinę architektoniczną SCA opisaną powyżej.

W miarę jak organizacje obronne wdrażają bardziej interoperacyjne platformy C2, łączność taktyczna SDR coraz bardziej integruje się z systemi wymiany danych, takimi jak te opisane w artykule o wrotach taktycznych łączy danych — zacierając granicę między warstwą fizyczną a warstwą aplikacyjną standardów taktycznej wymiany danych jak Link 16 i CoT.