DE102016220670A1

DE102016220670A1 - Verfahren und System zum Testen von Software für autonome Fahrzeuge

Info

Publication number: DE102016220670A1
Application number: DE102016220670.2A
Authority: DE
Inventors: Frederic Stefan; Marie Roger Alain Chevalier; Evangelos BITSANIS; Michael Marbaix
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2015-11-06
Filing date: 2016-10-21
Publication date: 2017-05-11
Also published as: US10579512B2; US20170132118A1; CN106991041A; CN106991041B

Abstract

Die Erfindung betrifft ein Verfahren und ein System zum Testen von Software für autonome Fahrzeuge mittels einer Loop-Simulation unter Einbindung von Hardware in Form von einem oder mehreren realen autonomen Fahrzeugen (4), welche zur Durchführung von autonomen Testfahrten in der realen Welt in der Lage sind. Gemäß der Erfindung wird auf einen von einem Benutzer gegebenen Arbeitsauftrag hin automatisch geprüft, welche unter mehreren realen autonomen Fahrzeugen (4), die zur Durchführung von autonomen Testfahrten auf weltweit verteilten Teststrecken (5a, 5b, 5c) in der realen Welt in der Lage sind, für einen oder mehrere in dem Arbeitsauftrag definierte Tests aktuell zur Verfügung stehen. Die Durchführung der Software-Tests und der Testfahrten wird dann automatisch geplant und koordiniert.

Description

