Neue Datenstrukturen für TCP und Fahrzeuge/Führerstände

[Carsten Hölscher]

Hier etwas Infos zu Datenstrukturen für TCP und Fahrzeuge/Führerstände - Mikro war nicht so ganz doll unterwegs aber ich hoffe man kann es verstehen:
https://youtu.be/Qs9S2bk80Vo

Ich übergebe mal mangels Zeit an Jens Haupert für eine Doku dazu.

Carsten

[Jens Haupert]

Hallo,

anbei verlinke ich euch eine neue Version der TCP-Datenstruktur: https://cloud.zusi.de/s/BCDNZryCgXcrDd7. Wie im Video zu sehen, ist angedacht diese Datenstruktur dann zukünftig sowohl (1) für Fst-Bauer als Datenquelle, (2) für DLL-Entwickler:innen als gemeinsames Datenmodell für Ein- und Ausgabe und (3) für TCP-Clients nutzbar zu machen.

Ich liste hier noch ein paar Hinweise auf. Den Text würde ich dann nach und nach ergänzen mit Punkten, die mir noch einfallen und welchen, die aus Rückmeldungen stammen. Schaut daher gerne öfter hier vorbei. Wer Rechtschreibfehler findet, darf sie gerne behalten.

1. Die bisherigen Liste "Führerstands-IDs" (TCP-Name), die alle Größen enthält, die im Fst nutzbar waren und noch aus Zusi2-Zeiten stammt, entfällt in der bisherigen Form.
2. Alle Informationen finden sich weiterhin in der Datenstruktur, nur an anderer Stelle.
3. Die Knoten zu den Zubeeinflussungssystemen, zum Notbremssystem, zur Sifa, zu den Türsystemen, zu ZD-LMs, zu Signalen und zu Weichen sind erst mal unverändert geblieben (erhalten nur eine neue Root-Level-ID).
4. Gleichzeitig wurden die bisherigen TCP-Knoten "Status Fahrzeug", "Status Zugverband" und "Status Zug-Fahrdaten" weiterentwicklet. Diese Strukturen hatten den Nachteil, dass sie im Laufe der Jahre immer weiter gewachsen sind und aufgrund ihrer Art einer flachen Liste mit der Zeit sehr unübersichtlich wurden. Neue Daten wurden meist einfach hinten angereiht, so dass viele Größen sehr verstreut waren und man diese lange suchen musste.
5. Aus diesem Grund wurden die drei Knoten systematisch überarbeitet und neu strukturiert. Herausgekommen sind nun die vier Knoten "Grunddaten zum Gesamtzug", "Fahrdaten zum Gesamtzug", "Grunddaten zu einzelnen Fahrzeugen" und "Fahrdaten zu einzelnen Fahrzeugen". Es gibt also zwei Paare; je ein Knotenpaar mit "Grunddaten", die sich innerhalb der Simulation meist selten bis gar nicht ändern und "Fahrdaten", deren Werte sich u.U. in jedem Simulationsschritt verändert. Um letztere Struktur so klein wie möglich zu halten, sind die eher statischen Daten ausgelagert. Diesen Ansatz gab's ja in in der bisherigen Struktur auch bereits ansatzweise. "Gesamtzug" sind Informationen, die für den gesamten gefahrenen Zugverband gelten und Knoten "zu einzelnen Fahrzeugen" enthalten dann Daten, die genau einen einzelnen Wagen betreffen.
6. Darüber hinaus gibt es noch schließlich den neuen Knoten "Physikalische Simulationswerte", der alle Werte (aus der Fst-IDs Tabelle) aufsammelt, die eigentlich nur desshalb verfügbar sind, weil wir die Bahnwelt simulieren.
7. Wer mit der alten Struktur vertraut ist, dem wir sofort auffallen, dass die Daten in den neuen Knoten zum einen in thematische Gruppen strukturiert sind und bedeutend mehr Daten umfassen. Viele dieser Werte sind als eine Art "Vorrüstung" zu sehen, da sind für die Nutzer:innen interessant sein könnten. Sie werden vom Simulator ab dem Start nicht direkt mit Daten gefüllt werden können, da die bisherigen Modelle erstmal nur ihrer jetzigen Daten in die neue Struktur überführen müssen. Für zukünftige Weiterentwicklungen sowohl im Simulator selbst, als auch für DLL-Entwickler:innen sind diese aber bereits berücksichtig. Auch sind sind viele "Baugruppen" bereits in der Struktur dafür vorbereitet, dass sie zukünftig pro Fahrzeug mehrfach vorkommen können, obwohl man das aktuelle im Fst- und Fzg-Editor so noch nicht konfigurieren kann. Aufgrund der tiefgreifenden Strukturierung lassen sich die einzelnen Baugruppen auch leichter um weitere Daten ergänzen, ohne dass gleich wieder Durcheinander entsteht.
8. Die PDF-Datei enthält für Entwickler:innen folgende Infos:
   1. In der bisherigen Liste "Führerstands-IDs" findet sich zu jedem Eintrag eine Information, wie dieser Wert zukünftig zu finden ist (entweder in einem anderen Knoten oder über eine Berechnungsvorschrift (Skript)).
   2. Bei den fünf neuen Knoten finden sich entgegengesetzt dazu Informationen, wo diese Größe früher zu finden war oder (wie bisher) ein * wenn sie neu eingeführt wurden.
   3. Knoten, die mehrfach auftreten können haben in der Tabelle kleine Winkel (⌜ und ⌞), die sie umschließen.
   4. Alle Knoten, die von den hier vorgestellten Maßnahmen nicht betroffen sind, sind in der PDF-Datei ausgeblendet.
