"Najlepszą metodą przewidywania przyszłości jest jej tworzenie" - Peter Drucker   

Główne Menu


Strona Główna


PSTT
· O Stowarzyszeniu
· Wydarzenia
· Statut


Redakcja wortalu
· O Nas
· Kontakt

Artykuły
· Telematics
· Transport

Inne
· Słownik telematyczny
· Konferencje
· Polecamy
· Do pobrania
· FAQ

Partnerstwo


Szukaj


Artykuły :: Transport :: Materiały konferencyjne

BEZPIECZEŃSTWO OPROGRAMOWANIA SYSTEMU STEROWANIA RUCHEM KOLEJOWYM
Andrzej Lewiński, Katarzyna Trzaska
2003-11-13 00:00:00

1.WARUNKI BEZPIECZEŃSTWA SYSTEMU SSP
Schematyczny model samoczynnej sygnalizacji przejazdowej przedstawiony został na rysunku nr 1. Przedstawia on rozmieszczenie urządzeń detekcji pociągu oraz urządzeń, na które system oddziałuje.
Symbole przedstawione na rysunku:
-
Układy oddziaływania na system przez przejeżdżający pociąg (czujniki): Cz1, Cz4 (czujniki włączające dla właściwego kierunku ruchu), Cz3, Cz6 (czujniki włączające dla niewłaściwego kierunku ruchu), Cz2, Cz5 (czujniki wyłączające dla właściwego oraz niewłaściwego kierunku ruchu),
-
Układy, na które system oddziałuje (którymi steruje): S1, S2 (sygnalizatory świetlne drogowe do ostrzegania użytkowników drogi o niebezpieczeństwie wywołanym przez przejeżdżający pociąg), B1, B2 (sygnalizatory akustyczne do ostrzegania użytkowników drogi o niebezpieczeństwie wywołanym przez przejeżdżający pociąg), R1, R2 (napędy rogatkowe służące do zabezpieczenia przejazdu) oraz To1, To2, To3, To4 (tarcze ostrzegawcze przejazdowe dla maszynistów).


Rys.1 Schematyczny model samoczynnej sygnalizacji przejazdowej

System musi zapewniać włączenie ostrzegania w momencie zbliżania się pociągu do skrzyżowania według następujących zasad:
-
W momencie gdy pojazd kolejowy znajdzie się w strefie oddziaływania czujnika włączającego Cz1/Cz4 (zależnie od kierunku), sygnał z tego czujnika jest przekazywany do układu sterującego, powodując w konsekwencji włączenie ostrzegania na przejazdowych tarczach ostrzegawczych dla maszynisty (co zezwala na przejazd pociągu z normalna prędkością), sygnalizatorach świetlnych drogowych oraz akustycznych. Podstępnym ostrzeganiu rozpoczyna się opuszczanie drągów rogatkowych zamykających jezdnię.
-
W momencie dojechania pociągu do skrzyżowania, gdy pojazd znajdzie się w strefie oddziaływania czujnika wyłączającego Cz2/Cz5 (zależnie od kierunku) oraz zjedzie ostatni osi ze strefy wyjazdowej tego czujnika, następuje wyłączenie urządzeń ostrzegania (sygnalizatory świetlne i akustyczne, tarcze ostrzegawcze przejazdowe, zapory rogatkowe).
-
Czujniki Cz3/Cz6 przeznaczone są do detekcji pojazdu kolejowego poruszającego się w niewłaściwym kierunku ruchu (zastosowane ze względu na możliwość ruchu dwukierunkowego). Czujniki te nie mogą powodować włączenia ostrzegania przez pojazdy poruszajace się po torze właściwym.
-
Ostrzeganie powinno być podtrzymane w przypadku, gdy po jednym torze poruszają się w niewielkiej odległości dwa pojazdy kolejowe jeden po drugim.
-
Ostrzeganie powinno być podtrzymane w przypadku, gdy po obydwu torach, w strefie oddziaływania urządzeń sygnalizacji przejazdowej porusza się kilka pojazdów kolejowych.

Sygnalizacja posiada 2 stany poprawnej pracy: stan oczekiwania (gdy nie ma miejsca żadna z przyczyn włączenia sygnalizacji) oraz stan ostrzegania (gdy nastąpiło wykrycie co najmniej jednego pociągu przez czujniki). Pozostałe stany urządzenia dotyczą sytuacji awaryjnych, zdefiniowanych w wymaganiach bezpieczeństwa oprogramowania (punkt 2).
Wszystkie poprawne z definicji stany urządzenia zostały zdefiniowane i zapisane na stałe (z możliwością zmiany) w wejściowej tablicy stanów TabWejsc (dotyczy czujników oraz sytuacji ruchowej) oraz tablicy wyjściowej TabWyjsc (dotyczy stanów urządzeń ostrzegających). Zmienne w tablicach są typu logicznego i przyjmują zawsze jedną z dwóch wartości: true lub false. Pozostałe stany traktowane są jako usterkowe i generują odpowiednią reakcje urządzeń wyjściowych.

