www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik CAN-Mikrocontroller, welcher überschreiben von CRC-Feld ermöglicht


Autor: Benjamin Meier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TManiac (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael L. (-mic-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TManiac (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: peterguy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Benjamin Meier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
huihui, das nenn ich mal nen gefährlichen ansatz

tipp:

lass die finger von der grundlegenden struktur der telegramme!

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: PatrickMl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: peterguy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau mal auf der Vector seite nach. Der Canstress kann das!
http://www.vector.com/vi_canstress_de.html

gruß

Autor: TManiac (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.