Was bei der Migration von CANopen zu CANopen FD zu beachten ist

Gegenüberstellung des Datentelegramms; klassisches CAN und CAN FD CiA

Im Vergleich zu klassisch CAN bietet CAN FD die Möglichkeit, innerhalb eines CAN Datentelegramms, bis zu 64 Byte an Nutzdaten, zu übertragen. Um die durch die Übertragung entstehenden Latenzzeiten so gering wie möglich zu halten, erlaubt CAN FD, den Datenteil des Datentelegramms, mit einer erhöhten Übertragungsgeschwindigkeit zu kommunizieren. Da viele Attribute des klassischen CAN, auch für CAN FD gelten, können Anwender des klassischen CANs, große Teile des bereits für klassisch CAN aufgebauten Wissens im CAN FD Umfeld wiederverwenden.

Etablierte CAN-Netzwerktopologien beibehalten

Insbesondere das Wiederverwenden von für klassisch CAN entwickelten Netzwerktopologien dürfte für Anwender, die auf CAN FD umsteigen wollen, hochgradig interessant sein. CAN FD weist genau für diesen Anwendungsfall die nötige Skalierbarkeit auf. Die Nutzung des verlängerten Datenfeldes sowie die Übertragung des Datenfeldes in erhöhter Kommunikationsgeschwindigkeit sind in CAN FD zwei getrennt ansteuerbare Parameter. Das Datenfeld lässt sich bedarfsgerecht an die Erfordernisse des Systems anpassen. Anwender können zudem die entstehende Latenzzeit prüfen und im Bedarfsfall so justieren, dass die Bestandstopologie weiterhin fehlerfrei arbeitet.

Dass nicht alles neu entwickelt werden muss, erleichtert den Umstieg auf CAN FD enorm. Sollte die für klassisch CAN entwickelte Netzwerktopologie doch zu viele Reflexionen erzeugen, können gegebenenfalls neu entwickelte CAN FD SIC Transceiver helfen, die Signalqualität zu verbessern und somit die Topologie einsatzfähig halten.

Bridges und Gateways für schrittweisen Umstieg auf CAN FD

Beim Umstieg von klassischem CAN auf CAN FD müssen Anwender beachten, dass alle Netzwerkteilnehmer CAN FD-fähig sind. CAN FD Geräte beherrschen zwar die klassische CAN Kommunikation. Allerdings beherrschen Geräte, basierend auf klassischen CAN Controllern, kein CAN FD Telegrammformat. Sie würden daher jeden Versuch einer CAN FD Kommunikation nachhaltig stören. Zwar gibt es Lösungen auf dem Markt, die wechselseitig auf klassisch CAN und CAN FD basieren und so einen Mischbetrieb von Geräten erlauben. Jedoch scheint für „Nicht-Automotivanwendungen“ die Trennung der unterschiedlichen CAN Generationen in verschiedene Netzwerke (Anwendungssegmente) der praktikabelste Weg. Der Datentransfer zwischen einem Anwendungssegment, in dem nur Geräte mit klassischen CAN Controllern sind, und einem Anwendungssegment, welches sich ausschließlich auf CAN FD Kommunikation stützt, gewährleisten in diesem Fall Bridges, Router oder Gateways.

CAN-FD-fähige Bridges gibt es einige auf dem Markt. Das CiA Geräteprofil für konfigurierbare Netzwerkkomponenten CiA 456 liefert sogar einen Lösungsvorschlag, wie eine harmonisierte Konfigurationsschnittstelle aussehen kann, um den Datentransfer zwischen den per CAN Bridge verbundenen CAN Anwendungssegmenten zu realisieren. Dieser Ansatz funktioniert beim Austausch von Datenpaketen, die die maximale Größe des klassischen CAN Datenfeldes nicht übersteigen. Sobald allerdings von CAN FD Seite Datentelegramme mit mehr als acht Byte Nutzdaten in das klassische CAN Anwendungssegment transferiert werden sollen, braucht es eine Lösung, wie die Nutzdaten vorverarbeitet werden müssen, damit klassische CAN Anwendungssegmente diese kommunizieren können.

Für diese Problemstellung hat die CiA Spezifikation CiA 302-7 eine standardisierte Lösung, indem eine CAN Router-interne Datenbank alle Daten verwaltet. Ankommende Daten werden portioniert und anwendungsgerecht in dieser Router-internen Datenbank abgelegt. Sobald die Daten in dieser Datenbank bereitstehen, können diese Daten für jedes CAN Anwendungssegment bedarfsgerecht, neu und individuell zusammengestellt werden. Somit ist auch das Problem gelöst, dass die CAN FD Seite gegebenenfalls Datenpakete anliefert, die nicht nur in Summe zu groß für klassische CAN Datentelegramme sind, sondern auch nur in Teilen, in ganz bestimmen CAN Anwendungssegmente, kommuniziert werden sollen.