2. MODEL OPROGRAMOWANIA
2.1 Definicja wejść i wyjść
Rysunek 2 przedstawia poprawne stany pracy sygnalizacji przejazdowej wraz z odpowiadającymi im stanami urządzeń ostrzegania. Kolejne elementy wektora odpowiadają następującym zmiennym:
TabWejsc:(Tor1Ruch, Tor1Kier, Cz1, Cz2, Cz3, Tor2Ruch, Tor2Kier, Cz4, Cz5, Cz6),
TabWyjsc:(To1b, To1p, To2b, To2p, To3b, To3p, To4b, To4p, Sygnaly)
Zmienne ToriRuch informują czy po danym torze odbywa się ruch, zmienne ToriKier określają czy kierunek ruchu jest właściwy czy nie, pozostałe zmienne Czi odpowiadają za informacje o zajętości strefy i-tego czujnika detekcji pojazdu.
Zmienne Toib oraz Toip wskazują odpowiednią tarczę ostrzegawcza przejazdową, oraz odpowiednie komory świateł (b - białe, p - pomarańczowe). Zmienna Sygnaly informuje o załączeniu ostrzegania na przejeżdzie kolejowym.


Rys. 2. Sposób zapisu poprawnych stanów pracy sygnalizacji wraz z odpowiadającymi im stanami urządzeń ostrzegania.

Można zauważyć, że tablica traktuje jako prawidłowe stany w których dwa sąsiednie czujniki (np. Cz1 i Cz2) przyjmują wartość true. Odpowiada ta dwóm sytuacjom (dla przykładu Cz1 i Cz2):
Prawidłowa sekwencja: pociąg zjechać z czujnika 1 a następnie wjechać na czujnik 2, nieprawidłowa sekwencja: obydwa czujniki wskazują zajętość.
W celu odróżnienia sekwencji prawidłowej od nieprawidłowej i zagwarantowania odpowiedniej reakcji systemu, a także rozpoznania kierunku poruszającego się pojazdu każdy z czujników podzielony został na 2 strefy: wjazdową i wyjazdową. Oprócz tego wprowadzono dodatkowa zmienną typu tablicowego Licznik [i], która zmienia swój stan w miarę przejeżdżania przez pojazd kolejnych stref czujnika. Nieprawidłowa sekwencja przejazdu przez czujniki Cz1 i Cz2 jest rozpoznawana przy wykorzystaniu zmiennej Licznik11] i Licznik[2].

2.2 Zależności w systemie
Poszczególne elementy wektora Licznik[i] są uzależnione od siebie tak jak to przedstawia tabela 1. Symbolem "M" oznaczone zostały stany możliwe do wystąpienia w systemie systemie przypadku pracy prawidłowej, symbolem "U" stany usterkowe. Symbol "M/Czi" dotyczy sytuacji gdy stan jest możliwy do wystąpienia pod warunkiem że zmienna opisująca stan czujnika Czi=True, czyli wcześniej czujnik ten zadziałać.

Wartość zmiennej Licznik[1]
0 1 2 3 4
Cz2=True
U/M U U U M
Wartość zmiennej Licznik[3]
0 1 2 3 4
Cz2=True M U U U U/M
Tab.1 Zależności pomiędzy zmienną Licznik [i]

Zależności pomiędzy zmiennymi zaimplementowane zostały w kilku miejscach (modułach) programu Dodatkowo system uwzględnia zależności takie jak np. powiązanie między kolejnymi stanami i-tego detektora pojazdu. W przypadku, gdy sekwencja nie zostanie zachowana następuje obsluga sytuacji uznanej za awaryjną.


Rys. 3. Fragment reprezentacji kodowej programu wiązany z obsługą usterek.

Na rysunku 3 został przedstawiony fragment reprezentacji kodowej programu odpowiadający blokowi decyzyjnemu odpowiedzialnemu za rozpoznawanie sytuacji awaryjnej.

2.3 Obsługa sytuacji awaryjnej
System uznaje za awaryjne następujące stany czujników:
-
jeĹźeli na torze nie ma ruchu tzn. zmienna ToriRuch=False, oraz ktĂłrykolwiek czujnik Czi=True,
-
jeżeli na torze 1 lub 2 jednocześnie pojawia się sekwencja Cz1, Cz2, Cz3=True lub Cz4, Cz5, Cz6=True,
-
jeżeli jednocześnie pojawiają się sekwencje Cz1, Cz3=True oraz Cz4, Cz6=True,
-
jeżeli w systemie czujnik 2 lub 5 sygnalizuje zajętość (Cz2 lub Cz5=True) bez uprzedniego zajęcia odpowiednio czujnika 1 lub 3 oraz 4 i 6,
-
gdy pojawia się jedna z następujących sekwencji bez uwzględnienia zależności pomiędzy zmiennymi Licznik[i]:

- Cz1, Cz2=True

- Cz3, Cz2=True,

- Cz4, Cz5=True,

- Cz6, Cz4=True.

