-
Stand der Technik
-
Es wurde eine Schwäche bei der CRC-Erzeugung (CRC = Cyclic Redundancy Check = zyklische Redundanzprüfung) der CAN FD Rahmen oder Nachrichten nach dem aktuellen Committee Draft der ISO11898-1 oder der Spezifikation „CAN with Flexible Data-Rate, Specification Version 1.0 (released April 17th, 2012)“ festgestellt, welche auf der Internetseite http://www.semiconductors.bosch.com/ heruntergeladen werden kann.
-
Die Schwäche steht im Zusammenhang mit dem CAN-Stuff-Mechanismus, welcher in dem angeführten Dokument beschrieben wird. Hierbei wird nach fünf Bits mit dem gleichen Pegel ein „Stuff-Bit“ oder „stuff bit“ eingefügt, das einen anderen Pegel als die fünf vorangehenden Bits hat. Durch diese vorbestimmte Regel zum Einfügen der Stuff-Bits kann verhindert werden, dass Bitfolgen mit mehr als fünf gleichen Bits irrtümlich als beispielsweise eine Signalisierung eines Rahmenendes „End of Frame“ interpretiert werden, oder dass durch das Fehlen von Signalflanken bzw. Pegelwechseln zwischen den Bits die Busteilnehmer die Synchronisierung verlieren. Denn bei CAN und CAN FD werden Signalflanken bzw. Pegelwechsel zur Synchronisierung der Busteilnehmer herangezogen.
-
CAN FD Nachrichten oder Rahmen (frames) haben nach einem initialen Start of Frame Bit (SOF-Bit) mit dominantem Pegel, das den Beginn des Rahmens signalisiert, ein Bit 28 bis Bit 18 und gegebenenfalls noch ein Bit 17 bis Bit 0 für einen Identifizierer oder Identifier des CAN FD Rahmens. Daher werden das Bit 28 bis Bit 0 auch ID28, ID27, usw. genannt. Frühestens nach dem Bit ID25 wird gemäß der bekannten Regel zum Einfügen der Stuff-Bits ein Stuff-Bit in den CAN FD Rahmen eingefügt, nämlich wenn ID28-ID25 = „0000“. Werden CAN FD Rahmen beginnend mit ID28-ID25 = „0000“ oder ID28-ID25 = „0001“ versandt, so kann ein vom Empfänger des Rahmens fehlerhaft detektiertes Start-of-Frame Bit dazu führen, dass der Identifier des Rahmens verfälscht wird, die CRC-Prüfung diesen Fehler aber nicht erkennt. Da bei CAN FD Stuff-Bits mit in die CRC-Erzeugung einbezogen sind, führt dieser Fehler zu keinem Format-Fehler und wird nicht erkannt. Der Rahmen wird daher vom Empfänger als gültig akzeptiert. Davon betroffen sind 11-Bit und 29-Bit Identifier bei Rahmen im FD-Format (17-Bit und 21-Bit CRC).
-
Die CRC-Schwäche wird durch den Initialisierungsvektor des CRC-Generators verursacht. Dieser ist aktuell ein Null-Vektor „0...0“. Diese Schwäche kann durch eine Änderung des Initialisierungsvektors auf z.B. „10...0“ (endgültiger Wert erst nach weiteren Untersuchungen) behoben werden. Das Problem hierbei ist jedoch, dass zwei CAN FD Implementierungen, die denselben CRC-Generator aber mit unterschiedlichen Initialisierungsvektoren verwenden, nicht miteinander kommunizieren können. Sie würden ständig CRC-Fehler detektieren und die empfangenen Rahmen verwerfen.
-
Rahmen im Classic CAN Format sind von dem Problem nicht betroffen, da hier die Stuff-Bits von der CRC-Berechnung ausgeschlossen sind.
-
Die Schwäche des CAN FD CRC kommt nur in den folgenden beiden Fällen zum tragen:
-
Fall 1) Sender sendet ID28-ID25 = “0000“.
-
Der Empfänger erkennt Start-of-Frame nicht und interpretiert daher ID28 als Start-of-Frame. Damit werden die ersten vier Identifier Bits aufgrund des vom Sender nach ID25 eingefügten Stuff-Bits zu ID28-ID25 = „0001“ verfälscht, alle nachfolgenden Identifier Bits werden korrekt empfangen. Der Sender erkennt beim Zurücklesen des Start-of-Frame vom Bus keinen Fehler.
-
Fall 2) Sender sendet ID28-ID25 = “0001“
-
Der Empfänger sieht ein dominantes Bit in der Bitzeit vor dem gesendeten Start-of-Frame und interpretiert diese Störung als Start-of-Frame. Das vom Sender gesendete Start-of-Frame erkennt der Empfänger als ID28. Damit werden die ersten vier Identifier Bits zu ID28-ID25 = „0000“ verfälscht. Das gesendete ID25 = „1“ wird vom Empfänger als Stuff-Bit interpretiert. Alle nachfolgenden Identifier Bits werden korrekt empfangen. Der Sender detektiert kein dominantes Bit in der Bitzeit direkt vor seinem Start-of-Frame.
-
Zusammengefasst zeigt Tabelle 1, wie durch den dargestellten Effekt die führenden vier Identifier-Bits auf dem Weg zum Empfänger verfälscht werden können, ohne dass der Fehler von der CRC-Prüfung des Empfängers erkannt wird.
| Gesendet | | Empfangen |
| ID25 | ID27 | ID26 | ID25 | | ID25 | ID27 | ID26 | ID25 |
| 0 | 0 | 0 | 0 | → | 0 | 0 | 0 | 1 |
| 0 | 0 | 0 | 1 | → | 0 | 0 | 0 | 0 |
Tabelle 1
-
In allen anderen Fällen wird ein verfälschter Identifier vom CRC mit einer Hamming-Distanz von 6 erkannt.
-
Offenbarung der Erfindung
-
Daher ist es Aufgabe der vorliegenden Erfindung, ein Verfahren zur seriellen Übertragung eines Rahmens über ein Bussystem von einem Sender zu mindestens einem Empfänger und eine Teilnehmerstation für ein Bussystem bereitzustellen, welches Verfahren und Teilnehmerstation die zuvor genannten Probleme lösen. Insbesondere sollen ein Verfahren zur seriellen Übertragung eines Rahmens über ein Bussystem von einem Sender zu mindestens einem Empfänger und eine Teilnehmerstation für ein Bussystem bereitgestellt werden, bei welchen die Sicherheit der Datenübertragung gegenüber bisherigen Verfahren weiter erhöht wird.
-
Die Aufgabe wird durch ein Verfahren zur seriellen Übertragung eines Rahmens über eine Busleitung von einem Sender zu mindestens einem Empfänger mit den Merkmalen des Anspruchs 1 gelöst. Bei dem Verfahren werden vom Sender in den Rahmen gemäß einer vorbestimmten Regel Stuff-Bits zur Erzeugung zusätzlicher Signalflanken eingefügt und/oder vom Empfänger die Stuff-Bits bei einer Auswertung des Rahmens wieder entfernt, wobei wenigstens eine Information über einen Teilabschnitt des Rahmens zusätzlich außerhalb dieses Teilabschnitts eingefügt und übertragen wird, und wobei der Teilabschnitt eine vorbestimmte Abfolge von Bitwerten aufweist.
-
Vorteilhafte weitere Ausgestaltungen des Verfahrens sind in den abhängigen Patentansprüchen angegeben.
-
Es ist möglich, dass der Rahmen einen Kopfteil, einen Datenteil und einen Schlussteil aufweist und/oder dass der Kopfteil einen Identifier aufweist und/oder dass der Rahmen eine CRC-Checksumme aufweist und/oder dass der Teilabschnitt kein Stuff-Bit aufweist.
-
Bevorzugt kann die Information im Datenteil und/oder im Kopfteil des Rahmens übertragen werden. Dadurch sind keine Änderungen an einer Kontrolleinrichtung einer Teilnehmerstation des Bussystems erforderlich.
-
Die Information kann zumindest teilweise im RRS-Bit und/oder im res-Bit und/oder im „ESI“-Bit eines CAN FD Rahmens und/oder einer zusätzlichen Prüfsumme im Datenteil übertragen werden.
-
Vorzugsweise kann der Empfänger bei der Auswertung des Rahmens die außerhalb des Teilabschnitts abgelegte Information über den Teilabschnitt des Rahmens mit dem Teilabschnitt des Rahmens vergleichen und abhängig von dem Vergleichsergebnis den Rahmen für gültig oder ungültig bewerten.
-
Möglicherweise kann der Teilabschnitt mit demjenigen Bit enden, nach welchem vom Sender frühestens ein Stuff-Bit in den Rahmen eingefügt wird, und/oder kann der Teilabschnitt des Rahmens vier Bits umfassen, deren Informationen in zwei Bits außerhalb dieses Teilabschnitts übertragen werden können.
-
In einer speziellen Ausgestaltung kann der Teilabschnitt des Rahmens bis zu drei Bits umfassen, deren Information in einem Bit außerhalb dieses Teilabschnitts übertragen werden, und/oder der Teilabschnitt des Rahmens kann bis zu drei Bits mit gleichem Pegel umfassen, denen außerhalb des Teilabschnitts ein weiteres Bit mit gleichem Pegel unmittelbar vorangehen kann.
-
In einer speziellen Ausgestaltung entspricht der Teilabschnitt des Rahmens den vier ersten Bits des Identifiers eines CAN FD Rahmens.
-
Die zuvor genannte Aufgabe wird zudem durch eine Teilnehmerstation für ein Bussystem nach Patentanspruch 9 gelöst. Die Teilnehmerstation umfasst eine Sende-/Empfangseinrichtung zum Senden eines Rahmens an und/oder Empfangen eines Rahmens von eine/r weitere/n Teilnehmerstation des Bussystems ausgestaltet sein, mit welchem Rahmen mittels serieller Übertragung über eine Busleitung von einem Sender zu mindestens einem Empfänger übertragbar sind, und eine Absicherungseinrichtung zum Absichern einer Information über einen Teilabschnitt des Rahmens, wobei die Sende-/Empfangseinrichtung ausgestaltet ist, vor dem Senden eines Rahmens in den Rahmen gemäß einer vorbestimmten Regel Stuff-Bits zur Erzeugung zusätzlicher Signalflanken einzufügen und/oder beim Auswerten eines empfangenen Rahmens die Stuff-Bits wieder zu entfernen, wobei die Absicherungseinrichtung ausgestaltet ist, wenigstens eine Information über einen Teilabschnitt des Rahmens zusätzlich außerhalb dieses Teilabschnittes in den Rahmen einzufügen, und wobei der Teilabschnitt eine vorbestimmte Abfolge von Bitwerten aufweist.
-
Die Teilnehmerstation kann Teil eines Bussystems sein, das zudem eine Busleitung und mindestens zwei Teilnehmerstationen aufweist, welche über die Busleitung derart miteinander verbindbar sind, dass sie miteinander kommunizieren können, wobei mindestens eine der mindestens zwei Teilnehmerstationen die zuvor beschriebene Teilnehmerstation ist.
-
Weitere mögliche Implementierungen der Erfindung umfassen auch nicht explizit genannte Kombinationen von zuvor oder im Folgenden bezüglich der Ausführungsbeispiele beschriebenen Merkmale oder Ausführungsformen. Dabei wird der Fachmann auch Einzelaspekte als Verbesserungen oder Ergänzungen zu der jeweiligen Grundform der Erfindung hinzufügen.
-
Zeichnungen
-
Nachfolgend ist die Erfindung unter Bezugnahme auf die beiliegende Zeichnung und anhand von Ausführungsbeispielen näher beschrieben. Es zeigen:
-
1 ein vereinfachtes Blockschaltbild eines Bussystems gemäß einem ersten Ausführungsbeispiel;
-
2 eine Darstellung eines Aufbaus eines Rahmens bei dem Bussystem gemäß dem ersten Ausführungsbeispiel; und
-
3 bis 6 zeigen jeweils in Bezug auf ein zweites Ausführungsbeispiel das Format von CAN FD Rahmen mit der Platzierung der zu prüfenden ersten vier Identifier Bits (ID28-ID25) und des Prüfungsbits RRS.
-
In den Figuren sind gleiche oder funktionsgleiche Elemente, sofern nichts anderes angegeben ist, mit denselben Bezugszeichen versehen.
-
Erstes Ausführungsbeispiel
-
1 zeigt in einem ersten Ausführungsbeispiel ein Bussystem 1, das beispielsweise ein CAN FD-Bussystem, sein kann. Das Bussystem 1 kann in einem Fahrzeug, insbesondere einem Kraftfahrzeug, einem Flugzeug, usw., oder im industriellen Bereich z.B. bei Steuerungsanlagen etc., oder im Krankenhaus usw. Verwendung finden.
-
In 1 hat das Bussystem 1 eine Busleitung 3, an die eine Vielzahl von Teilnehmerstationen 10, 20, 30 angeschlossen sind. Über die Busleitung 3 können Rahmen 50 in der Form von Signalen zwischen den einzelnen Teilnehmerstationen 10, 20, 30 übertragen werden. Die Teilnehmerstationen 10, 20, 30 können beispielsweise Steuergeräte, Sensoren, Anzeigevorrichtungen, usw. eines Kraftfahrzeugs sein.
-
Wie in 1 gezeigt, hat die Teilnehmerstation 10 eine Kommunikationssteuereinrichtung 11, eine Absicherungseinrichtung 12 und eine Sende-/Empfangseinrichtung 13. Selbstverständlich kann die Absicherungseinrichtung 12 auch Teil der Kommunikationssteuereinrichtung 11 sein. Die Teilnehmerstation 20 hat dagegen eine Kommunikationssteuereinrichtung 21, eine Absicherungseinrichtung 22 mit einer Einfügeeinheit 22A und einer Auswerteeinheit 22B, und eine Sende-/Empfangseinrichtung 23. Die Teilnehmerstation 30 hat eine Kommunikationssteuereinrichtung 31, eine Absicherungseinrichtung 32 und eine Sende-/Empfangseinrichtung 33, welche die Absicherungseinrichtung 32 aufweist. Die Sende-/Empfangseinrichtungen 13, 23, 33 der Teilnehmerstationen 10, 20, 30 sind jeweils direkt an die Busleitung 3 angeschlossen, auch wenn dies in 1 nicht dargestellt ist.
-
Die Kommunikationssteuereinrichtungen 11, 21, 31 dienen jeweils zur Steuerung einer Kommunikation der jeweiligen Teilnehmerstation 10, 20, 30 über die Busleitung 3 mit einer anderen Teilnehmerstation der an die Busleitung 3 angeschlossenen Teilnehmerstationen 10, 20, 30. Die Kommunikationssteuereinrichtungen 11, 21, 31 können jeweils wie ein herkömmlicher CAN FD Kontroller ausgeführt sein. Die Kommunikationssteuereinrichtungen 11, 21, 31 können jeweils auch als Teil eines Mikrocontrollers ausgebildet sein, welcher ebenfalls von der jeweiligen Teilnehmerstation 10, 20, 30 umfasst ist.
-
Die Sende-/Empfangseinrichtungen 13, 23, 33 können jeweils wie ein herkömmlicher CAN FD Transceiver ausgeführt sein.
-
Die Absicherungseinrichtungen 12, 22, 32 können auch als Software-Module ausgeführt sein, welche einen Teil der auf der Teilnehmerstation ablaufenden Software bilden. In diesem Fall wird das Verfahren gemäß der vorliegenden Erfindung vollständig in Software abgebildet.
-
Das erste Ausführungsbeispiel beschreibt ein Verfahren, zur Absicherung von CAN FD Rahmen mit Identifiern entsprechend den zuvor genannten Fällen 1) und 2). Das Verfahren wird jeweils mit den Absicherungseinrichtungen 12, 22, 32 ausgeführt.
-
2 zeigt sehr schematisch den Aufbau eines CAN FD Rahmens 50 ohne das Start of Frame Bit (SOF), das unmittelbar vor dem Rahmen 50 über die Busleitung 3 übertragen wird. Der Rahmen 50 hat ein Kopfteil 51, 51A, 52, ein Datenfeld 53, 54, 55, sowie ein Schlussteil 56, welches das Rahmenende bildet. Der Kopfteil 51, 51A, 52 weist in einem ersten Teilabschnitt 51 die ersten vier Bits des Identifiers (ID) 51, 51A, in einem zweiten Teilabschnitt 51A die übrigen Bits des Identifiers 51, 51A und ein Control Feld 52 auf. Das Datenfeld 53, 54, 55 weist in einem ersten Teil 53 ein Byte 0, in einem zweiten Teil 54 weitere Bytes und in einem dritten Teil 55 ein Byte n auf.
-
In 2 ist eine von vielen möglichen Platzierungen des ersten Teilabschnitts 51, welcher die zu prüfenden ersten vier Identifier Bits (ID28-ID25) aufweist, in dem Datenfeld 53, 54, 55 gezeigt. Genauer gesagt, in 2 sind die zu prüfenden ersten vier Identifier Bits (ID28-ID25) in dem ersten Teil 53 des Datenteils 53, 54, 55, also dem Byte 0 angeordnet. Der Schlussteil 56 bzw. das Rahmenende des CAN FD Rahmens 50 enthält die CRC.
-
Bei dem Verfahren gemäß dem vorliegenden Ausführungsbeispiel erfolgt die Absicherung ganz allgemein durch Einfügen der ersten vier Bits des Identifiers in das Datenfeld 53, 54, 55 des CAN FD Rahmens. Dieses Verfahren erfordert keine Änderungen an bestehenden CAN FD Kontrollern, wie den Kommunikationssteuereinrichtungen 11, 21, 31.
-
Damit ein Empfänger, beispielsweise die Teilnehmerstation 10, erkennen kann ob der Identifier 51, 51A eines empfangenen CAN FD Rahmens 50 durch ein fehlerhaft abgetastetes Start-of-Frame Bit verfälscht wurde, wird vom Sender, beispielsweise der Teilnehmerstation 30, genauer gesagt deren Absicherungseinrichtung 32, eine Kopie der von diesem Effekt betroffenen ersten vier Bits des Identifiers ID28-ID25 (Teilabschnitt 51) im Datenfeld 53, 54, 55 des CAN FD Rahmens abgelegt. Der Empfänger, also bei dem genannten Beispiel die Teilnehmerstation 10, vergleicht dann mit Hilfe seiner Absicherungseinrichtung 12, 22, 32 die vier Identifier Bits aus dem Datenfeld 53, 54, 55 mit den von ihm empfangenen Identifier Bits ID28-ID25 51. Bei Ungleichheit wird der Rahmen 50 verworfen.
-
Ist die Teilnehmerstation 20 Sender, wird die Kopie der von diesem Effekt betroffenen ersten vier Bits des Identifiers ID28-ID25 (Teilabschnitt 51) durch die Einfügeeinheit 22A der Absicherungseinrichtung 22 im Datenfeld 53, 54, 55 des CAN FD Rahmens 50 abgelegt, beispielsweise im Byte 0, wie in 2 gezeigt. Ist die Teilnehmerstation 20 Empfänger, vergleicht die Auswerteeinheit 22B der Absicherungseinrichtung 22 die vier Identifier Bits aus dem Datenfeld 53, 54, 55 mit den von der Teilnehmerstation 20 empfangenen Identifier Bits ID28-ID25 51.
-
Aufgrund der Schwäche der CAN FD CRC-Prüfung sind nur zwei Fälle relevant, wie in der zuvor angegebenen Tabelle 1 dargestellt. In allen anderen Fällen wird der verfälschte Identifier 51, 51A vom CRC sicher erkannt.
-
Die in Tabelle 1 und 2 gezeigten vier Identifier Bits ID28 bis ID25, der Teilabschnitt 51, können also in den oberen vier Bits des ersten Datenbytes im Datenfeld 53, 54, 55 des CAN FD Rahmens 50 abgelegt werden, wie in 2 gezeigt. Sie können aber auch in jeder beliebigen Stelle im Datenfeld 53, 54, 55 abgelegt werden.
-
Das beschriebene Verfahren kann für jeden Identifier 51, 51A ausgeführt werden. Alternativ ist es jedoch auch möglich, dass die Absicherungseinrichtung 22 die beschriebene Absicherung nur durchführt, wenn der Identifier 51, 51A mit den beiden kritischen Kombinationen „0000“ bzw. „0001“ beginnt, also einer vorbestimmten Abfolge von Bitwerten für einen Teilabschnitt 51 des CAN FD Rahmens 50.
-
Durch die im Datenfeld 53, 54, 55 des CAN FD Rahmens 50 abgelegten ersten vier Identifier-Bits (ID28-ID25) als Teilabschnitt 51 kann ein durch ein verfälschtes Start-of-Frame Bit veränderter Identifier 51, 51A sicher erkannt werden. Damit kann die durch die CRC-Schwäche entstandene Lücke geschlossen werden. Ganz allgemein kann der Teilabschnitt 51, der im Datenfeld 53, 54, 55 des CAN FD Rahmens 50 abgelegt wird, mit demjenigen Bit enden, nach welchem vom Sender frühestens ein Stuff-Bit in den Rahmen 50 60; 70; 600; 700) eingefügt wird.
-
Das Verfahren hat den Vorteil, dass keine Hardware-Änderung bei den CAN FD Kontrolllern 11, 21, 31 notwendig ist. Das heißt, der Initialisierungsvektor für den CRC-Generator muss nicht verändert werden. Damit werden zwei inkompatible Hardware-Versionen vermieden.
-
Gemäß einer Modifikation des ersten Ausführungsbeispiels wäre alternativ auch eine Kodierung im Datenfeld
53,
54,
55 mit zwei Bits F1 und F2 für den Teilabschnitt
51 möglich. Bit F1 wird zu Null gesetzt, wenn die Identifier Bits ID28-ID26 Null sind, ansonsten hat das Bit F1 den Wert Eins. Bit F2 zeigt den Wert von ID25 an. Dies ist in der nachfolgenden Tabelle 2 in der Übersicht gezeigt.
| Identifier | Kodierung Datenfeld |
| ID25 | ID27 | ID26 | ID25 | F1 | F2 |
| 0 | 0 | 0 | 0 | 0 | 0 |
| 0 | 0 | 0 | 1 | 0 | 1 |
| andere IDs | 0/1 | 1 | 0/1 |
Tabelle 2
-
Auf diese Weise kann eine Absicherung der Identifier Bits ID28-ID25 mit weniger Speicherbedarf im Datenfeld 53 bis 55 als bei dem ersten Ausführungsbeispiel erzielt werden.
-
Eine weitere Möglichkeit für eine Modifikation des ersten Ausführungsbeispiels wäre, dass der Sender für den Fall, dass der Identifier 51, 51A des zu sendenden Rahmens 50 mit den kritischen Kombinationen „0000“ bzw. „0001“ beginnt, den Datenlängencode (Data Length Code DLC) gemäß der ISO11898-1 im Control Feld 52 um eins erhöht, und die vier Identifier Bits ID28-ID25, den Teilabschnitt 51, oder die zwei Bits F1 und F2 für die vier Identifier Bits ID28-ID25, dann in einem nicht genutzten Byte des dadurch vergrößerten Datenfeldes 53, 54, 55 ablegt. Dies hätte den Vorteil, dass die Aufteilung der Datenbytes des Datenfeldes 53, 54, 55 auf die Nutzdaten unverändert bleiben kann. Der Datenlängencode DLC im Control Feld 52 ist in 3 bis 6 für das zweite Ausführungsbeispiel dargestellt.
-
Noch eine weitere Alternative für eine Modifikation des ersten Ausführungsbeispiels macht sich zunutze, dass die Nutzdaten im Datenfeld 53, 54, 55 oft mit einer zusätzlichen Prüfsumme abgesichert werden, wie z.B. dem Message Authentication Code. Diese Prüfsumme wird mit den Nutzdaten zusammen im Datenfeld 53, 54, 55, beispielsweise im dritten Teil 55 für das Byte n oder an anderer Stelle im Datenfeld, übertragen. Werden nun die Identifier Bits ID28-ID25, der Teilabschnitt 51, in die Prüfsummenberechnung mit einbezogen, so kann der Empfänger, genauer gesagt seine Absicherungseinrichtung 22 oder Auswerteeinheit 22B, mittels dieser zweiten Prüfsumme die verfälschten Identifier Bits 51 erkennen.
-
Die Verwendung des beschriebenen Verfahrens lässt sich durch das Verhalten der Teilnehmerstationen 10, 20, 30 mit Kommunikationssteuereinrichtungen 11, 21, 31 und Absicherungseinrichtungen 12, 22, 32 nachweisen.
-
Zweites Ausführungsbeispiel
-
Das Bussystem 1 ist bei diesem Ausführungsbeispiel in weiten Teilen auf dieselbe Weise ausgeführt, wie zuvor in Bezug auf das erste Ausführungsbeispiel beschrieben. Im Unterschied zum ersten Ausführungsbeispiel beschreibt das vorliegende Ausführungsbeispiel ein Verfahren zur Absicherung von CAN FD Rahmen mit Identifiern entsprechend Fall 1) und 2) durch zusätzliche Übertragung einer Information, z.B. Checksumme über den Inhalt der ersten vier Bits des Identifiers an anderer Stelle innerhalb des CAN FD Rahmens als bei dem ersten Ausführungsbeispiel und seinen Modifikationen genannt.
-
Durch die zusätzliche Übertragung einer Information, z.B. Checksumme über den Inhalt der ersten vier Bits des Identifiers wird eine Erkennung der zuvor in Bezug auf Tabelle 1 beschriebenen Fehlerfälle möglich.
-
Dies hat den Vorteil, dass dadurch die durch die CRC-Schwäche entstandene Lücke in der Fehlererkennung geschlossen werden kann. Die Rahmen- oder Nachrichtenformate der CAN und CAN FD Rahmen oder Nachrichten bleiben unverändert, es wird lediglich eine entsprechende Information in ein Kontrollbit geschrieben.
-
3 zeigt einen von einer der Teilnehmerstationen 10, 20, 30 gesendeten Rahmen 60 mit bis zu 16 Datenbytes im CAN FD-Basisformat. Der Rahmen 60 hat ein SOF-Bit 61 sowie mehrere Rahmenfelder, wie ein Arbitrationsfeld 62 (Arbitration field), ein Control Feld 63 (Control field), ein Datenfeld 64 (Data field) und ein Prüfsummenfeld 65 (CRC field). Das Arbitrationsfeld 62 umfasst in dem base-ID-Feld einen Identifizierer (Identifier) des Rahmens 60. Am Ende des Arbitrationsfelds 62 ist ein RRS-Bit angeordnet. Das Kontrollfeld 63 beginnt mit einem IDE-Bit, das von einem FDF-Bit und dann von einem res-Bit und einem sich daran anschließenden BRS-Bit und dann ESI-Bit gefolgt wird, an das sich ein DLC-Feld anschließt. Das Datenfeld 64 ist nicht vorhanden, wenn das DLC-Feld des Kontrollfelds 63 den Wert 0 hat. Das Prüfsummenfeld 65 enthält in einem CRC-seq-Feld eine CRC-Checksumme und endet mit einem daran anschließenden CRC-Delimiter CRC-Del. Die genannten Felder und Bits sind aus der ISO-CD-11898-1 bekannt und sind daher hier nicht näher beschrieben.
-
In 3 ist die Länge einer Arbitrationsphase 67 bei dem vorliegenden Ausführungsbeispiel angegeben. An die Arbitrationsphase 67 schließt sich die Datenphase 68 an, falls das BRS-Bit in dem Rahmen 60 rezessiv ist. Der Rahmen 60 hat einen Kopfteil 61 bis 63, einen Datenteil 64 und einen Schlussteil 65.
-
In 3 bis 6 sind dominante Bits mit einer breiten Linie am unteren Rand des Rahmens 60 dargestellt. Rezessive Bits sind in 3 bis 6 mit einer breiten Linie am oberen Rand des Rahmens 60 dargestellt.
-
Wie in 3 gezeigt, hat die zugehörige Kommunikationssteuereinrichtung 11, 21, 31 des Senders den Rahmens 60 derart erstellt, dass das SOF-Bit, das RRS-Bit, das IDE-Bit und das res-Bit dominant sind, wohingegen das FDF-Bit und der CRC-Delimiter CRC-Del rezessiv sind.
-
4 zeigt einen von einer der Teilnehmerstationen 10, 20, 30 gesendeten Rahmen 600 mit mehr als 16 Datenbytes im CAN FD-Basisformat. Der Rahmen 600 ist bis auf ein im Vergleich zu dem Datenfeld 64 längeres Datenfeld 640 und ein im Vergleich zu dem Prüfsummenfeld 65 längeres Prüfsummenfeld 650 auf die gleiche Weise aufgebaut wie der Rahmen 60 von 3. Der Rahmen 600 hat einen Kopfteil 61 bis 63, einen Datenteil 640 und einen Schlussteil 650.
-
5 zeigt einen von einer der Teilnehmerstationen 10, 20, 30 gesendeten Rahmen 70 mit bis zu 16 Datenbytes im CAN FD Erweiterten Format (CAN FD Extended Format). Gemäß 5 hat der Rahmen 70 ein SOF-Bit 71 sowie mehrere Rahmenfelder, wie ein Arbitrationsfeld 72 (Arbitration field), ein Control Feld 73 (Control field), ein Datenfeld 74 (Data field) und ein Prüfsummenfeld 75 (CRC field). Das Arbitrationsfeld 72 umfasst in dem base-ID-Feld und dem ID-ext-Feld einen Identifizierer (Identifier) des Rahmens 70. Zwischen dem base-ID-Feld und dem ID-ext-Feld sind ein SRR-Bit und ein IDE-Bit vorgesehen. Am Ende des Arbitrationsfelds 72 ist ein RRS-Bit angeordnet. Das Control Feld 73 beginnt mit einem FDF-Bit, gefolgt von einem res-Bit. Darauf folgt ein BRS-Bit und ein ESI-Bit. Das Control Feld 73 endet mit dem DLC-Feld. Das Datenfeld 74 ist nicht vorhanden, wenn das DLC-Feld des Control Felds 73 den Wert 0 hat. Ansonsten ist der Rahmen 70 auf die gleiche Weise aufgebaut wie der Rahmen 60 von 3 und hat eine entsprechende Arbitrationsphase 77 und Datenphase 78. Der Rahmen 70 hat einen Kopfteil 71 bis 73, einen Datenteil 74 und einen Schlussteil 75.
-
Wie in 5 gezeigt, hat die zugehörige Kommunikationssteuereinrichtung 11, 21, 31 des Senders den Rahmen 70 derart erstellt, dass das SOF-Bit, das RRS-Bit und das res-Bit dominant sind, wohingegen das SRR-Bit, das IDE-Bit und der CRC-Delimiter CRC-Del rezessiv sind.
-
6 zeigt einen von einer der Teilnehmerstationen 10, 20, 30 gesendeten Rahmen 700 mit mehr als 16 Datenbytes im CAN FD Erweiterten Format (CAN FD Extended Format). Der Rahmen 700 ist bis auf ein im Vergleich zu dem Datenfeld 74 längeres Datenfeld 740 und ein im Vergleich zu dem Prüfsummenfeld 75 längeres Prüfsummenfeld 750 auf die gleiche Weise aufgebaut wie der Rahmen 70 von 5. Der Rahmen 700 hat einen Kopfteil 71 bis 73, einen Datenteil 740 und einen Schlussteil 750.
-
Damit ein Empfänger, beispielsweise die Teilnehmerstation 20, erkennen kann, ob der Identifier 62, 72 eines empfangenen CAN FD Rahmens 60, 70, 600, 700 durch ein fehlerhaft abgetastetes Start-of-Frame Bit 61, 71 verfälscht wurde, wird vom Sender, beispielsweise der Teilnehmerstation 10, bei den betroffenen Botschaften oder Rahmen 60, 70, 600, 700 eine Information über den Inhalt der von diesem Effekt betroffenen ersten vier Bits ID28-ID25 des Identifiers 62, 72 als Teilabschnitt des Rahmens 60, 70, 600, 700 in einem Bit außerhalb des Datenfeldes 64, 74, 640, 740 abgelegt, beispielsweise im RRS-Bit des CAN FD Rahmens 60, 70, 600, 700. Diese Information ist z.B. RRS = 1 für 0001 und RRS = 0 für 0000. In allen anderen Fällen wird das RRS-Bit wie bisher vorgesehen dominant übertragen, wie in 3 bis 6 dargestellt.
-
Ganz allgemein kann auch hier der Teilabschnitt, dessen Information in einem Bit außerhalb des Datenfeldes 64, 74, 640, 740 abgelegt wird, mit demjenigen Bit enden, nach welchem vom Sender frühestens ein Stuff-Bit in den Rahmen 60, 70, 600, 700, eingefügt wird.
-
In einer Modifikation des zweiten Ausführungsbeispiels ist die Information für das RRS-Bit vorgesehen als RRS = 0, wenn die ersten vier Bits 28 bis 25 des Identifiers 62, 72, anders ausgedrückt ID28-ID25, als Teilabschnitt des Rahmens 60, 70, 600, 700 einen Wert von 0001 haben, und RRS = 1, wenn die ersten vier Bits 28-25 des Identifiers 62, 72 einen Wert von 0000 haben.
-
Zur Überprüfung des korrekten Empfanges der ersten vier Bits des Identifiers 62, 72 prüft oder stellt der Empfänger in einem entsprechenden Verfahren zunächst fest, ob in dem von ihm empfangenen Datenrahmen 60, 70, 600, 700 für den Identifier 62, 72 für (ID28, ID27, ID26) = 000 vorliegt, wobei (ID28, ID27, ID26) den Bits 28 bis 26 in base ID entspricht.
-
Ergibt diese Prüfung oder Feststellung, dass (ID28, ID27, ID26) ungleich 000 ist, wird keine weitere Prüfung vorgenommen.
-
Ergibt die Prüfung oder Feststellung jedoch, dass (ID28, ID27, ID26) gleich 000 ist, vergleicht der Empfänger den Inhalt von Bit 25 des Identifiers 62, 72, also ID25, mit dem Inhalt des RRS-Bits im von dem Empfänger empfangenen Datenrahmen 60, 70, 600, 700.
-
Bei Ungleichheit wird der empfangene Rahmen 60, 70, 600, 700 verworfen bzw. für gültig bewertet, d.h. der Empfänger sendet einen Error Flag.
-
Bei Übereinstimmung wird der Rahmen 60, 70, 600, 700 nicht verworfen bzw. für gültig bewertet.
-
Bei der oben genannten Modifikation des zweiten Ausführungsbeispiels sind die beiden zuvor genannten Maßnahmen, die für Ungleichheit und Übereinstimmung vorgesehen sind, entsprechend umgekehrt. Das heißt, bei Übereinstimmung wird der empfangene Rahmen 60, 70, 600, 700 verworfen, d.h. der Empfänger sendet einen Error Flag. Und bei Ungleichheit wird der Rahmen 60, 70, 600, 700 nicht verworfen.
-
In einer weiteren Modifikation des zweiten Ausführungsbeispiels wird zusätzlich das noch übrige bzw. nicht belegte „res“ Bit und/oder das „ESI“-Bit mit herangezogen und F1 und F2 verwendet. Diese Bits sind zuvor in Bezug auf das erste Ausführungsbeispiel und dessen Modifikationen genauer beschrieben.
-
Es ist jedoch auch möglich, nach dem ESI-Bit noch ein oder mehr zusätzliche Bits für die Übertragung der Information, z.B. F1 und F2, einzufügen.
-
Das RRS Bit wird in CAN FD Rahmen 60, 70, 600, 700 an derselben Position übertragen, an denen in Classic CAN Rahmen das RTR Bit übertragen wird.
-
Die Arbeitsversion des ISO-Standards zu CAN FD (ISO 11898-1) sieht vor, dass RRS-Bits nur in CAN FD Rahmen 60, 70, 600, 700 vorgesehen sind, wobei das RRS-Bit in CAN FD Rahmen 60, 70, 600, 700 an der Position des RTR-Bits in Classic CAN Rahmen gesendet werden soll und das RRS-Bit dominant gesendet werden soll, jedoch Empfänger rezessive und dominante RRS-Bits akzeptieren sollen. („RRS bit [only in FD Frames] The RRS bit shall be transmitted in FD Frames at the position of the RTR bit in Classical Frames. The RRS bit shall be transmitted dominant, but receivers shall accept recessive and dominant RRS bits.”)
-
Da zum Zeitpunkt der Übertragung des RRS-Bits für den Empfänger noch nicht feststeht, ob es sich bei dem empfangenen Rahmen 60, 70, 600, 700 bzw., des empfangenen Rahmens um einen Classic CAN oder um einen CAN FD Rahmen 60, 70, 600, 700 bzw. Nachricht handelt, kann die Auswertung erst nach Übertragung von zwei weiteren Bits (IDE Bit und FDF Bit) für Basic Format (Rahmen 60, 600), bzw. eines weiteren Bits (FDF Bit) für Extended Format (Rahmen 70, 700) durchgeführt werden.
-
Das RTR- bzw. RRS-Bit wird bei der Arbitrierung um den Buszugriff mitberücksichtigt. Dies führt jedoch nicht zu Problemen, weil: Wenn gleichzeitig von zwei verschiedenen Teilnehmern die Übertragung zweier Rahmen gestartet wird, wobei ein Rahmen, beispielsweise ein Rahmen 60, mit 0000 beginnt und RRS = 0 aufweist, und wobei der andere Rahmen, beispielsweise ein Rahmen 700, mit 0001 beginnt und RRS = 1 aufweist, wird (korrekte Funktion der Sender vorausgesetzt) der erste Sender die Arbitrierung gewinnen und der Wert des RRS-Bits spielt keine Rolle für die Arbitrierung.
-
Die Verwendung des beschriebenen Verfahrens lässt sich durch das Verhalten der Teilnehmerstationen 10, 20, 30 mit Kommunikationssteuereinrichtungen 11, 21, 31 und Absicherungseinrichtungen 12, 22, 32 nachweisen.
-
Alle zuvor beschriebenen Ausgestaltungen des Bussystems 1, der Teilnehmerstationen 10, 20, 30 und des Verfahrens können einzeln oder in allen möglichen Kombinationen Verwendung finden. Insbesondere können alle Merkmale der zuvor beschriebenen Ausführungsbeispiele und/oder deren Modifikationen beliebig kombiniert oder weggelassen werden. Zusätzlich sind insbesondere folgende Modifikationen denkbar.
-
Das zuvor beschriebene Bussystem 1 gemäß den Ausführungsbeispielen ist anhand eines auf dem CAN FD Protokoll basierenden Bussystems beschrieben. Das Bussystem 1 gemäß den Ausführungsbeispielen kann jedoch auch eine andere Art von Kommunikationsnetz sein. Es ist vorteilhaft, jedoch nicht zwangsläufige Voraussetzung, dass bei dem Bussystem 1 zumindest für bestimmte Zeitspannen ein exklusiver, kollisionsfreier Zugriff einer Teilnehmerstation 10, 20, 30 auf einen gemeinsamen Kanal gewährleistet ist.
-
Die Anzahl und Anordnung der Teilnehmerstationen 10 bis 30 in dem Bussystem 1 der Ausführungsbeispiele und deren Modifikationen ist beliebig. Insbesondere können auch nur Teilnehmerstationen 10 oder 20 oder 30 in dem Bussystem 1 vorhanden sein. Es sind beliebige Kombinationen der Teilnehmerstationen 10 bis 30 in den Bussystemen 1 möglich.
-
Der Teilabschnitt 51, 62, 72 des Rahmens 50, 60, 70, 600, 700 muss nicht unbedingt die vier ersten Bits des Identifiers eines CAN FD Rahmens aufweisen. Der Teilabschnitt kann auch eine andere vorbestimmte Abfolge von Bitwerten enthalten. Die vorbestimmte Abfolge kann mindestens zwei Bits aufweisen.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Nicht-Patentliteratur
-
- ISO11898-1 [0001]
- http://www.semiconductors.bosch.com/ [0001]
- ISO11898-1 [0048]
- ISO-CD-11898-1 [0054]
- ISO 11898-1 [0074]
