Hi Dirk,
ich habe in einem gelangweilten Moment ein bisschen eine Systemarchitektur gezeichnet. Es stellt das dar, was ich vorher schon erwähnt hatte; ich zitiere mich hier mal selbst:
Zitat
Original von praderbz
Da die Aufgaben der Signalisierung sich stets wiederholen, würde ich dann Schnittstellen definieren, über die Zustände und Daten von einem Punkt (Signal, Kontrollpunkt, ...) an den nächsten übertragen werden. Persönlich bevorzuge ich eine strikte Trennung der Funktionsebenen "Sicherung" und "Steuerung". Erstere stellt die signaltechnische Sicherheit her, und wird nie aktiv vom Benutzer beeinflusst. Die "Steuerung" stellt die Schnittstelle für Bedienung und Anzeige zur Verfügung.
Hier der Link zum PDF: http://signals.us-modellbahn.net/files/SIG/misc/sys-arch.pdf
Mit CP und APB meine ich einen Control Point, und ein automatisches APB-Intermediate, wie sie zwischen CPs stehen. Das sind aber nur Beispiele, die aber alles wichtige abdecken dürften, wenn sie in der Funktion nicht allzu eng definiert werden.
Die gelben Pfeile zwischen den CPs stellen die Sicherungsebene dar. Da würde ich folgendes reinpacken, auch wenn es am Beginn noch nicht voll genutzt wird:
- Signalaspekte: was zeigt das nächste Signal? (Signalfolgen also hier regeln)
- Besetztstatus: ist die Strecke frei im Block?
- Richtungsinformation: kommt ein Zug entgegen, bzw. ist die eingestellte Richtung entgegengesetzt?
In die Schnittstelle zwischen Anzeige und Sicherung:
- Signalzustände
- Gleiszustände
- ?
Die Zugbeeinflussung würde ich auf unterster Ebene ansiedeln, denn sie muss von dem darüberliegenden nix mitbekommen. Je dümmer, desto besser.
Den Automatismus, tja, damit habe ich keinerlei Erfahrung, aber wenn man sich so die realen Systeme anschaut, dürfte der in der Top-Ebene, sprich Steuerung und Anzeige am besten aufgehoben sein. Quod erat demonstrandum
Mir fällt gerade auf, dass ich genau diese Architektur bei meinen Modulen verwende ...
Na, ist mal eine Idee, vielleicht hilft sie dir weiter
Grüße
Michael