Oczywiście że można, a nawet powiem więcej – to się dzieje cały czas. W tej dziedzinie jest jednak trochę inaczej niż w przypadku koła. Telekomunikacja nie zatrzymała się w miejscu lecz ciągle się rozwija. Od czasu do czasu pojawiają się przełomowe rozwiązania zmieniające naszą rzeczywistość, takie jak sieć telefonii komórkowej. Zapewne jeszcze wielu z Was pamięta czasy, gdy w ramach GSM niektórzy operatorzy oferowali tzw pięciosekundówki, a w ramach abonamentu można było dostać 15 darmowych minut i 20 SMSów. To była rewolucja – telefon był zawsze z tobą (a to jednak czasami przekleństwo), a nie przywiązany do biurka i można było wysłać komuś krótką wiadomość (OszczędzałoSięNaSpacjachZaczynającKażdyWyrazZDużejLitery). Ruch w sieci generowały głównie rozmowy. Potem z kolejną generacją sieci przyszedł protokół WAP, czyli namiastka Internetu w telefonie. Pojawiały się pierwsze abonamenty bez limitu minut. Dziś w smartfonie funkcja telefonu jest dodatkiem. Ruch w sieci generuje głównie transmisja danych.

Tak chronologicznie to na początku były systemy C2 – command & control, czyli dowodzenia i kontrola. To nic innego jak przeniesienia części sztabowej roboty do środowiska teleinformatycznego. Systemy C2 ułatwiają zbieranie danych, planowanie oraz przygotowanie dokumentów rozkazodawczych. Jest to bardzo dobre rozwiązanie, ale że człowiek z natury jest leniwy, a ilość informacji spływającej na stanowiska dowodzenia rosła lawinowo wojskowi stwierdzili, że chcą lepsze zabawki (zawsze chcą coś lepszego). Tak oto do C2 dodawano z czasem kolejne literki wynikające z dodawania nowych funkcjonalności do tych systemów. Po pierwsze chodziło o skrócenie czasu reakcji – od zawsze ten, kto pierwszy pozyskał informację i wycelował miał większe szanse na przeżycie. Po drugie: optymalizacja przepływu danych – informacje z sensorów powinny trafiać w odpowiednie miejsce i nie zaśmiecać środowiska dowodzenia. Po trzecie: integracja różnych szczebli dowodzenia i zwiększenie interoperacyjności.

Na dzień dzisiejszy mamy zatem akronim C4ISR – od ang. command, control, communications, computers, intelligence, surveillance, and reconnaissance, co po naszemu rozszyfrowujemy jako dowodzenie, kontrola, łączność, komputery, wywiad, obserwacja/nadzór i rozpoznanie. Ale o co właściwie chodzi? Tak naprawdę to powiązanie ze sobą wielu podsystemów w jeden megasystem pozwalający dowódcom na uzyskanie jak najbardziej dokładnego obrazu sytuacji na polu walki oraz wspomagający ich w procesie dowodzenia. Literki C to tak naprawdę podsystemy informacyjne i dowodzenia (środki i sieci łączności, sieci komputerowe, centra danych, systemy lokalizacji jednostek własnych, itp.), a ISR to podsystemy zdobywania informacji i wskazywania celów, czyli rozpoznanie wszelkiej maści.

Chyba nawet dla laika jest jasne, że stworzenie takiego systemy to nie jest prosta robota do ogarnięcia przy kilku piwach i dużej paczce chipsów. Po pierwsze potrzebujemy sieci łączności – przewodowej i radiowej, by informacje przepływały pomiędzy różnymi poziomami dowodzenia w czasie zbliżonym do rzeczywistego. Po drugie potrzebujemy sieci komputerowych na stanowiskach dowodzenia wyposażonych w zasoby zdolne do przetwarzania dużych zbiorów danych. Muszą tu być zaimplementowane mechanizmy zarządzania informacją, oprogramowanie symulacyjne, analityczne, wspomagające procedury dowodzenia oraz bazy danych. Dużo baz danych. Po trzecie musimy mieć sensory, które będą karmiły bazy danych aktualnymi informacjami o wojskach własnych i przeciwniku.

