Verfahren zur Übertragung von Daten über einen seriellen Kommunikationsbus, entsprechend ausgelegte Busschnittstelle sowie entsprechend ausgelegtes

Computerprogramm

Die Erfindung betrifft das technische Gebiet der seriellen Datenübertragung zwischen elektronischen Komponenten insbesondere Steuergeräten, Sensoren und Aktoren, die über ein Bussystem vernetzt sind. Solche Steuergeräte werden vielfach in Kraftfahrzeugen eingesetzt. Vernetzte Steuergeräte, Sensoren und Aktoren werden auch in anderen

Gebieten der Technik eingesetzt, z.B. in der Automatisierungstechnik, Prozesstechnik, usw. Die Erfindung betrifft ebenso eine entsprechend ausgelegte Busschnittstelle sowie ein entsprechend ausgelegtes Computerprogramm.

In modernen Fahrzeugen werden eine Vielzahl von Steuergeräten verbaut. Alleine für den Antriebstrang werden eine Anzahl Steuergeräte eingesetzt, so z.B. Motor-Steuergerät, Getriebe-Steuergerät, ESP-Steuergerät, und weitere. Zu erwähnen ist auch die Klasse der Steuergeräte, die für Regelungen im Fahrwerksbereich zuständig sind. Solche sind

Steuergeräte zur elektronische Fahrwerkeinstellung oder Steuergeräte zur Fahrdynamik- Regelung oder Steuergeräte, die als Lenkhilfe fungieren, wie z.B. die

geschwindigkeitsabhängige Servolenkung. Daneben gibt es auch noch weitere Steuergeräte, die im Bereich der Fahrzeugkarosserie verbaut werden und für bestimmte Komfortfunktionen sorgen. Als Beispiele werden genannt die Tür- oder Fensterheber-Steuergeräte,

Klimaanlage-Steuergeräte, Sitzverstellungs-Steuergeräte, Airbag-Steuergeräte u.a. Dann gibt es weiterhin die Klasse der Steuergeräte, die zu dem Infotainment-Bereich zählen, wie Kamera-Steuergerät zur Umfeldbeobachtung, Navigationsgerät, RADAR- oder LIDAR-Gerät, Kommunikationsmodul und Entertainmentmodul mit TV, Radio, Video und Musik-Funktion.

Es gibt den Trend in der Technik, dass für die fahrzeuginterne Vernetzung von

Steuergeräten zukünftig vermehrt IP Kommunikation in Form von IPv6 oder IPv4 zum

Einsatz kommen soll. Dabei werden IP-Pakete übertragen, die eine Länge von bis zu 64 kByte aufweisen können. Zwar können die IP-Pakete segmentiert übertragen werden, jedoch erfordert der Einsatz von IP Kommunikation, dass eine Bustechnologie verwendet wird, die hinreichend große Botschaften übertragen kann. Typischerweise werden die Steuergeräte der verschiedenen Kategorien jeweils mit einem separaten, für die Gerätekategorie entsprechend ausgelegten Bus vernetzt. Es können daher mehrere verschiedene Bussysteme im Fahrzeug eingesetzt werden. Die

verschiedenen Bussysteme können dabei über Gateways miteinander verbunden sein, um einen Datenaustausch zu ermöglichen. Im Bereich der Antriebstrang-Steuergeräte wird typischerweise der CAN-Bus eingesetzt, ebenfalls im Bereich der Komfort-Steuergeräte. Im Infotainment-Bereich kommen auch andere Bussysteme zum Einsatz, wie Bussysteme die auf Ethernet-Technologie beruhen, z.B. AVB (Audio Video Bridging) der auf der Standard- Familie nach IEEE 802.3 Standard basiert. Auch Bussysteme, bei denen die

Datenübertragung über Lichtwellenleiter geschieht, sind einsetzbar. Als Beispiele werden genannt der MOST Bus (Media Oriented System Transport) oder der D2B Bus (Domestic Digital Bus).

Das Ethernet-Bussystem stammt schon aus den frühen Tagen der Vernetzung von

Computern und wurde am Palo Alto Research Center Xerox PARC in den späten 1970er Jahren entwickelt. Schon seit 1980 ist das Institute of Electrical and Electronics Engineers (IEEE) für die Pflege und Weiterentwicklung von Ethernet verantwortlich. Für Ethernet ist die Arbeitsgruppe 802 verantwortlich. Die Ethernet-bezogenen Standards werden deshalb mit einer führenden 802 gekennzeichnet (z.B. IEEE 802.1 , IEEE 802.2, IEEE 802.3, etc.).

Dabei besteht eine große Stärke des Ethernets darin, dass fertige Protokolle für den

Transport von vielfältigen Nutzdaten bestehen, wie Video- / Audio-Daten, usw. und, dass heute eine Vielzahl an physikalischen Medien unterstützt wird, die dessen Verwendung auch im Kraftfahrzeug erlauben. Da die physikalischen Medien vom Übertragungs-Protokoll unabhängig sind, können auch problemlos weitere Übertragungstechniken entwickelt und für Anforderungen aus der Automobilbranche angepasst werden.

Dabei wird gefordert, insbesondere, wenn das IPv6-Protokoll eingesetzt werden soll, dass als MTU (Maximum Transmission Unit), wie sie von Ethernet bekannt sind, mindestens 1280 Byte große Pakete übertragen werden können. Jedoch erfüllen weder der im Kraftfahrzeug eingesetzte klassische CAN Bus 2.0, entsprechend Controller Area Network noch der bereits erweiterte CAN FD Bus, entsprechend Controller Area Network Flexible Data Rate diese Anforderung, da sie Botschaften mit einer maximalen Größe von nur 8 respektive 64 Byte übertragen können. Das macht den Einsatz des CAN-Busses ungeeignet, wenn er die geforderte IPv6 Kommunikation unterstützen soll. Hinsichtlich weiterer Einzelheiten zum IPv6-Protokoll wird auf die Spezifikation RFC 2460 der Internet Engineering Task Force IETF verwiesen. Bisher wird im Kfz-Bereich kaum IPv6 Kommunikation eingesetzt, da dies einen hohen Ressourcenaufwand bedeutet. Der übliche Ansatz IPv6 Kommunikation zu ermöglichen besteht darin als Vernetzungstechnologie die für den Kfz-Bereich teure Ethernet-Technologie einzusetzen.

Für den Kfz-Bereich wurden die Varianten IEEE 100BASE-T1 und IEEE 1000BASE-T1 entwickelt. Dabei wird die Übertragung von Daten in Vorwärts- und Rückwärtsrichtung über nur ein verdrilltes Leitungspaar bewerkstelligt. Es gibt einen Physical Layer Block, der jeweils als eigener Baustein/Chip in einem Steuergerät (ECU) eingebaut wird. Dieser Block stellt die Verbindung zwischen physikalischem Medium (Netzwerkkabel) und dem Ethernet Controller Block her.

An einer Busleitung sind bei dieser Ethernet-Variante immer nur zwei Knoten

angeschlossen. Als Topologie steht somit nur die Punkt-zu-Punkt-Verbindung zur Verfügung. Mehr als zwei Knoten können mit Hilfe eines Koppelelements verbunden werden. Hier kommt üblicherweise ein Netzwerk-Switch zum Einsatz, der als Layer-2-Koppelelement die Anbindung an mehrere physikalische Verbindungen erlaubt und selbständig Botschaften von Zweig zu Zweig weiterleiten kann. Dies ist einer der größten Nachteile des Ethernet- Bussystems im Kfz-Bereich, weil es die Kosten in die Höhe treibt.

