Prace studyjne, badania funkcjonalne i analiza uwarunkowań eksploatacyjnych systemu śledzenia statków dalekiego zasięgu LRIT

Transkrypt

1 Samodzielna Pracownia Radiokomunikacji Morskiej w Gdańsku (P-8) Prace studyjne, badania funkcjonalne i analiza uwarunkowań eksploatacyjnych systemu śledzenia statków dalekiego zasięgu LRIT Praca nr Gdańsk, grudzień 2007

2 Prace studyjne, badania funkcjonalne i analiza uwarunkowań eksploatacyjnych systemu śledzenia statków dalekiego zasięgu LRIT Praca nr Słowa kluczowe: radiokomunikacja morska, ochrona żeglugi, bezpieczeństwo na morzu, LRIT, maritime security, maritime safety. Kierownik pracy: Wykonawcy pracy: dr inż. Jerzy Żurek dr inż. Rafał Niski dr inż. Jacek Stefański Kierownik Zakładu: dr inż. Rafał Niski Copyright by Instytut Łączności, Gdańsk 2007

3 Spis treści Spis akronimów Wprowadzenie Rys historyczny ustaleń międzynarodowych Architektura systemu LRIT Specyfikacja techniczna systemu LRIT Międzynarodowe Centrum Wymiany Danych LRIT (IDE) [10, 12] Architektura IDE Przetwarzanie i obsługa wiadomości Interfejsy zewnętrzne Dziennik LRIT Wydajność IDE Międzynarodowe Centrum Danych LRIT (IDC) [10, 13] Architektura IDC Interfejsy zewnętrzne Definicje użytkowników System łączności w sieci systemu LRIT [10, 14] Przegląd i typy wiadomości Strategia Protokołów Komunikacyjnych Bezpieczeństwo danych wewnątrz sieci LRIT Specyfikacja protokołów do budowy systemu testowania sieci LRIT i testowania procesów integracji nowych Centrów Danych LRIT [10, 15] Wytyczne dot. budowy i utrzymywania Planu Dystrybucji Danych [10] Standard naliczania kosztów i tworzenia bilingów w systemie LRIT [10, 16] Scenariusze naliczania opłat i przepływów finansowych w systemie LRIT Koszty stałe utrzymania systemu LRIT Podsumowanie i wnioski Załącznik Załącznik Załącznik Bibliografia

4 Spis akronimów ASP Application Service Provider CG Contracting Government CSP Communication Service Provider DC LRIT Data Centre DDP LRIT Data Distribution Plan HMAC Hash Message Authentication Code IDC International LRIT Data Centre IDE International LRIT Data Exchange LES Land Earth Station MMSI Maritime Mobile Service Identity NDC National Data Centre OASIS Organization for the Advancement of Structured Information Standards PKI Public Key Encryption R/CDC Regional/Cooperative Data Centre RFP Request for Proposal SAR Search and Rescue SAR SURPIC Search and Rescue Surface Picture SOAP Simple Object Access Protocol SOLAS International Convention for the Safety of Life at Sea SSL Secure Sockets Layer TLS Transport Layer Security VPN Virtual Private Network WS Web Service 4

5 1. Wprowadzenie Żegluga po morzach i oceanach zawsze wiązała się z dwoma rodzajami zagrożeń dla statków i żeglujących na nich osób zagrożeniem ze strony natury oraz zagrożeniem ze strony innych osób. Statki tonęły w wyniku przyczyn naturalnych takich jak sztormy, błędy w sztuce nawigacyjnej (wynikające często z bardzo trudnego i nieznanego środowiska np. wejścia na skały czy mielizny) czy wreszcie awarie. Od zarania, statki były również (abstrahując od wojen) przedmiotem ataków rozmaitego rodzaju piratów czy korsarzy. W czasach nam współczesnych, a szczególności w końcu XX i na początku XXI wieku, do piratów i korsarzy dołączyli piraci realizujący czysto polityczne i ideologiczne cele terroryści. Po II Wojnie Światowej całość problematyki związanej z żeglugą międzynarodową jest omawiana i regulowana na forum międzynarodowym w oparciu o strukturę United Nations (UN) Organizacji Narodów Zjednoczonych (ONZ). W tym celu została powołana specjalizowana organizacja agencyjna UN z siedzibą w Londynie, na początku pod nazwą IMCO (Intergovernmental Maritime Consultative Organization), która następnie zmieniła nazwę na IMO (International Maritime Organization). W drugiej połowie lat siedemdziesiątych ubiegłego wieku międzynarodowa wspólnota żeglugowa, pod przewodnictwem IMO, podjęła działania, których celem było wypracowanie sposobów zapobiegania zjawiskom przestępstw na morzu, takim jak np. nielegalne przejęcia statków oraz ich ładunków. W wyniku tych prac IMO już w roku 1984 rozpoczęła prowadzenie monitoringu aktów piractwa i zbrojnych rabunków na morzu. W wyniku tej działalności do tej pory zebrano ponad 3500 raportów dotyczących napadów morskich i zaboru ładunków lub wręcz statków. W wielu z tych przypadków doszło niestety także do utraty życia członków załóg i pasażerów. Z analizy tych raportów wynika, że przemoc na morzu ciągle wzrasta. W niniejszym opracowaniu zaprezentowano rysy historyczne ustaleń międzynarodowych dotyczących tworzenia standardu systemu śledzenia statków dalekiego zasięgu LRIT (Long Range Identification and Tracking of ships) oraz jego ostateczną architekturę. Przedstawiono również szczegółową strukturę poszczególnych elementów systemu. Zaprezentowano i omówiono strukturę wiadomości przesyłanych w systemie, struktury logiczne przepływu i przechowywania informacji LRIT, autoryzacji użytkowników systemu, rejestrowania i bilingu oraz rodzaj i charakter łącz telekomunikacyjnych w systemie. Poruszono również problematykę bezpieczeństwa transmisji wiadomości LRIT w budowanym systemie. W podsumowaniu poddano krytycznej ocenie standard techniczny systemu i zwrócono uwagę na istotne elementy systemu nie objęte standardem. W załączniku 1 przedstawiono formaty wiadomości w systemie LRIT, natomiast załączniki 2 i 3 zawierają wydruki recenzowanych artykułów opublikowanych w Zeszytach Naukowych Wydziału Elektroniki, Telekomunikacji i Informatyki Politechniki Gdańskiej i Akademii Marynarki Wojennej w Gdyni. 5