Die Erfindung betrifft ein Verfahren und ein System zum Testen von Software für autonome Fahrzeuge unter Einbindung von Hardware in Form von einem oder mehreren realen autonomen Fahrzeugen, welche zur Durchführung von autonomen Testfahrten in der realen Welt eingerichtet sind, gemäß den Oberbegriffen der Patentansprüche 1 und 6.
Ein derartiges Verfahren und ein derartiges System sind aus der Publikation Bock T., Maurer M., van Meel F., Müller T., "Vehicle in the Loop, Ein innovativer Ansatz zur Kopplung virtueller mit realer Erprobung" in ATZ 01/2008 Jahrgang 110, S. 2–8, bekannt. Darin wird ein Test- und Simulationsumfeld für Fahrerassistenzsysteme beschrieben, in dem ein reales Versuchsfahrzeug, das sich nicht im öffentlichen Straßenverkehr, sondern auf einer Freifläche oder einem Erprobungsgelände bewegt, mit einem Fahrsimulator kombiniert wird. Mit einem derartigen, "Vehicle in the Loop" genannten Prüfaufbau kann gefahrlos getestet werden, wie Fahrerassistenzfunktionen auf virtuellen Fremdverkehr oder sonstige virtuelle Objekte in einem virtuellen Verkehrsumfeld reagieren.
Aus der DE 196 15 008 A1 ist ein Verfahren und eine Vorrichtung zum Steuern eines Prüfstraßensystems für Kraftfahrzeuge bekannt. Dieses Dokument beschäftigt sich mit der computergestützten Abwicklung von Prüfvorgängen in einer bestimmten Prüfumgebung, hat jedoch nicht die Planung und Verteilung von Prüfvorgängen auf verschiedene Prüfumgebungen zum Gegenstand.
Die AT 511 131 A2 beschäftigt sich mit dem Zusammenspiel von realen und virtuellen Prüfungsvorgängen beim Test von Fahrtzeugen oder Fahrzeugkomponenten.
Für Software-Verifikation und -Validierung auf Systemebene spezifiziert man traditionell einen Satz von Stimuli und erwarteten Reaktionen des Systems. Die Stimuli und erwarteten Reaktionen werden direkt aus entsprechenden Anforderungen abgeleitet. Der Umfang dieser Anforderungen und daher auch der Umfang der Testfälle sind im Allgemeinen auf einen endlichen Satz von identifizierten Anwendungsfällen beschränkt. Typischerweise werden die Testfälle von Testingenieuren unter Verwendung von Software-Testwerkzeugen spezifiziert. Solche Werkzeuge können Funktionen zur Unterstützung von Testautomatisierung und zur Vergrößerung der Test-Maturität aufweisen (Versions-Management, Ausgabe-Tracker, grafische Testspezifikation usw.).
Die spezifizierten Tests werden dann in einem autonomen Fahrzeug durchgeführt, um zu bewerten, ob die entsprechenden Anforderungen korrekt im Fahrzeug implementiert worden sind (funktionelle Integration) und ob die entsprechenden Anforderungen akzeptabel sind (Kundenakzeptanz).
Die Anzahl von Testfällen für das Fahren im Fahrzeug ist an ein entwickeltes, in einem Fahrzeug integriertes Merkmal gebunden. Die auf dieses Merkmal und seine Integration bezogenen Tests definieren den Umfang der Verifikation und Validierung.
Für das Testen von Software für autonome Fahrzeuge scheint der Umfang der Tests beinahe unendlich zu sein. Tatsächlich muss so ein System im Stande sein, die meisten Fahrsituationen zu bewältigen, denen irgendein Fahrer in seinem Leben möglicherweise begegnet. Verschiedene Fahrer werden verschiedenen Arten von Anwendungsfällen gegenüber stehen, abhängig von einer großen Zahl von Umfeldfaktoren (andere Verkehrsteilnehmer, Tageszeit, Wetter, Gesundheit, Fahrzeugverschleiß, Straßenzustand usw.). Daher scheint es eine extrem hohe Zahl von Testkombinationen zu geben, und die Dauer der Fahrzeugtests scheint noch viel höher zu sein. Insbesondere die Planung solcher Tests oder die Wiederholung von bestimmten Tests durch Teams, die weltweit zusammenarbeiten, erfordert neue Verfahren und eine neue Plattform, um die Verifikation und Validierung von autonomen Fahrzeugen zu erleichtern.
Der Erfindung liegt die Aufgabe zu Grunde, die Verifikation und Validierung von autonomen Fahrzeugen auf Systemebene unter Bedingungen der realen Welt zu ermöglichen, und insbesondere, eine Lösung für die Beschränkungen bereitzustellen, die existieren können, wenn bestimmte Prototyp-Fahrzeuge oder Testanlagen nur in einem bestimmten geografischen Gebiet vorhanden sind.
Diese Aufgabe wird durch ein Verfahren und ein System mit den Merkmalen der Patentansprüche 1 und 6 gelöst.
Gemäß der Erfindung wird auf einen von einem Benutzer gegebenen Arbeitsauftrag hin automatisch geprüft, welche unter mehreren realen autonomen Fahrzeugen, die zur Durchführung von autonomen Testfahrten auf weltweit verteilten Teststrecken in der realen Welt in der Lage sind, für einen oder mehrere in dem Arbeitsauftrag definierte Tests aktuell zur Verfügung stehen, und dass die Durchführung der Software-Tests und der Testfahrten automatisch geplant und koordiniert wird.
Das erfindungsgemäße Verfahren wird in einem System durchgeführt, das sich auf ein Netz stützt, das mindestens ein Client-Gerät, mindestens einen Cloud-Server sowie Endgeräte umfasst, die mindestens ein Simulations-Endgerät wie z. B. HiL-Geräte und mindestens ein autonomes Fahrzeug umfassen.
Mit der Erfindung können existente globale XiL-Frameworks (Programmgerüste) um die Fähigkeit erweitert werden, Software für autonome Fahrzeuge auf Systemebene und in einem realen Umfeld auf der Welt zu simulieren, zu validieren und zu verifizieren. Ein zur Durchführung des erfindungsgemäßen Verfahrens eingerichtetes System ist im Stande, ein oder mehrere autonome Fahrzeuge weltweit zu befehligen, um auf reservierten Teststrecken bestimmte Manöver durchzuführen, und es ist auch im Stande, die Ergebnisse der Testfahrt an eine Bedienungsperson zurückzusenden.
XiL ist ein Standard für die Kommunikation zwischen Testautomatisierungswerkzeugen und Prüfständen in Form von virtuellen Umfeldern zur Softwareverifikation. XiL unterstützt Prüfstände auf allen Stufen des Entwicklungs- und Testprozessen, insbesondere MiL ("Model-in-the-Loop"), SiL (Software-in-the-Loop) und HiL (Hardware-in-the-Loop). Die Bezeichnung "XiL" zeigt somit an, dass der Standard für alle möglichen "in-the-Loop"-Systeme verwendet werden kann, wobei die in dem System durchgeführte Simulation hierin als Loop-Simulation bezeichnet wird.
Vorteilhafte Weiterbildungen der Erfindung sind in den abhängigen Patentansprüchen angegeben.
Insbesondere kann die Durchführung der Testfahrten über ein globales Datenkommunikationsnetz geplant und koordiniert werden, und ein Arbeitsauftrag kann Konfigurationsanweisungen, Umfeldanweisungen, Betriebsanweisungen, Datenerfassungsanweisungen und/oder Prüfbedingungs- und Berichtsanweisungen umfassen, welche weiter unten jeweils näher beschrieben werden.
In einer bevorzugten Ausführungsform werden auf einen von einem Benutzer gegebenen Arbeitsauftrag hin automatisch geeignete autonome Fahrzeuge und geeignete Teststrecken in verschiedenen Erprobungseinrichtungen auf verschiedenen Kontinenten identifiziert und gebucht, Software-Tests geplant, zu einer geplanten Zeit Software und Testanweisungen auf zu den Fahrzeugen gehörende Simulations-Endgeräte hochgeladen und während der Tests Daten von den Fahrzeugen bzw. Simulations-Endgeräten heruntergeladen, und nach Beendigung der Tests kann ein Testbericht generiert und an den Benutzer gesendet werden. Die Simulations-Endgeräte können insbesondere XiL- oder HiL-Geräte sein.
Es folgt eine Beschreibung von Ausführungsbeispielen anhand der Zeichnung. Deren einzige Figur zeigt einen Überblick über ein System zum Testen von Software für autonome Fahrzeuge.
Unter Bezugnahme auf die Figur umfasst das System eine Anzahl von Client-Geräten 1 zum Definieren und Senden von Arbeitsaufträgen, eine Anzahl von Cloud-Servern 2 zum Zuweisen, Organisieren und Einreihen der Arbeitsaufträge, eine Anzahl von Simulations-Endgeräten 3, eine Anzahl von Flotten von autonomen Fahrzeugen 4, die sich an ganz verschiedenen Orten auf dem Globus befinden können, und eine Anzahl von verschiedenen Straßenumfeldern, z. B. außerstädtische Teststrecken 5a, städtische Teststrecken 5b und Autobahn-Teststrecken 5c, an denen jeweils eine der Flotten von autonomen Fahrzeugen 4 stationiert ist.
Die Client-Geräte 1 ermöglichen es Testingenieuren, einen Satz von Arbeitsaufträgen zu definieren und in das System zu senden. Ein Arbeitsauftrag kann aus folgenden Anweisungen bestehen:

