Odczytywanie komunikatów w autobusach i tramwajach

[MisiekK]

Bo zdaje się, że przetarg na Swingi to był przetarg ogłaszany przez TW?

Akurat przy SWING-ach nikt z niczym nie biega. Wyjaśniałem w innym wątku wielokrotnie ograniczenia jakie dostały 120Na - nie będę się powtarzał. Natomiast dlaczego inni systemy z obsługa ręczna zamawiają - nie wiem i nie chce wiedzieć.

MZA i TW nie ogłaszają przetargów bez uzgodnienia z ZTM-em SWIZ-u, a części dotyczącej informacji pasażerskiej w szczególności.

Więcej - nie mają na treść tego rozdziału wpływu.

[Szeregowy_Równoległy]

Znaczy MZA czy TW nie mają wpływu na to jaki SIP dostaną, chociaż będą go obsługiwać?

[MisiekK]

Znaczy MZA czy TW nie mają wpływu na to jaki SIP dostaną, chociaż będą go obsługiwać?

Tak, mistrzu. Tak samo jak i ajenci. Wymagania określa ZTM.

[Szeregowy_Równoległy]

Nie, mistrzu. ZTM określa co ma ten SIP potrafić. Co ma wyświetlać i co ma umieć powiedzieć i jak ZTM ma móc się z danym systemem kontaktować, bo tego ZTM również, jak wiesz, wymaga. A to, kto to dostarczy to już inna sprawa. Gdyby Mobilis miał kaprys, to by sobie wybrał firmę z garażu na Tajwanie a ekraniki składałyby głodne dzieci za miskę ryżu. I guzik by do tego ZTM miał, jeśli SIP umiałby to, czego ZTM wymaga. A ZTM wymagania ma tylko w części dotyczącej bezpośrednio informacji pasażerskiej: co ma być wyświetlane i w jaki sposób dane mają być dostarczane do SIP. Skoro przewoźnicy miejscy, przynajmniej niektórzy, zapragnęli badziewia przy którym trzeba biegać z kartami żeby zaktualizować oprogramowanie (nie dane z ZTM) to jest to problem przewoźników, a nie Organizatora.

[MisiekK]

ZTM określa co ma ten SIP potrafić.

Trafiłeś w sedno. Kostki wybiera producent, ale funkcjonalność określa organizator. Jeśli się do tego doda, że dla każdego przetargu na tabor wymagania bywają inne to już mamy pełny obraz. Mobilis tego co pamiętam ma chyba 2 lub 3 różne wymogi dla różnych transzy autobusów.

[Szeregowy_Równoległy]

Niemniej jednak pomimo różnych wymogów (aktualnie Mobilis jeździ w ramach czterech przetargów) zdecydowanie w większości jest Macrosystem. Bo skoro te wymogi spełnia, a poza tym jest dość przyjazny dla przewoźnika, to nikomu nie przyszło do głowy szukać czegokolwiek innego. Dlatego nie rozumiem czemu TW czy MZA nie szukały czegoś, co spełnia wymagania ZTM a jednocześnie potrafi obsługującym zaoferować ciut więcej niż bieganie z kartami między wozami. Uwzględnienie tego wymogu w SIWZ w żaden sposób by nie wpłynęło na część wymaganą przez ZTM, natomiast sporo by ułatwiło. I tego się czepiam.

[MisiekK]

Uwzględnienie tego wymogu w SIWZ w żaden sposób by nie wpłynęło na część wymaganą przez ZTM, natomiast sporo by ułatwiło.

Ale piszę ci - kostki są nieważne - dostajesz je z pojazdem. W wymogach jest sposób wyświetlania poszczególnych zdarzeń i treść. Możesz dodatkowo dostać w wymogach zgodność z rozkładem służbowym i nie masz wtedy wyboru - np świecisz ZET-ami, a potem zbierasz cięgi na forum, bo niektórzy tego nie rozumieją.

[px33]

Ale piszę ci - kostki są nieważne - dostajesz je z pojazdem.

Ale chyba można dopisać własne wymagania - ZTCW MZA tak robi (dają dwa pliki - jeden z rysunkami z ZTM i drugi z bardziej technicznym opisem, chyba ich własny).

