Was haben reale Anforderungen mit Modellbau zu tun?

 Modellbau, Requirements, Systemmanagement  Kommentare deaktiviert für Was haben reale Anforderungen mit Modellbau zu tun?
Jun 122008
 

Auf den ersten Blick scheinen Modellbau und Anforderungsverwaltung (= Requirements Engineering) nichts miteinander zu tun zu haben, aber bei der Erstellung der Stellwerks-Software wird deutlich, wie viel Komplexität hinter diesem Thema steckt. Beim Entwurf einer Modellbahnsteuerung stand am Anfang die Idee, möglichst kostengünstig mit Standardtechnologien eine Steuerung zu entwickeln, um simpel Weichen schalten zu können. Dabei stand im Wesentlichen die Technik im Vordergrund. Nach und nach hat sich gezeigt, dass es die Software-Steuerung am Front-End in sich hat.

Anfangs stand die Darstellung des Soll-Zustand im Vordergrund. Es wurde über Start/Via/Ziel-Checkboxen ein Fahrtweg vorgegeben. Dieser soll so eingestellt werden, dass nur freie Gleise benutzt werden. Wurde eine freie Fahrstraße gefunden, sollen die Weichen geschaltet und die Signalfreigabe erteilt werden. Diese Anforderung war für den Anfang schnell implementiert. Bei genauerer Betrachtung zeigt sich, dass die Darstellung des Ist-Zustandes inkl. des Soll-Zustandes für den Benutzer erforderlich ist. Beim Studium von Berichten, wie realen Stellwerke funktionieren, hat sich gezeigt, dass das Thema sehr komplex ist. Die erste Idee war insofern nicht falsch angedacht. Tatsächlich erfolgt beim Suchen einer Fahrstraße erst eine Route, die frei ist. Diese muss durch das Stellen von Weichen erreicht werden. Dieser Vorgang heißt in der Realität Weichenumlauf. Hierbei ist der Vorgang an sich interessant, weil eine Rückmeldung erfolgen muss, dass die sog. Weichenendlage erreicht ist. Danach wird die Weiche verschlossen. Dieser mechanische Vorgang soll verhindern, dass sich durch die Erschütterung des darüberfahrenden Zuges die Weiche verstellt und somit den Zug zur Entgleisung bringt. Desweiteren ist eine versehentliche Umstellung durch den Fahrdienstleiter im Stellwerk dadurch nicht mehr möglich. Der mechanische Verschluss ist im Modellbau nicht möglich, wohl aber die Rückmeldung. Ein einfacher Schalter soll das Durchbrennen des Antriebes verhindern. Somit ist nur eine Spule unter Strom. Es lässt sich also mit einem hochohmigen Strom festellen, in welcher Lage sich die Weiche befindet ohne die Weiche durch den Strom selbst zu stellen. Somit kann diese Information dafür ausgewertet werden, ob eine Fahrstraße korrekt geschaltet wurde.

Erst danach kann eine Gleisfreigabe erfolgen. Die Realität weicht an dieser Stelle erheblich vom Modell ab. Die Gleisfreigabe erfolgt in der Realität durch Signale. Diese haben eine sog. punktuelle Zugbeeinflussung. Überfährt man ein auf rot stehendes Signal, löst ein unter dem Signal angebrachter Schwingkreis an der Lok eine Zwangsbremsung aus. Beim Modellbau sind Signale eher Kosmetik, allerdings kann keine Lok fahren, wenn kein Strom auf dem Gleis anliegt. Somit werden der Optik halber erst die Signale gestellt und danach erfolgt die Gleisfreigabe über das Aufschalten von Fahrstrom.

Jeder dieser Vorgänge ähnelt einer Transaktion so wie wir es aus der Informatik her kennen. Ein Vorgang (Weichenschalten) muss vollständig erfolgreich ausgeführt werden. Erst danach darf der nächste Vorgang (Signale schalten) folgen, denn sonst würde der Zug schon die Freigabe erhalten, während sich noch fatalerweise die Weichen schalten. Ist ein Vorgang nicht erfolgreich, müssen ggf. Vorgänge zurückgenommen werden. Weichen müssen nicht wieder zurückgestellt werden, wohl aber Signale und die Gleisfreigaben.

Die Steuerungs-Software muss diesen Anforderungen Rechnung tragen. Die Mikrocontroller müssen sowohl für eine korrekte Ansteuerung der Geräte (Weichen, Signale und Gleise) sorgen, eine korrekte Zustandsmeldung liefern und Zustandsmeldungen korrekt melden. Die Steuerungs-Software am Front End muss diese Meldungen korrekt darstellen und Fehlbedienungen ausschließen. Speziell bei der Fehlbedienung kommt eine Simulation des Verschlusses ins Spiel. Ist eine Fahrstraße erst einmal eingestellt, dürfen alle beteiligten Geräte nicht mehr verstellt werden. Mangels mechanischen Verschlusses kann das bei Modellweichen durch manuelles Verstellen trotzdem passieren. In diesem Fall muss eine dadurch betroffene Fahrstraße sofort deaktiviert werden. Desweiteren spielt das visuelle Feed-Back eine entscheidende Rolle. Da Mechanik im Spiel ist, dauert das Einstellen der Fahrstraße ggf. mehrere Sekunden. Dieser Vorgang muss auf der GUI dargestellt werden, ohne dass diese dadurch bedienungsunfähig wird. Das wird durch Multi-Threading erreicht. Das Versenden von Schaltkommandos wird in einem eigenen Thread durchgeführt. Diese Kommandos werden pro Vorgang in Batches zusammengefasst. Das Empfangen von Rückmeldungen erfolgt wiederum in einem eigenen Thread. SWT kann architekturbedingt nur Änderungen an der eigenen GUI im Haupt-Thread durchführen. Somit ist Message Passing nötig, um Zustandsänderungen in der GUI des Haupt-Threads visualisieren zu können. Optisch wird das so dargestellt, dass der Gleisplan in schwarz-weißen Strichen dargestellt wird. Durch Loks belegte Gleise werden immer orange dargestellt. Eine sich schaltende Fahrstraße ist schwarz-gelb. Weichen im Umlauf haben blinkende Weichennummern (in einem weiteren Thread als TimerTask implementiert). Ist die Fahrstraße erfolgreich eingestellt, wird diese grün dargestellt. Diese Darstellung ähnelt der eines voll-elektronischen Stellwerks der Realität. Hier werden weitere Sicherungsmaßnahmen genutzt, die im Modellbau schlicht Overkill wären: Ein Farbbalken, der zeigen soll, dass der Bildschirm auch wirklich alle Farben zeigen kann. Das alles nochmal als blinkender Farbbalken. Zusätzlich ist der darstellende Rechner mit zwei Grafikkarten ausgestattet, welche das Gleiche darstellen müssen.

Somit zeigt sich, dass Sicherungstechnik der Realität auch im Modellbau Anwendung findet. Viele Anforderungen zeigen sich erst währen der Implementierungsphase. Man muss einerseits den Entwicklungsprozess darauf abstimmen, andererseits muss die Architektur der Software so gestaltet sein, dass sich erweiterte Anforderungen leicht ergänzen lassen.

Quellen:
http://www.stellwerke.de
http://www.uni-stuttgart.de/iev/index.htm?/vwi/lupse/LUPSE.HTM