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

Wielkość: px
Rozpocząć pokaz od strony:

Download "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

Wzorcowy załącznik techniczny, do umowy w sprawie przesyłania faktur elektronicznych pomiędzy Firmą A oraz Firmą B

Wzorcowy załącznik techniczny, do umowy w sprawie przesyłania faktur elektronicznych pomiędzy Firmą A oraz Firmą B Załącznik Nr 1 Wzorcowy załącznik techniczny, do umowy w sprawie przesyłania faktur elektronicznych pomiędzy Firmą A oraz Firmą B Wersja 1.0 Na podstawie: Europejskiej Modelowej Umowy o EDI (w skrócie:

Bardziej szczegółowo

Wprowadzenie do PKI. 1. Wstęp. 2. Kryptografia symetryczna. 3. Kryptografia asymetryczna

Wprowadzenie do PKI. 1. Wstęp. 2. Kryptografia symetryczna. 3. Kryptografia asymetryczna 1. Wstęp Wprowadzenie do PKI Infrastruktura klucza publicznego (ang. PKI - Public Key Infrastructure) to termin dzisiaj powszechnie spotykany. Pod tym pojęciem kryje się standard X.509 opracowany przez

Bardziej szczegółowo

SSL (Secure Socket Layer)

SSL (Secure Socket Layer) SSL --- Secure Socket Layer --- protokół bezpiecznej komunikacji między klientem a serwerem, stworzony przez Netscape. SSL w założeniu jest podkładką pod istniejące protokoły, takie jak HTTP, FTP, SMTP,

Bardziej szczegółowo

Zastosowania PKI dla wirtualnych sieci prywatnych

Zastosowania PKI dla wirtualnych sieci prywatnych Zastosowania PKI dla wirtualnych sieci prywatnych Andrzej Chrząszcz NASK Agenda Wstęp Sieci Wirtualne i IPSEC IPSEC i mechanizmy bezpieczeństwa Jak wybrać właściwą strategię? PKI dla VPN Co oferują dostawcy

Bardziej szczegółowo

WLAN bezpieczne sieci radiowe 01

WLAN bezpieczne sieci radiowe 01 WLAN bezpieczne sieci radiowe 01 ostatnim czasie ogromną popularność zdobywają sieci bezprzewodowe. Zapewniają dużą wygodę w dostępie użytkowników do zasobów W informatycznych. Jednak implementacja sieci

Bardziej szczegółowo

ZAŁĄCZNIK Nr 3 do CZĘŚCI II SIWZ

ZAŁĄCZNIK Nr 3 do CZĘŚCI II SIWZ ZAŁĄCZNIK Nr 3 do CZĘŚCI II SIWZ WYMAGANIA BEZPIECZEŃSTWA DLA SYSTEMÓW IT Wyciąg z Polityki Bezpieczeństwa Informacji dotyczący wymagań dla systemów informatycznych. 1 Załącznik Nr 3 do Część II SIWZ Wymagania

Bardziej szczegółowo

Warstwy i funkcje modelu ISO/OSI

Warstwy i funkcje modelu ISO/OSI Warstwy i funkcje modelu ISO/OSI Organizacja ISO opracowała Model Referencyjny Połączonych Systemów Otwartych (model OSI RM - Open System Interconection Reference Model) w celu ułatwienia realizacji otwartych

Bardziej szczegółowo

MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP

MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP WERSJA 1 z 15 Spis treści 1. Kanał email dla podmiotów zewnętrznych...

Bardziej szczegółowo

Wykład 4. komputerowych Protokoły SSL i TLS główne slajdy. 26 października 2011. Igor T. Podolak Instytut Informatyki Uniwersytet Jagielloński

Wykład 4. komputerowych Protokoły SSL i TLS główne slajdy. 26 października 2011. Igor T. Podolak Instytut Informatyki Uniwersytet Jagielloński Wykład 4 Protokoły SSL i TLS główne slajdy 26 października 2011 Instytut Informatyki Uniwersytet Jagielloński 4.1 Secure Sockets Layer i Transport Layer Security SSL zaproponowany przez Netscape w 1994

Bardziej szczegółowo

WYMAGANIA TECHNOLOGICZNE W ODNIESIENIU DO SYSTEMÓW TELEKOMUNIKACYJNYCH I TELEINFORMATYCZNYCH W OBSZARZE SIŁ ZBROJNYCH

WYMAGANIA TECHNOLOGICZNE W ODNIESIENIU DO SYSTEMÓW TELEKOMUNIKACYJNYCH I TELEINFORMATYCZNYCH W OBSZARZE SIŁ ZBROJNYCH WYMAGANIA TECHNOLOGICZNE W ODNIESIENIU DO SYSTEMÓW TELEKOMUNIKACYJNYCH I TELEINFORMATYCZNYCH W OBSZARZE SIŁ ZBROJNYCH Robert Goniacz WYMAGANIA TECHNOLOGICZNE Obszar sił zbrojnych Najważniejsze problemy

Bardziej szczegółowo

Warszawa, dnia 14 grudnia 2012 r. Poz. 1412 ROZPORZĄDZENIE MINISTRA TRANSPORTU, BUDOWNICTWA I GOSPODARKI MORSKIEJ 1) z dnia 4 grudnia 2012 r.

Warszawa, dnia 14 grudnia 2012 r. Poz. 1412 ROZPORZĄDZENIE MINISTRA TRANSPORTU, BUDOWNICTWA I GOSPODARKI MORSKIEJ 1) z dnia 4 grudnia 2012 r. DZIENNIK USTAW RZECZYPOSPOLITEJ POLSKIEJ Warszawa, dnia 14 grudnia 2012 r. Poz. 1412 ROZPORZĄDZENIE MINISTRA TRANSPORTU, BUDOWNICTWA I GOSPODARKI MORSKIEJ 1) z dnia 4 grudnia 2012 r. w sprawie Narodowego

