EP3881507A1 - Steuergerätearchitektur für fahrzeuge - Google Patents
Steuergerätearchitektur für fahrzeugeInfo
- Publication number
- EP3881507A1 EP3881507A1 EP19801860.8A EP19801860A EP3881507A1 EP 3881507 A1 EP3881507 A1 EP 3881507A1 EP 19801860 A EP19801860 A EP 19801860A EP 3881507 A1 EP3881507 A1 EP 3881507A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- data packet
- interface controller
- data
- control device
- interface
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 239000000872 buffer Substances 0.000 claims abstract description 41
- 230000005540 biological transmission Effects 0.000 claims abstract description 38
- 238000004891 communication Methods 0.000 claims abstract description 34
- 230000009471 action Effects 0.000 claims abstract description 29
- 238000000034 method Methods 0.000 claims abstract description 29
- 230000015654 memory Effects 0.000 claims description 36
- 238000012512 characterization method Methods 0.000 claims description 12
- 239000012634 fragment Substances 0.000 claims description 3
- 230000008859 change Effects 0.000 description 5
- 238000011144 upstream manufacturing Methods 0.000 description 5
- 238000004458 analytical method Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 230000002457 bidirectional effect Effects 0.000 description 2
- 230000007774 longterm Effects 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 230000004913 activation Effects 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000005352 clarification Methods 0.000 description 1
- 150000001875 compounds Chemical class 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/30—Services specially adapted for particular environments, situations or purposes
- H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
- H04W4/46—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for vehicle-to-vehicle communication [V2V]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/40052—High-speed IEEE 1394 serial bus
- H04L12/40078—Bus configuration
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
- G06F30/34—Circuit design for reconfigurable circuits, e.g. field programmable gate arrays [FPGA] or programmable logic devices [PLD]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/101—Access control lists [ACL]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/10—Integrity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L2012/40267—Bus for use in transportation systems
- H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/90—Buffering arrangements
- H04L49/9042—Separate storage for different parts of the packet, e.g. header and payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/90—Buffering arrangements
- H04L49/9057—Arrangements for supporting packet reassembly or resequencing
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Geometry (AREA)
- General Physics & Mathematics (AREA)
- Evolutionary Computation (AREA)
- Computing Systems (AREA)
- Small-Scale Networks (AREA)
Abstract
Die Erfindung betrifft eine Steuergerätearchitektur und ein Verfahren bei der eine Kommunikationsverbindung zwischen mindestens zwei Steuergeräten, insbesondere in einem Fahrzeug, stattfindet. Das Verfahren weist folgende Schritte auf: • - Empfangen des Datenpakets (500), mittels des ersten Interface- Controllers (110); • - Bestimmen, mittels eines Daten-Analysators (120), einer Übermittlungsstrategie für das Datenpaket (500), wobei die Übermittlungsstrategie mindestens eine der folgenden Aktionen umfasst: • Verwerfen des Datenpakets (500), und/oder • Senden des Datenpakets (500) an mindestens einen der zweiten Interface-Controller (301, 302, 303), und/oder Senden des Datenpakets (500) an mindestens einen der Pufferspeicher (131, 132), und/oder • Fragmentieren des Datenpakets (500) und senden an mindestens einen der Pufferspeicher (131, 132), und/oder Senden des Inhalts des mindestens eines Pufferspeichers (131, 132) an mindestens einen der zweiten Interface-Controller (301, 302, 303); • - Durchführen der Übermittlungsstrategie für das Datenpaket (500)
Description
Steuergerätearchitektur für Fahrzeuge
Die Erfindung betrifft eine Steuergerätearchitektur, bei der eine Kommunikationsverbindung zwischen mindestens zwei
Steuergeräten, insbesondere in einem Fahrzeug, stattfindet. Die Erfindung betrifft weiterhin ein Verfahren zur
Übermittlung von Datenpaketen und eine Verwendung.
Steuergeräte in einem Fahrzeug weisen einen zunehmenden
Kommunikationsbedarf auf. Dies ist unter anderem dadurch verursacht, dass sich die Anzahl der Steuergeräte in
Fahrzeugen kontinuierlich erhöht. Dies führt zumindest bei manchen Fahrzeugen dazu, dass existierende
Übertragungsmedien, wie z.B. Feldbusse, nicht mehr die dafür erforderliche Bandbreite aufweisen und daher zunehmend durch andere, zum Teil schnellere, Kommunikationsverbindungen, Übertragungsmedien und/oder Übertragungsprotokolle ergänzt werden. Vielfach sollen dabei die existierenden
Übertragungsmedien weiter genutzt werden, z.B. aus Gründen der Sicherheit oder um existierende Methoden und/oder Geräte, z.B. für Test und/oder Debugging, weiter nutzen zu können.
Es ist Aufgabe der Erfindung, ein Verfahren und/oder eine Steuergerätearchitektur zur Verfügung zu stellen, welche die Anbindung von Steuergeräten mit existierenden Übertragungs medien an andere Übertragungsmedien und Über
tragungsprotokolle ermöglicht.
Ein Aspekt der Erfindung betrifft ein Verfahren zur
Übermittlung eines Datenpakets von einem ersten Interface-
Controller zu mindestens einem zweiten Interface-Controller, mit den Schritten:
- Empfangen des Datenpakets, mittels des ersten Interface- Controllers ;
- Bestimmen, mittels eines Daten-Analysators , einer
Übermittlungsstrategie für das Datenpaket, wobei die
Übermittlungsstrategie mindestens eine der folgenden Aktionen umfasst :
Verwerfen des Datenpakets, und/oder
Senden des Datenpakets an mindestens einen der zweiten
Interface-Controller, und/oder
Senden des Datenpakets an einen Pufferspeicher, und/oder Fragmentieren des Datenpakets und senden an mindestens einen Pufferspeicher, und/oder
Senden des mindestens einen Pufferspeichers, bzw. dessen Inhalts, an mindestens einen der zweiten Interface- Controller;
- Durchführen der Übermittlungsstrategie für das Datenpaket.
Der erste und der zweite Interface-Controller sind in einem Fahrzeug angeordnet. Bei dem Fahrzeug handelt es sich
beispielsweise um ein Kraftfahrzeug, wie Auto, Bus oder Lastkraftwagen, oder aber auch um ein Schienenfahrzeug, ein Schiff, ein Luftfahrzeug, wie Helikopter oder Flugzeug.
Der erste Interface-Controller kann beispielsweise mit einer Kommunikationsverbindung oder mit einem Übertragungsmedium verbunden sein. Die Kommunikationsverbindung kann z.B. draht lose und/oder drahtgebundene Übertragungsprotokolle, z.B. Ethernet-Protokolle, LTE-Protokolle (Long-Term-Evolution und/oder Long-Term-Evolution-Advanced) und/oder sogenannte
5G-Protokolle, verwenden. Bei diesen Protokollen werden die zu übertragenden Daten in Datenpakete mit fester oder
variabler Länge aufgeteilt. Der erste Interface-Controller ist dazu eingerichtet, ein derartiges Datenpaket zu
empfangen. Das Datenpaket kann gespeichert werden,
insbesondere temporär gespeichert werden, beispielsweise in einem Empfangspuffer.
Das Datenpaket wird zu mindestens einem zweiten Interface- Controller übermittelt. Dabei kann es sein, dass nicht jedes Datenpaket an genau einen zweiten Interface-Controller über mittelt wird. Manche der Datenpakete können z.B. verworfen werden. Manche der Datenpakete können z.B. an mehr als einen zweiten Interface-Controller übermittelt werden; dies kann auch als Multicast oder Broadcast bezeichnet werden. Der zweite Interface-Controller kann dasselbe Protokoll verwenden wie der erste Interface-Controller. Er kann auch denselben Protokoll-Typus verwenden wie der erste Interface-Controller, aber eine andere Geschwindigkeit; so kann der erste
Interface-Controller z.B. ein 1000BASE-T1 Protokoll verwenden und der zweite Interface-Controller 100BASE-T1. Der zweite Interface-Controller kann auch einen „traditionellen"
Fahrzeug-Bus verwenden, wie z.B. CAN-Bus oder einen seiner Nachfolger. Die Verwendung eines „traditionellen" Fahrzeug- Busses kann insbesondere vorteilhaft sein, weil es damit möglich sein kann, auch Komponenten zu verwenden, die für diese „traditionellen" Fahrzeug-Busse entwickelt und/oder hergestellt wurden, und diese Komponenten an neuere und/oder schnellere Kommunikationsverbindungen anzubinden.
Das Datenpaket wird mittels eines Daten-Analysators analy siert. Dabei können z.B. Header, Länge und/oder Inhalt des Datenpakets und/oder die Frequenz des Datenstroms, d.h. die Anzahl der Pakete pro Zeiteinheit, analysiert werden. Es können Informationen aus mehreren Protokollschichten
verwendet werden, z.B. eine MAC-Adresse und/oder die Nummer eines virtuellen Kanals, wie sie bestimmte Protokolle
verwenden. Dabei kann das Datenpaket auch einem bestimmten Typus von Daten zugeordnet werden. Beispiele für einen Daten- Typus können sein: Steuerinformationen für das Fahrzeug und/oder einen Aktor, Steuerinformationen für ein Gerät wie z.B. ein Telefon, Sensor-Rohdaten, Infotainment-Daten, Audio- daten, Videodaten. Bei der Analyse des Datenpakets kann auch der Datenfluss auf der Kommunikationsverbindung des ersten Interface-Controllers berücksichtigt werden, z.B. die
Auslastung der Kommunikationsverbindung.
Aus der Analyse des Datenpakets wird die Übermittlungsstra tegie für das Datenpaket bestimmt. Die Übermittlungsstrategie kann eine oder mehrere Aktionen beinhalten. Die Aktionen können als Einzelaktion, als parallele Aktion und/oder als serielle Aktion ausgeführt werden. Die Ausführung einer
Aktion kann von der Ausführung einer anderen Aktion abhängig sein. Die Aktion kann sich auf dasselbe Datenpaket beziehen oder auch andere Datenpakete mit einbeziehen, z.B.
Datenpakete, die bereits gespeichert wurden, z.B. in einem Pufferspeicher .
Eine der Aktionen kann sein, das Datenpaket zu verwerfen.
Dies kann z.B. geschehen, wenn bei dem ersten Interface- Controller ein Pufferüberlauf vorliegt oder droht. Das
Verwerfen kann auch abhängig von dem Daten-Typus durchgeführt werden. So können z.B. alle Datenpakete, die von einem Gerät mit unbekannter MAC-Adresse stammen, verworfen werden. Es kann z.B. auch eine Maximalanzahl von Paketen pro Zeiteinheit für einen bestimmten Daten-Typus definiert werden und alle Pakete, welche die Maximalanzahl überschreiten, verworfen werden. Die Maximalanzahl kann auch abhängig von einem bestimmten Absender definiert werden. Mit diesen Aktionen können vorteilhafterweise z.B. bestimmte Typen von DoS- Attacken (DoS: Denial of Service) abgewehrt werden. Dies ist bei Fahrzeugen insbesondere vorteilhaft, weil Steuergeräte im Bordnetz begrenzte, manche sogar stark begrenzte, Ressourcen - z.B. in Bezug auf Speicher und/oder Rechenleistung - haben können .
Eine der Aktionen kann sein, das Datenpaket an mindestens einen der zweiten Interface-Controller zu senden. Dies kann z.B. dann geschehen, wenn die Latenz der Übertragung
minimiert werden soll. Das Senden kann dabei beispielsweise ohne weitere Behandlung des Datenpakets geschehen. Wenn es z.B. erforderlich ist, dass die eintreffenden Daten mit hoher Sicherheit ankommen, dann können z.B. alle Filter deaktiviert werden und eine schnelle Weiterleitung ermöglicht werden. Dieser Zustand könnte auf Basis der Konfiguration oder auch auf Basis der empfangenen Daten (z.B. spezielle
Transportprotokolle, die Echtzeit verlangen) eingenommen werden .
Das Senden an mindestens einen der zweiten Interface- Controller kann z.B. von dem Daten-Typus des Datenpakets abhängig sein. Es können auch andere Eigenschaften aus dem
Datenpaket abgeleitet und/oder dem Datenpaket zugeordnet werden. Ein Beispiel kann eine Priorität sein, welche das Datenpaket z.B. in einem Teil des Headers aufweist oder die dem Datenpaket, z.B. aufgrund seines Daten-Typus, zugeordnet wird. So können z.B. Sensordaten eine höhere Priorität zugeordnet bekommen als beispielsweise Musikdaten.
Das Senden an mindestens einen der zweiten Interface-Con troller kann das Senden an eine vordefinierte Menge von zweiten Interface-Controllern oder das Senden an alle zweiten Interface-Controller beinhalten; dies kann auch als Multicast bzw. als Broadcast bezeichnet werden. Dies kann Protokolle des ersten Interface-Controller emulieren, welche Multicast bzw. Broadcast unterstützen.
Eine der Aktionen kann sein, das Datenpaket an mindestens einen der Pufferspeicher zu senden. Dies kann z.B. geschehen, um die Daten mehrerer Datenpakete zu sammeln - und erst gesammelt an einen der zweiten Interface-Controller zu senden - und damit den Datenverkehr zum dem ausgewählten zweiten Interface-Controller zu reduzieren.
Eine der Aktionen kann sein, das Datenpaket zu fragmentieren und das fragmentierte Datenpaket an mindestens einen Puffer speicher zu senden. Damit können beispielsweise große Daten pakete, welche das Protokoll und/oder die Eingangspuffer der zweiten Interface-Controller übersteigen, an die entsprechen den Geräte gesandt werden, ohne dass diese Geräte Design änderungen vornehmen müssten. Dies ermöglicht, ohne großen Anpassungsaufwand Geräte zu verwenden und/oder in späteren Generationen eines Fahrzeugs weiterzuverwenden, die bereits
umfangreich getestet sind und/oder die sich für dieses
Fahrzeug und/oder für andere Fahrzeuge bewährt haben.
Eine der Aktionen kann sein, des mindestens einen Puffer speichers an mindestens einen der zweiten Interface- Controller zu senden. Dies kann beispielsweise im Anschluss an das Fragmentieren und/oder das Sammeln von Daten in diesem Pufferspeicher geschehen. Dies kann einen Multicast bzw.
einen Broadcast an mehrere zweite Interface-Controller beinhalten. Damit kann z.B. eine Parallelverarbeitung von Daten realisiert werden. Dies ist insbesondere vorteilhaft, wenn stärkere Controller nicht verfügbar sind oder wenn stärkere Controller mehr Strom benötigen und/oder mehr Hitze abgeben würden als die parallelisierte Lösung. Auch ein Zusammenfassen mehrerer Datenströme ist möglich, d.h. wenn beispielsweise eine Überlast „vermutet" wird, dann kann ein Multicast-Strom erzeugt werden und/oder die Daten können - gewissermaßen „zur Sicherheit" - an den zweiten Controller weitergeleitet werden.
Nach dem Bestimmen der Übermittlungsstrategie wird die Über mittlungsstrategie für das Datenpaket durchgeführt.
Durch dieses Verfahren kann also eine Vorrichtung zum „Vor schalten" vor „übliche" Steuergeräte - z.B. von
Steuergeräten, die in der letzten Fahrzeuggeneration
verwendet wurden - realisiert werden. Dies ist auch
vorteilhaft, wenn die Schnittstellen der Mikrocontroller sich ändern. Dem zweiten Interface-Controller kann also eine weitere Hardware vorgeschaltet werden, die den Ethernet- Verkehr bearbeiten und/oder den Controller entlasten kann.
Weiterhin ist es damit möglich, die zweiten Interface- Controller von den ersten Interface-Controllern zu
entkoppeln. Dies kann beispielsweise genutzt werden, um die Anzahl der Interrupts und/oder den Protokoll-Overhead für die zweiten Interface-Controller zu reduzieren. Die zahlreichen Interrupts konnten zumindest bei manchen Steuergeräten den Effekt haben, dass die CPU der Steuergeräte über jeden eintreffenden Frame informiert wird und dadurch laufende Tasks unterbrochen werden konnten. Dies konnte manchmal dazu führen, dass Ethernet-Frames verworfen wurden und/oder pausierte Task können nicht zeitgerecht bearbeitet wurden. Dies zu vermeiden ist insbesondere in Hinblick auf ein
Bordnetz zum Transport von sicherheitskritischen Daten vorteilhaft. Dadurch kann es auch möglich werden, die
Bordnetzkommunikation dynamisch zu konfigurieren, z.B. auch in solchen Netzen, bei denen die Bordnetzkommunikation aus Gründen der Sicherheit, d.h. der funktionalen Sicherheit (Safety) , bisher statisch konfiguriert worden war. Dies kann auch für Multicast- sowie Broadcast-Kommunikation gelten.
Ein weiterer Aspekt der Erfindung betrifft ein Verfahren zur Übermittlung eines Datenpakets von mindestens einem zweiten Interface-Controller zu einem ersten Interface-Controller, mit den Schritten:
- Empfangen des Datenpakets, mittels des zweiten Interface- Controllers ;
- Bestimmen, mittels eines Daten-Analysators , einer
Übermittlungsstrategie für das Datenpaket, wobei die
Übermittlungsstrategie mindestens eine der folgenden Aktionen umfasst :
Verwerfen des Datenpakets (500), und/oder
Senden des Datenpakets (500) an den ersten Interface- Controller (110), und/oder
Senden des Datenpakets (500) an mindestens einen der
Pufferspeicher (131, 132), und/oder
Fragmentieren des Datenpakets (500) und senden an mindestens einen der Pufferspeicher (131, 132), und/oder
Senden des Inhalts des mindestens einen Pufferspeichers (131, 132) an den ersten Interface-Controller (110);
- Durchführen der Übermittlungsstrategie für das Datenpaket.
Die Übermittlung eines Datenpakets von mindestens einem zwei ten Interface-Controller zu einem ersten Interface-Controller kann auch als eine „inverse Operation" zu der Übermittlung eines Datenpakets von einem ersten Interface-Controller zu mindestens einem zweiten Interface-Controller verstanden werden. Diese beiden Operationen können so miteinander kombiniert werden, dass diese als ergänzende und/oder als bidirektionale Operationen aufgefasst werden können. Damit gelten auch für das Bestimmen und/oder das Durchführen der Übermittlungsstrategie analoge Überlegungen wie oben
erläutert .
In einer Ausführungsform umfasst die Übermittlungsstrategie weiterhin mindestens eine der folgenden Aktionen:
- Verwenden einer Charakterisierung für das Datenpaket. Die Charakterisierung kann dabei das Bestimmen eines Daten-Typus umfassen .
- Verwenden einer Zuordnung zu einem der Pufferspeicher und/oder zu einem der zweiten Interface-Controller für das Datenpaket. Dies kann z.B. vorteilhaft sein, wenn auf
schnelle Weise z.B. Videodaten und Telefondaten schnell
sortiert und den entsprechenden Geräten zugeordnet werden sollen .
- Verwenden einer Whitelist für das Datenpaket. Eine
Whitelist führt z.B. MAC-Adressen von Geräten auf, die übermitteln werden sollen. Alle anderen Daten werden
verworfen und reduzieren damit, insbesondere in Hinblick auf die Sicherheit der Geräte, das Risiko des Eindringens von unbefugten Adressen.
- Verwenden einer Priorität für das Datenpaket. Das Vergeben der Priorität kann abhängig von Typus der Daten geschehen.
Die Priorität der Daten kann Aktionen beeinflussen;
beispielsweise kann der Puffer von Daten mit höherer
Priorität schneller geleert werden oder Daten mit höherer Priorität können z.B. keine Puffer verwenden
- Verwenden einer Maximallast für das Datenpaket. Die
Maximallast kann die Last auf der Kommunikationsverbindung des ersten Interface-Controllers und/oder des zweiten
Interface-Controllers sein. Die Maximallast kann z.B. auch eine Maximalanzahl von Paketen pro Zeiteinheit für einen bestimmten Daten-Typus definiert werden und alle Pakete, welche die Maximalanzahl überschreiten, können verworfen werden. Die Maximalanzahl kann auch abhängig von einem bestimmten Absender definiert werden.
In einer Ausführungsform ist die Übermittlungsstrategie zumindest teilweise in einer Tabelle dargestellt. Die Tabelle kann beispielsweise umfassen: die Charakterisierung für das Datenpaket, Zuordnung zu einem der Pufferspeicher und/oder zu einem der zweiten Interface-Controller, Elemente einer White list für das Datenpaket, die Priorität für das Datenpaket, die Maximallast für das Datenpaket. Durch die Verwendung der
Tabelle kann das Verfahren weniger fehleranfällig werden. Außerdem ermöglicht die Tabelle eine dynamische
Konfiguration, entweder beim Einrichten des Fahrzeugs
und/oder bei einem Update und/oder durch eine
Konfigurationsdatei .
In einer Ausführungsform ist die Tabelle als ein Assoziativ speicher ausgestaltet. Dabei kann die Charakterisierung als ein Schlüssel für den Assoziativspeicher verwendet werden. Es können auch andere Schlüssel, z.B. zusammengesetzte Schlüssel oder auch nur ein Teil der Charakterisierung, verwendet werden. Ein Assoziativspeicher kann ein schnelleres Bestimmen der Übermittlungsstrategie ermöglichen.
In einer Ausführungsform umfasst die Übermittlungsstrategie weiterhin folgende Aktion:
- Einlesen der Tabelle von einem Konfigurationsmodul.
Damit ist eine einfache und schnelle Änderung der Übermitt lungsstrategie, bzw. beim Einrichten oder bei einem Update des Fahrzeugs möglich.
In einer Ausführungsform umfasst die Übermittlungsstrategie weiterhin folgende Aktion:
- Senden zumindest eines Teils des Datenpakets an ein
Protokollierungsmodul .
Damit kann vorteilhafterweise die Sicherheit der
Kommunikation weiter erhöht werden. Insbesondere können damit zumindest bestimmten Formen von Attacken festgestellt
und/oder nachvollzogen werden.
In einer Ausführungsform unterstützt der erste Interface- Controller ein Ethernet-Protokoll und der zweite Interface- Controller unterstützt ein paralleles Busprotokoll, ein serielles Busprotokoll und/oder ein Ethernet-Protokoll.
Damit kann eine breite Anwendbarkeit, z.B. auf verschiedene Kommunikationsverbindungen, Übertragungsmedien und/oder Übertragungsprotokolle erzielt werden.
In einer Ausführungsform weist das Verfahren weiterhin einen weiteren ersten Interface-Controller auf, wobei der weitere erste Interface-Controller dasselbe Protokoll wie der erste Interface-Controller unterstützt. Dies kann insbesondere bei Kommunikationsverbindungen mit Bus-Topologie, z.B. Ethernet, für eine Erhöhung der Leistung und/oder der Zuverlässigkeit genutzt werden.
In einer Ausführungsform wird der weitere erste Interface- Controller als redundanter erster Interface-Controller verwendet. Insbesondere bei Kommunikationsverbindungen mit Bus-Topologie kann damit dasselbe Datum mehrfach - z.B.
zweimal - mittels mehrerer erster Interface-Controller gelesen werden. Dies kann z.B. genutzt werden, um eine
Redundanzstrategie aufzubauen. Die Redundanzstrategie kann beispielsweise das gegenseitige Überprüfen der eingelesenen Daten, z.B. durch Vergleichen der Daten, beinhalten, das Abschalten von fehlerhaften Controllern und weitere
Redundanzstrategien .
Ein weiterer Aspekt der Erfindung betrifft ein Steuergerät zur Übermittlung eines Datenpakets von einem ersten
Interface-Controller zu mindestens einem zweiten Interface-
Controller und/oder zur Übermittlung eines Datenpakets von mindestens einem zweiten Interface-Controller zu einem ersten
Interface-Controller, das Steuergerät aufweisend:
einen ersten Interface-Controller,
einen Daten-Analysator,
mindestens einen Pufferspeicher, und
mindestens einen zweiten Interface-Controller.
Dabei ist das Steuergerät dazu eingerichtet, ein Verfahren wie oben und/oder in den Beispielen erläutert durchzuführen.
Das Steuergerät weist eine Reihe von Vorteilen auf. So ist ein Wechsel zu neuen Mikrocontrollern aufgrund einer
Einführung von Ethernet-Modulen in das Fahrzeug ohne große Änderungen möglich. Zumindest einige Plattformentwicklungen können trotz fehlender originären Protokollunterstützung weitergeführt werden, da derartigen Dem Controller nur das Steuergerät, als eine weitere Hardware, vorgeschaltet werden muss. Die vorgeschaltete Ethernet-Hardware kann auf Basis der vom Mikrocontroller erhaltenen Daten die Kommunikationsdaten anpassen. Anpassen heißt in diesem Kontext u.a. duplizieren, eliminieren, Adressen ändern und/oder prüfen.
Insbesondere ein Performancegewinn, aber auch ein Gewinn von Funktionalität, durch die Verwendung von Ethernet-basierter Kommunikation kann dabei genutzt werden. Beispielsweise können einige Ethernet-basierte Protokolle eine
Übertragungsrate von z.B. 100 Mbit/s realisieren, gegenüber beispielsweise einer Übertragungsrate von 0,5 Mbit des CAN- Busses. Auch wenn z.B. Sensoren wie Kamera und Radar
unkomprimierte Daten versenden, kann das Steuergerät
verwendet werden. Das Steuergerät und/oder das geschilderte
Verfahren kann deutlich geringere Hardwareressourcen
benötigen und kann daher gegebenenfalls mit vorhandenen
Implementierungen umgesetzt werden. Weiterhin kann damit das Sicherheitsniveau deutlich erhöht werden, in manchen
Ausführungsformen kann dies geschehen, ohne dass dies zu höheren Herstellungskosten für das Netzwerk oder für daran angeschlossene Geräte führt. Ein weiterer Vorteil dieses Steuergeräts ist zudem, dass eine vorhandene Hardware nicht verändert werden muss, sondern die vorhandene Hardware weiterverwendet werden kann. Das Steuergerät und/oder das Verfahren kann bei einigen Ausführungsformen in ein
bestehendes Netzwerk integriert werden, ohne dass vorhandene Geräte zu Schaden kommen.
In vorteilhafter Weise kann durch die Erfindung die Güte der Ausführung von Software-basierenden Anwendungen, z.B. bei einem zumindest teilweise automatisiert fahrenden Fahrzeug, erhöht werden, insbesondere mit besserer Absicherung in Bezug auf Safety und Security. Das erfindungsgemäße Netzwerksystem ist im Hinblick auf Kosten und Zuverlässigkeit verbessert. Durch die Integration der Ethernet-HW in der ECU kann weiter hin die Ausfallsicherheit der Systeme erhöht sein. In
vorteilhafter Weise kann durch die Erfindung die Sicherheit eines Fahrzeugnetzwerks signifikant und sehr simpel erhöht werden, insbesondere mit reduziertem finanziellen
Mehraufwand. Durch frühzeitigere Erkennung von Angriffen und Fehlverhalten mittels der frühen Analyse lassen sich Lücken und Fehler vor der Auslieferung des Fahrzeugs erkennen. Zudem bietet die Erfindung eine transparente
Sicherheitsfunktionalität .
Ein Vorteil dieser Erfindung ist zudem, dass die gängige Hardware nicht verändert werden muss, sondern die bestehende Hardware weiterverwendet werden kann. Dies kann zu weitgehend plattformunabhängigen Lösungen führen. Dadurch kann auch eine zumindest teilweise Kompatibilität zu neuen Protokollen wie z.B. AVB (Audio Video Bridging) und TSN (Time Sensitive
Networking) erreicht werden. Das Verfahren kann in ein bestehendes Netzwerk integriert werden, ohne dass vorhandene Geräte zu Schaden kommen.
In einer Ausführungsform ist das Steuergerät als ein ASIC oder als ein FPGA implementiert. Dies ermöglicht es, das Steuergerät ohne großen Platzbedarf z.B. mit einer
vorhandenen Hardware zu kombinieren und damit das
Anwendungsspektrum einfach und kostengünstig zu erweitern.
Ein weiterer Aspekt der Erfindung betrifft ein Steuerungs system zur Übermittlung eines Datenpakets von einem ersten Interface-Controller zu mindestens einem zweiten Interface- Controller und/oder zur Übermittlung eines Datenpakets von mindestens einem zweiten Interface-Controller zu einem ersten Interface-Controller, das Steuerungssystem aufweisend:
ein Steuergerät wie oben beschrieben,
ein Konfigurationsmodul, wobei das Steuergerät dazu
eingerichtet ist, eine Tabelle von dem Konfigurationsmodul einzulesen, und/oder
ein Protokollierungsmodul, wobei das Steuergerät dazu
eingerichtet ist, zumindest eines Teils des Datenpakets an das Protokollierungsmodul zu senden.
Ein weiterer Aspekt der Erfindung betrifft eine Verwendung eines Verfahrens, eines Steuergeräts oder eines Steuerungs systems wie oben und/oder in den Figuren beschrieben zur Übermittlung eines Datenpakets zwischen Controller-Modulen in einem Fahrzeug.
Ein weiterer Aspekt der Erfindung betrifft ein Fahrzeug mit einem Steuergerät oder einem Steuerungssystem wie oben und/oder in den Figuren beschrieben.
Die Erfindung kann außerhalb eines Fahrzeugs z.B. im Bereich von eingebetteten System eingesetzt werden. Hohe Sicherheits anforderungen, geringe Rechenleistung und langsame Plattform- Zyklen sind Beispiele für derartige Einsatzgebiete.
In einer Ausführungsform kann die Hardware für eine Funktion definiert werden, welche Filterfunktionen zur Verfügung stellt. Dazu werden die Filter (z.B. Datenparameter, Zeit einheit, Gültigkeitsdauer) an die Hardware übertragen und Aktionen definiert, welche bei Verletzung des Filters in Aktion treten sollen, wie z.B. Verwerfen der Daten, Verwerfen aller Daten ab dem Problem, Abspeichern der Daten, usw.
In einer Ausführungsform weist die Erfindung Funktionen zum Zusammenfügen bzw. Duplizieren von Daten auf. Hierbei werden vom Controller Datenstrompattern (IDs) an das System gemeldet auf deren Basis fusioniert, eliminiert oder dupliziert werden soll .
In einer Ausführungsform können die Nachrichten (Pakete) dynamisch an die Anforderungen/Kapazitäten des Controllers
angepasst werden sollen. Dabei kann z.B. die maximale
aktuelle Paketgröße vom Controller bestimmt werden. Die
Paketgröße und die Frequenz der Daten bestimmt letztendlich die entstehende Interrupt-Last des Controllers. Auf Basis dieser Erkenntnis wird dann in der Einheit die Paketgröße an die Anforderung angepasst. Treffen bspw. sehr große
Jumboframes von z.B. mehr als 1500 Byte ein, oder sehr kleine Frames von z.B. 64 Byte oder weniger, dann kann die Schaltung adaptiv neu zusammenstellen oder aufteilen. Dies kann
folgende Schritte umfassen:
- Prüfen der Ressourcenkapazität im Controller (in Bezug auf Security-Test, Verarbeitungsgeschwindigkeit, Speicher, etc.);
- Übermittlung der Parameter an die Zusatzhardware;
- Prüfen, ob einkommende Daten diesen Regeln entsprechen;
- Verarbeiten der Daten gemäß den Anforderungen;
- (optional) Rückmeldung über durchgeführte Aktionen an den Controller .
In einer Ausführungsform kann die Hardware so eingestellt werden, dass diese nur ab einer vordefinierten zulässigen Latenz verwendet wird.
In einer Ausführungsform weist kann die Hardware automatisch aktiviert werden, wenn z.B. Sicherheitsprotokolle erkannt werden bzw. Anforderungen erkannt werden (Headeranalyse der Ethernet-Hardware) . Hierbei kann die Hardware möglicherweise autark handeln und mit für diese Protokolle vordefinierten Filtern arbeiten. Eine Rückmeldung zur Aktivierung kann dann über den separaten Kontrollkanal an den Controller gegeben werden .
In einer Ausführungsform kann die Hardware bei Veränderung der Datenlast reagieren und diese auch über den Kontrollkanal zurückmelden. Steigt die Last pro Zeiteinheit an, so kann langsam und vorbereitend darauf reagiert werden und dies zusätzlich dem Controller gemeldet werden.
Zur weiteren Verdeutlichung wird die Erfindung anhand von in den Figuren abgebildeten Ausführungsform beschrieben. Diese Ausführungsformen sind nur als Beispiel, nicht aber als Ein schränkung zu verstehen.
Dabei zeigen :
Fig. 1: eine schematische Darstellung eines Steuergeräts gemäß einer Ausführungsform der vorliegenden
Erfindung;
Fig. 2: eine schematische Darstellung eines Steuergeräts gemäß einer weiteren Ausführungsform der vorliegenden Erfindung;
Fig. 3: eine schematische Darstellung eines Datenpakets
gemäß einer weiteren Ausführungsform der vorliegenden Erfindung;
Fig. 4: eine schematische Darstellung eines Teils einer
Tabelle gemäß einer weiteren Ausführungsform der vorliegenden Erfindung;
Fig. 5: eine schematische Darstellung eines Controllers in einem Fahrzeug gemäß einer Ausführungsform der vorliegenden Erfindung;
Fig. 6: eine schematische Darstellung einer Kommunikation mit vielen Kommunikationsverbindungen gemäß einer Ausführungsform der vorliegenden Erfindung;
Fig. 7: eine schematische Darstellung eines großen
Datenpakets auf einer Kommunikationsverbindung gemäß einer Ausführungsform der vorliegenden
Erfindung;
Fig. 8: eine schematische Darstellung von vielen Daten pro
Zeiteinheit auf einer Kommunikationsverbindung gemäß einer Ausführungsform der vorliegenden
Erfindung;
Fig. 9: eine schematische Darstellung eines ersten und
eines zweiten Interface-Controller gemäß einer Ausführungsform der vorliegenden Erfindung;
Fig. 10: eine schematische Darstellung einer Ausführungsform der vorliegenden Erfindung;
Fig. 11: eine schematische Darstellung einer Ausführungsform der vorliegenden Erfindung;
Fig. 12: eine schematische Darstellung einer Ausführungsform der vorliegenden Erfindung;
Fig. 13: eine schematische Darstellung einer Ausführungsform der vorliegenden Erfindung;
Fig. 14: eine schematische Darstellung einer Ausführungsform der vorliegenden Erfindung;
Fig. 15: eine schematische Darstellung einer Ausführungsform der vorliegenden Erfindung;
Fig. 16: eine schematische Darstellung einer Ausführungsform der vorliegenden Erfindung.
Fig. 1 zeigt eine schematische Darstellung eines Steuergeräts 100 gemäß einer Ausführungsform der vorliegenden Erfindung. Das Steuergerät 100 weist einen ersten Interface-Controller 110 auf, der mit einer Ethernet-Verbindung 420 verbunden ist. Die Ethernet-Verbindung 420 ist mit einer Ethernet-Leitung
400 verbunden. Die Ethernet-Leitung 400 kann Teil eines Fahrzeug-Kommunikationssystems sein. Der erste Interface- Controller 110 ist mit einem Daten-Analysator 120 verbunden, welcher dazu eingerichtet ist, eine Übermittlungsstrategie für ein Datenpaket 500 (siehe Fig. 3) zu bestimmen. Die
Übermittlungsstrategie kann z.B. umfassen, dass das Daten paket 500 verworfen wird. Dies kann z.B. bei Überlast auf der Ethernet-Verbindung 400, 420 der Fall sein oder wenn das Datenpaket 500 nicht für den ersten Interface-Controller 110 zugelassen ist, beispielsweise auf Basis einer Whitelist der MAC-Adressen . Der Daten-Analysator 120 ist in dieser
Ausführungsform mit einem Konfigurationsmodul 200 verbunden. Das Konfigurationsmodul 200 kann den Daten-Analysator 120, über das Interface 220, konfigurieren. Der Daten-Analysator 120 kann auch Daten an das Konfigurationsmodul 200 senden; dies kann z.B. ein einfaches „Acknowledge" für den Empfang der Daten umfassen, aber auch Daten, welche die
Umkonfiguration des Daten-Analysators 120 unterstützen. Der Daten-Analysator 120 ist weiterhin mit einem
Protokollierungsmodul 250 verbunden, welches zumindest Teile der Datenpakete 500 aufzeichnet. Dies kann z.B. zur
Entdeckung von sicherheitsrelevanten Szenarien verwendet werden .
Abhängig von Teilen des Datenpakets 500 kann das Datenpaket 500 z.B. direkt zu einem Fahrzeug-Controller 330 gesandt wer den. Dies ist durch den gestrichelt gezeichneten Puffer speicher 139 angedeutet; dieser Pufferspeicher 139 kann entweder sehr klein sein (z.B. nur einen Eintrag enthalten) oder kann auch entfallen, so dass eine direkte und damit schnelle Übertragung zu dem zweiten Interface-Controller 303
stattfinden kann. Abhängig von Teilen des Datenpakets 500 kann das Datenpaket 500 z.B. an den Pufferspeicher 131 und/oder 132 gesandt werden. Wenn das Datenpaket 500 an mehr als einen Pufferspeicher gesandt wird, so kann das die
Realisierung eines Multicast oder eines Broadcast sein. Der oder die Pufferspeicher 131, 132 können, über einen der zweiten Interface-Controller 301, 302, 303 an einen der
Fahrzeug-Controller 310, 320, 330 gesandt werden. In Fig. 1 ist dabei eine direkte Zuordnung der zweiten Interface- Controller 301, 302, 303 zu den Fahrzeug-Controller 310, 320, 330 dargestellt. In einer anderen Ausführungsform kann eine andere Zuordnung implementiert sein, z.B. kann der zweite Interface-Controller 302 sowohl an den Fahrzeug-Controller 310 als auch an den Fahrzeug-Controller 320 senden (nicht dargestellt). In einer anderen Ausführungsform kann z.B. der Fahrzeug-Controller 330 von beiden zweiten Interface- Controllern 301 und 302 Daten empfangen (nicht dargestellt) . Die Verbindung zwischen den zweiten Interface-Controllern 301, 302, 303 und den Fahrzeug-Controller 310, 320, 330 umfasst jeweils die Daten-Verbindungen 311, 321, 331 und die Interrupt-Verbindungen 312, 322, 332. Dies ist abhängig von der Wahl des Verbindungs-Protokolls zwischen den zweiten Interface-Controllern und den Fahrzeug-Controllern. Bei manchen Protokollen kann auf die Interrupt-Verbindungen verzichtet werden.
Fig. 2 zeigt eine schematische Darstellung eines Steuergeräts 100 gemäß einer weiteren Ausführungsform der vorliegenden Erfindung. Dabei weisen Komponenten mit den gleichen Bezugs zeichen wie bei Fig. 1 dieselbe oder eine analoge Funktion auf. Beispielsweise senden die Pufferspeicher 131, 132 in
Gegenrichtung wie bei Fig. 1. Diese in Fig. 2 gezeigte Aus führungsform kann beispielsweise verwendet werden, um Daten von einem der Fahrzeug-Controller 310, 320, 330 an die
Ethernet-Verbindung 420 zu senden. Im Gegensatz zu Fig. 1 steuert und/oder beeinflusst der Daten-Analysator 120 in dieser Ausführungsform nicht den ersten Interface-Controller 110, sondern die zweiten Interface-Controller 301, 302, 303. In einer anderen Ausführungsform kann der Daten-Analysator 120 mehrere der Komponenten des Steuergeräts 100 steuern, z.B. auch den ersten Interface-Controller 110.
Fig. 3 zeigt eine schematische Darstellung eines Datenpakets 500 gemäß einer weiteren Ausführungsform der vorliegenden Erfindung. Dabei sind deutlich der Header 510 und der Daten teil 520 des Datenpakets 500 erkennbar. Das Datenpaket 500 weist eine Gesamtlänge 501 auf. Der Datenteil 520 weist eine Datenlänge 521 auf. Die Übermittlungsstrategie des Daten- Analysators 120 kann durch Einträge im Header 510 und/oder im Datenteil 520 und/oder durch die Längen 501 und/oder 521 beeinflusst werden.
Fig. 4 zeigt eine schematische Darstellung eines Teils einer Tabelle 550 gemäß einer weiteren Ausführungsform der vorlie genden Erfindung. Die Tabelle weist als Beispiel die Zeilen 551, 552, 553, 554 auf. Jede der Tabellenzeilen 551, 552,
553, 554 weist dabei die Einträge Charakterisierung 560, Zuordnung 561, Whitelist 562, Priorität 563 und Maximallast 564 auf. Eine Ausführungsform der vorliegenden Erfindung kann diese Einträge, nur einen Teil dieser Einträge oder auch noch zusätzliche Einträge umfassen.
Die Charakterisierung 560 kann dabei das Bestimmen eines Daten-Typus umfassen. Beispiele für einen Daten-Typus können sein: Steuerinformationen für das Fahrzeug und/oder einen Aktor, Steuerinformationen für ein Gerät wie z.B. ein
Telefon, Sensor-Rohdaten, Infotainment-Daten, Audiodaten, Videodaten. Die Charakterisierung 560 kann beispielsweise auch als Schlüssel für einen Assoziativspeicher verwendet werden .
Die Zuordnung 561 kann eine Zuordnung zu einem der Puffer speicher und/oder zu einem der zweiten Interface-Controller sein. Es können einer, mehrere oder keiner der Pufferspeicher und/oder einer der zweiten Interface-Controller adressiert sein. Es kann der Eintrag „0" vorgesehen sein, wenn z.B. ein Datenpaket 500 mit einem vordefinierten Daten-Typus 560 in jedem Fall verworfen werden soll. Die Zuordnung 561 kann z.B. vorteilhaft verwendet werden, wenn auf schnelle Weise z.B. Videodaten und Telefondaten schnell sortiert und den
entsprechenden Geräten zugeordnet werden sollen.
Die Whitelist 562 kann bestimmte zulässige Adressen, z.B. MAC-Adressen oder Merkmale höherer Protokollschichten, auf weisen. Die Whitelist 562 kann leer sein.
Die Priorität 563 kann beispielsweise auf Basis einer Charak terisierung 560 vergeben werden oder auch, z.B. durch eine Definition in dem Konfigurationsmodul 200 (siehe Fig. 1 und 2) vorgegeben sein. So können z.B. Sensordaten eine höhere Priorität zugeordnet bekommen als beispielsweise Musikdaten. Abhängig davon können vordefinierte Typen von Daten bevorzugt behandelt werden.
Die Maximallast 564 kann sich z.B. auf das Kommunikations medium des ersten Interface-Controllers 110 beziehen. Es kann z.B. definiert sein, ab welcher Maximallast ein bestimmtes Datenpaket 500 zurückgewiesen bzw. verworfen wird.
Fig. 5 zeigt eine schematische Darstellung eines Controllers 310, 320, 330 in einem Fahrzeug gemäß einer Ausführungsform der vorliegenden Erfindung. Der Controller weist einen ersten Interface-Controller 110 auf, der direkt mit einem zweiten Interface-Controller 301, 302, 303 und einen Fahrzeug- Controller 310, 320, 330 verbunden ist.
Fig. 6 zeigt eine schematische Darstellung einer
Kommunikation mit vielen Kommunikationsverbindungen 400 gemäß einer Ausführungsform der vorliegenden Erfindung. Damit können einige der Interface-Controller 110 überlastet werden.
Fig. 7 zeigt eine schematische Darstellung eines großen
Datenpakets 500 auf einer Kommunikationsverbindung 400 gemäß einer Ausführungsform der vorliegenden Erfindung. Dies kann bei einigen der Interface-Controller 110 den maximalen
Eingangspuffer übersteigen.
Fig. 8 zeigt eine schematische Darstellung von vielen Daten paketen 500 pro Zeiteinheit auf einer
Kommunikationsverbindung 400 gemäß einer Ausführungsform der vorliegenden Erfindung. Dies kann bei einigen der Interface- Controller 110 die maximale Kapazität übersteigen. Dies kann beispielsweise durch eine sog. DoS-Attacke ausgelöst werden.
Fig. 9 zeigt eine schematische Darstellung eines ersten 110 und eines zweiten 301, 302, 303 Interface-Controllers gemäß einer Ausführungsform der vorliegenden Erfindung. Die CPU wird über jeden eintreffenden Frame informiert und kann dadurch laufende Tasks unterbrechen. Ethernet-Frames können möglicherweise verworfen werden, sowie pausierte Task können nicht zeitgerecht bearbeitet werden. Die vorliegende
Erfindung kann diese Effekte reduzieren. In manchen
Ausführungsformen kann die Bordnetzkommunikation zur
Reduktion dieser Effekte statisch konfiguriert sein. Ethernet kann Daten sowohl per Unicast als auch per Multicast und Broadcast versenden. Gelegentlich ist diese Adressierung nicht fix, weil Switches im Fehlerfall die Empfängeradresse ändern können. Wenn beispielsweise ein Empfänger nicht mehr erreichbar ist, kann der Switch möglicherweise einen mit Unicast adressierten Datenstrom an alle Controller
weiterleiten. Multicast- sowie Broadcast-Kommunikation kann nicht generell vermieden werden, weil sonst Protokolle wie ARP (Address Resolution Protocol) oder IEEE 802.1AS nicht mehr funktionieren könnten.
Die Verwendung von Ethernet und IP im Fahrzeug kann durch die geschilderten Verfahren und/oder Vorrichtungen verbessert werden. Die Art der Kommunikation (Client/Server) , welche Ethernet mit sich bringt, kann für zumindest einige Fahrzeuge neu sein. Die Ethernet-Kommunikation und/oder Spezifikationen neuerer Fahrzeug-Controller können schon zu hoher Busaus lastung führen. In einigen Ausführungsformen können z.B. sog. Netzwerk Cards verwendet werden. Bei derartigen Komponenten ist der Controller und der Transceiver auf einem separaten System integriert und damit vom Hauptsystem abgekoppelt.
Fig. 10 zeigt eine schematische Darstellung einer Ausführungsform der vorliegenden Erfindung. Dabei ist ein Steuergerät 100 zwischen die Verbindung, z.B. eine Ethernet- Verbindung, eingefügt. Damit können - anstatt oder zusätzlich zu anderen Maßnahmen - die Problemstellungen, wie sie in Fig. 6 bis 8 dargestellt sind, zumindest teilweise gemildert werden .
Dem Fahrzeug-Controller 310, 320, 330, z.B. einem Micro- controller (yC) oder Mikroprozessor (mR) bzw. einem System on Chip (SoC) , wird dabei eine Hardware mit Ethernet-Schnitt- stellen transparent vorgeschaltet. Transparent meint in diesem Zusammenhang, dass keine Protokollumsetzung erfolgen muss bzw. die Hardware auch fast unsichtbar für die Anwendung dargestellt werden kann. Die Hardware kann z.B. zwei
Ethernet-Schnittstellen aufweisen, welche in einer
Ausführungsform die gleiche Geschwindigkeit wie die vom yC anbieten. Zusätzlich dazu bietet die zusätzliche Komponente eine schnelle Konfigurationsschnittstelle 220 an, welche nicht über Ethernet geführt wird. Die Hardware kann entweder auf der Platine (OnBoard) oder durch ein Kabel mit dem yC (resp. dem PHY) verbunden sein. Die HW muss nicht zwangsweise auf dieselbe Platine gesetzt werden. Es kann sinnvoll sein, eine separate Konfigurationsleitung 220 zur Verfügung zu stellen. Die zusätzliche Hardware kann z.B. als ein
intelligenter 2-Port Ethernet-Switch-Baustein realisiert sein. Die zusätzliche Hardware kann auch als ein ASIC, z.B. mit Speicher und zwei Ethernet-Schnittstellen - im ASIC oder außerhalb - realisiert sein. Die Hardware kann z.B. als ein
solcher ASIC inkl . Register und 2 Ethernet-PHYs aufgebaut sein .
Fig. 11 zeigt eine schematische Darstellung einer
Ausführungsform der vorliegenden Erfindung. Dabei kann eine unter einigen Aspekten transparente (da weder ECU1 noch ECU2 eine Adresse dieser Komponente sehen, weder als Empfänger noch als Absender) Adressierung möglich sein. Dies ist in Fig. 11 durch einen bidirektionalen Pfeil 115 schematisch dargestellt. Dies kann möglich werden, wenn die zusätzliche Hardware nicht mehr adressiert wird und/oder adressiert werden soll. Das bedeutet, dass sie nicht auf Layer 2, sondern nach außen nur auf der physikalischen Schicht arbeitet .
Fig. 12 zeigt eine schematische Darstellung einer
Ausführungsform der vorliegenden Erfindung. Dabei handelt es sich um eine Ausführungsform, bei welcher die HW zwischen zwei unterschiedlichen Geschwindigkeiten vermittelt.
Hierdurch kann eine fehlende Schnittstelle des
Mikrocontrollers kompensiert werden und dieses Konzept mehr Anwendung finden. Hier kann zusätzlich die Hardware mit zusätzlichen Speicher ausgestattet werden, um die
hochfrequenten Pakete zwischenzuspeichern, bevor sie mit einer langsameren Verbindung weitergeleitet werden.
Fig. 13 zeigt eine schematische Darstellung einer
Ausführungsform der vorliegenden Erfindung. Dabei wird keine Priorität 563 vergeben, so dass die Datenströme 116 und 117 dieselbe Priorität aufweisen.
Fig. 14 zeigt eine schematische Darstellung einer Ausführungsform der vorliegenden Erfindung. Beispielsweise nach einem Softwareupdate können den Datenströmen 116 und 117 und der Software neue Prioritäten 563 zugeordnet werden. In der dargestellten Ausführungsform weist der Datenstrom 117 eine höhere Priorität auf als der Datenstrom 117. Dies kann z.B. genutzt werden, um Steuerungsdaten des Fahrzeugs, die als Datenstrom 117 ankommen, gegenüber einem Infotainment- Datenstrom 116 höher zu priorisieren . Die Erfindung erlaubt es, durch die vorgeschaltete Hardware, unabhängig vom
Fahrzeugnetzwerk, eine Entscheidung zu treffen und
ankommenden Sensordaten (in Datenstrom 117) höher bzw.
wichtiger zu priorisieren und beispielsweise gegenüber
Musikdaten vorzuziehen (und diese dann verzögert zu senden) . Diese Hardware könnte dann dynamisch, z.B. mittels des
Konfigurationsmoduls 200 (siehe Fig. 1 und/oder 2)
konfiguriert werden. Diese könnte sogar von einem anderen Teilnehmer des Netzwerks, also einen anderen ECU oder gar aus dem Backend, konfiguriert werden. D.h. die „Config" Schnitt stelle 220 kann auch als ein Bus oder Netzwerk ausgeführt sein .
Fig. 15 zeigt eine schematische Darstellung einer
Ausführungsform der vorliegenden Erfindung. Dabei sind an einen herkömmlichen Controller zwei Schnittstellen 110, 112 angeordnet, über welche Datenströme 116 und 117 geführt werden. Diese Datenströme können beispielsweise redundant betrieben bzw. konfiguriert werden.
Fig. 16 zeigt eine schematische Darstellung einer
Ausführungsform der vorliegenden Erfindung. Dabei sind an
einen herkömmlichen Controller zwei Schnittstellen 110, 112 angeordnet, über welche Datenströme 116 und 117 geführt werden. Diese Datenströme können beispielsweise redundant betrieben bzw. konfiguriert werden.
Bezugszeichenliste :
100 Steuergerät
110 erster Interface-Controller
112 weiterer erster Interface-Controller
115 Pfeil
116, 117 Datenströme
120 Header-Analyse
120 Daten-Analysator
131, 132 Pufferspeicher
139 Zwischenpuffer für Datenpakete
190 Steuerungssystem
200 Konfigurationsmodul
250 Protokollierungsmodul
301, 302, 303 zweiter Interface-Controller
310, 320, 330 Fahrzeug-Controller
311, 321, 331 Daten-Verbindung
312, 322, 332 Interrupt-Verbindung
400 Ethernet-Verbindung
420 Ethernet-Verbindung
500 Datenpaket
550 Tabelle
551, 552, 553, 554 Tabellenzeilen
560 Charakterisierung
561 Zuordnung
562 Whitelist
563 Priorität
564 Maximallast
Claims
Patentansprüche
1. Verfahren zur Übermittlung eines Datenpakets (500) von einem ersten Interface-Controller (110) zu mindestens einem zweiten Interface-Controller (301, 302, 303), mit den Schritten:
- Empfangen des Datenpakets (500), mittels des ersten Interface-Controllers (110);
- Bestimmen, mittels eines Daten-Analysators (120), einer Übermittlungsstrategie für das Datenpaket (500), wobei die Übermittlungsstrategie mindestens eine der folgenden Aktionen umfasst:
Verwenden einer Maximallast (564) für das Datenpaket (500), und/oder
Verwerfen des Datenpakets (500), und/oder Senden des Datenpakets (500) an mindestens einen der zweiten Interface-Controller (301, 302, 303), und/oder
Senden des Datenpakets (500) an mindestens einen der Pufferspeicher (131, 132), und/oder Fragmentieren des Datenpakets (500) und senden an mindestens einen der Pufferspeicher (131, 132), und/oder
Senden des Inhalts des mindestens eines Pufferspeichers (131, 132) an mindestens einen der zweiten Interface-Controller (301, 302, 303);
- Durchführen der Übermittlungsstrategie für das
Datenpaket (500).
2. Verfahren zur Übermittlung eines Datenpakets (500) von mindestens einem zweiten Interface-Controller (301, 302, 303) zu einem ersten Interface-Controller (110), mit den Schritten :
- Empfangen des Datenpakets (500), mittels des zweiten Interface-Controllers (301, 302, 303);
- Bestimmen, mittels eines Daten-Analysators (120), einer Übermittlungsstrategie für das Datenpaket (500), wobei die Übermittlungsstrategie mindestens eine der folgenden Aktionen umfasst:
Verwenden einer Maximallast (564) für das
Datenpaket (500), und/oder
Verwerfen des Datenpakets (500), und/oder
Senden des Datenpakets (500) an den ersten
Interface-Controller (110), und/oder
Senden des Datenpakets (500) an mindestens einen der Pufferspeicher (131, 132), und/oder
Fragmentieren des Datenpakets (500) und senden an mindestens einen der Pufferspeicher (131, 132), und/oder
Senden des Inhalts des mindestens einen
Pufferspeichers (131, 132) an den ersten Interface- Controller (110);
- Durchführen der Übermittlungsstrategie für das
Datenpaket (500).
3. Verfahren nach Anspruch 1 oder 2,
wobei die Übermittlungsstrategie weiterhin mindestens eine der folgenden Aktionen umfasst:
- Verwenden einer Charakterisierung (560) für das
Datenpaket (500);
- Verwenden einer Zuordnung (561) zu einem der
Pufferspeicher (131, 132) und/oder zu einem der zweiten
Interface-Controller (301, 302, 303) für das Datenpaket (500) ;
- Verwenden einer Whitelist (562) für das Datenpaket (500) ;
- Verwenden einer Priorität (563) für das Datenpaket (500)
und/oder
wobei die Maximallast:
- eine Last auf einer Kommunikationsverbindung des ersten Interface-Controllers und/oder des zweiten
Interface-Controllers ist; oder,
- eine Maximalanzahl von Paketen pro Zeiteinheit für einen Daten-Typus ist, wobei alle Pakete, welche die Maximalanzahl überschreiten, verworfen werden; oder,
- abhängig von einem Absender definiert ist.
4. Verfahren nach einem der vorhergehenden Ansprüche,
wobei die Übermittlungsstrategie zumindest teilweise in einer Tabelle (550) dargestellt ist.
5. Verfahren nach Anspruch 4,
wobei die Tabelle (550) als ein Assoziativspeicher ausgestaltet ist, wobei die Charakterisierung (560) als ein Schlüssel für den Assoziativspeicher verwendet wird.
6. Verfahren nach Anspruch 4 oder 5, wobei die
Übermittlungsstrategie weiterhin folgende Aktion
umfasst :
- Einlesen der Tabelle (550) von einem
Konfigurationsmodul (200).
7. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Übermittlungsstrategie weiterhin folgende Aktion umfasst :
- Senden zumindest eines Teils des Datenpakets (500) an ein Protokollierungsmodul (250).
8. Verfahren nach einem der vorhergehenden Ansprüche,
wobei der erste Interface-Controller (110) ein Ethernet- Protokoll unterstützt und
der zweite Interface-Controller (301, 302, 303) ein paralleles Busprotokoll, ein serielles Busprotokoll und/oder ein Ethernet-Protokoll unterstützt.
9. Verfahren nach einem der vorhergehenden Ansprüche,
weiterhin aufweisend einen weiteren ersten Interface- Controller (112),
wobei der weitere erste Interface-Controller (112) dasselbe Protokoll wie der erste Interface-Controller (110) unterstützt.
10. Verfahren nach einem der Ansprüche 8 oder 9,
wobei der weitere erste Interface-Controller (112) als redundanter erster Interface-Controller verwendet wird.
11. Steuergerät (100) zur Übermittlung eines Datenpakets
(500) von einem ersten Interface-Controller (110) zu mindestens einem zweiten Interface-Controller (301, 302, 303) und/oder zur Übermittlung eines Datenpakets (500)
von mindestens einem zweiten Interface-Controller (301, 302, 303) zu einem ersten Interface-Controller (110), das Steuergerät (100) aufweisend:
einen ersten Interface-Controller (110),
einen Daten-Analysator (120),
mindestens einen Pufferspeicher (131, 132), und
mindestens einen zweiten Interface-Controller (301, 302, 303) ,
wobei das Steuergerät (100) dazu eingerichtet ist, ein Verfahren nach einem der Ansprüche 1 bis 9
durchzuführen .
12. Steuergerät (100) gemäß Anspruch 11,
wobei das Steuergerät (100) als ein ASIC oder als ein FPGA implementiert ist.
13. Steuerungssystem (190) zur Übermittlung eines
Datenpakets (500) von einem ersten Interface-Controller (110) zu mindestens einem zweiten Interface-Controller (301, 302, 303) und/oder zur Übermittlung eines
Datenpakets (500) von mindestens einem zweiten
Interface-Controller (301, 302, 303) zu einem ersten Interface-Controller (110), das Steuerungssystem (190) aufweisend :
ein Steuergerät (100) gemäß Anspruch 11,
ein Konfigurationsmodul (200), wobei das Steuergerät (100) dazu eingerichtet ist, eine Tabelle (550) von dem Konfigurationsmodul (200) einzulesen, und/oder
ein Protokollierungsmodul (250), wobei das Steuergerät (100) dazu eingerichtet ist, zumindest eines Teils des
Datenpakets (500) an das Protokollierungsmodul (250) zu senden .
14. Verwendung eines Verfahrens nach einem der Ansprüche 1 bis 10, eines Steuergeräts (100) gemäß Anspruch 10, 11 oder 12 oder eines Steuerungssystems (190) gemäß
Anspruch 13 zur Übermittlung eines Datenpakets (500) zwischen Controller-Modulen in einem Fahrzeug. 15. Fahrzeug mit einem Steuergerät (100) gemäß Anspruch 10,
11 oder 12 oder einem Steuerungssystem (190) gemäß Anspruch 13.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| DE102018219246.4A DE102018219246A1 (de) | 2018-11-12 | 2018-11-12 | Steuergerätearchitektur für Fahrzeuge |
| PCT/EP2019/080819 WO2020099298A1 (de) | 2018-11-12 | 2019-11-11 | Steuergerätearchitektur für fahrzeuge |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| EP3881507A1 true EP3881507A1 (de) | 2021-09-22 |
Family
ID=68536863
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| EP19801860.8A Pending EP3881507A1 (de) | 2018-11-12 | 2019-11-11 | Steuergerätearchitektur für fahrzeuge |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US11902048B2 (de) |
| EP (1) | EP3881507A1 (de) |
| CN (1) | CN112997457A (de) |
| DE (1) | DE102018219246A1 (de) |
| WO (1) | WO2020099298A1 (de) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE102022210908A1 (de) | 2022-10-14 | 2024-04-25 | Elmos Semiconductor Se | Gateway zur verbindung mit einem sensor eines kraftahrzeugs und verfahren zum betreiben des gateways |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6791947B2 (en) * | 1996-12-16 | 2004-09-14 | Juniper Networks | In-line packet processing |
| US7042891B2 (en) * | 2001-01-04 | 2006-05-09 | Nishan Systems, Inc. | Dynamic selection of lowest latency path in a network switch |
| JP4591745B2 (ja) * | 2003-12-02 | 2010-12-01 | 富士ゼロックス株式会社 | 画像形成装置、パターン形成方法及びそのプログラム |
| US7444445B2 (en) * | 2006-07-30 | 2008-10-28 | International Business Machines Corporation | Selectively adjusting signal compensation parameters and data rate for transmission of data through a smart cable |
| GB2462406B (en) * | 2008-06-09 | 2011-02-23 | Gnodal Ltd | Method of data delivery across a network |
| CN105120496B (zh) * | 2009-11-06 | 2019-06-28 | 华为技术有限公司 | 负载控制方法和设备及通信系统 |
| US8891527B2 (en) * | 2012-02-03 | 2014-11-18 | Gigamon Inc. | Systems and methods for packet filtering and switching |
| WO2014138765A1 (de) * | 2013-03-14 | 2014-09-18 | Fts Computertechnik Gmbh | Vorrichtung und verfahren zur autonomen steuerung von kraftfahrzeugen |
| DE102013217259A1 (de) * | 2013-08-29 | 2015-03-05 | Bayerische Motoren Werke Aktiengesellschaft | Modusumschaltung eines Steuergeräts zwischen Diagnosebus und externer Ethernetverbindung |
| JP6983519B2 (ja) | 2017-03-08 | 2021-12-17 | 株式会社東芝 | パケット集約装置及び伝送処理プログラム |
-
2018
- 2018-11-12 DE DE102018219246.4A patent/DE102018219246A1/de active Pending
-
2019
- 2019-11-11 WO PCT/EP2019/080819 patent/WO2020099298A1/de unknown
- 2019-11-11 CN CN201980073954.6A patent/CN112997457A/zh active Pending
- 2019-11-11 US US17/291,140 patent/US11902048B2/en active Active
- 2019-11-11 EP EP19801860.8A patent/EP3881507A1/de active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| CN112997457A (zh) | 2021-06-18 |
| US11902048B2 (en) | 2024-02-13 |
| WO2020099298A1 (de) | 2020-05-22 |
| DE102018219246A1 (de) | 2020-05-14 |
| US20210392012A1 (en) | 2021-12-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| DE102005021820B4 (de) | Kommunikationsmitteilungs-Konvertierungseinrichtung, Kommunikationsverfahren und Kommunikationssystem | |
| DE102017211860B3 (de) | Verfahren zur Übertragung von Daten über einen seriellen Kommunikationsbus, entsprechend ausgelegte Busschnittstelle sowie entsprechend ausgelegtes Computerprogramm | |
| EP1566029B1 (de) | Gateway-einheit zur verbindung von subnetzen in fahrzeugen | |
| DE69830491T2 (de) | Cut-through -durchschaltung und paketfilterung in einem rechnersystem | |
| EP3248362B1 (de) | Datenübertragung in einem kommunikationsnetzwerk | |
| WO2015028342A1 (de) | Modusumschaltung eines steuergeräts zwischen diagnosebus und externer ethernetverbindung | |
| EP3542511B1 (de) | Verfahren für ein kommunikationsnetzwerk und elektronische kontrolleinheit | |
| DE102017120505A1 (de) | System zur Verifikation einer unregistrierten Vorrichtung basierend auf Informationen eines Ethernet-Switchs und Verfahren für dasselbige | |
| WO2018077528A1 (de) | Erkennung von manipulationen in einem can-netzwerk mittels überprüfung von can-identifiern | |
| EP2090031A2 (de) | Verfahren und anordnung zur kommunikation auf einem lin-bus | |
| EP3228036B1 (de) | Verfahren und steuergerät zur übertragung sicherheitsrelevanter daten in einem kraftfahrzeug mittels eines ethernet-standards | |
| WO2019030388A1 (de) | Verfahren, vorrichtung und computerprogramm zur dynamischen ressourcenzuweisung in einem mehrprozessor-computersystem | |
| DE102018215945A1 (de) | Verfahren und Vorrichtung zur Anomalie-Erkennung in einem Fahrzeug | |
| WO2018091401A1 (de) | Verfahren für ein kommunikationsnetzwerk und elektronische kontrolleinheit | |
| WO2020120550A1 (de) | Überlagerungserfassungseinheit für eine teilnehmerstation eines seriellen bussystems und verfahren zur kommunikation in einem seriellen bussystem | |
| WO2020099298A1 (de) | Steuergerätearchitektur für fahrzeuge | |
| EP3152872B1 (de) | Übertragungseinheit mit prüffunktion | |
| DE102014202826A1 (de) | Teilnehmerstation für ein Bussystem und Verfahren zur Erhöhung der Datenrate eines Bussystems | |
| DE102017012214B4 (de) | Verfahren zur Übertragung von Daten über einen seriellen Kommunikationsbus, entsprechend ausgelegte Busschnittstelle sowie entsprechend ausgelegtes Computerprogramm | |
| DE102019210224A1 (de) | Vorrichtung und Verfahren für Angriffserkennung in einem Rechnernetzwerk | |
| DE102019213322A1 (de) | Ethernet Physical Layer Transceiver für Zweidraht-Bustopologie | |
| DE102007049044A1 (de) | Vorrichtung und Verfahren zum Datenaustausch zwischen mindestens zwei Funktionsmodulen einer integrierten Schaltung | |
| WO2020088999A1 (de) | Teilnehmerstation für ein serielles bussystem und verfahren zum senden einer nachricht in einem seriellen bussystem | |
| EP1430647B1 (de) | Verfahren zum Betrieb eines Koppelknotens in einem Datennetz | |
| WO2021219337A1 (de) | Erkennen von fehlern in einem computernetzwerk |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: UNKNOWN |
|
| STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE |
|
| PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
| STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE |
|
| 17P | Request for examination filed |
Effective date: 20210614 |
|
| AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
| DAV | Request for validation of the european patent (deleted) | ||
| DAX | Request for extension of the european patent (deleted) | ||
| RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: CONTINENTAL AUTOMOTIVE TECHNOLOGIES GMBH |
|
| STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
| 17Q | First examination report despatched |
Effective date: 20230609 |
|
| RAP3 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: CONTINENTAL AUTOMOTIVE TECHNOLOGIES GMBH |