F59 im alten Jahr unterwegs ...

[invisible]

Ich liebe Qando...

Dass von einer Aktualisierung zur nächsten die Angaben zwischen Plan- und Echtzeit hin und her wechseln kannte ich ja schon, aber gestern Abend war's ganz absurd: da fuhren von der Station Schweglerstraße ein paar 49er in Echtzeit nach Hütteldorf, dann eine Zeile mit 49ern in Planzeit _ebenfalls_ nach Hütteldorf. Leider wars bei der nächsten Aktualisierung wieder weg und ich hab mir nicht näher angeschaut, ob die Plan- und Echtzeiten wenigstens zusammenpassten (würde mich nicht wundern wenn das nicht so wäre).

Zum Rennerring fuhr übrigens (oder soll ich sagen: logischerweise?) nichts.


Könnt man das ganze Graffl bitte nicht endlich in den Müll treten und z.B. zusammen mit der TU-Wien als Projekt ein neues System hochziehen? Ohne jetzt überheblich wirken zu wollen: Bei uns Softwareentwicklern ließen sich sicher einige Leute finden die sowas in annehmbarer Zeit (jedenfalls deutlich unter 10 Jahre) _funktionierend_ hinkriegen (und damit meine ich jetzt nicht nur Qando sondern das ganze RBL).

Und weil sich der Softwarehersteller gerne auf Bedienungsfehler herausredet (die es _natürlich_ auch gibt, davon muss man als Entwickler ausgehen!): Ich kann mir ehrlichgesagt auch nicht vorstellen - und ja, ich habe es jetzt minutenlang versucht -, wie das Softwaredesign dahinter aussieht, dass der oben geschilderte Fehler überhaupt zustandekommen kann. Ich befürchte inzwischen wirklich, dass es da gar keines gibt. 

[13er]

Ach, das willst du alles gar nicht so genau wissen, sonst vergisst du gleich alles, was du über Software Engineering und Datenmodellierung jemals gelernt hast Ich sehe es nur mehr lustig, geärgert hab ich mich genug drüber.

Und, ja, ich bin mir zu 100% sicher, dass man an der TU so ein System in 2-3 Jahren ausgezeichnet hochziehen könnte. Ich würde mit Freude an einem solchen Projekt mitarbeiten. Wobei man von der Komplexität her sagen muss, die Kernanwendung ist nicht viel mehr als eine Diplomarbeit. Mehr Arbeit ist es dann, die Haltestellen und Linien korrekt abzubilden, mit den Ausnahmefällen, die derzeit irgendwie hineingepfuscht sind.

Und was dann wirklich spannend wird, ist das, was das System jetzt noch nicht kann bzw. man explizit nicht verwenden will: Dass der Computer aufgrund seiner gelernten Erfahrungen Verkehrsmaßnahmen selbständig vorschlägt. Z.B. Falschparker in der Kreuzgasse, Computer schlägt vor, dass der 42er über die Währinger Straße fahren soll. Disponent klickt auf OK, Computer veranlasst Überschilderungen, Weichenstellen, Ansagen, einen Eintrag in die Qando-Störungen usw. Selbstverständlich würde jederzeit erhalten bleiben, dass der Disponent auch manuell eingreifen kann.

Das Potential wäre riesig.

[68er]

Das geht bei unserer selbsternannten "Eliteuni"-Informatikfakultät gar nicht als Diplomarbeit durch, Begründung: simple CRUD-Anwendung.

Praxisorientierung ist nur noch bei Bauingenieuren, Maschinenbauern, techn. Naturwissenschaften, Architektur und Raumplanung erlaubt, wir Informatiker spielen lieber "dafür sind FHs da".

Theoretische Logik oder Ausflüge in die Elektrotechnik sind dafür umso lieber gesehen.

[13er]

Noch Fragen?

@Tatra83: Wann das wohl behoben wird?

[hema]

Ich würde mit Freude an einem solchen Projekt mitarbeiten.

