Gebiet

Die Erfindung betrifft Kommunikationsnetze in Kraftfahrzeugen, insbesondere die Verbindung von unterschiedliche Protokolle und ggf. unterschiedliche physikalische Schnittstellen implementierenden Kommunikationsnetzen.

Hintergrund

In modernen Kraftfahrzeugen findet sich eine Vielzahl von computergesteuerten Steuergeräten, von denen zumindest einige für eine optimale Funktion Daten und/oder Steuersignale anderer Steuergeräte benötigen. Da die Anforderungen jedes der Steuergeräte an die Menge der zu dessen Betrieb jeweils zu übertragenden oder zu empfangenden Daten sich stark unterscheiden, und nicht zuletzt auch aus Sicherheitsgründen nicht alle Steuergeräte über ein gemeinsam genutztes Kommunikationsnetz miteinander verbunden sind, hat sich eine Vielzahl unterschiedlicher Kommunikationsnetze entwickelt, welche parallel in Kraftfahrzeugen betrieben werden. Die unterschiedlichen Kommunikationsnetze nutzen dabei zum Teil unterschiedliche logische Protokolle und ggf. auch unterschiedliche physikalische Schnittstellen. Die unter den Abkürzungen oder Namen wie CAN (Controller Area Network), FlexRay, Ethernet, LIN (Local Interconnect Network), MOST (Media Oriented Systems Transport) bekannten Kommunikationsnetze stellen nur eine Auswahl von bekannteren, in Kraftfahrzeugen verwendeten Kommunikationsnetzen dar. Steuergeräte in Kraftfahrzeugen werden auch als Engine Control Unit oder Electronic Control Unit bezeichnet, wobei beide unter dem Akronym ECU zusammengefasst sind. In dieser Beschreibung wird der Begriff Kraftfahrzeugsteuergerät für die Hardware verwendet, und der Begriff ECU für ein eine Funktion oder eine Gruppe zusammengehörender Funktionen, sofern sich aus dem Kontext nichts anderes ergibt.

Um den Daten- oder Signalaustausch zwischen unterschiedlichen Kommunikationsnetzen eines Kraftfahrzeugs sicherzustellen ist in heutigen Kraftfahrzeugen ein speziell zu diesem Zweck vorgesehenes Steuergerät vorgesehen, welches auch als Gateway bezeichnet wird. Die Entwicklung und Herstellung eines solchen dedizierten Steuergeräts sowie die Integration in ein Kraftfahrzeug ist mit großem Aufwand verbunden, insbesondere wenn innerhalb unterschiedlicher Baureihen eines Herstellers oder unterschiedliche Hersteller stark voneinander abweichende Anforderungen bezüglich der zu verbindenden Kommunikationsnetze oder der Bauform des Gateways zu erfüllen sind. Zudem ist die Softwarearchitektur in der Regel exakt auf einen Hersteller und die konkrete Fahrzeugtopologie, d.h. , die in einem konkreten Fahrzeug vorhandenen Kommunikationsnetze und Steuergeräte zugeschnitten und dafür optimiert, um die Aufgabe mit möglichst minimalem Aufwand an Prozessorleistung und Speicher erfüllen zu können. Diese Spezialisierung verhindert die Anpassung und Wiederverwendung der Hardware und/oder Software bestehender Gateways für andere Fahrzeugarchitekturen, oder erschwert sie zumindest erheblich.

Zusammenfassung der Erfindung

Hiervon ausgehend hat die vorliegende Erfindung die Aufgabe, ein Kraftfahrzeuggateway zu schaffen, welches in einfacher Weise an unterschiedliche reale oder zumindest teilweise virtualisierte Hardwareumgebungen anpassbar ist. Es ist eine weitere Aufgabe, ein Verfahren zum an eine gegebene Hardwareumgebung angepassten Betrieb des Kraftfahrzeuggateways anzugeben.

Diese Aufgabe wird von der in Anspruch 1 vorgeschlagenen Vorrichtung und das in Anspruch 5 angegebene Verfahren gelöst. Vorteilhafte Ausgestaltungen und Weiterbildungen sind in den jeweiligen abhängigen Ansprüchen angegeben.

