SCENARIUSZ WDROŻEŃ INTELIGENTNYCH SYSTEMÓW TRANSPORTOWYCH W OPARCIU O EUROPEJSKĄ ARCHITEKTURĘ FRAME

Transkrypt

1 Polski Kongres ITS Mgr inż. Krzysztof ewski 1 SCENARIUSZ WDROŻEŃ INTELIGENTNYCH SYSTEMÓW TRANSPORTOWYCH W OPARCIU O EUROPEJSKĄ ARCHITEKTURĘ FRAME W referacie przedstawiono znaczenie opracowania Architektury ITS. Artykuł zwraca uwagę na brak interopracyjności pomiędzy istniejącymi rozwiązaniami i proponuje cztery scenariusze wdrożeń Inteligentnych Systemów Transportowych w oparciu o Europejską Architekturę FRAME. Słowa kluczowe: Inteligentne Systemy Transportowe, Architektura ITS, FRAME, KAITS, INTELLIGENT TRANSPORT SYSTEMS DEPLOYMENT APPROACH AND SCENARIOS BASED ON EUROPEAN ITS FRAMEWORK ARCHITECTURE The paper presents deployment scenarios for Intelligent Transport Systems. It shows four types of architectures and points which type and scenario is the best for Poland. The article lists main causes of failure, challenge or success IT related projects and shows why ITS Architecture is important for development of ITS Services. Key words: Intelligent Transport Systems, ITS Architecture, FRAME, KAITS, 1. WPROWADZENIE Złożoność i interdyscyplinarność Inteligentnych Systemów Transportowych wymaga planowego podejścia do wdrożenia systemów telematyki transportu. Skomplikowanie w/w systemów objawia się w postaci integracji poszczególnych komponentów (składników systemów), które często są zamawiane u różnych dostawców, a w wielu przypadkach nie istnieją w momencie zamówienia danego systemu przez podmiot publiczny. W chwili oddania systemu do użytku komponenty mogą być także zarządzanie przez inne podmioty. Mimo złożoności systemów ITS istotne jest, aby wszystkie usługi działały w sposób przezroczysty dla użytkownika końcowego, który wymaga ich niezawodnego działania[1,7,8]. Jednym z najważniejszych zadań jakie stawiają sobie państwa wprowadzając inteligentne rozwiązania w transporcie jest ustanowienie architektury ITS, czyli szeregu powiązań (logicznych, fizycznych i komunikacyjnych) pomiędzy elementami systemów jakie tworzą Inteligentne Systemy Transportowe w celu stworzenia rozwiązań skalowalnych, łatwych w utrzymaniu i zarządzaniu. Krajowe architektury nie wskazują konkretnych technologii lub dostawcy, dzięki temu stają się otwartymi systemami zwiększającymi konkurencyjność implementowanych rozwiązań. Obecnie w Polsce rozwiązania ITS mają charakter wyspowy, tzn. iż oddzielnie spełniają zadaną rolę, natomiast w przypadku ich połączenia może dojść do sytuacji, w której systemy te są niekompatybilne i nie będą mogły ze sobą współpracować nie przynosząc tym samym potencjalnych korzyści.[3,9] 2. ZARZĄDZANIE PROJEKTAMI A ARCHITEKTURA ITS Według raportu Chaos Report 2 opracowanego przez Standish Group w 2009 r., wśród dziesięciu najważniejszych czynników wpływających na sukces projektu aż cztery są związane z analizą 1 OpenSky Systems and Services Sp. z o.o., ul. Trębacka 4, Warszawa, kmodelewski@openskyservices.com

