Symulator małej stacji z mechanicznymi USRK

[jageer]

Dąży się do optymalizacji liczby drążków przebiegowych tak, by zamykać przebiegi jak najmniejszą liczbą drążków przebiegowych.

Ogólnie, w przypadku prostej stacji i szlaku 2 torowego (blokada 1 kierunkowa), może się zdarzyć jeden drążek, dla wyjazdu z wszystkich torów

[marcinw]

[ciach beziery]
W takim razie zaimplementuję

Czy równolegle do symulatora rozwijasz jakiś edytor scenerii?

Tak, z tym, że jeszcze nie jestem pewny, w jakim dokładnie kierunku powinienem iść.

Aktualnie wszystko edytowane jest w samym edytorze unity. Na bieżąco piszę do niego skrypty, które ułatwiają tworzenie typowo kolejowych rzeczy, np. tory czy zwrotnice podczas edycji przyciągają się (snap) końcówkami (pozycja i orientacja), jest narzędzie do wstawiania trakcji, które automatycznie wstawia odpowiedni słup/wieszak (naprzemiennie długi/krótki lub seria takich samych) i łączy z poprzednim drutami odpowiedniego typu, semafory z automatu 'podłączają' się do najbliższego toru, czy też skrypt, który napisałem wczoraj, który wyznacza i odpowiednio nazywa wszystkie potencjalnie możliwe przebiegi spod zadanych semaforów.

Przykładowy screen:
https://www.dropbox.com/s/smyk8t0q90wb33z/editing.png?dl=0

Zaletą edycji w edytorze unity jest to, że można zrobić praktycznie wszystko, bo to bardziej podchodzi pod tworzenie 'moda', niż prostej scenerii (masz nawet normalny debugger dostępny do skryptów). Kolejna zaleta to otwartość, tzn. jak choć trochę znasz c# albo nawet javascripta, to możesz samemu pisać rozszerzenia, łącznie np. z eksportem do innego formatu, chociażby MaSzynowego. Wadą znowu jest ogrom opcji zupełnie zbędnych, jeśli jedyne, co chcemy zrobić, to stworzyć nową stacyjkę, no i możliwość popsucia czegoś przez przypadek, jak np. wstawimy semafor i przypadkowo wywalimy z niego skrypt, który go obsługuje. Musiałbym pogadać i poeksperymentować z ludźmi, którzy zajmują się tworzeniem poważnych scenerii, czego tak na prawdę potrzebują.

Unity ma tę fajną właściwość, że skrypty, które działają w jego edytorze, mogą również działać w programie wynikowym, więc te wszystkie rzeczy będę mógł również wykorzystać w edytorze dedykowanym, jeśli będzie na coś takiego realne zapotrzebowanie.

Myślę nad opcją, która mogłaby zadowolić zarówno laików jak i 'power userów', że wypasione scenerie robiłoby się za pomocą edytora unity, zaś prostsze stacyjki czy posterunki (jak np. ta aktualna) robiłoby się w prostym, dedykowanym edytorku wbudowanym w grę, który może nie pozwoli na odwzorowanie jakiś skomplikowanych węzłów, za to przypilnuje, aby to, co robimy, było zgodne z przepisami.

Ale to ewentualna przyszłość

Komunikat może być potwierdzony, ale czy to oznacza, że zwrotnica/sygnalizator się przestawił? Jeżeli tak, nie ma problemu. Ale tak jak pisałem, wystarczy że ktoś pomyli nazwę obiektu edytując dane dla nastawni i mimo że komunikat zostanie odebrany, to założenie że rozkaz został wykonany będzie błędne, a efektem będzie katastrofa w symulatorze. Ja bym projektował interfejsy czy komunikację tak, żeby była odporna na takie błędy, bez sterowania na ślepo.

Zgadzam się, niemniej jeśli klient dostanie rozkaz, którego wykonać nie może, to to oznacza fatalny błąd na który i tak nic nie poradzimy, więc taki klient powinien się chyba rozłączyć z odpowiednim komunikatem?


A jeszcze co do aparatu blokowego, jaka jest procedura zwalniania przebiegu? Dyżurny sam zwalnia kiedy wie, że można to zrobić bezpiecznie, czy też jest to od czegoś uzależnione?

[Paweł Piotr]

A jeszcze co do aparatu blokowego, jaka jest procedura zwalniania przebiegu? Dyżurny sam zwalnia kiedy wie, że można to zrobić bezpiecznie, czy też jest to od czegoś uzależnione?

Utwierdzony blokiem przebiegowo-utwierdzającym (Pu) przebieg w warunkach normalnej eksploatacji zostaje zwolniony przez pociąg, po minięciu tzw. przebiegowego miejsca końca pociągu, wskazanego w Regulaminie Technicznym Stacji (RTS), to jest miejsca, gdzie ostatnia oś pociągu opuściła ostatnią zwrotnicę utwierdzonego przebiegu. W tym miejscu w torze znajduje się element, powodujący dostarczenie impulsu prądu stałego do bloku Pu.
W dawnych rozwiązaniach dla przebiegów wjazdowych do stacji były także stosowane zwalniacze kluczowe w terenie: pracownik w terenie sprawdzał, czy pociąg wjechał z sygnałami końcowymi i minął przebiegowe miejsce końca pociągu, po czym przy pomocy klucza w specjalnym zamku powodował zwarcie obwodu elektrycznego prądu stałego do zwolnienia bloku Pu.
Utwierdzenie można także zwolnić doraźnie (w uzasadnionych przepisami przypadkach) przez obsłużenie plombowanego zwalniacza na samym bloku Pu.
Po zwolnieniu utwierdzonego przebiegu (tarczka w okienku bloku Pu zmieniła się z białej na czerwoną) i po nastawieniu na semaforze sygnału "stój" można przełożyć do położenia zasadniczego drążek przebiegowy, który zamykał zwrotnice dla tego przebiegu.

[Paweł]

Komunikat może być potwierdzony, ale czy to oznacza, że zwrotnica/sygnalizator się przestawił? Jeżeli tak, nie ma problemu. Ale tak jak pisałem, wystarczy że ktoś pomyli nazwę obiektu edytując dane dla nastawni i mimo że komunikat zostanie odebrany, to założenie że rozkaz został wykonany będzie błędne, a efektem będzie katastrofa w symulatorze. Ja bym projektował interfejsy czy komunikację tak, żeby była odporna na takie błędy, bez sterowania na ślepo.

Nastawnia w takiej sytuacji może pracować dalej, tylko dany przebieg się nie ustawi, efekt będzie taki jakby wystąpiła usterka urządzenia (urządzenie "nie odpowiada"). Można zamiast potwierdzeń wykonania przesyłać komunikaty o błędzie i niewykonaniu polecenia. Ale i tak moduł symulujący nastawnię będzie musiał to poodwracać i wygenerować sobie meldunki kontroli stanu urządzeń z odpowiednimi opóźnieniami czasowymi, o ile nie dostanie informacji o niewykonaniu polecenia. Wydaje mi się, że bardziej naturalnie jest po prostu przesyłać potwierdzenia z symulatora ruchu.

[marcinw]

Pawle Piotrze:
Super, o to mi chodziło

Nastawnia w takiej sytuacji może pracować dalej, tylko dany przebieg się nie ustawi, efekt będzie taki jakby wystąpiła usterka urządzenia (urządzenie "nie odpowiada"). Można zamiast potwierdzeń wykonania przesyłać komunikaty o błędzie i niewykonaniu polecenia. Ale i tak moduł symulujący nastawnię będzie musiał to poodwracać i wygenerować sobie meldunki kontroli stanu urządzeń z odpowiednimi opóźnieniami czasowymi, o ile nie dostanie informacji o niewykonaniu polecenia. Wydaje mi się, że bardziej naturalnie jest po prostu przesyłać potwierdzenia z symulatora ruchu.

Hmm, zaraz, teraz to już zupełnie zgłupiałem. Kto wysyła te meldunki? Masz coś jeszcze pomiędzy symulatorem nastawni a symulatorami prowadzenia pociągu? W końcu klienci od pociągów potwierdzeń wysyłać nie mogą, bo każdy mógłby coś innego wysłać i dopiero byłby bajzel

[Paweł]

Kto wysyła te meldunki?

Ten, kto symuluje ruch po scenerii i działanie urządzeń wykonawczych (przestawianie zwrotnic, wykolejnic, sygnalizatorów).

