MVB-Daten für ICE-Display gesucht

[Carsten Hölscher]

Ich habe ein Display aus einem ICE3/T ergattern können und da würde ich es mich reizen, es so als Original an Zusi anzuschließen.
Nun läuft das über MVB, wofür es grundsätzlich auch eine Schnittstelle zum Windowes-PC gibt. Allerdings hat man wohl keine Chance, selbst rauszubekommen, welche bits und bytes da hin und herfließen müssen, damit so ein Display funktioniert.
Liest hier zufällig ein Experte mit, der da helfen kann? Oder gibt es vielleicht auch einen Weg ohne MVB?

Carsten

[jonathanp]

Die Kommunikation zwischen EVC und DMI ist nicht standardisiert, so dass das Kommunikationsprotokoll vom EVC-Hersteller abhängt.
In diesem Fall würde ich annehmen, dass es der französische Hersteller Alstom ist. Wenn so, kann ich nicht weiterhelfen.

[Carsten Hölscher]

Es geht nicht um ETCS, sondern die ganz normalen maschinentechnischen Displays (und ein Hardware-MFA)

Carsten

[jonathanp]

Ich vermute, dass es bei diesem 25 Jahre alten Design selbst für den Originalhersteller schwierig wäre, die Kommunikation von Grund auf neu zu entwicklen.

Für ein Projeckt, bei dem es darum ging, die Elektronik eines Fahrzeugs eines ähnlichen Jahrgangs zu modifizieren, konnten die erforderlichen Informationen nur beschafft werden, indem man sich an pensionierte Wartungsmitarbeiterinnen wandte und sie fragte, ob sie private Kopien der benötigten Unterlagen aufbewahrt hätten...

[Joachim Günther]

Ich habe ein Display aus einem ICE3/T ergattern können und da würde ich es mich reizen, es so als Original an Zusi anzuschließen.
Nun läuft das über MVB, wofür es grundsätzlich auch eine Schnittstelle zum Windowes-PC gibt. Allerdings hat man wohl keine Chance, selbst rauszubekommen, welche bits und bytes da hin und herfließen müssen, damit so ein Display funktioniert.
Liest hier zufällig ein Experte mit, der da helfen kann? Oder gibt es vielleicht auch einen Weg ohne MVB?

Carsten

Die Ansteuerung der Displays, bzw. des MFA's mittels MVB-Telegramme vom PC aus halte ich nur dann für realistisch, wenn
- umfassende Kenntnisse des Multifunction Vehicle Bus für Eisenbahn-Fahrzeuge gemäß IEC 61375 - 3 bekannt sind und außerdem
- die Prozeßdaten (Telegrammstrukturen, Telegramminhalte, Signalnamen, NSDB, etc.) vorliegen.

Aussichtsreicher ist m.E. die Module zu entkernen und die verbleibende Hardware über die Zusi TCP/IP-Schnittstelle, Microcontroller und Zusatzhardware anzusteuern.
Ich betreibe mit dieser Lösung seit dem Jahr 2017 ein MFA20tfl (aus einer BR 101) an Zusi3.

Die ICE3 und die ICET waren meines Wissens auch mit einem MFA20 (Kennung aa, ba) der Fa. Deuta ausgerüstet. Die MVB-Karte ist wohl eine PC104 der Fa. Siemens.
---------------------
Joachim Günther

[Wolfgang E.]

Aussichtsreicher ist m.E. die Module zu entkernen und die verbleibende Hardware über die Zusi TCP/IP-Schnittstelle, Microcontroller und Zusatzhardware anzusteuern.
Ich betreibe mit dieser Lösung seit dem Jahr 2017 ein MFA20tfl (aus einer BR 101) an Zusi3.

Hat die 101 nicht eine MFA8 mit dem seriellen LZB-Bus? Oder stammt das Gerät aus dem ETCS-Versuch? Dort hat man doch am Anfang auch mit analogen MFA gearbeitet, oder?

Viele Grüße Wolfgang

[Joachim Günther]