Bardziej szczegółowo

Płatności CashBill - SOAP

Płatności CashBill - SOAP Dokumentacja techniczna 1.0 Płatności CashBill - SOAP Dokumentacja wdrożenia systemu Płatności CashBill w oparciu o komunikację według protokołu SOAP CashBill Spółka Akcyjna ul. Rejtana 20, 41-300 Dąbrowa

Bardziej szczegółowo

Zdalne logowanie do serwerów

Zdalne logowanie do serwerów Zdalne logowanie Zdalne logowanie do serwerów Zdalne logowanie do serwerów - cd Logowanie do serwera inne podejście Sesje w sieci informatycznej Sesje w sieci informatycznej - cd Sesje w sieci informatycznej

Bardziej szczegółowo

Internetowe Konto Pacjenta

Internetowe Konto Pacjenta Internetowe Konto Pacjenta Bezpieczne rozwiązanie dla Pacjentów i Lekarzy Tomasz Orlewicz Dyrektor Obszaru Biznesowego tomasz.orlewicz@unizeto.pl Warszawa, 28 listopada 2011 Internetowe Konto Pacjenta

Bardziej szczegółowo

Spis treści. Dzień 1. I Wprowadzenie (wersja 0906) II Dostęp do danych bieżących specyfikacja OPC Data Access (wersja 0906) Kurs OPC S7

Spis treści. Dzień 1. I Wprowadzenie (wersja 0906) II Dostęp do danych bieżących specyfikacja OPC Data Access (wersja 0906) Kurs OPC S7 I Wprowadzenie (wersja 0906) Kurs OPC S7 Spis treści Dzień 1 I-3 O czym będziemy mówić? I-4 Typowe sytuacje I-5 Klasyczne podejście do komunikacji z urządzeniami automatyki I-6 Cechy podejścia dedykowanego

Bardziej szczegółowo

Hosting WWW Bezpieczeństwo hostingu WWW. Dr Michał Tanaś (http://www.amu.edu.pl/~mtanas)

Hosting WWW Bezpieczeństwo hostingu WWW. Dr Michał Tanaś (http://www.amu.edu.pl/~mtanas) Hosting WWW Bezpieczeństwo hostingu WWW Dr Michał Tanaś (http://www.amu.edu.pl/~mtanas) Szyfrowana wersja protokołu HTTP Kiedyś używany do specjalnych zastosowań (np. banki internetowe), obecnie zaczyna

Bardziej szczegółowo

Procedura Walidacyjna Interfejs

Procedura Walidacyjna Interfejs Strona: 1 Stron: 7 SPIS TREŚCI: 1. CEL 2. ZAKRES 3. DEFINICJE 4. ODPOWIEDZIALNOŚĆ I UPRAWNIENIA 5. TRYB POSTĘPOWANIA 6. ZAŁĄCZNIKI Podlega aktualizacji X Nie podlega aktualizacji Strona: 2 Stron: 7 1.

Bardziej szczegółowo

System AIS. Paweł Zalewski Instytut Inżynierii Ruchu Morskiego Akademia Morska w Szczecinie

System AIS. Paweł Zalewski Instytut Inżynierii Ruchu Morskiego Akademia Morska w Szczecinie System AIS Paweł Zalewski Instytut Inżynierii Ruchu Morskiego Akademia Morska w Szczecinie - 2 - Treść prezentacji: AIS AIS i ECDIS AIS i VTS AIS i HELCOM Podsumowanie komentarz - 3 - System AIS (system

Bardziej szczegółowo

INFORMATYKA Pytania ogólne na egzamin dyplomowy

INFORMATYKA Pytania ogólne na egzamin dyplomowy INFORMATYKA Pytania ogólne na egzamin dyplomowy 1. Wyjaśnić pojęcia problem, algorytm. 2. Podać definicję złożoności czasowej. 3. Podać definicję złożoności pamięciowej. 4. Typy danych w języku C. 5. Instrukcja

Bardziej szczegółowo

System Automatycznej Identyfikacji. Automatic Identification System (AIS)

System Automatycznej Identyfikacji. Automatic Identification System (AIS) System Automatycznej Identyfikacji Automatic Identification System (AIS) - 2 - Systemy GIS wywodzą się z baz danych umożliwiających generację mapy numerycznej i bez względu na zastosowaną skalę mapy wykonują

Bardziej szczegółowo

Jednym z najważniejszych zagadnień, z którym może się zetknąć twórca

Jednym z najważniejszych zagadnień, z którym może się zetknąć twórca Uwierzytelnianie w PHP 01 Jednym z najważniejszych zagadnień, z którym może się zetknąć twórca stron internetowych, jest identyfikacja i uwierzytelnienie uprzywilejowanego użytkownika. Od zaprojektowania

Bardziej szczegółowo

PROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W CSIZS

PROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W CSIZS Załącznik nr 3 do umowy nr 10/DI/PN/2016 PROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W Rozdział 1. ADMINISTROWANIE 1. Wykonawca, w celu zapewnienia ciągłości funkcjonowania, zobowiązuje się

Bardziej szczegółowo

Kielce, dnia 27.02.2012 roku. HB Technology Hubert Szczukiewicz. ul. Kujawska 26 / 39 25-344 Kielce

Kielce, dnia 27.02.2012 roku. HB Technology Hubert Szczukiewicz. ul. Kujawska 26 / 39 25-344 Kielce Kielce, dnia 27.02.2012 roku HB Technology Hubert Szczukiewicz ul. Kujawska 26 / 39 25-344 Kielce Tytuł Projektu: Wdrożenie innowacyjnego systemu dystrybucji usług cyfrowych, poszerzenie kanałów sprzedaży

Bardziej szczegółowo

Część I -ebxml. UEK w Krakowie Janusz Stal & Grażyna Paliwoda-Pękosz. UEK w Krakowie Janusz Stal & Grażyna Paliwoda-Pękosz

Część I -ebxml. UEK w Krakowie Janusz Stal & Grażyna Paliwoda-Pękosz. UEK w Krakowie Janusz Stal & Grażyna Paliwoda-Pękosz Część I -ebxml Po zrealizowaniu materiału student będzie w stanie omówić potrzeby rynku B2B w zakresie przeprowadzania transakcji przez Internet zaprezentować architekturę ebxml wskazać na wady i zalety

Bardziej szczegółowo

Procedura podłączania węzła lokalnego Elektrowni do węzła centralnego OSP Systemu Monitorowania Parametrów Pracy JWCD (SMPP)

Procedura podłączania węzła lokalnego Elektrowni do węzła centralnego OSP Systemu Monitorowania Parametrów Pracy JWCD (SMPP) data:16-09-2003 wersja: 1.2 plik: Procedura_podlaczenia_SMPP_v1.2.doc Strona 1 / 6 Procedura podłączania węzła lokalnego Elektrowni do węzła centralnego OSP Systemu Monitorowania Parametrów Pracy JWCD

Bardziej szczegółowo

ZiMSK. Konsola, TELNET, SSH 1

ZiMSK. Konsola, TELNET, SSH 1 ZiMSK dr inż. Łukasz Sturgulewski, luk@kis.p.lodz.pl, http://luk.kis.p.lodz.pl/ dr inż. Artur Sierszeń, asiersz@kis.p.lodz.pl dr inż. Andrzej Frączyk, a.fraczyk@kis.p.lodz.pl Konsola, TELNET, SSH 1 Wykład

Bardziej szczegółowo

Jarosław Kuchta Administrowanie Systemami Komputerowymi. Internetowe Usługi Informacyjne

Jarosław Kuchta Administrowanie Systemami Komputerowymi. Internetowe Usługi Informacyjne Jarosław Kuchta Internetowe Usługi Informacyjne Komponenty IIS HTTP.SYS serwer HTTP zarządzanie połączeniami TCP/IP buforowanie odpowiedzi obsługa QoS (Quality of Service) obsługa plików dziennika IIS

Bardziej szczegółowo

Komunikacja i wymiana danych

Komunikacja i wymiana danych Budowa i oprogramowanie komputerowych systemów sterowania Wykład 10 Komunikacja i wymiana danych Metody wymiany danych Lokalne Pliki txt, csv, xls, xml Biblioteki LIB / DLL DDE, FastDDE OLE, COM, ActiveX

Bardziej szczegółowo

ROZPORZĄDZENIE MINISTRA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI 1) z dnia 29 kwietnia 2004 r.

ROZPORZĄDZENIE MINISTRA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI 1) z dnia 29 kwietnia 2004 r. Dz.U.2004.100.1024 ROZPORZĄDZENIE MINISTRA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI 1) z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych,

Bardziej szczegółowo

System Kontroli Bazy Danych Topograficznych (SKBDT) zawód kartografa?

System Kontroli Bazy Danych Topograficznych (SKBDT) zawód kartografa? System Kontroli Bazy Danych Topograficznych (SKBDT) zawód kartografa? Koszalin, 15-16.05.2006 III Zawodowa Konferencja Zawód kartografa 200910151500 Agenda 1. Koncepcja SKBDT 2. Podstawowe założenia koncepcji

Bardziej szczegółowo

Zdalne monitorowanie i zarządzanie urządzeniami sieciowymi

Zdalne monitorowanie i zarządzanie urządzeniami sieciowymi Uniwersytet Mikołaja Kopernika w Toruniu Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Infomatyki Stosowanej Piotr Benetkiewicz Nr albumu: 168455 Praca magisterska na kierunku Informatyka

Bardziej szczegółowo

Wykład 2: Budowanie sieci lokalnych. A. Kisiel, Budowanie sieci lokalnych

Wykład 2: Budowanie sieci lokalnych. A. Kisiel, Budowanie sieci lokalnych Wykład 2: Budowanie sieci lokalnych 1 Budowanie sieci lokalnych Technologie istotne z punktu widzenia konfiguracji i testowania poprawnego działania sieci lokalnej: Protokół ICMP i narzędzia go wykorzystujące

Bardziej szczegółowo

wersja dokumentu 1.0 data wydania 2008.11.14

wersja dokumentu 1.0 data wydania 2008.11.14 HERMESEDI System elektronicznej wymiany dokumentów w systemie EDI/ECOD wersja dokumentu 1.0 data wydania 2008.11.14 Syriusz sp. z o.o. Rzeszów 2008 SPIS TREŚCI: 1. Przeznaczenie... 3 2. Schemat pracy...

Bardziej szczegółowo

Świadczenie usługi hurtowej wysyłki wiadomości SMS dla Urzędu Miasta Torunia w latach

Świadczenie usługi hurtowej wysyłki wiadomości SMS dla Urzędu Miasta Torunia w latach OPIS WYMGŃ FUNKCJONLNO-TECHNICZNYCH dla zamówienia: Świadczenie usługi hurtowej wysyłki wiadomości SMS dla Urzędu Miasta Torunia w latach 2015-2016 Przedmiot zamówienia Przedmiotem zamówienia jest usługa

Bardziej szczegółowo

Bazy danych 2. Wykład 1

Bazy danych 2. Wykład 1 Bazy danych 2 Wykład 1 Sprawy organizacyjne Materiały i listy zadań zamieszczane będą na stronie www.math.uni.opole.pl/~ajasi E-mail: standardowy ajasi@math.uni.opole.pl Sprawy organizacyjne Program wykładu

Bardziej szczegółowo