Ein Kraftfahrzeugsteuergerät gemäß einem ersten Aspekt der Erfindung umfasst mindestens einen Mikroprozessor, diesem zugeordneten flüchtigen und nichtflüchtigen Speicher, sowie eine oder mehrere physikalische Kommunikationsschnittstellen, welche über eine oder mehrere Datenleitungen oder -busse kommunikativ miteinander verbunden sind. Der Mikroprozessor ist dazu eingerichtet, ein Computer-Betriebssystem auszuführen. Der Mikroprozessor ist außerdem dazu eingerichtet, eine virtualisierte Gateway- Instanz mit einer Routerfunktion auszuführen.

Die Gateway-Instanz implementiert einen oder mehrere Protokollstapel für entsprechende Kommunikationsprotokolle. Dabei greift die Gateway-Instanz auf Funktionen des Computer-Betriebssystems über eine Betriebssystemabstraktionsschicht (OSAL) zu. Für die Kommunikation über eine physikalische Schnittstelle des Kraftfahrzeugsteuergerät beinhaltet die Gateway-Instanz eine angepasste Konfiguration und entsprechende Computerbefehle zur Ansteuerung der in einem Kemel des Computer- Betriebssystems implementierten Treiber für die physikalische Kommunikationsschnittstelle. Die Ansteuerung der Treiber erfolgt bspw. über eine POSIX-Schnittstelle. POSIX ist ein Akronym für „Portable Operating System Interface“ und bezieht sich auf eine in der ISO/IEC/IEEE 9945 Norm standardisierte Programmierschnittstelle, welche die Schnittstelle zwischen Anwendungssoftware und Betriebssystem darstellt.

Außerdem implementiert die Gateway-Instanz für die Kommunikation mit einer virtualisierten ECU eine virtuelle Schnittstelle, welche einer in der virtualisierten ECU implementierten virtuellen Schnittstelle entspricht.

In virtualisierten ECUs wird üblicherweise derselbe Typ Schnittstelle virtualisiert, wie er in einer physikalisch vorhandenen ECU vorliegt. In physikalisch vorhandenen ECUs dient dies u.a. der verbesserten Austauschbarkeit in unterschiedlichen Fahrzeugnetzen unterschiedlicher Fahrzeugmodelle. Außerdem kann so auf bewährte Systemdesigns, Entwicklungsumgebungen und Testinstallationen zurückgegriffen werden, was nicht zuletzt der Zuverlässigkeit und raschen Anpassbarkeit zugute kommt.

Mehrere virtualisierte ECUs mit unterschiedlichen Funktionen können von derselben Hardware eines Kraftfahrzeugsteuergeräts unabhängig voneinander ausgeführt werden.

Bei einer oder mehreren Ausgestaltungen ist die Routingfunktion entsprechend dazu eingerichtet, protokollgleiche virtuelle Schnittstellen zweier innerhalb desselben Kraftfahrzeugsteuergeräts virtualisierter ECUs über eine Kraftfahrzeugsteuergerät-interne Verbindung zu verbinden. Die Kraftfahrzeugsteuergerät-interne Verbindung kann zumindest ein Protokoll verwenden, das sich von demjenigen der virtuellen Schnittstellen unterscheidet. Häufig liegt zudem eine andere physikalische Verbindung vor.

So ist aus mittels in jeweils eigenen Containern virtualisierten Funktionen, welche grundsätzlich unabhängig voneinander ausgeführt werden, bekannt, Daten zwischen den Containern über virtuelle IP-Verbindungen auszutauschen. Eine alternative Kommunikation zwischen Containern kann über gemeinsam genutzten Speicherplatz erfolgen. Die physikalische Verbindung erfolgt in diesem Fall über den Speicherbus, wenngleich es für die virtualisierte Funktion aussieht, als erfolge die Kommunikation über eine „echte“ physikalisch vorhandene Schnittstelle.

Bei einer oder mehreren Ausgestaltungen ist die Routerfunktion dazu eingerichtet, virtuelle Schnittstellen zweier auf zwei unterschiedlichen Kraftfahrzeugsteuergeräten virtualisierten ECUs zunächst mit einer jeweilige Kraftfahrzeugsteuergerät-internen Verbindung zu verbinden. Die jeweiligen Kraftfahrzeugsteuergerät-internen Verbindungen sind mit mindestens einer die zwei Kraftfahrzeugsteuergeräten verbindenden physikalischen Kommunikationsschnittstelle verbunden, welche eine für einen vorliegenden Datenaustausch der virtualisierten ECUs ausreichende Kapazität bereitstellt.