– Konfigurationsanweisungen, welche die nötige Hardware (ECU, Fahrzeug-Geräteausstattung, HiL-Kenndaten usw.) zum Abarbeiten eines Arbeitsauftrags und die für diese Hardware verlange Kalibrierung beschreiben. Es ist denkbar, dass für einen Test mehrere autonome Fahrzeuge 4 aktiviert werden, wobei sich z. B. nur ein Fahrzeug 4 in der realen Welt bewegt, während ein oder mehrere andere Fahrzeuge 4 derartige Fahrten nur simulieren.
– Umfeldanweisungen, welche ein Simulationsumfeld beschreiben, in dem der Arbeitsauftrag abgearbeitet werden soll. Das Simulationsumfeld kann eine Straße in der realen Welt auf einer Teststrecke sein, die auf irgendeinem Erprobungsgelände oder in einer dedizierten Testeinrichtung zur Verfügung steht, und schließt eine virtuelle Version der Teststrecke ein. Die virtuelle Version der Teststrecke kann auch auf Basis von charakteristischen Merkmalen von Straßen in der realen Welt automatisch erzeugt werden. Das Umfeld kann auch ein besonderer reservierter Abschnitt einer öffentlichen Straße sein.
– Betriebsanweisungen, welche die Route, der ein autonomes Fahrzeug 4 in dem definierten Umfeld folgen soll, präzise beschreiben, z. B. Startpunkt, Endpunkt, Anzahl der Fahrten; Anzahl der Wiederholungen, Fahrtstrecke usw. Es können auch besondere Restriktionen oder Ereignisse spezifiziert werden, z. B. Geschwindigkeitsbegrenzungen, Einspritzversagen usw. Es könnten auch besondere Artefakte aktiviert werden, die auf der Umfeldstraße zur Verfügung stehen, z. B. ein Dummy, der die Straße überquert, Spritzwasser auf der Straße usw. Außerdem könnte das Verhalten anderer Verkehrsteilnehmer in Bezug auf ein Haupt-Testfahrzeug spezifiziert werden, z. B. Überholmanöver, starkes Bremsen eines vorausfahrenden Fahrzeugs usw.
– Datenerfassungsanweisungen, welche den Satz von Informationen wie z. B. CAN-Signale, interne Signale, externe Videoerfassungen usw. beschreiben, die aufgezeichnet werden, während der Arbeitsauftrag abgearbeitet wird.
– Prüfbedingungs- und Berichtsanweisungen, welche Prüfbedingungen beschreiben, die das System während des gesamten Tests erfüllen soll, z. B. keine Deadlock-Situationen, keine Kollision, kein Rucken außerhalb bestimmter Wertebereiche usw., und welche bei der Generierung von anwenderspezifischen Berichten Anwendung finden, die das Ergebnis des Tests am Ende des Arbeitsauftrags oder in einem bestimmten Zeitintervall während dessen Abarbeitung zusammenfassen.