2 mgr inż. Krzysztof ewski wymagań. Należy zwrócić uwagę, iż niekompletne wymagania stają się najczęstszą przyczyną niepowodzeń w realizacji projektów. Tabela 1. Istotność czynników wpływających na sukces i niepowodzenie projektu[4] Istotność Nazwa czynnika sukcesu 3 Nazwa czynnika problemu 4 Nazwa czynnika niepowodzenia 5 1 Zaangażowanie Brak wkładu Niekompletne użytkowników (15,9%) 2 Wsparcie kierownictwa (13,9%) użytkowników (12.8%) Niekompletne wymagania i specyfikacje (12.3%) wymagania(13.1%) Brak zaangażowania użytkowników (12.4%) 3 Jasno określone wymagania (13%) Zmiana wymagań i specyfikacji (11.8%) Brak zasobów (10.6%) 4 Właściwe planowanie (9.6%) Brak wsparcia kierownictwa (7.5%) Nierealistyczne wymagania (9.9%) 5 Realistyczne oczekiwania (8.2%) Niekompetencja pod względem technologii Brak wsparcia kierownictwa (9.3%) (7.0%) 6 Mniejsze kroki milowe (7.7%) Brak zasobów (6.4%) Zmiana wymagań i specyfikacji (8.7%) 7 Kompetentny zespół (7.2%) Unrealistic Expectations (5.9 %) Brak planowania (8.1%) 8 Ownership (5.3%) Niejasne cele (5.3%) Didn't Need It Any Longer (7.5%) 9 Jasna wizja i cele (2.9%) Nierealistyczne ramy czasowe (4.3%) Brak zarządzania IT (6.2%) 10 Pracowity zespół (2.4%) Nowa technologia (3.7%) Brak wiedzy o technologii (4.3%) Architektura ITS ma istotny wpływ na określenie wymagań, zatem w powyższej tabeli zaznaczono pogrubionym kolorem obszary, w których występuje ścisły związek z analizą wymagań. Opierając się na raporcie [4] można stwierdzić, iż stosując jako podstawę architekturę można: a) Zwiększyć powodzenie projektu o 42,8% b) Zmniejszyć ryzyko występowania znaczących problemów w projekcie 36,9% c) Zmniejszyć ryzyko niepowodzenia projektu o 36,1 % 3. WDROŻENIA ARCHITEKTUR ITS W EUROPIE Krajowe Architektury ITS zostały wdrożone w następujących krajach: Francja (ACTIF), Włochy (ARTIST), Republika Czeska (TEAM), Węgry (HITS), Rumunia (NARTIS). 2 Raport zawiera wyniki analizy projektów z branży IT. Według autora projekty ITS mają ścisły związek z projektami ITS, ze względu, iż największe problemy tej branży dotyczą integracji systemów informatycznych. 3 Sukces projektu oznacza jego zakończenie w zadanym czasie i w określonym budżecie wraz ze wszystkimi wymaganymi funkcjonalnościami. 4 Trudności w projekcie oznaczają, że projekt został zakończony jednak przekroczył zadany horyzont czasowy, budżet i posiada mniejszą funkcjonalność niż początkowo zakładano. 5 Niepowodzenie oznacza projekt, który został przerwany.