Migration von CAN zu CAN FD in den unteren Layern

Trennung der CAN Generationen in verschiedene Anwendungssegmente CiA

Auf den „unteren“ Ebenen des ISO-OSI-Schichtenmodells, gibt es Lösungen, um die Migration von klassisch CAN zu CAN FD, zu erlauben. Applikationsseitig kann es aber gewollt sein, genau die Details zu verstecken, ob Daten mittels CAN FD oder klassisch CAN angeliefert wurden. Um überlagerte Applikationen nicht ändern zu müssen, kann es zu Migrationszwecken also sinnvoll sein, in CAN-FD-basierten Geräten, für klassisch CAN konzipierte CANopen Kommunikationssoftware zum Einsatz zu bringen. Diese Geräte können dann zwar nicht die volle Performance von CAN FD nutzen, ermöglichen aber auf Anwendungsschichtebene völlige Durchgängigkeit zwischen Anwendungssegmenten – basierend auf klassisch CAN und CAN FD.

Volle CAN FD Performance können lediglich Geräte ausschöpfen, die für CAN FD entwickelte Kommunikationssoftware unterstützen. Aus diesem Grund hat die CiA Interessengruppe (IG) CANopen FD, das bekannte, auf klassischem CAN basierende CANopen Protokoll, um die durch CAN FD bereitgestellten Möglichkeiten, erweitert. Das Ergebnis wurde im September 2017, als CANopen FD, im Dokument CiA 1301, veröffentlicht. CANopen FD behält die meisten CANopen-Eigenschaften bei.

Konfigurierbare Netzwerkkomponenten gemäß CiA 456 CiA

Allerdings sind die Datentransport-orientierten Dienste auf CAN FD angepasst worden. Das CANopen Prozessdatenobjekt (PDO) wurde so erweitert, dass es jetzt 64 Datenbyte im „Broadcast“ transferieren kann. In diesem Hinblick wäre die einzige Anpassung, welche an einer klassischen CANopen Software vorgenommen werden müsste, das Anheben des Grenzwertes eines PDOs, von acht auf 64 Byte. Eine CAN FD orientierte Erweiterbarkeit des für Konfiguration und Diagnose genutzten CANopen Dienstes Servicedatenobjekte (SDO) wäre kaum möglich gewesen und hätte nur bedingt befriedigende Resultate geliefert. Insofern hat sich die IG CANopen FD dazu entschlossen, das klassische SDO durch einen völlig neuen Dienst, genannt „Universal Service Data Object“ (USDO), zu ersetzen. Das USDO unterstützt den kompletten Funktionsumfang des klassischen SDOs. Darüber hinaus erlaubt das USDO während der Systemlaufzeit, den dynamisch Aufbau von Querkommunikation zwischen allen Netzwerkteilnehmern, ohne dass ein Systemintegrator diese vorkonfiguriert hätte. Dies ist sehr vorteilhaft für IoT-Anwendungen (Internet of Things), die zum Beispiel zur Systemlaufzeit auf beliebige Datenpunkte im CAN-basierten, eingebetteten Netzwerk zugreifen möchten. Ebenso können Systeme davon profitieren, die erst vom Endanwender zusammengestellt werden und immer wieder dynamisch in ihrer Zusammensetzung verändert werden (etwa Batterieladesysteme). Das USDO unterstützt den gleichzeitigen Zugriff auf mehrere Netzwerkteilnehmer. Diese Eigenschaft kann, verglichen zu klassischen CANopen Systemen, bei gleichzeitiger Konfiguration vieler gleichartiger Geräte, viel Zeit sparen.

CANopen/CANopen FD Gateways

CANopen FD Kommunikationssoftware ist bereits aus mehreren Quellen verfügbar. Allerdings werden CANopen/CANopen FD Gateways benötigt, um zwischen den höher-performanten CANopen FD Anwendungssegmenten und der CANopen-Seite zu vermitteln. Erste Prototypen solcher CANopen/CANopen FD Gateways wurden im Rahmen der SPS 2019, in Nürnberg, gezeigt.

Um alle Möglichkeiten von CAN FD ausnutzen zu können ist es ideal, wenn eine neue Geräte- oder Systemgeneration komplett auf eine neue Plattform mit CAN FD-fähigen Komponenten aufsetzt. Jedoch gibt es viele langlebige Anwendungen, in denen nicht alle Baugruppen, z. B. zum Zweck einer funktionalen Erweiterung, ausgetauscht werden können. Gerade für Anwendungen wie Baumaschinen, Eisenbahnen, etc. ist es wichtig, dass die hier skizzierten Migrationspfade bestehen, um mittels CAN FD, zukünftige Problemstellungen wie aus den Bereichen funktionale Sicherheit, Security, usw. leichter lösen zu können.

(ml)