Der Begriff Kapazität steht hierbei für die Anforderungen an die Kommunikation der virtualisierten ECUs, bspw. Datenrate, Timing, momentane Verfügbarkeit und dergleichen. Wenn die zwei Kraftfahrzeugsteuergeräte, auf denen jeweils eine ECU virtualisiert ist, mittels mehreren physikalischen Kommunikationsschnittstellen verbunden sind, kann die Routerfunktion eine für den momentanen Kommunikationsbedarf geeignete physikalische Schnittstelle auswählen.

Bei einer oder mehreren Ausgestaltungen ist die Routerfunktion der Gateway- Instanz dazu eingerichtet, eine Verbindung zwischen zwei ECUs anhand einer Korrelation von ECUs, unabhängig davon, ob diese physikalisch oder virtualisiert implementiert sind, bzw. in diesen implementierten SW-Funktionen und/oder den gemäß einer Netzwerktabelle in den ECUs implementierten bzw. vorhandenen Schnittstellen herzustellen.

Eine Verbindung zwischen zwei realen ECUs oder zwei ECUs, welche auf unterschiedlichen Kraftfahrzeugsteuergeräten virtualisiert sind, die über mehrere physikalische Schnittstellen verfügen, kann über eine beliebige der physikalischen Schnittstellen hergestellt werden, unabhängig davon über welche Schnittstelle die ECU oder die darauf implementierte SW-Funktion in einem klassischen System kommunizieren würde. Die Gateway-Instanz erhält dazu zur Compile- oder Laufzeit die Information, auf welchem Kraftfahrzeugsteuergerät die Funktion, an welche die Daten gesendet werden sollen, ausgeführt wird. In der Netzwerktabelle ist die Information zu den physikalisch vorhandenen Kommunikationsschnittstellen enthalten. So ist auch ein dynamisches Verteilen von Funktionen auf unterschiedliche Kraftfahrzeugsteuergeräte während des Betriebs möglich, etwa wenn ein Kraftfahrzeugsteuergerät ausfällt und die ursprünglich darauf ausgeführten Funktionen von anderen Kraftfahrzeugsteuergeräten übernommen werden.

Ein zweiter Aspekt der Erfindung betrifft ein Verfahren zum Routen von Datenpaketen von einer ersten ECU oder SW-Funktion zu einer zweiten ECU oder SW-Funktion mittels einer einem ersten Kraftfahrzeugsteuergerät virtualisierten Gateway-Instanz gemäß dem ersten Aspekt der Erfindung. Das Verfahren umfasst zunächst das Empfangen eines Datenpakets von der ersten ECU oder SW-Funktion. Das Datenpaket enthält eine Identifikation des Adressaten, d.h., der ECU oder SW-Funktion, für die es bestimmt ist. Anhand dieser Identifikation ermittelt die Gateway-Instanz, ob die zweite ECU oder SW- Funktion in dem ersten Kraftfahrzeugsteuergerät virtualisiert oder in einem über eine physikalische Schnittstelle verbundenen zweiten Kraftfahrzeugsteuergerät implementiert ist.

Wenn die zweite ECU oder SW-Funktion in einem über eine physikalische Schnittstelle verbundenen zweiten Kraftfahrzeugsteuergerät implementiert ist, wird das empfangene Datenpaket über die entsprechende physikalische Schnittstelle an den Empfänger oder einen weiteren Router oder Gateway gesendet, von wo aus das Datenpaket letztlich an den Empfänger geleitet wird. Je nach Kommunikationsprotokoll des Empfängers bzw. zwischen dem ersten Kraftfahrzeugsteuergerät und dem Empfänger liegender Kommunikationsverbindungen wird das Datenpaket ggf. einer entsprechenden Protokollumwandlung und/oder Kapselung unterworfen.