Napisałem o generowaniu meldunków przez nastawnię - chodzi o to, że jeżeli symulator jazdy nie będzie przesyłał meldunków położenia zwrotnic/stanu sygnałów, a jedynie potwierdzi odebranie komunikatu z rozkazem, to symulator nastawni będzie musiał generować meldunki sam sobie - np. wysyła rozkaz przestawienia zwrotnicy, i jeżeli nie ma żadnego błędu, to po 3 sekundach generuje meldunek zajęcia położenia końcowego (meldunki takie są wymagane dla urządzeń stacyjnych, dla których położenie zwrotnicy jest sygnałem z zewnątrz, a nie bezpośrednim wynikiem sterowania).

[marcinw]

U siebie przyjmuję takie założenia:
1. Zawsze nastawnia symuluje działanie swoich urządzeń, więc i meldunki sama sobie wewnętrznie organizuje.
2. Każdy symulator prowadzenia pociągu symuluje fizykę swojego składu i po prostu rozsyła pozycje wszystkich 'swoich' pojazdów do reszty.

Wydaje mi się to najprostsze. Nawet, jak będzie kilka nastawni i kilka składów to będzie jasny podział, kto co obsługuje, no i reszta klientów nie musi się martwić o to, jak działają urządzenia wykonawcze. Nie mniej jeśli widzisz tu jakieś potencjalne problemy to daj znać, założenia udoskonalimy albo zmienimy całkowicie

Punkt 2 trochę komplikuje współpracę pomiędzy kilkoma składami (jak sobie odłączymy wagony i ktoś inny będzie się chciał pod nie podłączyć, to nasz klient będzie musiał mu je niejako 'przekazać na własność'), ale wydaje mi się, że jest to nieuniknione przy grach sieciowych.

Alternatywą jest posiadanie jednego wielkiego serwera, który będzie symulował działanie wszystkiego (czyli wszystkich urządzeń wykonawczych oraz fizyki wszystkich pojazdów) na scenerii, ale to znowu byłoby bardzo upierdliwe, bo nie dość, że taki serwer trzeba by gdzieś mieć, to jeszcze prowadzenie składu za jego pośrednictwem byłoby bardzo toporne przy dużych lagach w internecie.

[Paweł]

W ISDR rozwiązane jest to w dużym uproszczeniu w następujący sposób:

symulacja urządzeń stacyjnych (wewnętrznych - pulpity nastawcze, system zależności)
|
symulacja ruchu i urządzeń wykonawczych (zewnętrznych - napędy zwrotnicowe/Wk, sygnalizatory, obwody torowe)

W celu integracji z symulatorem jazdy czy innym środowiskiem, w którym działać ma nastawnia, zastępujemy symulację ruchu i urządzeń wykonawczych zewnętrzną aplikacją. Urządzenia wykonawcze srk są generalnie elementami układu torowego, odwzorowanego w module, który będzie symulował ruch pojazdów po tym układzie.

Nie do końca wiem jaką zakładasz architekturę symulacji sieciowej, dotąd zakładałem, że będzie jakiś serwer który to wszystko koordynuje i na nim będą odwzorowane urządzenia wykonawcze, on by się zajmował również przesuwaniem pojazdów po układzie torowym na podstawie własnej symulacji (AI) lub wyliczeń od klientów-maszynistów, oraz detekcją kolizji.

Można założyć, że działanie urządzeń wykonawczych symulowane będzie po stronie symulatora nastawni, a symulator ruchu jedynie będzie otrzymywał informacje o zmianach stanu tych urządzeń. W takiej sytuacji nastawnia w zasadzie nie steruje i kontroluje urządzeń zewnętrznych, a jedynie nimi steruje, zakładając, że one po drugiej stronie są i działają jak należy. Moduł symulacji urządzeń stacyjnych w zasadzie nadal opiera się na meldunkach kontroli, z tym, że nie są one przysyłane z symulatora ruchu, a sztucznie generowane przez moduł interfejsu po stronie nastawni.

Jest to nie do końca zgodne z ideą działania systemów srk, ale na upartego można tak to rozwiązać. Wykluczamy wtedy niektóre sytuacje awaryjne urządzeń wykonawczych, np. tabor stoi na zwrotnicy i zwrotnica nie może się przełożyć - dla symulatora nastawni zawsze się przełoży. Ale tak czy inaczej symulator ruchu będzie musiał wysyłać meldunki zmiany położenia zwrotnic przy ich rozpruciu przez tabor, czy też gdy ktoś je zacznie w terenie korbować, o ile zakładamy taką możliwość.