3 Polski Kongres ITS Architekturami będącymi w przygotowaniu są architektury Słowenii (SITSA-C) oraz Szwajcarii (SA-CH). Podstawą dla większości z nich jest Europejska, Ramowa Architektura FRAME. 4. RODZAJE ARCHITEKTUR ITS Możemy rozróżnić trzy typy Architektur ITS, które różnią się szczegółowością i zakresem opisu. Każdy z rodzajów architektury ITS składa się z wielu punktów widzenia (ang. viewpoints), które opisują system/usługę z jednej perspektywy. Wśród wspomnianych punktów widzenia znajdują się: funkcjonalny punkt widzenia (architektura funkcjonalna) zawiera wszystkie funkcje niezbędne do wypełnienia potrzeb użytkowników, fizyczny punkt widzenia (architektura fizyczna) zawiera odwzorowanie funkcji określonych w funkcjonalnym punkcie widzenia na jednostki fizyczne występujące w danym systemie. W zależności od otoczenia systemu fizyczne punkty widzenia mogą wyglądać różnie ze względu na zmienność struktur jednostek je implementujących, komunikacyjny punkt widzenia (architektura komunikacyjna) to połączenia, które umożliwiają wymianę danych pomiędzy fizycznymi jednostkami zawartymi w fizycznym punkcie widzenia oraz między systemem a światem zewnętrznym. Powyższe punkty widzenia (perspektywy) Architektury ITS mogą stanowić podstawę dla następujących analiz: Analiza organizacyjna, która określa właściciela/zarządcę/operatora określonych w architekturze fizycznej podsystemów, modułów lub przepływów danych. Analiza wdrożenia, która stanowi plan implementacji usług ITS zawartych w architekturze co umożliwia łatwiejsze harmonogramowanie prac Analiza kosztów korzyści (C/B) pomaga ocenić opłacalność danego wdrożenia z punku widzenia ponoszonych wydatków i oczekiwanych zysków (mierzonych m.in. w postaci oszczędności czasu i pieniędzy) Analiza ryzyka wspomagająca decyzyjność procesów poprzez zwrócenie uwagi na kwestie wymagające szczególnej uwagi. 4.1 Architektura wysokiego poziomu (ramowa) Europejska Architektura ITS jest przeznaczona dla systemów ITS, które będą działały na obszarze państw członkowskich Unii Europejskiej, stanowiąc podstawę dla architektur średniego poziomu i określając dla nich wymagania, które spełniają niezbędne potrzeby użytkowników (wg FRAME). EAITS wspomaga pracę krajowych, regionalnych i lokalnych władz, a także wykonawców systemów w planowaniu, wdrożeniu, zarządzaniu i utrzymaniu systemów ITS w sposób spójny i efektywny kosztowo. W Architekturze FRAME zarówno potrzeby użytkowników, jak i funkcjonalny punkt widzenia zawierają szereg obszarów funkcjonalnych, które z dużym prawdopodobieństwem będą implementowane w krajach Unii Europejskiej. Europejska architektura ITS (KAREN 6 ) została opracowana wg następujących założeń: architektura będzie definiowała niezbędne elementy w celu zapewnienia otwartego rynku dla usług ITS w całej europie a także i na świecie, architektura będzie podstawą dla budowania kompromisu dla kwestii ciągle uniemożliwiających szeroki rozwój systemów ITS w Europie i pozwalającej wszystkim użytkownikom na zakup efektywnych kosztowo produktów ITS, które będą działały w taki sam sposób w całej UE, 6 Obecna nazwa to EFRAME

4 mgr inż. Krzysztof ewski architektura będzie przewodnikiem służącym realizacji usług ITS dla inwestycji publicznych, architektura będzie pełniła rolę doradczą w identyfikacji obszarów w których niezbędne jest prowadzenie badań naukowych. Architektury wysokiego poziomu są najczęściej opisywane wykorzystując modele procesowe, których główne elementy to tekstowo zapisane potrzeby użytkowników oraz przepływy danych pomiędzy funkcjami i podsystemami (modułami). Istotą modelowania procesowego jest jego zrozumiałość dla wszystkich odbiorców. 4.2 Architektura średniego poziomu Architektury średniego poziomu w odróżnieniu od architektur wysokiego poziomu zawierają fizyczny punkt widzenia. Dzięki temu otrzymujemy architekturę zbudowaną z bloków, które można łączyć ze sobą tworząc szkielet systemu. Architekturami średniego poziomu są architektury krajowe. Najbardziej znaną i pierwszą powstałą (w 1996 r.) jest Krajowa Architektura ITS opracowana dla Stanów Zjednoczonych Ameryki Północnej [10]. Zawiera ona zebrane potrzeby użytkowników, funkcjonalny punkt widzenia definiujący jednostki logiczne, fizyczny punkt widzenia (zawierający warstwę komunikacyjną i transportową), a także pakiety rynkowe, które stanowią wycinki fragmentów architektury ITS opracowane w celu szybkiej implementacji określonych usług (największe zorientowanie na rynek usług). 3.2 Architektura niskiego poziomu Rys 1. Pakiet rynkowy dla systemu ważenia w ruchu[6] Architektury niskiego poziomu są tworzone w celu opisania ram dla architektur regionalnych lub miast, a także dla określonych usług ITS, które mają zostać wdrożone. Wartym wspomnienia jest fakt, iż architektura tego typu może zostać opracowana w celu wytworzenia produktu (usługi) przez podmiot prywatny. Architektury niskiego poziomu mogą być modelowane procesowo jak i obiektowo. owanie procesowe zostało pokrótce opisane w pkt owanie obiektowe jest bardziej skomplikowanym procesem ze względu na sformalizowaną notację (np. UML, BPMN, SysML), która nie jest zrozumiała dla każdego, pozwala ona jednak na szybkie wdrożenie danego

