Von vielen einzelnen Adern zu einem einzigen leichten Bussystem

CAN-Bus Basics: Geschichte & Technik

Seit Anfang der 80er Jahre stieg die Anzahl komplexerer Systeme und die Verwendung von Mikroprozessoren besonders im PKW-Bereich deutlich an. Diverse Komfort- und Sicherheitsfunktionen hielten zu dieser Zeit zuerst in Fahrzeugen der Oberklasse Einzug. Viele dieser Funktionen, wie etwa ABS oder auch On-Board Diagnosesysteme gehören heute zum technischen Standard. Um diese Funktionen zu ermöglichen, müssen verschiedene Bausteine wie Sensoren, Steuergeräte und Aktoren miteinander kommunizieren. Dazu werden vermehrt Datenleitungen verlegt sowie immer komplexere Architekturen entwickelt. Im Flugzeugbau wurde bereits deutlich früher an Bussystemen gearbeitet, die es ermöglichten, dass verschiedene Teilnehmer über wenige BUS-Leitungen kommunizieren. Somit konnte die Anzahl der Datenleitungen und somit das damit verbundene Gewicht deutlich gesenkt werden

Der CAN-Bus ist das vermutlich am weitesten verbreitete Bussystem in modernen Fahrzeugen. Wie in der Abbildung zu sehen wurden in den letzten drei bzw. vier Jahrzehnten weitere Bussysteme für Sonderaufgaben in Industrie und Automobil entwickelt.

Zirka 15 Jahre nach der Entwicklung des CAN-Bus wurde bereits an einer kostengünstigeren Variante in Form des LIN-Busses gearbeitet, welcher im Jahr 2002 eingeführt wurde. Der LIN-Bus (Local Interconnect Network) zeichnet sich durch seine Einfachheit und geringen Kosten aus. Er wird vor allem für weniger komplexe Anwendungen wie die Steuerung von Komfortsystemen (z. B. Fensterheber oder Sitzverstellungen) eingesetzt.

Mit der zunehmenden Komplexität von Fahrzeugen und dem Aufkommen von sicherheitskritischen Systemen wurde jedoch schnell klar, dass leistungsfähigere Bussysteme benötigt werden. FlexRay, eingeführt im Jahr 2006, wurde speziell für sicherheitsrelevante Anwendungen wie X-by-Wire-Systeme (z. B. brake by wire) entwickelt. FlexRay zeichnet sich durch eine hohe Übertragungsrate und deterministisches Verhalten aus, was eine zuverlässige Kommunikation in Echtzeit ermöglicht.

Im Jahr 2008 folgte der Einsatz von Automotive Ethernet, welches ursprünglich für Infotainment-Anwendungen verwendet wurde. Automotive Ethernet ermöglicht im Vergleich zu den vorherigen Systemen deutlich höhere Bandbreiten und spielt eine entscheidende Rolle für moderne Fahrzeugarchitekturen, insbesondere im Hinblick auf vernetztes und autonomes Fahren.

2012 wurde der CAN-FD (Flexible Data Rate) entwickelt und 2015 in die ISO 11898-1:2015 aufgenommen, was eine Weiterentwicklung des klassischen CAN-Bus darstellt. CAN-FD ermöglicht höhere Datenübertragungsraten und eine effizientere Kommunikation, um den steigenden Anforderungen durch moderne Steuergeräte gerecht zu werden.

Mit CAN-XL, einem zukünftigen Standard, wird derzeit an einer weiteren Optimierung des CAN-Bus gearbeitet. CAN-XL soll noch höhere Datenraten und zusätzliche Funktionen bieten, um den Anforderungen der nächsten Generation von Fahrzeugen gerecht zu werden.

Der „CAN“ wird aller Wahrscheinlichkeit nach trotz deutlicher Konkurrenz im Bereich der Bussysteme, besonders was Übertragungsraten angeht, die nächsten Jahrzehnte weiterhin der de-facto Standard in der Kommunikation zwischen einfachen Steuergeräten sein. Auch wenn viele Hersteller (in etwa VW und Tesla) vermehrt mit Zonal-Architektur arbeiten, die Highspeed-Verbindung zwischen Hauptsteuergeräten notwendig macht, ist davon auszugehen, dass einfache Steuergeräte, in etwa Fensterheber, weiterhin mit dem CAN-Bus umgesetzt wird. Selbst hochmoderne Fahrzeuge wie der ID.7,  das Tesla Model Y oder der Audi A5 verwendet diesen für Komfortfunktionen.

Datenübertragung mit dem CAN

