CRC Berechnung

Was soll ein Softwaremäßiger CRC Check beim CAN Bus bringen ?
CAN bringt den CRC schon hardwaremäßig mit d.h. die Hardware prüft jede
Übertragung schon ganz von alleine mit einer CRC Checksumme und meldet
normalerweise wenn ein Fehler erkannt wurde. Einfach mal im Datenblatt 
des
CAN Controllers nachschauen.

Das CAN eine hardwaremäßig Prüfung durchführt war mir klar. Also macht 
es keinen Sinn, da nochmals zusätzlich eine CRC Prüfung durchzuführen ?

Du kannst ja auch für jedes Datenpacket 1 Byte senden und daraus eine 7 
Byte lange CRC errechnen. Sicher ist sicher ;)

Hallo,

nicht zu sehr lästern, wenn man es nicht genau alle Fakten kennt:

Für normale Funktionalität macht eine zusätzliche Prüfsumme keinen Sinn, 
da diese ja wie beschrieben schon im Protokoll vorkommt.

Ganz anders sieht es aus, wenn sicherheitsrelevante Daten über den 
CAN-Bus gehen sollen. Da in aller Regel die Übertragungsstrecke (also 
PC-Treiber, PC-CAN-Interface, Kabel, Controller-Transceiver, 
Controller-Low-Level-CAN-Stack) nicht entsprechend der einschlägigen 
Normen (IEC61508, ISO26262 etc.) entwickelt werden (können), kann eine 
zusätzliche End-To-End-Absicherung durchaus Sinn machen (bzw. ist häufig 
die einzige Möglichkeit, den geforderten Diagnostischen Deckungsgrad zu 
erreichen). Dann reicht allerdings in der Regel eine CRC alleine nicht 
aus, es muss dann noch ein Frame-Counter (von 1-X Bits) und eine 
Timeout-Erkennung eingebaut werden.

Da ich jedoch davon ausgehe, dass Du kein Gerät zusammeschraubst, 
welches Leib und Leben von Personen gefährden kann, solltest Du auf eine 
zusätzliche Absicherung verzichten können. Sollte diese Annahme jedoch 
falsch sein, dann empfehle ich dringend, sich mit den oben genannten 
Normen zu beschäftigen, denn dann gehört wesentlich mehr zu der 
Entwicklung als eine einzelne CRC.

Schöne Grüße,
Martin

Nun, es gibt neben der Sicherheitsrelevanz auch noch einen anderen 
Anwendungsfall, bei dem eine CRC innerhalb der Nutzdaten einer 
CAN-Botschaft erforderlich ist.

Im Mess- und Versystemstandard XCP over CAN bzw. dem Vorgänger CCP 
werden ebenfalls CRCs über die Nutzdaten erstellt.

Das dient dazu, die zeitliche Integrität der Übertraungsdaten zu 
gewährleisten.

Angenommen zum Zeitpunkt T = 1 werden 8 Datenbytes einer CAN-Botschaft 
zusammengestellt, deren Inhalt aus zu unterschiedlichen Zeitpunkten 
gerechneten Softwarekomponenten stammen, dann könnte es sein, dass zum 
Zeitpunkt T = 2 eine dieser Komponenten einen neuen Berechnungswert in 
diesen CAN-Puffer schreibt, der den Augenblickszustand zum Zeitpunkt T=1 
nicht mehr entspricht, weil erst zum Zeitpunkt T=3 die CAN-Daten erst 
vom Treiber gesendet werden.

Um das zu vermeiden wird im Automobilbereich eine CRC über die Nutzdaten 
bestimmt, damit solche Inkonsistenzen aufgedeckt werden können.

Die Problematik betrifft eher Multitasking-Betriebssysteme. Dabei spielt 
es keine Rolle, ob sie preemptiv oder kooperativ sind.

Ein Double-Buffering könnte in vielen Fällen die CRC-Berechnung 
überflüssig machen. Nur RAM ist in Embedded-Automotive-ECUs absolute 
Mangelware.

Vielen Dank für eure Beiträge. einen Framecounter habe ich bereits auf 
der Mikrocontroller seite eingeführt. Ich überprüfe zum Schluss erst, ob 
alle Frames angekommen sind. Das mit dem Timeout habe ich mir auch schon 
überlegt. Dies dient dazu um festzstellen ob in einem definierten 
Zeitfenster die CAN Botschaft empfangen (Mikrocontroller) empfangen 
wurde.
WIe man so einen Timeout realisiert, das muss ich mir noch überlegen. 
Eine CRC Prüfung ist wohl für meinen Fall nicht notwendig, da es sich 
nicht um Messwerte handelt sondern um binäre Daten von einer Firmeware.

Guten Morgen,

ich habe im Internet weitere recherchiert. Es gibt ein 
Trans­port­pro­to­koll für CAN - ISOTP (ISO 15765-3). Ich könnte für 
meinen Anwendungsfall auch das Transportprotokoll einsetzen.