Der oder die Cloud-Server 2 sind eine oder mehrere Computer-Zentraleinheiten, welche die von den Testingenieuren gesendeten Arbeitsaufträge abarbeiten, nämlich einen geeigneten Satz von weltweit zur Verfügung stehenden Endgeräten zu identifizieren und auszuwählen. Diese Tätigkeit umfasst:

– Konfigurieren der Endgeräte, z. B. Flashen von Software und Kalibrierung, Laden von Simulationsumfeldern usw.
– Planen einer Simulation in einem virtuellen Umfeld, um die Gefahr von Fehlkonfigurationen durch den Anwender zu mildern und die Ausfallgefahr zu mildern. Dies könnte sich auf ein Fahrzeug in der Test-Loop beziehen, wobei das ganze Fahrzeug, ohne sich zu bewegen, durch das Simulations-Endgerät simuliert wird.
– Planen einer weltweiten Simulation mittels des oder der zugeordneten autonomen Fahrzeuge 4.

Falls die Endgeräte aus irgendeinem Grund nicht fernkonfiguriert werden können, sollte der Cloud-Server 2 den Inhaber der Endgeräte auffordern, die benötigten Anpassungen vorzunehmen.
Der Cloud-Server 2 stellt auch die Verfügbarkeit der Endgeräte für die Dauer des Tests sicher, z. B. mittels eines Einreihungssystems.
Die Endgeräte, auf die die Arbeitsaufträge abzielen, sind typischerweise Paare von Simulations-Endgeräten 3 wie z. B. HiL-Geräten und autonomen Fahrzeugen 4, wobei ein Simulations-Endgerät 3 in einem autonomen Fahrzeug 4 eingebaut oder in der Nähe stationiert und per Funk mit den Fahrzeug 4 verbunden sein kann. Beide Arten von Endgeräten können die in dem Arbeitsauftrag spezifizierten Konfigurations- und Umfeldanweisungen unterstützen. Die Simulations-Endgeräte 3 und die autonomen Fahrzeuge 4 werden idealerweise mit Schnittstellen ausgerüstet, welche die vom Cloud-Server 2 geplante Fernkonfiguration ermöglichen. Die autonomen Fahrzeuge 4 sollten sich nahe an einem Straßenumfeld befinden, das den vom Anwender definierten Kenngrößen entspricht.
Für Loop-Simulation befindet sich jedes Simulations-Endgerät 3 am besten am Ort der autonomen Fahrzeuge 4, die es kontrolliert. Bestimmte Simulations-Endgeräte 3 können aber auch mit bestimmten entfernten autonomen Fahrzeugen kompatibel sein, da man sich vorstellen kann, das ein Fahrzeug in der Loop-Simulation aus großer Entfernung kontrolliert werden kann.
Die Pfeile A in der Figur veranschaulichen Datenkommunikationsverbindungen zwischen je einem der Client-Geräte 1, Cloud-Server 2, Simulations-Endgeräte 3 und autonomen Fahrzeuge 4. Über diese Datenkommunikationsverbindungen sendet ein Entwickler an dem Client-Gerät 1 z. B. einen Arbeitsauftrag, 200 km autonomes Fahren auf einer außerstädtischen Teststrecke 5a als Straßenumfeld durchzuführen. Vor Durchführung einer Testfahrt in der realen Welt durch ein autonomes Fahrzeug 4 auf der Teststrecke 5a bindet ein Simulations-Endgerät 3 das autonome Fahrzeug 4 in die Loop-Simulation ein.
Das Verfahren zum Testen von Software für autonome Fahrzeuge in globalen Test-Frameworks wird nun unter Bezugnahme auf die Figur und deren Erläuterung anhand des Beispiels beschrieben, dass ein in Europa befindlicher Entwickler eine neue Software für adaptive Tempomaten (ACC = Adaptive Cruise Control) im Zustand von frei fließendem Autobahnverkehr testen will. Ein ACC-System ist ein Tempomat, mit dem ein Fahrzeug seine Geschwindigkeit automatisch konstant halten, aber auch automatisch verringern kann, wenn ein vorausfahrendes Fahrzeug im Fahrweg erkannt wird, dem es dann mit angepasster Geschwindigkeit folgt.
Es seien die folgenden Test durchzuführen:

– Reaktion des Testfahrzeugs auf einen veränderten Zielwert für die Fahrzeuggeschwindigkeit.
– Testen, dass die Distanz zu einem vorausfahrenden Fahrzeug eingehalten wird.
– Testreaktion im Falle eines einscherenden anderen Fahrzeugs.

An dem Client-Gerät 1 spezifiziert der in Europa befindliche Entwickler die folgenden Daten:

– Konfigurationsanweisungen: – Zum Testen des ACC-Systems wird ein Host-Fahrzeug benötigt. Es sollte einen speziellen Controller an Bord haben, der im Stande ist, mit dem Motorsteuermodul und mit einigen Sensoren wie z. B. Lidar, Kamera, Radar usw. zu kommunizieren. Es sollte möglich sein, die ACC-Software auf diesen Controller zu flashen. Es sollte auch möglich sein, programmatisch Fahranweisungen an das autonome Fahrzeug zu senden. – Es wird ein zweites autonomes Fahrzeug zum Testen von Interaktionen mit dem zu testenden Fahrzeug benötigt. Es sollte möglich sein, programmatisch Fahranweisungen an das zweite Fahrzeug zu senden. Es sollte auch möglich sein, dass eine menschliche Person Fahranweisungen an das zweite Fahrzeug sendet.
– Umfeldanweisungen: – Es wird ein Erprobungsgelände mit einer autobahnähnlichen Teststrecke benötigt, d. h. einer langen Straße von guter Straßenqualität, die gerade ist oder große Kurvenradien hat, so dass sie schnelles Fahren erlaubt.
– Betriebsanweisungen:
– Test 1: – Starte das Host-Fahrzeug. – Lasse das Host-Fahrzeug mit 80 km/h fahren und der Straße folgen. – Aktiviere das zu testende ACC-System mit einer Zielgeschwindigkeit von 120 km/h. – Warte, bis eine bestimmte Zeit verstrichen ist. – Senke die ACC-Zielgeschwindigkeit in Schritten von 5 km/h pro Minute auf 0 km/h ab. – Lasse das Host-Fahrzeug zum Startpunkt zurückkehren und schalte seinen Antriebsmotor aus.
– Test 2: – Starte das zweite Fahrzeug. – Lasse das zweite Fahrzeug mit 80 km/h fahren und der Straße folgen. – Starte das Host-Fahrzeug. – Lasse das Host-Fahrzeug mit 80 km/h fahren und der Straße zwei Minuten später folgen. – Aktiviere das zu testende ACC-System mit einer Zielgeschwindigkeit von 120 km/h und einer Zieldistanz von 100 m zu einem vorausfahrenden Fahrzeug. – Ändere die Distanz zum vorausfahrenden Fahrzeug in unterschiedlichen Schritten. – Lasse die zwei Fahrzeuge nach einer bestimmten Fahrtstrecke zum Startpunkt zurückkehren und schalte ihre Antriebsmotoren aus.
– Test 3: – Starte das Host-Fahrzeug. – Lasse das Host-Fahrzeug mit 80 km/h fahren und der Straße folgen. – Aktiviere das zu testende ACC-System mit einer Zielgeschwindigkeit von 120 km/h und einer Zieldistanz von 100 m zu einem vorausfahrenden Fahrzeug. – Starte das zweite Fahrzeug zwei Minuten später und lasse es mit 140 km/h fahren. – Lasse das zweite Fahrzeug das Host-Fahrzeug überholen und in einer bestimmten Distanz vom Host-Fahrzeug ein Einscher-Manöver durchführen. – Teste mehrere Einscher-Manöver mit unterschiedlichen Distanzen. – Lasse die zwei Fahrzeuge zum Startpunkt zurückkehren und schalte ihre Antriebsmotoren aus.
– Datenerfassungsanweisungen: – Alle von dem Host-Fahrzeug und dem zweiten erhältlichen Signale sollen erfasst und mit bestimmten Kennungen an einen Cloud-Server 2 gesendet werden.
– Prüfbedingungs- und Berichtsanweisungen: – Informiere den Entwickler über den Testplan und sende Berichtsdaten, nachdem der Test durchgeführt worden ist. – Definiere folgende Prüfbedingungen, die automatisch in den Bericht aufgenommen werden sollen: – Für Test 1, prüfe, dass die Fahrzeug-Zielgeschwindigkeit innerhalb der in den ACC-Merkmalsattributen spezifizierten Zeit erreicht worden ist. – Für Test 2, prüfe, dass die Distanz zum vorausfahrenden Fahrzeug innerhalb der in den ACC-Merkmalsattributen spezifizierten Toleranz eingehalten worden ist. – Für Test 3, prüfe, dass die ACC-Software die Einscher-Situation erkannt hat und dass ein Bremsbefehl gegeben worden ist.

