DE102020134185A1

DE102020134185A1 - Verfahren zur Durchleitung von Service-Anfragen und Echtzeitrechner zur Durchführung des Verfahrens zur Durchleitung von Service-Anfragen

Info

Publication number: DE102020134185A1
Application number: DE102020134185.7A
Authority: DE
Inventors: Remigiusz Seiler
Original assignee: Dspace GmbH
Current assignee: Dspace GmbH
Priority date: 2020-12-18
Filing date: 2020-12-18
Publication date: 2022-06-23

Abstract

Die Erfindung betrifft ein Computer-implementiertes Verfahren zur Durchleitung einer ersten Anfrage-Nachricht eines auf einem ersten Rechenknoten implementierten ersten Consumers eines Services durch einen Echtzeitrechner mittels einer auf dem Echtzeitrechner implementierten Netzwerk-Simulation, an einen auf einem zweiten Rechenknoten implementierten Provider und zur Durchleitung der entsprechenden ersten Antwort-Nachricht des Providers an den ersten Consumer. Die Erfindung betrifft auch einen Echtzeitrechner zur Durchführung des erfindungsgemäßen Verfahrens.

Description

Die Erfindung betrifft ein Computer-implementiertes Verfahren zur Durchleitung einer ersten Anfrage-Nachricht eines auf einem ersten Rechenknoten implementierten ersten Consumers eines Services durch einen Echtzeitrechner mittels einer auf dem Echtzeitrechner implementierten Netzwerk-Simulation, an einen auf einem zweiten Rechenknoten implementierten Provider und zur Durchleitung der entsprechenden ersten Antwort-Nachricht des Providers an den ersten Consumer. Der erste Rechenknoten ist über ein erstes reales Netzwerk mit dem Echtzeitrechner verbunden und es können noch weitere Consumer für diesen oder weitere Services des Providers auf dem ersten Rechenknoten implementiert sein. Weiter ist der Echtzeitrechner über ein zweites reales Netzwerk mit dem zweiten Rechenknoten verbunden, wobei die Netzwerk-Simulation auf dem Echtzeitrechner einen simulierten Provider aufweist, welcher den Provider auf dem zweiten Rechenknoten als Gegenstück für die Consumer auf dem ersten Rechenknoten simuliert. Weiter weist die Netzwerk-Simulation mindestens zwei simulierte Consumer für Services des Providers auf, welche die Consumer auf dem ersten Rechenknoten als Gegenstück für den Provider auf dem zweiten Rechenknoten und für den simulierten Provider simulieren.
Die Erfindung betrifft auch einen Echtzeitrechner zur Durchführung des erfindungsgemäßen Verfahrens.
Solche Verfahren finden beispielsweise Anwendung beim Test von Steuergeräten, wenn die Kommunikation eines oder mehrerer Steuergeräte eines Netzwerks, z.B. eines (automotive) Ethernet-Netzwerks, getestet werden soll und in das Netzwerk ein Echtzeitrechner (i.d.R. als Hardware-inthe-Loop (HIL)-Rechner bezeichnet) eingebracht wird, um zu Testzwecken z.B. eine Restbus-Simulation durchzuführen und/oder Nachrichten zu manipulieren. Handelt es sich bei der zu testenden Kommunikation um eine Service-basierte Kommunikation, wie sie beispielsweise im AUTOSAR-Standard beschrieben ist, so gibt es Anbieter (im Folgenden: Provider), die auf Anfrage Abnehmern (Consumern) eine Funktion oder Methode über einen Dienst (Service) zur Verfügung stellen. Jede Anfrage ist gekennzeichnet durch eine Anfrage-Identifikation (Anfrage-ID), welche sich aus einer Identifikation für den Consumer (Client-ID) und einer Identifikation der sogenannten Session (Session-ID) bestimmt. Befinden sich alle Consumer auf einem einzigen Steuergerät, während sich der Provider auf einem zweiten Steuergerät befindet, so kann der Provider anhand der Anfrage-ID, bzw. insbesondere anhand der Client-ID, entscheiden, an welchen Consumer er eine Antwort auf eine Anfrage schicken muss. Sind die Consumer für die Dienste des Providers jedoch auf mehrere Rechenknoten des Netzwerks verteilt, so kann es sein, dass mehrere Rechenknoten ein und dieselbe Client-ID für Anfragen der auf ihnen implementierten Consumer vergeben, sodass der Provider auf dem zweiten Rechenknoten die entsprechende IP-Adresse des Steuergeräts und den Port (d.h. den UDP oder TCP Port des Netzwerks), von dem die Anfrage kommt, heranziehen muss. Ist zu Test- und Manipulationszwecken ein Echtzeitrechner mit einer Netzwerk-Simulation zwischen die Rechenknoten geschaltet, auf denen sich Consumer und Provider befinden, so muss auch im Rahmen der Netzwerk-Simulation eine eindeutige Zuordnung von Antworten zu Anfragen, bzw. den entsprechenden Sendern und Empfängern erfolgen.
Aufgabe der Erfindung ist es, den Stand der Technik für den Fall weiterzubilden, dass die Consumer auf mehrere Rechenknoten verteilt sind, dass also mindestens noch ein dritter Rechenknoten mit einem zweiten Consumer über das erste reale Netzwerk mit dem Echtzeitrechner verbunden ist. In diesem Fall weist die Netzwerk-Simulation auf dem Echtzeitrechner auch simulierte Consumer auf, welche die Consumer auf dem dritten Rechenknoten als Gegenstück für den Provider auf dem zweiten Rechenknoten und für den simulierten Provider auf dem Echtzeitrechner simulieren.
Die Aufgabe wird erfindungsgemäß durch folgende Verfahrensschritte gelöst:

a) Für die simulierten Consumer wird jeweils eine interne ID für ihre Service-basierten Anfragen berechnet, wobei die interne ID für einen simulierten Consumer so aufgebaut ist, dass sie mit einer entsprechenden internen ID des zu simulierenden Consumers übereinstimmt,
b) der erste Consumer schickt die erste Anfrage-Nachricht an den simulierten Provider auf dem Echtzeitrechner,
c) der simulierte Provider berechnet eine erste interne ID für die erste Anfrage-Nachricht des ersten Consumers,
d) die vom simulierten Provider berechnete erste interne ID wird mit den internen IDs der simulierten Consumer verglichen,
e) der simulierte Provider leitet die erste Anfrage-Nachricht an einen ersten simulierten Consumer weiter, wobei die Identifizierung des ersten simulierten Consumers durch eine Übereinstimmung beim Abgleich der ersten internen ID mit den internen IDs der simulierten Consumer erfolgt,
f) der erste simulierte Consumer versendet eine entsprechende erste Anfrage-Nachricht (ohne Weitergabe der internen ID) an den Provider auf dem zweiten Rechenknoten,
g) der Provider auf dem zweiten Rechenknoten versendet eine Antwort-Nachricht an den ersten simulierten Consumer,
h) der erste simulierte Consumer leitet die erhaltene Antwort-Nachricht inklusive seiner internen ID an den simulierten Provider weiter,
i) Der simulierte Provider versendet die Antwort-Nachricht an den ersten Consumer auf dem ersten Steuergerät anhand eines Abgleichs der mit der Antwort-Nachricht empfangenen internen ID des ersten simulierten Consumers mit den entsprechenden internen IDs für die Consumer auf dem ersten Rechenknoten oder dritten Rechenknoten oder mit der ersten internen ID für die erste Anfrage-Nachricht.

