DE102021109129A1 - Verfahren zum Testen eines Produkts - Google Patents

Verfahren zum Testen eines Produkts Download PDF

Info

Publication number
DE102021109129A1
DE102021109129A1 DE102021109129.2A DE102021109129A DE102021109129A1 DE 102021109129 A1 DE102021109129 A1 DE 102021109129A1 DE 102021109129 A DE102021109129 A DE 102021109129A DE 102021109129 A1 DE102021109129 A1 DE 102021109129A1
Authority
DE
Germany
Prior art keywords
simulation
depending
data
product
classification
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
DE102021109129.2A
Other languages
English (en)
Inventor
Joachim Sohns
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 DE102021109129.2A priority Critical patent/DE102021109129A1/de
Publication of DE102021109129A1 publication Critical patent/DE102021109129A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00Computer-aided design [CAD]
    • G06F30/20Design optimisation, verification or simulation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2117/00Details relating to the type or aim of the circuit design
    • G06F2117/08HW-SW co-design, e.g. HW-SW partitioning
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00Computer-aided design [CAD]
    • G06F30/10Geometric CAD
    • G06F30/15Vehicle, aircraft or watercraft design

Abstract

Vorgestellt wird ein computerimplementiertes Verfahren zum Testen eines Produkts insbesondere einer Software, einer Hardware oder eines Systems umfassend Hardware und Software. Dabei wird abhängig von Eingangsparametern für das Produkt mindestens eine erste Simulation durchgeführt, mit welcher eine bestimmte Eigenschaft des Produkts getestet wird, wobei mindestens ein erster Modellparameter der ersten Simulation abhängig von einem ersten Satz an Kalibrierungsdaten kalibriert wird und die erste Simulation abhängig von dem mindestens einem ersten Modellparameter der ersten Simulation durchgeführt wird. Abhängig von den Eingangsparametern wird für das Produkt mindestens eine zweite Simulation durchgeführt, mit welcher die bestimmte Eigenschaft des Produkts getestet wird, wobei mindestens ein erster Modellparameter der zweiten Simulation abhängig von einem zweiten Satz an Kalibrierungsdaten oder Validierungsdaten kalibriert wird und die zweite Simulation abhängig von dem mindestens einem ersten Modellparameter der zweiten Simulation durchgeführt wird. Dabei wird der zweite Satz an Kalibrierungsdaten oder Validierungsdaten durch eine Datenreduzierung aus dem ersten Satz an Kalibrierungsdaten oder Validierungsdaten erzeugt. Durch Vergleich von einem Ergebnis der ersten Simulation mit einem Ergebnis der zweiten Simulation wird eine Auswirkung der Datenreduzierung ermittelt. Abhängig von der ermittelten Auswirkung und einer festgelegten maximalen Auswirkung wird eine akzeptable Datenreduzierung bestimmt. Eine weitere Simulation, mit welcher die bestimmte Eigenschaft des Produkts getestet wird, wird abhängig von einem entsprechend der akzeptablen Datenreduzierung bestimmten Satz von Kalibrierungsdaten oder Validierungsdaten durchgeführt.

