Kommunikationssysteme Warum CAN XL eine Systemlösung ist

CAN XL bietet eine Lösung für Datenraten bis 20 Mbit/s, wobei die Vorteile des CAN-Protokolls wie die Kollisionsauflösung durch zerstörungsfreie Arbitrierung beibehalten werden. Bei der Bitrate schließt CAN XL die Lücke zwischen CAN FD und 100BASE-T1 (Ethernet). Ein Überblick zum Stand der Technik.

Ursprünglich spezifizierte CAN (controller area network) nur Datenrahmen (frames) und zugehörige Datenverbindungs-Protokolle (data link layer), auch als Layer-2 bezeichnet. Dann kamen PMA-Bauelemente (physical medium attachment) hinzu, die landläufig als CAN-Transceiver verkauft werden. Auch die zweite CAN-Protokoll-Generation, CAN FD (flexible datarate), standardisierte im Wesentlichen die beiden unteren OSI-Schichten (Open Systems Interconnection). Erst mit der dritten Generation, CAN XL (extended data-field length) wurde eine genormte Systemlösung angestrebt, bei der auch ein Layer-Management für höhere OSI-Schichten standardisiert wurde.

Untere OSI-Schichten

Die drei CAN-Protokoll-Generationen (CAN CC (classic), CAN FD und CAN XL) sind in der ISO-Norm 11898-1 (3. Edition von 2025) standardisiert. Genau genommen sind in dieser Norm nicht nur Frame-Formate und zugehörige Protokolle spezifiziert, sondern auch der „Physical Coding Sublayer“ (PCS), der formal zur untersten Schicht (physical layer) des OSI-Modells gehört.

CAN-XL-Controller beherrschen alle drei Protokoll-Generationen und können sogar mit CAN-FD-Controllern im gleichen Netzwerk betrieben werden. Reine CAN-CC-Controller reagieren auf CAN-FD- und CAN-XL-Frames mit einem Error-Frame (Fehlerrahmen). Einer der wesentlichen Unterschiede der Protokoll-Generationen liegt in der Länge des Datenfeldes: bis zu 8 Byte (CAN CC), bis zu 64 Byte (CAN FD) und bis zu 2048 Byte (CAN XL).

In der ISO-Norm ISO 11898-2 (4. Edition von 2026) sind CAN-bezogene PMA-Sublayer standardisiert. Dazu gehören CAN HS (high-speed), CAN FD, CAN SIC (signal improvement capability) und CAN SIC XL. Im Prinzip kann man diese in Transceiver-Chips implementierten PMA-Sublayer mit Einschränkungen für alle CAN-Protokolle einsetzen. Mit CAN HS bezeichnet man die klassischen CAN-Transceiver, die Bitraten bis zu 1 Mbit/s ermöglichen. CAN-FD-Transceiver sind für Bitraten bis zu 2 Mbit/s bzw. bis zu 5 Mbit/s (Punkt-zu-Punkt-Verbindung) geeignet.

SIC-Transceiver unterdrücken das „Klingeln“ auf den Busleitungen; mit ihnen sind Bitraten bis zu 8 Mbit/s möglich (abhängig von der Netzwerk-Topologie und den verwendeten Kabeln und Steckverbindern). Die CAN-SIC-XL-Transceiver unterstützen den in CAN-XL-Controllern optional konfigurierbaren FAST-Mode. In diesem Mode sind Bitraten bis zu 20 Mbit/s erreichbar. Alle Transceiver-Arten nutzen eine differentielle Zweidraht-Übertragung mit gemeinsamem „Ground“ sowie eine NRZ-Codierung (non-return-to-zero) in Arbitrierungsphase. Da die CAN-Transceiver keine komplexen Kodierungsverfahren verwenden, ist ihre Komplexität gering und kostengünstig. Zusätzlich sind in ISO 11898-2 auch optionale Funktionen wie „Low-Power-Mode“ und „Selective-Wake-up“ (partial networking) genormt.

„Eingebettete“ Layer-Management Funktionen

Eine der wesentlichen Neuerungen in CAN XL ist das „Einbetten“ von Layer-Management-Daten in den CAN-XL-Datenrahmen. Das 8-Bit-Feld „SDT (service data unit type)“ enthält Informationen über die verwendeten höheren OSI-Schichten (ab dem Netzwerk-Layer). Die internationale Anwender- und Herstellervereinigung CiA (CAN in Automation) e. V. teilt die entsprechenden SDT-Werte zu. Diese sind in dem Dokument CiA 611-1 festgelegt. Es enthält auch Werte für das „Mappen“ bzw. das „Tunneln“ von Ethernet-Frames. CAN-XL-Frames können über Ethernet „getunnelt“ werden (IEEE 1722). Somit kann man heterogene Netzwerk-Architekturen mit CAN-XL- und Ethernet-Segmenten realisieren.

