DE102022207563A1 - Techniken zum validieren oder verifizieren von closed-loop-testplattformen - Google Patents

Techniken zum validieren oder verifizieren von closed-loop-testplattformen Download PDF

Info

Publication number
DE102022207563A1
DE102022207563A1 DE102022207563.3A DE102022207563A DE102022207563A1 DE 102022207563 A1 DE102022207563 A1 DE 102022207563A1 DE 102022207563 A DE102022207563 A DE 102022207563A DE 102022207563 A1 DE102022207563 A1 DE 102022207563A1
Authority
DE
Germany
Prior art keywords
data
test platform
closed
loop test
input data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102022207563.3A
Other languages
English (en)
Inventor
Joachim Sohns
Patrick Weber
Philipp Glaser
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Priority to DE102022207563.3A priority Critical patent/DE102022207563A1/de
Priority to PCT/EP2023/069333 priority patent/WO2024022819A1/de
Publication of DE102022207563A1 publication Critical patent/DE102022207563A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B13/00Adaptive control systems, i.e. systems automatically adjusting themselves to have a performance which is optimum according to some preassigned criterion
    • G05B13/02Adaptive control systems, i.e. systems automatically adjusting themselves to have a performance which is optimum according to some preassigned criterion electric
    • G05B13/0265Adaptive control systems, i.e. systems automatically adjusting themselves to have a performance which is optimum according to some preassigned criterion electric the criterion being a learning criterion

Abstract

Ein allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein Verfahren zum Training eines Maschinen-Lern-Moduls zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zum Testen eines Systems. Das Verfahren umfasst Bereitstellen einer Mehrzahl von Datensätzen von zwei oder mehr Closed-Loop-Testplattformen, darunter mindestens eine Referenz-Testplattform. Jeder Datensatz enthält Eingangsdaten und zugehörige Ausgangsdaten eines getesteten Systems in einer jeweiligen Closed-Loop-Testplattform. Das Verfahren umfasst weiter Bestimmen von Ähnlichkeit von Abschnitten der Eingangsdaten für Paare der Mehrzahl von Datensätzen. Jedes Paar von Testdatensätzen enthält einen Datensatz einer Referenz-Testplattform. Das Verfahren umfasst weiterhin Bestimmen von Ähnlichkeiten von Abschnitten der Ausgangsdaten, die den Abschnitten von Eingangsdaten zugehörig sind und Trainieren eines Maschinen-Lern-Moduls auf eine Schätzung der Ähnlichkeit von Eingangsdaten und Ausgangsdaten eines Datensatzes einer zu validierenden oder zu verifizierenden Closed-Loop-Testplattform und der Datensätze der Mehrzahl von Datensätzen der mindestens einen Referenz-Testplattform als Funktion von Eingangsdaten und/oder Ausgangsdaten des Datensatzes der zu validierenden oder zu verifizierenden Closed-Loop-Testplattform unter Verwendung der bestimmten Ähnlichkeiten, um ein Maschinen-Lern-Modul zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zu erzeugen.