6 2. Rys historyczny ustaleń międzynarodowych Za pierwszy zarejestrowany, od momentu powołania IMO, akt terroryzmu na morzu oficjalnie uznaje się porwanie w 1985 roku włoskiego statku pasażerskiego Achille Lauro, kiedy to zginął jeden z pasażerów. Zdarzenie to spowodowało rozpoczęcie przez IMO, pod koniec 1986 roku, prac nad przygotowaniem międzynarodowej konwencji dotyczącej ochrony żeglugi (maritime security). W rezultacie tego na początku 1988 roku podpisano w Rzymie konwencję zatytułowaną: Convention for the Suppression of Unlawful Acts Against the Safety of Maritime Navigation, która w skrócie nosi nazwę Konwencja SUA (Suppression of Unlawful Acts). Punktem zasadniczego zwrotu w działaniach IMO i międzynarodowej wspólnoty żeglugowej w obszarze ochrony żeglugi stały się wydarzenia z 11 września 2001 roku. Już 20 listopada 2001 roku Zgromadzenie Ogólne IMO przyjmuje rezolucję A.924(22) zatytułowaną: Review of measures and procedures to prevent acts of terrorism which threaten the security of passengers and crews and the safety of ships. Równocześnie IMO powołała Maritime Safety Committee (MSC) Intersessional Working Group on Maritime Security, która pierwsze swoje posiedzenie odbyła w dniach od 11 do15 lutego 2002 roku. Zadaniem tej grupy roboczej było przygotowanie 75 sesji Maritime Safety Committee (MSC75) Komitetu Bezpieczeństwa na Morzu oraz merytoryczne przygotowania do Konferencji Dyplomatycznej dot. Ochrony Żeglugi (Diplomatic Conference on Maritime Security). W lutym 2002 roku Podkomitet IMO COMSAR (Communication Search and Rescue) na swojej 6 sesji zwrócił się do ITU WP8B, aby dokonała analizy technicznej dot. przydatności systemu AIS (Automatic Identification System) do budowy systemu śledzenia statków. W maju tego samego roku Komitet MSC zwraca się do ITU WP8B, aby dokonała analizy możliwości wykorzystania funkcji odpytywania (ang. polling) w systemie Inmarsat C lub danych AIS w celu zapewniania śledzenia statków, a także ewentualnych modyfikacji radiostacji MF/HF (sprzętu GMDSS) oraz AIS w celu wykorzystania ich do transmisji danych do określonych instytucji na lądzie, włącznie z instytucjami SAR. W dniach od 9 do 13 grudnia 2002 roku odbyła się w siedzibie IMO w Londynie Konferencja Dyplomatyczna dot. ochrony żeglugi (Maritime Security). Ustalenia tej konferencji stanowią podstawę wszystkich dalszych działań IMO w zakresie Maritime Security. Między innymi konferencja ta przyjęła dwie rezolucje dot. systemu LRIT. W Rezolucjach Nr 3 i Nr 10 państwa sygnatariusze zobowiązały się do opracowania standardu systemu śledzenia statków oraz wdrożenia i uruchomienia tego systemu na zasadach absolutnego priorytetu tak szybko jak to tylko możliwe. Komitet IMO MSC na sesji 76 (grudzień 2002) kieruje problematykę do Podkomitetu IMO COMSAR w celu jej dalszego opracowania. Podkomitet COMSAR podczas trwania swojej 7 sesji w dniach od 13 do 17 stycznia opracowuje pierwsze wymagania funkcjonalne i projekt standardów działania systemu LRIT. Propozycje te zostają przyjęte przez MSC na przełomie maja i czerwca 2003, podczas jego 77 sesji. W czasie tej sesji MSC powołuje również Korespondencyjną Grupę Roboczą MSC w celu dalszego opracowania efektów pracy Podkomitetu. W lutym 2004 roku COMSAR na sesji 8 opracowuje kolejną wersję wymagań funkcjonalnych dla systemu LRIT i rekomenduje Komitetowi MSC jednoznaczne rozdzielenie systemów AIS i LRIT. W maju 2004 Komitet na sesji MSC78 przyjmuje propozycje COMSAR i pracuje nad propozycją poprawek do konwencji SOLAS, które formalnie powołałyby do życia system LRIT. W grudniu 2004 odbywa się kolejna 79 sesja MSC, na której, na wniosek Unii Europejskiej, zostaje wyrażona zgoda na używanie wiadomości LRIT przez służby SAR oraz trwają dalsze prace nad poprawkami do konwencji 6

7 SOLAS wprowadzającymi ten system. Na sesji 9, w lutym roku 2005, Podkomitet COMSAR odbył intensywną dyskusję i pracę nad rozwojem standardu oraz poprawek do Konwencji SOLAS dot. LRIT [1]. Na tym spotkaniu została powołana również korespondencyjna grupa robocza COMSAR, której zadaniem było rozwiązanie jak największej liczby problemów i przesłania raportu ze swoich prac na sesję COMSAR10. W maju 2005 roku na sesji MSC80 prowadzono dalszą intensywną dyskusję i pracę nad poprawkami do konwencji SOLAS wprowadzającymi system LRIT. Komitet zwołał ponownie międzysesyjną grupę roboczą MSC ds. LRIT (MSC ISWG on LRIT). Grupa ta na swoim spotkaniu w październiku 2005 uzgodniła treść zapisów do konwencji SOLAS wprowadzających legalnie system LRIT. Na przełomie lutego i marca 2006 roku, w wyniku dwutygodniowych prac, najpierw Grupy Roboczej COMSAR ds. LRIT, a następnie całego Podkomitetu udało się ustalić architekturę systemu LRIT oraz ustalić jego funkcjonalność, co było rewolucyjnym postępem w procesie tworzenia tak złożonego, globalnego systemu. Pozostało jednak do opracowania wiele szczegółów technicznych. Punktem zwrotnym, z punktu widzenia politycznego było przyjęcie przez Komitet MSC w maju 2006 roku, na swojej 81 sesji, trzech kluczowych Rezolucji, które formalnie powołały do życia system LRIT. Były to następujące rezolucje: RESOLUTION MSC.202(81) - Amendments to the International Convention for the Safety Of Life At Sea, 1974, Chapter V - Safety of Navigation [7], RESOLUTION MSC.210(81) - Performance standards and functional requirements for the Long-range Identification and Tracking of ships [8], RESOLUTION MSC.211(81) - Arrangements for the timely establishment of the Longrange Identification and Tracking system [9]. Ponadto Komitet powołał międzysesyjną grupę roboczą pod nazwą Ad Hoc Working Group on Engineering Aspects of LRIT. Zadaniem tej grupy jest opracowanie i przedstawienie zarówno Komitetowi MSC jak i Podkomitetowi COMSAR propozycji rozwiązań wszystkich istotnych problemów technicznych związanych z budową systemu LRIT. W okresie od czerwca do listopada 2006, Grupa odbyła 3 sesje i prowadziła intensywne prace korespondencyjne. W wyniku tych działań, na 82 sesji MSC, która odbyła się w Istambule na przełomie listopada i grudnia 2006, został przyjęty raport Grupy, który został rozpowszechniony jako list okólny MSC, oznaczony jako MSC.1/Circ.1219, zawierający Interim LRIT Technical Specifications and other matters. Komitet zatwierdził również plan czasowy fizycznego wdrożenia systemu. Wynika z niego, że do połowy 2008 roku powinny zostać zbudowane kluczowe elementy infrastruktury systemu, a od początku roku 2009 system LRIT powinien funkcjonować jako całość. Na tejże sesji MSC podjęto również długo przygotowywaną decyzję o wyborze organizacji nadzorującej budowę i funkcjonowanie LRIT. Przy zastrzeżeniu ze strony USA do tego zadania wybrano IMSO (International Mobile Satellite Organization). W lutym 2007 roku odbyło się kolejne spotkanie grupy Ad Hoc Working Group on Engineering Aspects of LRIT, której zadaniem jest ostateczne ustalenie szczegółów technicznych oraz 11 sesja Podkomitetu COMSAR [11]. Pracowano głównie nad kwestiami dostępu różnych podmiotów do systemu oraz nad systemem naliczania opłat. Wiele kwestii, zarówno organizacyjnych jak i technicznych, pozostało jednak nadal nierozstrzygniętych. Dalszej pracy wymagać jeszcze będzie np. sposób ochrony informacji w systemie. Dopracowania wymagać będą również elementy systemu, które już zostały zdefiniowane. Trwa cały czas korespondencyjna praca grupy Ad Hoc Working Group on Engineering 7

8 Aspects of LRIT. Postanowiono, że Grupa ta, do jesiennego posiedzenia Komitetu MSC83 spotka się jeszcze dwu lub trzykrotnie w celu jak najszybszego rozwiązania wielu problemów. 8

9 3. Architektura systemu LRIT Na sesji MSC80 po raz pierwszy zaproponowano architekturę systemu LRIT [5]. Była to propozycja złożona przez IMSO. Charakteryzowała się silnie scentralizowaną strukturą w sensie gromadzenia i przechowywania danych LRIT. Propozycja ta zakładała możliwości wykorzystania istniejących już narodowych i regionalnych systemów monitoringu statków (VMS Vessel Monitoring System). Struktura ta kładzie szczególny nacisk na rolę koordynatora LRIT. W toku prac propozycja IMSO ulegała silnej ewolucji. Wprowadzono m.in. dostarczycieli usług i rozdzielono dostarczycieli usług komunikacyjnych od dostarczycieli usług aplikacyjnych. Pierwszą propozycję architektury przedłożoną przez IMSO zaprezentowano na rys. 1. Rys. 1. Propozycja architektury systemy LRIT zgłoszona przez IMSO. Kolejna propozycja architektury systemu LRIT [2,5], która została zaakceptowana przez wszystkie państwa członkowskie IMO, była wynikiem intensywnych prac prowadzonych przez Grupę Roboczą LRIT Podkomitetu COMSAR na sesji COMSAR10 na przełomie lutego i marca 2006 roku. Architekturę tą zaprezentowano na rys. 2. Zasadnicza różnica w stosunku do propozycji IMSO polega na tym, że informacje LRIT nie są gromadzone w jednym miejscu w systemie, a centralną rolę pełni serwis indeksujący położenie rzeczywistych wiadomości w systemie realizowany przez Międzynarodowe Centrum Wymiany Danych (International LRIT Data Exchange). 9

