Hi kennt sich jemand mit CAN error rates aus? 125 kbs, DLC 8, standard frame(nicht extended), kein FD ich muss irgendwelche Daten (RGB Wertetabelle, 500 kilo Byte Interior Beleuchtung) in ein auto CAN netzwerk an mein Steuergerät schicken. Soll ich über meine Nutzdaten einen zusätzlichzen CRC machen? Also es geht drum a. jede message zusaetzlich über ein CRC zu schützen b. nur die gesamt Menge allerdaten Daten über ein CRC schützen! Was meint ihr? Danke
Mach lieber einen Zähler mit rein, z.b. 4bit. Damit erkennst du zumindestens, ob du ein Telegramm verloren hast. CRC32 ist bei CAN schon mit dabei, du bekommst also sowieso nur komplette Telegramme, da die Hardware fehlerhafte direkt verwirft.
H. R. schrieb: > Soll ich über meine Nutzdaten einen zusätzlichzen CRC machen? Also es > geht drum Die haben doch schon eine CRC. Was nicht geschützt ist, ist die ID! Es ist also sinnvoll, die ID nochmal in die Nutzdaten mit zu übernehmen, damit die zusätzlich von der CRC geschützt wird. H. R. schrieb: > b. nur die gesamt Menge allerdaten Daten über ein CRC schützen! Das ist schon deutlich sinnvoller. Das hilft auch gegen Fehler im Software-Protokoll.
Wie wäre es mit dem Einsatz von ISO-TP? Ggf. UDS Kommandos 34, 36, 37 implementieren und im 36er dann Blöcke zu 4k übertragen.
Dr. Sommer schrieb: > Was nicht geschützt ist, ist die ID Auch die CAN Id ist in die Lowlevel-CRC Berechnung des CAN Controllers einbezogen. Anders macht das keinen Sinn. Der professionelle Ansatz wurde oben schon genannt. ISO15765 als Transportprotokoll (4k-Blöcke) und dann per UDS übertragen. Wenn jeder 4k-Block nochmal eine Software CRC hat, bist du auf der sicheren Seite. Die CRC kannst du on the fly beim Empfang mitrechnen, so kannst du jeden 4k Block direkt bestätigen.
H. R. schrieb: > Soll ich über meine Nutzdaten einen zusätzlichzen CRC machen? Nein. CAN ist schon geprüfsummt. Das Problem bei CAN ist eher, daß etwas nicht ankommt. Da reicht es, wenn eine der CAN Leitungen in einem etwas anderen Biegeradius verlegt ist als vorgesehen. Und natürlich wenn etwas Hardware am Bus kaputt geht steht gleich der ganze Bus. Extem frsgiles Zeug das viel Spass macht wenn man sein Leben spordischen Fehlern hinterherjagen will. Man braucht also ein perfektes Fehlerreporting, was denn nun der angebliche Grund ist, warum etwas mal wieder nicht funktioniert.
Hallo, Wenn der CAN Bus derart fragil wäre, hätte sich der Bus nicht im Automotive Bereich so ausgebreitet. Beim Design eines CAN Busknotens wird Wert darauf gelegt, dass Fehler der ECU nicht das gemeinsame Übertragungsmedium beeinträchtigen. Ein Zähler in den Botschaften macht Sinn zur Ausfallerkennungen. Gruss Worker
Michael B. schrieb: > H. R. schrieb: >> Soll ich über meine Nutzdaten einen zusätzlichzen CRC machen? > > Nein. > > CAN ist schon geprüfsummt. Im Automotive-Bereich ist eine zusätzliche End-to-End-CRC nicht so unüblich, denn die eingebaute CRC des CAN sichert nur die Kommunikation von CAN-Controller zu CAN-Controller ab. > Das Problem bei CAN ist eher, daß etwas nicht ankommt. Da reicht es, > wenn eine der CAN Leitungen in einem etwas anderen Biegeradius verlegt > ist als vorgesehen. So empfindlich ist CAN nicht. Was haben wir da schon für Schindluder damit getrieben, ohne dass ihn das in irgendeiner Weise beeinträchtigt hätte. > Und natürlich wenn etwas Hardware am Bus kaputt geht steht gleich der > ganze Bus. Auch das ist nur bedingt richtig. Die CAN-Controller haben einen Mechanismus, über den sie sich schrittweise vom Bus zurückziehen, wenn sie Fehler bemerken. Natürlich kann damit nicht alles abgedeckt sein. Aber das ist immer so, wenn alle Teilnehmer parallel an einem Strang hängen.
Bei 125kbit wirds wohl eher nicht in einem Fahrzeug sein? Die frage die sich immer stellt ist was passiert wenn Daten falsch empfangen werden? Brennt die Bude ab oder hat das Licht die falsche Farbe? RGB klingt für mich nicht nach etwas elementar wichtigen. Nachdem man wie bereits erwähnt bei CAN davon ausgehen kann, dass jede einzelne Frame korrekt ist, muss man nur Prüfen ob man alle Frames empfangen hat (Böswillige manipulation mal ausgenommen). Ich würde also einen Header verwenden, der ankündigt wie viele Frames kommen und dann mit einem Zähler sicherstellen, dass alle empfangen wurden.
zur Eingangsfrage...ja CAN ist gut durchdacht, man muss eben nur darauf achten den Bus nicht vollzustopfen, denn das sich ein Knoten langsam von alleine zurückzieht muss auch programmiert werden, von Haus aus macht er das nicht das Protokoll schreibt es nur so vor.
Thomas O. schrieb: > denn das sich ein Knoten langsam von > alleine zurückzieht muss auch programmiert werden, von Haus aus macht er > das nicht das Protokoll schreibt es nur so vor. Die Fehlererkennung und die Fehlerzähler sind schon im CAN-Controllerbaustein integriert. Bis kurz vor Bus_off kann der Controller Fehler selbst handeln. Da muss man keine Software dafür schreiben. Erst wenn der Fehlerzähler bei 255 steht (Bus Off) muss der es im Microcontroller Code geben, der den CAN-Controller resettieren kann.
Suchst du eine fertige Lösung? Ansonsten wäre der ATMega16M1 ein µC der CAN als auch LIN kann. Hab das Thema damals nur überflogen, ich glaube dir das man mit dem automatischen Bus_off war aber der Meinung das man hier eingreifen kann in dem man den Zähler manipuliert bzw auch zurücksetzen kann.
ISO-TP wäre bei dieser Datenmenge das Mittel der Wahl, es wurde genau für das entwickelt was du vorhast. Dieses Protokoll wird (über UDS) auch benutzt um z.B. die Firmware zu updaten, d.h. es macht eigentlich genau das was du willst. Auf jeden Fall besser als wenn du dir dein eigenes Transportprotokoll häkelst. Solche Späße wie Zähler oder CRC auf Protokollebene brauchst du dann auch nicht. Auf UDS kannst du theoretisch verzichten. Außer es läuft eh bereits auf deiner ECU, dann kannst du es ruhig benutzen. PS: CAN ist wohl eines der robustesten Bussysteme und funktioniert auch under abartigen Bedingungen oder wenn es weit außerhalb der Spezifikation betrieben wird.
:
Bearbeitet durch User
Le X. schrieb: > PS: CAN ist wohl eines der robustesten Bussysteme und funktioniert auch > under abartigen Bedingungen oder wenn es weit außerhalb der > Spezifikation betrieben wird. und auch mit abartigen Biegeradien ;)
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.