Description

  • Die Erfindung betrifft ein computerimplementiertes Verfahren zum Testen eines Produkts sowie ein dazu eingerichtetes Computerprogramm und eine dazu eingerichtete Testumgebung.
  • Stand der Technik
  • Aus der DE 10 2020 205 539 ist ein Verfahren zum Prüfen eines technischen Systems, insbesondere eines zumindest teilautonomen Roboters oder Fahrzeuges bekannt. Dabei wird ein virtueller Test-Klassifikator eingeführt, welcher die Erfordernisse von Modellvalidierung und Produkttest kombiniert.
  • Offenbarung der Erfindung
  • Vorgestellt wird ein computerimplementiertes Verfahren zum Testen eines Produkts insbesondere einer Software, einer Hardware oder eines Systems umfassend Hardware und Software. Dabei wird abhängig von Eingangsparametern für das Produkt mindestens eine erste Simulation durchgeführt, mit welcher eine bestimmte Eigenschaft des Produkts getestet wird, wobei mindestens ein erster Modellparameter der ersten Simulation abhängig von einem ersten Satz an Kalibrierungsdaten kalibriert wird und die erste Simulation abhängig von dem mindestens einem ersten Modellparameter der ersten Simulation durchgeführt wird. Abhängig von den Eingangsparametern wird für das Produkt mindestens eine zweite Simulation durchgeführt, mit welcher die bestimmte Eigenschaft des Produkts getestet wird, wobei mindestens ein erster Modellparameter der zweiten Simulation abhängig von einem zweiten Satz an Kalibrierungsdaten oder Validierungsdaten kalibriert wird und die zweite Simulation abhängig von dem mindestens einem ersten Modellparameter der zweiten Simulation durchgeführt wird. Dabei wird der zweite Satz an Kalibrierungsdaten oder Validierungsdaten durch eine Datenreduzierung aus dem ersten Satz an Kalibrierungsdaten oder Validierungsdaten erzeugt. Durch Vergleich von einem Ergebnis der ersten Simulation mit einem Ergebnis der zweiten Simulation wird eine Auswirkung der Datenreduzierung ermittelt. Abhängig von der ermittelten Auswirkung und einer festgelegten maximalen Auswirkung wird eine akzeptable Datenreduzierung bestimmt. Eine weitere Simulation, mit welcher die bestimmte Eigenschaft des Produkts oder eines ähnlichen Produkts (z.B. neue Produktvariante oder neue Produktgeneration) getestet wird, wird abhängig von einem entsprechend der akzeptablen Datenreduzierung bestimmten Satz von Kalibrierungsdaten oder Validierungsdaten durchgeführt.
  • Vorzugsweise wird abhängig von einem Vergleich eines Ergebnisses der weiteren Simulation mit einer Anforderung an die bestimmte Eigenschaft für das Ergebnis der weiteren Simulation eine erste Klassifikation ausgegeben, abhängig von einem Vergleich von Referenzdaten aus einem alternativen Test der bestimmten Eigenschaft des Produkts mit der Anforderung an die bestimmte Eigenschaft eine zweite Klassifikation ermittelt und abhängig von der ersten Klassifikation und der zweiten Klassifikation eine Kostenfunktion trainiert, abhängig von welcher der mindestens eine erste Modellparameter optimiert wird.
  • Vorzugsweise wird abhängig von der ersten Klassifikation und der zweiten Klassifikation eine Genauigkeit oder Robustheit der weiteren Simulation bestimmt.
  • In einer besonders bevorzugten Ausgestaltung wird die Auswirkung der Datenreduzierung bestimmt, indem im Vergleich zwischen mehreren ersten Simulationen und mehreren zweiten Simulationen bestimmt wird, welche Anzahl oder welcher Anteil der Simulationsergebnisse übereinstimmt. Dabei entspricht vorzugsweise die maximale Auswirkung einer maximalen Anzahl oder einem maximalen Anteil nicht übereinstimmender Simulationsergebnisse.
  • Bei dem (technischen) Produkt kann es sich insbesondere um eine Software handeln, welche auf einer Recheneinheit in einem technischen System ablaufen soll, beispielsweise eine Detektions-, Überwachungs- oder Steuerfunktion in einem zumindest teilautonomen Fahrzeug oder Roboter. Auch kann es sich bei dem (technischen) Produkt um eine Hardware umfassend eine Software handeln, beispielsweise einen Sensor, einen Aktor oder ein Steuergerät eines zumindest teilautonomen Roboters oder Fahrzeuges.
  • Die Klassifikationen im Rahmen der vorgestellten Verfahren werden insbesondere nicht dafür eingesetzt, Produkteigenschaften zu klassifizieren oder durch Klassifikation Fehler in Produkten zu erkennen. Vielmehr wird klassifiziert, ob und zu welchem Grad die auf Grundlage einer Simulation vorgenommene Bewertung eines Produkts den Eigenschaften des Produkts in der Realität entspricht. Es bietet die Möglichkeit, Modellparameter der Simulation zu optimieren sowie gegebenenfalls die Güte einer Simulation in Bezug auf vorgegebene Kriterien zu bestimmen. Darüber hinaus bietet es die Möglichkeit, automatisierte Simulationen anzustoßen. Eine weitere mögliche Anwendung besteht darin, die Güte von Simulationsergebnissen vorherzusagen ohne zusätzliche Referenzmessungen durchführen zu müssen.
  • In einer bevorzugten Ausgestaltung stammen die Referenzdaten aus einem Test am realen Produkt oder aus einer (insbesondere besonders genauen) Referenzsimulation.
  • Die erste Klassifikation und die zweite Klassifikation können beispielsweise jeweils umfassen, ob das Produkt den Test bestanden hat oder nicht bestanden hat oder ob der Test nicht durchgeführt wurde, weil dafür notwendige Bedingungen nicht erfüllt waren. Auch können die erste Klassifikation und die zweite Klassifikation jeweils umfassen, ob die Diagnose- oder Detektionsfunktion zu einem falsch positiven, einem falsch negativen, einem wahr positiven oder einem wahr negativen Ergebnis kommt, insbesondere bei einer Simulation einer Detektions- oder Diagnosefunktion. Außerdem können die erste und die zweite Klassifikation jeweils umfassen, ob ein vordefiniertes, sicherheitsrelevantes Ereignis eingetreten ist oder nicht, insbesondere bei einer Simulation einer sicherheitskritischen Funktion. Diese Klassifikationen ermöglichen eine effiziente Optimierung von Modellparametern der Simulation sowie eine stabile und aussagekräftige Metrik zur Bestimmung der Genauigkeit und Robustheit der Simulation.
  • Die beschriebenen Verfahren ermöglichen eine Priorisierung von Validierungs- und Kalibrierungsmessungen und -simulationen anhand vorhandener Klassifikationsergebnisse. Es können die Eingangsdaten für die Modellkalibrierung bestimmt werden, die zur Erreichung eines Simulationsziels notwendig waren. Somit ergibt sich eine effiziente Kalibrierungsstrategie, insbesondere für zukünftige Projekte, z.B. nachfolgende Generationen des gleichen Produkts oder andere Produktvarianten, die teilweise simulationsbasiert freigegeben werden sollen. Es können dabei reale Messungen und die zugehörigen Simulationen bei der Modellkalibrierung für zukünftige Projekte oder für andere Produktvarianten eingespart werden. Vorteilhafterweise kann eine Priorisierung möglicher Stimuli für die Modellkalibrierung bei zukünftigen Projekten oder bei anderen Produktvarianten ermittelt werden. Zudem kann eine Bewertung der Zuverlässigkeit einer Simulationsumgebung in Bezug auf beliebige, vom Anwender definierte Klassifikationskriterien erfolgen.
  • Die beschriebenen Verfahren können beispielsweise für eine Simulationsumgebung zur Freigabe von Testfunktionen sowie für eine HIL-, MIL-, SIL-Umgebung für den Test einer Diagnosefunktion oder einer Detektionsfunktion, beispielsweise einer Fahrassistenzfunktionen, einer sicherheitskritischen Funktion oder von Diagnosefunktionen in einem Steuergerät, eingesetzt werden.
  • Nachfolgend werden Ausführungsformen der Erfindung unter Bezugnahme auf die beiliegenden Zeichnungen näher erläutert. In den Zeichnungen zeigen schematisch:
    • 1 eine beispielhafte Ausprägung eines computerimplementierten Verfahren zum Testen eines Produkts,
    • 2 einen Ausschnitt aus 1 mit Details zu Block 130,
    • 3 einen beispielhaften Ablauf eines Testverfahrens einschließlich der Kalibrierung einer dabei eingesetzten Simulation,
    • 4 eine beispielhafte Ausprägung einer Kalibrierung einer Simulation in einer Testumgebung,
    • 5 eine beispielhafte Ausprägung zur Bestimmung einer geeigneten Datenreduzierung von Kalibrierungsdaten zur Kalibrierung einer Simulation.
  • Beschreibung der Ausführungsbeispiele
  • In der Softwaretechnik wird die Nutzung von Modellen zur Automatisierung von Testaktivitäten und zur Generierung von Testartefakten im Testprozess unter dem Oberbegriff „modellbasiertes Testen“ (model-based testing, MBT) zusammengefasst. Darunter kann beispielsweise die Generierung von Testfällen aus Modellen fallen, die das Sollverhalten des zu testenden Systems beschreiben.
  • Insbesondere eingebettete Systeme (embedded systems) sind auf schlüssige Eingangssignale von Sensoren angewiesen und stimulieren wiederum ihre Umwelt durch Ausgangssignale an unterschiedlichste Aktoren. Im Zuge der Verifikation und vorgelagerter Entwicklungsphasen eines solchen Systems kann daher in einer Regelschleife dessen Modell (model in the loop, MiL), Software (software in the loop, SiL), Prozessor (processor in the loop, PiL) oder gesamte Hardware (hardware in the loop, HiL) gemeinsam mit einem Modell der Umgebung simuliert werden. In der Fahrzeugtechnik werden diesem Prinzip entsprechende Simulatoren zur Prüfung elektronischer Steuergeräte je nach Testphase und -objekt mitunter als Komponenten-, Modul- oder Integrationsprüfstände bezeichnet.
  • Derartige Simulationen sind auf verschiedenen Gebieten der Technik verbreitet und finden beispielsweise Einsatz, um eingebettete Systeme in Elektrowerkzeugen, Motorsteuergeräte für Antriebs-, Lenk- und Bremssysteme, Kamerasysteme, Systeme mit Komponenten der künstlichen Intelligenz und des maschinellen Lernens, Robotiksysteme oder autonome Fahrzeuge in frühen Phasen ihrer Entwicklung auf Tauglichkeit zu prüfen.
  • Dennoch werden die Ergebnisse solcher Simulationsmodelle bislang aufgrund fehlenden Vertrauens in ihre Zuverlässigkeit in der Regel nur begrenzt in Freigabeentscheidungen einbezogen.
  • Im Kontext von Produktentwicklung können Klassifikationsverfahren unter anderem zur Entwicklung von Diagnosefunktionen für Steuergeräte und im Bereich Design of Reliability eingesetzt werden. Der Fokus liegt dabei darauf, anhand von Messdaten typische Fehlermuster zu erkennen. Auch in Steuergerätefunktionen für Fahrerassistenzfunktionen kommen Klassifikationsverfahren und andere Verfahren des maschinellen Lernens auf vielfältige Weise zum Einsatz.
  • Ein Simulationsmodell bzw. die darin enthaltenen Teilmodelle enthalten üblicherweise Parameter, die vorab kalibriert werden. Bevorzugte Verfahren können beispielsweise dem folgenden Schema folgen. Dabei werden Signale oder skalare Werte (QOI, Quantity of Interests) aus realen Messungen oder andere Referenzdaten (z.B. aus Simulationen mit höherer Genauigkeit) mit den zugehörigen QOls aus Simulationen verglichen. Anhand Anwender-definierter Metriken werden das Simulationsergebnis und die Referenzdaten für die QOls verglichen und die Abweichung bewertet. Durch Variation wird ein Satz von Modellparametern gesucht, für welchen die Abweichung möglichst gering ist.
  • Im Folgenden werden Beispiele für den Einsatz von Klassifikationsverfahren im Rahmen einer Verifikation oder Validierung eines Produkts beschrieben, beispielsweise für die Validierung einer eigebetteten Software-Funktion, insbesondere für Fahrfunktionen eines zumindest teilautomatisierten Fahrzeugs oder Roboters.
  • 1 zeigt eine beispielhafte Ausprägung eines computerimplementierten Verfahren zum Testen eines Produkts. Über das hierzu beschriebene Framework können unterschiedliche Simulationsmodelle und unterschiedliche Klassifikationen in die Validierung eingebunden werden.
  • Eingangsgrößen 101 können in ein Eingangsmodell 102 eingegeben werden, welches Ausgangsgrößen an eine simulationsbasierte Testumgebung 110 ausgibt. Weiterhin können weitere Eingangsgrößen 103, wie zum Beispiel Szenariolisten, Daten eines Testkatalogs oder ähnliche Informationen, direkt an die simulationsbasierte Testumgebung 110 gegeben werden.
  • Die simulationsbasierte Testumgebung kann auf verschiedene Modelle und Werkzeuge zugreifen und das zu testende Produkt mittels einer Simulation untersuchen. Die Testumgebung kann insbesondere MiL-, SiL-, HiL- oder PiL-Verfahren einsetzen.
  • Ergebnisse des oder der Tests werden aus der simulationsbasierten Testumgebung 110 einer Klassifizierungsinstanz 111 übergeben, welche für diese eine Klassifikation durchführt. Ein Ergebnis der Klassifikation wird von der Klassifizierungsinstanz 111 an den Block 130 übergeben.
  • Aus Block 104 können weitere Informationen wie relevante Signale der Simulation, Referenzdaten, Modellparameter oder weitere Eingangsgrößen an Block 130 übergeben werden.
  • Aus Block 120 werden Referenzdaten aus einem alternativen Test an eine Klassifizierungsinstanz 121 übergeben. Der alternative Test kann dabei insbesondere ein Versuch am realen Produkt sein oder es kann sich um eine besonders genaue, komplexere Simulation handeln als die Simulation in Block 110. Block 120 kann dabei insbesondere eine Datenbank mit Referenzdaten sein. Alternativ kann es sich bei Block 120 auch um eine weitere Testumgebung handeln, beispielsweise auch eine Apparatur zur Erzeugung weiterer Messungen, insbesondere am realen Produkt.
  • In den Klassifizierungsinstanzen 111 bzw. 121 werden die Ausgangsgrößen bzw. Ergebnisse der Simulation aus Block 110 bzw. die Ausgangsgrößen bzw. Referenzdaten aus Block 120 nach vorgegebenen Kriterien klassifiziert. Diese Kriterien können beispielsweise über eine Schnittstelle aus einer Nutzereingabe ermittelt werden.
  • Mögliche Klassifikationskriterien können z.B. sein:
    • - bei Software-, Hardware- oder Systemtests: Test bestanden / Test nicht bestanden oder Test/ freigegeben / Test nicht freigegeben
    • - bei Diagnose- und Detektionsfunktionen: Falsch positiv / falsch negativ / wahr positiv / wahr negativ
    • - im Kontext von Simulationen zur funktionalen Sicherheit, z. B. SOTIF-Simulationen (SOTIF = Safety Of The Intended Functionality): vordefiniertes Event eingetreten / nicht eingetreten
  • Je nach Anwendung lassen sich weitere Klassifikationskriterien definieren. Dabei bedeutet Klassifikation insbesondere die Zuordnung der Simulationsergebnisse bzw. Referenzdaten zu einer oder mehreren Klasse einer diskreten Anzahl von Klassen.
  • Block 130 umfasst eine klassifikationsbasierte Evaluierung der Genauigkeit oder Robustheit der Simulation aus Block 110, die Ausgangsgrößen 140 umfassen ein Maß für die Genauigkeit oder Robustheit der Simulation aus Block 110. Beispielsweise können die Ausgangsgrößen 140 eine Robustheits- oder Genauigkeitsmetrik wie ein Maß für einen Informationsgewinn (information gain) oder charakteristische Größen, wie sie aus dem Maschinellen Lernen bekannt sind, wie eine Konfusionsmatrix umfassen.
  • Die Klassifikationen aus den Klassifikationsinstanzen 111 und 121 können für eine Optimierung von Modellparametern der Simulation eingesetzt werden. Die Qualität einer Simulation in Bezug auf eine gegebene Simulationsaufgabe kann daran gemessen werden, wie gut die auf Grundlage der Simulation vorgenommene Klassifikation mit der Klassifikation auf Grundlage der Referenzdaten übereinstimmt. Das Simulationsmodell wird in diesem Verfahren als Klassifikator interpretiert, wobei die Modellparameter die Parameter des Klassifikators sind und dessen Genauigkeit und Performance festlegen. Die Modellparameter können so gewählt werden, dass bestimmte Werte aus den Klassifikationen abgeleitete werden, z.B. Werte der Konfusionsmatrix (oder daraus abgeleiteter Informationsmaße) den optimalen Wert erreichen.
  • Die Modellparameter des Simulationsmodells können dahingehend optimiert werden, dass eine vom Anwender definierte Art der Fehlklassifikation möglichst selten (oder ggf. auch möglichst häufig) auftritt.
  • Wird zum Beispiel eine Menge von Tests klassifiziert und besteht das Ziel darin, möglichst wenige Tests in der Simulation als „bestanden“ zu bewerten, die in der Realität bzw. gemäß Referenzdaten „nicht bestanden“ sind, so priorisiert der Anwender den betreffenden Eintrag in der Konfusionsmatrix des Ergebnisvergleichs. Die Modellparameter des Simulationsmodells werden anschließend dahingehend optimiert, dass diese Zahl minimal ist.
  • Das Verfahren kann beispielsweise wie folgt ablaufen:
    1. 1. Festlegung initialer Werte für die Modellparameter (beispielsweise mit einer etablierten Methode), z.B. in Block 101.
    2. 2. Durchführung von Simulationen mit den festgelegten Modellparametern in Block 110. Die Simulationen werden nach einem vorgegebenen Katalog durchgeführt. Für alle Simulationen sind Referenzdaten in Block 120 vorhanden, anhand derer das Simulationsergebnis bewertet wird.
    3. 3. Vergleich der Klassifikationen der Simulationsergebnisse aus Klassifikationsinstanz 111 mit den Klassifikationen der zugehörigen Referenzdaten aus Klassifikationsinstanz 112.
    4. 4. Erstellung einer Konfusionsmatrix in Block 130, z.B. als Summe über alle Simulationen und Referenzdaten, die zum gleichen Katalog gehören.
    5. 5. Gewichtung der Einträge in der Konfusionsmatrix entsprechend der Vorgaben des Anwenders in Block 130 und Ausgabe der Konfusionsmatrix aus Block 130 zu Block 150.
    6. 6. Bildung einer Kostenfunktion in Block 150 abhängig von der Konfusionsmatrix.
    7. 7. Verwendung der Kostenfunktion für eine Optimierung in Block 150, wobei die Modellparameter der Simulation die vom Optimierer anzupassenden Freiheitsgrade sind. Ausgabe der optimierten Modellparameter zu Block 110.
    8. 8. Nach jedem Update der Parameter werden in Block 110 die Simulationen erneut durchgeführt, die neue Kostenfunktion auf dieselbe Weise ermittelt und die Parameteroptimierung entsprechend durchgeführt.
  • In einer ersten bevorzugten Variante der beschriebenen Verfahren hängt die Kostenfunktion, bezüglich derer die Modellparameter optimiert werden, alleine von den relevanten Einträgen der Konfusionsmatrix ab. Es werden keine weiteren Kalibrierungs- oder Validierungsmessungen vorgenommen.
  • Diese Variante lässt sich auf einfache Weise erweitern: Wenn ein vorgegebenes Optimierungskriterium erreicht und die Optimierung abgeschlossen wurde, werden auf Grundlage der zuletzt durchgeführten Simulationen, wichtige bzw. festgelegte Signale aus Simulation und Referenzdaten miteinander verglichen. Mit Hilfe standardisierter Metriken lassen sich für jede einzelne Simulation oder für alle Simulationen in ihrer Gesamtheit ein (ggf. kumulierter) Modellfehler bestimmen. Dieser kann dazu verwendet werden, für zukünftige neue Simulationsprojekte (beispielsweise bei Weiterentwicklung eines Produkts oder Simulation neuer Varianten) eine Anforderung an die Modellgenauigkeit zu stellen. Die Daten können aber auch dazu verwendet werden, einen virtuellen Test-Klassifikators (VTC) entsprechend der DE 10 2020 205539 zu trainieren.
  • In einer zweiten bevorzugten Variante werden zusätzlich zu den Klassifikationsergebnissen weitere Kalibrierungsmessungen und zugehörige Simulationen durchgeführt und mit Hilfe von Signalmetriken die Abweichung von Referenzdaten und Simulation bestimmt. Auf diese Weise können zur Modellkalibrierung von Closed-Loop-Simulationen auch Open-Loop-Simulationen herangezogen werden.
  • Ähnlich wie bei etablierten Kalibrierungsmethoden gehen diese Abweichungen in eine Kostenfunktion ein, die durch Anpassung der Modellparameter minimiert wird. Die Modellparameter werden so verändert, dass die Abweichung zwischen Simulation und Referenzmessungen möglichst gering ist. Dabei wird die Modellabweichung, die mit Hilfe von Signalmetriken bestimmt wird, mit den Ergebnissen der Klassifikation kombiniert und abhängig davon die Kostenfunktion gebildet bzw. gelernt.
  • Auch bei dieser Variante können zusätzlich nach Erreichen des Optimierungsziels für alle durchgeführten Simulationen die Modellfehler ausgegeben werden. Diese lassen sich wiederum dazu verwenden, einen Virtual Test Classifier zu trainieren oder Anforderungen an die Simulationsgenauigkeit für weitere Projekte abzuleiten.
  • Beide beschriebenen bevorzugten Varianten lassen sich auf die Optimierung bezüglich unterschiedlicher Testkataloge verallgemeinern. Hierzu können die relativen Häufigkeiten in den Konfusionsmatrizen getrennt voneinander bestimmt werden. Bevorzugte eingesetzt werden können beispielsweise eine Pareto-Optimierung oder eine Kombination der Klassifikationsergebnisse aus unterschiedlichen Tests zu einer gemeinsamen Kostenfunktion.
  • 2 zeigt einen Ausschnitt aus 1 mit Details zu Block 130.
  • In 2 sind die angebundenen Blöcke 110, 120 und 150 sowie deren Eingänge nicht gezeigt. Die Klassifizierungsinstanzen 111 und 121 sowie deren Eingänge und Ausgänge entsprechen den Beschreibungen zu 1.
  • Block 130 kann neben den Klassifikationen aus den Blöcken 110 und 120 wie zu 1 beschrieben auch weitere Eingangsgrößen aus Block 104 erhalten. Block 130 umfasst insbesondere eine Eingangsinstanz 131 zum Empfang und zur Verarbeitung von Eingangsdaten.
  • Block 130 umfasst weiterhin einen Block 133 zu Modellerstellung, insbesondere zur Erstellung eines Metamodells, mit welchem eine Genauigkeit oder Robustheit der Simulation auch in Bereichen ermittelt werden kann, für welche keine Eingangsdaten bzw. keine Referenzdaten vorliegen. Block 133 kann dabei zur Modellerstellung Eingangsdaten aus Block 131 erhalten.
  • Block 130 umfasst zudem einen Block 134 zur Berechnung und Ausgabe von Ausgangsgrößen 140, insbesondere umfassend ein Maß der Genauigkeit oder Robustheit der Simulation aus Block 110. Block 134 kann zur Berechnung Eingangsdaten aus Block 133 erhalten.
  • 3 zeigt einen beispielhaften Ablauf eines Testverfahrens einschließlich der Kalibrierung einer dabei eingesetzten Simulation.
  • Dabei wird ein Datensatz zur Modellkalibrierung und -validierung schrittweise verkleinert und daraufhin untersucht, wie sich diese Verkleinerung auf die Werte der Modellparameter des Simulationsmodells und auf die damit erzielten Simulationsergebnisse auswirkt.
  • Im Detail kann das Verfahren beispielsweise nach folgendem Schema ablaufen.
  • In Schritt 301 erfolgt eine Kalibrierung der Modellparameter des Simulationsmodells mit Hilfe aller verfügbaren Validierungs- und Kalibrierungsdaten (ggf. auch über open-loop-Verfahren).
  • In Schritt 302 erfolgt eine Auswahl von Testfällen, für welche die Simulation und die Referenzdaten zum gleichen Ergebnis kommen (z.B. beides „bestanden“ oder beides „nicht bestanden“).
  • In Schritt 303 wird eine Aufteilung der Tests in Testgruppen vorgenommen und für jede Testgruppe eine absolute oder relative Zahl an Tests festgelegt, für die Simulation und Realität übereinstimmen sollen.
  • In Schritt 304 wird der Datensatz an Validierungs- und Kalibrierungsmessungen reduziert, indem eine Menge von Teildatensätzen erzeugt wird, bei denen eine oder mehrere Validierungs- und Kalibrierungsmessungen und die zugehörigen Simulationen fehlen.
  • In Schritt 305 werden die Modellparameter auf Grundlage der reduzierten Datensätze berechnet und alle vorgesehenen Simulationen mit den neuen Werten der Modellparameter durchgeführt.
  • In Schritt 306 erfolgt ein Vergleich, für wie viele Tests die Simulationsergebnisse gleichgeblieben sind.
  • In Schritt 307 wird abhängig von dem Vergleich überprüft, ob die Auswirkung der Datenreduzierung noch akzeptabel ist.
  • Falls für mindestens einen der Datensätze die absolute oder relative Zahl über der festgelegten Schwelle liegt, werden diese Zahlen für alle reduzierten Kalibrierungsdatensätze verglichen. Der Datensatz mit der größten Genauigkeit wird übernommen und mit Schritt 304 fortgesetzt.
  • Wird dagegen in Schritt 307 festgestellt, dass in allen betrachteten Varianten durch „Weglassen“ von Testdaten die geforderte Simulationsgenauigkeit nicht mehr gegeben ist, wird das Verfahren beendet. Der zuletzt verwendete Datensatz wird als Ergebnis ausgegeben. Die zugehörigen Szenarien oder Tests werden abgespeichert. Bei weiteren Simulationen, z.B. einer neuen Produktvariante oder einer neuen Produktgeneration mit ähnlichen Anwendungsfällen für die Simulation, kann zur Modellkalibrierung die reduzierte Liste an notwendigen Kalibrierungs- und Validierungsmessungen herangezogen werden.
  • 4 zeigt eine beispielhafte Ausprägung einer Kalibrierung einer Simulation in einer Testumgebung.
  • Dabei wird die Modellkalibrierung zweimal durchgeführt: Mit dem ursprünglichen Satz an Kalibrierungs- bzw. Validierungsdaten, insbesondere Messungen und zugehörigen Simulationen, 402 und mit einem verkleinerten Datensatz 405, der durch Datenreduzierung aus Datensatz 402 gewonnen wird. Die Datenreduzierung kann dabei auf unterschiedliche Weise erfolgen. Für jeden dieser verkleinerten Datensätze ergeben sich andere Werte für die Modellparameter.
  • Auf Basis des ursprünglichen Datensatzes an Kalibrierungs- bzw. Validierungsdaten 401 erfolgt in Block 402 mittels eines Kalibrierungsalgorithmus eine Kalibrierung der Modellparameter des Simulationsmodells, resultierend in einem ersten Parametersatz. Abhängig von dem ersten Parametersatz werden in Block 403 Simulationen durchgeführt. In Klassifizierungsinstanz 404 werden die Simulationsergebnisse klassifiziert.
  • Entsprechend erfolgt auf Basis des reduzierten Datensatzes an Kalibrierungs- bzw. Validierungsdaten 405 in Block 406 mittels eines Kalibrierungsalgorithmus eine Kalibrierung der Modellparameter des Simulationsmodells, resultierend in einem ersten Parametersatz. Abhängig von dem ersten Parametersatz werden in Block 407 Simulationen durchgeführt. In Klassifizierungsinstanz 408 werden die Simulationsergebnisse klassifiziert.
  • In Block 409 werden die Klassifikationen aus 404 und die Klassifikationen aus 408 miteinander verglichen. Das Ergebnis eines solchen Vergleichs kann beispielsweise in einer Matrixform 410 ausgegeben werden, bei welcher die Diagoalelemente der Zahl der Tests oder Szenarien entsprechen, für welche das Simulationsergebnis mit veränderten Modellparametern auf Basis eines reduzierten Datensatzes dem ursprünglichen Ergebnis entspricht.
  • 5 zeigt eine beispielhafte Ausprägung zur Bestimmung einer geeigneten Datenreduzierung von Kalibrierungsdaten zur Kalibrierung einer Simulation.
  • Wird der Vergleich entsprechend 4 für unterschiedliche Parameterdatensätze durchgeführt, so lassen sich diese wiederum vergleichen.
  • Beispielsweise wird auf Basis eines ersten reduzierten Datensatzes 501 in Block 502 eine Kalibrierung durchgeführt, mit den resultierenden Modellparametern simuliert und ein Vergleich zwischen ursprünglichen und neuen Simulationsergebnissen bzw. zwischen deren Klassifikationen durchgeführt. Das Ergebnis des Vergleichs 503 wird beispielsweise in Matrixform ausgegeben.
  • Entsprechend wird auf Basis eines zweiten reduzierten Datensatzes 504 in Block 505 eine Kalibrierung durchgeführt, mit den resultierenden Modellparametern simuliert und ein Vergleich zwischen ursprünglichen und neuen Simulationsergebnissen bzw. zwischen deren Klassifikationen durchgeführt. Das Ergebnis des Vergleichs 506 wird beispielsweise in Matrixform ausgegeben.
  • In Block 507 erfolgt nun ein Vergleich zwischen Vergleichsergebnis 503 und Vergleichsergebnis 506. Derjenige Satz von Modellparametern, für den sich das Simulationsergebnis am wenigsten verändert hat, erzielt die beste Performance. Dies bedeutet im Umkehrschluss, dass die Kalibrierungsmessungen, die in diesem Fall weggelassen wurden, die niedrigste Priorität haben.
  • Im Folgenden soll die beispielhafte Anwendung eines der vorgestellten Verfahren für einen Funktionstest für den Spurhalteassistenten (Lane Keeping System, LKS) eines Fahrzeugs beschrieben werden. Das zu testende System ist in diesem Fall die LKS-Funktionalität eines betrachteten Fahrzeugs. Eine Anforderung an das LKS ist, dass das Fahrzeug auch auf einer kurvenreichen Strecke einen Sicherheitsabstand zu den Rändern der Spur halten muss. Parameter wie die Krümmung der Strecke oder die Reibung zwischen Straßenbelag und Reifen können variiert werden. Diese spielen in diesem Szenario die Rolle der Eingangsgrößen für das Eingangsmodell.
  • Als Klassifikation wird jeder möglichen Parameterkonfiguration der Wert „Test bestanden“ oder „Test nicht bestanden“ für die beschriebene Anforderung zugewiesen. Diese Klassifikation wird sowohl für die Tests abhängig vom Referenzdatensatz (z.B. reale Daten oder Simulation mit größerer Genauigkeit) als auch für die zu bewertende Simulation vorgenommen. Durch die Kombinatorik der beiden Klassifikationen ergibt sich für jeden Punkt im mehrdimensionalen Parameterraum eine übergeordnete Gesamt-Klassifikation nach den folgenden Attributen: „Test simulativ bestanden und in der Referenz bestanden“, „Test simulativ bestanden und in der Referenz nicht bestanden“, „Test simulativ nicht bestanden und in der Referenz bestanden“, „Test simulativ nicht bestanden und in der Referenz nicht bestanden“.
  • Eine Konfusionsmatrix für den Anwendungsfall zur Bewertung eines Tests könnte beispielsweise wie folgt aussehen:
    Simulation Bestanden Nicht bestanden Nicht freigegeben
    Referenz
    Bestanden 0,1 0,2 0,1
    Nicht bestanden 0,15 0,4 0
    Nicht freigegeben 0 0,05 0
  • Üblicherweise werden Tests nicht alleine auf Grundlage von Simulationen freigegeben. Zur Absicherung werden zumindest einige Tests im realen Fahrzeug durchgeführt. Die Frage, wie viele reale Tests wirklich benötigt werden, lässt sich nicht auf allgemeine Weise beantworten. Das hier vorgestellte Verfahren ermöglichen den umgekehrten Weg. Zunächst wird für ein Pilotprojekt eine sehr große Zahl an realen Tests durchgeführt. Anschließend wird geprüft, welche Messungen für zukünftige, vergleichbare Projekte wirklich benötigt werden. Die Simulationsergebnisse werden mit realen Daten und den Ausgängen der durch reale Daten eingelernten Klassifikatoren verglichen.
  • Als weitere beispielhafte Anwendung soll die Genauigkeit oder Robustheit einer Simulation aus einer Simulationsumgebung für eine Diagnose- oder Detektionsfunktion bestimmt werden.
  • Unter anderem in Systemen mit eingebetteter Software werden häufig Diagnosefunktionen und Detektionsfunktionen verwendet. Manche dieser Funktionen dienen speziell zur Erkennung und Meldung von Fehlern. Beispiele hierfür sind die Diagnosefunktionen zur Überwachung eines Abgasnachbehandlungssystems. Tritt in relevanten Parameterbereichen ein auffälliges Verhalten auf, das auf eine Fehlfunktion hindeutet, so wird beispielsweise ein Status-Flag gesetzt, das weiterverarbeitet wird. Ein wiederholtes Auftreten eines solchen Ereignisses führt dazu, dass dem Fahrer ein Fehler angezeigt und im betreffenden Fehlerspeicher des Motorsteuergeräts eine entsprechende Information gespeichert wird.
  • Ein anderes Beispiel für den Einsatz von Diagnose- oder Detektionsfunktionen sind sicherheitsrelevante Funktionen für Fahrerassistenzsysteme wie AEB oder ESP. Auch hier werden Signale auf Grundlage vorgegebener Kriterien plausibilisiert und beim Auftreten bestimmter Ereignisse geeignete Gegenmaßnahmen eingeleitet (wie z.B. sicheres Anhalten, Einleiten einer Notbremsung oder andere Eingriffe in die Aktuatorik des Fahrzeugs).
  • In diesen Beispielen und für vielen weitere Anwendungen von Diagnose- und Detektionsfunktionen kann die Ausgabe der betreffenden Steuergerätefunktion einer der folgenden Kategorien zugeordnet werden:
    • - Falsch positiv: Es ist kein Ereignis aufgetreten, der implementierte Algorithmus hat jedoch ein Ereignis gemeldet.
    • - Falsch negativ: Es ist kein Ereignis aufgetreten, der implementierte Algorithmus hat ein Ereignis gemeldet.
    • - Wahr positiv: Es ist ein Ereignis aufgetreten, der implementierte Algorithmus hat ein Ereignis gemeldet.
    • - Wahr negativ: Es ist kein Ereignis aufgetreten, der implementierte Algorithmus hat kein Ereignis gemeldet.
  • Um Kosten einzusparen oder bereits in einer frühen Phase der Entwicklung Tests durchzuführen, werden auch solche Funktionen zunehmen in simulationsbasierten Plattformen bzw. Testumgebungen, z.B. mit SIL-, MIL- oder HIL-Verfahren getestet.
  • Als Ergebnis einer Bestimmung der Genauigkeit oder Robustheit einer solchen Simulation in einer Testumgebung für eine Diagnose- oder Detektionsfunktion kann aus dem Vergleich von Klassifikationen für die Simulationsergebnisse und für die entsprechenden Referenzdaten eine Metrik, beispielsweise eine Konfusionsmatrix berechnet werden. Auch in diesem Fall kann optional der Anwender auswählen, über welche Parameter summiert werden soll und über welche nicht. Wird über keinen der Parameter gemittelt, so kann jeder Punkt im Parameterraum einer der n Klassen zugeordnet werden (z.B. 16 Klassen bei einer 4x4-Matrix für die oben genannten Klassifikationen), je nachdem, was in der Simulation und in der Referenzmessung beobachtet wurde. Wird über einzelne Parameter gemittelt, so kann ein trainiertes Klassifikationsmodell für jeden Punkt und für jede Kategorie eine Wahrscheinlichkeit angeben (Konfusionsmatrix für jeden Punkt, wie im vorhergehenden Fall).
  • Eine Konfusionsmatrix für den Anwendungsfall zur Bewertung der Performance einer Diagnose- oder Detektionsfunktion könnte beispielsweise wie folgt aussehen:
    Simulation Falsch pos. Falsch neg. Wahr pos. Wahr neg.
    Referenz
    Falsch positiv 0,1 0,2 0,05 0,05
    Falsch negativ 0,15 0,3 0 0
    Wahr positiv 0 0,05 0 0
    Wahr negativ 0.05 0.05 0 0
  • Die Verwendung und Bewertung der Klassifikationsergebnisse hängt stark vom Anwendungsfall ab. Ist der Anwender z.B. in erster Linie daran interessiert, das Risiko zu minimieren, dass falsch-negative Ereignisse als falsch-positiv bewertet werden, so wird er den zugehörigen Eintrag in der Konfusionsmatrix entsprechend gewichten.
  • Auch in diesem Fall kann anhand eines Pilotprojekts mit einer großen Zahl an realen Messungen zur Absicherung der Aufwand für zukünftige Projekte deutlich reduziert und auf diese Weise Kosten eingespart werden.
  • Auch in diesem Beispiel können nun die Modellparameter so angepasst werden, dass der Simulationsfehler bezüglich der zu testenden Anforderungen minimiert wird. Die Parameter können beispielsweise so angepasst werden, dass in möglichst wenig Fällen die Kombination eines Simulationsergebnisses „Wahr negativ“ bei einem Ergebnis „Wahr positiv“ in den Referenzdaten auftritt.
  • Als weitere beispielhafte Anwendung sollen Simulationen zur Absicherung der funktionalen Sicherheit eines Produkts betrachtet werden, beispielsweise SOTIF-Simulationen von Fahrfunktionen eines zumindest teilautomatisierten Fahrzeugs.
  • Beispielsweise kann hierzu simulativ das Szenario einer Autobahnausfahrt betrachtet werden. Anhand von Fehlermodellen kann eine falsche Spurerkennung simuliert werden, die dazu führen kann, dass das Fahrzeug die Fahrbahn verlässt. Für jeden Fall, der im realen Feld beobachtet wurde, wird untersucht, ob das Fahrzeug in Folge des Fehlers die Fahrspur an der Ausfahrt verlassen hat oder nicht. Nun werden diese Szenarien mit Hilfe von Fehlermodellen in der Simulation nachgestellt und überprüft, ob das Fahrzeug in der Simulation die Fahrspur verlassen hat oder nicht. Für jeden zugehörigen Punkt im Parameterraum des Fehlermodells ergibt sich nun eine der Klassifikationen „Ereignis in Simulation und real eingetreten“, „Ereignis in Simulation nicht eingetreten und real nicht eingetreten“, „Ereignis in Simulation eingetreten und real nicht eingetreten“, „Ereignis in Simulation nicht eingetreten und real eingetreten“. Eine Klassifikation über die Parameter des Fehlermodells mittels eines Metamodells ermöglicht es in diesem Fall, die Prädiktionsgenauigkeit der Simulation auch für solche Simulationen vorherzusagen, die nicht real beobachtet werden. Die Konfusionsmatrix und daraus abgeleitete informationstheoretische Größen liefern in diesem Fall eine Indikation für die Genauigkeit oder Robustheit des Simulationsmodells für diese Art von Untersuchung.
  • Wiederum hängt es von der Priorisierung des Benutzers ab, wie er für die Zwecke der Modellparameteroptimierung Abweichungen zwischen Simulation und der aus den Referenzdaten abgeleiteten Klassifikation bewertet und priorisiert und welche Art von Abweichung zwischen Simulation und Experiment am wenigsten akzeptiert wird.
  • Auch in diesem Fall werden Referenzdaten zum Vergleich benötigt, deren Menge aus Kostengründen so gering wie möglich sein sollte.
  • Wiederum können nun die Modellparameter so angepasst werden, dass der Simulationsfehler bezüglich der zu testenden Anforderungen minimiert wird. Die Parameter können beispielsweise so angepasst werden, dass in möglichst wenig Fällen die Kombination „Ereignis in Simulation eingetreten und laut Referenzdaten nicht eingetreten“ auftritt.
  • 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 102020205539 [0002, 0036]

