Kommunikationsmodell
Damit die automatische Code-Synthesekette aus den grafischen Modellen für das verteilte System Code erzeugen kann, verwenden wir das Simulink AddOn Matlink der Firma TTTech für das Time-Triggered Protocol, um zum einen die Zuordnung von Programmteilen zu Rechenknoten zuzuordnen und zum anderen den Datenfluss zwischen den Knoten zu modellieren.
Ein einfaches Kommunikationsmodell
Obige Grafik zeigt ein einfaches Kommunikationsmodell, in dem zwei TTP Knoten Nachrichten miteinander austauschen. Innerhalb der blauen Subsysteme ist das jeweilige Verhalten innerhalb der entsprechenden TTP Knoten modelliert und die gelben Fähnchen repräsentieren das Lesen und Schreiben vom bzw. auf den TTP Bus.
Die Bahnanlage ist so organisiert, dass jeweils einer der 8 TTP Knoten unter der Bahnanlage seine angeschlossene Bahn-Peripherie ansteuert, aber nicht viel Steuerlogik implementiert. Diese Knoten nennen wir Aktuator Knoten. Ein zentraler Knoten ist nicht direkt an Bahn-Peripherie angeschlossen, sondern übernimmt nur die logische Steuerung. Er empfängt also den Status aller Aktuator Knoten und schickt Stellbefehle an sie zurück. Dieser Knoten heißt Controller Knoten.
Wie im Kapitel über die TTP Vernetzung beschrieben, besteht die Bahn aus insgesamt 8 Aktuator Knoten und einem Controller Knoten und wesentlich mehr Peripherie als in obiger Graphik angesprochen wird. Entsprechend ist auch das Kommunikationsmodell wesentlich größer:
Kommunikationsmodell für alle 8 TTP Knoten der Bahnanlage
Die Zahlen auf den Leitungen deuten an, dass jede Nachricht nicht nur einen einzigen Wert überträgt, sondern teilweise über 50 Werte, die aus übersichtlichkeits Gründen zu Arrays zusammengefasst wurden.
Dispatcher
Bei der Implementierung der eigentlichen Steuerung im Controller Knoten fällt dem Benutzer als erstes die Aufgabe zu, die Adressierung der Peripherie auf die einzelnen TTP Knoten und ihre Leistungselektroniken umzusetzen. Wenn die Logik auf einen Sensor oder Aktor zugreifen will, muß sie den zuständigen Knoten ausmachen und auf diesem an der richtigen Stelle auf den Block zur Hardwareansteuerung zugreifen.
Zusammenspiel der Modelle
Damit der Entwickler sowohl in dem eigentlichen Controller als auch in der Simulation der Bahn intuitiv auf die Bahn-Peripherie zugreifen kann, sitzt eine Dispatcher Einheit zwischen dem eigentlichen Controller und den Ein- und Ausgängen des Controller-Subsystems des Kommunikationsmodells. Somit bleibt für einen Controller-Entwickler die Verteilung der Bahnperipherie auf bestimmte TTP-Knoten transparent.
Der Dispatcher im Controller Subsystem
Somit kann ein Controller zum einen in dem Kommunikationsmodell eingesetzt werden, um direkt lauffähigen Code für die Bahnanlage zu erzeugen. Zum anderen kann derselbe Controller an ein Simulationsmodell der Bahnanlage angeschlossen werden, um das Verhalten zunächst nur zu simulieren.
Der selbe Controller für Simulation und Codesynthese