A jeśli jednak ten zły ZTM ma tyle wymagań i nie pozwala żeby przewoźnik dorzucił do tego swoje, to naprawdę powinni przygotować swoje własne programy (najlepiej otwartoźródłowe i rozszerzalne zewnętrznymi pluginami), tak żeby przewoźnik musiał tylko zamówić sprzęt (zgodny ze specyfikacją), na który producent wgrałby gotowe oprogramowanie i ewentualnie rozszerzył je o obsługę swoich urządzeń (wgrał pluginy do swoich protokołów, ewentualnie jakieś rozszerzenia funkcjonalności).
Taki układ miałby jedną fundamentalną zaletę - wszystkie nowości pojawiałyby się na wszystkich pojazdach w ciągu tygodnia, w dodatku można by na bazie tego bardzo fajnie wdrażać wszystkie nowinki - rozkłady dynamiczne, dynamiczną informację, precyzyjne raportowanie dla ZTM, monitoring na żywo, nowy system kasowników - wystarczy żeby ZTM dostarczył moduły i wysłał aktualizację na serwer.

[MisiekK]

jeśli jednak ten zły ZTM ma tyle wymagań i nie pozwala żeby przewoźnik dorzucił do tego swoje

Nigdzie tego nie napisałem.

fajnie wdrażać wszystkie nowinki

Wybacz, ale nowinki to możesz sobie wdrażać w domu na prywatnym komputerze. Rzeczy wrzucane w przestrzeń publiczna muszą być uzgodnione, przetestowane, dopuszczone i zgodne z wymaganiami....

nowy system kasowników

Wiesz może jaki będzie i o co oparty?

[px33]

Nigdzie tego nie napisałem.

Ekhm,
"-Znaczy MZA czy TW nie mają wpływu na to jaki SIP dostaną, chociaż będą go obsługiwać?
-Tak, mistrzu. Tak samo jak i ajenci. Wymagania określa ZTM."
Jeśli można dopisać własne wymagania to nijak ma się to do stwierdzenia "nie mają wpływu". To chyba oczywiste, że ZTM nie określa tego, w jaki sposób ma być zrealizowany system tylko jak ma wyglądać efekt końcowy (plus pewne minima żeby np. ktoś zamiast stretcha 38" nie wstawił monitora 15" 4:3, czy tablic diodowych o niskiej rozdzielczości)

Wybacz, ale nowinki to możesz sobie wdrażać w domu na prywatnym komputerze. Rzeczy wrzucane w przestrzeń publiczna muszą być uzgodnione, przetestowane, dopuszczone i zgodne z wymaganiami....

I z tego powodu każde zamówienie ma mieć zamrożony na 8-40 lat system informacji? Zwalenie produkcji i rozwoju oprogramowania na ZTM sprawiłoby że wszystkie systemy byłyby tak samo "uzgodnione, dopuszczone i zgodne z wymaganiami...", a testy to byłaby już ich wewnętrzna sprawa, ale wątpię żeby ktoś wysłał aktualizację, która zabiłaby kilkaset pojazdów.

Wiesz może jaki będzie i o co oparty?

Jakikolwiek by nie był i o co nie byłby oparty, przy zunifikowanym oprogramowaniu wystarczyłoby dołożyć switch ethernetowy, wysłać nową wersję oprogramowania (identyczną dla wszystkich pojazdów, ewentualnie na 2 architektury) i można instalować. Przy otwartym oprogramowaniu systemu można zażądać, żeby dostawca nowego systemu sam dopisał moduł obsługujący kasowniki.

[MisiekK]

Jeśli można dopisać własne wymagania to nijak ma się to do stwierdzenia "nie mają wpływu".

Na funkcjonalność. Cały czas o tym mowa.

I z tego powodu każde zamówienie ma mieć zamrożony na 8-40 lat system informacji?

Sprzęt elektroniczny ma określony czas życia. W tym czasie podlega gwarancjom, rękojmiom etc. Zmiany dopiero po tym czasie - co widać na mieście.

wątpię żeby ktoś wysłał aktualizację, która zabiłaby kilkaset pojazdów