Der CAN-Bus ist ein Netzwerk, das zur Kommunikation von Electronic Control Units (ECUs) dient. Aktuell kommt in der Praxis meist nur der klassische CAN und CAN FD zum Einsatz. Der Hauptunterschied ist dabei, dass unter anderem während der Übertragung der Payload die Bitrate erhöht wird, um eine achtmal größere Payload zu ermöglichen. Grundsätzlich besteht eine CAN-Nachricht oder ein Data Frame in jedem CAN-Netzwerk aus folgenden Teilen, vereinfacht von Bedeutung sind:
  • Arbitrierung-Feld: Neben dem Bit, das den Beginn eines Frames signalisiert, enthält dieser Teil den 11-Bit-langen Identifier (Extended Identifier 29-Bit) des Frames (auch als ID bezeichnet), der ein Data Frame in einem Cluster eindeutig identifiziert. Ohne Erweiterungen können somit 2048 verschiedene Identifier eingesetzt werden. Diese ID wird zur Arbitrierung verwendet, also als Priorität für das Versenden von Nachrichten. Je kleiner der Identifier, desto höher die Priorität der Nachricht. Außerdem kann hier ein Bit gesetzt werden, das eine Nachricht als RTR (Remote Transmission Request) anstelle eines Dataframes kennzeichnet.
  • Steuerfeld: Die Hauptaufgabe des Steuerfelds ist die Übertragung des Data Length Codes (DLC), also die Angabe der Länge der Nutzdaten.
  • Datenfeld / Payload: Das Datenfeld (0–8 Bytes) bzw. bei CAN-FD (0–64 Bytes) ist für die eigentliche Übertragung der Informationen zuständig. Die übertragenen Informationen können frei festgelegt werden.
  • CRC-Feld: CRC (Cyclic Redundancy Check) Bits werden genutzt, um festzustellen, ob eine Nachricht korrekt übertragen wurde.
  • Acknowledge-Feld: Hier bestätigt ein empfangender Knoten, dass er die Nachricht korrekt erhalten hat (dominantes Bit setzen).
  • EOF / IFS: EOF (End of Frame) kennzeichnet das Ende des Frames und besteht aus 7 rezessiven Bits. IFS (Interframe Space) ist die Wartezeit zwischen zwei Frames, in der der Bus frei bleibt, um Kollisionen zu vermeiden.
Die hier gezeigten Schritte sind vereinfacht und gehen nicht auf Schritte ein, die in Hardware oder Software von CAN-Transceivern umgesetzt sind. In der Praxis könnte die Übertragung einer Information mit dem CAN-Bus so aussehen: Der Kilometerstand eines Fahrzeugs wird über die CAN-Nachricht mit der ID 0x123 übertragen. Die Kodierung könnte wie folgt aussehen:
  • ID: 0x123 (Kilometerstand-Nachricht)
  • Datenfeld (8 Bytes): 00 00 1F 40 00 00 00 00
Hierbei könnten die Bytes 2 und 3 (in diesem Fall 1F 40 im Hexadezimalformat) den Kilometerstand in Kilometern repräsentieren. Um den tatsächlichen Wert zu berechnen, wird dieser hexadezimale Wert in eine Dezimalzahl umgewandelt: 1F4016 = 800010 (entspricht 8000 km) Oftmals kommt außerdem Multiplexing zum Einsatz, bei dem ein Teil der Nachricht wie ein weiterer Teil der ID fungiert. Beispielsweise könnte 00 im ersten Datenbyte den Kilometerstand, 01 die Außentemperatur und 02 den Tankfüllstand signalisieren:
  • ID: 0x123 (Kilometerstand-Nachricht)
  • Datenfeld (8 Bytes): 02 00 11 A8 00 00 00 00
Somit könnte der Tankstand übertragen werden: 11A816 = 452010 (entspricht 4520, oder 45,20 Liter) In diesem Fall müsste das Steuergerät je nach Wert des ersten Bytes das entsprechende Datenformat interpretieren. Somit sind selbst mit einer so vergleichweise einfachen Datenstuktur komplexe Übertragungen möglich. In der Praxis gestaltet sich die Verabeiterung solcher Daten für Fahrzeugumbauer oder andere IT fremde Gewerke als schwierig.

Deshalb speedsignal

Als eine der führenden Firmen im Bereich der Verarbeitung von CAN-Daten im europäischenn Raum bieten wir von der speedsignal GmbH deswegen Lösungen, die z.B. einfache Analogsignal ausgeben. Wir bieten über 25 Jahre Erfahrung in Soft- und Hardware in diesem Bereich, damit Sie sich auf ihr Kerngeschäft konzentrieren können. 

Die meisten Lösungen bieten wir steckerfertig in unserem Shop, speziellere Lösungen in etwa für Behörden erhalten Sie in Rücksprache mit unserem kompetenten und freundlichen Vertrieb

WordPress Cookie Hinweis von Real Cookie Banner