DE102018206188A1

DE102018206188A1 - System zum Durchführen von XiL-Tests von Komponenten selbstfahrender Kraftfahrzeuge

Info

Publication number: DE102018206188A1
Application number: DE102018206188.2A
Authority: DE
Inventors: Frederic Stefan; Alain Marie Roger Chevalier; Michael Marbaix; Evangelos BITSANIS; Turgay Aslandere
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2018-04-23
Filing date: 2018-04-23
Publication date: 2019-10-24
Also published as: US11232654B2; US20190325672A1; CN110389575A

Abstract

Die Erfindung betrifft ein System (2) zum Durchführen von XiL-Tests von Komponenten selbstfahrender Kraftfahrzeuge, mit zumindest einem Plattform-Interfacemodul (8), wobei das Plattform-Interfacemodul (8) dazu ausgebildet ist, Tests auf einer Mehrzahl von XiL-Plattformen auszuführen.

Description

Die Erfindung betrifft ein System zum Durchführen von XiL-Tests von Komponenten selbstfahrender Kraftfahrzeuge.
Selbstfahrende Kraftfahrzeuge (manchmal auch autonome Landfahrzeuge genannt) sind Kraftfahrzeuge, die ohne Einflussnahme eines menschlichen Fahrers fahren, steuern und einparken können (hochautomatisiertes Fahren bzw. autonomes Fahren). Im Falle, dass keinerlei manuelles Steuern seitens eines Fahrers nötig ist, wird auch der Begriff Roboterauto verwendet. Der Fahrersitz kann unbesetzt bleiben; eventuell sind kein Lenkrad, Brems- und Gaspedal vorhanden.
Selbstfahrende Kraftfahrzeuge können mit Hilfe verschiedener Sensoren ihre Umgebung erfassen und aus den gewonnenen Informationen ihre Position und die anderer Verkehrsteilnehmer bestimmen, in Zusammenarbeit mit der Navigationssoftware ein Fahrziel ansteuern und Kollisionen auf dem Weg dahin vermeiden.
Das Aufkommen von intelligenten Mobilitätslösungen und automatisierten Fahrfunktionen bringt neue Herausforderungen beim Testen derartiger Systeme mit sich. Physisches Prototyping und/oder intensive reale Testfahrten sind extrem herausfordernd. Aus diesem Grund wurden in den letzten Jahren neue Technologien für das virtuelle Engineering entwickelt.
Eine wichtige Voraussetzung für das Testen derartiger Systeme ist die Bereitstellung von X-in-the-Loop-Frameworks, die das Testen der entwickelten Software auf verschiedenen Plattformen ermöglichen, wie z.B. MiL, SiL, HiL, DiL, mit echtem ECU, in realen Prototypen.
Unter einem ECU bzw. Steuergerät wird dabei ein elektronisches Modul verstanden, die dazu ausgebildet sind, z.B. unter Verwendung einer Steuer- oder Steuer- oder Regelstrategie andere Komponenten, wie Komponenten eines Kraftfahrzeugs zu steuern oder zu regeln.
Typischerweise werden bei den Tests mindestens ein ECU, das die zu prüfende Software aufweist, und ein Modell, das das Verhalten des Systems nachahmt, verwendet. Die Modelle und die ECUs können in verschiedenen Kombinationen getestet werden. Zum Beispiel können in MiL die ECUs in Simulink und das Modell in Simulink oder CarSim laufen, in SiL können die ECUs für einen PC kompiliert werden und das Modell kann für PC kompiliert werden, in HiL können die ECUs auf einem echten ECU laufen und das Modell auf einer Echtzeitmaschine (z.B. dSPACE, Concurrent). Während des Projektlebenszyklus muss die gleiche Steuerungssoftware von verschiedenen Teams an verschiedenen Standorten und auf unterschiedlichen Plattformen getestet werden. Die Testspezifikationen können jedoch nicht gemeinsam genutzt werden, da unterschiedliche Teams unterschiedliche Modelle mit unterschiedlichen Namen verwenden und unterschiedliche Plattformen verwenden können. Darüber hinaus müssen mit dem Aufkommen automatisierter Fahrfunktionen neue komplexe Szenarien und Anwendungsfälle getestet werden, die nicht immer von herkömmlichen Testwerkzeugen unterstützt werden.
Es besteht also Bedarf daran, Wege aufzuzeigen, wie das Durchführen derartiger Tests vereinfacht werden kann.
Die Aufgabe der Erfindung wird gelöst durch ein System zum Durchführen von XiL-Tests von Komponenten selbstfahrender Kraftfahrzeuge, mit zumindest einem Plattform-Interfacemodul, wobei das Plattform-Interfacemodul dazu ausgebildet ist, Tests auf einer Mehrzahl von XiL-Plattformen auszuführen.
Mit anderen Worten, das Plattform-Interfacemodul ermöglicht es, denselben Test (oder dieselbe Simulation) auf einer SiL-, MiL-, HiL- oder DiL-Plattform auszuführen, ohne den Test (oder die Simulation) neu zu definieren. So können verschiedene Tests auf einer Plattform durchgeführt werden, was das Durchführen derartiger Tests vereinfacht
Gemäß einer Ausführungsform weist die Mehrzahl der XiL-Plattformen zumindest eine SiL- und/oder MiL- und/oder HiL- und/oder DiL-Plattform auf.
Bei den XiL-Tests kann es sich also um MiL (Model-in-the-Loop), SiL (Software-in-the-Loop), HiL (Hardware-in the-Loop) und/oder DiL (Driver-in-the-Loop) handeln. MiL umfasst dabei den Aufbau von Modellen für eine Regelstrecke und ein ECU sowie eine Regelungslogik mit Regelungsstrategie zur Verhaltenssimulation, SiL das Erstellen von Modellen in der Zielsprache des ECUs zum automatisierten Testen im Softwareentwicklungen, HiL bezeichnet ein Verfahren, bei dem ein eingebettetes System (z B. reales elektronisches ECU oder reale mechatronische Komponente, die Hardware) über seine Ein- und Ausgänge an ein angepasstes Gegenstück angeschlossen wird, und unter DiL eine Kombination der HIL-Simulation mit einem Fahrsimulator in einer DIL-Simulationsumgebung verstanden.
Gemäß einer weiteren Ausführungsform teilen sich ein SiL-Software-Agent und ein HiL-Software-Agent den gleichen Software-Agenten. Unter einem Software-Agenten wird ein Computerprogramm verstanden, das zu gewissem eigenständigem und eigendynamischem (autonomem) Verhalten fähig ist. Das bedeutet, dass abhängig von verschiedenen Zuständen (Status) ein bestimmter Verarbeitungsvorgang abläuft, ohne dass von außen ein weiteres Startsignal gegeben wird oder während des Vorgangs ein äußerer Steuerungseingriff erfolgt. So kann die Anzahl der erforderlichen Software-Agenten reduziert werden.
Gemäß einer weiteren Ausführungsform weist das Plattform-Interfacemodul eine Programmierschnittstelle zum Datenaustausch mit anderen Komponente des Systems aufweist. Dabei wird unter einer Programmierschnittstelle (API, englisch application programming interface) ein Programmteil verstanden, der von einem Softwaresystem anderen Programmen zur Anbindung an das System zur Verfügung gestellt wird. Z.B. kann hier eine Programmierschnittstelle wie z.B. ASAM XiL API verwendet werden.
Gemäß einer weiteren Ausführungsform ist ein Immersionsmodul vorgesehen, das dazu ausgebildet ist, einem Nutzer eine optische Wiedergabe zumindest eines Tests wiederzugeben. Mit anderen Worten, dass Immersionsmodul stellt eine virtuelle Realität bereit, mit der der Nutzer interagieren kann. Das Immersionsmodul kann eine Virtual Reality-Plattform im Raummaßstab (z.B. HTC Vive oder Occulus) sein, mit der ein Test- oder Designingenieur einen Test als Zuschauer oder Schauspieler mit Zusatzgeräten, wie z.B. einem Head-Mounted-Display und/oder Body-Tracking durchführen kann.
Gemäß einer weiteren Ausführungsform ist ein Fahrsimulator vorgesehen, der dazu ausgebildet ist, eine Simulation mit einem physischen Modell eines Kraftfahrzeugs und einer Steuer- oder Regelstrategie durchzuführen. Der Fahrsimulator erlaubt es, eine Simulation mit einem physischen Modell eines Kraftfahrzeugs und einer Steuer- oder Regelstrategie, die in realen ECUs abläuft, durchzuführen. Mit anderen Worten, mit dem Fahrsimulator kann der Nutzer eine Steuer- oder Regelstrategie als Fahrer testen, indem er realistischere Schnittstellen (wie z.B. Lenkräder, Pedale, Schalthebel, usw.) verwendet. Der Antriebssimulator kann Force-Feedback- und G-Force-Simulation enthalten, wenn das Fahrverhalten getestet wird. Der Fahrsimulator kann direkt mit einer Spiel-Engine verbunden sein und die Informationen (wie z.B. Kräfte, Geschwindigkeiten, usw.) erhalten, die notwendig sind, um die Simulation von dort umzusetzen. Unter einer Spiel-Engine wird dabei ein spezielles Framework für Computerspiele verstanden, das den Spielverlauf steuert und für die visuelle Darstellung des Spielablaufes verantwortlich ist. Zu den am häufigsten verwendeten Spiel-Engines gehören die CryEngine, Frostbite, die Unity Engine und die Unreal Engine.
Gemäß einer weiteren Ausführungsform ist das System dazu ausgebildet zu bestimmen, welche der XiL-Plattformen benötigt werden. Es kann dann in einem weiteren Schritt eine Kommunikation mit der entsprechenden Plattform initialisiert werden. So werden nur die wirklich benötigten Plattformen geladen, was die Rechnerressourcen schont.
Gemäß einer weiteren Ausführungsform ist das System dazu ausgebildet zu prüfen, ob der Test ein Real-Time-Test ist, und auf ein Erfassen eines Real-Time-Tests hin eine Synchronisation durchzuführen. So kann berücksichtigt werden, dass die Simulationsdauer auf der ausgewählten XiL-Plattform länger als die Simulationsdauer auf einer Spiel-Engine ist. Des Weiteren kann auch vorgesehen sein, eine Synchronisation dann durchzuführen, wenn der Test kein Real-Time-Test ist.
Ferner gehört zur Erfindung ein Computerprogrammprodukt für ein derartiges System.
Es wird nun die Erfindung anhand einer Zeichnung erläutert. Es zeigen:

1 in schematischer Darstellung ein System zum Durchführen von XiL-Tests von Komponenten selbstfahrender Kraftfahrzeuge
2 in schematischer Darstellung weitere Details des in 1 dargestellten Systems.
3 in schematischer Darstellung einen Verfahrensablauf beim Betrieb des in 1 dargestellten Systems.
4 in schematischer Darstellung einen weiteren Verfahrensablauf beim Betrieb des in 1 dargestellten Systems.
5 in schematischer Darstellung einen weiteren Verfahrensablauf beim Betrieb des in 1 dargestellten Systems.
6 in schematischer Darstellung einen weiteren Verfahrensablauf beim Betrieb des in 1 dargestellten Systems.

Es wird zunächst auf 1 Bezug genommen.
Das System 2 ist zum Durchführen von XiL-Tests von Komponenten selbstfahrender Kraftfahrzeuge ausgebildet.
Das reale Kraftfahrzeug ist im vorliegenden Ausführungsbeispiel ein PKW. Ferner ist das reale Kraftfahrzeug im vorliegenden Ausführungsbeispiel als selbstfahrendes Kraftfahrzeug ausgebildet, dass ohne Einflussnahme eines menschlichen Fahrers fahren, steuern und einparken kann. Hierzu weist das reale Kraftfahrzeug verschiedene Sensoren (nicht dargestellt) zur Umgebungserfassung auf und kann aus den gewonnenen Informationen seine Position und die anderer Verkehrsteilnehmer bestimmen, in Zusammenarbeit mit der Navigationssoftware ein Fahrziel ansteuern und Kollisionen auf dem Weg dorthin vermeiden.
Bei den XiL-Tests kann es sich MiL (Model-in-the-Loop), SiL (Software-in-the-Loop), HiL (Hardware-in the-Loop) und/oder DiL (Driver-in-the-Loop) handeln.
MiL umfasst dabei den Aufbau von Modellen für eine Regelstrecke und ein ECU sowie eine Regelungslogik mit Regelungsstrategie zur Verhaltenssimulation, SiL das Erstellen von Modellen in der Zielsprache des ECUs zum automatisierten Testen im Softwareentwicklungen, HiL bezeichnet ein Verfahren, bei dem ein eingebettetes System (z.B. ein reales elektronisches ECU oder reale mechatronische Komponente, also Hardware) über seine Ein- und Ausgänge an ein angepasstes Gegenstück angeschlossen wird, und unter DiL wird eine Kombination der HiL-Simulation mit einem Fahrsimulator in einer DIL-Simulationsumgebung verstanden.
Das System 2 weist im vorliegenden Ausführungsbeispiel ein 3D-Simulationsmodul 4, ein Immersionsmodul 6, ein Plattform-Interfacemodul 8, ein Modell-Interfacemodul 10, ein Datenaustauschmodul 12, ein Netzwerk 14, ein XiL-Modul 16 und einen Fahrsimulator 18 auf.
Das 3D-Simulationsmodul 4 ist eine Umgebung, in der die Nutzer virtuelle 3D-Testszenarien angeben und Tests und Simulationen ausführen können. Ein kommerzielles Tool (z.B. PreScan, Oktal, CarSim) oder eine Spiel-Engine kann für diesen Zweck verwendet werden.
Das Immersionsmodul 6 ist im vorliegenden Ausführungsbeispiel eine Virtual Reality-Plattform im Raummaßstab (z.B. HTC Vive oder Occulus), mit der ein Test- oder Designingenieur einen Test als Zuschauer oder Schauspieler mit Head-Mounted-Display und/oder Body-Tracking durchführen kann.
Das Plattform-Interfacemodul 8 ermöglicht es, denselben Test (oder dieselbe Simulation) auf einer SiL-, MiL-, HiL- oder DiL-Plattform auszuführen, ohne den Test (oder die Simulation) neu zu definieren oder zu ändern. Dies kann erreicht werden, indem beispielsweise eine Standard-Software-Schnittstelle definiert und implementiert wird (API wie die ASAM XiL API).
Das Modell-Interfacemodul 10 erlaubt es, den gleichen Test (oder die gleiche Simulation) mit verschiedenen Modellen auszuführen, d.h. mit Modellen, die nach verschiedenen Namenskonventionen, Styleguides usw. implementiert wurden.
Das Datenaustauschmodul 12 ist ein Modul, das den gesamten Datenaustausch, die Datenintegrität und die Datensynchronisation zwischen den verschiedenen Modulen des Systems 2 und insbesondere zwischen der XiL-Plattform auf der einen Seite und der 3D-Simulations- und Visualisierungsumgebung auf der anderen Seite abwickelt.
Das Netzwerk 14 erlaubt es, sich mit einem globalen Kommunikationsnetzwerk zu verbinden, so dass andere Nutzer als Zuschauer oder Schauspieler mit oder ohne Immersion an dem Test oder der Simulation teilnehmen können.
Das XiL-Modul 16 weist z.B. einige HiL-Rigs mit Echtzeitkomponenten (z.B. dSPACE oder Concurrent) zur Ausführung von Modellen und/oder ECUs zum Ausführen von Steuer- oder Regelstrategien auf. Auf der anderen Seite kann das XiL-Modul 16 verschiedene Werkzeuge und Methoden zum Lesen, Schreiben, Aufzeichnen von Daten (z.B. Control Desk) oder ein Automatisierungswerkzeug aufweisen, um eine Sammlung von Tests über Nacht zu planen.
Der Fahrsimulator 18 erlaubt es, eine Simulation mit einem physischen Modell eines Kraftfahrzeugs und einer Steuer- oder Regelstrategie, die in realen ECUs abläuft, durchzuführen.
Die genannten Komponenten können für ihre nachfolgend beschriebenen Aufgaben und Funktionen Hard- und/oder Software-Komponenten aufweisen.
Es wird nun zusätzlich auf 2 Bezug genommen.
Dargestellt ist ein Nutzer 20, der das System 2 für eine Simulation oder einen XiL-Test nutzen möchte.
Er bedient sich dabei eines Endgerätes 22. Das Endgerät 22 kann z.B. ein PC, ein Smartphone, ein Tablet oder ein Notebook sein. Das Endgerät 22 weist im vorliegenden Ausführungsbeispiel zumindest das 3D-Simulationsmodul 4 und das Datenaustauschmodul 12 sowie ein Testautomationframework 28 und eine Physik-Engine 30 auf.
Das Simulationsmodul 4 ist dazu ausgebildet, Definitionen von 3D-Umgebungen und Szenarien bereitzustellen, in denen Tests oder Simulationen stattfinden. Diese Umgebung enthält mindestens eine interne einfache Physik-Engine (nicht dargestellt), um physikalische Gesetze während eines virtuellen 3D-Tests zu simulieren. Ein VR-Plug-in ermöglicht das visuelle Eintauchen in Szenarien, die mit einem Netzwerk-Plug-in für mehrere Nutzer entwickelt wurden. Unter einem Plug-in wird dabei eine Software-Erweiterung oder ein Zusatzmodul in Form einer optionalen Software-Komponente verstanden, die eine bestehende Software erweitert bzw. verändert. Das Simulationsmodul 4 kann eine Spiel-Engine enthalten oder auf ihr aufgebaut sein. Es kann ferner vorgesehen sein, in einer Implementierung die 3D-Umgebung nur zum Zweck der Darstellung zu verwenden.
Das Datenaustauschmodul 12 ist für die Kommunikation zwischen den XiL-Plattformen und den laufenden Tools zuständig. Das Datenaustauschmodul 12 weist im vorliegenden Ausführungsbeispiel einen SiL- Software-Agenten 50, einen HiL-Software-Agenten 52, einen MiL-Software-Agenten 54, einen DiL-Software-Agenten 56 und einen ECU-Software-Agenten 58 sowie einen Synchronisationssoftware-Agenten 60 für den Datenaustausch und einen Kommunikationssoftware-Agenten 62 für die Abwicklung der Kommunikation mit einer Signalverarbeitungs-Plattform 24 auf.
Die Signalverarbeitungs-Plattform 24 ist dazu ausgebildet, anhand der vom Testautomationframework 28 bereitgestellten Informationen die Plattform des Tests zu ermitteln. Basierend darauf kann der geeignete Kommunikationssoftware-Agent aktiviert werden, d.h. ein MiL- / SiL- / HiL- oder ECU-Manager. Jeder Software-Agent kann auf verschiedenen Technologien basieren.
Der SiL-Software-Agent 50 und der HiL-Software-Agent 52 können sich den gleichen Software-Agenten teilen (z.B. XiL API Model Access Port-Implementierung), um die Kommunikation mit Modellen zu handhaben.
Der ECU-Software-Agent 58 kann ein spezifischer Software-Agent sein, der für die Kommunikation mit verschiedenen ECUs bestimmt ist (z.B. Implementierung des XiL-API-ECU-Zugangsports).
Der Kommunikationssoftware-Agent 62 kann ein spezifischer Software-Agent sein, der für die Kommunikation mit Modellen in der Spiel-Engine oder der Physik-Engine 30, wie z.B. CarSim und Controls Strategie in Matlab / Simulink inklusive einiger Signal Processing ausgelegt ist (z.B. Computer Vision Toolbox). Dieser Software-Agent könnte basierend auf Shared Memory und UDP implementiert werden.
Jeder Software-Agent stellt die Datenintegrität sicher, um zu gewährleisten, dass nur ein Akteur Daten zurzeit schreibt oder liest. Schließlich wird der Synchronisationssoftware-Agent 60 aufgerufen, um die Synchronisation der Kommunikation sicherzustellen (Co-Simulation). Dies hängt davon ab, ob der Test oder die Simulation in der Real-Time-Plattform ausgeführt werden muss oder nicht. Unter Real-Time bzw. in Echtzeit wird dabei verstanden ein System ein bestimmtes Ergebnisse zuverlässig innerhalb einer vorbestimmten Zeitspanne liefert.
Wenn sich eine Real-Time-Plattform im Loop befindet kann die 3D-Spiel-Engine zu langsam oder zu schnell sein. In diesem Fall kann vorgesehen sein, Komponenten, wie z.B. eine Spiel-Engine, zu zwingen, zu warten oder langsamer zu arbeiten, wenn sie zu schnell ist. Wenn sich keine Real-Time-Plattform im Loop befindet, kann eine herkömmliche Synchronisationsstrategie (z. B. Doppelschwingpuffer) implementiert werden, bei der die Modell- und/oder Steuerungsplattformen ihre jeweilige Simulationszeit austauschen und aufeinander warten, bevor sie zum nächsten Simulationsschritt übergehen.
Das Testautomationframework 28 ist die Kernlogik des Systems 2, die es ermöglicht, Tests und Simulationen auf der XiL-Plattform zu konfigurieren, einzurichten, zu planen und auszuführen. Es kann einige Testspezifikationsdateien 46 und eine Modellabstraktionsdatenbank 48 enthalten, um den gleichen Test mit verschiedenen Modi ausführen zu können. Die Betriebsmodi dieser Module werden später erklärt:
Auf die Physik-Engine 30 kann zurückgegriffen werden, wenn der Nutzer 20 spezielle Anforderungen in Bezug auf ein physikalisches Modell hat. Bei der Physik-Engine 30 kann es sich z.B. um CarSim handeln.
Das XiL-Modul 16 weist im vorliegenden Ausführungsbeispiel eine SiL-Plattform 32, eine HiL-Plattform 34, ein ECU-Plattform 36, eine MiL-Plattform 38, ein Modellabstraktions-Modul 40, ein ECU-Abstraktions-Modul 42 und ein MiL-Abstraktions-Modul 44 auf.
Die SiL-Plattform 32 ist dazu ausgebildet, dass der Nutzer 20 das Modell und sein ECU für das Endgerät 22 kompiliert hat. Typischerweise kann eine SiL-Plattform ein PC, ein Smartphone, ein Tablet oder ein Notebook sein. Für jedes dieser Geräte implementiert die SiL-Software ein API- oder Access-Port-Code-Segment, das eine Plattformabstraktion erlaubt (z.B. nach dem XiL API MAP Port Standard).
Die HiL-Plattform 34 ist dazu ausgebildet, dass der Nutzer 20 das Modell für ein Real-Time-Gerät (z.B. dSPACE oder Concurrent) kompiliert. Für jede Real-Time-Gerätefamilie implementiert die HiL-Software (die für das Real-Time-Gerät kompiliert wurde) ein API- oder Zugangs-Port-Code-Segment, das eine Plattform-Abstraktion erlaubt (z.B. nach dem XiL-API-MAP-Port-Standard).
Die ECU-Plattform 36 ist Teil z.B. eines HiL-Tests. Auf ihm läuft die vom Nutzer 20 entwickelte Steuer- oder Regelstrategie, die später dann in einem Kraftfahrzeug implementiert werden soll. Es werden Werkzeug wie z.B. INCA oder ATI verwendet. Jedes Softwaresegment implementiert einen API oder Zugangs-Port-Code, der eine Plattform-Abstraktion erlaubt (z. B. nach dem XiL API EAP Port Standard).
Die MiL-Plattform 38 wird verwendet, wenn der Nutzer 20 eine Steuer- oder Regelstrategie z.B. in Simulink entwickelt und mit einem Modell testet, das auch in Simulink oder in einem externen Tool wie z.B. einer Spiel-Engine oder CarSim läuft. Im Fall einer Ausbildung als externes Tool wird ein API- oder Access-Port-Code-Segment implementiert, der eine Plattform-Abstraktion ermöglicht. Dies kann durch Verwendung von einem gemeinsamem Speicher, UDP von Simulink-Seite und API von der Tool-Seite erfolgen.
Das Modellabstraktions-Modul 40 erlaubt es, dass Modelle auf der SiL-Plattform 32 und/oder der HiL-Plattform 34, d.h. dem Endgerät 22 oder einem anderen Echtzeitgerät, laufen.
Das ECU-Abstraktions-Modul 42 ist dazu ausgebildet, dass Steuer- oder Regelstrategien auf dem ECU laufen, so dass eine reale Steuer- oder Regelstrategie auf einem Prüfstand getestet werden kann, bevor sie in Kraftfahrzeuge integriert wird.
Das MiL-Abstraktions-Modul 44 basiert im vorliegenden Ausführungsbeispiel auf einer modellbasierten Entwicklungsumgebung wie Simulink und ist dazu ausgebildet, Steuerungen als Modell zu implementieren. Es kann auf einem externen Tool wie CarSim ausgeführt werden oder einer Spiel-Engine.
Das Immersionsmodul 6 ist dazu ausgebildet, dem Nutzer 20 zu ermöglichen, sich den Test oder der Simulation als Zuschauer oder auch als Teilnehmer anzuschauen. Dazu gehören eine Immersion in die Szene, ein Controller, ein Head Mounted Display, ein Körperverfolgungsgerät usw. Immersionsplattformen sind typischerweise integriert in einer 3D-Simulationsumgebung mittels eines dedizierten Plug-Ins, das für diese Umgebungen bereitgestellt wird. Die Immersion kann unabhängig vom Rest des Tests durchgeführt werden. Sie ist nur mit der 3D-Simulationsumgebung verbunden.
Das Netzwerk 14 stellt im vorliegenden Ausführungsbeispiel eine Internetverbindung bereit,, die es anderen an einem entfernten Ort befindlichen Nutzern 26 ermöglicht, dem Test- oder Simulationsaufbau durch den Nutzer 20 auf ähnliche Weise wie bei Online-Computerspielen beizutreten. Die Spiel-Engine stellt ein Plug-In bereit, um Netzwerke zu ermöglichen, die für diesen Zweck verwendet werden können. Diese Funktionen können verwendet werden, um einen kollaborativen Testbetriebsmodus zu.
Mit dem Fahrsimulator 18 kann der Nutzer 20 eine Steuer- oder Regelstrategie als Fahrer testen, indem er realistischere Schnittstellen (Lenkräder, Pedale, Schalthebel, usw.) verwendet. Der Antriebssimulator kann Force-Feedback- und G-Force-Simulation enthalten, wenn das Fahrverhalten getestet wird. Der Fahrsimulator 18 kann direkt mit einer Spiel-Engine verbunden sein und die Informationen Kräfte, Geschwindigkeiten, usw.) erhalten, die notwendig sind, um die Simulation von dort umzusetzen.
Es wird nun unter zusätzliche Bezugnahme auf 3 die Durchführung eines Setup-Tests erläutert.
Der Nutzer 20 wählt zuerst mindestens ein Modell für mindestens eine Modellzielplattform und mindestens eine Steuersoftware für mindestens eine Steuerzielplattform aus (Schritte S1000 bis S1040). Dann wählt der Nutzer 20 eine 3D-Umgebung und eine Szenariodefinition für die Spiele-Engine (Schritt S1050). Ferner wird die Physik-Engine 30 konfiguriert (Schritt S1060).
Optional kann der Nutzer 20 einen oder mehrere Signalverarbeitungsalgorithmen konfigurieren, die auf einer Plattform ausgeführt werden (Schritt S1070). Des Weiteren kann der Nutzer 20 einige visuelle Immersionselemente auf der Spiel-Engine und eine Vernetzung konfigurieren (Schritte S1080 und S1090). Schließlich kann der Nutzer 20 auswählen, ob der Test oder die Simulation als X-in-the-Loop ausgeführt werden soll.
In diesem Fall wird der Fahrsimulator 18 vom Nutzer 20 konfiguriert (Schritt S1100). Andernfalls werden einige Testdefinitions- und Analysedateien bereitstellen, die beispielsweise Eingabestimuli und Auswertungs- und Berichtsanweisungen enthalten (Schritte S1110 und S1120).
Dann wird in einem weiteren Schritt die Software geladen und das System 2 aktiviert (Schritt S1130).
Es wird nun unter zusätzlicher Bezugnahme auf 4 ein Lauftest erläutert.
In einem ersten Schritt erfolgt eine Planung des Tests, einhergehend mit einer Rechnerressourcenzuweisung. Dies kann auch ein Multi-Threading umfassen (Schritt S2000).
In einem weiteren, optionalen Schritt kann ein Server gestartet werden für einen Betrieb im Netzwerk 14 (Schritt S2010).
In einem weiteren, optionalen Schritt kann das Immersionsmodul 6 gestartet werden (Schritt S2020).
In einem weiteren, optionalen Schritt kann der Fahrsimulator 18 gestartet werden (Schritt S2030).
Nun wird in einem weiteren Schritt das System 2 aktiviert (Schritt S2040).
In einem weiteren Schritt werden dann die lokalen Verbindungen geprüft (Schritt S2050).
In einem weiteren, optionalen Schritt kann eine Signalverarbeitung gestartet werden (Schritt S2060).
Schließlich kann in einem weiteren Schritt der Test oder die Simulation gestartet werden (Schritt S2070).
Es wird nun unter zusätzliche Bezugnahme auf 5 der Betrieb des Modell-Interfacemoduls 10 erläutert.
In einem ersten Schritt wird ein Modell eingelesen (Schritt S3000).
In einem weiteren Schritt erfolgt ein Zugriff auf eine Signal-Tag-Datenbank (Schritt S3010).
In einem weiteren Schritt erfolgt eine Analyse des Modells, um Signale zu extrahieren und ihr Pfad wird extrahiert wie z.B. ein Simulink-Pfad (Schritt S3020).
In einem weiteren Schritt erfolgt eine Abfrage bezüglich des Namens des Signals in der Datenbank (Schritt S3030).
Schließlich werden in einem weiteren Schritt das Label und der Pfad in einer Datei wie einer XML-Datei verwendet (Schritt S3040). Die Labels oder Tags sind logische Namen, die in den Testanweisungen oder Testspezifikationen verwendet werden.
Es wird nun unter zusätzlicher Bezugnahme auf 6 der Betrieb des Systems 2 erläutert.
In einem ersten Schritt wird bestimmt, welche der XiL-Plattformen benötigt werden (Schritt S4000).
Wenn die SiL-Plattform 32, die HiL-Plattform 34 oder die ECU-Plattform 36 benötigt wird, wird in einem weiteren Schritt eine Kommunikation mit der entsprechenden Plattform initialisiert (Schritt S4010).
In einem weiteren Schritt werden dann die lokalen Verbindungen geprüft (Schritt S4020).
In einem weiteren Schritt wird dann ein Datenaustausch gestartet (Schritt S4030) .
Wenn hingegen die MiL-Plattform 38 oder die Signalverarbeitungs-Plattform 24 benötigt wird, wird in einem weiteren Schritt eine Kommunikation mit der entsprechenden Plattform initialisiert (Schritt S4040).
In einem weiteren Schritt werden dann die lokalen Verbindungen geprüft (Schritt S4050).
In einem weiteren Schritt wird dann ein Datenaustausch gestartet (Schritt S4060) .
In beiden Fällen wird dann in einem weiteren Schritt geprüft, ob der Test oder die Simulation ein Real-Time-Test bzw. eine Real-Time-Simulation ist oder nicht (Schritt S4070).
Wenn der Test oder die Simulation ein Real-Time-Test oder eine Real-Time-Simulation ist erfolgt in einem weiteren Schritt eine Synchronisation (Schritt S4080).
In einem weiteren Schritt wird geprüft, ob die Simulationsdauer auf der ausgewählten XiL-Plattform länger ist als die Simulationsdauer der Spiel-Engine ist (Schritt S4090).
Ist dies der Fall wird zum Vorgängerschritt (Schritt S4080) zurückgekehrt zur Synchronisation.
Andernfalls wird in einem weiteren Schritt ein Zeitfaktor der Spiel-Engine auf null reduziert, oder es wird der Zeitfaktor der Simulation angepasst (Schritt S4100). Fortgesetzt wird das Verfahren dann mit der Synchronisation (Schritt S4080).
Wenn hingegen der Test oder die Simulation kein Real-Time-Test oder keine Real-Time-Simulation ist erfolgt in einem weiteren Schritt eine Synchronisation (Schritt S4110).
In einem weiteren Schritt wird geprüft, ob der Simulationsschritt von der Spiel-Engine abgeschlossen wurde (Schritt S4120).
Ist dies nicht der Fall wird zum Vorgängerschritt (Schritt S4110) zurückgekehrt zur Synchronisation.
Andernfalls wird in einem weiteren Schritt der Simulationsschritt z.B. in Simulink ausgeführt (Schritt S4130).
So können mit dem System 2 verschiedene Tests auf einer XiL-Plattform durchgeführt werden, was das Durchführen derartiger Tests vereinfacht.
Bezugszeichenliste