Claims (11)

  1. Computerimplementiertes Verfahren zum Testen eines Produkts insbesondere einer Software, einer Hardware oder eines Systems umfassend Hardware und Software, gekennzeichnet durch folgende Schritte: - abhängig von Eingangsparametern wird für das Produkt mindestens eine erste Simulation durchgeführt, mit welcher eine bestimmte Eigenschaft des Produkts getestet wird, wobei mindestens ein erster Modellparameter der ersten Simulation abhängig von einem ersten Satz an Kalibrierungsdaten kalibriert wird und die erste Simulation abhängig von dem mindestens einem ersten Modellparameter der ersten Simulation durchgeführt wird, - abhängig von den Eingangsparametern wird für das Produkt mindestens eine zweite Simulation durchgeführt, mit welcher die bestimmte Eigenschaft des Produkts getestet wird, wobei mindestens ein erster Modellparameter der zweiten Simulation abhängig von einem zweiten Satz an Kalibrierungsdaten oder Validierungsdaten kalibriert wird und die zweite Simulation abhängig von dem mindestens einem ersten Modellparameter der zweiten Simulation durchgeführt wird, wobei der zweite Satz an Kalibrierungsdaten oder Validierungsdaten durch eine Datenreduzierung aus dem ersten Satz an Kalibrierungsdaten oder Validierungsdaten erzeugt wird, - durch Vergleich von einem Ergebnis der ersten Simulation mit einem Ergebnis der zweiten Simulation wird eine Auswirkung der Datenreduzierung ermittelt, - abhängig von der ermittelten Auswirkung und einer festgelegten maximalen Auswirkung wird eine akzeptable Datenreduzierung bestimmt, - eine weitere Simulation, mit welcher die bestimmte Eigenschaft getestet wird, wird abhängig von einem entsprechend der akzeptablen Datenreduzierung bestimmten Satz von Kalibrierungsdaten oder Validierungsdaten durchgeführt.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass abhängig von einem Vergleich eines Ergebnisses der weiteren Simulation mit einer Anforderung an die bestimmte Eigenschaft für das Ergebnis der weiteren Simulation eine erste Klassifikation ausgegeben wird, abhängig von einem Vergleich von Referenzdaten aus einem alternativen Test der bestimmten Eigenschaft des Produkts mit der Anforderung an die bestimmte Eigenschaft eine zweite Klassifikation ermittelt wird und abhängig von der ersten Klassifikation und der zweiten Klassifikation eine Kostenfunktion trainiert wird, abhängig von welcher der mindestens eine erste Modellparameter optimiert wird.
  3. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass abhängig von der ersten Klassifikation und der zweiten Klassifikation eine Genauigkeit oder Robustheit der weiteren Simulation bestimmt wird.
  4. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Auswirkung der Datenreduzierung bestimmt wird, indem im Vergleich zwischen mehreren ersten Simulationen und mehreren zweiten Simulationen bestimmt wird, welche Anzahl oder welcher Anteil der Simulationsergebnisse übereinstimmt.
  5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass die maximale Auswirkung einer maximalen Anzahl oder einem maximalen Anteil nicht übereinstimmender Simulationsergebnisse entspricht.
  6. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Referenzdaten aus einem Test am realen Produkt oder aus einer Referenzsimulation stammen.
  7. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die bestimmte Eigenschaft eine sicherheitskritische Eigenschaft des Produkts umfasst.
  8. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass eine Genauigkeit oder Robustheit der weiteren Simulation anhand einer Konfusionsmatrix oder eines Information Gain bestimmt wird.
  9. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass das Produkt eine sicherheitskritische Softwarefunktion oder ein sicherheitskritisches System für ein zumindest teilautomatisiertes Fahrzeug oder für einen zumindest teilautomatisierten Roboter umfasst.
  10. Computerprogramm, welches dazu eingerichtet ist, ein Verfahren nach einem der vorangegangenen Ansprüche durchzuführen.
  11. Testumgebung, welche dazu eingerichtet ist, ein Verfahren nach einem der Ansprüche 1 bis 9 mit einem Computerprogramm nach Anspruch 10 durchzuführen.
