Bild 1. Der Vergleich der Protokoll-Rahmen

© esd electronics

• Beibehaltung der klassischen CAN-Konzepte in der Arbitrierungs- und Bestätigungsphase sowie bei der Fehlerbehandlung.

• Erhöhung der Bitrate in der Datenphase von bisher maximal 1 Mbit/s auf bis zu 8 Mbit/s und mehr.

• Erhöhung der Zahl der in einer CAN-Nachricht übertragenen Datenbytes von bisher maximal 8 auf 64 Bytes.

Das neue Protokoll ist seit 2015 als internationaler Standard veröffentlicht, wobei alle CAN-FD-Controller abwärtskompatibel sind und nach wie vor auch das klassische CAN-Protokoll unterstützen. Mittlerweile existiert ein großes Angebot an dedizierten CAN-FD-Controllern, Mikrocontrollern mit integrierten CAN-FD-Schnittstellen und FPGA-basierten Lösungen.

Die Protokolldetails

Im klassischen CAN kann die Übertragung einer Nachricht logisch grob in die Phasen Busarbitrierung, Daten und Bestätigung unterteilt werden. Die Bits werden hier in allen Phasen mit der identischen Bitrate übertragen, wobei alle Busteilnehmer diese kontinuierlich nachsychronisieren, um Phasenrauschen und -drift der unabhängigen lokalen Oszillatoren zu kompensieren. Dies ist insbesondere während der Arbitrierungs- und Bestätigungsphase notwendig, da mehrere Knoten gleichzeitig auf dem Bus senden und jeder einzelne Knoten sein gesendetes Bit mit denen anderer Busteilnehmer vergleichen können muss. Diese Eigenschaft des klassischen CAN-Protokolls bestimmt die physikalischen Grenzen für die maximal mögliche Bitrate beziehungsweise Kabellänge.

Tabelle 2. Das Bitverhältnis CAN zu CAN FD

© esd electronics

Eine Aussage über den zu erwartenden Gewinn an Durchsatz oder die Reduzierung der Latenz beim Wechsel von CAN auf CAN FD ist durch die Art der Implementierung nicht einfach direkt zu ermitteln und hängt stark von dem verwendeten Protokoll und weiteren Randbedingungen ab.

Zur besseren Abschätzung stellt die Tabelle 2 die benötigten Bits für die Übertragung von Nachrichten mit 11-Bit-Identifier bei unterschiedlichen Datenlängen und unterschiedlichen Verhältnissen zwischen der Bitrate in der Arbitrierungs- und Datenphase für CAN FD dar. Die Zahl der Nachrichten-Bits bezieht sich dabei auf Bitzeiten der Arbitrierungsphase.

Ausgehend von Tabelle 2 sollen zwei Extrema bezüglich des Aufwandes bei einer Umstellung von CAN auf CAN FD betrachtet werden.

Umstellung von CAN auf CAN FD

ohne Änderung des Protokolls

Der (Software-) Aufwand reduziert sich neben der Anschaffung von CAN-FD-fähiger Hardware im besten Fall lediglich auf das Setzen der erhöhten Bitrate in der Datenphase. Bei einem Verhältnis zwischen Arbitrierungs- zu Datenphasen-Bitrate von 1:4 und einem Protokoll, das hauptsächlich auf Nachrichten mit 8 Datenbytes basiert, kann mit einer Verbesserung des Durchsatzes um mehr als Faktor 2 beziehungsweise um eine entsprechende Halbierung der Latenzzeiten gerechnet werden.

mit Änderung des Protokolls

Bild 3. Das Verhältnis von Arbitrierungs- zu Datenphasen-Bitrate bei der Performance-Optimierung mit CAN FD Payloads von 8/64 Bytes mit unterschiedlichen Bitratenverhältnissen.

© esd electronics

Wird neben der Erhöhung der Datenrate mit zusätzlichem Software-Aufwand das Protokoll angepasst, sodass die höhere Zahl von möglichen Datenbytes bei CAN FD ausgenutzt wird, sind noch deutlich größere Leistungszuwächse möglich. Ausgehend vom vorherigen Beispiel soll erneut ein Protokoll (zum Beispiel für die Aktualisierung eines Gerätes), das bisher auf 8 Byte CAN-Nachrichten basierte, auf 64 Byte CAN-FD-Nachrichten umgestellt werden. Bild 3 betrachtet dabei Blöcke von 64 Bytes.

Die Grafik zeigt, dass bei unverändertem Protokoll und einem Verhältnis von Arbitrierungs- zu Datenphasen-Bitrate von 1:4 der Datendurchsatz, wie im vorherigen Beispiel, mehr als verdoppelt wird. Unter Ausnutzung der vollen 64 Byte Nutzdaten von CAN FD erhöht sich der Datendurchsatz bereits um das fünffache und bei einer weiteren Steigerung des Bitratenverhältnisses auf 1:8 um mehr als das Neunfache. Im letzten Fall benötigt die Übertragung der 64 Byte CAN-FD-Nachricht sogar weniger Zeit als in der ursprünglichen Version des Protokolls die Übertragung einer einzelnen 8 Byte CAN-Nachricht, sodass unter diesen Randbedingungen noch zusätzlich eine Reduzierung der Latenz erreicht wird.

Migration zu CAN FD

für Hardware-Entwickler

Die Unterstützung von CAN FD für neue Hardware-Entwicklungen ist mittlerweile vergleichsweise einfach. Wie schon beim klassischen CAN, getrieben durch die Automobilindustrie, ersetzen ein oder mehrere CAN-FD-Schnittstellen bei aktuellen Mikrocontrollern die klassischen CAN-Schnittstellen. Bis zu einem bestimmten Verhältnis der Bitrate von Arbitrierungs- zur Datenphase akzeptiert CAN FD die gleiche Oszillator-Toleranz wie CAN, aber es empfiehlt sich, einen für CAN FD spezifizierten Transceiver einzusetzen, dessen Vorteile dem Kunden, selbst bei einer Nutzung mit ausschließlich klassischem CAN, zugute kommen. Auch die Erweiterung existierender Designs um eine CAN-FD-Anbindung ist mit mittlerweile verfügbaren Standalone Controllern oder durch Nutzung eines FPGA-IP-Cores einfach zu realisieren.

für Software-Entwickler

Der Aufwand der Migration einer Appli-kation nach CAN FD hängt stark von der bisher für klassisches CAN genutzten API ab. Bleibt diese unverändert auch für die CAN-FD-Hardware verfügbar, kann eine Migration in drei Schritten stattfinden.

1. Alle Teilnehmer nutzen die CAN-FD-Schnittstellen wie bisher mit dem klassischen CAN-Protokoll.
2. Umstellung aller Teilnehmer in der Datenphase eine höhere Bitrate zu nutzen, was bei unverändertem Protokoll sofort zu einer Verringerung der Latenz und Busauslastung beziehungsweise Erhöhung des Durchsatzes führt. Der Entwickler muss zuvor prüfen, ob sein Protokoll das Versenden von RTR-Nachrichten fordert, da dies bei CAN FD nicht mehr unterstützt wird.
3. Veränderung/Erweiterung des Protokolls durch Übertragung von mehr als 8 Byte Nutzdaten.

Der letzte Schritt erleichtert neben einem weiteren Gewinn beim Datendurchsatz insbesondere die Lösung von Problemen in Verbindung mit Datenkonsistenz von mehr als 8 Byte Nutzdaten sowie die Implementierung von Protokollen etwa im Bereich Safety und Security, die oftmals mit lediglich 8 Byte Nutzdaten schwer oder gar nicht zu realisieren sind. Insbesondere bei Schritt 3 muss der Entwickler jedoch überprüfen, ob die gewünschte Echtzeit-Eigenschaften seiner Implementierung (Latenzzeiten) nach wie vor erhalten geblieben sind.

für Systemintegratoren

Der Vorteil für Systemintegratoren bei einer Migration zu CAN FD besteht darin, dass die Busteilnehmer mit klassischem CAN-Controller zunächst – auch in mehreren Stufen – gegen Busteilnehmer mit einem CAN-FD-Controller getauscht werden können. Aufgrund der Abwärtskompatibilität lässt sich zunächst weiterhin das klassische CAN-Protokoll nutzen. Besteht zu einem späteren Zeitpunkt der Bedarf nach mehr Busbandbreite und/oder geringerer Latenz kann die Applikation entsprechend um-gestellt werden, mit dem Vorteil, jederzeit wieder auf den klassischen CAN-Zustand zurückwechseln zu können, wenn es bei der CAN-FD-Kommunikation zu Problemen kommen sollte, da die Verdrahtung ja unverändert bleibt. Der einzige Nachteil bei der Migration ist nur, dass eine Umstellung auf CAN FD erst erfolgen kann, wenn alle Busteilnehmer das CAN-FD-Protokoll unterstützen, da klassische CAN-Controller die CAN-FD-Nachrichten als Protokoll-fehler interpretieren.

