Frameformate der Nachrichten

Image: CAN Message Format
Nachrichtenframe für das Standard-Format (CAN Spezifikation 2.0A)

Das CAN Protokoll bietet zwei Nachrichtenframeformate, die sich hauptsächlich in der Länge des Identifiers (ID) unterscheiden. Beim Standard-Format beträgt die ID-Länge 11 Bits und beim Extended-Format beträgt die ID-Länge 29 Bits. Die Nachrichtenframes zur Übertragung der Nachrichten auf den Bus besteht aus sieben Hauptfeldern.

Eine Nachricht im Standard-Format beginnt mit dem Start-Bit “Start of Frame”, gefolgt vom “Arbitration Field”, das den Identifier und ein “RTR”-Bit enthält (Remote Transmission Request). Dieses Bit zeigt an, ob die Nachricht einen Datenframe enthält oder ob es ein Anfrageframe ohne Daten ist (Remote Frame). Das “Control Field” enhält das “IDE” (Identifier Extension) Bit, das festlegt ob es sich um ein Standard- oder ein Extended-Format handelt. Außerdem existiert noch ein Bit für zukünftige Erweiterungen (momentan unbenutzt) und in den letzten 4 Bits ein Zähler für die im “Data Field” enthaltenen Datenbytes. Das “Data Field” kann von 0 bis 8 Bytes enthalten und wird gefolgt vom “CRC field”, das benutzt wird um einen Sicherheitscheck durchzuführen, ob alle Daten korrekt sind und keine Bit-Fehler enthalten sind. Das “ACK Field” stellt den “ACK slot” dar (1 Bit) sowie den “ACK delimiter” (1 rezessives Bit). Das Bit im “ACK slot” wird als rezessives Bit versandt und somit von Knoten, die die Daten korrekt erhalten haben mit einem dominanten Bit überschrieben (Positive Bestätigung (Acknowledge)). Korrekte Nachrichten werden durch die Empfänger bestätigt, egal ob der Akzeptanztest erfolgreich war oder nicht. Das Ende der Nachricht wird durch das “End of Frame” eingeleitet. “Intermission” ist die minimale Bitperiode, die aufeinanderfolgende Nachrichten trennt. Wenn es keine folgenden Nachrichten gibt verbleibt der Bus in einem Idle Status (“bus idle”).

Feststellung und Meldung von Fehlern

Anders als andere Bussysteme benutzt das CAN Protokoll keine Bestätigungsnachrichten für Erfolg, sondern meldet nur alle auftretenden Fehler. Fur die Fehlererkennung kennt das CAN Protokoll drei Mechanismen auf Nachrichtenebene:

Cyclic Redundancy Check (CRC)

Der CRC sichert die Frameinhalte durch das Hinzufügen von redundanten Check Bits an das Frameende. Der Empfänger errechnet den Inhalt dieser Bits ebenfalls und vergleicht sein Ergebnis mit dem angehängten Wert. Stimmen diese nicht überein, wird ein CRC-Fehler gemeldet.

Frame check

Dieser Mechanismus überprüft die Struktur des übermittelten Frames, indem er die Bitfelder auf das festgelegte Format und den Gesamtframe auf seine Größe prüft. Fehler beim Frame check werden als Format-Fehler gemeldet.

ACK errors

Wie oben bereits beschrieben werden Frames von allen Empfängern positiv bestätigt. Sollte keine Bestätigung beim Sender eingehen (ACK error) ist eventuell ein nur durch die Empfänger erkannter Fehler aufgetreten. (ACK-Feld fehlerhaft, keine Empfänger vorhanden)

Das CAN Protokoll unterstützt auch zwei Mechanismen um auf Bitebene Fehler zu erkennen:

Monitoring

Die Möglichkeit des Senders Fehler zu erkennen basiert auf der Überwachung des Bussignals. Jeder Knoten, der Daten übermittelt, überwacht auch den Buslevel und kann Unterschiede zwischen dem angelegten Bit und dem tatsächlich auf dem Bus befindlichen Bit feststellen. Dies ermöglicht eine zuverlässige Fehlererkennung, sowohl global im Netz, als auch lokal beim Sender.

Bit stuffing

Die Kodierung der einzelnen Bits wird auf Bitebene überprüft. Die Bits im CAN Protokoll werden in der NRZ-Kodierung repräsentiert (Non-Return-to-Zero), was eine maximimale Effezienz garantiert. Die Synchronisationskanten werden über das Bit stuffing generiert, z.B. wird nach 5 Bits gleichen Levels vom Sender ein stuff Bit eingefügt, das den entgegengesetzten Wert enthält. Dieses Bit wird vom Empfänger beim Dekodieren wieder entfernt. Die Überprüfung der Kodierung ist nur von den festgelegten Stuffing Regeln abhängig.

Wenn eine oder mehrere Fehler von mindestens einer Station, mit obigen Regeln, festgestellt wurden, wird die laufende Übertragung abgebrochen und ein “Error Flag” gesendet. Dieses Error Flag verhindert, dass ein Empfänger die Nachricht als korrekt annimmt und verarbeitet und dies wiederum stellt die Datenkonsistenz im ganzen Netzwerk sicher.