9. Geplant ist, dass der Simulator mit der neuen Struktur noch das alte Datenformat lesen kann und die Informationen beim Lesen konvertiert. Der Fahrzeug- und Führerstands-Editor wird dann ebefalls noch die alte Struktur lesen können und beim Speichern in das neue Format überführen.
10. Geplant ist auch, dass man sich die gesamte Knotenstruktur im Simulator und in den Editoren ansehen kann und (in den Editoren) einzelne Werte auch direkt auswählen kann, ohne erst die PDF-Doku wälzen zu müssen.

Bitte listet gerne unten auf, was euch so auf-/einfällt, was u.U. noch berücksichtigt werden sollte oder was ihr anders erwarten würdet. Schreibt auch gerne was euch gefällt (ich weiß, wird in der heutigen Zeit nicht mehr so gerne gesehen).

Viele Grüße
Jens

[Alwin Meschede]

Die Größe "Luftstrom Fbv" hat bislang das Problem, dass sie zuglängenabhängig ist (bei längeren Zügen nimmt sie größere Werte an). Deshalb konnte man nur schlecht einen Führerbremsventil-Sound an diese Größe hängen. Wünschenswert wäre deshalb noch eine von der Zuglänge unabhängige Stromgröße aus dem Führerbremsventil. Also quasi ein "Luftstrom Relaisbehälter".

In der Struktur für physikalische Simulationswerte gibt es eine "Geschwindigkeit in km/h". Vor Jahren wurde ja die Parole ausgegeben, dass der Simulator nur SI-Einheiten ausgeben soll. Also m/s statt km/h

[F. Schn.]

Also vom Grundsatz her klingt das alles nicht falsch. Auch die alten DLLs (die es ja so gut wie noch nicht gibt) und die alten TCP-Clients zu droppen klingt sinnvoll. Ich bin ehrlich gesagt kein Freund davon, dass Clients nicht adaptiv auf alte Protokollversionen reagieren können, aber das geht wohl in dem Fall nicht anders. Adaptives Verhalten für den Server macht Carsten nur Arbeit. Ebenso bin ich kein Freund davon, dass man nur beim Start NEEDED_DATA senden kann, aber auch das ist vermutlich Aufwandsmäßig nicht sinnvoll, das noch zu ändern.

So, mal zu den Fragen:

1. Habt ihr schon ein Konzept zu den DLLs? Das wäre mir aus nahe liegenden Gründen wichtig. Ich kann zeigen, wie man bei DLLs mit Strukturen und Interfaces umgeht, ich habe dort nur noch keine Lesemeldung meiner Beiträge gesehen.
2. Habt ihr schon ein Konzept für die Nervigen (aber vorbildgerechten) Schaltersounds, wenn die Fahrpultinternen Größen entfallen sollen? Es wäre blöd, wenn dazu der Fst-Bauer immer eine DLL benötigen würde.
3. Es sind noch einige 00XX-Platzhalter in der PDF, z.B. 0002 000A 00XX Fahrdaten zum Gesamtzug.
4. Detailfragen:
a) 0002 000A 00XX 0013/14: Sind Absolutgeschwindigkeiten sinnvoll? Ist da nicht ein Ticker beim Eingangswert "Absolut" sinnvoller? Wenn doch: Wäre es nicht sinnvoller, die Vorzeichenbehafteten direkt in der nähe der vorzeichenlosen zu behalten?
b) 0002 000A 00XX 0016 bis 0018: Selbes Thema hier: Wozu soll das gut sein? Die echte, für jeden nutzbare Uhrzeit fliegt wo ganz anderes herum. Außerdem ergibt es für mich keinen Sinn, die Stunde nur bis 11 gehen zu lassen, da sich damit weder digitaluhren, noch Uhren mit AM/PM-Anzeige ansteuern lassen. Ich würde eher vorschlagen, Carsten sollte neben Plus und Minus auch die Mathematischen Funktionen "Stunde extrahieren", "Minute Extrahieren" und "Sekunde Extrahieren" anbieten, das wäre dann auch für künftig noch auftauchende Datum-Uhrzeit-Werte nutzbar,
c) Anschließend zu 1: Was ist denn das Ziel der riesigen, Komplexen Trafo- und Motorabteilung? Sollen sich da künftig DLL-Bauer dran halten oder soll da Zusi ein Retrofit bekommen, dass er das unterstützt?
d) Grunddaten: Das Ding sieht sehr leer aus. Hatten wir nie Zugnummer, Zuggattung und Zuglauf im Paket?