DE102021109129.2A 2021-04-13 2021-04-13 Verfahren zum Testen eines Produkts Pending DE102021109129A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102021109129.2A DE102021109129A1 (de) 2021-04-13 2021-04-13 Verfahren zum Testen eines Produkts

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102021109129.2A DE102021109129A1 (de) 2021-04-13 2021-04-13 Verfahren zum Testen eines Produkts

Publications (1)

Publication Number Publication Date
DE102021109129A1 true DE102021109129A1 (de) 2022-10-13

Family

ID=83361842

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102021109129.2A Pending DE102021109129A1 (de) 2021-04-13 2021-04-13 Verfahren zum Testen eines Produkts

Country Status (1)

Country Link
DE (1) DE102021109129A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116027699A (zh) * 2022-10-26 2023-04-28 浙江和夏科技股份有限公司 一种基于iTest软件平台的电驱MCU自动标定优化方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102020205539A1 (de) 2020-04-30 2021-11-04 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Prüfen eines technischen Systems

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102020205539A1 (de) 2020-04-30 2021-11-04 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Prüfen eines technischen Systems

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116027699A (zh) * 2022-10-26 2023-04-28 浙江和夏科技股份有限公司 一种基于iTest软件平台的电驱MCU自动标定优化方法
CN116027699B (zh) * 2022-10-26 2023-09-29 浙江和夏科技股份有限公司 一种基于iTest软件平台的电驱MCU自动标定优化方法

