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
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
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.