Deshalb dominierte im Kfz-Bereich der Einsatz des CAN-Busses (Controller Area Network) gemäß ISO-Norm. Der CAN-Bus wurde in den achtziger Jahren entwickelt und 1994 standardisiert. Die entsprechende ISO-Norm hat die Nummer ISO 1 1898. Es gibt eine Norm für den Highspeed-Bereich bis 1 Mbit/s, das ist die Norm ISO 1 1898-2. Dann gibt es eine Norm für den Lowspeed-Bereich bis 125 kBit/s, das ist die Norm ISO 1 1898-3. Durch das anwachsende Datenaufkommen ergeben sich immer höhere Buslasten auf den CAN- Bussen. Dies führte zu einer Weiterentwicklung des CAN-Busses. Der erweiterte CAN-Bus ist unter dem Begriff CAN FD-Bus bekannt. FD steht dabei für Flexible Data Rate. Bei dieser CAN-Bus Variante wird die Datenrate umgeschaltet. Für die Arbitrierungsphase bleibt die Datenrate niedrig, wie beim klassischen CAN-Bus. Für die Übertragung der Nutzdaten wird auf eine höhere Datenrate umgeschaltet. Überträgt man die Nutzdaten einer CAN-FD- Botschaft schneller, so verkürzt sich die Dauer der Busbelegung; und die Buslast verringert sich. Wenn die Übertragungsdauer im gleichen Rahmen bleibt wie bei den klassischen CAN- Botschaften, könnten größere Datenmengen mit einer CAN-FD-Botschaft transportiert werden. So wurde es auch bei CAN FD realisiert. Statt des 8 Byte langen Nutzdatenfeldes wird bei CAN FD ein 64 Byte langes Nutzdatenfeld eingesetzt. Die Datenrate steigt für die Übertragung des Nutzdatenfeldes bei einer Umsetzung z.B. von 500 kbit/s auf 2 Mbit/s an.

Die Erfindung setzt sich zum Ziel die beschriebenen Nachteile bei der Einführung von IP- Kommunikation im Kfz-Bereich zu vermeiden. Insbesondere soll es ermöglicht werden große Ethernet-Rahmen, sogenannte„Jumbo-Frames" ohne Segmentierung über den Kfz-Bus zu übertragen. Insbesondere soll die im Kraftfahrzeug so bewährte lineare Busstruktur unterstützt werden, wo mehrere Steuergeräte ohne den Einsatz von einem Switch als Koppelelement vernetzt sind. Diese Busstruktur ist hinsichtlich des Verkabelungsaufwandes und der Kosten optimal. Seitens der IEEE Organisation wird eine verbesserte 10 Mbit/s Ethernet-Variante gefordert um diesen Punkten gerecht zu werden. Dabei sollen sich die Busteilnehmer die zur Verfügung stehenden 10 MBit/s Bandbreite aufteilen. Das neue Übertragungsprotokoll soll ebenfalls echtzeitfähig sein. Gleichzeitig soll es dezentral administriert werden können. Das bedeutet, dass es nicht nötig sein darf alle Teilnehmer des Netzwerkes mit einer identischen Konfiguration zu versorgen. Dadurch lassen sich

Entwicklungsaufwände deutlich reduzieren. Es muss eine Priorisierung der Teilnehmer als auch der zu übertragenden Daten ermöglichen. Eine weitere Forderung besteht darin, dass das Ethernet-Rahmenformat entsprechend IEEE 802.1 Q unterstützt werden soll.

Diese Aufgabe wird durch ein Verfahren zur Übertragung von Daten über einen seriellen Kommunikationsbus, eine entsprechend ausgelegte Busschnittstelle sowie ein entsprechend ausgelegtes Computerprogramm gelöst.

Die abhängigen Ansprüche beinhalten vorteilhafte Weiterbildungen und Verbesserungen der Erfindung entsprechend der nachfolgenden Beschreibung dieser Maßnahmen.

Für die Lösung der Aufgabe wird ein Verfahren zur Übertragung von Daten über einen seriellen Kommunikationsbus verfolgt, bei dem die Daten mit einem angepassten

Übertragungsrahmen übertragen werden. Der angepasste Übertragungsrahmen weist wenigstens ein Arbitrierungs-Feld und ein Daten-Feld, wobei das Arbitrierungs-Feld zur Regelung des Buszugriffs nach dem CSMA-CR Verfahren, entsprechend Carrier Sense Multiple Access with Collision Resolution, durch Priorisierung der Botschaften mit Hilfe eines Identifizierers dient. Für die Arbitrierungsphase wird eine niedrige Bitrate eingestellt und für die Übertragung der Daten im Datenfeld wird eine erhöhte Bitrate eingestellt. Ein Start-Feld wird im Übertragungsrahmen vorgesehen und die Daten werden in Form eines Ethernet- Übertragungsrahmen verpackt, der wiederum in das Datenfeld des angepassten

Übertragungsrahmens eingefügt wird. Das Arbitrierungs-Feld und das Start-Feld ersetzen dabei eine Präambel und einer Start Frame Delimiter des Ethernet-Übertragungsrahmens. Der Ethernet-Übertragungsrahmen könnte ein Ethernet-Übertragungsrahmen nach der Variante IEEE 802.1 Q sein.

Der große Vorteil besteht darin, dass eine inhaltsabhängige, feingranulare prioritätsbasierte Arbitrierung mit Ethernet kombiniert werden und eine Vernetzungstechnologie entsteht, die sehr gut auf die Bedürfnisse der automobilen Vernetzung zugeschnitten ist. Das System kann genauso dezentral administriert werden, wie es heute beim CAN-Bus der Fall ist. Dies ermöglicht ein hohes Maß an Flexibilität im Entwicklungsprozess, insofern dass einzelne Steuergeräte im Netzwerk unabhängig von anderen verändert und weiterentwickelt werden können. Bei der Bustopologie kann weiterhin auf die lineare Busstruktur gesetzt werden, d.h. viele Stationen können untereinander kommunizieren bei sehr geringen Systemkosten.

Die erhöhte Datenrate kann voll ausgenutzt werden, d.h. es sind Datenraten bis über 10 Mbit/s realisierbar. Auch ist es möglich die Datenrate in Abhängigkeit der Netzwerkgröße und des Kommunikationsszenarios relativ frei zu wählen.

Weiterhin können die bestehenden Mechanismen zur Bewertung der Echtzeitfähigkeit vom zum Beispiel CAN FD Bus übernommen werden. Gleichzeitig kann dank des bleibenden Ethernet-Rahmenformats eine Geräteadressierung auf Basis von den bekannten Ethernet MAC-Adressen vorgenommen werden. Darüber hinaus eignet sich das Netzwerk dank der großen MTU (Maximum Transmission Unit), welches es vom Ethernet erbt hervorragend für fahrzeuginterne IP-Kommunikation, welche das erklärte Ziel darstellt.

Auch unter dem Aspekt der Interoperabilität mit anderen Ethernet-Netzwerken, die es zukünftig im Fahrzeug geben wird, ist diese Lösung vorteilhaft. Das bedeutet, dass der Ethernet-Rahmen ohne Schwierigkeiten dem angepassten Übertragungsrahmen entnommen werden kann und dann einem Router oder Netzwerk-Switch zugeführt werden kann für eine Weiterleitung in andere Teilnetze.

Eine besonders vorteilhafte Maßnahme betrifft die Vergabe der Identifizierer im

Arbitirierungs-Feld für die Priorisierung der Botschaften. Demnach wird der Identifizierer im Arbitrierungs-Feld in die Bereiche„Botschafts-Inhal -Identifizierer und„Geräte' -Identifizierer unterteilt. Durch die entsprechende Vergabe der Geräte ID kann einem Busteilnehmer die Priorität gegenüber den anderen Busteilnehmern eingeräumt werden. Dadurch wird das Netzwerkverhalten planbar/vorhersagbar und damit echtzeitfähig. Randbedingung ist, dass jedem Gerät ein eindeutiger Geräte-Identifizierer zugewiesen wird. Diese Maßnahme ist insbesondere dann sinnvoll, wenn mehrere gleichartige Steuergeräte, Aktuatoren oder Sensoren über den Kommunikationsbus vernetzt sind.