Das 8-Bit-VCID-Feld (virtual CAN network ID) enthält eine eindeutige Netzwerk-ID für komplexe Netzwerk-Architekturen, die aus mehreren Netzwerk-Segmenten bestehen. Dabei können die Segmente hierarchisch oder „vermascht“ angeordnet sein. Eine Standardisierung der VCID-Werte ist in offenen Netzwerk-Systemen nur notwendig, wenn man eine „automatische“ (off-the-shelf) Interoperabilität der einzelnen Netzwerk-Segmente erreichen möchte.

Ein typisches Beispiel für eine standardisierte Netzwerk-Architektur sind Nutzfahrzeuge mit verschiedenen „offenen“ Teilnetzwerken (z. B. Anhänger-Verbindungen, Aufbau-Netzwerk und ePTO-Bussystem). Wenn zwischen diesen Netzwerk-Segmenten Daten ausgetauscht werden sollen, ist eine Standardisierung von VCIDs sinnvoll, damit die übertragenen Parameter automatisch (auch ohne Konfiguration von Gateways) „richtig“ interpretiert werden. Solch eine standardisierte Zuteilung von VCIDs für bestimmte Anwendungen (z. B. Fahrzeuggespanne, landwirtschaftliche Fahrzeuge oder Baumaschinen) gibt es noch nicht.

Höhere OSI-Schichten

Zwar kann die CAN-XL-Lösung für Security, das kürzlich herausgegebene CANsec-Protokoll (CiA 613-2), auch in Hardware implementiert werden, aber trotzdem ist es eigentlich ein „höheres“ OSI-Protokoll. Es basiert auf MACsec mit entsprechenden Erweiterungen. Es wird also eine bewährte Security-Lösung verwendet.

Ein „echtes“ höheres Protokoll ist die in ISO 15765-2 spezifizierte Network/Transport-Schicht. Mit Hilfe dieser Protokollschicht kann man Nachrichten größer als die maximale Payload des unterlagerten CAN-Protokolls (8 Byte oder 64 Byte oder 2.048) auf der Senderseite segmentieren und beim Empfänger wieder zusammenbauen. Diese Norm ist allerdings bezüglich CAN XL noch in Entwicklung (entsprechende Protokolle für CAN CC und CAN FD sind schon seit vielen Jahren genormt).

Fertig ist dagegen das Multi-PDU-Protokoll (CiA 611-2). Dieses höhere Protokoll ermöglicht das „Mappen“ von homogenen (gleiches Application-Layer-Protokoll) oder heterogen (unterschiedliche Protokolle, z. B. CANopen und J1939) Nachrichten (messages) in einen CAN-XL-Datenrahmen. In einigen Spezifikationen werden die Application-Layer-Messages auch PDU (protocol data unit) genannt. Interessant ist das Multi-PDU-Protokoll für Steuergeräte mit mehreren Ports für unterlagerte CAN-Netzwerke.

Im Prinzip kann man schon jetzt CANopen-FD-Dienste auf CAN-XL-Frames abbilden. Die noch notwendigen (marginalen) Erweiterungen in der Spezifikation CiA 1301 (CANopen FD) werden aber erst eingefügt, wenn ein entsprechender Bedarf vorhanden ist. Noch sind nämlich keine industriellen Mikrocontroller mit CAN-XL-Schnittstellen verfügbar. Auch die auf 1939 basierenden Anwendungsschichten unterstützen derzeit keine Abbildung auf CAN XL.

Verfügbarkeit von CAN-XL-Produkten

Selbstverständlich müssen nicht nur Normen und Spezifikationen zur Verfügung stehen, sondern auch Produkte (möglichst von mehreren Anbietern) um ein „offenes“ Kommunikationssystem verwenden zu können. CAN-XL-Cores, die man in Halbleiter integrieren kann, gibt es schon seit einigen Jahren von mehreren Firmen (z. B. Arasan, Bosch, DCD-Semi, Fraunhofer/Cast, HMS/Peak).

