CANopen bekommt mit CANopen FD mehr Geschwindigkeit und höheren Datendurchsatz.Lonely – Fotolia.com
CANopen FD basiert auf dem seriellen CAN-FD-Protokoll, der verbesserten Datenverbindungsschicht von CAN. Es ist ebenso zuverlässig und robust wie sein Vorgänger und auch der Preis ist vergleichbar niedrig. Das ebenfalls in ISO 11898-1 international genormte serielle Kommunikationsprotokoll erlaubt allerdings höhere Datenraten und längere Nachrichten. Die längeren Nachrichten nutzt CANopen FD sowohl für die Servicedatenobjekte (SDO) als auch für die Prozessdatenobjekte (PDO).
Vor allem die längeren PDOs sind für die Hersteller von elektrischen Antrieben und anderen komplexen Geräten von Interesse. In den bis zu 64 Byte langen PDOs können Anwender beispielsweise mehrere Steuerworte und Sollwerte versenden. So lassen sich mit einem PDO beispielsweise bis zu acht Antriebe nach CiA 402 (Elektrische Antriebe) ansteuern. Eine synchrone Übertragung einzelner PDOs ist damit nicht mehr nötig. Dies erlaubt kürzere Zykluszeiten und vereinfacht auch die Anwendungs-Software. Man kann aber auch mehrere Sollwerte in einem PDO für einen Antrieb unterbringen. Dazu muss das CANopen-FD-Protokoll die Abarbeitung der in einem PDO untergebrachten Kommandos eindeutig festlegen.
PDO mit Kommandos und Positionssollwerten für acht Antriebe.CiA
In CANopen FD wird es wie bisher bei CANopen bis zu 64 Mapping-Einträge geben. Somit ist bei längeren PDOs kein bit-weise Mapping möglich. Das schränkt den Systemdesigner zwar ein, aber 518 Zeiger (Pointer) zu konfigurieren, ist auch kein Vergnügen. Die CANopen-Profile müssen deswegen noch angepasst werden. Die entsprechenden Gremien der internationalen Anwender- und Herstellervereinigung CAN in Automation (CiA) werden noch in diesem Jahr damit beginnen die Profilspezifikationen zu erweitern.
Beschleunigter Software-Download
Die Automobilindustrie ist bereits an die Grenzen des CAN-Datendurchsatzes gestoßen – vor allem beim Herunterladen von Software am Ende des Fließbandes ins Fahrzeug. Deshalb hat Bosch in Zusammenarbeit mit anderen CAN-Experten das CAN-FD-Protokoll entwickelt (CAN mit flexibler Datenrate). Es erlaubt eine höhere Übertragungsgeschwindigkeit, während nur ein Teilnehmer sendet. In der Arbitrierungsphase gilt weiterhin, dass die Bitrate mit der Netzwerklänge abnimmt. Dies trifft auch auf das Ende der Nachrichtenübermittlung zu, wenn die zuhörenden Teilnehmer innerhalb einer Bit-Zeit den korrekten Empfang bestätigten. Während der Datenphase sind die angeschlossenen Geräte nicht synchronisiert. Um eventuelle Laufzeitverzögerungen vor allem bei höheren Datenraten auszugleichen, können die sendenden CAN-FD-Chips diese automatisch kompensieren.
Bei einer Linientopologie mit kurzen Stichleitungen lassen sich realistisch Geschwindigkeiten bis 5 Mbit/s zu erreichen, ohne bei der Zuverlässigkeit und Robustheit Abstriche machen zu müssen. Dies gilt auch für den Einsatz im erweiterten Temperaturbereich, der vor allem für Maschinen im Outdoor-Einsatz von Bedeutung ist.
CAN-FD-Nachrichten werden optional mit zwei Bit-Raten übertragen, in der Arbitrierungsphase (Header und Trailer) ist sie auf 1 Mbit/s begrenzt, in der Datenphase sind je nach verwendeten Transceivern 2, 4, oder 5 Mbit/s möglich.CiA
Das SDO-Protokoll von CANopen-FD unterstützt ebenfalls Nachrichten mit einer Länge von bis zu 64 Byte. Dadurch lässt sich zusätzlich zum höheren Datendurchsatz auch ein effektiveres Segmentieren von großen Datenmengen erreichen. Da sich im CAN-FD-Protokoll die Datenlänge ab 8 Byte nur sprungweise vergrößern lässt, muss man die ungenutzten Bytes mit Bitpattern auffüllen. CANopen FD (CiA 301 Version 5.0 und höher) übernimmt dieses sogenannte ‚Padding‘ sowohl bei den Servicedatenobjekten (SDO) als auch den Prozessdatenobjekten (PDO) vom Protokollstack automatisch.
Alle anderen CANopen-Protokolle (NMT, Heartbeat, Sync, Emcy und Time) benötigen derzeit nicht mehr als 8 Byte, werden aber trotzdem mit der höheren Datenrate übertragen. Dies sorgt für Interoperabilität der am Markt erhältlichen Geräte. Für Interoperabilität sorgt ebenfalls, dass die unterstützten Versionen der verschiedenen CANopen-Spezifikationen im Objektverzeichnis und im elektronischen Datenblatt referenziert werden. Außerdem werden für die Profilspezifikationen sogenannte Klassen eingeführt. Das sind standardisierte Profilvarianten, bei denen bestimmte praxisrelevante Optionen verpflichtend sind. Die Gerätehersteller sind eingeladen eine oder mehrere Klassen zu unterstützen. Somit reduziert sich hoffentlich die Anzahl der am Markt angebotenen Varianten.
Strengere Regeln für das Bit Timing
Derzeit erarbeitet CAN in Automation (CiA) Richtlinien für den Entwurf von CAN-FD-Systemen (CiA 601). Der Systementwickler muss vor allem die Bittiming-Empfehlungen strenger befolgen als bisher. Schon geringe Abweichungen vom festgelegten Abtastzeitpunkt können zu Kommunikationsfehlern führen. Dies ist eine Erkenntnis aus den von CiA durchgeführten CAN-FD-Plugfesten. Bei diesen Veranstaltungen können die CiA-Mitglieder frühzeitig ihre Prototypen testen. Auch die CAN-FD-Norm legt fest, dass der zu verwendende Oszillator mit 20, 40, oder 80 MHz getaktet sein muss. Mit einem entsprechenden Vorteiler ist zu gewährleisten, dass die Time-Quanta (atomare Zeiteinheit) in allen Teilnehmern identisch ist. Auch die Toleranz der Frequenz ist definert.
Die CANopen-FD-Spezifikation (CiA 301 Version 5.0) wird im Laufe des Sommers veröffentlicht. Die Protokollstack-Anbieter, wie Emtas, HMS/Ixxat oder Port werden sicherlich gleichzeitig ihre Produkte auf den Markt bringen. Die Hersteller von Software-Werkzeugen wie Peak oder Vector werden zeitnah ebenfalls CANopen-FD-Produkte liefern. Die erforderlichen CAN-FD-Controller und die für Datenraten höher als 1 Mbit/s qualifizierte CAN-Transceiver sind bereits als Prototypen von verschiedenen Produzenten erhältlich.
Somit stehen den Geräteherstellern demnächst alle Komponenten für den Bau von CANopen-FD-Geräten zur Verfügung. Um die Konformität der CANopen-FD-Implementierungen zu gewährleisten, ist eine Zertifizierung durch den CiA vorgeschrieben. Neben der Konformität wird die Nutzervereinigung auch die Interoperabilität testen. Dazu soll ein permanentes CANopen-FD-Netzwerk mit konformen Produkten installiert werden.
Holger Zeltwanger
(mf)