2: System
4: 3D-Simulationsmodul
6: Immersionsmodul
8: Plattform-Interfacemodul
10: Modell-Interfacemodul
12: Datenaustauschmodul
14: Netzwerk
16: XiL-Modul
18: Fahrsimulator
20: Nutzer
22: Endgerät
24: Signalverarbeitungs-Plattform
26: Nutzer
28: Testautomationframework
30: Physik-Engine
32: SiL-Plattform
34: HiL-Plattform
36: ECU-Plattform
38: MiL-Plattform
40: Modellabstraktions-Modul
42: ECU-Abstraktion-Modul
44: MiL-Abstraktions-Modul
46: Testspezifikationsdateien
48: Modellabstraktionsdatenbank
50: SiL- Software-Agent
52: HiL-Software-Agent
54: MiL-Software-Agent
56: DiL-Software-Agent
58: ECU-Software-Agent
60: Synchronisationssoftware-Agent
62: Kommunikationssoftware-Agent

Claims

System (2) zum Durchführen von XiL-Tests von Komponenten selbstfahrender Kraftfahrzeuge, mit zumindest einem Plattform-Interfacemodul (8), wobei das Plattform-Interfacemodul (8) dazu ausgebildet ist, Tests auf einer Mehrzahl von XiL-Plattformen auszuführen.
System (2) nach Anspruch 1, wobei die Mehrzahl der XiL-Plattformen zumindest eine SiL-Plattform (32) und/oder eine HiL-Plattform (34) und/oder eine MiL-Plattform (36) und/oder eine DiL-Plattform aufweist.
System (2) nach Anspruch 1 oder 2, wobei ein SiL-Software-Agent (50) und ein HiL-Software-Agent (52) sich den gleichen Software-Agenten teilen.
System (2) nach Anspruch 1, 2 oder 3, wobei das Plattform-Interfacemodul (8) eine Programmierschnittstelle zum Datenaustausch mit anderen Komponenten des Systems (2) aufweist.
System (2) nach einem der Ansprüche 1 bis 4, wobei ein Immersionsmodul (6) vorgesehen ist, das dazu ausgebildet ist, einem Nutzer 20 eine optische Wiedergabe zumindest eines Tests wiederzugeben.
System (2) nach einem der Ansprüche 1 bis 5, wobei ein Fahrsimulator (18) vorgesehen ist, der dazu ausgebildet ist, eine Simulation mit einem physischen Modell eines Kraftfahrzeugs und einer Steuer- oder Steuer- oder Regelstrategie durchzuführen.
System (2) nach einem der Ansprüche 1 bis 6, wobei das System (2) dazu ausgebildet ist zu bestimmen, welche der XiL-Plattformen benötigt werden.
System (2) nach einem der Ansprüche 1 bis 7, wobei das System (2) dazu ausgebildet ist zu prüfen, ob der Test ein Real-Time-Test ist, und auf ein Erfassen eines Real-Time-Tests hin eine Synchronisation durchzuführen.
Computerprogrammprodukt für ein System (2) nach einem der Ansprüche 1 bis 8.