Systemkonfiguration mit Software- Werkzeugen Optimierung der PDO-Kommunikation in CANopen-Netzwerken

Die international genormte CAN­open-Anwendungs­schicht (EN50325-4) sieht für zeitkritische Übertragung von Prozessdaten das PDO-Protokoll vor. Es ist auf eine einzige CAN-Nachricht abgebildet, d.h., man kann pro PDO nur 8-Byte-Nutzdaten übertragen. Das reicht zwar für viele Befehlsworte und Statusinformationen aus, aber das voreingestellte PDO-Mapping ist nicht für jede Anwendung optimal. (Hinweis: In allen CAN-basierten Netzwerken, also auch in CANopen-Systemen, muss der Anwender darauf achten, dass er nur absolute Prozessdaten in den PDOs überträgt. Dies liegt daran, dass es vorkommen kann, dass eine CAN-Nachricht ein zweites Mal übertragen wird, obwohl die erste bereits von dem Empfänger als gültig akzeptiert wurde. Im Falle eines relativen Wertes, beispielsweise dem Kommando, die Temperatur um 10°C zu erhöhen, würde der Empfänger diesen Befehl zweimal empfangen und die Temperatur um 20°C anheben. Sind alle für eine Anwendung relevanten und zusammen gehörigen Prozessdaten in demselben PDO untergebracht, muss der Anwender nichts optimieren. Werden aber beispielsweise ein Byte aus einem PDO und ein weiteres Byte aus einem anderen PDO für eine Aufgabe benötigt, so hat der Systementwickler die Möglichkeit, die beiden Werte in ein PDO zu packen (engl.: to map). Dazu kann man ein neues PDO schaffen oder eines der beiden vordefinierten PDOs ummappen. Dazu gibt es im CANopen-Objektverzeichnis für jedes PDO eine Zeigerliste, die auf die zu mappenden Prozessdaten verweist. Die Zeigerliste enthält die \’Adressen\‘ (16-bit-Index und 8-bit-Subindex) der Prozessdaten, die in dem jeweiligen PDO zu übertragen sind. Theoretisch kann man bis zu 64 1-Bit-Prozess­daten in einem PDO übertragen. Man muss allerdings nicht die gesamte Länge des PDOs (8 Byte) ausnutzen. Wenn man nur 4Byte Prozessdaten benötigt, wird man, um die Buslast zu reduzieren, ein entsprechend kurzes PDO versenden. Dies erhöht zwar relativ den Anteil des Protokoll-Overheads, reduziert jedoch den absoluten Anteil an der Busbandbreite. Viele am Markt befindliche E/A-Module unterstützen solch ein variables PDO-Mapping. Es kann sehr komfortabel mit Hilfe von Softwarewerkzeugen genutzt werden. Bei einigen Tools erfolgt die Optimierung der PDOs von E/A-Modulen sogar automatisch oder zumindest semi-automatisch. Von variablem PDO-Mapping spricht man, wenn die Konfiguration im Netzwerkmanagement-Zustand (NMT-Status) \’pre-operational\‘ erfolgt. In diesem Zustand darf das CANopen-Gerät keine PDOs senden und empfangen. Somit muss der Systementwickler bei der Konfiguration nicht darauf achten, dass die PDO-Sender und -Empfänger jederzeit konsistent konfiguriert sind. Erst wenn die an der PDO-Kommunikation beteiligten Geräte in den NMT-Status \’operational\‘ geschaltet werden, müssen Sende- und Empfangsseite konsistent konfiguriert sein. Es gibt auch CAN­open-Geräte, die ein dynamisches PDO-Mapping erlauben. Dann muss der Systemdesigner darauf achten, dass die PDOs während der inkonsistenten Phase in der Konfiguration nicht gesendet beziehungsweise empfangen werden. Dazu kann er die PDOs abschalten und nach der Konfiguration wieder einschalten (Bit 31 im COB-ID-Parameter). Dies kann selbstverständlich auch von einem Tool automatisch bewerkstelligt werden. Die Buslast-Reduzierung durch ein optimiertes PDO-Mapping ist allerdings begrenzt. Wesentlich größeren Einfluss auf die Buslast hat ein optimierter Sendeplan (Scheduling) der PDOs. Das \’richtige\‘ PDO-Scheduling Viele aus der SPS-Welt kommende Systemdesigner übertragen Prozessdaten periodisch, da auch die Steuerung intern periodisch arbeitet. Dazu kann man in CANopen den PDO-Event-Timer ungleich Null setzen. Dieser Parameter ist im Objektverzeichnis mit Hilfe der SDO-Dienste (Servicedatenobjekt) konfigurierbar. Diese Übertragungsart ist aus Sicht der Busbandbreite allerdings nicht optimal. Die Busbandbreite ist in CAN-basierten Systemen ein kritischer Wert, da er von der Länge des Netzwerkes determiniert ist. Je länger der Bus, desto geringer ist die maximale Datenrate (von 1MBit/s bei 25m bis zu 50KBit/s bei 1km). Bei einer periodischen Übertragung wird der Wert auch gesendet, wenn er sich nicht geändert hat. Er ist also aus Anwendungssicht redundant. In CAN-Netzwerken ist deshalb eine Übertragung zu bevorzugen, bei der nur dann gesendet wird, wenn sich eines der gemappten Prozessdaten geändert hat. Mit dieser Scheduling-Methode kann man die Buslast reduzieren. Dies ist auch deshalb wichtig, da es in CAN-Netzwerken mit einer permanen­ten Buslast von über 50% vorkommen kann, dass ein Teilnehmer nicht mehr an der Kommunikation teilnehmen kann, da er im Error-Passive-Modus seine Fehlertelegramme nicht mehr korrekt beenden kann. Die asynchrone Change-of-state-Übertragung ist deshalb zu bevorzugen. Der Systementwickler muss allerdings berücksichtigen, dass sich alle Prozessdaten zum gleichen Zeitpunkt ändern können und sozusagen ein PDO-Gewitter ausgelöst wird. Übrigens: Die periodische PDO-Übertragung löst – wie landläufig angenommen wird – dieses Problem nicht: Da der Event-Timer von der lokalen Uhr getriggert wird, die nicht mit denen Uhren der anderen Teilnehmer synchronisiert sind, werden zu einem Zeitpunkt alle PDOs getriggert und erzeugen so eine hohe permanente Buslast. Um eine möglichst gleichmäßige Buslast zu erzeugen, gibt es deshalb in CANopen die synchrone Übertragung von PDOs sowie die Möglichkeit die lokalen Uhren mit der Time-Nachricht zu synchronisieren. Die Time-Nachricht ermöglicht es, eine absolute Systemzeit (in Millisekunden nach Mitternacht und Tagen nach dem 1.1.1984) mit einer Genauigkeit von 1ms an alle anderen Busteilnehmer zu versenden. Diese können dann ihre lokalen Uhren auf diese Systemzeit synchronisieren und ihre PDOs synchronisiert versenden. Die häufiger genutzte Alternative ist der PDO-Sync-Mechanis­mus. Dabei sendet ein Teilnehmer die Sync-Nachricht. Wenn diese empfangen wird, erfassen die CANopen-Geräte die Sensor- und Status-Prozessdaten und senden diese in so genannten synchron-zyklischen PDOs. Dabei hat der Systementwickler die Möglichkeit, das synchrone PDO so zu konfigurieren, dass es bei jeder Sync-Nachricht die Daten erfasst oder bei jeder zweiten oder dritten oder (bis zu) 240sten. So lässt sich die benötigte Busbandbreite für niederfrequente Prozessdaten deutlich reduzieren. Trotzdem kann es passieren, dass Prozessdaten redundant über­tragen werden, da sich der Wert über einen längeren Zeitraum nicht ändert. Um dies zu vermeiden, gibt es in CAN­open die synchron-azyklischen PDOs. Diese werden nur ausgelöst, wenn ein Sync-Nachricht empfangen wurde und eine Change-of-state-Bedingung vorliegt, sich also der Wert gegenüber dem letzten Wert verändert hat. Mit den unterschiedlichen Scheduling-Arten kann der Systementwickler die PDO-Kommunikation an seine Anwendung optimal anpassen. Selbstverständlich unterstützen ihn dabei die am Markt angebotenen CANopen-Konfigurationstools. Dies geht soweit, dass die Werkzeuge die gesamte Optimierung vornehmen. Der Anwender muss also keine tiefen CAN­open-Kenntnisse haben; er muss sich allerdings auf die im Tool implementierten Optimierungsalgorithmen verlassen. Eine Auswahl der verfügbaren Werkzeuge findet man im jährlich aktualisierten CANopen-Online-Produktführer der Nutzerorganisation CAN in Automation (CiA), der auch als CD erhältlich ist. Die \’richtige\‘ PDO-Priorität Um wichtigen Prozessdaten eine Vorrangstellung einzuräumen, kann der Systementwickler sie in PDOs mappen, die mit einer höheren Priorität auf dem CAN-Netzwerk übertragen werden. Im COB-ID-Parameter konfiguriert der Anwender die eineindeutige Priorität mit der ein PDO gesendet wird. Die voreingestellte PDO-Priorität kann der Anwender ziemlich frei verändern, er muss allerdings darauf achten, dass die Prioritäten eineindeutig vergeben werden. Die höchste Priorität hat die CAN-Nachricht mit dem Identifier \’0\‘ und die niedrigste Priorität hat der Identifier \’2047\‘. Für die PDO-Kommunikation stehen normalerweise die Identifier \’385\‘ bis \’1407\‘ zur Verfügung. Es dürfen aber auch andere Identifier verwendet werden außer \’0\‘ (NMT-Kommando), \’1409\‘ bis \’1663\‘ (Default-SDO) und \’1793\‘ bis \’1919\‘ (Heartbeat oder Boot-up-Nachricht). Die eineindeutige Zuordnung der CAN-IDs kann von Tools automatisch geprüft werden. Die \’richtige\‘ Vergabe der Prioritäten hat ebenso wie das \’richtige\‘ Scheduling eventuell Rückwirkungen auf das \’richtige\‘ PDO-Mapping. Es macht beispielsweise wenig Sinn, ein hochpriores Prozessdatum mit einem niederprioren im selben PDO zu übertragen. Die Optimierung der PDO-Kommunikation läuft also meistens in mehreren Iterationsschritten. Die \’richtige\‘ Lösung Letztendlich führt die PDO-Optimierung fast immer zu mehreren \’richtigen\‘ Lösungen. Es gibt nicht die einzig wahre, richtige Lösung. Wer keine Tools für die Optimierung der PDO-Kommunikation verwendet will, muss sich detaillierte Kenntnisse über CAN­open aneignen. Bei einfachen CAN-open-Systemen ist eine PDO-Optimierung nicht unbedingt notwendig. Dies gilt vor allem für Netzwerke, bei denen die durchschnittliche Buslast deutlich unter 25% liegt. Die am Markt erhältlichen CANopen-Systemdesign-Tools unterscheiden sich insbesondere in ih­rem Automatisierungsgrad: von rein manuellen Tools bis zur vollständig automatischen PDO-Optimierung. Der Anwender hat die Qual der Wahl – nicht nur bei den CANopen-Geräten, sondern auch bei den Tools.