Nachrichtenformat und Fehlererkennung

Das CAN-Protokoll unterscheidet vier verschiedene Typen von Botschaften, welche vom Zweck des Versandes abhängen. Auf die drei Haupttypen, die auch CAN-Telegramme genannte werden, geht dieser Beitrag genauer ein. Auch die zusätzliche Unterscheidung des CAN-Protokolls, in zwei grundsätzliche Nachrichtenformate, wird in aller Ausführlichkeit betrachtet.

Weiterhin werden Mechanismen zur Erkennung von fehlerhaften Nachrichten vorgestellt, die dabei helfen, gestörte oder verfälschte Botschaften im CAN-System frühzeitig ausfindig zu machen. Diese fünf Mechanismen sorgen für eine sofortige Beseitigung des Fehlers und damit für eine netzweite Datenkonsistenz.

CAN-Telegrammtypen

Im CAN-System gibt es vier verschiedene Telegrammtypen, wobei das Überlasttelegramm hier nicht weiter betrachtet wird. Die verbliebenen drei Haupttypen unterscheiden sich je nach dem Versandzweck der Nachricht und sind im Folgenden dargestellt:

  • Datentelegramm:
    Auf Initiative des Senders werden die Daten an einen oder mehrere Empfänger gesendet.
  • Datenanforderungstelegramm:
    Die Botschaft wird auf Initiative des Empfängers gesendet, nachdem diese durch einen Busteilnehmer angefordert wurde.
  • Fehlertelegramm:
    Entweder Sender oder Empfänger signalisieren durch dieses Telegramm einen Fehler.

Wenn ein Telegramm über den CAN-Bus versendet werden soll, ist es wichtig, zu erkennen, ob es sich um ein Datenpaket, eine Anforderung oder eine Fehlermeldung handelt. Aus diesem Grund unterscheiden sich die einzelnen Telegrammtypen, die auch als Rahmentypen bezeichnet werden, in ihren Bit-Feldern. Das Rahmenformat schreibt vor, welche Bit-Felder in dem Telegramm enthalten sind und welche Felder rezessiv oder dominant belegt werden.

Aufbau der CAN–Nachrichtenformate

Neben den Telegrammtypen sind zwei verschiedene Nachrichtenformate im CAN-Protokoll festgelegt, welche sich durch die Größe des Adressraumes abgrenzen. Eines ist ein Standard-Format mit einem 11-Bit-Identifier und das zweite ein Extended-Format mit einem 29-Bit-Identifier.

Der Aufbau der Botschaft wird durch insgesamt elf Felder strukturiert, wobei sich zwischen den Nachrichtenformaten nur das zweite Feld mit dem Identifier unterscheidet. Zum besseren Verständnis wird der Botschaftsaufbau in der zeitlichen Abfolge einer Sequenz, kurz dargestellt:

  1. Feld A – Start of Frame: Beinhaltet den Start of Frame (SOF) bzw. Botschaftsbeginn, welche für die Anfangserkennung des Telegrammbeginns und die erste Synchronisation verantwortlich ist. Sie besteht aus einem dominanten Pegel mit einem Bit.
  2. Feld B - Identifier: Enthält den Identifier (ID), welcher die eindeutige Priorität der Nachricht kennzeichnet. Je nach Standard- oder Extended-Format hat der Identifier ein 11 oder 29 Bits.
  3. Feld C - Telegrammtyp: Durch das RTR-Bit (Telegrammtyp) kann zwischen den Haupttypen Datentelegramm und Datenanforderungstelegramm unterschieden werden.
  4. Feld D - Steuerfeld: Das darauf folgende Steuerfeld ist 6 Bit lang und beinhaltet Informationen zum Nachrichtenformat, der Reserve für Erweiterungen und der Länge des Datenfeldes.
  5. Feld E - Datenfeld: In dem Datenfeld sind die eigentlichen Nutzdaten der Botschaft enthalten. Die Nutzerinformationen können eine Länge von bis zu 64 Bit haben.
  6. Feld F – CRC-Segment: Das 15 Bit lange CRC-Segment enthält eine Prüfsequenz. Dieses und nachfolgende Felder sind für die Übertragung von Prüfinformationen sowie den Abschluss des Telegramms verantwortlich.
  7. Feld G – CRC Delimiter: Die 1 Bit lange CRC Begrenzung ist mit einem rezessiven Pegel ausgestattet.
  8. Feld H – Bestätigungsfeld (ACK)
  9. Feld I - ACK-Delimiter (ACK-Begrenzung)
  10. Feld J – End-of-Frame (EOF)
  11. Feld K – Interframe Space (Telegrammzwischenraum)

Fehlererkennung und -behebung

Wie eingangs bereits erwähnt, gibt es fünf Grundmechanismen, die bei der Identifikation fehlerhafter Botschaften helfen. Sobald eine dieser Mechanismen erkannt wird, löst der entsprechende Teilnehmer des Bussystems direkt ein Fehlertelegramm aus, wodurch eine konsistente Datenübertragung gewährleistet wird. Die fünf Fehlermechanismen des CAN-Systems lauten wie folgt:

  • Bitmonitoring: 
    Der Sender überwacht, ob der beabsichtigte Pegel auch wirklich am Bus ankommt.
  • Überwachung Telegrammformat: 
    Die Netzknoten überprüfen die gesendete Botschaft auf Formfehler.
  • Zyklische Blocksicherung (CRC):
    Aus verschiedenen Feldern der Botschaft (Botschaftsbeginn, Arbitrierungsfeld, Steuerfeld, Nutzdaten) wird durch Polynomdivision eine Prüfsequenz, gemäß dem CRC-Verfahren, gebildet. Die vom Empfänger gefertigte Sequenz wird vom Empfänger der Prüfsequenz abgeglichen.
  • Überwachung Acknowledgement: 
    Der Empfänger schaltet einen dominanten Pegels im ACK-Feld auf, während der Versender der Botschaft auf eine Nachricht wartet, die den fehlerfreien Empfang bestätigt. Erhält der Sender keine Bestätigung, wird von einem Fehler ausgegangen.
  • Überwachung Bitstuffing: 
    Die Einhaltung der Bitstuffing-Regel wird gleichermaßen von allen Busteilnehmern kontrolliert.

Sobald eine der fünf genannten Fehlerbedingungen erkannt wird, sendet der jeweilige Busteilnehmer ein Fehlertelegramm. Dieses beginnt mit dem Fehlerflag, das aus sechs dominanten Bits besteht und die übertragene Nachricht zerstört. Durch diesen bewussten Verstoß gegen die Bitstuffing-Regel wird der Sender zur Wiederholung der Botschaft gebeten.

Zur Ergänzung soll noch kurz auf das Bitstuffing eingegangen werden, welches einen der Fehlermechanismen darstellt. Bei diesem Verfahren wird ein komplementäres Bit in eine definierte Anzahl gleicher Bitwerte eingefügt und damit ein Signalwechsel erzwungen. Der Empfänger dieser Botschaft weiß bereits, nach welcher Anzahl gleicher Bitwerte sich das sogenannte Stuffbit befindet und kann diese unnötige Information problemlos entfernen.