Weitere Fragen kommen sicherlich noch. Ich nehme auch noch Wetten an, wie lange es zum ersten Kommentar eines nutzenden zu deinem Beitrag kommt. :-P

[Jens Haupert]

Hallo,

@Alwin:
(1) "Luftstrom": ja der Wert ist aktuell nicht wirklich nutzbar und sollte angepasst werden. Wäre aber sogar unabhängig vom Protokoll.
(2) "SI-Einheiten": siehe Anwort zu F.Schn.

@F.Schn.:
(1) DLL: hier sind wir konzeptuell noch dran. Es würde sich vielleicht auch anbieten, dass man nach Ostern mit den "Betroffenen" und Experten zu dem Thema auch mal sich zusammenkonferiert.
(2) "Fahrpult-/Fahrzeug-Intern": hier müsste Carsten was zu sagen, da wird's aber eine Ersatzlösung für geben.
(3) Platzhalter: ja die neuen Pakete haben noch keine ID. Bisher waren die Struktur-Pakete ja in die Führerstand-IDs-Liste eingeklingt. Da das entfallen würde, bekommen diese alle eine neue ID. Würde ich aber gegen Ende des Prozesses sehen, wenn alle Knoten definiert sind.
(4) Ich vermute du meinst den Knoten "Fahrdaten zum Gesamtzug"? Denn 0002 000A 00XX steht ja bei allen neuen Knoten (daher am besten den Namen verwenden).
a) Bisher sind alle Daten die es als Fst-ID gab "nach hinten" verlagert. Da kann man hier und da noch aufräumen. Die Geschwindigkeit wäre so ein Fall, ebenso deren teils unterschiedliche Einheiten.
b) Wie a) sind die Größen 1-zu-1 verschoben; ich meine darüber werden aktuell analoge Uhren angesteuert? Da diese größen für alle Anwendungen außerhalb des Führerstands wohl nicht interessant sind, könnte man die Werte, wie die schriebst, auch errechnen.
c) Die Struktur ist darauf vorbereitet, dass man den Antrieb modularer gestalten kann. Wenn man sich die Antriebskonfiguration einer Vectron mit den aktuellen Modellen anschaut (um die Anforderungen (1) FM pro Radsatz ausgruppierbar, (2) Mehrsystem, (3) erhöhte E-Bremskraft und (4) Last Mile Diesel zu erfüllen), finden sich da mehr als 20 Antriebs/Bremskomponenten in den Fzg-Dateien. Das ist so kaum noch handhabbar. Da die Schnittstelle ja bisher schon so ausgelegt war, dass nur Knoten und Attribute übermittelt werden, wenn dafür Daten vorliegen, müssen diese Werte natürlich nicht alle gefüllt werden. Beim Nachdenken fällt mir z.B. ein, dass ich das Antriebskonzept "Dampf" bisher nicht berücksichtig habe.
(d) Diese Werte stehen im Paket 00 0C DATA_PROG.

Grüße
Jens

[F. Schn.]

Es würde sich vielleicht auch anbieten, dass man nach Ostern mit den "Betroffenen" und Experten zu dem Thema auch mal sich zusammenkonferiert.

Das würde ich sehr begrüßen. Ich bin mir jedoch btw. auch nicht mehr sicher, ob das online besprechbar ist.

(3) es macht halt das "worüber reden wir gerade" schwieriger.
(4c) Das klingt gut. Die Frage ist aber trotzdem: Ist das für Carsten gedacht? Wenn ja muss ich eigentlich Fragen stellen, was dies alles nach sich zieht, auf viele dieser Werte sind die bisherigen Eingaben im Fzg-Editor nicht ausgelegt. Das wird nicht nur in der Umsetzung, sondern auch in der Datenpflege Fragen aufwerfen. Als grobes Grundgerüst für mich als Antriebs-DLL-Bauer ist das im Grundsatz OK, Dann muss ich mir das aber noch mal genauer durchlesen. Grundsätzlich wollte ich eigentlich die Woche das C#-SDK updaten, so dass ich dann alle Antriebe (mit mehreren kleinen Lücken) auch als DLL in C# darstellen könnte. Man könnte Mittelfristig also auch in Richtung Gesamtauslagerung aus Zusi nachdenken. (Kurzfristig sind dazu aber noch zu viele Lücken.)
(4d) Dann würde ich eine Herauslösung daraus, eine Verlagerung nach Grunddaten und eine Ergänzung um Gattung und Zuglauf anregen.

