Witam wszystkich.
Zdanie wstępu - w tematach kolejowych szczególnie interesuje mnie automatyka sterowania i zabezpieczania ruchu (jako hobby).
Jeżdżąc na scenariuszu "bałtyk_zima" w sm42 kilka razy zostałem zaatakowany przez inne składy wjeżdżające na mój tor. Prawdopodobnie z powodu mojego ociągania się zostały niepoprawnie skierowane, bo zakładam że u autora działa właściwie. Obejrzenie źródeł scenariusza wskazuje na potencjalnego źródło dziwnego zachowania - eventy używane do indywidualnego sterowania wszystkimi elementami infrastruktury kolejowej, bez żadnego globalnego nadzorcy i koordynatora.
W rzeczywistości takie zdarzenia nie mogą mieć miejsca. Większość sytuacji ruchowych opiera się na określeniu skąd i dokąd dana lokomotywa/skład ma się przemieścić.
Stąd też pomysł dodania modułów realizujących logicznie bardziej zaawansowane funkcje.
"Układacz przebiegów" - zajmujący się automatycznym wytyczaniem trasy przebiegu z zadanego miejsca początkowego (nazwy toru, nazwy semafora spod którego startuje skład) do zadanego miejsca docelowego (jw.) opcjonalnie przez określone miejsce(a) pośrednie - jeśli zachodzi potrzeba wybrania nieoczywistego przebiegu wariantowego.
W procesie tym następuje:
- odnalezienie drogi w grafie, łączącej punkt początkowy i końcowy
- sprawdzenie że cała droga jest niezajęta innym przebiegiem oraz wszystkie jej elementy nie wchodzą w sposób kolizyjny z np. ochroną boczną innego przebiegu
- dla przebiegów pociągowych, sprawdzenie czy żaden odcinek nie jest już zajęty taborem
- przestawienie wymaganych rozjazdów i wykolejnic (wszystkie na raz lub jedna po drugiej - bardziej realistycznie, aby nie robić przeciążeń włączeniem wszystkich napędów na raz),
- automatyczne wyszukanie ochrony bocznej dla rozjazdów (inny rozjazd, semafor, wykolejnica, ewentualnie pewna odległość od innych obiektów np. 200m),
- ustalenie przebiegu - "zawłaszczenie" wszystkich elementów dla danego przebiegu
- zamknięcie rogatek przecinających przebieg
- wyświetlenie odpowiednich wskazań na semaforach (uwzględnienie ograniczeń prędkości po drodze np. 40km/h dla jazdy w bok, informacji o wskazaniu następnego semafora oraz miłe dla oka drobiazgi typu oświetlenie kształtowej tarczy ostrzegawczej stojącej tuż przed kształtowym semaforem zapala się tylko wtedy gdy semafor dopuszcza przejazd)
Po utwierdzeniu drogi następuje przejazd składu. W trakcie przejazdu składu następuje sukcesywne zwalnianie "zawłaszczonych" elementów, które powracają do położenia zasadniczego. Można w prosty sposób uwzględnić drobne niuanse typu: dla przebiegów pociągowych powrót do S1 następuje (upraszczając) po minięciu lokomotywą semafora, a dla manewrów dopiero po opuszczeniu całego składu (aby maszynista realizujący popych miał cały czas Ms2). Dla kształtowych można upraszczająco założyć, że wszystkie mają sprzęgła sygnałowe i dzięki temu mogą reagować podobnie do świetlnych. Oczywiście dla przypadku gdy pojazd nie dojedzie do końca zarezerwowanego przebiegu (np. nie ma potrzeby cofać się aż tak daleko) - następuje zwolnienie niezrealizowanej części przebiegu.
Dzięki takiemu rozwiązaniu można by wprowadzić bardziej realistyczny, a przede wszystkim zdecydowanie prostszy dla tworzących scenariusze, sposób prowadzenia ruchu - zamiast przestawiać w eventach ręcznie wszystkie rozjazdy i podawać sygnały, można zgłosić po prostu przebieg do realizacji. Nic nie stoi na przeszkodzie, żeby zakończenie procesu ustawiania przebiegu wyzwalało kolejne zdarzenia.
Zadania do realizacji na tym etapie: automatyczne określenie typu i "przynależności torowej" (którego toru i kierunku ruchu dotyczy wskazanie) semaforów i innych nietorowych obiektów, określenie sposobu reprezentacji obiektów w grafie (do poszukiwań przebiegów i ich rezerwacji), budowanie grafu opisującego zależności ruchowe na podstawie scenerii, testy poprawności reprezentacji, implementacja szukania drogi w grafie (przebieg i jego ochrona boczna) ze zwróceniem uwagi na różne nieoczywiste szczegóły (choćby wyjazd dwóch składów w przeciwne strony z jednego toru), implementacja zwalniania przebiegu. Do celów ładnej prezentacji oraz pomocy w zadaniach deweloperskich można pokusić się o syntezowanie widoku pulpitu zawiadowcy z obrazem sytuacji ruchowej na podstawie wygenerowanego grafu. Stąd już tylko krok do opcji przejęcia sterowania przez żywego operatora.
Część z tych zadań już widziałem na filmie zaimplementowaną w module AI (też musi wiedzieć, który semafor jest "jego" i z jaką prędkością może go minąć).
Po wspomnianym opanowaniu przebiegów w obrębie stacji, kolejnym krokiem automatyzacji prowadzenia ruchu jest obsługa komunikacji pomiędzy sąsiadującymi stacjami. W to wchodzi automatyczna i półautomatyczna blokada liniowa (oczywiście realizowana samoczynnie przez program - "scenerzysta" musi tylko postawić semafory na szlaku i ew. dla SBL określić że zamiast domyślnie trzystawnych są czterostawne), zagadnienia kierunku ruchu na danym torze, obsługa SSP.
Dysponując takim rozwiązaniem, można na jego podstawie zbudować moduł wyższego rzędu - "dyżurnego ruchu" pilnującego ruchu pociągów. I tu znowu jest szerokie pole do kreatywności: skład może mieć określony rozkład (konkretne godziny odjazdów), określony czas postoju, losowy (w podanym zakresie) czas postoju, oczekiwania na skomunikowanie z innym składem, itp. W sytuacji opóźnienia priorytetowanie kolejności wyjazdu na szlak w zależności od typu pociągu (np. najpierw pospieszne, potem osobowe a na końcu towarowe - wystarczy przeanalizować wagony). Dysponując wiedzą o krawędziach peronowych można realizować kierowanie pociągów pasażerskich na tory przy peronach, a towarowych w miarę możliwości poza perony. Można także zrealizować formowanie, przejazd i rozformowanie składu.
Oczywiście, żeby nie było że tylko po próżnicy piszę posty - jako, że ten temat mnie interesuje i trochę doskwiera obecna postać, chętnie dołożę swój wkład w rozwój symulatora i zrealizuję wspomniane pomysły lub pomogę w ich realizacji. C, python, perl, rozproszone systemy wersjonowania kodu, a także po części C++, nie są mi obce.