10 Rys. 2. Architektura systemu LRIT zaakceptowana przez państwa członkowskie IMO. W toku opracowywania przyjętej architektury systemu, poprzez definiowanie poszczególnych jej elementów, szczegółowe opisywanie funkcjonalności oraz zależności pomiędzy poszczególnymi elementami w strukturze systemu, postanowiono o uproszczeniu architektury i uzyskaniu w ten sposób przejrzystości dla przyszłych potrzeb projektowych. Można tego było dokonać, gdyż rysunek przedstawiający architekturę stał się częścią dokumentu szczegółowo opisującego strukturę i funkcjonowanie systemu. Szczególnie ważne są elementy związane z audytem i kontrolą prawdziwości przesyłanych w systemie danych. W rezultacie Sekretariat IMO opublikował architekturę systemu zaprezentowaną na rys. 3 [3, 4, 6]. Jest to ostateczny kształt systemu LRIT i wszystkie dalsze prace dotyczące funkcjonowania i jego aspektów technicznych są prowadzone na podstawie przedstawionej poniżej architektury systemu. 10

11 Rys. 3. Ostateczna architektura systemu LRIT opublikowana przez Sekretariat IMO. 11

12 4. Specyfikacja techniczna systemu LRIT W wyniku prac Ad Hoc Working Group on Engineering Aspects of LRIT opracowano i na 82 sesji MSC zaakceptowano w formie Interim LRIT technical specifications [10] logiczną strukturę i strukturę przepływu danych w systemie. Definicję standardu technicznego systemu postanowiono w International LRIT Data Exchange i International Data Centre, które uznano za najistotniejsze elementy architektury systemu. W trakcie prac realizowanych w 2007 roku, dopracowano wcześniej zdefiniowane moduły specyfikacji technicznej systemu, stworzono moduł definiujący testowanie systemu, opracowano bardzo trudny moduł standardu technicznego dotyczący taryfikacji (bilingów) w systemie, zaproponowano elementy systemu zabezpieczania wiadomości LRIT poprzez zastosowanie mechanizmów kryptograficznych. Dokument stanowiący specyfikację techniczną systemu LRIT (LRIT technical specifications) na dzień dzisiejszy składa się z sześciu modułów [10, 12, 13, 14, 15, 16]: 1. specyfikacja techniczna Międzynarodowego Centrum Wymiany Danych LRIT (International LRIT Data Exchange), 2. specyfikacja techniczna Międzynarodowego Centrum Danych LRIT (International LRIT Data Centre), 3. specyfikacja techniczna systemu łączności w sieci systemu LRIT (Communications within the LRIT System network), 4. specyfikacja protokołów do budowy systemu testowania sieci LRIT i testowania procesów integracji nowych Centrów Danych LRIT (Protocols for the Development Testing of the LRIT System and for Testing of the Integration of a New LRIT Data Centres into the system), 5. wytyczne dot. budowy i utrzymywania Planu Dystrybucji Danych (Guidance on setting up and maintaining the Data Distribution Plan), 6. standard naliczania kosztów i tworzenia bilingów w systemie LRIT (LRIT Costing and Billing Standard). Dokumenty te obejmują bardzo szczegółowe zagadnienia a ich łączna objętość wraz z towarzyszącymi dokumentami roboczymi pozwala tylko na prezentację zasadniczych elementów standardu technicznego systemu Międzynarodowe Centrum Wymiany Danych LRIT (IDE) [10, 12] Międzynarodowe Centrum Wymiany Danych LRIT (IDE), z punktu widzenia teleinformatycznego ma być rodzajem sytemu indeksującego wiadomości (message handling service), który umożliwia wymianę wiadomości pomiędzy Centrami Danych LRIT oraz uprawnionymi użytkownikami systemu LRIT, w ramach ich uprawnień kieruje ruchem informacji przekazywanych pomiędzy Centrami Danych (DC). Komunikacja z Centrum odbywa się w standardzie TCP/IP. IDE musi archiwizować informacje o całym ruchu w swojej bazie danych określanej jako Dziennik LRIT (LRIT Journal). 12

13 Architektura IDE Ogólny schemat przepływu danych i tym samym struktury logicznej IDE zaprezentowano na rysunku 4. Rys. 4. Ogólny schemat przepływu danych w Międzynarodowym Centrum Wymiany Danych LRIT (IDE) Poszczególne bloki pokazane na rysunku 4 przedstawiają moduły funkcjonalne lub podsystemy dużego systemu, jakim jest IDE. Implementację IDE można przykładowo zrealizować w postaci szybkiego komputera z zainstalowanym wyspecjalizowanym oprogramowaniem IDE. Oprogramowanie to może składać się z różnych modułów takich jak moduł interfejsu Data Centre, moduł przetwarzania informacji, moduł nadzorujący QoS, itd Przetwarzanie i obsługa wiadomości W tej części standardu technicznego systemu zostały zdefiniowane różne rodzaje wiadomości LRIT, które mogą być przesyłane w systemie. W tabeli 2 zestawiono wszystkie wiadomości (wiadomości 1 do 12) i zaznaczono czy wiadomość jest przekazywana pomiędzy DC, czy też do wszystkich DC. Na rysunku 5 przedstawiono ogólny algorytm obsługi i przetwarzania wiadomości LRIT przez Międzynarodowe Centrum Wymiany Danych. 13

14 Tabela 1. Zestawienie wiadomości LRIT. Typ wiadom ości Nazwa wiadomości Periodic Position Report Polled Position Report SAR Position Report Opis wiadomości / Przeznaczenie TX RX Broadcast LRIT positional data (position report) messages Okresowy, regularny raport o pozycji statku DC2 IDE IDE DC1 Raport o pozycji statku jako rezultat DC2 IDE żądania pollingu IDE DC1 Raport o pozycji statku jako rezultat DCx IDE żądania SAR IDE DC1 No No No Ship Position Request SAR Poll Request SAR SURPIC Request Receipt message 8 DDP Update Oznaczenia: System Status message RDC or IDC issued Billing & Transaction LRIT request messages Umożliwienie DC żądania danych DC1 IDE pozycyjnych statków monitorowanych przez inne DC. IDE DC2 Specjalny polling statku. Odebrany od przepytującego DC i przekazany do DC DC1 IDE określonego statku przy użyciu MMSI. Może być wysyłany jednorazowo lub cyklicznie. IDE DC2 Przepytywanie w obszarze wysyłane do DC1 IDE wszystkich DC IDE DCx Other messages Umożliwia prowadzącemu DC potwierdzenie odbioru i przetwarzanie statusu wiadomości Request Message od żądającego DC. Procedura uaktualniania DDP przez serwer DDP kierowana do IDE. DC2 IDE DDP IDE DC1 DCx IDE Wysyłanie i odbiór przez IDE wiadomości IDE DCx statusowych co 30 minut do każdego i od każdego DC DCx IDE Okresowa comiesięczna wiadomość od RDC (IDC) do IDE zawierająca zestawienie transakcji i raport bilingowy. DC1 = żądające DC; DC2 = dostarczające DC; DCx = wszystkie DC; RDC1 = regionalne lub kooperujące DC RDC1 (IDC) IDE No No Yes No Nie routowane przez IDE Yes No 14

15 Rys. 5. Ogólny algorytm obsługi i przetwarzania wiadomości LRIT przez Międzynarodowe Centrum Wymiany Danych (IDE) Interfejsy zewnętrzne Kolejnym bardzo ważnym elementem Międzynarodowego Centrum Wymiany Danych LRIT, są funkcjonalnie procedury przesyłania poszczególnych wiadomości LRIT, interfejs 15