Es müssten sich halt echte Praktiker mit guten Informatikern zusammentun. Nicht Möchtegerns mit Möchtegerns. Was da herauskommt, sieht man in der täglichen Praxis. Aber sie werden es nie zugeben sich lieber in weiterem Schönreden ergehen. 


Ich traue mich wetten, dass da sogar zwei engagierte Personen reichen würden, um in relativ kurzer Zeit ein alltagsbrauchbares System im Kern zu erstellen!

[invisible]

Das geht bei unserer selbsternannten "Eliteuni"-Informatikfakultät gar nicht als Diplomarbeit durch, Begründung: simple CRUD-Anwendung.

Nana, da kann man schon noch ein bisserl was "sophisticateteres" reinbauen. Eben z.B. wie 13er vorgeschlagen hat das automatische Lernen/Vorschlagen von Maßnahmen im Störungsfall, insbesondere auch unter Berücksichtigung von Dienstplans und Pausenzeiten (da wäre ev. auch interessant, dass sich das System z.B. notfalls Stellen für fliegende Fahrerwechsel o.ä. [in Wien] 'exotische' Maßnahmen ausrechnen könnte), laufende Optimierung von Fahrplantreue/Intervall/Anschlusssicherung/Niederflur-Verteilung/..., usw. usw.

Weitere Punkte die noch rein spielen wären: Ausfallsicherheit (da kommen dann in die ganzen Porbleme von verteilten [hier sogar Echtzeit-]Systemen, wie Konsensfindung u.dgl. vor), Berücksichtigung/Optimierung beschränkter Ressourcen (z.B: optimales Ausnutzen der begrenzten Anzahl von Funkkanälen bzw. der begrenzten Bandbreite im Datenfunk - wobei man hier auch beaknnte oder gelernte Funklöcher ins Scheduling der Nachrichten einbeziehen könnte; oder wenn man ganz krasse Sachen machen will vielleicht auch Dinge wie Lastverteilung im Fahrleitungsnetz falls mal irgendwo ein Unterwerk den Geist aufgibt; ...), etc.

Optimalerweise natürlich mit einer modular designten Grundanwendung, der man die zusätzlichen Funktionalitäten im laufenden Betrieb per 'Plugin' nachrüsten kann (dann haben mehrere Generationen von Studenten was davon *g*).

[benkda01]

Und was dann wirklich spannend wird, ist das, was das System jetzt noch nicht kann bzw. man explizit nicht verwenden will: Dass der Computer aufgrund seiner gelernten Erfahrungen Verkehrsmaßnahmen selbständig vorschlägt. Z.B. Falschparker in der Kreuzgasse, Computer schlägt vor, dass der 42er über die Währinger Straße fahren soll. Disponent klickt auf OK, Computer veranlasst Überschilderungen, Weichenstellen, Ansagen, einen Eintrag in die Qando-Störungen usw. Selbstverständlich würde jederzeit erhalten bleiben, dass der Disponent auch manuell eingreifen kann.

Das Potential wäre riesig.

Das kann man gar nicht genug betonen!

[Klingelfee]

Und was dann wirklich spannend wird, ist das, was das System jetzt noch nicht kann bzw. man explizit nicht verwenden will: Dass der Computer aufgrund seiner gelernten Erfahrungen Verkehrsmaßnahmen selbständig vorschlägt. Z.B. Falschparker in der Kreuzgasse, Computer schlägt vor, dass der 42er über die Währinger Straße fahren soll. Disponent klickt auf OK, Computer veranlasst Überschilderungen, Weichenstellen, Ansagen, einen Eintrag in die Qando-Störungen usw. Selbstverständlich würde jederzeit erhalten bleiben, dass der Disponent auch manuell eingreifen kann.

Das Potential wäre riesig.

Das kann man gar nicht genug betonen!

