Maritime University of Szczecin
Akademia Morska w Szczecinie
2008, 13(85) pp. 65‐73 2008, 13(85) s. 65‐73
Model systemu wspomagania decyzji nawigacyjnych
na statku morskim
Model of navigational decision support system
on a sea-going vessel
Zbigniew Pietrzykowski, Janusz Magaj, Jarosław Chomski
Akademia Morska w Szczecinie, Instytut Nawigacji Morskiej 70-500 Szczecin, ul. Wały Chrobrego 1–2, tel. 091 48 09 496,
e-mail: zbip@am.szczecin.pl, janmag@am.szczecin.pl, jarc@am.szczecin.pl
Słowa kluczowe: wspomaganie decyzji, statek morski, nawigacja Abstrakt
Złożoność procesu prowadzenia nawigacji i konieczność zapewnienia możliwie wysokiego poziomu bezpie-czeństwa wymusza podejmowanie prac nad nawigacyjnymi systemami wspomagania decyzji. W artykule przedstawiono założenia oraz model projektowanego systemu. Do modelowania systemu zastosowano język UML (Unified Modeling Language). Pozwala on przedstawić projektowany system w różnych perspekty-wach w sposób czytelny zarówno dla przyszłych użytkowników, jak też jego twórców: analityków, projek-tantów i programistów. Opracowany model jest prototypem projektowanego systemu wspomagania decyzji nawigacyjnych na statku morskim.
Key words: decision support, sea going vessel, navigation Abstract
The complexity of the navigation process and necessity of ensuring a possibly high level of safety, with con-tinually growing vessel traffic intensity, ships’ tonnage and speeds developed at sea, call for research on navigational decision support systems. This article presents the assumptions and a model of such system de-sign. The Unified Modeling Language (UML) has been used for system modelling. The UML allows present-ing the designed system from various perspectives in a manner easily perceived by its future users as well as its creators: analysts, designers and programmers. The developed model provides a basis for building a proto-type of the designed system of navigational decision support on the sea going vessel.
Założenia systemu
Potencjalne źródło błędów ludzkich skutkują-cych wypadkami morskimi stanowi nadmiar na-pływających informacji i wynikające stąd trudności z ich przetworzeniem oraz wykorzystaniem. Dużo uwagi poświęca się zagadnieniom eliminowania lub ograniczenia błędów ludzkich poprzez budowę systemów wspomagania decyzji nawigatora. Roz-wój nowoczesnych technik i technologii informa-tycznych stwarza odpowiednie możliwości do bu-dowy takich systemów. Podstawowymi zadaniami projektowanego nawigacyjnego systemu wspoma-gania decyzji są [1]:
– automatyczne pozyskiwanie i dystrybucja infor-macji nawigacyjnej,
– analiza sytuacji nawigacyjnej i rozwiązywanie sytuacji kolizyjnych,
– interakcja z nawigatorem.
System powinien umożliwić m.in. realizację na-stępujących zadań:
– sygnalizowanie sytuacji niebezpiecznych oraz aktualnego poziomu bezpieczeństwa nawigacyj-nego na podstawie kryteriów stosowanych przez ekspertów nawigatorów,
– automatyczne wyznaczanie manewru/manew-rów i trajektorii ruchu w sytuacjach kolizyjnych,
Rys. 1. Ogólna architektura systemu wspomagania decyzji nawigacyjnych na statku morskim Fig. 1. General architecture of the navigational support system on a sea going vessel
– możliwość objaśniania (uzasadnienia) wyboru proponowanego manewru,
– czytelne dla nawigatora zobrazowanie sytuacji nawigacyjnej.
Projektowany system jest przykładem systemu czasu rzeczywistego. Jego zadaniem jest obserwa-cja statku i środowiska, rejestraobserwa-cja informacji nawi-gacyjnych, ich selekcja, ekstrakcja, weryfikacja i przetwarzanie. Rezultatem procesów przetwarza-nia będą prezentowane nawigatorowi informacje dotyczące identyfikacji i oceny sytuacji nawigacyj-nej oraz proponowane rozwiązania (decyzje) za-pewniające bezpieczną żeglugę.
Ogólną architekturę systemu przedstawiono na rysunku 1. O skuteczności i przydatności systemu w dużym stopniu będzie decydował m.in. moduł interakcji (komunikacji) z operatorem.
Nawigacyjny system wspomagania decyzji ma być uzupełnieniem wyposażenia nawigacyjnego statku. Jego prawidłowe funkcjonowanie wymaga współdziałania z urządzeniami i systemami na stat-ku. Standardowe wyposażenie statku obejmuje: log, żyrokompas, radar, echosondę, ARPA (Automatic
Radar Plotting Aids), ECDIS (Electronic Chart Display and Information System). Informacje
uzy-skiwane z systemu ECDIS stanowią sumę informa-cji uzyskiwanych z urządzeń współpracujących z tym systemem: logu, radaru, ARPA, echosondy, GNSS (Global Navigational Satellite System), np. GPS (Global Positioning System), DGPS (Differential Global Positioning System) – i innych. Różnorodne środki łączności i systemy komunika-cji umożliwiają przesyłanie na statek informakomunika-cji nawigacyjnych oraz innych uzupełniających, zwią-zanych z realizacją podróży: AIS – (Automatic
Identification System), GMDSS – (Global Maritime Distress and Safety System), systemy VTS (Vessel Traffic Service).
Modelowanie systemów czasu rzeczywistego
Systemy czasu rzeczywistego są systemami uwarunkowanymi czasowo. Charakteryzują się m.in. [2, 3]:
– rodzajem ograniczeń czasowych (systemy moc-no i słabo uwarunkowane czasowo),
– obsługą/współdziałaniem z wieloma urządze-niami,
– nieregularnością i różnymi priorytetami obsługi-wanych zdarzeń,
– ograniczonymi zasobami (pamięć, moc oblicze-niowa),
– uwarunkowaną czasowo obsługą rozproszonych i współbieżnie realizowanych zadań,
– wymaganą odpornością na różnego rodzaju błędy.
Podstawowe znaczenie w modelowaniu systemu ma określenie wymagań wobec projektowanego systemu: funkcjonalnych i niefunkcjonalnych. Wy-magania funkcjonalne opisują czynności i operacje wykonywane przez system, w tym sposoby reakcji na określone zdarzenia. Do opisu wymagań funk-cjonalnych stosuje się m.in. narzędzia UML w po-staci diagramów przypadków użycia (perspektywa przypadków użycia).
Wymagania niefunkcjonalne opisują ogranicze-nia, przy których system ma realizować swoje funkcje. Wśród wymagań niefunkcjonalnych wy-różnia się wymagania produktowe, organizacyjne i zewnętrzne. Pierwsze z nich dotyczą m.in. sposo-bu komunikacji z operatorem, efektywności obli-czeniowej (w tym czasów odpowiedzi na zdarze-nia/bodźce) i niezawodności systemu. Ze względu na uwarunkowania czasowe niezbędna jest identy-fikacja zdarzeń (bodźców) i skojarzonych z nimi odpowiedzi systemu oraz wymagań czasowych
z nimi związanych. Wymagania organizacyjne wy-nikają z obowiązujących strategii w zakresie dzia-łania systemu. Definiują m.in. stosowane protokoły komunikacyjne, obowiązujące procedury oraz wy-magane standardy dla rzeczywistych procesów modelowanych w systemie. Wymagania zewnętrz-ne są związazewnętrz-ne z koniecznością uwzględnienia środowiska zewnętrznego. Są to m.in. wymagania dotyczące współpracy z systemami zewnętrznymi, prawne i etyczne.
Obok perspektywy przypadków użycia, definiu-jącej zakres i oczekiwaną funkcjonalność systemu, istotne z punktu widzenia modelowania projekto-wanego systemu są perspektywy: logiczna, dyna-miczna, komponentów i rozlokowania. Każda z perspektyw uwypukla inne aspekty architektury systemu [4]. Umożliwia to opis systemu uwzględ-niający różne punkty widzenia użytkowników i twórców (analityków, projektantów i programi-stów) oraz systemu.
Perspektywa logiczna dokumentuje statykę (strukturę) systemu. Ma ona na celu określenie obiektów (bytów) występujących w projektowanym systemie oraz relacji występujących między nimi. Do jej opisu stosowane są narzędzia UML w postaci diagramów klas, obiektów i pakietów. Pakiety, będące agregatami bytów, umożliwiają wyeksponowanie zasadniczych funkcji systemu.
Perspektywa dynamiczna opisuje zachowanie systemu. Służą do tego diagramy maszyny stano-wej, czynności i interakcji (komunikacji, sekwencji i interakcji). Perspektywa dynamiczna ma szcze-gólne znaczenie dla opisu systemów czasu rzeczy-wistego.
Perspektywa komponentów dokumentowana jest za pomocą diagramów komponentów i diagramów pakietów. Komponent jest modułem kodu. Diagram komponentów jest fizycznym odpowiednikiem diagramów klas. Dzieli system na fizyczne elemen-ty (moduły) oprogramowania: pliki, biblioteki, wykonywalne programy itp.
Perspektywa rozlokowania realizowana z wyko-rzystaniem diagramów rozlokowania i diagramów pakietów dokumentuje sprzęt informatyczny oraz jego powiązania z komponentami (oprogramowa-nie) systemu.
Diagramy komponentów i diagramy rozlokowa-nia dokumentują fizyczną strukturę projektowanego systemu i zaliczane są do tzw. diagramów wdroże-niowych.
Modelowanie systemu z wykorzystaniem wy-mienionych narzędzi (diagramów UML) umożliwia uwypuklenie różnych aspektów architektury syste-mu z jednoczesnym pominięciem innych, nie-istotnych dla danego punktu widzenia szczegółów.
Pozwala to na pełniejszy opis projektowanego sys-temu, odpowiadający kompetencjom zawodowym i organizacyjnym uczestników procesu tworzenia systemu i przyszłych użytkowników.
Z punktu widzenia procesu prowadzenia statku, nawigacyjny system wspomagania decyzji jest sys-temem silnie uwarunkowanym czasowo. Wynika to z konieczności szybkiego reagowania na zdarzenia przy określonych obowiązujących zasadach doty-czących czasu odpowiedzi. Do jego opisu zastoso-wano scharakteryzowane powyżej perspektywy. Prezentując opracowany model systemu wspoma-gania decyzji nawigatora, przedstawiono wybrane, przykładowe diagramy definiujące strukturę i za-chowanie systemu. Wykorzystano do tego celu oprogramowanie ModelMaker.
Perspektywa przypadków użycia
W celu określenia wymagań funkcjonalnych projektowanego systemu zdefiniowano użytkowni-ka systemu (nawigator – operator), reprezentowa-nego w procesie modelowania UML przez tzw. aktora. Przypisano mu wymagane przez niego funkcje systemu. Grupę aktorów uzupełniono, zgodnie z konwencją języka UML, o systemy ze-wnętrzne wykorzystywane przez system. Stanowią ją urządzenia i systemy nawigacyjne, w tym syste-my ARPA, AIS, GPS, log, żyrokompas i inne.
Ustalono obowiązujące procedury i przepisy do-tyczące podejmowania decyzji w procesie prowa-dzenia nawigacji na statku. Do określenia wymagań funkcjonalnych wykorzystano diagramy przypad-ków użycia.
Nawigator
System wspomagania decyzji
Użycie GUI Ocena sytuacji nawigacyjnej Wypracowanie manewru Konfigurowanie systemu Wyświetlenie predykcji sytuacji nawigacyjnej Wykonanie archiwizacji danych
Rys. 2. Główne przypadki użycia systemu wspomagania decy-zji nawigacyjnych na statku morskim
Fig. 2. Diagram of main use cases of the navigational support system on a sea going vessel
Najistotniejsze usługi (funkcje) systemu wyma-gane przez nawigatora przedstawiono w postaci diagramu przypadków użycia na rysunku 2.
Zaliczono do nich: 1) komunikację użytkownika z systemem (użycie interfejsu operatora GUI); 2) ocenę sytuacji zgodną z obowiązującymi przepi-sami i kryteriami oceny zdefiniowanymi przez nawigatora; 3) wypracowanie manewru w sytuacji kolizyjnej; 4) prezentację prognozy sytuacji dla zadanego horyzontu czasowego (predykcja sytu-acji); 5) rejestrację (archiwizację) danych, w tym poleceń nawigatora, w celu odtworzenia podróży morskiej; 6) konfigurowanie systemu – zmianę domyślnych ustawień i dostosowanie do indywidu-alnych wymagań nawigatora oraz aktualnie warun-ków nawigacyjnych (np. modyfikacja kryteriów oceny sytuacji).
Tabela 1 Scenariusz przypadku użycia „wypracowanie ma-newru”
Table 1. Scenario of use case “manoeuvre planning“ Przypadek
użycia Wypracowanie manewru
Aktorzy Nawigator; Czas; Sensory; Moduł analiza sytu-acji
Krótki opis Nawigator żąda wypracowania dopuszczalnych manewrów w aktualnej sytuacji nawigacyjnej Warunki
wstępne
Sytuacja nawigacyjna określona jako niebez-pieczna (Moduł ocena sytuacji)
Warunki
końcowe Lista wypracowanych manewrów
Scenariusz główny
1. Nawigator inicjuje wypracowanie manewru 2. Dane z sensorów (od wszystkich obiektów)
zostają zintegrowane.
3. Za pomocą dostępnych metod wyznaczane są dopuszczalne manewry (trajektorie). 4. Moduł udostępnia listę wypracowanych
ma-newrów
Scenariusze alternatywne
1 a. Moduł analiza sytuacji aktywuje żądanie wypracowania manewru
4 a. Nawigator przegląda trajektorie wypracowa-nych manewrów
Specjalne wymagania
Wyprzedzenie czasowe dla manewru
Limit czasu obliczeń na wypracowanie manewru Limit czasu, po którym Moduł analiza sytuacji aktywuje wypracowanie manewru
Komentarze Manewry z listy wypracowanych manewrów udostępniane są nawigatorowi Komentarze Brak
Dla pełniejszego opisu wymagań sporządzono tzw. scenariusze przypadków użycia. Są one przed-stawiane w formie tekstowej i określają ciąg czyn-ności wykonywanych przez aktora lub system. Przykładowy scenariusz przypadku użycia „wypra-cowanie manewru” przedstawiono w tabeli 1. Określono w nim m.in. warunki inicjujące przypa-dek, scharakteryzowano stan systemu po realizacji przypadku i scenariusz główny. Zdefiniowano listę możliwych, alternatywnych scenariuszy oraz
wymagania niefunkcjonalne istotne dla realizacji (implementacji w systemie) przypadku użycia.
W analizie wymagań niefunkcjonalnych szcze-gólną uwagę zwrócono na wymagania czasowe. Zidentyfikowano zdarzenia i skojarzone z nimi odpowiedzi (reakcje) systemu oraz określono wy-magania. Do zdarzeń istotnych z punktu widzenia bezpieczeństwa nawigacyjnego zaliczono: pojawie-nie się nowego obiektu (statku) w systemie, zmianę parametrów ruchu obiektu/obiektów, wystąpienie (wykrycie) sytuacji niebezpiecznej, polecenia Nawigatora oraz czas systemowy.
Perspektywa logiczna
Perspektywę logiczną modelowanego systemu opisano przy użyciu diagramów klas i diagramów pakietów. Zidentyfikowano obiekty istotne dla re-alizacji celów systemu. Wyróżniono podstawowe klasy stanowiące uogólnienie występujących obiek-tów, charakteryzujących się (identycznymi): struk-turą danych, związkami i zachowaniem: statek, ko-munikat, manewr, sytuacja. Zdefiniowano związki występujące między nimi (asocjacje, uogólnienia, zależności i realizacje). Wyróżnionym klasom przypisano metody (zestawy operacji) realizowane w ich środowisku. Przedstawiono je na rysunku 3.
Na podstawie przeprowadzonej analizy mode-lowanego systemu, w celu wyeksponowania zasad-niczych funkcji systemu, opracowano diagramy pakietów, stanowiące agregację elementów modelu. Rysunek 4 przedstawia wyróżnione podstawowe pakiety systemu. Wyróżniono pakiety: informacyj-ny (rejestracji dekodowania i interpretacji komuni-katów z systemów i urządzeń zewnętrznych), iden-tyfikacji zdarzeń, analizy i oceny sytuacji, wyboru manewru, predykcji ruchu, zarządzający, bazy wie-dzy oraz bibliotekę procedur nawigacyjnych.
Szczególną uwagę zwrócono na dwa ostatnie. W pakiecie bazy wiedzy zawarto m.in. algorytmy interpretacji przepisów prawa drogi (MPDM) oraz kryteria analizy i oceny sytuacji, z możliwością ich personalizacji, tzn. ich modyfikacji zgodnie z prefe-rencjami poszczególnych użytkowników systemu (nawigatorów). Pakiet ten pełni funkcje usługowe dla pakietów: nawigacyjnego, wypracowania ma-newru oraz śledzenia trajektorii ruchu.
Ze względu na specyfikę projektowanego sys-temu (system czasu rzeczywistego) wyodrębniono pakiet zarządzający. Jego głównym zadaniem jest m.in. analiza zdarzeń, szeregowanie zadań i zarzą-dzanie zasobami systemu (aktywacja zadań i przy-dzielanie zasobów systemu niezbędnych do ich realizacji).
Rys. 3. Diagramy klas modelowanego systemu Fig. 3. Class diagrams of the system model
Rys. 4. Diagram pakietów systemu wspomagania decyzji nawigatora Fig. 4. Package diagram of the navigational support system
Statek Statek_własny Statek_obcy DaneGPS DaneZyrokompas DaneLOG DaneARPA Historia Dane DaneAIS
Perspektywa dynamiczna
Do opisu (zdefiniowania) zachowania systemu zastosowano diagramy sekwencji, komunikacji i maszyny stanowej. Przykładowo, proces wyzna-czania manewru (wypracowanie i wybór manewru) zilustrowano z wykorzystaniem diagramu sekwen-cji (rys. 5).
Skuteczność działania systemu zależy w dużej mierze od pozyskiwania, interpretacji i udostępnia-nia informacji o sytuacji nawigacyjnej (sensory). Procesy te opisano z wykorzystaniem diagramów komunikacji. Na rysunku 6 przedstawiono jeden z diagramów, charakteryzujący powiązania między obiektami systemu (sensory, statek, sytuacja), oraz komunikację (przepływ komunikatów) pomiędzy nimi.
Diagramy maszyny stanowej stanowią istotne uzupełnienie opisu zachowania systemu, szczegól-nie w przypadku systemów czasu rzeczywistego. Dokumentują sekwencje stanów (także procesów), w których znajduje się obiekt, w odpowiedzi na zdarzenia zachodzące w trakcie funkcjonowania systemu. Na rysunku 7 przedstawiono przejścia
między dwoma, z punktu widzenia prowadzenia nawigacji, podstawowymi stanami systemu: sytu-acją bezpieczną i sytusytu-acją niebezpieczną. Zazna-czono zdarzenia aktywujące przejścia między nimi. Wyróżniono tu dodatkowo tzw. pseudostan oceny sytuacji nawigacyjnej, istotny dla opisu przejścia między wcześniej wymienionymi stanami.
Modelowanie z użyciem diagramów maszyny stanowej pozwala uwzględnić współbieżność akty-wowania różnych stanów systemu. Na rysunku 8 przedstawiono tzw. obszary współbieżne, aktywo-wane z chwilą uruchomienia systemu, charaktery-zujące interakcję systemu z użytkownikiem. Są to: zarządzanie interakcją i komunikatami systemu oraz prezentacja sytuacji nawigacyjnej.
Dotyczy to także modelowania zachowania sys-temu z uwzględnieniem współbieżności procesów analizy i oceny sytuacji, wypracowania manewru (rys. 9).
W analogiczny sposób, zgodnie z przyjętą me-todyką, sporządzono diagramy opisujące pozostałe aspekty zachowania systemu. Pozwoliło to opraco-wać model zgodnie z wymaganiami użytkowników.
Rys. 5. Diagram sekwencji dla procesu wyznaczania manewru Fig. 5. Sequence diagram of manoeuvre determination process
«actor» AIS «actor» GPS : Komunikat_Sensory : Komunikat_AIS : Komunikat_GPS : Statek 1: mesage 8: message 4: Wyslij_komunikat 13: Wyslij_komunikat 10: zapisz_sytuacje 2: Odczytaj_komunikat 3: Spraw dz_typ_komunikatu 9: Odczytaj_komunikat 11: Spraw dz_typ_komunikatu 5: jaki_nr_komunikatu 6: Dekoduj_komunikat1 7: Jaki_MMSI 12: zapisz_sytuacje 14: Jaki_Typ 15: Dekoduj_GLL 16: zapisz_sytuacje
Rys. 6. Diagram komunikacji w procesie odbioru, rejestracji i interpretacji komunikatów (sensory) Fig. 6. Diagram of communication in the process of reception, registration and interpretation (sensors)
Rys. 7. Diagram maszyny stanowej systemu wspomagania decyzji nawigatora Fig. 7. State machine diagram of the navigational support system
Rys. 8. Diagram maszyny stanowej interfejsu użytkownika (GUI) Fig. 8. State machine diagram of graphic user interface
Rys. 9. Współbieżność procesów oceny sytuacji oraz wypracowania manewru Fig. 9. Concurrency of processes situation assessment and manoeuvre planning
Podsumowanie
Złożoność projektowanego systemu wspomaga-nia decyzji, w tym współbieżność procesów reali-zowanych przez system oraz stawiane mu wyma-gania (funkcjonalne i niefunkcjonalne) wymuszają opracowanie modelu uwzględniającego punkty widzenia przyszłych użytkowników. Opracowany model powinien jednocześnie precyzyjnie definio-wać zadania stawiane projektantom i
programi-stom. Realizując powyższe cele, do budowy mode-lu projektowanego systemu zastosowano język modelowania UML.
Opracowane modele systemu wspomagania de-cyzji nawigatora na statku morskim (diagramy wdrożeniowe) pozwalają na perspektywiczne zre-alizowanie systemu spójnego i czytelnego zarówno dla użytkowników, jak i tworzących go, który speł-nia wymagaspeł-nia stawiane tego typu systemom.
Bibliografia
1. PIETRZYKOWSKI Z., CHOMSKI J., MAGAJ J., BĄK A., URIASZ J.: Aims and tasks of the navigational support system on a sea going vessel. Advanced in Transport Systems Telematics 2, Ed. J. Mikulski, Publisher Faculty of Trans-port, Silesian University, Katowice 2007.
2. DĄBROWSKI W., STASIAK A., WOLSKI M.: Modelowanie systemów informatycznych w języku UML 2.1. WN PWN SA, Warszawa 2007.
3. SOMMERVILLE I.: Inżynieria oprogramowania. Wydawnictwa Naukowo-Techniczne, Warszawa 2003.
4. WRYCZA S., MARCINKOWSKI B., WYRZYKOWSKI K.: Język UML 2.0 w modelowaniu systemów informatycznych. Helion, Gliwice 2005.
Recenzent: dr hab. inż. Lucjan Gucma, prof. AM Akademia Morska w Szczecinie