5 Opracowane z FRAME Część Architektury FRAME Polski Kongres ITS produktu na rynek w oparciu o architektury wyższych poziomów. Tabela nr 2 przedstawia zależność pomiędzy modelowaniem procesowym a modelowaniem obiektowym. obiektowy opiera się na takich pojęciach jak klasa, dziedziczenie i hermetyzacja, co jest szczególnie użyteczne dla sektora prywatnego ponieważ zapewnia ponowne wykorzystanie komponentów, dzięki transformacjom MDA (ang. Driven Archcitecture) wygenerowanie kodu źródłowego, łatwe sprawdzenie poprawności modelu, wspomaganie pracy dzięki narzędziom CASE. Tabela 2. Zależność modelowania procesowego i obiektowego. Na podstawie [2] owanie procesowe owanie obiektowe Składnik Aarchitektury Potrzeby użytkowników kontekstowy Obszary funkcjonalne Opis Określa potrzeby interesariuszy w usystematyzowany sposób Pokazuje zależności pomiędzy systemem a światem zewnętrznym High-level view of Functions grouped by purpose Wymagania systemowe Przypadków użycia klas/diagram pakietów struktury Funkcje Opis wysokiego poziomu dotyczący realizowanych funkcji Opis przypadków użycia Lista wejściowych i wyjściowych przepływów danych y przepływów Szczegółowy opis wymagań funkcjonalnych Przedstawia połaczenia (przeływy danych) pomiędzy funkcjami a bazami danych i światem zewnętrznym aktywności i diagram sekwencji aktywności wysokiego poziomu dynamiki Fizyczny punkt widzenia Komponenty w ramach których zgrupowane są funkcje komponentów struktury Komunikacyjny punkt widzenia Opis połaczeń komunikacyjnych pomiędzy komponentami w fizycznym punkcie widzenia komunikacji dynamiki Rysunek poniżej przedstawia diagram kontekstowy dla jednej z opracowywanych architektur ITS.

6 uc Context mgr inż. Krzysztof ewski Ambient Environment Driver Transport Planner Road Network Operator Traffic Emergency Systems SYSTEM Public Transport Vehicle Traveller Law Enforcement Agency Broadcaster Planned Event Organiser Road Maintenance Organisation Rys.2 kontekstowy zapisany w notacji UML 5. SCENARIUSZE WDROŻEŃ SYSTEMÓW ITS a) Scenariusz I: Scenariusz pierwszy zakłada opracowanie Krajowej Architektury ITS, a na jej podstawie budowanie architektur niskiego poziomu (regionalnych, miejskich i dla określonych usług i produktów). b) Scenariusz II: Scenariusz drugi zakłada opracowanie architektur niskiego poziomu bez określenia Krajowej Architektury ITS. c) Scenariusz III: Scenariusz trzeci zakłada opracowanie architektur dla poszczególnych usług ITS, bez opracowania architektury krajowej oraz architektur regionalnych/miejskich. d) Scenariusz IV: Scenariusz czwarty zakłada opracowanie architektur dla poszczególnych produktów ITS, bez opracowania architektury krajowej oraz architektur regionalnych/miejskich. Tabela. Scenariusze wdrożeń systemów ITS Scenariusz Krajowa Architektura ITS Regionalna, miejska architektura ITS Architektura ITS dla określonych usług Scenariusz I + +/- +/- +/- Scenariusz II - + +/- +/- Scenariusz III /- Scenariusz IV Architektura ITS dla określonych i produktów Najbardziej optymalnym scenariuszem wdrożenia systemów ITS w Polsce jest scenariusz nr 1, zawierający stworzenie Krajowej Architektury ITS (KAITS). Scenariusz ten powinien: uwzględniać sytuację w krajach sąsiadujących z Polską, w celu zapewnienia minimum interoperacyjności z tymi krajami, opisywać wybraną grupę usług ITS należy rozważyć czy zawrzeć wszystkie usługi ITS, czy wybrać kilka najważniejszych i na nich skupić swój wysiłek. Poziom szczegółowości