Sobald die Anweisungen definiert worden sind, sendet sie der Entwickler an einen Cloud-Server 2.
Der Cloud-Server 2 analysiert die vom Entwickler gesendeten Anweisungen und führt die folgenden Tätigkeiten durch:

– Der Cloud-Server 2 identifiziert geeignete Fahrzeuge auf verschiedenen Erprobungsgeländen in Europa, Asien und Amerika.
– Der Cloud-Server 2 identifiziert nur geeignete Teststrecken in Asien und Amerika.
– Der Cloud-Server 2 stellt fest, dass die Teststrecken in Amerika intensiv für andere Tests genutzt wird; daher werden die Teststrecke in Asien und die entsprechenden Fahrzeuge genutzt.
– Der Cloud-Server 2 plant den Test, bucht die Fahrzeuge und die Teststrecke in Asien für die Dauer des Tests und benachrichtigt den örtlichen Verantwortlichen.
– Zur geplanten Zeit lädt der Cloud-Server 2 die nötige Software, Testanweisungen auf die Testfahrzeuge in Asien hoch.
– Während des Tests lädt der Cloud-Server 2 Daten von den Fahrzeugen herunter, und wenn der Test beendet ist, plant der Cloud-Server 2 die Generierung des Testberichts, die von einem externen System durchgeführt werden kann. Schließlich teilt der Cloud-Server 2 dem Entwickler mit, dass der Test beendet worden ist, und sendet ihm den Testbericht.

