Forum: Mikrocontroller und Digitale Elektronik CAN-Bus Fehlerwahrscheinlichkeit


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Bernd K. (prof7bit)


Bewertung
-1 lesenswert
nicht lesenswert
Folgendes Szenario: Ich hab hier was ausgetüftelt das gelegentlich mal 
ein 4kB großes Blob von A nach B transportieren muss. A und B sind per 
CAN-Bus miteinander verbunden.

Ich stelle nun fest daß alle paar hundert Byte (zufällig) ein Byte 
falsch übertragen wird (oder zumindest nach dem Zusammensetzen der 
vielen 7-Byte Blöcke falsch ist) und zwar jedesmal an zufälliger anderer 
Stelle.

Frage:

* Ist es wahrscheinlich daß alle ~70 Telegramme eins so verfälscht wird 
daß die CRC dennoch passt und der CAN Controller den Empfang eines 
gültigen Telegramms meldet? (Bonusfrage: wie wahrscheinlich ist das 
überhaupt bei gegebener CRC-Länge, kann man das quantifizieren, mir 
mangelt leider etwas die Mathematik zu der ganzen CRC-Geschichte?

* Oder muss ich den Fehler in meinen Code suchen? Jetzt wo ich nochmal 
drüber nachdenke während ich hier umständlich ein Posting darüber 
verfasse fällt mir aufgrund des nichtdeterministischen Verhaltens 
vielleicht ein falscher Umgang mit der Hardware ein oder ein Race mit 
deren DMA (Messagebuffer nicht gesperrt obwohl ich dachte das täte ich).

von Karl der erste von oben (Gast)


Bewertung
4 lesenswert
nicht lesenswert
Aus vielen hundert gigabytes Messung Erfahrung kann ich sagen, dass das 
untypisch ist.
Ein ordentlich aufgebauter Bus hat praktisch keine Bitfehler. Noch dazu 
müsste der oder die Fehler den CRC passieren ohne erkannt zu werden.

von H.Joachim S. (crazyhorse)


Bewertung
3 lesenswert
nicht lesenswert
Jo, praktisch null.Irgendwo hatte ich mal ne Zahl für die 
Wahrscheinlichkeit unerkannter Fehler. Selbst erkannte Fehler sind schon 
sehr selten. Irgendwas was läuft da bei dir grundsätzlich schief.

von Tilo R. (joey5337) Benutzerseite


Bewertung
-1 lesenswert
nicht lesenswert
Letzteres halte ich für wahrscheinlicher.
CRC-Fehler erkennt der CAN-Controller und setzt dann ggf. ein Error 
Flag. Das musst du natürlich auswerten. Daher mein Verdacht Software.

Zur Mathematik:
Der CRC-Code ist 15 Bit lang. Fehler bleiben unbemerkt, wenn sich mit 
den falschen Daten eine passende Checksumme ergibt.
Im Schnitt wird von 2^15 fehlerhaften Frames nur einer unbemerkt bleibt.

Wenn es tatsächlich um nicht bemerkte Bitfehler ginge müsste dein Bus 
ganz massiv gestört sein. Du müsstest tausendfach Frames wegen Fehlern 
erneut übertragen.
Das wäre dir doch sicher aufgefallen?

von dunno.. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Die wirkliche fehlerwahrscheinlichkeit dafür kann ich dir auch nicht 
ausrechnen...

Fakt ist, aus der praxis- wenn es bei dir so oft passiert hast du einen 
bug in deiner software.

Oder reden wir von einer wirklich verseuchten umgebung..?

von georg (Gast)


Bewertung
1 lesenswert
nicht lesenswert
dunno.. schrieb:
> Oder reden wir von einer wirklich verseuchten umgebung..?

Selbst wenn - da kommt eher die Übertragung zum Erliegen, dass ständig 
Fehler unerkannt durchrutschen ist sehr unwahrscheinlich. Ganz abgesehen 
davon kann man ja auch eine eigene Sicherung der Daten durchführen, 
unabhängig von der Bus-Software.

Georg

von Sven B. (scummos)


Bewertung
0 lesenswert
nicht lesenswert
Tilo R. schrieb:
> Zur Mathematik:
> Der CRC-Code ist 15 Bit lang. Fehler bleiben unbemerkt, wenn sich mit
> den falschen Daten eine passende Checksumme ergibt.
> Im Schnitt wird von 2^15 fehlerhaften Frames nur einer unbemerkt bleibt.

Diese Folgerung halte ich für falsch. Das wäre der Fall, wenn du das 
komplette Telegramm durch ein zufälliges anderes ersetzen würdest. 
Überträgst du aber z.B. pro Telegramm 128 Bit und hast einen Bitfehler 
pro MB, wird die Eigenschaft des CRC, dass einzelne Bitfehler immer 
erkannt werden, dazu führen dass die Rate viel viel niedriger ist, 
wahrscheinlich Richtung 2^-50 oder noch weniger.

: Bearbeitet durch User
von Gerd E. (robberknight)


Bewertung
1 lesenswert
nicht lesenswert
Schneide den CAN-Traffic doch mal auf einem separaten Gerät 
(CAN-Bus-Analyzer) mit und vergleiche die Daten auf dem Bus mit den 
Solldaten.

Dann siehst Du ob das Problem auf der Senderseite oder auf der 
Empfängerseite ist.

von Tilo R. (joey5337) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Sven B. schrieb:
> Tilo R. schrieb:
>> Zur Mathematik:
>> Der CRC-Code ist 15 Bit lang. Fehler bleiben unbemerkt, wenn sich mit
>> den falschen Daten eine passende Checksumme ergibt.
>> Im Schnitt wird von 2^15 fehlerhaften Frames nur einer unbemerkt bleibt.
>
> Diese Folgerung halte ich für falsch.
Ich habe gute Gründe für die Annahme und würde das gerne diskutieren. 
Wenn ich falsch liege bleibt mir der Erkenntnisgewinn!

> Das wäre der Fall, wenn du das
> komplette Telegramm durch ein zufälliges anderes ersetzen würdest.
Ich habe keine Annahme gemacht, wie viele Bit des Telegrams falsch sind.
Zugegeben, ich habe den Prüfsummenalgorithmus nicht untersucht, ob er 
sicher alle 1-, 2-, ... n-Bit Fehler erkennt, und wie diese Distanzen 
verteilt sind.
Stattdessen habe ich den Checksummen-Algorithmus als ideal angenommen, 
d.h. wie eine kryptographische Hashfunktion/Prüfsumme, die alle 
möglichen Telegrammdaten gleichmäßig auf den Wertebereich der 
Checksummen abbildet. Die Kollissionswahrscheinlichkeit ist dann die 
Wahrscheinlichkeit für eine falsch-negative Checksumme, d.h. die 
Wahrscheinlichkeit, dass ein falscher Frame als richtig erkannt wird, 
ganz egal, wie viele Bits darin jetzt falsch sind.

Klar, mit realistischen Bitfehlerraten ist die Betrachtung der 
dominanten Einzel- bzw. Wenig-Bitfehler und deren Erkennung 
zielführender.

Im gegebenen Fall halte ich meinen Ansatz für gerechtfertigt, da der TO 
eine abartig hohe Frame-Fehlerrate haben muss, wenn angeblich netto 
jeder 70ste Frame  unerkannt falsch durchkommt. Die korrespondierende 
Bitfehlerrate muss dazu so hoch sein, dass ein Telegramm-Einzelbitfehler 
nicht mehr typisch ist und die Einzelbitfehler-Betrachtung daher keinen 
Sinn mehr macht.


> Überträgst du aber z.B. pro Telegramm 128 Bit und hast einen Bitfehler
> pro MB, wird die Eigenschaft des CRC, dass einzelne Bitfehler immer
> erkannt werden, dazu führen dass die Rate viel viel niedriger ist,
> wahrscheinlich Richtung 2^-50 oder noch weniger.

Ja, das klingt realistisch.
1 Bit pro MB ist nicht wirchlich toll, das entspricht ungefähr einer 
Roh-Bitfehlerrate von 10^-7

Damit ergeben sich überschlägig als Wahrscheinlichkeiten (für Frames mit 
100 Bit) folgende Warhscheinlichkeiten
1,0 * 10^-5 für einen 1-Bit-Fehler im Frame
4,9 * 10^-11 für 2 falsche Bits
1,6 * 10^-16 für 3 falsche Bits
3,9 * 10^-22 für 4 falsche Bits

1-Bit-Fehler werden vom CRC sicher erkannt, die fallen also weg. Und bei 
2- und 3-bit Fehlern wird sicherlich auch noch ein Großteil erkannt (wie 
gesagt - über die Verteilung der Distanzen habe ich keine Kenntnis)
Eine Netto-Framefehlerrate von 2^-50, entsprechend 10^-15 oder besser 
halte ich auch für möglich.
Hier sind wir also einer Meinung.

von Sven B. (scummos)


Bewertung
0 lesenswert
nicht lesenswert
Tilo R. schrieb:
> Im gegebenen Fall halte ich meinen Ansatz für gerechtfertigt, da der TO
> eine abartig hohe Frame-Fehlerrate haben muss, wenn angeblich netto
> jeder 70ste Frame  unerkannt falsch durchkommt. Die korrespondierende
> Bitfehlerrate muss dazu so hoch sein, dass ein Telegramm-Einzelbitfehler
> nicht mehr typisch ist und die Einzelbitfehler-Betrachtung daher keinen
> Sinn mehr macht.

Ok, das ist für mich so ohne Rechnen auch erstmal schlüssig. Man müsste 
mal nachrechnen, ob das so hinkommt (ob z.B. der Bus effektiv überhaupt 
noch funktioniert, wenn Mehr-Bit-Fehler die Regel sind), aber klingt 
nachvollziehbar.

Im Endeffekt scheint es mir eher so, als ob die "du prüfst das 
CRC-Error-Flag nicht"-Erklärung plausibel ist.

: Bearbeitet durch User
von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Ich stelle nun fest daß alle paar hundert Byte (zufällig) ein Byte
> falsch übertragen wird (oder zumindest nach dem Zusammensetzen der
> vielen 7-Byte Blöcke falsch ist) und zwar jedesmal an zufälliger anderer
> Stelle.

Nur eins? Dann schau Dir auch mal das Fifo Handling in der Software an.

Insbesondere wenn das NXP Zeuchs ist, die hatten da sowas ähnliches 
drin:
  RingPuffer[(wr++) % BUFFERSIZE] = wert;

Man sieht nicht gleich dass da der wr Index zu zeitig (VOR dem 
Schreiben) hochgezählt werden kann.

von Bernhard S. (b_spitzer)


Bewertung
2 lesenswert
nicht lesenswert
Zur Fehlererkennung mit CRC: der genutzte Algorithmus beim CAN-Bus 
erkennt
- bis zu 5 zufällig verteilte Fehler in einer Nachricht
- 15 aufeinanderfolgende Fehler (Burst-Fehler)
- alle ungeradzahligen Bitfehler-Kombinationen
- die Restfehlerwahrscheinlichkeit beträgt <4,7*10^-14
(Quelle Eschermann: CAN-Bus)

Wie sieht bei dir die Verdrahtung aus? Ist Masse mit verbunden oder nur 
CAN-L und CAN-H?
Wie viele Teilnehmer umfasst dein Netzwerk? Gibt es Error-Frames?

von Martin L. (maveric00)


Bewertung
2 lesenswert
nicht lesenswert
Hallo,

oder andere Betrachtung: der CAN ist mit der CRC-Checksumme für ASIL B 
Datenübertragung nach ISO 26262 geeignet, d.h. als Einzelfehlerquelle im 
Automotive-Umfeld mit rund 1 FIT als Fehlerrate angenommen. 1 FIT ist 1 
Fehler alle 10^9 Betriebsstunden. Da im Auto der CAN mit bis zu 1 
MBit/Sekunde betrieben wird, geht also die Norm davon aus, dass bei 
einem normalen CAN-Bus maximal 1 Fehler alle 4.5*10^17 Bytes unerkannt 
durchgeht.

Wenn bei Dir in jedem Kilobyte ein Byte verfälscht wird, würde ich stark 
davon ausgehen, dass es am Code liegt (wenn man den unwahrscheinlichen 
Fall eines Hardwaredefektes des CAN-Controllers ebenfalls 
ausschließt)...

Schöne Grüße,
Martin

von Name H. (hacky)


Bewertung
0 lesenswert
nicht lesenswert
Ich wuerde auf EMV tippen. Erbitte Schema, Layout und Foto des Aufbaus. 
Allenfass auch ein Oszilloskopbild der Signale.

von Bernd K. (prof7bit)


Bewertung
1 lesenswert
nicht lesenswert
Jim M. schrieb:
> Nur eins? Dann schau Dir auch mal das Fifo Handling in der Software an.
>

Ich möchte auflösen. Es war natürlich meine Software, was auch sonst,

> Insbesondere wenn das NXP Zeuchs ist, die hatten da sowas ähnliches
> drin:
>   RingPuffer[(wr++) % BUFFERSIZE] = wert;

Hardware ist zwar NXP (ehemals Freescale), Treiber selber gestrickt, 
aber damit hatte es gar nichts zu tun. Nachdem die Übertragung dieser 
Blobs vor 2 Monaten schonmal funktioniert hat (mit der alten Hardware, 
deshalb mein Hardwareverdacht) hab ich diesen Teil lange nicht mehr 
angefasst und auch bis letzte Woche nicht mehr getestet. Allerdings hat 
eine nachträgliche Änderung an ganz anderer Stelle in Verbindung mit 
einem von Anfang an unbemerkt fehlerhaften Dispatcher für eingehende 
Frames dafür gesorgt daß die leeren Heartbeat-Frames des Masters 
versehentlich in die selbe fifo gelangt sind wie die Frames mit den 
Nutzdaten. Das hat keine andere Funktion beeinträchtigt, nur an dieser 
einen einzigen Stelle an der eigentlich normalerweise keine Frames der 
Länge 0 jemals hätten hingelangen sollen (die wären damals schon viel 
weiter vorne rausgefiltert gewesen) wurde weder die id geprüft noch die 
Datenlänge und es wurde uninitialisierter Speicher blind als 
Sequenznummer und Datenblock interpretiert.

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.