scenariusz wdrożeń inteligentnych systemów

Polski Kongres ITS
Mgr inż. Krzysztof Modelewski1
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 Report2” 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, 00-074 Warszawa, [email protected]
mgr inż. Krzysztof Modelewski
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 sukcesu3
1
2
3
4
5
6
Zaangażowanie
użytkowników (15,9%)
Wsparcie kierownictwa
(13,9%)
Jasno określone
wymagania (13%)
Właściwe planowanie
(9.6%)
Realistyczne oczekiwania
(8.2%)
8
Mniejsze kroki milowe
(7.7%)
Kompetentny zespół
(7.2%)
Ownership (5.3%)
9
Jasna wizja i cele (2.9%)
10
Pracowity zespół (2.4%)
7
Nazwa czynnika problemu4
Nazwa czynnika
niepowodzenia5
Brak wkładu
Niekompletne
użytkowników (12.8%)
wymagania(13.1%)
Niekompletne wymagania Brak
i specyfikacje (12.3%)
zaangażowania
użytkowników
(12.4%)
Brak zasobów
Zmiana wymagań i
(10.6%)
specyfikacji (11.8%)
Brak wsparcia kierownictwa Nierealistyczne
(7.5%)
wymagania (9.9%)
Niekompetencja pod
Brak wsparcia
względem technologii
kierownictwa (9.3%)
(7.0%)
Brak zasobów (6.4%)
Zmiana wymagań i
specyfikacji (8.7%)
Unrealistic Expectations
Brak planowania
(5.9 %)
(8.1%)
Niejasne cele (5.3%)
Didn't Need It Any
Longer (7.5%)
Nierealistyczne ramy
Brak zarządzania IT
czasowe (4.3%)
(6.2%)
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.
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 (KAREN6) 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
mgr inż. Krzysztof Modelewski
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).
Rys 1. Pakiet rynkowy dla systemu ważenia w ruchu[6]
3.2 Architektura niskiego poziomu
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.
Modelowanie procesowe zostało pokrótce opisane w pkt. 4.1. Modelowanie 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
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. Model
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. Model 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]
Część Architektury FRAME
Modelowanie procesowe
Składnik
Aarchitektury
Opis
Diagram
Potrzeby
użytkowników
Określa potrzeby interesariuszy
w usystematyzowany sposób
Wymagania
systemowe
Diagram
kontekstowy
Pokazuje zależności pomiędzy
systemem a światem
zewnętrznym
Przypadków
użycia
Obszary
funkcjonalne
High-level view of Functions
grouped by purpose
Diagram
klas/diagram
pakietów
Funkcje
Opis wysokiego poziomu
dotyczący realizowanych
funkcji
Opis
przypadków
użycia
Model
Model
struktury
Lista wejściowych i
wyjściowych przepływów
danych
Szczegółowy opis wymagań
funkcjonalnych
Opracowane z
FRAME
Modelowanie obiektowe
Diagram
aktywności i
diagram
sekwencji
Model
dynamiki
Diagramy
przepływów
Przedstawia połaczenia
(przeływy danych) pomiędzy
funkcjami a bazami danych i
światem zewnętrznym
Diagram
aktywności
wysokiego
poziomu
Fizyczny punkt
widzenia
Komponenty w ramach których
zgrupowane są funkcje
Diagram
komponentów
Model
struktury
Komunikacyjny
punkt widzenia
Opis połaczeń
komunikacyjnych pomiędzy
komponentami w fizycznym
punkcie widzenia
Diagram
komunikacji
Model
dynamiki
Rysunek poniżej przedstawia diagram kontekstowy dla jednej z opracowywanych architektur ITS.
mgr inż. Krzysztof Modelewski
uc Context Diagram
Driver
Ambient
Environment
Transport Planner Road Network
Operator
Traffic
Emergency
Systems
Public Transport
Vehicle
SYSTEM
Traveller
Law Enforcement
Agency
Broadcaster
Planned Event
Organiser
Road
Maintenance
Organisation
Rys.2 Diagram 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
Regionalna,
Architektura ITS
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
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] Modelewski K. “Czym jest ITS?, strona internetowa www.itspolska.pl, 8 kwietnia 2011 r.
[4] Putman A. “Factors Influencing Project Success,Challenge or Failure”, Project Management
Institute Erie, styczeń 2007
[5] Senczyna S., “Modelowanie procesowe i efektywność technologii
przedsiębiorstwach”, Politechnika Śląska, Katedra Systemów Technicznych
[6] US National ITS Architecture, Version 6.1
informacyjnej
w
[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 2006.
[10]
Gis, W., M. Litwin (2006) ITS w strategii rozwoju transportu; Architektura krajowa ITS.
XLIX Techniczne Dni Drogowe, Szczyrk, 6-9 listopada 2006.