Warszawa, dnia 18 grudnia 2015 r. RZĄDOWE CENTRUM LEGISLACJI DEPARTAMENT PRAWA ADMINISTRACYJNEGO

Warszawa, dnia 18 grudnia 2015 r. RZĄDOWE CENTRUM LEGISLACJI DEPARTAMENT PRAWA ADMINISTRACYJNEGO Warszawa, dnia 18 grudnia 2015 r. RZĄDOWE CENTRUM LEGISLACJI DEPARTAMENT PRAWA ADMINISTRACYJNEGO RCL.DPA.553.18/2015 Dot.: DP-WL.0211.39.2015/SB Pani Katarzyna Kobierska Dyrektor Departamentu Prawnego

Bardziej szczegółowo

Polityka prywatności i bezpieczeństwa przetwarzania danych osobowych w zbiorze czas-na-przeglad.pl

Polityka prywatności i bezpieczeństwa przetwarzania danych osobowych w zbiorze czas-na-przeglad.pl Poznań, 24.01.2011 Polityka prywatności i bezpieczeństwa przetwarzania danych osobowych w zbiorze czas-na-przeglad.pl Realizując postanowienia ustawy z dnia 29.08.1997r. o ochronie danych osobowych (Dz.

Bardziej szczegółowo

ActiveXperts SMS Messaging Server

ActiveXperts SMS Messaging Server ActiveXperts SMS Messaging Server ActiveXperts SMS Messaging Server to oprogramowanie typu framework dedykowane wysyłaniu, odbieraniu oraz przetwarzaniu wiadomości SMS i e-mail, a także tworzeniu własnych

Bardziej szczegółowo

Temat: EasyAccess 2.0 Data: 10 Października 2014 Prowadzący: Maciej Sakowicz

Temat: EasyAccess 2.0 Data: 10 Października 2014 Prowadzący: Maciej Sakowicz Temat: EasyAccess 2.0 Data: 10 Października 2014 Prowadzący: Maciej Sakowicz Agenda Część 1: Studium przypadku i rozwiązanie Część 2: Czym jest EasyAccess 2.0? Część 3: Dlaczego warto użyć EasyAccess 2.0?

Bardziej szczegółowo

System DiLO. Opis interfejsu dostępowego v. 2.0

System DiLO. Opis interfejsu dostępowego v. 2.0 System DiLO Opis interfejsu dostępowego v. 2.0 Warszawa 2015 1 Wprowadzone zmiany Wersja Opis 1.0 Wersja bazowa 1.1 Dodanie możliwości przejścia z wydania karty w POZ (WK-POZ) do zabiegu operacyjnego (ZAB-OPER)

Bardziej szczegółowo

Rozdział 3. ROZWÓJ APLIKACJI CENTRALNEJ

Rozdział 3. ROZWÓJ APLIKACJI CENTRALNEJ Załącznik nr 2 do umowy nr 11/DI/PN/2013 PROCEDURA UTRZYMANIA I ROZWOJU APLIKACJI CENTRALNEJ Rozdział 1. WPROWADZENIE Celem niniejszego dokumentu jest sprecyzowanie procedury zarządzania realizacją umowy

Bardziej szczegółowo

iqportal abonencki panel zarządzania

iqportal abonencki panel zarządzania ISO 9001:2000 iqportal abonencki panel zarządzania Wersja 0.9 Informacje zawarte w niniejszym dokumencie stanowią tajemnicę naszego przedsiębiorstwa w rozumieniu przepisów Ustawy o zwalczaniu nieuczciwej

Bardziej szczegółowo

KOMPUTEROWY SYSTEM WSPOMAGANIA OBSŁUGI JEDNOSTEK SŁUŻBY ZDROWIA KS-SOMED

KOMPUTEROWY SYSTEM WSPOMAGANIA OBSŁUGI JEDNOSTEK SŁUŻBY ZDROWIA KS-SOMED KOMPUTEROWY SYSTEM WSPOMAGANIA OBSŁUGI JEDNOSTEK SŁUŻBY ZDROWIA KS-SOMED Podręcznik użytkownika Katowice 2010 Producent programu: KAMSOFT S.A. ul. 1 Maja 133 40-235 Katowice Telefon: (0-32) 209-07-05 Fax:

Bardziej szczegółowo

ZAŁĄCZNIK NR 1 DO REGULAMINU SERWISU ZNANEEKSPERTKI.PL POLITYKA OCHRONY PRYWATNOŚCI

ZAŁĄCZNIK NR 1 DO REGULAMINU SERWISU ZNANEEKSPERTKI.PL POLITYKA OCHRONY PRYWATNOŚCI ZAŁĄCZNIK NR 1 DO REGULAMINU SERWISU ZNANEEKSPERTKI.PL POLITYKA OCHRONY PRYWATNOŚCI Headlines Spółka z ograniczoną odpowiedzialnością i spółka spółka komandytowa szanuje i troszczy się o prawo do prywatności

Bardziej szczegółowo

SKRÓCONA INSTRUKCJA OBSŁUGI SYSTEMU ZARZĄDZANIA OBIEGIEM INFORMACJI (SZOI)

SKRÓCONA INSTRUKCJA OBSŁUGI SYSTEMU ZARZĄDZANIA OBIEGIEM INFORMACJI (SZOI) SKRÓCONA INSTRUKCJA OBSŁUGI SYSTEMU ZARZĄDZANIA OBIEGIEM INFORMACJI (SZOI) Wymiana dokumentów elektronicznych pomiędzy Apteką a Zachodniopomorskim Oddziałem Wojewódzkim NFZ Strona 1 z 10 INFORMACJE OGÓLNE

Bardziej szczegółowo

Bezpieczeństwo Systemów Komputerowych. Wirtualne Sieci Prywatne (VPN)

Bezpieczeństwo Systemów Komputerowych. Wirtualne Sieci Prywatne (VPN) Bezpieczeństwo Systemów Komputerowych Wirtualne Sieci Prywatne (VPN) Czym jest VPN? VPN(Virtual Private Network) jest siecią, która w sposób bezpieczny łączy ze sobą komputery i sieci poprzez wirtualne

Bardziej szczegółowo

Zalecenia standaryzacyjne dotyczące bezpieczeństwa wymiany danych osobowych drogą elektroniczną. Andrzej Kaczmarek Biuro GIODO

Zalecenia standaryzacyjne dotyczące bezpieczeństwa wymiany danych osobowych drogą elektroniczną. Andrzej Kaczmarek Biuro GIODO Zalecenia standaryzacyjne dotyczące bezpieczeństwa wymiany danych osobowych drogą elektroniczną Andrzej Kaczmarek Biuro GIODO 1 Plan prezentacji: Przepisy określające wymagania w zakresie bezpieczeństwa

Bardziej szczegółowo

Analiza kosztów stosowania bilingu

Analiza kosztów stosowania bilingu Warszawa, 11.10.2010 r. Analiza kosztów stosowania bilingu System bilingowy Kobi w firmie X * * firma X to jeden z większych banków w Polsce, w związku z obowiązującą nas umową, nie możemy podać nazwy

Bardziej szczegółowo

Systemy internetowe. Wykład 5 Architektura WWW. West Pomeranian University of Technology, Szczecin; Faculty of Computer Science

Systemy internetowe. Wykład 5 Architektura WWW. West Pomeranian University of Technology, Szczecin; Faculty of Computer Science Systemy internetowe Wykład 5 Architektura WWW Architektura WWW Serwer to program, który: Obsługuje repozytorium dokumentów Udostępnia dokumenty klientom Komunikacja: protokół HTTP Warstwa klienta HTTP

Bardziej szczegółowo

Gatesms.eu Mobilne Rozwiązania dla biznesu

Gatesms.eu Mobilne Rozwiązania dla biznesu Mobilne Rozwiązania dla biznesu SPECYFIKACJA TECHNICZNA WEB API-USSD GATESMS.EU wersja 0.9 Opracował: Gatesms.eu Spis Historia wersji dokumentu...3 Bezpieczeństwo...3 Wymagania ogólne...3 Mechanizm zabezpieczenia

Bardziej szczegółowo

Protokoły zdalnego logowania Telnet i SSH

Protokoły zdalnego logowania Telnet i SSH Protokoły zdalnego logowania Telnet i SSH Krzysztof Maćkowiak Wprowadzenie Wykorzystując Internet mamy możliwość uzyskania dostępu do komputera w odległej sieci z wykorzystaniem swojego komputera, który

Bardziej szczegółowo

Galileo - encyklopedia internetowa Plan testów

Galileo - encyklopedia internetowa Plan testów Galileo - encyklopedia internetowa Plan testów Sławomir Pawlewicz Alan Pilawa Joanna Sobczyk Matek Sobierajski 5 czerwca 2006 1 Spis treści 1 Wprowadzenie 3 1.1 Cel..........................................

Bardziej szczegółowo

Marek Parfieniuk, Tomasz Łukaszuk, Tomasz Grześ. Symulator zawodnej sieci IP do badania aplikacji multimedialnych i peer-to-peer

Marek Parfieniuk, Tomasz Łukaszuk, Tomasz Grześ. Symulator zawodnej sieci IP do badania aplikacji multimedialnych i peer-to-peer Marek Parfieniuk, Tomasz Łukaszuk, Tomasz Grześ Symulator zawodnej sieci IP do badania aplikacji multimedialnych i peer-to-peer Plan prezentacji 1. Cel projektu 2. Cechy systemu 3. Budowa systemu: Agent

Bardziej szczegółowo

Currenda EPO Instrukcja Konfiguracji. Wersja dokumentu: 1.3

Currenda EPO Instrukcja Konfiguracji. Wersja dokumentu: 1.3 Currenda EPO Instrukcja Konfiguracji Wersja dokumentu: 1.3 Currenda EPO Instrukcja Konfiguracji - wersja dokumentu 1.3-19.08.2014 Spis treści 1 Wstęp... 4 1.1 Cel dokumentu... 4 1.2 Powiązane dokumenty...

Bardziej szczegółowo

Promotor: dr inż. Krzysztof Różanowski

Promotor: dr inż. Krzysztof Różanowski Warszawska Wyższa Szkoła Informatyki Prezentacja do obrony pracy dyplomowej: Wzorcowa polityka bezpieczeństwa informacji dla organizacji zajmującej się testowaniem oprogramowania. Promotor: dr inż. Krzysztof

Bardziej szczegółowo

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli Diagnostyka stanu nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 21 maja 2012 Historia dokumentu

Bardziej szczegółowo

IPsec bezpieczeństwo sieci komputerowych

IPsec bezpieczeństwo sieci komputerowych IPsec bezpieczeństwo sieci komputerowych Bartłomiej Świercz Katedra Mikroelektroniki i Technik Informatycznych Łódź,18maja2006 Wstęp Jednym z najlepiej zaprojektowanych protokołów w informatyce jestprotokółipoczymświadczyfakt,żejestużywany

Bardziej szczegółowo

1. Wprowadzenie...9. 2. Środowisko multimedialnych sieci IP... 11. 3. Schemat H.323... 19

1. Wprowadzenie...9. 2. Środowisko multimedialnych sieci IP... 11. 3. Schemat H.323... 19 Spis treści 3 1. Wprowadzenie...9 2. Środowisko multimedialnych sieci IP... 11 2.1. Model odniesienia... 11 2.2. Ewolucja technologii sieciowych...12 2.3. Specyfika ruchowa systemów medialnych...13 2.4.

Bardziej szczegółowo

System Express ELIXIR

System Express ELIXIR System Express ELIXIR wybrane aspekty bezpieczeństwa Tomasz Jończyk Dyrektor Linii biznesowej rozliczenia Leszno, 15 marca 2013 roku 1 System Express ELIXIR System Express ELIXIR stanowi infrastrukturę

Bardziej szczegółowo

BeamYourScreen Bezpieczeństwo

BeamYourScreen Bezpieczeństwo BeamYourScreen Bezpieczeństwo Spis treści Informacje Ogólne 3 Bezpieczeństwo Treści 3 Bezpieczeństwo Interfejsu UŜytkownika 3 Bezpieczeństwo Infrastruktury 3 Opis 4 Aplikacja 4 Kompatybilność z Firewallami

Bardziej szczegółowo

Model sieci OSI, protokoły sieciowe, adresy IP

Model sieci OSI, protokoły sieciowe, adresy IP Model sieci OSI, protokoły sieciowe, adresy IP Podstawę działania internetu stanowi zestaw protokołów komunikacyjnych TCP/IP. Wiele z używanych obecnie protokołów zostało opartych na czterowarstwowym modelu

Bardziej szczegółowo

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie informatycznej. Zadaniem systemu jest rejestracja i przechowywanie

Bardziej szczegółowo

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU> Załącznik nr 4.4 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA numer wersji

Bardziej szczegółowo

ZAŁĄCZNIK NR 1 DO SIWZ OPIS PRZEDMIOTU ZAMÓWIENIA

ZAŁĄCZNIK NR 1 DO SIWZ OPIS PRZEDMIOTU ZAMÓWIENIA ZAŁĄCZNIK NR 1 DO SIWZ OPIS PRZEDMIOTU ZAMÓWIENIA Strona 1 z 7 Spis treści 1. Wprowadzenie... 3 2. Cel zamówienia... 3 3. Przedmiot zamówienia... 3 4. Etapy realizacji... 3 5. Wymagania... 4 5.1. Wymagania

Bardziej szczegółowo

Rywalizacja w sieci cd. Protokoły komunikacyjne. Model ISO. Protokoły komunikacyjne (cd.) Struktura komunikatu. Przesyłanie między warstwami

Rywalizacja w sieci cd. Protokoły komunikacyjne. Model ISO. Protokoły komunikacyjne (cd.) Struktura komunikatu. Przesyłanie między warstwami Struktury sieciowe Struktury sieciowe Podstawy Topologia Typy sieci Komunikacja Protokoły komunikacyjne Podstawy Topologia Typy sieci Komunikacja Protokoły komunikacyjne 15.1 15.2 System rozproszony Motywacja

Bardziej szczegółowo

Rozdział I Zagadnienia ogólne

Rozdział I Zagadnienia ogólne Załączniki do decyzji nr 2/11 Szefa Centralnego Biura Antykorupcyjnego z dnia 3 stycznia 2011 r. (poz. ) Załącznik nr 1 Instrukcja zarządzania systemem teleinformatycznym służącym do przetwarzania danych

Bardziej szczegółowo

Konfiguracja aplikacji ZyXEL Remote Security Client:

Konfiguracja aplikacji ZyXEL Remote Security Client: Połączenie IPSec VPN pomiędzy komputerem z zainstalowanym oprogramowaniem ZyWALL Remote Security Client, a urządzeniem serii ZyWALL. Przykład konfiguracji. Konfiguracja aplikacji ZyXEL Remote Security

Bardziej szczegółowo

Obszary potencjalnych zastosowań TETRA w praktyce morskiej

Obszary potencjalnych zastosowań TETRA w praktyce morskiej Forum TETRA Polska Obszary potencjalnych zastosowań TETRA w praktyce morskiej Ryszard J. Katulski Rafał Niski Jacek Stefański Jerzy Żurek Prezentacja zespołu Zespół Naukowo-Badawczy ds. Maritime Security

Bardziej szczegółowo

Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora

Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora Krzysztof Wertejuk audytor wiodący ISOQAR CEE Sp. z o.o. Dlaczego rozwiązania

Bardziej szczegółowo

Metodyka projektowania komputerowych systemów sterowania

Metodyka projektowania komputerowych systemów sterowania Metodyka projektowania komputerowych systemów sterowania Andrzej URBANIAK Metodyka projektowania KSS (1) 1 Projektowanie KSS Analiza wymagań Opracowanie sprzętu Projektowanie systemu Opracowanie oprogramowania

Bardziej szczegółowo

WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO WSPARCIA UŻYTKOWNIKÓW HELP DESK ORAZ ASYSTY TECHNICZNEJ

WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO WSPARCIA UŻYTKOWNIKÓW HELP DESK ORAZ ASYSTY TECHNICZNEJ Załącznik nr 6 do SIWZ WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO WSPARCIA UŻYTKOWNIKÓW HELP DESK ORAZ ASYSTY TECHNICZNEJ I. Warunki ogólne 1. Wykonawca zobowiązany jest do udzielenia Zamawiającemu gwarancji

Bardziej szczegółowo

INSTRUKCJA UŻYTKOWNIKA Repozytorium Dokumentów Elektronicznych KS-EDE ISO 9001:2008 Dokument: 2015.0.0.7 Wydanie: 2015-08

INSTRUKCJA UŻYTKOWNIKA Repozytorium Dokumentów Elektronicznych KS-EDE ISO 9001:2008 Dokument: 2015.0.0.7 Wydanie: 2015-08 Spis treści Wstęp... 2 1. System KS-EWD... 2 1.1. Instalacja KS-EWD... 2 2. Aktualizacja plików repozytorium Dokumentów... 4 2.1.1. Instalacja KS-EDE... 7 3. Integracja systemów... 8 4. Konfiguracja ustawień

Bardziej szczegółowo

Proces obsługi walnego zgromadzenia z perspektywy KDPW

Proces obsługi walnego zgromadzenia z perspektywy KDPW Proces obsługi walnego zgromadzenia z perspektywy KDPW Krzysztof Ołdak Dyrektor Działu Operacyjnego Krajowy Depozyt Papierów Wartościowych 17 lutego 2010 r. Zmiany KSH wynikają z 3 sierpnia 2009 r. Implementacja

Bardziej szczegółowo

fermacell AESTUVER Płyta przeciwpożarowa

fermacell AESTUVER Płyta przeciwpożarowa fermacell AESTUVER Płyta przeciwpożarowa Żegluga morska - dopuszczenie Moduł B Moduł D Deklaracja Zgodności Tłumaczenie z języka niemieckiego Europejska jednostka notyfikowana Numer identyfikacyjny 0736

Bardziej szczegółowo

Współpraca z platformą Emp@tia. dokumentacja techniczna

Współpraca z platformą Emp@tia. dokumentacja techniczna Współpraca z platformą Emp@tia dokumentacja techniczna INFO-R Spółka Jawna - 2013 43-430 Pogórze, ul. Baziowa 29, tel. (33) 479 93 29, (33) 479 93 89 fax (33) 853 04 06 e-mail: admin@ops.strefa.pl Strona1

Bardziej szczegółowo

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi Jerzy Brzeziński, Anna Kobusińska, Dariusz Wawrzyniak Instytut Informatyki Politechnika Poznańska Plan prezentacji 1 Architektura

Bardziej szczegółowo

Samokontrola postępów w nauce z wykorzystaniem Internetu. Wprowadzenie

Samokontrola postępów w nauce z wykorzystaniem Internetu. Wprowadzenie mgr Piotr Gaś, dr hab. inż. Jerzy Mischke Ośrodek Edukacji Niestacjonarnej Akademii Górniczo-Hutniczej w Krakowie Samokontrola postępów w nauce z wykorzystaniem Internetu Wprowadzenie W każdym systemie

Bardziej szczegółowo

INTERNET - Wrocław 2005. Usługi bezpieczeństwa w rozproszonych strukturach obliczeniowych typu grid

INTERNET - Wrocław 2005. Usługi bezpieczeństwa w rozproszonych strukturach obliczeniowych typu grid Usługi bezpieczeństwa w rozproszonych strukturach obliczeniowych typu grid Bartłomiej Balcerek Wrocławskie Centrum Sieciowo-Superkomputerowe Plan prezentacji Podstawowe pojęcia z dziedziny gridów Definicja

Bardziej szczegółowo

Pobieranie komunikatów GIF

Pobieranie komunikatów GIF Spis treści Wstęp... 2 1. Ustawienia harmonogramu zadań... 3 1.1. Tryby pracy AswPlan... 3 2. System KS-EWD... 4 2.1. Instalacja KS-EWD... 5 3. Inauguracja OSOZ... 6 3.1. Zdefiniowanie zadania pobierania

Bardziej szczegółowo

Web Services. Bartłomiej Świercz. Łódź, 2 grudnia 2005 roku. Katedra Mikroelektroniki i Technik Informatycznych. Bartłomiej Świercz Web Services

Web Services. Bartłomiej Świercz. Łódź, 2 grudnia 2005 roku. Katedra Mikroelektroniki i Technik Informatycznych. Bartłomiej Świercz Web Services Web Services Bartłomiej Świercz Katedra Mikroelektroniki i Technik Informatycznych Łódź, 2 grudnia 2005 roku Wstęp Oprogramowanie napisane w różnych językach i uruchomione na różnych platformach może wykorzystać

Bardziej szczegółowo

SZCZEGÓŁOWY OPIS PRZEDMIOTU ZMÓWIENIA

SZCZEGÓŁOWY OPIS PRZEDMIOTU ZMÓWIENIA SZCZEGÓŁOWY OPIS PRZEDMIOTU ZMÓWIENIA Przedmiot zamówienia Przedmiotem zamówienia jest instalacja systemu wydawania kluczy w obiekcie PGE Dystrybucja S.A. Oddział Łódź Miasto znajdującym się w Zgierzu,

Bardziej szczegółowo

2.11. Monitorowanie i przegląd ryzyka 2.12. Kluczowe role w procesie zarządzania ryzykiem

2.11. Monitorowanie i przegląd ryzyka 2.12. Kluczowe role w procesie zarządzania ryzykiem Spis treści Wstęp 1. Wprowadzenie 1.1. Co to jest bezpieczeństwo informacji? 1.2. Dlaczego zapewnianie bezpieczeństwa informacji jest potrzebne? 1.3. Cele, strategie i polityki w zakresie bezpieczeństwa

Bardziej szczegółowo

Uniwersalny Konwerter Protokołów

Uniwersalny Konwerter Protokołów Uniwersalny Konwerter Protokołów Autor Robert Szolc Promotor dr inż. Tomasz Szczygieł Uniwersalny Konwerter Protokołów Szybki rozwój technologii jaki obserwujemy w ostatnich latach, spowodował że systemy

Bardziej szczegółowo

Spis treści Wstęp 1. Wprowadzenie 2. Zarządzanie ryzykiem systemów informacyjnych

Spis treści Wstęp 1. Wprowadzenie 2. Zarządzanie ryzykiem systemów informacyjnych Wstęp... 13 1. Wprowadzenie... 15 1.1. Co to jest bezpieczeństwo informacji?... 17 1.2. Dlaczego zapewnianie bezpieczeństwa informacji jest potrzebne?... 18 1.3. Cele, strategie i polityki w zakresie bezpieczeństwa

Bardziej szczegółowo

Wydział Informatyki, Elektroniki i Telekomunikacji Katedra Telekomunikacji

Wydział Informatyki, Elektroniki i Telekomunikacji Katedra Telekomunikacji Wydział Informatyki, Elektroniki i Telekomunikacji Katedra Telekomunikacji Bezpieczeństwo sieci teleinformatycznych Laboratorium 5 Temat: Polityki bezpieczeństwa FortiGate. Spis treści 2. Cel ćwiczenia...

Bardziej szczegółowo

MODEL OSI A INTERNET

MODEL OSI A INTERNET MODEL OSI A INTERNET W Internecie przyjęto bardziej uproszczony model sieci. W modelu tym nacisk kładzie się na warstwy sieciową i transportową. Pozostałe warstwy łączone są w dwie warstwy - warstwę dostępu

Bardziej szczegółowo

Protokół wymiany sentencji, wersja 1

Protokół wymiany sentencji, wersja 1 Protokół wymiany sentencji, wersja 1 Sieci komputerowe 2011@ MIM UW Osowski Marcin 28 kwietnia 2011 1 Streszczenie Dokument ten opisuje protokół przesyłania sentencji w modelu klientserwer. W założeniu

Bardziej szczegółowo

Infrastruktura klucza publicznego w sieci PIONIER

Infrastruktura klucza publicznego w sieci PIONIER Infrastruktura klucza publicznego w sieci PIONIER Ireneusz Tarnowski Konferencja i3 Wrocław, 2 grudnia 2010 Plan wystąpienia PKI Infrastruktura Klucza Publicznego Zastosowania certyfikatów X.509 Jak to

Bardziej szczegółowo

Wykład 3 / Wykład 4. Na podstawie CCNA Exploration Moduł 3 streszczenie Dr inż. Robert Banasiak

Wykład 3 / Wykład 4. Na podstawie CCNA Exploration Moduł 3 streszczenie Dr inż. Robert Banasiak Wykład 3 / Wykład 4 Na podstawie CCNA Exploration Moduł 3 streszczenie Dr inż. Robert Banasiak 1 Wprowadzenie do Modułu 3 CCNA-E Funkcje trzech wyższych warstw modelu OSI W jaki sposób ludzie wykorzystują

Bardziej szczegółowo

Dane osobowe: Co identyfikuje? Zgoda

Dane osobowe: Co identyfikuje? Zgoda Luty 2009 Formalności Na podstawie ustawy z dnia 22 stycznia 1999 r., o ochronie informacji niejawnych (Dz. U. Nr 11, poz. 95 z późniejszymi zmianami) i rozporządzenia Prezesa Rady Ministrów z 25 lutego

Bardziej szczegółowo

11. Autoryzacja użytkowników

11. Autoryzacja użytkowników 11. Autoryzacja użytkowników Rozwiązanie NETASQ UTM pozwala na wykorzystanie trzech typów baz użytkowników: Zewnętrzna baza zgodna z LDAP OpenLDAP, Novell edirectory; Microsoft Active Direcotry; Wewnętrzna

Bardziej szczegółowo

AKADEMIA GÓRNICZO-HUTNICZA Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki

AKADEMIA GÓRNICZO-HUTNICZA Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki AKADEMIA GÓRNICZO-HUTNICZA Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki KATEDRA INFORMATYKI Mobicents VoIP Projekt wykonany w ramach SIUS i IOSR Biolik Wojciech Błazej Kardyś Informatyka,

Bardziej szczegółowo

POLITYKA PRYWATNOŚCI STRONY INTERNETOWEJ www.mektal.pl P.P.U.H. i T. MEKTAL Obowiązujące od dnia 30.07.2015. 1. Wstęp... 2

POLITYKA PRYWATNOŚCI STRONY INTERNETOWEJ www.mektal.pl P.P.U.H. i T. MEKTAL Obowiązujące od dnia 30.07.2015. 1. Wstęp... 2 POLITYKA PRYWATNOŚCI STRONY INTERNETOWEJ www.mektal.pl P.P.U.H. i T. MEKTAL Obowiązujące od dnia 30.07.2015 Spis treści 1. Wstęp... 2 2. Postanowienia ogólne... 2 3. Dane użytkownika... 3 4. Dane osobowe...

Bardziej szczegółowo

ROZPORZĄDZENIE MINISTRA INFRASTRUKTURY 1) z dnia 2010 r. w sprawie wyposażania statków w System Identyfikacji i Śledzenia Dalekiego Zasięgu 2)