Hallo Wolfgang.
Ja, Deine Vermutung stimmt. Es ist eines der Geräte, die auf der VDE 8.3 ((Doppelausrüstung LZB/ETCS) bei einigen Loks der BR 101 des DB-Fernverkehrs im Einsatz waren und für die zusätzliche Anzeige der ETCS-Daten auf die MVB-Schnittstelle umgerüstet wurden.
——————
Joachim

[nonesense]

Die Ansteuerung der Displays, bzw. des MFA's mittels MVB-Telegramme vom PC aus halte ich nur dann für realistisch, wenn
- umfassende Kenntnisse des Multifunction Vehicle Bus für Eisenbahn-Fahrzeuge gemäß IEC 61375 - 3 bekannt sind und außerdem

Volle Zustimmung!
Abgesehen davon ist sündhaft teure Hardware nötig.

- die Prozeßdaten (Telegrammstrukturen, Telegramminhalte, Signalnamen, NSDB, etc.) vorliegen.

Die MVB-Tabelle sollte sich noch beschaffen lassen - Hilfreich wäre die aber wegen des Punkts oben aber nicht.

Aussichtsreicher ist m.E. die Module zu entkernen und die verbleibende Hardware über die Zusi TCP/IP-Schnittstelle, Microcontroller und Zusatzhardware anzusteuern.

Auch das bei MFA20 nicht ganz trivial, wegen der Mikrocontroller gesteuerten Schrittmotoranzeiger. Natürlich kann man die Schrittmotoren auch vom eigenen Mikrocontroller betreiben, wobei auf ein Teil der originalen Elektronik nicht verzichtet werden kann, weil Nullstellung nicht durch einen mechanischen Anschlag, sondern über eine Lichtschranke erkannt wird.
Bei MFA4, MFA7 ist das deutlich einfacher, wobei diese, wie auch das MFA8, tatsächlich mit überschaubarem Aufwand im Originalzustand betrieben werden können.

Die ICE3 und die ICET waren meines Wissens auch mit einem MFA20 (Kennung aa, ba) der Fa. Deuta ausgerüstet. Die MVB-Karte ist wohl eine PC104 der Fa. Siemens.

Es ist ein ba. PC104 von Siemens ist ebenfalls korrekt.

Gruß
Jens

[Thomas B]

Abgesehen davon ist sündhaft teure Hardware nötig.

Oh ja. Ein Bus-Konverter MVB <-> Ethernet mit Bus-Admin Funktion z.B., da ist man schnell mit einem vierstelligen Betrag dabei. Und das ist natürlich dann noch keine Plug&Play Lösung.

[F. Schn.]

Die Ansteuerung der Displays, bzw. des MFA's mittels MVB-Telegramme vom PC aus halte ich nur dann für realistisch, wenn
- umfassende Kenntnisse des Multifunction Vehicle Bus für Eisenbahn-Fahrzeuge gemäß IEC 61375 - 3 bekannt sind und außerdem

Volle Zustimmung!

Also ich muss sagen, ich habe bei so etwas immer ein ausgeprägtes Unverständnis. Wenn einem nicht daran gelegen ist, die historische Hardware wieder zum Laufen zu bekommen (was Carsten ja scheinbar vor hat), sollte man es in meinen Augen eigentlich gleich lassen, und das von Grund auf neu bauen. Ist dann auch einfacher als seine eigenen Sachen an die wenigen Original-Reste zu adaptieren.

[Wolfgang E.]

Also ich muss sagen, ich habe bei so etwas immer ein ausgeprägtes Unverständnis. Wenn einem nicht daran gelegen ist, die historische Hardware wieder zum Laufen zu bekommen (was Carsten ja scheinbar vor hat), sollte man es in meinen Augen eigentlich gleich lassen, und das von Grund auf neu bauen. Ist dann auch einfacher als seine eigenen Sachen an die wenigen Original-Reste zu adaptieren.

Ich teile grundsätzlich den Wunsch möglichst viel Originales zu behalten und die Schnittstellen nachzuahmen. Mit dem MFA 3,4 und 7 und wahrscheinlich auch 8 ist das auch noch mit sehr überschaubaren Aufwand möglich. Die Erstumsetzung hat aber auch nur durch die freundliche Unterstützung mehrerer wohlmeinender Leute halbwegs reibungslos geklappt. Zirka 2 Mannmonate stecken auch drin, was aber leicht verkraftbar war, da es sich um eine studentische Arbeit handelt.

Schwierig wird es aber ohne Unterlagen. Ich würde gerne, wie an anderer Stelle geschrieben, mein MFA23-Bedienterminal zum Leben erwecken. Funkwerk hat nicht mal eine Absage geschickt,sondern gar nicht geantwortet, obwohl in meiner Funktion an der TH Köln hingeschrieben hatte. Auf meine Frage hier im Forum kam auch nur die Antwort von Carsten, dass er es auch erfolglos versucht hatte. Was jetzt? Ich sehe drei Möglichkeiten:
1. Verzicht auf die Funktion der ZF.
2. Ersatz des Geräts durch einen Touchscreen, der auch die Hardwaretasten nachahmt.
3. Behalten der Frontplatte und Einlesen der Tasten plus neues Display.

Wahrscheinlich wird es irgendwann 3 werden, es sei denn ich bekomme doch noch irgendwoher eine Protokollbeschreibung.

Das gleiche gilt für EBuLa. Kennt jemand die Kommunikation, mit der das Fahrzeuggerät über die serielle Schnittstelle und ZF die Fahrplandaten runterlädt? Vermutlich leider nicht. Auch hier wieder die Möglichkeiten:
1. Um ein anderes Programm auf dem Original-Gerät laufen zu lassen, muss man schon sehr alte Entwicklungstools haben und bereit sein damit zu arbeiten. Nichts mit Qt oder ähnlichem.
2. Man kauft sich ein aktuelles Gerät. Vermutlich kein EBuLa, sondern ein MFD, weil die leistungsfähiger sind. Ich habe mich noch nicht getraut, bei einem Hersteller nach dem Preis zu fragen.
3. Ersatz des Geräts durch einen Touchscreen, der auch die Hardwaretasten nachahmt.
4. Behalten der Frontplatte und Einlesen der Tasten plus neues Display.

Auch da wird es wohl die letzte Möglichkeit werden, wobei ich mein EBuLa nicht schlachten brauche, weil ich noch eine Frontplatte geschenkt bekommen habe. Ich verbaue mir also 1 nicht.

Aber wenn jemand noch Informationen zu den beiden Themen für mich hat, nehme ich sie dankbar entgegen.

Viele Grüße Wolfgang

[Carsten Hölscher]

Etwas Erfahrung hab ich mit CAN-Bus, da ich schon viele Projekte hatte, bei denen ich CAN-Bus Bauteile zum laufen gebracht habe. Das war im Prinzip recht einfach, wenn man von den Herstellern die passenden Adressen usw. bekommen hatte, an die man Kommandos schicken muss. Ist MVB hier deutlich komplexer?
Der Preis für die Schnittstelle relativiert sich, wenn man dafür dann keine neuen Rechner-Innereien kaufen muss und sich den aufwendigen Umbau spart.

Carsten

[Joachim Günther]

Der Preis für die Schnittstelle relativiert sich, wenn man dafür dann keine neuen Rechner-Innereien kaufen muss und sich den aufwendigen Umbau spart.

Da für die LZB/PZB-Anzeige (analog und digital) zum großen Teil die Original-Hardware verwendet werden kann, sind die Kosten für die zusätzlich benötigte Hardware überschaubar.
(Zusatzhardware bei meiner Lösung: Arduino MEGA 2560 mit Ethernet Shield, Stromversorgung 5V/24V, einige Schieberegister für die Seriell/Parallel-Umsetzung sowie elektronische Kleinteile wie Steckbrücken, Verdrahtungsplatine, etc.)

Der Arbeitsaufwand einschließlich der Programmierung des Arduino beläuft sich, wie ihn auch schon oben @machina-vectoria benannt hat, auf einige Mannmonate. Er ist natürlich auch davon abhängig, ob und welche Schaltungsunterlagen des Herstellers zur Verfügung stehen.

Die Ansteuerung der Schrittmotore im MFA20 erfolgt bei meiner Lösung durch 1000Hz PWM-Signale der analogen Ausgänge des Arduinos, dessen Tastverhältnis ich durch direkte Registerprogrammierung des Controllers verändere.
-------------------------
Joachim Günther

[Max Senft]

Nach einem kurzen Blick in die Norm IEC 61375-3-1:2012 handelt es sich bei den elektrisch verbundenen Geräten im MVB wohl um RS485, bzw. eine daran angelehnte Übertragung.

Eine handvoll Standard-Funktionen liefert die Norm ebenfalls (bspw. Abfragen der MVB-Device-Daten). Allerdings ist alles was applikationsspezifisch (sprich Fahrzeug-/Hersteller-spezifisch) ist, nicht enthalten. Da wird dann wohl nur die interne Doku des Fahrzeug-Herstellers wirklich weiter helfen können .

Gruß
Max

[nonesense]

Das war im Prinzip recht einfach, wenn man von den Herstellern die passenden Adressen usw. bekommen hatte, an die man Kommandos schicken muss. Ist MVB hier deutlich komplexer?

Man braucht im wesentlichen folgende Informationen, um den MVB zu betreiben:

• Geräteadresse
• Portnummern
• Zykluszeit der Ports
• Portgrößen
• Portinhalte

Vermutlich gibt es nur einen Port, nämlich der mit dem LZB-Telegramm 1.
Was den Aufbau dieses Ports betrifft kann man stark Vermuten, dass der der Gleiche ist, wie bei aktuellen Projekten mit DMIs.
Darin sind die um einen Faktor von 64 (meine ich) skalierten Führungsgrößen, wobei die Zielentfernung auch noch durch ein zusätzliches Flag in der Auflösung verändert werden kann.
Die Leuchtmelder werden über 4Bit Enumerationen betrieben, wo an, aus, blinken, langsames blinken und je invertiertem blinken unterschieden wird.
Dann gibt es über das Telegramm auch noch einen CRC, dessen Bildung bekannt sein müsste, da das MFA sonst wahrscheinlich die Daten nicht akzeptiert.

Bei MVB war es früher so, dass man vom Hersteller des Fahrzeugs eine Binary bekommen hat, die die Komponentenhersteller in Ihre MVB-Chips eingespielt haben, der sog. NSDB. Dazu gab es noch ein Textfile mit Informationen über die Daten, mit dessen Hilfe man seine eigene Hardware an dem MVB-Chip betreiben konnte.
Heute läuft das komfortabler, oder kann komfortabler laufen. Als ich angefangen habe, mich von Berufswegen mit MVB zu beschäftigen, war diese Methode nicht mehr wirklich angewandt.

Gruß
Jens

[Joachim Günther]

Man braucht im wesentlichen folgende Informationen, um den MVB zu betreiben:

• Geräteadresse
• Portnummern
• Zykluszeit der Ports
• Portgrößen
• Portinhalte

Vermutlich gibt es nur einen Port, nämlich der mit dem LZB-Telegramm 1.
Was den Aufbau dieses Ports betrifft kann man stark Vermuten, dass der der Gleiche ist, wie bei aktuellen Projekten mit DMIs.
Darin sind die um einen Faktor von 64 (meine ich) skalierten Führungsgrößen, wobei die Zielentfernung auch noch durch ein zusätzliches Flag in der Auflösung verändert werden kann.
Die Leuchtmelder werden über 4Bit Enumerationen betrieben, wo an, aus, blinken, langsames blinken und je invertiertem blinken unterschieden wird.
Dann gibt es über das Telegramm auch noch einen CRC, dessen Bildung bekannt sein müsste, da das MFA sonst wahrscheinlich die Daten nicht akzeptiert.

Bei MVB war es früher so, dass man vom Hersteller des Fahrzeugs eine Binary bekommen hat, die die Komponentenhersteller in Ihre MVB-Chips eingespielt haben, der sog. NSDB. Dazu gab es noch ein Textfile mit Informationen über die Daten, mit dessen Hilfe man seine eigene Hardware an dem MVB-Chip betreiben konnte.
Heute läuft das komfortabler, oder kann komfortabler laufen. Als ich angefangen habe, mich von Berufswegen mit MVB zu beschäftigen, war diese Methode nicht mehr wirklich angewandt.

Gruß
Jens

LZB-Telegramm 1 für die LZB/PZB-Anzeigedaten im MFA ist korrekt. Telegrammrahmen: 32 Prozeßbytes (davon 4 Byte Zeitstempel, 4 Byte CRC), Zykluszeit: 128ms.

Bei der Datenausgabe an DMI's sind u.U. noch weitere LZB-Telegramme beteiligt, z.B. für die Ausgabe von LZB/PZB-Zusatztexten oder für das Zugdateneingabe-und Quittungsverfahren.
-----------------------
Joachim Günther

[Thomas B]

Ist MVB hier deutlich komplexer?.

Leider schon, ja.
MVB basiert, wie Max richtig schreibt, zwar auf RS485 bzw. UART, das ist aber halt nur die Transportschicht. Ähnlich wie CANopen sich dem CAN Protokoll zur Übertragung bedient. MVB erfordert zwingend einen Master (Bus-Admin) und der ist kaum mit Hobby-Mitteln zu emulieren. Zumindest ist mir bisher keine OpenSource Lösung bekannt.

[Wolfgang E.]

Ja, Deine Vermutung stimmt. Es ist eines der Geräte, die auf der VDE 8.3 ((Doppelausrüstung LZB/ETCS) bei einigen Loks der BR 101 des DB-Fernverkehrs im Einsatz waren und für die zusätzliche Anzeige der ETCS-Daten auf die MVB-Schnittstelle umgerüstet wurden.

Hallo Günther,

wie sahen denn die ETCS-Anzeigen aus? Ich habe mal ein Bild mit einem blauen Ü-ETCS LM gesehen. Führungsgrößen sind auch klar. ETCS-Level und Betriebsart wurden nicht angezeigt, weil es im Versuch nur jeweils eine gab?

Viele Grüße Wolfgang

[Joachim Günther]

Ja, Deine Vermutung stimmt. Es ist eines der Geräte, die auf der VDE 8.3 ((Doppelausrüstung LZB/ETCS) bei einigen Loks der BR 101 des DB-Fernverkehrs im Einsatz waren und für die zusätzliche Anzeige der ETCS-Daten auf die MVB-Schnittstelle umgerüstet wurden.

Wie sahen denn die ETCS-Anzeigen aus? Ich habe mal ein Bild mit einem blauen Ü-ETCS LM gesehen. Führungsgrößen sind auch klar. ETCS-Level und Betriebsart wurden nicht angezeigt, weil es im Versuch nur jeweils eine gab?

Viele Grüße Wolfgang

Siehe dazu https://i.imgur.com/ABvVtLs.png.
Die Fahrten unter ETCS-Führung fanden übrigens unter Sicherheitsverantwortung des ETCS-Systems statt.
----------------
Joachim

[Carsten Hölscher]

MVB basiert, wie Max richtig schreibt, zwar auf RS485 bzw. UART, das ist aber halt nur die Transportschicht. Ähnlich wie CANopen sich dem CAN Protokoll zur Übertragung bedient. MVB erfordert zwingend einen Master (Bus-Admin) und der ist kaum mit Hobby-Mitteln zu emulieren. Zumindest ist mir bisher keine OpenSource Lösung bekannt.

Sowas alleine reicht als Master nicht?
https://www.duagon.com/de/produkte/einzelheiten/d442/

Carsten