Endgeräte:

– In diesem Beispiel befinden sich zwei Testfahrzeuge in Asien: Das Host-Fahrzeug und das zweite Fahrzeug.
– Die ACC-Software wird mittels des Cloud-Servers 2 auf das Host-Fahrzeug bzw. das zugehörige Simulations-Endgerät geflasht.
– Jedes Fahrzeug empfängt zuerst die Anweisung, sich zur richtigen Zeit auf die richtige Teststrecke zu begeben.
– Die Testanweisungen für Test 1, Test 2 und Test 3 werden in jedem Fahrzeug gespeichert, z. B. in einem dedizierten Speicher.
– Jedes Fahrzeug führt dann zur richtigen Zeit seine Anweisungen aus, z. B. zu starten, mit 80 km/h zu fahren, usw.

Allgemein werden mit der Erfindung Verfahren und Algorithmen bereitgestellt, um die Durchführung von Testfahrten durch autonome Fahrzeuge automatisch zu planen und zu koordinieren. Die Verfahren stützen sich auf ein globales Netz, das mindestens ein Client-Gerät, mindestens einen Cloud-Server sowie Endgeräte umfassen kann, wobei die Endgeräte mindestens ein Simulations-Endgerät und mindestens ein autonomes Fahrzeug umfassen. Die Verfahren stützen sich auch auf die Fähigkeit, Informationen über die Testfahrten und deren Ergebnisse aufzuzeichnen.
Auch werden hiermit Verfahren und Algorithmen bereitgestellt, die es einem Entwicklungsingenieur ermöglichen, an einem Client-Gerät Arbeitsaufträge zu definieren und abzusenden, welche Konfigurationsanweisungen (was zu tun ist), Umfeldanweisungen (wo es zu tun ist), Betriebsanweisungen (wie es zu tun ist), Datenerfassungsanweisungen (welche Daten zu sammeln sind) und/oder Prüfbedingungs- und Berichtsanweisungen (Berichtsergebnisse) beinhalten können.
Auch werden hiermit Verfahren und Algorithmen bereitgestellt, um Arbeitsaufträge zu verarbeiten, die von verschiedenen Client-Geräten gesendet worden sind, wobei die Verarbeitung die Identifizierung der richtigen Endgeräte, die Planung der von geeigneten Endgeräten durchzuführenden Aufträge, das Einreihen von Aufträgen an die geeigneten Endgeräte und Rückmeldungen an das Client-Gerät umfassen kann. Die Verarbeitung kann auch eine Validierungsphase auf Basis einer Simulation vor dem tatsächlichen Betrieb eines autonomen Fahrzeugs umfassen, um sicherzustellen, dass die Betriebsprozedur valid bzw. plausibel ist. Die Verarbeitung kann von Cloud-Servern oder ähnlichen Geräten durchgeführt werden.
Auch werden hiermit Verfahren und Algorithmen bereitgestellt, um Endgeräte festzulegen, die eine Sammlung von XiL-Geräten und autonomen Fahrzeugen sind, die sich an geeigneten Orten auf der ganzen Welt befinden können und die zur Durchführung der Arbeitsaufträge in der Lage sind. Die XiL-Geräte können als vorbereitende Validierungsumgebung verwendet werden, um sicherzustellen, dass das autonome Fahrzeug korrekt betrieben werden wird. Dies kann durch Simulieren der Aufträge in einer virtuellen Umgebung, einer "Vehicle in the Loop"-Umgebung usw. geschehen. Das festgelegte autonome Fahrzeug muss in seiner Ausstattung zu den XiL-Geräten passen und muss sich an einem Ort befinden, wo der Test durchgeführt werden kann, z. B. in einer geeigneten Testeinrichtung.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