ROZPORZĄDZENIE MINISTRA INFRASTRUKTURY 1) z dnia 2010 r. w sprawie wyposażania statków w System Identyfikacji i Śledzenia Dalekiego Zasięgu 2) ROZPORZĄDZENIE MINISTRA INFRASTRUKTURY 1) z dnia 2010 r. w sprawie wyposażania statków w System Identyfikacji i Śledzenia Dalekiego Zasięgu 2) Na podstawie art. 16c ust. 4 ustawy z dnia 9 listopada 2000

Bardziej szczegółowo

Zapytanie ofertowe na dostawę:

Zapytanie ofertowe na dostawę: Wrocław, dnia 09.08.2010 r. Zapytanie ofertowe na dostawę: Systemu składającego się z aplikacji modułowej, która zapewni zautomatyzowany, swobodny i bezpieczny przepływ danych i informacji finansowo księgowych

Bardziej szczegółowo

Aplikacje webowe na celowniku. Leszek Miś IT Security Architect RHCA,RHCSS,Sec+ Linux Polska Sp. z o.o. 1

Aplikacje webowe na celowniku. Leszek Miś IT Security Architect RHCA,RHCSS,Sec+ Linux Polska Sp. z o.o. 1 Aplikacje webowe na celowniku. Leszek Miś IT Security Architect RHCA,RHCSS,Sec+ Linux Polska Sp. z o.o. 1 Fakty Złożona i rozbudowana architektura: błędy w kodzie błędy w konfiguracji błędy w założeniach

Bardziej szczegółowo