Edit1:
(5a) Zugverband: Masse des Fahrzeugs ohne Ladung scheint zu fehlen bzw. habe ich noch nicht gefunden.
(5b) Führerstandsmodus: Müsste man mal prüfen, ob das dort in "weitere Angaben" Sinn ergibt, oder besser in 01 03 ("interne Informationen") gehört.
(5c) Fahrdaten Trafo Fahrstufe sehe ich nicht als byte sondern als Int32. Außerdem sollte der Maximalwert in den Grunddaten angegeben werden.
(5d) Die Brennstoffzelle als Exoten ist dann finde ich schon viel. Ist es hier vlt. machbar, Dinge zusammenzufassen? Etwa die Batterie und den Tank einer Dampfspeicherlok, oder die Verbrennungsmotoren und die kalten Verbrennungen. Das würde aber erfordern, dass man vermutlich ein Typen-Byte reservieren müsste, mit dem man dann Details angeben kann. Dem Trafo=4QS würde das sicherlich auch gut tun. Generell würde es sich sicherlich anbieten, auch Strings für Herstellerbezeichner der (Diesel-)Motoren frei zu halten, falls jemand vor hat, diese anzugeben.
(5f) Generell ist der Antriebsstrang schon jetzt so voll, dass es denke ich Sinn machen würde, ihm noch mal einen Zwischenknoten zu geben, und ihn nicht in den selben "namespace" wie Türen und Zugsicherung zu tun.
(5g) Oberstrombegrenzung automatisch: Ist das als Fahrdaten sinnvoll?
(5h) Ist-Tankinhalt und Norm-Batteriespannung als Word? Besser Single.
(5i) Dieselmotor-Getriebe mit Ist- und Sollzugkraft? Ist da nicht Motor- und Scheinenseitige Zugkraft sinniger. Analog Generator: Das müsste auch die Strom- und die Mechanische Seite Leistungsmäßig getrennt werden.
(5j) Akku-Kapazität, bzw. Tank-Kapazität?
(5k) Fahrleitungsspannung in V, aber keine Fahrleitungsfrequenz? Generell wäre auch eine Netzimpedanz (und -reaktanz) ganz nett.
(5l) Zugsammelschiene: Das ist jetzt mit Verbraucherfokus. Der Erzeugerfokus, incl. der Angabe, welche Spannung und Frequenz das Konstrukt schließlich hat, bräuchte man denke ich auch.
(6) Also ich fasse es mal so zusammen: Generell finde ich gerade den Antriebs- aber auch den Bremsstrang leicht chaotisch und schwer zu erweitern. Häufig fehlt eine getrennte Auflistung der Eingangs- und Ausgangswerte einer Komponente, die Abwärme-Leistung und die Kummulative Abwärme-Energie wären in vielen Fällen neben den Detaillierten Eingangs- und Ausgangswerten das, was ich am ehesten vermisse. Ich muss da mal näher drüber nachdenken und einen geordneten Vorschlag unterbreiten.
Edit2:
(5m) Trafo-Nennspannungen müssten mehrere zulässig sein.
Edit3:
(5n) Analog zu Alwins Beitrag: Drehzahlen in 1/n oder U/min...?
Edit4+5:
(5h-Ergänzung) Kühlwassertemperatur als Byte? Dann wird das ja nicht-Negativ. -> Single.
Edit6:
(5o): Ach ja: Zp9.
Edit7+8:
(7) Zum Entfall der Ja-Nein-Werte: Wir brauchen dann aber in jedem Fall Frequenzangaben zur Frequenz des blinkens, gerade wenn es verschiedene Baugruppen gibt, die unterschiedliche Frequenzen haben und die der Client nicht alle namentlich unterscheiden soll; die Vorgabe muss von Zusi kommen. Man sollte auch überlegen, wo das Vorbild syncron blinkt, und wo assyncron.
Edit9:
(8) Bitte die Uhrzeit nicht auf die Sekunde runden und nur jede Sekunde verschicken, sondern in JEDEM TCP-Paket. Es gibt Uhren, bei denen der Zeiger die Sekunden kontinuierlich anzeigt.

[nonesense]

Coole Sache!

Eine Überarbeitung des TCP begrüße ich sehr. Dann möchte ich auch ein Paar Gedanken dazu loswerden.

Die Umsetzung der Änderung würde ja die alten Clients teilweise Inkompatibel machen. Daher mein Vorschlag, diese neue Struktur auf einem separaten TCP Port zu führen. So könnte man auf dem anderen TCP-Port die alte Struktur legacy noch ein oder zwei Zusi-Iterationen mitführen. Der neue Standardport mit neuer Struktur könnte dann 1437 sein.

An manchen Stellen gibt es neuerdings die Einheit km/h, was ich begrüße. Allerdings ist das nicht konsequent überall umgestellt. Die Streckenhöchstgeschwindigkeit wird z.B. weiter in m/s übertragen. Wenn es nicht einen generellen Wechsel vom m/s nach km/h geben soll, würde ich es befürworten genrell bei m/s zu bleiben.

Geschwindigkeiten werden ja von Zusi idr. als Floatingpoint übertragen. Wäre es denkbar hier auf Integer mit Vorfaktor zu gehen? Also z.B. 1365 für 13,65km/h?

Der Block zur Zugsicherung in der PDF nicht enthalten, was mich vermuten lässt, dass es hier keine Änderungen geben wird. Hier hätte ich allerdings auch einen Wunsch:
Nämlich die Unterknoten in den PZB/LZB Betriebsdaten in direkte Attribute aufzulösen, da die meistens eh nur ein Attribut enthalten.
Das Betrifft die Konten von Ende-Verfahren 000E bis LZB EL-Auftrag 00016.
Dies hilft dabei, das Ende der Zustände besser zu erkennen, da man dann immer sauber eine 0 bekommt, wenn Auftrag oder Zustand nicht mehr anstehen. Besonders mag ich den Ersastzauftrag, der kein Attribut enthält, wo doch in der Spezifikation steht, dass die Nutzdaten aus den Attributen zu entnehmen und nicht aus der Präsenz oder Absenz eines Knotens abzuleiten sind.