Description

  • Stand der Technik
  • Der Einsatz von virtuellen Testplattformen bei der Verifikation und Validierung von neuen Systemen (z.B. Systemen zum autonomen oder assistierten Fahren) hat enormes Potential und kann zur Verkürzung. des Validierungsprozesses beitragen. Insbesondere bei der Freigabe von autonomen Fahrfunktionen ab Level 3 (nach SAE-Definition) ist der Einsatz simulationsgestützter Testplattformen beinahe unverzichtbar. Der Begriff „Verifikation“ bezeichnet einen Vergleich des Verhaltens und/oder der Konfiguration eines Systems mit einer vorgegebenen Spezifikation. Üblicherweise erfolgt die Verifikation anhand von Testfällen, die von den Anforderungen („Requirements“) abgeleitet werden. Im Rahmen der Validierung wird überprüft, ob das System alle erforderlichen Sicherheitsziele erfüllt und alle nötigen Qualitätseigenschaften besitzt. Die Validierung geht über die Verifikation hinaus. Unter anderem werden bei der Validierung auch die Vollständigkeit der Anforderungen sowie die Gültigkeit von getroffenen Annahmen überprüft. Wenn im Rahmen der vorliegenden Offenbarung von „testen“ gesprochen wird, so ist damit die Überprüfung von Qualitätsanforderungen, Sicherheitszielen und weiteren Anforderungen an das System gemeint.
  • Durch eine virtuelle Validierung oder Verifizierung kann beispielsweise ein Umfang eines Testprogramms im Feld erheblich reduziert oder ein solches Testprogramm sogar vollständig vermieden werden (z.B. Testfahrten mit dem zu testenden System). Zusätzlich oder alternativ kann der Umfang und/oder eine Qualität eines Testprogramms erhöht werden, ohne dass dabei der Einsatz an Ressourcen steigt. Das kann beispielsweise dazu beitragen, potentielle Risiken durch seltene Ereignisse zu reduzieren. So kann bei Testfahren eine Testung der Reaktion des zu testenden Systems auf seltene Ereignisse schwierig sein. Um eine Mehrzahl bestimmter seltener Ereignisse in den Testfahrten zu beobachten, kann zum Beispiel eine prohibitive Menge an Testkilometern notwendig sein. In einer virtuellen Validierung oder Verifizierung können seltene Ereignisse durch ein passend gewähltes Szenario einfach erzeugt werden.
  • Die virtuelle Validierung oder Verifizierung bringt aber auch neue Probleme mit sich. Eine fundamentale Herausforderung stellt die Nachbildung einer Umgebung des zu testenden Systems oder auch des zu testenden Systems selbst in der virtuellen Umgebung dar (z.B. eine Simulation der Eingangssignale eines Systems für ein System eines Fahrzeugs). Dabei werden im Rahmen einer Modellbildung der Umgebung oder der Auswahl von Umgebungsdaten stets ein Eingangssignal der realen Umgebung des Systems durch ein simuliertes und/oder synthetisiertes Eingangssignal ersetzt. Das synthetisierte Eingangssignal kann auch auf Grundlage realer Daten erzeugt worden sein (z.B. Fehlerinjektion auf Basis realer Fehlerbilder). Hier stellt sich die Frage, ob relevante Merkmale oder Eigenschaften der realen Umgebungen verändert oder nicht dargestellt werden. Sowohl das Fehlen von relevanten Merkmalen als auch deren Veränderung kann dazu führen, dass ein zu testendes System im Rahmen der virtuellen Validierung oder Verifizierung nicht adäquat getestet wird. Das kann die Funktionalität und sogar die Betriebssicherheit des so getesteten Systems maßgeblich beeinflussen.
  • Diese Gefahr ist in besonderem Maße für „Closed-Loop-Testplattformen“ zur virtuellen Validierung oder Verifizierung ein Thema. In einer Closed-Loop-Testplattform wird ein zu testendes System mit Eingangsdaten (in der vorliegenden Offenbarung auch als „Eingangssignale“ bezeichnet) beschickt. Zudem werden Ausgangsdaten (in der vorliegenden Offenbarung auch als „Ausgangssignale“ bezeichnet) des zu testenden Systems zurückgespeist, um die Aktionen des zu testenden Systems in die Testumgebung zurückzuführen. Basierend darauf können dann die Eingangssignale angepasst werden, usw. Mittels Closed-Loop-Testplattformen kann damit das Verhalten eines zu testenden Systems getestet werden, wenn das System auf seine Umgebung zurückwirkt (und Rückkoppelschleifen entstehen). Für „Closed-Loop-Testplattformen“ sind die oben genannten Probleme in manchen Fällen noch kritischer, da in vielen Situationen komplexe Systeme mittels verschiedener Modelle abgebildet werden müssen, um z.B. die Eingangssignale eines zu testenden Systems zu bilden (und dessen Ausgangssignale zu prozessieren). Mit steigender Komplexität der Closed-Loop-Testplattformen steigt im Allgemeinen auch das Risiko, dass ein zu testendes System im Rahmen der virtuellen Validierung oder Verifizierung nicht adäquat getestet wird (z.B., weil gewisse Ereignisse in der Umgebung nicht oder nicht richtig simuliert werden). Zum Beispiel muss in einer Closed-Loop-Testplattform mit simulativer Nachbildung der Umgebung eines Systems das Auftreten in einer bestimmten Situation erwarteter Reaktionen des Systems nicht immer heißen, dass ein valider Test des Systems bezüglich der bestimmten Situation durchgeführt wurde. So kann es vorkommen, dass die simulative Nachbildung der Umgebung einen anderen Auslöser für die erwartete Reaktion enthält als in der realen Umgebung.
  • Um die Gefahr einer unzureichenden virtuellen Validierung oder Verifizierung und den damit einhergehenden Folgen (z.B. für die Betriebssicherheit des zu testenden Systems) zu reduzieren, sind daher wiederum Maßnahmen zur Validierung oder Verifizierung von Closed-Loop-Testplattformen notwendig. Die Techniken der vorliegenden Offenbarung nehmen sich dieser Aufgabe an.
  • Offenbarung der Erfindung
  • Ein erster allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein Verfahren zum Training eines Maschinen-Lern-Moduls zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zur Validierung oder Verifizierung eines Systems. Das Verfahren umfasst Bereitstellen einer Mehrzahl von Datensätzen von zwei oder mehr Closed-Loop-Testplattformen, darunter mindestens eine Referenz-Testplattform. Jeder Datensatz enthält Eingangsdaten und zugehörige Ausgangsdaten eines getesteten Systems in einer jeweiligen Closed-Loop-Testplattform. Das Verfahren umfasst weiter Bestimmen von Ähnlichkeit von Abschnitten der Eingangsdaten für Paare der Mehrzahl von Datensätzen. Jedes Paar von Datensätzen enthält einen Datensatz einer Referenz-Testplattform. Das Verfahren umfasst weiterhin Bestimmen von Ähnlichkeiten von Abschnitten der Ausgangsdaten, die den Abschnitten von Eingangsdaten zugehörig sind und Trainieren eines Maschinen-Lern-Moduls auf eine Schätzung der Ähnlichkeit von Eingangsdaten und Ausgangsdaten eines Datensatzes einer zu validierenden oder zu verifizierenden Closed-Loop-Testplattform und der Datensätze der Mehrzahl von Datensätzen der mindestens einen Referenz-Testplattform als Funktion von Eingangsdaten und/oder Ausgangsdaten des Datensatzes der zu validierenden oder zu verifizierenden Closed-Loop-Testplattform unter Verwendung der bestimmten Ähnlichkeiten, um ein Maschinen-Lern-Modul zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zu erzeugen.
  • Ein zweiter allgemeiner Aspekt der vorliegenden Offenbarung betrifft Verfahren zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zum Testen eines Systems. Das Verfahren umfasst Empfangen eines Datensatzes einer Closed-Loop-Testplattform zum Testen eines Systems, Einspeisen zumindest eines Teils des Datensatzes der Closed-Loop-Testplattform in ein Maschinen-Lern-Modul zum Validieren oder Verifizieren einer Closed-Loop-Testplattform. Das Maschinen-Lern-Modul ist auf eine Schätzung der Ähnlichkeit von Eingangsdaten und Ausgangsdaten eines Datensatzes einer zu validierenden oder zu verifizierenden Closed-Loop-Testplattform und Datensätzen von mindestens einer Referenz-Testplattform als Funktion von Eingangsdaten und/oder Ausgangsdaten des Datensatzes der zu validierenden oder zu verifizierenden Closed-Loop-Testplattform trainiert. Das Verfahren umfasst weiter Ausgeben einer oder mehrerer Schätzungen der Ähnlichkeit von Eingangsdaten und Ausgangsdaten eines Datensatzes einer zu validierenden oder zu verifizierenden Closed-Loop-Testplattform.
  • Ein dritter allgemeiner Aspekt der vorliegenden Offenbarung betrifft eine Recheneinheit, die dazu ausgelegt ist, die Verfahren gemäß der ersten oder zweiten allgemeinen Aspekte auszuführen.
  • Die Techniken gemäß der ersten bis dritten allgemeinen Aspekte der vorliegenden Offenbarung können in manchen Fällen einen oder mehrere der folgenden Vorteile haben.
  • Erstens kann mittels der Techniken der vorliegenden Offenbarung in manchen Fällen eine Validierung oder Verifizierung auf der Ebene eines (Gesamt-)Systems auch in Situationen erfolgen, in denen das zu testende System und/oder seine Umgebung komplex ist/sind und bspw. mittels einer Mehrzahl (möglicherweise einer großen Zahl) von (Unter-)Modellen simulativ dargestellt werden müssen. In manchen Ansätzen des Stands der Technik werden die verschiedenen (Unter-)Modelle separat validiert oder verifiziert. Das kann aufwändig sein. Zudem kann in manchen Fällen die Validierung oder Verifizierung nur in einem Open-Loop erfolgen, was wie oben beschrieben unter Umständen keine zuverlässige Aussage zum Verhalten des Systems im Feld (also in einem Closed-Loop) zulässt. Die Verwendung von Ähnlichkeiten der Eingangsdaten und Ausgangsdaten des (Gesamt-)Systems zur Beurteilung der Validität einer Closed-Loop-Testplattform ermöglicht z.B. die Erkennung, ob bestimmte Verhalten des Systems in bestimmten Betriebsszenarien ausreichend abgebildet und somit getestet werden. Die verwendeten Datensätze der Referenz-Testplattformen können adäquate Validierungen oder Verifizierungen repräsentieren. Damit kann eine Schätzung des Maschinen-Lern-Moduls bezüglich einer Ähnlichkeit der Eingangsdaten und Ausgangsdaten zu den Datensätzen der Referenz-Testplattformen in manchen Fällen eine belastbare Aussage darüber ermöglichen, ob einen zu validierende oder zu verifizierende Closed-Loop-Testplattform das Verhalten eines Systems adäquat testet. Insbesondere kann geschätzt werden, ob die zu validierende oder zu verifizierende Closed-Loop-Testplattform relevante Eingangsdaten testet und diese zu erwarteten Ausgangsdaten des zu testenden Systems führen. In manchen Techniken des Stands der Technik wird lediglich überprüft, ob z.B. bestimmte kritische Betriebssituationen in den Ausgangsdaten des zu testenden Systems vorkommen. Dann kann es jedoch passieren, dass bspw. in einer Closed-Loop-Testplattform, die eine Umgebung eines zu testenden Systems simuliert, ganz andere Eingangsdaten als im Feld zu den kritischen Betriebssituationen in den Ausgangsdaten des zu testenden Systems führen. Auch das kann bedeuten, dass die Closed-Loop-Testplattform gewisse Verhalten des zu testenden Systems nicht adäquat validiert oder verifiziert.
  • Zweitens lassen sich die Techniken der vorliegenden Offenbarung in manchen Fällen auch dann anwenden, wenn die Daten verschiedener Testplattformen sich unterscheiden (z.B. nicht exakt gleiche Betriebsszenarien simuliert / gefahren wurden oder nicht alle relevanten Bedingungen in der Simulation nachgestellt wurden). Beispielsweise können auch Daten eines Dauerlaufs verwendet werden (z.B. Daten, die in Systemen im Feld aufgenommen wurden). Das kann den Aufwand zur Validierung oder Verifizierung von Testplattformen in manchen Fällen verringern, da ein breiteres Spektrum an Daten zur Validierung oder Verifizierung zur Verfügung steht (z.B. können nach Änderungen in Testprotokollen vorher erhobene Daten weiterverwendet werden oder auch Daten, die gar nicht im Rahmen eines Tests erhoben wurden). Auch können Testplattformen verschiedener Hersteller in manchen Situationen (einfacher) verglichen werden. Der Einsatz eines Maschinen-Lern-Moduls, das auf die Schätzung der Ähnlichkeit von Eingangsdaten und Ausgangsdaten eines Datensatzes einer zu validierenden oder zu verifizierenden Closed-Loop-Testplattform und Datensätzen von Referenz-Testplattformen trainiert ist, kann eine zuverlässige Validierung oder Verifizierung auch in den oben genannten Fällen ermöglichen.
  • Drittens können die Techniken der vorliegenden Offenbarung den Aufwand zur Durchführung der Validierung oder Verifizierung (z.B. einer Simulation) in manchen Fällen verringern. Die Eingangs- und Ausgangsdaten werden abschnittsweise verglichen, wobei nur ein Teil der Eingangs- und Ausgangsdaten je nach untersuchtem Betriebsszenario in Betracht gezogen wird. Zudem können die Abschnitte in manchen Fällen mittels Techniken zur Reduktion ihrer Dimensionalität kompakt dargestellt werden. Beides kann sowohl das Training als auch die Anwendung der Maschinen-Lern-Module effizienter (z.B. in Bezug auf Speicherplatz und/oder Rechenaufwand) gestalten.
  • Viertens können die Techniken der vorliegenden Offenbarung verwendet werden, um Betriebsszenarios oder Parameterbereiche zu identifizieren, für welche eine Closed-Loop-Testplattform noch nicht hinreichend validiert oder verifiziert wurde. Treten in dem Datensatz der Closed-Loop-Testplattform Daten auf, denen kein geeignetes Datum der Referenz-Testplattform zugeordnet werden kann, so ist dies ein Hinweis darauf, dass für die Closed-Loop-Testplattform oder darin enthaltene Teilmodelle weitere Daten zur Validierung erhoben werden müssen.
  • Einige Begriffe werden in der vorliegenden Offenbarung wie folgt benutzt:
    • Eine „Closed-Loop-Testplattform“ (auf Deutsch frei übersetzt als „Testplattform mit Rückkopplung“) ist jedes System, das eine Testumgebung für ein zu testendes System bildet, wobei das zu testende System mit Eingangsdaten beschickt wird und zudem Ausgangsdaten des zu testenden Systems in die Testumgebung zurückgespeist werden (und diese beeinflussen können). In anderen Worten bildet die „Closed-Loop-Testplattform“ eine Rückkoppel-Schleife (und eignet sich daher für die Validierung oder Verifizierung von Systemen oder Funktionen von Systemen, in denen Rückkopplungen im Systemverhalten eine Rolle spielen - was auf eine große Anzahl von Systemen zutrifft). In einer „Closed-Loop-Testplattform“ wird zwischen dem zu testenden System (in der vorliegenden Offenbarung, so nicht explizit anders beschrieben, ein Teil der Closed-Loop-Testplattform) und der Umgebung des zu testenden Systems unterschieden. In manchen Fällen kann eine Closed-Loop-Testplattform sowohl das zu validierende oder zu verifizierende System als auch seine Umgebung simulieren. In anderen Beispielen kann ein reales zu validierendes oder zu verifizierendes System in die Closed-Loop-Testplattform eingefügt werden (der Begriff „real“ wird hier im Gegensatz zu dem Begriff „simuliert“ benutzt - das reale System ist später in dieser Form auch im Einsatz, ein simuliertes System bildet ein reales System nach; eine reale Umgebung ist die Umgebung im Feld oder in der Anwendung). Das zu testende System kann jede erdenkliche Form annehmen. Z.B. kann das zu testende System ein Hardware-System, ein Software-System oder ein System mit Hardware- und Software-Komponenten sein. In der vorliegenden Offenbarung ist auch ein zu testendes System im Feld oder auf einem Teststand eine Closed-Loop-Testplattform (z.B. ein Testfahrzeug, dass ein zu testendes System enthält - die Testumgebung kann hier eine reale Umgebung des zu testenden Systems im Anwendungsfall sein).
  • Als „Eingangsdaten“ werden alle Daten bezeichnet, die in einer Closed-Loop-Testplattform an das zu testende System übermittelt werden (z.B. um eine Umgebung des zu testenden Systems nachzubilden oder aus einer realen Umgebung des zu testenden Systems). Die Eingangsdaten können mittels Modellen oder anderweitig simulierte oder synthetisierte Daten und/oder reale Daten umfassen (die in Echtzeit aufgenommen/erzeugt oder aus einer Datenbank abgerufen werden können und/oder mittels einer oder mehrerer Bearbeitungsschritte verändert sein können). Zum Beispiel können die Eingangsdaten reale Daten umfassen, die in einer gewissen Weise manipuliert sind. In manchen Fällen können die Eingangsdaten Zeitschriebe umfassen. Die Eingangssignale können aber auch jedes erdenkliche andere Format haben.
  • Als „Ausgangsdaten“ werden alle Daten bezeichnet, die in der Closed-Loop-Testplattform aus dem zu testenden System ausgegeben werden oder bezüglich des zu testenden Systems erfasst oder abgeleitet werden (z.B. von einem Agenten, der ein Verhalten des zu testenden Systems überwacht). Die Ausgangsdaten können zumindest teilweise wieder in die Umgebung der Closed-Loop-Testplattform zurückgespeist werden und/oder zu Überwachungszwecken bereitgestellt werden.
  • Die Begriffe „Umgebung“ oder „Testumgebung“ bezeichnen den Kontext, in den ein zu testendes System eingebettet ist (d.h. im avisierten Anwendungsfall). Die Umgebung kann die Eingangsdaten des zu testenden Systems erzeugen. Zudem können die Ausgangsdaten des zu testenden Systems (zumindest teilweise) auf die Umgebung zurückwirken. Die Umgebung kann weitere Systeme (z.B. weitere Systeme, mit denen das zu testende System im Einsatz verbunden ist) enthalten und/oder Objekte eines Umfelds, in dem das zu testende System in dem avisierten Anwendungsfall operiert. Die Umgebung (bzw. das zu testende System) definiert eine oder mehrere Schnittstellen, über die Daten von der Umgebung an das System übertragen werden (oder andersherum). In manchen Closed-Loop-Testplattform wird die Umgebung simuliert. Dementsprechend kann die Umgebung simulativ so nachgebildet sein, dass die an das System im Anwendungsfall übergebenen Daten so nachgebildet werden, dass eine Funktionalität des Systems getestet werden kann.
  • Ein „System“ kann jede Vorrichtung oder Gruppe von Vorrichtungen sein, die für einen bestimmten Zweck ausgelegt ist, z.B. eine oder mehrere Regel-, Steuer-, Kommunikations- und/oder Überwachungsaufgaben. Ein System kann eine Komponente eines übergeordneten (weiteren) Systems sein. Ein System kann eine Software sein. In anderen Beispielen kann ein System eine Hardware-Komponente sein (in manchen Beispielen mit zugehöriger Software). Zum Beispiel kann ein System ein embedded System (auf Deutsch „eingebettetes System“) sein. In manchen Beispielen kann das System ein Fahrzeug oder ein Modul für ein Fahrzeug (z.B. für ein Kraftfahrzeug) sein. In anderen Beispielen kann das System ein Roboter oder ein Modul für einen Roboter sein. In wieder anderen Beispielen kann das System eine Industrieanlage oder -maschine oder ein Modul für eine Industrieanlage oder -maschine sein.. In wieder anderen Beispielen kann das System ein Werkzeug oder ein Modul für ein Werkzeug sein.
  • Ein „Maschinen-Lern-Modul“ ist gemäß der vorliegenden Offenbarung jedes Hardware- und/oder Softwaremodul, das mittels maschinellen Lernens für eine Aufgabe trainierbar/trainiert ist. Das Maschinen-Lern-Modul weist dazu Parameter auf, die im Rahmen eines Trainings mit einem Trainings-Datensatz so verändert werden, dass in Antwort auf bestimmte Eingangsdaten gewünschte Ausgangsdaten erzeugt werden. Im günstigen Fall prozessiert das so trainierte Maschinen-Lern-Modul auch unbekannte Eingangsdaten (d.h. solche, die nicht in den Trainings-Datensatz enthalten sind) in einer gewünschten Weise. Ein Maschinen-Lern-Modul kann ein oder mehrere künstliche neuronale Netzwerke umfassen, ist aber nicht auf diese Topologie beschränkt. Ein Maschinen-Lern-Modul kann in jeder geeigneten Weise implementiert sein. Zum Beispiel kann ein Maschinen-Lern-Modul ein Software-Modul sein (d.h. die Funktionalität ist in Software definiert, die auf einer unspezifischen Recheneinheit ausgeführt werden kann). In anderen Beispielen kann das Maschinen-Lern-Modul eine Hardware-Modul sein (d.h., die Funktionalität des Maschinen-Lern-Moduls ist in Hardware definiert). In wieder anderen Beispielen kann die Funktionalität des Maschinen-Lern-Moduls in Software und in Hardware definiert sein.
  • Ein „Fahrzeug“ ist in der vorliegenden Offenbarung jede Vorrichtung zum Transport von Passagieren (einschließlich Fahrern) und/oder Gütern. Ein Fahrzeug kann zumindest teilweise autonom oder assistiert sein. Ein Fahrzeug kann ein Kraftfahrzeug, aber auch jedes andere Landfahrzeug sein. Auch schwimmende, tauchende und/oder fliegende Vorrichtungen können Fahrzeuge gemäß der vorliegenden Offenbarung sein.
  • Kurzbeschreibung der Figuren
    • 1 zeigt ein Flussdiagramm eines Verfahrens zum Training eines Maschinen-Lern-Moduls zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zum Testen eines Systems gemäß der vorliegenden Offenbarung.
    • 2 illustriert schematisch die Verfahren zum Training der vorliegenden Offenbarung.
    • 3 illustriert schematisch ein beispielhaftes Verfahren zum Training eines Maschinen-Lern-Moduls der vorliegenden Offenbarung.
    • 4 zeigt schematisch eine Closed-Loop-Testplattform.
    • 5 zeigt ein Flussdiagramm eines Verfahrens zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zum Testen eines Systems gemäß der vorliegenden Offenbarung.
    • 6 illustriert schematisch ein beispielhaftes Verfahren zum Validieren oder Verifizieren einer Closed-Loop-Testplattform der vorliegenden Offenbarung.
    • 7 zeigt eine beispielhafte Ausgabe eines Verfahrens zum Validieren oder Verifizieren einer Closed-Loop-Testplattform der vorliegenden Offenbarung.
    • 8 zeigt eine weitere beispielhafte Ausgabe eines Verfahrens zum Validieren oder Verifizieren einer Closed-Loop-Testplattform der vorliegenden Offenbarung.
  • Detaillierte Beschreibung
  • Zunächst werden in Bezug auf 1 bis 4 die Techniken zum Trainieren eines Maschinen-Lern-Moduls zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zum Testen eines Systems gemäß der vorliegenden Offenbarung erläutert. Im Folgenden werden anhand 5 bis 8 die Techniken zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zum Testen eines Systems gemäß der vorliegenden Offenbarung diskutiert (d.h., die Anwendung des trainierten Maschinen-Lern-Moduls).
  • 1 zeigt ein Flussdiagramm eines Verfahrens 100 zum Training eines Maschinen-Lern-Moduls zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zum Testen eines Systems gemäß der vorliegenden Offenbarung. 2 illustriert schematisch die Verfahren zum Training der vorliegenden Offenbarung.
  • Das Verfahren zum Training eines Maschinen-Lern-Moduls zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zur Validierung oder Verifizierung eines Systems umfasst Bereitstellen 101 einer Mehrzahl von Datensätzen 11 - 14 von zwei oder mehr Closed-Loop-Testplattformen 20, 22. Unter den Closed-Loop-Testplattformen ist mindestens eine Referenz-Testplattform 22 (in der vorliegenden Offenbarung wird der Begriff „Referenz-Testplattform“ als Abkürzung für den Begriff „Referenz-Closed-Loop-Testplattform“ verwendet). Die Referenz-Testplattform 22 bzw. deren Datensätze 13, 14 werden im Rahmen des Trainings als Bezugspunkte für Schätzungen der Ähnlichkeiten verwendet. In anderen Worten wird/ist das Maschinen-Lern-Modul darauf trainiert, zu schätzen wir ähnlich die Eingangs- und Ausgangsdaten der zu validierenden oder zu verifizierenden Closed-Loop-Testplattformen den Eingangs- und Ausgangsdaten der Referenz-Testplattform(en) 22 sind. Referenz-Testplattform(en) können in manchen Beispielen Closed-Loop-Testplattformen, die bereits validiert oder verifiziert wurden oder für die aus sonstigen Gründen ein Vertrauen besteht, dass sie das zu testende System adäquat getestet haben.
  • Jeder Datensatz 11- 14 enthält Eingangsdaten und zugehörige Ausgangsdaten eines getesteten Systems in einer jeweiligen Closed-Loop-Testplattform 20, 22 (nicht in 1 und 2 aufgeschlüsselt). Das Bereitstellen kann jedwede Operation umfassen, mit der die Mehrzahl von Datensätzen 11-14 für die nachfolgende Verarbeitung zugänglich gemacht werden.
  • Ein Datensatz 11-14 kann jedwede Daten umfassen, die beim Betrieb der Closed-Loop-Testplattform mit dem zu testenden System anfallen. Zum Beispiel kann ein Datensatz 11-14 Daten umfassen, die in einem bestimmten Zeitintervall beim Betrieb der Closed-Loop-Testplattform mit dem zu testenden System anfallen. Wie bereits erwähnt ist auch ein System im Feld eine Closed-Loop-Testplattform gemäß der vorliegenden Offenbarung. Daher kann ein Datensatz 11-14 auch Daten, die beim Betrieb des Systems in der Anwendung und/oder im Feld anfallen, umfassen (auch wenn das System in diesem Fall nicht in einem engeren Sinne getestet werden mag).
  • Ein Datensatz 11-14 kann Daten für einen oder mehrere Testläufe einer Closed-Loop-Testplattform mit dem zu testenden System umfassen. Ein Testlauf kann dabei in manchen Beispielen ein bestimmtes Betriebsszenario des zu testenden Systems und/oder eine bestimmte Betriebssituation (z.B. ein Betriebszustand) des zu testenden Systems betreffen (z.B. kann der Testlauf das Betriebsszenario oder die Betriebssituation nachbilden). Die Eingangsdaten und Ausgangsdaten können in diesem Fall Daten sein, die während des bestimmten Betriebsszenarios und/oder der bestimmten Betriebssituation des betreffenden Testlaufs angefallen sind (dazu unten mehr). In anderen Beispielen kann ein Datensatz aber auch aufgenommen werden, ohne dass ein bestimmtes Betriebsszenario des zu testenden Systems und/oder eine bestimmte Betriebssituation des zu testenden Systems nachgebildet werden. Zum Beispiel kann der Datensatz 11-14 Daten aus einem Dauerlauf einer Closed-Loop-Testplattform mit dem zu testenden System anfallen.
  • Ein Betriebsszenario oder eine Betriebssituation kann in der vorliegenden Offenbarung jede im Betrieb des zu testenden Systems auftretende Konstellation oder jeder im Betrieb des zu testenden Systems auftretende Zustand sein (bspw. gekennzeichnet durch bestimmte Werte von Betriebsparametern des zu testenden Systems oder von Parametern seiner Umgebung). Zum Beispiel kann ein Betriebsszenario oder eine Betriebssituation bestimmte Umgebungsbedingungen bzw. Umgebungs-Konfigurationen des Systems betreffen (z.B. eine Fahrt in bestimmten Umgebungsbedingungen bzw. Umgebungs-Konfigurationen). Zusätzlich oder alternativ kann ein Betriebsszenario oder eine Betriebssituation eine Verletzung von Sicherheitszielen umfassen. Weiter zusätzlich oder alternativ kann ein Betriebsszenario oder eine Betriebssituation einen kritischen Zustand des zu testenden Systems oder einen Fehlerzustand des zu testenden Systems betreffen.
  • Die Eingangsdaten können alle Daten umfassen, die im Betrieb der entsprechenden Closed-Loop-Testplattform dem zu testenden System zugeführt werden. Je nach Closed-Loop-Testplattform und/oder zu testenden System und/oder Art des Betriebs (z.B. ein bestimmter Testlauf oder eine Dauerlauf) können die Eingangsdaten verschieden aufgebaut und/oder formatiert sein. In manchen Beispielen umfassen die Eingangsdaten diejenigen Signale, die das zu testende System im Betrieb (z.B. während eines bestimmtes Testlaufs oder eines Dauerlaufs) aus der Umgebung bezieht (z.B. Sensorsignale oder Ausgangssignale anderer Systeme, die dem zu testenden System vorgelagert sind und/oder mit dem zu testenden System kommunizieren). Diese Signale werden in der vorliegenden Offenbarung auch als Eingangssignale bezeichnet. In manchen Beispielen können die Eingangsdaten zumindest teilweise einen oder mehrere Zeitschriebe umfassen (wie in 2 gezeigt). Die Zeitschriebe können einen oder mehrere Parameter oder Größen über der Zeit abbilden (d.h., eindimensional oder mehrdimensional sein). Zeitschriebe können auch den zeitlichen Verlauf von komplexen Datenstrukturen abbilden (z.B. Objektlisten oder Bilder).
  • Die Ausgangsdaten können alle Daten umfassen, die im Rahmen des Betriebs der entsprechenden Closed-Loop-Testplattform (z.B. während eines bestimmtes Testlaufs oder eines Dauerlaufs) von dem zu testenden System ausgegeben werden. Diese Ausgangsdaten können in manchen Beispielen Daten umfassen, die in die Closed-Loop-Testplattform zurückgespeist werden (z.B. im Rahmen eines Testlaufes oder im Dauerlauf). Zusätzlich oder alternativ können die Ausgangsdaten Daten umfassen, die zum Zwecke der Überwachung des zu testenden Systems aufgenommen werden (z.B. die ein Verhalten des zu testenden Systems charakterisieren). Die Ausgangsdaten werden in der vorliegenden Offenbarung auch als Ausgangssignale bezeichnet. Wie auch die Eingangsdaten können die Ausgangsdaten je nach Closed-Loop-Testplattform und/oder zu testenden System und/oder Art des Betriebs (z.B. ein bestimmter Testlauf oder eine Dauerlauf) verschieden aufgebaut und/oder formatiert sein. In manchen Beispielen können die Ausgangsdaten zumindest teilweise einen oder mehrere Zeitschriebe umfassen. Die Zeitschriebe können einen oder mehrere Parameter oder Größen über der Zeit abbilden (d.h., eindimensional oder mehrdimensional sein).
  • Ausgangsdaten können den Eingangsdaten zugehörig sein, wenn sie im gleichen Betrieb (z.B. während eines bestimmtes Testlaufs oder eines Dauerlaufs) in zeitlichem Zusammenhang mit den Eingangsdaten anfallen (z.B. im Wesentlichen gleichzeitig oder mit einem nach oben begrenzten zeitlichen Versatz). In anderen Worten sind die zugehörigen Ausgangsdaten die Daten, die das System ausgibt oder die bei der Überwachung des Systems aufgenommen werden, wenn es bestimmte Eingangsdaten verarbeitet (z.B. im Rahmen eines Testlaufes oder im Dauerlauf).
  • Sowohl die Eingangsdaten als auch die Ausgangsdaten sind in manchen Beispielen verarbeitet (z.B. gefiltert oder in ein anderes Format weiterverarbeitet). Es ist also nicht notwendig (aber möglich), dass die Eingangs- und/oder Ausgangsdaten in der Form verarbeitet werden, in der sie in der Closed-Loop-Testplattform anfallen. In anderen Beispielen werden die Eingangs- und/oder Ausgangsdaten aus den Daten abgeleitet, in der sie in der Closed-Loop-Testplattform anfallen. In manchen Beispielen umfassen die Eingangsdaten und/oder Ausgangsdaten sämtliche Daten, die in der Closed-Loop-Testplattform anfallen (z.B. im Rahmen eines Testlaufes oder im Dauerlauf). In anderen Beispielen sind die Eingangsdaten und/oder die Ausgangsdaten nur eine Auswahl der Daten, die in der Closed-Loop-Testplattform anfallen (z.B. im Rahmen eines Testlaufes oder im Dauerlauf).
  • In manchen Beispielen kann das Verfahren auch das Erzeugen einer oder mehrerer der Mehrzahl von Datensätzen 11-14 umfassen (z.B. durch das Durchführen eines entsprechenden Testlaufs mittels der Closed-Loop-Testplattform 20, 22). Alternativ oder zusätzlich können einer oder mehrerer der Mehrzahl von Datensätzen 11-14 bereits vorliegen.
  • Das Verfahren umfasst zudem Bestimmen 102 der Ähnlichkeit von Abschnitten 31 -38 der Eingangsdaten für Paare der Mehrzahl von Datensätzen 11-14. Jedes Paar von Testdatensätzen enthält einen -Datensatz 13, 14 einer Referenz-Testplattform 22 (und dementsprechend einen zweiten Datensatz 11, 12 einer weiteren Closed-Loop-Testplattform 20). Aspekte zur Art der Ermittlung der Ähnlichkeiten (z.B. einsetzbare Ähnlichkeitsmetriken) werden weiter unten beschrieben. In anderen Worten wird z.B. für einen ersten Abschnitt 31 eines ersten Datensatzes 11 eine Ähnlichkeit mit einem zweiten Abschnitt 35 eines zweiten Datensatzes 13 (einer Referenz-Testplattform 22) bestimmt. Dieses Vorgehen kann dann für weiter (erste) und weitere (zweite) Abschnitte (z.B. mehr als 100, mehr als 1000 oder mehr als 100.000 Abschnitte) wiederholt werden. Zusätzlich oder alternativ können Abschnitte verschiedener Paare von Datensätzen verglichen werden.
  • Ein Abschnitt ist dabei ein Teil der Eingangsdaten und/oder ein Teil eines Daten-Elements der Eingangsdaten (d.h., weniger als die kompletten Eingangsdaten und/oder weniger als ein komplettes Daten-Element der Eingangsdaten). Wenn ein Daten-Element der Eingangsdaten (oder die gesamten Eingangsdaten) ein Zeitschrieb ist (sind), kann ein Abschnitt wiederum ein Zeitschrieb kürzerer Dauer als der gesamte Zeitschrieb sein (d.h., ein zeitlicher Abschnitt des Zeitschriebs). In manchen Beispielen kann eine Länge eines der zeitlichen Abschnitte innerhalb einer vorbestimmten (festen oder variablen) Dauer festgelegt sein (die von der Art des zu testenden Systems und/oder des Betriebs abhängen kann). Die vorbestimmte Dauer kann kürzer als 2 Minuten sein (z.B. kürzer als 30 Sekunden oder kürzer als 15 Sekunden). Zusätzlich oder alternativ kann die vorbestimmte Dauer länger als 2 Sekunden sein (z.B. länger als 5 Sekunden). Diese Dauern können insbesondere für Systeme, die in Fahrzeugen eingesetzt werden, von Interesse sein.
  • In anderen Beispielen kann ein Abschnitt gemäß einem anderen Kriterium als der Zeit einen Teil der Eingangsdaten und/oder einen Teil eines Datums der Eingangsdaten auszeichnen (z.B., ein Ausschnitt eines Bildes einer Serie von Bilddaten oder ein Ausschnitt einer Objektliste).
  • In manchen Beispielen umfasst das Verfahren Zerlegen der Eingangsdaten oder eines Datums der Eingangsdaten in mehrere Abschnitte 31-38 (wie in 2 anhand der Zeitschriebe gezeigt). Die Abschnitte können disjunkt sein (d.h., keine gemeinsamen Datenpunkte aufweisen) oder überlappen. Das oben beschriebene Ermitteln der ähnlichen Abschnitte kann für jeden der Abschnitte durchgeführt werden.
  • In manchen Beispielen kann das Verfahren Ermitteln von ähnlichen Abschnitten 31 - 38 von Eingangsdaten für Paare der Mehrzahl von Datensätzen 11-14 umfassen (wobei jedes Paar von Testdatensätzen einen Datensatz 13, 14 einer Referenz-Testplattform 22 umfasst). In manchen Beispielen werden die Ähnlichkeiten nur für die ermittelten ähnlichen Abschnitte bestimmt. In anderen Worten wird z.B. für einen ersten Abschnitt35 eines ersten Datensatzes (z.B. ein Testdaten-Satz 13, 14 einer Referenz-Testplattform 22) ein ähnlicher zweiter Abschnitt 31 eines zweiten Datensatzes 11, 12 ermittelt (und ggf. eine Ähnlichkeit bestimmt). Dieses Vorgehen kann dann für weiter (erste) und weitere (zweite) Abschnitte wiederholt werden. Wenn die Mehrzahl von Datensätzen mehr als zwei Datensätze enthält, kann das Ermitteln von ähnlichen Abschnitten (und ggf. das Bestimmen von Ähnlichkeiten) für mehrere (z.B. alle) Paare der Mehrzahl von Datensätzen durchgeführt werden. Für einen bestimmten (ersten) Abschnitt können auch mehrere ähnliche (zweite) Abschnitte ermittelt werden (und die entsprechenden Ähnlichkeiten bestimmt werden). Natürlich ist es auch möglich, dass für einen bestimmten Abschnitt auch kein ähnlicher anderer Abschnitt gefunden werden kann.
  • In manchen Beispielen können die Techniken der vorliegenden Offenbarung auch das Auffinden von Paaren von Abschnitten von Eingangsdaten zum Training eines Maschinen-Lernmoduls zur Validierung oder Verifizierung einer Closed-Loop-Testplattform umfassen (d.h. die Paare, die zum Bestimmen 102 von Ähnlichkeiten der Eingangsdaten verwendet werden). In anderen Worten kann zunächst in der Mehrzahl von Datensätzen nach Abschnitten von Eingangsdaten gesucht werden, die miteinander gepaart werden und deren Ähnlichkeit im Weiteren wie beschrieben bestimmt wird. Das Auffinden kann das vorstehende Zerlegen der Eingangsdaten und/oder das Ermitteln von ähnlichen Abschnitten umfassen.
  • Das Auffinden von Paaren von Abschnitten von Eingangsdaten kann Vergleichen mehrerer unterschiedlicher möglicher Kombinationen von Datenpaaren (d.h. zwei Datenätzen) aus der Mehrzahl von Datensätzen und Auswählen einer oder mehrere der unterschiedlichen Kombinationen von Datenpaaren gemäß einem vorbestimmten Kriterium umfassen. Die möglichen Kombinationen können durch Variationen verschiedener Parameter erzeugt werden. Zum Beispiel kann eine Länge der Abschnitte unterschiedlich gewählt werden. Zusätzlich oder alternativ können die Abschnitte eines Paares unterschiedlich zeitlich versetzt zueinander sein. In einem Beispiel können die Abschnitte der Datensätze eines Paares gefaltet werden (optional zusätzlich unter Benutzung einer variablen Länge der Abschnitte). In jedem Fall kann für die möglichen Kombinationen jeweils eine Ähnlichkeit bestimmt werden (z.B. mittels der in der vorliegenden Offenbarung beschriebenen Techniken) und Kombinationen mit der größten Ähnlichkeit und/oder einer Ähnlichkeit, die ein bestimmtes Maß übersteigt, ausgewählt werden.
  • Zusätzlich oder alternativ können in manchen Beispielen zum Auswählen der Paare die Abschnitte der Eingangsdaten in immer kleinere Einheiten zerlegt werden (z.B. Zeitabschnitte). Zunächst kann für eine erste Größe (z.B. ein erster Betriebsparameter) ein Abschnitt aus den Eingangsdaten identifiziert werden, in dem ein bestimmtes Kriterium erfüllt ist (beispielsweise annähernde Stationarität oder ähnliches Kriterium). Für den betreffenden Abschnitt wird eine zweite Größe (z.B. ein zweiter Betriebsparameter) betrachtet und der Abschnitt in kleinere Teile zerlegt, in denen jeweils wieder ein bestimmtes Kriterium für die zweite Größe erfüllt ist. In manchen Beispielen kann dieses Procedere für eine oder mehrere weitere Größen wiederholt werden. Dann liegt eine Mehrzahl von kürzeren Abschnitten (als der ursprüngliche Abschnitt) vor, in denen für alle behandelten Größen (erste Größe, zweite Größe usw.) jeweils bestimmte Kriterien erfüllen. Diese Abschnitte können sowohl in den Eingangsdaten der Datensätzen der mindestens einen Referenz-Testplattform als auch in den weiteren Datensätzen ermittelt werden und zu den Paaren zusammengestellt werden, deren Ähnlichkeiten wie in der vorliegenden Offenbarung beschrieben bestimmt wird.
  • Das Verfahren umfasst zudem Bestimmen 103 von Ähnlichkeiten 50 von Abschnitten der Ausgangsdaten, die den Abschnitten von Eingangsdaten 31 - 38 (d.h. den Abschnitten, für die Ähnlichkeiten bestimmt werden und/oder die ermittelt wurden) zugehörig sind (nicht in 2 gezeigt). Für jedes Paar von Abschnitten der Eingangsdaten 31-38 wird somit eine Ähnlichkeit der zugehörigen Abschnitte der Ausgangsdaten bestimmt. Wiederum werden die verwendbaren Ähnlichkeitsmetriken weiter unten beschreiben (für den Vergleich der Abschnitte der Eingangsdaten und den Vergleich der Abschnitte der Ausgangsdaten können unterschiedliche Ähnlichkeitsmetriken eingesetzt werden). Die Abschnitte der Ausgangsdaten können wie die Abschnitte der Eingangsdaten ausgestaltet sein. Z.B. können, wenn ein Datum der Ausgangsdaten (oder die gesamten Ausgangsdaten) ein Zeitschrieb ist, ein Abschnitt wiederum ein Zeitschrieb kürzerer Dauer als der gesamte Zeitschrieb sein (d.h., ein zeitlicher Abschnitt des Zeitschriebs). In manchen Beispielen kann eine Länge eines der zeitlichen Abschnitte innerhalb einer vorbestimmten (festen oder variablen) Dauer festgelegt sein (die von der Art des zu testenden Systems und/oder des Testlaufs abhängen kann). Die vorbestimmte Dauer kann - wie für die Abschnitte der Eingangsdaten - kürzer als 2 Minute sein (z.B. kürzer als 30 Sekunden oder kürzer als 15 Sekunden). Zusätzlich oder alternativ kann die vorbestimmte Dauer länger als 2 Sekunden sein (z.B. länger als 5 Sekunden). In manchen Beispielen können die Dauern der Abschnitte der Ausgangsdaten unterschiedlich sein von den Dauern der Abschnitte der Eingangsdaten. In manchen Beispielen sind Abschnitte der Ausgangsdaten und/oder Eingangsdaten ausgewählt, um Daten zu einer oder mehrere vorbestimmter Betriebssituationen und/oder Betriebsszenarios des Systems in der jeweiligen Closed-Loop-Testplattform zu enthalten.
  • Zum Beispiel können die ein oder mehreren vorbestimmten Betriebssituationen und/oder Betriebsszenarios kritische Betriebssituationen und/oder Betriebsszenarios des Systems sein (z.B. kritisch für die Funktionalität oder Betriebssicherheit des Systems). Die Kritikalität kann nach einem vorbestimmten Kritikalitätskriterium bestimmt das. Das vorbestimmte Kritikalitätskriterium kann je nach Art des zu testenden Systems unterschiedlich ausgestaltet sein. In manchen Beispielen kann ein Kritikalitätskriterium sein, dass eine Betriebssituation des Systems oder ein Zustand seiner Umgebung ein oder mehrere vorbestimmte Charakteristika aufweist (z.B. ein bestimmter Fehler ist aufgetreten, ein bestimmtes Ereignis (bspw. eine bestimmte Anomalie) ist in dem System oder seiner Umgebung aufgetreten, die Eingangssignale und/oder die Ausgangssignale des Systems erfüllen eine oder mehrere vorbestimmte Bedingungen).
  • Zum Beispiel können kritische Betriebssituationen und/oder Betriebsszenarios des Systems im Falle eines Systems für ein Fahrzeug kritische Fahrsituationen und/oder Fahrszenarios sein. Diese können eines oder mehrere umfassen von Fahren unter besonderen Umgebungsbedingen (z.B. Lichtverhältnisse oder Wetterbedingungen), kritische Objekte oder Ereignisse in der Umgebung des Systems (fehlende oder falsche Fahrspurmarkierungen, verdeckte Objekte, scharfe Kurven) oder bestimmte Fahrmanöver (z.B. Fahren über einer bestimmten Geschwindigkeit). In manchen Beispielen können kritische Fahrsituationen und/oder Fahrszenarios ein oder mehrere kritische Fahrsituationen und/oder Fahrszenarios umfassen, die im Standard ISO/PAS 21448:2019 (Englischer Titel „Road vehicles - Safety of the intended functionality“) als „Triggering Events“ beschrieben sind.
  • Das Verfahren umfasst zudem Trainieren 104 eines Maschinen-Lern-Moduls auf eine Schätzung der Ähnlichkeit von Eingangsdaten und Ausgangsdaten eines Datensatzes einer zu validierenden oder zu verifizierenden Closed-Loop-Testplattform und der Datensätze 13, 14 der Mehrzahl von Datensätzen der mindestens einen Referenz-Testplattform 22 als Funktion von Eingangsdaten und/oder Ausgangsdaten des Datensatzes der zu validierenden oder zu verifizierenden Closed-Loop-Testplattform unter Verwendung der bestimmten Ähnlichkeiten 50, um ein Maschinen-Lern-Modul zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zu erzeugen. In anderen Worten ist das Ziel des Trainings, dass das Maschinen-Lern-Modul schätzt, wie ähnlich ein Testdaten-Satz (und damit die diesen erzeugende Closed-Loop-Testplattform) der für das Training verwendeten ein oder mehreren Datensätzen 13, 14 der mindestens einen Referenz-Testplattform 22 ist.
  • Dieses Schätzergebnis kann zum Validieren oder Verifizieren Closed-Loop-Testplattform (und/oder des darin enthaltenen Systems) verwendet werden. Wenn z.B. die Datensätze 13, 14 der mindestens einen Referenz-Testplattform 22 das Betriebsverhalten des zu testenden Systems adäquat validieren oder verifizieren, kann geschätzt werden, ob eine zu validierende oder zu verifizierende Closed-Loop-Testplattform ein ähnliches Verhalten in Bezug auf die Eingangsdaten und Ausgangsdaten zeigt wir die Datensätze 13, 14. Ist das der Fall, kann davon ausgegangen werden, dass auch die zu validierende oder zu verifizierende Closed-Loop-Testplattform das Betriebsverhalten des zu testenden Systems adäquat validiert oder verifiziert.
  • Weiter Aspekte des Trainings des Maschinen-Lern-Moduls werden nun in Bezug auf 3 erläutert. 3 illustriert schematisch ein beispielhaftes Verfahren zum Training eines Maschinen-Lern-Moduls 62 der vorliegenden Offenbarung. Das Maschinen-Lern-Modul kann 62 zumindest einen Teil der Ausgangsdaten und/oder der Eingangsdaten 61 für die Datensätze, die nicht mit der mindestens einen Referenz-Plattform erzeugt sind (in 3 die (erste) Closed-Loop-Testplattform 20), als Eingangsgröße erhalten und die Schätzung der Ähnlichkeit der der Eingangsdaten und Ausgangsdaten als Ausgangsgröße erzeugen. Im Rahmen des Trainings werden die bestimmten Ähnlichkeiten 50 als Ground Truth (d.h. die erwartete Ausgabegröße des Maschinen-Lern-Moduls) verwendet. Dabei kann eine mittels einer bestimmten Ähnlichkeitsmetrik ermittelte Ähnlichkeit direkt verwendet oder aber prozessiert werden. Zum Beispiel kann eine Ähnlichkeit normiert und/oder skaliert werden. In anderen Beispielen kann eine Ähnlichkeit in zwei oder mehr Klassen eingeteilt werden (z.B. binär in die Klassen „ähnlich“ oder „unähnlich“). Das Maschinen-Lern-Modul kann 62 kann also darauf trainiert werden, basierend auf dem zumindest einen Teil der Ausgabedaten und/oder der Eingabedaten 61 die Ähnlichkeiten 50 der Eingabedaten und Ausgabedaten zu schätzen. Das Training kann mittels jeder geeigneten Trainingsmethode für Maschinen-Lern-Module durchgeführt werden. Zum Beispiel kann eine Verlustfunktion (d.h., ein Unterschied zwischen den realen Ähnlichkeiten und der Ausgabe des Maschinen-Lern-Moduls 62) durch Anpassung der Parameter des Maschinen-Lern-Moduls schrittweise reduziert werden (z.B. durch Verwendung eines Backpropagation-Algorithmus und/oder eines Gradienten-Abstiegs-Algorithmus).
  • In manchen Beispielen erhält das Maschinen-Lern-Modul 62 nur einen Teil der Ausgabedaten und/oder Eingabedaten als Eingangsgrößen. In diesem Fall kann das Maschinen-Lern-Modul 62 somit darauf trainiert werden (und schließlich sein), eine Schätzung der Ähnlichkeit von Eingangsdaten und Ausgangsdaten basierend auf einem kleineren und/oder anderen Teil der Ausgabedaten und/oder Eingabedaten eines Datensatzes eines zu testenden Systems zu schätzen, als für die Bestimmung der Ähnlichkeiten im Rahmen des Trainings des Maschinen-Lern-Moduls 62 verwendet wurde (z.B. eine weitere Auswahl an Eingangsdaten und Ausgangsdaten wird für die Bestimmung der Ähnlichkeiten im Rahmen des Trainings des Maschinen-Lern-Moduls 62 verwendet). Zum Beispiel kann das Maschinen-Lern-Modul 62 darauf trainiert werden (und als Ergebnis dann trainiert sein), basierend auf nur einem Teil der Ausgangsdaten eines zu testenden Systems in einer Closed-Loop-Testplattform Ähnlichkeiten zwischen Eingangsdaten und Ausgangsdaten zu schätzen. In anderen Beispielen kann das Maschinen-Lern-Modul 62 darauf trainiert werden (und als Ergebnis dann trainiert sein), basierend auf nur einem Teil der Eingangsdaten eines zu testenden Systems in einer Closed-Loop-Testplattform Ähnlichkeiten zwischen Eingangsdaten und Ausgangsdaten zu schätzen.
  • Zusätzlich oder alternativ kann in manchen Beispielen der Teil der Eingangsdaten und/oder Ausgangsdaten 61 Informationen umfassen, die ein mit der jeweiligen Closed-Loop-Testplattformen 20, 22 erfasstes oder simuliertes Betriebsszenario eines in der Closed-Loop-Testplattform enthaltenen Systems oder eine mit der jeweiligen Closed-Loop-Testplattformen 20, 22 erfasste oder simulierte Betriebssituation eines in der Closed-Loop-Testplattform enthaltenen Systems charakterisieren. Zum Beispiel kann ein Abschnitt der Eingangsdaten ein Betriebsszenario oder eine Betriebssituation charakterisieren (z.B. ein Zeitschrieb während des Betriebsszenarios oder der Betriebssituation). Dieser Abschnitt kann eine Eingangsgröße des Maschinen-Lern-Moduls 62 im Anwendungsfall sein (für die das des Maschinen-Lern-Modul 62 die Ähnlichkeiten 50 schätzt). Zusätzlich oder alternativ kann ein Abschnitt der Ausgangsdaten ein Betriebsszenario oder eine Betriebssituation charakterisieren (z.B. ein Zeitschrieb während des Betriebsszenarios oder der Betriebssituation). Dieser Abschnitt kann ebenfalls eine Eingangsgröße des Maschinen-Lern-Moduls 62 im Anwendungsfall sein (für die das des Maschinen-Lern-Modul 62 die Ähnlichkeiten schätzt).
  • Das Maschinen-Lern-Modul 62 kann jede geeignete Struktur aufweisen, um auf die Schätzung der Ähnlichkeiten der Eingangsdaten und Ausgangsdaten trainiert werden zu können. In manchen Fällen kann das Maschinen-Lern-Modul 62 ein künstliches neuronales Netz enthalten (z.B. ein tiefes neuronales Netz und/oder ein faltendes neuronales Netz).
  • Das Maschinen-Lern-Modul 62 kann ausgelegt sein, eine erste Ähnlichkeit für die Eingangsdaten und eine zweite Ähnlichkeit für die Ausgangsdaten zu schätzen (z.B. eine Ähnlichkeit der Eingangsdaten und zugehörigen Ausgangsdaten der zu validierenden oder zu verifizierenden Closed-Loop-Testplattform und den entsprechenden Daten der mindestens einen Referenz-Testplattform). Die Ähnlichkeiten können von dem Maschinen-Lern-Modul 62 klassifiziert werden (d.h. das Maschinen-Lern-Modul 62 gibt die Ähnlichkeit für einen Datensatz einer zu validierenden oder zu verifizierenden Closed-Loop-Testplattforme in zwei oder mehreren Klassen aus, z.B. binär in den Klassen „ähnlich“ oder „unähnlich“). Das Maschinen-Lern-Modul kann auch eine probabilistische Einstufung in mehrere Klassen der Ähnlichkeit ausgeben. In diesen Beispielen ist das Maschinen-Lern-Modul 62 ein Klassifikator. In anderen Beispielen kann das Maschinen-Lern-Modul 62 eine Kennzahl oder andere Kenngröße für die Ähnlichkeit ausgeben (z.B. von 0% bis 100%). In diesen Beispielen ist das Maschinen-Lern-Modul 62 ein Regressor. In jedem Fall kann anhand der Ausgabe des Maschinen-Lern-Moduls 62 erkannt werden, ob ein Datensatz für eine Closed-Loop-Testplattform ein zu testendes System adäquat testet (d.h. in einer ähnlichen Weise wie die mindestens eine Referenz-Testplattform).
  • Wie vorstehend beschrieben, wird sowohl für die Abschnitte der Eingangsdaten als auch für die Abschnitte der Ausgangsdaten Ähnlichkeiten bestimmt werden. Diese Ermittlungen können in manchen Beispielen in einer der folgenden Weisen durchgeführt werden.
  • In manchen Beispielen kann die Bestimmung der Ähnlichkeiten der Abschnitte der Eingangsdaten Bestimmen eines Abstandes eines ersten Abschnitts der Eingangsdaten eines ersten Datensatzes des jeweiligen Paares mit den Eingangsdaten eines zweiten Abschnitts des zweiten Datensatzes des Paares umfassen. In anderen Worten wird mittels einer geeigneten Abstandsmetrik ein Abstand zwischen dem ersten Abschnitt der Eingangsdaten eines ersten Datensatzes des jeweiligen Paares und dem zweiten Abschnitt der Eingangsdaten des zweiten Datensatzes des Paares berechnet. Ein größerer Abstand bedeutet eine kleinere Ähnlichkeit (und umgekehrt). Die Abstandmetrik kann basierend auf dem Typ der verglichenen Eingangsdaten gewählt sein. Beispielhafte Abstandsmetriken umfassen einen euklidischen Abstand, einen Manhattan-Abstand oder einen Abstand einer höheren Vektornorm (für ein- oder mehrdimensionale Abschnitte von Eingangsdaten, die einen euklidischen Raum aufspannen). Andere Beispiele für Abstandsmetriken sind ein Hamming-Abstand oder eine Levenshtein Distanz (z.B. für Zeichenketten). In anderen Beispielen kann die Abstandsmetrik eine Abstandmetrik für Verteilungen umfassen (z.B. Abstandsmetriken für Wahrscheinlichkeitsverteilungen, bspw. eine earth mover's distance, EMD, oder ein Wassertstein-Abstand - z.B. für Punktwolken, die von einem Radar oder LIDAR detektiert werden).
  • In manchen Beispielen können die Abschnitte der Eingangsdaten direkt mit dem geeigneten Abstandsmaß verglichen werden. In anderen Beispielen können die Abschnitte einen oder mehrere Vorverarbeitungsstufen durchlaufen. Zum Beispiel kann das Bestimmen der Ähnlichkeiten Komprimieren der einzelnen Abschnitte und Vergleichen der komprimierten Abschnitte von Eingangsdaten umfassen. In manchen Beispielen kann das Komprimieren der einzelnen Abschnitte das Erzeugen eines für den jeweiligen Abschnitt charakteristischen Datums mit geringer Dimensionalität als der ursprüngliche Abschnitt umfassen. Zusätzlich oder alternativ kann das Komprimieren der einzelnen Abschnitte eine Durchführung eines oder mehrerer Verfahren zur Dimensionalitätsreduktion der einzelnen Abschnitte umfassen (z.B. Auswahl von den ein oder mehr wichtigsten Hauptkomponenten in einer Hauptkomponentenanalyse, weglassen von Least Significant Bits usw.). In manchen Beispielen kann ein Abschnitt eines skalaren oder vektoriellen Zeitschriebs durch ein einzelnes skalares oder vektorielles Datum repräsentiert werden (d.h., die Zeitdimension fällt weg). Zusätzlich oder alternativ kann ein vektorielles Datum durch ein vektorielles Datum niedrigerer Dimension oder ein skalares Datum repräsentiert werden (ein Vektor hat in der vorliegenden Offenbarung mindestens zwei Einträge). Eine Kompression und/oder Dimensionalitätsreduktion kann hilfreich sein, da gerade Eingangsdaten in vielen Closed-Loop-Testplattformen hochdimensional sein können.
  • Zusätzlich oder alternativ können die Abschnitte der Eingangsdaten normiert oder in anderer Weise vereinheitlich werden. In dieser Weise können Abschnitte von Eingangsdaten mit verschiedenen Formaten (z.B. Länge oder Dimensionalität) und/oder unterschiedlichen Wertebereichen verglichen werden. Die oben beschriebenen Verfahren zur Kompression und/oder Dimensionalitätsreduktion können ebenfalls in manchen Beispielen verwendet werden, um die die Abschnitte der Eingangsdaten zu vereinheitlichen. Z.B. können (verschieden lange oder dimensionale) Abschnitte jeweils durch ein Skalar repräsentiert werden. Diese Techniken können die Vergleichbarkeit von Abschnitten von Eingangsdaten verschiedener Closed-Loop-Testplattformen verbessert werden.
  • In den vorhergehenden Abschnitten wurden Verarbeitungsaspekte (insbesondere bezüglich der Bestimmung der Ähnlichkeiten) hauptsächlich für die Abschnitte der Eingangsdaten beschrieben. Die Techniken können jedoch ebenfalls oder alternativ für die Abschnitte der Ausgangsdaten angewandt werden. Zum Beispiel kann die Bestimmung der Ähnlichkeiten der Abschnitte der Ausgangsdaten Bestimmen eines Abstandes eines ersten Abschnitts der Ausgangsdaten eines ersten Datensatzes des jeweiligen Paares von einem zweiten Abschnitt des zweiten Datensatzes des Paares umfassen. In anderen Worten wird mittels einer geeigneten Abstandsmetrik ein Abstand zwischen dem ersten Abschnitt der Ausgangsdaten eines ersten Datensatzes des jeweiligen Paares und dem zweiten Abschnitt der Eingangsdaten des zweiten Datensatzes des Paares berechnet. Ein größerer Abstand bedeutet eine kleinere Ähnlichkeit (und umgekehrt). Die weiteren oben beschriebenen Techniken können für die Ausgangsdaten ebenfalls eingesetzt werden.
  • Die Closed-Loop-Testplattformen, deren Daten zum Trainieren des Maschinen-Lern-Moduls 62 verwendet werden, verschiedene Formen annehmen. 4 zeigt schematisch eine Closed-Loop-Testplattform 75.
  • Wie bereits beschrieben, kann die Closed-Loop-Testplattform 75 ein zu testendes System 71 und eine Umgebung 70 des zu testenden Systems umfassen. Die Umgebung 70 führt dem zu testenden System 71 Eingangsdaten 73 zu. Die Eingangsdaten 73 können simulativ erzeugt werden oder in anderer Weise synthetisiert werden (z.B. die Umgebung 70 wird durch eine Simulation nachgebildet). In anderen Beispielen können die Eingangsdaten 73 reale Daten aus der Umgebung des zu testenden Systems 71 sein (z.B. in einem Teststand oder während des Betriebs des zu testenden Systems 71 im Feld - in diesen Beispielen kann die Umgebung 70 zumindest teilweise die reale Umgebung des Systems oder eine Nachbildung derer durch Hardware umfassen). In wieder anderen Beispielen können Eingangsdaten 73 reale Daten umfassen, die mittels einer oder mehrerer Bearbeitungsschritte verändert sind (z.B. Fehlerinjektion auf Basis realer Fehlerbilder). Ausgangsdaten 74 des zu testenden Systems 71 können wiederum in die Umgebung 70 zurückgeführt werden (und dort neue Eingangsdaten 73 erzeugen), usw.
  • In manchen Beispielen kann eine Closed-Loop-Testplattform 75 eine Software-in-the-Loop-Testplattform sein. In diesem Fall ist das zu testende System 71 eine Software (d.h. das System wird durch eine Software gebildet). Die Software kann dabei in der Anwendung Teil eines übergeordneten Systems sein (z.B. einer Komponente, die die Software enthält und in der die Software eine vorbestimmte Funktion ausführt). In einer Software-in-the-Loop-Testplattform werden die Eingangsdaten 73 und die Ausgangsdaten 74 über eine Software-Schnittstelle zugeführt bzw. abgegriffen. Die Software wird während eines Testlaufs oder im Dauerlauf ausgeführt (auf einer geeigneten Recheneinheit), um den Betrieb in der Anwendung nachzustellen. Die Umgebung 71 kann simulativ nachgestellt werden und/oder durch reale Systeme.
  • In manchen Beispielen kann eine Closed-Loop-Testplattform 75 eine Model-in-the-Loop-Testplattform sein. In diesem Fall ist das zu testende System 71 ein Modell eines weiteren Systems sein (z.B. ein Modell eines Systems, das letztendlich in die einer Anwendung zum Einsatz kommen soll). In diesen Beispielen kann das technische System wiederum eine Software sein (d.h. eine Software, die das weitere System modelliert). In diesen Model-in-the-Loop-Testplattformen werden die Eingangsdaten 73 und die Ausgangsdaten 74 über eine Software-Schnittstelle zugeführt bzw. abgegriffen (wobei die Eingangsdaten an das jeweilige Modell angepasst sein). Das Modell wird während eines Testlaufs oder im Dauerlauf ausgeführt (auf einer geeigneten Recheneinheit), um den Betrieb in der Anwendung nachzustellen. Die Umgebung 71 kann simulativ nachgestellt werden und/oder durch reale Systeme.
  • In wieder anderen Beispielen kann eine Closed-Loop-Testplattform 75 eine Hardware-in-the-Loop-Plattform sein. In diesem Fall ist das zu testende System 71 eine Hardware-Komponente (die ihrerseits auch Software enthalten kann). Beispielsweise kann das zu testende System eine für eine Anwendung bestimmte Hardware-Komponente sein. In einer Hardware-in-the-Loop-Testplattform können die Eingangsdaten 73 und die Ausgangsdaten 74 über existierende Schnittstellen der Hardware-Komponente zugeführt / abgefragt werden. Die Umgebung 71 kann simulativ nachgestellt werden und/oder durch reale Systeme.
  • In wieder anderen Beispielen kann eine Closed-Loop-Testplattform 75 das zu testende System 71 im Feld oder auf einem Teststand umfassen. In diesem Fall ist kann das zu testende System 71 eine Hardware-Komponente (die ihrerseits auch Software enthalten kann) oder eine Software-Komponente sein. Beispielsweise kann das zu testende System eine für eine Anwendung bestimmte Hardware-Komponente oder Software-Komponente sein. Wiederum können die Eingangsdaten 73 und die Ausgangsdaten 74 über existierende Schnittstellen der Hardware-Komponente oder Software-Schnittstellen zugeführt / abgefragt fragen. Die Umgebung 71 ist in diesen Beispielen eine reale Umgebung des Systems im Feld oder auf einem Teststand.
  • Wie oben beschrieben wird das Maschinen-Lern-Modul 62 mittels einer Mehrzahl von Datensätzen trainiert, die jeweils mit unterschiedlichen Closed-Loop-Testplattformen 75 erzeugt sind. Dabei können die vorstehend beschriebenen Closed-Loop-Testplattformen in beliebiger Weise kombiniert werden. Insbesondere kann jeder Typ der vorstehend beschriebenen Closed-Loop-Testplattformen 75 eine Referenz-Testplattform sein.
  • In manchen Beispielen kann die mindestens eine Referenz-Testplattform eine Closed-Loop-Testplattform 75 eines ersten Typs enthalten und die andere(n) Closed-Loop-Testplattform(en) eine Closed-Loop-Testplattform 75 eines zweiten Typs enthalten.
  • Zusätzlich oder alternativ kann die mindestens eine Referenz-Testplattform eine Closed-Loop-Testplattform 75 umfassen, die das zu testende System 71 im Feld oder auf einem Teststand umfasst. In anderen Worten kann die Referenz-Testplattform das reale zu testende System enthalten. Das kann eine Qualität der Datensätze der Referenz-Testplattform sicherstellen (da z.B. Probleme durch simulatives Nachbilden des Systems und/oder seiner Umgebung reduziert werden können). Alternativ oderzusätzlich kann die mindestens eine Referenz-Testplattform aber auch eine andere der oben genannten Closed-Loop-Testplattformen 75 umfassen (z.B. eine Closed-Loop-Testplattform, in der die Umgebung und/oder das zu testende System mit einem höheren Aufwand simulative nachgestellt werden als in anderen zu validierenden oder zu verifizierenden Closed-Loop-Testplattformen und/oder eine Closed-Loop-Testplattform, deren Verhalten bereits validiert oder verifiziert wurde).
  • Wie weiter oben erklärt, können die Techniken der vorliegenden Offenbarung für jedwede Systeme, die in Closed-Loop-Testplattformen getestet werden, eingesetzt werden. In manchen Beispielen ist das zu testende System ein Fahrzeug oder ein Modul für ein Fahrzeug (z.B. für ein Kraftfahrzeug). Das System kann dabei zum Einbau in das Fahrzeug selbst konfiguriert sein und/oder zur Kommunikation mit dem Fahrzeug (z.B. in einem Backend oder einer Infrastruktur-Komponente, das/die eine Funktionalität für das Fahrzeug zur Verfügung stellt. In manchen Beispielen kann das System eine Funktionalität für das assistierte oder autonome Fahren eines Fahrzeugs bereitstellen.
  • Im Zusammenhang mit 1 bis 4 wurden im Wesentliche Aspekte des Trainierens eines Maschinen-Lern-Moduls zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zum Testen eines Systems beschrieben. In den folgenden Abschnitten werden Anwendungen einer trainierten Maschinen-Lern-Moduls zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zum Testen eines Systems genauer diskutiert.
  • 5 zeigt ein Flussdiagramm eines Verfahrens zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zum Testen eines Systems gemäß der vorliegenden Offenbarung. 6 illustriert schematisch ein beispielhaftes Verfahren zum Validieren oder Verifizieren einer Closed-Loop-Testplattform 81 der vorliegenden Offenbarung.
  • Das Verfahren umfasst Empfangen 501 eines Datensatzes 61a, 61b einer Closed-Loop-Testplattform 81 zum Testen eines Systems. Ziel des Verfahrens ist eine Validierung oder Verifizierung des Datensatzes 61a, 61b bzw. der Closed-Loop-Testplattform 81, mit der der Datensatz 61a, 61b erzeugt wurde. Der Datensatz 61a, 61b kann ebenso aufgebaut sein, wie die oben in Bezug auf das Training des Maschinen-Lern-Moduls beschriebenen Datensätze (z.B. der Datensatz enthält Eingangsdaten und zugehörige Ausgangsdaten wir oben erläutert). In manchen Beispielen kann der Datensatz nur Eingangsdaten oder nur Ausgangsdaten umfassen (z.B. nur ausgewählte Eingangsdaten oder Ausgangsdaten).
  • Wie weiter oben erklärt, können die Techniken der vorliegenden Offenbarung für jedwede Systeme, die in Closed-Loop-Testplattformen getestet werden, eingesetzt werden. In manchen Beispielen ist das zu testende System ein Fahrzeug oder ein Modul für ein Fahrzeug (z.B. für ein Kraftfahrzeug). Das System kann dabei zum Einbau in das Fahrzeug selbst konfiguriert sein und/oder zur Kommunikation mit dem Fahrzeug (z.B. in einem Backend oder einer Infrastruktur-Komponente, das/die eine Funktionalität für das Fahrzeug zur Verfügung stellt. In manchen Beispielen kann das System eine Funktionalität für das assistierte oder autonome Fahren eines Fahrzeugs bereitstellen.
  • Das Verfahren umfasst weiterhin Einspeisen 502 zumindest eines Teils des Datensatzes 61a, 61b der Closed-Loop-Testplattform 81 in ein Maschinen-Lern-Modul 83 zum Validieren oder Verifizieren einer Closed-Loop-Testplattform. Zum Beispiel kann der Teil des Testdatensatzes 61a, 61b Eingangsdaten und/oder Ausgangsdaten umfassen, die Informationen enthalten, die ein mit der Closed-Loop-Testplattform 81 erfasstes oder simuliertes Betriebsszenario eines in der Closed-Loop-Testplattform 81 enthaltenen Systems oder eine mit der Closed-Loop-Testplattformen 81 erfasste oder simulierte Betriebssituation eines in der Closed-Loop-Testplattform 81 enthaltenen Systems charakterisieren. Zum Beispiel kann der Teil der Eingangsdaten ein Betriebsszenario oder eine Betriebssituation charakterisieren (z.B. ein Zeitschrieb während des Betriebsszenarios oder der Betriebssituation).
  • Das Maschinen-Lern-Modul 83 ist auf eine Schätzung der Ähnlichkeit von Eingangsdaten und Ausgangsdaten eines Datensatzes einer zu validierenden oder zu verifizierenden Closed-Loop-Testplattform und Datensätzen mindestens einer Referenz-Testplattform als Funktion von Eingangsdaten und/oder Ausgangsdaten des Datensatzes der zu validierenden oder zu verifizierenden Closed-Loop-Testplattform unter Verwendung der bestimmten Ähnlichkeiten trainiert.
  • Das Verfahren umfasst zudem Ausgeben 503 einer oder mehrerer Schätzungen 40a, 40b der Ähnlichkeit von Eingangsdaten und Ausgangsdaten eines Datensatzes 61a, 61b der Closed-Loop-Testplattform zum Testen eines Systems 81 (d.h. der zu validierenden oder zu verifizierenden Closed-Loop-Testplattform) und den Datensätzen der mindestens einer Referenz-Testplattform mit dem Maschinen-Lern-Modul 83. In manchen Beispielen kann eine erste Ähnlichkeit für die Eingangsdaten und eine zweite Ähnlichkeit für die Ausgangsdaten ausgeben werden. Die Schätzungen 40a, 40b können, wie oben beschrieben, verschiedene Formen annehmen. Zum Beispiel kann eine binäre Information ausgegeben werden, ob die Eingangsdaten und die Ausgangdaten den zum Training verwendeten Datensätzen ähnlich sind, oder nicht. Alternativ (oder zusätzlich) kann eine Kennzahl oder andere Kenngröße für die Ähnlichkeit ausgeben werden.
  • In manchen Beispielen ist die Closed-Loop-Testplattform 81 zum Testen eines Systems eine Closed-Loop-Simulationsplattform, d.h., das Umfeld des zu testenden Systems, das zu testende System, oder beide werden mittels einer Simulation erzeugt. Zum Beispiel können Eingangsdaten, die in der Closed-Loop-Testplattform dem zu testenden System zugeführt werden, mittels einer Simulation erzeugt werden (z.B. durch eine Simulation anderer Systeme, die das zu testende System mit Eingangsdaten versorgen, einem Umfeld des zu testenden Systems, oder beiden). Zusätzlich oder alternativ können die Ausgangsdaten des zu testenden Systems zumindest teilweise in die Simulation zurückgespeist werden.
  • In manchen Beispielen umfasst das Verfahren Ausgeben mehrerer Schätzungen der Ähnlichkeit von Eingangsdaten und Ausgangsdaten des Datensatzes 61, 61b der Closed-Loop-Testplattform zum Testen eines Systems 81 (d.h. der zu validierenden oder zu verifizierenden Closed-Loop-Testplattform) und den Datensätzen der mindestens einer Referenz-Testplattform mit dem Maschinen-Lern-Modul 83. Die mehreren Schätzungen können Schätzungen der Ähnlichkeit für verschiedene Werte von Betriebsparameter des getesteten Systems und/oder verschiedenen Betriebsszenarien oder Betriebsituationen sein. Basierend auf diesen Informationen kann erkannt werden, ob eine zu validierende oder zu verifizierende Closed-Loop-Testplattform 81 bestimmte Bereiche adäquat testet (oder nicht).
  • Die Schätzungen der Ähnlichkeiten 40a, 40b können in jeder geeigneten Weise ausgegeben werden. In manchen Beispielen werden die einen oder mehreren Schätzungen der Ähnlichkeiten 40a, 40b Schätzungen in einer graphischen Benutzeroberfläche ausgegeben werden. In anderen Beispielen können die Schätzungen auch über andere Schnittstellen ausgegeben werden (in menschen- oder maschinelesbarer Form).
  • In Bezug auf 7 oder 8 werden nun weitere Aspekte der ausgebbaren Schätzungen der Ähnlichkeiten besprochen. 7 zeigt eine beispielhafte Ausgabe eines Verfahrens zum Validieren oder Verifizieren einer Closed-Loop-Testplattform der vorliegenden Offenbarung. 8 zeigt eine weitere beispielhafte Ausgabe eines Verfahrens zum Validieren oder Verifizieren einer Closed-Loop-Testplattform der vorliegenden Offenbarung.
  • In manchen Beispielen können die Schätzungen für verschiedene Punkte oder Bereiche eines Parameterraums ermittelt und ausgegeben werden. 7 und 8 zeigen beispielhaft einen zweidimensionalen Parameterraum (mit einer ersten Achse 96, die einen ersten Parameter aufträgt und einer zweiten Achse 97, die einen zweiten Parameter aufträgt). In anderen Beispielen kann der Parameterraum mehr als zwei Dimensionen haben. In wieder anderen Beispielen können Schätzungen für zwei oder mehr Betriebsszenarien und/oder Betriebssituationen des Systems ausgegeben werden.
  • Anhand der Schätzungen der Ähnlichkeiten können nun Bereiche 90 in dem Parameterraum ausgemacht werden, in denen die zu validierende oder zu verifizierende Closed-Loop-Testplattform adäquate Ergebnisse liefert (z.B. Eingangs- und Ausgangsdaten sind ähnlich zu den Eingangs- und Ausgangsdaten der Referenz-Testplattformen unter einem vorbestimmten Ähnlichkeitskriterium) und andere Bereiche 91, in denen die zu validierende oder zu verifizierende Closed-Loop-Testplattform keine adäquaten Ergebnisse liefert (z.B. Eingangs- und Ausgangsdaten sind nicht ähnlich zu den Eingangs- und Ausgangsdaten der Referenz-Testplattformen unter einem vorbestimmten Ähnlichkeitskriterium). Die Beurteilung kann automatisch erfolgen und an einen Nutzer ausgegeben werden (z.B. über eine graphische Benutzeroberfläche). In anderen Beispielen kann statt einer binären Einstufung („ähnlich“ oder „unähnlich“) eine probabilistische Einstufung erfolgen und/oder ein Wert für einen Ähnlichkeitsmetrik ausgeben werden.
  • 8 zeigt eine Ausgabe (z.B. über eine graphische Benutzeroberfläche), in der für eine Mehrzahl von Punkten eines Parameterraums Schätzungen der Ähnlichkeiten ausgeben werden. Für jeden Punkt kann jeweils eine (erste) Schätzung 94 der Ähnlichkeit der Eingangsdaten und eine (zweite) Schätzung 95 der Ähnlichkeit der Ausgangsdaten ausgegeben werden. Zusätzlich können Datenpunkte 92 oder Parameterbereiche kenntlich gemacht werden, für die Datensätze für Referenz-Testplattformen vorliegen.
  • Basierend auf der Ausgabe der Ähnlichkeiten können ein oder mehrere weitere Schritte vorgenommen werden (die in manchen Beispielen automatisiert ausgeführt werden können).
  • In manchen Beispielen können insbesondere Datensätze (z.B. für bestimmte Testläufe einer zu validierenden oder zu verifizierenden Closed-Loop-Testplattform), für die keine Daten einer Referenz-Testplattform (z.B. dem zu testenden System im Feld) vorliegen, auf Zuverlässigkeit geprüft werden. Das trainierte Maschinen-Lern-Modul kann in manchen Fällen auch für diese Datensätze eine belastbare Schätzung vornehmen, ob die Daten der zu validierenden oder zu verifizierenden Closed-Loop-Testplattform ausreichende Ähnlichkeit zu den zu erwarteten Daten haben.
  • Zusätzlich oder alternativ kann in manchen Beispielen anhand der einen oder mehreren Schätzungen 40a, 40b eine Abdeckung eines Parameterraums durch die zu validierende oder zu verifizierende Closed-Loop-Testplattform und/oder die mindestens eine Referenz-Testplattform bestimmt werden. Zum Beispiel können Bereiche identifiziert werden, zu denen noch keine Daten der Referenz-Testplattform vorliegen. Für diese Bereiche können zusätzliche Daten angefordert und/oder erhoben werden. Zum Beispiel können für die zu validierende oder zu verifizierende Closed-Loop-Testplattform und/oder die mindestens eine Referenz-Testplattform Daten angefordert und/oder erhoben werden, in denen bestimmte Betriebssituationen oder Betriebsszenarien behandelt werden (z.B. wenn es zu Abschnitten in den Datensätzen der Referenz-Testplattform keine ähnlichen Abschnitte der zu validierenden oder zu verifizierenden Closed-Loop-Testplattform gibt, oder umgekehrt)
  • Zusätzlich oder alternativ können gezielte neue Datensätze für die zu validierende oder zu verifizierende Closed-Loop-Testplattform angefordert (und erzeugt) werden, um eine Ähnlichkeit mit den Datensätzen der Referenz-Testplattform zu erhöhen (z.B. durch Fuzzing der Eingangsdaten).
  • Wenn eine Closed-Loop-Testplattform mit den Techniken der vorliegenden Offenbarung validiert oder verifiziert wurden ist, kann das darin enthaltene zu testende System freigegeben und im Weiteren verwendet werden (z.B. in einem Produkt oder in einer nachgelagerten Stufe einen Entwicklungsprozesses). Die vorliegende Offenbarung umfasst auch Einsetzen des in der Closed-Loop-Testplattform enthaltenen Systems.
  • In den vorhergehenden Abschnitten wurden die Techniken der vorliegenden Offenbarung meistens anhand der Verfahren der vorliegenden Offenbarung erläutert. Die Verfahren der vorliegenden Offenbarung können in manchen Beispielen automatisiert (z.B. Computer-implementiert) ausgeführt werden.
  • Die vorliegende Offenbarung betrifft auch eine Recheneinheit, die dazu ausgelegt ist, die Verfahren gemäß der vorliegenden Offenbarung auszuführen. Die Recheneinheit kann jede geeignete Form in Bezug auf ihre Hardware oder Software annehmen (z.B. eine Stand-Alone-Recheneinheit oder eine verteilte Recheneinheit, z.B. eine Recheneinheit in einer Cloud).
  • Die vorliegende Offenbarung betrifft auch ein Computer-Programm, das Instruktionen enthält, die, wenn sie auf einer Recheneinheit ausgeführt werden, die Recheneinheit dazu bringen, die Schritte der Verfahren der vorliegenden Offenbarung auszuführen.
  • Die vorliegende Offenbarung betrifft auch ein Computer-Programm-Produkt oder Signal, das die Computer-Programme der vorliegenden Offenbarung enthält.

Claims (17)

  1. Verfahren zum Training eines Maschinen-Lern-Moduls zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zur Validierung oder Verifizierung eines Systems, umfassend: Bereitstellen (101) von einer Mehrzahl von Datensätzen (20, 22) von zwei oder mehr Closed-Loop-Testplattformen, darunter mindestens eine Referenz-Testplattform, wobei jeder Datensatz (20, 22) Eingangsdaten und zugehörige Ausgangsdaten eines getesteten Systems in einer jeweiligen Closed-Loop-Testplattform enthält; Bestimmen (102) von Ähnlichkeiten (50) von Abschnitten der Eingangsdaten (31-38) für Paare der Mehrzahl von Datensätzen (20, 22), wobei jedes Paar von Datensätzen einen Datensatz einer der mindestens einen Referenz-Testplattformen enthält; Bestimmen (103) von Ähnlichkeiten (50) von Abschnitten der Ausgangsdaten, die den Abschnitten von Eingangsdaten (31-38) zugehörig sind; und Trainieren (104) eines Maschinen-Lern-Moduls auf eine Schätzung der Ähnlichkeit von Eingangsdaten und Ausgangsdaten eines Datensatzes einer zu validierenden oder zu verifizierenden Closed-Loop-Testplattform und der Datensätze der Mehrzahl von Datensätzen der mindestens einen Referenz-Testplattform als Funktion von Eingangsdaten und/oder Ausgangsdaten des Datensatzes der zu validierenden oder zu verifizierenden Closed-Loop-Testplattform unter Verwendung der bestimmten Ähnlichkeiten (50), um ein Maschinen-Lern-Modul zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zu erzeugen.
  2. Verfahren gemäß Anspruch 1, wobei das Maschinen-Lern-Modul nur einen Teil der Ausgangsdaten und/oder Eingangsdaten als Eingangsgröße erhält und die Schätzung der Ähnlichkeit der der Eingangsdaten und Ausgangsdaten als Ausgangsgröße erzeugt.
  3. Verfahren gemäß Anspruch 2, wobei der Teil der Eingangsdaten und/oder Ausgangsdaten Informationen umfasst, die ein mit der jeweiligen Closed-Loop-Testplattform erfasstes oder simuliertes Betriebsszenario oder eine mit der jeweiligen Closed-Loop-Testplattform erfasste oder simulierte Betriebssituation eines in der Closed-Loop-Testplattform enthaltenen Systems charakterisieren.
  4. Verfahren gemäß einem der vorangehenden Ansprüche 1 bis 3, wobei die Abschnitte der Ausgangsdaten und/oder Eingangsdaten (31-38) Abschnitte aus Zeitschrieben umfassen.
  5. Verfahren gemäß einem der vorangehenden Ansprüche 1 bis 4, wobei die Abschnitte der Ausgangsdaten und/oder Eingangsdaten (31-38) ausgewählt sind, um Daten zu einer oder mehrere vorbestimmter Betriebssituationen oder einem oder mehreren vorbestimmten Betriebsszenarios des zu testenden Systems in der jeweiligen Closed-Loop-Testplattform zu enthalten.
  6. Verfahren gemäß Anspruch 5, wobei die vorbestimmten Betriebssituationen oder Betriebsszenarios kritische Betriebssituationen oder Betriebsszenarios des Systems sind, optional wobei die kritischen Betriebssituationen oder Betriebsszenarios die Verletzung eines vorbestimmten Sicherheitsziels umfassen.
  7. Verfahren gemäß einem der Ansprüche 1 bis 6, wobei das Bestimmen der Ähnlichkeiten von Abschnitten der Eingangsdaten Bestimmen eines Abstandes eines ersten Abschnitts (31; 32; 33; 38) der Eingangsdaten eines ersten Datensatzes (20) des jeweiligen Paares und eines zweiten Abschnitts (34; 35; 36; 37) der Eingangsdaten des zweiten Datensatzes (22) des Paares umfasst.
  8. Verfahren gemäß einem der vorangehenden Ansprüche 1 bis 7, wobei das Bestimmen der Ähnlichkeiten von Abschnitten der Eingangsdaten (31-38) Komprimieren der einzelnen Abschnitte und Vergleichen der komprimierten Abschnitte von Eingangsdaten umfasst.
  9. Verfahren gemäß Anspruch 8, wobei Komprimieren der einzelnen Abschnitte eine Erzeugung eines für den jeweiligen Abschnitt (31 -38) charakteristischen Datums mit geringer Dimensionalität als der ursprüngliche Abschnitt umfasst.
  10. Verfahren gemäß einem der vorangehenden Ansprüche 1 bis 9, wobei das System ein Fahrzeug oder ein Modul zum Einsatz in einem Fahrzeug umfasst.
  11. Verfahren gemäß einem der vorangehenden Ansprüche 1 bis 10, wobei die mindestens eine Referenz-Testplattform mindestens eine Testplattform, die das System im Feld oder auf einem Teststand umfasst, umfasst.
  12. Verfahren zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zum Testen eines Systems, umfassend: Bereitstellen (501) eines Datensatzes einer Closed-Loop-Testplattform zum Testen eines Systems; Einspeisen (502) zumindest eines Teils des Datensatzes der Closed-Loop-Testplattform in ein Maschinen-Lern-Modul zum Validieren oder Verifizieren einer Closed-Loop-Testplattform, wobei das Maschinen-Lern-Moduls auf eine Schätzung der Ähnlichkeit von Eingangsdaten und Ausgangsdaten eines Datensatzes einer zu validierenden oder zu verifizierenden Closed-Loop-Testplattform und Datensätzen mindestens einer Referenz-Testplattform als Funktion von Eingangsdaten und/oder Ausgangsdaten des Datensatzes der zu validierenden oder zu verifizierenden Closed-Loop-Testplattform trainiert ist; und Ausgeben (503) einer oder mehrerer Schätzungen der Ähnlichkeit von Eingangsdaten und Ausgangsdaten des Datensatzes der Closed-Loop-Testplattform zum Testen eines Systems und den Datensätzen der mindestens einer Referenz-Testplattform mit dem Maschinen-Lern-Modul.
  13. Verfahren gemäß Anspruch 12, wobei die Closed-Loop-Testplattform zum Testen eines Systems eine Closed-Loop-Testplattform ist, die das zu testende System, die Umgebung des zu testenden Systems, oder beide, simuliert, ist/sind.
  14. Verfahren gemäß Anspruch 12 oder Anspruch 13, weiter umfassend: Ausgeben mehrerer Schätzungen der Ähnlichkeit von Eingangsdaten und Ausgangsdaten des Datensatzes der Closed-Loop-Testplattform zum Testen eines Systems und den Datensätzen der mindestens einer Referenz-Testplattform mit dem Maschinen-Lern-Modul, wobei die mehreren Schätzungen Schätzungen der Ähnlichkeit für verschiedene Werte von Betriebsparameter des getesteten Systems und/oder verschiedenen Betriebsszenarien sind.
  15. Recheneinheit, das dazu ausgelegt ist, die Verfahren gemäß einem der Ansprüche 1 bis 14 auszuführen.
  16. Computer-Programm, das Instruktionen enthält, die, wenn sie auf einer Recheneinheit ausgeführt werden, die Recheneinheit die Verfahren gemäß einem der Ansprüche 1 bis 14 ausführen lassen.
  17. Computer-Programm-Produkt oder Signal, das das Computer-Programm gemäß Anspruch 16 enthält.
DE102022207563.3A 2022-07-25 2022-07-25 Techniken zum validieren oder verifizieren von closed-loop-testplattformen Pending DE102022207563A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE102022207563.3A DE102022207563A1 (de) 2022-07-25 2022-07-25 Techniken zum validieren oder verifizieren von closed-loop-testplattformen
PCT/EP2023/069333 WO2024022819A1 (de) 2022-07-25 2023-07-12 Techniken zum validieren oder verifizieren von closed-loop-testplattformen

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102022207563.3A DE102022207563A1 (de) 2022-07-25 2022-07-25 Techniken zum validieren oder verifizieren von closed-loop-testplattformen

Publications (1)

Publication Number Publication Date
DE102022207563A1 true DE102022207563A1 (de) 2024-01-25

Family

ID=87312241

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102022207563.3A Pending DE102022207563A1 (de) 2022-07-25 2022-07-25 Techniken zum validieren oder verifizieren von closed-loop-testplattformen

Country Status (2)

Country Link
DE (1) DE102022207563A1 (de)
WO (1) WO2024022819A1 (de)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021100149A1 (de) * 2020-08-05 2022-02-10 Dspace Digital Signal Processing And Control Engineering Gmbh Computerimplementiertes Verfahren zum Bereitstellen eines Test-Verlaufs zu testender Verkehrsszenarien
WO2022042822A1 (en) * 2020-08-24 2022-03-03 Siemens Industry Software Netherlands B.V. Validating a software-driven system based on real-world scenarios

Also Published As

Publication number Publication date
WO2024022819A1 (de) 2024-02-01

Similar Documents

Publication Publication Date Title
WO2009037042A2 (de) Verfahren und vorrichtung zur ermittlung einer eintrittswahrscheinlichkeit
DE102019126195A1 (de) Verfahren zur effizienten, simulativen Applikation automatisierter Fahrfunktionen
DE102019124018A1 (de) Verfahren zum Optimieren von Tests von Regelsystemen für automatisierte Fahrdynamiksysteme
DE102019209540A1 (de) Verfahren und Vorrichtung zur optimalen Aufteilung von Testfällen auf unterschiedliche Testplattformen
EP4193135A1 (de) Computerimplementiertes verfahren zum bereitstellen eines test-verlaufs zu testender verkehrsszenarien
EP3757792A2 (de) Verfahren und vorrichtung zum prüfen eines systems, zur auswahl realer tests und zum testen von systemen mit komponenten maschinellen lernens
DE102021210107A1 (de) Computerimplementierte Verfahren, Module und System zur Anomalieerkennung in industriellen Fertigungsprozessen
AT523850B1 (de) Computergestütztes Verfahren und Vorrichtung zur wahrscheinlichkeitsbasierten Geschwindigkeitsprognose für Fahrzeuge
DE102020214596A1 (de) Verfahren zum Erzeugen von Trainingsdaten für ein Erkennungsmodell zum Erkennen von Objekten in Sensordaten einer Umfeldsensorik eines Fahrzeugs, Verfahren zum Erzeugen eines solchen Erkennungsmodells und Verfahren zum Ansteuern einer Aktorik eines Fahrzeugs
DE102022207563A1 (de) Techniken zum validieren oder verifizieren von closed-loop-testplattformen
DE102021109126A1 (de) Verfahren zum Testen eines Produkts
DE102021109129A1 (de) Verfahren zum Testen eines Produkts
EP3757698A1 (de) Verfahren und vorrichtung zur bewertung und auswahl von signal-vergleichsmetriken
DE102019219067A1 (de) Verfahren zur automatischen Qualifizierung eines virtuellen Modells für eine Kraftfahrzeugkomponente
DE102021109127A1 (de) Verfahren zum Testen eines Produkts
DE102021111724B4 (de) Verfahren und Computerprogramm zum Evaluieren eines Softwarestands eines Fahrerassistenzsystems
DE102017213764A1 (de) Vorrichtung zur Zuverlässigkeitsanalyse eines mechatronischen Systems
DE102020215387A1 (de) Verfahren zum Optimieren eines Testsatzes zur automatischen Qualifizierung eines virtuellen Modells für eine Kraftfahrzeugkomponente
DE102021109131A1 (de) Verfahren zum Testen eines Produkts
DE102020205527A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
DE102021202335A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
EP3764185A1 (de) Verfahren zum testen eines systems
DE102021109133A1 (de) Verfahren und Vorrichtung zum Erstellen von Testfällen für ein Testsystem
DE102021102460A1 (de) Verfahren zur Durchführung einer Simulation
DE102021109130A1 (de) Verfahren zum Testen eines Produkts