Polskie systemy automatyzacji obrony powietrznej cz. II: Po wejściu do NATO

Artykuł sponsorowany, partner publikacji PGZ S.A.

Prace nad systemem DUNAJ rozpoczęły się w roku 1996 od realizacji projektu koncepcyjnego. Umowę na realizację etapów B+R podpisano w IV kwartale roku 1997. Badania państwowe zakończono w roku 2000, a w latach 2001-2004 obiekty systemu Dunaj zostały wdrożone do eksploatacji w SZ RP. Te daty warto przypomnieć, by ocenić poziom techniczny systemu i celność wybranych do jego realizacji rozwiązań. Przypomnijmy, że gdy projekt powstawał, Polska nie była już członkiem Układu Warszawskiego i jeszcze nie była w NATO - był to okres tzw. Partnerstwa dla Pokoju z bardzo ograniczonym dostępem do informacji o organizacji systemu dowodzenia NATO. Przy opracowaniu projektu korzystano z doświadczeń uzyskanych przy budowie wcześniejszych systemów i z dostępniej wiedzy o systemach teleinformatycznych

System Dunaj miał być i dzisiaj jest kluczowym komponentem C2 w systemie dowodzenia obroną powietrzną. Gdy inicjowano projekt, Zamawiający (wtedy Departament Polityki Zbrojeniowej MON i Wojska Lotnicze i Obrony Powietrznej), dysponował jedynie pewną wiedzą o planach realizacji dla europejskich państw NATO systemu OP pod nazwą ACCS (Air Command and Control System) - patrz Rysunek 1, którą udostępnił Wykonawcy.

Zamawiający postawił na system DUNAJ następujące wymagania:

• Komponenty systemu powinny być mobilne,
• System powinien funkcjonować w 4 Sektorach OP,
• System powinien składać się z dwóch podsystemów:

o   Podsystemu rozpoznania radiolokacyjnego, którego zadaniem miało być opracowanie jednolitej zidentyfikowanej informacji o sytuacji powietrznej (dopiero po wstąpieniu do NATO, zaczęto ją nazywać RAP-em) na bazie informacji ze stacji radiolokacyjnych rozlokowanych na obszarze Polski,

o   Podsystemu kierowania walką, którego zadaniem miała być koordynacja działań środków walki (lotnictwa i naziemnych środków OP).

• System powinien stanowić wyposażenie dla SD zasadniczych i zapasowych,
• System powinien cechować się wysoką niezawodnością i być przygotowany do ciągłej pracy,
• System powinien być przystosowany do przetwarzania informacji niejawnej.

Opisując jak powstawał system DUNAJ, zacznę od przedstawienia istotnych założeń projektowych, jakie zostały przyjęte przez autorów projektu tego systemu. Aby móc ocenić ich dojrzałość i „śmiałość" warto jeszcze raz przypomnieć, że działo się to w latach 1996-98. Wymagania Zamawiającego zdekomponowano na poniższe założenia projektowe:

• Należy zapewnić wysoką przeżywalność systemu (survive to operate) – w rozumieniu zaplanowania zachowania się systemu w sytuacji jego degradacji – w projekcie należy przewidzieć rozwiązania rezerwowe tzw. backup'y. Przez degradację systemu należy rozumieć eliminację jego komponentów, źródeł informacji, środków walki i komponentów C2, jak również degradację systemu łączności – uszkodzenia lub zmniejszenie przepustowości łącz;
• System OP jest systemem rozproszonym terytorialnie. Jego komponenty są zlokalizowane na posterunkach radiolokacyjnych, lotniskach, w lokalizacjach rozlokowania środków ogniowych (rakietowych i artyleryjskich) i środków walki elektronicznej. Centra decyzyjne systemu to Centrum Operacji Powietrznych oraz cztery Ośrodki Dowodzenia i Naprowadzania – ODN (odpowiedniki NATO Control and Reporting Centre – CRC);
• Do systemu będą bezpośrednio dołączane tylko źródła radiolokacyjne 3D z wyjściami cyfrowymi (w tym czasie w PIT zostały opracowana pierwsze stacje 3D z wyjściami cyfrowymi N-11 i N-12, były to radary, w których do wydawania danych radiolokacyjnych wykorzystywano protokół ASTERIX^[1];
• Należy zapewnić integrację z poprzednią generacją stacji radiolokacyjnych z wyjściami analogowymi - należy opracować adaptery dla zestawów odległościomierz-wysokościomierz, które będą wydawać informacje jak stacje 3D. Zakładano, że wykorzystanie tych sensorów będzie ograniczone do kliku lat. Radary te (zestawy N-31 i N-41) pracują w systemie do dnia dzisiejszego i dopiero teraz są zastępowane przez mobilne, trójwspółrzędne stacje radiolokacyjne ODRA.;
• System ma być transportowalny i posiadać krótkie czasy osiągnięcia gotowości bojowej. Prototypy komponentów systemu były zrealizowane jako transportowalne (zabudowane w kontenerach 20ft), po wstąpieniu do NATO obiekty systemu DUNAJ zostały wdrożone do Sił Zbrojnych, jako stacjonarne i dopiero dzisiaj wraca się do realizacji mobilnych komponentów tego systemu.

-         Obiektami odpowiedzialnymi, za opracowanie informacji o sytuacji powietrznej będą: obiekty Centrum Rozpoznania Radiolokacyjnego CRR-20 (patrz Rysunek 2), przeznaczone dla Ośrodków Dowodzenia i Naprowadzania (ODN), obiekty Zautomatyzowany Posterunek Radiolokacyjny ZPR-10 i Terminale Sprzężenia Stacji Radiolokacyjnych TSS-10 przeznaczone dla posterunków radiolokacyjnych WRT. Ze względu na zmniejszenie liczby tych posterunków Terminale TSS-10 zostały wycofane z eksploatacji około roku 2010.

-         Obiektem odpowiedzialnym za kierowanie środkami walki będzie obiekt Centrum Dowodzenia Sektora CDS-20. Obiekt ten był wyprodukowany tylko w dwóch egzemplarzach, które zostały wycofane z eksploatacji w trakcie modernizacji systemu DUNAJ w 2009 roku. Generalnie z powodu braku otoczenia systemowego – obiektów kierowania jednostkami OPL (SAMOC^[2]) - i lotnictwem (WOC^[3]) ich przydatność uznano za niewielką. Dzisiaj brakująca w systemie DUNAJ funkcjonalność kierowania środkami walki na SD Sektorów OP jest zauważalna i jest przesłanką do jej odbudowy.

Korzystając z udostępnionej przez WLOP wiedzy o ACCS^[4], architektura system DUNAJ próbowała odwzorować podział zadań miedzy komponentami system ACCS –ACC (CDS-20), RPC (CRR-20) i SFP (ZPR-10) – odpowiednik ARS w systemie ACCS. W planach MON przewidziano, że system DUNAJ będzie w przyszłości uzupełniony komponentami odpowiedzialnymi za integrację środków walki (PRZELOT‑SAMOC i PRZELOT-WOC) oraz systemów koordynacji wsparcia lotniczego dla Wojsk Lądowych i Marynarki Wojennej CKOP^[5] PODBIAŁ (AOCC^[6]). Historia pokazała, że realizacja systemu DUNAJ znacznie wyprzedziła wdrożenie ACCS. DUNAJ jest eksploatowany od 2001 roku, mamy rok 2022 a ACCS nie jest jeszcze wdrożony i zbliżamy się do decyzji o rezygnacji z jego wdrożenia.

Bazując na opisanych założeniach projektowych została podjęta, najbardziej istotna z punktu widzenia przyszłości, decyzja projektowa:system DUNAJ, jako system integrujący system dowodzenia OP, będzie wykorzystywał do wymiany informacji pomiędzy jego komponentami, sieć IP-WAN, którą nazwano „OP-NET"^[7].

  Wykonawca był świadomy istniejących ryzyk związanych z tą decyzją:

-         budowany był system czasu rzeczywistego, w którym należało minimalizować opóźnienia transmisji danych, a do dyspozycji była sieć podkładową oferującą kanały analogowe o przepustowości do 9.600 bit/s i rozwijającą się sieć łączności cyfrowej oferującą, w tym czasie, kanały 64kbit/s;

-         technika sieci rozległych nie była jeszcze zestandaryzowana, produkty różnych producentów nie zawsze współpracowały ze sobą (w realizacji sieci postawiono na produkty CISCO i SUN);

-         nie było wzorców projektowych, należało bazować na doświadczeniu i intuicji.

-         nie było polskiego urządzenia kryptograficznego klasy IP-Crypto dedykowanego dla rozwiązań klasy IP-WAN (system został zakredytowany do przetwarzania informacji niejawnych dopiero w roku 2009 z wykorzystaniem urządzania natowskiego).

Zamawiający i Wykonawca wspólnie podjęli to ryzyko. To ważne, bo odwaga decydentów umożliwiła osiągnięcie efektów, które do dzisiaj budzą respekt.

Dzięki temu rozwiązaniu dzisiaj system posiada cechy systemów sieciocentrycznych. Posiada architekturę otwartą, jest skalowalny i podatny na rozwój. To właśnie sieć „OP-NET" i przyjęta w niej filozofia wymiany informacji pozwala dołączać do systemu nowe komponenty, a więc umożliwia rozwój systemu OP.

Jednym z problemów, jakie należało rozwiązać realizując system DUNAJ była organizacja przetwarzania informacji radiolokacyjnej. Trudność wynikała z następujących przyczyn:

-         należało odbierać informacje z radarów z wyjściami cyfrowymi i z radarów z wyjściami analogowymi,

-         zastosowanie do wymiany informacji sieć IP-WAN oznaczało, że poszczególne meldunki z radaru będą miały różne opóźnienie (transmisja pakietowa),.

-         opracowywana informacja RAP powinna mieć minimalne opóźnienie.

Później dodano jeszcze wymaganie dotyczące implementacji natowskich protokołów wymiany danych Link-1, Link-11B i Link-16.

Jak wspomniano, w systemie DUNAJ do wymiany informacji wykorzystywana jest sieć IP-WAN, którą nazwano „OP‑NET" (Rysunek 3). Poszczególne komponenty systemu stają się węzłami tej sieci, co zapewnia, że mają możliwość wydawania w tej sieci informacji i odbioru informacji w niej dostępnej.

W sieci zdefiniowano wewnętrzne protokoły wymiany informacji (native protocols). Do wymiany informacji o sytuacji powietrznej wykorzystywane są protokoły oparte o format ASTERIX, do wymiany informacji dotyczącej kierowania środkami walki wykorzystywany jest protokół XDR (ang. eXternal Data Representation), w którym zawartość struktur informacyjnych odpowiada zawartości depesz J standardu Link-16, natomiast do wymiany dokumentów bojowych wykorzystywana jest poczta elektroniczna i dokumenty zgodne z natowskim standardem ADatP-3. W sieci wykorzystywany jest mechanizm transmisji grupowej jeden do wielu tzw. multicast.

Projektowanie rozproszonego systemu wymagało zdefiniowania modelu biznesowego systemu:

-         podziału zadań pomiędzy komponentami (generalnego podziału odpowiedzialności);

-         funkcji realizowanych przez komponenty;

-         funkcji/zadań operatorów i interfejsu człowiek – stanowisko pracy - HMI^[8];

-         interfejsów pomiędzy komponentami (zakres informacyjny wymiany danych).

Kolejną fazą projektowania systemu było przeniesienie modelu biznesowego na rozwiązania techniczne, w tym przypadku wykorzystujące siec IP WAN. Najważniejszym elementem tego projektu były zasady wymiany informacji. Zastosowano wymianę informacji typu multicast (jeden do wielu)\ i jednocześnie zdefiniowano standardowe protokoły wymiany informacji w relacjach (patrz Rysunek 4):

-         System C2 – Sensor (Interfejs Sensora),

-         System C2 – Efektor (Interfejs Efektora),

-         System C2 – System C2 (Interfejs C2)

Dystrybucja informacji w sieci IP-WAN w formie multicastu daje następujące dodatkowe możliwości:

-         wydawanie informacji o sytuacji powietrznej umożliwia korzystanie z tej informacji wielu użytkownikom jednocześnie;

-         wydawanie adresowanego rozkazu o wskazaniu celu do zwalczania oznacza dla adresata rozkaz, a dla pozostałych uczestników informację, że cel jest obsługiwany przez wskazany komponent;

-         wydawanie meldunków o statusie uzbrojenia oraz o rezultatach działań daje uczestnikom działań świadomość możliwości działań i uzyskanych efektach działań.

Takie rozwiązanie powoduje, że:

-         Komponent systemu OP traktuje sieć WAN jako dostawcę usług (każda usługa jest źródłem informacji). Te usługi pozwalają zapełniać zawartość lokalnej bazy danych, w oparciu o którą budowana jest świadomość sytuacyjna.

-         Komponent systemu OP jest dostawcą usług udostępnianych przez sieć WAN.

To rozwiązanie zapewnia współdzielenie się danymi, informacją i wiedzą (data sharing). Ten mechanizm zapewnia wspólną świadomość sytuacji w przestrzeni walki – co jest podstawową zdolnością systemów o cechach sieciocentrycznych.

Rozwiązania systemu DUNAJ ewoluowały w pierwszych latach po przyjęciu Polski do NATO. NATO uruchomiło inwestycyjne programy dostosowawcze tzw. Capability Packet (w znacznej części finansowane ze środków NATO), których celem było zintegrowanie polskiego systemu OP z systemem NATINADS  (NATO INtegrated Air Defence System). Zadania ujęte w pakietach inwestycyjnych obejmowały miedzy innymi:

-         opracowania RAP (Recognised Air Picture) z wykorzystaniem standardu Link-1,

-         integracji natowskich komponentów OPL przy wykorzystaniu Link-11B,

-         współpracy z powietrznym systemem rozpoznania AWACS,

-         współpracy z MW przy wykorzystaniu Link-11A

Aby sprostać najpilniejszemu zadaniu implementacji RAP, w latach 2001-2002, jako kontynuację programu B+R DUNAJ, realizowano program implementacji standardu LINK-1 oraz natowskich procedur operacyjnych związanych z opracowywaniem wspólnego obrazu sytuacji powietrznej tzw. RAP. Realizacja tej pracy oraz wsparcie udzielane dowództwu Sił Powietrznych w realizacji pakietów dostosowawczych wiązało się z licznymi kontaktami pracowników PIT-RADWAR z natowskimi Agencjami - głownie z Agencją NC3A w Hadze i NATO Programming Centre (NPC)w Glons. W efekcie tych działań zaimplementowano w systemie DUNAJ protokół LINK-1 i związane z nim procedury operacyjne w tym tzw. „Cross Tell Procedure" odpowiadającą za koordynację wymiany informacji o sytuacji powietrznej pomiędzy Sektorami OP.

Przedstawiony powyżej opis systemu DUNAJ, korzysta już z nomenklatury natowskiej, bo jednym z istotnych efektów współpracy było poznanie słownictwa, procedur i natowskich standardów wymiany informacji.

W latach 2003-2004 uruchomiono program pk. PRZYLASZCZKA mający na celu analizę możliwości implementacji systemach narodowych, natowskich standardów wymiany danych Link-11B, Link-16, Link-22 i ADatP-3. Zadanie to realizował PIT‑RADWAR (wtedy PIT) przy współpracy z OBR CTM i ITWL. W efekcie tego programu powstał projekt koncepcyjny implantacji ww. protokołów w systemach DUNAJ, PRZELOT-SAMOC i ŁEBA. W oparciu o tę koncepcję realizowano kolejne zadania wynikające z pakietów dostosowawczych - zaimplementowano standard Link-11B w systemach DUNAJ w zakresie wymiany informacji o sytuacji powietrznej. Standard Link-11B został zaimplementowany w pełnym zakresie w obiektach systemu PRZELOT-SAMOC. PIT‑RADWAR nadal prowadzi pracę nad implementacją standardów Link. Obecnie prace skupiają się głownie nad implementacją Link-16/JREAP-C w systemach OPL i lotnictwie.

Około roku 2000 zapoczątkowano realizację dwóch kolejnych systemów: pierwszy pod kryptonimem PRZELOT‑SAMOC dla Wojsk OPL, a drugi pod kryptonimem PRZELOT-WOC dla Wojsk Lotniczych. Celem tych dwóch programów było uzupełnienie systemu OP o komponenty odpowiadające za wykorzystanie aktywnych środków walki. Brak finasowania spowodował, że z realizacji programu PRZELOT-WOC zrezygnowano po etapie projektu koncepcyjnego, a program PRZELOT-SAMOC został podzielono na dwa etapy – pierwszy obejmujący realizację obiektu automatyzacji dla Stanowiska Dowodzenia (SD) dywizjonu rakietowego (dr) KRUG (obiekt SDP-10K) zakończony w 2005 r. i drugi obejmujący zasadniczą część programu - obiekty automatyzacji dla Stanowiska Dowodzenia Brygady Rakietowej Obrony Powietrznej (obiekt SDP-20) i Stanowiska Dowodzenia dywizjonu rakietowego NEWA (obiekt SDP-10N) zakończone w 2008 r.

Jak wspomniano wcześniej, brak systemów PRZELOT-WOC i PRZELOT SAMOC systemie powodował, że opracowany w ramach systemu DUNAJ obiekt CDS-20 (Centrum Dowodzenia Sektora), którego zadaniem było wspomaganie kierowania środkami walki, nie mógł być wykorzystywany w pracy bojowej i nie był rozwijany synchronicznie z pozostałymi elementami systemu DUNAJ, co w efekcie spowodowało rezygnację z jego użycia w systemie.

Program PRZELOT-SAMOC obejmował automatyzację dwóch szczebli dowodzenia – Brygady Rakietowej (BR) i dwóch typów dywizjonów rakietowych (dr) wyposażonych w Przeciwlotnicze Zestawy Rakietowe (PZR) KRUG i NEWA-SC.

Na szczebel BR opracowano obiekt automatyzacji SDP-20 przeznaczony dla SD OPL (SAMOC^[9]), stanowisko dowodzenia, z którego dowódca BR (lub osoba przez niego wyznaczona) dowodzi podporządkowanymi jednostkami ogniowymi zgodnie z otrzymanymi zadaniami i uprawnieniami oraz kieruje walką operacyjnie podporządkowanych pododdziałów przeciwlotniczych w nakazanym obszarze odpowiedzialności - strefie MEZ (ang. Missile Engagement Zone).

Obiekt SDP-20 zapewnia zautomatyzowane stanowiska pracy dla osób funkcyjnych biorących udział w dowodzeniu i kierowaniu wojskami i środkami walki na szczeblu BR. Obiekt SDP-20 posiada w swoim składzie Kabiny Kierowania Walką (patrzRysunek 5) i Kabiny Operacyjne. Na bazie tych kabin można wyposażyć zasadnicze i zapasowe stanowiska dowodzenia Brygady Rakietowej. Przy organizacji SD wykorzystywane są dodatkowe stanowiska pracy sprzężone z kabinami umieszczone w dodatkowych rozkładanych kontenerach tzw. Mobilnych Modułach Stanowisk Dowodzenia (MMSD).

Obiekt SDP-20 zapewnia:

• współpracę z obiektem nadrzędnym (ODN wyposażonym w obiekt CSI);
• opracowanie informacji o sytuacji powietrznej (LAP^[10]) na podstawie informacji z radarów (dołączonych lokalnie lub do sieci WAN OPL);
• kierowanie podległymi naziemnymi środkami walki (GBAD^[11]). W tej liczbie mogą występować:

o   dywizjony rakietowe wyposażone w obiekty SDP-10N posiadające trzy PZR NEWA-S.C.,

o   pojedyncze PZR NEWA-S.C.,

o   baterie bardzo krótkiego zasięgu V-SHORAD^[12] np. PSRA PILICA,

a w przyszłości po uzupełnieniach zrealizowanych w ramach programów WISŁA i NAREW:

o   baterie Zestawów Rakietowych Obrony Powietrznej Wisła (poprzez IBCS)

o   baterie Zestawów Rakietowych Obrony Powietrznej Wisła/Narew (poprzez IBCS).

• zapewnia interoperacyjność z systemami dowodzenia natowskimi jednostkami GBAD i pracę w sojuszniczym ugrupowaniu GBAD dzięki implementacji natowskich standardów Link-11B i zapewnieniu pracy w sieci Link-16 (JREAP-C) jako pełnoprawny uczestnik klasy C2.

Obiekt SDP-10K był przeznaczony dla dywizjonu PZR KRUG, jego badania państwowe zakończyły się wynikiem pozytywnym w 2005 roku. Obiekt został wdrożony do wojsk. Został wycofany z eksploatacji wraz z zestawami PZR Krug w roku 2011.

Obiekt SDP-10N jest dedykowany dla SD dywizjonu rakietowego wyposażonego w PZR Newa-SC. Do SDP-10N można dołączyć do czterech (typowo trzy) kabin dowodzenia KDN zestawu Newa. Obiekt SDP-10N korzysta z tego samego oprogramowania co obiekt SDP-20.

Te wszystkie komponenty systemu OPL współpracują miedzy sobą poprzez sieć IP-WAN (zwaną „WAN‑OPL"), która funkcjonuje wg tych samych reguł co sieć IP WAN „OP-NET", której filozofia została opisana wcześniej przy okazji systemu DUNAJ. Sieć WAN-OPL może być integralną częścią sieci „OP‑NET" lub pracować jako sieć autonomiczna (w przypadku decentralizacji systemu).

Sieć WAN-OPL jest siecią mobilną i korzysta z sieci podkładowej zbudowanej z wykorzystaniem aparatowni RWŁC (Ruchomy Węzeł Łączności Cyfrowej). Relacje dalsze są realizowane przy wykorzystaniu radiolinii R-450A, a relacje bliskie (do 7-10 km) przy wykorzystaniu radiostacji IP typu R‑450C. Dzięki tym rozwiązaniom technicznym oraz architekturze systemu informatycznego stworzono realne możliwości osiągania zdolności sieciocentryczne systemu OPL prowadzące do – tzn. zwiększenia zdolności/efektywności bojowej.

Obiekt SDP-20 (SAMOC) zapewnia wspomaganie dowodzenia i kierowania podległymi naziemnymi środkami OP. W systemie, w jego oprogramowaniu, można wydzielić następujące moduły programowe (patrz Rysunek 6):

• Moduł planowania i przygotowania działań realizujący następujące zadania:

o   Wsparcie przygotowania planu obrony klastra;

o   Przetwarzanie rozkazów i meldunków sformalizowanych;

o   Planowanie rozmieszczenia elementów ugrupowania, cyfrowa analiza terenu, analiza pokryć radarowych.

• Moduł kierowania walką realizujący następujące zadania:

o   Produkcja lokalnego obrazu sytuacji powietrznej;

o   Ocena zagrożenia i rekomendacja;

o   Przydział środków walki do realizacji zadań odziaływania na cele powietrzne;

o   Monitorowanie sytuacji oraz statusu realizacji zadań;

o   Monitorowanie stanu sił i środków;

Realizacja przedstawionych zadań wymaga współpracy obiektu SDP-20 z jego otoczeniem:

• obiektem SD szczebla nadrzędnego;
• sensorami radiolokacyjnymi;
• podporządkowanymi obiektami kierowania ogniem.

Ta współpraca, jak już wspomniano, jest realizowana poprzez sieć IP WAN „WAN-OPL" lub dedykowane interfejsy obsługujące standard Link-16/JREAP, Link-11B (dotyczy współpracy ze szczeblem nadrzędnym i podporządkowanymi obiektami kierowania ogniem).

Na bazie rozwiązań programów PRZELOT-SAMOC i ŁOWCZA w PIT-RADWAR zostało opracowane oprogramowania dla Stanowiska Dowodzenia (SD) pododdziału OPL bardzo krótkiego zasięgu tzw. V-SHORAD. Temat ten był realizowany z środków własnych PIT-RADWAR i uzyskanych w ramach dokapitalizowania z Ministerstwa Skarbu Państwa. Wyniki pracy zostały wdrożone w ramach projektu PSRA PILICA^[13], który był realizowany przez konsorcjum PGZ, ZM Tarnów i PIT-RADWAR. Efektorami PSRA Pilica jest jednostka ogniowa zbudowana na bazie armaty 23 mm (ZU-23-2) uzupełniona o wyrzutnie rakiet Grom/Piorun (patrz Rysunek 7). SD dywizjonu rakietowo artyleryjskiego zabudowano na podwoziu Jelcz (patrz Rysunek 8). SD wyposażone jest w dwa zautomatyzowane stanowiska pracy – jedno dla strzelającego (wskazanie obiektów do zwalczania wraz ze wskazaniem sposobu zwalczania armata/rakieta), drugie dla d-cy (zapewniające komunikację ze szczeblem nadrzędnym i realizację funkcji planistycznych). SD współpracuje z efektorami przy wykorzystaniu łącz radiowych (radiostacja R-450C firmy Transbit) lub światłowodowych.

Stanowisko Dowodzenia może współpracować z efektorami opracowanymi w projekcie Pilica, ale również z innymi, które PIT-RADWAR opracował wspólnie z ZM Tarnów i HSW - Armata 35 mm oraz z ZM Mesko - SPZR POPRAD^[14] wykorzystujący rakiety Grom i Piorun (patrz Rysunek 9).

Dzisiejszy polski system dowodzenia obroną powietrzną oparty jest o zintegrowany (przy wykorzystaniu sieci „OP-NET"), zautomatyzowany system teleinformatyczny, na który składają się:

• polskie radary opracowane przez PIT-RADWAR:

o   rodzina radarów N-12 (N-12ME, N-12M)

o   radary TRS-15 ODRA,

o   radary lotniskowe AVIA-W,

o   radary dla OPL (SOŁA, N-21, N-22)

• polskie systemy C2 opracowane przez PIT-RADWAR:

o   DUNAJ (obiekty CRR-20 i ZPR-10 oraz terminale TL-1 i AWD-10),

o   PRZELOT-SAMOC (obiekty SDP-20 i SDP-10N),

o   ŁOWCZA/REGA,

o   ORZYC (terminal TU-20L)

• komponenty dostarczone w ramach natowskich programów wspierających dostosowanie polskiego systemu do wymagań NATO:

o   radary RAT-31DL,

o   systemy C2:

§  CSI^[15] (kierowanie środkami walki, interfejs do sieci LINK-16, konwerter protokołów),

§  ICC^[16] (planowanie działań).

System OP składa się z dwóch podsystemów – Podsystemu Rozpoznania Radiolokacyjnego i Podsystemu Kierowania Środkami Walki. Pierwszy odpowiada za opracowanie informacji RAP (ang. Recognised Air Picture), a drugi odpowiada za koordynację wykorzystania środków ogniowych w celu zwalczania naruszycieli polskiej przestrzeni powietrznej (patrz Rysunek 10).

System DUNAJ był pierwszym systemem, który zainicjował budowę nowoczesnego systemu automatyzacji obrony powietrznej. Wykonawcą części sprzętowej systemu był PIT, a obecnie utrzymuje ją w sprawności PIT‑RADWAR. Oprogramowanie komponentów systemu podlega procesowi ciągłego rozwoju przez PIT‑RADWAR (węzły sieci OP-NET, adaptery interfejsów Link-16, Link-11B i Link‑1, punkt naprowadzania obiektu CRR-20 i obiekt ZPR-10) oraz przy współpracy z FILBICO Sp. z o.o. (obiekt CRR‑20 w zakresie funkcjonalności opracowania RAP).

System DUNAJ dwukrotnie został oceniany przez NATO – pierwszy raz w ramach programu „ACCS Alternative Study" w latach 2007-2008 i drugi raz w ramach obecnie realizowanego programu „AirC2 Systems Analysis of Alternatives". Należy podkreślić, że system, który został zrealizowany w Polsce przez polska firmę PIT‑RADWAR S.A., został w każdym z tych projektów wysoko oceniony – w pierwszym został wytypowany jako jeden z trzech najlepszych rozwiązań w Europie (wtedy jeszcze z obiektem CDS-20 w składzie), w drugim przeszedł pozytywnie trzy etapy oceny. Nie wszedł do następnego etapu oceny ze względu na brak funkcjonalności kierowania środkami walki (o czym wspomniano wcześniej). Warto jednak podkreślić, że to funkcjonujące w polskim systemie OP rozwiązanie zostało wysoko ocenione dzięki:

• nowatorskiemu rozwiązaniu integracji z wykorzystaniem sieci IP-WAN;
• elastycznym rozwiązaniom w zakresie przetwarzania informacji o sytuacji powietrznej,
• integracji informacji wymienianych w domenie czasu nierzeczywistego (dokumenty AdatP-3) ze zobrazowaniem informacji w domenie czasu rzeczywistego,
• zawansowanej implementacji LINK-16/JREAP^[17].

Andrzej Kątcki, PIT-RADWAR S.A.

Artykuł sponsorowany, partner publikacji PGZ S.A.

PRZYPISY:

^[1] ASTERIX - All-purpose STructured EUROCONTROL Surveillance Information EXchange – format protokołu przeznaczony do wymiany informacji o sytuacji powietrznej opracowany dla potrzeb EUROCONTROL. Pierwsze zastosowanie tego protokołu w Polsce nastąpiło w ramach prac związanych z integracją polskich radarów z systemem ASOC

^[2] SAMOC – Surface to Air Mission Operation Centre – stanowisko dowodzenia OPL szczebla Brygady

^[3] WOC – Wing Operation Centre – stanowisko dowodzenia lotnictwem w Bazie Lotniczej

^[4] ACCS – Air Command and Control System – natowski program realizacji systemu OP dla Europy realizowany od roku 1996

^[5] CKOP – Centrum Koordynacji Operacji Powietrznych – odpowiednik AOCC

^[6] AOCC – Air Operations Coordination Centre – Centrum Koordynacji Operacji Powietrznych – wsparcia lotniczego dla działań WLąd i MW

^[7] OP-NET - Obrony Powietrznej NETwork sieć IP-WAN zbudowana dla integracji komponentów systemu OP

^[8] HMI - Human Machine Interface

^[9] SAMOC – Surface to Air Mission Operations Centre

^[10] LAP – Local Air Picture

^[11] GBAD – Grond Based Air Defence

^[12] V-SHORAD – ang. Very SHOrt Range Air Defence – zestaw OPL bardzo krótkiego zasięgu

^[13] PSRA PILICA – Przeciwlotniczy System Rakietowo Artyleryjski bardzo krótkiego zasięgu

^[14] SPZR POPRAD – Samodzielny Przeciwlotniczy Zestaw Rakietowy

^[15] CSI - CRC System Interface

^[16] ICC - Integrated Command and Control Software for Air Operations

^[17] JREAP – ang. Joint Range Extension Applications Protocol - protokół zgodny ze, STANAG 5518, umożliwiający przesyłanie taktycznych komunikatów danych (np. serii J/LINK16) przez sieci dalekiego zasięgu, np. łącza satelitarne wersja A, sieci WAN wersja C