Forum: Mikrocontroller und Digitale Elektronik Adressierungsfehler bei CAN Bus ausschließen


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 Ohjeeminee (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Mir ist bekannt, wie ein CAN Telegramm aufgebaut ist. Mir ist auch 
bekannt, dass die Nutzdaten durch eine CRC-Checksumme verifiziert 
werden. Was ich mich allerdings frage: wie wird sichergestellt, dass die 
Adresse einer CAN-Nachricht nicht fehlerhaft ist. Dann würde die 
Nachricht von einer falschen Mailbox empfangen werden und könnte so für 
erhebliche Störungen sorgen. Offensichtlich kommt dies aber so gut wie 
nie vor, darum frage ich mich, wie dieser Sicherungsmechanismus 
funktioniert.

Danke!

von Wolfgang (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Ohjeeminee schrieb:
> Was ich mich allerdings frage: wie wird sichergestellt, dass die
> Adresse einer CAN-Nachricht nicht fehlerhaft ist.

So eine CAN-Nachricht hat nur einen Absender.

Zusammen mit der Datensicherung über die CRC ergibt sich ein 
Hamming-Abstand von 6. Das hilft deutlich gegen zufällig falsche 
"richtige" Nachrichten.

von Ohjeeminee (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Die Sache mit dem Hamming-Abstand habe ich mir gestern Abend mal 
angesehen. War mir neu und ich bin noch nicht ganz durchgestiegen. Ist 
vielleicht auch nur was für Mathematiker. Dass eine Fehlererkennung und 
-korrektur damit funktioniert, ist mir allerdings halbwegs klar 
geworden. Ist denn diese Fehlererkennung bereits im CAN-Protokoll 
implementiert oder muss man sich selber darum kümmern?

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ohjeeminee schrieb:
> Die Sache mit dem Hamming-Abstand habe ich mir gestern Abend mal
> angesehen. War mir neu und ich bin noch nicht ganz durchgestiegen.

Ein Hamming-Abstand von 6 bedeutet, dass sich zwei Nachrichten in 
mindestens 6 Bit unterscheiden, d.h. selbst wenn 3 Bit falsch übertragen 
werden, kann das immer noch im Empfänger korrigiert werden.

von Ohjeeminee (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ja, so weit, so gut. Nur, werden die fehlerhaften Bits dann beim 
CAN-Empfänger automatisch korrigiert, d.h. ist diese Fehlerkorrektur 
Bestandteil der CAN-Spezifikation, oder ist dafür eine Library bzw. eine 
gesonderte Funktion vonnöten?

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Um sicherzustellen, dass eine CAN-Botschaft vom richtigen Absender kommt 
und nicht einfach nur Müll ist, kann man zum Beispiel eine zusätzliche 
CRC-8 in den Datenbytes verwenden.

von Nils P. (torus)


Bewertung
0 lesenswert
nicht lesenswert
Sagt mal, ist das mit der Fehlerkorrektur nicht rein theoretischer 
Natur?

Wenn nur ein Teilnehmer die CRC falsch liest, dann er schon während der 
Übertragung im ACK Delimiter das Fehler Bit setzen. Damit ist das Frame 
ungültig und wird ggf. vom Sender neu übertragen.

Darüber kenne ich keinen integrierten CAN Transceiver Block, der 
fehlerhafte Frames auch nur in den RX FIFO schiebt.

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Nils P. schrieb:
> Sagt mal, ist das mit der Fehlerkorrektur nicht rein theoretischer
> Natur?

Naja, stell Dir mal vor, ein Teilnehmer sendet Botschaften auf der 
falsche ID. Die sind zwar gültig, aber trotzdem nur Müll.
Bestenfalls weicht die Länge ab und man kann darüber feststellen, dass 
die Botschaft Müll ist, wenn nicht hat der Empfänger ein Problem.
Für so einen Fall macht man bei kritischen Botschaften dann eben noch 
eine zusätzliche Absicherung über eine CRC-8 in den Daten.

von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Ohjeeminee schrieb:
>> Was ich mich allerdings frage: wie wird sichergestellt, dass die
>> Adresse einer CAN-Nachricht nicht fehlerhaft ist.
>
> So eine CAN-Nachricht hat nur einen Absender.

Nein, sie hat eine ID. Die beschreibt den Inhalt, nicht den Absender. 
Adressen gibt es beim CAN nicht.

Ohjeeminee schrieb:
> Ja, so weit, so gut. Nur, werden die fehlerhaften Bits dann beim
> CAN-Empfänger automatisch korrigiert, d.h. ist diese Fehlerkorrektur
> Bestandteil der CAN-Spezifikation, oder ist dafür eine Library bzw. eine
> gesonderte Funktion vonnöten?

Keins von beiden. CAN hat keine FEC. Fehler werden nur erkannt, nicht 
korrigiert.

Nils P. schrieb:
> Darüber kenne ich keinen integrierten CAN Transceiver Block, der
> fehlerhafte Frames auch nur in den RX FIFO schiebt.

Wenn, dann würde das der CAN-Controller machen, nicht der Transceiver.

von Thomas O. (kosmos)


Bewertung
0 lesenswert
nicht lesenswert
> Nein, sie hat eine ID. Die beschreibt den Inhalt, nicht den Absender.
> Adressen gibt es beim CAN nicht.

Da bei CAN eine ID nur von einem Teilnehmer verwendet werden soll kann 
man dadurch auch auf den Absender schließen.

von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
Klar kann man indirekt auf den Absender schließen. Trotzdem gibt die ID 
primär den Inhalt an, nicht den Absender. Der Empfänger liest die Werte 
die ihn interessieren, und dabei ist ihm eigentlich egal, wer der 
Absender ist. Und ein Absender kann auch (und wird oft auch) mehrere 
verschiedene IDs senden.

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Klar kann man indirekt auf den Absender schließen. Trotzdem gibt die ID
> primär den Inhalt an, nicht den Absender.

Natürlich gibt die ID den Absender der Daten an, z.B. den Drehzahlsensor 
oder einen bestimmten Temperatursensor.

von Rudolph R. (rudolph)


Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Natürlich gibt die ID den Absender der Daten an, z.B. den Drehzahlsensor
> oder einen bestimmten Temperatursensor.

Und wenn irgendwas quer schiesst und auf der falschen ID sendet?
Tja.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Ohjeeminee schrieb:
> Ja, so weit, so gut. Nur, werden die fehlerhaften Bits dann beim
> CAN-Empfänger automatisch korrigiert, d.h. ist diese Fehlerkorrektur
> Bestandteil der CAN-Spezifikation, oder ist dafür eine Library bzw. eine
> gesonderte Funktion vonnöten?

Fehlerkorrektur ist der falsche Begriff. Es wird nichts korrigiert, 
sondern als fehlerhaft erkannte Pakete werden verworfen und die 
Übertragung wird vom Absender automatisch wiederholt.

: Bearbeitet durch User
von rcc (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Man verwendet ungerne Ientifier die sich nur in einem Bit unterscheiden, 
außerdem macht man auf Applikationsebene gerne weitere CRC und 
Botschaftszähler. Wenn die nicht passen verwirft der Empfänger in der 
Applikation die Daten.

von Jürgen S. (starblue) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Rolf M. schrieb:
>> Klar kann man indirekt auf den Absender schließen. Trotzdem gibt die ID
>> primär den Inhalt an, nicht den Absender.
>
> Natürlich gibt die ID den Absender der Daten an, z.B. den Drehzahlsensor
> oder einen bestimmten Temperatursensor.

Das kann sich z.B. bei einem Redesign ändern, ohne dass die Empfänger 
etwas davon merken.

von H.Joachim S. (crazyhorse)


Bewertung
0 lesenswert
nicht lesenswert
rcc schrieb:
> Man verwendet ungerne Ientifier die sich nur in einem Bit unterscheiden,

Ist mir noch nicht aufgefallen, müsste ich direkt mal nachschauen.

von rcc (Gast)


Bewertung
0 lesenswert
nicht lesenswert
H.Joachim S. schrieb:
>> Man verwendet ungerne Ientifier die sich nur in einem Bit unterscheiden,
>
> Ist mir noch nicht aufgefallen, müsste ich direkt mal nachschauen.

kommt hald darauf an wie viele Altlasten man mitschleppt und wie gut die 
Busarchitekten arbeiten.

von npn (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> Das kann sich z.B. bei einem Redesign ändern, ohne dass die Empfänger
> etwas davon merken.

Warum merken die Empfänger nichts davon, wenn z.B. die Drehzahl durch 
ein Redesign jetzt mit einer anderen ID gesendet wird?
Klingt irgendwie unlogisch...

von rcc (Gast)


Bewertung
1 lesenswert
nicht lesenswert
npn schrieb:
>> Das kann sich z.B. bei einem Redesign ändern, ohne dass die Empfänger
>> etwas davon merken.
>
> Warum merken die Empfänger nichts davon, wenn z.B. die Drehzahl durch
> ein Redesign jetzt mit einer anderen ID gesendet wird?
> Klingt irgendwie unlogisch...

Weil die ID gleich bleibt nur das Steuergerät dass die Botschaft jetzt 
sendet ein anderes ist; höhere Integration oder Vereinfachung oder 
Änderung die den Rest nicht beeinflussen soll. Gerade bei automotive 
Tagesgeschäft....

von npn (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
rcc schrieb:
>> Warum merken die Empfänger nichts davon, wenn z.B. die Drehzahl durch
>> ein Redesign jetzt mit einer anderen ID gesendet wird?
>> Klingt irgendwie unlogisch...
>
> Weil die ID gleich bleibt

Du bist aber witzig!

Jürgen S. schrieb:
>> Natürlich gibt die ID den Absender der Daten an, ...
>
> Das kann sich z.B. bei einem Redesign ändern, ohne dass die Empfänger
> etwas davon merken.

von Besucher (Gast)


Bewertung
0 lesenswert
nicht lesenswert
npn schrieb:
> Warum merken die Empfänger nichts davon, wenn z.B. die Drehzahl durch
> ein Redesign jetzt mit einer anderen ID gesendet wird?
> Klingt irgendwie unlogisch...

Ne, ist heute Gang und Gäbe. Bei einem PKW wird z.B. die Raddrehzahl mit 
der ID 0x100 übertragen. Der Empfänger weis, das die Information in der 
ID 0x100 steck. Ob die Daten von einem ESP oder ABS kommen, je nach 
Ausstattung, ist dabei nicht erkennbar und auch nicht wichtig. Das gibt 
es bei verschieden Antriebsarten, Audiosystem, usw.

Dadurch kann man verschieden Kombinationen in einem Netzwerklaufen 
lassen, ohne jeweils einen eigene Architektur aufzubauen.

von npn (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Besucher schrieb:
> Ob die Daten von einem ESP oder ABS kommen, je nach
> Ausstattung, ist dabei nicht erkennbar und auch nicht wichtig.

Die Drehzahl wird (in deinem Beispiel) trotzdem mit der ID 100 gesendet. 
Und die ID ändert sich auch bei einem Redesign nicht. So meinte ich das.
Insofern fand ich den Beitrag von Jürgen S. etwas mißverständlich...

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]
  • [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.