In einer vereinfachten Variante werden alle Bits des Identifizierers, zum Beispiel 32 Bits, für die Botschafts-Inhalt-Identifizierung und Priorisierung verwendet. Die Geräte-Adressierung erfolgt dabei allein durch die im angepassten Übertragungsrahmen ebenfalls übermittelten MAC-Adressen.

Dabei ist es von Vorteil, wenn der Abschnitt mit den höherwertigen Bits für die Priorisierung des Botschafts-Inhaltes reserviert wird und der Abschnitt mit den niederwertigen Bits für die Geräte-Identifizierung vorgesehen werden. Dadurch entscheidet sich der Buszugriff, wie beim CAN-Bus, während der Arbitirierungsphase vorwiegend über die mit verschiedener Priorität versehenen Botschaftsinhalte und erst in zweiter Linie über die Geräte ID.

In einer vorteilhaften Variante wird ein 32 Bit langer-ldentifizierer so aufgeteilt, dass 24 Bit für die Priorisierung des Botschafts-Inhaltes reserviert werden und 8 Bit für die Priorisierung des Gerätes vorgesehen werden.

In einige Ausführungsformen weist das Datenfeld bis zu einer festgelegten Obergrenze eine variable Länge auf. Die Variabilität der Länge des Datenfeldes garantiert viele

Einsatzmöglichkeiten. So braucht kein Kompromiss eingegangen zu werden, wenn es je nach Anwendungsfall auf eine hohe Nettodatenrate ankommt oder in einem anderen Fall mehr die Echtzeitfähigkeit im Vordergrund steht und es mehr auf geringe Latenzzeiten ankommt.

Dabei ist es besonders vorteilhaft, wenn für die variable Länge des Daten-Feldes ein Bereich von 0 bis 4096 Bytes spezifiziert wird. Dies ermöglicht eine gute Interoperabilität mit der heute vielfach zur Anwendung kommenden 1 GBit-Ethernet Variante. Ein Routing zwischen einem Teil des Kfz-Netzwerks wo die 1 GBit Ethernet Bus Variante zum Einsatz kommt, wäre dann ohne Segmentierung möglich. Der Einsatz von IP Kommunikation wird dadurch problemlos möglich.

Es ist ebenfalls von Vorteil, wenn die Länge des Arbitrierungs-Feldes auf 32 Bit festgelegt wird. Diese Maßnahme vereinfacht die Hardwareentwicklung für den angepassten Bus. Die heute üblichen Registerlängen sind typischerweise ein Vielfaches von einem Byte, d.h. ein Vielfaches von 8 Bit. Weiterhin vorteilhaft ist, wenn im angepassten Übertragungsrahmen ein Steuerungs-Feld zwischen Arbitrierungs-Feld und Daten-Feld vorgesehen wird, in dem wenigstens ein Abschnitt für die Längenangabe bzgl. des Daten-Feldes vorgesehen wird. Hier ist also eine Verlängerung dieses Abschnitts erforderlich um die volle Länge von 4096 Bytes angeben zu können. Dafür sind 13 Bits nötig.

Weiterhin kann im Übertragungsrahmen ein CRC-Feld vorgesehen werden, in dem wenigstens ein Abschnitt für einen CRC-Prüfcode vorgesehen wird. Der CRC Prüfcode dient zur Fehlerdetektion entsprechend des bekannten Cyclic Redundancy Check Algorithmus. Dabei ist es von Vorteil, wenn im Übertragungsrahmen ein Start-Feld vorgesehen wird und der CRC-Prüfcode über die Felder Start-Feld, Arbitrierungs-Feld, Steuerungs-Feld und Daten-Feld berechnet wird.

Dabei ist es besonders vorteilhaft, wenn der im Ethernet-Übertragungsrahmen vorgesehen CRC-Prüfcode durch einen erweiterten CRC-Prüfcode ersetzt wird und dieser in einem verlängerten CRC-Feld (CRC) des angepassten Übertragungsrahmens eingefügt wird. Der erweiterte CRC-Prüfcode wird über die Felder Start-Feld (SOF), Arbitrierungs-Feld (BA), Steuerungs-Feld (DL), Zieladress-Feld (DA), Quell-Adress-Feld (SA), optional Q-TAG-Feld (QTAG), Typ-Feld (ET); Daten-Feld (PL) und den Abschnitt des Stuff-Bit Zählers im CRC- Feld (CRC) berechnet.

Das Gleiche gilt für den Einsatz eines Bitstuffing Verfahrens, zum Beispiel ein welches schon beim CAN 2.0 Protokoll und CAN FD Protokoll zum Einsatz kam. Hier ist es vorteilhaft, dass die Übertragung der Daten asynchron erfolgt und zur Gewährleistung des Gleichtaktes von Datensende-Station und Datenempfangs-Station eine Resynchronisation nach einer Bitstuffing-Regel durchgeführt wird, wobei die Bitstuffing-Regel über die Bereiche vom Start- Feld bis zum Ende des Daten-Feldes angewendet wird, wobei die Anzahl der eingefügten Stuff-Bits zur Kontrolle in einem Abschnitt des CRC-Feldes eingetragen wird. Durch die Einfügung eines Stuff-Bits wird ein Flankenwechsel auf dem Bus erzwungen, welcher im CAN-Controller zur Resynchronisation des Taktgebers dient, der den Abtasttakt für die Bitrückgewinnung beim Empfang von Daten vorgibt. Dabei wird eine modifizierte Bitstuffing- Regel eingesetzt. Der Bitstuffing Algorithmus (Frame Encoding) wird für das neue

Übertragungsformat insofern abgewandelt, dass ein Stuff-Bit nicht, wie bei CAN 2.0 und CAN FD, nach 5, sondern erst nach 10 unmittelbar aufeinander folgenden Bits mit dem gleichen Bus-Pegel eingefügt wird. Es werden dadurch weniger„Overhead"-Bits im

Datenrahmen benötigt und es wird dadurch die Effizienz der Datenübertragung gesteigert. Es ist von Vorteil, wenn im Übertragungsrahmen weiterhin ein Ende-Feld vorgesehen wird und in das Ende-Feld wenigstens ein End-of-Frame-Code eingetragen wird, wobei der End- of-Frame-Code eine Länge von 1 1 Bit aufweist. Diese Maßnahme ist wegen der veränderten Bitstuffing Regel von Vorteil. Durch Senden des End-of-Frame Codes wird eine Verletzung der neuen Bitstuffing-Regel erzwungen, so dass Teilnehmer, die nicht korrekt synchronisiert waren, diese Tatsache erkennen und den CAN-Controller zurücksetzen können um wieder korrekt synchronisiert zu werden.

Im CRC-Feld wird die Bitstuffing Regel nach dem erweiterten Protokoll nicht eingesetzt. Deshalb ist es zusätzlich von Vorteil, wenn im CRC-Feld an fest vorgegebenen Positionen ein Stuff-Bit zwangsweise eingefügt wird. So werden auch im CRC-Feld Flankenwechsel garantiert und die CAN-Controller der Busteilnehmer bleiben synchronisiert.

In einem bevorzugten Beispiel beginnt das CRC-Feld mit einem fest vorgegebenen Stuff-Bit und die weiteren fest vorgegebenen Stuff-Bits werden im Abstand von jeweils 9 Bits des CRC-Feldes eingefügt. Das fest vorgegebene Stuff-Bit ist dabei komplementär zu seinem Vorgänger-Bit.

Für eine entsprechend ausgelegte Busschnittstelle zur Verwendung bei dem

vorgeschlagenen Verfahren zur Übertragung von Daten über einen seriellen

Kommunikationsbus gelten die entsprechenden Vorteile wie im Zusammenhang mit den entsprechenden Verfahrensschritten erläutert.