Żeby nie była za nudno do tego wypadałoby zapewnić wymianę informacji pomiędzy wszystkimi Rodzajami Sił Zbrojnych (WLąd, SP, MW, WOT, ) i Rodzajami Wojsk (a tu jest już zdecydowanie dużo więcej, bo rozróżniamy rodzaje wojsk: pancernych, zmechanizowanych, aeromobilnych, rakietowych i artylerii, obrony przeciwlotniczej, inżynieryjnych, chemicznych, łączności i informatyki, rozpoznania i walki elektronicznej, lotniczych, radiotechnicznych, a to tylko te, które pamiętam).

No i zaczynają się schody, bo nawet w ramach jednego RSZ mogą występować różne bazy danych i różne protokoły transmisji. Trzeba to jakoś ze sobą pożenić i zmusić do gadania we wspólnym języku. Wymaga to trochę wysiłku, ale jest do zrobienia. Pod jednym warunkiem: masz dostęp do dokumentacji technicznej i nie musisz zgadywać, czy producent danego rozwiązania zastosował się w 100% do wytycznych zapisanych dla danego standardu, czy też wprowadził w protokołach dodatkowe bity danych co rozwala cały system.

Sporym wyzwaniem jest również architektura systemu. Trzeba się zdecydować jaki i gdzie będziemy przechowywali i przetwarzali zebrane dane. W przypadku stacjonarnych systemów nie ma problemu: budujemy serwerownię, umieszczamy w niej wymaganą liczbę fizycznych serwerów, na nich uruchamiamy wirtualne maszyny z przeznaczeniem na kontrolery domeny, serwery baz danych, serwery kopii zapasowej itp. Jednak posiadanie jednej serwerowni to duże ryzyko, bo występuje w takiej konfiguracji jeden punkt krytyczny – awaria serwerowni kładzie cały system. Jeśli zależy nam na wysokiej dostępności do usług to warto zadbać o co najmniej jeszcze jedną lokalizację, która będzie replikował się z główną serwerownią i w razie czego przejmie jej rolę.

A co jeśli jestem użytkownikiem mobilnym i potrzebuję dostępu do danych w każdym miejscu i o dowolnym czasie? Na dodatek zakładam, że środowisko w którym będę działał będzie mało przyjazne i prawdopodobnie powszechnie dostępne łącza zostaną poważnie uszkodzone lub poddane atakom cybernetycznym? Można przenieść swoje serwery do chmury, ale w takim wariancie musimy zainwestować w chmurę oraz redundantne połączenia do tej chmury. Drugim rozwiązaniem jest działanie zgodnie ze starożytną maksymą: jak nie możesz połączyć się z serwerem zabierz go ze sobą. Na dzień dzisiejszy oba te warianty są stosowane w wojskowych systemach teleinformatycznych, oba mają swoje zalety i wady.

W przypadku chmury ktoś inny martwi się o jej funkcjonowanie i utrzymanie. Ja muszę zadbać o łącze do niej – światłowód (jak jest dostępna infrastruktura stacjonarna), radio, satelita. Obowiązkowo zwielokrotnione, bo w przypadku zakłócenia jestem odcięty od danych oraz nie mogę przesyłać na serwery aktualizacji sytuacji.

W przypadku lokalnego serwera na stanowisku dowodzenia problem łączności „w górę” trochę traci na znaczeniu, bo dane mam lokalnie, jak nawiążę łączność z resztą sieci to wtedy wymienię się danymi z innymi użytkownikami i zrobię aktualizację sytuacji. Jestem jednak odpowiedzialny za działanie tego serwera, co angażuje dodatkowe siły i środki.

Jednak nawet najlepszy we wszechświecie C4ISR będzie bezużyteczny jak malakser w kuchennej szufladzie jeśli nie będzie "karmiony" aktualnymi informacjami z pola walki. Najlepiej, żeby proces "karmienia" był automatyczny, bo wiedza na dzisiejszym polu walki o tym, gdzie są wojska własne i gdzie jest przeciwnik jest równie ważna jak lufy, pancerz, skrzydła i drony.

Jest i to zapewne nie tylko trzecia, ale i czwarta, piąta… dziesiąta. Problem jest o wiele bardziej złożony od koła i można go rozwiązać na wiele różnych sposobów.

