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.
:
Bearbeitet durch User
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...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.