Das Gleiche gilt für ein entsprechend ausgelegtes Computerprogramm, das bei Abarbeitung in einer Recheneinheit die sendeseitigen Schritte und/oder die empfangsseitigen Schritte des vorgeschlagenen Verfahrens zur Übertragung von Daten durchführt. Zwar spielen im Kfz- Bereich die Hardwarekosten eine zentrale Rolle, so dass hier hauptsächlich weniger leistungsfähige MikroController eingesetzt werden, die durch separate CAN-Controller unterstützt werden, bei denen das Datenübertragungsprotokoll durch Spezial-Hardware realisiert wird. In anderen Bereichen, z.B. im Feldbusbereich für Automatisierungstechnik oder Prozesstechnik werden auch leistungsfähigere Mikrocontroller eingesetzt, für die dann auch die Softwarelösung zur Implementierung des erweiterten Datenübertragungsprotokolls in Betracht kommt.

Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und werden nachfolgend anhand der Figuren näher erläutert. Es zeigen:

Fig. 1 ein Fahrzeug mit den Kfz-Elektronik-Komponenten für die Bereiche Antrieb,

Fahrwerk und Fahrerassistenz;

Fig. 2 ein Blockdiagramm für ein Fahrzeug-Bordnetzwerk für die Bereiche Antrieb,

Fahrwerk und Fahrerassistenz;

Fig. 3 ein Blockdiagramm für das Fahrzeug-Bordnetzwerk für den Bereich

Fahrerassistenz;

Fig. 4 das detaillierte Übertragungsrahmen-Format eines Ethernets-Frames nach IEEE

802.1 Q Spezifikation;

Fig. 5 das detaillierte Übertragungsrahmen-Format gemäß einem ersten

Ausführungsbeispiel der Erfindung zur Übertragung eines Basic Ethernet-

Rahmens;

Fig. 6 die einzelnen Bits in dem CRC-Feld gemäß dem neuen

Übertragungsrahmenformat;

Fig. 7 das detaillierte Übertragungsrahmen-Format gemäß einem zweiten

Ausführungsbeispiel der Erfindung zur Übertragung eines„Tagged" Ethernet-

Rahmens; und

Fig. 8 ein Beispiel des Ablaufs der Arbitrierungsphase für das neue

Übertragungsrahmenformat, wenn zwei Netz-Knoten gleichzeitig auf den Bus zugreifen.

Die vorliegende Beschreibung veranschaulicht die Prinzipien der erfindungsgemäßen Offenbarung. Es versteht sich somit, dass Fachleute in der Lage sein werden, verschiedene Anordnungen zu konzipieren, die zwar hier nicht explizit beschrieben werden, die aber Prinzipien der erfindungsgemäßen Offenbarung verkörpern und in ihrem Umfang ebenfalls geschützt sein sollen.

Fig. 1 zeigt ein Fahrzeug 10 mit verschiedenen elektronischen Komponenten. Dargestellt ist ein Personenkraftwagen Pkw. Als Fahrzeug kämen allerdings beliebige andere Fahrzeuge ebenfalls in Betracht. Beispiele von weiteren Fahrzeugen sind: Busse, Nutzfahrzeuge, insbesondere Lastkraftwagen Lkw, Landmaschinen, Baumaschinen, Motorräder,

Schienenfahrzeuge, usw. Die Erfindung wäre allgemein bei Landfahrzeugen,

Schienenfahrzeugen, Wasserfahrzeugen und Luftfahrzeugen einsetzbar. Der Einsatz der Erfindung ist primär für den Fahrzeugbereich gedacht. Allerdings kommt wie beim CAN-Bus auch der Einsatz im Feldbus-Bereich, also in der Automatisierungstechnik, Prozesstechnik, usw. in Frage. Es wird eine Vielzahl von elektronischen Steuergeräten im modernen Kraftfahrzeug eingesetzt. In Fig. 1 ist die Vernetzung einiger Steuergeräte und Sensoren dargestellt. Dabei werden drei verschiedene Klassen von Steuergeräten unterschieden. Die Steuergeräte einer Klasse sind jeweils separat vernetzt. Verbunden sind die jeweiligen Kommunikationsbusse über ein zentrales Gateway-Steuergerät 140. Die Steuergeräte der Klasse der Steuergeräte für den Bereich Fahrerassistenz sind über den Bus 102 vernetzt. Daran angeschlossen sind die Steuergeräte Fahrerassistenz-Steuergerät 1 1 1 , RADAR- Gerät 1 12 und Ultraschallsensor-Steuergerät 1 13. Dabei dient das RADAR-Gerät

(entsprechend Radio Detection and Ranging) zur Realisierung eines Radartempomaten oder zur Realisierung eines Abstandswarnungs- oder Kollisionswarnungsgerätes. Dazu kann auch ein LIDAR-Gerät (entsprechend Light Detection and Ranging) ergänzend oder alternativ eingesetzt werden.

Die Steuergeräte der Klasse der Steuergeräte für den Antriebstrang sind über den Bus 104 vernetzt. Daran angeschlossen sind die Steuergeräte Motor-Steuergerät 121 , ESP- Steuergerät 122 und Getriebe-Steuergerät 123. Weiterhin angeschlossen an den Bus 104 sind die Raddrehzahlsensoren 124 bis 127. Die Steuergeräte der Klasse der Steuergeräte für den Bereich Fahrwerk sind über den Bus 106 vernetzt. Daran angeschlossen sind die Steuergeräte Fahrwerk-Steuergerät 131 und Lenkhilfe-Steuergerät 122.

Fig. 2 zeigt das entsprechende Blockschaltbild für die Kfz-Elektronik in den Bereichen Antrieb, Fahrwerk und Fahrerassistenz. Gleiche Bezugszahlen bezeichnen in Fig. 2 dieselben Komponenten wie in Fig. 1. Die drei separaten Kommunikationsbusse 102, 104, 106 sind als lineare Busse ausgeführt. Dabei können die Busprotokolle für die

Kommunikationsbusse 102, 104 und 106 nach den Bedürfnissen der dort vernetzten

Steuergeräte ausgelegt sein. Z.B. könnte es sinnvoll sein, den Kommunikationsbus 106 für den Bereich Fahrwerk mit höherer Datenrate auszulegen als die beiden

Kommunikationsbusse 102 und 104. Auf Sensorsignale die für das Fahrwerk relevant sind, z.B. bei dem Komfortmerkmal Schlaglocherkennung muss extrem schnell reagiert werden um die die Dämpfereinstellung entsprechend anpassen zu können.

Zu dem Zweck, des Austausches von Daten zwischen Teilnehmern, die an unterschiedliche Kommunikationsbusse 102, 104, 106 angeschlossen sind, ist das Gateway 140 vorgesehen. Dieses ist mit allen drei verschiedenen Bussystemen 102, 104 und 106 verbunden. Das Gateway 140 ist dazu ausgelegt, die Datenpakete, die es über den einen

Kommunikationsbus empfängt, so umzusetzen, dass sie in dem Übertragungsformat des anderen Kommunikations-Busses dort weitergeleitet werden können. Wie dargestellt, ist das Gateway 140 als zentrales Gerät sowohl an den Bus 102, den Bus 104 als auch an den Bus 106 angeschlossen. Es übernimmt daher alle notwendigen Format-Umsetzungen, wenn Daten zwischen den verschiedenen Bussystemen ausgetauscht werden sollen.

