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!
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.
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?
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.
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?
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
rcc schrieb:> Man verwendet ungerne Ientifier die sich nur in einem Bit unterscheiden,
Ist mir noch nicht aufgefallen, müsste ich direkt mal nachschauen.
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.
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...
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....
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.
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.
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...
