CAN-FD-Light: Commander/Responder-Netzwerk als Alternative

CAN-FD, die zweite CAN-Protokoll-Generation, kommt schon seit zwei Jahren in den ersten Pkws zum Einsatz, wobei die Fahrzeughersteller vor allem von dem längeren Datenfeld profitieren. Nun sind auch die Entwickler von tief eingebetteten Netzwerken an CAN-FD interessiert; allerdings benötigen sie keine Busarbitrierung, da in solchen Anwendungen immer nur ein Knoten (Commander) die Kommunikations-Initiative hat. Deshalb entwickelten CiA-Mitglieder (CiA: CAN in Automation) CAN-FD-Light. Knoten, die diese Spezifikation erfüllen, dürfen nur auf Aufforderung durch den Commander CAN-FD-Frames senden. CAN-FD-Light ist unter anderem für „intelligente“ Scheinwerfer sowie zur Vernetzung von Batteriezellen geeignet.

Der Wunsch nach solchen Commander-Responder-Kommunikationsstrukturen gibt es schon seit Anfang der 90er Jahre. Bereits 1993 wurde das SLIO-Konzept (Serial Link Input Output) für CAN entwickelt. Es war sozusagen eine Erweiterung der lokalen Ressourcen eines CAN-Knotens, aber kommerziell nicht erfolgreich. Einige Jahre später wurde LIN (Local Interconnect Network) entwickelt. Es ist inzwischen in der Normenreihe ISO 17987 international genormt. Für einige tief eingebettete Netzwerke ist die von LIN zur Verfügung gestellte Busbandbreite und die Länge der Rahmentelegramme (Frames) nicht ausreichend. Ein weiteres Commander-Responder-Netzwerk ist CXPI (Clock Extension Peripheral Interface), welches in der Normenreihe ISO 20794 spezifiziert ist. Es ist allerdings nur in Japan etabliert.

Zu den Commander-Responder-Netzwerk-Anwendungen, denen die Leistungsmerkmale der bisherigen Netzwerke nicht ausreichen, zählen beispielsweise LED-Scheinwerfer, Batterien mit vielen Zellen und Klimasteuerungen mit vielen Sensoren. Deshalb begannen Mitglieder der internationalen CAN-Anwendervereinigung CiA auf Basis der zweiten CAN-Protokoll-Generation eine Commander-Responder-Lösung zu entwickeln. Im September 2021 veröffentlichte der eingetragene Verein die CAN-FD-Light-Spezifikation (CiA 604-1). Das „Light“ im Namen soll an die erste Anwendungsidee (Rückscheinwerfer) erinnern und gleichzeitig auf den reduzierten Implementierungsaufwand in den Respondern hinweisen.

Seit 2015 ist das CAN-FD-Protokoll in ISO 11898-1 international genormt. Eine der wichtigen Unterschiede zum klassischen CAN-Protokoll ist das Datenfeld mit bis zu 64 Byte. Eine weitere ist die Verwendung von zwei Datenraten, die allerdings bei CAN-FD-Light nicht genutzt wird. Das CAN-FD-Protokoll verfügt im Gegensatz zu dem klassischen CAN-Protokoll über mehrere von der Datenlänge abhängige CRC-Polynome, die die Datenübertragung absichern. Das CAN-FD-Protokoll kann alle 1-Bit-Fehler erkennen und mit einer sehr hohen Wahrscheinlichkeit auch mehrere Bitfehler in einem Rahmentelegramm entdecken. Dazu wurden zusätzliche Maßnahmen implementiert: Stuff-Bit-Zähler und feste Stuff-Bits in der Datenphase. Stuff-Bits sind vom Sender eingefügte Bits, die von den Empfängern wieder entfernt werden. Sie dienen neben der CRC-Prüfung zur Erkennung von Bitfehlern.

Das CAN-FD-Protokoll ist die Basis für den Commander. Er sendet seine Rahmentelegramme entsprechend dem in ISO 11898-1 spezifiziertem Datenverbindungsprotokoll. Er verwendet nur eine Bitrate von maximal 1 Mbit/s. Der Commander-Knoten überprüft das gesendete Rahmentelegramm und würde bei Erkennung eines Fehlers die Übertragung mit dem Senden eines Fehler-Telegramms abbrechen.

Die Responder-Knoten verstehen das CAN-FD-Protokoll, aber sie können keine Übertragung von Rahmentelegrammen initiieren. Sie können nur auf empfangene Rahmentelegramme des Commanders reagieren. Selbstverständlich wartet der Commander, wenn er eine Information vom Responder erwartet, bis er das nächste Rahmentelegramm sendet. So ist gewährleistet, dass immer nur ein Knoten im CAN-FD-Light-Netzwerk sendet. Die gesamte Netzwerksteuerung obliegt also dem Commander-Knoten. Das hat den Vorteil, dass die Responder nicht mit anderen Knoten um den Buszugriff „streiten“ müssen, wie es bei CAN normalerweise üblich ist. Andererseits benötigen Responder-Knoten dadurch keinen zusätzlichen Taktgeber (z. B. Oszillator), was die Kosten für externe Bauelemente senkt. Die Synchronisation auf den Sender erfolgt mit dem Start-of-Frame-Bit des Datenframes.