Wie eingangs erwähnt, soll ein Kommunikationsbus eingesetzt werden, der es ermöglicht auch größere Datenpakete nach IPv4 oder IPv6-Protokoll zu übertragen. Dafür ist an sich der Einsatz einer Variante der Ethernet Standard-Familie sinnvoll. Hier gibt es schon fertige Übertragungsprotokolle wie IP (Internet Protocol), UDP (User Datagram Protocol), RTP (Real-Time Transport Protocol), TCP (Transmission Control Protocol) auf die zurückgegriffen werden kann. Der Entwicklungsaufwand, was die Übertragungsprotokolle anbelangt, hält sich dann in Grenzen. Die Ethernet-Netzwerk-Technologie entspricht weitestgehend der lEEE-Norm 802.3. Für den Einsatz dieser Technologie im Kraftfahrzeug wurden besondere Varianten entwickelt. Zwei dieser Varianten sind die erwähnte 100BASE-T1 Variante und die 1000BASE-T1 Variante der Ethernet-Standard-Familie. Die Automobilindustrie hat die Bitübertragungsschicht als Kommunikationsstandard für Automotive Ethernet spezifiziert. Dieser Standard wird von der IEEE in zwei Varianten als 100BASE-T1 und als 1000BASE- T1 als Teil der Spezifikation IEEE P802.3bp veröffentlicht.

Als physikalisches Übertragungsmedium wird bei beiden Varianten eine verdrillte

Zweidrahtleitung verwendet, an der symmetrische Differenzspannungen für die

Informationsübertragung angelegt werden. Die Spannungen repräsentieren Symbole, die ein Sender gemäß dem gewünschten Bitstrom erzeugt (kodiert). Ein Empfänger verwendet den entstandenen Symbolstrom wiederum, um die enthaltenen Bits zurückzugewinnen

(dekodieren).

Besonders attraktiv an dieser physikalischen Schicht ist, dass Informationen auf einem UTP- Kabel (ein Kabel mit einem verdrillten Leiterpaar ohne Abschirmung, entsprechend unshielded twisted pair) mit 100 Mbit/s oder 1000 Mbit/s übertragbar sind. Bei nur zwei Teilnehmern ist sogar Vollduplex-Betrieb möglich, d.h. zwei miteinander verbundene Knoten können gleichzeitig senden und empfangen. Dies ist bei den Ethernet- Varianten 100BASE- T1 und 1000BASE-T1 gegeben, weil dort durch den Einsatz des Netzwerk-Switch nur Punkt- zu-Punkt-Verbindungen möglich sind. Als Sender addiert ein Knoten seine eigene

Differenzspannung auf die beiden Leiter, während er als Empfänger seine eigene Spannung von der anliegenden Gesamtspannung subtrahiert. Das Ergebnis der Subtraktion entspricht der Spannung, die von der Gegenseite gesendet wurde. Damit Differenzspannungen addiert bzw. subtrahiert werden können, müssen die beiden Knoten wissen, wann ein neues Symbol beginnt. Das bedeutet, dass beide Knoten auf den Symbolstrom synchronisiert sein müssen. Dies erfolgt bei IEEE 100BASE-T1 mit Hilfe eines Master- und eines Slave-Knotens. Der Master erzeugt einen kontinuierlichen Symbolstrom, auf den sich der Slave synchronisiert. Die Konfiguration des PHY als Master oder Slave erfolgt durch die Basissoftware des MikroControllers. Bei mehr Teilnehmern, muss zwingend ein Netzwerk-Switch vorgesehen sein.

Aus den oben bereits beschriebenen Gründen wird der Kommunikationsbus 106 für den Bereich Fahrwerk nach der IEEE 1000BASE-T1 Variante ausgelegt und die beiden anderen Busse 102 und 104 nach der IEEE 100BASE-T1 Variante.

Das gleiche Netzwerkkabel, das bei Ethernet nach der IEEE 100BASE-T1 Variante benutzt wird, kann auch bei dem CAN-Bus als physikalisches Übertragungsmedium eingesetzt werden. Dort ist aber kein Vollduplex-Betrieb mehr vorgesehen, weil mehrere Teilnehmer an dem Bus angeschlossen sind. Durch das besondere Busarbitrierungsverfahren nach

CSMA/CR (entsprechend Carrier Sense Multiple Access / Collision Resolution, auch bekannt unter CSMA/CA, entsprechend Carrier Sense Multiple Access / Collision Avoidance) werden Daten-Kollisionen vermieden und es setzt sich genau ein Teilnehmer auf dem Bus durch, so dass auf einen Netzwerk-Switch verzichtet werden kann.

Das Prinzip der Vernetzung von elektronischen Komponenten mittels des

Kommunikationsbusses gemäß der Erfindung ist in Fig. 3 näher dargestellt. Als Beilspiel wird der Kommunikationsbus 102 für den Bereich Fahrerassistenz gezeigt. Alle Steuergeräte 1 1 1 bis 1 13 sind an den Kommunikationsbus 102 angeschlossen. Ebenfalls ist noch das

Gateway 140 an den Kommunikationsbus 102 angeschlossen (nicht mehr dargestellt). Die Busstruktur des Kommunikationsbus 102 ist linear. Als Busleitung wird die schon erwähnte verdrillte, ungeschirmte UTP-Zweidrahtleitung genutzt. In jedem Steuergerät 1 1 1 bis 1 13 dient eine Busanpassschaltung 21 zum Anschluss an die Busleitung. Damit verbunden ist ein angepasster Physical Layer Chip 22. Der PHY Chip 22 entspricht im Wesentlichen einem CAN-Transceiver-Chip, ist aber angepasst, so dass das angepasste Übertragungsprotokoll unterstützt wird. Die Bezugszahl 23 bezeichnet den zugehörigen angepassten CAN- Controller. Mit der Bezugszahl 24 ist ein Mikrorechner bezeichnet, auf dem als Host IC die Anwendungssoftware installiert ist. Auch weitere Netzwerkprotokolle ab der Data Link Layer sind auf diesem Mikrorechner 24 installiert. Der Ethernet-MAC-Rahmen wird von der Ethernet MAC-Layer geliefert. Der zugehörige Netzwerkprotokollstapel ist auf dem

Mikrorechner 24 installiert. Der CAN-Controller 23 übernimmt den fertigen Ethernet-MAC- Rahmen, entfernt den CRC-Abschnitt, stellt den angepassten Übertragungsrahmen zusammen, berechnet den CRC-Prüfcode nach der neuen Methode und fügt ihn in das CRC-Feld ein. Die Einzelheiten werden nachfolgend genauer erläutert. Der CRC-Abschnitt des Ethernet-MAC-Rahmens wird deswegen nicht in das Nutzdatenfeld PL übernommen, weil bei jeder Weiterleitung eines Ethernet-MAC-Rahmens seitens eines Netzwerk-Switch der CRC-Prüfcode sowieso neu berechnet wird. Das geschieht auf MAC-Ebene vor dem Übertragen der Daten auf die Busleitung.

Fig. 4 zeigt das neue Übertragungsrahmen-Format gemäß Ethernet Busvariante IEEE 100BASE-T1. Es ist der sogenannte Tagged MAC-Frame dargestellt, der im

Fahrzeugbereich bevorzugt wird. Im unteren Teil ist das Format eines Ethernet-Paketes bei dieser Variante gezeigt. Die beiden ersten Abschnitte Präambel und SFD sind dabei nur Teil des Ethernet-Paketes. Der eigentliche Ethernet-Frame, auch Ethernet MAC Frame genannt, beginnt erst danach. Für die Übertragung des Ethernet Frames fügt ein Ethernet PHY zu Beginn die Präambel sowie den Start Frame Delimiter (SFD) hinzu. Diese dienen bei IEEE 100BASE-T1 zur Signalisierung des Übertragungsbeginns, also zur oben bereits erwähnten Synchronisierung. Der Ethernet MAC-Frame besteht aus den Feldern MAC-Header, MAC Payload und CRC-Feld. Der MAC-Header besteht aus den Abschnitten für Ziel-Adresse, Quell-Adresse, VLAN-Tag, EtherType. In den Abschnitten Ziel-Adresse und Quell-Adresse wird jeweils die MAC-Adresse für Ziel und Quelle eingetragen. Eine Unterscheidung zwischen Basic und Tagged MAC Frame erfolgt mit dem Typfeld EtherType. Dieses kennzeichnet generell das enthaltene Paket im Payload-Bereich und gibt damit Auskunft über verwendete Protokolle in den höheren Schichten (z.B. IPv4, IPv6). Bei dem Tagged MAC Frame steht im Feld VLAN-Tag zu Beginn eine VLAN-Kennung (z.B. 0x8100). Ist diese vorhanden, so wird das Typfeld EtherType um vier Byte nach hinten verschoben und an dessen ursprünglicher Position der VLAN Tag eingefügt.

