Bitfehlererkennung CAN FD verbessert

Mikrocontrollern mit CAN-FD-Modulen unterziehen sich einem Masken-Redesign.
Eine Lücke in der Sicherheitskette von CAN FD ist nun geschlossen.

Im Normungsprozess des CAN-FD-Protokolls wurde vor Kurzem eine Bitfehler-erkennungsschwäche entdeckt und behoben. Damit ist nun die für Fahrzeugnetzwerke erforderliche hohe Zuverlässigkeit sichergestellt. Hersteller von Mikrocontrollern mit CAN-FD-Modulen müssen ihre Produkte einem Masken-Redesign unterziehen.

Als Bosch 1986 das CAN-Protokoll vorstellte, dachte man, dass die in jeder Nachricht enthaltene CRC-Sicherung garantiert, dass fünf beliebig verteilte Bitfehler (Hamming-Distanz von 6) unter allen Umständen erkannt werden können. Dies stimmt jedoch nicht für Nachrichten, die auf der Sender- und Empfängerseite ungleiche Länge aufweisen. Dies kann der Fall sein, wenn ein dynamisch eingefügtes Stuffbit gestört wird und noch ein anderes Bit unrichtig erkannt wird. Zugegeben, dies ist sehr unwahrscheinlich. Aber theoretisch gibt es Szenarien [1], in denen zwei Bitfehler nicht erkannt werden (Hamming-Distanz von 2). Da das CAN-Protokoll noch über andere Fehlererkennungsmechanismen verfügt (z.B. Formatprüfung, Acknowledgement, Stuffbit-Prüfung) ist die Wahrscheinlichkeit, dass eine fehlerhafte Nachrichtenübertragung nicht entdeckt wird, äußerst gering. Wissenschaftliche Untersuchungen Anfang der 90er Jahre haben theoretische Werte geliefert, die aber wenig praktische Relevanz haben [2]. Dies ist vor allem in der Annahme begründet, dass die eingestreuten Fehler zufällig die Länge eines Bits haben. Berechnet man die Restfehlerwahrscheinlichkeit für realistische Fehlerszenarien, dann sind die Werte um Potenzen besser [3].

Soweit die Vergangenheit. Einer der Gründe für eine niedrigere Hamming-Distanz ist die Nichtberücksichtigung der dynamisch generierten Stuffbits in der CAN-Nachricht bei der CRC-Berechnung. Dies wollte man beim CAN-FD-Protokoll nicht wiederholen. Deshalb wurden sie bei der CRC-Berechnung berücksichtigt und zusätzlich feste Stuffbits in der CRC-Sequenz eingeführt. Die dynamischen Stuffbits werden immer nach fünf gleichpoligen Bits (dominant oder rezessiv) in den Bitstrom eingefügt. Die empfangenden CAN-Controller brauchen fallende und steigende Flanken, um sich mit dem Sender zu synchronisieren. Bei den festen Stuffbits im CAN-FD-Protokoll haben diese jeweils den umgekehrten Wert des vorhergehenden Bits. Auf ein rezessives Bit folgt also ein dominantes und umgekehrt.

Nicht entdeckbare Fehlerszenarien

Leider steckt der Teufel im Detail. Als japanische und chinesische Experten das zur Normung eingereichte CAN-FD-Protokoll auf seine Zuverlässigkeit untersuchten, fanden sie Fehlerszenarien, die schon bei einem einfachen Bitfehler nicht mehr entdeckbar waren [4]. Dies war für die Automobilindustrie nicht akzeptabel, auch wenn diese Fehler­szenarien extrem unwahrscheinlich sind. Vor allem US-Juristen würden sich darauf stürzen. Das CAN-FD-Protokoll muss mindestens so zuverlässig sein wie das klassische CAN-Protokoll. Bosch erarbeitete mehrere Lösungsvorschläge, die im zuständigen ISO-Arbeitskreis diskutiert wurden.

Um die Länge einer Nachricht zu kennen und damit alle Fehler entdecken zu können, muss man die Anzahl der dynamischen Stuffbits zählen und überprüfen. Deshalb wurde vor dem CRC-Feld ein Stuffbit-Zähler eingeführt. Der Sender zählt die Stuffbits (modulo 8) und überträgt sie als 3-bit-Wert, welcher Gray-kodiert ist. Der Empfänger tut das Gleiche und vergleicht seinen gezählten Wert mit dem übertragenen. Um den Zähler abzusichern, wird nach dem Zähler noch ein Paritätsbit übertragen und vom Empfänger überprüft. Auf das Paritätsbit folgt das erste feste Stuffbit der CRC-Sequenz (Tabelle). Also eine weitere Plausibilitätsprüfung. Allgemein gilt: Je mehr festgelegte Bitwerte in eine Nachricht vorhanden sind, desto zuverlässiger ist die Übertragung. Außerdem wurde noch der Startwert der CRC-Berechnung von „0...0“ auf „10...0“ geändert.

 Anzahl der StuffbitsZähler wertParitätsbit1. festes Stuffbit
00000 1
100110
201101
301010
411001
511110
610110
710010
Stuffbit-Zähler und seine Sicherung

Lösung ist bereits Teil der Normierung

Die Lösung ist Anwendungs-transparent. Das heißt, die Bytes des Datenfeldes (bis zu 64 Byte) und das Identifier-Feld wurden nicht verändert (Bild 1). Die bereits entwickelten Transportprotokolle für die Diagnose (ISO 15765-2) und die Kalibrierung (XCP on CAN FD) müssen nicht angepasst werden. Auch CANopen-FD wird in seiner Entwicklung nicht verzögert. Es soll im Frühjahr freigegeben werden. Eine CAN-FD-Weiterentwicklung des J1939-Protokolles ist derzeit bei der CiA-Nutzervereinigung in Vorbereitung und soll dann der SAE (Society of Automotive Engineers) vorgestellt werden. Entsprechende AUTOSAR-Erweiterungen sind ebenfalls bereits verabschiedet und werden demnächst veröffentlicht (Version 4.2.1).

Die Änderungen im CAN-FD-Protokoll sind bereits in die Normung eingeflossen. Der kurz vor Weihnachten eingereichte Normungsvorschlag enthält die oben beschriebenen Verbesserungen und wird zur Zeit international abgestimmt. Um die bereits am Markt verfügbaren CAN-FD-Produkte mit dem ursprünglichen CAN-FD-Protokoll von denen zu unterscheiden, die dem zukünftigen genormten CAN-FD-Protokoll entsprechen, bedarf es einer einvernehmlichen Sprachregelung. Der CiA empfiehlt deshalb zwischen non-ISO CAN FD und ISO CAN FD zu differenzieren. Da die Änderungen Anwendungs-transparent sind, können die Fahrzeughersteller und andere Systementwickler ihre Evaluierungen auch mit non-ISO CAN FD weiterführen. Auch für die Anbieter von FPGA-Lösungen ist der Umstieg auf ISO CAN FD nur ein Software Update. Bosch wird seine Kunden, wenn dieser Artikel erschienen ist, bereits mit einem Update beliefert haben. Auch die anderen FPGA-Anbieter werden in den nächsten Tagen nachziehen (Cast, esd, Inicore, Kvaser, Peak usw.). Die Hersteller von Mikrocontrollern mit CAN-FD-Modulen müssen allerdings in den sauren Apfel beißen und ihre Produkte einem Masken-Redesign unterziehen. Dies kostet Zeit und Geld. Aber es ist immer noch besser, in der Prototypenphase Dinge zu ändern, als Fahrzeuge zurückzurufen.