Zur Info, das KANN das System nicht automatisch. Das muss der Disponent, wenn mit 2 Klick selbst machen. Denn bei manchen Fahrtbehinderungen muss man aus personaltechnischen Gegebenheiten (Pausengewährung) einen Bus/Zug draufstellen lassen, oder den Zug/bus anders abzulenken. Ich finde das manuelle System, so wie es derzeit zu bedienen ist genau richtig.

[68er]

Ich finde das manuelle System, so wie es derzeit zu bedienen ist genau richtig.

Ich bin ja auch gegen Automatisierung um der Automatisierung Willen und bezweifele stark den Wert heutiger Expertensysteme, aber der Status Quo kann wohl nicht genau richtig sein. Da gibt es nämlich eine Meßgröße, den störungsarmen Betrieb, von dem keine Rede sein kann.

[invisible]

Zur Info, das KANN das System nicht automatisch. Das muss der Disponent, wenn mit 2 Klick selbst machen. Denn bei manchen Fahrtbehinderungen muss man aus personaltechnischen Gegebenheiten (Pausengewährung) einen Bus/Zug draufstellen lassen, oder den Zug/bus anders abzulenken. Ich finde das manuelle System, so wie es derzeit zu bedienen ist genau richtig.

Wenn das System den Dienstplan kennt, dann KANN es das sehr wohl. Ab einer gewissen Anzahl von Variablen (Mitarbeiter, Dienstzeiten derselben, gerade vorhandene Störungen/Umleitungen/Kurzführungen, ...) auch 'besser' als ein menschlicher Disponent. Insofern wären entsprechende *Vorschläge* (natürlich auch entsprechend dargestellt und begründet, damit der Vorschlag nachvollziehbar ist), die der Disponent nur mehr absegnen muss schon eine feine Sache.
Und da spreche ich aus Erfahrung; meine Firma verdient ihr Geld u.a. mittels eines teilautonomen Systems (das inzwischen sogar völlig _ohne_ manuelle Absegnungen in einem von unseren Mitarbeitern vorgegebenen Rahmen funktioniert).

Auch das mit dem gleichzeitig Umleiten + Umschildern + Durchsagen machen + Displays aktualisieren kann das derzeitige System vielleicht theoretisch - in der Praxis merkt man davon aber herzlich wenig. Wenn überhaupt dann passieren diese Dinge oft derart zeitverzögert, dass ich mir keinen anderen Weg vorstellen kann, als das das tatsächlich alles händisch in verschiedene Systeme übernommen werden muss.


Aber es scheitert ja offenbar schon lange vorher, z.B. an der Funkdisziplin. Wenn ich weiß dass mein System (wie hier zu lesen war) nur 5 Kanäle hat und wenn ich weiß dass es in Wien nach jedem cm Neuschnee immer ein Verkehrschaos gibt, dann muss ich das den Fahrern halt nochmal einbleuen (und mittelfristig mein System so umbauen/erweitern, dass es mit der Anforderung klar kommt). Z.B. dass Störungen über Datenfunk angemeldet und dann darauf gewartet werden muss dass der Disponent sich meldet wenn ein Kanal frei ist. Dass bei einem Betrieb der Größe der WiLi nur 5 Kanäle zur Verfügung stehen ist natürlich das nächste Problem.

[13er]

Zur Info, das KANN das System nicht automatisch. Das muss der Disponent, wenn mit 2 Klick selbst machen. Denn bei manchen Fahrtbehinderungen muss man aus personaltechnischen Gegebenheiten (Pausengewährung) einen Bus/Zug draufstellen lassen, oder den Zug/bus anders abzulenken.

Es gibt aber bereits eine HASTUS-Schnittstelle zum RBL. Das wäre das geringste Problem. Ein Computer kann die Pausenzeiten sogar wesentlich besser und schneller berücksichtigen als ein Expeditor. Freilich muss, wie gesagt, immer ein manuelles Eingreifen garantiert sein. Also wenn der Expeditor will, kann er auch alles selbst machen. Aber ich sehe keinen Sinn darin, tagtäglich mehrere Falschparker in der Währinger Straße inklusive aller Einzelschritte zu expedieren. Das ist doch langweilige, sich dauernd wiederholende Arbeit, die wie geschaffen für einen Computer ist. Der Expeditor hätte den Kopf frei für härtere Fälle.