Ein VLAN Tag besteht aus einem Protocol Identifier (TPID) (entspricht der VLAN-Kennung) und einer Control Information (TCI). Die TCI besteht aus einer Priorität (PCP), einem Drop Eligible oder Canonical Form Indicator (DEI oder CFI) sowie einem Identifier (VID). In der Automobilbranche werden hauptsächlich Identifier VID und Priorität PCP verwendet. Der Identifier VID kennzeichnet das jeweilige virtuelle Netzwerk für die unterschiedlichen

Anwendungsbereiche. Die Priorität erlaubt die Optimierung von Laufzeiten durch Netzwerk- Switches, sodass wichtige Informationen bevorzugt weitergeleitet werden können.

Im Nutzdatenbereich des Ethernet Frame (MAC-Payload) können Informationen mit variabler Länge übertragen werden. Beim Tagged MAC Frame hat das Payload-Feld eine

Mindestlänge von 42 Byte. Gemäß IEEE 100BASE-T1 Spezifikation können darin bis zu 1500 Byte enthalten sein. In das CRC-Feld am Ende des MAC Frames wird eine CRC-Prüfsumme übertragen. Der enthaltene Wert wird mit Hilfe eines standardisierten Algorithmus berechnet, der in Sender und Empfänger gleich implementiert ist. Die Berechnung erfolgt mit allen Feldern des Ethernet MAC Frames und sichert daher die gesamte Botschaft ab.

Im mittleren Teil der Fig. 4 ist das Format eines IPv6-Paket.es mit einer Größe von 1500 Bytes gezeigt. Es findet komplett Platz im Nutzdatenfeld des Ethernet-MAC Frames.

Darüber ist ein UDP-Paket, entsprechend User Datagram Protocol, dargestellt. Es hat eine Länge von 1460 Byte und findet komplett Platz in dem Nutzdatenfeld des IPv6-Paket.es.

Erfindungsgemäß geschieht jetzt die Übertragung eines vollständigen Ethernet MAC-Frames nicht nach der bekannten Ethernet Variante IEEE 100BASE-T1 . Stattdessen wird das dezentrale Vielfach-Buszugriffsverfahren nach CSMA CR eingesetzt. Dazu werden die in Fig. 4 gezeigten Felder am Anfang eines Ethernet-Paketes Präambel und SFD ersetzt. Sie werden durch die vom CAN-Bus bekannten Felder SOF (Start of Frame) und BA (Bus Arbitration) abgelöst. Im Unterschied zum CAN-FD Bus wird das BA-Feld aber von 29 Bit auf 32 Bit verlängert. Dies erweitert den Addressraum für den Identifier innerhalb des BA-Feldes und nutzt die gängigen Registergrößen bei Mikrorechnern voll aus. Die vom CAN FD-Bus bekannten Steuerungsbits SRR, RTR, RRS und IDE, die sonst zum Zweck der

Übertragungsrahmen-Formatsteuerung vorgesehenen sind, entfallen.

Die verschiedenen Felder der neuen Übertragungsrahmenformate sind in den Figuren 5 und 6 gezeigt. Die Bezeichnungen der verschiedenen Felder mit ihrer Bezeichnung in englischer Sprache sind in der folgenden Tabelle aufgelistet. Bei der nachfolgenden Erwähnung dieser Felder wird die ausführliche Bezeichnung nicht mehr wiederholt.

Feld Ausführliche Bezeichnung

SOF Start of Frame

BA Bus Arbitration

DL Data Length

DA Destination Address

SA Source Address

ET Eth erType

QTAG Q-Tag

PL Payload

CRC Error Check Sum

Dabei zeigt Fig. 5 das Übertragungsrahmenformat für die Übertragung eines Basic Ethernet- Rahmens nach IEEE 802.1 Q. In diesem Fall hat das PL-Feld eine Länge von 46 - 4096 Bytes. Die Länge dieses Feldes wurde gegenüber der bei IEEE 100BASE-T1 spezifizierten Länge also drastisch erhöht. Auf Grund von Interoperabilitätsanforderungen mit anderen Ethernet-Netzwerken, muss das Nutzdatenfeld PL auf eine Mindestlänge aufgefüllt werden. Dies geschieht durch die bekannte„Padding' -Technik. Die Regel für die„Padding' -Technik lautet: DA+SA+ET+QTAG+PL+CRC >=64 Byte. Die aufgelisteten Felder müssen zusammen genommen eine Länge von mindestens 64 Byte ergeben. Dabei muss der Wert des

Längenfeldes der tatsächlichen Länge der Payload ohne Berücksichtigung der Padding-Bits entsprechen.

Im Steuerungs-Feld DL wird der Abschnitt für die Längenangabe des Datenfeldes auf eine Länge von 13 Bit erweitert. Es entfällt aber das vom CAN FD-Bus am Anfang des DL-Feldes stehende ESI-Bit. In den Bits DL0 bis DL12 wird die Länge des Nutzdatenfeldes in der Anzahl der Bytes angegeben. Damit gibt der numerische Wert in diesem Abschnitt exakt die Anzahl an Bytes im Nutzdatenfeld an. Mit 13 Bit kann die maximale Anzahl von 8192 Bytes kodiert werden. Es kann aber auch jede beliebige andere ganze Zahl in dem Bereich damit kodiert werden. Die Länge des Datenfeldes soll bis zu 4096 Byte umfassen, damit noch ein Ethernet Jumbo Frame bis zu dieser Größe darin Platz finden kann. Das DL-Feld kann zwar mit 13 Bit mehr Bytes angeben, es wird aber über eine Festlegung auf 4096 Bytes begrenzt. Es dürfen also in das verlängerte Daten-Feld PL innerhalb der festgelegten Obergrenze von 4096 eine beliebige Anzahl von Bytes eingetragen werden.

Das Daten-Feld PL selbst kann eine variable Länge aufweisen. Hier können je nach dem was eingestellt wird bis maximal 4096 Bytes folgen. Das entspricht einer Länge von 32768 Bits.

Die Steuerungsbits FDF, BRS und das reservierte res Bit zwischen Steuerungs-Feld DL und Daten-Feld PL entfallen.

Das CRC-Prüfcode-Feld CRC wird auf eine Länge von 51 Bit verlängert. Dies ist der gleichzeitigen Verlängerung des Datenfeldes geschuldet. Dabei beträgt die Länge des CRC- Prüfcodes wie gehabt eine Länge von 32 Bit. Es werden aber besondere Bits für ein

Bitstuffing vorgesehen. Die Bezeichnung und Position der einzelnen Bits im CRC-Feld ist in Fig. 6 gezeigt. Das CRC-Feld CF in dem der CRC Prüfcode eingetragen wird, wird auf eine CRC Länge von 32 Bit erweitert. Der Prüfcode wird in die Bit-Felder CRCO bis CRC31 eingetragen.

Zur Berechnung des CRC-Prüfcodes wird z.B. das Polynom G(x) = x32 + x26 + x23 + x22 + x16 + x12 + x1 1 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1 verwendet.

Dabei entspricht das gewählte Polynom dem Polynom, welches in der Spezifikation IEEE 802.3 für Ethernet vorgeschlagen wird.

Die CRC Prüfsumme ist vom SOF-Bit bis zum letzten Bit des Stuff Bit Counters (StuffO) zu berechnen.