Die Responder-Knoten prüfen zwar die Korrektheit des empfangenen Rahmentelegramms. Im Fehlerfall verwerfen sie die empfangene Information und verarbeiten sie nicht. Sie senden keine Fehlertelegramme (Error Frame). Das Fehlerhandling erfolgt in der Anwendung. Ein Responder-Knoten benötigt nicht unbedingt einen Mikrokontroller. Seine Logik kann auch nur hardwaremäßig (fest) verdrahtet sein. Dies reicht beispielsweise für LED-Treiberschaltungen und einfache Sensoren sowie Aktuatoren.

Die Kosten für ein CAN-FD-Light-Netzwerk sind erheblich niedriger als für ein CAN-FD-Netzwerk. Der Datendurchsatz von 1 Mbit/s bei 64 Byte pro Datenframe sowie die Zuverlässigkeit sind aber vergleichbar. Für die Anwender ist die internationale Normung von Kommunikationssystemen wichtig, damit man am Markt von verschiedenen Herstellern die Produkte erwerben kann. Deshalb wurde von Beginn an CAN-FD-Light im Rahmen einer nicht-gewinn-orientierten Organisation entwickelt. CiA fördert seit 30 Jahren die Entwicklung und Verbreitung von CAN – zuerst mit dem Ziel industrieller Anwendungen, doch seit vielen Jahren eigentlich für alle Anwendungen einschließlich der Automobilindustrie. Schon bei der Entwicklung von CAN-FD organisierte der CAN-Verein sogenannte Plugfests, bei denen die ersten CAN-FD-Implementierungen auf Interoperabilität geprüft wurden. Diese Plugfests fanden in Europa und in den USA bei General Motors und Ford statt.

Auch für CAN-FD-Light sind Plugfests geplant; der CiA wartet nur noch auf eine genügende Anzahl von Implementierungen. Neben ST-Microelectronics wird demnächst auch Texas Instruments das vereinfachte CAN-FD-Protokoll in seinen Produkten anbieten. Das Interesse ist derzeit nach Aussagen der Halbleiterhersteller groß. Neben Anbietern von Fahrzeugbeleuchtungen wollen auch Batteriefirmen und Lieferanten von Klimaanlagen das preisgünstige und trotzdem zuverlässige CAN-FD-Light-Protokoll zukünftig nutzen.

Die nächste Generation von Rückleuchten wird je nach Fahrzeugsituation dynamische Lichtszenarien (zum Beispiel bei Gefahr) zur Verfügung stellen. Sie werden auch als Gestaltungselement genutzt werden. Bei diesen komplexen Beleuchtungssystemen liegen die LED-Treiber räumlich oft nicht eng beieinander, so dass ein tief eingebettetes Netzwerk notwendig ist. Ähnliches gilt auch für größere Batteriesysteme und Klimaanlagen. Zusätzlich ist CAN-FD-Light in kommerziellen Fahrzeugen – einschließlich Landmaschinen und Baumaschinen – ein geeignetes Kommunikationssystem, zumal die Komponenten (Controller und Transceiver) für einen erweiterten Temperaturbereich spezifiziert sind.

CAN-FD-Light-Netzwerke lassen sich nahtlos als tief eingebettete Netzwerke in bestehende Kommunikationsarchitekturen integrieren. Dies gilt für die Patchwork-Netzwerke der 90er Jahre genauso wie für Domain-orientierte Ansätze und moderne Zonen-Architekturen. Bei den Patchworks wurde immer noch ein Netzwerk hinzugefügt. Wenn die Software unübersichtlich wurde, ging man zu einer strukturierten Netzwerk-Architektur nach Anwendungen (Domain) über. Doch dies hat den Nachteil, dass eventuell viele Netzwerkleitungen kreuz und quer durch das Fahrzeug gezogen werden müssen. Dies ist aber wegen des Gewichtes von Leitungen unerwünscht. Deshalb denkt man über ein breitbandiges Backbone-Netzwerk (Ethernet) nach, an dem eventuell Sub-Backbone-Netzwerke (z. B. CAN-FD oder CAN-XL) angeschlossen sind, die wiederum mit tief eingebetteten Netzwerken verbunden sind. CAN-FD-Light-Netzwerke sind also sowohl in Domain- als auch in Zonen-Architekturen, die auf CAN-FD oder CAN-XL basieren, sehr einfach zu integrieren.

Um die Forderung der Fahrzeughersteller nach internationaler Normung zu erfüllen, hat der CiA die CAN-FD-Light-Spezifikation (CiA 604-1) bereits zur Integration als normativen Anhang in ISO 11898-1 eingereicht. Gleichzeitig wurde auch das CAN-XL-Protokoll (CiA 610-1) zur Normung an die ISO gegeben. Für die physikalische Übertragung kann man die in ISO 11898-2-spezifizierten Transceiver verwenden. Die handelsüblichen High-Speed-Transceiver reichen in der Regel für Bustopologien aus. Bei hybriden Topologien mit Bus- und Sternanteilen können die SIC-Transceiver (Signal Improvement Capability) zum Einsatz kommen. Sie sind in CiA 601-4 spezifiziert und wurden ebenfalls zur internationalen Standardisierung (ISO 11898-2) eingereicht.