16 komunikacyjny z Planem Dystrybucji Danych LRIT (LRIT Data Distriburion Plan DDP), monitorowanie jakości działania Centrum (QoS) oraz interfejs administracyjny dla całego systemu. Wymagania stawiane interfejsowi komunikacyjnemu z Planem Dystrybucji Danych LRIT mówią o konieczności utrzymywania przez IDE bezpiecznego połączenia komunikacyjnego do serwera DDP bazując na zabezpieczonych protokołach komunikacyjnych. Wymagania dotyczące monitorowania jakości usług QoS wymuszają na IDE nadzór nad wszystkimi połączeniami komunikacyjnymi do wszystkich DC oraz zapewnienie operatorowi IDE i koordynatorowi LRIT dostępu do zarządzania, rozliczania oraz danych technicznych i operacyjnych, w celu umożliwienia oceny wydajności IDE oraz zapewnienia im wymaganego poziomu niezawodności, nadzoru i osiągalności. Interfejs administracyjny IDE powinien zapewnić zewnętrznym użytkownikom możliwość połączenia z IDE, poprzez bezpieczne łącze internetowe i wykonania prostych zadań administracyjnych. Odpowiedzialność za powoływanie użytkowników zewnętrznych administracyjnego interfejsu IDE i przyznawanie im dostępu do wybranych funkcji administracyjnych IDE leży po stronie Koordynatora LRIT. IDE powinno mieć zdolność zezwalania użytkownikom zewnętrznym na zrealizowanie połączeń z systemem IDE i wykonanie następujących zadań: zapytanie skierowane do Dziennika LRIT o specyficzną wiadomość LRIT, zapytanie IDE o raporty bilingowe lub raporty z auditów, zapytanie IDE o listę wszystkich DC połączonych z IDE, zapytanie IDE o statystykę sieci (szybkość przesyłu danych, błędne pakiety itp.) dla wszystkich lub określonych połączeń komunikacyjnych, zapytanie IDE o listę błędów lub anomalii, które IDE wykryło w danym okresie czasu, zapytanie IDE o rezultaty testów diagnostycznych, zapytanie IDE o informację odnoszącą się do oprogramowania działającego w IDE (np. numer wersji itp.). IDE powinno zapewniać dostęp do informacji bazy danych lub Dziennika LRIT tylko zgodnie ze wskazówkami dostarczonymi przez Koordynatora LRIT. Każdy dostęp lub udostępnienie informacji powinno zostać odnotowane, w celu kontrolowania wprowadzonych zmian Dziennik LRIT Zgodnie z Rezolucją MSC.210(81), IDE powinno automatycznie utrzymywać bazę danych jako Dziennik LRIT zawierający jedynie nagłówki wiadomości. Zadaniem Dziennika jest umożliwienie IDE śledzenia, zapisywania i archiwizowania identyfikatorów wiadomości w celu wspomagania audytów i tworzenia statystyk, obsługi i dystrybucji wiadomości oraz informacji o kosztach. Wiadomości zapisywane w Dzienniku muszą posiadać specjalny format uwzględniający tzw. znaczniki czasowe (tabela 2). IDE powinno również prowadzić archiwum Dzienników, które umożliwi szybkie odnalezienie w nim danych, z ostatniego roku. Zarchiwizowany Dziennik powinien zawierać kompletny rekord aktywności IDE pomiędzy dwoma następującymi po sobie rocznymi auditami. 16

17 Tabela 2. Format zapisu w Dzienniku LRIT. Parametr Rx time stamp Tx time stamp Message contents Pole danych Czas (wg UTC) odebrania wiadomości. Niedostępny dla wiadomości tylko nadawanych przez IDE (wiadomość 9, 11) i nie routowanych. Czas (wg UTC) nadania wiadomości (przekazywany do odpowiedniego DC). Niedostępny dla wiadomości tylko odbieranych przez IDE (wiadomość 12, 8) i nie routowanych Kompletna zawartość wiadomości z wyłączeniem parametrów wyposażenia statku z wiadomości 1, 2 i Wydajność IDE W ostatniej części tego modułu standardu opisano ogólne parametry działania IDE, takie jak opóźnienia w przesyłaniu wiadomości, dostępność, niezawodność, możliwości rozbudowy. Zdecydowano, że maksymalne opóźnienie w przesłaniu wiadomości może wynosić 30 sekund, IDE musi być zdolne do przetwarzania co najmniej 100 wiadomości LRIT na sekundę oraz do realizacji połączeń z 1000 Centrów danych LRIT. Ponadto IDE musi być dostępne przez 7 dni w tygodniu, 24 godziny na dobę z niezawodnością lepszą niż 99,9% na tydzień. Zakłada się, że niezawodność działania w ciągu roku będzie lepsza niż 95%. Ponadto wyposażenie IDE powinno być tak zaprojektowane, aby główne jego części mogły być łatwo zastępowalne, bez złożonej kalibracji lub ponownego dopasowania oraz aby było łatwo dostępne dla inspekcji i nadzoru. Oprogramowanie IDE powinno posiadać możliwość łatwego uaktualniania, w tym również rozszerzania jego funkcji, za pomocą standardowych bezpiecznych połączeń internetowych Międzynarodowe Centrum Danych LRIT (IDC) [10, 13] Funkcjonalności Międzynarodowego Centrum Danych LRIT (International LRIT Data Centre IDC) została narzucona Rezolucją MSC.210(81). Zgodnie z tymi wytycznymi wyposażenie statkowe powinno w sposób automatyczny i bez interwencji obsługi statku przesyłać do IDC, w 6-cio godzinnych odstępach czasowych, pozycję statku, dane identyfikacyjne i znaczniki czasu oraz zapewnić funkcjonalność określoną w tabeli 3. IDC powinno być w stanie przetworzyć dane z statków podlegających Konwencji SOLAS. Zakładając, że każdy z nich przesyła 4 raporty na dobę, w rezultacie otrzymujemy raportów na dzień. Pojemność systemu, w sensie zdolności odbioru i przechowywania raportów LRIT, powinna być dostatecznie duża, tak aby zapewnić długoterminowe archiwizowanie zgodnie z odpowiednimi wymaganiami IMO (min. rok). 17

18 Tabela 3. Dane nadawane przez statki w raporcie LRIT. Parametry Shipborne equipment Identifier Positional data Time Stamp 1 Komentarz Identyfikator stosowany przez wyposażenie statkowe. Pozycja GNSS statku (szerokość i długość geograficzna wg WGS 84). Wyposażenie powinno transmitować pozycje statku, zgodnie z regulacją SOLAS V/19-1, bez interwencji ludzkiej na pokładzie. Raportowanie pozycji na żądanie: Wyposażenie powinno odpowiedzieć na prośbę transmisji informacji LRIT na żądanie bez interwencji ludzkiej na pokładzie, niezależnie od lokalizacji statku. Raportowanie pozycji wstępnie planowane: Wyposażenie powinno być zdalnie rekonfigurowane, tak, aby umożliwić zmianę częstotliwości transmisji informacji LRIT do Centrum Danych LRIT, bez interwencji ludzkiej na pokładzie, niezależnie od lokalizacji statku, w przedziale od 15 minut do 6 godzin. Wyposażenie powinno transmitować datę i czas (wg UTC) skojarzone z pozycją GNSS wraz z każdą przesyłaną informacją LRIT Architektura IDC Na rys 6. przedstawiono ogólny schemat przepływu danych w Centrum i tym samym jego strukturę logiczną. Ogólne wymagania funkcjonalne Międzynarodowego Centrum Danych LRIT (IDC) dotyczą odbioru, magazynowania i rozpowszechniania informacji LRIT. Zgodnie z nimi IDC powinno: sprawdzać komunikaty i zapewniać bezpieczeństwo danych stosując metody takie jak autoryzacja, identyfikacja, poufność i integralność, utrzymywać rekordy statków które transmitują informacje LRIT do IDC, obejmujące: nazwę statku, numer identyfikacyjny statku IMO, znak wywołania, flagę państwa statku, nr MMSI oraz aktualny odstęp czasu raportowania, utrzymywać aktualną listę statków nietransmitujących dłużej danych do IDC (np. w związku ze zmianą flagi lub zakończenia usługi). Centrum IDC powinno ponadto uzupełnić powyższe informacje o datę i czas (wg. UTC) oraz Administracje, pod której flagą statek był oficjalnie upoważniony do pływania. IDC powinno również zapewniać, stosując odpowiedni sprzęt i oprogramowanie, aby informacje LRIT były: archiwizowane w regularnych odstępach czasu, magazynowane i dostępne tak szybko jak to możliwe, dla zapewnienia ciągłości usługi. Ponadto IDC powinno utrzymywać listę przyłączonych do Centrum Danych providerów ASP oraz statków obsługiwanych przez każdego z ASP. Wymagania funkcjonalne dotyczące interfejsu dostarczyciela aplikacji (ASP Interface Function), mówią o tym, że IDC powinno przetwarzać informacje LRIT przychodzące z ASP i wysyłać żądania wiadomości LRIT i wiadomości konfiguracyjne do ASP. Ponadto IDC powinno przyjmować informacje LRIT od statków, przetwarzać wiadomości pozycyjne przedstawione w tabeli 4, wykonywać żądania okresowego przepytywania (pollingu) informacji LRIT oraz przetwarzać wiadomości żądania podania pozycji. 18