Wenn die zweite ECU oder SW-Funktion in dem ersten Kraftfahrzeugsteuergerät virtualisiert ist, wird das empfangene Datenpaket über die entsprechende virtualisierte Schnittstelle an eine Kraftfahrzeugsteuergerät- interne Kommunikationsverbindung und von der Kraftfahrzeugsteuergerät- internen Kommunikationsverbindung an eine virtualisierte Schnittstelle der virtualisierten ECU oder SW-Funktion gesendet. Auch hierbei kann ggf. eine Protokollumwandlung erfolgen.

Erfindungsgemäß umfasst das Verfahren, wenn die zweite ECU oder SW- Funktion in einem über mehrere physikalische Schnittstellen mit dem ersten Kraftfahrzeugsteuergerät verbundenen zweiten Kraftfahrzeugsteuergerät implementiert ist, das Bestimmen einer physikalischen Schnittstelle, welche das Datenpaket innerhalb einer zugelassenen maximalen Verzögerungszeit an die zweite ECU oder SW-Funktion übertragen kann. Hierbei können bspw. eine derzeitige Verfügbarkeit bzw. die Wartezeit, bis eine Schnittstelle verfügbar ist, eine Datenrate der Schnittstellen und dergleichen berücksichtigt werden. Sobald eine geeignete Schnittstelle bestimmt ist, wird das empfangene Datenpaket über die entsprechende physikalische Schnittstelle gesendet.

Bei einer oder mehreren Ausgestaltungen erfolgt das Ermitteln anhand einer Netzwerktabelle, in welcher virtuelle und physikalische Schnittstellen von ECUs und/oder SW-Funktionen sowie von diesen benötigte Datentypen und deren Absender miteinander korreliert sind.

Ein Computerprogrammprodukt gemäß einem weiteren Aspekt der Erfindung enthält Befehle, die bei der Ausführung durch einen Prozessor oder Computer diesen dazu veranlassen, eine oder mehrere Ausgestaltungen und Weiterentwicklungen des vorstehend beschriebenen Verfahrens ausführen. Das Computerprogrammprodukt kann auf einem computerlesbaren Medium bzw. Datenträger gespeichert sein. Das Medium bzw. der Datenträger kann physisch verkörpert sein, bspw. als Festplatte, CD, DVD, Flash-Speicher oder dergleichen, das Medium bzw. der Datenträger kann aber auch ein moduliertes elektrisches, elektromagnetisches oder optisches Signal umfassen, das von einem Computer mittels eines entsprechenden Empfängers empfangen und in dem Speicher des Computers gespeichert werden kann.

Ein Kraftfahrzeugsteuergerät mit einer virtualisierten Gateway-Instanz ermöglicht ein flexibles Einrichten der Gateway-Funktionen auf unterschiedlichen ECUs. Dabei kann die Gateway-Instanz je nach Netzwerkarchitektur des Kraftfahrzeugs als physisch separate ECU oder als virtuelle ECU auf einem Domain Controller zusammen mit anderen virtualisierten ECUs oder Funktionen ausgeführt sein. Neben Einsparungen bei der Hardware sind dadurch auch Verbesserungen der Performance erreichbar, insbesondere bei der Kommunikation zwischen virtualisierten ECUs. Dies liegt u.a. darin begründet, dass für die virtuellen Schnittstellen keine aufwendigen Treiber genutzt werden müssen, sondern eine Ansteuerung implementiert werden kann, welche weniger Ressourcen des Hostsystems verwendet.

Die Möglichkeit, in der Gateway-Instanz Protokolltransformationen zu implementieren und bereitzustellen, so dass eine automatische Protokollumwandlung zwischen Signal-, Service- und/oder Objekt-basierten Protokollen erfolgt, erweitert die Flexibilität und Verwendbarkeit des erfindungsgemäßen Kraftfahrzeugsteuergeräts zusätzlich. Hierzu können ggf. Codegeneratoren genutzt werden, welche auf Basis entsprechender Korrelationen geeigneten Source-Code erzeugen, welcher die jeweiligen Transformationen nach Bedarf umsetzt.

Durch die einfache Anpassbarkeit der auf generischen, ausgereiften Softwaremodulen aufbauenden Gateway-Instanz an unterschiedliche Fahrzeugarchitekturen unterschiedlicher Hersteller werden Entwicklungsaufwände reduziert.