Und doch noch ein Tippfehler in der PDF:
In der Einheit von Zugkraftvorschlag Autopilot in fehlt das ² bei m/s²

Gruß
Jens

[Wolfgang E.]

Die Idee, das Ganze neu zu strukturieren, ist sicherlich positiv für die weitere Entwicklung von Zusi. Die Aufteilung erscheint mir sinnvoll. Das mit den Skripten für den Steuerwagen habe ich noch nicht ganz verstanden, aber das kommt bestimmt noch. Auch die Mächtigkeit der Skripte ist mir noch nicht klar. Reicht es für beispielsweise für ein kombiniertes Fahrdraht-/Motorspannungsinstrument wie in den Steuerwagen oder der 141 oder 151? Kann man damit eine Hilfs- oder Anfahrfahrschaltersteuerung realisieren? Oder mache ich das doch in einer dll? Dann brauche ich aber Variablen, auf die ich schreiben kann.

Schön finde ich auch, dass Spitzenlicht und Zugsammelschiene Eingang in die neue Struktur gefunden haben.

Ich würde mir noch Phasenwinkel bei Ober- und Motorstrom wünschen. In meiner geplanten dll für Antriebe mit Einphasenreihenschlussmotoren wird auf jeden Fall komplex gerechnet werden.

Bei den Fahrstufen muss man unterscheiden:
- Loks ohne Feinregler/Feinschaltwerk: Hier dürfte die 103 mit 39 Fahrstufen führen.
- Loks mit Feinregler: Hier dürfte die E18/19 mit 18 Dauerfahrstufen und 73 Zwischenstufen führend sein. Das wären 1259 Stufen.
- Akkutriebwagen 515/517: Mit alle Zwischenstufen gibt es 84 Fahrstufen.
Fazit: Für die Dauerfahrstufen sollte ein Byte reichen. Wenn man aber Feinreglersteuerungen nachbilden möchte (und ich möchte eines Tages) braucht man mehr Auflösung. Daher schlage ich eine Single-FP-Variable vor, die im Vorkommateil die Dauerfahrstufen und im Nachkommateil die Zwischenfahrstufen ausgibt.

Von dem Vorschlag, Werte die in Zusi als FP vorliegen in eine Integergröße mit Vorfaktor zu wandeln, halte ich nichts, da ich in meiner Clientsoftware mit FP rechne und es alles wieder zurück wandeln würde. Das stört mich schon bei Loksim3D.

Ich würde den Vorschlag, die alte Struktur noch eine Zeit lang parallel zu führen, sehr unterstützen. Andernfalls stünde ich nach dem Update vor dem Nichts und müsste meine gesamte Peripherie ohne jede Rückfallebene auf einmal anpassen. Das ist nicht mal so eben gemacht, da das von mir verwendete pyzusi3 das Protokoll als Objektstruktur abbildet, weshalb sämtliche Software geändert werden muss.

Ich weiß, dass Fragen nach dem wann hier sehr unbeliebt sind. Hierbei geht es aber nicht um eine neue Strecke, die halt früher oder später oder auch nie kommt, sondern um eine Kernfunktion. Ein zeitlicher Ausblick würde mir da echt helfen.

Viele Grüße
Wolfgang

[Carsten Hölscher]

Es könnte schwierig werden, die bisherige Schnittstelle parallel weiter zu betreiben. Aber eine Übergangsphase wird es geben, da die neue SAchnittstelle sicherlich eine längere Beta-Phase durchlaufen wird.

Ansonsten muss man heute nicht der Frage nachgehen, ob man bei irgendeinem Knoten tief irgendwo noch ein Attribut mehr braucht oder etwas in m/s oder km/h über den Äther kommt (kzrz dazu: m/s sind es aktuell wohl überall und bleiben es auch). Im Moment ist eher interessant, ob das grundsätzlich so sinnvoll erscheint und die Struktur so für alle Anwender praktikabel erscheint.

Carsten

[Johannes]

Die Umsetzung der Änderung würde ja die alten Clients teilweise Inkompatibel machen. Daher mein Vorschlag, diese neue Struktur auf einem separaten TCP Port zu führen.

So weit würde ich nicht gehen. Aber ich würde natürlich für die 00 XX neue IDs vergeben, die bisher ungenutzt sind. Und in Zukunft würde ich bitten, auch konsequent bei inkompatiblen Änderungen (z.B. Änderung Datentyp eines Knotens, Entfernen von Attributen) neue IDs zu vergeben. Das ist bisher leider nicht durchgezogen worden und führt bei einem untypisierten und unversionierten Protokoll wie dem Zusi-3-TCP-Protokoll zu unnötigem und vermeidbarem Fehlersuch-Aufwand bei Entwicklern.

