Controller Area Network (CAN) unterscheidet zwischen mehreren Formaten einer CAN-Nachricht zur Datenübertragung und Signalisierung von Zuständen. Im aktuellen Blog-Beitrag möchten wir eine Übersicht über die verschiedenen Nachrichtenformate, deren Zweck und Aufbau geben.
Bei CAN wird zwischen den folgenden vier Nachrichtenformaten unterschieden: Datentelegramm, Datenanforderungstelegramm, Fehlertelegramm und Überlasttelegramm.
Datentelegramm (Data Frame)
Das Datentelegramm ist das am häufigsten verwendete Nachrichtenformat im CAN-Netzwerk. Es dient der Übertragung von Nutzdaten von einem Sender zu einem oder mehreren Empfängern. Ein typisches Datentelegramm besteht aus mehreren Feldern:
- Start of Frame (SOF), ein dominantes Bit
- Arbitrierungsfeld (Arbitration Field), bestehend aus dem Identifier und einem RTR-Bit (Remote transmission request)
- Steuerungsfeld (Control Field), welches aus dem IDE-Bit (dominant für Standard-11-Bit-Identifier), einem reservierten Bit und dem Data Length Code besteht
- Datenfeld (Data field)
- Cyclic redundancy check (CRC)
- Acknowledgement slot (ACK)
- End of Frame (alle Bits rezessiv)
Das Arbitration Field bestimmt die Priorität der CAN-Nachricht, wobei niedrigere Werte höhere Priorität bedeuten. Das Data Field kann zwischen 0 und 8 Bytes an Daten enthalten, was eine flexible Datenübertragung ermöglicht.
Entsprechend der gültigen klassischen CAN-Spezifikation werden zwei unterschiedliche, miteinander kompatible Nachrichtenformate definiert, das sog. „Standard-Format“ mit 11-Bit-Identifier, sowie das „Extended Format“ mit 29-Bit-Identifier.
Das 29-Bit-Identifier-Format
Im Einsatz von Nutzfahrzeugen hat sich gezeigt, dass die große Anzahl der abzubildenden CAN-Nachrichten einen wesentlich längeren Identifier erfordert. Deshalb wurde neben dem 11-Bit-Identifier ein zusätzliches erweitertes Format mit einem 29-Bit-Identifier definiert. Basierend auf dem 29-Bit-Identifier sind bis zu 512 Mio. CAN-Nachrichten unterscheidbar.
Standard und erweitertes Format sind kompatibel zueinander, d.h. CAN-Nachrichten beider Formate können im gleichen Netzwerk existieren. Die Unterscheidung zwischen den beiden Formaten erfolgt mit Hilfe des “Identifier-Extension“-Bits (IDE-Bit). Im erweiterten Format ist der 29-Bit-Identifier in zwei Teile, nämlich den 11-Bit langen Basis-Identifier (Base-ID) sowie einen 18-Bit langen erweiterten Identifier (Extended-ID) aufgeteilt.
Datenanforderungstelegramm (Remote Frame)
Mit einem Datenanforderungstelegramm (Remote Frame) kann jeder Knoten das Senden einer bestimmten Nachricht bei einem für diese Nachricht zuständigen anderen Knoten anfordern. Die gewünschte CAN-Nachricht ist durch den mit dem Anforderungstelegramm übertragenen Identifier spezifiziert. Während die Anforderung einer bestimmten Nachricht von allen empfangenden Knoten aus möglich ist, darf es für die angeforderte CAN-Nachricht nur einen einzigen verantwortlichen Sendeknoten geben.
Das Nachrichtenformat eines Anforderungstelegramms entspricht dem des Datentelegramms, mit dem Unterschied, dass bei einem Anforderungstelegramm das RTR-Bit rezessiv, bei einem Datentelegramm dagegen dominant übertragen wird. Ein gleichzeitig mit einem Datentelegramm mit gleichem Identifier arbitrierendes Anforderungstelegramm verliert somit die Arbitrierung, da die angeforderte CAN-Nachricht ja bereits gesendet wird. Außerdem ist das Datenfeld leer. Der Datenlängencode im Datenanforderungstelegramm muss dem des entsprechenden Datentelegramms entsprechen.
Fehlertelegramm (Error Frame)
Jeder Netzknoten, der während des Sendens oder Empfangens eines Daten- oder Datenanforderungstelegramms einen Fehler erkennt, signalisiert dies umgehend an alle anderen Netzknoten durch Senden eines Fehlertelegramms (Error Frame). Da das Fehlertelegramm eine Bitsequenz von sechs Bits gleicher Polarität (Fehler-Flag) enthält, verletzt dieses (absichtlich) die Bit-Stuffing-Regel* und veranlasst somit den Sender, das fehlerhaft gesendete oder empfangene Telegramm nochmals zu senden.
Das Fehlertelegramm besteht aus zwei Feldern. Das erste Feld entsteht aus einer Überlagerung von Fehlerflags, aufgeschaltet durch einen oder mehrere Netzknoten. Mit dem zweiten Feld, einer Folge von 8 rezessiven Bits wird analog zum Daten- und Anforderungstelegramm das Telegrammende angezeigt.
*Bit-Stuffing bei CAN ist ein Verfahren, das dafür sorgt, dass die Datenübertragung synchron und fehlerfrei bleibt, indem es nach fünf aufeinanderfolgenden gleichen Bits automatisch ein entgegengesetztes Bit einfügt. Dies verhindert, dass lange Folgen gleicher Bits die Synchronisation der Netzwerkteilnehmer stören und erleichtert die Fehlererkennung.
Überlasttelegramm (Overload Frame)
Das Überlasttelegramm wird verwendet, um anzuzeigen, dass ein Knoten nicht bereit ist eine CAN-Nachricht zu empfangen. Dies kann aufgrund von internen Verzögerungen oder Pufferüberläufen auftreten. Das Überlasttelegramm gibt dem Knoten Zeit, um sich auf den Empfang der nächsten CAN-Nachricht vorzubereiten. Ein Überlasttelegramm kann als ein spezielles Fehlertelegramm aufgefasst werden und besteht wie dieses aus einem Flag (Overload Flag) sowie einem Endekennzeichen (Overload Delimiter).
Im Gegensatz zu einem Fehlertelegramm ist das Senden eines Overload Frames von ganz spezifischen, auf das Intermission-Feld bezogene Fehlerbedingungen abhängig und verursacht keine Wiederholung eines vorher gesendeten Daten- oder Datenanforderungstelegramms.
Zusammenfassung
Die vier Haupttypen von CAN-Nachrichtenformaten – Datentelegramm, Datenanforderungstelegramm, Fehlertelegramm und Überlasttelegramm – sind entscheidend für die Funktionalität und Zuverlässigkeit von CAN-Netzwerken. Jedes Format hat seine spezifischen Einsatzbereiche und Strukturen, die es ermöglichen, Daten effizient zu übertragen, Anfragen zu stellen, Fehler zu identifizieren und Überlastsituationen zu bewältigen.