7 Polski Kongres ITS opisu powinien zależeć od aktualnej sytuacji w kraju (np. gdzie należy wyspecyfikować wymagania dla systemów łączności). zawierać potrzeby użytkowników zebrane podczas spotkań twarzą w twarz, bezwzględnie zawierać pomoce/wytyczne dla zamawiających systemy ITS (w zależności od grupy docelowej na różnym poziomie szczegółowości), wspomagające ich w m.in. procesie specyfikacji wymagań oraz możliwości finansowania, zawierać zmiany w prawie nakładające obowiązek stosowania KAITS. Nie należy tworzyć martwych architektur ITS, wspomagać lub być wspomaganym przez takie dokumenty jak Polityka Transportowa lub Strategia Inteligentnych Systemów Transportowych 6. WNIOSKI Komisja Europejska w dyrektywie 2010/40/WE zwraca uwagę na brak interoperacyjności usług ITS. Większość krajów członkowskich UE posiada lub ma w opracowaniu Krajowe Architektury ITS. Niektóre z już istniejących architektur istnieją jedynie na papierze i nie są wykorzystywane w praktyce. Polska stoi przed ogromną szansą wykorzystania wiedzy i uniknięcia błędów poprzedników, dzięki czemu może stać się jedną z najbardziej wartościowych w Europie. Autor pracy zaleca tworzenie Architektury ITS metodą małych kroków, co oznacza zawarcie w KAITS usług najbardziej potrzebnych(np. zarządzanie ruchem, informacja dla pasażerów, płatności elektroniczne), a następnie uzupełnienie jej usługami mającymi mniejsze znaczenie lub będącymi we wdrożeniu w dalszej perspektywie czasowej (np. wymiana informacji pomiędzy pojazdami lub pojazdami i infrastrukturą). Literatura [1] Bossom R., Jesty Peter, Using the FRAME Architecture for Planning Integrated Intelligent Transport Systems [2] Moving from Process to Object Oriented Methodologies, EC Cooperative Systems Concertation Meeting Brussels 14 March 2008 [3] ewski K. Czym jest ITS?, strona internetowa 8 kwietnia 2011 r. [4] Putman A. Factors Influencing Project Success,Challenge or Failure, Project Management Institute Erie, styczeń 2007 [5] Senczyna S., owanie procesowe i efektywność technologii informacyjnej w przedsiębiorstwach, Politechnika Śląska, Katedra Systemów Technicznych [6] US National ITS Architecture, Version 6.1 [7] Litwin.M, The role of Intelligent Transportation Systems (ITS) National Architecture and Standards The Canadian Experience IV Konferencja Naukowo Techniczna, Poznań 2003 [8] Litwin M., Krukowski P., Inteligentne Systemy Transportowe w Polityce Państwa. Krajowa Architektura ITS - VI Konferencja Naukowo Techniczna, Poznań, 2007 [9] Jamroz, K., M. Litwin, J. Oskarbski (2006) Inteligentne Systemy Transportu - Zaawansowane SystemyZarządzania Ruchem, I Polski Kongres Drogowy. Warszawa, 4-6 października [10] Gis, W., M. Litwin (2006) ITS w strategii rozwoju transportu; Architektura krajowa ITS. XLIX Techniczne Dni Drogowe, Szczyrk, 6-9 listopada 2006.