-
Die Erfindung betrifft ein Verfahren und eine Anordnung zum Bereitstellen eines Prüfstands zum Prüfen eines Verbundes aus Komponenten eines Kraftfahrzeugs.
-
Elektronische Komponenten in einem Kraftfahrzeug müssen vor einem Einsatz beim Kunden geprüft werden, um ein störungsfreies und sicheres Zusammenspiel im Verbund sicherzustellen. Zum Prüfen des Zusammenspiels für verschiedene Fahrzeugprojekte werden Prüfstände verwendet, an denen die Komponenten und Verbindungen zwischen den Komponenten im Rahmen verschiedener Testszenarien nachgebaut und getestet werden. Diese vollständig realen Prüfstände werden auch als Hardware-in-the-Loop-(HiL)-Prüfstände bezeichnet. Aufgrund einer steigenden Komplexität von Funktionen in den Bereichen Elektrifizierung, Connectivity und automatisiertes Fahren stoßen diese Integrationsprüfstände jedoch an ihre Grenzen.
-
Ferner sind vollständig virtuell betriebene Prüfstände bekannt. Diese werden auch als Softwarein-the-Loop-(SiL)-Prüfplätze bezeichnet. Hierbei sind jedoch sehr genaue Modelle der Komponenten notwendig, um Testszenarien realistisch prüfen zu können.
-
Aus der
DE 10 2012 210 516 A1 sind ein Verfahren und eine Anordnung zur virtuellen Applikation von Komponenten eines Kraftfahrzeugs bekannt. Die Anordnung umfasst eine Datenbank zur Ablage von Parametersätzen, eine Simulationsumgebung und einen Prüfstand.
-
Aus SCANIA AB: Bewegende Vielfalt, dSpace Magazin, 2015, H. 1, S. 12-19, URL: https://www.dspace.com/shared/data/pdf/2015/12-19 Variety de.pdf, [abgerufen am 15.01.2021], ist ein Testsystem für ein generisches Steuergerätesystem bekannt.
-
Aus der
DE 10 2007 029 137 A1 ist ein Testsystem-Verbund zum parallelen Testen mehrerer solcher Systeme für ein Flugzeug bekannt, bei welchem ein übergeordnetes Netzwerk vorgesehen ist, das dem Datenaustausch zwischen den einzelnen Testsystemen und einer Steuerungseinheit dient, sowie ein originale Verkabelung zwischen den Testsystemen, über die die getesteten Systeme direkt miteinander verschaltet werden können. Auf diese Weise kann die Flexibilität von Systemtests für Flugzeuge erhöht werden.
-
Aus der
DE 10 2006 000 943 A1 ist ein HiL-System zum Testen von Steuergeräten eines Steuersystems, vorzugsweise eines Fahrzeugsteuersystems, bekannt, mit einer echtzeitfähigen, über mindestens einen Zentralrechner bedienbaren Simulationseinrichtung zur Ausführung einer Systemsimulation, welche mit mehreren Testmodulen zum Anschluss je zugeordneter Steuergeräte des Steuersystems in Verbindung steht, wobei die Simulationseinrichtung verteilt auf einer mit dem Zentralrechner verbundenen Zentraleinheit sowie mehreren hieran angekoppelten Moduleinheiten der Testmodule angeordnet ist, wobei ferner der Teil der in der Zentraleinheit untergebrachten Simulationseinrichtung die eine steuergeräteübergreifende Abläufe betreffende Interaktion der Steuergeräte nachbildet, wogegen der Teil der in den Moduleinheiten untergebrachten Simulationseinrichtung steuergerätespezifische Abläufe für die hieran angeschlossenen Steuergeräte nachbildet.
-
Aus der
US 2015/0153413 A1 ist eine Vorrichtung zum Testen einer elektrischen Komponente bekannt, mit einer Simulationseinheit zum Erzeugen eines Simulationssignals, mehreren Testeinheiten und mindestens einer elektrischen Verbindungsvorrichtung, wobei die Simulationseinheit und die mehreren Testeinheiten miteinander elektrisch leitend über die mindestens eine Verbindungsvorrichtung verbunden oder verbindbar sind, wobei die mindestens eine Verbindungsvorrichtung mindestens eine elektrische Schaltvorrichtung aufweist, die angeordnet ist, um eine elektrische Verbindung zwischen den mehreren Testeinheiten herzustellen oder zu unterbrechen.
-
Der Erfindung liegt die Aufgabe zu Grunde, ein Verfahren und eine Anordnung zum Bereitstellen eines Prüfstands zum Prüfen eines Verbundes aus Komponenten eines Kraftfahrzeugs zu verbessern.
-
Die Aufgabe wird erfindungsgemäß durch ein Verfahren mit den Merkmalen des Patentanspruchs 1 und eine Anordnung mit den Merkmalen des Patentanspruchs 6 gelöst. Vorteilhafte Ausgestaltungen der Erfindung ergeben sich aus den Unteransprüchen.
-
Insbesondere wird ein Verfahren zum Bereitstellen eines Prüfstands zum Prüfen eines Verbundes aus Komponenten eines Kraftfahrzeugs zur Verfügung gestellt, wobei eine Rechnerwolke bereitgestellt wird, wobei eine Mehrzahl von frei programmierbaren Steuergeräten bereitgestellt wird, wobei mindestens ein Fahrzeugbusgateway bereitgestellt wird, wobei mittels des mindestens einen Fahrzeugbusgateways die Mehrzahl der frei programmierbaren Steuergeräte über mindestens ein Fahrzeugbussystem verbunden wird, Signale für Eingänge der frei programmierbaren Steuergeräte erzeugt werden und Signale von Ausgängen der frei programmierbaren Steuergeräte erfasst werden und das mindestens eine Fahrzeugbussystem mit der Rechnerwolke verbunden wird, wobei mittels mindestens einer auf der Rechnerwolke ausgeführten Anwendung ausgehend von einer vorgegebenen Testkonfiguration
- - das mindestens eine Fahrzeugbusgateway konfiguriert wird,
- - zumindest ein Teil der Mehrzahl der frei programmierbaren Steuergeräte für das Bereitstellen einer Funktionalität von zumindest einer Komponente programmiert wird, und
- - eine vorgegebene Fahrzeugumgebung für ein vorgegebenes Testszenario durch Erzeugen von mit dem Testszenario korrespondierenden Busnachrichten auf dem mindestens einen Fahrzeugbussystem und Signalen an den Eingängen simuliert wird.
-
Ferner wird insbesondere eine Anordnung zum Bereitstellen eines Prüfstands zum Prüfen eines Verbundes aus Komponenten eines Kraftfahrzeugs geschaffen, umfassend eine Rechnerwolke, eine Mehrzahl von frei programmierbaren Steuergeräten, mindestens ein Fahrzeugbusgateway, eingerichtet zum Verbinden der Mehrzahl der frei programmierbaren Steuergeräte über mindestens ein Fahrzeugbussystem, zum Erzeugen von Signalen für Eingänge der frei programmierbaren Steuergeräte und zum Erfassen von Signalen an Ausgängen der frei programmierbaren Steuergeräte und zum Verbinden des mindestens einen Fahrzeugbussystems mit der Rechnerwolke, wobei mindestens eine auf der Rechnerwolke ausgeführte Anwendung dazu eingerichtet ist, ausgehend von einer vorgegebenen Testkonfiguration
- - das mindestens eine Fahrzeugbusgateway zu konfigurieren,
- - zumindest einen Teil der Mehrzahl der frei programmierbaren Steuergeräte für das Bereitstellen einer Funktionalität von zumindest einer Komponente zu programmieren, und
- - eine vorgegebene Fahrzeugumgebung für ein vorgegebenes Testszenario durch Erzeugen von mit dem Testszenario korrespondierenden Busnachrichten auf dem mindestens einen Fahrzeugbussystem und Signalen an den Eingängen zu simulieren.
-
Das Verfahren und die Anordnung ermöglichen es, reale Steuergeräte im Verbund zu testen und hierzu flexibel beliebige Konfigurationen der Steuergeräte und des Verbundes vorzunehmen. Hierbei kann insbesondere ein Aufwand beim Zusammenstellen und Konfigurieren des Verbundes aus Steuergeräten bzw. Komponenten reduziert werden. Dies wird erreicht, indem eine Mehrzahl von frei programmierbaren Steuergeräten bereitgestellt wird. Die Mehrzahl von frei programmierbaren Steuergeräten wird mittels mindestens eines Fahrzeugbusgateways über mindestens ein Fahrzeugbussystem in einer vorgegebenen, einer Testkonfiguration entsprechenden, Konfiguration miteinander verbunden. Ferner werden mittels des mindestens einen Fahrzeugbusgateways Signale für Eingänge der frei programmierbaren Steuergeräte erzeugt und Signale an Ausgängen der frei programmierbaren Steuergeräte erfasst. Das Erzeugen und Erfassen von Signalen erfolgt insbesondere jedoch nur, wenn dies gemäß der vorgegebenen Testkonfiguration für ein jeweils betrachtetes Steuergerät vorgesehen ist. Das mindestens eine Fahrzeugbusgateway verbindet die Mehrzahl der frei programmierbaren Steuergeräte ferner mit einer bereitgestellten Rechnerwolke. Auf der Rechnerwolke wird mindestens eine Anwendung ausgeführt, die ausgehend von einer vorgegebenen Testkonfiguration das mindestens eine Fahrzeugbusgateway konfiguriert. Hierbei werden insbesondere die frei programmierbaren Steuergeräte entsprechend der Testkonfiguration miteinander verbunden und zur Kommunikation über den mindestens einen Fahrzeugbus eingebunden. Ferner wird mittels der mindestens einen Anwendung ausgehend von einer vorgegebenen Testkonfiguration zumindest ein Teil der Mehrzahl der frei programmierbaren Steuergeräte für das Bereitstellen einer Funktionalität von zumindest einer Komponente programmiert. Das Programmieren kann insbesondere ein Einladen („Flashen“) einer jeweiligen Firmware in die frei programmierbaren Steuergeräte und ein Konfigurieren und/oder Parametrieren der Steuergeräte umfassen. Beispielsweise kann vorgesehen sein, dass eine Firmware zum Bereitstellen einer Funktionalität eines Navigationssystems, eines Parkassistenten und/oder einer Anzeige- und Bedieneinrichtung etc. in ein hierfür geeignetes frei programmierbares Steuergerät eingeladen wird. Die mindestens eine Anwendung simuliert ferner ausgehend von der vorgegebenen Testkonfiguration eine vorgegebene Fahrzeugumgebung für ein vorgegebenes Testszenario durch Erzeugen von mit dem Testszenario korrespondierenden Busnachrichten auf dem mindestens einen Fahrzeugbussystem und Signalen an den Eingängen der Steuergeräte. Hierbei ist insbesondere vorgesehen, dass der Verbund aus Komponenten in einem Testszenario getestet werden kann, wie es real auftreten würde, wenn die Komponenten bzw. die Steuergeräte in einem Kraftfahrzeug verbaut wären. Die Steuergeräte bzw. die Komponenten erhalten daher über das mindestens eine Fahrzeugbussystem entsprechende Busnachrichten, die den real im Kraftfahrzeug in dem Testszenario auftretenden Busnachrichten entsprechen (z.B. Zustandsdaten: „Tür auf“, „Tür zu“ etc.; Fahrzeugdynamikdaten, Sensordaten etc.). Ebenfalls werden Signale an den Eingängen der Steuergeräte bzw. Komponenten realitätsgetreu nachgebildet und simuliert. Hierdurch lassen sich verschiedene Verbünde aus Komponenten des Kraftfahrzeugs sowie unterschiedliche Testszenarien realitätsnah und flexibel testen.
-
Einer der Vorteile des Verfahrens und der Anordnung ist, dass das Konfigurieren eines Verbundes aus Komponenten automatisiert und zeitsparend erfolgen kann. Ein aufwändiger Aufbau eines Prüfstandes durch Zusammenstellen von Komponenten samt einer Verdrahtung etc. sowie ein anschließendes Auseinanderbauen und erneutes Zusammenstellen kann entfallen. Soll eine Testkonfiguration geändert werden, so kann dies automatisiert erfolgen. Auch können Testkonfigurationen beliebig gewechselt werden, solange sichergestellt ist, dass die zu testenden Komponenten mit der Mehrzahl von frei programmierbaren Steuergeräten bereitgestellt werden können. Insgesamt ist eine Flexibilität beim Bereitstellen von Prüfständen erhöht und Kosten für das Konfigurieren können reduziert werden.
-
Ein weiterer Vorteil ist, dass ein Nutzer des Prüfstandes prinzipiell nicht mehr vor Ort bei den zu testenden Steuergeräten bzw. Komponenten sein muss. Hierdurch kann eine verteilte Testinfrastruktur bereitgestellt werden, die die Flexibilität weiter erhöht und die Kosten bei den Integrationstests weiter senkt.
-
Das in dieser Offenbarung beschriebene Verfahren und die Anordnung ermöglichen insbesondere eine automatisiert verwaltete und bereitgestellte Prüfstandsinfrastruktur, die flexibel an jeweils notwendige Testkonfigurationen angepasst werden kann.
-
Die frei programmierbaren Steuergeräte sind insbesondere Steuergeräte aus dem Automotive-Bereich, das heißt reale Steuergeräte (engl. Electronic Control Unit, ECU), wie diese üblicherweise in Kraftfahrzeugen eingesetzt werden. Die frei programmierbaren Steuergeräte können hierbei zumindest gruppenweise gleichartig oder auch verschieden sein. Insbesondere ist vorgesehen, eine Vielzahl von unterschiedlichen Steuergeräten bzw. Steuergerätetypen bereitzustellen, die in Kraftfahrzeugen (von zumindest einem Hersteller) üblicherweise verwendet werden, sodass eine Vielzahl von Testkonfigurationen für unterschiedliche Fahrzeugtypen flexibel bereitgestellt werden kann. Es kann beispielsweise vorgesehen sein, dass die frei programmierbaren Steuergeräte zusammengefasst als Racks bereitgestellt werden, wobei jedes Rack ein eigenes Fahrzeugbusgateway aufweist.
-
Die vorgegebene Testkonfiguration umfasst insbesondere sämtliche Konfigurationsparameter des Fahrzeugbusgateways, die jeweilige Firmware für die Komponenten, eine Konfiguration bzw. Parameter der jeweiligen Komponenten und Ablaufinformationen und Parameter des zu prüfenden Testszenarios, das heißt insbesondere des durchzuführenden Integrationstests.
-
Eine Fahrzeugumgebung soll insbesondere ein Verhalten des Kraftfahrzeugs umfassen, wie dieses unter realen Bedingungen auftreten würde. Insbesondere umfasst das Simulieren der Fahrzeugumgebung das Simulieren von Busnachrichten und Signalen an Eingängen der Steuergeräte. Die Busnachrichten und Signale an den Eingängen können hierbei Zustandsdaten des Kraftfahrzeugs, wie beispielsweise Sensordaten von Sensoren des Kraftfahrzeugs, oder Steuersignale des Kraftfahrzeugs, umfassen.
-
Es ist vorgesehen, dass auf der Anordnung mehrere Prüfstände parallel betrieben werden können. Hierbei wird dann jeweils ein Teil der Mehrzahl der frei programmierbaren Steuergeräte in einer Testkonfiguration und einem Testszenario verwendet, ein oder mehrere andere Teile in anderen Testkonfigurationen und anderen Testszenarien. Hierdurch kann eine zentrale Prüfstandsinfrastruktur bereitgestellt werden, mit der Wartungs- und Betriebskosten weiter reduziert werden können.
-
Es ist erfindungsgemäß vorgesehen, dass in Abhängigkeit der vorgegebenen Testkonfiguration mindestens ein virtuelles Steuergerät und/oder eine virtuelle Komponente mittels der Rechnerwolke bereitgestellt und in den Verbund aus Komponenten eingebunden wird. Hierdurch können im Rahmen der Testkonfiguration auch Steuergeräte bereitgestellt werden, die nicht real, sondern nur virtuell benötigt werden. Es kann hierdurch ein hybrider Prüfstand geschaffen werden, in dem sowohl reale als auch virtuelle Steuergeräte und/oder virtuelle Komponenten im Verbund miteinander getestet werden können. Eine Flexibilität beim Bereitstellen des Prüfstandes kann hierdurch weiter gesteigert werden. Die virtuellen Steuergeräte und/oder virtuellen Komponenten werden insbesondere auf Grundlage eines Steuergerätemodells bzw. Komponentenmodells simuliert, die ein Verhalten eines realen Steuergeräts bzw. einer realen Komponente möglichst realitätsnah nachbilden können.
-
Es ist erfindungsgemäß vorgesehen, dass der Prüfstand zumindest teilweise mittels einer Anwendungsplattform des Cloud Computing ausgebildet wird, wobei die frei programmierbaren Steuergeräte mittels des Fahrzeugbusgateways jeweils als Ressourcen in die Anwendungsplattform eingebunden werden. Hierdurch kann eine Flexibilität weiter erhöht werden, da die Anwendungsplattform nahezu beliebig skalierbar ist. Die frei programmierbaren Steuergeräte werden dann als Ressourcen in die Anwendungsplattform eingebunden. Hierbei kann vorgesehen sein, dass frei programmierbare Steuergeräte beliebig hinzugefügt und entfernt werden können. Insbesondere ist hierbei vorgesehen, dass die frei programmierbaren Steuergeräte automatisiert von der Anwendungsplattform als entsprechende Ressourcen ausgehend von der vorgegebenen Testkonfiguration in einen bereitzustellenden Prüfstand eingebunden werden können und nach Beenden des Testszenarios, wenn der Prüfstand nicht mehr benötigt wird, als Ressourcen wieder freigeben werden können. Insbesondere das Bereitstellen von mehreren gleichzeitig bereitgestellten Prüfständen kann hierdurch im Hinblick auf das Bereitstellen und das Organisieren flexibler und insbesondere vereinfacht erfolgen, da die frei programmierbaren Steuergeräte als flexibel einbindbare Ressourcen verwendet werden können.
-
Ferner ist erfindungsgemäß vorgesehen, dass die Mehrzahl von frei programmierbaren Steuergeräten als Steuergerätefarm betrieben und bereitgestellt wird. Hierdurch können ausreichende Ressourcen für eine Vielzahl von gleichzeitig zu testenden Verbünden aus Komponenten eines oder mehrerer Kraftfahrzeuge bereitgestellt werden. Ferner können hierdurch die bereitgestellten Ressourcen im Hinblick auf eine Auslastung optimal bereitgestellt und genutzt werden. Beispielsweise kann vorgesehen sein, die Mehrzahl von frei programmierbaren Steuergeräten in mehreren Racks mit jeweils einem Fahrzeugbusgateway bereitzustellen und über eine Layer-2-Verbindung mit der Rechnerwolke zu verbinden. Die bereitgestellten frei programmierbaren Steuergeräte können dann über die Fahrzeugbusgateways flexibel in verschiedene Testkonfigurationen eingebunden werden, wobei hierzu jeweils das in dieser Offenbarung beschriebene Verfahren ausgeführt wird.
-
In einer Ausführungsform ist vorgesehen, dass mindestens eine Klemme der frei programmierbaren Steuergeräte mittels eines steuerbaren Schalters von der mindestens einen Anwendung angesteuert und/oder verschaltet wird. Hierdurch kann ein reales Schaltverhalten an den vorhandenen Klemmen der Steuergeräte simuliert werden. Als steuerbare Schalter können insbesondere Relais eingesetzt werden, welche beispielsweise in Form einer Relaiskarte bereitgestellt und mittels der mindestens einen Anwendung im Rahmen des Testszenarios gesteuert wird. Eine solche Relaiskarte wird insbesondere vor dem Simulieren der Fahrzeugumgebung mittels der mindestens einen Anwendung gemäß der Testkonfiguration konfiguriert. Beim Durchlaufen des Testszenarios können dann Klemmen gemäß dem Testszenario geschaltet werden, um beispielsweise Klemmenfehler realitätsgetreu simulieren zu können.
-
In einer Ausführungsform ist vorgesehen, dass erfasste Signale an den Ausgängen der frei programmierbaren Steuergeräte und/oder über das mindestens eine Fahrzeugbussystem übermittelte Busnachrichten aufgezeichnet und bereitgestellt werden. Hierdurch kann eine vollständige Dokumentation des Verhaltens der Steuergeräte und/oder der Komponenten bereitgestellt werden.
-
In einer Ausführungsform ist vorgesehen, dass die Anwendungsplattform als OpenShift® Container Platform (OCP, Produkt der Firma Red Hat, Inc.) ausgebildet ist, wobei die frei programmierbaren Steuergeräte jeweils als Container bereitgestellt werden, wobei das mindestens eine Fahrzeugbusgateway über die OpenShift® Container Platform konfiguriert wird, und wobei die mindestens eine Anwendung in Form von mindestens einem Software Container bereitgestellt wird. Die OpenShift® Container Platform wird von der Firma Red Hat, Inc. vertrieben. Prinzipiell können jedoch auch andere Anwendungsplattformen verwendet werden.
-
In einer Ausführungsform ist vorgesehen, dass das mindestens eine Fahrzeugbusgateway und die Rechnerwolke mittels einer Layer 2-Verbindung (Ethernet) miteinander kommunizieren. Hierdurch kann eine Echtzeitkommunikation während der Simulation und dem Durchführen des Testszenarios bereitgestellt werden, da Multihops, die übermittelte Datenpakete verzögern, vermieden werden können.
-
In einer Ausführungsform ist vorgesehen, dass das Programmieren, das Konfigurieren und das Simulieren mittels einer REST-API durchgeführt werden. REST steht hierbei für Representational State Transfer.
-
Weitere Merkmale zur Ausgestaltung der Anordnung ergeben sich aus der Beschreibung von Ausgestaltungen des Verfahrens. Die Vorteile der Anordnung sind hierbei jeweils die gleichen wie bei den Ausgestaltungen des Verfahrens.
-
Nachfolgend wird die Erfindung anhand bevorzugter Ausführungsbeispiele unter Bezugnahme auf die Figuren näher erläutert. Hierbei zeigen:
- 1 eine schematische Darstellung einer Ausführungsform der Anordnung zum Bereitstellen eines Prüfstands zum Prüfen eines Verbundes aus Komponenten eines Kraftfahrzeugs;
- 2 eine schematische Darstellung einer Struktur und von Signalflüssen eines bereitgestellten Prüfstandes zur Verdeutlichung der Erfindung;
- 3 eine schematische Darstellung einer Ausführungsform der Anordnung zum Bereitstellen eines Prüfstands zum Prüfen eines Verbundes aus Komponenten eines Kraftfahrzeugs.
-
In 1 ist eine schematische Darstellung einer Ausführungsform der Anordnung 1 zum Bereitstellen eines Prüfstands zum Prüfen eines Verbundes aus Komponenten eines Kraftfahrzeugs gezeigt.
-
Die Anordnung umfasst eine Rechnerwolke 2, eine Mehrzahl aus frei programmierbaren Steuergeräten 3, welche in Racks 4 zusammengefasst sind, und für jedes der Racks 4 jeweils ein Fahrzeugbusgateway 5.
-
Die Fahrzeugbusgateways 5 verbinden die frei programmierbaren Steuergeräte 3 über mindestens ein Fahrzeugbussystem (nicht gezeigt), beispielsweise einen Controller Area Network (CAN)-Bus, miteinander. Die Fahrzeugbusgateways 5 unterschiedlicher Racks 4 sind miteinander über eine Kommunikationsverbindung 6 verbunden, sodass auch frei programmierbare Steuergeräte 3 in unterschiedlichen Racks 4 miteinander kommunizieren können. Die Fahrzeugbusgateways 5 können hierbei als Client-Master- oder als Multimastersysteme ausgestaltet sein.
-
Ferner kann das Fahrzeugbusgateway 5 Signale für Eingänge der frei programmierbaren Steuergeräte 3 erzeugen. Weiter können die Fahrzeugbusgateways 5 Signale an Ausgängen der frei programmierbaren Steuergeräte 3 erfassen. Die Fahrzeugbusgateways 5 verbinden das mindestens eine Fahrzeugbussystem mit der Rechnerwolke 2. Hierzu ist zwischen den Fahrzeugbusgateways 5 und der Rechnerwolke 2 eine Layer-2-Kommunikationsverbindung 7 (Ethernet) ausgebildet, welche beispielsweise mittels eines Switches 8 und eines Routers 9 hergestellt wird.
-
Auf der Rechnerwolke 2 wird mindestens eine Anwendung ausgeführt. Die Anwendung konfiguriert ausgehend von einer vorgegebenen Testkonfiguration 10 die Fahrzeugbusgateways 5. Insbesondere werden hierzu die einzelnen Fahrzeugbussysteme zum Verbinden der Steuergeräte 3 (bzw. Komponenten) eingerichtet und konfiguriert. Ferner wird zumindest ein Teil der frei programmierbaren Steuergeräte 3 ausgehend von der vorgegebenen Testkonfiguration 10 programmiert, wobei hierzu insbesondere eine jeweilige Firmware in die Speicher der frei programmierbaren Steuergeräte 3 geladen wird, das heißt die frei programmierbaren Steuergeräte 3 werden zum Bereitstellen einer Funktionalität programmiert („geflasht“). Die Firmware und eine Konfiguration der Komponenten entspricht hierbei jeweils den zu testenden Integrationsprüfstandsversionen des jeweiligen Fahrzeugprojekts und der jeweiligen Funktionsversionen.
-
Nach dem Programmieren verhalten sich die jeweils programmierten Steuergeräte 3 so, wie ein reales Steuergerät für die entsprechende Funktionalität in einem Kraftfahrzeug.
-
Für ein vorgegebenes Testszenario 11 wird eine vorgegebene Fahrzeugumgebung durch Erzeugen von mit dem Testszenario 11 korrespondierenden Busnachrichten auf dem mindestens einen Fahrzeugbussystem und Signalen an den Eingängen der Steuergeräte 3 simuliert. Das vorgegebene Testszenario 11 entspricht hierbei einem durchzuführenden Test auf dem Prüfstand.
-
Es ist vorgesehen, dass in Abhängigkeit der vorgegebenen Testkonfiguration 10 mindestens ein virtuelles Steuergerät und/oder eine virtuelle Komponente mittels der Rechnerwolke 2 bereitgestellt und in den Verbund aus Komponenten eingebunden wird.
-
Es kann vorgesehen sein, dass mindestens eine Klemme der frei programmierbaren Steuergeräte 3 mittels eines steuerbaren Schalters von der mindestens einen Anwendung angesteuert und/oder verschaltet wird. Beispielsweise kann vorgesehen sein, dass eine mittels der mindestens einen Anwendung steuerbare Relaiskarte verwendet wird, um Klemmen der Steuergeräte 3 zu schalten.
-
Es ist im Rahmen der Durchführung des Testszenarios 11 insbesondere vorgesehen, dass erfasste Signale an den Ausgängen der frei programmierbaren Steuergeräte 3 und/oder über das mindestens eine Fahrzeugbussystem übermittelte Busnachrichten aufgezeichnet und bereitgestellt werden. Die aufgezeichneten Signale und Busnachrichten können später ausgewertet werden, um beispielsweise ein detailliertes Testprotokoll für einen Integrationstest der Komponenten des Kraftfahrzeugs zu erstellen.
-
Es ist vorgesehen, dass der Prüfstand zumindest teilweise mittels einer Anwendungsplattform des Cloud Computing ausgebildet wird, wobei die frei programmierbaren Steuergeräte 3 mittels der Fahrzeugbusgateways 5 jeweils als Ressourcen in die Anwendungsplattform eingebunden werden.
-
Weiterbildend kann vorgesehen sein, dass die Anwendungsplattform als OpenShift® Container Platform (OCP, Produkt der Firma Red Hat, Inc.) ausgebildet ist, wobei die frei programmierbaren Steuergeräte 3 jeweils als Container bereitgestellt werden, wobei die Fahrzeugbusgateways 5 über die OpenShift® Container Platform konfiguriert werden, und wobei die mindestens eine Anwendung in Form von mindestens einem Software Container bereitgestellt wird.
-
Es ist insbesondere vorgesehen, dass das Programmieren, das Konfigurieren und das Simulieren mittels einer REST-API durchgeführt werden.
-
Es ist ferner vorgesehen, dass die frei programmierbaren Steuergeräte 3 als Steuergerätefarm 18 betrieben und bereitgestellt werden. Insbesondere kann hierdurch eine Vielzahl von verschiedenen Prüfständen ausgebildet und parallel zueinander verwendet werden.
-
In 2 ist eine schematische Darstellung einer Struktur und von Signalflüssen eines bereitgestellten Prüfstandes zur Verdeutlichung der Erfindung gezeigt. Gezeigt sind die Fahrzeugbussysteme 12 (z.B. MIB CAN, CON-CAN, AB CAN (FD) etc.), die von den Fahrzeugbusgateways 5 bereitgestellt werden und die verschiedene Komponenten 13-x miteinander und mit einer Rechnerwolke 2 verbinden. Die Komponenten 13-x werden mittels der frei programmierbaren Steuergeräte 3 bereitgestellt, nachdem diese mittels der mindestens einen Anwendung programmiert wurden. Die Komponenten 13-x stellen beispielsweise die folgenden Funktionalitäten für ein Kraftfahrzeug bereit:
- - Komponente 13-1: In-Car App Server, auf dem ein Driver Notification Master und weitere Services laufen;
- - Komponenten 13-2, 13-3: Anzeige- und Bedieneinrichtung (z.B. Multimediakonsole etc.);
- - Komponente 13-4: Online Unit (z.B. Internet, Connectivity etc.);
- - Komponente 13-5: Kombiinstrument (z.B. Tachometer, Drehzahlanzeiger, Tankanzeige etc.).
-
Mittels einer Relaiskarte 14 kann die „Klemme 30“ KI30 einzelner oder aller Steuergeräte 3 geschaltet werden. Die Relaiskarte 14 kann hierbei mittels der Fahrzeugbusgateways 5 gesteuert werden oder sogar Teil der Fahrzeugbusgateways 5 sein.
-
Beispielhaft gezeigt ist für die Komponente 13-3 (Anzeige- und Bedieneinrichtung), dass ein Ausgang mittels der Fahrzeugbusgateways 5 erfasst wird. Hierbei handelt es sich um einen Videoausgang, an dem mittels des Fahrzeugbusgateways 5 die erzeugten Videobilder erfasst und aufgezeichnet werden. Die Videobilder entsprechen hierbei den in einem Kraftfahrzeug im selben Zustand auf einer entsprechenden Anzeige- und Bedieneinrichtung angezeigten Videobildern (z.B. Auswahlmenüs, Straßenkarte eines Navigationssystems etc.).
-
In der Rechnerwolke 2 werden mehrere Anwendungen 15-x bereitgestellt. Die Anwendung 15-1 stellt einen virtuellen CAN-Bus bereit, auf dem Busnachrichten für die Fahrzeugbussysteme 12 erzeugt und Busnachrichten von den Fahrzeugbussystemen 12 empfangen und verarbeitet werden. Insbesondere können hierdurch virtuelle Komponenten simuliert und in einen Gesamtverbund aus Komponenten 13-x integriert werden. Die Anwendung 15-2 dient hierbei als Übersetzer zwischen den virtuellen Komponenten, die in der Rechnerwolke 2 simuliert werden und dem virtuellen CAN-Bus. Die Anwendung 15-3 stellt eine Web-Schnittstelle als Nutzerschnittstelle, insbesondere als Graphical User Interface (GUI), bereit, die es einem Nutzer ermöglicht, den Prüfstand mittels eines Web-Clients 16 zu konfigurieren und zu bedienen, sowie erfasste Testdaten einzusehen und auszuwerten. Mittels der Web-Schnittstelle können die Komponenten 13-x auch bedient werden und beispielsweise Zustände des Kraftfahrzeugs (z.B. „Tür auf“, „Tür zu“ etc.) und/oder der Komponenten 13-x geändert werden. Die Anwendung 15-4 stellt einen Videoserver bereit, in dem die erfassten Videobilder der Komponente 13-3 hinterlegt sind und mittels des Web-Clients 16 abgerufen und abgespielt werden können. Ferner kann die Komponente 13-3 mittels des Web-Clients 16 bedient werden.
-
Die Kommunikation zwischen der Rechnerwolke 2 und den Fahrzeugbusgateways 5 erfolgt mittels einer Layer-2-Kommunikationsverbindung 7 (Ethernet), sodass Echtzeittests an dem Prüfstand möglich sind.
-
Mittels des in dieser Offenbarung beschriebenen Verfahrens und der Anordnung ist es möglich, „gemischte“ Prüfstände bereitzustellen, welche sowohl virtuelle Komponenten als auch reale Komponenten 13-x umfassen. Hierdurch können flexibel und aufwandsarm nahezu beliebige Prüfstände geschaffen, konfiguriert und zum Testen verwendet werden. Da die frei programmierbaren Steuergeräte 3 nach dem Durchführen eines Testszenarios auf einem solchen Prüfstand als Ressourcen wieder freigegeben werden, lassen sich die freigegebenen Steuergeräte 3 anschließend sofort wieder in andere „gemischte“ Prüfstände einbeziehen, indem eine jeweilige Firmware der Steuergeräte 3 überschrieben wird.
-
In 3 ist eine schematische Darstellung einer Ausführungsform der Anordnung 1 zum Bereitstellen eines Prüfstands zum Prüfen eines Verbundes aus Komponenten eines Kraftfahrzeugs gezeigt. Mittels der gezeigten Ausführungsform wird eine Vielzahl von „gemischten“ Prüfständen bereitgestellt. Hierzu wird eine Vielzahl von frei programmierbaren Steuergeräten 3 (der Übersichtlichkeit halber sind nicht alle mit einem eigenen Bezugszeichen gekennzeichnet) in Form einer Steuergerätefarm 18 bereitgestellt, in der jeweils mehrere gleichartige und unterschiedliche Steuergeräte 3 umfasst sind. Hierbei sind insbesondere sämtliche Typen von Steuergeräten 3 vorhanden, wie diese auch in einem realen Kraftfahrzeug verwendet werden. Über die Fahrzeugbusgateways 5 sind die Steuergeräte 3 mit einer Rechnerwolke 2 verbunden.
-
Es ist vorgesehen, dass der Prüfstand zumindest teilweise mittels einer Anwendungsplattform 17 des Cloud Computing ausgebildet wird bzw. ausgebildet ist, wobei die frei programmierbaren Steuergeräte 3 mittels des Fahrzeugbusgateways 5 jeweils als Ressourcen in die Anwendungsplattform 17 eingebunden werden bzw. eingebunden sind.
-
Die Anwendungsplattform 17 ist als OpenShift@ Container Platform (OCP, Produkt der Firma Red Hat, Inc.) ausgebildet. Die frei programmierbaren Steuergeräte 3 werden hierbei jeweils als Container bereitgestellt. Die Fahrzeugbusgateways 5 werden über die OpenShift® Container Platform konfiguriert und die mindestens eine Anwendung wird in Form von mindestens einem Software Container bereitgestellt. Eine Testkonfiguration umfasst dann eine Beschreibung eines Containerverbundes sowohl aus Containern für die (programmierten) Steuergeräte 3 als auch eine Beschreibung von Anwendungen in Form von Software Containern sowie die Konfiguration für die Fahrzeugbusgateways 5, die einer Verschaltung der Steuergeräte 3 auf den jeweiligen Fahrzeugbussystemen entspricht. Die Anwendungsplattform 17 baut dann ausgehend von einer vorgegebenen Testkonfiguration, die beispielsweise in Form von Testkonfigurationsdaten von einem Nutzer bereitgestellt wird, automatisiert den Prüfstand auf. Es kann hierbei vorgesehen sein, dass ein Zustand des Prüfstandes abgespeichert werden kann und zu einem späteren Zeitpunkt wieder abgerufen werden kann. Hierzu werden Zustandsdaten der Steuergeräte 3, der Fahrzeugbusgateways 5 und der Anwendungen erfasst und hinterlegt.
-
Mittels der Anwendungsplattform 17 ist es möglich, die als Ressourcen eingebundenen und bereitgestellten frei programmierbaren Steuergeräte 3 zu verwalten. Insbesondere können mehrere „gemischte“ Prüfstände in Form von gemischten Testumgebungen MTE (Mixed Test Environments) bereitgestellt werden. Jeweils für eine Testkonfiguration innerhalb eines solchen „gemischten“ Prüfstands benötigte reale Komponenten werden mit Hilfe der frei programmierbaren Steuergeräte 3 der Steuergerätefarm 18 bereitgestellt, indem diese als Container in den „gemischten“ Prüfstand eingebunden werden. Beispielhaft sind in der 3 drei frei programmierbare Steuergeräte 3, die in einen solchen „gemischten Prüfstand“ eingebunden sind, mit einer Umrandung markiert.
-
Die Anwendungsplattform 17 erkennt insbesondere automatisch, beispielsweise über Virtualkubletsverfahren („Kubernetes®“), neue Ressourcen, die über ein Operator Framework akquiriert und zur Verfügung gestellt werden. Wird ein Prüfstand nicht mehr benötigt, so werden die Steuergeräte 3 als Ressourcen wieder freigegeben und in andere „gemischte“ Prüfstände eingebunden.
-
Die Anordnung 1 und das Bereitstellen der frei programmierbaren Steuergeräte 3 als Steuergerätefarm 18 ermöglichen eine flexible und kostengünstige Durchführung von Tests mit Hilfe von jeweils gemäß einer jeweils vorgegebenen Testkonfiguration konfigurierten Prüfständen. Da ein Prüfstand nicht mehr real, das heißt physisch, zusammengestellt werden muss, sondern über die Anwendungsplattform 17 logisch zusammengestellt und konfiguriert werden kann und da Testszenarios von der Anwendungsplattform 17 aus gesteuert durchgeführt werden können, können Kosten und Aufwand eingespart werden. Ferner können Tests an einem Prüfstand durchgeführt werden, ohne dass ein Nutzer hierfür vor Ort sein muss. Es kann hierdurch eine konfigurierbare „Prüfstandswolke“ bereitgestellt werden.
-
Ein weiterer Vorteil ist, dass sowohl die Rechnerwolke 2 als auch die Steuergerätefarm 18 bei Bedarf skaliert werden können, indem der Rechnerwolke 2 mehr Rechenleistung und Speicherplatz bereitgestellt werden und/oder der Steuergerätefarm 18 weitere frei programmierbare Steuergeräte 3 hinzugefügt werden.
-
Insgesamt erlauben es das in dieser Offenbarung beschriebene Verfahren und die beschriebene Anordnung 1, funktionale Absicherungstests von Verbünden von Komponenten in Kraftfahrzeugen hinsichtlich eines Aufwands und einer Flexibilität zu verbessern. Insbesondere können funktionale Absicherungstests für Verbünde aus Komponenten eines Kraftfahrzeugs mit weniger Aufwand und daher kostengünstiger durchgeführt werden.
-
Bezugszeichenliste
-
- 1
- Anordnung
- 2
- Rechnerwolke
- 3
- Steuergeräte
- 4
- Rack
- 5
- Fahrzeugbusgateway
- 6
- Kommunikationsverbindung
- 7
- Layer-2-Kommunikationsverbindung
- 8
- Switch
- 9
- Router
- 10
- vorgegebene Testkonfiguration
- 11
- vorgegebenes Testszenario
- 12
- Fahrzeugbussystem
- 13-x
- Komponente
- 14
- Relaiskarte
- 15-x
- Anwendung
- 16
- Web-Client
- 17
- Anwendungsplattform
- 18
- Steuergerätefarm
- KI30
- Klemme 30
- MTE
- gemischter Testumgebung