DE 19615008 A1 [0003]
AT 511131 A2 [0004]

Zitierte Nicht-Patentliteratur

Publikation Bock T., Maurer M., van Meel F., Müller T., "Vehicle in the Loop, Ein innovativer Ansatz zur Kopplung virtueller mit realer Erprobung" in ATZ 01/2008 Jahrgang 110, S. 2–8 [0002]

Claims

Verfahren zum Testen von Software für autonome Fahrzeuge mittels einer Loop- Simulation unter Einbindung von Hardware in Form von einem oder mehreren realen autonomen Fahrzeugen (4), welche zur Durchführung von autonomen Testfahrten in der realen Welt in der Lage sind, dadurch gekennzeichnet, dass auf einen von einem Benutzer gegebenen Arbeitsauftrag hin automatisch geprüft wird, welche unter mehreren realen autonomen Fahrzeugen (4), die zur Durchführung von autonomen Testfahrten auf weltweit verteilten Teststrecken (5a, 5b, 5c) in der realen Welt in der Lage sind, für einen oder mehrere in dem Arbeitsauftrag definierte Tests aktuell zur Verfügung stehen, und dass die Durchführung der Software-Tests und der Testfahrten automatisch geplant und koordiniert wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Durchführung der Testfahrten über ein globales Datenkommunikationsnetz geplant und koordiniert wird.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass ein Arbeitsauftrag Konfigurationsanweisungen, Umfeldanweisungen, Betriebsanweisungen, Datenerfassungsanweisungen und/oder Prüfbedingungs- und Berichtsanweisungen umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass auf einen von einem Benutzer gegebenen Arbeitsauftrag hin automatisch geeignete autonome Fahrzeuge und geeignete Teststrecken in verschiedenen Erprobungseinrichtungen auf verschiedenen Kontinenten identifiziert und gebucht werden, Software-Tests geplant werden, zu einer geplanten Zeit Software und Testanweisungen auf zu den Fahrzeugen (4) gehörende Simulations-Endgeräte (3) hochgeladen werden, während der Tests Daten von den Fahrzeugen (4) oder Simulations-Endgeräten (3) heruntergeladen werden und/oder nach Beendigung der Tests ein Testbericht generiert und an den Benutzer gesendet wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Simulations-Endgeräte (3) XiL- oder HiL-Geräte sind.
System zum Testen von Software für autonome Fahrzeuge, dadurch gekennzeichnet, dass das System wenigstens ein Client-Gerät zum Definieren und Senden von Arbeitsaufträgen, wenigstens ein Cloud-Server-Gerät zum Zuweisen, Organisieren und Einreihen der Arbeitsaufträge sowie Endgeräte umfasst, die mindestens ein Simulations-Endgerät und mindestens ein autonomes Fahrzeug, welches zur Durchführung von autonomen Testfahrten in der realen Welt in der Lage ist, aufweisen, wobei diese Geräte untereinander vernetzt und zur Durchführung des Verfahrens nach einem der vorhergehenden Ansprüche ausgebildet sind.