Das erfindungsgemäße Verfahren kann vorteilhaft in Land-, Wasser- oder Luftfahrzeugen verwendet werden.

Kurze Beschreibung der Zeichnung Nachfolgend wird die Erfindung unter Bezugnahme auf die begleitenden Figuren exemplarisch näher erläutert. Alle Figuren sind rein schematisch, und für die Erläuterung unerhebliche Elemente können weggelassen sein. Es zeigen:

Fig. 1 eine exemplarische Darstellung von Komponenten einer virtualisierten Gateway-Instanz,

Fig. 2 eine exemplarische Darstellung von Komponenten einer auf einem dedizierten Kraftfahrzeugsteuergerät implementierten Gateway-ECU mit einer virtualisierten Gateway-Instanz mit Treibern für die physikalischen Schnittstellen, welche die virtuellen Interfaces ersetzen,

Fig, 3 eine weitere exemplarische Darstellung von Komponenten einer auf der Hardware eines Kraftfahrzeugsteuergeräts virtualisierten Gateway- Instanz, welche sowohl über virtuelle Interfaces als auch über Treiber für physikalische Schnittstellen verfügt,

Fig. 4 eine exemplarische Darstellung von Komponenten einer auf der Hardware eines Kraftfahrzeugsteuergeräts, auf der auch die Gateway- Instanz virtualisiert ist, virtualisierten ECU,

Fig. 5 ein exemplarisches Flussdiagramm eines Verfahrens zum Routen von Datenpaketen von einer ersten ECU oder SW-Funktion zu einer zweiten ECU oder SW-Funktion mittels einer in einem ersten Kraftfahrzeugsteuergerät virtualisierten erfindungsgemäßen Gateway- Instanz, und

Fig. 6 ein exemplarisches Blockdiagramm eines zur Ausführung eines oder mehrerer Aspekte des erfindungsgemäßen Verfahrens eingerichteten Kraftfahrzeugsteuergeräts.

Gleiche oder ähnliche Elemente sind in den Figuren mit gleichen oder ähnlichen Bezugszeichen versehen.

Ausführungsbeispiel Figur 1 zeigt eine exemplarische Darstellung von Komponenten einer virtualisierten Gateway-Instanz 100 eines Fahrzeugsystems. Die exemplarische Gateway-Instanz 100 umfasst eine Routerfunktion 102, mehrere Protokoll- Gateways 104 und mehrere Logikfunktionen oder Applikationen 106 zum Betrieb der Gateway-Instanz. Für die Kommunikation mit anderen die in dem Fahrzeugsystem vorhandenen ECUs sind entsprechende Protokollstapel vorhanden, d.h., für jede physikalisch vorhandene oder virtuell implementierte Kommunikationsschnittstelle einer ECU des Fahrzeugsystems ist der benötigte Protokollstapel in der Gateway-Instanz vorgesehen. In dem Beispiel sind Protokollstapel 110, 112, 114, 116 für ein LIN-Netzwerk, ein CAN-Netzwerk, ein FlexRay-Netzwerk und ein IP-basiertes Netzwerk vorhanden. Zu jedem Protokollstapel 110, 112, 114, 116 ist außerdem ein entsprechendes virtuelles Interface 120, 122, 124, 126 für die Kommunikation mit auf demselben Kraftfahrzeugsteuergerät virtualisierten ECUs implementiert. Wenn die Gateway-Instanz auf einem separaten Kraftfahrzeugsteuergerät virtualisiert ist, oder eine Kommunikation auf einem physikalisch separaten Kraftfahrzeugsteuergerät virtualisierten ECUs oder dedizierten nicht- virtualisierten ECUs, sog. „Legacy ECUs“, erforderlich ist, können die virtuellen Interfaces durch entsprechende Treiber für die physikalisch vorhandenen Netzwerke ergänzt werden oder diese ersetzen. Für den Zugriff auf Funktionen des Computer-Betriebssystems ist eine Betriebssystem-Abstraktionsschicht 130 vorgesehen.