Es sei angemerkt, dass es unerheblich ist, wann genau Verfahrensschritt a) ausgeführt wird, ob vor der Laufzeit der Kommunikation/Simulation oder während der Laufzeit. Wesentlich ist hierbei nur, dass zum Zeitpunkt des Abgleichs mit der vom simulierten Provider berechneten internen ID die zu vergleichenden internen IDs der simulierten Consumer vorliegen. Da die in Schritt a) berechneten internen IDs der simulierten Consumer mit den internen IDs der Consumer auf den Rechenknoten übereinstimmen, können die in Schritt a) berechneten internen IDs auch für den Abgleich in Schritt i) verwendet werden.
Weiter sei angemerkt, dass die Netzwerk-Simulation auf dem Echtzeitrechner so eingerichtet ist, dass der Empfang einer Anfrage-Nachricht von einem Consumer beim simulierten Provider über das erste reale Netzwerk eine Weiterleitung der Anfrage-Nachricht an den entsprechenden simulierten Consumer anstößt und der Empfang einer Anfrage-Nachricht bei einem simulierten Consumer eine Weiterleitung der Anfrage-Nachricht über das zweite reale Netzwerk an den Provider auf dem zweiten Rechenknoten anstößt und wobei der Empfang einer Antwort-Nachricht vom Provider bei einem simulierten Consumer eine Weiterleitung der Antwort-Nachricht an den simulierten Provider anstößt, welcher die Antwort-Nachricht dann an den Consumer weiterleitet, von dem er die entsprechende Anfrage-Nachricht erhalten hatte.
Eine Weiterleitung oder Übergabe von Nachrichten innerhalb des Echtzeitrechners vom simulierten Provider an den simulierten Consumer oder umgekehrt kann auf zwei verschiedene Weisen erfolgen. In einer ersten Ausführungsform löst der Empfang einer (Anfrage- oder Antwort-) Nachricht (d.h. eine Erhöhung des Empfangszählers) aus, dass die ankommende Nachricht geparsed wird und die einzelnen Werte in Variablen geschrieben werden. Anschließend werden diese Werte in einer geeigneten Programmiersprache (z.B. C oder auch Simulink^®) weiteren Variablen zugewiesen. Diese weiteren Variablen werden anschließend serialisiert in einen Puffer geschrieben, der dann an den nächsten Empfänger (d.h. an den simulierten Consumer oder - im Fall der Weiterleitung einer Antwort-Nachricht - an den simulierten Provider) abgeschickt wird. Im Prinzip entspricht dies einer Parameterübergabe.
Eine zweite Ausführungsform der Weiterleitung oder Übergabe besteht darin, die Daten der empfangenen Nachricht nicht mehr automatisch zu parsen, sondern die Daten im Eingangspuffer zu belassen und nur dem simulierten Consumer (oder simulierten Provider) Zugriff auf den Eingangspuffer zu verschaffen, um diesen als Ausgangspuffer zu nutzen. Dies ist ein Zero-Copy-Mechanismus. Eine zwischenzeitliche Manipulation der Daten im Puffer zu Testzwecken kann trotzdem erfolgen.
Zur Identifizierung des entsprechenden simulierten Consumers für die Weiterleitung der Anfrage-Nachricht dienen die erfindungsgemäß in Schritt c) für die ersten Anfrage-Nachricht berechnete erste interne ID und der in Schritt d) ausgeführte Vergleich mit den in Schritt a) berechneten und dem simulierten Provider auf dem Echtzeitrechner zur Verfügung stehenden internen IDs der simulierten Consumer. Die Berechnung der ersten internen ID ermöglicht ebenfalls die Identifizierung des Consumers an den die entsprechende Antwort-Nachricht zu senden ist.
Der Vergleich der internen IDs erfolgt bevorzugt durch geeignete, auf dem Echtzeitrechner vorgehaltene Programmanweisungen.
In Schritt f) versendet der identifizierte erste simulierte Consumer eine entsprechende erste Anfrage-Nachricht, d.h. er leitet die erste Anfrage-Nachricht an den Provider auf dem zweiten Rechenknoten weiter. Diese Weiterleitung erfolgt über das zweite reale Netzwerk, in welchem der Echtzeitrechner mit dem zweiten Rechenknoten verbunden ist und zwar ohne Übergabe der ersten internen ID, da das erste und das zweite reale Netzwerk i.d.R. Standard-konform sind, z.B. konform mit dem SOME/IP-Protokoll des AUTOSAR-Standards, bei dem nach jetzigem Standard eine solche interne ID nicht vorgesehen ist und somit auch nicht versendet wird. Auf dem Rückweg der Antwort-Nachricht vom Provider auf dem zweiten Rechenknoten zum ersten Consumer über den Echtzeitrechner übergibt der erste simulierte Consumer in Schritt h) die Antwort-Nachricht an den simulierten Provider inklusive seiner internen ID, welche mit der in Schritt c) berechneten ersten internen ID für den ersten Consumer übereinstimmt und dem simulierten Provider so eine Identifizierung des Consumers ermöglicht, an den die Antwort-Nachricht zu senden ist. Da die internen IDs erfindungsgemäß so aufgebaut sind, dass sie für jeden Consumer i.d.R. (d.h. bis auf sehr wenige, eher unwahrscheinliche Ausnahmen) eindeutig sind und mit der internen ID des entsprechenden simulierten Consumers übereinstimmen, können die internen IDs für alle Consumer auch schon vor Beginn der Simulation berechnet und auf dem Echtzeitrechner, zugänglich für den simulierten Provider hinterlegt werden, beispielsweise in einer Lookup-Tabelle oder einfach als Objekt im Rahmen einer Objekt-orientierten Programmierung. Der Abgleich zur Identifizierung des Consumers an den die Antwort vom simulierten Provider zu Versenden ist, kann somit auf Basis der hinterlegten internen IDs erfolgen, während die in Schritt c) berechnete interne ID, die sowohl zur Identifizierung des Absenders als auch zur Ermittlung des simulierten Consumers, an den die Anfrage-Nachricht weiterzuleiten ist, dient, verworfen werden kann. Alternativ wäre es möglich, diese berechnete interne ID für die Identifizierung der Antwort-Nachricht zu hinterlegen.
Die Netzwerk-Simulation auf dem Echtzeitrechner dient dazu, in der eigentlich zu testenden Netzwerk-Kommunikation zwischen den Consumern und dem Provider unbemerkt Nachrichten durchleiten, aber dabei auch abfangen, manipulieren und versenden zu können. D.h. der Echtzeitrechner ist für Consumer und Provider auf den Rechenknoten quasi transparent. Zu diesem Zweck wird das eigentlich zu testende Netzwerk in zwei unabhängige Netzwerke aufgeteilt, nämlich das erste reale Netzwerk, in dem die Consumer mit dem Echtzeitrechner verbunden sind und das zweite reale Netzwerk, in dem der Provider mit dem Echtzeitrechner verbunden ist. Die Kommunikationspartner für Consumer und Provider werden durch die simulierten Kommunikationspartner ersetzt, sodass der Echtzeitrechner für Consumer und Provider „unsichtbar“ ist. Beide realen Netzwerke sind völlig getrennt, sodass z.B. die simulierten Consumer in dem zweiten realen Netzwerk dieselbe IP-Adresse haben können, wie die Consumer in dem ersten realen Netzwerk.
Vorteilhaft an dem erfindungsgemäßen Verfahrens ist es, dass die Identifizierung der Kommunikationspartner, an die eine Nachricht weitergeleitet werden muss, nicht mehr auf der Client-ID basiert, welche bei mehreren Rechenknoten mehrfach vergeben werden könnte, da die Vergabe innerhalb der Rechenknoten erfolgt und obendrein nur durch einen Bereich eingeschränkt sein kann.
Ein weiterer Vorteil ist, dass durch die Vergabe einer einzigen, eindeutigen internen ID als einem einzigen Integer-Wert die Identifizierung bei der Weiterleitung von Anfrage und Antwort erleichtert wird, da nicht mehrere Größen übergeben und verglichen werden müssen.
In einer weiteren Ausführungsform des Verfahrens ist mindestens einer der Rechenknoten ein zu testendes Steuergerät und die benötigten Informationen zur Berechnung der internen IDs werden der sogenannten Kommunikationsmatrix der zu testenden Steuergerätekommunikation entnommen und/oder dem simulierten Provider und den simulierten Consumern - d.h. im Wesentlichen: der Netzwerk-Simulation auf dem Echtzeitrechner - zur Verfügung gestellt.
Bei dieser bevorzugten Ausführungsform können beispielsweise der erste und der dritte Rechenknoten durch ein zu testendes Steuergerät gegeben sein und der zweite Rechenknoten kann z.B. durch einen Simulations-PC für das Test-System gegeben sein, auf dem ein Modell ausgeführt wird, das beispielsweise ein Fahrzeug für die Steuergeräte simuliert. Die für das Testsystem typischer Weise bekannte Kommunikationsmatrix enthält unter anderem die für die Kommunikation wichtigen Informationen wie die IP-Adresse der Steuergeräte, die Ports, über welche die Kommunikation erfolgen soll, die Namen der angebotenen Services und Methoden, die zugehörigen Identifikationen (IDs) und vieles mehr. Vorteilhafterweise werden die für die Simulation der in der Kommunikationsmatrix beschriebenen Consumer und Provider benötigten Informationen mittels eines Hilfsprogramms automatisch aus der Kommunikationsmatrix extrahiert und der Netzwerk-Simulation auf dem Echtzeitrechner, bspw. als Konfiguration zur Verfügung gestellt.
In einer bevorzugten Ausführungsform der Erfindung betrifft die erste Anfrage-Nachricht eine Anfrage für einen Methoden-Aufruf und sowohl der Methode als auch dem Service ist eine ID zugeordnet. Folgende Größen gehen bei dieser Ausführungsform in die Berechnung der internen ID ein:

• die IP-Adresse des anfragenden ersten Consumers,
• der Netzwerk-Port des ersten realen Netzwerks, über den die erste Anfrage vom ersten Consumer versendet wird,
• die Identifikation des betreffenden Services (Service-ID) sowie
• die Identifikation der angefragten Methode (Method-ID).

In einer besonders bevorzugten Ausführungsform geht als weitere Größe in die Berechnung der internen ID auch ein Wert für das Transportprotokoll (UDP oder TCP) ein, beispielsweise wird UDP durch eine 0 codiert und TCP durch eine 1. So wird ein weiteres Unterscheidungsmerkmal in die interne ID aufgenommen. Der Vorteil darin, die interne ID aus den hier aufgezählten Größen aufzubauen besteht darin, dass z.B. hier gerade nicht die Client-ID einbezogen wird, die unter gewissen Umständen nicht eindeutig sein kann, andererseits aber einen Satz an festen Größen zu verwenden, die von Anfang der Simulation an gegeben sind und gleichzeitig eine Eindeutigkeit der internen ID ermöglichen.
Vorzugsweise wird die interne ID als eine Summe der mit einer Primzahl multiplizierten Bytes der angegebenen Größen berechnet. Eine andere Möglichkeit besteht darin, eine Hash-Funktion über diese Größen zu berechnen, was zwar eine noch höhere Wahrscheinlichkeit bietet, dass die berechnete interne ID eindeutig ist, aber auch einen höheren Rechenaufwand bedeutet. Der Vorteil, die Größen nicht einzeln für die Identifizierung des ersten Consumers zu verwenden liegt darin, dass nur eine einzige Zahl verglichen werden muss, kein String oder Byte-Array wie im Falle einer IP-Adresse, deren Vergleich rechnerisch aufwendiger wäre. Außerdem ist die Übergabe-Schnittstelle für die Weiterleitungen „schlanker“ als wenn mehrere Größen übergeben werden müssten.
In einer weiteren Ausführungsform wird die Anfrage-Nachricht vom ersten Consumer in Verbindung mit einer Anfrage-Identifikation (Anfrage-ID), umfassend eine Identifikation des ersten Consumers (Client-ID) und die Session-ID der Anfrage, an den simulierten Provider übermittelt, wobei bei der Weiterleitung der ersten Anfrage-Nachricht vom simulierten Provider an den ersten simulierten Consumer auch die Anfrage-ID übergeben wird.
In weiteren Ausführungsform ordnet der simulierte Provider die vom simulierten Provider berechnete erste interne ID dem ersten Consumer zu und hinterlegt eine entsprechende Zuordnung, z.B. in einer Lookup-Tabelle, sodass der simulierte Provider die Antwort-Nachricht anhand eines Abgleichs der ersten internen ID aus der hinterlegten Zuordnung mit der vom ersten simulierten Consumer in Verbindung mit der Antwort-Nachricht erhaltenen internen ID an den ersten Consumer zurück sendet.
In einer weiteren Ausführungsform ordnet der simulierte Provider die Anfrage-ID der ersten Anfrage-Nachricht dem ersten Consumer zu und für den Fall, dass der Vergleich der ersten internen ID mit den internen IDs der simulierten Consumer keine Übereinstimmung ergibt (z.B. für den Fall, dass dynamische Ports verwendet werden), erfolgt ein Vergleich der in der Anfrage-ID enthaltenen Client-ID mit den aus der Kommunikationsmatrix bekannten Client-IDs der simulierten Consumer und basierend auf diesem Vergleich wird entweder entschieden, an welchen simulierten Consumer die Anfrage-Nachricht weitergeleitet wird, oder, dass eine Meldung ausgegeben wird, dass kein Empfänger ermittelt werden konnte.
Für den Fall, dass die Client-ID zur Ermittlung des simulierten Consumers führt, an den die Anfrage-Nachricht weiterzuleiten ist, wird diese Client-ID auch für die Weiterleitung der Antwort-Nachricht vom simulierten Provider an den anfragenden Consumer auf dem ersten Rechenknoten verwendet.
Die oben genannte Aufgabe wird auch gelöst durch einen Echtzeitrechner, der eingerichtet ist, über das erste reale Netzwerkmit dem ersten Rechenknoten, auf dem der erste Consumer implementiert ist, und mit dem dritten Rechenknoten, auf dem der zweite Consumer implementiert ist, verbunden zu werden und wobei der Echtzeitrechner eingerichtet ist, über ein zweites reales Netzwerk mit dem zweiten Rechenknoten verbunden zu werden, auf dem der Provider implementiert ist, und wobei auf dem Echtzeitrechner eine Netzwerk-Simulation implementiert ist, die eingerichtet ist, die simulierten Consumer als Gegenstück für den Provider zu simulieren und den simulierten Provider als Gegenstück für den ersten Consumer und den zweiten Consumer zu simulieren und wobei der Echtzeitrechner weiter eingerichtet ist, die Verfahrensschritte des erfindungsgemäßen Verfahrens durchzuführen.
Bevorzugt ist der Echtzeitrechner ein HIL-Simulator zum Test von automobilen Steuergeräten.
Die Erfindung wird nachfolgend unter Bezugnahme auf die Zeichnungen näher erläutert. Darin zeigt:

1 ein typische, Service-basierte Kommunikation zwischen einem Provider (P) und zwei Consumern (CA, CB),
2 eine schematische Ansicht eines Testsystems mit drei Rechenknoten (ECU A, ECU B, ECU C) und einem in das Kommunikations-Netzwerk eingebrachten HIL-Simulator (HIL),
3 eine schematische Ansicht der erfindungsgemäßen Netzwerk-Simulation zur Durchleitung einer Anfrage-Nachricht und der entsprechenden Antwort-Nachricht durch den HIL-Simulator (HIL),
4 einen Pseudo-Code zur Berechnung der internen ID für einen (simulierten) Consumer.

Die Abbildung der 1 zeigt eine schematische Ansicht einer Service-basierten Kommunikation zwischen einem ersten Consumer CA auf einem ersten Rechenknoten ECU A und einem zweiten Consumer CB auf einem dritten Rechenknoten ECU B mit einem Provider P auf einem zweiten Rechenknoten ECU C, welcher über einen Service eine bestimmte Methode zur Verfügung stellt, wobei die Consumer CA, CB den Service des Providers P abonniert haben. Beide Consumer CA, CB sind über ein Netzwerk NW mit dem zweiten Rechenknoten ECU C verbunden (angedeutet durch die gestrichpunkteten Pfeile).
Die Kommunikation läuft beispielsweise so ab, dass beim ersten Consumer CA eine Anfrage nach der vom Provider P angebotenen Methode angestoßen wird (trigger request).
Jeder Consumer besitzt eine ihm bekannte Identifikation (Client-ID). Wenn es sich bei den Rechenknoten beispielsweise um Steuergeräte aus einem automobilen Steuergeräteverbund handelt, ist diese Client-ID beispielsweise aus der Kommunikationsmatrix bekannt.
Zum Aufbau der Kommunikation sendet der erste Consumer eine Anfrage-Nachricht. Für die Übertragung von Anfrage und Antwort muss eine sogenannte „Session“ eröffnet werden, welcher ebenfalls eine Identifikation zugewiesen wird. Die Anfrage-Nachricht wird dann mit einer Anfrage-Identifikation (CS-ID_A, CS-ID_B, CS-ID), welche auch „Request-ID“ genannt wird und aus Client- und Session-ID aufgebaut ist, an den Provider P auf dem zweiten Rechenknoten ECU C versendet.
Beim Provider P wird eine Lookup-Tabelle (Client-ID Lookup) aufgebaut, in der die Client-ID und der zugehörige Absender gespeichert werden. Dann wird die Nachricht dekodiert und ein Empfangszähler (RxCnt) beim Provider P hochgesetzt. Die Anfrage ist damit empfangen.
Für das Versenden der Antwort-Nachricht wird anhand der die Client- und die Session-ID enthaltenden Anfrage-ID durch einen Abgleich mit der Look-up-Tabelle der Empfänger der Antwort-Nachricht (Consumer CA oder Consumer CB) ermittelt und anschließend die Antwort-Nachricht inklusive der Anfrage-ID verschickt.
Der Empfänger, d.h. Consumer CA oder Consumer CB, vergleicht die Client-ID aus der Antwort-ID mit seiner eigenen Client-ID und setzt bei einer Übereinstimmung seinen Empfangszähler (RxCnt) hoch. Die Antwort ist damit empfangen.
Da der zweite Consumer CB hier auf dem dritten Rechenknoten ECU B implementiert ist, und jeder Rechenknoten die Client-ID des Consumers ohne Absprache mit den weiteren Steuergeräten (aber innerhalb eines in der Kommunikationsmatrix vorgegebenen Bereichs) vergibt, kann es vorkommen, dass für Consumer von unterschiedlichen Rechenknoten dieselbe Client-ID vergeben wird. In diesem Fall ist diese nicht eindeutig und zur Ermittlung des korrekten Empfängers der Antwort-Nachricht muss mindestens eine weitere Kenngröße zur Identifizierung des richtigen Adressaten herangezogen werden. In der Regel sind das die IP-Adresse des Rechenknotens und der Port, über welchen die Nachricht versendet wird.
Die Abbildung in 2 zeigt nun eine schematische Ansicht eines Testsystems mit drei Rechenknoten ECU A, ECU B, ECU C und einem in das Kommunikations-Netzwerk eingebrachten HIL-Simulator HIL. Der erste Rechenknoten ECU A und der dritte Rechenknoten ECU B sind über ein erstes reales Netzwerk NW1 mit dem Echtzeitrechner HIL verbunden. Der erste Rechenknoten ECU A ist durch ein erstes zu testendes Steuergerät gegeben, auf dem ein erster Consumer CA implementiert ist. Der dritte Rechenknoten ECU B ist ein weiteres Steuergerät, auf dem ein weiterer Consumer CB implementiert ist. Der zweite Rechenknoten ECU C ist beispielsweise durch ein reales Steuergerät mit einem implementierten Provider P gegeben oder durch einen Simulations-PC, auf dem der Provider P auf z.B. auf einem (simulierten) „virtuellen Steuergerät“ implementiert ist.
Die Kommunikation zwischen den Consumern CA, CB und dem Provider P bleibt bezüglich der auf den Rechenknoten ECU A, ECU B, ECU C von den Consumern CA, CB und dem Provider P ausgeführten Aktionen dieselbe wie zu 1 beschrieben. Hinzu kommt jedoch, dass das Netzwerk NW aus 1 nun in das erste reale Netzwerk NW1 und das zweite reale Netzwerk NW2 aufgetrennt und der Echtzeitrechner HIL mit der Netzwerk-Simulation derart dazwischengeschaltet ist, dass er für die Rechenknoten ECU A, ECU B, ECU C möglichst transparent ist und Nachrichten zwischen dem Provider und dem Consumern unbemerkt „durchleitet“. Es können statt einer reinen Durchleitung innerhalb des Echtzeitrechners auch Manipulation (z.B. durch eine C-API) an den Nachrichten vorgenommen werden, um die Reaktion der Steuergeräte zu testen. Damit die Consumer CA, CB und der Provider P nicht merken, dass sie nicht mehr direkt miteinander kommunizieren, wird auf dem Echtzeitrechner HIL den Consumern CA, CB das Gegenstück ihrer Kommunikation, der Provider P, durch den simulierten Provider P' ersetzt und entsprechend dem Provider P seine zugehörigen Consumer CA, CB durch die simulierten Consumer CA', CB' ersetzt.
Wie auch in 1 beziehen sich Pfeile, die von links nach rechts zeigen auf die Weitergabe von Anfrage-Nachrichten, Pfeile, die von rechts nach links zeigen auf die Weitergabe von Antwort-Nachrichten. An den mit einem Fragezeichen gekennzeichneten Stellen muss nun bei der Durchleitung für den Fall, dass Client- und Session-ID, d.h. die Anfrage-ID CS_ID, CS-ID_A, CS-ID_B zufälligerweise nicht eindeutig sind, am simulierten Provider P' entschieden werden, an welchen simulierten Consumer CA', CB' die Anfrage-Nachricht, bzw., an welche Consumer CA, CB auf den Rechenknoten ECU A, ECU B die Antwort-Nachricht weitergeleitet werden muss.
Die erfindungsgemäße Lösung ist in 3 skizziert und auf das Vorgehen im Echtzeitrechner HIL fokussiert. Erfindungsgemäß wird für eine eingehende Anfrage-Nachricht beim simulierten Provider P' eine interne Identifikation (ID) INT-ID berechnet, derart, dass diese Identifikation für jede Anfrage eines Consumers CA, CB einerseits eindeutig ist, andererseits aber so festgelegt ist, dass sie schon vor der Laufzeit auch für jeden entsprechenden simulierten Consumer CA', CB' zu demselben Wert führt, also die interne ID INT-ID für den ersten Consumer CA identisch ist mit der internen ID INT-ID_A' für den ersten simulierten Consumer CA'. Auf dem Echtzeitrechner HIL wird dann anhand von Programmanweisungen ein Vergleich der vom simulierten Provider berechneten internen ID INT-ID für die erste Anfrage-Nachricht mit den zuvor berechneten internen IDs INTID_A', INT-ID_B' der simulierten Consumer CA', CB' durchgeführt und anhand einer Übereinstimmung entschieden, an welchen simulierten Consumer CA', CB' die Anfrage-Nachricht zu weiterzuleiten ist. Die Anfrage-ID CS-ID der Anfrage-Nachricht kann ebenfalls übergeben werden, auch wenn sie an dieser Stelle nicht benötigt wird. Hat ein simulierter Consumer CA', CB' eine Anfrage-Nachricht vom simulierten Provider P' erhalten, so schickt er diese über das zweite reale Netzwerk NW2 an den Provider P. Da der Provider P anhand des Abonnements für den Service und/oder anhand der Informationen aus der Kommunikationsmatrix die Ziel-Adressen seiner Consumer CA, CB kennt und die simulierten Consumer CA', CB' in dem zweiten realen Netzwerk NW2 die „echten“ Consumer CA, CB aus dem ersten realen Netzwerk NW1 bis hin zu den IP-Adressen und Port-Nummern genau simulieren, erhält beispielsweise der erste simulierte Consumer CA', der eine erste Anfrage-Nachricht an den Provider P versendet, auch die entsprechende Antwort-Nachricht.
Bei der Durchleitung der Antwort-Nachricht durch den Echtzeitrechner HIL werden zunächst die Empfangszähler RxCnt der simulierten Consumer CA', CB' untersucht. Ist ein Empfangszähler RxCnt geändert, d.h. hochgesetzt worden, so werden Antwort-Nachricht, die zugehörige Anfrage-ID CS-ID und die interne ID INT-ID-A', INT-ID_B' des simulierten Consumers CA', CB', an dem die Antwort-Nachricht empfangen wurde, an den simulierten Provider P' weitergeleitet.
Anschließend wird die Versendung der Antwort-Nachricht an den entsprechenden Consumer CA, CB beim simulierten Provider P' angestoßen. Dazu ermittelt dieser in einer hinterlegten Zuordnung von internen IDs INT-ID zu den Consumern CA, CB (d.h. auch zu den simulierten Consumer CA', CB', da deren interne IDs INT-ID-A', INT-ID_B' ja denen der Consumer CA, CB entsprechen), den Consumer CA, CB, an den die Antwort-Nachricht zu schicken ist. Die Zuordnung kann z.B. in einer Lookup-Tabelle hinterlegt sein.
Es sei angemerkt, dass die internen Identifikationen INT-ID, INT-ID_A', INT-ID_B' nicht über die Netzwerke NW1 oder NW2 übertragen werden, dass sie aber für einen Benutzer, der den Echtzeittest mit dem Echtzeitrechner HIL durchführt, über eine sogenannte Setter- oder Getter-Funktion zugänglich gemacht und so auch vom Benutzer abgefragt und/oder gesetzt werden können.
Die in 3 skizzierte erfindungsgemäße Durchleitung erfolgt völlig automatisch, sodass ein Benutzer (HIL-Tester) sich nicht um die Schnittstellen der internen Weiterleitung kümmern muss.
4 zeigt einen Pseudo-Code für eine mögliche Berechnung einer internen ID intID, INT-ID, INT-ID-A', INT-ID_B' für einen (simulierten) Consumer CA, CB, CA', CB'. In die Berechnung der internen ID intID gehen folgende Größen ein: eine Zahl für das Übertragungsprotokoll (UDP oder TCP), die Nummer des Ports (port), über den die Anfrage versendet wird, die IP-Adresse (ip) des Rechenknotens, von dem die Anfrage versendet wird, die ID des Services (serviceID) und die ID der angefragten Methode (methodID).
Die interne ID intID berechnet sich hier so, dass das Byte für eine erste der oben genannten Größen mit einer Primzahl größer als 256 multipliziert wird und anschließend ein nächstes Byte einer der oben genannten Größen addiert wird. Die Summe wird dann wieder mit der Primzahl multipliziert und das nächste Byte der nächsten Größe addiert. Diese Vorschrift wird befolgt, bis alle genannten Größen in die interne ID intID eingeflossen sind.
In der Berechnungsvorschrift in den geschweiften Klammern ist in 4 als Primzahl beispielsweise die Zahl 257 gewählt.
Bevorzugt ist hier eine Bitbreite von 32 Bit gewählt, andere Bitbreiten sind aber auch möglich. Für einen „unsigned“ Datentyp würde bei einem Überlauf der internen ID intID von 0 aus weitergezählt, d.h. falls die interne ID schon während der Berechnung beispielsweise den Wert intID = 2³²-3 erreichte und noch einmal der Wert 5 addiert werden müsste, so ergäbe sich eine interne ID von intID = 1.