[marcinw]

Jest to nie do końca zgodne z ideą działania systemów srk, ale na upartego można tak to rozwiązać. Wykluczamy wtedy niektóre sytuacje awaryjne urządzeń wykonawczych, np. tabor stoi na zwrotnicy i zwrotnica nie może się przełożyć - dla symulatora nastawni zawsze się przełoży.

Nie trzeba wykluczać, bo nastawnia wie, gdzie są wszystkie pojazdy na stacji i zanim coś przestawi to może sprawdzić, czy tor nie jest zajęty. Wydaje mi się, że różnica u nas w architekturze jest generalnie taka, że Ty zakładasz osobny centralny serwer ruchu, kiedy ja mam architekturę bardziej rozproszoną, gdzie nastawnie są niejako lokalnymi 'pseudo serwerami'.

Zresztą do końca tygodnia powinienem dać radę przygotować wszystko na bardziej publiczny test, wiec zobaczymy, jak się to wstępnie sprawdzi w praktyce w normalnym działaniu

Ale tak czy inaczej symulator ruchu będzie musiał wysyłać meldunki zmiany położenia zwrotnic przy ich rozpruciu przez tabor, czy też gdy ktoś je zacznie w terenie korbować, o ile zakładamy taką możliwość.

Zgadza się. I z tej strony wg mnie powinno to działać tak, jak to opisałeś wcześniej, że korbujący wysyła info do właściciela zwrotnicy (czyli lokalnej nastawni), że korbuje, a ona już rozsyła to info do wszystkich klientów, że zwrotnica się przestawiła, bo ktoś ją przestawił ręcznie.

[Paweł]

Jako moduł nastawni mam na myśli zewnętrzny moduł, którego zadaniem jest odwzorowanie działania urządzeń wewnętrznych srk (pulpity, systemy zależności). Wymiana danych między nastawnią a modułami symulującymi ruch i pojazdy odbywa się pojedynczym torem komunikacyjnym i obejmuje takie informacje, jakie podałem na początku. Rzeczy takie jak położenia osi na układzie torowym nastawnię nie interesują - to się dzieje w terenie, do nastawni dochodzą jedynie meldunki zajęcia obwodu torowego i położeń zwrotnicy.

Przy takim rozwiązaniu jakie proponujesz, trzeba by przewidzieć między nastawnią a symulatorami dodatkowo serwer nastawni, który opiera się na programie symulatora ruchu i komunikuje się ze wszystkimi klientami, także z modułem symulującym nastawnię, a ponadto może mieć dokładny obraz sytuacji ruchowej i pełnić funkcję wizualizacji sytuacji ruchowej 3D.

[taper]

Zgadza się. I z tej strony wg mnie powinno to działać tak, jak to opisałeś wcześniej, że korbujący wysyła info do właściciela zwrotnicy (czyli lokalnej nastawni), że korbuje, a ona już rozsyła to info do wszystkich klientów, że zwrotnica się przestawiła, bo ktoś ją przestawił ręcznie.

Czy stan zwrotnicy nie potrzebny jest tylko właścicielowi zwrotnicy(nastawni) i pociągowi którego ta czynność dotyczy?

[Paweł]

Czy stan zwrotnicy nie potrzebny jest tylko właścicielowi zwrotnicy(nastawni) i pociągowi którego ta czynność dotyczy?

Interesuje wszystkich klientów, którzy działają na fragmencie scenerii, w którym jest zwrotnica.

[marcinw]

W sobotę około godziny 21:00 (czas PL) będę robił testy online symka aby zobaczyć, jak się zachowa przy większej liczbie użytkowników. Kto by dał radę być online w tym terminie i chciał mi pomóc potestować, dajcie proszę mi znać tutaj albo na PW. Wymagana tylko umiejętność prowadzenia eu07 (już uruchomionej) lub obsługi nastawni mechanicznej, tudzież chęć zgłaszania błędów i własnych pomysłów na usprawnienia.

Jak wstanę to opisze wszystko szczegółowo, wrzucę gdzieś plan stacji i przykładowy filmik, aby pokazać, co i jak (bo teraz to prawie zasypiam przy kompie...)

[jageer]

Ja mogę pomachać wajchami.

[DamDam]

Rezerwuję kierowncę siódemki.