19 Rys. 6. Ogólny schemat przepływu danych w Międzynarodowym Centrum Danych LRIT Oznaczenia: REQ = Request; FS = Flag State; PS= Port State; CS = Coastal State Z kolei wymagania dotyczące funkcji przetwarzania i przechowywania danych LRIT (LRIT Information Storage and Handling Function), wymuszają na IDC konieczność archiwizowania informacji LRIT pochodzących od statków i transmitowanych do IDC, przynajmniej raz w roku, w celu przygotowania rocznego raportu dla Koordynatora LRIT. IDC powinno przechowywać informacje w bazie danych i zgodnie z ustalonymi harmonogramami przekazywać je do ASP. Do wymagań dotyczących funkcji interfejsu użytkownika IDC (IDC LRIT Data User interface Function), należy przetwarzanie przepytywań, próśb i stałych zleceń bezpośrednio od administracji państw, których statki są zgłaszane w IDC. Ponadto IDC powinno m.in. dokonywać uwierzytelniania użytkowników sieci LRIT i zapewniać odbiór informacji tylko uprawnionym użytkownikom. W przypadku prowadzenia akcji poszukiwawczo-ratunkowych na morzu, IDC powinno dostarczyć służbom SAR, informacje LRIT transmitowane przez wszystkie statki zlokalizowane w obszarze geograficznym poszukiwań, co pozwoli na szybką identyfikacje statku, który mógłby asystować w prowadzeniu takiej akcji. Wymagania funkcjonalne dotyczące interfejsu do Międzynarodowego Centrum Wymiany Danych LRIT (IDE Interface Function) nakładają na IDC konieczność komunikowania się w 19

20 centrami danych poprzez Międzynarodowe Centrum Wymiany Danych oraz m.in. dokonywania uwierzytelniania użytkowników danych, utrzymywania systemu zapewniającego dostęp do informacji tylko uprawnionym użytkownikom, przetwarzania powiadomień o aktualizacji DDP i przekazywania próśb przepytywań. Do wymagań funkcjonalnych dotyczących interfejsu komunikacyjnego z Planem Wymiany Danych (DDP Interface Function) należy uaktualnianie DDP bezpośrednio z serwera DDP po odebraniu zawiadomienia o uaktualnieniu. Wymagania funkcjonalne dotyczące monitoringu QoS (Quality of Service Monitoring Function) narzucają na IDC obowiązek monitorowania samego siebie i ASP, IDE oraz interfejsów użytkowników danych LRIT. Ponadto IDC powinno odpowiadać na zapytania dotyczące jakości od operatora IDC i Koordynatora LRIT, dostarczać Koordynatorowi LRIT danych pozwalających na monitorowania IDC oraz dokonywać pomiarów QoS i archiwizować ich wyniki. Do wymagań funkcjonalnych dotyczących modułu przetwarzania bilingów (Billing Handling Function) należy monitorowanie IDC, ASP, IDE i interfejsów użytkowników danych LRIT pod kątem transakcji podlegających opłatom, zestawianie raportów dotyczących billingów i kosztów dla IDE oraz wysyłanie rachunków i faktur do stosownych użytkowników. Wymagania dotyczące funkcji przetwarzania i obsługi parametrów LRIT (Processing and Parameter Handling Function) narzucają na IDC konieczność przetwarzania otrzymanych od ASP, IDE i interfejsów użytkowników LRIT, identyfikować typ wiadomości i w zależności od niego dodawać do wiadomości stosowne znaczniki czasu i parametry informacyjne. Do wymagań funkcjonalnych interfejsu do Koordynatora LRIT (LRIT Co-ordinator Interface) należą uwierzytelnianie Koordynatora LRIT, udostępnia nie mu informacji billingowych, raportów o błędach oraz informacji pozwalających na monitorowanie pracy systemu. Ogólne informacje na temat dostępności i niezawodności działania systemu są dokładnie tak samo zdefiniowane jak dla Międzynarodowego Centrum Wymiany Danych LRIT Interfejsy zewnętrzne Kolejnym bardzo ważnym elementem definiowanym, są interfejsy Międzynarodowego Centrum Danych LRIT. Przyjęto model komunikacji wykorzystujący Dostarczyciela Usług Aplikacji (Application Service Provider) który komunikuje się z Dostarczycielem Usług Komunikacyjnych (Communication Service Provider), w szczególności może być to te sam dostarczyciel usług. Bardzo istotna jest definicja funkcji interfejsu aplikacji, który musi umożliwiać: zdalną integrację sprzętu statkowego LRIT z Międzynarodowym Centrum Danych LRIT, automatyczną konfigurację transmisji informacji LRIT, automatyczną modyfikację częstości transmisji informacji LRIT, automatyczne zawieszanie transmisji informacji LRIT, transmisję informacji LRIT na żądanie, automatyczne odtwarzanie i zarządzanie transmisją informacji LRIT. 20

21 Centrum powinno być również zdolne do przetwarzania informacji dodawanych do każdej transmitowanej wiadomości LRIT przez Dostarczyciela Usługi Aplikacji i samo IDC. Zestawienie tych informacji zaprezentowano w tabeli 4. Tabela 4. Dane dodawane do wiadomości LRIT przez Dostarczyciela Usługi Aplikacji i samo Międzynarodowe Centrum Danych LRIT. Ship Identity Parametry Time Stamp 2 Time Stamp 3 LRIT Data Centre Identifier Time Stamp 4 Time Stamp 5 Komentarz Numer identyfikacyjny IMO statku i MMSI dla statku. (opcjonalnie nazwa statku.) Data i czas (wg UTC) odebranego raportu pozycji przez ASP (gdy użyto). Data i czas (wg UTC) przekazywanego raportu pozycji z ASP (gdy użyto) do właściwego Centrum Danych LRIT. Tożsamość Centrum Danych LRIT wskazana przez Unikalny Identyfikator. Data i czas (wg UTC) odebranego raportu pozycji przez Centrum Danych LRIT. Data i czas (wg UTC) przekazywanego raportu pozycji z Centrum Danych LRIT do Użytkownika Danych LRIT Definicje użytkowników Ostatni element tej części standardu stanowią definicje użytkowników systemu LRIT i ich funkcjonalnych uprawnień. Standard definiuje 4 rodzaje użytkowników uprawnionych do odbioru informacji LRIT: państwo flagi, państwo portu, państwo nadbrzeżne, instytucje SAR. Rodzaj użytkownika decyduje o tym, jakie informacje LRIT do niego docierają i z jaką częstotliwością są wysyłane System łączności w sieci systemu LRIT [10, 14] Przegląd i typy wiadomości System łączności w systemie LRIT bazuje na trzech typach wiadomości wymienianych pomiędzy poszczególnymi składnikami systemu: żądanie wymaganie specyficznych informacji LRIT, dane pozycji zawierają dane pozycji statku LRIT, inne pomocnicze wiadomości systemu wiadomości taryfikacyjne i dotyczące transakcji, wiadomości potwierdzające, wiadomości uaktualniające DDP, wiadomości żądania dostępu do DDP i wiadomości statusowe systemu. 21