Und ich erwähnte es glaub ich schon mal: Neben den Pascal-spezifischen Datentyp-Namen (Cardinal, SmallInt, Word, …) unterstützt Delphi auch gleichberechtigt sprechende Standardnamen wie Int32, UInt64, etc. Diese sollte man in der Doku konsequent verwenden, weil die Pascal-Namen in der großen weiten Welt absolut unüblich sind.

[Wolfgang E.]

Es könnte schwierig werden, die bisherige Schnittstelle parallel weiter zu betreiben. Aber eine Übergangsphase wird es geben, da die neue Schnittstelle sicherlich eine längere Beta-Phase durchlaufen wird.

Ansonsten muss man heute nicht der Frage nachgehen, ob man bei irgendeinem Knoten tief irgendwo noch ein Attribut mehr braucht oder etwas in m/s oder km/h über den Äther kommt (kzrz dazu: m/s sind es aktuell wohl überall und bleiben es auch). Im Moment ist eher interessant, ob das grundsätzlich so sinnvoll erscheint und die Struktur so für alle Anwender praktikabel erscheint.

Was meinst Du mit Beta-Phase? Das Zusi eine Datenstruktur bekommt, die sich dann noch x-mal inkompatibel ändert und man jedes Mal sämtliche Client-Software, Führerstände und Fahrzeuge anpassen muss? Ich denke nicht. Vielleicht ist jetzt noch nicht der richtige Zeitpunkt, aber ich plädiere dafür, die Datenstruktur fertig zu diskutieren und dann zu implementieren. Vielleicht wird sich dann doch noch Änderungsbedarf ergeben, aber man sollte wenigsten mit einem fertigen und durchdachten Plan in die Implementierung starten. Sonst wird das nur viel unnötiger Mehraufwand auf Benutzer-Seite.

Ich selber würde auf Clientseite nun damit anfangen, mit dem aktuellen Protokoll auf die Steuerwagensignale zu verzichten und mir die Daten aus der Fahrzeugstruktur rauszufischen, denn das werde ich mit dem neuen Protokoll ja sowieso benötigen.

So weit würde ich nicht gehen. Aber ich würde natürlich für die 00 XX neue IDs vergeben, die bisher ungenutzt sind. Und in Zukunft würde ich bitten, auch konsequent bei inkompatiblen Änderungen (z.B. Änderung Datentyp eines Knotens, Entfernen von Attributen) neue IDs zu vergeben. Das ist bisher leider nicht durchgezogen worden und führt bei einem untypisierten und unversionierten Protokoll wie dem Zusi-3-TCP-Protokoll zu unnötigem und vermeidbarem Fehlersuch-Aufwand bei Entwicklern.

Und ich erwähnte es glaub ich schon mal: Neben den Pascal-spezifischen Datentyp-Namen (Cardinal, SmallInt, Word, …) unterstützt Delphi auch gleichberechtigt sprechende Standardnamen wie Int32, UInt64, etc. Diese sollte man in der Doku konsequent verwenden, weil die Pascal-Namen in der großen weiten Welt absolut unüblich sind.

Die Idee den neuen Telegrammen neue IDs zu vergeben und sie zunächst in das alte Protokoll einzufügen, finde ich gut. Inkompatible Änderungen sollten vermieden werden. Jedes Mal eine neue ID zu vergeben, finde ich auf Carstens Seite schwierig, denn dass bedeutet ja, dass die Telegramme mit den alten IDs immer weiter mitgeführt werden müssen. Das wird irgendwann kaum mehr überschaubar.

Die Datentypen mit den allgemein üblichen Begriffen zu belegen, macht es für die meisten Programmierer sicherlich einfacher, da die wenigsten in Pascal programmieren werden.

Viele Grüße
Wolfgang

[nonesense]

Neben den Pascal-spezifischen Datentyp-Namen (Cardinal, SmallInt, Word, …) unterstützt Delphi auch gleichberechtigt sprechende Standardnamen wie Int32, UInt64, etc. Diese sollte man in der Doku konsequent verwenden, weil die Pascal-Namen in der großen weiten Welt absolut unüblich sind.

Finde ich gut.

Ansonsten muss man heute nicht der Frage nachgehen, ob man bei irgendeinem Knoten tief irgendwo noch ein Attribut mehr braucht oder etwas in m/s oder km/h über den Äther kommt (kzrz dazu: m/s sind es aktuell wohl überall und bleiben es auch). Im Moment ist eher interessant, ob das grundsätzlich so sinnvoll erscheint und die Struktur so für alle Anwender praktikabel erscheint.

Kann verstehen, dass Ihr geren Rückmeldung zu der eigentlich größten Aänderung haben möchtet. Dennoch nehmt Ihr eine Änderung vor, die eine Änderung an der Mehrheit der Clients erfordert. Wenn ich es nicht ausgerechnet jetzt vorschlagen soll, wann dann?

Von dem Vorschlag, Werte die in Zusi als FP vorliegen in eine Integergröße mit Vorfaktor zu wandeln, halte ich nichts, da ich in meiner Clientsoftware mit FP rechne und es alles wieder zurück wandeln würde. Das stört mich schon bei Loksim3D.