Ekipa megamózgów powiązana z Politechniką Poznańską postanowiła założyć start-up Milsim.AI Research Lab (kolejny w swojej karierze) i zaproponować właśnie inną drogę. Swój pomysł nawali OSANVE (brzmi jak sawanna w Afryce, ale oznacza Opportunistic Situational Awareness Networt for Versatile Edge) i oparli o coś, co fachowo nazywa się spatial hash grid, a przekładając na język bardziej zrozumiały dla statystycznego Kowalskiego chodzi o zastosowanie algorytmów zamieniających świat rzeczywisty na czterowymiarową macierz (trzy wymiary XYZ + czas, czyli czasoprzestrzeń). Na pierwszy rzut oka nie ma tu ani nic rewolucyjnego, ani innowacyjnego. Ot po prostu inna forma zapisu danych w bazie. Jednak gdy zaczniemy wgryzać się w zagadnienie algorytmów spatial hash grid to wszystko nagle zaczyna się niesamowicie komplikować. Zapewne pierwsze co wypluje wam przeglądarka to informacja, iż jest to technika chętnie stosowana w grach typu multiplayer. Tak, jest to prawda. Dlaczego? Z dwóch zasadniczych powodów: szybkość przetwarzania danych (a dokładniej informacji o położeniu obiektu na cyfrowej mapie), co wiąże się z ograniczeniem zapotrzebowania na moce obliczeniowe oraz oszczędność przestrzeni dyskowej. Na serwerach obsługujących dziesiątki tysięcy graczy jest to bardzo ważne zagadnienie.

Ale gry to nie wszystko. Spatial Hasing jest też chętnie stosowane w algorytmach sztucznej inteligencji, detekcji kolizji czy symulacjach.

Na czym to polega? Algorytmy dokonują swego rodzaju kwantyzacji: rzeczywisty świat przekształcają na komórki (2D lub 3D, przez informatyków zwane wiadrami, z ang. bucket), które układane są w strukturę macierzy, czyli każda komórka na swoich sąsiadów (z prawej, lewej, góry, dołu). Cała magia opiera się nie na „obrabianiu” zawartości takiej komórki, ale na operowaniu hashem, czyli funkcją skrótu. Hash charakteryzuje się tym, że ma stałą długość.

Tak dla przykładu skrót obliczony wg metody SHA256 dla ciągu znaków „Dane wejściowe” wynosi (w postaci szesnastkowej) 59cd06a366664b56551cc1af64bba46ea2f5e21a28d1a836ec1a813785967592. Jak wrzucicie tę liczbę w konwerter HEX –> BIN to otrzymacie ciąg o długości 256 bitów.

Dla ciągu znaków „Nie ważne jak długi będzie ciąg znaków. Funkcja skrótu SHA-256 zawsze daje ciąg o długości 256 bitów” wartość szesnastkowa wynosi c6e339c0d66e6c7a05ad859d95ca2cbad62e859d80182f236b35cd6953dd5148. I nie zgadniecie. Postać binarna ma znów długość 256 bitów.

Dlaczego to takie ważne? Maszyny cyfrowe po prostu bardziej „lubią” operować na danych o określonej długości. Przy ciągach bitów o różnej długości muszą w pierwszej kolejności sprawdzić ich długość, dokonać odpowiednich wyrównań i dopełnień, wykonać kilka operacji odwołania do pamięci. Przy niewielkich zbiorach danych różnica jest niezauważalna, ale przy naprawdę dużych zbitkach wszystkie efekty dodatkowych taktów w działaniu zaczynają się nawarstwiać i widoczne są różnice w wydajności.

Po tej przydługiej dygresji wróćmy jednak do algorytmów spatial hash grid. Cały proces kwantyzacji świata wygląda w uproszczeniu tak:

• STRUKTURA: określamy rozmiar komórki (lub jak kto woli wiadra) na taki, by był zbliżony do maksymalnego rozmiaru obiektu, który chcemy umieścić w naszym cyfrowym świecie. Chodzi o to, by obiekt zajmował jedną komórkę;
• SKRÓT: funkcja haszująca przekształca współrzędne komórki na skrót, czyli coś, co można nazwać unikalnym kluczem o stałej długości. Klucz, jak to ma w swojej naturze, zazwyczaj pasuje tylko do jednego zamka. Tak jest też w tym przypadku: skrót jednoznacznie identyfikuje konkretną komórkę (choć jak z tanimi zamkami, tak i kiepska funkcja haszująca może dawać kiepskie rezultaty);
• WSTAWIANIE OBIEKTÓW – algorytmy wyliczają, do której komórki wpadają nam obiekty w cyfrowym świecie i dodają je do listy w tej komórce. Jak chcemy dowiedzieć się co „siedzi” w danej komórce znajdujemy jej położenie, odnajdujemy jej skrót, który jest kluczem do jej zawartości, i sprawdzamy co tam sobie siedzi. Co ważne algorytmy nie potrzebują tworzyć bazy wzajemnych powiązań między obiektami na mapie. Jeśli dwa różne sensory widzą coś w jednej komórce/wiadrze to następuje natychmiastowa fuzja danych.