22 Każda z części składowych systemu LRIT (z wyłączeniem wyposażenia statku) będzie miała swój unikalny identyfikator LRIT (LRIT ID), który umożliwi innym składnikom sieci LRIT identyfikację tego konkretnego składnika systemu. Koordynator systemu LRIT powinien zarządzać listą identyfikatorów LRIT ID i odpowiadać za przypisywanie ich różnym elementom systemu. Na rys.7 pokazano składniki systemu LRIT jak również różne segmenty komunikacyjne (A do E) w sieci LRIT. Rys. 7. Segmenty komunikacyjne systemu LRIT W tabeli 5 przedstawiono zestawienie wszystkich wiadomości przesyłanych w systemie LRIT. Wiadomości pozycyjne statku LRIT Ship Position Reports (wiadomości 1, 2 i 3) zawierające informacje o pozycji statku są przeznaczone dla użytkowników danych LRIT, uprawnionych do odbierania danych pozycyjnych. Wiadomości zapytanie o pozycję statku LRIT Ship Position Request Messages (wiadomość 4 i 5) są przeznaczone do dostarczania Użytkownikom Danych LRIT informacji o pozycji statku (z możliwością przepytywania), zmiany częstotliwości raportowania przez statek, zmiany archiwizowanych wiadomości o pozycji lub zaprzestania odbioru raportów od danego statku. Wiadomość SAR SURPIC Request (Wiadomość 6) żąda wysłania z bazy danych, zlokalizowanej w Centrum Danych, aktualnych danych, w tym zobrazowania statku w danym obszarze geograficznym, dla potrzeb służb SAR prowadzących akcje ratunkowe. Wiadomość Receipt Message (wiadomość 7) jest wysyłana jako potwierdzenie odbioru wiadomości LRIT. Wiadomość DDP Update (wiadomość 8) jest nadawana bezpośrednio z serwera do Międzynarodowego Centrum Wymiany Danych LRIT - IDE i Centrów Danych. Wiadomość ta zawiera ostatni plan dystrybucji danych i jest używana przez IDE oraz Centra Danych do uaktualnienia swoich kopii planu dystrybucji danych. 22

