XML-Migration meines CANopen-Projekts abgeschlossen

Im Mai wurde ich vor die Aufgabe gestellt, in Ada geschriebene Software zu erweitern, welche in ihrer ursprünglichen Form von einem Bündel von Generatoren erzeugt, aber seit Jahren von Hand erweitert worden war.

Klar, dass der Gedanke von mir Besitz ergriff, kein generierbares Stück Code von Hand zu schreiben und vielmehr die quasi verloren gegangenen Generatoren neu zu schreiben.

Am liebsten hätte ich das mit ruby und xml erledigt, aber ich hatte zu diesem Zeitpunkt noch keine in ruby unter Zurhilfenahme von XML geschriebene Software, die nahe genug an dieser Aufgabe dran war, um daraus die Software für dieses Projekt abzuleiten.

Ich stand unter ziemlichem Druck, Ergebnisse abzuliefern, und so erledigte ich die Aufgabe in den darauf folgenden Wochen erst einmal in perl und baute die zentrale Datenstruktur einfach als perl-Datenstruktur.
Nach wenigen Wochen konnte ich alle generierbaren Code-Stücke wirklich aus dieser zentralen Datenstruktur erzeugen, und für den weiteren Verlauf des Projektes stand praktisch nur noch die Weiterentwicklung dieser zentralen Datenstruktur und natürlich das Arbeiten mit ihn in Ada auf dem “embedded system” an.

Nun es stellte sich schon noch heraus, dass mehr als ursprünglich erwartet generiert werden konnte. Der Erwartungsdruck hier war aber nicht mehr so groß wie der am Anfang, und ich wollte nach Möglichkeit mit XML-Techniken weiterarbeiten. Ich baute also einen Converter, um die perl-Datenstruktur in eine “en passant” zu definierende XML-Datenstruktur zu transformieren, natürlich ist die Spezifikations-Sprache dazu “RELAX NG” und die Datenstruktur wird seit dem im emacs im nxml-mode editiert. Das neue XML bekam dann hübsche Extra-Features mit eigenen Code-Generatoren, immer noch in perl. Der bittere Aspekt war jedoch selbstverständlich, dass ich bis auf weiteres alle Änderungen im Bereich der in perl gehaltenen Datenstruktur in der XML-Variante nachziehen musste. Es stellte sich heraus, dass sich in diesem Bereich wochenlang keine Änderungen bzw. Erweiterungen ergaben. Aber mittelfristig sollten aus meiner Sicht schon alle generierbaren Code-Stücke nur aus der XML-Variante erzeugt werden.

Nun gestern erreichte ich dieses Ziel, und darüber bin ich sehr zufrieden. Die Code-Generatoren sind zwar immer noch in perl geschrieben (nur die Datenstruktur-Zugriffe mussten schließlich angepasst werden) und werden das vermutlich zeitlebens auch bleiben, aber sie funktionieren und sie sind auch ganz gut zu lesen und zu pflegen.

Mittlerweile habe ich jedoch auch für ein paar kleine Anwendungsgebiete neue Code-Generatoren entwickelt, und die sind in ruby geschrieben. Für die nächsten größeren und kleineren Aufgaben werden sie bestimmt als Vorlage dienen.
Selbstverständlich benutzen auch die neuen XML-Spezifikationen wieder “RELAX NG”.

Mittlerweile ist das CANopen-Kommunikationsprofil für ein zweites Fahrzeug in diesem CANopen-XML begonnen worden, und die Zweifel an der Nützlichkeit werden zumindest nicht mehr lautstark diskutiert.

Zu den erwähnten Extra-Features dieses CANopen-XMLs zählen Records mit “representation specifications” und Aufzählungstypen (ebenso mit rep. specs), aus welchen die Ada-Records und -Aufzählungstypen generiert werden.
Die Unterprogramme, mit welchen in Ada die CANopen-PDOs zusammengebaut und abgeschickt werden, sind sozusagen halb-automatisch erstellt.
Diejenigen Unterprogramme, welche ankommende PDOs zerlegen, sind noch gänzlich handgeschrieben, die XML-mäßigen Spezifikationen der PDOs werden darin aber als hilfreiche Kommentare verwendet.

Wer weiß, vielleicht verlangt ja mal ein Auftraggeber “Traceability”, die Grundlagen dafür wären schon gelegt.
Alle XML-Tags bekämen passende Attribute und Werte dazu,
und diese würden überallhin durchgeschleift.


Comments

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.