Einige Halbleiter-Hersteller haben diese IP-Cores (intellectual property) schon in ihre Mikrocontroller integriert (z. B. Infineon, NXP, Renesas und ST-Microelectronics). Es gibt auch erste Prototypen herstellerspezifischer integrierter Schaltungen, die CAN-XL-IP-Cores integrieren. Sie werden tiefeingebettet in speziellen Geräten eingesetzt. CAN-SIC-XL-Transceiver haben bereits den Prototypen-Status verlassen.

Schon zu einem frühen Zeitpunkt hatten Oszilloskop-Hersteller CAN-XL-Protokoll-Interpreter zur Verfügung gestellt. Auch dedizierte CAN-XL-Bus-Analysatoren sind schon am Markt erhältlich, waren schon bei den ersten CiA-CAN-XL-Plugfests im Einsatz. In diesen Plugfests wurde die Interoperabilität von ersten CAN-XL-Implementierungen getestet. CiA plant ein weiteres Plugfest, in dem die Interoperabilität von CANsec-Implementierungen geprüft werden soll.

Erste CAN-XL-Interface-Boards auf Basis von FPGAs (field-programmable gate arrays) und dedizierten Protokoll-Controllern sind ebenfalls von mehreren Firmen erhältlich (z. B. c&s group, esd electronics, Etas, HMS/Peak, Microsys, Vector, Tosun). Module von Etas und Microsys eignen sich auch zur Prototypen-Entwicklung von Steuergeräten (electronic control units).

Inzwischen haben HMS/Peak (PCAN Developer 5), Tosun (TSmaster) und Vector (CANoe) ihre CAN-Software-Werkzeuge für CAN-XL-Anwendungen erweitert. Auch der „open-source“ Linux-Treiber (SocketCAN) und zugehörige Linux-Utilities sind bereits verfügbar. Dr. Oliver Hartkopp, ein ehemaliger VW-Mitarbeiter, ist die treibende Kraft hinter diesen Linux-Projekten. Er unterstützt auch das Github-Projekt für die Validierung von Implementierungen des CAN-XL-Transport-Protokolls (ISO 15765-2).

Was noch fehlt!

Die Normen für die Konformitätstestpläne der CAN-XL-Protokoll-Controller (ISO 16845-1) und der CAN-SIC-XL-Transceiver (ISO 16845-2) sind noch in der Abstimmungsphase. Die Veröffentlichung wird in den nächsten Monaten erwartet. Die Prüfung der Konformität von Halbleitern mit den Anforderungen in ISO 11898-1 beziehungsweise ISO 11898-2 garantiert allerdings nicht die Interoperabilität verschiedener Implementierung. Sie erhöht aber die Wahrscheinlichkeit, dass die Implementierungen in einem CAN-XL-Netzwerk fehlerfrei kommunizieren können. Die Interoperabilität von Produkten lässt sich nur in einem Systemtest (z. B. Plugfests) feststellen.

Das CAN-XL-Ecosystem ist also schon ziemlich komplett. Es fehlen jedoch noch Design-Richtlinien und Anwendungshinweise für Hersteller und Anwender. CiA-Mitglieder arbeiten an solchen Dokumenten: CiA 612-1 (Empfehlungen für das CAN-XL-Systemdesign), CiA 612-2 (Richtlinie für die Pulse-Width-Modulation-Codierung), CiA 612-3 (Anwendungshinweise für das Einstellen der Arbitrierungs-Bitrate). CiA 612-4 (Richtlinie für die Zeitsynchronisierung), CiA 612-5 (Augendiagramm-Definitionen für CAN-SIC-XL-Symbole) und CiA 612-6 (Richtlinie für Verzögerungen intern im Steuergerät). Einige dieser Richtlinien und Empfehlungen sollen noch vor dem Jahresende veröffentlicht werden.

CiA-Mitglieder haben auf Initiative von Volkswagen ein Simulation-Modell für PMA-Implementierungen (sprich: CAN-SIC-XL-Transceiver) spezifiziert (CiA 910-1 und CiA 910-2). Diese Dokumente befinden sich derzeit in Überarbeitung. Die Standardisierung des CAN-SIC-XL-Modell ermöglicht es, die Simulationsergebnisse unterschiedlicher Implementierungen zu vergleichen. Solche Simulatoren werden von Fahrzeugherstellern oder unabhängigen Testhäusern entwickelt. Derzeit gibt es erste Prototypen-Implementierungen. (kr)

(ID:50991321)