Architektur

Inhalt:

1. Hardware-Architektur
2. Software-Architektur

Hardware-Architektur

Vorschlag für die HW-Architektur, basierend auf einer Diskussion mit Armin Mühl. Er hat den großen Vorteil, daß Bedienung/Bauform auf eine separate Platine ausgelagert sind, und damit die Anpassung an die (individuellen) Gegebenheiten einfach zu realisieren sind. Sicherlich auf Kosten (zu mindest am Anfang) erhöhten Aufwandes.

Beschreibung der einzelnen Funktionsgruppen:

• Prozessorboard
  Es beherbergt alle Komponenten, die bauformunabhängig sind.
1. Prozessor
   Der Prozessor mit allen Komponenten, wie: Schwinger, RESET, ISP, Logging (mit RS232), ...
2. PS (Powersupply)
   Es sollte die Stromversorgung für alle Komponenten auf dem PB und bei geringem Stromverbrauch auch für das BB sicherstellen.
   [BA] Vorschlag: mit eigenem Brückengleichrichter, dann hats Verpolungsschutz und kann Wechselstrom ab.
3. BLI (Blockinterface für elektr. Block)
   (Quasi) RS 422, wie schon bei [SB] definiert.
4. BHI (Bahnhofsinterface für Bahnhofsschnittstelle)
   Bahnhofsschnittstelle nach René Pabst mit Ergänzungen von [RM].
5. RLI optional (Blockinterface für Relaisblock)
   Falls irgendwann erforderlich auch eine Schnittstelle zum Relaisblock. Das schaltet dann aber die BLI aus!
6. X1 (Steckverbinder zum Bedienboard)
   Derzeitiger Vorschlag: Zwei 10-polige Steckverbinder mit der gleichen Belegung wie beim STK 500. Dann kann das auch damit getestet werden.


• Bedienboard
  Hier können die (individuellen) Wünsche nach Bauform, Bedienung, Einbauart, etc realisiert werden. Festgelegt ist eigentlich nur die Schnittstelle zum PB, nicht mal die Richtung der einzelnen Pins (siehe SW).
1. PKI (Peripherie: Kontaktinterface)
   Irgendwo müssen wir die Kontakte (Taster, etc) der Bedienoberfläche ja einlesen.
2. PMI (Peripherie: Melderinterface)
   Alle Melder hängen hier, egal ob Lampe, LED, Wecker... . Das bedeuted, daß der Boardesigner hier auf entsprechenden Schutz des PB zu achten hat.
3. PRI (Peripherie: Relaisinterface)
   Evtl. notwendige elektromechanische Verriegelungen.
   [BA]Ob dazu ein von PMI getrenntes Interface notwendig ist kann ich im Moment nicht absehen.
4. X1 (Steckverbinder zum Prozessorboard)
   Siehe PB.
5. PS (Powersupply)
   Bei höherem Stromverbrauch oder "exotischen" Spannungen (z.B.: Lämpchen mit leckeren 48 Volt im Bedienfeld) muß das BB seine Stromversorgung selbst sicherstellen.

Software-Architektur

Eine SW-Architektur müssen wir irgendwann sowieso festlegen (oder nachdokumentiern). Wenn wir auch die Vorteile der obigen HW-Architektur nutzen wollen, kommen ein paar Punkte hinzu.
Spätestens hier zeigen sich die Vorteile von Stefans Vorliebe für C-Programme und modulares Programmieren. :-)

Beschreibung der einzelnen Funktionsbausteine

[BA] Ob wir wirklich eine strikte Trennung zwische Betriebssystem und Basissystem durchhalten wollen, oder das in einer Ebene verwursten wollen, sollten wir noch diskutieren. Ich habs mal in zwei Ebenen dargestellt, weil der Weg von zwei nach eins einfacher ist, als umgekehrt.
[SB] Naja, meine bisher genutzte Verzeichnisstruktur ist als vertikale Unterteilung gedacht, aber darin finden sich natuerlich die "S" und "B" Schicht wieder, wie unten "aufgemalt"
[BA] So hatte ich Deine SW auch interpretiert. Ich wollte das nur nicht alleine festlegen. Also es gibt zwei Ebenen!?!

• Betriebsystem (Interrupt-getrieben)
  Hier werden alle HW-nahen Dinge abgefahren, also z.B. Steuerung der Richtung von PINs, Entprellung von Eingängen. Hier kommen die Module von [SB] zum Tragen, incl 10ms Interrupt.
1. SBK (System: Blockkomunikation (elektr.))
   Bedienung des U(S)ART.
2. SGK (System: Gleiskontakt)
   Sonderbehandlung für den Gleiskontakt, per Interrupt.
3. SPA (System: PIN-Ausgabe)
   Regelmäßiges Setzen der Ausgabepins.
4. SPE (System: PIN-Einlesen)
   Regelmäßiges Einlesen und (individuelles??) Endprellen der Eingangspins.
• Basissystem ([SB]Von Hauptschleife angetrieben, [BA] Da würde mir interupgetrieben (Deine 10ms) besser gefallen)
  Hier stellen wir die "sichere" Übersetznug der BeSy-Atome in signaltechnische Fragmente zur Verfügung. Z.B.: Wenn ein Kommando in der Queue steht, dann ist es auch abzuarbeiten und zurückzumelden. Das heißt, saubere, dokumentierte Schnittstelle.
  Hier kommen natürlich auch die Module von [SB] zum Tragen, incl 10ms Interrupt.
1. BBK (Basis: Blockkommunikation)
   "Sichere" Kommandoschnittstelle, für die Kommunikation mit dem Nachbarblock. Falls RLI implementiert würde auch die Kommunikation mit einer Relaisimplementierung eines Blocks hier abgedeckt.
2. BBS (Basis: Bahnhofsschnittstelle)
   Die erlaubten Zustände der Bahnhofsschnittstelle (incl. Störung). Das heißt, hier sind Ein-/Ausgänge schon interpretiert.
3. BBI (Basis: Bedieninterface)
   Hier gibts nur stabile Eingänge und (evtl. rückgelesene) Ausgänge. Was da wie zu interpretieren ist, macht die Applikation.
• Applikation (Anwenderspezifisch) (Endlosschleife)
  Hier werden die bauformabhängigen Funktionen implementiert. Kann individuell geschehen (Verteilung der Arbeit auf mehr Schultern). Allerdings sollten die unterlagerten Schichten nicht umgangen werden.
  [BA] Da wir ja eh bei Sourceforge ein OpenSource-Projekt haben, finde ich es angemessen, wenn individuelle Implementierungen, die auf unserem Basis-/Betriebssystem aufsetzen, dort auch der Allgemeinheit zur Verfügung gestellt werden.

Beschreibung des Ist-Zustandes der Software

Diese Seite wurde zusammengestellt von Bernd Wisotzki. Stand: 05.01.2003

Site hosted by: