CAN XL als Backbone im Fahrzeug

Seit 30 Jahren ist CAN das dominierende fahrzeug-interne Netzwerk. Die wichtigsten Erfolgsgründe sind die Zuverlässigkeit dank Fehlererkennung und automatischer Sendewiederholung von Rahmentelegrammen (Frames) im Fehlerfall, die durch differenzielle Übertragung gegebene Robustheit gegen Störungen sowie die Einfachheit des CAN-Protokolls.

Insbesondere die Möglichkeit, Teilnehmer hinzuzufügen oder wegzulassen, gestattet den Herstellern, ihre Fahrzeuge in verschiedenen Varianten anzubieten, ohne die Steuergeräte umzuprogrammieren.

CAN und CAN FD

Die maximale Datenrate von 1 MBit/s sowie die maximal 8 Byte Nutzdaten pro Rahmentelegramm von CAN reichten 20 Jahre lang für die meisten Anwendungen im Fahrzeug aus. War die Busbandbreite zu gering, konnte ein weiteres CAN-Netzwerksegment mit dem bereits existierenden CAN-Netzwerk über ein Steuergerät mit Bridge-, Router- oder Gateway-Funktion verbunden werden. Um diese Limitierungen der ersten CAN-Generation (Classical CAN) zu überwinden, entwickelte Bosch im Jahre 2012 die zweite CAN-Generation, die im Laufe der ISO-Standardisierung weiter verbessert wurde. Sie ist als CAN FD (flexible Datenrate) derzeit in vielen Fahrzeugen integriert.

Neben den CAN-FD-fähigen Transceivern, die in ISO 11898-2:2016 spezifiziert sind, gibt es auch die kompatiblen SIC-Transceiver (hier: Signal Improvement Capapility) nach CiA 601-4 (CiA: CAN in Automation). Diese SIC-Transceiver können das Klingeln auf den Netzwerkleitungen unterdrücken, so dass Datenraten von deutlich mehr als 2 MBit/s in der Datenphase bei gegebener Netzwerktopologie möglich sind. Insbesondere trifft dies auf Sterntopologien und Hybridtopologien zu. CAN XL überträgt pro Datenframe bis zu 64 Byte Nutzdaten.

Anforderungen an CAN XL als Rückgrat-Kommunikationssystem

Um CAN-Netzwerke auch als Rückgrat-Kommunikationssystem zu verwenden, sind weitere Funktionen erforderlich, die CAN FD nicht standardisiert zur Verfügung stellt. Aus der Ethernet-Welt ist beispielsweise das EtherType-Feld bekannt. Mit ihm kann der Sender eines Frames dem Empfänger mitteilen, welches höhere OSI-Protokoll verwendet wird. Dies ermöglicht die Implementierung von Multiprotokoll-Stacks, was erforderlich ist, wenn unterschiedliche Anwendungen auf einem Kabel laufen sollen. Solche Integrationsnetzwerke werden in Zonen-Netzwerk-Architekturen benötigt, die mit möglichst wenigen Leitungen auskommen. Im Extremfall befindet sich für eine Anwendung ein Steuergerät im Frontbereich und das andere im Heck. Herkömmliche Domänen-orientierte Netzwerkarchitekturen sind zwar in punkto Software eine gute Lösung, aber aus Gewichtsgründen nicht optimal.

CAN XL

Deshalb initiierte Volkswagen in der CiA-Nutzervereinigung die Entwicklung von CAN XL, der dritten CAN-Protokoll-Generation. Im Herbst 2021 gab CiA die entsprechenden Spezifikationen heraus:

CiA 610-1: CAN XL data link layer and physical coding sub-layer
CiA 610-3: CAN SIC XL physical medium attachment sub-layer
Beide Spezifikationen wurden bereits bei ISO zur internationalen Normung eingereicht. Sie sollen in die Normen ISO 11898-1 beziehungsweise ISO 11898-2 eingearbeitet werden.

Der CiA arbeitet derzeit an entsprechenden CAN-XL-Konformitäts-Testplänen, die ebenfalls bei ISO eingereicht werden sollen, um sie in die Normen ISO 16845-1 sowie ISO 16845-2 zu integrieren. Darüber hinaus entwickeln CiA-Mitglieder ein CAN-XL-Security-Protokoll, das in CAN-XL-Protokoll-Controller implementiert werden kann. Auch eine Frame-Fragmentierung, die bei zu langer Buslatenzzeit für eine bestimmte Anwendung benötigt wird, ist in Arbeit. Die Buslatenzzeit ist die Zeit, die ein Teilnehmer mit dem Senden eines Datenframes der höchsten Priorität warten muss, wenn gerade noch ein Rahmentelegramm übertragen wird. Mit der Frame-Fragmentierung kann der Nutzer die maximale Länge der Datenframes und damit die Buslatenzzeit reduzieren. Dies ist unabhängig von der Transportschicht, welche die Nachrichten der Anwendungsschicht entsprechend den Möglichkeiten der Datenverbindungsschicht in Segmente aufteilt. Die Frame-Fragmentierung ist sozusagen ein QoS-Merkmal (Quality-of-Service) der Datenverbindungsschicht. Sie ist für CAN XL in dem Dokument CiA 613-3 spezifiziert.

SDU-Type und Virtual-CAN-Network-ID

Gemäß der Norm ISO 7498-4 benötigt jede OSI-Schicht für Multiprotokoll-Schnittstellen eine dynamische Konfigurationsmöglichkeit, die auch in das jeweilige Protokoll eingebettet sein kann. Im klassischen CAN-Protokoll ist diese beispielsweise das IDE-Bit (Identifier Extension). In CAN FD kommt noch das FDF-Bit und bei CAN XL das XLF-Bit hinzu. Mit diesen drei Bits wird dem CAN-Protokoll-Controller mitgeteilt, welches Frame-Format er beim Senden verwenden beziehungsweise, wie er ein empfangenes Datenframe interpretieren soll. Genaugenommen gehören auch noch das RTR-Bit (Remote Transmission Request) des klassischen CAN-Protokolls beziehungsweise die RRS-Bits (Remote Request Substitution) der anderen CAN-Protokolle dazu. Da aber die Verwendung von Remote-Frames nicht mehr State-of-the-Art ist, kann man diese Bits auch als historisches Relikt betrachten.

Um dem Empfänger mitzuteilen, welches höhere Protokoll verwendet wurde, ist eine entsprechende Information im Rahmentelegramm nötig. Im CAN-XL-Protokoll gibt es dazu das 8 Bit lange SDT-Feld (service data unit type, SDU type, Bild 1).

Somit sind 256 verschiedene höhere Protokolle unterscheidbar. In der Spezifikation CiA 611-1 sind den höheren Protokollen entsprechende 8-Bit-Werte zugeordnet. Neben Werten für standardisierte Protokolle gibt es auch Werte für herstellerspezifische Protokolle.

TCP/IP per CAN

Beispielsweise wurde TCP/IP ein Wert zugeordnet, so dass entsprechende Anwendungen nun auch per CAN XL übertragen werden können. Dadurch sind keine großen Änderungen der Software zur Nutzung von CAN XL nötig. Das CAN-XL-Datenfeld mit seinen bis zu 2048 Byte kann ohne Weiteres TCP-Segmente transportieren. Die Zuverlässigkeit mit einer Hamming-Distanz von 6 (es werden fünf beliebig verteilte Bitfehler erkannt) und die Robustheit der physikalischen Übertragung sind die wichtigsten Vorteile gegenüber anderen Protokollen der Datenverbindungsschicht.

Auch der Preis für die CAN-XL-Hardware ist verglichen mit anderen Kommunikationslösungen ähnlicher Leistungsfähigkeit wegen der geringeren Komplexität der physikalischen Übertragung geringer. CAN-XL-SIC-Transceiver nach CiA 610-3 können je nach verwendeter Netzwerk-Topologie mehr als 10 MBit/s übertragen.

Um auch Anwendungen mit gleichen höheren Protokollen unterscheiden zu können, ist im CAN-XL-Protokoll das 8 Bit lange Feld) eingebettet. Mit ihm sind 256 Instanzen eines höheren Protokolls (siehe SDT-Feld) kennzeichenbar. Dies dürfte selbst für sehr komplexe Backbone-Netzwerke ausreichen.

Prioritäts-Feld und Akzeptanz-Feld

Im Gegensatz zum klassischen CAN- und zum CAN-FD-Protokoll wurde beim CAN-XL-Protokoll die Doppelfunktion des CAN-Identifiers separiert. In den ersten beiden CAN-Protokoll-Generationen diente das 11 Bit beziehungsweise 29 Bit lange ID-Feld sowohl einer eindeutigen Prioritätszuteilung für den Buszugriff als auch zur Inhaltskennzeichnung, womit es zur SDU (Service Data Unit) des nächsthöheren Protokolls gehörte und folglich Payload war. In CAN XL gibt es dagegen ein 11 Bit langes Prioritäts-Feld (priority field) und ein separates 32 Bit langes Akzeptanz-Feld (acceptance field), in dem eine Adresse oder eine Inhaltskennzeichnung steht, die vom nächsthöheren Protokoll ausgewertet wird. Die Länge des Akzeptanz-Feldes von 32 Bit gewährleistet, dass alle bisherigen höheren auf CAN basierenden Protokolle abbildbar sind.

Konfigurierbarkeit und Skalierbarkeit

Die CAN-XL-Datenverbindungsschicht ist in ihrer Funktionalität konfigurierbar (Tabelle 1).

Neben der dynamischen Frame-Konfigurierbarkeit gibt es auch noch weitere auswählbare Funktionen. Dazu zählt zum Beispiel das Abschalten der automatischen Sendewiederholung, wenn ein Fehler erkannt wird. Dann wird erst in der Transportschicht eine Fehlerbehandlung durchgeführt. In diesem Zusammenhang kann auch eine maximale Anzahl von Sendewiederholungsversuchen konfiguriert werden (1 bis 6 Versuche).

Mit seinen drei Generationen und einer partiellen Rückwärtskompatibilität ist die CAN-Datenverbindungsschicht relativ gut skalierbar. CAN FD und CAN XL sind dank der spezifizierten Exception-Mode-Funktion rückwärtskompatibel. In der Praxis bedeutet das, dass ein CAN-FD-Controller CAN-XL-Frames ignoriert. Ein CAN-XL-Controller kann alle CAN-Frame-Formate verarbeiten. Nur ein CAN-Controller der ersten Generation versteht weder CAN-FD- noch CAN-XL-Frames. Er sendet dann ein Fehler-Rahmentelegramm (error frame).

Bezüglich der physikalischen Übertragung ist CAN XL ähnlich wie CAN FD skalierbar. CAN XL verwendet aber immer zwei Bitraten: eine für die Arbitierungsphase und eine für die Datenphase. Es erfolgt also immer eine Bitraten-Umschaltung. Dafür gibt es zwei Bitraten-Register. Wenn kein hoher Datendurchsatz nötig ist, kann aber auch in beiden Phasen die gleiche Bitrate verwendet werden. Allerdings geht die Übertragung dann nicht schneller als 1 MBit/s; der Grund hierfür ist die bekannte Begrenzung in der CAN-Arbitrierungsphase. Die in ISO 11898-2:2016 genormten Transceiver sind je nach Netzwerk-Auslegung und Anzahl der Teilnehmer für maximal 5 MBit/s qualifiziert. Mit den in CiA 601-4 spezifizierten SIC-Transceivern sind bis zu 8 MBit/s erreichbar, wenn das Netzwerk entsprechend ausgelegt ist. Für noch höhere Bitraten gibt es die CAN-SIC-XL Transceiver, die deutlich mehr als 10 MBit/s übertragen können. Dazu muss aber der CAN-XL-Controller entsprechend konfiguriert werden (transceiver mode switching), da er dann nicht mehr NRZ-codierte Bit, sondern PWM-codierte Bit an seiner AUI-Schnittstelle (Attachment Unit Interface) zum Transceiver überträgt.

Die Bitraten-Konfiguration ist vom Prinzip her beliebig innerhalb der spezifizierten Grenzen einstellbar, aber selbstverständlich gelten die physikalischen Gesetze der Leitungstheorie. Nach Möglichkeit sollten minimale Datenraten verwendet werden, da bei höheren Bitraten leichter Störungen auftreten können.

Ausblick

Tests zur Interoperabilität erste CAN-XL-Implementierungen von verschiedenen Anbietern (Bosch, Fraunhofer und Vector) fanden bereits im Sommer 2021 statt. In einem vom CiA-Verein organisierten CAN-XL-Plugfest wurden CAN-SIC-XL Transceiver von Infineon und NXP eingesetzt, und in einem zweiten Plugfest soll nun getestet werden, ob sich die CAN-XL-Implementierungen auch bei Störungen interoperabel verhalten. Konformitätstestpläne sind ebenfalls im CiA in Entwicklung. Mit ihnen können Testhäuser die Konformität von CAN-XL-Controller und CAN-SIC-XL Transceiver prüfen.

Die Basisspezifikationen (CiA 610-1 und CiA 610-3) sind fertiggestellt und wurden bereits bei ISO zur internationalen Normung eingereicht. Eine Liste aller fertiggestellten und veröffentlichten CAN-XL-Spezifikationen ist in Tabelle 2 zu sehen.

CAN XL eignet sich von seiner Funktionalität her insbesondere als Backbone-Netzwerk. Es ist für preiskritische Anwendungen in Personenkraftwagen entwickelt worden. Auch für die Anwendung in Nutzfahrzeugen ist CAN XL geeignet, da es TCP/IP-Anwendungen und bewährte höhere Protokolle wie J1939 und CANopen über die gleiche Leitung übertragen kann. Mit dem Multi-PDU-Konzept (CiA 611-2) sind sogar unterschiedliche Anwendungsschicht-Nachrichten in einem CAN-XL-Frame übertragbar.