CANopen-Slave-Custom-Device-Implementierung zur Simulation
Zugsteuerungsintegrationstest
CANopen findet immer stärkere Verbreitung in Schienenfahrzeugen und dient dort dem Datenaustausch der einzelnen Komponenten. Für den Integrationstest einer Zugsteuerung ist es erforderlich Geräte mit einer CANopen-Schnittstelle zu simulieren. Im Umfeld der Software Veristand gibt es aber bisher keine CANopen-Slave Implemenentierung um Geräte mit CANopen-Slave-Schnittstelle simulieren zu können. Der Lösungsansatz ist somit die Implementierung eines Custom Devices zur Anbindung von CANopen.
Dafür musste in einem Custom Device die Anbindung der physikalischen CAN-Schnittstelle, die CANopen-Protokollimplementierung sowie alle relevanten CANopen-Dienste implementiert werden. Durch die Anwendung moderner SoftwareArchitekturen und -entwurfsansätze konnte eine CANopen-Kommunikationsanbindung für die Prüfstand-Software Veristand geschaffen werden. Der Integrationstest von Zugsteuerungen erfordert die Simulation von CANopen-Geräten innerhalb eines Zuges. Dafür ist es notwendig, anhand der CANopen-Spezifikation ein Custom Device für die Software zu implementieren. Hierbei sollen alle erforderlichen Kommunikationsdienste, die in der CANopen-Spezifikation beschrieben sind, bereitgestellt werden. Außerdem soll das Custom Device die Möglichkeit bieten, mehrere virtuelle Geräte an einer physikalischen Schnittstelle zu simulieren und mehrere physikalische Schnittstellen parallel in einem System zu betreiben. Das Objektverzeichnis des CANopen-Gerätes soll basierend auf EDS-Dateien (Electronic Data Sheet) automatisch erzeugt werden. Für die Abbildung aller notwendigen Funktionalitäten des Custom Devices ist es erforderlich alle Schnittstellen genau zu benennen. Dies ist einerseits die busseitige CANopen-Kommunikation mit der gerätespezfischen Datenbasis des Objektverzeichnisses und andererseits die spezifische Kanalschnittstellle von Veristand. Anhand der notwendigen Schnittstellen und Funktionalitäten konnten die erforderlichen Konfigurationsparameter und entsprechenden Konfigurationsseiten für den Custom Device im System Explorer der Prüfstand-Software entworfen werden. Die Abbildung oben zeigt die entsprechende Konfigurationsseite. Um die Konfiguration eines CANopen Custom Devices zu vereinfachen, ist die Datenübernahme des Objektverzeichnisses aus einer EDS-Datei möglich. Diese wird typischerweise vom jeweiligen Gerätehersteller bereitgestellt. Weitere Konfigurationsmöglichkeiten sind schnittstellenspezifische Einstellungen sowie die Kanalkonfiguration zur Anbindung an die Software. Über die direkte Kopplung zwischen Einträgen des Objektsverzeichnisses und Veristand-Kanälen erfolgt eine einfache Einbindung der CANopen-Schnittstelle in das Daten- und Ausführungsmodell. Standardmäßig sind verschiedene Kanäle vordefiniert, um den Zustand des CANopen Slave Device abzubilden.
Kommunikationsteil Custom Device
Der Kommunikationsteil des Custom Device besteht im Aufbau aus mehreren einzelnen Schichten. Die Struktur ist in Bild 2 dargestellt. In der untersten Ebene befindet sich die physikalische Schnittstelle (Xnet). Eingehende CAN-Nachrichten werden in CANopenNachrichten übersetzt und an den Dispatcher weitergeleitet. Dieser filtert die eingehenden Nachrichten und leitet diese an die entsprechenden registrierten virtuellen CANopen-Geräte weiter. Der implementierte CANopen-Kommunikationsstack implementiert hierbei unter anderem. folgende Dienste: NMT (Network Management), SYNC (Synchronisierung), TIME (Zeitsynchronisierung), SDO (Servicedaten Übertragung), PDO (Prozessdaten Übertragung) sowie EMCY (Übertragungsfehler). Eine einzelne Instanz des CANopen Custom Device besteht hierbei aus einem Slave Device und startet einen asynchronen Prozess zur Anbindung der CAN-Schnittstelle sowie einen CANopen-Dispatcher zur Verteilung aller Nachrichten. Bei der Implementierung wurde großer Wert auf die Funktionsfähigkeit und Qualität des Quellcodes gelegt. Durch den Einsatz des objekt-orientierten Programmieransatzes war es möglich, die hierarchische Kommunikationsstruktur zu abstrahieren und zu optimieren. Ein wichtiger Punkt ist auch die handwerkliche Qualität des Quellcodes, um den Aufwand für Wartung und zukünftige Erweiterungen zu vereinfachen. Bild 3 zeigt hier beispielhaft den Quellcode zur Nachrichtenkonvertierung.
Fazit
Der entwickelte CANopen Slave Custom Device für Veristand ermöglicht die Simulation von mehreren CANopen-Slave-Geräten und die Anbindung von einer oder mehreren CAN-Schnittstellen. Durch die Kopplung der CANopen-Anbindung mit den entsprechenden Simulationsmodellen über Veristand-Kanäle können die verschiedensten Geräte eines Schienenfahrzeuges simuliert werden. Durch die selektive Zu- und Abschaltung der simulierten Geräte ist es möglich, verschiedenste Betriebszustände sowie Fehlerzustände zu testen. Dies ist mit realen Geräten nur unter erschwerten bzw. kostenintensiven Bedingungen möglich. Die Implementierung auf Grundlage der objektorientierten Programmmierung erlaubt eine leichte Erweiterbarkeit sowie Wartbarkeit des gesamten Custom Devices, auch eine einfache Integration weiterer physikalischer CAN-Schnittstellen ist damit sichergestellt.