Ad nicht können: Die Wiener Linien wollten bei der Anschaffung des RBL-Systems explizit, dass das System nur zur Beobachtung des Verkehrs dient und nicht vorschlagen/eingreifen darf. Du kannst ja mal mit DI Hochreiter darüber reden, der hat mir das vor ein paar Jahren genau erklärt.

@68er: Von experimentell kann da überhaupt nicht die Rede sein. Das ist nicht einmal Forschung der letzten Jahre, sondern ein längst gelöstes Problem.

[Linie 41]

Ad nicht können: Die Wiener Linien wollten bei der Anschaffung des RBL-Systems explizit, dass das System nur zur Beobachtung des Verkehrs dient und nicht vorschlagen/eingreifen darf.

Na eh klar... das ist der übliche Gewerschaftskäse.

[Tatra83]

Aber es scheitert ja offenbar schon lange vorher, z.B. an der Funkdisziplin. Wenn ich weiß dass mein System (wie hier zu lesen war) nur 5 Kanäle hat und wenn ich weiß dass es in Wien nach jedem cm Neuschnee immer ein Verkehrschaos gibt, dann muss ich das den Fahrern halt nochmal einbleuen (und mittelfristig mein System so umbauen/erweitern, dass es mit der Anforderung klar kommt). Z.B. dass Störungen über Datenfunk angemeldet und dann darauf gewartet werden muss dass der Disponent sich meldet wenn ein Kanal frei ist. Dass bei einem Betrieb der Größe der WiLi nur 5 Kanäle zur Verfügung stehen ist natürlich das nächste Problem.

Alles eine Frage des Geldes und der Priorität. Mehr Funkkanäle bzw. grundsätzlich ein leistungsfähigeres Funksystem kosten Geld - ohne Frage. Was mit dem IBIS-Bordrechner geht, sind codierte und (auch) quittungspflichtige Meldungen (Z.B. Vorsicht Glatteis!!!  ) von der Leitstelle an den Fahrer. In anderen (nicht-weltbesten) Verkehrsbetrieben meldet bspw. der Fahrer die Beförderung von Rollstühlen und Kinderwagen via IBIS ans RBL. Weiterhin werden 100%-besetzt-Meldungen am IBIS getätigt - Schließlich kann nicht jedes Fahrzeug mit einer Zählanlage ausgerüstet sein.

[hema]

Weiterhin werden 100%-besetzt-Meldungen am IBIS getätigt - Schließlich kann nicht jedes Fahrzeug mit einer Zählanlage ausgerüstet sein.

A1 und B1 kennen eh ihren Besetzungsgrad und auch das IBIS "weiß bescheid" und kann ihn anzeigen. Bei allen anderen Fahrzeugen kann/könnte man ihn händisch eingeben. Aber das war es dann auch schon, bis zum RBL gelangt der Wert nie (oder wird bestenfalls ignoriert)!

[13er]

Diese Information könnte ein (anderes) RBL dazu verwenden, Züge zu kürzen. Wenn im Störungsfall der eine 43er zu 80% gefüllt ist und der andere nur zu 20% - und die Pausenzeiten der Fahrer lassen dies zu -, würde dann das RBL vorschlagen, den schwach besetzten Zug gleich zu kürzen, um möglichst wenige Beförd^WKunden zu verärgern.

Aufgaben, wie geschaffen für einen PC... ein Mensch kann das in den oft nur wenigen Sekunden, die pro Zug zur Verfügung stehen, gar nicht so umfassend beurteilen. Außer er hat 30 Jahre Dispo-Erfahrung.