Figur 2 zeigt eine exemplarische Darstellung von Komponenten einer auf einem dedizierten Kraftfahrzeugsteuergerät implementierten Gateway-ECU mit einer virtualisierte Gateway-Instanz 100 mit Treibern 120‘, 122‘, 124‘, 126' für die physikalischen Schnittstellen, welche die virtuellen Interfaces 120, 122, 124, 126 ersetzen. Die übrigen Elemente entsprechen denen aus Figur 1.

Die Virtualisierung der Gateway-Instanz erlaubt es, ausgehend von einer allgemeinen Gateway-Instanz und angepasst an die jeweiligen Gegebenheiten des Fahrzeugnetzes nur diejenigen Protokollstapel vorzusehen, für die in dem Fahrzeugnetz tatsächlich virtuelle oder physikalische Schnittstellen vorhanden sind. Durch den Einsatz von verifizierten und validierten modularisierten Softwarekomponenten werden dabei Fehlerquellen vermieden, und die jeweils benötigte Software kann schneller erstellt werden.

Figur 3 zeigt eine exemplarische Darstellung von Komponenten einer auf der Hardware eines Kraftfahrzeugsteuergeräts 10 virtualisierten Gateway-Instanz 100, die für die Kommunikation mit auf derselben Hardware virtualisierten ECUs und mit ECUs, welche auf einer separaten Hardware implementiert sind, eingerichtet ist. Eine beispielhafte, auf derselben Hardware wie die Gateway- Instanz virtualisierte ECU ist in Figur 4 gezeigt.

Entsprechend verfügt die Gateway-Instanz sowohl virtuelle Interfaces 120, 122, 124, 126 für die Kommunikation mit auf derselben Hardware virtualisierten ECUs als auch über Treiber 120‘, 122‘, 124‘, 126' für physikalische Schnittstellen zur Kommunikation mit auf einer separaten Hardware implementierten ECUs. Diese Kommunikation erfolgt in bekannter Weise und wird an dieser Stelle nicht weiter ausgeführt.

Die virtuellen Interfaces 120, 122, 124, 126 kommunizieren mit entsprechenden virtuellen Interfaces der anderen auf demselben Kraftfahrzeugsteuergerät virtualisierten ECU über eine Kraftfahrzeugsteuergerät-interne Kommunikationsschnittstelle 140. Die Kraftfahrzeugsteuergerät-interne Kommunikationsschnittstelle 140 kann dabei die über die virtuellen Interfaces 120, 122, 124, 126 nach dem jeweiligen Protokoll gesendeten Daten einkapseln und entsprechend eines anderen Protokolls an das virtuelle Interface des Empfängers senden, wo es entkapselt wird und im ursprünglichen Protokoll vorliegt.

Figur 4 zeigt eine exemplarische Darstellung von Komponenten einer auf der Hardware eines Kraftfahrzeugsteuergeräts 10, auf der auch die Gateway- Instanz 100 virtualisiert ist, virtualisierten ECU 200. Die exemplarische ECU 200 umfasst ein oder mehrere Logikfunktionen oder Applikationen 206 zum Betrieb der ECU. Für die Kommunikation mit anderen in dem Fahrzeugsystem vorhandenen ECUs sind entsprechende Protokollstapel vorhanden, in diesem Beispiel ein LIN-Protokollstapel 210 und ein IP-Protokollstapel 216, die beide mit der Gateway-Instanz über die Kraftfahrzeugsteuergerät-interne Kommunikationsschnittstelle 140 kommunizieren. Sofern die ECU 200 mit einer ECU kommunizieren muss, welche nicht auf derselben Hardware des Kraftfahrzeugsteuergeräts virtualisiert ist, wird eine Verbindung zu der Routerfunktion der Gateway-Instanz über eine entsprechende virtuelle Schnittstelle hergestellt, und die Routerfunktion stellt die Verbindung zu der Empfänger-ECU über eine geeignete physikalische Schnittstelle her.