W tym momencie zapewne programistom popękało szkliwo na zębach, ale jak zwykle stosuję szereg uproszczeń i skrótów myślowych aby nie zamulić tematu zagadnieniami zrozumiałymi tylko dla wąskiej grupy specjalistów. Drodzy programiści – odpuście.

Wróćmy jednak do rewolucyjnego pomysłu ludzi z polibudy, bo jak na razie niewiele z tego co przeczytaliście wskazuje na coś więcej, niż jakąś bieda gierkę z czołgami na telefon.

Otóż panowie słusznie zauważyli, że dotychczasowe modele systemów dowodzenia opierają się na centralnym elemencie (serwerze lub chmurze), który jest niczym mózg dla żywego organizmu: jeśli mózg przestanie funkcjonować organizm czeka śmierć. Co zatem trzeba zrobić? Zbudować organizm niepotrzebujący mózgu, a w zasadzie taki z rozproszonym mózgiem. Jak? Wykorzystując architekturę MESH lub jak kto woli mozaikę. Na czym to polega? Elementy sieci nie mają żadnego wyróżnionego punktu centralnego (serwera czy routera sterujących pracą pozostałych elementów) lecz komunikują się ze sobą na zasadzie każdy z każdym wymieniając się informacją. Dodatkowo megamózgi z MILSIM.AI postanowiły wyposażyć każdy z tych mini węzłów sieci w swoim modelu OSANVE we własny, lokalny model otoczenia zbudowany w oparciu o algorytmy spatial hash grid. Efekt jest taki, że sieć MESH działając bez zakłóceń ze strony przeciwnika wymienia się szybko i płynnie bieżącą informacją o stanie otoczenia. Gdy wchodzą celowe zakłócenia przeciwnika lub część z węzłów zostanie uszkodzona/zniszczona OSANVE nie zgłasza jednego wielkiego komunikatu FATAL ERROR, tylko korzystając z algorytmów rekonfiguracji szuka nowych ścieżek połączeń. Nawet jeśli jakaś część sieci lub pojedynczy węzeł zostaną odcięte od pozostałych elementów nadal dzięki lokalnemu modelowi świata wiedzą, co jest grane. Oczywiście prędzej czy później dane te ulegną przedawnieniu, ale prędzej czy później powinny również zostać przywrócona kanały łączności.

Dodatkową zaletą tego rozwiązania jest możliwość zaimplementowania tych algorytmów również na efektorach (dronach FPV, rakietach przechwytujących, inteligentnych minach, przeciwpancernych pociskach kierowanych), które zanim dopełnią swego żywota zgodnie ze swoim przeznaczeniem niszcząc sprzęt i siłę żywą przeciwnika mogą przecież pełnić rolę sensora. W końcu lecąc do celu mijają po drodze niemały obszar omiatając przestrzeń swoimi głowicami.

Jedna uwaga: aby efektor stał się sensorem karmiącym system informacją potrzeba zmiany filozofii w konstruowaniu tego sprzętu. Tradycyjnie sprzęt wojskowy projektowało się układając dla niego wymagania taktyczno-techniczne, budowało się prototyp i wypełniało się go osprzętem dedykowanym do konkretnego działania. Można to nazwać zamkniętą architekturą, bo bez dokumentacji technicznej i udziału producenta niewiele można w takim systemie zmienić, a jeśli już się go modernizuje to zmienia się cholernie dużo, bo nie ma możliwości dostosowania funkcjonowania całych bloków. Trzeba je po prostu wyrzucić i wstawić nowe. Model ten od pewnego czasu jest zastępowany przez architekturę otwartą, a to dzięki przejęciu przez oprogramowanie części funkcji realizowanych dotychczas sprzętowo. To jak działa urządzenie nie jest już definiowane ściśle przez warstwę hardwarową, ale przez software.

Porównanie wydajności modelu OSANVE z tradycyjnymi protokołami. Źródło: Milsim.AI Research Lab