Similar Documents

Publication Publication Date Title
DE102020205539A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
DE102020005507A1 (de) Verfahren zum Testen einer automatisierten Fahrfunktion
WO2021058223A1 (de) Verfahren zur effizienten, simulativen applikation automatisierter fahrfunktionen
WO2023041458A2 (de) Computerimplementierte verfahren, module und system zur anomalieerkennung in industriellen fertigungsprozessen
EP3757792A2 (de) Verfahren und vorrichtung zum prüfen eines systems, zur auswahl realer tests und zum testen von systemen mit komponenten maschinellen lernens
WO2019119011A1 (de) Verhaltensmodell eines umgebungssensors
DE102019134053A1 (de) Verfahren zur kontinuierlichen Absicherung im Fahrversuch applizierter automatisierter Fahrfunktionen
DE102021109129A1 (de) Verfahren zum Testen eines Produkts
AT523850B1 (de) Computergestütztes Verfahren und Vorrichtung zur wahrscheinlichkeitsbasierten Geschwindigkeitsprognose für Fahrzeuge
DE102021109126A1 (de) Verfahren zum Testen eines Produkts
DE102019213797A1 (de) Verfahren zur Bewertung einer Sequenz von Repräsentationen zumindest eines Szenarios
DE102021109131A1 (de) Verfahren zum Testen eines Produkts
WO2023041459A1 (de) Computerimplementierte verfahren und system zur anomalieerkennung und verfahren zur anomalieerkennung in einer akustischen endprüfung eines getriebes
WO2018177526A1 (de) Robustheitsanalyse bei fahrzeugen
DE102021109130A1 (de) Verfahren zum Testen eines Produkts
DE102021109127A1 (de) Verfahren zum Testen eines Produkts
DE102021109128A1 (de) Verfahren zum Testen eines Produkts
DE102020206327A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
DE102021200927A1 (de) Verfahren und Vorrichtung zur Analyse eines insbesondere in einen zumindest teilautonomen Roboter oder Fahrzeug eingebetteten Systems
DE102020205540A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
DE102020205131A1 (de) Verfahren und Vorrichtung zum Simulieren eines technischen Systems
DE102020206321A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
EP3757698A1 (de) Verfahren und vorrichtung zur bewertung und auswahl von signal-vergleichsmetriken
DE102021202335A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
EP3173928B1 (de) Verfahren und vorrichtung zum überprüfen eines komponentenfehlerbaums