Der Abschnitt Stuff Count im CRC-Feld wird gegenüber CAN FD auf eine Länge von 12 Bit geändert und betrifft die Bits StuffO bis Stuffl 1. In den Abschnitt Stuff Count wird die Anzahl der in dem Bereich vom SOF-Bit bis zum letzten Bit des Daten-Feldes DF eingefügten Stuffbits eingetragen. Dabei wird die Anzahl der Stuffbits binär kodiert. Der Einsatz des Bitstuffing ist gegenüber dem beim CAN-FD Standard eingesetzten Bit-Stuffing allerdings vereinfacht, wie im Folgenden im Einzelnen beschrieben.

Die Einfügung von Stuffbits dient dem Zweck der Synchronisation bei asynchroner

Datenübertragung. Zur Herstellung des Gleichlaufs der Kommunikationspartner dient die von rezessiv nach dominant wechselnde Signalflanke des Startbits SOF einer CAN-Botschaft. Ein Resynchronisationsmechanismus sorgt im Anschluss an das SOF-Bit für die

Beibehaltung des Gleichlaufs. Der Resynchronisationsmechanismus basiert auf der

Auswertung der von rezessiv nach dominant wechselnden Signalflanken. Damit hier die Synchronisation beibehalten wird, wurde im CAN-Standard der Bitstuffingmechanismus eingefügt. In der ISO Norm ISO 1 1898-1 ist spezifiziert, dass spätestens nach fünf homogenen Bits ein komplementäres Bit zu übertragen ist, auch dann, wenn nach fünf homogenen Bits ohnehin ein komplementäres Bit folgen würde. Die Lage der Stuffbits ist dem Empfänger aufgrund der Regel bekannt und er kann die Stuffbits ignorieren.

Der Bitstuffing Algorithmus (Frame Encoding) für das neue Übertragungsformat wird insofern abgewandelt, dass ein Stuff-Bit nicht nach 5, sondern erst nach 10 unmittelbar aufeinander folgenden Bits mit dem gleichen Bus-Pegel eingefügt wird. Es werden dadurch weniger Overhead-Bits im Datenrahmen benötigt und es wird dadurch die Effizienz der

Datenübertragung gesteigert. Das variable Bitstuffing ist nur für die Bits vom SOF bis zum letzten Bit des Data Feldes PL durchzuführen. Ab dem CRC-Feld werden vordefinierte Stuffbits (FixedStuffx) verwendet. Die FixedStuff-Bits werden immer nach 9 Bits eingefügt.

Es handelt sich um die Bits FixedStuffO, FixedStuffI , FixedStuff2, FixedStuff3, FixedStuM und FixedStuffö. Die einzelnen Stuffbits in dem CRC-Feld sind jeweils mit dem

entgegengesetzten Pegel des direkt davor übertragenen Bits zu übertragen.

Durch diese fest vorgegebenen Stuff-Bits FixedStuffO, FixedStuffI , FixedStuff2, FixedStuff3, FixedStuff4 und FixedStuffö wird ein garantierter Flankenwechsel bei der Übertragung an der gewünschten Stelle bewirkt.

Das Bit FixedStuffO wird zwischen dem letzten Daten Bit und dem Bit Stuffl 1 übertragen. Das Bit FixedStuffI wird zwischen dem Bit Stuff3 und dem Bit Stuff2 übertragen.

Das Bit FixedStuff2 wird zwischen dem Bit CRC26 und dem Bit CRC25 übertragen.

Das Bit FixedStuff3 wird zwischen dem Bit CRC17 und dem Bit CRC16 übertragen.

Das Bit FixedStuff4 wird zwischen dem Bit CRC8 und dem Bit CRC7 übertragen.

Das Bit FixedStuffö wird zwischen dem Bit CRCO und dem Bit CRCDel übertragen.

Das CRCDel Bit, was die Funktion eines CRC Delimiters innehat, bleibt unverändert und hat die gleiche Funktion wie im CAN FD Standard.

Im Ende-Feld EOF entfallen die vom CAN FD-Bus bekannten Bits ACK und ACKDel.

Im Ende-Feld EF wird der Abschnitt mit der EOF Kennzeichnung auf 1 1 Bit erweitert. Hier werden also statt der beim CAN Bus üblichen 7 aufeinander folgenden rezessiven Bits 1 1 rezessive Bits übertragen. Die Verlängerung des EOF-Symbols ist der Modifikation des Stuffing Algorithmus geschuldet. Erst nach 1 1 aufeinander folgenden Bits gleichen

Buspegels wird die neue Stuffing-Regel verletzt. Dies wird hier ausgenutzt.

Beim CAN Bus und CAN FD Bus wird zwischen zwei übertragenen Datenrahmen ein sogenanntes Intermission Feld eingefügt. Hier werden nochmals 3 aufeinanderfolgende rezessive Bits IFS2 bis IFSO übertragen. Daran erkennen die CAN Controller, dass der Bus wieder freigegeben ist. Dieses Feld kann bei dem hier neu vorgeschlagenen

Übertragungsformat entfallen. Fig. 7 zeigt noch das Übertragungsrahmenformat für die Übertragung eines Tagged Ethernet-Rahmens nach IEEE 802.1 Q. Dieses Übertragungsrahmenformat unterscheidet sich von dem in Fig. 5 gezeigten Format lediglich dadurch, dass noch das bekannte QTAG- Feld mit 4 Byte zwischen dem SA-Feld und ET-Feld vorgesehen ist. Dadurch bedingt ist das Datenfeld PL bzgl. der Mindestgröße auf 42 Byte verkürzt. Das QTAG-Feld ist prinzipiell optional, wird aber dennoch sehr wahrscheinlich immer verwendet. Die Einzelheiten zum QTAG-Feld sind in der Spezifikation IEEE 802.1 Q beschrieben.

Wie in beiden Figuren Fig. 5 und Fig. 7 dargestellt, werden 2 verschiedene Bitraten für die Übertragung der Bits im Übertragungsrahmen eingesetzt. Die genaue Umschaltposition BRSP ist in beiden Figuren angegeben. Die Bitratenumschaltung erfolgt zwischen BA- und DL-Feld von langsam auf schnell und zwischen CRC- und EOF-Feld von schnell auf langsam.

Die langsamere Bitrate wird als Bit Rate Langsam bezeichnet.

Die schnellere Bitrate wird als Bit Rate Schnell bezeichnet.

Für die Bit Rate Langsam wird ein Bereich zwischen 500 KBit/s und 1500 KBit/s festgelegt. Dabei sollen alle Bitraten in 250 KBit/s Schritten unterstützt werden.

Für die Bit Rate Schnell wird ein Bereich zwischen 2000 KBit/s und 12000 KBit/s festgelegt. Dabei sollen in diesem Bereich alle Bitraten in 1000 KBit/s Schritten unterstützt werden.

Höhere Bitraten für die Bit Rate Langsam und Bit Rate Schnell können optional unterstützt werden.

Das Busarbitrierungs-Feld BA wird wie beim CAN-Bus zur Busarbitrierung genutzt. Dabei unterliegt die Festlegung der Identifizierer für die Botschaften grundsätzlich keinerlei Beschränkungen.

Trotzdem ist es vor dem Hintergrund, den Bus für die Übertragung von IP-Paketen zu optimieren, hilfreich eine Vergaberichtlinie hinsichtlich der ID-Vergabe anzuwenden.

Die Befolgung der Vergaberichtlinie ist insbesondere für den Bereich der IP Kommunikation vorteilhaft.

Wie beim CAN Bus und CAN FD wird der Identifizierer zur Realisierung eines