Dokładając teraz do istniejących radarów, głowic optoelektronicznych, odbiorników radiowych, czujników akustycznych, kamer indywidualnych, radiostacji a nawet rakiet czy amunicji krążącej (i co tam jeszcze przyjdzie nam do głowy) moduł z oprogramowaniem OSANVE zaproponowanym przez MILSIM.AI możemy z już istniejących klocków stworzyć system pozwalający na zbieranie z setek sensorów i budowanie jednolitego obrazu pola walki w czasie rzeczywistym wykorzystując do maksimum możliwości posiadanych zasobów. No i nie potrzebujemy dużych centrów obliczeniowych, które stanowią SPOF (Single Point of Failure).

Każdy z elementów systemu jest strumieniem danych, przy czym o ile pojedynczy sensor może mieć ograniczoną świadomość o otoczeniu, o tyle wiele sensorów z różnych domen oraz zakresów wzajemnie się uzupełnia. Jednocześnie agregacja tych danych odbywa się zupełnie automatycznie, bez konieczności angażowania operatora. Twórcy OSANVE deklarują również, że integracja z nowymi platformami będzie liczona w godzinach, nie miesiącach (patrz integracja ICBS z naszymi radarami – nie tak to miało wyglądać, choć system miał być otwarty i elastyczny).

Porównanie wydajności modelu OSANVE z tradycyjnymi protokołami. Źródło: Milsim.AI Research Lab

Na obecnym etapie projekt OSANVE wchodzi w fazę testów praktycznych. Przed twórcami niewątpliwie jeszcze dziesiątki nieprzespanych nocy i hektolitry wypitej kawy i energetyków (też tak maci, że jak siedzi wam w głowie jakiś problem to nawet zasypiając myślicie o rozwiązaniu i potraficie obudzić się w środku nocy z przeświadczeniem, że koniecznie musicie sprawdzić nowy pomysł już teraz?), ale już dziś pomysł wygląda bardzo obiecująco.

Zatem do czego można wykorzystać OSANVE? W zasadzie do wszystkiego, bo dzisiejsze technologie z natury są dual-use. Programiści z MILSIM.AI najwyraźniej świadomi ostrej konkurencji na rynku postawili na lekkie i otwarte protokoły wymiany danych. Dostosowanie ich do wymagań konkretnego klienta to kwestia wprowadzenia pewnych zmian w kodzie. Zwracam uwagę, że sformułowanie „otwarty protokół” to nie „otwarta transmisja danych” i nie oznacza możliwości grzebania w transmisji przez każdego chętnego. To są całkowicie dwie różne kwestie.

Na rynku cywilnym algorytmy z MILSIM.AI można wykorzystać jako bazę do stworzenia systemu monitorowania ruchu pojazdów (zarówno tych przemieszczających się po drogach jak i w powietrzu) lub w systemach monitorowania infrastruktury krytycznej.

W środowisku militarnym OSANVE można zastosować jako podsystem do karmienia danymi systemów dowodzenia C4ISR i wymiany danych. Brak centralnych punktów wymiany danych oraz rozproszona architektura są tu niewątpliwym atutem. Budowa systemy świadomości sytuacyjnej na najniższym poziomie taktycznych (już od drużyny) przy stosunkowo małych kosztach też wydaje się kuszącym zastosowaniem. Jak sami twórcy podpowiadają można też na jego bazie zbudować system C-UAS, w którym odwrócimy stosunek koszt-efekt na korzyść obrońcy: efektory wielokrotnego użytku, sensory z półki + dane z C4ISR, rozproszenie i przeniesienie mocy obliczeniowych oraz decyzji o ataku na krawędź sieci (brak kosztownych centrów obliczeniowych) – to zalety, dzięki którym można pokusić się o rozpoczęcie prac nad parasolem antydronowym na najniższych szczeblach dowodzenia.

Dla ciekawskich i zainteresowanych współpracą z MILSIM.AI Research Lab

OSANVE — Common Operating Picture

MILSIM.AI | Przejmij Dowodzenie

Adam AS

Karierę zaczynałem jako nieopierzony oficer od walki radioelektronicznej wierząc, że WRE będzie dynamicznie rozwijało się w WP. Rok po roku byłem odzierany z marzeń, aż podjąłem decyzję o zmianie kierunku na łączność. Przez kolejne lata służby zajmowałem się organizacją łączności. Na starość postanowiłem wrócić do pierwszej zawodowej miłości i pisać o ciekawostkach ze świata WRE i okolic.