23 Typ wiadomości Tabela 5. Wiadomości w systemie LRIT. Nazwa wiadomości Opis wiadomości LRIT Positional Data (position report) Messages 1 Periodic Position Report Okresowy, regularny raport o pozycji statku 2 Polled Position Report Raport o pozycji statku jako rezultat żądania pollingu 3 SAR Position Report Raport o pozycji statku jako rezultat żądania SAR LRIT Request Messages 4 Ship Position Request Żądanie raportu z pollingu 5 SAR Poll Request Żądanie SAR zapytania o określoną pozycję statku 6 SAR SURPIC Request Żądanie SAR zapytania o pozycję statku w określonym obszarze. Other Messages 7 Receipt Wiadomość potwierdzająca brak możliwości odpowiedzi na żądanie LRIT lub wiadomość raportująca (np. Time Stamp- -czas i data. 8 DDP Update Informacja używana do uaktualnienia DDP. 10 System Status Standardowa (co 30 minut) wiadomość statusowa wysyłana z Międzynarodowej Wymiany Danych LRIT do każdego Centrum Danych (lub vice versa) powiadamiająca, że system jest zdrowy. 12 RDC issued Billing and transaction Report Standardowy miesięczny raport wytworzony w RDC lub IDC i wysłany do IDE. Wiadomość System Status Message (Wiadomość 10) wysyłana z IDE informuje wszystkie Centra Danych LRIT o prawidłowym działaniu IDE, a wiadomość System Status wysyłana z Centrów Danych informuje IDE o ich prawidłowym działaniu. Wiadomości LRIT Billing and Transaction Report Messages (wiadomość 12) są nadawane w cyklach miesięcznych przez IDE do Centrów danych LRIT, przez IDC do IDE i przez RDC do IDE. Każda wiadomość zawiera plik z zestawieniem wszystkich transakcji i informację bilingową. Szczegółowy opis wszystkich informacji przesyłanych w systemie LRIT został przedstawiony w tabelach 6 13 w załączniku Strategia Protokołów Komunikacyjnych Rysunek 8 ilustruje różne połączenia komunikacyjne w systemie LRIT. Wiadomości LRIT będą przekazywane w sieci LRIT za pomocą każdego z połączeń komunikacyjnych. Protokoły komunikacyjne tworzą mechanizm zapewniający transport wiadomości od jednego do drugiego składnika sieci LRIT. W systemie LRIT zdefiniowano 4 typy łączy komunikacyjnych: Com Link Type 1 łączący CSP z ASP, Com Link Type 2 łączący ASP z NDC, RDC i DC, Com Link Type 3 łączący DC z CG, Com Link Type 4 łączący DC z DDP/IDE. 23

24 Rys. 8. Struktura łączy w systemie LRIT Medium fizyczne, które przekazuje wiadomości LRIT i związana z nim warstwa fizyczna nie są ograniczone do jednego specyficznego typu lub protokołu. Stąd możliwe jest stosowanie wielu różnych mediów niskiego poziomu takich jak światłowody, linie miedziane, łącza mikrofalowe i związane z nimi standardy warstwy fizycznej takie jak np. Sonnet, OC192, T1, E1. Warstwa łącza danych, która znajduje się powyżej warstwy fizycznej, nie jest również ograniczona do jednego standardu. Można używać wielu protokołów warstwy łącza danych zaimplementowanych do komunikacji między różnymi składnikami sieci LRIT. Przykładowo możliwe do zastosowania standardy to: Ethernet, ATM, ISDN i 802.XX. Warstwa sieci powinna bazować na wersji 4 specyfikacji protokołu internetowego (IPv4). Późniejsze wersje specyfikacji IP są również akceptowalne. Każdy element sieci LRIT (np. IDE, DC) powinien mieć swój unikalny adres IP. Jako minimum, IDE powinno być osiągalne dla DC poprzez standardową internetową ścieżkę komunikacyjną. Warstwa transportowa powinna bazować na protokole TCP. Podobnie jak poprzednio IDE powinno być osiągalne dla DC poprzez standardową internetową ścieżkę komunikacyjną. Warstwa aplikacji powinna używać protokołu TLS (TLS wersja 1.1 lub nowsza) i powinna komunikować się pomiędzy różnymi częściami LRIT za pomocą wiadomości SOAP bazujących na XML. Wiadomości SOAP (Simple Object Access Protocol) będą wymieniane między węzłami SOAP przez powiązanie z protokołem HTTPS jak to zdefiniowano w specyfikacji SOAP wersja 1.2. W warstwie aplikacji dla wymiany wiadomości LRIT wewnątrz sieci LRIT będzie używany protokół Simple Object Access Protocol (SOAP) wersja 1.2. Protokół SOAP jest protokołem warstwy aplikacji, który zezwala na komunikację między węzłami nie stawiając wymagań co do sieci komunikacyjnej, systemu operacyjnego czy też języka programowania. Wiadomość będzie przekazywana przy użyciu HTTP jako protokołu podstawowego. Chociaż HTTP jest z definicji mechanizmem typu zapytanie/odpowiedź, projektanci i wprowadzający muszą przyjmować asynchroniczny model i stosować odpowiednie nieblokujące się mechanizmy do odbioru odpowiedzi http, w celu zapewnienia optymalnych właściwości. Z perspektywy implementacji wiadomość przekazywana jest w jedną stronę. Wiadomości SOAP osadzone w odpowiedzi HTTP zawierają wyłącznie informację wskazującą stan końcowy wymiany wiadomości zapytanie-odpowiedź, którym może być sukces lub błąd. 24

25 Centra Danych, IDE i ASP zgodnie ze strategią protokołu komunikacyjnego będą funkcjonalnie pracowały jako węzły SOAP. Dwa asynchroniczne jednokierunkowe połączenia dla wiadomości będą zestawiane pomiędzy łączącymi się węzłami. Wiadomości LRIT, będą przesyłane między węzłami SOAP przez połączenia komunikacyjne zilustrowane na rysunku 8. W przekazywaniu wiadomości SOAP mogą uczestniczyć jedynie dwa węzły: początkowy nadawca i końcowy odbiorca. Dlatego nie będzie węzłów pośredniczących SOAP na ścieżce routingu każdej wiadomości SOAP. Mechanizm przekazywania wiadomości SOAP (forwarding mechanizm) nie jest używany, ponieważ nie są wymagane węzły pośrednie. Zawsze, kiedy zawartość odebranej wiadomości SOAP trzeba wysłać do różnych miejsc, należy stworzyć nową wiadomość SOAP i wysłać ją za pomocą węzła SOAP działającego jako inicjujący nadawca. Każdy możliwy związek lub korelacja, która może być ustanowiona pomiędzy przychodzącą, a wychodzącą wiadomością SOAP jest ustalany i utrzymywany w warstwie aplikacji przez software owe moduły aplikacyjne. Wiadomość SOAP będzie wymieniana pomiędzy węzłami SOAP przez powiązanie z protokołem HTTP(S) jak to zdefiniowano w wersji 1.2 specyfikacji SOAP. Wiadomość SOAP będzie wysyłana jedynie za pomocą kompleksowej metody HTTP POST. W treści wiadomości HTTP POST będą umieszczone parametry wiadomości osadzone w strukturze wiadomości SOAP Bezpieczeństwo danych wewnątrz sieci LRIT Bezpieczeństwo danych przesyłanych pomiędzy różnymi częściami składowymi systemu LRIT opiera się na wymaganiach przedstawionych w Rezolucji MSC.210(81) Performance Standards and Functional Requirements for LRIT of Ships. Kluczowymi pojęciami są autoryzacja, identyfikacja, uwierzytelnianie, poufność i integralność, które zostaną przedstawione poniżej. Informacje przesyłane w sieci LRIT nie powinny być dostępne dla wszystkich użytkowników systemu LRIT. Autoryzacja danych powinna bazować na polityce wymagań ustalonych i zaimplementowanych zgodnie z rezolucją MSC.202(81). Każda część składowa systemu LRIT wewnątrz sieci powinna zapewniać, że inna część składowa sieci, z którą się komunikuje, jest upoważniona tylko do odbioru nadawanej informacji zgodnie z planem dystrybucji DDP. Różne części składowe systemu LRIT w sieci LRIT powinny, przed wymianą informacji z inną częścią składową systemu, przeprowadzać identyfikację i uwierzytelnianie, przy użyciu standardowego procesu uwierzytelniania. Dane przesyłane w sieci LRIT, pomiędzy jej częściami składowymi, powinny być zaszyfrowane w celu uniemożliwienia dostępu do nich nieautoryzowanym użytkownikom, przy czym algorytm szyfrowania powinien wykorzystywać klucze o długości co najmniej 128 bitów lub większej. Obok ochrony kryptograficznej, dane przekazywane w sieci LRIT powinny podlegać sprawdzeniu ich integralności, w celu wykrycia prób ich modyfikacji przez nieupoważnione jednostki. Kolejnym bardzo ważnym elementem definicji standardu jest zabezpieczenie połączeń komunikacyjnych typu punkt punkt w oparciu o protokół Transport Layer Security (TLS 25

26 version 1.1 lub późniejsze), zdefiniowany przez Internet Engineering Task Force w dokumencie RFC 4346, wykorzystujący infrastrukturę klucza publicznego. Protokół TLS zapewnia bezpieczeństwo komunikacji w sieci Internet. Protokół umożliwia aplikacjom klient/serwer komunikację zabezpieczoną przed podsłuchem, ingerencją lub fałszowaniem wiadomości oraz zapewnia wymagania bezpieczeństwa odnoszące się do zachowania poufności i integralności. Poufność i integralność danych osiąga się za pomocą minimum 128 bitowego szyfrowania TLS przy użyciu symetrycznego algorytmu kryptograficznego Hash Message Authentication Code (HMAC). Algorytm HMAC zabezpiecza zarówno integralność wiadomości jak i jej autentyczność, poprzez zezwolenie weryfikatorom (którzy również posiadają prywatny, tajny klucz) na wykrywanie każdej zmiany zawartości wiadomości. HMAC może być używany z różnymi algorytmami hashowania m.in. MD5 i SHA-1. Każda część składowa sieci LRIT powinna używać klucza HMAC w czasie komunikowania się przez połączenie zabezpieczone protokołem TLS. HMAC powinien zapewnić, że przesyłane w sieci LRIT dane nie zostały zmienione w czasie transmisji oraz że ich integralność została zachowana. Części składowe sieci LRIT przesyłające informacje w oparciu o protokół TLS, powinny, przed wymianą danych, używać infrastruktury standardowego publiczno prywatnego (asymetrycznego) klucza w celu poprawnego uwierzytelniania oraz identyfikacji części składowych LRIT. Globalny certyfikat standardowego klucza publicznego (PKI) musi być wydany przez wiarygodną trzecią stronę, w celu zapewnienia weryfikacji i poręczenia tożsamości użytkownika. Jeżeli jakakolwiek część składowa sieci LRIT wykryje problem z innym certyfikatem PKI, wówczas wymiana informacji nie powinna mieć miejsca. Połączenia pomiędzy centrami danych w systemie i centrum wymiany danych systemu muszą być realizowane przy wykorzystaniu kryptograficznych tuneli transmisji danych Virtual Private Network (VPN), przy użyciu technologii TLS (wersja 1.1 lub nowsza) Specyfikacja protokołów do budowy systemu testowania sieci LRIT i testowania procesów integracji nowych Centrów Danych LRIT [10, 15] Ta część standardu ma charakter wysoce opisowy i nie uzyskała jeszcze postaci zbliżonej do postaci ostatecznej. Słowo protokół należy tutaj rozumieć jako ogólny przepis (zalecenie) co powinno zostać sprawdzone w danym rodzaju testów. W ogólności dokument dzieli testy na dwie grupy: testy w fazie rozwoju systemu LRIT oraz testy związane z integracją nowych elementów do istniejącego systemu. Przy definiowaniu testów oraz ich realizacji dokument daje duże uprawnienia Koordynatorowi systemu LRIT czyli organizacji IMSO. Dopuszcza się także realizowanie testów użytkownika (mogą je fizycznie realizować firmy zewnętrzne), muszą one jednak spełniać pewne wymagania oraz testować system w ścisłej zgodzie z opisywanymi wcześniej modułami technicznymi standardu. Jako szczególne wyróżniono testy związane z uruchomieniem operacyjnym systemu (tzw. commissioning test), a także opisano funkcjonalność testów związanych z rozbudową (integracją nowych elementów do systemu) i modyfikacjami systemu. Zakłada się, że część testów będzie musiała być zgłaszana do MSC IMO. Zakłada się również, że w czasie projektowania systemu intensywnie będą wykorzystywane symulatory komputerowe systemu LRIT. 26

27 4.5. Wytyczne dot. budowy i utrzymywania Planu Dystrybucji Danych [10] Istotnym elementem całego systemu jest Plan Dystrybucji Danych LRIT. Szczegółowy opis jego funkcjonalności to kolejny element standardu technicznego systemu LRIT. Zakłada się, że struktura ta będzie raczej mało dynamicznie zmienna, i będzie realizowana jako oddzielna funkcjonalność pod nadzorem IMO. Według standardu prawo dostępu do danych LRIT będą mieli użytkownicy systemu LRIT zgodnie ze swoim tytułem. Państwa portu, do którego zmierzają statki będą mogły uzyskiwać dane o statkach zmierzających w ich kierunku, państwa przybrzeżne o jednostkach przepływających w ich pobliżu, w obszarze, które same będą definiować, zgodnie z określonymi zasadami. Służby SAR będą mogły uzyskiwać dane (już istniejące na razie brak zgody na polling) w swoich strefach SRR lub tylko w obszarach gdzie będą koordynować akcje. Wszystkie dane o zdefiniowanych strefach geograficznych, ustanowionych czasach raportowania, strefach SRR itp. decydują o uprawnieniach. Mogą one być zbierane i weryfikowane tylko przez organizację międzynarodową, ustalono, że będzie to IMO. Nikt w systemie nie będzie miał dostępu do wszystkich danych i informacji LRIT. Zdefiniowano także wymagania odnośnie dostępności i niezawodności. Serwis ten ma być dostępny tak jak i inne kluczowe elementy systemu, 24 godziny na dobę, 7 dni w tygodniu przez 99,9% czasu i przez co najmniej 95% czasu w ciągu roku Standard naliczania kosztów i tworzenia bilingów w systemie LRIT [10, 16] Problem opłat i bilingów jest najdłużej dyskutowanym aspektem systemu LRIT. W połowie 2007 roku, pojawił się projekt dokumentu, przygotowany przez Grupę Roboczą LRIT, który próbuje ściśle rozwiązać ten problem. Dokument ten nie został jeszcze zatwierdzony przez odpowiednie ciała IMO. Obecnie dokument opisuje alokacje środków zarówno zarobionych jak pochodzących z dotacji, dla każdego elementu systemu co tworzy dosyć skomplikowaną sieć. Dodatkowo nakłada się na to problem rejestracji ruchu w sieci LRIT oraz rozliczeń wzajemnych pomiędzy podmiotami składającymi się na system. W ogólności obowiązuje nadal zasada, że jednostka pływająca nie ponosi żadnych kosztów w związku z nadawaniem przez siebie raportów LRIT. Koszty te ponosi w systemie użytkownik (uprawniony), który zażądał takich informacji. Kosztów też mają nie ponosić służby SAR, które będą wykorzystywać informacje LRIT do ratowania życia. Na rysunku 9 przedstawiono przepływ raportów i żądań ich dostarczenia w systemie LRIT. Poprawne zaplanowanie przepływów finansowych, podziału zysku a także oszacowanie rzeczywistych kosztów wiadomości LRIT dla użytkownika, jak również kosztów początkowych budowy i eksploatacji systemu przesądzą o sukcesie lub porażce całego przedsięwzięcia. 27

28 Rys. 9. Przepływ raportów i żądań ich dostarczenia w systemie LRIT 28

29 Scenariusze naliczania opłat i przepływów finansowych w systemie LRIT Aby problem uczynić bardziej przejrzystym, skonstruowano 10, przedstawionych poniżej scenariuszy, które obejmują wszystkie możliwe przepływy finansowe w systemie. Scenariusz 1: Państwo flagi National Data Centre Opis: Opłaty: Państwo flagi przesyła raport do NDC i żąda podania danych pozycyjnych własnego statku (patrz rys. 10). 1. Statek nie otrzymuje rachunku i nic nie płaci, 2. CSP obciąża ASP (jeśli są oddzielnie), 3. ASP obciąża DC, 4. DC (jeśli jest wydzielone) obciąża państwo strony Rys. 10. Scenariusz 1 naliczania opłat i przepływów finansowych w systemie LRIT Scenariusz 2: Państwo flagi Regional/Cooperative Data Centre Opis: Opłaty: Państwo flagi przesyła raport do R/CDC i żąda podania danych pozycyjnych własnego statku (patrz rys. 11). 1. Statek nie otrzymuje rachunku i nic nie płaci, 2. CSP obciąża ASP (jeśli są oddzielnie) lub DC, 3. ASP obciąża DC, 4. DC (jeśli jest wydzielone) obciąża państwo strony Rys. 11. Scenariusz 2 naliczania opłat i przepływów finansowych w systemie LRIT 29

30 Scenariusz 3: Państwo flagi International LRIT Data Centre Opis: Opłaty: Państwo flagi przesyła raport do IDC i żąda podania min. 4 raportów pozycyjnych na dobę własnego statku (patrz rys. 12). 1. Statek nie otrzymuje rachunku i nic nie płaci, 2. CSP obciąża ASP (jeśli są oddzielnie) lub DC, 3. ASP obciąża IDC, 4. IDC obciąża państwo strony Rys. 12. Scenariusz 3 naliczania opłat i przepływów finansowych w systemie LRIT Scenariusz 4: Państwo flagi nie chce otrzymywać kilku lub wszystkich raportów Opis: Opłaty: Państwo flagi przesyła raport do IDC i nie żąda podania kilku lub wszystkich z min. 4 raportów pozycyjnych na dobę własnego statku (patrz rys. 13). 1. Statek nie otrzymuje rachunku i nic nie płaci, 2. CSP obciąża ASP (jeśli są oddzielnie) lub DC, 3. ASP obciąża IDC, 4. IDC obciąża państwo strony za raporty, które zamówiło i otrzymało, 5. koszty za niechciane raporty zaliczane są do kosztów stałych państwa flagi lub IDC lub całego systemu LRIT. Rys. 13. Scenariusz 4 naliczania opłat i przepływów finansowych w systemie LRIT 30

31 Scenariusz 5: Państwo portu/flagi Regional/Cooperative Data Centre Opis: Opłaty: Państwo portu/flagi przesyła raport do R/CDC i żąda podania danych pozycyjnych statku przypisanego do tego samego R/CDC (patrz rys. 14). 1. Statek nie otrzymuje rachunku i nic nie płaci, 2. CSP obciąża ASP (jeśli są oddzielnie) lub DC, 3. ASP obciąża DC, 4. DC (jeśli jest wydzielone) jeśli działa komercyjnie to obciąża państwo strony w oparciu o wewnętrzne ustalenia pomiędzy państwami, a jeśli nie działa komercyjnie to koszty będą podzielone pomiędzy państwa stron zgodnie z wewnętrznymi ustaleniami pomiędzy tymi państwami. Rys. 14. Scenariusz 5 naliczania opłat i przepływów finansowych w systemie LRIT Scenariusz 6: National Data Centre lub Regional/Cooperative Data Centre państwa portu/flagi National Data Centre lub Regional/Cooperative Data Centre Opis: Opłaty: Państwo portu/flagi żąda przesłania raportu od Administracji należącej do NDC lub R/CDC poprzez IDE do innego NDC lub R/CDC, do którego jest przypisany statek (patrz rys. 15). 1. brak opłaty za raporty z wyjątkiem stałych kosztów IDE, 2. koszty mogą być podzielone, lub 3. źródłowe DC może zarabiać w zamian za podział kosztów. Rys. 15. Scenariusz 6 naliczania opłat i przepływów finansowych w systemie LRIT 31

32 Scenariusz 7: International LRIT Data Centre państwa portu/flagi National Data Centre lub Regional/Cooperative Data Centre Opis: Opłaty: Państwo portu/flagi żąda przesłania raportu od Administracji należącej do IDC poprzez IDE do NDC lub R/CDC, do którego jest przypisany statek (patrz rys. 16). 1. Statek nie otrzymuje rachunku i nic nie płaci, 2. CSP obciąża ASP (jeśli są oddzielnie) lub DC, 3. ASP obciąża DC, 4. DC (jeśli jest wydzielone) obciąża państwo strony Rys. 16. Scenariusz 7 naliczania opłat i przepływów finansowych w systemie LRIT Scenariusz 8: National Data Centre lub Regional/Cooperative Data Centre państwa portu/flagi International LRIT Data Centre Opis: Opłaty: Państwo portu/flagi żąda przesłania raportu od Administracji należącej do NDC lub R/CDC poprzez IDE do IDC, do którego jest przypisany statek (patrz rys. 17). 1. brak opłaty za raporty z wyjątkiem stałych kosztów IDE, 2. koszty mogą być podzielone, lub 3. źródłowe DC może zarabiać w zamian za podział kosztów. Rys. 17. Scenariusz 8 naliczania opłat i przepływów finansowych w systemie LRIT 32

33 Scenariusz 9: International LRIT Data Centre International LRIT Data Centre Opis: Opłaty: Państwo portu/flagi żąda przesłania raportu od Administracji należącej do IDC dotyczącego statku przypisanego do IDC (patrz rys. 18). 1. brak opłaty za raporty z wyjątkiem stałych kosztów IDE, 2. koszty mogą być podzielone, lub 3. źródłowe DC może zarabiać w zamian za podział kosztów. Rys. 18. Scenariusz 9 naliczania opłat i przepływów finansowych w systemie LRIT Scenariusz 10: Żądania SAR Opis: Żądania Służby SAR w trakcie prowadzenia akcji poszukiwawczo ratowniczych. Opłaty: brak opłat za żądania Służb SAR Koszty stałe utrzymania systemu LRIT Jak już wspomniano część kosztów może zostać zakwalifikowanych jako koszty stałe poszczególnych elementów składowych systemu. Koszty Koordynatora LRIT powinny zostać rozłożone na wszystkie elementy systemu LRIT, którym Koordynator LRIT świadczy usługi zapisane w standardzie. Są to wszystkie centra danych, ASP raportujące do IDC oraz IDE. Z kolei w przypadku DDP, Sekretariat IMO pokrywa wszystkie koszty ze swojego budżetu. Ponieważ DDP jest używany przez wszystkie państwa stron i wszystkie centra danych, jego koszty stałe powinny być rozdzielone na cały system. Zaproponowano kilka opcji określających te koszty: Każde z państwa strony jest bezpośrednio obciążane taką samą kwotą, co oznacza, że Sekretariat IMO pokrywa te koszty. Każde centrum danych jest obciążane taką samą kwotą, co oznacza, że Sekretariat IMO nie musi opłacać państw stron. Każde centrum danych jest obciążane kwotą zależną od ilości państw stron z niego korzystających, co jest preferowane jako najuczciwsze rozwiązanie. 33