Priorisierungskonzeptes verwendet. Anhand des Identifizierers entscheidet sich welcher CAN-Knoten sich auf dem Bus durchsetzt. Das Buszugriffs verfahren entspricht dem CSMA- CR Verfahren (Carrier Sense Multiple Access with Collision Resolution). Das CSMA/CR- Verfahren sorgt dafür, dass sendewillige CAN-Knoten erst dann auf den CAN-Bus zugreifen, wenn dieser frei ist. Bei simultanen Buszugriffen sorgt die dem CSMA/CR-Verfahren zugrundeliegende Methode der bitweisen Busarbitrierung dafür, dass sich immer jener CAN- Knoten mit der höchstprioren CAN-Botschaft durchsetzt. Prinzipiell gilt: je höher die Priorität einer CAN-Botschaft, desto eher kann sie auf dem CAN-Bus übertragen werden.

Niederpriore CAN-Botschaften laufen bei ungünstigem Systemdesign sogar Gefahr, gar nicht übertragen zu werden. Deshalb ist die Vergabe der IDs sehr wichtig für die Realisierung eines deterministischen Datenaustausches.

Nach dem neuen Konzept werden die 32 Bit des Identifizierers in zwei Bereiche [Botschafts- Inhalt] und [Gerät] unterteilt.

Der Bereich [Botschafts-Inhalt] umfasst die höherwertigen Bits des Identifizierers.

Der Bereich [Gerät] umfasst die niederwertigen Bits des Identifizierers.

Die Größe der einzelnen Bereiche kann bedarfsgerecht gewählt werden, muss aber innerhalb eines CAN Netzwerks für allen Teilnehmern gleich sein. In einer beispielhaften Ausführungsform werden 24 Bit für den Bereich [Botschafts-Inhalt] reserviert und 8 Bit für den Bereich [Gerät]. Damit ist es möglich eine feine Differenzierung hinsichtlich der Priorität von Botschaften im Netzwerk vorzunehmen. Sollten zwei Teilnehmer zum gleichen Zeitpunkt eine Botschaft mit der gleichen Priorität senden wollen, entscheidet es sich im Bereich

[Gerät], welcher Teilnehmer den Vorzug erhält.

Eine niedrigere Binärzahl im Bereich [Botschafts-Inhalt] bzw. [Gerät] entspricht einer tatsächlich höheren Priorität. Auf dem CAN Bus setzt sich in der Arbitrierungsphase immer der dominante Buspegel durch. Ein CAN Knoten, der erkennt, dass er selbst nur den rezessiven Buspegel gesendet hat und aber erkennt, dass der dominante Pegel anliegt, gibt bei der Arbitrierung auf.

Durch die entsprechende Vergabe der Device ID kann einem Busteilnehmer die Priorität gegenüber den anderen Busteilnehmern eingeräumt werden. Dadurch wird das Netzwerk verhalten vorhersagbar und damit echtzeitfähig.

Fig. 8 illustriert den Vorgang der Arbitrierung:

Im oberen Teil der Darstellung sind die einzelnen Bit Positionen des Arbitirierungs-Feldes BA von 0 bis 31 durchnummeriert. Im [Botschaftsinhalt]-Bereich wird für jedes Bit auch angegeben welche Priorität mit der einzelnen Bit-Position verbunden ist. Der Bit-Position ID8 kommt im [Botschaftsinhalt]-Bereich die niedrigste Priorität PriorityO zu und der Bit-Position ID31 dementsprechend die höchste Priorität Priority23 im [Botschaftsinhalt]-Bereich. Ebenso hat das Bit mit der Nummer IDO im [Gerät]-Bereich die niedrigste Priorität und das Bit mit der Nummer ID7 dann die höchste Priorität.

Im mittleren Bereich der Fig. 8 ist ein Arbitrierungsvorgang dargestellt wo zwei Steuergeräte St. A und St. B um den Bus konkurrieren. Dem Steuergerät St.A wurde die Device ID

00000010b zugewiesen und dem Steuergerät St.B wurde die Device ID 0000001 1 b zugewiesen. In diesem Fall entscheidet sich die Busvergabe im Bereich [Botschafts-Inhalt]. Im dargestellten Fall gewinnt der Teilnehmer St.B weil er im Bit ID9 eine„0" eingetragen hat und der Teilnehmer St.A dort eine„1 " eingetragen hat. Eine eingetragene„0" entspricht beim CAN-Bus dem dominanten Buspegel.

Im unteren Bereich der Fig. 8 ist ein Arbitrierungsvorgang dargestellt wo wiederum die zwei Steuergeräte St. A und St. B um den Bus konkurrieren. Im Bereich [Botschafts-Inhalt] senden beide Teilnehmer dieselbe CAN-Botschaft, hier wird also im Bereich [Botschafts- Inhalt] dieselbe ID gesendet. Dadurch entscheidet sich die Busvergabe in diesem Fall erst im Bereich [Gerät]. Im dargestellten Fall gewinnt der Teilnehmer St.A weil er im letzten Bit mit der Nummer IDO eine„0" eingetragen hat und der Teilnehmer St.B dort eine„1 " eingetragen hat.

In einer vereinfachten Variante werden alle 32 Bit des Identifizierers für die Botschafts-Inhalt- Identifizierung und Priorisierung verwendet. Die Geräte-Adressierung erfolgt dabei allein durch die im angepassten Übertragungsrahmen ebenfalls übermittelten MAC-Adressen.

Die Offenbarung ist nicht auf die hier beschriebenen Ausführungsbeispiele beschränkt. Es gibt Raum für verschiedene Anpassungen und Modifikationen, die der Fachmann aufgrund seines Fachwissens als auch zu der Offenbarung zugehörend in Betracht ziehen würde.

Alle hierin erwähnten Beispiele wie auch bedingte Formulierungen sind ohne Einschränkung auf solche speziell angeführten Beispiele zu verstehen. So wird es zum Beispiel von

Fachleuten anerkannt, dass das hier dargestellte Blockdiagramm eine konzeptionelle Ansicht einer beispielhaften Schaltungsanordnung darstellt.

Es sollte verstanden werden, dass das vorgeschlagene Verfahren und die zugehörigen Vorrichtungen in verschiedenen Formen von Hardware, Software, Firmware,

Spezialprozessoren oder einer Kombination davon implementiert werden können. Spezialprozessoren können anwendungsspezifische integrierte Schaltungen (ASICs), Reduced Instruction Set Computer (RISC) und / oder Field Programmable Gate Arrays (FPGAs) umfassen. Vorzugsweise wird das vorgeschlagene Verfahren und die Vorrichtung als eine Kombination von Hardware und Software implementiert. Die Software wird vorzugsweise als ein Anwendungsprogramm auf einer Programmspeichervorrichtung installiert. Typischerweise handelt es sich um eine Maschine auf Basis einer

Computerplattform die Hardware aufweist, wie beispielsweise eine oder mehrere

Zentraleinheiten (CPU), einen Direktzugriffsspeicher (RAM) und eine oder mehrere Eingabe/Ausgabe (I/O) Schnittstelle(n). Auf der Computerplattform wird typischerweise außerdem ein Betriebssystem installiert. Die verschiedenen Prozesse und Funktionen, die hier beschrieben wurden, können Teil des Anwendungsprogramms sein, oder ein Teil der über das Betriebssystem ausgeführt wird.

Bezugszeichenliste 0 Fahrzeug

1 Anpassschaltung

2 vereinfachter CAN-Transceiver

3 erweiterter Ethernet PHY

4 Schalter

5 Mikrorechner

00 Kfz-Elektronik

02 Datenbus - Fahrerassistenz

104 Datenbus - Antrieb

106 Datenbus - Fahrwerk

1 11 Fahrerassistenz-Steuergerät

1 12 RADAR-Steuergerät

1 13 Ultraschallsensor-Steuergerät

121 Motor-Steuergerät

122 ESP-Steuergerät

123 Getriebe-Steuergerät

124 Raddrehzahl-Sensor

125 Raddrehzahl-Sensor

126 Raddrehzahl-Sensor

127 Raddrehzahl-Sensor

131 Fahrwerk-Steuergerät

132 Lenkhilfe-Steuergerät

140 Gateway

BRSP Bitratenumschaltpunkt