Symulator EU07 (i nie tylko) > Na warsztacie
Opis logiczny scenerii - VD prace koncepcyjne
Paul:
Możesz dokładniej opisać, na jakich zasadach miałby działać Twój VD? Ja tu sobie wyobrażam system o następującej strukturze (odpowiadającej generalnie rzeczywistym systemom automatycznego sterowania, np. działających w centrach sterowania IECC):
infrastruktura przytorowa (zwrotnice, sygnalizatory, odcinki izolowane)
|
zależności wraz z przebiegowym nastawianiem, najlepiej o logice geograficznej
|
automatyka nastawiania przebiegów (ARS), działająca na podstawie śledzenia ruchu (przesuwania numerów wraz z przebiegami - PIP), rozkładu jazdy i poleceń dyspozytorskich z wyższych warstw ("dyżurny ruchu")
|
warstwa optymalizacji ("dyspozytor"), która na bieżąco sprawdza możliwość realizacji rozkładu jazdy poprzez prognozowanie rozwoju sytuacji ruchowej na uproszczonym modelu (np. CPN) i w razie potrzeby modyfikuje rozkład, np. przez zmianę kolejności jazdy lub torów ("polecenia dyspozytorskie")
Ogólnie widzę to jako oddzielną aplikację, może w serwerze, a może jako klient tego serwera (do serwera podłączamy klientów maszynistów i klientów sterujących ruchem). W ten sposób po stronie Maszyny do zrobienia jest dostosowanie scenerii i zapewnienie interfejsu (a ten już w zasadzie jest - WM_COPYDATA), ładowanie tego do exe symulatora jest niepotrzebne i niewskazane (jeżeli już, to jako zewnętrzny, dynamicznie linkowany moduł). Sceneria jest jedynie warstwą wykonawczą (eventy podające sygnały, przestawiające zwrotnice, zamykające przejazdy itp.), potrzebne dane o sieci i rozkładzie jazdy wprowadzane i przetwarzane są niezależnie. Jeżeli sceneria ma także działać bez tego systemu, trzeba przewidzieć opcjonalnie włączany plik, a najlepiej dwa pliki: z eventami sterującymi ruchem (zależności przebiegowe) i eventami kierującymi ruchem (konkretny scenariusz/rozkład jazdy). Eventy te muszą być jednak odseparowane od eventów wykonawczych, tak żeby można było je wyłączyć gdy nie są potrzebne (sterowanie ruchem przez opisany system).
Do prostej automatyki sterowania ruchem w symulatorze wystarczą w zasadzie pierwsze trzy warstwy (sceneria, zależności, ARS), pod warunkiem że zapewnimy unikanie zakleszczeń (deadlock) na odcinkach jednotorowych. Coś takiego już testowałem z niezłymi efektami. Może będę jeszcze rozwijał ten temat, jako że wszystkie warstwy nad infrastrukturą przytorową pokrywają się z tym, co robię i testuję we własnym symulatorze srk, i mogą znaleźć zastosowanie i tu, i tu.
firleju:
Architektura wygląda mniej więcej tak:
Opis scenerii (tory, W5, W4, semafory, odcinki)
|
Opis zależności których nie da się opisać w scenerii (niektore zalezności potrzebne dla srk oraz wyizolowanie stacji, szlaków, itp.) plus ewentualne odcinki pokrywające się z tymi już zdefiniowanymi (chyba, że będzie się dało przypisać więcej niż jeden odcinek)
|
automatyka przebiegów bazująca na opisie urządzeń pb wraz z zakodowaniem wszystkich elementarnych urządzeń bez blokad liniowych, gdyż to można zrobić na zasadzie rezerwacji w warstwie wyższej
|
dyspozytor ustalający skąd-dokąd i w jakiej kolejności. Modeli teoretycznych do ewentualnych optymalizacji nie znam więc tu jest wielkie pole do popoisu dla wszystkich chętnych.
Aplikacja w wersji klient serwer, gdyż nie ma sensu bawić się we wkompilowywanie tego do exe. Jeśli chodzi o przesylanie danych to z tego co wiem wtedy musisz oprócz exe uruchomić osobny maly "serwer", który bierze schowek i wyrzuca go do sieci. Tutaj wolałbym bezpośrednio zlinkować bibliotekę do komunikacji (np ZeroMQ) do exe. Nie wiem tylko czy się da, ale to nie jest ten etap na którym należy się przejmować sposobem komunikacji.
Sterowanie urządzeniami bezpośrednio, tzn ewentualne wywoływanie eventów takich jak przestaw zwrotnicę czy wyświetl sygnał. w tej chwili widzę taki problem, że sygnalizatory są sterowane eventami z nazwami sygnałów takimi jak w Polsce i wtedy serwer jest niemożliwy do zastosowania z innymi systemami sygnalizacyjnymi. Jakiś pomysł na bardziej uniwersalne rozwiązanie?
Tak w zasadzie nie ma sensu mieszać scenerii sterowanych za pomocą VD z tymi sterowanymi za pomocą eventów, gdyż rozkład jazdy przygotowany dla tej pierwszej musi mieć zupełnie inną formę, tj. rozkład musi zawierać także wszelkiego typu manewry oraz jeśli dobrze to myślę to także zdefiniowane nazwy torów na których ma się znaleźć (z ewentualnymi alternatywami). Zakładam, że tak jest łatwiej zorganizować VD niż bawić się w szukanie poszczególnych elementów na podstawie tego co dany pociąg ma robić. No i rozkład musi być pisany odrębnie dla każdego pojazdu poruszającego się od początku do końca działania symulacji.
W tej chwili ruszam warstwę 1 i 2, tzn przenoszę kod z pracy magisterskiej (nie mogę go bezpośrednio użyć) na C# zmieniając niektóre rzeczy (np aby ewentualnie dało się symulować także działanie urządzeń innych typów w przypadku sterowania ręcznego)
Paul:
--- Cytat: gfirlejczyk w 28 Marca 2015, 15:17:07 ---w tej chwili widzę taki problem, że sygnalizatory są sterowane eventami z nazwami sygnałów takimi jak w Polsce i wtedy serwer jest niemożliwy do zastosowania z innymi systemami sygnalizacyjnymi. Jakiś pomysł na bardziej uniwersalne rozwiązanie?
--- Koniec cytatu ---
Na obcych sieciach mogą być inne zasady sygnalizacji i logika zależnościowa (np. w sygnalizacji szwedzkiej występują różne sygnały manewrowe, informujące czy droga przebiegu jest zorganizowana oraz czy jazda odbywa się na tor wolny), nazwy sygnałów to chyba mniejszy problem, można je ewentualnie definiować w konfiguracji systemu sterowania ruchem (jakieś ogólne ustawienia dla danej scenerii). Dochodzą tu jeszcze lokalne specyfiki posterunków, np. semafory ze starymi sygnałami.
--- Cytat: gfirlejczyk w 28 Marca 2015, 15:17:07 ---Tak w zasadzie nie ma sensu mieszać scenerii sterowanych za pomocą VD z tymi sterowanymi za pomocą eventów, gdyż rozkład jazdy przygotowany dla tej pierwszej musi mieć zupełnie inną formę, tj. rozkład musi zawierać także wszelkiego typu manewry oraz jeśli dobrze to myślę to także zdefiniowane nazwy torów na których ma się znaleźć (z ewentualnymi alternatywami).
--- Koniec cytatu ---
Miałem na myśli raczej wykorzystanie samej infrastruktury przez VD i scenariusze programowane eventami. Jeżeli eventy wykonawcze zostaną umiejętnie rozdzielone od sterujących, to powinno to być możliwe (jak pisałeś na początku, trzeba np. przenieść eventy uruchamiające jakieś procedury scenariusza z wpisów torów do oddzielnego pliku).
Tak w ogóle, żeby takie koncepcje mogły być kiedyś wprowadzone do życia, trzeba by z wyprzedzeniem określić jakieś standardy nazewnictwa urządzeń, torów, eventów, rozmieszczenia odcinków w sceneriach itp.
firleju:
--- Cytuj ---Na obcych sieciach mogą być inne zasady sygnalizacji i logika zależnościowa (np. w sygnalizacji szwedzkiej występują różne sygnały manewrowe, informujące czy droga przebiegu jest zorganizowana oraz czy jazda odbywa się na tor wolny), nazwy sygnałów to chyba mniejszy problem, można je ewentualnie definiować w konfiguracji systemu sterowania ruchem (jakieś ogólne ustawienia dla danej scenerii). Dochodzą tu jeszcze lokalne specyfiki posterunków, np. semafory ze starymi sygnałami.
--- Koniec cytatu ---
Tutaj bardziej mi chodzi o to, że nazwy sygnałów są konkretnym wzorem na sygnalizatorze a nie muszą być. Można to zrobić w ten sposób, że w zależności od przyjętego schematu sygnalizowania (np. polski, niemiecki, itp.) wysyłamy odpowiednią komendę do wybranego sygnalizatora, ale nie w postaci wyświetl taki wzór, a raczej wyświetl prędkość na tym taką, a na następnym jest taka (czy jakie tam parametry jeszcze będą potrzebne). A sam sygnalizator dobiera sobie już informację jaką wyświetli.
Pojawia się kwestia jak dobierać prędkość przebiegu (zapewne z torów). To mogłoby działać w taki sposób, że wysyłasz mu, że ma maksymalną prędkość przebiegu 60 km/h a sygnalizator stwierdza, że nie ma takiej opcji i wyświetla tylko 40. W tej chwili jest ten nowy wskaźnik do podania prędkości i on tu dużo zmienia sygnał chyba ciągle nazywa się tak samo, a sam wskaźnik może wyświetlać rożne prędkości. Myślę, że łatwiej by było stworzyć API (a raczej zestaw danych obligatoryjnych oraz dodatkowych) przesyłanych do sygnalizatorów danego systemu niż bawić się w mapowania. Im więcej można objąć przypadków bez wyjątków tym lepiej.
--- Cytuj ---Miałem na myśli raczej wykorzystanie samej infrastruktury przez VD i scenariusze programowane eventami. Jeżeli eventy wykonawcze zostaną umiejętnie rozdzielone od sterujących, to powinno to być możliwe (jak pisałeś na początku, trzeba np. przenieść eventy uruchamiające jakieś procedury scenariusza z wpisów torów do oddzielnego pliku).
--- Koniec cytatu ---
Im dłużej o tym myślę tym bardziej widzę, że prawdopodobnie infrastruktura zrobiona pod vd (to co wyżej) będzie wymagała na tyle dużych zmian w plikach scenerii, że usunięcie eventów sterujących scenariuszem to będzie przy tym nie problem. Mogę się mylić, zobaczymy co wyjdzie.
--- Cytuj ---Tak w ogóle, żeby takie koncepcje mogły być kiedyś wprowadzone do życia, trzeba by z wyprzedzeniem określić jakieś standardy nazewnictwa urządzeń, torów, eventów, rozmieszczenia odcinków w sceneriach itp.
--- Koniec cytatu ---
Wydaje mi się, że będą potrzebne tylko zmiany w urządzeniach sterujących. Całą resztę można można w pewien sposób wyciągnąć jeśli np. kozioł oporowy dostanie swój przypisany typ co raczej nie będzie problemem. Nazewnictwo sterujące zwrotnicami jest juz usystematyzowane, sygnalizacje opisałem wyżej, wykolejnice tez, przejazdy z tego co wiem to też mają pewien schemat. Nie ma rozróżnienia na tory główne i boczne - jazda pociągowa czy manewrowa - (rozróżnianie po typie semafora na końcu albo jego braku?), te z peronami można rozróżnić po przypisaniu W4.
El Mecánico:
Generalnie zasady nazewnictwa elementów infrastruktury można przenieść (przynajmniej dla scenerii zlokalizowanych na pl_PL) z instrukcji PLK. Dalej zależności i eventy wykonawcze (czyt. przekaźnikownia) należy zrobić na diagramie drabinkowym. Jakby ktoś miał przykładowy schemat elektryczny prostej nastawni, do mogę łatwo szybko przygotować diagram z plikiem pod LDmicro (oczywiście human readable)
Nawigacja
[#] Następna strona
Idź do wersji pełnej