A ja takie aktualizacje widziałem. Wwalone bezmyślnie bez testów na serwer dystrybucyjny a potem latanie tabunu ludzi bo pojazdy muszą rano wyjść na miasto.

Jakikolwiek by nie był i o co nie byłby oparty, przy zunifikowanym oprogramowaniu wystarczyłoby dołożyć switch ethernetowy, wysłać nową wersję oprogramowania (identyczną dla wszystkich pojazdów, ewentualnie na 2 architektury) i można instalować. Przy otwartym oprogramowaniu systemu można zażądać, żeby dostawca nowego systemu sam dopisał moduł obsługujący kasowniki.

Nikt ci nie zrobi otartego oprogramowania. Szczególnie do kasowników, biletomatów etc. Zapomnij o tym. Poza tym te systemy są w każdym pojeździe autonomiczne (ba, nawet własny czas mają) ze względów, których można się łatwo domyśleć.

[px33]

Na funkcjonalność. Cały czas o tym mowa.

Aktualizacje programów w locie to też funkcjonalność. A (1) chyba o tym mówimy, przynajmniej ostatnio; (2) zażądanie czegoś takiego raczej nie łamałoby wytycznych ZTM.

Nikt ci nie zrobi otartego oprogramowania. Szczególnie do kasowników, biletomatów etc.

Otwarte nie miałoby być oprogramowanie kasowników tylko systemu informacji (tego zunifikowanego, dostarczanego przez ZTM). Za odpowiednie pieniądze na pewno jakiś dostawca napisałby taki system, bo to raczej nie powinna być strasznie skomplikowana sprawa. A udostępnienie tego na licencji wirusowej (np. GPL) sprawiłoby że ta firma niekoniecznie by na tym straciła, bo nikt inny nie włączyłby ich kodu do swojego projektu.
Dostawca kasowników musiałby dopisać moduł do tego systemu żeby system mógł obsługiwać jego kasowniki. Nikt nie kazałby producentowi kasowników otwierać źródeł programu w jego sprzęcie, publiczna byłaby tylko implementacja protokołu, a to i tak producent powinien ujawnić.

Poza tym te systemy są w każdym pojeździe autonomiczne (ba, nawet własny czas mają) ze względów, których można się łatwo domyśleć.

W każdym z wyjątkiem jakichś 99% systemów na świecie (a zwłaszcza w Polsce z monopolem R&G, ale światowy IBIS też ma takie założenie), w których kasowniki są sterowane przez ten sam sterownik co wszystko inne. A jeśli powodem rozdzielenia systemów ma być niezawodność, to przecież przy zamawianiu nowego systemu można zamówić sprytniejsze kasowniki - takie, z których jeden (dowolny) w przypadku awarii głównego systemu pojazdowego sam stawałby się serwerem i przejmował jego obowiązki.

[MisiekK]

W każdym z wyjątkiem jakichś 99% systemów na świecie (a zwłaszcza w Polsce z monopolem R&G, ale światowy IBIS też ma takie założenie), w których kasowniki są sterowane przez ten sam sterownik co wszystko inne.

W przypadku stołecznego Monetela (Syntaxa) jest to system autonomiczny we wszystkich pojazdach. Sterownik SPOzP pozwala sobie przysłać kablem dane do nastawy urządzeń (linia, brygada, strefa), zakończenie pracy i nic więcej. Resztę obsługuje sam (obsługa kasowników końcowych, dwustronna transmisja danych, wysyłanie raportów, synchronizacja czasu z wzorcem) i jest to dobre rozwiązanie.

[Szeregowy_Równoległy]

Jechałem 1406+1405, w drugim wagonie. Wagon gadał, ale podwójnie. Znaczy zapowiedź pojawiała się zarówno w związku z przejechaniem określonego dystansu od opuszczanego przystanku, bądź w określonej odległości od przystanku do którego pojazd się zbliżał, a niezależnie od tego zapowiedzi aktywowało otwarcie/zamknięcie drzwi. Coś jak w Macrosystemie jakiś czas temu.

[SławekM]

I tak sukces. Rok temu potrafił 4 razy ten sam przystanek zapowiedzieć.