Hallo, ich bin auf der Suche nach einem µC mit CAN oder einem Standalone-CAN-Controller, welcher mir ermöglicht, das CRC-Feld im CAN-Datenframe selbst zu bestimmen. Beim MCP2515 funktioniert dies nicht, da die Hardware den CRC nach meinen bisherigen Infos aus dem Datenblatt selbst berechnet. Der CRC-Wert wird zwar zwischendurch in ein CRC-Register abgelegt, dieses ist aber nach meinen Infos nicht selbst zu beschreiben. Kennt jemand von euch CAN-Hardware, bei denen man diese Automatismen übergehen kann? Danke & viele Grüße, Benjamin
Was willst du damit anfangen? Das ist schon von der CAN Spec her nicht möglich. Da heutige Controller alle die Spec einhalten, wird auch bei allen der CRC genauso wie Arbitierung und die ganzen anderen Layer 1 Sachen im Controller selber erldigt. Nicht mal bei den mir bekannten Testhardwaretools lässt sich der CRC per hand einstellen.
hallo benjamin. > ich bin auf der Suche nach einem µC mit CAN oder einem > Standalone-CAN-Controller, welcher mir ermöglicht, das CRC-Feld im > CAN-Datenframe selbst zu bestimmen. wie gesagt, wenn sich eine schnittstelle CAN schimpft, darf sie auch nur so tun wie CAN spezifiziert ist. und die spezifikation sieht nun mal keine "benutzerdefinierte" CRC vor. einzige chance, die du hast: besorg dir einen µC (genauer gesagt einen pro netzwerkknoten), der schnell genug ist, und implementiere ein eigenes "beinahe-CAN-protokoll". viel spaß :-) gruß michael
Was mir noch eingefallen ist: Wie kommst du auf die Idee den CRC verändern zu müssen? Falls es um Übertragungen im Auto geht, so muss man dazu sagen, dass manche Nachrichten zusätzlich noch einen Mini-CRC innerhalb der Datenbytes haben. Dieser dient aber ausschließlich der Plausiblitätsprüfung. Dieser zusätzliche CRC wird zum Beispiel bei der Übertragung von sogenannten Segmentierten Nachrichten verwendet um zu überprüfen dass keine Nachricht fehlt. Gruß TManiac
Ich vermute, Benjamin möchte mit seinen falschen CRCs absichtlich fehlerhafte Nachrichten erzeugen, um z.B. Empfängerknoten zu testen. Wenn dem wirklich so sein sollte, würde ich einen FPGA empfehlen und versuchen, an einen open source CAN Core/IP für diesen FPGA zu kommen. Das hätte den riesen Vorteil, daß man die komplette Erzeugung der Botschaften nach seinen eigenen Wünschen gestalten kann. Man ist also nicht beschränkt auf Änderungen am CRC, man könnte z.B. auch Bits kippen, die Bitdauer verändern, falsche Header ausgeben, etc...
Im Rahmen einer Diplomarbeit möchte ich dem CAN-Bus Sicherheit in Form von Authentifizierung bzw. Identifizierung der Steuergeräte untereinander hinzufügen. Dazu muss natürlich zusätzlicher Overhead aufgestaut werden. Eine Idee war es, u.a. das CRC-Feld zusätzlich dafür zunutzen (Kombination CRC-Feld/Authentizitätsinformationen). Danke für die bisherigen Antworten, das hilft mir weiter! Benjamin
huihui, das nenn ich mal nen gefährlichen ansatz tipp: lass die finger von der grundlegenden struktur der telegramme!
Kann mich dem Vorschreiber nur anschließen. Selbst wenn Du das mit dieser Variante praktisch hinkriegst, erzeugst Du Dir netto garantiert weniger Sicherheit der Datenkorrektheit.
Hi Benjamin, >>Im Rahmen einer Diplomarbeit möchte ich dem CAN-Bus Sicherheit in Form >>von Authentifizierung bzw. Identifizierung der Steuergeräte >>untereinander hinzufügen. Dazu muss natürlich zusätzlicher Overhead >>aufgestaut werden. Eine Idee war es, u.a. das CRC-Feld zusätzlich dafür >>zunutzen (Kombination CRC-Feld/Authentizitätsinformationen). Der Empfängerknoten wird die Botschaft in diesem Fall einen CRC Fehler erkennen und die Botschaft zerstören. Für zusätzliche Sicherheit stehen Dir nur die Daten und eventl. die ID zur Verfügung. Gruß Patrick
Ganz genau, wenn du den CRC verfälschst, wird die Botschaft vom Empfänger verworfen. Versuch doch mit Multiplexing zu arbeiten, in dem du z.B. das erst Datenbyte verwendest, um die restlichen 7 Bytes zu identifizieren. Beispiel: 1.Byte: 0, restliche Bytes werden als Authentifizierungsdaten interpretiert 1. Byte: 1, restliche Daten werden als "normale" Botschaftsdaten interprtiert Der Nachteil ist halt, daß du ein Byte "verschwendest", also mehr Overhead hast. Aber irgenteinen Tod wirst du sterben müssen...
Also für einen Fehlersimulator würde mir so etwas auch gefallen. Wie wird eigentlich in der (Entwickler-)Praxis überprüft ob der Knoten alle Anforderungen erfüllt (u.a. Kontrolle ob die EmpfangsCRC richtig berechnet werden)? Aber für die Identifikation kann man vielleicht den 29Bit Identifier nutzen. Steffen
Schau mal auf der Vector seite nach. Der Canstress kann das! http://www.vector.com/vi_canstress_de.html gruß
Authentifizierung bzw. Identifizierung der Steuergeräte ist eigentlich schon gängige Praxis. So wird zum Beispiel ein "Querverbau" (der Einbau eines Steuergerätes in ein anderes Auto) schon lange erkannt und das Auto in den Notlauf geschickt. Oder auch die Kommunikation eines OBD-Testers mit den Steuergeräten ist abgesichert. Die Strategien sind unterschiedlich. Auf der einen Seite kann man ein einmal aufgestartes Gerät mit einem Timeout überwachen. Und ein Aufstarten kann man so komplex machen, wie die Fantasie es hergibt. Auf der anderen Seite muss ein Steuergerät nicht nur über eine ID senden, man kann auch eine zweite zur Identifizierung nutzen. Oder wie es schon angesprochen wurde die MsgId an sich kann man auch nutzen. Und bei einer 29bit langen hat man sehr viel Platz für solche Spielereien. Aber es soll ja deine Diplomarbeit werden also mach die einen Kopf. Das beste ist meißt ganz einfach und man sieht es zu beginn nicht.
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.