-
Die vorliegende Erfindung betrifft ein Verfahren zur Fehlererkennung und Fehlerkorrektur in Bussystemen, sowie eine Vorrichtung.
-
Ausführungsformen der vorliegenden Erfindung beziehen sich auf ein Verfahren zur Datenübertragung in Bussystemen. Einige Ausführungsformen umfassen ein Codieren mindestens der Nutzdaten eines Datenrahmens durch ein ECC-Verfahren und ein Codieren mindestens der Nutzdaten des Datenrahmens durch ein CRC-Verfahren. Spezifischer umfassen einige Ausführungsformen das Erstellen von ECC-Prüfzeichen und von CRC-Prüfzeichen, die zusammen mit den Nutzdaten in dem Datenrahmen übertragen werden. Dabei kann, gemäß einer oder mehreren Ausführungsformen, der Zustand eines Steuerzeichens festlegen, ob eine ECC-Codierung vorgenommen wird oder nicht. Weitere Ausführungsformen sind auf ein Sende- und/oder Empfangsgerät zur Datenübertragung in Bussystemen gerichtet. Noch weitere Ausführungsformen sind auf ein Rahmenformat zur Datenübertragung in Bussystemen gerichtet.
-
Die sichere Datenübertragung stellt ein wichtiges Merkmal für Bussysteme in sicherheitsrelevanten Anwendungen wie beispielsweise im Automotive-Bereich dar. Zur Erkennung von Fehlern werden üblicherweise redundante Informationen zugefügt und beim Empfang der übertragenen Daten ausgewertet. Für sichere Bussysteme im Automotive-Bereich wie CAN oder FlexRay basiert die Fehlererkennung auf einer CRC-Berechnung (CRC: Cyclic Redundancy Check = zyklische Redundanzprüfung, auch: Cyclic Redundancy Code = zyklischer Redundanzcode).
-
In einem vorgegebenen Bussystem wird üblicherweise das gleiche CRC-Polynom für Datentelegramme unterschiedlicher Länge verwendet. Dadurch entsteht der Nachteil, dass kürzere Datentelegramme besser als längere geschützt werden. Für CAN-Bussysteme kann ein Datentelegramm eine Länge von bis zu 8 Bytes aufweisen. Somit bietet die herkömmliche Verwendung der gleichen 16-bit CRC-Berechnung den besten Schutz für das kürzeste Datentelegramm von einem Byte und den schlechtesten Schutz für die längste Botschaft von 8 Bytes an. Diese Feststellung hinsichtlich der Schutzminderung der CRC-Berechnung trifft insbesondere für FlexRay Bussysteme zu, da Paketlängen von bis zu 254 Bytes unterstützt werden. Die 24-bit CRC-basierte Überprüfung von Nutzdaten schützt 2-Byte lange Pakete viel besser als 254-Byte lange Datentelegramme. Diese Feststellung lässt sich anhand der Hamming-Distanz in FlexRay-Bussystemen verdeutlichen. Die 24-Bit FlexRay-CRC bietet eine Hamming-Distanz von 6 für Datenpakete von bis zu 246 Bytes an. Für Datenpakete länger als 246 Bytes wird eine kleinere Hamming-Distanz von 4 ermittelt. Der informationstheoretische Abstand, hier quantifiziert durch die Hamming-Distanz, sinkt also für solche langen Datenpakete gegenüber kurzen Datenpaketen. Die Wahrscheinlichkeit, dass ein Bitfehler von der 24-bit CRC-Überprüfung nicht erkannt wird, ist somit höher für eine lange Datenbotschaft von 254 Bytes als für ein kurzes Datentelegramm von nur 2 Bytes.
-
Ein anderes Problem, das vorwiegend bei der Übertragung von langen Datentelegrammen auftreten kann, ist eine Minderung der Verfügbarkeit nach Fehlererkennung mittels der CRC-Berechnung. Nachdem ein CRC-Fehler erkannt wird, wird dies dem Sender mitgeteilt, welcher das betroffene Datentelegramm erneut senden muss. Jede wiederholte Sendung von Datenpaketen (und insbesondere von langen Datentelegrammen) mindert die Verfügbarkeit des Übertragungsmediums.
-
Gleichzeitig bieten lange Datenpakete Vorteile für verschiedene Anwendungen an. Werden in Bussystemen nur sehr kurze Datentelegramme übertragen, führt dies zu einer sehr schlechten Effizienz der Übertragung von Nutzdaten. Daher besteht ein Bedürfnis, solche langen Datentelegramme zu übermitteln.
-
Dieser Erfindung liegt als eine Aufgabe zugrunde, den Schutz für die Übertragung von langen Datenpaketen in sicheren Bussystemen zu verbessern und dabei eine Beeinträchtigung der Verfügbarkeit des Übertragungsmediums möglichst zu vermeiden.
-
Im Hinblick auf die zuvor genannten Probleme werden ein Verfahren gemäß dem unabhängigen Anspruch 1, ein Rahmenformat oder die Verwendung eines solchen gemäß unabhängigem Anspruch 7, ein Sender gemäß unabhängigem Anspruch 8 und ein Empfänger gemäß dem unabhängigen Anspruch 10 bereitgestellt. Weitere vorteilhafte Ausbildungen, die in geeigneter Weise beliebig miteinander kombiniert werden können, sind den abhängigen Ansprüchen, den Zeichnungen und der Beschreibung zu entnehmen.
-
Nach einer Ausführungsform wird ein Verfahren zur Übertragung eines Datenrahmens in einem Bussystem bereitgestellt. Dabei umfasst der Datenrahmen einen Header-Bereich, einen Nutzdatenbereich und einen CRC-Prüfdatenbereich. Header-, Nutz- und CRC-Prüfdaten weisen jeweils eine vorbestimmte Maximallänge auf. Zumindest die Nutzdatenlänge ist variabel. Das Verfahren umfasst Bereitstellen von Nutzdaten und Bereitstellen von Header-Daten, wobei die Header-Daten ein Steuerzeichen umfassen. Das Steuerzeichen kann mindestens einen ersten und einen zweiten Steuerzustand einnehmen. Das Verfahren umfasst weiter Codieren mindestens der Nutzdaten durch ein ECC-Verfahren, wenn das Steuerzeichen den ersten Steuerzustand einnimmt, und Codieren mindestens der Nutzdaten durch ein CRC-Verfahren. Weiter umfasst das Verfahren Senden der Daten des Datenrahmens über das Bussystem, wobei der codierte Datenrahmen mindestens das Steuerzeichen im Klartext enthält.
-
Nach einer weiteren Ausführungsform wird ein Rahmenformat für einen Datenrahmen in einem Bussystem zur Verfügung gestellt. Das Rahmenformat umfasst einen Header-Bereich für Header-Daten, einen Nutzdatenbereich und einen CRC-Prüfdatenbereich für Prüfzeichen eines zyklischen Redundanzcodes CRC. Des Weiteren umfasst das Rahmenformat im Header-Bereich ein Steuerzeichen zur Schaffung eines ECC-Prüfdatenbereichs für Prüfzeichen eines Fehlerkorrekturcodes ECC in dem Nutzdatenbereich. Dabei weist der Nutzdatenbereich eine Maximallänge auf, so dass bei Schaffung des ECC-Prüfdatenbereichs in dem Nutzdatenbereich die Maximallänge den Nutzdaten und Prüfzeichen des Fehlerkorrekturcodes ECC nur gemeinschaftlich zur Verfügung steht.
-
Optional kann das Rahmenformat ein bekanntes Rahmenformat modifizieren, wobei das bekannte Rahmenformat optional ausgewählt ist aus einer Gruppe bestehend aus: CAN-Rahmenformaten und FlexRay-Rahmenformaten. Die gemeinsame Maximallänge des Nutzdatenbereichs kann z. B. 254 Bytes für das FlexRay-Rahmenformat oder 8 Bytes für CAN-Rahmenformate betragen. Eine andere Ausführungsform ist auf die Verwendung dieses Rahmenformats gerichtet.
-
Nach einer weiteren Ausführungsform wird ein Sender zur Übertragung eines Datenrahmens in einem Bussystem bereitgestellt. Der Datenrahmen umfasst einen Header-Bereich, einen Nutzdatenbereich und einen CRC-Prüfdatenbereich. Die Header-, Nutz- und CRC-Prüfdaten weisen jeweils eine vorbestimmte Maximallänge auf. Zumindest die Nutzdatenlänge ist variabel. Der Sender umfasst eine Datenbereitstellungseinheit zur Bereitstellung eines Datenteils des Datenrahmens. Dabei kann der Datenteil optional mindestens Header- und Nutzdaten umfassen. Der Sender umfasst weiter eine ECC-Codiereinheit, die eingerichtet ist, den Datenteil einer ECC-Codierung zu unterziehen. Die ECC-Codierung kann optional aus dem Datenteil und ECC-Prüfzeichen bestehen. Der Sender umfasst des Weiteren eine CRC-Codiereinheit, die eingerichtet ist, die ECC-Codierung einer CRC-Codierung zu unterziehen. Die CRC-Codierung kann optional aus der ECC-Codierung und CRC-Prüfzeichen bestehen. Die Datenbereitstellungseinheit, die ECC-Codiereinheit und die CRC-Einheit sind schaltungstechnisch verbunden, optional zur seriellen Codierung.
-
Nach einer weiteren Ausführungsform wird ein Empfänger zur Übertragung eines Datenrahmens in einem Bussystem bereitgestellt. Der Datenrahmen umfasst einen Header-Bereich, einen Nutzdatenbereich und einen CRC-Prüfdatenbereich. Die Header-, Nutz- und CRC-Prüfdaten weisen jeweils eine vorbestimmte Maximallänge auf. Zumindest die Nutzdatenlänge ist variabel. Der Empfänger umfasst eine CRC-Decodiereinheit, die eingerichtet ist, aus dem Bussystem empfangene Daten einer CRC-Decodierung zu unterziehen und ein CRC-Fehlersyndrom zu ermitteln, und eine ECC-Decodiereinheit, die eingerichtet ist, mindestens einen Teil der aus dem Bussystem empfangenen Daten einer ECC-Decodierung zu unterziehen und ein ECC-Fehlersyndrom zu ermitteln. Der Empfänger umfasst weiter eine Prüfeinheit, die eingerichtet ist, die aus dem Bussystem empfangenen Daten zu behalten oder zu verwerfen auf Basis einer gemeinsamen Prüfung des ECC-Fehlersyndroms und des CRC-Fehlersyndroms.
-
Eine weitere Ausführungsform ist auf ein Sende-Empfangs-System zur Übertragung eines Datenrahmens in einem Bussystem gerichtet. Das Sende-Empfangs-System umfasst einen Sender gemäß hierin beschriebenen Ausführungsformen und/oder einen Empfänger gemäß hierin beschriebenen Ausführungsformen und einen Datenbus, eingerichtet zur Verbindung von Sender und Empfänger.
-
Einige der oben erwähnten und weitere detaillierte Aspekte werden in der Beschreibung näher bezeichnet und zumindest teilweise mit Bezug auf die Abbildungen erläutert.
-
1 zeigt ein Rahmenformat gemäß einer oder mehreren Ausführungsformen;
-
2 zeigt Rahmenformate gemäß einer oder mehreren Ausführungsformen;
-
3 zeigt einen Sender zur Übertragung von Datenrahmen in einem Bussystem gemäß einer oder mehreren Ausführungsformen;
-
4 zeigt eine ECC-Generatormatrix gemäß einer oder mehreren Ausführungsformen;
-
5 zeigt einen Empfänger zur Übertragung von Datenrahmen in einem Bussystem gemäß einer oder mehreren Ausführungsformen;
-
6 illustriert ein Verfahren zur Fehlererkennung und Fehlerkorrektur für aus einem Bussystem empfangene Datenrahmen einer oder mehreren Ausführungsformen.
-
Innerhalb von Beschreibungen der Abbildungen beziehen sich gleiche Referenzzeichen auf gleiche oder ähnliche Komponenten. Im Allgemeinen werden nur die Unterschiede zwischen einzelnen Ausführungsformen beschrieben. Die Abbildungen sind nicht notwendigerweise maßstabsgetreu und dienen der Illustration.
-
Im Folgenden werden zunächst spezielle Ausführungsformen beschrieben, bei denen im Hinblick auf eine praktische Verwendung eine Kompatibilität mit bekannten Bussystemen wie beispielsweise CAN und FlexRay im Vordergrund steht. Dies ist jedoch nicht als Einschränkung zu verstehen. Im Anschluss werden einige mögliche Erweiterungen diskutiert.
-
1 und 2 zeigen den Aufbau des Flex-Ray-Rahmenformats 1 und von zwei CAN-Rahmenformaten, nämlich des CAN-Basisrahmenformats 2 und des erweiterten CAN-Rahmenformats 3. Für den Begriff Rahmenformat ist auch der englische Ausdruck „frame format” gebräuchlich, für Datentelegramm oder Datenrahmen auch der englische Ausdruck „data frame” oder nur „frame”. Die Rahmenformate sehen für die Datenrahmen einen Headerbereich, einen Nutzdatenbereich („Payload”) und einen CRC-Prüfdatenbereich („CRC trailer”, auch Rahmen-CRC oder „frame CRC”) vor. Prüfzeichen des CRC-Prüfdatenbereichs, bei denen es sich um Prüfbits handeln kann, werden in den FlexRay- und CAN-Formaten aus den Header- und Nutzdaten berechnet, wodurch Übertragungsfehler in den letzteren erkannt werden können. Der CRC-Prüfdatenbereich ist in 1 von dem dort gezeigten Unterbereich „Header CRC” verschieden, der nur Teile des Headers absichert, selbst aber durch den CRC-Prüfdatenbereich abgesichert wird.
-
In den FlexRay- und CAN-Rahmenformaten ist gegenwärtig 1 Bit für zukünftige Anwendungen reserviert. Es handelt sich um das erste Bit 1a eines FlexRay-Telegramms oder um das r0 Bit 2a, 3a eines CAN-Datentelegramms. Für CAN-Bussysteme mit einer erweiterten Kennung von 29 Bits steht auch das Bit r1 (3b) zukünftigen Anwendungen zur Verfügung.
-
Gemäß einer oder mehreren Ausführungsformen wird in jedem Datentelegramm ein Steuerzeichen verwendet. Das Steuerzeichen wird im Folgenden als Steuerbit bezeichnet. Dies soll nicht als Einschränkung auf ein binäres Alphabet verstanden werden. Das Steuerbit kann in einer vorhandenen, beispielsweise ungenutzten Bitposition eines Datenrahmens gesetzt werden. Bei FlexRay- oder CAN-Rahmenformaten, kann dies z. B. das bislang reservierte Bit sein. Das Steuerbit soll festlegen, ob eine Erweiterung der herkömmlichen Schutzmechanismen in einem Datentelegramm eingeschlossen ist. Falls dieses Steuerbit gesetzt ist, werden bestimmte Bitpositionen zur Fehlererkennung und Fehlerkorrektur verwendet werden. Wenn dieses Steuerbit nicht gesetzt ist, kann das Datentelegramm z. B. herkömmlichen Spezifikationen entsprechen, wobei nur eine Fehlererkennung möglich ist. Herkömmliche Schutzmechanismen können auch das Steuerbit abdecken. Dann kann ein fehlerhaftes Steuerbit mittels der herkömmlichen Schutzmechanismen erkannt werden.
-
Gemäß einer oder mehreren Ausführungsformen werden also diese reservierten Bits als Signalisierungsmittel (Steuerbits) für das Anwenden, bzw. die Verfügbarkeit einer ECC-Codierung in einem FlexRay- oder CAN-Datentelegramm (ECC: Error Checking and Correction = Fehlerprüfung und -korrektur, auch Error Correcting Code = Fehlerkorrekturcode) verwendet.
-
Die vorgeschlagene Schutzerweiterung und die herkömmlichen Schutzmechanismen können sich gemäß einer oder mehreren Ausführungsformen gegenseitig überwachen. Die Schutzerweiterung kann vorzugsweise so konzipiert werden, dass Sicherheitslücken von herkömmlichen Schutzmechanismen möglichst geschlossen werden. Weiterhin kann die Schutzerweiterung ein Verfahren zur Fehlerkorrektur unterstützen, um eine bessere Verfügbarkeit von übertragenen Daten gewährleisten zu können.
-
Die Fehlererkennung in Bussystemen wie beispielsweise CAN und FlexRay basiert im Automotive-Bereich oft auf einer CRC-Überprüfung. Gemäß hierin beschriebenen Ausführungsformen wird ein ECC-Verfahren als geeignete Erweiterung der CRC-basierten Schutzmechanismen verwendet. Typischerweise wird gemäß einer oder mehreren Ausführungsformen eine Blockcodierung im ECC-Verfahren verwendet, z. B. zyklische fehlerkorrigierende Codes wie BCH-Codes (Bose-Chaudhuri-Hocquenghem-Codes), die als Spezialfälle RS-Codes (Reed-Solomon-Codes) enthalten. Es können aber auch Hamming-Codes oder andere Codes verwendet werden.
-
Ein lineares (n, k) ECC-Codierungsschema lässt sich anhand einer Generatormatrix G oder einer Paritätsprüfungsmatrix (Parity Check Matrix) H festlegen. Die Generatormatrix G kann von der Paritätsprüfungsmatrix P für systematische ECC-Codeworte wie folgt abgeleitet werden (und umgekehrt): GkxnH T / (n-k)xn = 0 Gkxn = [Ik|Pkx(n-k)], H(n-k)xn = [P T / kx(n-k)|In-k] wobei P eine Matrix mit k Zeilen und (n – k) Spalten ist und Ik eine (k × k) Einheitsmatrix bezeichnet.
-
Für jede Nachricht oder jedes Speicherwort w der Länge k wird ein Codewort c der Länge n durch die Zusammenfügung des errechneten (n – k) langen Prüfvektors p gebildet. Jedes gültiges Codewort erfüllt die folgende Bedingung: c1xnH T / (n-k)xn = 0.
-
Jeder bei der Speicherung oder bei der Datenübertragung auftretende Fehler kann mittels eines Fehlervektors e der Länge n dargestellt werden. Bei der Multiplikation des fehlerbehafteten Codewortes (c xor e) mit der Parity-Check-Matrix H ergibt sich ein Syndrom s der Länge (n – k), anhand dessen die Fehlerkorrektur oder Fehlererkennung durchgeführt wird: (c xor e)1xnH T / (n-k)xn = s1x(n-k).
-
Eine 22,16 ECC Generatormatrix 35 ist in 4 beispielhaft dargestellt.
-
Wie oben erwähnt, wird in CAN- und FlexRay-Systemen bislang jeweils 1 Bit für zukünftige Anwendungen reserviert. Dieses reservierte Bit wird in einer oder mehreren Ausführungsformen vorzugsweise als Steuerbit für die Erweiterung der herkömmlichen Schutzmechanismen verwendet. Falls dieses Bit gesetzt ist, können z. B. Bits oder Bytes der Nutzdaten, typischerweise die letzten Bits oder Bytes der Nutzdaten, als ECC-Prüfzeichen, im Weiteren auch als ECC-Prüfbits bezeichnet, dienen. Die Anzahl von ECC-Prüfbits hängt typischerweise von der ECC-Schutzstrategie ab. Es können z. B. 1 Bit bis 6 Bytes der Nutzdaten als ECC-Prüfbits dienen, typischerweise 1 Byte bis 4 Bytes, noch typischer 1 Byte bis 2 Bytes.
-
In einer oder mehreren Ausführungsformen wird der ECC-Algorithmus so ausgewählt, dass die ECC-Überprüfung die Wahrscheinlichkeit von Restfehlern der CRC-Berechnung weiter mindert. Die Wahrscheinlichkeit von nicht erkannten Fehlern der CRC-Berechnung steigt typischerweise mit der Länge der übertragenen Botschaft an. Unter Umständen kann man systematisch dafür sorgen, dass das Zusammenwirken der zwei Fehlererkennungsverfahren ECC und CRC eine höhere minimale Hamming-Distanz als die herkömmliche CRC-Überprüfung erzielt. Beispielsweise bietet die herkömmliche CRC-Überprüfung von FlexRay-Nutzdaten eine minimale Hamming-Distanz von 6 für eine Datenlänge von bis zu 246 Bytes. Für mehr als 246 Bytes (bis 254 Bytes) an Nutzdaten in einem FlexRay-Datentelegramm schrumpft die minimale Hamming-Distanz auf 4. Solche Datentelegramme werden als lang bezeichnet. Allgemein können Datentelegramme oder Datenrahmen (englisch: „data frame” oder „frame”) hier als lang bezeichnet werden, wenn für sie eine Verminderung eines informationstheoretischen Abstandmaßes wie z. B. der Hamming-Distanz gegenüber kürzeren Datenrahmen einhergeht, z. B. wenn dieses Maß auf oder unter eine Mindestgrenze (oben: 4) abfällt. Für solche langen Datentelegramme stellt die vorgeschlagene Erweiterung der herkömmlichen Schutzmechanismen einen großen Vorteil dar, indem die minimale Hamming-Distanz vergrößert wird. Jedoch ergeben sich die Vorteile des erhöhten Schutzes für längere Botschaften auch ohne das Eintreten einer Verringerung eines Abstandsmaßes des Codes. Beispielsweise ergibt sich für die maximal 8 Byte langen Botschaften im CAN-Format kein Abfall der Hammingdistanz gegenüber kürzeren Botschaften. Dennoch sind 8 Byte lange Botschaften fehleranfälliger als kürzere und werden durch die vorgeschlagene Erweiterung nun besser geschützt. Durch größere Fehlertoleranz kann dadurch z. B. die Verfügbarkeit des Bussystems erhöht werden. Es können beispielsweise die letzten 1 oder 2 Bytes der Nutzdaten als ECC-Prüfbits verwendet werden. Der ECC-Algorithmus kann so ausgelegt werden, dass CRC-Fehlermuster für Botschaften mit kleineren Hamming-Distanzen mittels der ECC-Überprüfung erkannt werden.
-
Wird eine ECC-basierte Fehlerkorrektur allein eingesetzt, so liegt ein bekannter Nachteil in der Möglichkeit einer falschen Korrektur bei bestimmten Fehlermustern. Für typische ECC-Algorithmen können manche Fehler in einer ungeraden Anzahl von Bitpositionen fälschlicherweise als Ein-Bit-Fehler erkannt werden.
-
Dieser Nachteil wird gemäß einer oder mehreren Ausführungsformen durch die gegenseitige Überwachung CRC und ECC behoben. Dabei können CRC und ECC zwei diversitäre und/oder komplementäre Fehlererkennungsmechanismen sein. Eine Fehlerkorrektur wird z. B. nur dann als einwandfrei betrachtet, wenn ein Fehler zuerst von den zwei unabhängigen Überwachungsmechanismen (CRC und ECC) erkannt wird. Insbesondere kann nach einer oder mehreren Ausführungsformen die ECC-Codierung von der CRC-Codierung unabhängig sein. Unabhängig bedeutet dabei, dass zumindest einige Fehler oder Fehlerarten, vorzugsweise alle Fehler oder Fehlerarten, die der CRC-Codierung entgehen, von der ECC-Codierung entdeckt werden oder Fehler/Fehlerarten, die der ECC-Prüfung-entgehen, von der CRC-Codierung entdeckt werden, oder beides.
-
Anschließend kann eine CRC-Überprüfung überprüfen, ob ein vermittels ECC korrigiertes Datentelegramm auch tatsächlich richtig korrigiert wurde. Diese nachträglich durchgeführte CRC-Berechnung wird vorzugsweise nicht in Form einer seriellen Berechnung des empfangenen Bitstroms durchgeführt, sondern in Form einer Verknüpfung von CRC-Codeworten. Hierbei kann die Eigenschaft verwendet werden, wonach sich ein gültiges CRC-Codewort aus einer XOR-Verknüpfung von zwei gültigen CRC-Codeworten ergibt. Typischerweise wird die Anzahl von zu korrigierenden Bitfehlern und/oder Bitstellen gering gehalten (z. B. 1 Bit oder 2 Bit), um einen höheren Aufwand für die Fehlerkorrektur zu vermeiden. Es können z. B. einfache Vektoren für die Korrektur im Vorfeld vorbereitet werden, indem Ihre CRC-Prüfbits, im Weiteren auch als CRC-Prüfbits bezeichnet, in eine Tabelle abgelegt werden. Diese für die Korrektur zu verwendenden Vektoren bestehen vorwiegend aus Null-Bits bis auf die wenigen, zu korrigierenden Bitpositionen.
-
Nach einer oder mehreren Ausführungsformen berechnet die ECC-Überprüfung auf der Basis der empfangenen Nutzdatenbits und ECC-Prüfbits ein ECC-Syndrom. Anhand dieses ECC-Syndroms bestimmt der ECC-Algorithmus, ob die Nutzdaten fehlerfrei sind. Falls ein Bitfehler erkannt wird, kann der ECC-Algorithmus feststellen, ob der Fehler korrigierbar ist. Für jeden korrigierbaren Fehler ermittelt der ECC-Algorithmus eindeutig den Vektor, der zur Fehlerkorrektur dienen kann.
-
An dieser Stelle kann der herkömmliche ECC-Algorithmus vorzugsweise so erweitert werden, dass CRC-Prüfbits für den für die Fehlerkorrektur zu verwendenden Vektor (beispielsweise aus einer Tabelle) ausgegeben werden. Diese CRC-Prüfbits der ECC-Korrekturvektoren können dann für die nachträgliche Überprüfung einer erfolgreichen Fehlerkorrektur in Betracht gezogen werden. Im Falle einer gelungenen Korrektur sollten sich die für die empfangenen Nutzdatenbits berechneten CRC-Prüfbits als XOR-Verknüpfung der CRC-Prüfbits des ECC-Korrekturvektors mit den CRC-Prüfbits der korrigierten Nutzdaten erweisen.
-
Das beschriebene Verfahren kann vorzugsweise für alle Datenübertragungsprotokolle angewandt werden, bei denen lange Datentelegramme mittels der CRC-Überprüfung geschützt werden.
-
Gemäß einer oder mehreren Ausführungsformen kann eine möglicherweise noch bessere Verfügbarkeit der Daten erzielt werden, indem das Protokoll eine ECC-Berechnung auch für die CRC-Prüfbits zulässt. In diesem Fall werden die ECC-Prüfbits nach den CRC-Prüfbits übertragen, damit der Empfänger auch CRC-Prüfbits mittels ECC korrigieren kann.
-
Generell können die Daten eines Datenrahmens seriell verarbeitet werden. Beispielsweise kann die CRC-Codierung und/oder die ECC-Codierung seriell ausgeführt werden. Ebenso können andere Operationen der Übertragung des Datenrahmens seriell ausgeführt werden. Ein serielles Codieren kann dabei umfassen, einen seriellen Bitstrom mindestens der Nutzdaten, ggf. auch der Headerdaten, on-the-fly zu codieren. Dabei bedeutet „on-the-fly”, dass die Zwischenergebnisse der Codierung in Form von vorläufigen Prüfbits für jedes seriell gesendete Bit erzeugt und aktualisiert werden. Nach dem letzten Bit der Nutzdaten stellt die Aktualisierung der vorläufigen Prüfbits die endgültigen Prüfbits dar, welche an den Datenstrom angehängt werden. Nutz- und Headerdaten können im Klartext in der ECC- und/oder CRC-Codierung vorliegen. Dabei bedeutet „im Klartext”, dass die Zeichenwerte (Bitwerte) der Nutz- und Headerdaten nicht verändert werden, es kommen lediglich Prüfzeichen bzw. Prüfbits hinzu. Ein serielles Verfahren kann z. B. die elektronische Schaltung einfach und effizient machen.
-
In einer oder mehreren Ausführungsformen können die Daten eines Datenrahmens parallel verarbeitet werden. Auch bei paralleler Verarbeitung können gemäß einer oder mehreren Ausführungsformen die Nutz- und/oder Headerdaten im Klartext in der ECC- und/oder CRC-Codierung vorhanden sein. In einigen Ausführungsformen ist mindestens das Steuerzeichen im Klartext in der Codierung vorhanden. Das Steuerzeichen im Klartext sorgt auf der Empfängerseite dafür, dass eine ECC-Decodierung und eine CRC-Decodierung vorgenommen werden, wenn das Steuerzeichen gesetzt ist, und nur eine CRC-Decodierung vorgenommen wird, wenn das Steuerzeichen nicht gesetzt ist. Sowohl ECC-Codierung als auch CRC-Codierung können den gesamten Datenrahmen umfassen oder Teile davon. Das heißt, die ECC- und/oder CRC-Codierung können eine Codelänge aufweisen, die gleich der (maximalen) Länge eines Datenrahmens sein kann. Vertauschen die ECC- und die CRC-Codieroperation nicht, kommt es bei der Codierung und der Decodierung auf die Reihenfolge der Operationen an. Diese kann festgelegt sein oder z. B. durch weitere Steuerzeichen bekannt gegeben werden. In parallel verarbeitenden Ausführungsformen kann die Menge der zur Verfügung stehenden Codes größer sein als in der seriell verarbeitenden Methode. Durch die größere Codeflexibilität können möglicherweise Codes verwendet werden, die besser auf bestimmte Anwendungen und zu erwartende Fehlerarten zugeschnitten sind.
-
Gemäß einer oder mehreren Ausführungsformen werden ein Sender, ein Empfänger sowie ein Sende-Empfangs-System zur Übertragung eines Datenrahmens in einem Bussystem bereitgestellt.
-
Eine Ausführungsform eines Senders ist als Beispiel in 3 veranschaulicht. In herkömmlichen Implementierungen werden Nutzdaten aus einem Puffer 21 von einem Parallel-Seriell-Wandler 22 in einen seriellen Bitstrom umgewandelt und anschließend in ein CRC-Berechnungsmodul 28 eingespeist. In der Ausführungsform nach 3 wird die CRC-Berechnung von einem ECC-Verfahren unterstützt. In 3 wird das ECC-Verfahren von einer ECC-Codiereinheit 20 ausgeführt. Hierbei werden die ECC-Bits seriell berechnet, um die Anzahl von XOR-Gattern 25a, 25b minimal zu halten. Der ECC-Zustandsautomat 23 kann die Anwendung einer ECC Generatormatrix vornehmen, indem die Spalten der Matrix sequentiell für die Berechnung von ECC-Prüfbits verwendet werden. Der ECC-Zustandsautomat 23 ist ein FSM (FSM: Finite State Machine = endlicher Zustandsautomat). Dieser ist typischerweise mit anderen FSM synchronisiert, z. B. Empfängerseitigen FSM für die ECC-Decodierung. Die ECC-Prüfbits werden dem Bitstrom hinzugefügt. Hierfür kann der Multiplexer 27 verwendet werden. Für den zu sendenden Bitstrom und die berechneten ECC-Prüfbits werden CRC-Prüfbits im CRC Modul 28 generiert. Der ECC-Zustandsautomat kann im Leerlauf bleiben, falls die ECC-Codierung nicht verwendet wird. Die Entscheidung, ob eine ECC-Codierung verwendet wird oder nicht, kann von einem Zustand oder einer Einstellung des ECC-Zustandsautomats 23 abhängen. Diese Einstellung kann vom Anwender vorgenommen und/oder geändert werden, z. B. von einem Benutzer, einem Automaten oder einem Programm. Der Wert des Steuerbits kann für den ECC-Zustandsautomaten 23 sichtbar sein. Der senderseitige ECC-Zustandsautomat 23 kann dann entscheiden, ob ECC-Prüfbits berechnet und angefügt werden. Es könnte alternativ auch eine eigene senderseitige Steuereinheit vorgesehen sein, die das Steuerbit auswertet, um dies zu entscheiden. Der ECC-Zustandsautomat 23 kann dann inaktiv oder abgeschaltet werden, wenn die eigene senderseitige Steuereinheit feststellt, dass keine ECC-Prüfbits zu berechnen sind. Die Schaltung zur Berechnung des ECC-Codes kann beispielsweise wie in 3 gezeigt ausgeführt sein. Die Einheit 24 stellt dabei das Rechenwerk des ECC-Zustandsautomats 23 dar und kann u. a. logische Gatter (xor) 25a 25b und Auswertemodule 24a, 24b basierend auf d-flip-flop Registern beinhalten. Wenn ECC Prüfbits angefügt werden, werden sie am Ausgang der Einheit 26 sichtbar und mithilfe des Multiplexers 27 in eine serielle Bitfolge umgewandelt.
-
In 4 ist eine ECC Generatormatrix 35 dargestellt. Für die Implementierung dieser Generatormatrix 35 in einem ECC-Zustandsautomaten 23 auf der Senderseite werden z. B. nur 6 XOR-Gatter (u. a. 25a, 25b) benötigt.
-
Die empfangenen Nutzdatenbits, ECC- und CRC-Prüfbits werden, wie in 5 dargestellt, weiter verarbeitet. Der Empfänger gemäß der Ausführungsform der 5 liest das ECC-Steuerbit. Das ECC-Steuerbit kann an den empfängerseitigen ECC-Zustandsautomat 43 übermittelt werden. Der ECC-Zustandsautomat 43 kann anhand des Werts des ECC-Steuerbits entscheiden, ob eine ECC-Überprüfung im Empfänger stattfinden soll. Diese Entscheidung kann auch in einer eigenen empfängerseitigen Steuereinheit geschehen. Der ECC-Zustandsautomat 43, bzw. die ECC-Decodiereinheit 40a, kann dann auf der Empfängerseite aktiviert werden, wenn das ECC-Steuerbit aktiviert ist, und ansonsten inaktiv sein oder abgeschaltet werden. Ist das ECC-Steuerbit aktiviert, werden neue ECC-Bits für den empfangenen Bitstrom berechnet und danach mit den empfangenen ECC-Prüfbits verglichen. Diese Berechnung kann beispielsweise wie in 5 gezeigt erfolgen. Die Einheiten 44 und 47 sind die Rechenwerke des ECC-Zustandsautomats 43. Die Einheit 44 soll die ECC Prüfsumme der empfangenen Bits errechnen und dann diese errechnete Prüfsumme an die Einheit 47 weitergeben. Die Einheit 47 vergleicht die errechneten ECC-Prüfbits mit der empfangenen ECC-Prüfbits (ECC-Prüfsumme) und kann somit einen ECC Fehler feststellen. Die Komponenten 45a, 49a, 49b sind XOR Gatter und die Komponenten 46a, 48a, 48b Auswertemodule basierend auf d-flip-flop Registern. Diese ECC-Überprüfung im Empfänger ermittelt somit ein ECC-Syndrom („ECC Fehler” in 5), anhand dessen eine Entscheidung über das Vorhandensein von Fehlern und die Möglichkeit zur Korrektur getroffen wird.
-
Das entsprechende Entscheidungsverfahren ist in 6 veranschaulicht. Ein Datentelegramm wird als fehlerfrei (108) betrachtet, nur wenn die CRC-Prüfung („CRC Fehler” in 5) und die ECC-Prüfung („ECC Fehler” in 5) unabhängig voneinander keinen Fehler erkennen. Eine Fehlerkorrektur kommt zustande, nur wenn ein ECC-Fehler (100) und ein CRC-Fehler (101) gemeinsam gemeldet werden. Anhand des ECC-Syndroms („ECC Fehler” in 5) legt der ECC-Algorithmus fest, ob der Fehler korrigierbar ist (103) und eine Fehlerkorrektur in einer ECC-Korrektureinheit 53 stattfindet (105). Für den ECC-Korrekturvektor der ECC-Korrektureinheit 53 werden die entsprechenden CRC-Prüfbits in einer CRC-ECC-Prüfeinheit 52 generiert und als CRC-ECC-Prüfmuster bezeichnet. Für eine einwandfrei durchgeführte Korrektur 107 soll das CRC-ECC-Prüfmuster der XOR-Verknüpfung der empfangenen (41) und der berechneten (42) CRC-Prüfbits entsprechen. ECC-Korrekturvektor und das entsprechende CRC-ECC-Prüfmuster können z. B. in Blockeinheiten 50 und 51 erzeugt werden, die in 5 parallel auf den Bitdaten operieren. Zu einer Prüfeinheit 50a, die das Verfahren wie in 6 ausführen kann, können die Blockeinheiten 50, 51 sowie die ECC-Korrektureinheit 53 und die CRC-ECC-Prüfeinheit 52 gehören. Ist die Korrektur nicht nötig, weil ECC-Prüfung 100 und CRC-Prüfung 102 keinen Fehler melden, oder erfolgreich, können valide Daten erhalten werden (108) und z. B. in einem Empfangspuffer 55 gespeichert werden, dem ein Seriell-Parallel-Wandler 54 vorgeschaltet sein kann. Andernfalls, wird ein Datenfehler gemeldet (106) und eine erneute Sendung der Daten veranlasst.
-
Nach einer oder mehreren Ausführungsformen wird ein Verfahren zur Übertragung eines Datenrahmens in einem Bussystem bereitgestellt. Das Verfahren zur Übertragung des Datenrahmens kann ein Verfahren zum Senden des Datenrahmens umfassen. Das Bussystem kann ein Bussystem für den Automotive-Bereich sein, z. B. FlexRay oder CAN. Generell kann das Verfahren oder der Datenrahmen gemäß einem Rahmenformat bereitgestellt werden, z. B. gemäß dem FlexRay-Rahmenformat oder dem CAN-Rahmenformat (CAN2.0a, CAN2.0b) sein. Dabei umfasst der Datenrahmen einen Header-Bereich, einen Nutzdatenbereich und einen CRC-Prüfdatenbereich. Header-, Nutz- und CRC-Prüfdaten weisen jeweils eine vorbestimmte Maximallänge auf. Die jeweilige Maximallänge kann durch das Rahmenformat bestimmt sein. Diese Maximallängen können z. B. für FlexRay 40 Bit für den Header, 254 Byte für die Nutzdaten und 24 Bit für die CRC-Prüfdaten sein.
-
Zumindest die Nutzdatenlänge kann variabel sein zwischen verschiedenen Datenrahmen, typischerweise zwischen 0 Bytes und der Maximallänge der Nutzdaten, z. B. von 0 bis 254 Bytes für FlexRay und von 0 bis 8 Bytes für CAN. Das Verfahren umfasst Bereitstellen von Nutzdaten und Bereitstellen von Header-Daten, wobei die Header-Daten ein Steuerzeichen umfassen. Das Steuerzeichen kann mindestens einen ersten und einen zweiten Steuerzustand einnehmen. Das Steuerzeichen kann ein Steuerbit sein, z. B. das reservierte Bit 1a bei FlexRay oder das reservierte Bit r0 2a, 3a bei CAN, oder mehrere Steuerbits, z. B. die Bits r0 und r1 3a, 3b bei CAN.
-
Die Nutzdaten des (zu übertragenden) Datenrahmens können eine (konkrete) Nutzdatenlänge aufweisen. Das Steuerzeichen kann in Abhängigkeit von der (konkreten) Nutzdatenlänge des (zu übertragenden) Datenrahmens gesetzt werden. Insbesondere kann das Bereitstellen von Header-Daten ein Setzen des Steuerzeichens in den ersten Steuerzustand umfassen, wenn die (konkrete) Nutzdatenlänge des (zu übertragenden) Datenrahmens eine Schwellenlänge übersteigt. Eine solche Botschaft, bei der die Nutzdatenlänge die Schwellenlänge übersteigt, wird generell als lang bezeichnet. Die Schwellenlänge kann durch mindestens eine der nachfolgenden Beziehungen festgelegt sein: die Schwellenlänge beträgt von 75% bis 97% der vorbestimmten Maximallänge der Nutzdaten und/oder die Schwellenlänge ist bestimmt durch die Verringerung in einem Abstandsmaß des CRC-Codes bei Übersteigen der Schwellenlänge, vorzugsweise der Verringerung der Hamming-Distanz des CRC-Codes. Die Schwellenlänge kann für FlexRay z. B. 246 Bytes sein. Bei einer konkreten Nutzdatenlänge von mehr als 246 Bytes verringert sich für einige 24-bit CRC-Codes die Hamming-Distanz von 6 auf 4. Allgemein ergibt sich die Schwellenlänge aus den Sicherheitsanforderungen für eine vorgegebene Anwendung. Der Anwender, z. B. ein Benutzer oder eine Software, kann aufgrund der Sicherheitsanforderungen an die zu übertragende Botschaft entscheiden, ob ECC verwendet wird. Beispielsweise kann einer Botschaft für Diagnosezwecke vom Anwender eine niedrigere Sicherheitsanforderung zugeschrieben werden als einer Botschaft für ein Bremssteuergerät. Dementsprechend kann der Anwender z. B. entscheiden, für die Botschaft an das Bremssteuergerät ECC einzusetzen, nicht aber für die Diagnosebotschaft, obwohl beide Botschaften von ähnlicher Länge sein mögen.
-
Das Verfahren umfasst weiter Codieren mindestens der Nutzdaten durch ein ECC-Verfahren, wenn das Steuerzeichen den ersten Steuerzustand einnimmt. Das ECC-Verfahren kann ein ECC-Blockcodierverfahren sein, insbesondere ein serielles ECC-Blockcodierverfahren. Typischerweise werden die Header- und die Nutzdaten ECC-codiert. Es können aber auch, insbesondere bei Parallelverarbeitung des Datenrahmens, die CRC-Prüfdaten durch das ECC-Verfahren codiert werden. Das ECC-Codieren kann ein Erzeugen von ECC-Prüfzeichen (Prüfbits) umfassen. Diese können auf der Basis zumindest der Nutzdaten erzeugt werden, typischerweise auf Basis der Nutz und Header-Daten. Die ECC-Prüfzeichen können in den Nutzdatenbereich ein- oder angefügt werden. Typischerweise werden die ECC-Prüfzeichen an die Nutzdaten in den Nutzdatenbereich angefügt. Mindestens das Steuerzeichen, typischerweise die Nutz- und/oder Header-Daten, kann/können im Klartext in der ECC-Codierung vorliegen. Die Summe der Länge der Nutzdaten und der ECC-Prüfzeichen ist nach einer oder mehreren Ausführungsformen höchstens gleich der, gegebenenfalls durch das Rahmenformat vorbestimmten Maximallänge der Nutzdaten. Die ECC-Prüfzeichen können eine Länge z. B. von 1% bis 30% der vorbestimmten Maximallänge der Nutzdaten aufweisen, typischerweise von 0,3% bis 3% (insbesondere für FlexRay) oder von 12,5% bis 25% (insbesondere für CAN). Die ECC-Prüfzeichen können z. B. eine Länge von 4 Bit bis 7 Byte aufweisen, typischerweise von 1 Byte bis 2 Byte.
-
Das Verfahren umfasst ein Codieren mindestens der Nutzdaten durch ein CRC-Verfahren. Typischerweise werden mindestens die Header- und die Nutzdaten ECC-codiert. Wenn eine ECC-Codierung vorliegt, insbesondere wenn also das Steuerzeichen den ersten Zustand einnimmt, kann die ECC-Codierung durch das CRC-Verfahren codiert werden. Liegen ECC-Prüfzeichen des ECC-Verfahrens vor, so können auch diese CRC-codiert werden. Das CRC-Codieren kann ein Erzeugen von CRC-Prüfzeichen (CRC-Prüfbits) umfassen. Diese können auf der Basis zumindest der Nutzdaten, zumindest der Header- und Nutzdaten oder auf Basis der Headerdaten, Nutzdaten und der ECC-Prüfzeichen erzeugt werden. Die CRC-Prüfzeichen können in den Prüfdatenbereich ein- oder angefügt werden. Mindestens das Steuerzeichen, typischerweise zumindest die Nutzdaten, zumindest die Header- und Nutzdaten oder Headerdaten, Nutzdaten und ECC-Prüfzeichen, kann/können im Klartext in der CRC-Codierung vorliegen. Die Länge der Prüfdaten, insbesondere der CRC-Prüfzeichen, ist nach einer oder mehreren Ausführungsformen höchstens gleich der, gegebenenfalls durch das Rahmenformat vorbestimmten Maximallänge der Prüfdaten. Die CRC-Prüfzeichen können z. B. eine Länge von 15 Bit bis 64 Bit aufweisen, typischerweise von 15 oder 16 Bit (insbesondere für CAN) oder von 24 Bit (insbesondere für FlexRay).
-
Weiter umfasst das Verfahren Senden der Daten des Datenrahmens über das Bussystem. Dabei ist der Datenrahmen typischerweise nur ECC-codiert, wenn das Steuerzeichen den zweiten Steuerzustand einnimmt, und sowohl ECC- als auch CRC-codiert, wenn das Steuerzeichen den ersten Steuerzustand einnimmt. Der codierte Datenrahmen kann mindestens das Steuerzeichen im Klartext enthalten. Typischerweise enthält der Datenrahmen zumindest die Nutzdaten, zumindest die Header- und Nutzdaten oder gegebenenfalls die Headerdaten, Nutzdaten und die ECC-Prüfzeichen im Klartext.
-
Gemäß einer oder mehreren Ausführungsformen kann das Verfahren zur Übertragung eines Datenrahmens in einem Bussystem auch ein Verfahren zum Empfangen des Datenrahmens umfassen. Das Verfahren kann ein Empfangen der über das Bussystem gesendeten Daten des Datenrahmens umfassen. Das Verfahren kann ein Bestimmen umfassen, ob das empfangene Steuerzeichen in dem ersten oder dem zweiten Zustand vorliegt. Weiter kann das Verfahren umfassen: Decodieren mindestens der Nutzdaten durch das ECC-Verfahren, wenn das empfangene Steuerzeichen den ersten Steuerzustand einnimmt, und bestimmen, ob ein Datenfehler vorliegt und/oder ob ein Datenfehler korrigierbar ist. Diese Bestimmung kann einen Abgleich mit empfangenen ECC-Prüfzeichen umfassen, insbesondere das Berechnen eines CRC-Fehlersyndroms und/oder das Berechnen eines ECC-Fehlersyndroms. Mindestens die Nutzdaten können durch ein CRC-Verfahren decodiert werden. Typischerweise werden Header-, Nutz- und ggf. ECC-Prüfzeichen dem zyklischen Redundanzcheck CRC unterzogen. Es kann durch den CRC bestimmt werden, ob ein Datenfehler vorliegt. Die empfangenen Daten des Datenrahmens können entweder behalten werden, z. B. in einem Empfangspuffer gespeichert werden, oder verworfen werden. In letzterem Fall kann das Verfahren ein Rückübermitteln einer Aufforderung zum erneuten Senden des Datenrahmens umfassen.
-
Das Verfahren kann insbesondere ein Behalten oder Verwerfen der empfangenen Daten des Datenrahmens auf Basis eines gemeinsamen Bestimmens durch das ECC-Verfahren und das CRC-Verfahren umfassen. Das gemeinsame Bestimmen kann umfassen: Behalten der Daten des Datenrahmens, wenn das ECC-Verfahren und das CRC-Verfahren bestimmen, dass kein Datenfehler vorliegt und Verwerfen der empfangenen Daten des Datenrahmens, wenn das ECC-Verfahren bestimmt, dass ein nicht korrigierbarer Datenfehler vorliegt, oder das ECC-Verfahren bestimmt, dass ein Datenfehler vorliegt, das CRC-Verfahren jedoch bestimmt, dass kein Datenfehler vorliegt, oder das ECC-Verfahren bestimmt, dass kein Datenfehler vorliegt, das CRC-Verfahren jedoch bestimmt, dass ein Datenfehler vorliegt. Das jeweilige Bestimmen kann auf der Grundlage eines berechneten CRC-, bzw. ECC-Fehlersyndroms erfolgen. Des Weiteren kann das gemeinsame Bestimmen umfassen: Korrigieren der empfangenen Daten des Datenrahmens, wenn das ECC-Verfahren bestimmt, dass ein korrigierbarer Datenfehler vorliegt und das CRC-Verfahren bestimmt, dass ein Datenfehler vorliegt. Dabei kann das ECC-Verfahren eine Fehlerkorrektur des korrigierbaren Datenfehlers vornehmen und das CRC-Verfahren bestimmen, ob die Korrektur erfolgreich war. Insbesondere kann die Bestimmung, ob die Korrektur erfolgreich war, umfassen: Erzeugen von CRC-Prüfzeichen eines ECC-Korrekturvektors, Bilden einer logischen Verknüpfung von empfangenen und von berechneten CRC-Prüfzeichen und Vergleichen, ob die CRC-Prüfzeichen des ECC-Korrekturvektors der logischen Verknüpfung entsprechen. Die logische Verknüpfung kann eine XOR-Verknüpfung sein, insbesondere, wenn die Prüfzeichen Prüfbits sind. Korrigierte empfangene Daten des Datenrahmens mögen behalten werden, wenn die Korrektur erfolgreich war, und verworfen werden, wenn die Korrektur nicht erfolgreich war.
-
Weitere Ausführungsformen beziehen sich auf Sender und/oder Empfänger Übertragung von Datenrahmen in einem Bussystem, wobei Sender und/oder Empfänger eingerichtet sind, die Verfahren gemäß hierin beschriebenen Ausführungsformen auszuführen.
-
Des Weiteren sind Ausführungsformen auch auf Verfahren gerichtet, nach denen die hierin beschriebenen Sender und/oder Empfänger arbeiten oder durch welche sie hergestellt werden. Diese Verfahren enthalten Verfahrensschritte zum Ausführen der Funktionen der Sender/Empfänger. Weitere Ausführungsformen sind auf die Verwendung von Sendern und/oder Empfängern gemäß hierin beschriebenen Ausführungsformen gerichtet, insbesondere eine Verwendung zu Übertragung von Datenrahmen in einem Bussystem.
-
Noch weitere Ausführungsformen sehen die Verwendung der hierin beschriebenen Rahmenformate und Datenrahmen in Verfahren zur Übertragung von Datenrahmen in einem Bussystem vor, insbesondere in Verfahren gemäß hierin beschriebenen Ausführungsformen. Rahmenformate von hierin beschriebenen Verfahren können die Rahmenformate gemäß hierin beschriebenen Ausführungsformen sein.
-
Gemäß einer oder mehreren Ausführungsformen können die hier beschriebenen Verfahrensschritte ganz oder teilweise als Softwareroutinen implementiert sein.
