-
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 Übertragungsmedien an andere Übertragungsmedien und Übertragungsprotokolle 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. drahtlose 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 übermittelt 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 analysiert. 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, Audiodaten, 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 Übermittlungsstrategie 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-Controller 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 Pufferspeicher zu senden. Damit können beispielsweise große Datenpakete, welche das Protokoll und/oder die Eingangspuffer der zweiten Interface-Controller übersteigen, an die entsprechenden 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 Pufferspeichers 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 Übermittlungsstrategie für das Datenpaket durchgeführt.
-
Durch dieses Verfahren kann also eine Vorrichtung zum „Vorschalten“ 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 zweiten 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 Whitelist 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 Assoziativspeicher 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 Übermittlungsstrategie, 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 weiterhin 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 Steuerungssystem 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 Steuerungssystems 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 Sicherheitsanforderungen, 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, Zeiteinheit, 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 Einschränkung zu verstehen.
-
Dabei zeigen:
- 1: eine schematische Darstellung eines Steuergeräts gemäß einer Ausführungsform der vorliegenden Erfindung;
- 2: eine schematische Darstellung eines Steuergeräts gemäß einer weiteren Ausführungsform der vorliegenden Erfindung;
- 3: eine schematische Darstellung eines Datenpakets gemäß einer weiteren Ausführungsform der vorliegenden Erfindung;
- 4: eine schematische Darstellung eines Teils einer Tabelle gemäß einer weiteren Ausführungsform der vorliegenden Erfindung;
- 5: eine schematische Darstellung eines Controllers in einem Fahrzeug gemäß einer Ausführungsform der vorliegenden Erfindung;
- 6: eine schematische Darstellung einer Kommunikation mit vielen Kommunikationsverbindungen gemäß einer Ausführungsform der vorliegenden Erfindung;
- 7: eine schematische Darstellung eines großen Datenpakets auf einer Kommunikationsverbindung gemäß einer Ausführungsform der vorliegenden Erfindung;
- 8: eine schematische Darstellung von vielen Daten pro Zeiteinheit auf einer Kommunikationsverbindung gemäß einer Ausführungsform der vorliegenden Erfindung;
- 9: eine schematische Darstellung eines ersten und eines zweiten Interface-Controller gemäß einer Ausführungsform der vorliegenden Erfindung;
- 10: eine schematische Darstellung einer Ausführungsform der vorliegenden Erfindung;
- 11: eine schematische Darstellung einer Ausführungsform der vorliegenden Erfindung;
- 12: eine schematische Darstellung einer Ausführungsform der vorliegenden Erfindung;
- 13: eine schematische Darstellung einer Ausführungsform der vorliegenden Erfindung;
- 14: eine schematische Darstellung einer Ausführungsform der vorliegenden Erfindung;
- 15: eine schematische Darstellung einer Ausführungsform der vorliegenden Erfindung;
- 16: eine schematische Darstellung einer Ausführungsform der vorliegenden Erfindung.
-
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 3) zu bestimmen. Die Übermittlungsstrategie kann z.B. umfassen, dass das Datenpaket 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 werden. Dies ist durch den gestrichelt gezeichneten Pufferspeicher 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 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.
-
2 zeigt eine schematische Darstellung eines Steuergeräts 100 gemäß einer weiteren Ausführungsform der vorliegenden Erfindung. Dabei weisen Komponenten mit den gleichen Bezugszeichen wie bei 1 dieselbe oder eine analoge Funktion auf. Beispielsweise senden die Pufferspeicher 131, 132 in Gegenrichtung wie bei 1. Diese in 2 gezeigte Ausfü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 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.
-
3 zeigt eine schematische Darstellung eines Datenpakets 500 gemäß einer weiteren Ausführungsform der vorliegenden Erfindung. Dabei sind deutlich der Header 510 und der Datenteil 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.
-
4 zeigt eine schematische Darstellung eines Teils einer Tabelle 550 gemäß einer weiteren Ausführungsform der vorliegenden 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 Pufferspeicher 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, aufweisen. Die Whitelist 562 kann leer sein.
-
Die Priorität 563 kann beispielsweise auf Basis einer Charakterisierung 560 vergeben werden oder auch, z.B. durch eine Definition in dem Konfigurationsmodul 200 (siehe 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 Kommunikationsmedium des ersten Interface-Controllers 110 beziehen. Es kann z.B. definiert sein, ab welcher Maximallast ein bestimmtes Datenpaket 500 zurückgewiesen bzw. verworfen wird.
-
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.
-
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.
-
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.
-
8 zeigt eine schematische Darstellung von vielen Datenpaketen 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.
-
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 Busauslastung 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.
-
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 6 bis 8 dargestellt sind, zumindest teilweise gemildert werden.
-
Dem Fahrzeug-Controller 310, 320, 330, z.B. einem Microcontroller (µC) oder Mikroprozessor (µP) bzw. einem System on Chip (SoC), wird dabei eine Hardware mit Ethernet-Schnittstellen 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 µC 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 µC (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.
-
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 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.
-
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.
-
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.
-
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 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“ Schnittstelle 220 kann auch als ein Bus oder Netzwerk ausgeführt sein.
-
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.
-
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
