Koncepcja Zintegrowanego Systemu Zarządzania Ruchem w

Transkrypt

Koncepcja
Zintegrowanego Systemu
Zarządzania
Ruchem w Warszawie
– na terenie obszaru I
I&S ITS - I n t e l l i g e n t T r a f f i c S y s t e m s
Siemens Sp. z o.o. & Siemens AG
2/192
Spis treści
1.
1.1.
1.2.
1.3.
2.
2.1.
2.2.
2.2.1.
2.2.2.
2.3.
2.3.1.
2.3.2.
2.3.3.
2.3.4.
2.3.5.
2.3.6.
2.3.7.
2.3.8.
2.3.9.
2.4.
2.4.1.
2.4.2.
2.4.2.1.
2.4.2.2.
2.4.3.
2.5.
2.5.1.
2.5.2.
2.5.3.
2.6.
2.6.1.
2.6.1.1.
2.6.1.2.
2.6.1.3.
2.6.2.
2.7.
2.8.
2.9.
2.10.
2.11.
2.12.
2.13.
2.14.
2.15.
2.15.1.
2.15.2.
WSTĘP ................................................................................................................................10
SŁOWNIK UśYWANYCH AKRONIMÓW ................................................................................10
OPIS OGÓLNY ......................................................................................................................11
ZGODNOŚĆ Z OCIT ..............................................................................................................16
KONCEPCJA SYSTEMU (SITRAFFIC SCALA/CONCERT) .......................................................18
STRUKTURA SYSTEMU .......................................................................................................18
OMÓWIENIE OFEROWANEGO SYSTEMU SITRAFFIC SCALA/CONCERT .......................21
STRUKTURA SPRZĘTOWA SYSTEMU SITRAFFIC SCALA/CONCERT.............................21
ODZWIERCIEDLENIE FUNKCJI CAŁEGO SYSTEMU ...............................................................22
KRÓTKI OPIS OPROGRAMOWANIA PRZEWIDZIANEGO DLA SYSTEMU ZARZĄDZANIA
RUCHEM..............................................................................................................................24
SITRAFFIC BEDIENCLIENT - KLIENT OBSŁUGI (NADZÓR I WIZUALIZACJA) ....................24
SITRAFFIC SUPPLY (SYSTEM ZARZĄDZANIA DANYMI) ...................................................25
SITRAFFIC CONTROL (LOKALNE I ZDALNE PROGRAMOWANIE STEROWNIKÓW
SYGNALIZACJI) ...................................................................................................................25
STATYSTYKI I PROTOKOŁY (WIZUALIZACJA I PRZETWARZANIE WARTOŚCI POMIAROWYCH)
...........................................................................................................................................26
SITRAFFIC P2 (PLANOWANIE Z ZAKRESU INśYNIERII RUCHU ) .......................................26
SITRAFFIC LANGUAGE (JĘZYK PROGRAMOWANIA STEROWNIKÓW SYGNALIZACJI).......27
SITRAFFIC S-L (ALGORYTM STEROWANIA) ....................................................................27
SITRAFFIC PDM (ALGORYTM STEROWANIA)..................................................................28
SITRAFFIC SERVICE (PROGRAM DO SERWISOWANIA I WIZUALIZACJI PRACY STEROWNIKA
SYGNALIZACJI) ...................................................................................................................28
SERWERY ...........................................................................................................................29
UWAGI OGÓLNE..................................................................................................................29
HARDWARE ........................................................................................................................30
SYSTEM DYSKÓW TWARDYCH ...........................................................................................30
NAPĘD DAT .......................................................................................................................30
SOFTWARE..........................................................................................................................30
KLIENCI ..............................................................................................................................31
UWAGI OGÓLNE..................................................................................................................31
HARDWARE ........................................................................................................................31
SOFTWARE..........................................................................................................................32
KOMPONENTY NIEZBĘDNE DLA STEROWNIKÓW SYGNALIZACJI Z OCIT ...........................33
OCIT INTELLIGENT GATEWAY (OCIT-IG)........................................................................33
UWAGI OGÓLNE..................................................................................................................33
HARDWARE ........................................................................................................................33
SOFTWARE..........................................................................................................................33
SERWER DANYCH ŹRÓDŁOWYCH .......................................................................................33
DRUKARKI ..........................................................................................................................33
ZASILANIE AWARYJNE (UPS) ............................................................................................34
ZDALNY DOSTĘP W CELU PROWADZENIA PRAC KONSERWACYJNYCH ...............................35
NADZÓR NAD SYSTEMEM ...................................................................................................35
KONCEPCJA OBSŁUGI .........................................................................................................36
ZARZĄDZANIE UśYTKOWNIKAMI .......................................................................................37
USTAWIANIE DATY I GODZINY, SYNCHRONIZACJA. ...........................................................37
POZIOMY ZABEZPIECZEŃ ...................................................................................................38
AWARIA SKŁADNIKÓW .......................................................................................................38
MACIERZ DYSKÓW TWARDYCH (RAID 10) .......................................................................39
LUSTRZANE ODBICIE DYSKU TWARDEGO (RAID 5) ..........................................................40
Koncepcja Zintegrowanego Systemu Zarządzania Ruchem w Warszawie – na terenie obszaru I
Wersja 4.0
Prawa autorskie  Konsorcjum Siemens Sp. z o.o. i Siemens AG I&S ITS 2006 Wszelkie prawa zastrzeŜone
3.
3.1.
3.1.1.
3.1.2.
3.1.3.
3.1.4.
3.1.4.1.
3.1.4.2.
3.1.4.3.
3.1.4.4.
3.1.5.
3.1.5.1.
3.1.5.2.
3.1.5.3.
3.1.6.
3.2.
3.2.1.
3.2.1.1.
3.2.1.2.
4.
5.
5.1.
5.1.1.
5.1.2.
5.2.
5.2.1.
5.2.2.
5.2.3.
5.2.4.
5.2.5.
5.2.6.
5.2.7.
5.2.8.
5.3.
5.3.1.
5.3.2.
5.3.2.1.
5.3.2.2.
5.3.2.3.
5.3.2.4.
5.4.
5.5.
6.
7.
7.1.
7.1.1.
7.1.2.
7.2.
7.2.1.
7.2.2.
3/192
ORGANIZACJA DANYCH I BEZPIECZEŃSTWO DANYCH .......................................................41
ORGANIZACJA DANYCH .....................................................................................................41
PRZEGLĄD ..........................................................................................................................41
CENTRALNE DANE STERUJĄCE ...........................................................................................42
DANE KOMUNIKATÓW........................................................................................................42
ARCHIWUM KOMUNIKATÓW ROBOCZYCH .........................................................................44
ATRYBUTY KOMUNIKATU ROBOCZEGO .............................................................................45
SPOSÓB DZIAŁANIA ARCHIWUM KOMUNIKATÓW DOT. TRYBU PRACY ..............................46
OKNO KOMUNIKATÓW ONLINE ..........................................................................................47
WYSZUKIWANIE I ARCHIWIZACJA W ARCHIWUM KOMUNIKATÓW DOT. TRYBU PRACY ....47
WARTOŚCI POMIARÓW (DANE DOT. RUCHU DROGOWEGO) ...............................................48
ARCHIWUM WARTOŚCI POMIARÓW ....................................................................................49
WYSZUKIWANIE W ARCHIWUM ..........................................................................................50
OPRACOWYWANIE WARTOŚCI POMIARÓW .........................................................................50
DANE ŹRÓDŁOWE ...............................................................................................................50
ZABEZPIECZANIE DANYCH .................................................................................................52
KOPIA ZAPASOWA, PONOWNE URUCHAMIANIE ..................................................................52
ARCHIWIZACJA I WCZYTYWANIE .......................................................................................53
KOPIA ZAPASOWA I PRZYWRACANIE SYSTEMU .................................................................56
PRIORYTET DLA TRANSPORTU ZBIOROWEGO .....................................................................56
PROCES PROJEKTOWANIA I ZASILANIA DANYMI ................................................................58
STANOWISKO INśYNIERA KIEROWANIA RUCHEM SITRAFFIC P2 ....................................58
ZAKRES DANYCH................................................................................................................58
EKSPORT DO SITRAFFIC LANGUAGE (TL).......................................................................60
SITRAFFIC LANGUAGE (PROGRAMOWANIE ALGORYTMÓW LOGICZNYCH TECHNIKI
STEROWANIA RUCHEM)......................................................................................................61
ŚRODOWISKO PROGRAMISTYCZNE TL...............................................................................61
ZARZĄDZANIE PROJEKTEM ................................................................................................62
EDYTOR SCHEMATÓW STRUKTURY WZGL. SCHEMATÓW BLOKOWYCH.............................62
KOMPILATOR......................................................................................................................63
KOMPILATOR ANSI C ........................................................................................................63
PROCEDURY STERUJĄCE - GŁÓWNE FUNKCJE ....................................................................63
KONFIGURACJA PARAMETRÓW ..........................................................................................64
BIBLIOTEKI UśYTKOWNIKA ...............................................................................................64
SITRAFFIC CONTROL .......................................................................................................64
IMPORT/EKSPORT DANYCH Z PROGRAMU SITRAFFIC P2.................................................65
PROGRAMOWANIE STEROWNIKÓW SYGNALIZACJI ŚWIETLNEJ (STEROWNIK C800V) ZA
POMOCĄ SITRAFFIC CONTROL ........................................................................................66
DANE PODSTAWOWE ..........................................................................................................66
MONITOR KONFLIKTÓW SISI (ZABEZPIECZENIE SYGNAŁÓW) ...........................................68
OBIEKTY ZASILAJĄCE WSZYSTKICH ZALEśNOŚCI OD NATĘśENIA RUCHU .........................68
ZALEśNY OD NATĘśENIA RUCHU PROGRAM (KOD) WSZYSTKICH ZALEśNOŚCI OD
NATĘśENIA RUCHU .............................................................................................................68
PROGRAM SYMULACYJNY VISSIM....................................................................................68
PROGRAMOWANIE STEROWNIKA SYGNALIZACJI ŚWIETLNEJ .............................................70
STRAMO...........................................................................................................................75
OPIS TECHNIKI STEROWANIA RUCHEM...............................................................................78
STEROWANIE W FUNKCJI CZASU (AUTOMATYKA ROCZNA) ...............................................78
KALENDARZ .......................................................................................................................78
WYMAGANIA DLA PLANÓW CZASOWYCH ..........................................................................79
WYBÓR PROGRAMU SYGNALIZACJI (TASS) W ZALEśNOŚCI OD WARUNKÓW RUCHU .......80
ZMIANA SYTUACJI I ZMIANA PROGRAMU SYGNALIZACJI ...................................................80
EKRAN OBSŁUGI .................................................................................................................81
Wersja 4.0
7.2.3.
7.2.4.
7.2.5.
7.2.6.
7.2.7.
7.3.
7.3.1.
7.3.2.
7.3.3.
7.3.4.
7.3.5.
7.4.
8.
8.1.
8.2.
8.2.1.
8.2.2.
8.2.3.
8.2.4.
8.2.5.
8.2.6.
8.2.7.
8.3.
8.3.1.
8.3.2.
8.3.3.
8.3.4.
8.3.5.
8.4.
8.5.
8.5.1.
8.5.2.
8.5.3.
8.5.4.
8.5.5.
8.6.
8.6.1.
8.6.2.
8.6.3.
8.6.4.
9.
9.1.
9.1.1.
9.1.2.
9.1.3.
9.1.4.
9.1.5.
9.1.6.
9.1.7.
9.1.8.
4/192
MOśLIWOŚCI TESTOWANIA ................................................................................................82
TWORZENIE KOMUNIKATÓW ..............................................................................................83
STEROWANIE CENTRALNE I ZDECENTRALIZOWANE ..........................................................83
RĘCZNE WPROWADZANIE SYTUACJI ..................................................................................83
REALIZACJA .......................................................................................................................83
ADAPTACYJNE STEROWANIE SIECIOWE (MOTION)..........................................................83
KONCEPCJA ADAPTACYJNEGO UKŁADU STEROWANIA ......................................................83
REJESTRACJA STANU RUCHU..............................................................................................84
OGÓLNA KONCEPCJA DYNAMICZNEJ „ZIELONEJ“ FALI ......................................................85
ROZPOZNAWANIE ZAKŁÓCEŃ ............................................................................................86
STANOWISKO ZASILANIA I OBSŁUGI ..................................................................................86
TRASY POJAZDÓW SŁUśB RATOWNICZYCH........................................................................86
WIZUALIZACJA ...................................................................................................................90
MOśLIWOŚĆ KONFIGUROWANIA WIDOKÓW NA EKRANIE ..................................................90
OBSŁUGA SYSTEMU NA PODSTAWIE MAPY ........................................................................90
GIS OPARTY NA UKŁADZIE WARSTWOWYM ......................................................................90
ZACHOWYWANIE DANYCH GIS .........................................................................................91
WIZUALIZACJA OBIEKTÓW ................................................................................................91
FUNKCJA ZOOM ..................................................................................................................95
WYSZUKIWANIE W SYSTEMIE GIS .....................................................................................96
WIDOKI ZDEFINIOWANE PRZEZ UśYTKOWNIKA.................................................................96
ZAPISYWANIE DZIAŁAŃ .....................................................................................................96
STAN RZECZYWISTY ...........................................................................................................96
WIDOK LISTY URZĄDZEŃ SYGNALIZACJI ŚWIETLNEJ (SKRZYśOWAŃ) ..............................97
WIDOK SZCZEGÓŁOWY ......................................................................................................97
WIDOK SZCZEGÓŁOWY STEROWNIKÓW SYGNALIZACJI ŚWIETLNEJ ..................................99
PRZYRZĄD DO OBSŁUGI STEROWNIKA SYGNALIZACJI ŚWIETLNEJ/OBSŁUGA
CENTRALNA/TRYB EKSPERCKI .........................................................................................103
OGÓLNY STAN RZECZYWISTY ..........................................................................................105
STEROWANIE RĘCZNE ......................................................................................................106
KOMUNIKATY ..................................................................................................................108
KOMUNIKATY STEROWNIKÓW .........................................................................................108
WSKAZANIA ONLINE I ARCHIWIZACJA KOMUNIKATÓW...................................................108
RĘCZNE WPROWADZANIE KOMUNIKATÓW ......................................................................110
AUTOMATYCZNE PRZEKAZYWANIE KOMUNIKATÓW (SYSTEM ZARZĄDZANIA ALARMAMI)
.........................................................................................................................................110
WPROWADZANIE KOMUNIKATÓW O STANIE RUCHU I ADMINISTROWANIE NIMI .............110
WIZUALIZACJA ONLINE ....................................................................................................112
WIDOK SIECI.....................................................................................................................112
RZUT POZIOMY WĘZŁA KOMUNIKACYJNEGO ...................................................................115
SYGNALIZACJA.................................................................................................................116
„ZIELONA FALA” ..............................................................................................................117
OCENA DANYCH DOTYCZĄCYCH RUCHU .........................................................................118
STATYSTYKI I PROTOKOŁY...............................................................................................118
CHARAKTERYSTYKA SYSTEMU ........................................................................................118
WYBÓR ZDEFINIOWANYCH WSTĘPNIE PROTOKOŁÓW, STATYSTYK ORAZ ICH SELEKCJA ......
.........................................................................................................................................118
WYBÓR NA PODSTAWIE CZASU ........................................................................................118
RODZAJE OCEN .................................................................................................................118
SKALOWANIE ...................................................................................................................119
WPROWADZANIE OCEN DO PAMIĘCI, PROFILE OCEN........................................................119
DRUKOWANIE OCEN .........................................................................................................119
WSTĘPNIE ZDEFINIOWANE PROTOKOŁY I STATYSTYKI ....................................................119
Wersja 4.0
9.1.8.1.
9.1.8.2.
9.1.8.3.
9.1.8.4.
9.1.8.5.
9.2.
9.3.
9.3.1.
9.3.2.
9.3.3.
9.3.4.
9.3.5.
10.
10.1.
10.2.
10.2.1.
10.2.2.
10.3.
10.3.1.
10.3.1.1.
10.3.1.2.
10.3.1.3.
10.3.1.4.
10.3.2.
10.3.2.1.
10.3.2.2.
10.4.
10.4.1.
10.4.2.
10.5.
10.6.
10.6.1.
10.6.2.
11.
11.1.
11.2.
11.3.
11.4.
11.5.
11.6.
11.7.
12.
13.
13.1.
13.2.
13.3.
13.3.1.
13.3.2.
13.3.3.
13.3.4.
13.3.5.
13.3.6.
13.3.7.
5/192
DANE KRÓTKOOKRESOWE ...............................................................................................119
DANE DŁUGOOKRESOWE..................................................................................................120
PROTOKÓŁ MIESIĘCZNY SUM DZIENNYCH .......................................................................121
PROTOKÓŁ DANYCH ŚRODOWISKOWYCH ........................................................................122
STATYSTYKA WARTOŚCI DZIENNYCH LUB WARTOŚCI MIESIĘCZNYCH ............................123
PRZETWARZANIE WARTOŚCI MIERZONYCH .....................................................................126
OCENY WARTOŚCI MIERZONYCH PRZY UśYCIU SITRAFFIC P2 .....................................126
MIEJSCA PRZEPROWADZENIA POMIARU ...........................................................................126
BUDOWA POZYCJI MIEJSCE PRZEPROWADZENIA POMIARU ..............................................126
ŁĄCZENIE MIEJSC PRZEPROWADZENIA POMIARU ............................................................126
DZIENNE LINIE WAHAŃ ....................................................................................................128
PLANY OBCIĄśENIA .........................................................................................................129
ANALIZA JAKOŚCI QM/Q2 ...............................................................................................132
PODSTAWOWA CHARAKTERYSTYKA KONTROLI JAKOŚCI I ANALIZY JAKOŚCI ................132
CECHY SYSTEMU ..............................................................................................................132
SITRAFFIC QM ..............................................................................................................133
SITRAFFIC Q2................................................................................................................133
PRZYKŁADY OCEN W ZAKRESIE KONTROLI JAKOŚCI .......................................................135
ANALIZY TRANSPORTU PUBLICZNEGO - ÖPNV ...............................................................135
OCENA CZASÓW JAZDY ....................................................................................................135
OCENA PRZEBIEGU JAZDY NA SKRZYśOWANIACH ...........................................................136
CZĘSTOŚĆ WYSTĘPOWANIA PUNKTÓW ZGŁASZANIA CZASU ...........................................137
KONTROLA DZIAŁANIA PUNKTÓW MELDUNKOWYCH ......................................................138
OCENY ODCINKOWE .........................................................................................................140
PRZEBIEG JAZDY ..............................................................................................................140
CZAS JAZDY......................................................................................................................141
PRZYKŁADY OCEN W RAMACH ANALIZY JAKOŚCI ...........................................................142
OCENA CZASÓW PRZEŁĄCZANIA ......................................................................................142
OCENA WARTOŚCI WSKAZANYCH PRZEZ DETEKTORY .....................................................144
DEFINICJA WARTOŚCI PROGOWYCH W ZARZĄDZANIU JAKOŚCIĄ ....................................145
RAPORT - FUNKCJA KONTROLI JAKOŚCI ..........................................................................148
MODUŁ RAPORTU .............................................................................................................148
ZARZĄDZANIE KONTROLĄ JAKOŚCI .................................................................................149
ZARZĄDZANIE W SYTUACJACH AWARYJNYCH ................................................................150
DWUCZĘŚCIOWA KONCEPCJA OBSŁUGI............................................................................150
PRZEGLĄD ........................................................................................................................151
PRZEGLĄD ZAKŁÓCEŃ ......................................................................................................151
PODZIAŁ MELDUNKÓW I POWIADAMIANIE .......................................................................152
TŁUMIKI MELDUNKÓW .....................................................................................................154
PLAN DZIAŁANIA ..............................................................................................................155
PROFILE UśYTKOWNIKÓW ...............................................................................................156
STEROWNIKI RUCHU DROGOWEGO NA SKRZYśOWANIACH C800V. ...............................157
SYSTEM ZARZĄDZANIA RUCHEM .....................................................................................158
PODSYSTEM CCTV ..........................................................................................................159
INTERFEJS TABLIC INFORMACYJNYCH .............................................................................163
ZARZĄDZANIE MELDUNKAMI...........................................................................................164
INFORMACJA OGÓLNA ......................................................................................................167
OBOWIĄZYWANIE MELDUNKU .........................................................................................168
OBSZAR OBOWIĄZYWANIA MELDUNKU ...........................................................................169
DODATKOWE INFORMACJE ..............................................................................................169
WŁĄCZANIE MELDUNKU DO PLANÓW DZIAŁANIA ...........................................................170
POWIĄZANIE Z CCTV ......................................................................................................171
ZARZĄDZANIE MELDUNKAMI I ROZPOZNAWANIE ZAKŁÓCEŃ .........................................172
Wersja 4.0
13.3.8.
13.4.
13.5.
13.6.
13.7.
13.8.
13.9.
13.10.
13.11.
13.12.
14.
14.1.
14.2.
14.3.
14.3.1.
14.3.2.
14.3.3.
14.4.
14.4.1.
14.4.2.
14.4.3.
14.4.4.
6/192
AUTOMATYCZNE WYSYŁANIE ZLECEŃ MEDIALNYCH......................................................172
ZARZĄDZANIE MEDIALNE ................................................................................................173
SYSTEM INFORMACJI ŚRODOWISKOWEJ ...........................................................................175
PANEL WIZUALIZACYJNY ................................................................................................175
SYSTEM STEROWANIA I MONITORINGU TUNELU W ZAGŁĘBIENIU WISŁOSTRADY .........176
TABLICE INFORMACYJNE .................................................................................................176
PODSYSTEM DYNAMICZNEGO NAPROWADZANI NA PARKINGI .........................................180
PROPONOWANIE ALTERNATYWNYCH TRAS PRZEJAZDU ..................................................184
ZARZĄDZANIE ROBOTAMI DROGOWYMI ..........................................................................184
MEDIUM KOMUNIKACYJNE ..............................................................................................184
OGÓLNE WARUNKI ...........................................................................................................189
REFERENCJE .....................................................................................................................189
DOKUMENTACJA ..............................................................................................................189
BEZPIECZEŃSTWO INFORMACJI ........................................................................................189
OCHRONA ANTYWIRUSOWA .............................................................................................189
ZABEZPIECZENIE DOSTĘPU...............................................................................................189
ZABEZPIECZENIE DANYCH ...............................................................................................189
OGÓLNE ZAŁOśENIA I WARUNKI RAMOWE ......................................................................189
UWZGLĘDNIONE PRZEPISY ...............................................................................................189
WARUNKI OTOCZENIA I WARUNKI ŚRODOWISKOWE .......................................................190
OGÓLNA CHARAKTERYSTYKA OPRZYRZĄDOWANIA I OPROGRAMOWANIA ....................191
OBSŁUGA SYSTEMU..........................................................................................................191
Załączniki
1. SKRZYśOWANIA Z SYGNALIZACJĄ PODLEGAJĄCĄ REMONTOM
2. SKRZYśOWANIA Z DOSTOSOWANIEM STEROWNIKÓW DO PRACY W SYSTEMIE
3. TŁUMACZENIE OPISU FUNKCJONALNEGO INTERFEJSU OCIT
4. OPIS FUNKCJONALNY INTERFEJSU OCIT – wersja oryginalna
Wersja 4.0
7/192
Spis rysunków i tabel
1.1 Skróty ...................................................................................................................... 11
1.2 Zakres terytorialny pierwszego obszaru Zintegrowanego Systemu Zarządzania
Ruchem w Warszawie..……………………………………………………………………12
2.1 Struktura logiczna systemu ................................................................................... 18
2.2 Szczegółowa struktura systemu SITRAFFIC Scala/Concert ................................ 20
2.3 Struktura fizyczna systemu SITRAFFIC Scala/Concert........................................ 21
2.4 Funkcje systemu zarządzania ruchem w Warszawie (schemat) .......................... 22
2.5 Wykaz funkcji systemu zarządzania ruchem w Warszawie (tabelaryczny) ......... 24
2.6 Interfejsy systemu zarządzania ruchem w Warszawie ......................................... 24
2.7 Przykładowy interfejs uŜytkownika ....................................................................... 36
2.8 Koncepcja układu Raid 1........................................................................................ 39
3.1 Typy komunikatów.................................................................................................. 43
3.2 Elementy komunikatu ............................................................................................. 44
3.3 Wyszukiwanie w archiwum komunikatów dot. trybu pracy ................................. 47
3.4 Przykład widoku aktualnych wartości pomiarów ................................................. 48
3.5 Przykład wywołania zapisanych wartości pomiarów ........................................... 49
3.6 Przykład opracowania wartości pomiarów ........................................................... 50
3.7 Tabela definicji pojęć archiwizacji, kopii zapasowej ............................................ 54
3.8 Przykład interfejsu uŜytkownika umoŜliwiającego zdefiniowanie planów
archiwizacji danych ............................................................................................... 54
4.1 Schemat systemu udzielania priorytetów dla transportu zbiorowego ................ 56
5.1 Środowisko programistyczne ................................................................................ 62
5.2 Przykładowy widok okna edytora schematów ...................................................... 63
5.3 Przykładowy widok okna wprowadzania parametrów.......................................... 64
5.4 Przykładowy widok okna programu VISSIM ......................................................... 69
5.5 Przykład wgrywania programu z uŜyciem SITRAFFIC Supply............................. 71
5.6 Przykład konfiguracji centralnego układu kalendarza JAUT ............................... 73
7.1 Ekran obsługi SPA zaleŜnego od stanu ruchu...................................................... 81
7.2 Przykład ekranu "Matryca zmian strategii" ........................................................... 82
7.3Przykład wizualizacji tras przejazdów słuŜb ratowniczych ................................... 86
7.4 Kreator EFR............................................................................................................. 87
7.5 Tryb wykonawczy ................................................................................................... 89
8.1 Przykładowe okno wizualizacji .............................................................................. 91
8.2 Elementy symboli punktów pomiarowych i detektorów ...................................... 92
8.3 Przykład wizualizacji skrzyŜowań.......................................................................... 93
8.4 Przykład wizualizacji opcji "Roboty drogowe i imprezy" ..................................... 93
8.5 Przedstawienie sytuacji komunikacyjnej w GIS.................................................... 94
8.6 Przykładowa ramka informacyjna obiektów na mapie GIS .................................. 95
8.7 Widok listy urządzeń sygnalizacji świetlnej.......................................................... 97
8.8 Przykład okna widoku szczegółowego.................................................................. 98
8.9 Przykładowe okno zakładki "stan rzeczywisty".................................................... 99
8.10 Przykładowe okno zakładki "dane stałe" .......................................................... 100
8.11 Przykładowe okno zakładki "przynaleŜność do grupy" ................................... 101
8.12 Przykładowe okno zakładki "serwis"................................................................. 102
8.13 Przykładowe okno obsługi sterowania urządzeniem ....................................... 103
Wersja 4.0
8/192
8.14 Przykładowe okno obsługi centralnej ............................................................... 104
8.15 Przykładowe okno ogólnego stanu rzeczywistego (zakładka "Stan systemu)105
8.16 Przykładowe okno ogólnego stanu rzeczywistego (zakładka "Obiekty
wykazujące usterki") ........................................................................................... 106
8.17 Przykładowe okno sterowania ręcznego........................................................... 107
8.18 Sieć GIS: wywoływanie widoku szczegółowego............................................... 112
8.19 Sieć GIS: lokalizacja obiektów ........................................................................... 113
8.20 Rysunek stanu ruchu.......................................................................................... 115
8.21 Widok węzła komunikacyjnego online .............................................................. 115
8.22 Wizualizacja programu sygnalizacji w trybie rzeczywistym ........................... 116
8.23 Widok "zielonej fali" online ................................................................................ 117
9.1 Krzywa (wykres) dzienna nasilenia ruchu pojazdów.......................................... 123
9.2 Dzienna linia wahań średniej prędkości.............................................................. 124
9.3 Diagram podstawowy v-q..................................................................................... 124
9.4 Diagram podstawowy v-k ..................................................................................... 125
9.5 Diagram podstawowy q-k..................................................................................... 125
9.6 Linia wahań dziennych ......................................................................................... 127
9.7 Przedstawienie obciąŜenia punktów węzłowych w tabelarycznej formie ......... 128
9.8 Przedstawienie obciąŜenia punktu węzłowego w graficznej formie.................. 129
9.9 Przedstawienie ramowego planu fazowego........................................................ 130
10.1 Przegląd danych stosowanych do wykonywania ocen.................................... 136
10.2 MoŜliwości kontroli i oceny grup sygnałowych SITRAFFIC Q2/QM ................ 134
10.3 MoŜliwości kontroli i ocen SITRAFFIC Q2/QM odnoszących się do węzła ..... 135
10.4 MoŜliwości kontroli i oceny SITRAFFIC Q2/QM odnoszące się do trasy ........ 135
10.5 Ocena czasów jazdy ........................................................................................... 136
10.6 Przykładowe okno z oceną przebiegu jazdy w punktach węzłowych.............. 137
10.7 Przykładowe okno z widokiem częstości występowania punktów zgłaszania
czasu................................................................................................................... 138
10.8 Przykładowe okno z widokiem kontroli działania punktów meldunkowych ... 139
10.9 Przykładowe okno z kontrolą działania punktów meldunkowych (Tabela)..... 140
10.10 Przykładowe okno z wykresem zaleŜności drogi w czasie - przebieg jazdy. 141
10.11 Przykładowe okno z diagramem rozkładu częstości występowania czasów
jazdy na wybranym odcinku trasy .................................................................. 142
10.12 Okno z widokiem czasów przełączania sygnałów zielonych, prezentacja
graficzna ........................................................................................................... 143
10.13 Okno z widokiem czasów przełączania sygnałów zielonych, prezentacja
tabelaryczna ..................................................................................................... 143
10.14 Wizualizacja wartości detektorów, prezentacja tabelaryczna ........................ 144
10.15 Wizualizacja wartości detektorów, prezentacja graficzna.............................. 144
10.16 Wartości progowe wyświetlania światła zielonego ........................................ 145
10.17 Edytor wartości progowych czasów trwania faz............................................. 146
10.18 Edytor wartości progowych - detektory .......................................................... 147
10.19 Edytor wartości progowych czasów oczekiwania .......................................... 147
10.20 Edytor wartości progowych - punkty meldunkowe/czasy jazdy.................... 148
10.21 Moduł raportu.................................................................................................... 148
10.22 Przykładowa wizualizacja zarządzania kontrolą jakości ................................ 149
11.1 Przegląd zakłóceń............................................................................................... 151
11.2 Filtrowanie meldunków ...................................................................................... 153
11.3 Widok okna zdefiniowanych odbiorców meldunków ....................................... 154
Wersja 4.0
9/192
11.4 Widok okna rozplanowanego czasu pracy........................................................ 155
13.1 Centrala systemu zarządzania ruchem (schemat moŜliwych podsystemów). 158
13.2 Centrala systemu zarządzania ruchem (nazwy własne modułów) .................. 159
13.3 CCTV.................................................................................................................... 160
13.4 Propozycja lokalizacji kamer.............................................................................. 162
13.5 Przegląd meldunków (Lista)............................................................................... 164
13.6 Szczegóły meldunku........................................................................................... 165
13.7 Wyszukiwanie w archiwum meldunków ............................................................ 166
13.8 Symbole meldunków (przykład z opisami niemieckimi)................................... 167
13.9 WaŜność meldunku ............................................................................................ 168
13.10 Obszar obowiązywania meldunku ................................................................... 169
13.11 Okno wizualizacji zdefiniowanego planu działania przy wystąpieniu
określonego meldunku .................................................................................... 170
13.12 Powiązanie z CCTV ........................................................................................... 171
13.13 Przetwarzanie meldunku medialnego.............................................................. 173
13.14 Panel Wizualizacyjny ........................................................................................ 175
13.15 Lokalizacja tablic zmiennej treści dla obszaru I ............................................. 178
13.16 Lokalizacja tablic zmiennej treści dla obszaru II i III....................................... 179
13.17 Przykład tablic drogowskazowych z informacją o zajętości miejsc
postojowych ..................................................................................................... 180
13.18 System PLC200 – przykład moŜliwych wariantów.......................................... 181
13.19 Przykład wydzielonych stref parkowania w centrum ..................................... 183
13.20 Schemat Systemu Informacji Parkingowej ..................................................... 183
13.21 Schemat podsystemu Proponowania alternatywnych tras przejazdu .......... 184
13.22 Schemat ogólny sieci łączności....................................................................... 187
Wersja 4.0
1.
10/192
Wstęp
1.1. Słownik uŜywanych akronimów
Skrót
Wyjaśnienie
ANSI C
Standard języka programowania C
AP
Anwender Programmvariablen / zmienne programowe uŜytkownika
BEFA
System do komunikacji pomiędzy centralą sterowania i sterownikami
BEMA
operating message archive / archiwum komunikatów systemowych
C800V/C900V
SIEMENS Intersection Controller / Sterownik Sygnalizacji firmy SIEMENS
CCTV
Closed-Circuit Television / system przekazywania obrazu z kamer
telewizyjnych
European Committee for Standardization / Europejski Komitet
ds.Standaryzacji
Siemens Product Name for Traffic Management System / Nazwa własna
Systemu Zarządzania Ruchem
CEN
Concert
DCF
EFR
Sygnał radiowy, wzorzec czasu. Nadawany w paśmie fal długich na
częstotliwości 77,5 kHz z miejscowości Mainflingen, około 25 km na
południowy wschód od Frakfurtu nad Menem w Niemczech
EinsatzFahrzeugRouten/ Trasy przejazdów słuŜb ratowniczych
GIS
Geographical Information System / Graficzny System Informacyjny
GPS
Global Positioning System / System nawigacji satelitarnej
GUI
Graphical User Interface / Graficzny Interfejs UŜytkownika
HW
Hardware / Sprzęt
IG
JAUT
Intelligent Gateway / oprogramowanie do komunikacji przy pomocy
protokołu OCIT
International Organization for Standardization / Międzynarodowa
Organizacja ds.Standaryzacji
Roczna automatyka sterowania
LAN
Local Area Network / Lokalna Sieć Komunikacyjna
LOS
Level Of Service / Poziom Obsługi
LSA
Urządzenie lokalne sterowania sygnalizacją świetlną
MESZ
Sposób przełączania programów sygnalizacji na skrzyŜowaniach
MEWA
meassurement archive / archiwum pomiarów
MOTION
Macro control dependent on traffic data / System Optymalizacji Sieciowej
NTCIP (USA)
National Transportation Communications for ITS Protocol / Protokół
komunikacyjny dla systemów zarządzania ruchem opracowany w Stanach
Zjednoczonych Ameryki
Network Time Protocol / protokół internetowy umoŜliwiający
synchronizację czasu pomiędzy komputerami
ISO
NTP
OCIT
Open Communication Interface for Road Traffic Control Systems / Otwarty
Protokół Komunikacyjny dla Systemów Centralnego Sterowania Ruchem
ODG
OCIT Developer Group / Organizacja zarządzająca dystrybucją i rozwojem
protokołu OCIT
Open System Interconnection / Zbiór zasad komunikowania się urządzeń
sieciowych
OSI
Wersja 4.0
11/192
Skrót
Wyjaśnienie
PDM
Metoda sterowania fazowego sygnalizacją świetlną
RAID
RDS
Redundant Array of Independent Disks, / Nadmiarowa macierz
niezaleŜnych dysków
Raw Data Server / serwer danych nieprzetworzonych
REFLI
Rejestry wewnętrzne sterownika sygnalizacji
Scala
SIEMENS product name for Urban Traffic Central System / Nazwa własna
Centralnego Systemu Sterowania Ruchem firmy SIEMENS
Signal Plan / program sygnalizacji
SIPL
S-L , Sitraffic S-L
SNRT
Nazwa własna algorytmu sterowania sygnalizacją świetlną firmy
SIEMENS
System Nadzoru Ruchu Tramwajowego
SPA
System wyboru programu
STRAMO
ZaleŜny od ruchu wybór programu sygnalizacji
SW
Software / Oprogramowanie
TAE
Telegram Decoding Unit / Moduł dekodujący telegramy
TASS
Traffic actuated signal plan selection / System automatycznego,
zaleŜnego od ruchu wyboru planów sygnalizacyjnych
TCP/IP
protokół komunikacji sieciowej
TL
Traffic Language / Język programowania sterowania ruchem
TMS
Traffic Management System / System Zarządzania Ruchem
UPS
Uniteruptable Power Supply / Zasilanie Awaryjne
USER
UŜytkownik
UTC
Urban Traffic Control / Sterowanie Ruchem w Mieście
UTCS
Urban Traffic Central System / Centralny System Sterowania Ruchem
VSR
system sterowania ruchem
WAUT
Tygodniowa automatyka sterowania
XML
Extensible Markup Language / uniwersalny język programowania
ZWD
green wave diagram / wykres koordynacji
Tabela 1.1: Skróty
1.2. Opis ogólny
Zintegrowany System Zarządzania Ruchem w Warszawie stanowi zbiór metod i środków
oddziaływania na ruch drogowy. Zarządzanie informacją odbywa się na podstawie danych
o stanie bieŜącym ruchu i środowiska. Celem systemu zarządzania ruchem jest
zapewnienie optymalnego przepływu osób i towarów na obszarze jego oddziaływania.
Efektywność pracy Zintegrowanego Systemu Zarządzania Ruchem będzie osiągnięta
dzięki wymianie informacji między podsystemami oraz zastosowaniu nowoczesnych metod
analizy i przewidywania sytuacji ruchowej.
Wersja 4.0
12/192
Zintegrowany System Zarządzania Ruchem w Warszawie będzie wdraŜany stopniowo w
dwóch płaszczyznach:
- płaszczyźnie rozbudowy terytorialnej (wdraŜanie kolejnych obszarów)
- płaszczyźnie funkcjonalnej (uruchamianie poszczególnych podsystemów w
kolejnych latach budowy systemu)
Niniejsze opracowanie dotyczy budowy Zintegrowanego Systemu Zarządzania Ruchem w
obszarze I, obejmującego w płaszczyźnie terytorialnej: rejon Powiśla, ciąg
Al. Jerozolimskich na odcinku od Ronda Waszyngtona do Placu Zawiszy oraz ciąg
Wisłostrady od mostu S. Grota – Roweckiego do mostu Siekierkowskiego (rysunek 1.2).
Rysunek 1.2: Zakres terytorialny pierwszego obszaru Zintegrowanego Systemu Zarządzania
Ruchem w Warszawie
Budowany system składa się z wielu podsystemów o róŜnym stopniu oddziaływania na
ruch i pozyskiwania informacji, uwzględniając jednocześnie moŜliwości dalszej jego
rozbudowy.
Z uwagi na przewidywany program wdraŜania Zintegrowanego Systemu Zarządzania
Ruchem w Warszawie system ten jest systemem otwartym tzn. umoŜliwia jego
Wersja 4.0
13/192
rozszerzanie o kolejne podsystemy w przyszłości, w miarę pojawiających się potrzeb
funkcjonalnych i terytorialnych.
Zintegrowany System Zarządzania Ruchem dla obszaru I będący przedmiotem niniejszej
koncepcji składa się z dwóch faz:
I. fazy projektowej obejmującej:
- projekty podsystemów sterowania sygnalizacją świetlną w pierwszym obszarze
Zintegrowanego Systemu Zarządzania Ruchem powiązanych z systemem
sterowania w tunelu pod Wisłostradą
- projekt podsystemu informacji dla kierowców poprzez znaki zmiennej treści
- projekt podsystemu informacji o środowisku (pogoda, zanieczyszczenie
środowiska itp.)
- projekt podsystemu zarządzania przejazdami pojazdów uprzywilejowanych –
nadawanie priorytetów warunkowych lub bezwarunkowych dla pojazdów
komunikacji szynowej
- projekt podsystemu informacji o sytuacji ruchowej przy pomocy
ogólnodostępnych środków masowego przekazu (radio, RDS, Internet itp.)
II. fazy wdroŜeniowej obejmującej:
- wykonanie kompleksowych remontów sygnalizacji świetlnych na 14
skrzyŜowaniach obszaru I.
Remonty obejmą wymianę sterowników sygnalizacji świetlnych, wymianę
masztów i latarni sygnalizacyjnych, modernizację okablowania zasilającego
sygnalizacje świetlną, zainstalowanie detektorów kołowych i pieszych (przyciski
dla pieszych) oraz instalację układu pomiarowego energii elektrycznej.
Modernizacją objęte zostaną następujące skrzyŜowania:
Lp.
1
Nazwa skrzyŜowania
Sanguszki – Konwiktorska
2
3
4
5
6
7
8
9
10
11
12
13
14
WybrzeŜe Gdańskie – Grodzka
WybrzeŜe Kościuszkowskie - Nowy Zjazd
Wisłostrada – Ludna
Kruczkowskiego – KsiąŜęca
Ludna – Czerniakowska
Rozbrat – Łazienkowska
Czerniakowska – Gagarina
Rondo de Gaulle’a
Al. Jerozolimskie – Krucza
Rondo Waszyngtona
Plac Zawiszy
Al. Jerozolimskie – Chałubińskiego
Al. Jerozolimskie – Emilii Plater
Aktualny stan sygnalizacji podlegających remontom prezentuje załącznik nr 1.
- dostosowanie do pracy w systemie sterowania na 23 skrzyŜowaniach obszaru I
Dostosowanie obejmuje wymianę istniejących sterowników na sterowniki
wyposaŜone w moduły i interfejsy komunikacyjne, umoŜliwiające realizację funkcji
monitoringu i optymalizacji sieciowej w ramach Centrum Sterowania.
Wersja 4.0
14/192
W przypadku sygnalizacji wyposaŜonych w sterowniki produkcji SIEMENS
dostosowanie będzie polegało na uzupełnieniu sterowników o moduły
komunikacyjne.
Dostosowaniem objęte zostaną następujące skrzyŜowania:
Lp.
1
Nazwa skrzyŜowania
WybrzeŜe Gdańskie – Wenedów
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
WybrzeŜe Gdańskie – Sanguszki
Wjazd do tunelu N
Dobra – Lipowa
Browarna – Lipowa
Browarna – Karowa
Tamka – Most Świętokrzyski
Zajęcza – Dobra
Tamka – Dobra
Zajęcza – Topiel
Tamka – Kruczkowskiego
Wjazd do tunelu S
Kruczkowskiego – Czerwonego KrzyŜa
Czerniakowska – Witosa
Czerniakowska – Chełmska
Czerniakowska – Łazienkowska
Rozbrat – Górnośląska
Czerniakowska – Bartycka
Marszałkowska – Al. Jerozolimskie
Al. Jerozolimskie – Miedziana
Al. Jerozolimskie – śelazna
Czerniakowska – SzwoleŜerów
Karowa – Dobra
Aktualny stan sygnalizacji podlegających dostosowaniom prezentuje załącznik nr 2.
- budowa sieci łączności pomiędzy lokalnymi urządzeniami systemu zarządzania
ruchem a Centrum Sterowania. Dla łączności będzie wykorzystywana sieć na
bazie technologii światłowodowej a w przypadku znaków zmiennej treści
zlokalizowanych po północnej stronie mostu Grota-Roweckiego – łączność
poprzez GPRS.
- wdroŜenie systemu zarządzania przejazdami uprzywilejowanymi w ciągu Alei
Jerozolimskich poprzez nadawanie priorytetu tramwajom na
9 skrzyŜowaniach, na odcinku od Ronda Waszyngtona do Placu Zawiszy.
- budowa systemu informacji dla kierowców opartego na tablicach zmiennej treści
umieszczonych w wybranych lokalizacjach na terenie miasta Warszawy.
Lokalizacje tablic mają ścisły związek z moŜliwością dynamicznego
oddziaływania na zachowania kierowców w obszarze I.
- budowa Centrum Sterowania i Zarządzania Ruchem zlokalizowanego w siedzibie
Zarządu Dróg Miejskich przy ul. Chmielnej 120
- wykonanie systemu monitoringu i zarządzania tunelem w Zagłębieniu Wisłostrady
- wykonanie internetowego serwisu informacyjnego o ruchu drogowym w granicach
obszaru I.
Wersja 4.0
15/192
W ramach Zintegrowanego Systemu Zarządzania Ruchem w Warszawie jako priorytetowy
przyjęto podsystem sterowania ruchem, którego podstawową funkcją jest efektywne
zarządzanie sygnalizacjami świetlnymi i realizacja priorytetu dla transportu zbiorowego.
Podsystem sterowania ruchem umoŜliwia realizację sterowania obszarowego, opartego na
generowaniu przez system centralny w czasie rzeczywistym parametrów sterowania dla
sterowników lokalnych. Sterowanie odbywa się w oparciu o aktualne pomiary ruchu i
prognozę krótkoterminową, która jednocześnie stanowi bazę danych dla systemu
informacji o ruchu w sieci.
Rozwiązania Zintegrowanego Systemu Zarządzania Ruchem w Warszawie wdraŜane na
obszarze I, umoŜliwiają:
- realizację
róŜnych
strategii
sterowania
(minimalizacja
strat
czasu,
maksymalizacja przepustowości w obszarze, minimalizacje długości kolejek itp.)
w odniesieniu do zaistniałych warunków ruchu
- realizację automatycznego wyboru strategii sterowania
- współpracę systemu sterowania z róŜnymi typami detekcji (pętle indukcyjne,
wideodetekcja, detekcja z wykorzystaniem czujników podczerwieni itp.)
- realizację priorytetu dla transportu zbiorowego
WdraŜany Zintegrowany System Zarządzania Ruchem w Warszawie, w zakresie
sterowania sygnalizacjami świetlnymi na skrzyŜowaniach ma charakter wielopoziomowy.
NajniŜszy poziom stanowią lokalne sterowniki sygnalizacji świetlnych.
KaŜdy sterownik lokalny będzie podłączony do systemu obszarowego sterowania ruchem.
Podsystem sterowania obszarowego ma za zadanie nadzorowanie i optymalizację
sterowania na skrzyŜowaniach wykorzystując metodę optymalizacji sieciowej (MOTION).
Poziom najwyŜszy stanowi Centrum Zarządzania Ruchem, nadzorujący sterowanie
ruchem przy jednoczesnym łączeniu funkcji zarządzania ruchem poprzez wykorzystanie
podsystemów informacyjnych.
Na potrzeby budowy systemu zarządzania ruchem w Warszawie Siemens dostarczy
system SITRAFFIC Scala/Concert, oparty na nowoczesnej zasadzie Client/Server
zorientowanej na potrzeby uŜytkowników i spełnienie wymagań przetargu.
Jest to system, który moŜe być dalej rozbudowywany, a dzięki zastosowaniu standardu
OCIT umoŜliwia on takŜe integrację urządzeń sygnalizacji świetlnej innych producentów, o
ile są one oparte na standardzie OCIT. Zapewnia to jednak tylko zakres funkcjonalny
właściwy dla standardu OCIT. Funkcje wykraczające poza zakres funkcjonalny OCIT mogą
być zrealizowane tylko przy zastosowaniu sterowników firmy Siemens.
Podstawę systemu zarządzania ruchem, który ma zapewnić bezproblemowe uŜytkowanie
urządzeń drogowej sygnalizacji świetlnej i dołączonych podsystemów, stanowią
następujące funkcje:
wizualizacja
archiwizacja
adaptacyjne sterowanie ruchem
komunikaty
przetwarzanie danych pomiarowych
analiza jakościowa (online i offline)
planowanie ruchu
sterowanie w tunelach
CCTV (telewizja przemysłowa)
system informacji o ruchu drogowym (oparty na środkach masowego przekazu).
Wersja 4.0
16/192
Ze względu na postęp techniczny i stały rozwój zarówno narzędzi, jak i sprzętu naleŜy
oczywiście liczyć się z moŜliwością, Ŝe do momentu dostawy i instalacji systemu na rynku
znajdą się nowocześniejsze, bardziej zaawansowane komponenty, które będzie moŜna
zastosować po uzgodnieniu ze zleceniodawcą.
1.3. Zgodność z OCIT
Struktura systemu zarządzania ruchem drogowym dla Warszawy opiera się na tak zwanej
architekturze bazowej OCIT i jest wyposaŜona w następujące interfejsy OCIT:
OCIT-Outstations V1.1.
Podłączenie urządzeń sterujących kompatybilnych z OCIT odbywa się za pośrednictwem
standaryzowanego interfejsu OCIT-Outstations w wersji 1.1. NaleŜy w tym celu zapoznać
się z następującymi dokumentami (p. www.ocit.org):
OCIT-Outstations, wprowadzenie do systemu, OCIT-O-System_V1_1_A01
OCIT-Outstations, urządzenia sterowania sygnalizacją świetlną, OCIT-O-Lstg_V1_1_A02
OCIT-Outstations, funkcje bazowe urządzeń polowych, OCIT-O-Basis_V1_1_A02
OCIT-Outstations, reguły i protokoły, OCIT-O-Protokoll_V1_1_A01
OCIT-Outstations, profil 1 – profil transmisji dla połączeń punkt-punkt na łączach stałych,
OCIT-O-Profil_1_V1_1_A01
Załącznikiem nr 3 do koncepcji jest tłumaczenie opisu funkcjonalnego interfejsu OCIT –
„OCIT-O_V1.1_Funktionsspiegel_V1.0_A01”. Pozwala ono na zapoznanie się z
właściwościami i funkcjami interfejsu OCIT. Dodatkowo załączono wersję oryginalną tego
dokumentu (załącznik nr 4).
Dalsza oficjalna dokumentacja dotycząca OCIT nie jest aktualnie dostępna.
PoniŜej znajduje się krótki opis standardu OCIT.
Podstawowe załoŜenia systemu OCIT powstały w firmie Siemens AG i były dalej
opracowywane wspólnie z firmą Signalbau Huber AG. Przy pracach nad systemami
otwartymi wykorzystano takŜe otwarty interfejs NTCIP (USA) i prowadzone na jego
podstawie prace w ISO.
Oprócz podstawowych załoŜeń koncepcyjnych otwarty interfejs wymaga przede wszystkim
porozumienia między producentem a uŜytkownikiem odnośnie funkcji urządzenia i
odpowiednich danych sterujących. Dlatego niezbędna jest współpraca uŜytkownika i
producenta, zarówno na etapie projektowania jak i później przy wieloletniej aktualizacji. Na
tym polega zasadnicza róŜnica między interfejsami otwartymi a systemami opracowanymi
samodzielnie przez producenta i „przedstawianymi” dopiero po ich wykonaniu. Do tej pory
udało się pozyskać dalszych producentów do realizacji tej koncepcji. Następujący
producenci współpracują pod nazwą ODG (OCIT Developer Group) dąŜąc do wspólnego
opracowania systemu OCIT:
Dambach, Siemens AG, Signalbau Huber AG, Stoye i Stührenberg.
Równolegle do prac prowadzonych w Niemczech grupa ODG dąŜy do zabezpieczenia
koncepcji OCIT poprzez nawiązywanie współpracy z innymi producentami europejskimi.
Główny cel prowadzonej współpracy to zaakceptowanie koncepcji przez rynek.
Towarzyszy mu dąŜenie do jej standaryzacji przez CEN.
Wersja 4.0
17/192
W systemie OCIT dane definiowane są według ścisłych reguł. Tak zdefiniowane dane
określane są jako obiekty OCIT. Reguły te mogą być stosowane takŜe odnośnie danych
specyficznych, czyli funkcji, które nie zostały uwzględnione w standardzie OCIT. Dane te
mogą być potem wykorzystywane w systemie analogicznie jak obiekty standardowe.
Sprowadzane bardzo zróŜnicowane i obszerne dane (dane w dowolnych formatach), np.
dotyczące logiki sterowania, są przekazywane w formie neutralnie zapakowanych plików.
W odróŜnieniu do obiektów OCIT, dane te są obsługiwane przy pomocy narzędzi danego
producenta.
Przekaz danych w systemie OCIT podlega regułom ISO dotyczącym systemów otwartych
— model warstwowy OSI Open System Interconnection. NajwaŜniejszym protokołem na
poziomie uŜytkownika jest protokół uŜytkownika OCIT, a na poziomie przesyłu - protokół
TCP/IP. RóŜne protokoły w warstwie 2 zapewniają moŜliwość wykorzystania róŜnych
urządzeń i mediów do przesyłu danych. W pierwszej kolejności stosowane są modemy
standardowe.
W systemie OCIT dane są definiowane według ściśle określonych reguł. Tak zdefiniowane
dane określane są jako obiekty OCIT. Jest bardzo waŜne, aby kaŜdy obiekt OCIT otrzymał
jednoznacznie identyfikującą go nazwę. Dotyczy to takŜe obiektów wytwarzanych przez
poszczególnych producentów dla specjalnych funkcji bez dalszych uzgodnień. W tym celu
stosowany jest język opisu danych, umoŜliwiający maszynowe przetwarzanie danych.
Wersja 4.0
18/192
2.
Koncepcja systemu (Sitraffic Scala/Concert)
2.1.
Struktura systemu
Rysunek 2.1 przedstawia schematyczną budowę systemu, który ma być zastosowany w
Warszawie.
Klient
Klient
Klient
Poziom 4
Narzędzia
Serwer Systemu
IG
Poziom 3
RDS
Poziom 2
Zewnętrzny punkt dostępowy
OCIT- urządzenie
inne
SIEMENS
OCIT- urządzenie
SIEMENS
OCIT - urządzenie
Poziom 1
Rysunek 2.1: Struktura logiczna systemu
System składa się z czterech poziomów i jest zbudowany następująco:
Klient (poziom 4) – pole zaznaczone na niebiesko
Bazujący na sieci klienci do obsługi, wizualizacji i działania systemu
Nie są wymagane dodatkowe nakłady na instalację
MoŜliwość wykorzystania pracujących juŜ w sieci zleceniodawcy komputerów PC
Narzędzia (poziom 3/4) – pola zaznaczone na czerwono i niebiesko
Narzędzia planistyczne dla inŜynierów ruchu (P2)
Narzędzie zapewnienia jakości do analizy ruchu indywidualnego i ruchu pojazdów
transportu publicznego
Wersja 4.0
19/192
Serwer Systemu (poziom 3) – pole zaznaczone na czerwono
Skalowalny system z 1 – 4 (maks. 20) serwerami UTC/TMS
Centralne zarządzanie danymi
Dane, procesy i wizualizacje są zapamiętywane, monitorowane i administrowane
Serwer z funkcjonalnością On-line - czasu rzeczywistego (poziom 2) – pole
zaznaczone na zielono
Wstępne przetwarzanie danych i komunikacja
ZaleŜny od czasu wybór planu sygnałowego
Prosty interfejs uŜytkownika ze strategią Fall-Back
Zastosowane będą
- Intelligent Gateways (IG) do podłączenia urządzeń na skrzyŜowaniach produkcji
Siemensa i/lub obcych za pośrednictwem interfejsu OCIT
Urządzenia lokalne (poziom 1) – pole zaznaczone na Ŝółto
Z wyborem programu zaleŜnie od czasu lub (natęŜenia) ruchu oraz zaleŜną od
ruchu optymalizacją planu sygnałowego
Podłączenie sterowników sygnalizacji Siemensa (C800/C900) za pośrednictwem
interfejsu OCIT
Podłączenie sterowników sygnalizacji produkcji innej niŜ Siemensa za
pośrednictwem interfejsu OCIT
Na rysunku 2.2 przedstawiono szczegółową strukturę systemu SITRAFFIC
Scala/Concert.
MoŜliwość rozbudowy systemu ilustruje takŜe Rysunek 13.1 Centrala systemu
zarządzania ruchem.
Wersja 4.0
System
informacji
massmedia
Partyline, GSM,
GPRS, etc.
System VMS
Funkcje opcjonalne
OCIT-I VD
Signs
System kontroli
tuneli
Znaki
System RBL/
System
informacji dla
pasaŜerów
Strefa
parkingowa
Usługi Partyline,
GSM, GPRS itp..
System
informacji
parkingowej
VDV
SOAP/XML
Serwer
aplikacji
Statystyka
STÖMA
Q2
P2
Sterownik
Modem
V.34
Modem
Połączenie OCIT
Oparte o TCP/IP
MOTION
Strategia
Wizualizacja
C800V/C900V
GSM
N-COM
GSM
IG
Serwer
komunikacyjny
MEWA
JAUT
BEMA
GIS
Serwer GUI
GIS
System VMS
RDS
System UTC
OCIT-I PD
Sterownik
Ethernet LWL/DSL
Funkcje ujęte w kontrakcie
System
informacji o
środowisku
Sterowanie
Dostarczanie
danych
Serwer S4
Klient
Rozszerzenie zdolności
komunikacji zgodnie z
wymaganiami
Rozszerzenie umoŜliwiające
podłączenie dodatkowych
systemów, zgodnie z
wymaganiami
Skanowalność serwera,
zgodnie z wymaganiami
(system zawierający 2/3/4
serwery)
Modułowe rozszerzenia
funkcjonalności, zgodnie
z wymaganiami
Rozszerzenie stacji
roboczej operatora oraz
jej funkcjonalności,
zgodnie z wymaganiami
20/192
Rysunek 2.2: Szczegółowa struktura systemu SITRAFFIC Scala/Concert
Wersja 4.0
2.2.
21/192
Omówienie oferowanego systemu SITRAFFIC
SCALA/CONCERT
2.2.1. Struktura sprzętowa systemu SITRAFFIC SCALA/CONCERT
Rysunek 2.3: Struktura fizyczna systemu SITRAFFIC Scala/Concert
Wersja 4.0
22/192
2.2.2. Odzwierciedlenie funkcji całego systemu
Na rysunku 2.4 przedstawione są najwaŜniejsze funkcje całego systemu i główne kierunki
przepływu danych:
Rysunek 2.4: Funkcje systemu zarządzania ruchem w Warszawie (schemat)
Wersja 4.0
23/192
Krótki opis
Tabela 2.5 zawiera wykaz istotnych funkcji systemu jako całości.
Funkcja
Planowanie
Planowanie VA
Programowanie
Testowanie
QA
Wizualizacja
Obsługa/
konfiguracja
Eksploatacja/
zdarzenia
Protokoły/
statystyka
Krótki opis
Oprogramowanie dla stanowiska pracy inŜyniera
ruchu, umoŜliwiające tworzenie projektów
Narzędzie planistyczne do zaleŜnego od ruchu
sterowania PDM
Narzędzie firmy SIEMENS do zdalnego
programowania urządzeń sterujących SIEMENS i
programowania systemu sterowania ruchem
Pakiet oprogramowania do testów i symulacji
programów akomodacyjnych
Pakiety oprogramowania do kontroli i analizy jakości
Prezentacja online informacji o stanie systemu
sterowania ruchem (VSR) lub podłączonych
urządzeń sterujących.
W skład wchodzą:
• prezentacja sieci GIS
• prezentacje online działania sygnalizacji na
jednym skrzyŜowaniu lub większej ich liczbie
w postaci/na bazie planu sytuacyjnego
skrzyŜowań lub diagramu planu sygnalizacji
bądź teŜ wykresu czas-droga
Okienko do wprowadzania danych ręcznie.
MoŜliwość wprowadzania danych w celu
dostosowania parametrów
Listy i szczegółowe prezentacje danych na temat
stanu systemu i komunikatów
Narzędzia do generowania protokołów i statystyk
BEMA
Archiwum komunikatów o pracy systemu
MEWA
Archiwum wartości pomiarowych
Przetwarzanie
danych
Serwer danych
surowych
Algorytmy tworzenia wartości pochodnych
Sterowanie
strategiczne
(Response plan +
STRAMO)
Adaptacyjne
sterowanie siecią
MOTION
Automatyka roczna
Komponent słuŜący do ewidencji, buforowania i
udostępniania surowych danych z urządzeń
sterujących sygnalizacją świetlną (LSA)
Sterowanie strategiczne na bazie informacji
własnych i obcych
ZaleŜny od ruchu wybór programu sygnalizacji
Komponent
SITRAFFIC P2
TL
SITRAFFIC Control
Vissim
SITRAFFIC QM/Q2
SITRAFFIC
Scala/Concert Client
[Visu Signal Plan,
Visu Intersection,
Visu Green Wave]
SITRAFFIC
SITRAFFIC
SITRAFFIC
[Statistic & Report
Tool]
SITRAFFIC
Scala/Concert Server
SITRAFFIC
SITRAFFIC
SITRAFFIC
SITRAFFIC
Adaptujące się do sytuacji na drodze sterowanie
sieciowe
SITRAFFIC MOTION
ZaleŜne od czasu sterowanie na bazie kalendarza
rocznego z uwzględnieniem dni powszednich, świąt,
wakacji i ferii oraz dni szczególnych
SITRAFFIC
Scala/Concert
Server/ IG
Wersja 4.0
Funkcja
Priostack
Sterowanie
sygnalizacją
System RAID
Krótki opis
Część systemu sterowania, odpowiedzialna za
koordynację Ŝądań zgłaszanych przez róŜne
poziomy sterowania (automatyka roczna, MOTION,
obsługa itp.)
Część systemu sterowania, odpowiedzialna za
sterowanie sygnalizacją świetlną
Wszystkie serwery są wyposaŜone w systemy RAID
i napędy do zabezpieczania kompletnych
odwzorowań systemu oraz danych archiwalnych i
danych dotyczących aplikacji.
24/192
Komponent
IG
IG
SITRAFFIC
Tabela 2.5: Wykaz funkcji systemu zarządzania ruchem w Warszawie (tabelaryczny)
Tabela 2.6 zawiera wykaz istotnych interfejsów kompletnego systemu.
Interfejs
Komunikacja z
outstation OCIT
Komunikacja
SIEMENS
Interfejs
specyficzny dla
projektu
Lokalny dostęp do
systemu
(specyficzny dla
producenta)
Krótki opis
Interfejsy OCIT-O V1.1 urządzeń sterujących
kompatybilnych z OCIT
Wewnętrzne interfejsy SIEMENS – przede
wszystkim między procesami serwerów i klientów,
np. między platformami obsługi i odpowiednimi
aplikacjami na serwerze
Interfejs podsystemów na bazie XML
Specyficzny dla producenta urządzeń interfejs
umoŜliwiający bezpośredni dostęp na miejscu
Komponent
SITRAFFIC
Scala/Concert
Server/Client
SITRAFFIC
Specyficzne dla
producenta narzędzie
wprowadzania
danych
(w przypadku
urządzeń SIEMENS:
SITRAFFIC Control)
Tabela 2.6: Interfejsy systemu zarządzania ruchem w Warszawie
2.3.
Krótki opis oprogramowania przewidzianego dla systemu
zarządzania ruchem
2.3.1. SITRAFFIC Client - klient obsługi (nadzór i wizualizacja)
SITRAFFIC Client jest graficzną platformą obsługi i dowodzenia nowego systemu
zarządzania ruchem dla Warszawy.
NajwaŜniejsze cechy SITRAFFIC Client to:
Informowanie
Przełączanie
Przetwarzanie i generacja zgłoszeń
Analiza danych
Ogólne funkcje systemowe
UŜytkownicy i grupy uŜytkowników
Uprawnienia dostępu
Wersja 4.0
25/192
Pliki konfiguracyjne
System pomocy
SITRAFFIC Client zawiera archiwa, w których gromadzone są bezterminowo róŜnorodne
komunikaty robocze i dane pomiarowe. Wielkości te moŜna poddać obróbce z
wykorzystaniem zintegrowanych procedur do opracowywania wyników.
2.3.2. SITRAFFIC Supply (System zarządzania danymi)
Do Systemu TMS/UTC Warszawa dane są dostarczane przez managera systemu
zarządzania danymi SITRAFFIC Supply 4 w sposób zorientowany na obiekty.
Dostarczane są następujące dane:
o
o
dane bazowe komputera ruchu
dane bazowe urządzeń sterujących sygnalizacji świetlnej (LSA)
Dostarczanie danych do komputera ruchu i urządzeń sterujących odbywa się za
pośrednictwem managera SITRAFFIC Supply. Posiada on zintegrowane jako edytor dla
urządzeń sterujących narzędzie SITRAFFIC Control.
SITRAFFIC Supply/Control są zintegrowane w ramach systemu danych.
SITRAFFIC Supply zarządza danymi w kilku obszarach:
w jednym dane są składowane i mogą być pokazywane uŜytkownikowi w
zaleŜności od jego uprawnień (zasoby);
o w następnym obszarze dane mogą być poddane przetworzeniu (obszar roboczy);
o skasowane dane są składowane w trzecim obszarze, zanim będą mogły zostać
definitywnie skasowane przez uŜytkownika (obszar roboczy – dane skasowane).
o
2.3.3. SITRAFFIC Control (lokalne i zdalne programowanie sterowników
sygnalizacji)
SITRAFFIC Control oferuje komfortową platformę edycji danych dostarczanych
urządzeniom sterującym Siemens.
Wszystkie dane dotyczące danego skrzyŜowania są gromadzone w jednym projekcie.
Program juŜ w trakcie konfiguracji sterownika sprawdza kaŜdy parametr (dane
podstawowe, program uŜytkownika, symulacja itp.) pod kątem zaleŜności i wzajemnej
spójności.
Dostarczane dane są prezentowane w postaci drzewa obiektów podziale podziałem na
obszary; moŜna je zmieniać za pomocą edytorów. W pewnych obszarach są zastosowane
edytory graficzne, co ułatwia wprowadzanie danych.
Dzięki całkowitemu lub częściowemu importowi danych z istniejących juŜ projektów moŜna
znacznie skrócić czas edycji.
Programowanie sterowników sygnalizacji
Przejrzyste struktura wprowadzania danych i edytory
Przekazywanie danych do programu symulacyjnego VISSIM
Integracja z modułem SITRAFFIC Konzept
Dalsze informacje moŜna znaleźć w rozdziale 2.3.4.
Wersja 4.0
26/192
2.3.4. Statystyki i protokoły (wizualizacja i przetwarzanie wartości pomiarowych)
Wszystkie dane dynamiczne wszystkich obiektów (detektorów itd.) są zapisywane w
archiwum. MoŜliwe jest ich późniejsze wykorzystanie.
Oprogramowanie do opracowywania danych stanowi samodzielny moduł, zrealizowany na
bazie generatora raportów. Do sporządzania protokołów i statystyk stosuje się
standardowe narzędzie raportowania (np. Jasper). Dane zapamiętane w systemie
archiwizującym moŜna przedstawić na następujących osiach:
oś czasu (wykresy czasowe),
przy róŜnych typach danych moŜliwa jest prezentacja z dwiema osiami y;
oś wartości (histogramy).
Osie prezentacji zawierają opisy z podaniem rodzaju i jednostki przedstawianego obiektu,
np. natęŜenie ruchu [pojazdy/h] i czas [min]. Protokoły i statystyki moŜna wyświetlić na
ekranie lub wydrukować.
Bardziej wyczerpujący opis moŜna znaleźć w rozdziale 9.1 Statystyki i protokoły
2.3.5. SITRAFFIC P2 (planowanie z zakresu inŜynierii ruchu )
SITRAFFIC P2 jest narzędziem planistycznym z zakresu inŜynierii ruchu koncernu
Siemens AG.
Szczególne znaczenie ma efektywne ukształtowanie całego procesu, od załoŜeń aŜ po
eksploatację urządzenia sygnalizacji świetlnej.
SITRAFFIC P2 wspomaga inŜyniera ruchu. Program wspomaga zadania związane z
projektowaniem za pomocą najnowocześniejszych metod i edytorów graficznych, co
pozwala na ich szybką i efektywną realizację.
Dane wytworzone za pomocą modułu SITRAFFIC P2 moŜna dalej wykorzystywać po ich
zaimportowaniu do programu SITRAFFIC Control. Do celów prostego sterowania
stałoczasowego moŜna je, po uzupełnieniu o dane specyficzne dla systemu, przesłać do
sterownika sygnalizacji lub dokonać ich transferu do systemu sterowania ruchem.
Oznacza to istotny wzrost bezpieczeństwa dzięki spójnym zasobom danych na stanowisku
planowania i na poziomie sterowania oraz wymierną oszczędność czasu i kosztów.
PoniewaŜ właściwości i dane dla urządzeń sterujących oraz procedur sterowania moŜna
uwzględnić juŜ na etapie projektowania w SITRAFFIC P2, nie są konieczne Ŝadne inne
kosztowne działania dopasowujące.
Centralne zadania programu to
interaktywne stanowisko pracy inŜyniera ruchu z zarządzaniem wersjami
w pełni graficzne środowisko m.in. z liniami odniesienia i obszarami konfliktów na
bazie planu sytuacyjnego
obliczanie czasów międzyzielonych według róŜnych procedur z automatycznym
określaniem odległości na podstawie planu sytuacyjnego
graficzne opracowywanie i funkcje generowania przejść między fazami i
harmonogramów sygnalizacji
opracowywanie i wizualizacja danych o ruchu drogowym
komfortowe obliczanie i opracowywanie harmonogramów sygnalizacji
obliczenia wg HBS 2001
Wersja 4.0
27/192
funkcje wspomagające słuŜące do tworzenia parametrów dla akomodacyjnych
algorytmów sterowania PDM i S-L
komfortowy edytor graficzny do opracowywania diagramów skoordynowanej
sygnalizacji świetlnej
optymalizacji ruchu pojazdów transportu publicznego
wymiana danych z programami do programowania sterowników sygnalizacji i
systemów sterowania ruchem rodziny Siemens
eksport danych do programu symulacyjnego VISSIM
Wymiana danych przez interfejsy OCIT® Instation.
Bardziej wyczerpujący opis moŜna znaleźć w rozdziale 5.1.Stanowisko inŜyniera
kierowania ruchem SITRAFFIC P2.
2.3.6. SITRAFFIC Language
SITRAFFIC Language (TL) jest środowiskiem programistycznym do edycji algorytmów
sterowników sygnalizacji MS lub C800V.
SITRAFFIC Language umoŜliwia tworzenie logiki dla programów sygnalizacji.
Główne zadania programu to:
prezentacja logiki jako strukturogramu
prezentacja logiki jako diagramu przepływu
moŜliwość włączenia samodzielnie zdefiniowanych funkcji
Przekazywanie danych do programu symulacyjnego VISSIM.
TL jest jednocześnie językiem, za pomocą którego projektant moŜe, bez znajomości
języka programowania, przekształcić algorytmy związane ze sterowaniem ruchem
drogowym w kod programowy. Edytor strukturogramów/diagramów przepływu wspomaga
uŜytkownika graficznie w formułowaniu warunków logicznych.
Bardziej wyczerpujący opis moŜna znaleźć w rozdziale 5.2.SITRAFFIC Language
(programowanie algorytmów logicznych techniki sterowania ruchem).
2.3.7. SITRAFFIC S-L (algorytm sterowania)
SITRAFFIC S-L jest standaryzowanym algorytmem sterowania zaleŜnego od natęŜenia
ruchu, zintegrowanym z obecnie istniejącym systemem. SITRAFFIC S-L jest
sparametryzowanym algorytmem sterowania fazowego zaleŜnym od planów ramowych
sterowania fazami, a takŜe sterowania lokalnego. MoŜna go zastosować do zadań
prostych i średnio skomplikowanych, bez moŜliwości definiowania skrzyŜowań
częściowych i częściowych faz ruchu. Program nadaje się do zastosowania z rodziną
sterowników sygnalizacji C800V. Wprowadzanie parametrów odbywa się w programie
SITRAFFIC Control za pomocą specjalnych edytorów. Po dokonaniu parametryzacji
moŜna przeprowadzić symulację za pomocą programu VISSIM bez konieczności
zastosowania urządzenia sterującego.
Główne cechy:
sparametryzowane zaleŜności logiczne
przejrzyste okna wprowadzania danych
test gotowej logiki sterownika za pomocą programu do symulacji VISSIM
integracja z programem SITRAFFIC Koncept
Wersja 4.0
28/192
2.3.8. SITRAFFIC PDM (algorytm sterowania)
SITRAFFIC PDM jest mikroskopowym algorytmem sterowania przeznaczonym dla
sterowników sygnalizacji firmy SIEMENS.
Główne cechy:
• rozszerzona biblioteka VA (funkcje akomodacji)
• moŜliwośc stworzenia własnej logiki sterowania przy pomocy programu TL
• test opracowanej logiki za pomocą narzędzia symulacji VISSIM
Algorytm PDM steruje grupami sygnalizacyjnymi i przejściami międzyfazowymi. W ramach
jednej fazy stan grup sygnalizacyjnychpozostaje bez zmian. Start przejść międzyfazowych
jest inicjowany przez uŜytkownika zgodnie z projektem algorytmu (Ŝądanie od detektorów
itp.).
2.3.9. SITRAFFIC Service (program do serwisowania i wizualizacji pracy sterownika
sygnalizacji)
SITRAFFIC Service jest komfortowym programem do obsługi, diagnozy i odczytywania
danych urządzenia sterowników syganlizacji.
Program umoŜliwia indywidualne dopasowanie wyświetlanych danych, przejście w tryb
pracy lokalnej lub ręczne wydłuŜenie czasu trwania fazy.
W celu zmiany programu sterującego istnieje moŜliwość wgrania danych do pamięci flash
sterownika. Dane znajdujące się w pamięci sterownika moŜna teŜ częściowo skasować.
Diagnostykę sterownika sygnalizacji wspomaga funkcja odczytu i zapamiętywania plików
dziennika i archiwów. MoŜna teŜ wyświetlić status poszczególnych archiwów.
Do dyspozycji ekspertów jest generator zdarzeń jako narzędzie do testowania pamięci dla
komunikatów Transportu Publicznego i telegramów TAE.
Podstawowe funkcje diagnostyczne to wizualizacja planów sygnalizacji (takŜe online) i
wizualizacja i symulacja detektorów. W celu diagnozy wejść i wyjść moŜna – podobnie jak
w symulacji detektorów – ustawić wybrane porty.
Z modułem SITRAFFIC Service zintegrowany jest program do testowania monitora
konfliktów.
Opcje diagnostyczne uzupełniają informacje na temat interfejsu do centrali i statusu
pamięci roboczej.
Dalszą istotną funkcją programu jest moŜliwość odczytu wielu danych urządzenia, takich
jak: informacje o statusie, stany rejestrów (REFLI), bądź tekstów dziennika zdarzeń i
zabezpieczeń sygnałowych.
Wersja 4.0
2.4.
29/192
Serwery
2.4.1. Uwagi ogólne
Centralnym elementem systemu SITRAFFIC SCALA/Concert są serwery systemowe.
Na serwerach systemowych są zapamiętywane, monitorowane i administrowane wszystkie
niezbędne do pracy systemu dane, procesy i wizualizacje. System zawiera następujące
serwery:
Serwer bazy danych:
Serwer do centralnego przechowywania danych.
Serwer aplikacji:
Serwer aplikacji słuŜy do realizacji następujących funkcji:
o
o
o
o
o
o
o
o
sterowanie strategiczne
automatyka roczna
przetwarzanie danych pomiarowych
MOTION
archiwum wartości pomiarowych
archiwum komunikatów roboczych
róŜne usługi dla serwera GUI
zarządzanie uŜytkownikami i licencjami
Serwer GUI
Serwer GUI udostępnia informacje niezbędne dla wszystkich funkcji obsługi i
wizualizacji stacji roboczych.
NaleŜą do nich m.in.:
o
o
o
udostępnianie aktualnych dynamicznych danych do prezentacji stanu
rzeczywistego i wizualizacji online
udostępnianie informacji z archiwów w razie zapytań
przyjmowanie i przetwarzanie rozkazów obsługi
Serwer interfejsów:
Realizuje róŜne interfejsy między komputerami.
Serwer planowania i danych:
Na potrzeby realizacji zadań związanych z planowaniem i danymi z dziedziny
inŜynierii ruchu drogowego są udostępniane róŜne programy i narzędzia,
korzystające z serwera centralnej bazy danych.
Serwer sterowania sieciowego:
Zawiera strategiczne i adaptacyjne sterowanie sieciowe.
Do serwera są przesyłane informacje z urządzeń lokalnych. Główne źródło informacji
stanowią dane o stanie sterowników sygnalizacji i dane o ruchu.
Szacunkowa (zgróbna) kalkulacja ilości zapisywanych danych dla obszaru I:
- komunikaty operacyjne
37 sterowników x 100 informacji dziennie x 300 bajtów na wiadomość = około 1MB
dziennie
- dane o ruchu z detektorów
250 detektorów x 400 kB dziennie = około 100 MB dziennie
Wersja 4.0
30/192
Daje to w sumie około 101MB dziennie zapisywanej informacji.
Dane są przechowywane na dysku serwera tylko przez ograniczony okres np. 6 miesięcy i
po tym okresie są zapisywane i archiwizowane przy pomocy napędu DAT.
Serwery pracują w oparciu o protokół sieciowy TCP/IP. TakŜe komunikacja w ramach
OCIT opiera się na protokole TCP/IP. Generalnie moŜna wykorzystać kaŜdą infrastrukturę
sieciową opartą na protokole TCP/IP, zarówno w przypadku przewodów świetlnych jak i
miedzianych. Wszystkie komputery pracujące w sieci otrzymują stały adres IP. W ramach
testów systemowych siecią zarządza firma Siemens. Po przekazaniu systemu siecią
będzie zarządzał ZDM lub instytucja przez niego wyznaczona.
W kaŜdej chwili technicznie moŜliwe jest rozszerzenie funkcji serwerów. Odbywa się ono
zgodnie z wymaganiami zleceniodawcy i zakłada wykonanie zgodnie ze specyfikacją
projektu komponentów sprzętowych i programowych.
2.4.2. Hardware
Komponenty PC
Primergy Rack
PY TX300S2r X/3.4/2M 2G
RAID 0,1
floppy, DVD ROM, 2x GB LAN
Napęd DAT
Band-LW DDS Gen5 36GB 3MB/s
wewn.
Dysk twardy
4x HDD U320 10000rpm 73GB hot plug
1" M
Mysz optyczna z kółkiem
Mysz optyczna z kółkiem (Logitech)
USB i PS/2 przyłącze (z adapterem)
Klawiatura
KBPC SX INT/D, standard
2.4.2.1. System dysków twardych
System dysków twardych serwerów jest zabezpieczony przed utratą danych za pomocą
sprzętowego kontrolera RAID.
System RAID z czterema dyskami po 73 GB jest zastosowany na poziomach 0 i 1
(RAID10):
Dzięki mirroringowi i stripingowi (p. teŜ rozdz. 2.15.1) serwery mają do dyspozycji
pojemność dwóch dysków (razem 146 GB).
Aby w razie wymiany dysków serwery mogły dalej pracować, zastosowano dyski hot plug,
które moŜna wyjmować i wkładać podczas pracy.
Kontroler i system operacyjny zapewniają, Ŝe podczas takich operacji nie powstaną
niespójne dane.
2.4.2.2. Napęd DAT
Serwery są wyposaŜone w napęd DAT. Napęd DDS GEN5 DAT ma pojemność 36 GB.
2.4.3. Software
Windows 2000 i Windows 2003 dla serwerów
Oracle dla wszystkich serwerów
XMLSPY 5 Home edition
Wersja 4.0
31/192
Symantec PC-Anywhere V11.0
Symantec Ghost V8.0
Virenscanner FP-WIN Professional
JLOOX
Koszt zakupu niezbędnych 5 licencji Oracle jest wliczony w cenę ofert.
Stosowana wersja Oracle to 10g (zastrzegamy moŜliwość instalacji nowszej wersji).
Skaner antywirusowy FP-WIN Professional jest programem stosowanym i
rekomendowanym przez Siemens A.G.
Na serwerach są zainstalowane komponenty oprogramowania zgodnie z rysunkiem 2.2
Szczegółowa struktura Systemu SITRAFFIC Scala/Concert
2.5.
Klienci
2.5.1. Uwagi ogólne
Wszystkie czynności związane z obsługą, Ŝądania danych i programowanie są w systemie
wykonywane przez tzw. klientów. Oprogramowanie zainstalowane na stacji roboczej
klienta umoŜliwia dostęp do definiowalnej puli danych, prezentowanej przez wyszukiwarkę
Siemens.
Klientów moŜna instalować w sieci niezaleŜnie od miejsca. Warunkiem jest połączenie
sieciowe z serwerem systemowym. W kaŜdej chwili moŜliwa jest integracja z dalszymi
klientami; w tym celu naleŜy jedynie zdefiniować prawa i zainstalować zgodnie z licencjami
oprogramowanie specyficzne dla komputerów sterujących ruchem drogowym.
Dla Warszawy przewidziano następujące stacje obsługi:
5 stacji w centrali (4 operatorskie + 1 kierownik centrum)
3 stacje jako zdalni klienci (Remote Clients)
1 stacja na stanowisku pracy inŜyniera ruchu
Stanowiska pracy są wyposaŜone w monitory TFT 19“, mysz, klawiaturę i nagrywarkę DVD
do indywidualnej archiwizacji danych przez uŜytkowników.
2.5.2. Hardware
Komponenty PC
Celsius Floorstand
CELSIUS M440 PWR
Procesor
Intel Pentium 4 HT 540 (3.4 GHz)
RAM
2x 512 MB DDR2 SDRAM PC533, niebuf.,
ECC
Karta graficzna
Nvidia Quadro FX 540, 128 MB
DVD-RW
DVD+-R/ +-RW, Double Layer, ATAPI
Napęd dyskietek
FDD 1.44MB
Wersja 4.0
32/192
Dysk twardy
HDD 160 GB, S-ATA, 7200 rpm, cichy
Karta sieciowa (PCI)
Gigabit Ethernet, SysKonnect
Mysz optyczna z kółkiem
Logitech PS/2 Interface
Klawiatura
KBPC SX INT/D, standard
Dodatek specyficzny dla
kraju (INT)
Kabel sieciowy - zasilający , instrukcja
obsługi (multi)
Liczba
licencji
Stacja w centrali 1
Stacja w centrali 2
Stacja w centrali 3
Stacja w centrali 4
Stacja w centrali 5
Stacja zdalna 1
Stacja zdalna 2
Stacja zdalna 3
InŜynier ruchu
2.5.3. Software
KLIENT
Windows XP Prof. system
operacyjny
Office 2003 Standard
PC Anywhere
Virenscanner
SITRAFFIC Scala/Concert Klient
System Alarm Management
SITRAFFIC SCALA/CONCERT
Visu Signal Plan
Visu Intersection
Visu Green Wave
SITRAFFIC GIS-Net
SITRAFFIC Statistic & Report Tool
SITRAFFIC SUPPLY
SITRAFFIC CONTROL
9
x
x
x
x
x
x
x
x
x
9
9
9
9
9
9
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
9
x
x
x
x
x
x
x
x
x
9
x
x
x
x
x
x
x
x
x
9
9
9
5
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
SITRAFFIC P2
VISSIM
Wybór planu sygnalizacji
(STRAMO)
1
1
9
x
x
x
x
x
x
x
x
x
x
x
Licencje programów Sitraffic P2, VISSIM i jedna licencja Sitraffic Control powinny być
zainstalowane na stacji dla inŜyniera ruchu.
Pozostałe 4 licencje Sitraffic Control mogą być zainstalowane na stacjach operatorów
systemu sterowania.
Wersja 4.0
33/192
Oprogramowanie jest zabezpieczone kluczem sprzętowym i moŜe być przenoszone
pomiędzy stacjami roboczymi.
2.6.
2.6.1.
Komponenty niezbędne dla sterowników sygnalizacji z OCIT
OCIT Intelligent Gateway (OCIT-IG)
2.6.1.1. Uwagi ogólne
Do komunikacji ze sterownikami sygnalizacji kompatybilnymi z OCIT niezbędny jest OCIT
Intelligent Gateway. Jest to przemysłowy komputer PC marki INONET zabudowany w
szafie 19“.
2.6.1.2. Hardware
przemysłowy PC 19“ Mayflower Iix (INONET)
Pentium P4 2,8 GHz/512kB
2 x RAM 512 MB
karta graficzna AGP
3 x dysk twardy 200 GB
napęd DVD 16/48x IDE
kontroler SATA RAID 5
2.6.1.3. Software
LINUX (SuSE Linux Version 9.2) - systemy operacyjne zostały dobrane w
zaleŜności od wymagań zastosowanego na nich oprogramowania systemowego –
dla OCIT-IG rekomendowanym jest system Linux
pakiet oprogramowania IG
pakiet oprogramowania serwera danych źródłowych
2.6.2.
Serwer danych źródłowych
Do rejestracji danych przekazywanych przez urządzenia OCIT, np. stanów grup
sygnałowych, urządzeń sygnalizacji świetlnej, wartości pomiarowych, wartości AP itd.,
słuŜy serwer danych źródłowych.
Serwer danych źródłowych pracuje na sprzęcie OCIT Intelligent Gateway IG.
2.7.
Drukarki
HP Laser Jet 1200N
1200 x 1200 dpi
szybkość druku (cz./b., DIN A4) : 14 stron/min
pamięć: 16MB RAM
Wersja 4.0
2.8
34/192
Zasilanie awaryjne (UPS)
Dla zapewnienia niezawodnej pracy system SITRAFFIC SCALA/CONCERT wymaga
zasilania awaryjnego (UPS). NaleŜy je tak zaprojektować, aby bez problemu
kompensowało wahania i zaniki napięcia sieci.
Po powrocie napięcia system SITRAFFIC SCALA/CONCERT samodzielnie ponownie
uruchomi się.
W Warszawie wymagany jest czas podtrzymania 360 minut. UPS jest tak zaprojektowany,
aby zasilać przez ten czas serwery i klientów.
JeŜeli przerwa w zasilaniu będzie dłuŜsza niŜ 360 minut, system wyłączy się w sposób
zdefiniowany.
Do UPS są podłączeni klienci, IG i serwery (nie są podłączone drukarki laserowe).
Serwery i urządzenia komunikacyjne w centrum sterowania będą zabezpieczone
przez UPS z czasem podtrzymanie do 6 godzin:
Funkcje UPS-a:
technologia true on-line z podwójną konwersją energii, sinusoida na wyjściu,
jednofazowy konwerter wejściowy,
przetwornica ładująca baterie - charger (czas ładowania rozładowanej baterii
standardowej - 1,5 do 3 godzin do pojemności 90%),
falownik jednofazowy IGBT;
wyświetlacz ciekłokrystaliczny pokazujący wszystkie stany pracy UPSa,
automatyczny (statyczny) system obejściowy (bypass elektroniczny),
ręczny (serwisowy) system obejściowy (bypass ręczny),
baterie hermetyczne VRLA o Ŝywotności 5 – 8 lat,
filtr radioelektryczny,
funkcja comiesięcznych automatycznych testów bateryjnych,
funkcja głębokich testów bateryjnych (kalibracja baterii),
układ konserwującego ładowania baterii (2,25V/ogniwo) w czasie obecności sieci,
układ forsującego ładowania baterii (2,4V/ogniwo) po wcześniejszym rozładowaniu
baterii i powrocie sieci; po osiągnięciu 100% pojemności przejście na
charakterystykę ładowania buforowego 2,25V/ogniwo,
system temperaturowej korekcji napięcia ładowania baterii,
funkcja startu (uruchomienia) UPSa z baterii,
funkcja automatycznego programowalnego shutdownu i restartu,
programowalna funkcja automatycznego wyłączenia UPSa w przypadku obniŜenia
się obciąŜenia do poziomu <2% mocy znamionowej (w czasie pracy bateryjnej),
funkcja dostosowywania częstotliwości wyjściowej do wejściowej (do współpracy z
agregatem prądotwórczym o nieustabilizowanych elektrycznych parametrach
wyjściowych),
zestaw komunikacyjny:
- port (interfejs) komunikacyjny RS232,
- interfejs zdalnego awaryjnego wyłączenia UPSa (wyłącznik p/poŜ),
- sloty do zamontowania karty sieciowej SNMP lub karty styków beznapięciowych,
- slot do zamontowania karty pracy równoległej,
dokumentacja techniczna w języku polskim.
Charakterystyka oprogramowania:
• Transmisja alarmów zdefiniowanych przez UŜytkownika,
• Kontrolowany i automatyczny shutdown systemu,
• Kontrolowany i automatyczny shutdown UPSa,
• Programowany shutdown systemu & UPSa,
Wersja 4.0
•
•
•
•
•
•
35/192
Programowane testowanie UPSa,
Struktura Klient / Agent,
Program Proxy Agent (agent do instalacji na komputerze/serwerze zastępujący kartę
sieciową),
program współpracuje z siecią informatyczną. Ma wbudowane mechanizmy
współpracy z siecią lokalną LAN i rozległą WAN. Wykorzystuje do tego standardowe
rozwiązanie - protokół SNMP.
program ma wbudowany prosty serwer WEB umoŜliwiający zdalne zarządzanie przez
Internet lub inną sieć TCP/IP.
program prowadzi w historii analizę zasilania i inne zestawienia dotyczące UPS-a i
systemu operacyjnego.
KaŜda stacja robocza będzie podłączona do osobnego ups-a z czasem podtrzymania 15
min.
UPS został wyposaŜony w interfejs komunikacyjny RS 232 umoŜliwiający podłączenie
oprogramowania monitorującego.
2.9
Zdalny dostęp w celu prowadzenia prac konserwacyjnych
Wybrani technicy i administratorzy mogą dostać się do systemu za pośrednictwem linii
telefonicznej ISDN. Dostęp jest realizowany za pomocą narzędzia zdalnego dostępu
(Remote Access Tool) PCAnywhere. UŜytkownik przy łączeniu się z systemem przechodzi
przez trzystopniowe zabezpieczenia. Pierwsze realizuje sam Remote Access Tool. MoŜna
tu zastosować mechanizmy odpytywania, uwaŜane powszechnie za nie do obejścia. Po
skutecznym zalogowaniu się między obydwoma narzędziami zdalnego dostępu (jedno na
serwerze systemu SITRAFFIC SCALA/CONCERT Server, drugie na komputerze
dzwoniącego klienta) musi nastąpić zalogowanie się na serwerze aplikacji, czyli na
poziomie systemu operacyjnego. RównieŜ tutaj są zastosowane mechanizmy, które
według Microsoftu są absolutnie bezpieczne. Po skutecznym zalogowaniu się, takŜe tutaj
naleŜy wprowadzić identyfikator uŜytkownika na poziomie aplikacji. Dopiero po
bezbłędnym wykonaniu tych kroków dzwoniący otrzymuje dostęp do serwera i
zainstalowanego na nim oprogramowania.
W celu dalszego zwiększenia bezpieczeństwa systemu moŜna określić liczbę połączeń
telefonicznych, połączenie zwrotne i/lub blokadę uŜytkownika w ramach narzędzi zdalnego
dostępu.
2.10 Nadzór nad systemem
System jest wyposaŜony w programowe narzędzie nadzoru centrali. Jądro sterowania
centrali wysyła cyklicznie telegram OK. JeŜeli w określonym czasie (maks. 5 s) telegram
nie zostanie wysłany, nastąpi automatyczne odłączenie urządzeń komunikacyjnych od
serwerów i wszystkie urządzenia sterujące przejdą na pracę lokalną.
Zaniki napięcia sieci są monitorowane przez zasilanie awaryjne (UPS), które przy
dłuŜszych zanikach inicjuje zdefiniowane zamknięcie systemu. Po powrocie napięcia
system uruchomi się samodzielnie. Wymagane będzie wtedy ponowne zalogowanie się
uŜytkowników w stacjach roboczych.
Wersja 4.0
36/192
2.11 Koncepcja obsługi
Rysunek 2.7: Przykładowy interfejs uŜytkownika zastosowany w Centrum Zarządzania w
Berlinie
Interfejs uŜytkownika słuŜy do prezentacji i określania pozycji obiektów na mapie cyfrowej.
Stwarza ona komfortowe moŜliwości nawigacji w ramach mapy. Wszystkie dostępne dane
są stosownie do kategorii umieszczone w postaci drzewa nawigacyjnego z lewej strony
ekranu. Okno jest podzielone na trzy obszary. Lewy to wspomniane drzewo, prawy to
mapa z paskiem symboli umoŜliwiających jej opracowywanie. Przez bezpośredni wybór
obiektów w GIS moŜna zmieniać interaktywnie widoki i rodzaj obsługi. (p. rozdział 8.2
Obsługa systemu na podstawie mapy). PoniŜej tych dwóch obszarów wyświetlane są
zdarzenia robocze w archiwum zdarzeń - p. teŜ rozdział 3.1.4.
Pasek stanu pokazuje informacje o aktualnym statusie roboczym.
Oprogramowanie oferuje pomoc online w języku danego kraju opartą na odpowiednim
podręczniku oprogramowania. Ponadto zawiera ono podręcznik uŜytkownika w postaci
pliku pdf. Pomocą w wyszukiwaniu jest drzewo rozdziałów z odniesieniami tematycznymi.
Dodatkowo do dyspozycji jest wyszukiwarka tekstów.
Program obsługi oferuje przyjazną uŜytkownikowi platformę Windows, pozwalającą mu na
łatwe i szybkie wykonywanie zadań. Aplikacje na stacjach roboczych są ładowane
automatycznie przez serwer, o ile instalacja lokalna nie jest wymagana.
Interfejs uŜytkownika zgodnie z polskimi przepisami będzie w języku polskim.
Na rysunku 2.7 pokazano przykładowy widok interfejsu z innej wersji językowej.
Wersja 4.0
37/192
2.12. Zarządzanie uŜytkownikami
Zarządzanie uŜytkownikami zapewnia, Ŝe dostęp do aplikacji otrzymują jedynie osoby
uprawnione. Skojarzona z nim administracja praw dostępu gwarantuje, Ŝe
zindentyfikowany uŜytkownik będzie mógł wykonywać tylko przyporządkowane mu
czynności (autoryzacja).
Zgłoszenie pracownika odbywa się na stacji klienta. Ponowne zgłoszenie na innej stacji
klienta spowoduje ponowny start. Ustawienia pulpitu są specyficzne dla poszczególnych
klientów. Ustawienia pracowników są administrowane dla wszystkich klientów centralnie
na serwerze.
Wszyscy uŜytkownicy systemu są podzieleni na grupy. Jeden uŜytkownik moŜe naleŜeć do
róŜnych grup. UŜytkownik o odpowiednich uprawnieniach moŜe dowolnie dodawać i
zmieniać uŜytkowników i grupy uŜytkowników.
Grupom uŜytkowników moŜna przyporządkowywać uprawnienia na płaszczyźnie
funkcjonalnej i/lub na płaszczyźnie obiektów/urządzeń. MoŜna przy tym róŜne funkcje
grupować w tzw. grupy funkcyjne, a obiekty w grupy obiektowe.
Do obsługi systemu utworzono wymaganych uŜytkowników i grupy uŜytkowników z
wymaganymi uprawnieniami. Dostępne funkcje i obiekty, dla których moŜna przydzielać
uprawnienia, są zaleŜne od poszczególnych aplikacji. Menu i przyciski są na stałe
przyporządkowane
określonym
funkcjom.
Grupom
uŜytkowników
moŜna
przyporządkowywać charakterystyczne funkcjonalności przez grupowanie pojedynczych
funkcji.
Grupami uŜytkowników moŜna dowolnie zarządzać. MoŜna na przykład utworzyć
następujące grupy:
-
administrator
serwis
kierownictwo działów i zarządzanie projektami
zespół „Zarządzanie ruchem“
zespół „Budowa i eksploatacja“
zespół „Projektowanie inŜynierii ruchu“
Czasy pracy uŜytkowników są zapisywane w archiwum.
Zarządzanie uŜytkownikami, grupami uŜytkowników i uprawnieniami odbywa się na
poziomie systemu operacyjnego oraz na poziomie aplikacji.
2.13. Ustawianie daty i godziny, synchronizacja.
Jako precyzyjny zegar synchronizujący czas zastosowany zostanie odbiornik GPS,
podłączony do serwera aplikacji.
Za pośrednictwem protokołu NTP dokładny czas jest automatycznie udostępniany
wszystkim innym komputerom w sieci systemu zarządzania ruchem drogowym, co
umoŜliwia ich synchronizację.
Serwer aplikacji jest więc serwerem udostępniającym aktualny czas wszystkim innym
komputerom, tzn. serwerom, stacjom roboczym, OCIT-IG itp.
Podłączone komputery są z kolei klientami usługi udostępniania czasu i cyklicznie
sprawdzają czas.
Wersja 4.0
38/192
OCIT-IG to z kolei serwer usługi udostępniania aktualnego czasu dla podłączonych
sterowników, które równieŜ cyklicznie (zazwyczaj co 10 minut) sprawdzają czas. Do tego
celu stosowany jest protokół NTP (ntpdate).
Dla sterowników spełniających wymagania protokołu OCIT oferowane są zgodnie z OCIT
Outstation, OCIT-O-Lstg_V1.1 następujące procedury odliczania:
2
01.01. aktualny rok bez przełączania MESZ (standard)
3
01.01.1980 z przełączaniem MESZ
4
0:00 (godz.) aktualny dzień bez przełączania MESZ
2.14. Poziomy zabezpieczeń
System charakteryzuje się wielostopniową strategią zabezpieczeń przed skutkami awarii:
W przypadku awarii komputera na stanowisku pracy (stacja robocza) pozostała
część systemu (sterowanie, obsługa, archiwizacja itd.) działa bez ograniczeń.
MoŜliwość obsługi zapewnia serwer.
W przypadku awarii serwerów, sterowanie systemowe (sterowanie zaleŜne od
ruchu, sterowanie zaleŜne od czasu) działa w dalszym ciągu bez ograniczeń.
Awaryjny sposób obsługi (ograniczona funkcjonalność) umoŜliwia komputer
obszarowy. Komunikaty i wartości pomiarów zapisywane są tymczasowo na
poziomie sterowania online i po usunięciu problemu przekazywane do serwera.
W przypadku awarii systemu sterowania uzaleŜnionego od natęŜenia ruchu, działa
nadal
system
sterowania
uzaleŜnionego
od
czasu.
Awaryjny sposób obsługi (ograniczona funkcjonalność) umoŜliwia komputer
obszarowy.
W przypadku awarii komputera obszarowego, sterownik sygnalizacji w „tryb
lokalny” oparty o wzorzec czasu DCF. Z reguły jest to tryb adaptacyjny/uzaleŜniony
od natęŜenia ruchu (mikrosterowanie).
W przypadku awarii centralnego systemu sterowania, zadanie koordynowania
grupy sterowników moŜe przejąć kaŜdorazowo jeden ze sterowników. Funkcja ta
wymaga odrębnego okablowania pomiędzy sterownikami danej grupy.
2.15 Awaria składników
W przypadku zakłócenia wzgl. awarii jednego ze składników (np. podłączonej sygnalizacji
świetlnej zgodnej z OCIT lub komputera centralnego), obowiązuje następująca strategia
zabezpieczeń przed skutkami awarii:
Zakłócenie jakiegokolwiek rodzaju generuje zgodnie z ustalonymi zasadami OCIT
(poziom 1 OCIT, komunikaty podstawowe) jednoznaczny komunikat o błędzie.
Zakłócenie składnika poziomu lokalnego nie ma wpływu na pracę całego systemu.
Po usunięciu zakłócenia dany element zgłasza się ponownie zgodnie z ustalonymi
zasadami OCIT (poziom 1 OCIT, komunikaty podstawowe) i zapewnia dostęp do
całego zakresu swych funkcji.
W przypadku awarii serwera, tryb pracy awaryjnej zapewnia system sterowania
czasu rzeczywistego lub teŜ Intelligent Gateway:
Wersja 4.0
o
o
o
39/192
Sterowanie wg aktualnego automatycznego układu sterowania rocznego
(JAUT).
Awaryjny sposób obsługi systemu sterowania czasu rzeczywistego i
systemu Intelligent Gateway w celu włączania, wyłączania i przełączania
programów.
Buforowanie komunikatów o zakłóceniach i dotyczących trybu pracy aŜ do
momentu ponownego uruchomienia serwera. Czas buforowania dla ES/IG
wynosi maks. 300 dni (z moŜliwością skonfigurowania przez pracownika
serwisu – standardowe zasilanie przez 7 dni). Po pomyślnym ponownym
uruchomieniu komunikaty o zakłóceniach i dotyczące trybu pracy przesyłane
są do serwera sterowania ruchem i są tym samym dostępne do dalszego
przetworzenia.
2.15.1 Macierz dysków twardych (RAID 10)
W celu zwiększenia bezpieczeństwa działania systemu, serwer wyposaŜony jest w
macierz dysków twardych z lustrzanym odbiciem (RAID 10).
Kombinacja systemu lustrzanego odbicia (mirroring) oraz systemu striping zapewnia
połączenie wzrostu szybkości z bezpieczeństwem danych. System RAID 0+1 dzięki
linearnemu połączeniu wielu dysków osiąga większą prędkość zarówno podczas operacji
odczytu, jak równieŜ podczas zapisu. Dodatkowe lustrzane odbicie zestawu na wiele
dysków zapewnia bezpieczeństwo danych. W zaleŜności od producenta procedura ta
określana jest jako RAID 0+1, RAID 0/1 lub RAID 10. W przypadku tej metody wysoki
poziom bezpieczeństwa układu RAID Level 1 łączy się z prędkością układu RAID Level 0.
Sterowanie dyskami twardymi odbywa się w następujący sposób:
W celu utworzenia macierzy RAID 10 stosuje się zazwyczaj cztery napędy dysków
twardych. Najpierw dwa dyski łączone są w zestaw liniowy (RAID 0), a następnie lustrzane
odbicie ich dysków logicznych (RAID 1). W wyniku tego potem dostępne są zasoby dwóch
dysków twardych. Koncepcję układu Raid 1 przedstawiono na rysunku 2.8.
Rysunek 2.8: Koncepcja układu Raid 1
W przypadku awarii dysku twardego kontroler ten reaguje niezwłocznie i rekonstruuje
niezbędne dane z zasobów dysków znajdujących się nadal w uŜyciu. Dzięki temu jeden z
dysków serwera moŜe podczas pracy ulec całkowitej awarii, nie powodując w ten sposób
utraty danych.
Wersja 4.0
40/192
2.15.2 Lustrzane odbicie dysku twardego (RAID 5)
W celu zwiększenia dostępności systemu sterowania ruchem drogowym serwer danych
pierwotnych wyposaŜony jest w macierz dysków twardych z lustrzanym odbiciem (RAID 5).
W celu utworzenia macierzy RAID Level 5 niezbędne są trzy dyski twarde. Dane
zapisywane są równolegle na wszystkich dyskach twardych, wchodzących w skład
macierzy. Ponadto na wszystkich dyskach zapisywane są informacje o parzystości. Dzięki
temu awaria jednego z dysków macierzy nie pociąga za sobą utraty danych w macierzy.
Po usunięciu uszkodzonego i zainstalowaniu nowego dysku twardego, RAID moŜe
odtworzyć macierz bez utraty danych lub konieczności wgrywania kopii zapasowej.
Oznacza to najwyŜszy poziom bezpieczeństwa danych wskazanego tu poziomu RAID.
Zasoby pamięci uŜyte do zapisania informacji o parzystości nie są dostępne dla danych,
dlatego zasadę działania macierzy RAID 5 opisuje wzór: (pojemność wszystkich dysków
twardych) - (pojemność jednego dysku twardego) = wolne zasoby dla danych.
Wersja 4.0
3.
Organizacja danych i bezpieczeństwo danych
3.1.
Organizacja danych
41/192
Jako system bazy danych zastosowany zostanie najprawdopodobniej system Oracle 8i.
Oferent zastrzega sobie prawo wymiany tego systemu z powodów technicznych
(optymalizacja) na nowszą wersję Oracle wzgl. inny system przechowywania danych.
Generalne załoŜenie jest takie, iŜ system opiera się na zasadzie klient-serwer.
System wyposaŜony jest w centralny zbiór danych.
Dostęp do centralnego zbioru danych odbywa się za pośrednictwem interfejsów otwartych.
NajwaŜniejsze funkcje systemu, np. przechowywanie danych, skoncentrowane są w
centrali, przy czym w odniesieniu kaŜdego przypadku stosowane są zoptymalizowane
systemy przechowywania danych (np. centralny sposób przechowywania w bazach
danych lub plikach).
Udostępnianie danych róŜnym klientom odbywa się za pośrednictwem serwera.
Dostęp do danych w centrali odbywa się wyłącznie za pośrednictwem przeznaczonych do
tego celu interfejsów.
3.1.1. Przegląd
RozróŜnia się następujące istotne zasoby danych:
Bufor serwera danych pierwotnych [„archiwum sygnalizacji”]
o pracuje jako pamięć pierścieniowa z konfigurowalnym czasem zapisu (w
dniach),
o zawiera pierwotne wartości pomiarów, fazy sygnałów i dane procesowe
(wartości AP z mikrosterowania w sterownikach sygnalizacji świetlnej),
archiwum wartości pomiarowych [„archiwum wartości pomiarowych” wraz z
archiwum dla transportu zbiorowego],
o zawiera skonsolidowane wzgl. opracowane dane pomiarów oraz
komunikaty transportu zbiorowego i tryby pracy (status),
archiwum komunikatów [„archiwum online”],
o zawiera komunikaty dot. trybu pracy i zakłóceń,
o dane sterujące na podstawie projektów i stanu aktualnego.
W zaleŜności od rodzaju danych, przechowywanie ich w systemie realizowane jest w róŜny
sposób. RóŜnice powstają ze względu na ilości danych, jak teŜ z powodu róŜnych
wymagań co do dostępności, archiwizacji i zabezpieczeń.
RozróŜnia się następujące rodzaje danych:
centralne dane sterujące: dane uzaleŜnionego od czasu wyboru programu,
programy sygnalizacyjne sterowników (o ile są udostępnione przez procedurę
transmisji),
dane komunikatów: komunikaty dot. trybu pracy, zakłóceń, komunikaty specjalne,
dane pierwotne ze sterownika (wg OCIT są to dane detektorów, telegramy
transportu zbiorowego oraz dane sygnalizacyjne sterowników, jak teŜ tzw. wartości
AP jako dane procesu sterowania),
Wersja 4.0
42/192
dane dot. ruchu drogowego (opracowane pierwotne dane o ruchu drogowym).
Przechowywanie danych komunikatów realizowane jest przez jedną z centralnych baz
danych (ORACLE).
Przechowywanie centralnych danych sterujących oraz danych dot. ruchu drogowego wraz
ze stanami trybów pracy odbywa się w postaci plików.
Przechowywanie danych pierwotnych realizowane jest przez bazę danych, zawierającą
pliki.
3.1.2. Centralne dane sterujące
Dane sterujące składają się z informacji na temat konfiguracji i sterowania sterowników
sygnalizacji świetlnej oraz z parametrów centralnego systemu zarządzania ruchem
drogowym /systemu sterowania ruchem drogowym w Warszawie.
Są to następujące dane:
dane podstawowe centralnego systemu zarządzania ruchem drogowym / systemu
sterowania ruchem drogowym,
dane podstawowe sterowników sygnalizacji świetlnej.
3.1.3. Dane komunikatów
System SITRAFFIC SCALA/CONCERT zapisuje wszystkie komunikaty dot. trybu pracy i
stany pracy w archiwum komunikatów (BEMA). Program SITRAFFIC View udostępnia
interfejs uŜytkownika, umoŜliwiający opracowywanie archiwum komunikatów dot. trybu
pracy (patrz rozdz. 5.2 Analiza/wyszukiwanie w podręczniku obsługi SITRAFFIC View).
Komunikaty generowane są przez róŜne podsystemy. Podsystem moŜe składać się z
odrębnego, inteligentnego składnika, np. sterownika, lub teŜ z pojedynczych modułów
oprogramowania, np. automatycznego układu sterowania rocznego.
Jako wejście komunikatów dla systemów zewnętrznych dostępne jest złącze SOAP/XML.
Komunikaty dot. trybu pracy mogą być przekazywane zgodnie z regułami filtrowania przez
System Alarm Management za pośrednictwem faksu, wiadomości SMS lub e-mail.
Przegląd najwaŜniejszych typów komunikatów zawiera Tabela 3.1: Typy komunikatów
Typ komunikatu
OCIT
Komunikaty dot. trybu pracy i zakłóceń z
urządzeń lokalnych
Komunikaty statusu pracy urządzeń lokalnych
Komunikaty dot. trybu pracy i zakłóceń ze
składników SITRAFFIC SCALA/CONCERT,
serwera aplikacji, systemów czasu
rzeczywistego (np. IG/ES)
Komunikaty dot. trybu pracy z managera
danych SITRAFIC Supply
Komunikaty programu SITRAFFIC View
Wpisy uŜytkownika „komunikat ręczny”
Komunikaty o zakłóceniach dróg transmisji wg
X
Centrala
X
X
X
X
X
X
X
Wersja 4.0
OCIT
Automatyka roczna na poziomie centralnym
(JAUT)
Automatyka roczna na poziomie lokalnym
(JAUT)
Automatyka tygodniowa przełączania
programów (WAUT)
Komunikaty ostrzegawcze archiwum
komunikatów o trybach pracy (BEMA), np.
ostrzeŜenia o poziomie zapełnienia
Komunikaty dot. trybu pracy i zakłóceń z
systemu pomiarowego
43/192
X
X
X
X
Tabela 3.1: Typy komunikatów
Wszystkie komunikaty składają się z wielu elementów i mają taką samą strukturę.
Elementy komunikatów uzupełniane są częściowo automatycznie przez system.
Komunikaty urządzeń OCIT, dotyczące trybu pracy, rozszerzane są o „kategorię
komunikatu” i „poziom komunikatu”.
Kategoria i poziom komunikatu opatrzone są wartościami domyślnymi (zgodnie z definicją
OCIT).
W przypadku komunikatów utworzonych ręcznie (komunikatów tekstowych), zarówno
odnośne numery (z reguły numery skrzyŜowań), jak teŜ czas (czas oryginalny) mogą być
wybierane przez uŜytkownika wzgl. uzupełniane.
Wprowadzone ręcznie komunikaty statusu, które są przewidziane dla celów wizualizacji,
niepodłączonych (pracujących offline) urządzeń lokalnych, zawierają komunikaty
podstawowe, przewidziane przez protokół OCIT.
Komunikaty, które trafiają do systemu za pośrednictwem wejścia komunikatów dla
systemów zewnętrznych (interfejs SOAP/XML), np. SITRAFIC Q2, mają równieŜ taką
samą strukturę, jak wszystkie inne komunikaty, lecz bez „kategorii komunikatu” i „poziomu
komunikatu”.
Komunikaty generowane są przez:
podłączone sterowniki sygnalizacji świetlnej (urządzenia lokalne OCIT),
uŜytkownika (ręczny wpis komunikatu),
system sterowania ruchem drogowym,
opracowania w obszarze QA/QM.
Komunikaty przekazywane są w obrębie systemu do:
procesów interfejsu uŜytkownika (w celu wyświetlenia komunikatów online),
systemu System Alarm Management (w celu powiadomienia o zakłóceniu za
pomocą wiadomości SMS, e-mail i/lub faksu),
archiwum (BEMA) w celu zapisania komunikatów wraz z informacjami
dodatkowymi (potwierdzenie, komentarze, przeszukiwanie archiwum itp.).
Wersja 4.0
44/192
Elementy komunikatu opisano na przykładzie w tabeli 3.2:
Element
komunikatu
Opis
ID
Unikalny numer identyfikacyjny
Tworzony jest przez SITRAFFIC SCALA/CONCERT i słuŜy do
jednoznacznego określania komunikatów.
Czas zapisania
Data i godzina zapisania w bazie danych
Zazwyczaj jest to czas minimalnie późniejszy niŜ czas oryginalny.
Proces ten wykonywany jest zwykle przez system SITRAFFIC
SCALA/CONCERT.
Czas oryginalny
Data i czas wystąpienia w danym miejscu, np. w sterowniku,
KOMPUTERZE STERUJĄCYM RUCHEM.
Potwierdzenie
Pole wskazuje symbolicznie stan potwierdzenia
(potwierdzony/niepotwierdzony).
Identyfikator
tekstowy (Text-Id)
Identyfikacja typu komunikatu
Źródło
Dodatkowe informacje o przyczynie powstania w przypadku
komunikatów OCIT nr 14.536 do 14.540, np. JAUT, USER
Numer procesu
Jednoznaczny numer procesu dla kaŜdej czynności, który pozostaje
niezmieniony takŜe w przypadku późniejszych komunikatów
zwrotnych z wielu punktów. Dzięki temu moŜna w celu
wyszukiwania filtrować i wyświetlać powiązane ze sobą procesy.
Nr Sr
Numer komputera sterowania ruchem.
Punkt węzłowy
Zewnętrzny numer węzła z komunikatu
Program
sygnalizacyjny
Numer programu sygnalizacyjnego z komunikatu
Detektor
Zewnętrzny numer detektora z komunikatu
Grupa
sygnalizacyjna
Numer grupy sygnalizacyjnej z komunikatu
Parametry (x)
Parametry komunikatu, o ile są dostępne
Opis tekstowy
Opis tekstowy z komunikatu
Tekst Sr
Tekst komputera sterowania ruchem z komunikatu
tekst komunikatu.
Informacja tekstowa na temat komunikatu, jaka pojawia się np. na
wydruku protokołu.
Ta informacja zbiorcza tworzona jest z wielu obiektów wtórnych, np.
„skrzyŜowań”, „program sygnalizacyjny”, „Tx” itp., jak równieŜ
wewnętrzne obiekty, jak np. „Text-ID” lub teŜ „StringPar” z
programu SITRAFFIC VIEW.
Komentarze
W tej kolumnie uŜytkownik moŜe wpisać jedną lub wiele dowolnych
uwag dotyczących komunikatu. Symbol koperty wskazuje, Ŝe
istnieje jeden lub kilka komentarzy.
Potwierdzony przez
Nazwa uŜytkownika, który potwierdził komunikat
Potwierdzony dnia
Data potwierdzenia komunikatu
Tabela 3.2: Elementy komunikatu
3.1.4. Archiwum komunikatów roboczych
W archiwum komunikatów roboczych zapisywane są komunikaty robocze i usterkowe z
sygnaturą czasu, komentarzem i statusem. Poza tym operator ma moŜliwość dopisywania
komentarzy do komunikatów i ich przeszukiwania wg kryteriów historycznych. WaŜniejsze
komunikaty, na które operator musi zareagować, wymagają potwierdzenia. NiezaleŜnie od
Wersja 4.0
45/192
automatycznej rejestracji komunikatów istnieje moŜliwość ich ręcznego wprowadzania i
zapisywania w archiwum komunikatów roboczych. Za przykład mogą tu posłuŜyć
komunikaty nie odbierane bezpośrednio przez system, ale otrzymywane chociaŜby drogą
telefoniczną (informacje takie jak przekręcony maszt anteny biczowej albo uszkodzenie
soczewki rozpraszającej sygnalizatora). Ręcznie wprowadzane komunikaty są traktowane
tak samo jak generowane automatycznie.
W archiwum komunikatów roboczych zapisywane są ingerencje operatora z podaniem
identyfikatora zalogowanego uŜytkownika i ewentualnie związaną ze sterowaniem
przyczyną wykonywanych przez operatora czynności, waŜne zdarzenia systemowe i
komunikaty błędów.
Ingerencje operatora:
•
ręczne przełączanie urządzenia lokalnego (np. urządzenia sygnalizacji świetlnej,
tablicy informacyjnej)
•
wprowadzanie nowych komunikatów dot. ruchu drogowego,
•
i inne
Zdarzenia systemowe:
•
komunikaty zwrotne o zdarzeniach łączeniowych
•
komunikaty zwrotne urządzeń lokalnych o zmianie statusu
•
start serwera
•
start planu działania
•
wysyłka informacji do mediów,
•
i inne
Komunikaty błędów:
•
usterka urządzenia lokalnego
•
błąd przy wysyłce informacji do mediów
•
awaria komunikacji z jednym z podsystemów,
•
i inne
3.1.4.1. Atrybuty komunikatu roboczego
Zarchiwizowane komunikaty robocze i usterkowe zawierają następujące atrybuty:
• czas oryginalny: sygnatura czasu wygenerowania komunikatu
• czas zapisu: sygnatura czasu zapisu w archiwum komunikatów roboczych,
• obiekt,
• podsystem,
• tekst komunikatu.
• identyfikator komunikatu,
• status/czas potwierdzenia,
• poziom komunikatu zgodnie z OCIT: opisuje poziom waŜności komunikatu,
o informacja
bez wpływu na ruch drogowy,
o ostrzeŜenie
nie ma wpływu na ruch drogowy, ale musi
nastąpić reakcja,
Wersja 4.0
•
•
•
46/192
o błąd
nie ma istotnego wpływu na ruch drogowy,
o powaŜny błąd
ma istotny wpływ na ruch drogowy,
kategoria komunikatu zgodnie z OCIT: opisuje element systemu wzgl. nadawcę
komunikatu. Zdefiniowano następujące kategorie:
o inne
nie da się przypisać Ŝadnej z poniŜszych
kategorii,
o urządzenia HW
ogólnie komponenty sprzętowe,
o błąd obrazu Ŝądanego
np. zabezpieczenie sygnalizacji przed
sygnałami kolizyjnymi,
o błąd obrazu rzeczywist.
np. Ŝarówki w sygnalizatorach,
o VA
komunikaty techniczno-ruchowe w programie
uŜytkownika,
o system transmisji
komunikacja z centralą,
o system op., oprogr. sprzęt. błędy systemowe i inne,
o programy uŜytkownika
progr. uŜytkownika nie związane z techniką
sterowania ruchem,
o zasilanie
komunikaty związane z zasilaniem,
o zegar
komunikaty związane z błędem czasu,
o detektory
komunikaty związane z detektorami,
o stan roboczy
komunikaty o stanach roboczych,
Kategoria komunikatu nie jest elementem składowym samego komunikatu
(atrybutu), tylko jest uzupełniana w centrali i wtedy staje się widoczna dla
uŜytkownika.
numer procesu: odwołanie komunikatów dodatkowych OCIT do odpowiedniego
komunikatu podstawowego OCIT. Komunikaty dodatkowe związane z danym
komunikatem głównym moŜna odczytywać w oknie szczegółów komunikatu
podstawowego.
komentarz.
3.1.4.2. Sposób działania archiwum komunikatów dot. trybu pracy
Oprócz komunikatów roboczych z systemu i odpowiednich urządzeń lokalnych oraz
podzespołów moŜna równieŜ rejestrować komunikaty robocze z podłączonych
podsystemów i zapisywać je w archiwum.
Archiwum komunikatów dot. trybu pracy ma postać relacyjnej bazy danych. Struktura bazy
danych zaprojektowana została pod kątem optymalizacji czasu zapisywania i
opracowywania danych. Z tego względu zastosowano bazę danych Oracle. Archiwizacja
komunikatów dot. trybu pracy oraz zakłóceń odbywa się automatycznie bez udziału
uŜytkownika. Okres przechowywania komunikatów w archiwum uzaleŜniony jest od ilości
komunikatów oraz od dostępnych na serwerze zasobów pamięci. W przypadku średniej
wielkości systemu, obejmującego ok. 500 sterowników sygnalizacji świetlnej, komunikaty w
archiwum moŜna przechowywać przez okres 5 lat. Komunikaty, wykraczające poza
ustalony przedział czasu, przenoszone są automatycznie do systemu plików, dzięki czemu
moŜna zapewnić długookresową archiwizację na nośniku zewnętrznym. Wyeksportowane
komunikaty moŜna wprowadzić ponownie do bazy danych np. w celu ich wyszukiwania.
Opcjonalnie istnieje moŜliwość przekazywania komunikatów dot. trybu pracy i zakłóceń za
pośrednictwem interfejsu otwartego do dalszych podsystemów, jak np. System Alarm
Management, w celu automatycznego powiadamiania pracowników serwisu technicznego.
Wersja 4.0
47/192
3.1.4.3. Okno komunikatów online
Okno komunikatów online stanowi składnik struktury podstawowej interfejsu uŜytkownika.
Podgląd ten moŜe być wyświetlany stale jako odrębny element interfejsu uŜytkownika.
UŜytkownik moŜe dowolnie dostosowywać rozmiar okna przy uŜyciu myszy. W przypadku
terminala obsługi z wieloma monitorami istnieje opcjonalnie moŜliwość przypisania okna
komunikatów do odrębnego monitora.
Nadchodzące komunikaty dot. trybu pracy wyświetlane są na bieŜąco w formie tabeli.
Tabela zapewnia te same, komfortowe funkcje formatowania i sortowania, jakie dostępne
są w widokach list. Dzięki temu dane waŜne dla pracownika obsługi zawsze prezentowane
są optymalnie w polu widzenia.
RóŜne filtry umoŜliwiają ograniczenie widoku w oknie komunikatów online. Filtry te
skonfigurowane są wstępnie w momencie dostarczenia systemu i podczas uruchamiania
moŜna je dostosować do wymagań uŜytkownika.
Cały komunikat zajmuje jeden wiersz tabeli, zaś jego poszczególne elementy tworzą
kolumny. Pracownicy obsługi technicznej mogą dostosować wybór wyświetlanych
elementów do specyficznych wymagań uŜytkownika w zaleŜności od konfiguracji, pod
kątem klienta lub serwisu. Wydruk wykonywany jest wyłącznie w kolejności rosnącej wg
czasu oryginalnego.
3.1.4.4. Wyszukiwanie i archiwizacja w archiwum komunikatów dot. trybu pracy
W celu znalezienia starych komunikatów dot. trybu pracy system zapewnia funkcje
wyszukiwania. MoŜna je zastosować do komunikatów zapisanych w archiwum. Ponadto
moŜliwe jest równieŜ zdefiniowanie i uŜywanie filtrów uŜytkownika.
Rysunek 3.3: Wyszukiwanie w archiwum komunikatów dot. trybu pracy
Objaśnienia do rysunku przedstawiono na następnej stronie.
Wersja 4.0
48/192
Objaśnienia do rysunku 3.3:
Tekst:
- zakłócenie komunikacji na Sc....
- zmiana statutu tablicy DMS22...
Jako kryterium filtrowania moŜna przyjąć:
• czas od do,
• obiekt,
• podsystem,
• uŜytkownika,
• tekst komunikatu.
Dla kryteriów filtrowania dostępna jest ponadto funkcja Wildcard. MoŜna równieŜ
ograniczać liczbę trafień. Wynik wyszukiwania wyświetlany jest w postaci tabeli i moŜna go
poddać dodatkowej edycji z zastosowaniem dalszych funkcji tabeli i filtrów.
Wyniki wyszukiwania moŜna wydrukować lub teŜ zapisać w formacie *.xml albo *.pdf.
3.1.5. Wartości pomiarów (dane dot. ruchu drogowego)
Wywoływanie wartości pomiarów odbywa się w sposób zorientowany obiektowo, tzn.
najpierw następuje wybór obiektów z posortowanej listy wartości pomiarowych np. wg
pomiarów ruchu w przekroju poprzecznym, następnie zaś wyświetlane są z tego zakresu
wyboru aktualne lub zapisane wartości pomiarowe.
Selekcja
obiekt
+ wywołanie
szczegółów
udostępnia
widok online
wartości
pomiaru
+ wywołanie
linii wahań
natęŜenia
ruchu
udostępnia
widok
aktualnych
wartości
Rysunek 3.4: Przykład widoku aktualnych wartości pomiarów
Wersja 4.0
49/192
Przykład z rysunku 3.4 przedstawia widok aktualnych wartości pomiarów (porównanie
pomiędzy zapisaną linią wahań natęŜenia ruchu (linia niebieska) oraz aktualnymi
wartościami pomiaru z danego dnia (linia czerwona)).
Sytuację tę poprzedzają następujące czynności uŜytkownika:
wybór pomiaru ruchu w przekroju poprzecznym (wart. pomiaru) z widoku listy,
wyświetlenie widoku szczegółowego dla tego pomiaru ruchu w przekroju
poprzecznym (wart. pomiaru),
wyświetlenie krzywej wartości pomiarów dla tej wartości pomiarowej w widoku
szczegółowym.
3.1.5.1. Archiwum wartości pomiarów
Zapisywanie skonsolidowanych wartości pomiarów wykonywane jest w postaci plików.
Tworzona jest przy tym struktura wg lat, miesięcy, dni i typów wartości pomiarów, w
obrębie której zapisywane są następnie pliki dzienne poszczególnych instancji wartości
pomiarowych. Zapis wykonywany jest w łatwym do odczytania formacie XML.
3.1.5.2. Wyszukiwanie w archiwum
Przykład z rysunku 3.5 pokazuje, w jaki sposób z poziomu tego widoku moŜna wyświetlić
archiwalne wartości.
Wybór za pomocą zakładki „Data”.
Wyświetlenie krzywej wartości pomiarów za pomocą polecenia „Aktualizuj”.
...
Za pomocą
zakładki Data
moŜna
ustawić
przedział
czasu
wyszukiwania
+ wywołanie
Aktualizuj
udostępnia
widok
Ŝądanych
wartości
Rysunek 3.5: Przykład wywołania zapisanych wartości pomiarów
Wersja 4.0
50/192
3.1.5.3. Opracowywanie wartości pomiarów
Interfejs uŜytkownika umoŜliwia wyświetlanie wykresów dla róŜnych typów danych wartości
pomiarów ruchu i wartości pomiarów z obiektów parkingowych. Przy czym wartość
pomiaru dziennego moŜna w razie potrzeby wyświetlić wraz z linią wahań natęŜenia ruchu.
MoŜliwe jest przy tym wyświetlenie określonego dnia wzgl. wielu wybranych dni oraz ich
ew. umieszczenie jednego nad drugim. Skalowanie osi X/Y odbywa się automatycznie,
jednakŜe w razie potrzeby moŜna je zdefiniować ręcznie. Przykładowe widok okna
opracowania wartości pomiarów przedstawiono na rysunku 3.6.
Rysunek 3.6: Przykład opracowania wartości pomiarów
Objaśnienia do rysunku:
Tagesmesswerte – wartości pomiaru dziennego
Zaehlung Kfz – pomiar ruchu
Messwerte – wartości pomiaru
Datum - data
Skalierung - skalowanie
Ganglinie anzeigen – wyświetlenie krzywej wahań natęŜenia ruchu
Tagesmesswerte anzeigen – wyświetlenie wartości pomiaru dziennego
3.1.6. Dane źródłowe
Serwer danych źródłowych (patrz opis w rozdziale 2.6.2.) obejmuje zarówno wymagane
usługi i funkcje danych, jak teŜ zasoby danych w bazie danych źródłowych.
Dane dostępne na serwerze danych źródłowych dzielą się na (wg OCIT):
wartości pomiarów, dzielące się na:
o źródłowe wartości pomiarów (zbocza i zadziałania detektorów) o
rozdzielczości rzędu 10 ms,
o stany grup sygnalizacyjnych,
o telegramy Ŝądań dla transportu publicznego (R09 wzgl. AMLI),
wartości AP (Anwender Programmvariablen – zmienne programowe uŜytkownika).
Wersja 4.0
51/192
Zasadniczo gromadzenie wszystkich tych danych ma charakter zadaniowy.
Oznacza to, Ŝe opracowywanie i zapisywanie wykonywane jest tylko po uaktywnieniu
odpowiedniego zadania, jakie otrzymuje dany punkt pomiarowy (np. grupa sygnalizacyjna).
Zadanie (zapisane w dynamicznym procesie zbierania danych) odzwierciedla połączenie
róŜnych wartości pomiarów oraz wartości AP, np. zgromadzenie danych statusu „grupy
sygnalizacyjnej 3”.
Zdefiniować moŜna tylko zadania z punktami pomiarowymi urządzeń lokalnych,
podłączonych za pośrednictwem protokołu OCIT.
Aby zaplanować opracowanie danych, zadania te są definiowane w zaleŜności od czasu
(data/godzina do data/godzina).
Do definiowania zadań słuŜy odpowiedni interfejs uŜytkownika.
Dostęp do danych w bazie danych źródłowych realizowany jest równieŜ za pomocą
interfejsu SOAP/XML. Gromadzenie danych w bazie danych źródłowych odbywa się w
pierwszym rzędzie wg urządzeń lokalnych, kanału danych i czasu.
Zasadniczo wszystkie dane zapisywane są w bazie danych pierwotnych za pośrednictwem
odwołań zewnętrznych bez informacji o zadaniach (zleceniach). Przy opcjonalnym
zabezpieczeniu umoŜliwia to dostęp do starych zasobów danych nawet podczas
przebudowy systemu. Oznacza to, Ŝe właściwe dane moŜna opracowywać takŜe bez
odwołania do zadań archiwizacji.
Do zadań systemu sterowania na poziomie lokalnym naleŜy:
Gromadzenie danych źródłowych
Komunikacja z urządzeniami lokalnymi. Normalizacja protokołów urządzeń
lokalnych.
Zarządzanie zadaniami
Realizuje zadania dot. danych, uzaleŜnione od czasu, w celu dokonania późniejszej
oceny. Tu definiowane są z reguły wszystkie dane, przeznaczone do archiwizacji. W
pierwszym etapie scalane są w zadania. W drugim dla tych zadań definiowane są
warunki czasowe. Mogą to być bezwzględne czasy rozpoczęcia i zakończenia
archiwizacji lub teŜ stałe gromadzenie danych.
Usługi zapisu i odczytu archiwum:
Sam interfejs bazy danych źródłowych.
zbieranie danych do zarządzania zadaniami:
Interfejs uŜytkownika. Tu dostarczane są dane do punktów danych, przeznaczonych
do archiwizacji.
Serwer SOAP:
Konwertuje dane na format XML i udostępnia interfejs SOAP.
Następujące funkcje realizowane są w obrębie komponentów serwera danych źródłowych:
Dane Ŝródłowe online do SITRAFFIC QM/Q2 (QA-Tool)
Dane źródłowe online wysyłane są bezpośrednio do SITRAFFIC Q2.
Dane wywołane online nie wymagają z reguły archiwizacji.
Jeśli jednak archiwizacja jest konieczna, jest ona zlecana osobno.
Dane źródłowe online do późniejszego przetworzenia
Archiwum danych źródłowych zaprojektowano jako pamięć na maks. 30 dni.
Za pośrednictwem interfejsu SOAP/XML dane źródłowe online przekazywane są do
narzędzia QA SITRAFFIC Q2 (Client).
Wersja 4.0
3.2.
52/192
Zabezpieczanie danych
3.2.1. Kopia zapasowa, ponowne uruchamianie
Pojęcie
Definicja
Zastosowanie
Backup (kopia
zapasowa)
Uwagi
Zabezpieczenie zasobów
danych na nośniku
zapasowym.
Mogą to być np.:
o
kopie bezpieczeństwa
systemów róŜnych
komputerów (images),
Ręczne
Poprzez tworzenie obrazu
(Symantec Ghost);
cyklicznie lub po większych
zmianach w systemie
o
o
Restore
(przywracanie)
kopie bezpieczeństwa
danych, tzn.
zabezpieczenie danych
uŜytkowych ze
ścieŜek/plików
zdefiniowanych dysków
Automatyczne
Przy uŜyciu Veritas Backup
Exec;
cyklicznie, np. co miesiąc
kopia bezpieczeństwa
danych z bazy danych
Odtwarzanie konfiguracji po
awarii do stanu ostatniej
kopii zapasowej
Ręczne
W razie potrzeby dwustopniowo:
ponowne skopiowanie zasobów
danych do systemu plików
(Symantec Ghost,

ponowne skopiowanie do
aplikacji (np. bazy Oracle)
Archiwizacja
Archiwizacja
Automatyczne
krótkoterminowa:
przeznaczone do
archiwizacji dane
(komunikaty dot. trybu pracy
i zakłóceń, skonsolidowane
wartości pomiarów z
urządzeń sygn. świetln.
OCIT) zapisywane są w
pierwszym etapie w
archiwum online na serwerze
Komunikaty dot. trybu pracy i
zakłóceń zapisywane są w bazie
danych Oracle.
Archiwizacja
długoterminowa:
ze względów optymalizacji
dostępu i zasobów pamięci,
dane online przenoszone są
cyklicznie i zapisywane na
nośnikach zapasowych
Plany zabezpieczania danych
(cykle ustalane są przez
administratora systemu;
zazwyczaj: comiesięczna kopia)
Automatyczne
Skonsolidowane wartości
pomiarów zapisywane są w
postaci plików.
Wersja 4.0
Wczytywanie

Wczytywanie skopiowanych
danych z nośnika
zapasowego do archiwum
online serwera
53/192
Ręczne
W przypadku wyszukiwania
komunikatów dot. trybu pracy i
zdarzenia poza obrębem
obszaru online uŜytkownik
otrzymuje wskazówkę
Ręczne
Dla skonsolidowanych wartości
pomiarów. W przypadku
wyszukiwania poza obrębem
obszaru online uŜytkownik
otrzymuje wskazówkę
Tabela 3.7: Tabela definicji pojęć archiwizacji, kopii zapasowej
3.2.1.1. Archiwizacja i wczytywanie
Pod pojęciem archiwizacji rozumiane jest krótkoterminowe lub długoterminowe
przechowywanie wybranych danych w archiwach:
komunikaty dot. trybu pracy i zdarzeń,
dane pomiarowe z sterowników sygnalizacji świetlnej OCIT (dane skonsolidowane).
W przypadku tych archiwów dostępne są dwa programy do opracowywania.
Zapisywanie danych źródłowych sterowników sygnalizacji świetlnej OCIT odbywa się na
odrębnym serwerze danych źródłowa (pamięć pierścieniowa 30 dni), który stanowi
składnik partii 1 i który poprzedza archiwizację.
Archiwizacja wykonywana jest przy tym w dwóch etapach:
Archiwizacja krótkoterminowa:
Dane przeznaczone do archiwizacji zapisywane są w pierwszym etapie w archiwum
online.
Archiwizacja długoterminowa:
Ze względów optymalizacji dostępu i zasobów pamięci, dane online przenoszone
są cyklicznie i zapisywane na nośnikach zapasowych
Archiwizacja krótkoterminowa komunikatów dot. trybu pracy oraz zdarzeń odbywa się
automatycznie, bez udziału uŜytkownika. UŜytkownik moŜe ze swej strony zdefiniować
filtry wpływające na zapisywanie komunikatów.
Archiwizacja krótkoterminowa komunikatów dot. trybu pracy oraz zdarzeń odbywa się przy
uŜyciu bazy danych Oracle.
Archiwizacja krótkoterminowa skonsolidowanych wartości pomiarów odbywa się
automatycznie, bez udziału uŜytkownika. Podczas konfiguracji komputera naleŜy ustalić,
jakie wartości pomiarów mają być archiwizowane.
W celu długoterminowej archiwizacji skonsolidowanych wartości pomiarów oraz
komunikatów dot. trybu pracy i zakłóceń, w systemie aktywowane są zapisane plany
archiwizacji danych. W planach tych uŜytkownik moŜe ustalić cykle, w jakich następować
ma przeniesienie plików archiwum z archiwum online serwera na nośnik zapasowy. Zapis
Wersja 4.0
54/192
na nośniku zapasowym wykonywany jest w formie pliku skompresowanego. Na rysunku
3.8 pokazano przykładowy widok interfejsu uŜytkownika dla definiowania planów
archiwizacji danych.
Rysunek 3.8: Przykład interfejsu uŜytkownika umoŜliwiającego zdefiniowanie planów
archiwizacji danych
Neues Ereignis – nowe zdarzenie
Neue Verknupfung – nowe połączenie
Datum – data
Uhrzeit – godzina
Wiederkehrendes Zeitereignis – powtarzające się zdarzenia
Wczytywanie skonsolidowanych wartości pomiarów i komunikatów dot. trybu pracy i
zakłóceń wykonuje uŜytkownik. W przypadku wyszukiwania poza obrębem obszaru online
uŜytkownik otrzymuje informację.
3.2.1.2. Kopia zapasowa i przywracanie systemu
Pod pojęciem kopii zapasowej rozumiane jest zabezpieczenie wybranych danych na
nośniku zapasowym w celu przywrócenia ponownie pierwotnego stanu w przypadku
awarii.
Wersja 4.0
55/192
UŜytkownik moŜe przy tym ustalić, jakie dane chce zabezpieczyć:
pełna kopia zapasowa w formie obrazu systemu (zabezpieczenie całego obrazu
poszczególnych komputerów),
zasoby archiwalne,
parametry systemu.
Pełna kopia zapasowa w postaci obrazu systemu wykonywana jest przy uŜyciu programu
Symantec Ghost. Kopie zapasowe wykonywane są ręcznie w określonych, cyklicznych
odstępach czasu lub teŜ po większych zmianach w systemie (np. aktualizacje w ramach
umowy systemowej) i nie moŜna ich wykonywać podczas pracy systemu.
Zabezpieczanie danych uŜytkowych wykonywane jest w cyklicznych odstępach czasu,
automatycznie podczas pracy systemu, przy uŜyciu programu Veritas Backup Exec. Ten
program do tworzenia kopii zapasowych konfigurowany jest za pośrednictwem
odpowiednich skryptów.
Przechowywane w plikach dane uŜytkowe są podczas zabezpieczania danych po prostu
kopiowane. Zabezpieczanie baz danych Oracle wymaga, aby podczas zabezpieczania
były one przełączane (wewnętrznie) na tryb tylko do odczytu.
Zabezpieczanie danych moŜe obejmować takŜe parametry systemu.
W zaleŜności od danego błędu konieczne jest skorzystanie z pełnego zabezpieczenia
systemu lub teŜ wystarczy wgranie odpowiednich zabezpieczonych plików.
Wersja 4.0
4.
56/192
Priorytet dla transportu zbiorowego
Dla potrzeb wdroŜenia systemu udzielania priorytetów dla pojazdów transportu zbiorowego
w Warszawie w obszarze I wykorzystywany będzie istniejący w tramwajach System
Nadzoru Ruchu Tramwajowego (SNRT), dostarczający niezbędnych informacji na temat
bieŜącej lokalizacji pojazdów, poruszających się w ciągu Alei Jerozolimskich na odcinku od
Ronda Waszyngtona do Placu Zawiszy.
System będzie obejmował 160 pociągów tramwajowych i obsługiwał priorytety na 9
skrzyŜowaniach.
Lp.
1
2
3
4
5
6
7
8
9
Nazwa skrzyŜowania
Rondo Waszyngtona
Rondo de Gaulle’a
Al. Jerozolimskie – Krucza
Al. Jerozolimskie – Marszałkowska
Al. Jerozolimskie – Emilii Plater
Al. Jerozolimskie – Chałubińskiego
Al. Jerozolimskie – śelazna
Al. Jerozolimskie – Miedziana
Plac Zawiszy
Schemat systemu udzielania priorytetu dla transportu zbiorowego przedstawia rysunek
4.1.
Rysunek 4.1: Schemat systemu udzielania priorytetów dla transportu zbiorowego
Wersja 4.0
57/192
Zasada funkcjonowania systemu udzielania priorytetów dla transportu zbiorowego:
o System priorytetu będzie bazował na informacjach z istniejącego Systemu Nadzoru
Ruchu Tramwajowego (SNRT), umoŜliwiającego bieŜącą lokalizację pociągów
tramwajowych, poruszających się w ciągu Alei Jerozolimskich na odcinku od
Ronda Waszyngtona do Placu Zawiszy
o Dodatkowo w pojazdach zostanie zainstalowany i podłączony do istniejących
komputerów pokładowych sterownik komunikatów
o Komputer pokładowy będzie przekazywał do sterownika komunikatów aktualną
pozycję w oparciu o system GPS
o Sterownik komunikatów, na podstawie aktualnej pozycji i zaprogramowanych
informacji o trasie przejazdu i lokalizacji pozycji zgłoszeniowych, wysyła
odpowiednie komunikaty bezpośrednio do sterowników sygnalizacji.
o Komunikacja pomiędzy tramwajem i sterownikiem sygnalizacji odbywa się drogą
radiową, przy pomocy radia krótkiego zasięgu (max.500m).
o Zastosowane zostaną standaryzowane telegramy VDV-R09.x
o Za pośrednictwem tego połączenia radiowego pojazd transportu zbiorowego
przesyła, w momencie osiągnięcia zdefiniowanego punktu zgłoszeniowego,
telegram Ŝądania do sterownika urządzenia sygnalizacji świetlnej.
o Sterownik sygnalizacji świetlnej uwzględnia Ŝądanie pojazdu transportu zbiorowego
w algorytmie sterowania, uzaleŜnionym od natęŜenia ruchu, i reaguje odpowiednio
na zgłoszenie.
o Telegram Ŝądania zapisywany jest razem z dodatkowymi informacjami w
sterowniku w dzienniku transportu zbiorowego .
o Dziennik transportu zbiorowego jest stale odczytywany przez system sterowania
ruchem drogowym, archiwizowany w centrali i wykorzystywany do analiz
jakościowych.
Struktura telegramów Ŝądań transportu zbiorowego jest standaryzowana (VDV – R09.x) i
moŜe zawierać następujące waŜne informacje:
o numer punktu zgłoszeniowego,
o numer linii,
o numer kursu,
o priorytet,
o odstępstwo od rozkładu jazdy.
Zazwyczaj rozróŜnia się klika rodzajów punktów zgłoszeniowych (np. zgłoszenie wstępne,
zgłoszenie główne, wyjście). Pozycja punktu określana jest przez komputer pokładowy
pojazdu transportu zbiorowego za pośrednictwem systemu lokalizacji GPS.
Dokładna lokalizacja punktów zgłoszeniowych zostanie określona na etapie
szczegółowych projektów sterowania na poszczególnych skrzyŜowaniach.
W sterownikach sygnalizacji zostanie zamontowane radio krótkiego zasięgu oraz układ
AFD, odpowiedzialny za przekazywanie telegramów do sterownika sygnalizacji poprzez
łącze szeregowe.
Przewiduje się zastosowanie odbiorników/nadajników radiowych pracujących w zakresie
częstotliwości 430-470 MHz. Przed dokładnym określeniem zastosowanych urządzeń musi
nastąpić wybór i pozyskanie dla systemu odpowiedniej częstotliwości.
Szczegółowe parametry techniczne zastosowanych urządzeń zostaną zawarte w
projektach technicznych po uzyskaniu wszystkich niezbędnych uzgodnień i pozwoleń.
Wersja 4.0
5.
58/192
Proces projektowania i zasilania danymi
Projektowanie poszczególnych urządzeń sygnalizacji świetlnej moŜna podzielić ogólnie na
3 etapy:
na projektowanie podstawowe (np. ustalanie sygnałów przejścia i ich czasów,
określanie grup sygnalizacyjnych i typów),
projektowanie techniki sterowania ruchem drogowym (formułowanie algorytmów
logicznych sterowania ruchem przy uŜyciu róŜnych technik sterowania ruchem),
symulację (test utworzonej techniki sterowania ruchem za pomocą VISSIM).
Z poziomu narzędzi do projektowania programy przekazywane są do komputera
sterującego ruchem i sterowników. Za pośrednictwem standaryzowanego interfejsu OCIT
Outstation moŜna zdalnie programować sterowniki oraz klienckie stanowiska obsługowe z
centrali. Dokładny opis narzędzi oraz ich wzajemnych powiązań zamieszczono w dalszych
rozdziałach.
5.1.
Stanowisko inŜyniera kierowania ruchem SITRAFFIC P2
SITRAFFIC P2 oferuje inŜynierowi ruchu wsparcie podczas planowania i projektowania
punktów kolizji wraz z obliczaniem czasów międzyzielonych z automatycznym ustalaniem
drogi na podstawie planu sytuacyjnego, obliczanie planu sygnalizacji oraz edycję
graficzną.
Tworzenie danych podstawowych oraz parametrów dla róŜnych mikroskopowych procedur
sterowania wraz z funkcjami m.in. edycji faz i generowania planu ramowego.
Edycja skoordynowanych układów sterowania sygnalizacją z funkcjami w rodzaju np.
tworzenia wykresów koordynacyjnych (droga w funkcji czasu) ze szczególnym
uwzględnieniem przebiegów przejazdu transportu publicznego i obszarów sterowania
uzaleŜnionego od natęŜenia ruchu.
Wymiana danych pomiędzy sterownikami i komputerami sterowania ruchem.
Transfer danych do symulacji mikroskopowych (VISSIM).
Stanowisko pracy inŜyniera ruchu SITRAFFIC P2 to obiektowe narzędzie do obliczania
czasów
międzyzielonych
oraz
projektowania
programów
stałoczasowych
i
akomodowanych, takŜe w układzie skoordynowanym.
Obejmuje ono tworzenie programów sygnalizacji (w razie potrzeby z uwzględnieniem
sprawdzenia wydajności), wykresów koordynacyjnych oraz podstawowych danych dla
sterowania akomodacyjnego. W celu symulacji dane te moŜna przekazać do programu
VISSIM za pomocą funkcji eksportowania.
Projektowanie wspomagane jest poprzez automatyczne przejmowanie danych z planu
sytuacyjnego do edytorów, wykaz urządzeń oraz kontrolę spójności, jak równieŜ róŜne
algorytmy obliczeniowe.
Utworzone dane projektowe słuŜą jako podstawa do programowania sterowników
(C800V/C900V) oraz systemów sterujących ruchem (SITRAFFIC Scala); moŜna je
przesyłać do programów SITRAFFIC Control i SITRAFFIC Supply/S4 za pomocą funkcji
eksportu.
5.1.1. Zakres danych
Wersja 4.0
59/192
Interfejs obejmuje wyświetlanie w punktach kolizji danych podstawowych programów
sygnalizacyjnych, tzn. na podstawie przepisów i dyrektyw dot. technicznych warunków
projektowania programów sygnalizacyjnych urządzeń sygnalizacji świetlnej.
Nie zostały uwzględnione specyficzne dla producentów dane dot. programowania
sterowników,. Poza tym nie są przenoszone algorytmy logiczne sterowania
akomodacyjnego lub adaptacyjnego sterowników sygnalizacji świetlnej jak równieŜ dane
standaryzowanych technik programowania.
Następujące dane moŜna przenieść za pomocą interfejsu OCIT do systemu SITRAFFIC
P2:
Cechy sterownika
o Wersja
o Producent
o Typ urządzenia
o Uwagi
Parametry komunikacji z nadrzędnym systemem sterowania ruchem
o Wersja
o Producent
o Typ interfejsu
o Parametry interfejsu
o Uwagi
Podstawowe parametry sterowników sygnalizacji świetlnej
o Nazwa, skrócona nazwa
o Numer urządzenia
o Numer grupy
o Numer urządzenia
o Miejscowość, kraj
o Uwagi
Dane dot. projektu
o Status
o Wersja
o Nazwa
o Data
o Zlecenie
o Źródło danych
o Uwagi
Dane skrzyŜowania
o Wytyczne projektowe
o Lokalizacja
o Programowa część węzła
o Sprzętowa część węzła
o Uwagi
Polecenia przełączania
Pragram sygnalizacji odwzorowywany jest poprzez wyświetlanie barwnego układu
sygnalizatorów (włączona, wyłączona, miga) oraz takich parametrów takich jak:
o Grupy sygnalizacyjne
o Numer
o Nazwa
o Typ
o Nadajnik sygnału
o Liczba komór sygnalizacyjnych w grupie
Wersja 4.0
o
o
o
o
o
o
o
o
60/192
Warunki nadzorowania
Grupa sygnalizacyjna
Nadzorowanie grup
Uwagi
Lista min. czasów zielonych
Lista min. czasów czerwonych
Matryce czasów międzyzielonych
Offsety
Programy sygnalizacyjne (o numerze większym niŜ 0)
o Numer (>0)
o Nazwa
o Typ programu
o Długość cyklu
o Offset
o Punkt włączenia
o Punkt wyłączenia
o Punkt przełączania
o Czas międzyzielone
o Punkt synchronizacji
o Rodzaj sterowania
o Listy (listy poleceń, min. czasu zielony, min. czasu czerwony,
matryca czasów międzyzielonych)
o Fazy
o Numer
o Nazwa
o Typ
o Uwagi
o Przejścia fazowe
o Numer
o Nazwa
o Typ
Lista poleceń przejść międzyfazowych
o Faza źródłowa i docelowa
o Czas trwania
Detektory
o Numer
o Nazwa
o Typ
o Uwagi
Polecenia uzaleŜnione kalendarza programów
SITRAFFIC P2 zapewnia ogólny interfejs wymiany danych dla róŜnych programów
sygnalizacji. Dzięki eksportowi danych projektowych, ich przeniesieniu do innych
programów, oraz danych pobranych ze sterownika moŜna uniknąć wielokrotnego
programowania.
5.1.2. Eksport do SITRAFFIC Language (TL)
Wersja 4.0
61/192
Za pośrednictwem polecenia menu‚ Edycja – Eksport danych –Eksport TL’ moŜna
eksportować parametry programów (nazwy)
Grupy sygnalizacyjne
detektory
wyjścia
przejścia fazowe
w postaci pliku źródłowego TL (*.QEL).
5.2.
SITRAFFIC Language (programowanie algorytmów
logicznych techniki sterowania ruchem)
SITRAFFIC Language - TL to język dla algorytmów sterowania akomodacyjnego, za
pomocą którego projektant moŜe przetworzyć zadania techniki sterowania ruchem na kod
programu. Dzięki edytorowi schematów blokowych, który działa w oparciu o elementy tego
języka, uŜytkownik ma odwzorowanie graficzne podczas formułowania algorytmów
logicznych sterowania.
W obrębie programu, biblioteki modułowe zapewniają rozwiązania dla szeregu problemów
techniki sterowania ruchem. Funkcjom tym wystarczy jedynie nadać odpowiednie
parametry, a ich wyniki dostępne są dla uŜytkownika w celu dalszej modyfikacji.
Funkcje zaprogramowane samodzielnie przez projektanta moŜna zgrupować w bibliotece
uŜytkownika.
Dzięki duŜej ilości wstępnie zdefiniowanych rozwiązań standardowych moŜna zredukować
do minimum część warunków indywidualnych przy uŜyciu SITRAFFIC Language i
znacznie skrócić czas tworzenia i testowania programu.
Nowy debugger ułatwia wyszukiwanie błędów programu akomodacyjnego.
Przy uŜyciu kompilatora algorytm sterowania ruchem tłumaczony jest na kod programu dla
narzędzia VISSIM (w celu symulacji programu akomodacyjnego).
5.2.1. Środowisko programistyczne TL
Składniki, które obejmuje środowisko programistyczne TL przedstawiono na rysunku 5.1.
Wersja 4.0
62/192
Rysunek 5.1: Środowisko programistyczne
Objaśnienia do rysunku 5.1:
tlp – plik projektu
bib – biblioteki
qel – pliki tekstów źródłowych
mod – definicje parametrów
TL-Oberflache – powierzchni TL
Projektverwaltung – administracja projektu
Struktograomm- / Flussdiagrammeditor – edytor struktogramu i diagramu blokowego
Praprocessor – preprocesor
Compilertreiber – kompilator
ANSI C-Compiler – kompilator ANSI C
Fehlerruckfuhrung – eliminowanie błędów
Simulation / VISSIM – symulacja / VISSIM
Parametrierung - parametryzowanie
5.2.2. Zarządzanie projektem
Wszystkie informacje o uŜywanych w jednym projekcie bibliotekach, tekstach źródłowych i
parametrach, jak równieŜ o plikach eksportu/importu zapisane są w pliku projektu (*.TLP).
Wszystkie niezbędne pliki te są ładowane podczas otwierania projektu.
5.2.3. Edytor schematów struktury wzgl. schematów blokowych
Ten moduł oprogramowania dzięki graficznej prezentacji przebiegów, pętli i rozgałęzień
wspiera uŜytkownika i ułatwia mu w znacznym stopniu tworzenie układu logicznego. Przy
uŜyciu elementów języka TL uŜytkownik moŜe pracować nawet bez wiedzy
programistycznej, zaś struktura okien (przykład na rysunku 5.2) pomaga uniknąć błędów.
Wersja 4.0
63/192
Rysunek 5.2: Przykładowy widok okna edytora schematów
Objaśnienia do powyŜszego ekranu:
Funktion AnwenderInit - Funkcja inicjalizacja uŜytkownika
Initialisierungen - Inicjalizacja
Initzeitpunkt - Moment inicjalizacji
1.Aufruf der TL nach Netzaus oder Neuversorgung - 1. uruchomienie TL po wyłączeniu sieci lub
ponowne zasilanie
Bei Start der Verkehrsabhangigkeit Initialisieren der Folgenden Anwendervagriablen - Przy
uruchomieniu uzaleŜnienia od ruchu, Inicjalizacja następujących zmiennych uŜytkownika
5.2.4. Kompilator
Kompilator to interfejs pomiędzy SITRAFFIC Language a ANSI-C. W zaleŜności od
zastosowanego typu kompilatora sposób wywoływania i komunikaty o błędach są róŜne.
Kompilator C wymaga sterownika tworzącego kod.
5.2.5. Kompilator ANSI C
Te elementy programu są aktywowane z w sposób niewidoczny dla uŜytkownika.
Kompilator przekłada algorytm sterowania ruchem, utworzony przy uŜyciu preprocesora,
na kod programu VISSIM.
Kod programu umoŜliwia wraz z komponentami podstawowymi programu VISSIM
wykonanie symulacji programu akomodacyjnego.
5.2.6. Procedury sterujące - główne funkcje
Jednym z przykładów jest algorytm sterowania PDM. Algorytm PDM bazuje na zmianach
natęŜenia ruchu. Zmiana stanu dla poszczególnych grup sygnalizacyjnych realizowana jest
w przejściach fazowych.
Procedura sterująca PDM udostępnia dwie biblioteki:
- bibliotekę jądra sterującego
- bibliotekę procedury sterującej PDM
Przy uŜyciu programu SITRAFFIC Language uŜytkownik moŜe stworzyć program
sygnalizacyjny (przy uŜyciu gotowych bibliotek) zgodny z dokumentacją projektową.
Wynikiem powyŜszych działań jest otrzymywany kod programu.
Kod ten moŜna następnie przetestować przy uŜyciu programu VISSIM.
Wersja 4.0
64/192
5.2.7. Konfiguracja parametrów
Programowania funkcji programu sygnalizacyjnego oraz parametrów nie moŜna wykonać
w obrębie TL. Niezbędny jest do tego program SITRAFFIC Control.
W nim ustalane są wartości poszczególnych parametrów. Nazwy parametrów
przekazywane są do TL w pliku parametrów (*.MOD).
Rysunek 5.3: Przykładowy widok okna wprowadzania parametrów – przykład z Centrum
Zarządzania w Berlinie
Na rysunku 5.3 przedstawiono moŜliwy wygląd okna wprowadzania parametrów. Okna
wprowadzania definiowane są jednorazowo. MoŜna zdefiniować parametry do
wprowadzania i przypisać im teksty pomocy. Ułatwia to późniejszym uŜytkownikom
określenie parametrów programu akomodowanego.
5.2.8. Biblioteki uŜytkownika
KaŜdy uŜytkownik ma moŜliwość zapisania często uŜywanych funkcji w indywidualnej
bibliotece. UmoŜliwia to rozszerzenie funkcji standardowych o funkcje uŜytkownika. Dzięki
temu projektant moŜe wprowadzać indywidualne rozwiązania w wielu projektach bez
konieczności ich ponownego programowania za kaŜdym razem.
Biblioteki uŜytkownika moŜna równieŜ udostępniać innym projektantom.
5.3.
SITRAFFIC Control
Zdalne programowanie sterowników sygnalizacji świetlnej wykonywane jest przy uŜyciu
programu SITRAFFIC Control bezpośrednio ze stanowisk obsługowych klienta.
Stałe parametry programów sygnalizacyjnych są dostępne na poziomie projektów oraz w
sterowniku lokalnym.
Integracja programowania dla sterowników innych producentów jest moŜliwa za
pośrednictwem otwartego interfejsu:
Wersja 4.0
65/192
interfejs OCIT słuŜy do przekazywania programów sygnalizacji do narzędzia
programowania,
interfejs OCIT słuŜy do zdalnego programowania sterowników lokalnych poprzez
stacje zewnętrzne
5.3.1. Import/eksport danych z programu SITRAFFIC P2
Wymiana danych pomiędzy programem do projektowania SITRAFFIC P2 a SITRAFFIC
Control redukuje moŜliwość dublowania się danych.
W programie SITRAFFIC Control moŜna, za pośrednictwem funkcji importu, przenieść
dane utworzone w SITRAFFIC P2 do pliku projektu (*.SIP).
MoŜna importować dane związane z programem uŜytkownika, parametrami
podstawowymi i symulacją. Wyboru danych do przeniesienia dokonuje się zaznaczając
pola wyboru w oknie dialogowym. W obszarze programów stałoczasowych parametry
podstawowe i symulację moŜna zaimportować do projektu w dwóch odrębnych
etapach.
W edytorach (program uŜytkownika, parametry podstawowe i symulacja wyświetlane
są osobno) dane z pliku projektu SITRAFFIC P2 konfrontowane są z aktualnym
projektem SITRAFFIC Control. Następnie moŜna wybrać pojedyncze instancje,
przeznaczone do zaimportowania. Standardowo import danych definiują następujące
warunki wstępne:
Obiekty identycznie w obu programach nie są kopiowane.
Obiekty róŜniące się, ale istniejące, są kopiowane z pliku projektu P2 (ew. jako
wartości domyślne ustawiane są dodatkowe parametry z SITRAFFIC Control).
Jeśli obiekt znajduje się w pliku projektu, i nie ma go w SITRAFFIC Control, jest on
kopiowany.
W przeciwnym razie ustawiane są wartości domyślne.
Moduł zarządzania projektem SITRAFFIC Control wymienia następujące informacje:
Nazwa projektu
Miasto
Ulica
Punkt odniesienia
Numer sterownika
Typ sterownika
Wymieniane są następujące obiekty danych:
Dane źródłowe (części)
Definicja wyświetlanych sygnałów
Definicja sygnałów przejściowych
Przyporządkowania sygnałów przejściowych
Czasy min.
Przesunięcia pomiędzy grupami
Sekwencje załączania/wyłączania
Matryce czasów międzyzielonych
Programy sygnalizacyjne
Definicje faz (PDM, SL)
Przejścia fazowe (PDM, SL)
Wersja 4.0
66/192
Matryce przejścia fazowych (PDM, SL)
Plany ramowe (DPM, SL)
Jeśli projekt zostanie zapisany w programie SITRAFFIC Control, dane zostaną
automatycznie przejęte do SITRAFFIC S4.
SITRAFFIC Control słuŜy modułowi SITRAFFIC Supply jako:
edytor dla wszystkich danych skrzyŜownania, z funkcjami Utwórz nowy i Zmień,
interfejs importu/eksportu do SITTRAFIC P2,
narzędzie do programowania urządzeń SITRAFFIC C800 V
Jeśli zachodzi potrzeba przeniesienia danych z SITRAFFIC P2, wówczas SITRAFFIC
Control wywoływany jest przez SITRAFFIC Supply, przejmuje dane i zapisuje je ponownie
w module SITRAFFIC Supply.
SITRAFFIC Supply moŜe przejmować z SITRAFFIC P2 następujące dane:
Dane źródłowe (dane podstawowe punktów skrzyŜowań)
Programy sygnalizacji stałoczasowe (SV)
Akomodacyjne programy sygnalizacyjne EPS
Matryce czasów międzyzielonych (ZZ)
Kalendarz automatyki rocznej
Czasy min.
Detektory
5.3.2. Programowanie sterowników sygnalizacji świetlnej (sterownik C800V) za
pomocą SITRAFFIC Control
W poniŜszej tabeli opisano dane, które mogą być zapisywane i wczytywane.
5.3.2.1. Dane podstawowe
Przegląd pokazuje, czy obiekty parametrów mogą być zapisane (write)/odczytywane
(read).
- = nie, X = tak
Droga wgrywania
Droga wgrywania wg przeglądu
Węzeł drzewa
Obiekt
Dane
Dane źródłowe
podstawowe
Parametry
Warunki
Parametry czasu
Definicje wejść/wyjść
Definicje
Definicje kolorów
sygnałów
Opis sygnału
Kolory przejściowe
(zielony czerwony)
Scala
OCIT
C800 V4
(modem)
11
w
r
X
X
X
-
X
X
X
X
X
-
X
X
Wersja 4.0
Droga wgrywania
Węzeł drzewa
Obiekt
Kolory przejściowe
(czerwony zielony)
Przypisanie kolorów
przejściowych do grup
sygnalizacyjnych
Przypisanie kolorów
przejściowych do grup
sygnalizacyjnych
Sygnalizacja
Listy min. czasów
zielonych
Listy min. czasów
czerwonych
Matryce czasów
międzyzielonych
Matryce czasów
przesunięcia początek
Matryce czasów
przesunięcia koniec
Sekwencja włączania
Sekwencja wyłączania
Obrazy
włączania/wyłączania
Programy sygnalizacyjne
Program straŜy poŜarnej
Program przejazdów
kolejowych
Fazy ręczne
Fazy
Przejście fazowe
Parametry faz
Matryca przejść
fazowych
Automatyka
Kalendarz automatyki
przełączająca
rocznej
Wejścia/wyjścia
Nadzór detektorów
Detektor
Wyjścia
Potwierdzenie wejść
Centrala
Definicje BEFA
Zdalne programy
sygnalizacyjne
SiplOnline
Dane tekstowe
Definicje celów TABU
Identyfikacja klienta
Specjalne
Dane transportu
publicznego
Złącza szeregowe
67/192
Scala
OCIT
C800 V4
(modem)
11
w
r
X
-
X
-
X
-
X
-
X
-
X
-
X
-
X
-
X
X
X
X
X
-
X
X
X
-
X
X
X
X
X
X
X
X
X
-
X
X
X
X
X
X
X
X
X
X
X
X
X
-
X
Wersja 4.0
Droga wgrywania
Węzeł drzewa
Obiekt
Archiwum
Modem
Parametry pulpitu BAZ
PrzejeŜdŜający na
czerwonym świetle
Transport publiczny –
lampy 4-ro komorowe
Permissiv
Zezwolenia
68/192
Scala
OCIT
C800 V4
(modem)
11
w
r
X
X
X
X
X
X
X
-
X
X
X
X
5.3.2.2. Monitor konfliktów SISI (zabezpieczenie sygnałów)
Parametrów monitora konfliktów nie moŜna wgrać ani odczytać z centrali.
5.3.2.3. Obiekty zasilające wszystkich zaleŜności od natęŜenia ruchu
Przegląd pokazuje, czy parametry mogą być zapisywane (write)/odczytywane (read).
- = nie, X = tak
Droga wgrywania
Obiekt
Wszystkie parametry akomodacji (VA)
Scala
OCIT
C800 V4
(modem)
11
w
r
X
X
5.3.2.4. ZaleŜny od natęŜenia ruchu program (kod) wszystkich zaleŜności od
natęŜenia ruchu
Przegląd pokazuje, czy program moŜe być zapisywany (write)/odczytywany (read).
- = nie, X = tak
Droga wgrywania
Obiekt
Cały kod VA
5.4.
Scala
OCIT
C800 V4
(modem)
11
w
r
X
-
Program symulacyjny VISSIM
Do symulacji w projekcie warszawskim zostanie uŜyty program VISSIM.
Wersja 4.0
69/192
VISSIM to program do symulacji i testowania, za pomocą którego moŜna w przejrzysty
sposób wizualizować i oceniać mikroskopijne przebiegi ruchu w sieciach komunikacji
drogowej. Przykładowy widok okna z programu VISSIM przedstawiono na rysunku 5.4.
Rysunek 5.4: Przykładowy widok okna programu VISSIM
W celu wykonania symulacji układów sterowania moŜna wyeksportować dane podstawowe
topografii skrzyŜowań z programu SITRAFFIC P2 do dalszej edycji w programie VISSIM.
Przy czym eksport skrzyŜowania moŜliwy jest zarówno do nowego pliku *.INP, jak równieŜ
do istniejącego juŜ odcinka.
Eksportowane są informacje z następujących obiektów SITRAFFIC P2:
Informacje o pasach jezdni (w programie VISSIM moŜna dostosować długość pasa
jezdni w celu uwzględnienia grup sygnalizacyjnych)
Przejścia (tutaj pojawiają się róŜnice w wartościach w wyniku wydłuŜenia przejścia)
Linie odniesienia
Przystanki
Detektory (umieszczane są na odpowiednich pasach jezdni; w przypadku
przycisków dla pieszych ustawiane są wartości domyślne)
Punkty zgłoszeniowe (umieszczane są na odpowiednich pasach jezdni)
W przypadku istniejących juŜ odcinków do programu VISSIM moŜna zaimportować nowy
plan sygnalizacji (stałoczasowy).
MoŜliwy jest eksport matrycy czasów międzyzielonych dla SITRAFFIC Language (TL) do
istniejącego lub nowego pliku *.PW1.
Program VISSIM stosowany jest w celu dokonania testu i oceny procedur sterujących
(sterowania stałoczasowego, PDM itp.).
Symulacja obejmuje:
moduł podstawowy VISSIM,
Wersja 4.0
70/192
moduł akomodacji - VA (interfejs zaleŜności od natęŜenia ruchu).
Wartości pomiarów z detektorów oraz stany sygnalizacji przekazywane są za pomocą
interfejsu.
Za pomocą programu VISSIM moŜna przetestować na komputerze, w trybie offline,
algorytm sterowania, utworzony przy uŜyciu TL. Podczas symulacji moŜna – dzięki zmianie
parametrów – wykonać optymalizację zaleŜności od natęŜenia ruchu.
MoŜliwe jest przetestowanie projektu z uŜyciem wartości pomiarów, zgromadzonych przez
sterownik sygnalizacji świetlnej, lub pomiarów wykonanych ręcznie, z bezpośrednim
wpływem na detektory. W przypadku testu, oprócz kompleksowych protokołów, za pomocą
debuggera tworzony jest protokół dla algorytmu sterowania. Ułatwia to wyszukiwanie
błędów zaprojektowanego algorytmu.
Po wykonaniu testu technicznego i po utworzeniu programu sygnalizacji, moŜna wgrać
dane do sterownika .
5.5.
Programowanie sterownika sygnalizacji świetlnej
NaleŜy przesłać następujące dane:
dane podstawowe systemu sterowania ruchem,
dane podstawowe sterowników sygnalizacji świetlnej.
Ładowanie danych podstawowych systemu sterowania ruchem i sterowników sygnalizacji
świetlnej wykonywane jest przez program SITRAFFIC Supply. Jako edytor obszaru
skrzyŜowań integruje on narzędzie SITRAFFIC Control.
SITRAFFIC Supply/Control zintegrowane są w pakiet narzędzi programowych.
SITRAFFIC Supply zarządza danymi w wielu obszarach:
W pierwszym obszarze zapisane są dane (zasoby), widoczne dla uŜytkownika w
zaleŜności od jego uprawnień.
Kolejny obszar umoŜliwia edycję danych (obszar roboczy).
Usunięte dane zapisywane są w trzecim obszarze, zanim zostaną one całkowicie
usunięte przez uŜytkownika (usunięty obszar roboczy).
Na rysunku 5.5 przedstawiono moŜliwy wygląd okna podczas wgrywania programu z
uŜyciem SITRAFFIC Supply.
Wersja 4.0
71/192
Rysunek 5.5: Przykład wgrywania programu z uŜyciem SITRAFFIC Supply
Bestand – zasób
Arbeitsbereich – obszar roboczy
Arbeitsbereich geloscht – usunięty obszar roboczy
Versorgung – zasilanie
Verkehrsrechner – komputer sterujący ruchem
Feldgerate – urządzenia polowe
BEFA-Liste – lista BEFA
Knotengruppen – grupy węzłów
MOTION-Bereich – obszary MOTION
Messsystem – system pomiarowy
Systemkonfiguration – konfiguracja systemu
Wartungsteams – zespoły konserwacyjne
Hersteller – producent
Messstellen-Typen – rodzaje miejsc pomiaru
Textschnittstellen Konfiguration – konfiguracja interfejsów tekstowych
Wgrywanie konfiguracji systemu sterownikom sygnalizacji świetlnej
dane podstawowe systemów sterowania ruchem,
pasek elementów sygnalizacji,
import/eksport.
W obszarze funkcyjnym wgrywane są parametry związane z algorytmem sterowania
systemu sterowania ruchem.
Wersja 4.0
72/192
Wgrywanie parametrów punktów węzłowych
dane podstawowe punktu węzłowego,
topologia,
detektor,
grupy sygnalizacyjne,
przesunięcia grup sygnałowych (matryce czasów przesunięcia),
programy sygnalizacyjne,
lokalny automatyczny kalendarz sterowania rocznego (JAUT),
sprzęt – oprogramowanie,
import/eksport.
Opisywane są parametry związane z techniką sterowania, właściwości sterownika, jak
równieŜ zasilanie układów topologii (przejmowanie danych z SITRAFFIC P2, m.in. grupy
sygnalizacyjne, detektory równoległe, detektory szeregowe, ramiona punktów węzłowych)
danego skrzyŜowania.
SITRAFFIC Control słuŜy narzędziu SITRAFFIC Supply jako:
edytor dla wszystkich parametrów skrzyŜowania, z funkcjami Utwórz nowy i Zmień,
interfejs importu/eksportu do stanowiska projektowania SITTRAFIC P2,
zdalne programowanie sterowników SITRAFFIC C800V.
Jeśli zachodzi potrzeba przeniesienia danych z SITRAFFIC P2, wtedy SITRAFFIC Control
wywoływany jest przez CITRAFFIC Supply, przejmuje dane i zapisuje je ponownie w
module SITRAFFIC Supply.
SITRAFFIC Supply moŜe przejmować z SITRAFFIC P2 następujące dane:
Dane źródłowe (dane podstawowe skrzyŜowań)
Programy sygnalizacji stałoczasowe,
Matryce czasów międzyzielonych (ZZ)
lokalny automatyczny kalendarz sterowania rocznego (JAUT),
Czasy min.
Detektory
Programowanie przyporządkowań grup punktów węzłowych oraz centralnego
automatycznego układu sterowania rocznego (JAUT) wykonywane jest przy uŜyciu okien
dialogowych konfiguracji, otwieranych bezpośrednio z poziomu interfejsu uŜytkownika
systemu sterowania ruchem.
Wersja 4.0
73/192
Rysunek 5.6: Przykład konfiguracji centralnego układu kalendarza JAUT
Name – nazwa
Kurzname – skrót
Subsystem – podsystem
Wichtigkeit – priorytet
Istzustand – stan aktualny
Sollzustand – stan zadany
Stammdaten – dane podstawowe
Detektoren – detektory
Gruppenzugehorigkeit – przynaleŜność do grupy
Lage – połoŜenie
Redaktion – redakcja
Sernice – serwis
Steuerungsebene – poziom sterowania
Blockieren – blokowanie
Hand von – ręczne od (data)
Jaut: w tym polu pojawia się definicja terminu kalendarza JAUT w formie tekstowej
Hauptknoten – węzeł główny
Ein – włączony
Wersja 4.0
74/192
Aus – wyłączony
Auto – tryb automatyczny
SP-Auswahl – wybór SP
Schaltmodus – tryb włączania
OV Bevorzugung – preferencje środków komunikacji publicznej
Schaltgrund – przyczyna włączenia
Wersja 4.0
6.
75/192
STRAMO
Za pomocą funkcji modułu STRAMO moŜna powiązać ze sobą dane wejściowe systemów
TMS/UTC Warszawa, wraz z podłączonymi sterownikami OCIT-LSA
które będą wprowadzone w przyszłości, jak np. systemy sterowania dojazdem
pojazdów do parkingów itp.
i moŜna wprowadzić automatyczne albo półautomatyczne plany działania.
UŜytkownik otrzymuje duŜe moŜliwości tworzenia funkcji logicznych i wstępnego
zdefiniowania planów działania.
Funkcja STRAMO oferuje np. następujące funkcje.
powiązania łańcuchowe danych wejściowych przez kompleksowe algorytmy
logiczne (np. zdarzenia z układu zarządzania przypadkami zakłóceń ruchu z
aktualnymi informacjami, pochodzącymi z układu sterowania światłami
sygnalizacyjnymi);
włączanie prostych zdarzeń (np. akcje załączania);
wprowadzanie danych wyjściowych (do wykorzystania w innych modułach, np. w
układach mikrosterowania pracujących adaptacyjnie);
zawiera kompletne otoczenie, wraz z edytorem układów logicznych i testem offline;
moŜe uwzględniać algorytmy sformułowane w JAVA;
generuje kody JAVA moŜliwe do uruchomienia;
cyklicznie przetwarza istniejące układy logiczne (1 do 60 min).
UŜytkownik otrzymuje wiele moŜliwości tworzenia logicznych powiązań łańcuchowych.
STRAMO pracuje z wykorzystaniem wprowadzonych algorytmów logicznych sterowania,
które są cyklicznie przetwarzane. W obszarze tych systemów uŜytkownik nie ma Ŝadnej
moŜliwości ręcznego oddziaływania na strategię. UmoŜliwienie ręcznego wdraŜania
„wariantów strategii“odbywa się poprzez stosowanie tzw. planów reakcji
Plany reakcji oferują między innymi następujące moŜliwości zastosowania:
formułowanie kompleksowych planów reakcji (równieŜ z podziałem czasowym);
proste funkcje logiczne danych wyjściowych;
aktywacja, opracowanie, zatwierdzenie działań w ramach strategii przez
pracownika obsługi;
aktywacja przez warunki czasowe;
aktywacja przez zdarzenia występujące w systemie;
funkcje logiczne warunków czasowych i zdarzeń występujących w systemie;
powiązanie logiczne ze STRAMO;
przetwarzanie automatyczne lub półautomatyczne (równieŜ w trybie pojedynczych
kroków).
UŜytkownik otrzymuje liczne moŜliwości wstępnego zdefiniowania planów reakcji.
Wersja 4.0
76/192
Plany reakcji mają za zadanie pomóc operatorowi w podjęciu prawidłowych decyzji, w
prawidłowej kolejności, przy dowolnym zdarzeniu występującym w systemie. JeŜeli w
systemie wystąpi zdarzenie, wówczas operator moŜe wykorzystać wcześniej wprowadzony
plan reakcji. Treść tego planu moŜe być róŜna, w zaleŜności od rodzaju zdarzenia, np.
mogą być włączane teksty wyświetlane na tablicach informacyjnych. W zaleŜności od
określonego czasu przejazdu moŜe zostać włączony podgląd kamer telewizyjnych, np.
programy sygnalizacji pochodzące z systemu sterującego ruchem. Operator otrzymuje
przy tym wykaz punktów, które powinien wykonać.
Plan reakcji jako centralny moduł zarządzania
Plany reakcji nadzorują występujące w systemie zdarzenia i, w przypadku zmiany jednego
z parametrów występujących w systemie, mogą realizować uprzednio wprowadzony plan.
PoniewaŜ w systemie mogą występować róŜne zdarzenia, więc plan reakcji moŜe zostać
wprowadzony nie tylko w przypadku rozpoznania zakłócenia w ruchu (zator albo incydent),
ale równieŜ np. w przypadku zmiany sytuacji komunikacyjnej na dowolnym fragmencie
odcinka. Tego rodzaju warunki są określane w systemie jako układy typu „Tigger”.
Oprócz występujących w systemie zdarzeń są jeszcze przewidziane następujące opcje:
wprowadzone ręcznie przez operatora
wprowadzone przez system sterowania pracujący w funkcji czasu
wprowadzony przez moduł strategiczny (pośrednio przez zdarzenia systemowe).
Definicja zdarzenia systemowego
Pod pojęciem zdarzenia systemowego rozumie się przekroczenie parametru w systemie.
Zasadniczo w systemie STRAMO wszystkie wartości dynamiczne są do dyspozycji w
formie parametrów. W zaleŜności od tego, w jakim cyklu zostały wprowadzone do systemu
nowe dane, zmieniają się równieŜ stany parametrów. Te zmiany stanu stanowią elementy
planu reakcji.
Parametry systemowe mogą być wykorzystane za pomocą planów reakcji jako układy typu
„Tigger”.
Sytuacja komunikacyjna występująca:
w punkcie pomiarowym,
na fragmencie odcinka trasy,
na trasie (będącej połączeniem kilku odcinków).
Parametry komunikacyjne w punkcie pomiarowym/detektorze
zliczanie pojazdów
stan zajętości
prędkość
stan punktu pomiarowego (detektora)
Czas przejazdu na
trasach
drogach sterowanych tablicami informacyjnymi
stanie ( praca prawidłowa/ praca nieprawidłowa) tablicy informacyjnej
Wersja 4.0
77/192
Funkcje logiczne systemu Stramo
parametry pracy
Pozwalają na stworzenie dowolnych funkcji logicznych z dynamicznym
odczytywaniem wartości, które mogą wprowadzić plan reakcji.
Za pomocą algorytmów moŜna definiować następujące zdarzenia systemowe:
stan (wartość dyskretna) parametru
zmiana stanu (przełączenie na wartość względną) parametru
W ramach zarządzania planami reakcji istnieje moŜliwość porównania zdarzenia
systemowego pod kątem obszarów z określoną wartością parametryzowanej stałej. W
przeciwieństwie do modułu strategii nie jest tutaj moŜliwe dokonywanie porównania z
innymi stanami systemowymi i zmiennymi.
Tym samym moŜna zinterpretować stan określonego obszaru jako zdarzenie systemowe.
To samo dotyczy zmiany stanu.
Przykład:
Istnieje moŜliwość nadzorowania sytuacji komunikacyjnej na określonym odcinku drogi pod
kątem wartości stałej = 2 (zator). Gdy zmienna osiągnie wartość „2”, wówczas zostaje
włączony plan reakcji. MoŜe on np. spowodować wyświetlenie na tablicy informacyjnej
wcześniej wprowadzonego tekstu. Kolejnym krokiem moŜe być zmiana pracy grupy
sygnalizacyjnej skrzyŜowania (z tego odcinka drogi), na program sygnalizacji nr 3.
Program sygnalizacji nr 3 zawiera dłuŜsze światła zielone dla wyŜej wymienionego
fragmentu odcinka.
PoniewaŜ w przypadku planów reakcji chodzi o bardzo dynamiczne kroki, przyjmuje się
więc, Ŝe operatorzy lub administratorzy opracują w miarę upływu czasu własne plany
reakcji, uwzględniające występujące w praktyce okoliczności.
Wersja 4.0
7.
Opis techniki sterowania ruchem
7.1.
Sterowanie w funkcji czasu (automatyka roczna)
78/192
System posiada automatykę roczną, jako element składowy systemu sterowania,
pracujący w funkcji czasu.
Dla kaŜdego dnia roku definiowane są zdarzenia sterowania. Zdarzenia są zdefiniowane w
planach dziennych. W kalendarzu przyporządkowuje się plany dzienne do określonych dni
tygodnia.
Automatyka roczna uwzględnia następujące typy dni:
dni tygodnia (od niedzieli do soboty);
dni świąteczne i specjalne
dni poprzedzające dni świąteczne i niedzielę;
wakacje
Załączenia zainicjowane przez automatykę roczną powodują wysłanie zarchiwizowanych
komunikatów. Na podstawie komunikatów moŜna ustalić parametr załączenia (automatykę
roczną).
Automatyka roczna nadaje się zarówno do centralnego sterowania zdalnego programami
sygnalizacji lub do sterowania pojedynczymi skrzyŜowanie, jak i do sterowania
zdecentralizowanego.
W przypadku sterowania zdecentralizowanego, w razie potrzeby zostaje zainicjowane
automatyczne zgranie programu sygnalizacji ze sterownika (w programie sterowania nie
ma wybranego programu sygnalizacji).
7.1.1. Kalendarz
System SITRAFFIC SCALA/CONCERT oferuje obszerny kalendarz zdarzeń. Kalendarz
ten moŜna wywołać bezpośrednio ze struktury drzewiastej lub przy tworzeniu określonych
zadań sterowanych czasem. Kalendarz oferuje przegląd dni albo tygodni. Podział dni
moŜe być dowolnie zdefiniowany za pomocą skali czasowej. Zdarzenia takie jak
wysterowanie tablicy informacyjnej w określonym czasie są przedstawione w kalendarzu
graficznie, odpowiednio do czasu ich trwania. Istnieją przy tym róŜne moŜliwości filtracji,
pozwalające uzyskać przejrzysty wybór zdarzeń, które naleŜy przedstawić albo utworzyć.
Kalendarz zdarzeń umoŜliwia udostępnienie odpowiednich informacji innym podsystemom.
System SITRAFFIC SCALA/CONCERT oferuje moŜliwość sterowania tablicami
informacyjnymi itp. w funkcji czasu oraz poprzez automatykę roczną na bazie kalendarza
rocznego, z uwzględnieniem róŜnych typów dni (dzień tygodnia, dni świąteczne, dni
urlopowe i specjalne). Wszystkie układy logiczne systemu sterowania posiadają w
systemie funkcję kalendarza, umoŜliwiającą włączanie wstępnie zdefiniowanych strategii w
zaleŜności od pory dnia lub daty. Do zdefiniowania specjalnych typów dni jest do
dyspozycji odpowiednie okno dialogowe. Tutaj moŜna ustalić typy dni: dla określonego
terminu (np. dzień świąteczny w całym kraju), dla określonego przedziału czasu (np. ferie
szkolne), jako określony dzień tygodnia (poniedziałek, szczyt poranny) albo jako
powtarzający się co roku dzień świąteczny (np. święto kościelne).
System zdarzeń przetwarza zdarzenia systemowe i czasowe.
Wersja 4.0
79/192
7.1.2. Wymagania dla planów czasowych
Czas startu: podaje czas rzeczywisty, w którym powinno zostać uruchomione zadanie. Dni,
w których ma to nastąpić, są ustalone w następnych danych.
Powtarzanie: ustala wzorzec powtarzalności, wg którego zadanie ma być powtórnie
uruchomione. MoŜe to następować jednorazowo, codziennie, co tydzień albo co miesiąc.
Dla kaŜdego wzorca obowiązują oddzielne parametry.
Jednorazowo: wskazanie powinno zostać uruchomione tylko w określonym dniu, na
określony czas.
Codziennie: zadanie powinno być powtarzane przez „n“ dni.
Co tydzień
powtórz zadanie przez „n“ tygodni albo
powtórz zadanie w wybranych dniach tygodnia (np. co poniedziałek)
Co miesiąc
powtórz zadanie kaŜdego „n-tego“ dnia miesiąca albo
powtórz zadanie kaŜdego 1-5 tygodnia w miesiącu, w jednym albo w kilku
określonych dniach tygodnia.
Dodatkowo mogą być wybierane miesiące.
Data rozpoczęcia i zakończenia: dla wszystkich wzorców powtórzeń musi być podana data
startu. Opcjonalnie moŜna równieŜ podać datę zakończenia, w przeciwnym wypadku
zadanie będzie wciąŜ powtarzane.
Powtarzanie w ciągu dnia:jeŜeli zadanie zostało uruchomione, wówczas moŜe być
powtarzane w ciągu dnia z następującymi parametrami (aŜ do osiągnięcia określonego
czasu):
powtarzanie co „n“ minut albo
powtarzanie co „n“ godzin
Powtarzanie w dniach określonego typu: zdarzenia czasowe mają następować równieŜ w
dniach ustalonych przez typ dzienny komponentów linii wahań natęŜenia ruchu.
Definicje typów dni mogą być wyeksportowane po kaŜdej zmianie jako pliki *.pdf albo *.xml
i tym samym mogą być wymieniane z podsystemami.
Wersja 4.0
7.2.
80/192
Wybór programu sygnalizacji (TASS) w zaleŜności od
warunków ruchu
Układ sterowania strategicznego VSR (system sterujący ruchem) ma dostęp do wszystkich
danych znajdujących się w systemie sterowania ruchem i moŜe zrealizować, przez tzw.
strategie (składające się z kroków), dowolne reakcje w ramach systemu sterowania (patrz
rozdział 6). NaleŜy do tego – w zaleŜności od warunków technicznych i kaŜdorazowego
projektu – zaleŜny od ruchu program sygnalizacji akomodacyjnych.
Wybór programów sygnalizacji akomodacyjnych moŜe zostać zastosowany przy realizacji
następujących zadań:
Wybór programów sygnalizacji odpowiadających chwilowemu ruchowi
Aktywacja w przypadku specjalnych warunków komunikacyjnych reakcji
przewidzianych przez inzyniera ruchu, jak np.:
zdławienie ruchu na określonych skrzyŜowaniach;
otwarcie lub zablokowanie dla ruchu indywidualnego specjalnych pasów
ruchu przewidzianych dla komunikacji publicznej;
zmiana obszarów lokalnej modyfikacji programów sygnalizacji świetlnej
w sterownikach akomodacyjnych znajdujących się w węzłach
komunikacyjnych.
Wybór programu sygnalizacji w zaleŜności od ruchu steruje na poziomach hierarchii:
Rozpoznanie sytuacji
= poziom strategii dla obszaru
Wybór programu sygnalizacji = poziom taktyczny dla danego obszaru
Na poziomie strategicznym określa się aktualną sytuację komunikacyjną. Dla kaŜdej
sytuacji powinien istnieć przypisany dla kaŜdego skrzyŜowania, co najmniej 1
(podstawowy) program sygnalizacji, odpowiadającej charakterowi sytuacji (jednakowa
długość cyklu sygnalizacji, określony kierunek koordynacji itd.)
Na poziomie taktycznym zostaje wybrany dla obszaru program sygnalizacji uzaleŜniony od
aktualnie występującej tam strategii.
Na płaszczyźnie sterowania powinna istnieć moŜliwość względnie szybkiego reagowania
na wahania ruchu w róŜnych częściach obszaru. Dokonuje się tego przez przełączenie na
tzw. alternatywne programy sygnalizacji, których charakterystyki (długość cyklu
sygnalizacji, koordynacja) powinny odpowiadać charakterystykom programu sygnalizacji
podstawowej. Dzięki temu uniknie się zakłóceń w przebiegu ruchu przez częstą zmianę
programu sygnalizacji.
7.2.1. Zmiana sytuacji i zmiana programu sygnalizacji
Na podstawie dowolnych, zmierzonych parametrów ruchu określa się zmianę strategii i
przekazuje te zmiany do systemu.
Przejście do nowej sytuacji, obwarowane jest następującymi warunkami.
Licznik zmian przy danej strategii musi być większy niŜ aktualnie wprowadzony.
Upłynął czas zablokowania poprzedniej sytuacji.
Sytuacja docelowa nie jest zablokowana przez operatora.
Przyporządkowanie programu sygnalizacji do danych sytuacji następuje przez matrycę
zmian sytuacji. JeŜeli wszystkie wyŜej wymienione warunki są spełnione, wówczas na
podstawie matrycy decyzyjnej, następuje włączenie przewidzianej reakcji (zmiana w planie
sygnalizacji).
Wersja 4.0
81/192
7.2.2. Ekran obsługi
System posiada komfortowy ekran umoŜliwiający wprowadzanie wszystkich danych dla
funkcji logicznych pracujących w funkcji czasu. Konfiguracja ekranu przewidziana jest dla
personelu posiadającego wykształcenie w dziedzinie inŜynierii ruchu i nie wymaga
Ŝadnych specjalnych umiejętności w dziedzinie programowania.
Kreator ten umoŜliwia szybkie zdefiniowanie sytuacji i zmian sytuacji. Rozwiązanie strategii
w systemie jest moŜliwe, przez przyporządkowanie reakcji do określonych warunków.
Ekran z rysunku 7.1 definiuje strategię w obszarze grupy:
Rysunek 7.1: Ekran obsługi SPA zaleŜnego od stanu ruchu
Objaśnienia do ekranu:
Last - obciąŜenie
Normal - stan normalny
Schneefall - opad śniegu
Wind - wiatr
Ein – włączony
Aus – wyłączony
Wunsch - Ŝyczenie
Przy wgrywaniu danych wprowadza się i wyświetla zdefiniowane strategie i stany.
Kolumny „Bezeichnung“ (nazwa) i „Manuell gesperrt“ (blokada ręczna) (przejście od
sytuacji docelowej nie jest moŜliwe) moŜna edytować.
Reakcje mogą zostać przydzielone do wybranego wiersza przez ComboBox „Aktion
zuweisen“ (przydzielenie reakcji), na podstawie wstępnie zdefiniowanych komend
grupowych.
Wersja 4.0
82/192
Przyciski na ekranie, umieszczone w panelu „Situation setzen“ (wprowadzanie strategii),
mają następujące działanie:
ręczne wprowadzanie Ŝądanej sytuacji ( przycisk „mit Übergang” (z
przejściem))
ręczne wprowadzanie aktualnej sytuacji (przycisk: Sofort (natychmiast))
Przyciski w panelu „Situation“ (sytuacja) powodują:
wprowadzanie sytuacji (przycisk: Hinzufügen (wstaw))
usuwanie sytuacji (przycisk: Entfernen (usuń))
Zapisywanie powoduje automatyczne zrównanie z planem reakcji.
Na rysunku 7.2 przedstawiono ekran, który definiuje przejścia sytuacji, tzn. matrycę zmian
strategii (przejście z poprzedniego ekranu za pomocą przycisku “Bearbeiten” (obróbka):
Rysunek 7.2: Przykład ekranu „Matryca zmian strategii” – przykład z Centrum Zarządzania w
Berlinie
Na ekranie z rysunku 7.2 konfiguruje się całą matrycę zmian strategii.
Zapisanie powoduje automatyczne zrównanie z zarządzaniem planem reakcji.
Kolumna „Stand“ (Tendenzzähler) (stan - licznik zmian) informuje o aktualnym stanie
licznika zmian. Kolumna „Sperrzeit“ (czas blokady) przedstawia aktualnie nastawiony czas
blokady, powodujący zatrzymanie zmiany strategii. Czasy te zapobiegają zbyt szybkim
zmianom strategii/programów sygnalizacji.
Za pomocą przycisków na pulpicie moŜna włączać i wyłączać wybór programu sygnalizacji
dla poszczególnych grup, uzaleŜniony od wielkości ruchu.
7.2.3. MoŜliwości testowania
WdroŜenie planowania jest wspomagane przez funkcje testowe offline i online.
Wersja 4.0
83/192
7.2.4. Tworzenie komunikatów
Załączenia spowodowane przez wybór programu sygnalizacji, uzaleŜniony od natęŜenia
ruchu, powodują wysłanie komunikatów, które są archiwizowane. Na podstawie tego
komunikatu moŜna ustalić, czy spełniony został warunek załączenia (wybór
akomodacyjnego programu sygnalizacji).
7.2.5. Sterowanie centralne i zdecentralizowane
UzaleŜniony od natęŜenia ruchu wybór programów sygnalizacji nadaje się zarówno do
centralnego sterowania zdalnego sterowania sygnalizacją świetlną, jak równieŜ do
sterowania zdecentralizowanego.
W przypadku sterowania zdecentralizowanego następuje automatyczne pobranie
programu sygnalizacji do sterownika (wybrany program sygnalizacji nie występuje w
programie sterowania).
7.2.6. Ręczne wprowadzanie sytuacji
Wprowadzanie Ŝądanej sytuacji (licznik zmian i czas zablokowania są uwzględniane) jest
moŜliwe za pomocą ekranu obsługi.
Ręczne wprowadzanie aktualnej sytuacji (licznik zmian i czas zablokowania nie są
uwzględniane) jest równieŜ moŜliwe.
7.2.7. Realizacja
Realizacja funkcji logicznych, związanych z algorytmem sterowania ruchem, moŜe być
wdroŜona za pomocą Stramo albo planów reakcji.
Funkcje logiczne planów reakcji:
-
mogą zostać w kaŜdej chwili bardzo łatwo dopasowane przez „normalnego“
pracownika obsługi;
posiadają powiązania łańcuchowe I, ALBO oraz NEGACJA, o dowolnej
głębokości zagnieŜdŜania;
w przypadku zmiany wielkości wejściowej następuje zmiana reakcji.
Stramo ma moŜliwość:
-
7.3.
posiadania funkcjonalnie połączonych składników;
pracy cyklicznej;
poddania testowi offline.
Adaptacyjne sterowanie sieciowe (MOTION)
7.3.1. Koncepcja adaptacyjnego układu sterowania
Istotnym zadaniem sterowania sieciowego jest określenie warunków ruchu i przygotowanie
informacji w systemie sterowania o:
NatęŜeniu ruchu (o ile nie moŜna ich zmierzyć);
Długości zatorów, czasach oczekiwania, czasach przejazdu;
Poziomie obsługi (Level of Service - LOS);
Zakłóceniach.
Wersja 4.0
84/192
Przez uwzględnienie otrzymanych komunikatów o zakłóceniach i komunikatów specjalnych
oraz dzięki zintegrowanej kontroli prawidłowości, rozpoznaje się detektory wadliwie
działające albo uszkodzone i stosuje się odpowiednie wartości zastępcze. W zaleŜności od
usterki, wartości zastępcze mogą zostać określone np. przez wybór alternatywnego
detektora, przez korelację z sąsiednimi detektorami albo na podstawie znajdujących się w
pamięci wahań natęŜenia ruchu. Drugim, istotnym zadaniem adaptacyjnego sterowania
sieciowego jest optymalne dostosowanie podłączonych sygnalizacji świetlnych do
określonego stanu ruchu. W tym celu poddaje się optymalizacji zwykle stosowane
wielkości sterownicze:
kolejność faz,
udział światła zielonego,
offsety,
długość cyklu sygnalizacji grup na skrzyŜowaniach.
Odbywa się to samoczynnie i przy uwzględnieniu załoŜeń zarządzania strategicznego, jak
np.
dozwolone kolejności faz i programy sygnalizacji,
obszary dozwolone dla parametrów optymalizowanych,
hierarchia funkcji docelowych.
Parametry funkcji docelowych mogą być przy tym modyfikowane online.
7.3.2. Rejestracja stanu ruchu
Rejestracja stanu ruchu jest centralnym składnikiem kaŜdego adaptacyjnego sterowania
sieciowego. Jakość zastosowanych algorytmów moŜna ocenić po tym, jak dokładne informacje
o stanie ruchu, odnoszące się do odcinka albo sieci, są uzyskiwane z urządzeń pomiarowych (z
reguły lokalnych). W MOTION zastosowano do tego celu nowoczesne algorytmy, które
przeprowadzają analizę sygnałów pomiarowych. Nadają się one zwłaszcza do zastosowania z
detektorami umieszczonymi w pobliŜu linii zatrzymania pojazdów na jezdni.
Centralna metoda szacuje występującą wielkość odciąŜenia ruchu w kierunku bocznym.
Lokalne szacowanie natęŜenia dostarcza wszystkich informacji, koniecznych do
optymalizowania koordynacji. Zastosowanie tradycyjnych kombinacji, pochodzących z
szacowania źródła i celu oraz rozkładu (zwykle statystycznych) staje się tym samym
bezprzedmiotowe, gdyŜ odpowiednie moduły nie są juŜ stosowane w sterowaniu
sieciowym. W aspekcie rysującej się jakości nowych metod stanowi to jednocześnie
poprawę osiągów i jakości sterowania sieciowego.
W połączeniu z wielkością odciąŜenia przez ruch w kierunku bocznym moŜna
bezzwłocznie oszacować, przez bilansowanie dopływów i odpływów, długości zatorów na
całym odcinku trasy. Oszacowania te są poddawane ciągłej regulacji przez procedury
korekcyjne.
Ponadto ocenia się natęŜenie ruchu odpowiadające stopniowi nasycenia i stopnie
wykorzystania wszystkich sygnalizacji świetlnych, poddaje się je optymalizacji oraz
udostępnia się inne aplikacje sytemu sterowania.
Wykrywane jest równieŜ wystąpienie oraz poziom istotności zakłóceń. Dzięki nowej
metodzie zastosowanej w MOTION następuje znacznie dokładniejsze oszacowanie czasu
przejazdu w przypadku zakłóceń ruchu, niŜ umoŜliwiały to dotychczasowe rozwiązania
techniczne.
Algorytmy do szacowania pracują w sposób umoŜliwiający integrację wartości
pochodzących z nowoczesnych metod pomiarowych, w sensie fuzji. JeŜeli w systemie
zarządzania ruchem występują dane FCD albo Wideo, wówczas moŜna je zintegrować z
rejestracją stanu bez „algorytmicznego przekształcenia”.
Wersja 4.0
85/192
7.3.3. Ogólna koncepcja dynamicznej „zielonej“ fali
Dynamizacja „zielonych fal“ na poziomie taktycznym odgrywa w MOTION waŜną rolę. Z
wymagań dotychczasowych projektów i w ramach aktualnych rozszerzeń powstała metoda
odpowiadająca aktualnemu stanowi techniki, dzięki analizie danych pomiarowych i
modelowaniu przebiegu ruchu. Jednocześnie metoda ta dostarcza moŜliwości konfiguracji,
pozwalających na uwzględnienie tradycyjnych zasad projektowania, równieŜ w
adaptacyjnym sterowaniu sieciowym.
Moduł rejestracji stanu ruchu w sterowaniu sieciowym MOTION dostarcza - oprócz
oszacowania niemierzalnych natęŜeń ruchu - innych informacji, istotnych dla dynamicznej
optymalizacji „zielonych fal“.
Dokładne oszacowanie natęŜenia ruchu kierunków bocznych pozwala na dokładne,
dynamiczne uszeregowanie zaleŜności koordynacyjnych wg stopnia waŜności, na
podstawie obciąŜeń strumieni ruchu. Uprzywilejowane strumienie odciąŜające w
kierunku bocznym mogą być rozpoznawane automatycznie.
Bezzwłoczne oszacowanie dowolnie długich zatorów i wynikających z tego czasów
przejazdów (moŜna oszacować równieŜ znacznie zwiększone czasy przejazdów
spowodowane zakłóceniami) umoŜliwia optymalne uwzględnienie juŜ znajdujących
się w ruchu pojazdów, przy określeniu czasu przesunięcia i pozwala (takŜe w
przypadku przeciąŜenia) na uniknięcie niepotrzebnych zatrzymań (progresja
ujemna).
Oferowany układ sterowania sieciowego MOTION charakteryzuje się róŜnymi
moŜliwościami konfiguracji, gwarantującymi przekształcenie Ŝyczeń klientów w
dynamiczną „zieloną falę“.
ZałoŜenie stałych offsetów, odniesionych do początku albo końca zielonego
światła.
ZałoŜenie dozwolonych zakresów offsetów.
Akceptacja określonej kolejności faz z moŜliwością ograniczenia do określonych
sytuacji, pór dnia albo długości cyklu sygnalizacji.
ZałoŜenie własnego stopnia waŜności czasów oczekiwania i zatrzymania,
zwłaszcza do optymalizacji offsetów.
MoŜliwe jest wprowadzenie tras, na których znajdują się poddawane optymalizacji
„zielone fale”.
W eksploatacji MOTION posiada następujące moŜliwości (o ile wymaga tego
konfiguracja):
ustalanie priorytetów strumieni ruchu i natęŜenia kierunków bocznych, na
podstawie mierzonych/szacowanych obciąŜeń (patrz wyŜej);
zalecanie najkorzystniejszej kolejności faz;
uwzględnienie znajdujących się w ruchu pojazdów (patrz wyŜej) równieŜ przy
przeciąŜeniu;
minimalizacja liczby zatrzymań przez progresję ujemną, o ile to konieczne.
Przy ustalaniu połoŜenia fali MOTION nie jest ograniczony przy wyborze długości cyklu
programu sygnalizacji przez stałe punkty czasowe. Cały przebieg planu sygnalizacji moŜe
być przesuwany w obszarze długości cyklu programu sygnalizacji.
Wersja 4.0
86/192
7.3.4. Rozpoznawanie zakłóceń
Sterowanie sieciowe posiada moduł rozpoznawania zakłóceń.
7.3.5. Stanowisko zasilania i obsługi
Stanowisko zasilania i obsługi sterowania sieciowego jest zainstalowane na serwerach
Client sterowania sieciowego i komputerze systemu sterującego ruchem (serwer
sterowania sieciowego).
7.4.
Trasy pojazdów słuŜb ratowniczych
Za pomocą trasy pojazdów słuŜb ratowniczych (EFR - EinsatzFahrzeugRouten) mogą być
otwierane drogi przejazdu dla tego rodzaju pojazdów (straŜ poŜarna itp.).
Rysunek 7.3: Przykład wizualizacji tras przejazdu pojazdów słuŜb ratowniczych - przykład z
Centrum Zarządzania w Berlinie
Czasy od [s] do [s] oznaczają początek i koniec fazy zielonego światła, w odniesieniu do
momentu aktywacji. RóŜne trasy pojazdów słuŜb miejskich mogą zostać zdefiniowane
przez selekcję sygnalizacji świetlnej z ekranu systemu informacji geograficznej (GIS) albo
z widoku list (decydująca jest kolejność selekcji).
Wersja 4.0
87/192
Z widoków GIS lub list moŜna bezpośrednio przełączyć się na kreator EFR. Wybrane
sygnalizacje świetle zostają przejęte odpowiednio do ich kolejności selekcji przez kreator
EFR (przykładowy widok okna kreatora EFR przedstawionona rysunku 7.4). MoŜna
wprowadzać inne sygnalizacje świetlane, a juŜ wprowadzone moŜna kasować.
Rysunek 7.4: Kreator EFR
Element
Tabele reakcji
ID
LSA Name
LSA Kurzname
Verzögerung
Gerätesteuerung
Opis
Identyfikacja reakcji
Nazwa urządzenia sygnalizacji świetlnej
Skrót nazwy urządzenia sygnalizacji świetlnej
Offset planów reakcji
Tekstowe streszczenie dialogu z układem sterowania urządzenia
Przyciski do obsługi reakcji na ekranie
Bearbeiten
Po naciśnięciu przycisku „Bearbeiten“ ukazuje się dialog związany z
wprowadzaniem danych do urządzenia,
Wskazówka: ramka wybór urządzenia sygnalizacji świetlnej (LSA
Auswahl) nie ukazuje się przy wywołaniu programu sterowania z
widoku szczegółowego sterownika sygnalizacji świetnej.
Hinzufügen
Wprowadzenie nowej reakcji przez dialog polegający na wprowadzaniu
danych do urządzenia,
Löschen
Kasowanie wybranej reakcji.
Auf /Ab
Zmiana kolejności wykonywania reakcji.
Dane na temat
planu reakcji
Aktionsplan ID
Aktionsplan Name:
Gdy plan reakcji zostanie załadowany, zapisany albo zapisany na
nowo, wówczas zostaje wyświetlony identyfikator planu reakcji.
Identyfikator wskazuje na juŜ istniejący plan reakcji, przyciski
„Löschen“ i „Starten“ są aktywne.
Nazwa posiada wprowadzoną pierwsza i ostatnią skrótową nazwę
sterownika sygnalizacji świetlnej. Wprowadzenie zmiany jest moŜliwe.
Wersja 4.0
Przyciski planu
akcji na ekranie
Speichern
Speichern als neu
Laden
Löschen
Starten
88/192
Opracowanie albo nadpisanie istniejącego planu reakcji. Wskazania
przydzielonego identyfikacji planu reakcji (Aktionsplan ID).
Zapisanie duplikatu planu reakcji
Ładowanie planu reakcji (zostaje wyświetlona lista planów reakcji z
kategorii LSA EFR Route) sterownika sygnalizacji świetlnej na trasie
przejazdu pojazdów słuŜb ratowniczych.
Kasowanie planu reakcji (musi być wyświetlony Aktionsplan ID)
Uruchamianie planu reakcji (musi być wyświetlony Aktionsplan ID).
JeŜeli plan akcji uległ poprzednio zmianie, wówczas wyświetlane jest
pytanie ostrzegawcze, czy uprzednio zapisany ma pozostać. Przycisk
startowy nie wprowadza automatycznie zmian przy uruchamianiu
(wywołanie następuje przez TSC-Invoke).
Za pomocą kreatora EFR dla kaŜdego urządzenia sygnalizacji świetlnej moŜna utworzyć
akcję w ramach planu reakcji. Opóźnienie załączania jest przejmowane jako offset.
Plan reakcji zawiera jako kategorię wartość „sterowniki sygnalizacji świetlnej na trasie
pojazdów słuŜb ratowniczych” („LSA EFR Route“) i nazwę, którą powinien zdefiniować
operator. Poszczególne zapisane reakcje zawierają jako opcję tekst skróconej nazwy i
skróconą nazwę sterownika sygnalizacji świetnej.
Kreator oferuje następujące moŜliwości:
tworzenie planu reakcji (sterowanie trasą przejazdu słuŜb ratowniczych);
edycja niŜej podanych parametrów dla kaŜdego urządzenia sygnalizacji świetlnej;
rozpoczęcie utworzonego planu reakcji;
kasowanie planu reakcji;
moŜliwość stopniowania treści poszczególnych załączeń (moŜliwość kopiowania
wierszami);
załadowanie istniejącego planu reakcji w celu późniejszej edycji (z odpowiednią
kategorią);
Przez dialog z układem sterowania dla kaŜdego sterownika sygnalizacji świetlnej moŜna
wprowadzić:
offsety,
czas trwania sygnału zielonego,
włączenie/wyłączenie HK,
Program sygnalizacji, tryb załączenia,
przyczynę załączenia.
Wersja 4.0
89/192
Do zaakceptowania i ręcznego wykonania poszczególnych reakcji uŜywany jest ekran jak
na rysunku 7.5:
Rysunek 7.5: Tryb wykonawczy
Spalte
State
ID
Type
Description
Execute
Confirm
Offset
Time Left
Opis
Stan reakcji: ukończona pomyślnie, w trakcie realizacji
Identyfikacja reakcji
Typ reakcji
Opis reakcji
Wstępne ustawienia są przejmowane z dialogu startowego i mogą zostać
jeszcze zmienione.
JeŜeli nie jest aktywowane, wówczas reakcja uruchamia się
automatycznie po upływie podanego offsetu. JeŜeli jest aktywowana,
wówczas po upływie offsetu ukazuje się pytanie o potwierdzenie
realizacji.
Offset ustawień moŜe być wprowadzany bezpośrednio do tabeli. Za
pomocą przycisków umieszczonych z prawej strony tabeli moŜna
dodawać lub odejmować offset wybranych wierszy w krokach 10, 20 i 60
sekundowych.
Na początku aktywacji reakcji czas offsetu zostaje przejęty do kolumny
„Time Left“. Od tego momentu rozpoczyna się odliczanie wsteczne.
Zmiany w offsecie są przenoszone do kolumny „Time Left“.
Odliczanie wsteczne odbywa się w krokach 5-sekundowych.
Start now uruchamia wybraną reakcję natychmiast, niezaleŜnie od offsetu i właśnie
realizowanej reakcji.
Przycisk Continue powoduje bezpośrednie wykonanie reakcji.
Cancel Plan przerywa cały plan reakcji.
Wersja 4.0
90/192
8.
Wizualizacja
8.1.
MoŜliwość konfigurowania widoków na ekranie
Widoki na ekranie moŜna w duŜym zakresie konfigurować. Parametry istotne dla widoków
uzyskiwanych z systemu informacji geograficznej (GIS) są przykładowo konfigurowane za
pomocą programu narzędziowego GisConfig. MoŜna zarówno dodawać nowe kategorie,
jak teŜ dowolnie definiować grupy lub obiekty przedstawiane w ramach grup. W ten sposób
widoki na ekranie moŜna dostosowywać do wymagań uŜytkownika
8.2.
Obsługa systemu na podstawie mapy
8.2.1. GIS oparty na układzie warstwowym
Monitor eksploatacyjny oparty na mapie wykorzystuje tzw. wizualizację GIS (Geographical
Information System), która umoŜliwia graficzne przedstawianie obiektów znajdujących się
w bazie danych, na podstawie przyporządkowania geograficznego na mapie. Podstawę
danych dla GIS stanowią stosowane formaty map cyfrowych, jak np. format MapInfo.
Wizualizacja jest zorganizowana w wielu warstwach statycznych i dynamicznych. Warstwy
statyczne są to poziomy, których treść nie zmienia się albo zmienia się bardzo rzadko, jak
np. topografia miasta albo sieć ulic. Warstwy statyczne mogą zostać dopasowane przez
uŜytkownika w zewnętrznych programach edycyjnych (np. definicja warstw). Warstwy
dynamiczne są warstwami specyficznymi dla typów obiektów, których treść zmienia się w
czasie, jak np. stan ruchu albo stan eksploatacyjny sterowników sygnalizacji świetlnej.
Warstwę dynamiczną uŜytkownik moŜe komfortowo skonfigurować online w systemie
zarządzania ruchem, w ramach wyglądu ekranu obsługi. Warstwy dynamiczne zawierają
przystosowane do klikania linki do wyświetlanych w nich obiektów z bazy danych.
Typowymi warstwami zdefiniowanymi w systemie są:
Mapa podstawowa
Roboty drogowe
Stan ruchu
Ulice
Punkty
pomiarowe/detektory
Zakłócenia/komunikaty
Sekcje/rejony
Parkingi
Sensory meteorologiczne
Lokalizacja pojazdów
Prognoza ruchu
Detekcja lokalna
Urządzenia sygnalizacji
świetlnej
Trasy
Przystanki komunikacji
(objazdy/doprowadzenia) miejskiej
Lokalizacja kamer
Tablice informacyjne
Trasy przejazdu
komunikacji publicznej
(fragmenty odcinków dla
komunikacji miejskiej)
Wprowadzona do systemu kolejność warstw określa równieŜ kolejność wyświetlania
dynamicznych obiektów z bazy danych. Obiekty te, zlokalizowane w przestrzennie
podobnych miejscach w GIS, mogą się więc przy określonych stopniach zoom-u
ewentualnie nakładać na siebie (zgodnie z ustaloną w systemie kolejnością warstw).
RóŜne warstwy (i wyświetlane tym samym typy obiektów) mogą być przez pracownika
Wersja 4.0
91/192
obsługi selektywnie wprowadzane i usuwane. Przykładowe okno wizualizacji
przedstawiono na rysunku 8.1.
Rysunek 8.1: Przykładowe okno wizualizacji - przykład z Centrum Zarządzania w Berlinie
8.2.2. Zachowywanie danych GIS
Mapa cyfrowa jest przechowywana w odpowiedniej bazie, z moŜliwością aktualizacji.
Obiekty statyczne i dynamiczne są przyporządkowywane do mapy. KaŜdemu obiektowi
przyporządkowywane są co najmniej współrzędne, częściowo równieŜ przyporządkowanie
do fragmentu odcinka drogi. Fragmenty odcinków na pierwotnej mapie mogą być
wyświetlane na ekranie obsługi w odcinki nadrzędne i mogą być traktowane w systemie
jako obiekty samodzielne. Odcinki mogą być następnie łączone w trasy. Trasom moŜna
przypisywać róŜne atrybuty, jak np. trasa komunikacji miejskiej, trasa pojazdów słuŜb
ratowniczych itp.
8.2.3. Wizualizacja obiektów
Obiekty dynamiczne na mapie sieciowej są przedstawione za pomocą ikon i posiadają
kolor odpowiadający ich aktualnemu stanowi eksploatacyjnemu. System zawiera
standardowy zestaw ikon dla róŜnych typów obiektów. Ikony te mogą zostać jednak
zasadniczo ustalone równieŜ przez uŜytkownika. Kolory tła ikon mają za zadanie
przekazać szybką informacje o tym, czy urządzenie działa i czy występują ewentualnie
zakłócenia. PoniŜej przedstawiono przykładowo symbole detektorów, sterowników
sygnalizacji świetlnej na skrzyŜowaniach, robót drogowych oraz fragmentów odcinków
dróg.
Wersja 4.0
92/192
Symbole punktów pomiarowych i detektorów składają się z następujących elementów:
Rysunek 8.2: Elementy symboli punktów pomiarowych i detektorów
Objaśnienia do schematu:
Belastungsgrad – stopień natęŜenia
Verkehrssituation – sytuacja drogowa
Betriebsstatus – stan eksploatacyjny
Messtellensymbol – symbol punktu pomiarowego
Messstellenbezeichnung – nazwa punktu pomiarowego
Tło symbolu moŜe przy tym mieć 5 róŜnych kolorów, oznaczających stan eksploatacyjny
obiektu:
= stan obiektu nieznany
= obiekt jest offline
= obiekt podlega zakłóceniu
= obiekt częściowo podlega zakłóceniu
= obiekt pracuje prawidłowo
Pole wskazań sytuacji komunikacyjnej na punktach pomiarowych moŜe przyjmować
następujące barwy (wyświetlane opcjonalnie, moŜliwość aktywacji do 5 stopni):
= ruch spowolniony
= ruch w niewielkim stopniu spowolniony
= zator
= stan krytyczny/ruch spowolniony
= przejazd swobodny
Wskazania stopnia swobody ruchu ulicznego odzwierciedlają nasycenie odcinka ulicy w
punkcie pomiarowym (wyświetlane opcjonalnie).
SkrzyŜowania są przedstawiane w sposób następujący:
Wersja 4.0
93/192
Rysunek 8.3: Przykład wizualizacji skrzyŜowań
LSA-Symbol – symbol LSA
Betriebsstatus – stan eksploatacyjny
Signalplan – plan sygnalizacyjny
Knotenbezeichnung – nazwa węzła (skrzyŜowania)
Hinterlegte Notitz – dodana notatka
Kolory tła ikon mogą być następujące:
= stan eksploatacyjny nieznany
= sterownik sygnalizacji świetlnej jest offline
= występuje powaŜna usterka, np. przerwanie komunikacji
= komunikat alarmowy, np. przepalenie się lampy czerwonej
= ostrzeŜenie, występuje usterka, sterownik jeszcze pracuje
= sterownik sygnalizacji świetlnej pracuje prawidłowo
Za pomocą widoku szczegółowego (dostępnego przez menu kontekstu, po kliknięciu
prawym przyciskiem myszy na symbol obiektu) istnieje moŜliwość dodawania notatek do
kaŜdego skrzyŜowania. JeŜeli węzeł jest wyposaŜony w notatkę, wówczas w lewym
górnym naroŜniku symbolu obiektu ukazuje się zielone oznaczenie. Dodatkowo moŜe
zostać opcjonalnie wyświetlony aktualny numer programu sygnalizacji z ikoną.
Roboty drogowe i imprezy (opcja) są wyświetlane w postaci symbolu. Opcjonalnie moŜe
być równieŜ wyświetlony na siatce ulic rozmiar robót lub imprezy.
Rysunek 8.4: Przykład wizualizacji opcji „Roboty drogowe i imprezy”
Wersja 4.0
94/192
Baustellenausdehnung – obszar robót drogowych
Baustellensymbol – symbol miejsca robót drogowych
Baustellenbezeichnung – nazwa miejsca robót drogowych
Baustellenstatus – status prowadzonych robót drogowych
Kolory symbolu i fragmentów odcinka trasy informują o aktualności zdarzenia. Znaczenie
kolorów jest następujące:
= nieznane
= w przyszłości
= przerwane
= aktywne
= zakończone
= nie zweryfikowane
Zakłócenia są zawsze przedstawiane wyłączne w kolorze CZERWONYM i nie mogą
przyjmować stanów poprzednich.
Fragmenty odcinków posiadają kolory odpowiadające ich poziom obsługi (Level of
Service - LOS) (informacje na temat czasu przejazdu znajdują się na widoku
szczegółowym).
Rysunek 8.5: Przedstawienie sytuacji komunikacyjnej w GIS
Na kontrolowanych fragmentach odcinków są umieszczane zaleŜne od kierunku linie.
Posiadają one następujące kolory (moŜliwość aktywacji do 5 stopni):
= zator
= stan krytyczny/ruch spowolniony
= przejazd swobodny
= przejazd nieco spowolniony
= przejazd znacznie spowolniony
Definicja przestrzennego połoŜenia wszystkich fragmentów odcinków jest przedstawiona
przez sieć L&D.
Wersja 4.0
95/192
Zakłócenia
Obiekty posiadające inny status eksploatacyjny niŜ „nieznany“ i „OK“ są wyświetlane na
GIS najpierw w sposób migający, aby ściągnąć na siebie uwagę pracownika obsługi. MoŜe
on następnie wprowadzić wykazujący zakłócenia obiekt do listy zakłóceń akceptowanych,
przez menu kontekstowe, po kliknięciu prawym przyciskiem myszy, po czym symbol
obiektu przestaje migać.
Pracownik obsługi moŜe dodatkowo wyświetlić za pomocą struktury nawigacyjnej wykaz
wszystkich obiektów wykazujących w danym momencie zakłócenia. Zostaje dokonany
podział na zakłócenia zaakceptowane i nie zaakceptowane.
Funkcja Tool Tip
Elementem składowym wizualizacji GIS jest funkcja przeznaczona dla dynamicznych
obiektów bazy danych. Po krótkotrwałym ustawieniu kursora myszy na danym obiekcie na
mapie GIS, ukazuje się ramka informacyjna, zawierająca wyciąg istotnych danych
dynamicznych.
Rysunek 8.6: Przykładowa ramka informacyjn obiektów na mapie GIS – przykład z Centrum
8.2.4. Funkcja zoom
GIS daje moŜliwość stosowania logicznego zoomu. W tym celu rozróŜnia się zwykle
następujące statyczne kategorie dróg.
• autostrady z mostami i tunelami
• drogi główne i boczne
W podstawowym ustawianiu mapy moŜna np. uwidocznić sieć autostrad, a wygasić sieć
podrzędnych dróg. Gdy mapa zostanie powiększona, wówczas pojawi się sieć dróg
podrzędnych, zawierająca drogi główne i boczne. Przy stosowaniu logicznego zoom-u
moŜna ustalić, od jakiej rozdzielczości mają być widoczne określone obiekty dynamiczne.
Sensowne jest np. aby juŜ w podstawowym połoŜeniu mapy operator posiadał ogólny
przegląd, nie przeładowany przy tym obiektami dynamicznymi. Z tego powodu dokonuje
się typowy dla systemu następujący podział warstw dynamicznych (definicja warstwy moŜe
być jednak zawsze dowolnie skonfigurowana).
1. Wraz z wyświetleniem autostrad zostają wyświetlone (przykładowo)
o
o
o
sytuacja komunikacyjna na fragmentów odcinków,
wypadki,
roboty drogowe.
Wersja 4.0
96/192
2. Wraz z wyświetleniem podrzędnej sieci dróg zostaną przykładowo wyświetlone
połoŜenia:
o
punktów pomiarowych/detektorów z podsystemów,
o
punktów pomiarowych urządzeń detektorowych,
o
kamer telewizji kablowej,
o
sterowników sygnalizacji świetlnej...
8.2.5. Wyszukiwanie w systemie GIS
W widoku sieci zintegrowana jest funkcja wyszukiwania, która umoŜliwia wyszukiwanie
obiektów w sieci. W tym celu wszystkie obiekty są wyszczególnione w widoku listy, z
pogrupowaniem wg typów obiektów. JeŜeli operator zaznaczy obiekt i następnie kliknie na
wyszukiwanie („Suchen“), wówczas funkcja ta przeszukuje mapę GIS. Przy znalezieniu
obiektu zostaje on przedstawiony w środku widoku i zaznaczony. UŜytkownik moŜe
nastawić Ŝądany stopień powiększenia i zidentyfikować otoczenie obiektu. Wyszukiwanie
obiektu jest moŜliwe dla wszystkich obiektów dynamicznych. Wyszukiwanie obiektów
statycznych jest moŜliwe w obszarze sieci ulic.
Za pomocą zintegrowanego okna dialogowego (wyszukiwanie) istnieje moŜliwość
ograniczenia wyszukiwania do określonych nazw obiektów. MoŜna np. wyszukiwać obiekty
bez wprowadzania kompletnej nazwy. Kryterium wyszukiwania pozwola na znalezienie
wszystkich obiektów, w których nazwie występuje wskazana kombinacja liter. Nie są
uwzględniane litery duŜe i małe.
8.2.6. Widoki zdefiniowane przez uŜytkownika
System SCALA/CONCERT daje moŜliwość zdefiniowania przez uŜytkownika widoków
uzyskiwanych w ramach wizualizacji i zapisywania ich. Istnieje moŜliwość zapisywania
konfiguracji GIS w zaleŜności od wyświetlonych warstw (typów obiektów), stopnia zoom-u i
połoŜenia na mapie. UmoŜliwia to wygodne ładowanie róŜnych, wstępnie zdefiniowanych,
widoków, jak np. grupowanie określonych typów obiektów w określonym rejonie mapy
cyfrowej.
8.2.7. Zapisywanie działań
System umoŜliwia rejestrację róŜnych, kolejnych czynności, jako działań (funkcja makro).
Za pomocą tej funkcji istnieje moŜliwość zdefiniowania działań w ramach zarządzania
strategicznego, w postaci wykonanych kolejno czynności, za pomocą ekranu obsługi
(przełączonego na makro). Moduł ten pozwala na zdefiniowanie akcji (środków) bez uŜycia
dodatkowego opisu.
8.3.
Stan rzeczywisty
Stan rzeczywisty informuje o aktualnym stanie skrzyŜowań i detektorów lub elementów
składowych systemu.
Wersja 4.0
97/192
8.3.1. Widok listy urządzeń sygnalizacji świetlnej (skrzyŜowań)
Wszystkie obiekty przedstawione w GIS mogą być przedstawione w formie tabeli. Do tego
celu uŜytkownik ma moŜliwość zaŜądania odpowiednich informacji o określonych typach
obiektów, przy wykorzystaniu paska nawigacji. Dla kaŜdego typu obiektu istnieje
moŜliwość otrzymania przeglądu wszystkich wprowadzonych do systemu obiektów.
Przegląd ten moŜna posortować wg typów i podtypów. Dla kaŜdego obiektu zostaną przy
tym przedstawione najwaŜniejsze informacje (jak stan, nazwa, zliczone wartości itp.).
Oprócz wyświetlonych list moŜliwe jest równieŜ uzyskanie zwartych przeglądów,
zawierających jedynie stan kaŜdego obiektu. Z obu tych przeglądów moŜna przejść do
widoku szczegółowego przez wybranie określonego obiektu. Przy wyświetlaniu list moŜna
zdefiniować dla kaŜdego typu obiektów maksymalną wyświetlaną liczbę kolumn. Spośród
wstępnie wprowadzonej ilości uŜytkownik moŜe wybrać istotne dla siebie dane i ustawić
szerokość wyświetlanego obrazu. Wyświetlaną listę moŜna sortować w kolumnach.
Wszystkie widoki list moŜna równieŜ wydrukować lub eksportować. W tym celu moŜna
przeprowadzić dla wybranego obiektu bezpośrednie wyszukiwanie przynaleŜnych
komunikatów eksploatacyjnych.
Rysunek 8.7: Widok listy urządzeń sygnalizacji świetlnej (skrzyŜowań)
Objaśnienia do ekranu powyŜej:
Flexiblen Sortier- und Autofilterfunktionen - Elastyczne funkcje sortowania i automatycznego
filtrowania
Details – Indos zur LSA ohne Bedienen - Szczegóły – informacja o LSA bez obsługi
Bedienen – Indos zur LSA mit Bedinen - Obsługa – informacja o LSA z obsługą
Details fur die angeklicte LSA (Blau hinterlegt) - Szczegóły dotyczące wybranego LSA
(podświetlone na niebiesko)
Przez wybranie np. obiektu w postaci sterownika sygnalizacji świetlnej moŜna wywołać
róŜne funkcje, jak np. widok szczegółowy urządzenia, dialog obsługowy urządzenia albo
wyszukiwanie GIS (pozycjonowanie mapy GIS i zaznaczenie wybranego urządzenia
sygnalizacji świetlnej).
8.3.2. Widok szczegółowy
Dla wszystkich obiektów moŜliwe jest uzyskanie widoków szczegółowych. Mogą być one
wywoływane z przeglądu list lub bezpośrednio z geograficznego systemu informacyjnego
przy selekcji odpowiedniego obiektu.
Wersja 4.0
98/192
Na widoku szczegółowym wyświetlane są dokładne informacje o przekazywanych w formie
tabeli wartościach dynamicznych obiektu i jego zasilaniu. W zaleŜności od tego, o jaki typ
obiektu chodzi, na róŜnych zakładkach plików są wyświetlane dynamicznie wszystkie
istotne informacje na temat wybranego obiektu. Dla sterowników sygnalizacji świetlnej są
to np. aktualnie włączony program sygnalizacji, połoŜenie urządzenia (współrzędne
geograficzne i odniesienie do ulic), parametryzacja i inne specyficzne uwagi na temat
obiektu. Sterowniki sygnalizacji świetlnej mogą być sterowane bezpośrednio z widoku
szczegółowego. Przykład okna widoku szczegółowego przedstawiono na rysunku 8.8.
Rysunek 8.8: Przykład okna widoku szczegółowego
Tłumaczenie objaśnień na zielonym polu:
Aufrufbar aus dem GIS und den Listenansichten - MoŜliwość wyświetlenia z GISu i widoków
pasków
Darstellung der Detailinformation der Iststände und weiteren Informationen separiert über diverse
Reiter - Przedstawienie szczegółowych informacji dotyczących stanu rzeczywistego i pozostałych
informacji w poszczególnych zakładkach
umfangreiche Statusinformation - Obszerne informacje na temat statusu
GIS-Suche - Wyszukiwanie w GIS
Aufrufobjektbezogene Archiv-Recherche - Przeszukiwanie archiwum pod kątem wyświetlanego
obiektu
Aufruf von knotenspezifischen Visualisierungen - Wyświetlenie wizualizacji dotyczącej danego
węzła (skrzyŜowania)
MoŜe to następować albo przez wprowadzenie bezpośrednich komend załączania albo
przez sterowanie czasowe (kalendarz). Na widoku szczegółowym dostarczane są szersze
informacje dla punktów pomiarowych. Jako dane dynamiczne są tutaj wprowadzone
aktualnie zliczone wartości. Mogą zostać wybrane i wyświetlone aktualne i historyczne
wyniki zliczania. Oprócz tego moŜe być przedstawiona i sparametryzowana graficznie
sytuacja komunikacyjna przyporządkowana przekrojowi pomiarowemu. Poza tym istnieje
moŜliwość dodania fotografii do obiektu (w stosowanym formacie rastra).
Z widoku szczegółowego moŜna dokonać lokalizacji obiektu w GIS oraz - podobnie jak
przy wyświetlaniu list - równieŜ tutaj moŜna wybrać do wizualizacji albo do eksportu
specyficzne komunikaty eksploatacyjne obiektu.
Wersja 4.0
8.3.3
99/192
Widok szczegółowy sterowników sygnalizacji świetlnej
Widok szczegółowy sterowników sygnalizacji świetlnej przedstawia wszystkie statyczne i
dynamiczne informacje o skrzyŜowaniu. Informacje mogą być posortowane wg obszarów
tematycznych (stan rzeczywisty, dane stałe, detektory, przynaleŜność do grupy, połoŜenie,
redakcja, serwis) i wywoływane za pomocą zakładek.
Zakładka „stan rzeczywisty“
Wyświetlane są tutaj wszystkie dynamiczne informacje, jak np. poziom sterowania,
charakterystyka centrali, stan sterownika, stany eksploatacyjne i stany usterek.
Przykładowe okno zakładki „stan rzeczywisty” przedstawiono na rysunku 8.9.
Rysunek 8.9: Przykładowe okno zakładki „stan rzeczywisty” – przykład z Centrum
Zakładka „dane stałe“
Zakładka dostarcza informacji statycznych, jak np. istniejące plany sygnalizacji, typ
sterownika sygnalizacji świetlnej, producent, rodzaj komunikacji i inne informacje opisowe.
Przykładowe okno zakładki „dane stałe” przedstawiono na rysunku 8.10.
Wersja 4.0
100/192
Rysunek 8.10: Przykładowe okno zakładki „dane stałe” – przykład z Centrum Zarządzania w
Berlinie
Wersja 4.0
101/192
Zakładka „przynaleŜność do grupy“
Wyświetlana jest tutaj w formie listy przynaleŜność skrzyŜowania do róŜnych węzłów.
Przykładowe okno zakładki „przynaleŜność do grupy” przedstawiono na rysunku 8.11.
Rysunek 8.11: Przykładowe okno zakładki „przynaleŜność do grupy” – przykład z Centrum
Status: unbekannt – status nieznany
Wersja 4.0
102/192
Zakładka „serwis“
Mogą być tutaj wpisane róŜne informacje na temat konserwacji i obsługi technicznej, jak
np. osoby wyznaczone do utrzymywania kontaktu i ich numery telefonów. Przykładowe
okno zakładki „serwis” przedstawiono na rysunku 8.12.
Rysunek 8.12: Przykładowe okno zakładki „serwis”
Wartungsinfo - Informacja na temat konserwacji i przeglądów
Wartungsfirma - Firma prowadząca przeglądy i konserwację
Lampenwechselfirma - Firma odpowiedzialna za wymianę świateł
Ansprechpartner/Rufnumer - Partner / numer telefonu
Polizei (verantwortlich) – Policja (odpowiedzialny)
Ersatzregelung - Uregulowanie zastępcze
Wersja 4.0
103/192
8.3.4. Przyrząd do obsługi sterownika sygnalizacji świetlnej/obsługa centralna/tryb
ekspercki
Do obsługi sterowników sygnalizacji świetlnej moŜna wybrać na widoku szczegółowym
róŜne okna dialogowe obsługi.
Narzędzie obsługi (sterowanie urządzeniem)
Za pomocą tego okna dialogowego (przykład na rysunku 8.13) moŜna wprowadzić róŜne
komendy specyficzne dla sterownika obsługującego dane skrzyŜowanie, jak. np.
załączanie programu sygnalizacji, blokowanie itp.
Rysunek 8.13: Przykładowe okno obsługi sterowania urządzeniem – przykład z Centrum
Ramka wybór urządzenia sygnalizacji świetlnej („LSA Auswahl“) ukazuje się tylko przy
wywołaniu okna dialogowego z układem sterowania sterownika z poziomu zarządzania
strategicznego itp., poniewaŜ na tym poziomie niekoniecznie dokonywany jest najpierw
wybór sterownika sygnalizacji świetlnej, tak jak przy wywoływaniu dialogu z widoku listy
urządzeń sygnalizacji świetlnej.
Wersja 4.0
104/192
Obsługa centralna
Za pomocą okna dialogowego obsługi centralnej (przykład okna przedstawiono na rysunku
8.14) moŜna blokować programy sygnalizacji albo przełączać i ponownie włączać
rejestrację komunikatów albo stanu rzeczywistego skrzyŜowania.
Rysunek 8.14: Przykładowe okno obsługi centralnej – przykład z Centrum Zarządzania w
Berlinie
Wersja 4.0
105/192
8.3.5. Ogólny stan rzeczywisty
W ramach ogólnego stanu rzeczywistego wyświetlany jest albo stan systemu, albo obiekty
wykazujące usterki.
Z widoku stan systemu („Systemzustand“) pracownik obsługi moŜe uzyskać informacje o
stanie systemu, tzn. o stanie sterownika na serwerze i wykonywanych na nim funkcjach.
Stan systemu jest przy tym przedstawiony w formie hierarchicznego drzewa. Na poziomie
najwyŜszym wyszczególnione są poszczególne sterowniki serwera, na poziomie niŜszym –
funkcje wykonywana na danym sterowniku. Stan jest przedstawiony w postaci oznaczenia
barwnego i opisu. Przykładowe okno widoku tej zakładki przedstawiono na rysunku 8.15.
Rysunek 8.15: Przykładowe okno ogólnego stanu rzeczywistego (zakładka „Stan systemu”)
– przykład z Centrum Zarządzania w Berlinie
Na widoku „obiekty wykazujące usterki” („gestörte Objekte“) pracownik obsługi moŜe
zasięgnąć informacji o obiektach wykazujących usterki oraz o obiektach, w których właśnie
wystąpiły usterki. W górnej części okna wyświetlane są obiekty wykazujące usterki, wraz z
podaniem przyczyny usterki. W dolnej części okna przedstawiane są obiekty, których stan
usterki uległ zmianie i nie został jeszcze „zaakceptowany” przez pracownika obsługi. MoŜe
on teraz „zaakceptować” te obiekty, w których właśnie wystąpiła usterka. Tym samym
obiekt przechodzi z części okna „nie zaakceptowane obiekty wykazujące usterkę” do
części okna „zaakceptowane obiekty wykazujące usterkę”. Przykładowy widok
przedstawiono na rysunku 8.16.
Wersja 4.0
106/192
Rysunek 8.16: Przykładowe okno ogólnego stanu rzeczywistego (zakładka „Obiekty
wykazujące usterkę”) – przykład z Centrum Zarządzania w Berlinie
8.4.
Sterowanie ręczne
System powinien przewaŜnie pracować automatycznie. Mimo to występuje konieczność,
aby w razie potrzeby przejść na sterowanie ręczne. Do tego celu system posiada
komfortowy ekran obsługi, wykorzystujący technikę okien. W oknach tych wyświetlane są
informacje o aktualnym stanie elementów składowych systemu oraz wizualizowane są
ręczne ingerencje w program sterowania. Obsługa moŜe odbywać się z wielu stanowisk i
dopuszcza dostęp pracowników obsługi o róŜnych profilach.
Do wprowadzania komend, będącego istotną i częstą ingerencją w program sterowania
sygnalizacją świetlną, jest do dyspozycji przejrzysty i obszerny wybór komend,
niewymagający nauczenia się skomplikowanej składni komend.
Wprowadzenie komendy moŜe zostać uruchomione:
o z widoku szczegółowego sterownika sygnalizacji świetlnej,
o z ogólnego stanu rzeczywistego,
o z widoku sieci.
Wprowadzanie komend daje moŜliwość wyboru moŜliwych komend do obsługi kaŜdego
komputera rejonu, grupy albo skrzyŜowania. Zasób komend jest zaleŜny od załoŜeń
programowych wszystkich skrzyŜowań lub wspólnych właściwości grupy przy tworzeniu
grup sterowników.
Wybrana komenda zostaje wysłana dopiero po potwierdzeniu przez pracownika obsługi.
MoŜliwe są między innymi następujące komendy:
o włączanie sterownika sygnalizacji świetlnej,
o wyłączanie sterownika sygnalizacji świetlnej,
o włączanie programu sygnalizacji,
o praca miejscowa sterownika sygnalizacji świetlej,
o włączanie/wyłączanie wyboru programu sygnalizacji,
o blokowanie sterownika sygnalizacji świetlnej,
o zwolnienie sterownika sygnalizacji świetlnej,
o blokowanie planu sygnalizacji,
o zwolnienie planu sygnalizacji.
Wersja 4.0
107/192
KaŜda komenda załączenia zostaje wprowadzona do archiwum (z podaniem czasu
rzeczywistego i kodu pracownika obsługi).
Rysunek 8.17: Przykładowe okno sterowania ręcznego
Tłumaczenie haseł na zielonym polu powyŜej:
Festlegung Steuerungsebene (Blockierung oder ohne Blockierung) - Ustalenie poziomu sterowania
(blokowanie lub bez blokowania)
Schaltzeit sofort oder zeitlich begrenzt - Czas załączania natychmiast lub w ograniczonym czasie
Hauptknoten - Główne węzły (skrzyŜowania):
ein und Auswahl Signalplan - załączanie i wybór planu sygnalizacji
aus und Auswahl Ausschaltmodus - wyłączanie i wybór trybu wyłączania
lokal und freigeben - lokalnie i zwolnienie
lokale VA - Lokalne VA
ein/aus/freigeben- załączanie / wyłączanie / zwalnianie
Schaltgrundeingabe zur späteren Nachvollziehbarkeit - Podanie przyczyny załączenia w celu
zapewnienia moŜliwości odtworzenia
Wskazówka do wprowadzania przyczyny załączenia:
W tym przypadku chodzi o pole opcjonalne. MoŜna dokonać wyboru spośród tekstów
zdefiniowanych wstępnie przez konfigurację. MoŜliwe jest równieŜ wprowadzenie
dowolnego tekstu alternatywnie.
Wersja 4.0
8.5.
108/192
Komunikaty
8.5.1. Komunikaty sterowników
Transmitowane mogą być następujące komunikaty zwrotne:
włączenie/wyłączenie sterownika
włączenie/wyłączenie akomodacji,
usterka sterownika,
zakłócenie procesu,
pęknięcie Ŝyły,
wyłączenie sieci,
usterka wtórna (wtórna usterka lamp),
zabezpieczenie sygnalizacji (usterka lampy czerwonej),
usterka detektora,
przekroczenie minimalnej wartości czasu międzyzielonego,
przekroczenie minimalnego czasu świecenia się światła zielonego,
praca miejscowa,
załączanie ręczne,
miejscowa ingerencja w program,
wygaszenie,
brak odpowiedzi (usterka przewodu),
przewód w stanie prawidłowym (odcinek transmisji = oczywisty),
błędna odpowiedź,
usterka w kanale komunikatów zwrotnych,
usterka w systemie komunikacji,
komunikaty o zmianie programu sygnalizacji,
usterki detektora,
komunikaty z dziennika pracy.
Wszystkie komunikaty są zaopatrzone w informacje na temat czasu, są archiwizowane i
rozdzielane w zaleŜności od ustawienia filtra.
8.5.2. Wskazania online i archiwizacja komunikatów
Wizualizacja aktualnych komunikatów eksploatacyjnych następuje we własnym oknie.
Komunikaty są wyświetlane bezpośrednio po nadejściu, w zaleŜności od wyboru filtra, i
jednocześnie wprowadzane do archiwum komunikatów eksploatacyjnych.
Wyświetlane są:
komunikaty eksploatacyjne sterowników i detektorów,
komunikaty eksploatacyjne sterowników obszarowych,
dane wprowadzane przez pracowników obsługi, jak komunikaty ręczne i
komentarze,
komunikaty specjalne.
Dane wprowadzone do archiwum komunikatów eksploatacyjnych mają charakter
dokumentacyjny. Nie moŜna ani wprowadzić zmian ani ich skasować.
Wyświetlanie online komunikatów odbywa się w formie tabelarycznej.
Wersja 4.0
109/192
Cały komunikat tworzy jeden wiersz tabeli, poszczególne elementy komunikatów (numer,
tekst itd.) tworzą kolumny. Wybór uwidacznianych elementów moŜe zostać dostosowany
do potrzeb uŜytkownika.
Istotnymi elementami komunikatów są:
Numer identyfikacyjny w systemie.
Data i czas wprowadzenia do pamięci. Normalnie jest on minimalnie późniejszy niŜ
czas oryginalnego komunikatu.
Data i czas powstania w odpowiednim miejscu (w sterowniku albo w systemie
sterującym ruchem (czas oryginalny)).
Potwierdzenie.
Dodatkowe informacje o źródle wysłania komunikatu, np. pracownik obsługi, układ
sterowania pracujący w funkcji czasu, układ sterowania pracujący w funkcji ruchu.
Numer skrzyŜowania.
Numer programu sygnalizacji.
Numer detektora.
Numer grupy sygnalizacyjnej.
Parametry komunikatów.
Informacja tekstowa do komunikatów.
Wskazania, czy komunikat posiada dodatkowe komentarze.
Nazwisko uŜytkownika, który potwierdził komunikat.
Data potwierdzenia komunikatu.
Archiwum komunikatów eksploatacyjnych (BEMA) umoŜliwia śledzenie zaistniałych
zdarzeń na poszczególnych węzłach komunikacyjnych, na grupach węzłów oraz na
sterownikach obszarowych.
Wszystkie zdarzenia są rejestrowane bezpośrednio jako komunikaty i wprowadzane od
pamięci w archiwum. Komunikaty mogą słuŜyć np. jako materiał dowodowy przed sądem.
Pojemność pamięci wystarcza, aby uzyskać dostęp online do komunikatów
eksploatacyjnych z kilku lat. W razie potrzeby mogą one być zapisane na zewnętrznym
nośniku danych lub ponownie wprowadzone.
Do wyszukiwania z archiwum komunikatów eksploatacyjnych są do dyspozycji róŜne filtry.
Minimalny zakres koniecznych filtrów:
Komunikaty ręczne
Załączanie przez
pracownika obsługi
Komunikaty wprowadzone ręcznie przez uŜytkownika.
Komunikaty występujące bezpośrednio po wysłaniu
komendy obsługi, zawierające informacje o pracowniku
obsługi.
Usterki
Komunikaty zdefiniowane jako usterki lub błędy
Komunikaty programowe
Komunikaty o błędach, które wystąpiły w programie
Komunikaty z komentarzem Komunikaty, do których został wprowadzony komentarz
Komunikaty nie potwierdzone Komunikaty, które wymagają potwierdzenia, ale nie zostały
potwierdzone
Filtry specyficzne dla uŜytkownika mogą zostać łatwo opracowane.
Wersja 4.0
110/192
8.5.3. Ręczne wprowadzanie komunikatów
Oprócz automatycznego przejmowania komunikatów istnieje moŜliwość dokonywania
ręcznych wpisów i przejmowania ich do archiwum komunikatów eksploatacyjnych.
Przykładem tego są usterki przewodów albo rodzaje usterek przy transmisji, które nie są
rejestrowane przez system komunikatów, jak równieŜ informacje wpływające telefonicznie.
8.5.4. Automatyczne przekazywanie komunikatów (System Zarządzania Alarmami)
W przypadku wystąpienia usterki system moŜe automatycznie powiadomić dział
konserwacji albo innego odbiorcę informacji, np. urzędy i organy administracji.
Komunikaty o usterkach są wyświetlane natychmiast na ekranie (lub pojawiają się na
drukarce protokółów) i są przekazywane w formie tekstowej
jako SMS
jako e-mail albo
jako faks
do działu konserwacji.
Szczegółowe informacje na temat automatycznego przekazywania komunikatów są
podane w rozdziale 11.5.
8.5.5. Wprowadzanie komunikatów o stanie ruchu i administrowanie nimi
Ten moduł, nazwany poniŜej menedŜerem komunikatów, rejestruje dla potrzeb
SCALA/CONCERT następujące zdarzenia i administruje nimi:
•
•
•
•
miejsca robót drogowych,
imprezy (koncerty, wydarzenia sportowe, demonstracje itp.),
komunikat dysponenta,
komunikaty transportu publicznego.
Sposób postępowania w przypadku róŜnych typów zdarzeń jest w zasadzie jednakowy.
Zdarzenia mogą być ręcznie wprowadzane na ekranie w systemie SITRAFFIC
SCALA/CONCERT albo mogą być automatycznie przejmowane z podsystemu (system
robót drogowych) za pomocą zewnętrznego interfejsu.
MenedŜer komunikatów posiada następujące funkcje:
• edytowanie zdarzeń, np. wprowadzanie nowych, modyfikowanie i kasowanie,
•
wizualizacja wszystkich zdarzeń
o
w formie przeglądu listy i jako pojedynczego okna
o
na mapie cyfrowej z podaniem połoŜenia i odniesienia do czasu
(aktualne, zakończone, w przyszłości lub podczas opracowania).
•
zapisywanie wszystkich komunikatów do archiwum komunikatów komunikacyjnych;
•
zapisywanie wszystkich działań administracyjnych w archiwum komunikatów
eksploatacyjnych;
Wersja 4.0
111/192
•
dostarczanie wszystkich danych do dalszej obróbki w zarządzaniu strategicznym;
•
identyfikator:
Jednoznaczny numer identyfikacyjny w obszarze kategorii typ zdarzenia i źródło.
•
typ zdarzenia:
Kategoria komunikatu: roboty drogowe, impreza, zakłócenia, komunikat
dysponenta, komunikat komunikacji publicznej albo informacja o stanie.
•
źródło :
SCALA/CONCERT albo nazwa podsystemu
•
nazwa:
Nazwa komunikatu.
•
odniesienie geograficzne:
Wykaz nazw ulic + informacja o kierunku + od skrzyŜowania z ulicą do
skrzyŜowania z ulicą (informacja od i do) w celu dokładnego ustalenia połoŜenia +
współrzędnych. Zakresy numeracji domów są wprowadzane tylko w tekstowym
opisie robót drogowych. Mogą być równieŜ stosowane identyfikatory w formie
linków.
•
czas obowiązywania (początek – koniec):
Rzeczywisty czas, w którym występuje zdarzenie (data rozpoczęcia + czas oraz
data zakończenia + czas).
•
czas obowiązywania w ciągu dnia
•
stan:
w przyszłości, aktualnie, zakończone
•
kasowanie automatyczne:
JeŜeli upłynęło więcej niŜ k dni
(k dni = nieskończoność, n dni, natychmiast)
•
stopień istotności/wpływ:
Klasyfikacja znaczenia zdarzenia dla ruchu (duŜe, średnie, małe, Ŝadne) =
klasyfikacja subiektywna.
•
opracował:
Nazwisko osoby ostatnio opracowującej komunikat.
•
dane czasowe:
Dane ostatniej modyfikacji komunikatu
(ewentualnie w przypadku systemów obcych: ostatnie wejście do SCALA/CONCERT)
•
kategoria zdarzenia:
Podział zdarzeń na podkategorie, np.:
transport publiczny: awaria pojazdy, roboty drogowe: impreza: mecz piłki noŜnej,
demonstracja, koncert.
Wersja 4.0
112/192
•
ograniczenia:
Liczba istniejących pasów ruchu, liczba zablokowanych pasów ruchu, zwęŜone
pasy ruchu, ograniczenia prędkości, zakazy wyprzedzania.
•
opis:
Tu mogą być ewentualnie wprowadzane tekstowe informacje dodatkowe (np.
zalecane objazdy).
MenedŜer komunikatów zawiera równieŜ opis sposobów postępowania z komunikatami.
Funkcja ta pozwala na identyfikację róŜnych obiektów dynamicznych, które są
zlokalizowane bardzo blisko siebie. W tym celu ustala się typy obiektów, np. zdarzenia.
Poza tym pracownik obsługi moŜe podać obszar działania, w którym ma zostać
wprowadzone wyszukiwanie następnego zdarzenia. JeŜeli w tym promieniu działania
znajdą się 2 zdarzenia, zostanie wysłany komunikat i zostanie wyświetlony na własnej
liście. Ten sposób postępowania z komunikatami ma za zadanie pomóc dysponentom
zwłaszcza przy rozpoznawaniu podwójnie zgłoszonych obiektów.
8.6.
Wizualizacja online
8.6.1. Widok sieci
Wizualizowane są na tle mapy miasta stany skrzyŜowań, detektorów i wartości pomiarowe.
Na mapie rastrowej moŜna wprowadzić granice obszarów jako informacje statyczne. Na tej
podstawie widoczna jest przynaleŜność sterowników sygnalizacji świetlnej do obszaru
sterowania.
Przez kliknięcie na obiekt mogą zostać wywołane szczegółowe informacje na jego temat
(patrz przykład na rysunku 8.18):
Rysunek 8.18: Sieć GIS: wywoływanie widoku szczegółowego
Opis na zielonym polu powyŜej z prawej strony rysunku:
Proszę najechać strzałką na obiekt i kliknąć prawym klawiszem myszy – pojawi się menu do wyboru
Wersja 4.0
113/192
Na mapie sieci zlokalizowane są obiekty komunikacyjne:
skrzyŜowania jako symbole,
detektory jako symbole,
wartości pomiarowe, równieŜ jako symbole lub w formie zabarwienia odcinków ulic.
Rysunek 8.19: Sieć GIS: lokalizacja obiektów
Stan symbolu jest oznaczony jego barwą.
Wyświetlane stany obiektów są wciąŜ aktualizowane.
Okno widoku sieciowego zawiera elementy do
poziomego i pionowego przesuwania widoku,
nawigacji w obszarze wskazań,
powiększania,
wyszukiwania,
selekcji,
ustalania kontrastu,
wyświetlania i wygaszania tła,
wyświetlania i wygaszania technicznych obiektów komunikacyjnych,
wyświetlania i wygaszania legendy i widoku przeglądowego.
Wersja 4.0
114/192
Wizualizacja sieci spełnia następujące warunki brzegowe:
Przydatność dla bardzo duŜych map rastrowych stanowiących tło.
Wspomaganie najwaŜniejszych formatów map (Navtech, DTED, TeleAtlas, OGDI,
ESRI).
Wspomaganie najwaŜniejszych projekcji (Lamber, Mercator, Transverse Mercator,
Universal Transversal Mercator, Lambert Conformal Conic, Stereographic,
Identity).
Wyświetlanie symboli w formacie wektorowym, jak równieŜ w formacie pixeli (jpg,
gif, png).
Wyświetlanie obiektów sterowane przez uŜywanie warstw.
Drukowanie z wysoką jakością widocznych wycinków mapy.
Ewentualnie wyświetlanie okna przeglądowego do nawigacji.
Przy uŜywaniu zoomu następuje powiększanie lub pomniejszanie symboli
(moŜliwość wyłączenia).
Bezstopniowy zoom.
Bezstopniowe przesuwanie mapy za pomocą paska do przewijania.
Obiekty graficzne mogą być wprowadzane lub kasowane online.
Obiekty mogą być wyszukiwane i wyświetlane w grafice.
Stan ruchu jest określany na podstawie pomiarów wykonanych w tym punkcie (zliczanie i
prędkość).
Sytuacja w punkcie pomiarowym jest określana na tej podstawie, Ŝe ze zmierzonych
wartości moŜna uzyskać miarodajną ocenę na temat odcinków połoŜonych dalej w
kierunku przepływu strumienia ruchu. Ze stanu ruchu w punktach pomiarowych określana
jest sytuacja komunikacyjna na przynaleŜnym fragmencie odcinka ulicy. JeŜeli fragment
ten posiada tylko 1 punkt pomiarowy, wówczas stan ruchu na tym odcinku odpowiada
stanowi ruchu w punkcie pomiarowym; przy większej liczbie punktów pomiarowych na
fragmencie odcinka naleŜy określać stan ruchu przez połączenie poszczególnych punktów
pomiarowych.
Przez połączenie fragmentów odcinków w odcinki lub przez dalszą komasację odcinków
otrzymuje się stan ruchu z zdefiniowanym obszarze lub rejonie.
Stan ruchu w punkcie pomiarowym jest określany na podstawie wprowadzonej dla niego
parametryzacji. Stan ruchu dzieli się na 3 stopnie:
Stopień 0 = ruch płynny lub wolne miejsca postojowe
Stopień 1 = ruch spowolniony, niebezpieczeństwo powstania zatorów lub wysoki
stopień wykorzystania stanowisk postojowych
Stopień 2 = przeciąŜenie, zator lub całkowite wykorzystanie stanowisk postojowych
W celu podziału stanów ruchu na podane stopnie przeprowadza się dokładną analizę
wartości pomiarowych.
Wersja 4.0
115/192
Rysunek 8.20: Rysunek stanu ruchu
Poszczególne odcinki są przedstawione za pomocą linii, umieszczonych zawsze z prawej i
z lewej strony ciągów ulic (patrz rysunek 8.20). W zaleŜności od stanu ruchu mają one
odpowiednie kolory.
Stopień 0 = zielony
Stopień 1 = pomarańczowy
Stopień 2 = czerwony.
8.6.2. Rzut poziomy węzła komunikacyjnego
Dane węzła przedstawione są na wskazaniach w oknie (przykład na rysunku 8.21) i
aktualizowane co sekundę, z moŜliwie największą realistycznością na rzucie poziomym
węzła. Obejmują one chwilowy stan sygnalizacji, wartości pomiarowe w punktach
pomiarowych, zarejestrowane stany sygnalizacji i wartości pomiarowe.
Rysunek 8.21: Widok węzła komunikacyjnego online
Wersja 4.0
116/192
Jako tło dla węzłów online mogą być zastosowane pliki w formacie BMP, EMF lub WMF.
System umoŜliwia jednoczesną wizualizację 5 węzłów.
Istnieje moŜliwość wizualizacji większej liczby węzłów w jednym oknie.
8.6.3. Sygnalizacja
Głównym celem jest wizualizacja sekundowych stanów grup sygnalizacyjnych i
detektorów, aby móc przeprowadzić analizę przebiegu programów sygnalizacji.
Rysunek 8.22: Wizualizacja programu sygnalizacji w trybie rzeczywistym – przykład z
Stany sygnalizacji w węźle, np. czerwona, Ŝółta, zielona, czerwona i Ŝółta, wygaszona,
migająca są przedstawione w formie harmonogramu sygnalizacji. Przykład przedstawiono
na rysunku 8.22.
System umoŜliwia jednoczesną wizualizację 5 węzłów.
Istnieje równieŜ moŜliwość wizualizacji danych z kilku węzłów w jednym oknie.
Przebiegi programu sygnalizacji mogą być rejestrowane i wizualizowane z przesunięciem
czasowym.
Wszystkie dane sygnalizacji są zapisywane w archiwum programów sygnalizacji.
UmoŜliwia to:
dokumentację
UŜytkownik moŜe zrekonstruować stan sygnalizacji w określonym węźle i czasie.
kontrolę
UŜytkownik musi mieć moŜliwość kontrolowania automatycznie generowanych
programów sygnalizacji.
Nie ma moŜliwości ciągłej archiwizacji rzeczywistego stanu sygnalizacji we wszystkich
węzłach. Jest to niemoŜliwe ze względu na pojemność (zdolność transmisji, pojemność
Wersja 4.0
117/192
pamięci). Funkcje te słuŜą jedynie do nadzorowania albo kontroli poszczególnych
urządzeń, np. po wprowadzeniu nowej funkcji zaleŜnej od stanu ruchu.
Archiwizowane są zmiany przynajmniej następujących danych:
dane podstawowe wizualizacji programów sygnalizacji online (SIPL)
z numerem skrzyŜowania, numerem programu sygnalizacji, metodą sterowania i
źródłem programu sygnalizacji.
początek i koniec okresu waŜności programów,
czas trwania sygnałów,
koniec czerwonego – koniec zielonego – czasy grup sygnalizacyjnej
8.6.4. „Zielona fala”
Głównym celem jest wizualizacja strumieni ruchu pomiędzy skrzyŜowaniami w fazie
zielonego światła.
Rysunek 8.23: Widok „zielonej fali” online – przykład z centrum Zarządzania w Berlinie
W tym celu widok „zielonej fali” (patrz rysunek 8.23) stanowi pomocniczy środek dla
projektanta ruchu przy koordynacji programów sygnalizacyjnych, poniewaŜ moŜe on je
sprawdzić na podstawie rzeczywistych stanów na poszczególnych skrzyŜowaniach.
UŜytkownik definiuje odcinki, zawierające określony wybór koordynowanych skrzyŜowań.
Długość odcinków jest reprezentowana na wykresie przez oś X, a czas przez oś Y.
Po uruchomieniu wizualizacji, fazy zielonego światła są wyświetlane za pomocą zielonych
pasków pomiędzy skrzyŜowaniami na wykresie i są aktualizowane w zaleŜności od
długości cyklu.
Wykresy „zielonej fali” mogą być rejestrowane i wyświetlane. Dla projektanta ruchu
stanowią one miarodajny rysunek obrazujący załączanie poszczególnych ciągów ulic.
Wersja 4.0
9.
Ocena danych dotyczących ruchu
9.1.
Statystyki i protokoły
9.1.1.
Charakterystyka systemu
118/192
RóŜne dane dynamiczne wszystkich obiektów (detektory, parkingi, miejsca odpoczynku,
miejsca garaŜowe, powierzchnie parkowania) zapisywane są w archiwum. MoŜliwe jest
dokonywanie oceny tych danych.
Program do oceny realizowany jest w postaci samodzielnego modułu na bazie generatora
protokołów. Do sporządzania protokołów i statystyk stosowane jest standardowe narzędzie
sprawozdawcze (np. Jasper). Dane zapisane w systemie archiwizacyjnym mogą być
przedstawiane na następujących osiach:
Oś czasu (linie przebiegu mierzonych wartości)
Przy róŜnych typach danych moŜliwe jest równieŜ przedstawienie przy uŜyciu
dwóch osi Y.
Oś wartości (histogramy).
Osie prezentacji danych zawierają opis typu i jednostki przedstawianej wielkości, np.
natęŜenia ruchu (ilość pojazdów/ godz.). Protokoły i statystyki mogą być wyświetlane na
ekranie monitora lub drukowane.
9.1.2. Wybór zdefiniowanych wstępnie protokołów, statystyk oraz ich selekcja
Wybór Ŝądanych ocen następuje poprzez menu 'Protokoły i Statystyki':
Wybór Ŝądanej grupy protokołów i statystyk,
Wybór specjalnych protokołów,
Wybór jednej linii lub grupy obiektów (np. wszystkie średnie pomiarowe w jednym
kierunku jazdy) z jednej listy (uwzględniane są tylko obiekty pasujące do
wybranego protokołu).
O ile dostępna jest data przebiegu, moŜliwe jest równieŜ dokonanie oceny wartości
dotyczących danego przebiegu.
9.1.3. Wybór na podstawie czasu
Wybór wartości w systemie archiwizacji następuje na podstawie czasu (dzień, godzina,
minuta). MoŜliwe jest dokonanie wyboru wartości na podstawie dnia i rodzaju dnia:
dni tygodnia
dni robocze
niedziele i święta
9.1.4. Rodzaje ocen
Dane przedstawiane są w postaci tabel, krzywych, wykresów belkowych, punktów i
diagramów (np. dla podstawowych diagramów bez uwzględnienia czasu). W przypadku
braku wartości, krzywa stanowiąca wykres wartości jest w odpowiednim miejscu
przerywana. Wartości zastępcze są specjalnie oznakowane. W przypadku uzyskania
dostępu do czasu, w którym aktywnych było wiele funkcji, menu uŜytkownika dotyczyć
będzie ostatniej funkcji.
Wersja 4.0
119/192
9.1.5. Skalowanie
Przy skalowaniu moŜna dokonać wyboru pomiędzy wartościami domyślnymi (np. prędkość
pomiędzy 0 i 255) a automatycznym dopasowaniem w zaleŜności od szerokości pasma
przedstawianych wartości mierzonych. Istnieje moŜliwość ręcznego dopasowania
skalowania osi.
9.1.6. Wprowadzanie ocen do pamięci, profile ocen
Oceny zapisywane są jako pliki w formacie PDF. Nazwy plików podawane są w
odpowiednim skrócie. Treść zapisanego protokołu stanowią parametry oceny i wyniki
badań.
Ocenione dane archiwalne mogą być wprowadzone do pamięci w standardowym formacie.
Wspierane są następujące formaty eksportowe:
XML
CSV
Eksportowany plik zawiera dodatkowe informacje w formie nagłówka, który opisuje filtr
eksportowanych danych. KaŜda kolumna eksportowanych danych zawiera atrybut
przedstawiający waŜność wartości.
System zapisuje dane w konfigurowanym wykazie domyślnym. UŜytkownik ma dodatkową
moŜliwość wyboru innego miejsca zapisu eksportowanego pliku. UŜytkownik jest w stanie
wprowadzać do pamięci odpowiednie profile ocen i ponownie ich uŜywać.
9.1.7. Drukowanie ocen
Oceny drukowane są w wersji czarno-białej lub kolorowej. KaŜda ocena zawiera nagłówek,
legendę i numerację stron. W nagłówku i w stopce podana jest data wystawienia oraz
nazwisko osoby sporządzającej dokument, wybrany okres czasu oraz miejsce. Istnieje
moŜliwość edytowania nagłówka i stopki.
9.1.8. Wstępnie zdefiniowane protokoły i statystyki
UŜytkownik moŜe wybrać następujące wstępnie zdefiniowane protokoły i statystyki:
9.1.8.1. Dane krótkookresowe
Ten zdefiniowany wstępnie protokół danych dotyczących ruchu zawiera wartości mierzone
kaŜdego pasa ruchu. UŜytkownik dokonuje wyboru następujących parametrów:
1. Okres
2. Przedział czasowy (np. 5, 15, 60 minut)
3. Źródło danych
a. Cały przekrój pomiaru
b. Specyficzny pas ruchu przekroju pomiaru
Protokół zawiera następujące specyficzne wartości mierzone dotyczące ruchu, jeŜeli
zostały one dostarczone przez infrastrukturę detekcyjną: q-poj.mech., q-sam.cięŜ, qsam.osob., v-poj.mech., v-sam.osob., v-sam.cieŜ., t-netto, b, s (s poj. mech.)
Wartości mierzone dotyczące ruchu prezentowane są w następującej postaci:
Pas ruchu/ Nazwa detektora: Pas ruchu 1/A17.MS53c.DET1
Wersja 4.0
Czas
qp.m.
7.2.2004
05:00:00
7.2.2004
06:00:00
7.2.2004
07:00:00
7.2.2004
08:00:00
120/192
qsam.cięŜ.
800
qsam.osob.
400
vpoj.mech.
400
v-sam.osob.
v-sam.cięŜ.
t-netto
b
80
80
80
0
0
10
200
100
100
70
70
70
0
0
9
700
400
250
70
70
70
0
0
10
500
260
230
70
70
70
0
0
9
s
(poj.m.)
Czas
qpoj.mech.
7.2.2004
05:00:00
7.2.2004
06:00:00
7.2.2004
07:00:00
7.2.2004
08:00:00
qsam.cięŜ.
800
qsam.osob.
400
vpoj.mech.
400
v-sam.osob.
v-sam.cięŜ.
80
tnetto
0 0
80
80
200
100
100
70
700
400
250
500
260
230
b
10
70
70
0
0
9
70
70
70
0
0
10
70
70
70
0
0
9
s
(spoj.m.)
9.1.8.2. Dane długookresowe
kaŜdego pasa ruchu na przekroju pomiaru. UŜytkownik wybiera następujące parametry:
1. Okres
2. Przedział czasu (np. 15, 60 minut)
3. Źródło danych
a. Łączny przekrój pomiaru
Protokół zawiera następujące specyficzne parametry ruchu drogowego, o ile są one
dostępne w infrastrukturze detekcyjnej: q-pojazdy, q-pojazdy cięŜarowe, q-pojazdy
cięŜarowe długie, q-pojazdy osobowe, q-pojazdy osobowe długie, q-autobusy, v-pojazdy,
v-pojazdy osobowe, v-pojazdy cięŜarowe, s-pojazdy cięŜarowe, s-pojazdy osobowe, qinne.
Czas
qp.m.
qs.c.
qs.c.dł.
qs.o.
qs.o.d
qautobusy
vp.m.
Vs.c.
Vs.o.
ss.c.
ss.o.
qinne
7.2.2004
05:00:00
7.2.2004
06:00:00
7.2.2004
07:00:00
7.2.2004
08:00:00
1000
400
200
500
400
20
70
80
60
20
15
80
200
100
100
70
0
0
68
80
60
10
16
0
700
400
250
70
0
0
80
80
50
15
10
0
500
260
230
70
0
0
80
80
60
18
10
0
Wersja 4.0
121/192
Pas ruchu/Nazwa detektora: Pas ruchu 2/A17.MS53c.DET1
Czas
qp.m.
qs.c.
q-s.c.
długie
qs.o.
q-s.o.
długie
qautobusy
vp.m
vs.c.
vs.o
ss.c.
ss.o.
qinne
7.2.2004
05:00:00
7.2.2004
06:00:00
7.2.2004
07:00:00
7.2.2004
08:00:00
1000
400
200
500
400
20
70
80
60
20
15
80
200
100
100
70
0
0
68
80
60
10
16
0
700
400
250
70
0
0
80
80
50
15
10
0
500
260
230
70
0
0
80
80
60
18
10
0
9.1.8.3. Protokół miesięczny sum dziennych
kaŜdego pasa ruchu na przekroju pomiaru dla wszystkich dni wybranego miesiąca.
Dzienne wartości mierzone bazują na wartościach 60-minutowych. UŜytkownik wybiera
następujące parametry:
1. Okres (miesiąc)
2. Źródło danych
a. Cały przekrój pomiaru
Protokół zawiera następujące specyficzne wartości mierzone dotyczące ruchu, jeŜeli
zostały one dostarczone przez infrastrukturę detekcyjną: q-poj.mech., q-sam.osob., qsam.cięŜ., %-sam.cieŜ. ((q-sam.cieŜ. / q-poj.mech.) * 100), q-poj.mech.-noc, q-sam. cięŜ.noc, poj. mech.- szczyt (wartość maksymalna q-sam. cięŜ.), poj. mech.-szczyt-czas (czas
szczytu poj. mech.).
Pas ruchu/Nazwa detektora: Pas ruchu 1/A17.MS53c.DET1
Czas
01.06.04
qp.m.
5000
qs.o.
2500
q-s.c.
50.00
%s.c.
1000
q-p.m.noc
567
q-s.c.
noc
345
2500
02.06.04
5000
2500
2500
50.00
1600
234
566
03.06.04
5000
2500
2500
50.00
1800
553
543
04.06.04
5000
2500
2500
50.00
24
235
654
05.06.04
5000
2500
2500
50.00
1243
552
456
06.06.04
5000
2500
2500
50.00
554
355
765
07.06.04
5000
2500
2500
50.00
123
224
345
08.06.04
5000
2500
2500
50.00
332
431
564
09.06.04
5000
2500
2500
50.00
23
244
456
10.06.04
5000
2500
2500
50.00
53
44
224
11.06.04
5000
2500
2500
50.00
334
143
554
p.m.- szczyt
p.m.- szczytczas
12:00 –
13:00
07:00 –
08:00
09:00 –
10:00
11:00 –
12:00
07:00 –
08:00
05:00 –
06:00
22:00 –
23:00
21:00 –
22:00
21:00 –
22:00
07:00 –
08:00
14:00 –
15:00
Wersja 4.0
122/192
12.06.04
5000
2500
2500
50.00
566
443
564
13.06.04
5000
2500
2500
50.00
234
553
654
14.06.04
5000
2500
2500
50.00
564
224
345
15.06.04
5000
2500
2500
50.00
2234
422
653
16.06.04
5000
2500
2500
50.00
5
653
456
17.06.04
5000
2500
2500
50.00
44
652
564
18.06.04
5000
2500
2500
50.00
2234
245
445
19.06.04
5000
2500
2500
50.00
43
566
654
20.06.04
5000
2500
2500
50.00
32
43
456
21.06.04
5000
2500
2500
50.00
567
6
654
22.06.04
5000
2500
2500
50.00
567
3
654
23.06.04
5000
2500
2500
50.00
4476
66
456
24.06.04
5000
2500
2500
50.00
775
33
543
25.06.04
5000
2500
2500
50.00
433
356
654
26.06.04
5000
2500
2500
50.00
445
353
654
27.06.04
5000
2500
2500
50.00
553
433
345
28.06.04
5000
2500
2500
50.00
456
354
500
29.06.04
5000
2500
2500
50.00
335
553
564
30.06.04
5000
2500
2500
50.00
543
335
456
13:00 –
14:00
15:00 –
16:00
16:00 –
17:00
19:00 –
20:00
21:00 –
22:00
23:00 –
00:00
22:00 –
23:00
07:00 –
08:00
13:00 –
14:00
09:00 –
10:00
07:00 –
08:00
12:00 –
13:00
14:00 –
15:00
15:00 –
16:00
02:00 –
03:00
05:00 –
06:00
07:00 –
08:00
09:00 –
10:00
07:00 –
08:00
9.1.8.4. Protokół danych środowiskowych
Ten zdefiniowany wstępnie protokół zawiera róŜne dane dotyczące środowiska w
wybranym okresie czasu. UŜytkownik dokonuje wyboru następujących parametrów:
1. Okres czasu
2. Źródło danych
3. Typ danych, np. opady, np. opady, gołoledź, widoczność, jasność, wilgotność
powietrza
Wartości prezentowane są w następującej postaci:
Czas
Nazwa
Pozycja
[km]
Typ danych
Wartość
Stopień
Status
01.01.2005
06:00:00
01.01.2005
06:00:00
01.01.2005
12:30:00
01.01.2005
12:30:00
01.01.2005
16:10:00
UDE_NI_1
117.1
5
117.1
5
117.1
5
117.1
5
117.1
5
Opady
0.7
mm/h
60
0
0000
Alarm gołoledzi
0000
3
0000
4
0000
-
0000
UDE_G_1
UDE_SI_1
UDE_HE_
1
UDE_LF_1
Gołoledź
Widoczność
Jasność
Wilgotność
powietrza
8000
m
1000
0 lux
30%
Wersja 4.0
01.01.2005
00:00:00
01.01.2005
00:00:00
02.01.2005
06:00:00
02.01.2005
06:00:00
02.01.2005
00:00:00
02.01.2005
00:00:00
02.01.2005
00:00:00
02.01.2005
00:00:00
02.01.2005
00:00:00
UDE_FF_1
UDE_LT_1
UDE_NI_1
UDE_G_1
UDE_SI_1
UDE_HE_
1
UDE_LF_1
UDE_FF_1
UDE_LT_1
123/192
117.1
5
117.1
5
137.1
5
137.0
0
137.0
0
137.0
0
137.0
0
137.0
0
137.0
0
Wilgotność
jezdni
Temperatura
powietrza
Opady
Gołoledź
Widoczność
Jasność
Wilgotność
powietrza
Wilgotność
jezdni
Temperatura
powietrza
3
1°C
1.0
mm/h
9000
m
9000
lux
25%
0000
0000
1
0000
OstrzeŜenie przed
gołoledzią
4
0000
0000
4
0000
0000
3
2°C
0000
0000
9.1.8.5. Statystyka wartości dziennych lub wartości miesięcznych
Ta zdefiniowana wstępnie statystyka określa graficznie sytuację ruchu drogowego w
wybranym dniu. UŜytkownik wybiera następujące parametry:
1. Okres czasu (dzień lub miesiąc)
2. Przedział czasu przy wartościach dziennych (np. 5, 15, 60 minut)
3. Źródło danych
4. Typ statystyki
a. Krzywa dzienna nasilenia ruchu pojazdów mechanicznych, samochodów
osobowych, samochodów cięŜarowych (rysunek 9.1)
Rysunek 9.1: Krzywa (wykres) dzienna nasilenia ruchu pojazdów
Opisy do wykresu powyŜej:
NatęŜenie ruchu
Czas [h]
KFZ – pojazdy mechaniczne
PKW – samochody osobowe
LKW – samochody cięŜarowe
Wersja 4.0
124/192
b. Dzienna linia wahań średniej prędkości samochodów osobowych,
samochodów cięŜarowych (rysunek 9.2)
Rysunek 9.2: Dzienna linia wahań średniej prędkości
Prędkość
Czas [h]
PKW – samochody osobowe
LKW – samochody cięŜarowe
c. v-q diagram podstawowy (rysunek 9.3)
Rysunek 9.3: Diagram podstawowy v-q
Diagram podstawowy [q/v]dla MQ23a-H
Oś pionowa: natęŜenie ruchu [pojazdy / h]
Oś pozioma: prędkość [km/h]
Wersja 4.0
125/192
d. v-k diagram podstawowy (rysunek 9.4)
Rysunek 9.4: Diagram postawowy v-k
Diagram podstawowy [v/k]dla MQ23a-H
Oś pionowa: prędkość [km/h]
Oś pozioma: gęstość [pojazdy/km]
e. q-k diagram podstawowy (rysunek 9.5)
Rysunek 9.5: Diagram postawowy q-k
Diagram podstawowy [Q/K] dla MQ23a-H
Oś pionowa: natęŜenie ruchu [pojazd/h]
Oś pozioma: gęstość [pojazdy/km]
Wersja 4.0
9.2.
Przetwarzanie wartości mierzonych
Patrz rozdział 10.
9.3.
126/192
Analiza jakości QM/Q2
Oceny wartości mierzonych przy uŜyciu SITRAFFIC P2
Nasilenie ruchu wizualizowane jest graficznie przez SITRAFFIC P2 zarówno w formie
dziennych wahań, jak i w formie przebiegów obciąŜenia dla róŜnych sytuacji ruchu w
postaci tabeli.
9.3.1. Miejsca przeprowadzenia pomiaru
Miejsca przeprowadzenia pomiaru słuŜą do przyporządkowania danych liczbowych.
9.3.2. Budowa pozycji miejsce przeprowadzenia pomiaru
Dane w nagłówku
Nazwa
Opis
Od: data/czas
Do: data/czas
Numer miejsca pomiaru.
dowolne oznaczenie miejsca przeprowadzenia pomiaru
przy automatycznym zakładaniu wstawiane są 'Oryginalne
wartości mierzone'
Początek okresu czasu
Koniec okresu czasu
Numer identyfikacyjny. Miejsce pomiaru, któremu nadano
numer określane jest jako oryginalne miejsce
przeprowadzenia pomiaru.
9.3.3. Łączenie miejsc przeprowadzenia pomiaru
Miejsca przeprowadzenia pomiaru moŜna łączyć poprzez operacje dodawania (+ :
dodawanie wartości liczbowych) i odejmowania (- : odejmowanie wartości liczbowych).
BliŜsze informacje podane są w podręczniku obsługi systemu SITRAFFIC P2, rozdział
4.7.3 – Miejsca przeprowadzenia pomiaru.
9.3.4. Dzienne linie wahań
Dzienne linie wahań przedstawiają przebiegi natęŜenia ruchu w określonych okresach
czasu, przy czym poszczególne wartości sczytywane są z reguły w godzinnych
przedziałach (moŜliwe jest równieŜ stosowanie przedziałów czasowych wynoszących 1
min. lub 15 min).
Wahania dzienne przedstawione są w formie, jak na rysunku 9.6.
Wersja 4.0
127/192
Rysunek 9.6: Linia wahań dziennych
Objaśnienia:
Oś pionowa: wartość zliczeń
9.3.5. Plany obciąŜenia
ObciąŜenia kierunkowe opracowywane są w oddzielnym obiekcie i mogą być
przedstawiane zarówno w formie tabeli (rysunek 9.7), jak i w formie graficznej (rysunek
9.8), jako wartości obciąŜeń.
Źródłem danych mogą być przy tym z jednej strony zliczane ręcznie wartości liczbowe,
określające ilość pojazdów mechanicznych przypadających na przedział czasowy, lub ilość
określonych pojazdów przypadających na przedział czasowy.
Z drugiej strony moŜliwe jest automatyczne przejmowanie wartości z opisanych wcześniej
miejsc dokonywania pomiarów.
Konieczne jest przy tym przypisanie miejsc dokonywania pomiarów do odpowiednich
kierunków lub podanie odpowiedniego udziału miejsca dokonywania pomiarów w danym
kierunku.
Dokładny opis zawarty jest w podręczniku obsługi systemu SITRAFFIC P2, rozdział 4.7.1.
Poszczególne wartości przedstawiane są graficznie w diagramie dla punktu węzłowego.
Wersja 4.0
128/192
Rysunek 9.7: Przedstawienie obciąŜenia punktów węzłowych w tabelarycznej formie przykład z Centrum Zarządzania w Berlinie
Wersja 4.0
129/192
LA (PKWE/h)
dojazd wsch.
wyjazd pd.
LA (PKWE/h)
dojazd.poł.
GA
(PKWE/h)
wyjazd pn.dojazd pd.
RA
(PKWE/h)
dojazd zach.
– wyjazd pd.
GA
(PKWE/h)
dojazd pd.
RA
(PKWE/h)
dojazd pd.
Rysunek 9.8: Przedstawienie obciąŜenia punktu węzłowego w graficznej formie - przykład z
Wersja 4.0
130/192
Układ kontroli czasów przełączania koordynuje sterowanie przy pomocy systemu
SITRAFFIC P2 (alternatywnie do SITRAFFIC Q2).
Aby umoŜliwić dokonywanie oceny sprawności skoordynowanego sterowania sygnalizacją,
(zielona fala) zapisywane są czasy przełączeń (początek lub koniec zwolnienia).
Przy programach akomodacyjnych uzyskiwane są punkty czasowe początków
i końców emisji światła zielonego, które ulegają ciągłym wahaniom w wyniku róŜnych
przedziałów czasowych zwalniania lub zatrzymania ruchu.
PoniewaŜ do utrzymania koordynacji płynnego ruchu moŜliwe jest dopuszczenie tylko
określonego zakresu wahań, protokołowane są czasy przełączeń wykraczające poza ten
zakres.
Zdarzenie zapisywane jest w formie tabeli. Na Ŝyczenie uŜytkownika istnieje moŜliwość
przedstawienia graficznego.
Zakresy zwalniania poszczególnych grup sygnalizacyjnych i programów sygnalizacyjnych
definiowane są przez własny obiekt, a tym samym własny edytor. Istnieje równieŜ
moŜliwość ich importowania z danych ramowego planu z SITRAFFIC P2.
Punktem wyjścia są zakresy faz dopuszczania metody PDM generowane i przedstawiane
graficznie w SITRAFFIC P2.
Na podstawie tych, tak zwanych ramowych planów PDM (przykładowe okno ramowego
planu fazowego przedstawiono na rysunku 9.9), które przyporządkowane są do kaŜdego
programu sygnalizacji jako rekord parametrów akomodacji, opracowywane są testowe
harmonogramy sygnalizacji.
Te testowe harmonogramy sygnalizacji zawierają najwcześniejszy moŜliwy początek lub
najpóźniejsze moŜliwe zakończenie zwolnienia kaŜdej grupy sygnalizacji. Te punkty
czasowe obliczane są automatycznie na podstawie ramowych planów PDM i zapisywane
jako dane XML.
Pocz. em.
św. ziel.
Koniec
em. św. z.
Rysunek 9.9: Przedstawienie ramowego planu fazowego - przykład z Centrum Zarządzania w
Berlinie
Wersja 4.0
131/192
Te najwcześniejsze/najpóźniejsze momenty przełączeń harmonogramów testowych mogą
być uŜyte jako wartości graniczne przy kontroli przełączeń skoordynowanych skrzyŜowań,
poniewaŜ ze względów koordynacyjnych przełączanie moŜliwe jest tylko w obszarze
wyznaczonym przez te parametry graniczne.
W połączeniu z oceną aktualnie stosowanego programu sygnalizacji przez SITRAFFIC Q2
moŜna stosować obowiązujący rekord wartości progowych do prowadzenia kontroli.
Pozwala to na wyeliminowanie fałszywych alarmów spowodowanych stosowaniem
niewłaściwych wartości granicznych.
Dokonywana jest równieŜ ocena częstotliwości (bezwzględnej i względnej) występowania
róŜnych momentów początkowych i końcowych emisji światła zielonego i obliczane są
wartości średnie. Te wartości średnie określane są dla reprezentatywnych grup
sygnalizacji pewnej ilości punktów węzłowych i przedstawiane są w formie tabelarycznej.
Wersja 4.0
10.
132/192
Analiza jakości QM/Q2
10.1. Podstawowa charakterystyka kontroli jakości i analizy
jakości
Dane dotyczące sygnalizacji świetlnej w punktach węzłowych dzielą się na tak zwane dane
zasilające i dane procesowe.
Dane zasilające opisują podstawowe parametry / konfiguracja obiektu (np. czasy
międzyzielone, kolejność sygnałów), zasilanie urządzeń/ definicja obiektu (np. grupa
sygnalizacyjna), dane systemowe (np. przyporządkowanie kanałów) ocenianej instalacji
sygnalizacji świetlnej.
Dane procesowe opisują wartości zmierzone przez przyrządy lokalne (wartości mierzone i
stany) oraz wartości AP ocenianej instalacji sygnalizacji świetlnej.
Ocena dotyczy następujących zagadnień:
Analiza ruchu
IV-analiza zielonych fal
IV-analiza detektorów
NajwaŜniejszym zadaniem oceny jest zapewnienie odpowiedniej jakości pracy systemu.
•
Zapewnienie odpowiedniej jakości działania przyrządów
lokalnych i stosowanych metod (HW & SW)
•
Kontrola jakości technicznej urządzeń lokalnych i
centralnych
Analiza
jakościowa
•
Zarządzanie awaryjne IV i ÖV
•
Szczegółowa analiza jakościowa dla wykonywania
indywidualnych ocen
Zarządzanie
jakością
•
Sporządzanie raportów dotyczących systemów i
elementów
•
Rozwój: Integracja działań w skali makro z systemem
zarządzania ruchem
Kontrola
10.2. Cechy systemu
Do kontroli jakości i prowadzenia analizy jakości systemu zarządzania ruchem drogowym
stosowane są narzędzia SITRAFFIC QM i SITRAFFIC Q2, które umoŜliwiają zarówno
ocenę jakości technicznej, jak i systemowe analizy pod kątem niezawodności instalacji
sygnalizacji świetlnej i urządzeń rejestrujących.
Kontrola jakości i analiza jakości opiera się na danych OCIT-LSA przekazywanych przez
interfejs OCIT.
Dane przejmowane są przez centralę. Ona teŜ dokonuje ocen. Kontrola jakości
aktywowana jest Online.
Wersja 4.0
133/192
10.2.1. SITRAFFIC QM
SITRAFFIC QM konfiguruje i zleca kontrolę jakości (QK) i jest niezbędny do
parametryzowania.
Kontrola jakości stanowi centralny element ustalania wartości progowych i jest sprzęŜona z
serwerem danych (RDS) SITRAFFIC SCALA/CONCERT.
Kontrola jakości (QK) umoŜliwia sprawdzanie następujących parametrów:
Czasy wyświetlania sygnału zielonego dowolnych grup sygnalizacyjnych
Okresy wyświetlania światła (np. tylko zielonego lub czerwonego) dowolnych grup
sygnalizacyjnych.
Wartości liczbowe detektorów w zadanym przedziale czasowym
Czasy pomiędzy równoległym detektorem a wyświetlaniem zielonego światła przez
przynaleŜną grupę sygnalizacyjną.
Punkty pomiarowe z minimalną i maksymalną ilością telegramów oraz procentowe
odchylenie ilości telegramów w ramach jednego skrzyŜowania.
Właściwości kontroli jakości:
Kontrola poszczególnych wartości
Wielokrotnie powtarzane meldunki zbierane są w jeden odpowiedni meldunek.
Jako element serwera działa w 24 godzinnym trybie pracy.
MoŜliwość przechowywania raportów w archiwum roboczym
Kontrola wartości zbiorczych (meldowanie kontroli wykonywanej w określonym
przedziale czasowym)
10.2.2. SITRAFFIC Q2
SITRAFFIC Q2 słuŜy do oceny danych LSA zbieranych przez serwer danych
nieprzetworzonych.
W celu wykonania analizy importowane są dane z serwera danych nieprzetworzonych
(RDS).
Ocena następuje na stanowisku obsługi (VIEW-CLIENT) i jest wywoływana przez aplikację
SITRAFFIC Q2.
Zapewnia to moŜliwość zastosowania opcji Serwer-Klient..
Przegląd kontroli jakości i analizy jakości
Tabela 10.1 daje przegląd danych stosowanych do wykonywania ocen:
Tx sekunda cyklu
sygnalizacyjnego przy
meldunku
SPL numer planowy
sygnału
TU czas trwania cyklu
sygnalizacyjnego
Oceny dotyczące grup
sygnalizacyjnych
X
Oceny dotyczące
detektorów
X
Oceny ruchu
drogowego
X
X
X
X
X
X
X
Wersja 4.0
Dane grupy
sygnalizacyjnej SG
Dane detektorowe
(wartości
nieprzetworzone)
Dane OM (Telegram
AMLI/R09 )
134/192
X
X
X
Tabela 10.1: Przegląd danych stosowanych do wykonywania ocen
Narzędzia Q2/QM dają następujące moŜliwości dokonania oceny/analizy:
Oceny na bazie informacji sygnałowych i
detektorowych
Kontrola jakości
(wejścia równoległe)
[Q1]
[Q2]
[Q3]
[Q4]
[Q5]
[Q6]
[Q7]
[Q8]
[Q9]
[Q10]
Określanie czasów wyświetlania światła
zielonego, łączny czas róŜnych faz
Maksymalne czasy wyświetlania światła
zielonego i czerwonego
(Sumy wyświetlania światła zielonego/
czerwonego)
Czasy cyklu
(Początek wyświetlania światła
zielonego – początek wyświetlania
światła zielonego) z podaniem czasu
wyświetlania światła zielonego
Moment wyświetlania światła zielonego
grupy sygnalizacyjnej
Zliczanie zameldowań i odmeldowań
Czas pomiędzy zameldowaniem i
odmeldowaniem
Okres pomiędzy zameldowaniem i
wyświetlaniem światła zielonego grupy
sygnalizacyjnej
Analiza jakości
(po zaistnieniu zdarzeń)
Przesunięcie czasowe grupy sygnałowej
Okres czasu pomiędzy początkiem i
końcem wyświetlania światła zielonego
dwóch grup sygnalizacyjnych
Częstość (absolutna i procentowa)
czasu wyświetlania światła zielonego i
czerwonego
Zgłoszenia na detektorach
Tabela 10.2: MoŜliwości kontroli i oceny grup sygnałowych SITRAFFIC Q2/QM
Wersja 4.0
Ocena odnosząca się do skrzyŜowania
na podstawie informacji zawartych w
Kontrola jakości
pamięci transportu publicznego (ÖPNV wejścia seryjne)
[Q11]
[Q13]
[Q14]
[Q15]
Czasy jazdy
Rzeczywiste czasy jazdy od momentu
zameldowania do momentu
odmeldowania.
Meldunki specjalne
Meldunki
Częstość występowania trzech
alarmowe
zdefiniowanych wcześniej
standardowych meldunków specjalnych:
‚Zameldowanie alarmowe ‘, ‚Modyfikacja
bez odmeldowania‘ i ‚Odmeldowanie
wymuszone‘
Czasy sygnałów dowolnych linii
Przebieg jazdy
Przebieg jazdy poszczególnych linii w
punkcie węzłowym
135/192
Analiza jakości
(przesunięta w czasie)
Tabela 10.3 MoŜliwości kontroli i ocen SITRAFFIC Q2/QM odnoszących się do węzła
[Q16]
[Q18]
Ocena odnosząca się do trasy na
podstawie informacji zawartych w
Kontrola jakości
pamięci transportu publicznego (ÖPNV wejścia seryjne)
Przebieg jazdy na trasie
Czasy jazdy na odcinkach trasy
Czasy podróŜy
Rozkład częstości czasów podróŜy dla
wybranej trasy
Analiza jakości
(przesunięta w czasie)
Tabela 10.4; MoŜliwości kontroli i oceny SITRAFFIC Q2/QM odnoszące się do trasy
10.3. Przykłady ocen w zakresie kontroli jakości
10.3.1. Analizy transportu publicznego - ÖPNV
10.3.1.1. Ocena czasów jazdy
Wskazanie rzeczywistych czasów jazdy od momentu zameldowania do odmeldowania.
Na podstawie rozkładu częstości zdarzeń moŜna dokonać oceny skuteczności sterowania
ruchem drogowym.
Na osi x (rysunek 10.5) podane są czasy jazdy. Na osi y zaznaczona jest ilość pojazdów.
Belki pokazują ile pojazdów wymagało określonego czasu jazdy wyraŜonego w sekundach
i zdefiniowanego jako czas pomiędzy zameldowaniem i odmeldowaniem. W zaleŜności od
rodzaju prezentacji, wartości liczbowe wskazywane są w postaci absolutnej lub względnej
(w procentach, w stosunku do łącznej ilości ocenianych pojazdów).
Oprócz częstości występowania obliczay jest równieŜ średni czas podróŜy i wykazywany w
porównaniu do „przewidywanego czasu jazdy” (czas z LSA przenoszony jest przez
telegram AMLI).
Wersja 4.0
136/192
Warianty prezentacji:
Z przebiegu krzywej moŜna odczytać rozrzut czasów jazdy.
Im węŜszy jest ten rozrzut, tym mniejsze są odchylenia czasu jazdy od czasu średniego
lub rozkładowego czasu jazdy.
Rysunek 10.5: Ocena czasów jazdy
Objaśnienia do wykresów powyŜej:
Häufigkeit (Anzahl) - częstotliwość (liczba) – [oś pionowa]
Fahrzeit (sec) - czas przejazdu (sek) – [oś pozioma]
ÖV-Richtung - Kierunek ruchu transportu publicznego
Start Auswertung - Początek oceny
Ende Auswertung - Zakończenie oceny
Häufigkeiten der Fahrzeiten - Liczba przejazdów
Prognostizierte Fahrzeit - Prognozowany czas przejazdu
Mittere Fahrzeit bei Abmeldung - Średni czas przejazdu przy wymeldowaniu
10.3.1.2. Ocena przebiegu jazdy na skrzyŜowaniach
Diagram pokazuje przebieg jazdy poszczególnych linii na skrzyŜowaniu. Poczynając od
pierwszego zameldowania wybranego kierunku, łączone są linią ciągłą czasy jazdy do
kolejnych punktów zameldowania i do punktu odmeldowania. W ten sposób moŜna
obserwować rozrzut czasów jazdy w punkcie węzłowym.
Na osi x (rysunek 10.6) zaznaczane są punkty zgłoszeń danego kierunku. Na osi z
zaznaczany jest czas jazdy.
Wersja 4.0
137/192
Nieco szerszą, szarą linią zaznaczany jest idealny przejazd ustalony na podstawie
teoretycznych czasów jazdy. W przypadku braku danych stosowany jest średni czas jazdy,
przy czym średnia ustalana jest w oparciu o wybrane czasy jazdy.
Rysunek 10.6: Przykładowe okno z oceną przebiegu jazdy w punktach węzłowych – przykład
z Centrum Zarządzania w Berlinie
10.3.1.3. Częstość występowania punktów zgłaszania czasu
Dla oceny działania systemu szczególne znaczenie ma porównanie częstości
punktualnych zgłoszeń dotarcia do miejsc zameldowania i odmeldowania. Na tej
podstawie moŜna odczytać zarówno opóźnienia przebiegu, jak równieŜ brakujące
zgłoszenia i odmeldowania.
W diagramie z rysunku 10.7 prognozowane czasy dotarcia, zapowiedziane przy
zgłoszeniu, zestawione zostały z rzeczywistym czasem dotarcia (stwierdzonym przy
odmeldowaniu).
Górny diagram pokazuje rozkład częstości występowania prognozowanych czasów
dotarcia. Dolny diagram pokazuje rozkład zmierzonych czasów odmeldowania, tzn. Ilość
pojazdów, które rzeczywiście dotarły w prognozowanym czasie.
Na obydwu osiach x zaznaczony jest czas cyklu sygnalizacyjnego. Na obydwu osiach y
zaznaczona jest częstość występowania (ilość pojazdów).
Dodatkowo pokazano na diagramie standardowy czas emisji światła zielonego: zielony
obszar.
Wersja 4.0
138/192
Rysunek 10.7: Przykładowe okno z widokiem częstości występowania punktów zgłaszania
czasu – przykład z Centrum Zarządzania w Berlinie
10.3.1.4. Kontrola działania punktów meldunkowych
Jedną z istotnych cech sprawności systemu SITRAFFIC Q2 w zakresie wymiany danych
pomiędzy pojazdem i sterownkiem jest jakość odbioru punktów składania meldunków.
Na osi x (rysunek 10.8) kaŜda wartość całkowita oznacza numer kursu. Na osi y
zaznaczone są punkty meldunkowe.
Przyporządkowanie tych wskaźników do rzeczywistych numerów linii i kursów oraz do
numerów punktów meldunkowych następuje w oparciu o legendę (nieprzedstawioną na
ilustracji).
Ilości otrzymywanych informacji z kaŜdego kursu obliczane są w centrum ocen i
przedstawiane jako wartość średnia.
Uszkodzone pojazdy lub punkty meldunkowe moŜna łatwo zidentyfikować na podstawie
kształtu odpowiedniego wierzchołka (w przedstawionym przypadku kursy 4 i 6 oraz punkt
meldunkowy 22 wykazują się wadliwą jakością odbioru. Przyczyną mogą być źle
działające nadajniki radiowe w pojazdach lub niedokładnie ustawione słupki wskaźnikowe).
Wersja 4.0
139/192
W tym celu konieczne jest pozyskanie niezbędnych informacji, np. przez przewody jezdne,
w celu dokonania oceny.
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
15
26
28
24
10
Linie/Kurs
22
20
5
18
Meldepunkte
16
0
14
Rysunek 10.8: Przykładowe okno z widokiem kontroli działania punktów meldunkowych
Objaśnienia:
linia/kurs
punkty meldunkowe
Wersja 4.0
140/192
Rysunek 10.9: Przykładowe okno z kontrolą działania punktów meldunkowych (Tabela) –
przykład z Centrum Zarządzania w Berlinie
Forma tabeli
Tabelaryczna wersja (rysunek 10.9) zawiera poszczególne przejazdy z informacjami
dotyczącymi linii, kursu i trasy oraz z podaniem czasów startu i zakończenia przejazdów.
Dla kaŜdego kierunku przedstawionego przejazdu zsumowane zostały punkty
meldunkowe. Odchylenia od oczekiwanej ilości punktów meldunkowych zostały
zaznaczone kolorem i zaprotokołowane.
10.3.2. Oceny odcinkowe
10.3.2.1. Przebieg jazdy
Ocenie podlegają czasy jazdy. W wyniku przypisania zdefiniowanego wstępnie łańcucha
punktów meldunkowych definiowane są punkty węzłowe i punkty meldunkowe.
Diagram pokazuje przebieg poszczególnych jazd przez róŜne punkty węzłowe trasy.
Poczynając od zgłoszenia w pierwszym punkcie węzłowym czasy jazdy przedstawiane są
kolejno według poszczególnych punktów węzłowych.
Wersja 4.0
141/192
Na osi x (rysunek 10.10) podane są obok siebie poszczególne punkty węzłowe trasy
odpowiednio do wyselekcjonowanych punktów meldunkowych. Na osi y naniesiony jest
czas jazdy.
KaŜda jazda przedstawiona jest jako kolorowa linia. Objaśnienia zawarte są w legendzie.
Znajdują się w niej równieŜ szczegółowe dane dotyczące poszczególnych kursów.
Ocena zawiera równieŜ średnie czasy jazdy (szersza, Ŝółta linia), przy czym określone
zostały one na podstawie wyselekcjonowanych, a więc nie tylko wskazanych kursów.
Rysunek 10.10: Przykładowe okno z wykresem zaleŜności drogi w czasie - przebieg jazdy –
przykład z Centrum Zarządzania w Berlinie
10.3.2.2. Czas jazdy
Diagram pokazuje rozkład częstości występowania czasów jazdy na wybranym odcinku
trasy.
Na osi x (rysunek 10.11) podane są czasy jazdy. Na osi y podana jest częstość (liczba
pojazdów).
Belki pokazują liczbę pojazdów, które pokonały trasę w odnośnym czasie.
Uwzględniane są dane z wszystkich punktów węzłowych wyselekcjonowanych punktów
meldunkowych. Pod uwagę brane są tylko pełne kursy, tzn. musi nastąpić zgłoszenie i
wymeldowanie linii/kursu.
Oprócz rozkładu częstości obliczany jest równieŜ średni czas podróŜy i wskazywany jest
on zarówno w legendzie, jak i w grafice, jako cienka linia pionowa.
Wersja 4.0
142/192
Rysunek 10.11: Przykładowe okno z diagramem rozkładu częstości występowania czasów
jazdy na wybranym odcinku trasy – przykład z Centrum Zarządzania w Berlinie
10.4. Przykłady ocen w ramach analizy jakości
10.4.1. Ocena czasów przełączania
Aby dokonać oceny skoordynowanego sterowania sygnalizacji świetlnej, konieczne jest
ustalenie czasów przełączania (początek emisji światła zielonego lub zakończenie emisji
światła zielonego).
W przypadku działania, zaleŜnego od sytuacji w ruchu drogowym, powstają róŜne
przedziały wydłuŜające lub regulacja strumieni ruchu poprzez przyspieszanie lub
opóźnianie początku emisji światła zielonego lub światła czerwonego, które ulegają
ciągłym wahaniom.
PoniewaŜ w celu zapewnienia płynnej koordynacji ruchu dopuszczalne są zakresy wahań,
naleŜy protokołować czasy przełączeń odbiegające od czasów normalnych. Nie jest
moŜliwe dokładne kontrolowanie offsetu dwóch grup sygnałowych pomiędzy dwoma
skrzyŜowaniami.
Czasy przełączania mogą być przedstawiane zarówno w formie tabel (rysunek 10.13), jak i
w formie graficznej (rysunek 10.12).
Wersja 4.0
143/192
W polu z prawej strony, obok zaprezentowanych czasów przełączania pokazany jest
rozdział częstości występowania poszczególnych czasów przełączania.
Rysunek 10.12: Okno z widokiem czasów przełączania sygnałów zielonych, prezentacja
graficzna – przykład z Centrum Zarządzania w Berlinie
Rysunek 10.13: Okno z widokiem czasów przełączania sygnałów zielonych, prezentacja
tabelaryczna – przykład z Centrum Zarządzania w Berlinie
Wersja 4.0
144/192
10.4.2. Ocena wartości wskazanych przez detektory
Wizualizacja wartości detektorowych następuje w formie tabel (rysunek 10.14) lub w formie
graficznej (rysunek 10.15).
Rysunek 10.14: Wizualizacja wartości detektorów, prezentacja tabelaryczna – przykład z
Rysunek 10.15: Wizualizacja wartości detektorów, prezentacja graficzna – przykład z
Wersja 4.0
145/192
10.5. Definicja wartości progowych w zarządzaniu jakością
Poprzez odpowiedne edytory moŜna zdefiniować wartości progowe dla kaŜdego
istniejącego skrzyŜowania. Dostępne są następujące edytory:
Czasy wyświetlania światła zielonego (IV/ÖV)
Edytor ten słuŜy do konfiguracji kontroli czasów wyświetlania światła zielonego.
Kontrola jakości odczytuje aktualne czasy wyświetlania światła zielonego i porównuje je z
wartościami progowymi. Istnieją rekordy i wiersze wartości progowych.
Rekord jest zawsze związany z typem i określa warunki ramowe. Są one
parametryzowane w wierszu nagłówkowym.
KaŜdy rekord wartości progowych symbolizowany jest przez odpowiedni symbol wewnątrz
edytora.
Rysunek 10.16: Wartości progowe wyświetlania światła zielonego
Instanznummer – numer instancji
Kurzbezeichner – symbol
Name – nazwa
Beschreibung – opis
Signalprogramme – programy sygnalizacyjne
Wochentage – dni tygodnia (od poniedziałku do niedzieli)
Uhrzeit – godzina
Start – początek
Ende – koniec
Qualitatskontrolle – kontrola jakości:
Uberwachung – monitorowanie
Anzahl Uberschreitungen – liczba przekroczeń
Uberwachungsinterwale – interwały monitorowania
Signalgru – grupa sygnalizacyjna
Farbe – kolor
Grun – zielony
Anwurf – rzut
Freigabebeginn – początek zwolnienia
Freigabeende – koniec zwolnienia
Fruhest – najwcześniej
Spatest – najpóźniej
Richtung - kierunek
Nachwirkszeit – czas oddziaływania
Wersja 4.0
146/192
Czasy trwania faz
Czasy trwania faz (rysunek 10.17) wybranej grupy sygnalizacyjnej analizowane są przez
zdefiniowany okres czasu.
Konfiguracja parametrów następuje w edytorze. Istnieją rekordy i wiersze wartości
progowych. Rekord jest zawsze związany z typem i określa warunki ramowe. Są one
parametryzowane w wierszu nagłówkowym.
KaŜdy rekord wartości progowych symbolizowany jest przez odpowiedni symbol wewnątrz
edytora.
Rysunek 10.17: Edytor wartości progowych czasów trwania faz
Patrz: objaśnienia do ekranu na rysunku 10.16
+
Zustandsdauern – czasy trwania faz
Zuschlag - dodatek
Detektory
Kontrola detektorów (rysunek 10.18) jest bardzo wielostronna i zaleŜna od moŜliwości
poszczególnych detektorów. Podobnie jak inne edytory zawiera ona rekordy i wiersze
wartości progowych. Rekordy wartości progowych określają dla wszystkich zawartych w
nich wierszach długość przedziału czasu, i sumowane są wartości wysyłane przez
detektory. Konfiguracja wartości wysyłanych przez detektor następuje w poszczególnym
wierszu wartości progowej w zaleŜności od tego jakich wartości moŜe dostarczać detektor.
Wersja 4.0
147/192
Rysunek 10.18: Edytor wartości progowych - detektory
Patrz: ekran na rysunku 10.16
+
Aggregierungsinterval – interwał agregacji
Std-Report – raport godzinowy
Auswerte-Typ – rodzaj oceny
Zahlwerte – wartości zliczone
Czasy oczekiwania
Sprawdzane są okresy pomiędzy zameldowaniem przez detektor a wyświetlaniem światła
zielonego przez odpowiednią grupę sygnałową (rysunek 10.19).
Rysunek 10.19: Edytor wartości progowych czasów oczekiwania
+
Std-Report – raport godzinowy
Wartezeit – czas oczekiwania
Gewunscht – poŜądany
Toleriert - tolerowany
Punkty meldunkowe/Czasy jazdy
Ten edytor (rysunek 10.20) słuŜy do konfiguracji czterech kontroli jakości:
► Kontroli czasu jazdy pomiędzy skrzyŜowaniami
► Kontroli ilości meldunków awaryjnych
► Kontroli minimalnej i maksymalnej ilości telegramów punktów meldunkowych
Wersja 4.0
148/192
► Kontroli róŜnicy ilości telegramów punktów meldunkowych w dwóch punktach
meldunkowych.
Rysunek 10.20: Edytor wartości progowych - punkty meldunkowe/czasy jazdy
+
Richtungsauswahl – wybór kierunku
Allgemeine Abweichung – odchylenie ogólne
Max. Anzahl Notanmeldungen – maksymalna liczba zgłoszeń sytuacji awaryjnych
Max. Abweichung zur theor. Fahrzeit – maksymalne odchylenie od teoretycznego czasu jazdy
10.6. Raport - Funkcja kontroli jakości
10.6.1. Moduł raportu
Wartości progowe nie zdefiniowane
błąd
Poza tolerancja
błąd
W granicach tolerancji
Info
E
SOAP
BEMA
XLS
Plik
CSV
Fax
SMS
Typ meldunku
Mail
Meldunek
Drucker
Moduł raportu (rysunek 10.21) określa strategię sprawozdawczą kontroli jakości. W
kaŜdym obiekcie wartości progowych istnieje punkt menu ,,Ustawienia/sprawozdania“
S
E
E
E
S
Tabela 10.21: Moduł raportu
Wersja 4.0
149/192
10.6.2. Zarządzanie kontrolą jakości
Ta centralna strona (rysunek 10.22) umoŜliwia wgląd w dane. Przedstawiane są w niej w
przejrzysty sposób i kontrolowane wszystkie punkty meldunkowe na trasie oraz czas
jazdy.
W obszarze IV przedstawiane i kontrolowane są np. czasy emisji światła zielonego,
detektory i czasy oczekiwania.
JuŜ na pierwszy rzut oka
widać, czy odchylenie jest
spowodowane przez
instalację sygnalizacyjną
(kolumna) , czy przez
uŜytkownika pojazdu (wiersz).
JuŜ na pierwszy rzut oka
widać, czy przyczyna
odchylenia ma charakter
miejscowy (kolumna), czy
czasowy (wiersz).
Rysunek 10.22: Przykładowa wizualizacja zarządzania kontrolą jakości – przykład z Centrum
Od przeglądu moŜna w razie potrzeby odejść po rozpoznaniu odchylenia wraz z
dokonaniem szczegółowych ocen.
Wykonanie przeglądu w postaci strony internetowej stwarza klientowi moŜliwość
wizualizacji w intranecie.
Przy ustawieniu okresu czasowego na 24 godziny moŜna generować dzienne raporty
jakości ruchu zawierające jakościowy przegląd w zakresie publicznego transportu
podmiejskiego (IV i OPNV).
Wersja 4.0
11.
150/192
Zarządzanie w sytuacjach awaryjnych
11.1. Dwuczęściowa koncepcja obsługi
Zarządzanie w sytuacjach awaryjnych zostało celowo opracowane niezaleŜnie od
zarządzania ruchem, w celu organizacyjnego oddzielenia obydwu systemów. Rozwiązanie
takie umoŜliwia optymalne śledzenie i realizowanie zadań komunikacyjnych.
Z punktu widzenia operatora zarządzanie ruchem drogowym wygląda następująco:
KaŜdy obiekt kontrolowany jest pod kątem swojego statusu.
JeŜeli obiekt dostarcza jedynie meldunki robocze, to zostaje pozbawiony statusu.
Informacje statusowe archiwowane są jako wartości mierzone i słuŜą do
późniejszej oceny statystycznej (np. przełączeń i zakłóceń w określonym czasie)
Meldunki robocze przechowywane są w archiwum roboczym
KaŜda zmiana statutu (błąd, alarm, ostrzeŜenie, ok, nieznane) jest pokazywana i
wymaga skwitowania.
W okienku szczegółów obiektu wskazywane są, oprócz statutu, odpowiednie
meldunki robocze (autofiltr)
Z punktu widzenia operatora zarządzanie w sytuacjach awaryjnych wygląda następująco:
Wszystkie meldunki robocze i informacje o statusie przejmowane są przez system
zarządzania ruchem drogowym, przy czym następuje (wartość ustawialna) ok. 2godzinne buforowanie.
JeŜeli status obiektu (np. tablicy informacyjnejj, parkingu, itp.) zmienia się na
,,Awaria“, to wznawiana jest procedura zakłóceniowa
Procedura ta umoŜliwia jednoznaczne określenie awarii (czas początku/
zakończenia awarii, skwitowanie, kategoria zakłócenia, itp.).
Elementem składowym kaŜdej procedury są meldunki robocze dotyczące obiektu,
które umoŜliwiają usunięcie zakłócenia.
Wykorzystywane są przy tym dodatkowo meldunki z bufora wejściowego
pochodzące sprzed czasu powstania zakłócenia.
KaŜda procedura usuwania zakłócenia archiwizowana jest wraz z uwagami
dotyczącymi usunięcia awarii, informacjami na temat statusu i innymi informacjami
szczegółowymi.
Do śledzenia procedury usuwania uszkodzenia dostępne są identyczne interfejsy
obsługi systemu zarządzania ruchem i systemu zarządzania w sytuacjach
awaryjnych
Wersja 4.0
151/192
11.2. Przegląd
Ustawienia administracyjne mogą być tak konfigurowane, Ŝe przedstawione i
opracowywane będą tylko Ŝądane obiekty (podział zadań, np. usuwanie zakłóceń,
oświetlenie ulic, itp.).
Zarządzanie w sytuacjach awaryjnych posiada własne archiwum procedur usuwania
zakłóceń, co sprawia, Ŝe system ten moŜe pracować niezaleŜnie od systemu zarządzania
ruchem. Z PC klienta uruchamiane jest wiele funkcji, np. monitor roboczy
i przeglądanie list.
11.3. Przegląd zakłóceń
Okienko przeglądu zakłóceń podzielone jest na dwie części. Jedna część przeznaczona
jest dla nowych meldunków. Druga, przedstawiona na rysunku 11.1, część przeznaczona
jest dla zakończonych meldunków.
Rysunek 11.1: Przegląd zakłóceń
Anstehende Storungen - Istniejące zakłócenia
Objekt-Kategorie – kategoria obiektu
Bezeichnung – nazwa
Storungskategorie – kategoria zakłócenia
Storungsbeginn – początek zakłócenia
Storung unterbrochen – zakłócenie przerwane
Storung an alle Ziele komplett gemeldet – zakłócenie zgłoszone w pełni do wszystkich jednostek
docelowych
Wersja 4.0
152/192
Keine Storungsansage – brak zapowiedzi zakłócenia
Abgeschlossene Storungen – zakłócenia zakończone
Meldunki zakłóceń przekazywane są do systemu zarządzania w sytuacjach awaryjnych
przez system zarządzania ruchem, w postaci sklasyfikowanej.
KaŜda awaria zaopatrzona jest w opis zastosowanej procedury usunięcia zakłócenia
(z podaniem numeru).
Poza tym podawane są jeszcze następujące informacje: kategoria obiektu
(charakterystyka pochodzenia), kategoria zakłócenia, oznakowanie, czas powstania awarii
(czas oryginalny) i czas usunięcia awarii, pole skwitowania, typ meldunku, stopień
istotności zakłócenia, tekst meldunku, dodatkowe parametry.
Zakończone meldunki mają jeszcze pola informacyjne, słuŜące do zakończenia awarii i
podania czasu trwania zakłócenia.
Meldunki dodatkowe do meldunku głównego OCIT przedstawiane są w sposób optyczny i
mają wspólny numer procesowy.
Przy pomocy pól kwitowania ustalane są strategie meldunkowe. MoŜna równieŜ
aktywować skwitowanie z wymuszonym skrótem nazwy uŜytkownika. Jest to moŜliwe
poprzez wprowadzenie tekstu do opisu klienta oraz podanie kodu funkcji poprzez DTMF
(wybieranie tonowe) w celu skwitowania. Stosowane są równieŜ funkcje Clip oraz
wprowadzanie Pinu.
JeŜeli w podglądzie listy pojawi się symbol, to oznacza on meldunki z istniejącymi
komentarzami. Po kliknięciu na symbol moŜna czytać treści oraz dodawać nowe
komentarze.
Pola do selekcji okresów czasowych moŜna ustawić na: dzisiaj, ostatnie 3 dni, ostatnie 7
dni i ostatnie 31 dni.
Poza tym moŜliwe jest wyszukiwanie dowolnym tekstem we wszystkich polach archiwum.
MoŜliwe są teŜ łączenia i negacje.
KaŜde zakłócenie moŜe być sygnalizowane akustycznie. Najnowsze meldunki mogą być
wyróŜniane optycznie poprzez zastosowanie innej barwy wierszy.
Luki w archiwum systemu zarządzania w sytuacjach awaryjnych (spowodowane np.
przerwami w połączeniach) uzupełniane są po przywróceniu komunikacji.
11.4. Podział meldunków i powiadamianie
W celu dokonania rozdziału meldunków instalowane są w systemie ,,skrzynki pocztowe“
(,,pojemniki“), które są zapełniane poprzez filtry.
MoŜna zdefiniować dowolną ilość skrzynek pocztowych. Odpowiednie filtry umoŜliwiają
wymagane flitrowanie niepotrzebnych meldunków. MoŜliwe jest teŜ grupowanie wielu
obiektów w jednej „skrzynce pocztowej”.
Wersja 4.0
153/192
Meldungsverteilung
filtrFilter
Mailbox 1
Output-Properties
Mailbox 2
Output-Properties
Mailbox 3
Output-Properties
Mailbox x
Output-Properties
UŜytkownik
Empfänger
Rysunek 11.2: Filtrowanie meldunków
Do kanału wyjściowego kaŜdej „skrzynki pocztowej“ moŜna podłączyć jednego lub wielu
odbiorców informacji (patrz rysunek 11.2). Poprzez charakterystykę kanału wyjściowego
określany jest moment przekazu wiadomości, np. poprzez stopień napełnienia „skrzynki”,
poprzez określenie godziny przekazu, czy teŜ poprzez treść meldunku. Plan gotowości
zapewnia dynamiczną wymianę informacji pomiędzy celami przekazu.
Filtry definiowane są poprzez klasy meldunków. Klasyfikacja nadawana jest przez system
zarządzania ruchem i stosowana jest w systemie zarządzania w sytuacjach awaryjnych.
Filtry mogą być definiowane przez operatora i wprowadzane do banku danych pod
dowolną nazwą.
Filtracja moŜe przebiegać według typów obiektów (np. LSA), okresów czasowych, czasu
trwania, kategorii, stopnia utrudnienia i charakterystyki pochodzenia (wielkości zadane
OCIT).
W zarządzaniu awaryjnym meldunki główne i dodatkowe traktowane są jednakowo i są
odpowiednio rozprowadzane przez filtry.
Zachowany pozostaje jednak związek pomiędzy meldunkami głównymi i meldunkami
dodatkowymi, poprzez nadanie im wspólnego numeru zakłócenia.
Grupy sterowników podłączone do centrali sterowania występują w systemie jako grupa
urządzeń lokalnych dla np. definicji filtracyjnych.
Filtry mogą być stosowane równieŜ do eliminacji specjalnych meldunków roboczych, np.
do odrzucania obok zakłóceń, takŜe wszystkich przełączeń ręcznych.
Specjalne meldunki, takie jak np. meldunki VA nie są filtrowane w systemie zarządzania w
przypadkach awaryjnych, lecz są kierowane do archiwum meldunków systemu głównego.
W wyniku negocjacji, tzn. wykluczania np. poszczególnych kategorii lub właściwości,
dokonywana jest konfiguracja kolejnych kryteriów filtracji.
Wersja 4.0
154/192
Oprócz duŜej ilości zdefiniowanych wstępnie filtrów (Presets) moŜna równieŜ sporządzać
indywidualne filtry poprzez odpytywanie SQL, np. specjalne odpytywanie dokonywane w
planach działania.
Istnieje moŜliwość stosowania następujących filtrów o działaniu selektywnym:
- wielokrotne meldunki zakłóceń w ustawionym czasie,
- jednokrotne meldunki w wyniku kontroli czasu i statusu obiektu
(pierwszy meldunek jest przekazywany, zaś kolejne meldunki nie są przesyłane. )
- maks. czas trwania zakłócenia
- min. i maks. ilość meldunków
11.5. Tłumiki meldunków
O kaŜdym zakłóceniu moŜe być powiadomionych do 8 odbiorców. JeŜeli uda się
powiadomić wszystkich odbiorców, to jest to dodatkowo potwierdzane w przeglądzie
zakłócenia.
Rysunek 11.3: Widok okna zdefiniowanych odbiorców meldunków – przykład z Centrum
JeŜeli np. nie moŜna osiągnąć jednego z 6 odbiorców, to następują kolejne próby
przesłania wiadomości poprzez powtarzanie wybierania w określonym okresie czasu.
Przy powiadamianiu głosowym (syntetyzator mowy z określonym tekstem)
przeprowadzana jest opcjonalnie strategia meldunkowa. Pierwszy odbiorca seryjnie
wysyłanej wiadomości moŜe dokonać zdalnego skwitowania lub potwierdzić, Ŝe przyjmuje
awarię do usunięcia.
Wersja 4.0
155/192
JeŜeli pierwszy odbiorca nie moŜe jednak tego wykonać, to następuje kontakt z drugim
odbiorcą, itd. Ten sposób nie jest moŜliwy przy kontaktach podejmowanych przez SMS,
faks lub e-mail.
Odebranie meldunku sprawdzane jest przez następujące techniki odbioru informacji:
- Serwer -e-mailowy (Intranet/LAN/SMTP)
- e-mail przez Internet (poprzez adapter DFÜ)
- SMS przez magistralę (GSM)
- FAX (przez wybraną sieć i GSM)
11.6. Plan działania
Wszystkie dane odbiorców zawarte w planie działania administrowane są w systemie
zarządzania uŜytkownikami. Osoby obsługujące system zarządzania w sytuacjach
awaryjnych mogą być traktowane równie dobrze jako odbiorcy wiadomości.
Edytowanie czasów działania (rysunek 11.4) odbywa się podobnie jak przy planowaniu
terminów MS Outlook z elementami graficznymi. Poszczególne grupy uŜytkowników mogą
być oznaczone róŜnymi kolorami.
Rysunek 11.4: Widok okna rozplanowanego czasu pracy – przykład z Centrum Zarządzania w
Berlinie
Planowanie działania umoŜliwia tworzenie róŜnych rozwiązań graficznych, np. wydruków w
formie kalendarza dla poszczególnych pracowników. Istnieje równieŜ moŜliwość
przedstawiania specyficznych zadań, np. zakresu odpowiedzialności za poszczególne
obiekty w określonym czasie (tydzień, miesiąc, kwartał, itp.)
Luki w planie działania moŜna stwierdzić wizualnie. Istnieje jednak równieŜ kontrola treści
przy tworzeniu planu działania, która pozwala wykryć ewentualne luki.
Wersja 4.0
156/192
11.7. Profile uŜytkowników
KaŜdy uŜytkownik moŜe kształtować swój indywidualny profil. Ostatnie ustawienia
obowiązujące przy wylogowaniu zapisywane są w pliku.
Po kaŜdym zgłoszeniu następuje ponowny zapis ustawień obowiązujących dla
uŜytkownika.
Ustawieniami dotyczącymi uŜytkownika są np. filtry, sposoby sortowania, szerokości
kolumn, typy kolumn, kolejności, wielkości okienek, pozycje okienek, itp.
JeŜeli powierzchnie informacyjne są za małe do przedstawienia kompletnego tekstu, to
pełny tekst przedstawiany jest w ramkach. Trzeba wykonać w tym celu dodatkowe
kliknięcie.
W ramach grupy uŜytkowników "Administrator" moŜliwe są takie zadania, jak np.
zarządzanie uŜytkownikami, zarządzanie parametrami, prowadzenie banku danych,
zarządzanie klientami, itp.
Wersja 4.0
157/192
12. Sterowniki ruchu drogowego na skrzyŜowaniach
C800V.
Nasza oferta zawiera sterowniki ruchu drogowego na skrzyŜowaniach serii SITRAFFIC
C800 w aktualnej wersji oprzyrządowania i oprogramowania firmowego. Urządzenia te
mają budowę modułową i są wyposaŜone zgodnie z wymogami skrzyŜowania.
Sterowniki posiadają obudowy z tworzywa sztucznego (IP 54).
Poprzez zastosowania odpowiedniego medium komunikacji i podzespołów na bazie PC,
realizowana jest komunikacja z komputerem sterowania ruchem na bazie standardowego
interfejsu zgodnie ze specyfikacjami OCIT.
Oferowane sterowniki spełniają opisane wymagania techniczne. W szczególności chcemy
zwrócić uwagę na następujące cechy:
•
•
•
•
Przeprowadzone badania rodzaju budowy przez TÜV InterTraffic GmbH
Bezpieczna sygnalizacja z sumaryczną kontrolą prądową (dla świateł
pomarańczowych i zielonych)
Metoda przełączania STRETCH
Współpraca w ramach algorytmu sterowania sieciowego Motion
Ze względu na zastosowany rodzaj obudowy sterownik SITRAFFIC C800V/VK/XS nie
wymaga wykonywania okablowania tylnej ścianki układów sterujących. Dlatego przy
mechanicznym montaŜu nie jest konieczna rama uchylna. Dostarczane obudowy
wykonane są w rodzaju ochrony IP54 i odpowiadają wymaganiom przetargowym.
Dokładne informacje zawarte są w załączonych opisach produktu.
Wersja 4.0
158/192
13. System zarządzania ruchem
Modułowa budowa systemu SITRAFIC pozwala na jego współpracę z innymi systemami
sterowania ruchem pojazdów.
Rysunek 13.1: Centrala systemu zarządzania ruchem (schemat moŜliwych podsystemów)
W aktualnej wersji system zarządzania ruchem SITRAFFIC CONCERT moŜe
współpracować z następującymi standardowymi systemami:
Systemy parkingowe róŜnych producentów
Komputery do sterowania ruchem Siemens SITRAFFIC Scala i VSR M
Oprogramowanie serwisowe róŜnych producentów
Centrale wydawania kwitów parkingowych
Systemy zarządzania ruchem na placach budowy róŜnych producentów
System sterowania tras o zmiennym kierunku
Swobodnie programowalne tablice informacyjne wykonane w technice LED
Serwery internetowe
Detektory stacji pomiaru danych „Traffic Eye Universal“
Wersja 4.0
159/192
Wspólne
Kernel
UTC
System
Ruch
Manage
Podsystemy
Zarz dzanie
mediami
Polecenie
Polecenie
znaku
Stacja
Przydro na
Zarz dzanie
sieci dróg
Polecenia
wyj ciow
Podsystemy
operacyjne
Kontrola
znaków
System
parkingowy
Statystyka
Raporty
porty
Wezw.
konserwat
Transport
publiczny
Archiwum
Archiwum
pomiarów
Middle
Ware
Obliczanie
syt. drog.
GIS
CCTV
Zarz dz.
zdarzenia
Szybka
baza
SICOMP
R
Przetwarz.
danych
Wykrywanie
zdarze
Obserwator
ruchu Eye
SICOMP
M
Analiza
jako ci
Wykaz
obrazów
VIZ, VRZ,
UZ
Detekcja
video
ZWD
online
Zarz dz.
strategi
trategi
Prognozo
Prognozo
wanie
P2, Q2,
Kontrola
ontrola
Online
Sipl
Archiw
Archiwum
operacyjn
Internet
Wej cie
MELD
Stacja
OCIT
RUCH
Pozio
Centrum
OCIT
Polecenia
Befa
Sterow. w
czasie
Wezwanie
pomocy
Zarz dz.
komunikat
Rysunek 13.2: Centrala systemu zarządzania ruchem (nazwy własne modułów)
SITRAFFIC CONCERT jest systemem modularnym, co sprawia, Ŝe moŜe on być dowolnie
rozbudowywany i dostosowywany do róŜnych potrzeb. System jest ciągle udoskonalany i
uzupełniany o nowe elementy.
Rozbudowa systemu powinna odbywać się w sposób obwodowy, wokół obszaru I. W
ramach podsystemów, wzdłuŜ głównych lini komunikacyjnych miasta, znaleźć się powinny
takie dzielnice, jak: Śródmieście, Ochota, Praga Północ, Praga Południe.
13.1. Podsystem CCTV
CCTV (Closed-Circuit Television) odgrywa waŜną rolę przy niepublicznym przekazie video
i jest często stosowana do kontroli ruchu drogowego w punktach naraŜonych na
powstawanie zatorów oraz w miejscach szczególnie zagroŜonych wypadkami, a takŜe w
tunelach.
Serwer systemu CCTV komunikuje się przy tym z systemem SITRAFFIC CONCERT
poprzez interfejs API. UmoŜliwia to bezpośrednie wprowadzanie do systemu
poszczególnych obrazów z nastawną częstotliwością powtórzeń. System CCTV
obsługiwany jest przy tym z reguły przez WEB klienta. UmoŜliwia to wydawanie poleceń
Wersja 4.0
160/192
sterowania PTZ (Pan/Tilt/Zoom) do podłączonego systemu CCTV. Przykładowe okno
widoku CCTV przedstawiono na rysunku 13.3.
Rysunek 13.3: CCTV – przykład z Centrum Zarządzania w Berlinie
Kamery CCTV opisane są kartą GIS poprzez listę. W karcie GIS określone są stanowiska
kamer. Status Icons kamer określa kolor, jeŜeli podsystem CCTV dostarcza tych danych.
• Kolor czerwony: kamera uszkodzona
• Kolor zielony: kamera gotowa do pracy
• Kolor szary: status nieznany
Ten sam kod barwny stosowany jest w listach. Na tej podstawie moŜna uzyskać dalsze
szczegółowe informacje dotyczące poszczególnych stanowisk (pozycja). Poprzez makra
moŜliwa jest kontrola kamer i ich ustawianie w określonym połoŜeniu, o ile interfejs CCTV
wspomaga taką funkcję.
Poza tym kamery mogą być włączone poprzez sterowanie CCTV do wykonywania innych
zadań systemu SITRAFFIC CONCERT. Poprzez system zarządzania meldunkami (patrz
0) moŜliwe jest wykorzystanie kamer do wizualnej weryfikacji zakłócenia. Makra
umoŜliwiają automatyczne wykorzystanie zalet systemu.
Alternatywą bezpośredniego uŜycia kamer jest aktywacja serwera Web systemu CCTV
GIS. UmoŜliwia to wykorzystanie wszystkich funkcji serwera Web w zakresie działań
systemu kamer.
Charakterystyka kamer
Zaproponowano zintegrowane szybkoobrotowe kamery dualne o rozdzielczości 480 linii, w
obudowach zabezpieczonych przed oddziaływaniem wilgoci, z podgrzewaniem. Obudowy
zostaną zamontowane na uchwytach montaŜowych, pozwalających na umieszczenie
kamery na słupie lub elewacji budynku. Zintegrowane szybkoobrotowe kamery są
przystosowane do zdalnego zarządzania z centrum, reagując na polecenia zmiany
Wersja 4.0
161/192
ogniskowej oraz obszaru obserwacji. Kamery wyposaŜone są w funkcję ochrony stref
prywatnych uniemoŜliwiającą naruszanie prywatności w mieszkaniach.
Dla transmisji obrazu z kamer do centrum nadzoru wykorzystana zostanie sieć
transmisyjna. Transmisja sygnałów wizyjnych z kamery w obrębie węzła drogowego do
punktu dostępowego odbywać się będzie za pomocą koncentrycznych kabli miedzianych.
System transmisji zapewnia łączność dwukierunkową - od centrum do punktów
kamerowych komendy sterujące urządzeniami, w przeciwnym kierunku - transmisja
obrazu. Lokalizację kamer na skrzyŜowaniach z obszaru I przedstawiono na rysunku 13.4.
Sterowanie ruchomych punktów kamerowych
System transmituje obrazy z kamer centrum nadzoru w czasie rzeczywistym, umoŜliwiając
operatorowi równoczesny podgląd wszystkich kamer. W skład wyposaŜenia centrum
wchodzą pulpity operatorskie słuŜące do sterowania kamerami umoŜliwiające manipulację
kamerami (obroty, zoom, przełączanie obrazów pomiędzy poszczególnymi stanowiskami
itp.) Oprogramowanie zarządzające pracą systemu zapewnia funkcję dzielenia obrazu
oraz sprawne zarządzanie plikami z nagraniami.
Rejestracja sygnałów wizyjnych
Rejestratory cyfrowe umoŜliwiają zapis obrazów na dysku w postaci cyfrowej min z 30 dni
przy odświeŜaniu min 1 klatka na sek., przy pełnej rozdzielczości kamer i min. 256
kolorach/stopniach szarości. Obrazy video są nagrywane jako sekwencje o definiowanej
długości, opatrzone numerem kamery, datą i godziną rejestracji. Parametry kompresji
(liczba klatek, rozdzielczość, liczba kolorów) jest programowana w programie kodującym.
Wersja 4.0
162/192
Rysunek 13.4: Propozycja lokalizacji kamer
Wersja 4.0
163/192
13.2. Interfejs tablic informacyjnych
Do sterowania tablicami informacyjnymi słuŜy systemowi SITRAFFIC CONCERT
standardowy interfejs XML, który spełnia następujące wymagania:
• Zgodność z krajowymi i międzynarodowymi standardami, dotyczącymi róŜnych
projektów
• NiezaleŜność producenta
• MoŜliwość rozbudowy projektu
• Wolność licencji
• Zgodność z OSI
• Czytelność bez specjalnych narzędzi
• Asynchroniczny mechanizm komunikacji
• NiezaleŜność platformy
• Stan technologii
• Bezpieczna przyszłość
System SITRAFFIC CONCERT spełnia te podstawowe wymagania przy pomocy
otwartego interfejsu XML Schnittstelle (Extensible Markup Language), który
ukierunkowany jest specjalnie na te potrzeby i umoŜliwia np. przekazywanie stanów
roboczych tablic informacyjnych z serwera do systemu SITRAFFIC CONCERT. W ten sam
sposób moŜliwe jest wysyłanie rozkazów sterowania z systemu SITRAFFIC CONCERT do
serwera tablic informacyjnych. Jako protokół transportowy stosowany jest protokół SOAP
(Simple Object Access Protocol). Interfejs jest otwarty i moŜe być wykorzystywany przez
innych producentów poprzez stosowanie własnego serwera.
UmoŜliwia to komunikację serwera tablic informacyjnych z tablicami w protokołach
sporządzanych w języku kraju ich stosowania. Tak zwany interfejs SoapServer spełnia
następujące funkcje:
• UmoŜliwia dostęp do danych systemu SITRAFFIC CONCERT (poprzez
system zarządzania zapisywane są wszystkie dane dynamiczne w
określonych punktach)
• Zapewnia kontrolę dostępu do archiwum danych
• Kontrola Timeout dla kaŜdego klienta
Sterowanie tablic informacyjnych jest realizowane poprzez zastosowanie serwera
spełniającego wymagania producenta. Serwer ten przejmuje niezawodną kontrolę stanu
roboczego tablic informacyjnych i związane z tym sterowanie. Serwer podłączany jest
przez Ethernet na bazie http przez TCP/IP.
KaŜdy rozkaz operatora prowadzi w ramach systemu SITRAFFIC CONCERT do
wykonania przełączenia na interfejsie SOAP. Rozkaz zostaje przekazany poprzez SOAP
(put) drogą ethernetową do serwera tablicy informacyjnej. Serwer tablicy informacyjnej
przetwarza odpowiednio rozkaz i powoduje wyświetlenie odpowiedniej treści na tablicy
informacyjnej. Jako potwierdzenie otrzymania rozkazu serwer tablicy informacyjnej wysyła
ponownie rozkaz SOAP (put result) do interfejsu SOAP systemu SITRAFFIC CONCERT.
W kolejnym kroku klienta SOAP serwera tablicy przekazywane jest do SITRAFFIC
CONCERT potwierdzenie dokonania wyświetlenia na tablicy i przekazywana jest
odpowiednia informacja statusowa.
System SITRAFFIC CONCERT potwierdza ten meldunek przez put result. Stanowi to
potwierdzenie wykonanej operacji.
W przypadku braku potwierdzenia zwrotnego przez serwer tablicy informacyjnej, czynność
powtarzana jest wielokrotnie. JeŜeli zakończy się to niepowodzeniem, to status
Wersja 4.0
164/192
odpowiedniej tablicy w systemie SITRAFFIC CONCERT będzie wskazywał błąd i operator
otrzyma informację zaznaczoną kolorem o wprowadzeniu do archiwum meldunków
roboczych lub do archiwum stanów rzeczywistych.
JeŜeli system SITRAFFIC CONCERT nie wysyła Ŝadnych rozkazów przełączania, to
serwer tablic informacyjnych melduje w regularnych odstępach czasu stan (Status) tablic.
Automatyczne meldunki ostrzegawcze wysyłane są równieŜ do systemu SITRAFFIC
CONCERT wówczas, gdy tablica zmienia swój status z jakiegokolwiek powodu lub gdy
zmieniana jest treść tablicy informacyjnej, czy teŜ gdy nie jest osiągalny serwer tablicy
informacyjnej. W wyjątkowych przypadkach, gdy nie jest moŜliwy dostęp do systemu
SITRAFFIC CONCERT, tablice informacyjne przełączane są automatycznie na treść
domyślną.
13.3. Zarządzanie meldunkami
System SITRAFFIC CONCERT zawiera wiele funkcji zarządzania meldunkami, które
wspomagają operatora w codziennej pracy. Funkcja meldowania umoŜliwia dynamiczne
zarządzanie zdarzeniami mającymi miejsce w ruchu drogowym w dowolnej formie. Oprócz
meldowania istnieje moŜliwość zgłaszania do systemu SITRAFFIC CONCERT
rozpoznanych przez podsystemy zakłóceń, definiowania i edytowania nowych
dodatkowych zdarzeń.
Mogą one być przedstawiane tabelarycznie lub na karcie cyfrowej, czy teŜ prezentowane
w mediach. Przykładowy widok okna z listą meldunków pokazano na rysunku 13.5. Poza
tym meldunki mogą być włączane do zarządzania strategicznego.
Zarządzanie meldunkami zawiera w sobie z jednej strony moŜliwość wpływania na ruch
drogowy, a z drugiej strony wewnętrzne zarządzanie wszystkimi nadchodzącymi
meldunkami.
Rysunek 13.5: Przegląd meldunków (Lista)
Name – nazwa
Quelle – źródło
Subtyp – podtyp
Schwere – waga, znaczenie
Von – od
Bis – do
Wersja 4.0
165/192
Stadt – miasto
Bezirk – dzielnica
Alles – wszystko
Zukunftig – w przyszłości
Storung – zakłócenie
Stark – silne
Meldunki mogą być przejmowane z róŜnych podsystemów bezpośrednio do systemu
SITRAFFIC CONCERT. Są one natychmiast rejestrowane i odpowiednio klasyfikowane.
Wymiana meldunków następuje z reguły poprzez otwarty, standardowy interfejs
SOAP/XML i musi odbywać się zgodnie z załoŜeniami projektowymi podłączonego
systemu.
Oprócz automatycznego przejmowania system oferuje moŜliwość ręcznego nadawania
meldunków przez operatora. SłuŜą do tego odpowiednie narzędzia. System zarządzania
meldunkami umoŜliwia wgląd we wszystkie meldunki znajdujące się w systemie. Meldunki
te mogą być wyświetlane lub edytowane.
Rysunek 13.6: Szczegóły meldunku
Meldungstyp – rodzaj zgłoszenia (meldunku)
Name – nazwa
Gultigkeit – waŜność (obowiązywanie)
Lage - połoŜenie
Umleitung – objazd
Aktionsplane – plany działania
Kameras – kamery
Letzter Bearbeiter - ostatni edytor
Letzte Anderung – ostatnia zmiana
Estellungsgrund – przyczyna sporządzenia
Quelle – źródło
Schwere – znaczenie
Beschreibung – opis: planowana impreza sportowa, obwodnica Kaiser-Fridrich zamknięta
Veranstaltung – impreza
Wersja 4.0
166/192
W szczegółach meldunku (rysunek 13.6.) podane są ogólne informacje dotyczące
meldunku, takie jak: obowiązywanie, pozycja, redakcja, zakres rozpowszechniania, plany
działania itp. Punkty te zostaną dokładniej wyjaśnione w następnych rozdziałach.
Gdy tylko meldunek dotrze do systemu lub zostanie zaimportowany, jest on zapisywany
pod jednoznacznym numerem identyfikacyjnym w archiwum roboczym i archiwum ruchu
drogowego. Tym samym jest on dostępny w systemie dla wszystkich operatorów
(klientów). Dodatkowo wszystkie meldunki importowane przez podsystemy mogą być
weryfikowane i klasyfikowane przez operatora przed ich ostatecznym zapisaniem w
systemie. W archiwum meldunków roboczych zapisywane są przede wszystkim czynności
związane z zarządzaniem meldunkami. Wyszukiwanie meldunków umoŜliwiają liczne
funkcje wyszukiwania i funkcje filtracyjne. Funkcja wyszukiwania obejmuje wszystkie
aktualne i historyczne meldunki robocze. Istnieje moŜliwość czasowego rozgraniczenia
zdarzeń. Wyszukiwanie moŜe następować w oparciu o róŜne kryteria (np. operator,
przedział czasowy, itp.) Wynik wyszukiwania moŜe być poddany dalszej filtracji w ramach
narzędzi, jakimi dysponuje archiwum meldunków roboczych.
W archiwum meldunków przechowywany jest kaŜdy meldunek wraz ze szczegółowymi
informacjami.
MoŜna w nim wyszukiwać meldunki w celu dokonania w nie wglądu lub w celu ich
odtworzenia wg:
• ID
• Typ meldunku/podtyp
• Opis
• Kategoria i podkategoria
• Operator
• Stopień waŜności
• Okres obowiązywania
Przykładowy widok okna wyszukiwania meldunków pokazano na rysunku 13.7.
Rysunek 13.7: Wyszukiwanie w archiwum meldunków
Storungen – zakłócenia
Unfall – wypadek
Veranstaltungen – imprezy
Sportveranstaltungen – impreza sportowa
Wersja 4.0
167/192
Baustellen – place budowy
Strassenbau – roboty drogowe
Operatormeldungen – meldunki operatora
Summenmeldungen – meldunki sumaryczne
13.3.1. Informacja ogólna
Nadawane meldunki dzielą się na następujące typy:
• Miejsce budowy (budowa, prace rozbiórkowe, itp.)
• Impreza (koncert, wydarzenie sportowe, demonstracja, itp.)
• Zakłócenie (wypadek, zator na drodze, itp.)
• Meldunek operatora (meldunek bez zapisu w karcie)
KaŜdy meldunek przedstawiany jest w karcie meldunków odpowiednio do typu meldunku,
z podaniem własnego, charakterystycznego symbolu.
Poza typem meldunku następuje wskazanie jego rozszerzenia w sieci drogowej.
Dodatkowo podawany jest czas waŜności meldunku. Na rysunku 13.8 przedstawione są
róŜne typy meldunków i sposób ich zamieszczenia w karcie:
Symbol
Nazwa
Rysunek 13.8: Symbole meldunków (przykład z opisami niemieckimi)
Oznakowanie odcinka trasy symbolizuje obszar, którego dotyczy zakłócenie. Oznakowanie
moŜe dotyczyć obydwu stron odcinka trasy lub tylko jednej strony. Kolor symbolu informuje
o aktualności zdarzenia.
Meldunkom mogą być przyporządkowane róŜnego typu atrybuty, takie jak:
Zakres obowiązywania
Odniesienie
Kategoria sygnalizacji
Meldunki zapisywane są w systemie z podaniem jednoznacznej nazwy. KaŜdy meldunek
jest klasyfikowany poprzez określenie typu i kategorii meldunku. Dodatkowo moŜna podać
stopień istotności zakłócenia. PoniŜsza tabela daje przegląd moŜliwych meldunków.
Klasyfikacja moŜe być w kaŜdej chwili dostosowana przez administratora lub operatora,
posiadającego odpowiednie uprawnienia, do standardów obowiązujących w danym kraju
lub mieście. Kategoria stanowi istotny element meldunków. Oprócz charakteru
informacyjnego podanie kategorii meldunku umoŜliwia włączenie go do systemu
zarządzania strategicznego (patrz 13.3.5) i pozwala zadecydować, które meldunki mają
być kierowane do zarządzania medialnego (patrz 13.3.8).
Typ sygnalizacji Kategoria meldunku
Budowa
nieokreślona
Budowa kanału
Budowa drogi
Metro
Przygotowanie miejsca
budowy
Wpływ
zakłócenia
nieokreślony
silny
średni
słaby
Podkategoria
Zator
Lewy pas ruchu
Prawy pas ruchu
Środkowy pas ruchu
Wszystkie pasy ruchu
Obydwa lewe pasy
ruchu
Wersja 4.0
168/192
Impreza
nieokreślona
Impreza sportowa
Koncert
Demonstracja
Parada uliczna
Nieokreślony
silny
średni
słaby
Awaria
nieokreślona
Wypadek
Wypadek z obraŜeniami
osób
Wypadek bez obraŜeń osób
Korek
nieokreślony
silny
Zator
Lewy pas ruchu
Prawy pas ruchu
Środkowy pas ruchu
Obydwa lewe pasy
ruchu
Zator
Lewy pas ruchu
średni
Prawy pas ruchu
słaby
Środkowy pas ruchu
Obydwa lewe pasy
ruchu
nieokreślony
Zator
Stojący pojazd
Meldunek
operatora
nieokreślony
Czas podróŜy
silny
Meldunek transport zbiorowy średni
Ręczniy meldunek - Pogoda słaby
Lewy pas ruchu
Prawy pas ruchu
Środkowy pas ruchu
Obydwa lewe pasy
ruchu
Meldunki mogą mieć zweryfikowany lub nie zweryfikowany status. Operator informowany
jest poprzez kolor meldunku, czy wymaga on sprawdzenia przy pomocy kamer lub innymi
metodami. Jest to szczególnie waŜne w przypadku meldunków importowanych przez
system samodzielnie lub poprzez subsystemy. W oddzielnym okienku moŜna dokonać
wizualizacji wszystkich nie weryfikowanych meldunków.
13.3.2. Obowiązywanie meldunku
Przy nadawaniu meldunku konieczne jest podanie okresu jego obowiązywania. Okres
obowiązywania meldunku określany jest poprzez podanie dokładnego czasu zegarowego
rozpoczęcia i końca obowiązywania (0-24 godz.). Dla kaŜdego meldunku moŜna
zdefiniować wiele okresów obowiązywania. Meldunek zaznaczany jest w karcie zgodnie z
jego aktualnym statutem. Meldunki powtarzane zaznaczane są innym kolorem.
Barwa symbolu i odcinka trasy informuje o aktualności meldunku. RozróŜnia się
następujące przyporządkowanie kolorów:
= Nieznana
= W przyszłości
= Przerwana
= Aktywna
= Zakończona
= Niezweryfikowana
Rysunek 13.9: WaŜność meldunku
Wersja 4.0
169/192
Po upływie okresu obowiązywania meldunku moŜna go automatycznie skasować.
Przy kasowaniu meldunków moŜna zastosować zwłokę, tzn. Ŝe meldunek jest kasowany
po przekroczeniu n dni od daty upływu jego waŜności.
13.3.3. Obszar obowiązywania meldunku
Obszar lub odcinek obowiązywania meldunku przedstawiony zostaje na mapie (przykład
przedstawiono na rysunku 13.10).
Dotyczy jednego kierunku
Dotyczy obydwu kierunków
Rysunek 13.10: Obszar obowiązywania meldunku
Geograficzne odniesienie meldunku określane jest przy jego edytowaniu lub jest
dodawane po jego sporządzeniu. Istnieją zasadniczo trzy moŜliwości określenia obszaru
obowiązywania meldunku. Wszystkie te moŜliwości wykazują się jednakową dokładnością
pozycjonowania.
•
•
•
Ręczne pozycjonowanie w GIS
Wybór z listy ulic
Wstępnie zdefiniowane pozycje
Przy ręcznym pozycjonowaniu następuje po kliknięciu myszą bezpośrednie określenie na
mapie odcinka, którego dotyczy zdarzenie w ruchu drogowym.
MoŜna to przedstawić graficznie odnośnie jednej lub obydwu stron rozpatrywanego
odcinka trasy.
Przy wyborze nazw ulic z listy konieczne jest podanie kierunku. Określenie wpływu
zdarzenia na ruch drogowy wymaga dodatkowych informacji dotyczących odcinka
pomiędzy skrzyŜowaniami ulic.
Numeracja domów moŜe być ujęta w formie stosowanej dla miejsc budowy.
Alternatywnie moŜliwe jest pozycjonowanie meldunków poprzez listę linków IDs.
Poza tym istnieje w systemie zarządzania meldunkami moŜliwość zmiany pozycji
zdefiniowanych na liście. Przy tym następuje odniesienie do dokładnie zdefiniowanych na
liście odcinków trasy z określonym kierunkiem i jednoznaczną nazwą słuŜącą do
identyfikacji.
13.3.4. Dodatkowe informacje
KaŜdy meldunek moŜe być opatrzony dodatkowym tekstem. SłuŜy do tego oddzielne pole
tekstowe.
Wersja 4.0
170/192
Przy nadawaniu meldunku operator lub redaktor tekstów dotyczących ruchu ma moŜliwość
wprowadzania ograniczeń stworzonych przez zdarzenia mające miejsce w ruchu
drogowym. Ograniczenia te traktowane są jako uzupełnienia meldunków. Ograniczenia
mogą dotyczyć ilości dostępnych pasów jezdni, ilości wyłączonych z ruchu pasów jezdni,
zwęŜeń pasów jezdni, ograniczeń prędkości i zakazów wyprzedzania.
Wszystkie wyŜej wymienione informacje mogą być połączone automatycznie z
odpowiednimi meldunkami medialnymi w zleceniach medialnych (patrz 13.3.8)
13.3.5. Włączanie meldunku do planów działania
Do wszystkich meldunków mogą być przyporządkowane wstępnie zdefiniowane plany
działania w ilości jeden lub wiele. Stwarza to moŜliwość aktywnego włączenia zarządzania
meldunkami w system zarządzania strategicznego. Przyporządkowane plany działania
mogą zawierać dowolne akcje. Akcje te wykonywane są automatycznie, w połowie
automatycznie lub po potwierdzeniu przez operatora, gdy tylko meldunek dotrze do jego
obszaru kompetencji. Przykładowe okno wizualizacji zdefiniowanego planu działania
pokazano na rysunku 13.11.
Rysunek 13.11: Okno wizualizacji zdefiniowanego planu działania przy wystąpieniu
określonego meldunku – przykład z Centrum Zarządzania w Berlinie
Typowym przykładem zastosowania są miejsca budowy i planowane imprezy. Czas
obowiązywania meldunku uzyskuje status meldunku przyszłego. Odpowiednio do
meldunku definiowany jest plan działania, który wraz ze zmianą stanu zmienia swój status
z ,,przyszłego” na ,,aktywny”. Tym samym tablice informacyjne mogą informować
automatycznie o aktualnych i przyszłych miejscach budowy.
JeŜeli meldunek straci waŜność, plan działania ulega zakończeniu automatycznie lub po
dodatkowym potwierdzeniu przez operatora.
Wersja 4.0
171/192
Przyporządkowanie planu działania do meldunku moŜe odbywać się metodą ręczną lub
automatyczną. Przy stosowaniu metody ręcznej operator wybiera plany działania z
istniejącej listy. Przy automatycznym przyporządkowywaniu do planu działania musi być
przypisana jednoznaczna lokalizacja oraz podkategoria (np. prawy pas jezdni).
Gdy tylko meldunek zostanie podany przez operatora w tym samym miejscu z tą samą
kategorią, lub gdy zostanie wygenerowany przez system, jest on automatycznie
przyporządkowywany do odpowiedniego planu działania. MoŜna w ten sposób
opracowywać wstępnie odpowiednie strategie dla punktów szczególnie naraŜonych na
wypadki i minimalizować ich wpływ na przebieg ruchu drogowego. JeŜeli operator otrzyma
meldunek o wypadku w tym miejscu, to system podejmuje odpowiednie działania.
Meldunek o wypadku moŜe być przekazany automatycznie mediom wraz jego lokalizacją i
przewidywanymi skutkami.
NajbliŜsza kamera moŜe dokonać weryfikacji zdarzenia i odpowiednie tablice informacyjne
oraz inne urządzenia drogowe mogą ostrzec zbliŜające się do miejsca wypadku pojazdy
lub zarządzić objazd miejsca wypadku.
Zewnętrzny interfejs dostarcza meldunki ze wszystkimi atrybutami. Meldunki są
lokalizowane na podstawie nazw ulic (od – do), kierunku i numeru identyfikacyjnego. Poza
tym następuje lokalizacja w oparciu o współrzędne geograficzne w odnośnym systemie
geodezyjnym. Pozwala to wykorzystać informacje pochodzące z systemu zarządzania
ruchem w zewnętrznym systemie (np. w serwerze internetowym do przedstawienia sytuacji
panującej w ruchu drogowym).
13.3.6. Powiązanie z CCTV
Wszystkie meldunki mogą być powiązane równieŜ z systemem kamer obserwujących ruch
drogowy. Przy aktywacji kamery przez meldunek następuje przesłanie obrazu z kamery do
centrali. W zaleŜności od systemu monitoringu moŜliwa jest bezpośrednia kontrola poprzez
ten system kamer, jak teŜ kontrola działania kamer. Przykładowy widok stanu kamery
pokazano na rysunku 13.12
Rysunek 13.12: Powiązanie z CCTV
Wersja 4.0
172/192
Name – nazwa
Standort – lokalizacja
Beschreibung - opis
13.3.7. Zarządzanie meldunkami i rozpoznawanie zakłóceń
System zarządzania meldunkami moŜe współdziałać z automatycznym wykrywaniem
zakłóceń. Pozwala to w znacznym stopniu usprawnić pracę centrali ruchu drogowego.
Zakłócenie w ruchu drogowym zdefiniowane jest jako niezaplanowane zdarzenie mające
wpływ na ruch drogowy.
Zakłócenie ma miejsce wówczas, gdy rzeczywisty przebieg ruchu odbiega od
oczekiwanego.
Rozpoznanie zakłócenia moŜe zostać zrealizowane poprzez ocenę róŜnych wartości
mierzonych dostarczonych przez detektory i kamery wideo, poprzez stosowanie
specjalnych algorytmów. Stosowane algorytmy są róŜne dla autostrad i dla dróg szybkiego
ruchu oraz dla obszarów miejskich.
Oprócz obliczeń dotyczących zakłócenia w ruchu drogowym, obliczane jest równieŜ
prawdopodobieństwo wystąpienia zakłócenia.
Wszystkie zakłócenia zgłaszane przez automatyczny system wykrywania zakłóceń
prezentowane są na liście systemu zarządzania meldunkami.
Zakłócenie definiowane jest przy tym jako meldunek, gdy określona wartość progowa
przekroczy stopień prawdopodobieństwa nastąpienia wypadku.
Operator moŜe weryfikować i klasyfikować automatycznie generowane meldunki o
zakłóceniach według określonej procedury (np.za pomocą kamer lub meldunków
otrzymywanych z pojazdów słuŜbowych).
Istnieje moŜliwość wprowadzania dodatkowych danych. W wyniku klasyfikacji moŜna
automatycznie włączyć meldunek do wstępnie zdefiniowanego planu działania.
Akcje przewidziane w planie działania mogą być wykonywane automatycznie lub po
potwierdzeniu przez operatora.
Rozpoznany przez system przypadek zakłócenia utrzymywany jest jako aktualny przez 24
godziny. Operator moŜe określić rzeczywisty czas jego trwania.
13.3.8. Automatyczne wysyłanie zleceń medialnych
Meldunki mogą być wysyłane bezpośrednio poprzez zdefiniowane wstępnie zlecenia.
W taki sposób moŜliwe jest na przykład przekazywanie nowych meldunków do stacji
radiowych i urzędów miejskich. Zlecenia medialne mogą być aktywowane bezpośrednio z
systemu zarządzania meldunkami. Wybrane meldunki wysyłane są automatycznie pod
określone w zleceniu adresy.
W zleceniu medialnym moŜliwa jest dodatkowa filtracja meldunków według ich kategorii i
wpływu na ruch drogowy. Poszczególni adresaci mogą otrzymywać zestaw odpowiednich
dla nich meldunków (w sprawie dodatkowych informacji patrz równieŜ 13.4).
Wersja 4.0
173/192
13.4. Zarządzanie medialne
Moduł zarządzania medialnego umoŜliwia automatyczny lub ręczny wybór informacji z
SITRAFFIC CONCERT i przekazywanie aktualnych informacji o ruchu drogowym do
róŜnych środków masowego przekazu.
Otrzymane i ocenione informacje przekazywane są do róŜnych mediów, takich jak: radio,
fax, e-mail lub Internet i mogą być poddawane specjalnemu przygotowaniu. Uwzględnia
się przy tym ręczne wprowadzanie informacji, np. o budowach i utrudnieniach w ruchu
drogowym.
SITRAFFIC CONCERT pozwala na uzyskanie w kaŜdym momencie aktualnego raportu o
stanie ruchu.
Aby wystawić zlecenie medialne trzeba wykonać następujące czynności:
•
Wystawienie zlecenia: ustalenie treści dokumentu oraz czasu jego publikacji.
Czas ten moŜe być wybierany ręcznie lub zaleŜeć od zdarzenia, bądź być
zdefiniowany poprzez z góry załoŜony plan.
Przy wystawianiu zlecenia uwzględniane są określone moduły tekstowe zawarte w
formularzu meldunkowym.
Moduły tekstowe mogą składać się z wolnego tekstu lub z kombinacji wolnego
tekstu i zdefiniowanych bloków tekstowych. MoŜliwe jest równieŜ wprowadzanie
grafiki oraz zmiennych systemowych, które wypełniane są dynamicznie przy
wysyłaniu zleceń medialnych. Warunki zarządzania medialnego mogą być równieŜ
definiowane przez JavaScripts. Szerokie moŜliwości filtracji pozwalają na
uzyskanie jasnej definicji określającej treść meldunków i ich adresy. I tak na
przykład mogą być wysyłane jedynie nowe meldunki, meldunki dotyczące miejsc
budowy lub meldunki o stanie ruchu drogowego.
Rysunek 13.13: Przetwarzanie meldunku medialnego
Wersja 4.0
174/192
Tłumaczenie meldunku:
Empfänger: STADT ABC - Odbiorca: miasto ABC
Zeit: 02.12.2005, 14:56:36 - Czas: 02.12.2005, 14:56:36
Betreff: Baustelle – Asphaltierung A96 – Dotyczy:Budowy – asfaltowanie A96
Schwere: stark - Znaczenie: duŜe
Quelle: Koncert - Źródło: concert
Bearbeiter: Admin - Edytor: administrator
Subtyp: Straβenbau; Id: 0 - Podtyp: prace drogowe; Id 0
Status: Aktiv - Status: aktywny
Änderung: 02.12.2005 14:56 - Zmiany: 02.12.2005 14:56
Gültigkeit - Okres obowiązywania
Start 02.11.2005 00:00 - Początek: 02.11.2005 00:00
Ende 10.12.2005 00:00 - Koniec: 10.12.2005 00:00
Tägliche Gültigkeit - Okres obowiązywania w ciągu dnia: .........
Lokalizacja
Miasto: ABC
Dzielnica: ...
Typ: selekcja
Droga: A 61, jedna strona
Ograniczenia: zablokowane pasy 1 -3
ograniczenie prędkości
zwęŜenie pasa
zakaz wyprzedzania
maksymalna szerokość lewego pasa 2,5 m
Opis
Odnowienie warstwy nośnej asfaltu na prawym pasie
Objazd:
Objazd moŜliwy tylko w ograniczonym zakresie, naleŜy się liczyć z utrudnieniami ruchu
Redakcja
Wprowadzono 2.11
Z powaŜaniem
………………………………………….
•
Wstępne przetwarzanie meldunku: Po wystawieniu zlecenia wystawiany jest
dokument HTML, który moŜe być edytowany ręcznie. Na tym etapie dokument ten
zawiera jeszcze zmienne. Krok ten ma charakter opcjonalny i umoŜliwia szybkie
dopasowanie zlecenia medialnego bez konieczności tworzenia od początku
kompletnego formularza.
•
Opracowanie końcowe: Przy opracowywaniu końcowym wyświetlany jest dokument
HTML z treścią meldunku wysyłanego do odbiorcy.
Zmienne zostały zamienione w tym dokumencie przez wartości i
przyporządkowane teksty. Istnieje jeszcze moŜliwość skontrolowania meldunku
medialnego i dokonania ewentualnych zmian. Krok ten ma charakter opcjonalny.
•
•
Wysyłanie meldunku: Meldunek wysyłany jest do wybranego odbiorcy. Skuteczne,
bądź nieudane wysłanie protokołowane jest w archiwum roboczym.
Wersja 4.0
175/192
Wszystkie przekazane zlecenia medialne przechowywane są w archiwum
medialnym z podaniem nazwy, adresu, daty, godziny i treści.
Zlecenia medialne mogą być równieŜ wysyłane bezpośrednio z systemu
zarządzania medialnego (patrz 13.3.8).
13.5. System informacji środowiskowej
Moduł systemu informacji środowiskowej umoŜliwia pobieranie danych na temat warunków
środowiskowych do systemu zarządzania ruchem; moŜna je wykorzystywać do
wyświetlania informacji o warunkach środowiskowych (np. ostrzeŜenie o gołoledzi) na
zmiennych znakach stacji pogodowych lub na stronie systemu informacji drogowej.
SprzęŜenie danych z serwera środowiskowego miasta z systemem CONCERT
realizowane jest poprzez interfejs SOAP-XML. Analiza danych i ich dalsze przetwarzanie
w systemie zarządzania ruchem, a takŜe ich przekazywanie do obu wyŜej wymienionych
podsystemów, odbywa się z wykorzystaniem planów odpowiedzi.
13.6. Panel Wizualizacyjny
Ściana graficzna składa się z 6 elementów kaŜdy o przekątnej 50” oraz rozdzielczości
XGA (1024x768). Sposób łączenia jest bezszwowy tj. szczelina pomiędzy ekranami
< 1mm (około 0.8mm). Szerokość całkowita ekranu 3mx1.5m (szerokość x wysokość),
rozdzielczość całkowita 3072x1536 pixeli, przekątna całkowita ekranu 3.35m. Jasność
ekranów 750 ANSI lumenów, kontrast 1500:1, wypełnienie całościowe pojedynczego
ekranu 95% powierzchni pojedynczego projektora. Pobór mocy dla całości systemu
6x200W + kontroler 250W razem 1450W. Kąt widzenia dla operatora w pionie, poziomie
160x160 stopni. Poziom hałasu < 40dB. Projekcja DLP na układzie DMD 0.7”. Czas Ŝycia
lamp 10000h, typ lampy UHP.
Ekrany są zamontowane na podstawie gwarantującej optymalny kąt patrzenia dla
operatorów. Proponujemy, aby dolna krawędź ekranu została ustalona po wizycie lokalnej
na obiekcie. Czynności serwisowe są wykonywane po zdjęciu tylnej obudowy projektora.
Pomieszczenie, w którym zostanie zamontowany system nie moŜe być mniejsze niŜ
wysokość całkowita systemu oraz wysokość podstawy. Pomieszczenie powinno być
klimatyzowane, a jeŜeli nie, to powinno się oddzielić projektory od części uŜytkowej w
mniejszym pomieszczeniu, w którym powinno się zamontować klimatyzator podręczny.
Odległość od tylnej obudowy projektora a ścianą pomieszczenia powinno wynosić
przynajmniej 1m. KaŜdy z projektorów (lampa) wydziela około 100W ciepła. Na rysunku
13.4 pokazano wymiary 1 elementu ściany graficznej oraz widok po złoŜeniu kilku
elementów.
Rysunek 13.14: Panel Wizualizacyjny
Wersja 4.0
176/192
13.7. System Sterowania i Monitoringu Tunelu w Zagłębieniu
Wisłostrady
System sterownia
Obecnie zainstalowany system sterownia ruchem zostanie rozbudowany o funkcje
komunikacyjne z proponowanym systemem wideo monitoringu. Na podstawie informacji z
systemu wideo monitoringu oraz istniejącego systemu detekcji będą podejmowane
odpowiednie decyzje.
System sterowania zostanie rozbudowany o funkcje archiwizujące działanie systemu.
W centrum zarządzania ruchem zostanie zainstalowany zdalny pulpit sterowniczy.
Operator będzie miał moŜliwość przeglądu wszystkich funkcji systemu, zdarzeń i alarmów,
wprowadzania parametrów pracy oraz wydawania ręcznych komend sterujących. System
będzie przekazywał informację do systemu nadrzędnego poprzez jeden z otwartych
protokołów wymiany danych.
System wideo monitoringu
System realizuje detekcję zdarzeń, opartą na analizie obrazów wizyjnych z kamer, oraz
cyfrową rejestrację obrazów. Oprogramowanie umoŜliwia pełną kontrolę i zarządzanie
systemami detekcji zdarzeń i zapisu cyfrowego oraz urządzeniami transmisji. System
złoŜony jest z detektora wizyjnego SISTORE SX SiADS, centralnego serwera komunikacji
Cluster Server, stacji klienckich zlokalizowanej w centrum nadzoru oraz urządzeń
zewnętrznych (kamery, nadajniki/odbiorniki video, serwery wideo, etc.).
Wykryte zdarzenia sygnalizowane są na ekranie stacji klienckiej w centrum nadzoru w
postaci wiadomości alarmowych, jak równieŜ na graficznym schemacie, na którym
prezentowane są alarmy.
Detekcję zdarzeń oraz rejestrację cyfrową realizują 19" przemysłowe detektory wizyjne
SISTORE SX SiADS, pracujące w sieci Ethernet. Do kaŜdego detektora wizyjnego
SISTORE SX SiADS, realizującego detekcję zdarzeń i rejestrację obrazów, moŜe zostać
podłączonych osiem analogowych sygnałów wizyjnych.
Cluster Server realizuje równieŜ funkcje serwera sieciowego WebServer. Serwer sieciowy
umoŜliwia prostą integrację i zarządzanie systemem w ramach sieci LAN. Zdalna kontrola i
administracja systemem z poziomu centrum nadzoru odbywa się przez centralny serwer
komunikacji.
13.8. Tablice informacyjne
Charakterystyka techniczna znaków zmiennej treści
Znaki zmiennej treści spełniają wymagania normy PN-EN-12966 oraz Rozporządzenia
Ministra Infrastruktury z dnia 3 lipca 2003r. w sprawie szczegółowych warunków
technicznych dla znaków i sygnałów drogowych oraz urządzeń bezpieczeństwa ruchu
drogowego i warunków ich umieszczania na drogach.
Właściwości optyczne:
•
•
•
sterowanie diodami: statyczne z kontrolą prądową,
trwałość diod LED: nie mniejsza niŜ 100 000 godzin,
luminancja: zgodnie z klasą L3 według PN-EN-12966,
Wersja 4.0
•
•
•
•
•
177/192
pionowy i poziomy kat rozsyłu światła: zgodnie z klasą B4 według PN-EN-12966,
współczynnik luminancji: zgodnie z klasą R2 według PN-EN-12966,
równomierność rozsyłu światła: < 3 według PN-EN-12966,
kontrola kolorystyki kaŜdego piksela: 16 poziomów dla kaŜdego podstawowego koloru,
automatyczna regulacja jasności (256 kroków) poprzez czujnik oświetlenia
zewnętrznego (umieszczony od frontu oraz z tyłu znaku) oraz zdalnie przy
wykorzystaniu protokołu komunikacyjnego,
Maksymalny pobór prądu przez diody LED: < 20 mA.
Właściwości techniczne i funkcjonalne:
•
•
•
budowa modułowa,
mikroprocesorowa jednostka sterująca, oprogramowanie z funkcją watch-dog,
wewnętrzny system diagnostyczny do kontroli obecności napięcia sieci, temperatur
wewnątrz obudowy znaku.
Właściwości środowiskowe:
•
•
•
temperatura otoczenia: zgodne z klasą T2 według PN-EN-12966,
wilgotność otoczenia: do 95%,
klasa szczelności obudowy: IP-55 (P2 według PN-EN-12966),
Charakterystyka techniczna kontrolera VMS Controller
•
•
protokół TCP/IP
wbudowany modem GPRS - modemy GPRS są przewidziane do zastosowania tylko
dla komunikacji z jedną Tablicą informacyjną (rysunek 13.18, lokalizacja przed Mostem
gen. Grota – Roweckiego); ze względu na bardzo małą ilość przesyłanych danych
(około 6 sesji połączenia na godzinę po 2kB, wymagana chwilowa prędkość transmisji
9,6 kb/s) z systemu zarządzania do tablic informacyjnych i odwrotnie, wybrano
rozwiązanie GPRS i nie przewiduje się zastosowania innych standardów.
Na poniŜszych rysunkach pokazano proponowaną lokalizację tablic dla Etapu I, z
podziałem na 5 tablic dla Obszaru I (rysunek 13.15) i 4 tablic dla Obszaru II i III (rysunek
13.16). Tablice z Obszaru II i III, nie wchodzą w zakres zadania firmy SIEMENS.
Wersja 4.0
178/192
Rysunek 13.15: Lokalizacja tablic zmiennej treści dla obszaru I
Wersja 4.0
179/192
Rysunek 13.16: Lokalizacja tablic zmiennej treści dla obszaru II i III
Wersja 4.0
180/192
13.9. Podsystem dynamicznego naprowadzania na parkingi
Koncepcja systemu dynamicznego naprowadzania na parkingi na przykładzie Centrum
Informacji Parkingowej PLC2000
Rysunek 13.17: Przykład tablic drogowskazowych z informacją o zajętości miejsc
postojowych
W ramach podsystemu dynamicznego naprowadzania na parkingi (nie stanowiącego
przedmiot zadania dla Etapu I) wchodzą następujące elementy:
• Dynamicznych tablic informacyjnych przy ulicy informujących kierowców
poszukującego miejsca postojowego o aktualnej zajętości stref i obiektów
parkingowych i kierujących go najkrótszą drogą do wybranego przezeń regionu
postoju.
• Do wyświetlania informacji uŜywane są tablice zmiennej treści (mogę to być tablice:
m LCD, z matrycą punktową, diodową LED lub siedmioczęściową) informujące o
wolnych miejscach bądź trzystronne znaki obrotowe (pryzmatyczne).
• Dowolnie programowalne wyświetlacze tekstowe dodatkowo informują kierowców
o szczególnych warunkach drogowych np. w przypadku targów, kiermaszy itp.
Wspierane są technologie tablic LCD, LED i matrycowych.
• Dzięki budowie modułowej PLC2000 jest systemem skalowalnym do potrzeb
kaŜdego zastosowania i dzięki temu moŜe być rozbudowany z wersji bazowej
poprzez wersję centrum informacji parkingowej aŜ do systemu informacji
parkingowej z obsługą wielu uŜytkowników.
• W wariancie bazowym tablicami informacji parkingowej steruje system
podstawowy, czerpiący dane o zajętości miejsc z podłączonych do niego urządzeń
i podsystemów instalacji postojowych.
• Wykorzystując interfejs uŜytkownika do wizualizacji i obsługi, moŜna rozbudować
system do postaci centrum informacji parkingowej, które daje szybki i wygodny
przegląd stanu zajętości miejsc postojowych i umoŜliwia ocenę zebranych danych.
• Dalsza rozbudowa do centrum informacji parkingowej z obsługą wielu
uŜytkowników moŜliwa jest na potrzeby bardzo obszernych zastosowań.
Wersja 4.0
181/192
Rysunek 13.18: System PLC200 – przykład moŜliwych wariantów
System dynamicznego naprowadzania na prakingi umoŜliwia:
• Centralny komputer jest rdzeniem systemu informacji parkingowej PLC2000.
Steruje on i monitoruje cały system wraz z wszystkimi podłączonymi do niego
elementami, a takŜe archiwizuje najistotniejsze dane.
• Komunikację z instalacjami zewnętrznymi realizuje komputer łącznościowy
(ComBox) połączony z komputerem centralnym, odciąŜając go od czystych zadań
komunikacyjnych.
• Wizualizacja i obsługa systemu moŜliwa jest opcjonalnie na komputerze centralnym
lub na komputerach zdalnych, obsługiwanych przez operatorów. Wizualizacja
pozwala uŜytkownikom szybką ocenę bieŜącego statusu systemu i ewentualną
interwencję w razie potrzeby.
• Parametry moŜna w prosty sposób zmieniać z poziomu komputera centralnego lub
jednego ze zdalnych komputerów, a do pewnego stopnia nawet za pośrednictwem
Internetu. Dane systemowe archiwizowane są na komputerze centralnym
(serwerze PLC).
• Centralny komputer cyklicznie odczytuje bieŜące dane o zajętości poszczególnych
parkingów. Korzystając z róŜnych opcjonalnych i dowolnie sparametryzowanych
algorytmów, oblicza na ich podstawie liczbę wolnych miejsc postojowych do
wyświetlenia. Wartości te przekazywane są do poszczególnych tablic
informacyjnych.
• Komputer centralny i komputery operatorów oparte są na architekturze Intel PC i
pracują pod kontrolą Microsoft Windows 2000.
Wersja 4.0
•
182/192
System posiada strukturę modułową i moŜe być w kaŜdej chwili rozbudowany o
opcje funkcyjne, jak równieŜ o dodatkowe instalacje parkingowe/wyświetlacze
Przegląd cech i funkcji podsystemu
Nowoczesna wizualizacja i interfejs uŜytkownika
• Ustandaryzowany układ ekranu zapewnia intuicyjną obsługę
• Funkcje przewijania i zbliŜenia sterują wyświetlaniem mapy
Sterowanie wyświetlaczami
• Rozbudowane algorytmy sterujące
• Opcjonalnie dostępne róŜnorakie algorytmy prognozowania
• Grupowe sterowanie tablicami pryzmatycznymi i tekstowymi
• Wielofunkcyjne sterowanie akcją
Archiwum komunikatów operacyjnych
• Archiwizacja komunikatów z identyfikatorem uŜytkownika w przypadku
potwierdzania i interwencji manualnych
• Sterowanie sygnałem dźwiękowym
• Powiadomienie o potrzebie interwencji za pomocą wiadomości przesłanej faksem
lub SMS-em
Statystyka
• Archiwizacja danych dotyczących zajętości parkingu
• Wyświetlanie liczby wolnych miejsc w postaci wykresów słupkowych dla wszystkich
parkingów
• Profil zajętości w postaci wykresu liniowego
• Interfejs eksportu
Konfiguracja
• Kontekstowe zapytania do operatora
• Edycja aktualnie aktywnej bazy danych konfiguracyjnych na miejscu lub zdalnie
(offline/online)
Dodatkowo w ramach systemu dynamicznego naleŜy uwzględnić System Informacji
Parkingowej.
Liczba zajętych miejsc oraz dokładność systemu informacji parkingowej w zakresie
zewnętrznych miejsc postojowych, znajdujących się przy ulicy, zaleŜy głównie od
następujących czynników:
- Wprowadzone krzywe zajętości
- Liczba grup klientów, którzy mogą parkować bez opłat (mieszkańcy,
niepełnosprawni, policja itd.)
- Sprawność egzekwowania opłat i wysokość mandatów za ich brak
- Sytuacja środowiskowa (więcej postojów długoterminowych tak jak w dzielnicach
mieszkaniowych czy krótkie postoje tak jak w dzielnicach zakupowych)
- Wysokość opłat
- ZłoŜoność systemu opłat (struktura taryfowa)
System Informacji Parkingowej przy uŜyciu informacji pobieranych z parkomatów działa w
następujący sposób:
Ulice w centrum miasta są małe, wąskie i dysponują ograniczoną liczbą miejsc
postojowych. Niecelowe jest więc instalowanie wyświetlaczy na kaŜdej ulicy. NaleŜy
Wersja 4.0
183/192
zdefiniować strefy parkowania wyposaŜone w parkomaty. Przykład zdefiniowania stref
parkowania zilustrowano na rysunku 13.19.
Rysunek 13.19: Przykład wydzielonych stref parkowania w centrum
Dzięki temu moŜemy określić procent zajętości w interesującej strefie i ta informację
przekazać.
Np.
Zajętość
Wskazanie
86% – 100%
Bardzo duŜa
51% – 85%
Umiarkowana
26% - 50%
Niska
0% - 25%
Bardzo niska
Rysunek 13.20 przedstawia schemat działania systemu z przekazywaniem danych. Dane
przekazywane są w obydwu kierunkach.
Dostarczenie
informacji o liczbie
sprzedanych
biletów
Zapytanie i wprowadzenie
wykresu faktycznej
zajętości miejsc
Przekazanie danych
do PLC2000
Wizualizacja na
tablicach
informacyjnych
Obliczenie zajętości
miejsc
Rysunek 13.20: Schemat Systemu Informacji Parkingowej
Wersja 4.0
13.10.
184/192
Proponowanie alternatywnych tras przejazdu
Pracę podsystemu alternatywnych tras przejazdu przedstawiono na schemacie z rysunku
13.21.
Rysunek 13.21: Schemat podsystemu Proponowania alternatywnych tras przejazdu
Informacje o działaniu podsystemu zawarte są w dziale 8.2.3 i 6.
Na podstawie informacji z podsystemu detekcji i podsystemu informacji o zdarzeniach
system wysyła automatyczne lub „ręcznie” wprowadzone informacje dla kierowców na
znaki zmiennej treści – patrz załączony rysunek.
13.11.
Zarządzanie robotami drogowymi
Podsystem zarządzania robotami drogowymi jest składnikiem systemu SCALA i został
opisany w rozdziale 8.5.5. Wprowadzanie komunikatów o stanie ruchu i administrowanie
nimi
13.12.
Medium komunikacyjne
Propozycja realizacji sieci łączności dla systemu sterowania ruchem miejskim w
Warszawie – obszar I
Oszacowanie wymaganej przepustowości łączy
Proponowane rozwiązanie umoŜliwia transmisję danych o ruchu pochodzących ze
sterowników sygnalizacji na skrzyŜowaniach i skojarzonych ze sterownikami detektorów
ruchu do centrum nadzoru. RównieŜ z Centrum nadzoru będą przekazywane do
sterowników dane dotyczące zmian w programach sterowania ruchem pochodzące z
Wersja 4.0
185/192
oprogramowania analizującego i optymalizującego ruch. Ponadto przekazywane będą
dane związane z utrzymaniem urządzeń oraz alarmami.
PowyŜej opisane strumienie danych naleŜy ocenić na kilka do kilkunastu kilobajtów na
sekundę w kaŜdą stronę na lokalizację.
Największe zapotrzebowanie na pasmo będzie związane z przekazywaniem obrazu z
kamer monitoringu do centrum nadzoru.
Zgodnie z wymaganiami Zamawiającego zastosowane zostaną kamery o rozdzielczości co
najmniej 480 linii. Na obserwowanych skrzyŜowaniach zastosowane zostaną kamery z
obiektywami o zmiennej ogniskowej w obudowach umoŜliwiające obrót kamery w zakresie
360o oraz zmianę kąta elewacji. PoniewaŜ kamery powinny być zainstalowane w celu
obserwacji duŜych węzłów komunikacyjnych oraz newralgicznych przystanków
komunikacji zbiorowej to naleŜy zachować dobre warunki do obserwacji i w szczególności
w przypadku sterowania kamerami. W celu umoŜliwienia operatorowi nadąŜania kamerą
za ruchem obserwowanych obiektów, zastosowane kamery i urządzenia do transmisji
obrazu będą działać z jak najmniejszym opóźnieniem przekazywania obrazów do
oglądania na Ŝywo w centrum nadzoru takim, aby operator mógł sterować kamerą w
czasie rzeczywistym, nie gubiąc obserwowanego obiektu. Wymaga to transmisji z pasmem
na poziomie co najmniej 4Mb/s.
Sygnały sterujące z centrum nadzoru do kamer nie wymagają zbyt duŜych przepływności.
Prawidłowe funkcjonowanie jest zagwarantowane przy zastosowanej przepływności
strumieni na poziomie 9600 b/s.
Ponadto jednym z elementów oferowanego rozwiązania jest wydzielony system
monitorowania tunelu. Rozwiązanie umoŜliwia operatorowi jednoczesny zdalny dostęp do
6 kamer.
W celu zapewnienia dostatecznego pasma do przesyłania informacji z tunelu wymagane
jest zastosowanie łącza o duŜej przepływności związanej z liczbą jednocześnie
obserwowanych obiektów (kamer) oraz z koniecznością przekazywania zarchiwizowanych
obrazów z pozostałych kamer do serwerów archiwizujących.
Dodatkowo przewidziano odpowiednie pasmo na przekazywanie informacji do tablic
zmiennej treści. Strumienie informacji do takich tablic będą zbliŜone do strumieni informacji
wykorzystywanych do sterowania kamerami tj. 9600b/s
Wybór medium transmisyjnego
Cała transmisję, poza transmisją obrazów z kamer jest moŜliwa do zrealizowania za
pomocą zwykłych modemów. Konieczność transmisji obrazów z kamer bardzo podnosi
wymagania dotyczące medium transmisyjnego.
DuŜe wymagania na transmisję dotyczą przede wszystkim transmisji od rozproszonych w
terenie kamer do centrum nadzoru oraz szacowane zapotrzebowanie na pasmo wynosi co
najmniej 4 Mb ogranicza wybór technologii realizujących takie wymagania:
a. światłowód – jest to najbardziej preferowana technologia przez zamawiającego.
Zastosowanie światłowodu powoduje prostą budowę systemu transmisyjnego.
Dostępne nadajniki i odbiorniki pozwalają na umieszczanie urządzeń aktywnych na
końcach łaczy.
b. Kable miedziane – nie moŜna stosować łączy ADSL – za mała przepływność w
górę sieci. MoŜliwość stosowania łączy HDSL, SDSL, VDSL do urządzeń
aktywnych zainstalowanych u operatora sieci oraz dalej przez sieć operatora do
centrum zarządzania. Wymaga to dzierŜawy kabli od operatora oraz wykupienia
Wersja 4.0
186/192
odpowiednich łączy dzierŜawiony lub usług. Jest to realizowalne praktycznie i
wyłącznie przy współpracy TPSA. Tylko TPSA dysponuje w centrum miasta
odpowiednią infrastrukturą kablową. Wymagać to będzie dzierŜawy łączy o
przepływnościach około 4Mb na lokalizację. Łącza miedziane SHDSL, VDSL maja
ograniczony zasięg (od kilkuset metrów do 2-3 km) i są mało odporne na
zakłócenia. Stosunkowo wysokie są cennikowe koszty ich dzierŜawy. (około
2000PLN/Mb miesięcznie).
c. Łącza radiowe
W Warszawie łącza radiowe LMDS zapewniają teoretycznie wystarczającą
przepływność jednak pasmo radiowe jest mocno wykorzystywane przez innych
operatorów i prawdopodobnie nie uzyska się dostatecznej liczby kanałów do
obsługi całego systemu. Ponadto instalacje radiowe wymagają widoczności
pomiędzy terminalami a stacjami bazowymi, co moŜe być trudne do osiągnięcia w
centrum miasta poniŜej skarpy wiślanej. Na dodatek w centrum miasta buduje się
duŜo wysokich budynków, które będą zmieniały warunki propagacji. Dlatego teŜ nie
naleŜy rozwaŜać łaczy radiowych jako rozwiązanie polecane na dłuŜszy okres
eksploatacji.
Ze względu na budowaną od dłuŜszego czasu sieć monitoringu miejskiego wykorzystującą
głównie światłowody do transmisji obrazów zdecydowano się na wybór sieci bazującej na
światłowodach. Dla realizacji zadania przyjęto rozwiązanie mieszane – budowa
światłowodów własnych plus maksymalne wykorzystanie wolnych zasobów transmisyjnych
naleŜących do jednostek miejskich.
Proponowane rozwiązanie to budowa sieci łączności w oparciu o Ethernet. Wykorzystanie
Ethernetu pozwoli na maksymalną uniwersalność rozwiązania i łatwość integracji z
istniejącą lub budowaną siecią miejską.
Planowana topologia sieci uwzględnia wymagania zamawiającego tzn. awaria
pojedynczego urządzenia nie będzie powodować odcięcia łączności z innymi węzłami
komunikacyjnymi
Plan budowy sieci łączności
Plan budowy sieci łączności opiera się na następujących załoŜeniach
Budowana sieci będzie siecią dwuwarstową – lokalnej i szkieletowej NajniŜszy poziom
sieci bazuje na małych lokalnych pętlach światłowodowych łączących wybrane węzły ze
sobą. Pętle lokalne będą połączone z przełącznikami agregującymi tworząc węzły sieci w
warstwie szkieletowej.
Na kaŜdym skrzyŜowaniu będzie zainstalowany przełącznik Ethernetowy typu
przemysłowego z dwoma uplinkami światłowodowymi. Przełączniki te będą łączone
światłowodami w pętle po pięć do ośmiu przełączników. Połączenie w pętle pozwala na
spełnienie warunku redundancji i zapewnią poprawną łączność pomiędzy pozostałymi
urządzeniami w przypadku uszkodzenia jednego z urządzeń w pętli. Taka architektura
pozwala na oszczędne korzystanie z zasobów światłowodowych przy zapewnieniu duŜych
przepływności i zachowaniu wymaganej odporności budowanej sieci na uszkodzenia.
Ogólny schemat sieci łączności pokazano na rysunku 13.22.
Wersja 4.0
187/192
sterownik
sterownik
Przełącznik na skrzyŜowaniu
Przełącznik
agregujący
sterownik
Światłowód Ethernet 100BaseFX
Światłowód Ethernet 100BaseFX uplink
sterownik
sterownik
Światłowód Ethernet 1000BaseSX
Rysunek 13.22: Schemat ogólny sieci łączności
Z dwóch wybranych przełączników w pętli wykorzystujemy po jednym porcie
Ethernetowym (elektrycznym) do realizacji połączenie w górę sieci. Wybór tych
przełączników nastąpi na etapie projektu szczegółowego na podstawie analizy topologiii
dostępnych światłowodów (nowo budowanych i dostępnych włókien w juŜ zbudowanej
infrastrukturze). Na podstawie analizy przeprowadzonej na etapie projektu szczegółowego
zostaną wskazne najbardziej dogodne przełączniki ze względu na topologię sieci jak i
dostępność włókien światłowodowych do realizacji połączeń w górę sieci. W celu
zachowania niezawodności, wyjście z pętli światłowodowej w górę sieci będzie
realizowane z dwóch róŜnych przełączników (redundancja – zabezpieczenie przed
negatywnymi skutkami uszkodzenia pojedynczego przełącznika).
Wyjście w górę będzie realizowane za pomocą portów elektrycznych i konwerterów
Ethernet 100BaseT na światłowód. MoŜliwe jest takŜe zastosowanie konwerterów
jednowłóknowych (1550/1350nm).
Przełączniki szkieletowe będą agregować sygnały z pierścieni lokalnych. Przełaczniki
szkieletowe będą połączone z przełącznikiem centralnym umiejscowionym w Centrum
Sterowania Ruchem za pomocą uplinków Ethernetowych o przepływnościach co
najmniej1Gb. KaŜdy z przełączników agregujących będzie dołączony do przełącznika
centralnego za pomocą co najmniej dwóch uplinków.
Wybór lokalizacji dla przełączników szkieletowych nastąpi w trakcie tworzenia projektu
szczegółowego. Lecz juŜ teraz moŜna wskazać dwie lokalizacje. Jedna z lokalizacji to
centrum nadzoru przy ulicy Chmielnej 120 gdzie zlokalizowany jest przełacznik centralny,
który równieŜ moŜe być wykorzystywany do agregacji ruchu z pętli lokalnych. Druga
lokalizacja to pomieszczenia tunelu pod Wisłostradą. Istnieją tam pomieszczenia
techniczne, w których moŜna umieścić przełącznik agregujący i ponadto w tunelu będą
zlokalizowanych kamery generujące duŜy strumień danych o ruchu w tunelu.
Agregacja pozwala na zaoszczędzenie włókien światłowodowych potrzebnych do budowy
sieci rozległej.
Wersja 4.0
188/192
Uplinki z przełączników agregujących umieszczonych w lokalizacjach wyniesionych (np.
tunelu) będą realizowane jako dwa niezaleŜne uplinki o przepływności po 1Gb/s
(redundancja portów).
We wszystkich mini pierścieniach zachowany zostanie warunek redundancji połączeń i
włókien światłowodu.
Tunel
Usytuowany w pomieszczeniu technicznym tunelu przełącznik Ethernetowy będzie
agregował ruch z pętli lokalnych oraz będzie pośredniczył pomiędzy urządzeniami
zainstalowanymi w tunelu a centrum nadzoru.
Wersja 4.0
189/192
14. Ogólne warunki
14.1. Referencje
Na Ŝyczenie zleceniodawcy załączamy dodtkowe referencje opisanego systemu.
14.2. Dokumentacja
W przypadku zlecenia dostarczane są dokładne podręczniki dla wszystkich narzędzi.
14.3. Bezpieczeństwo informacji
14.3.1. Ochrona antywirusowa
Skaner antywirusowy
Skaner antywirusowy FP-WIN Professional stosowany jest zarówno na serwerach, jak i na
sprzęcie komputerowym. Skaner FP-WIN wykrywa w niezawodny sposób nie tylko wirusy
w plikach i wirusy typu Boot-Viren, ale równieŜ wirusy Makro i Script, oraz stosowane
niedozwolone inne oprogramowanie (MalWare). MoŜliwe jest przeszukiwanie nie tylko
lokalnych systemów, ale równieŜ systemów sieciowych. Zainfekowane obiekty naleŜy w
miarę moŜliwości pozbawić wirusów.
Skaner F-PROT umoŜliwia stosowanie metody wyszukiwania nieznanych dotychczas
wirusów i ostrzegania przed nimi. BliŜsze informacje o skanerze antywirusowym FP-WIN
Professional znajdą Państwo na stronie www.fp-win.de.
14.3.2. Zabezpieczenie dostępu
Dostęp do systemu mają jego uŜytkownicy i osoby uprawnione. Dostęp do systemu
zabezpieczony jest hasłem.
14.3.3. Zabezpieczenie danych
Dane mogą być zapisane na CD/DVD lub na kasetach DAT.
14.4. Ogólne załoŜenia i warunki ramowe
14.4.1. Uwzględnione przepisy
Uwzględnione zostały następujące przepisy .
Kodeks drogowy (KD wraz z Ogólnymi Przepisami Administracyjnymi OPA ))
Norma DIN VDE 0832, Instalacje sygnalizacyjne stosowane w ruchu drogowym
Wytyczne w sprawie instalacji sygnalizacyjnych (WwSIS)
Norma DIN 67527, Właściwości techniczno-świetlne świateł sygnalizacyjnych
stosowanych w ruchu drogowym
Wytyczne i informacje Instytutu Badawczego Drogownictwa dotyczące instalacji
sygnalizacyjnych stosowanych w ruchu drogowym.
Wersja 4.0
190/192
Techniczne warunki przyłączenia miejscowych instalacji sygnalizacyjnych.
Wytyczne VDEW w sprawie przyłączania stałych szafek sterowniczo- rozdzielczych
do sieci niskich napięć
Warunki dopuszczeniowe Poczty Niemieckiej SA
Norma DIN VDE 0100, Ustalenia dotyczące wykonania instalacji energetycznej o
napięciu znamionowym do 1000 V
Norma DIN 57160, uziemienia
Norma DIN VDE 0800, część 1, Technika sygnalizacyjna, Wykonanie i uŜytkowanie
urządzeń
Norma DIN VDE 0800, część 2, Technika sygnalizacyjna, Uziemienie i wyrównanie
potencjałów
Norma DIN VDE 0875, Zabezpieczenie urządzeń elektrycznych i instalacji przed
zakłóceniami
Norma DIN VDE 0878/2, Odporność urządzeń telekomunikacyjnych na zakłócenia
elektromagnetyczne
ENVG 09/1992, Ustawa o odporności elektromagnetycznej urządzeń
RSA, Wytyczna w sprawie bezpieczeństwa miejsc pracy
Stacje terenowe OCIT, Wprowadzenie do systemu, System OCIT-O-V1.0
Stacje terenowe OCIT, Urządzenia sygnalizacji świetlnej, OCIT-O- V1.0
Stacje terenowe OCIT, Podstawowe funkcje przyrządów polowych, OCIT-O-Baza
V1.0
Stacje terenowe OCIT, Zasady i protokoły, Protokół OCIT-O_V1.0
Stacje terenowe OCIT, Profil 1 – Profil przenoszenia z punktu do punktu na stałych
trasach przenoszenia , OCIT-O-Profil_1_V1.0
Stacje wewnętrzne OCIT- Format interfejsu „OCIT VI dla sterowania sygnalizacją
świetlną, Dane bazowe VT, wersja 1, wydanie z dnia 15.11.2001“
Elementy dostarczanego systemu zarządzania ruchem spełniają obowiązujące przepisy w
zakresie zabezpieczenia przed zakłóceniami:
Ochrona przed zakłóceniami wg EN 55022 (CE)
Ochrona przed zakłóceniami na zasilaczu wg IEC 801-4 i 801-5
Ochrona przed statycznym wyładowaniem wg IEC 801-2
Badanie ochrony przed zakłóceniami wg NAMUR
Dopuszczenie do bezpiecznego uŜytkowania wg EN 60950, UL 1950
Klasa ochrony według VDE 0106 część 1(IEC 536)
Rodzaj ochrony według DIN 40050: IP20
14.4.2. Warunki otoczenia i warunki środowiskowe
Zleceniodawca musi zapewnić spełnienie następujących warunków.
Warunki środowiskowe dla elementów serwera SITRAFFIC SCALA/CONCERT,
OS, IG, ES, SIEL i OCIT- OAP:
Temperatura wewnętrzna 5...30°C
Względna wilgotność powietrza 10... 85%
Antystatyczna wykładzina podłogowa
Zabezpieczenie przed bezpośrednim działaniem promieni słonecznych lub innych
źródeł ciepła
Wstrząsy do maks. 0,4 g
Warunki środowiskowe dla stacji roboczych:
Temperatura wewnątrz pomieszczeń 5...45°C
Względna wilgotność powietrza 10... 85%
Wersja 4.0
191/192
Zabezpieczenie przed bezpośrednim działaniem promieni słonecznych lub innych
źródeł ciepła
Wstrząsy do maks. 0,4 g
PowyŜsze dane stanowią minimalne warunki, które muszą być spełnione dla całego
systemu. W przypadku konieczności spełnienia specjalnych wymagań, zostanie to
oddzielnie zaznaczone w odnośnych podrozdziałach. Nie spełnienie podanych powyŜej
warunków sprawi, Ŝe niemoŜliwe będzie zapewnienie stabilnej pracy systemu.
Zleceniodawca powiadomi zleceniobiorcę o odstępstwach od wymaganych warunków.
14.4.3. Ogólna charakterystyka oprzyrządowania i oprogramowania
System Zarządzania Ruchem dla Miasta Stołecznego Warszawy (SITRAFFIC
SCALA/CONCERT) realizowany będzie przy zastosowaniu dostępnych na rynku,
standardowych
produktów
w
zakresie
oprzyrządowania
i
oprogramowania
odpowiadających najnowszemu stanowi technologii.
Następuje przy tym implementacja podstawowej struktury klienta wraz z poszczególnymi
obiektami za pomocą sieci komputerowej na bazie protokołów internetowych TCP/IP.
Zastosowane będą dostępne na rynku mechanizmy komunikacyjne. (interfejs RS232,
Ethernet z protokołem TCP/IP, FTP, ISDN itp.)
Zastosowany będzie system roboczy Microsoft Windows 2000/2003. Dane zapisywane
będą w bazie danych systemu zarządzania (ORACLE) lub w plikach róŜnych systemów
zapisu danych (File-System).
14.4.4. Obsługa systemu
Pracownicy ZDM będą posiadać najwyŜsze uprawnienia i ponosić będą pełną
odpowiedzialność za funkcjonowanie systemu UTC, oraz realizować wszelkie funkcje,
które są niezbędne do funkcjonowania systemu.
Personel firmy SIEMENS zapewni przeszkolenie na stanowisku roboczym pracowników
ZDM.
Funkcjonowanie systemu:
Codzienne działanie systemu, będące odpowiedzią na potrzeby związane z zarządzaniem
ruchem drogowym i zaistniałymi wypadkami, będą realizowane przez personel ZDM.
Personel Operacyjny będzie opracowywał, rozwijał i dopasowywał plany reagowania na
wypadki oraz zatory, monitorował codzienne funkcjonowanie systemu, zbierał oraz
analizował dane o natęŜeniu ruchu drogowego, przygotowywał i rozpowszechniał
informacje dla uczestników ruchu drogowego, a takŜe – wdraŜał plany reagowania.
Dostęp do systemu
System posiada róŜne poziomy zabezpieczenia. UŜytkownicy systemu, w zaleŜności od
poziomu dostępu, będą mieli prawo do wykorzystywania róŜnych modułów systemu.
Na poziomie centralnym:
- obserwator systemu: tylko funkcje przeglądowe, nie posiada praw do zmiany
parametrów;
- operator systemu: moŜliwość zmian parametrów, dotyczących standardowych działań
operacyjnych;
- administrator systemu: wszystkie moduły, związane z funkcjami administratora;
- obsługa systemu: wszystkie elementy systemu na poziomie lokalnym:
Wersja 4.0
192/192
- normalny serwis: nie posiada praw do zmiany programu sterownika;
- programista: posiada wszystkie prawa
KaŜdy z uŜytkowników systemu będzie posiadał osobiste hasło dostępu do systemu.
KaŜda zmiana w systemie będzie monitorowana i będzie zapamiętywana w dzienniku
systemu.
Wersja 4.0

Koncepcja Zintegrowanego Systemu Zarządzania Ruchem w

Transkrypt

Podobne dokumenty

Presentation Cover (Text only) max. 3 lines, 28pt

Automatyzacja i digitalizacja w przemyśle

Pobierz egzemplarz CX News

Siemens MAG 5000 - kierunekwodkan.pl