Higher Layer Protokolle

Der Autor: Oliver Thimm ist Leiter System Design bei esd electronics.

© esd electronics

Nach Veröffentlichung des Standards im Jahr 2015 wurden inzwischen auch eine Reihe von klassischen CAN-basierten Higher Layer Protokollen unterschiedlicher Industriedomänen an die Erweiterungen von CAN FD angepasst oder stehen kurz vor einer Veröffentlichung. Beispiele hierfür sind ISO TP und J1939 (Automobil-industrie), CANopen FD (Automatisierung) oder ARINC825 (Luftfahrt).

Kurzinterview: Warum zu CAN FD migrieren?

Dirk Flege ist Vertriebsleiter bei esd electronics.

© esd electronics

Seit gut vier Jahren ist das CAN FD-Protokoll mit höherer und flexibler Datenrate standardisiert. Durch die Abwärtskompatibilität dieser Technologie lassen sich klassische CAN-Applikationen zu CAN FD migrieren oder als Basis in neuen Applikationen nutzen. Dirk Flege, Vertriebsleiter bei esd electronics, erläutert im Gespräch, was für eine Migration zu CAN FD spricht.

Das CAN-Protokoll zeichnet sich durch eine große Robustheit gegen Störungen aus. Wie wird diese Eigenschaft des CAN-Protokolls bei CAN FD erhalten?

Dirk Flege: Das CAN FD-Protokoll ist so angelegt, dass klassische CAN-Konzepte in der Arbitrierungs- und Bestätigungsphase sowie bei der Fehlerbehandlung beibehalten werden können. Um auch in der längeren Datenphase die gleiche Robustheit gegenüber Kommunikationsfehlern zu erreichen, verwendet das Protokoll zur Kontrolle statt der üblichen 15-Bit-Prüfsumme eine 17-Bit-Prüfsumme (Nachrichten mit bis zu 16 Bytes Nutzdaten) oder eine 21-Bit Prüfsumme (Nachrichten mit mehr als 16 Bytes Nutzdaten).

Das CAN FD-Protokoll ist abwärtskompatibel zum klassischen CAN-Protokoll. Welche Chancen bietet das für die industrielle Automatisierung?

Flege: Durch das abwärtskompatible Design lassen sich CAN-Applikationen einfach auf die leistungsfähigere CAN FD-Kommunikation umstellen, ohne die bestehende Verdrahtung ändern zu müssen. Alternativ können CAN FD-Komponenten auch als Basis in aktuellen CAN-Applikationen eingesetzt und zu einem späteren Zeitpunkt einfach auf die CAN FD-Kommunikation umgestellt werden.

Neben Standard CAN FD-Controllern sind auch CAN FD Controller auf FPGA-Basis auf dem Markt, die eine höhere Flexibilität hinsichtlich der Leistungsfähigkeit und der Funktionsdichte aufweisen. Welche Vorteile bieten FPGA-basierte CAN-Controller?

Flege: Der Schreib- und besonders der Lesezugriff auf Standard-Controller ist im Vergleich zur Zykluszeit moderner CPUs eher langsam. Daher haben wir einen FPGA-basierten CAN-Controller entwickelt, der nun die Basis unserer CAN-Interfaces bildet. Der Advanced CAN Controller (esdACC) hat ein bis zu 32 Bit breites Interface, unterstützt einen 64 Bit Timestamp und kann einen 100-prozentigen Busload generieren. Hiervon leitet sich der CAN FD-Controller für FPGA ab, der das CAN FD-Protokoll gemäß ISO11898-1:2015 unterstützt.

Welche Vorteile bringt das FPGA konkret für die CAN FD-Interfaces? 

Flege: Das CAN-Interface „CAN-PCIe/402-FD“ beispielsweise ist ein universell einsetzbares Board, dass für den PCIe-Bus entwickelt wurde und über ein oder zwei CAN FD-Interfaces gemäß ISO 11898-2 verfügt. Für die Datenübertragung zum Host-Speicher nutzt es das Bus-Mastering. Dadurch wird eine Verringerung der Latenzzeit während der I/O-Transaktionen, insbesondere durch die höhere Datenrate und der Reduzierung des CPU-Loads, erreicht. Durch die Verwendung von MSI (Message Signaled Interrupts) kann das PC-Board beispielsweise in Hypervisor-Umgebungen arbeiten. Zudem unterstützt es hochauflösende Hardware-Timestamps.