Nach Abbruch der Übermittlung einer fehlerhaften Nachricht nimmt der Sender die Übermittlung erneut auf (Automatische Wiederholung). Natürlich findet dann erneut eine prioritätsprüfung anhand des Identifiers statt, damit auch andere Nachrichten hoherer Priorität gesendet werden können. Der erneute übermittlungsversuch wird innerhalb von 23 Bit-Zeiten nach der Fehlerfeststellung eingeleitet. In speziellen Fällen kann es zu 31 Bit-Zeiten kommen, wenn eine Systemwiederherstellung nötig war.

Egal wie effektiv und effizient eine Methode auch ist, es kann immer vorkommen, dass ein fehlerhafter Knoten den Abbruch jeglicher Übermittlungsversuche verursacht ( einschließlich Korrekter ) und so eine Blockierung des Gesamtsystems herbeiführt. Daher sollten permanent Messungen und Selbsttests ausgeführt werden, um solche Sitationen abzufangen. Das CAN Protokoll verfügt über Mechanismen um sporadische Fehler von permanenten Fehlern zu unterscheiden, sowie Fehler auf lokaler Ebene lokal zu behandeln (fault confinement).

Dies geschieht über die statistische Analyse von Fehlersituationen um lokale Fehler zu erkennen und möglicherweise durch den Wechsel in einen Status, der das restliche Netz nicht mehr negativ beeinflusst. Dies kann bis zur Selbstabschaltung der Station führen, um den Abbruch von korrekten Nachrichten, die als falsch erkannt wurden, am Bus zu verhindern.

Erweitertes CAN Nachrichtenformat

Das SAE “Truck und Bus” Unterkommitee hat Signale und Nachrichten, sowie Datenübermittlungsprotokolle für eine Vielzahl von Übertragungsraten standardisiert. Bei diesem Vorgang wurde es offensichtlich, dass eine Standardisierung einfacher festzulegen ist, wenn ein längeres ID-Feld vorhanden ist.

Um diesen Beobachtungen Folge zu leisten, wurde das CAN Protokoll um den 29-Bit Identifier erweitert. Dieser Identifier resultiert aus dem bereits vorhandenen 11-Bit Identifier (Basis-ID) und einer 18-Bit Erweiterung (ID-Erweiterung). Somit wird die Nutzung von zwei verschiedenen Nachrichtenformaten im CAN Protokoll möglich:

  • StandardCAN ( Version 2.0A ) und
  • ExtendedCAN ( Version 2.0B )

Da die Formate gleichzeitig auf einem Bus vorkommen können, muss festgelegt werden, welche Nachricht die höhere Priorität bei gleichzeitigem Buszugriff und identischem Basis-Identifier hat.

Also wurde festgelegt, dass eine Nachricht im StandardCAN Format immer Vorrang vor einer im ExtendedCAN Format hat!
CAN Frame standard format (CAN Spezifikation 2.0A)

CAN Controller, die das ExtendedCAN Format unterstützen müssen also auch Nachrichten im StandardCAN Format senden und empfangen können. CAN Controller, die aber nur das StandardCAN Format unterstützen, würden Nachrichten im ExtendedCAN Format falsch interpretieren und daher wird der gemischte Einsatz nicht empfohlen. Für den gemischten Einsatz existieren aber auch CAN Controller, die neben dem StandardCAN Format das ExtendedCAN Format erkennen können, diese Nachrichten dann aber ignorieren und verwerfen (Version 2.0B passive).

Eine Unterscheidung zwischen den beiden Formaten wird über das IDE (Identifier Extension Bit) gemacht. Beim ExtendedCAN Format ist das Bit rezessiv.

Das RTR-Bit wird dominant oder rezessiv übermittelt, je nachdem ob ein Datenteil transportiert wird, oder ob eine spezielle Nachricht bei einem entfernten Empfänger angefragt werden soll. Beim ExtendedCAN Format wird anstatt des RTR-Bit ein SRR-Bit (substitute remote request) übermittelt. Das SRR-Bit wird immer rezessiv übermittelt, damit ein StandardCAN Frame immer die höhere Priorität bei gleicher Basis-ID hat.

Erweitertes CAN Nachrichtenformat (CAN Spezifikation 2.0B)

Beim ExtendedCAN Format folgt dem IDE-Bit die 18-Bit ID-Extension, das RTR-Bit und abschließend noch ein reserviertes Bit (r1).

Alle darauf folgenden Felder sind mit dem StandardCAN Format identisch. Die Konformität der beiden Formate wird durch die Tatsache sichergestellt, dass CAN Controller, die ExtendedCAN Formate verstehen, auch StandardCAN Formate verarbeiten können.

Implementierung des CAN Protokolls

Die Kommunikation ist für alle Implementierungen des CAN Protokolls identisch. Es gibt natürlich Unterschiede in der Implementierung der reinen Übermittlung der Nachricht, die außerhalb des Mikrocontrollers durch den CAN Chip stattfindet.