Claims

Computer-implementiertes Verfahren zur Durchleitung einer ersten Anfrage-Nachricht eines auf einem ersten Rechenknoten (ECU A) implementierten ersten Consumers (CA) eines Services durch einen Echtzeitrechner (HIL), mittels einer auf dem Echtzeitrechner (HIL) implementierten Netzwerk-Simulation, an einen auf einem zweiten Rechenknoten (ECU C) implementierten Provider (P) und zur Durchleitung der entsprechenden ersten Antwort-Nachricht des Providers (P) an den ersten Consumer (CA), wobei der erste Rechenknoten (ECU A) über ein erstes reales Netzwerk (NW1) mit dem Echtzeitrechner (HIL) verbunden ist und mindestens noch ein dritter Rechenknoten (ECU B) mit einem zweiten Consumer (CB) über das erste reale Netzwerk (NW1) mit dem Echtzeitrechner (HIL) verbunden ist und wobei der Echtzeitrechner (HIL) über ein zweites reales Netzwerk (NW2) mit dem zweiten Rechenknoten (ECU C) verbunden ist, wobei die Netzwerk-Simulation auf dem Echtzeitrechner einen simulierten Provider (P') aufweist, welcher den Provider (P) auf dem zweiten Rechenknoten (ECU C) als Gegenstück für die Consumer auf dem ersten Rechenknoten (ECU A) und dem dritten Rechenknoten (ECU B) simuliert und mindestens zwei simulierte Consumer (CA', CB') für Services des Providers (P) aufweist, welche die Consumer (CA, CB) auf dem ersten Rechenknoten (ECU A) und dem dritten Rechenknoten (ECU B) als Gegenstück für den Provider (P) auf dem zweiten Rechenknoten (ECU C) und für den simulierten Provider (P') simulieren, wobei das Verfahren die folgenden Schritte aufweist: a) Für die simulierten Consumer (CA', CB') wird jeweils eine interne ID (INT-ID, INT-ID_A', INT-ID_B') für ihre Service-basierten Anfragen berechnet, wobei die interne ID (INTID_A', INT-ID_B') für einen simulierten Consumer (CA', CB') so aufgebaut ist, dass sie mit einer entsprechenden internen ID (INT-ID) des zu simulierenden Consumers (CA, CB) übereinstimmt, b) der erste Consumer (CA) schickt die erste Anfrage-Nachricht an den simulierten Provider (P') auf dem Echtzeitrechner (HIL), c) der simulierte Provider (P') berechnet eine erste interne ID (INT-ID) für die erste Anfrage-Nachricht des ersten Consumers (CA), d) die vom simulierten Provider (P') berechnete erste interne ID (INT-ID) wird mit den internen IDs (INT-ID_A', INT-ID_B') der simulierten Consumer (CA', CB') verglichen, e) der simulierte Provider (P') leitet die erste Anfrage-Nachricht an einen ersten simulierten Consumer (CA') weiter, wobei die Identifizierung des ersten simulierten Consumers (CA') durch eine Übereinstimmung beim Abgleich der ersten internen ID (INT-ID) mit den internen IDs (INT-ID_A', INT-ID_B') der simulierten Consumer (CA', CB') erfolgt, f) der erste simulierte Consumer (CA') versendet eine entsprechende erste Anfrage-Nachricht an den Provider (P) auf dem zweiten Rechenknoten (ECU C), g) der Provider (P) auf dem zweiten Rechenknoten (ECU C) versendet eine Antwort-Nachricht an den ersten simulierten Consumer (CA'), h) der erste simulierte Consumer (CA') leitet die erhaltene Antwort-Nachricht inklusive seiner internen ID an den simulierten Provider (P') weiter, i) Der simulierte Provider (P') versendet die Antwort-Nachricht an den ersten Consumer (CA) auf dem ersten Steuergerät (ECU A) anhand eines Abgleichs der mit der Antwort-Nachricht empfangenen internen ID (INT-ID_A') des ersten simulierten Consumers (CA') mit den entsprechenden internen IDs (INT-ID) für die Consumer (CA, CB) auf dem ersten Rechenknoten (ECU A) oder dritten Rechenknoten (ECU B) oder anhand eines Abgleichs mit der für die erste Anfrage-Nachricht berechneten ersten internen ID (INT-ID).
Verfahren nach Anspruch 1, wobei mindestens einer der Rechenknoten (ECU A, ECU B, ECU C) ein zu testendes Steuergerät ist und die benötigten Informationen zur Berechnung der internen IDs (INT-ID, INT-ID_A', INT-ID_B') der Kommunikationsmatrix der zu testenden Steuergerätekommunikation entnommen und/oder dem simulierten Provider (P') und den simulierten Consumern (CA', CB') zur Verfügung gestellt werden.
Verfahren nach Anspruch 1 oder 2, wobei die erste Anfrage-Nachricht eine Anfrage für einen Methoden-Aufruf betrifft und wobei sowohl der Methode als auch dem Service eine ID (serviceID, methodID) zugeordnet sind und wobei in die Berechnung der internen ID (INTID) folgende Größen eingehen: • die IP-Adresse (ip) des anfragenden ersten Consumers (CA), insbesondere ergänzt um eine VLAN-ID, • der Netzwerk-Port (port), über den die erste Anfrage vom ersten Consumer versendet wird, • die Identifikation des Services (serviceID) sowie • die Identifikation der angefragten Methode (methodID).
Verfahren nach Anspruch 3, wobei als weitere Größe in die Berechnung der internen ID (INT-ID, INT_A', INT_B') auch ein Wert für das Transportprotokoll (UDP oder TCP) eingeht.
Verfahren nach einem der Ansprüche 3 oder 4, wobei die interne ID (INT_ID, INT_A', INT_B') als eine Summe der mit einer Primzahl multiplizierten Bytes der angegebenen Größen oder durch eine Hash-Funktion für diese Größen berechnet wird.
Verfahren nach einem der vorstehenden Ansprüche, wobei die erste Anfrage-Nachricht vom ersten Consumer (CA) in Verbindung mit einer Anfrage-ID (CS-ID), umfassend eine Client-ID des ersten Consumers (CA) und die Session-ID der Anfrage, an den simulierten Provider (P') übermittelt wird, und wobei bei der Weiterleitung der ersten Anfrage-Nachricht vom simulierten Provider (P') an den ersten simulierten Consumer (CA') auch die Anfrage-ID (CS-ID) übergeben wird.
Verfahren nach einem der vorstehenden Ansprüche, wobei der simulierte Provider (P') die vom simulierten Provider (P') berechnete erste interne ID (INT-ID) dem ersten Consumer (CA) zugeordnet und eine entsprechende Zuordnung hinterlegt und die Antwort-Nachricht anhand der hinterlegten Zuordnung der ersten internen ID (INT-ID) zu dem ersten Consumer (CA) an den ersten Consumer (CA) sendet.
Verfahren nach Anspruch 7, wobei der simulierte Provider (P') die Anfrage-ID (CS-ID) der ersten Anfrage-Nachricht dem ersten Consumer (CA) zuordnet und für den Fall, dass der Vergleich der ersten internen ID (INT-ID) mit den internen IDs (INT-ID_A', INTID_B') der simulierten Consumer (CA', CB') keine Übereinstimmung ergibt, ein Vergleich der in der Anfrage-ID (CS-ID) enthaltenen Client-ID mit den Client IDs der simulierten Consumer (CA', CB') erfolgt und basierend auf diesem Vergleich entschieden wird, an welchen simulierten Consumer (CA', CB') die Anfrage-Nachricht weitergeleitet wird, oder entschieden wird, dass eine Meldung ausgegeben wird, dass kein Empfänger ermittelt werden konnte.
Echtzeitrechner (HIL) zur Durchführung des Verfahrens nach einem der vorstehenden Ansprüche, wobei der Echtzeitrechner eingerichtet ist, über das erste reale Netzwerk (NW1) mit dem ersten Rechenknoten (ECU A) auf dem der erste Consumer (CA) implementiert ist und mit dem dritten Rechenknoten (ECU B) verbunden zu werden und wobei der Echtzeitrechner (HIL) eingerichtet ist, über ein zweites reales Netzwerk (NW2) mit dem zweiten Rechenknoten (ECU C) verbunden zu werden, und wobei auf dem Echtzeitrechner (HIL) eine Netzwerk-Simulation implementiert ist, die eingerichtet ist, simulierte Consumer (CA', CB') als Gegenstück für den Provider (P) zu simulieren und den simulierten Provider (P') als Gegenstück für den ersten Consumer (CA) und den zweiten Consumer (CB) zu simulieren und wobei der Echtzeitrechner (HIL) weiter eingerichtet ist, die Verfahrensschritte nach einem der vorstehenden durchzuführen.