Ich vermute hier kommen wir nie überein. Müssen wir auch nicht. Von meinen Wünschen hat auch due geringste Priorität.

Aber eine Übergangsphase wird es geben, da die neue Schnittstelle sicherlich eine längere Beta-Phase durchlaufen wird.

Was es mit der Betaphase aufsich hat wüsste ich gerne. Wenn es so kommt, sind am Ende alle Programmierer von Zusatzsoftware gezwungen vom ersten Tag des Releases der neune Struktur von heute auf morgen eine angepasste software beeitzustellen.

Gruß
Jens

[HaraldB]

Für einfache (i.A. nur lesende) Version-2 Clients ließe sich sicher eine generische Bridge implementieren, von den Führerstand-/Fahrpult-internen Werten mal abgesehen. Doch dass NEEDED-DATA nicht dynamisch ist war mir neu und könnte hier zu negativen Seiten-Effekten (Over-Fetching oder Re-Connect) führen.
Ich hab da noch was auf Halde, was das Protokoll in Websocket/JSON übersetzt, damit Browser-Clients versorgt werden können, da ließe sich sowas einbauen.

Im Kapitel 0.1.3.3.1.3 Skripte sind Gleiten und Schleudern vertauscht.

Türen A-B und links/rechts erscheint mir angesichts der anderen Änderungen etwas statisch.

Auch die FP-Uhrzeit ist ja (für Analog-Uhren) nur sekundengenau. Eine zusätzliche Millisekunden-Info wäre für bestimmte Berechnungen sicher eine zusätzliche Hilfe und müsste nicht mit Hilfe der Normalzeit orakelt werden.

[F. Schn.]

Im Moment ist eher interessant, ob das grundsätzlich so sinnvoll erscheint und die Struktur so für alle Anwender praktikabel erscheint.

Also vom Grundsatz her halte ich das Konzept für sinnvoll. (Unter Vorbehalt, dass das auch DLL-Seitig sinnvoll wird, und das für nicht-Programmierer genügend Standardwerte vordefiniert sind, letzteres hast du im Video aber schon selbst erwähnt.)

Eines habe ich aber noch vergessen: Was ist denn mit Meldern, die man mit Mausklick bedienen will? Liefen die bislang bereits ausschließlich über die Baugruppen oder liefen einzelne davon über die Physikalische Größe?

Für einfache (i.A. nur lesende) Version-2 Clients ließe sich sicher eine generische Bridge implementieren

Ich würde dem zustimmen, falls es wirklich viel Nachfrage nach dem alten Protokoll geben sollte, liegt eine Comunnity-erstellte Bridge einfach logisch näher. Und da das Protokoll vom Rahmen her Kompatibel ist, würde ich auch davon abraten, einen anderen Port zu verwenden, das führt nur zu Verwirrungen "der Server läuft doch". Wer die Bridge einsetzt kann ja den Port manuell ändern (und die Bridge so bauen, dass sie die Protokollversion 3 direkt 1:1 durchleitet.)

Es gäbe noch eine zweite Alternative: Wenn sich der Client mit Version 2 meldet, reagiert Zusi im ACK_HELLO so, dass er in Paket 0001 0002 0003 das Byte auf einen fest definierten Wert (z.B. 04) setzt. Wenn dieser Wert geschickt wird, lehnt Zusi die Verbindung zwar erst mal ab, baut sie aber nicht sofort wieder ab, sondern ermöglicht es dem Client, noch mal ein zweites HELLO-Paket zu schicken. Dann sollte man den Paketen wie Johannes erwähnt hat, IDs geben, die sich nicht mit denen des alten Protokolls überschneiden, und man kann dann die Clients schrittweise umbauen.

[HaraldB]

Drei Punkte, die in diesem Kontext geklärt werden sollten:
1. Wann ist für einen Attribut-Wert ein Default anzunehmen und ist es immer "0"? Wenn der Parent-Knoten fehlt oder aus dem Kontext? (Bei PZB/LZB sind bisher mehrere Knoten mit gleicher ID aber unterschiedlichen Attributen üblich, da zählt also der Kontext)
2. Kann eine Attribut-ID mehrfach im Knoten vorkommen? (ich kenne es nur bei NEEDED_DATA)
3. Sind Attribute und Knoten sortiert? (Das würde für u.a. für (1.) frühe Schlussfolgerungen zulassen)

[Johannes]

[*] Geplant ist auch, dass man sich die gesamte Knotenstruktur im Simulator und in den Editoren ansehen kann und (in den Editoren) einzelne Werte auch direkt auswählen kann, ohne erst die PDF-Doku wälzen zu müssen.

Da die Daten somit wohl in maschinenlesbarer Form vorliegen, würde ich anregen:
- die Struktur nicht nur als PDF, sondern zusätzlich in strukturierter Form (XML, JSON, …) zu dokumentieren.
- idealerweise diese strukturierte Form programmseitig zu generieren
- und die PDF-Doku aus dieser strukturierten Form zu generieren
-> keine Handarbeit nötig, Doku ist immer konsistent und man kann in Zukunft TCP-Clients programmatisch generieren