Dodatkowo w systemie uwzgledniono usterki związane z niezachowaniem sekwencji przejazdu przez i-ty czujnik. Uwzględnione zostały tu tylko stany możliwe do zrealizowania - wszystkie pozostałe powodują uruchomienie obsługi usterki.
Reakcja na każdą z tych usterek polega na włączeniu ostrzegania na przejeżdzie kolejowym oraz pomarańczowych świateł na tarczach ostrzegawczych przejazdowych. Jeżeli awarii ulega czujnik 2 lub 5 wtedy tarcze ostrzegawcze sygnalizują usterkę po stronie kierunku właściwego i niewłaściwego. Ostrzeganie zostaje wyłączone dopiero po usunieciu usterki (zresetowanie układu).
W przypadku pojawienia się awarii jest ona wykrywana przy pomocy wywoływanej cyklicznie co 500us, procedury TimerPoprawnosc. Po rozpoznaniu stanu usterkowego (jeszcze nie sklasyfikowanego) procedura przekazuje sterowanie do odpowiedniego podprogramu sterującego, odpowiedzialnego klasyfikację i odpowiednią reakcję (np. zaświecenie odpowiednich tarcz ostrzegawczych).
Pozostałe stany awaryjne (np. awarie urzadzeń ostrzegania) nie zostały uwzględnione w systemie. Zostaną one uwzględniona jako kontynuacja pracy.

3.UPROSZCZONY ALGORYTM DZIAŁANIA SYSTEMU

obrazek 4


4.ZASADY PROJEKTOWANIA BEZPIECZNEGO OPROGRAMOWANIA
Wprowadzając nowe systemy komputerowe w miejsce dotychczasowych układów (np. w przekażnikowych systemach srk) należy zapewnić co najmniej taki sam poziom funkcjonalności czy bezpieczeństwa względem parametrów niezawodnościowych czy też eksploatacyjnych. Specyfiką tych nowych standardów jest podział na część sprzętową oraz na oprogramowanie. Analiza niezawodności na poziomie sprzętu opiera się na znanych z teorii niezawodności metodach uwzględniających głównie strukturę powiązań pomiędzy podsystemami, urządzeniami czy elementami systemu. Analizując oprogramowanie należy posługiwać się innymi metodami szacowania prawdopodobieństwa poprawnego wykonania programu związanymi np. z teorią procesów Markowa.
Projektowanie programów poprawnych wiąże się ze stosowaniem specjalnych procedur i metod programowania jak programowanie systematyczne, strukturalne, specyfikowane czy defensywne [1]. Istotną sprawą jest zapewnienie zarówno poprawności pod względem syntaktycznym jak i semantycznym. Jakkolwiek poprawność syntaktyczna nie jest wielkim problemem, ze względu na ścisłe reguły składni języków programowania, to poprawność semantyczna nie jest już tak jednoznacznie identyfikowalna. Stąd też liczne metody dowodzenia poprawności semantycznej, które najczęściej bazują na sprawdzeniu, czy zachowanie programu będzie takie, jak wskazują to dodatkowo narzucone na zmienne programowe warunki. Jest to bardzo istotne zagadnienie w przypadku systemów sterowania związanych z bezpieczeństwem, jak to ma miejsce w systemach NSRK (Nadzoru i Sterowania Ruchem Kolejowym). Według UIC i CENELEC na każdym etapie powstawania oprogramowania systemu bezpiecznego, od specyfikacji wymagać do zatwierdzenia oprogramowania, stosowa należy odpowiednie analizy i metody tworzenia oprogramowania [4]. Są to elementy istotne zwłaszcza w świetle przyszłego członkostwa Polski w strukturach Unii Europejskiej, gdzie obecnie obowiązują raporty oraz standardy CENELEC.

BIBLIOGRAFIA
[1]
LEWIŃSKI A.: Problemy oprogramowania bezpiecznych systemów komputerowych w zastosowaniach transportu kolejowego, Politechnika Radomska im. K. Pułaskiego, Monografia nr 49, Radom 2001
[2]
DEMBIŃSKI P., MAŁUSZYŃSKI J.:Matematyczne metody definiowania języków programowania, WNT, Warszawa, 1981
[3]
Opracowanie CNTK, Zakład Sterowania Ruchem Kolejowym: Wymagania bezpieczeństwa dla urządzeń sterowania ruchem kolejowym, Warszawa, luty 1998
[4]
CENELEC EN 50128, Railway Applications, Software for railway control and protection systems, 1997
[5]
MYERS G. J.: Projektowanie niezawodnego oprogramowania, WNT, Warszawa 1980
[6]
DĄBROWA-BAJON M.: Podstawy sterowania ruchem kolejowym. Funkcje, wymagania, zarys techniki, WPW 2002
[7]
KOPETZ H.: Niezawodność oprogramowania, WNT, Warszawa 1980.

Autorzy:
dr hab. inż. Andrzej Lewiński
Wydział Transportu Politechniki Radomskiej
mgr inĹź. Katarzyna Trzaska
Wydział Transportu Politechniki Śląskiej

Logowanie

Użytkownik

Hasło


Załóż konto

Zapomniałem hasła

Nowe artykuły


Ankieta




Ogółem głosów: 0

Wyniki poprzednich ankiet


©NET-DESIGN 2007