Figur 5 zeigt ein exemplarisches Flussdiagramm eines Verfahrens 500 zum Routen von Datenpaketen von einer ersten ECU oder SW-Funktion zu einer zweiten ECU oder SW-Funktion mittels einer in einem ersten Kraftfahrzeugsteuergerät 10 virtualisierten erfindungsgemäßen Gateway- Instanz 100. In Schritt 502 wird ein Datenpaket von der ersten ECU oder SW- Funktion empfangen. Anschließend wird in Schritt 504 ermittelt, ob die zweite ECU oder SW-Funktion in dem ersten Kraftfahrzeugsteuergerät virtualisiert oder in einem über eine physikalische Schnittstelle mit dem ersten Kraftfahrzeugsteuergerät verbundenen zweiten Kraftfahrzeugsteuergerät implementiert ist. Wenn die zweite ECU oder SW-Funktion in einem mit dem ersten Kraftfahrzeugsteuergerät über eine physikalische Schnittstelle verbundenen zweiten Kraftfahrzeugsteuergerät implementiert ist, „j“-Zweig von Prüfschritt 506, wird das empfangene Datenpaket über die entsprechende physikalische Schnittstelle gesendet. Ggf. kann zuvor eine Protokollwandlung oder Kapselung erfolgen. Wenn die zweite ECU oder SW-Funktion in einem über mehrere physikalische Schnittstellen mit dem ersten Kraftfahrzeugsteuergerät 10 verbundenen zweiten Kraftfahrzeugsteuergerät implementiert ist, kann vor dem Senden in Schritt 510 in einem optionalen Schritt 508 eine physikalische Schnittstelle bestimmt werden, welche das Datenpaket innerhalb einer zugelassenen maximalen Verzögerungszeit an die zweite ECU oder SW-Funktion übertragen kann. Bei der Bestimmung der maximal zu erwartenden Verzögerungszeit kann u.a. die gegenwärtige Verfügbarkeit der Schnittstelle, deren Datenrate und dergleichen berücksichtigt werden.

Wenn die zweite ECU oder SW-Funktion in dem ersten Kraftfahrzeugsteuergerät virtualisiert ist, „n“-Zweig von Schritt 506, wird das empfangene Datenpaket in Schritt 512 über die entsprechende virtualisierte Schnittstelle an eine Kraftfahrzeugsteuergerät-interne Kommunikationsverbindung 140 und von der Kraftfahrzeugsteuergerät-internen Kommunikationsverbindung 140 an eine virtualisierte Schnittstelle der virtualisierten ECU oder SW-Funktion gesendet. Auch hier kann ggf. zuvor eine Protokollwandlung oder Kapselung erfolgen.

Figur 6 zeigt ein exemplarisches Blockdiagramm eines zur Ausführung eines oder mehrerer Aspekte des erfindungsgemäßen Verfahrens eingerichteten Kraftfahrzeugsteuergeräts 10. Kraftfahrzeugsteuergerät 10 umfasst neben einem Mikroprozessor 12 flüchtigen und nichtflüchtigen Speicher 14 bzw. 16 sowie mindestens eine Kommunikationsschnittstelle 18. Die Elemente des Kraftfahrzeugsteuergeräts 10 sind über eine oder mehrere Datenverbindungen oder -busse 20 kommunikativ miteinander verbunden. Der nichtflüchtige Speicher 16 enthält Computerprogramminstruktionen die, wenn sie von dem Mikroprozessor 12 ausgeführt werden, das Kraftfahrzeugsteuergerät 10 zur Ausführung des erfindungsgemäßen Verfahrens 500 einrichten.

Bezuqszeichenliste

10 Kraftfahrzeugsteuergerät 124, 124’ virtuelles FlexRay

12 Mikroprozessor Interface

14 flüchtiger Speicher 126, 126’ virtuelles Ethernet

16 nichtflüchtiger Speicher Interface

18 physikalische 130 Betriebssystem-

Kommunikationsschnittstelle Abstraktionsschicht

20 Datenverbindung/-bus 140 Kraftfahrzeugsteuergerät-

100 Gateway-Instanz interne Kommunikation

102 Routerfunktion 200 virtualisierte ECU

104 Protokoll-Gateways 500 Verfahren

106 Logikfunktionen / 502 Empfangen

Applikationen 504 Ermitteln

110 LIN-Protokollstapel 506 Prüfen

112 CAN-Protokollstapel 508 Bestimmen

114 FlexRay-Protokollstapel 510 Senden

116 IP-Protokollstapel 512 Senden

120, 120’ virtuelles LIN Interface

122, 122’ virtuelles CAN

Interface