[Wolfgang E.]

Da die Daten somit wohl in maschinenlesbarer Form vorliegen, würde ich anregen:
- die Struktur nicht nur als PDF, sondern zusätzlich in strukturierter Form (XML, JSON, …) zu dokumentieren.
- idealerweise diese strukturierte Form programmseitig zu generieren
- und die PDF-Doku aus dieser strukturierten Form zu generieren
-> keine Handarbeit nötig, Doku ist immer konsistent und man kann in Zukunft TCP-Clients programmatisch generieren

Das finde ich eine sehr reizvolle Idee, wobei ich XML bevorzugen würde, da alle Konfigurationsdateien von Zusi XML sind.

Viele Grüße
Wolfgang

[hlinke]

Da die Daten somit wohl in maschinenlesbarer Form vorliegen, würde ich anregen:
- die Struktur nicht nur als PDF, sondern zusätzlich in strukturierter Form (XML, JSON, …) zu dokumentieren.
- idealerweise diese strukturierte Form programmseitig zu generieren
- und die PDF-Doku aus dieser strukturierten Form zu generieren
-> keine Handarbeit nötig, Doku ist immer konsistent und man kann in Zukunft TCP-Clients programmatisch generieren

Das finde ich eine sehr reizvolle Idee, wobei ich XML bevorzugen würde, da alle Konfigurationsdateien von Zusi XML sind.

Viele Grüße
Wolfgang

Das hätte auch den Vorteil, daß man damit dann einen automatischen Konverter bauen könnte, der das etwas unhandliche Binärformat on the fly in XML umsetzt.

Das könnte auch die Umstellung vereinfachen.

Viele Grüße
Harold

[HaraldB]

https://github.com/zusitools/tcp_dissector

ist eine praktische Dokumentation.

Daraus lässt sich z.B. ein C#-Modell erzeugen, das aber zugegebenermaßen etwas unhandlich lange Bezeichner verwendet. Natürlich ließen sich auch XML, JSON Schema oder OpenAPI raushauen.

Mir ein bisschen Hingabe ließen sich ähnliche Enums oder Knoten (z.B. LZB Grund- und Ersatzdaten) noch verallgemeinern und dadurch das Modell genießbarer machen. Hier würde es helfen, das Delphi-Modell zu haben.

Einen Konverter nach Websockets/JSON hätte ich, wie gesagt. Das hatte ich mal angefangen um mit Leaflet die Zugposition in einem Browser-Fenster anzuzeigen.

Allerdings sind nicht alle Clients gleich und haben sehr unterschiedliche Anforderungen (mit/ohne Events, Reactive, etc.). Was dem einen zuwenig ist für den anderen Overkill.

[Carsten Hölscher]

(z.B. Änderung Datentyp eines Knotens, Entfernen von Attributen)

Wo ist das schonmal vorgekommen?

Beta-Phase stell ich mir so vor:

1. Feststellen, ob das grundsätzlich so ok ist (aktuelle Diskussion)

2. Umsetzen des in 1 gefunden Stands, wobei sich sicherlich in der Umsetzung noch Anpassungsbedarf ergibt. Endet in einer 1. Beta mit angepasster Doku

3. Dann können die Nutzer ihre Software umbauen und testen

4. Diskussion der Erkenntnisse und Umsetzung von ggf. gefundenem Änderungsbedarf -> ggf. mehrere Schleifen

5. erste offizielle Version mit finalem Datenformat

Was ist denn mit Meldern, die man mit Mausklick bedienen will? Liefen die bislang bereits ausschließlich über die Baugruppen oder liefen einzelne davon über die Physikalische Größe?

Also sowas wie "G" bei LZB? Muss ich nachschauen wie es geht aber sicher nicht über die phys. Größe.

1. Wann ist für einen Attribut-Wert ein Default anzunehmen und ist es immer "0"? Wenn der Parent-Knoten fehlt oder aus dem Kontext? (Bei PZB/LZB sind bisher mehrere Knoten mit gleicher ID aber unterschiedlichen Attributen üblich, da zählt also der Kontext)

Wenn ein Attribut gar nicht kommt, gibt es die Info nicht. Eine 0 würde immer verschickt.

2. Kann eine Attribut-ID mehrfach im Knoten vorkommen? (ich kenne es nur bei NEEDED_DATA)

Nein, das bei neededdata war mir gar nicht bewußt, das hätte man schon damals anders machen sollen.

3. Sind Attribute und Knoten sortiert? (Das würde für u.a. für (1.) frühe Schlussfolgerungen zulassen)

Sind nicht sortiert nach Nummern sondern nach logischem Ablauf.

Doe Doku generiere ich direkt aus Zusi raus in TeX, das ist auch bisher schon so mit einigen Tabellen im Anhang. xml wär auch kein Problem.

Und ein Punkt fiel mir noch ein: Man sollte Nummernbereiche vorgeben für indivduelle Knoten und Attribute, z.B. die ganz hohen Wertebereiche, so dass Zusi weiß, dass es die selbst nicht auswerten soll.

Wär wäre denn dabei, die Schnittstelle zur dll zu besprechen?


Carsten