Łódzkie Forum Komunikacyjne

1179 - w automacie nie działa płatność kartą, oraz automat nie przyjął żadnej z posiadanych przeze mnie monet. Czyli jazda na gapę
Konstal 1834 - automat nieczynny

Są sprawdzane codziennie - na każdej z zajezdni jest ekipa serwisowa od producenta. Poza tym producent i MPK mają wgląd w oprogramowanie i jak coś wyskoczy na ekranie to niektóre awarie da się usunąć zdalnie albo zrobić reset.
Niektóre awarie są krótkotrwałe. Wczoraj byłem świadkiem takiej sytuacji w Konstalu na "8" - po kilku minutach zaczął się restartować i wrócił do życia.

A ostatnio w którymś pojeździe MPK byłem świadkiem, jak w biletomacie nie działało prawidłowo podświetlenie wyświetlacza.

Coś takiego sprzęt też wykrywa i oprogramowanie to zgłasza?

Albo przynajmniej kierowcy/motorniczowie sprawdzają takie rzeczy i zgłaszają w razie usterki?

Ja co jadę 82 (z 4-5 razy tak miałem) to zawsze pierwsza próba zakupu jest nieudana i dopiero za drugim razem wychodzi...
Ogólnie wolne są te urządzenia, wydaje mi się, ze w ŁKA jest trochę lepiej.

Jak dla mnie, właśnie te ŁKA są wolne. Czasem trzeba długo czekać, aż bilet wyjdzie, a czasem jeszcze wyjdzie jego mały kawałek taki, że nie da się go złapać i wyciągnąć, po czym się tak zatnie na kilkanaście sekund. Po tym, jak ktoś kupi bilet, znów trzeba czekać kilkanaście sekund, aż automat przejdzie do ekranu głównego. Jak się przez pomyłkę wejdzie w gotówkę chcąc zapłacić kartą i wybierze "anuluj" - trzeba poczekać, aż sobie pomieli mechanicznymi częściami od obsługi gotówki, i dopiero wyjdzie z opcji "gotówka".

Plus brak możliwości kupienia biletu ze stacji innej, niż ta, z której właśnie odjechał pociąg, w którym znajduje się dany automat i brak możliwości kupienia biletu z przesiadką. Przydałaby się też możliwość kupowania biletów na zapas do skasowania w kasowniku. Strasznie niefunkcjonalne są te automaty.

Biletomaty w ŁKA działają na Windowsie 8, więc nic dziwnego Pamiętam jak w jednym z pierwszych dni kursowania ŁKA pojechałem do Sieradza, to przez calutką trasę dwóch "inżynierów" z laptopem próbowali ten biletomat uruchomić - bilety oczywiście sprzedawał konduktor ze swojej drukareczki.

Ale to raczej nie jest Windows taki jak na pecety, tylko wersja Embedded - dedykowana na systemy wbudowane. To nie jest to samo.

Interfejs Metro w Embedded ?

Jak widać, tak: https://www.youtube.com/watch?v=DGSyirScOfI

kuba_łódź pisze:Interfejs Metro w Embedded ?

A w czym problem? GUI to już kwestia środowiska .NET. Zaś "kernel" to inna sprawa. GUI Metro w zamysłach miało mieć znacznie uproszczone API względem np WinForms i jakoś jest i smartfonach z Windowsem 10. Windows XP jako platforma dla aplikacji embedded to już historia.

Jednak przez pół roku od startu ŁKA z biletomatami był ciągły problem, i mam wrażenie że to nie byla wina aplikacji obsługującej automat. Windows XP Embedded ma wsparcie jeszcze przez rok, więc chyba to jeszcze nie taka historia. W praktyce można spotkać jeszcze starsze systemy w tego typu urządzeniach, przykładowo w Tesco w Galerii Łódzkiej kasy działały pod kontrolą Windows NT 4.0

Jeden z łódzkich radnych wystosował propozycję ustawy, na mocy której w przypadku, gdy automat biletowy nie działa, a my chcemy nabyć bilet, w przypadku kontroli biletów nie zostajemy ukarani, gdyż kontlorerzy będą sprzedawać takim osobom bilety 60-minutowe. W przypadku braku pieniędzy - po zakupie biletu za ten przejazd w czasie 7 dni opłata zostałaby anulowana.

Uważam, że jest to bardzo uczciwe posunięcie, ale takia liberalna postawa doprowadziłaby do nadużyć, a może nawet masowego sabotażu automatów. Wszakże dzikości pośród społeczeństwa nie brakuje.

Bez przesady, jakoś we Wrocławiu nikt automatów nie niszczy, a przynajmniej nie masowo.

@prof_klos: to już nie propozycja, a fakt. Uchwała została podjęta przez radnych i czekamy na jej wejście w życie.

Co do nadużyć - MPK na bieżąco monitoruje działanie biletomatów, więc jak będzie widać zwiększenie ilości awarii to pewnie będzie reakcja. Poza tym pytanie w jakim stopniu taki biletomat tylko na kartę można zepsuć, bo powiem szczerze że nie mam pomysłu. Co innego te na gotówkę, ale takie są w mniejszości pojazdów.

Np. może stracić łączność z systemem bankowym.

Mogą też być chociażby problemy po stronie banku osoby płacącej, w ogóle uniemożliwiające płacenie kartą. Były takie przypadki.

Tylko, że w uchwale (projekt był dostępny na stronie UMŁ) wyraźnie zapisano że w przypadku awarii potwierdzonej przez kontrolera. Kontroler nie jest w stanie stwierdzić czy ktoś ma problem z łącznością z bankiem czy może nie ma środków na koncie.

A to są właśnie najczęstsze przypadki problemów z biletomatem.

Niech chociaż będzie tak, że jak wszystkim pasażerom biletomat odrzuca transakcje (bez względu na bank i rodzaj karty, nawet dla konkretnie transakcji zbliżeniowej - bo skąd pasażer ma wpaść na to, że to może nie działać dla zbliżeniowej a działać z wetknięciem karty?), to uznawane jest to za awarię biletomatu.

kuba_łódź pisze: Windows XP Embedded ma wsparcie jeszcze przez rok, więc chyba to jeszcze nie taka historia.

Rok to już ostatni dzwonek jak masz przejsć na nowe środowisko. Prototyp, budowa aplikacji, testy, wdrożenie do produkcji, wymiana, migracja u klienta.

kuba_łódź pisze: W praktyce można spotkać jeszcze starsze systemy w tego typu urządzeniach, przykładowo w Tesco w Galerii Łódzkiej kasy działały pod kontrolą Windows NT 4.0

Równie dobrze możnaby znaleźć i tylko tryb tekstowy pod DOS w takich zastosowaniach . Czemu nie, jak działa niezawodnie to po co zmieniać i robić sobie problemy. Środowisko graficzne szczególnie tak ciężkie jak w wykonaniu M$ czyli .NET nie jest żadną zaletą. Ja pamietam systemy oparte na terminalach, proste niezawodne. Wszystko uruchamiane na serwerze tylko prosty transfer niewielkich pakietów - dawało sobie to radę nawet na 9.6 kbit/s. Podobnie do borlandowskiego Turbo Vision (albo Clarion'a dla DOS'a) to dla świata terminalowego dla unix'ów były oferowane całkiem rozbudowane systemy okienkowe. Często były scalane z bazodanowymi API. Dla takich kas naprawdę wystarcza prosty tryb tekstowy. Nawet TCP/IP nie potrzeba.

Co do możliwosci graficznych w trybie tekstowym. O ile tryb tekstowy MS-DOS był pod tym wzgłędem ubogi to szeroka implementacja ANSI np. w Amidze pozwałała na bardzo złożone grafiki budowane ze standardowego zestawu znaków (było np. dostępre przesnięcia o ułamek więrsza, o ułamek kolumny).

Wracając do NT4.0 Ostanie klasyczne NT to 3.51 to jeszcze to co powstało w sumie w firmie Digital / DEC. Potem to były mało udane niestety próby przeszczepania kiepskich rozwiązań z linii Windows 3.11 z Win32 / Windows 95. Po dziś dzień w Win 10 x64 są jeszcze absurdy wnikające z zamierzchłej przeszłości jak różne limity na długość nazwy pliku, ściezki dostępu itd. Windows XP był znany z tego iż tam były nadal słabo scalone te dwa światy - np. IP Forwarding - części kodu korzystała z konfiguracji odziedziczonej po jednej rodzinie windows i było do tego GUI a dla pozostałej cześci trzeba było ręcznie rejestr modyfikować. Jedyną zaletą XP było to iż był mało skażony .NET'em.

Obok dawnego Win NT 3.51 to IBM'owski OS/2 były naprawdę przemyślanymi i dobrymi OS'ami. Niestety M$ naobiecywał i z musu porzez nakładkę i to w bardzo pierwotnej wersji na MS-DOS'a wykorzystał jeden jedyny atut - odpalanie starych gier by zmonopolizować rynek.

W Solarisie 1560 biletomat wywala błąd połączenia z centrum rozliczeniowym. Zostaje jazda na gapę.

Ja niedawno trafiłem na przypadek, gdzie w biletomacie nie była dostępna płatność kartą, ale była dostępna Blikiem.

Czy coś takiego liczy się jako awaria uprawniająca do jazdy na gapę?

Domyślam się, że nie, a tak być nie powinno.