Kein Vorteil ohne Nachteil
CANopen-Migration zu CANopen-FD
CANopen-FD, beschrieben in CiA 1301, wird Schritt für Schritt klassische CANopen-Netzwerke ablösen. Der Übergang ist jedoch nicht immer sofort möglich, sodass eine Migration notwendig ist.
Bild: CAN in Automation (CiA) GmbHCAN-FD wird in der Automobilindustrie in den nächsten Jahren die klassischen CAN-Netzwerke ersetzen. Dies hat mehrere Gründe. Der höhere Datendurchsatz in CAN-FD-Netzwerken ist einer. Genauso wichtig ist aber auch das längere Datenfeld (payload) in den CAN-FD-Frames. Diese ermöglichen eine effizientere Übertragung und können auch für zusätzliche Protokolle verwendet werden, beispielsweise für funktionale Sicherheit und Cyber-Security. Da klassische CAN-Controller CAN-FD-Frames nicht kennen, werden diese mithilfe von CAN-Error-Frames zerstört. Die automatische Wiederholung führt zum selben Ergebnis. Das CAN-FD-Frame wird abgeschossen. Umgekehrt funktioniert es. In einem Netzwerk mit CAN-FD-Controllern können ohne Probleme klassische CAN-Datenframes versendet werden. Am einfachsten wäre es, sämtliche CANopen-Geräte in einem Netzwerk auf CAN-FD-Hardware und CANopen-FD-Software umzustellen. Aber das ist Theorie. In der Praxis nutzen die meisten CANopen-Netzwerke Geräte von verschiedenen Herstellern. Die Produktzyklen dieser Hersteller sind verständlicherweise nicht aufeinander abgestimmt. Der Systemdesigner hat mehrere Möglichkeiten, klassische CANopen-Geräte in CANopen-FD-Netzwerke einzubinden. Diese sollen im Folgenden auf ihre Praxistauglichkeit untersucht werden.
Brücke ist keine Krücke
Eine Lösung ist, die klassischen CANopen-Geräte über eine CAN/CAN-FD-Brücke zu isolieren. Dies kann ein einfaches Gerät sein, das die klassischen CANopen-PDOs in das CAN-FD-Netzwerk weiterleitet. Ob dabei die CAN-Identifier angepasst werden müssen, hängt von den beiden Netzwerkkonfigurationen ab. Allerdings braucht man auch in dem klassischen CANopen-Netzwerk ein Gerät mit NMT-Master-Funktionalität (Netzwerk-Management). Diese saubere Trennung von klassischen CANopen- und CANopen-FD-Geräten ist sehr flexibel. Wenn ein Gerät mit CANopen-FD-Interface erhältlich ist, wird es in das CAN-FD-Segment integriert. Anderenfalls bleibt es im klassischen CAN-Segment. Sogenannte Brücken zwischen CAN und CAN-FD werden von mehreren Firmen angeboten und können teilweise auf vielfältige Weise konfiguriert werden. Dabei ist sogar ein Aufteilen der PDOs und Wiederzusammensetzen möglich. Es gibt auch sogenannte Switches mit mehreren CAN- und CAN-FD-Ports für komplexe Systemarchitekturen. Zu beachten ist, dass zwei Konfigurationen notwendig sind. Man muss die CANopen-FD-Geräte per USDO (Universal-SDO) konfigurieren und die CANopen-Geräte im anderen Netzwerk-Segment werden per SDO (Servicedatenobjekt) parametriert. Die beiden Konfigurationsfunktionen müssen selbstverständlich koordiniert werden, damit das Gesamtsystem konsistent ist. Am Ende der Migration sind alle Geräte mit einem CANopen-FD-Interface verfügbar und dann fehlt das klassische CAN-Segment einfach weg und die Brücke wird überflüssig.
Bild: CAN in Automation (CiA) GmbHSchweigen ist nicht so goldig
Eine andere Idee, klassische CANopen-Geräte in einem CANopen-FD-Netzwerk ohne Error-Frames betreiben zu können, ist, diese vor der CAN-FD-Kommunikation zum Schweigen zu bringen. Dies ist einfach möglich, wenn man CAN-Transceiver mit selektiver Aufwachfunktion verwendet. Sie waren ursprünglich für andere Anwendungen entwickelt worden. Einige Fahrzeughersteller nutzen sie, um selten benötigte Steuergeräte in den Schlafmodus zu versetzen, um den Energieverbrauch zu reduzieren. Steuergeräte für Fensterheber und Schiebedächer sowie Einparkhilfen sind typische Beispiele. In CANopen-FD-Netzwerken könnten die klassischen CANopen-Geräte mit solchen Transceivern ausgestattet werden. Diese müssten vor der Übertragung von CAN-FD-Frames in den Ruhezustand versetzt werden, damit sie keine Error-Frames senden, wenn CAN-FD-Frames gesendet werden. Wenn die CANopen-FD-Kommunikation beendet ist, werden sie wieder aufgeweckt. Nachteilig ist, dass die CANopen-Geräte andere Transceiver benötigen und der CANopen-FD-Hostrechner die Schlaf- und Aufweckfunktion übernehmen muss. Außerdem muss der Hostrechner sowohl CANopen-FD (CiA 1301) und CANopen (CiA 301) unterstützten, damit er alle Geräte im Netzwerk konfigurieren kann. In CANopen erfolgt dies normalerweise mit SDOs. In CANopen-FD gibt es dafür die neuen USDO-Dienste, die eine SDO-Vollvermaschung unterstützen.
Verstecken hinter dem Schild
Eine weitere Möglichkeit wurde schon vor einiger Zeit vorgestellt, ist aber noch nicht am Markt erhältlich. NXP und auch Kvaser stellte CAN-Transceiver vor, mit denen man die CAN-FD-Frames nicht zu den klassischen durchlässt. Die beiden Konzepte unterscheiden sich zwar in der Realisierung, aber für den klassischen CAN-Teilnehmer ist das Ergebnis identisch. Er sieht die CAN-FD-Frames nicht, sendet also auch keine CAN-Error-Frames. NXP hat vor kurzem angekündigt seine Shield-Transceiver gegen Ende des Jahres auf den Markt zu bringen. Aber auch hier gilt: Es ist eine Hardwareänderung der bestehenden CANopen-Geräte notwendig. Allerdings ist kein zusätzliches Management notwendig. Auch das Konfigurieren der CANopen-Geräte per SDO muss gelöst werden. Der Hostrechner muss also einen CANopen- und einen CANopen-FD-Protokollstack implementieren.
Warten auf Godot
Samual Becketts Godot wartete ewig. Solange wird es im Falle von CANopen-FD nicht dauern. Mehrere Protokollstack-Anbieter haben bereits CANopen-FD implementiert. Die Gerätehersteller werden bei jedem Redesign ihrer Geräte bereits CAN-FD-fähige Hardware verwenden. Dies betrifft die Mikrocontroller mit integrierten CAN-FD-Schnittstellen und die CAN-Transceiver, die für Bitraten bis zu 5MBit/s qualifiziert sind. Der Kunde entscheidet, ob er CANopen oder CANopen-FD auf diesen Geräten laufen lässt. Mehrere Firmen haben die Hardware bereits auf CAN-FD umgestellt und es liegt an dem Kunden, ob er sich für das klassische CANopen oder CANopen-FD entscheidet. Anwender, die nur eigene Hardware einsetzen, können ebenfalls erst alle Geräte mit CAN-FD-Controllern ausstatten und dann in einem Schritt auf CANopen-FD umschalten. Erste OEMs haben dies bereits in Angriff genommen und werden in der nahen Zukunft alle Geräte CAN-FD-fähig machen und dann in ein bis zwei Jahren die CANopen-FD-Software laufen lassen.
Fazit und Ausblick
Mikrocontroller mit CAN-FD-Schnittstellen sind schon am Markt erhältlich, aber sie sind nicht unbedingt auch für vergleichsweise kleine industrielle Geräte (z.B. Sensoren) geeignet. Diese Situation wird sich im Laufe des Jahres ändern. Für den Umstieg von CANopen auf CANopen-FD sind zwei Optionen empfehlenswert:
- Warten bis alle benötigten Geräte mit CAN-FD-Hardware erhältlich sind und dann auf CANopen-FD umsteigen.
- Bereits erhältlich CANopen-FD-Geräte in einem CAN-FD-Netzwerk betreiben und über eine Brücke die klassischen CANopen-Geräte integrieren.
CAN in Automation (CiA) bietet entsprechende Schulungen (auch In-Haus-Seminare) an. Die Maschinen- und Anlagenbauer, die zu CANopen-FD migrieren möchten, können auch den kostenlosen CiA-E-Mail-Service nutzen, um sich in das Thema einzuarbeiten. Da wir auch in der Technik mit Kompromissen leben müssen, gibt es auch bei der Migration von CANopen zu CANopen-FD keinen Vorteil ohne Nachteil.
CANopen-FD, beschrieben in CiA 1301, wird Schritt für Schritt klassische CANopen-Netzwerke ablösen. Der Übergang ist jedoch nicht immer sofort möglich, sodass eine Migration notwendig ist.
Bild: CAN in Automation (CiA) GmbHCAN-FD wird in der Automobilindustrie in den nächsten Jahren die klassischen CAN-Netzwerke ersetzen. Dies hat mehrere Gründe. Der höhere Datendurchsatz in CAN-FD-Netzwerken ist einer. Genauso wichtig ist aber auch das längere Datenfeld (payload) in den CAN-FD-Frames. Diese ermöglichen eine effizientere Übertragung und können auch für zusätzliche Protokolle verwendet werden, beispielsweise für funktionale Sicherheit und Cyber-Security. Da klassische CAN-Controller CAN-FD-Frames nicht kennen, werden diese mithilfe von CAN-Error-Frames zerstört. Die automatische Wiederholung führt zum selben Ergebnis. Das CAN-FD-Frame wird abgeschossen. Umgekehrt funktioniert es. In einem Netzwerk mit CAN-FD-Controllern können ohne Probleme klassische CAN-Datenframes versendet werden. Am einfachsten wäre es, sämtliche CANopen-Geräte in einem Netzwerk auf CAN-FD-Hardware und CANopen-FD-Software umzustellen. Aber das ist Theorie. In der Praxis nutzen die meisten CANopen-Netzwerke Geräte von verschiedenen Herstellern. Die Produktzyklen dieser Hersteller sind verständlicherweise nicht aufeinander abgestimmt. Der Systemdesigner hat mehrere Möglichkeiten, klassische CANopen-Geräte in CANopen-FD-Netzwerke einzubinden. Diese sollen im Folgenden auf ihre Praxistauglichkeit untersucht werden.
CAN in Automation (CiA) GmbH
Dieser Artikel erschien in SPS-MAGAZIN 7 2018 - 16.07.18.Für weitere Artikel besuchen Sie www.sps-magazin.de
