DE102021109130A1 - Verfahren zum Testen eines Produkts - Google Patents

Verfahren zum Testen eines Produkts Download PDF

Info

Publication number
DE102021109130A1
DE102021109130A1 DE102021109130.6A DE102021109130A DE102021109130A1 DE 102021109130 A1 DE102021109130 A1 DE 102021109130A1 DE 102021109130 A DE102021109130 A DE 102021109130A DE 102021109130 A1 DE102021109130 A1 DE 102021109130A1
Authority
DE
Germany
Prior art keywords
simulation
classification
model
product
test
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
DE102021109130.6A
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 DE102021109130.6A priority Critical patent/DE102021109130A1/de
Publication of DE102021109130A1 publication Critical patent/DE102021109130A1/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
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3688Test management for test execution, e.g. scheduling of test suites
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3692Test management for test results analysis

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • Quality & Reliability (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Vorgestellt wird ein computerimplementiertes Verfahren zum Testen eines Produkts insbesondere einer Software, einer Hardware oder eines Systems umfassend Hardware und Software, bei welchem abhängig von Eingangsparametern für das Produkt eine Simulation durchgeführt wird, mit welcher eine bestimmte Eigenschaft des Produkts getestet wird. Abhängig von einem Vergleich eines Ergebnisses der Simulation mit einer Anforderung an die bestimmte Eigenschaft wird für das Ergebnis der 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 wird eine zweite Klassifikation ermittelt. Abhängig von der ersten Klassifikation und der zweiten Klassifikation wird eine Genauigkeit oder Robustheit der Simulation bestimmt.

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 205539 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, z.B. eines eingebetteten Systems.
  • Dabei wird ein Simulationsmodell kalibriert. Eine Streuung von Modellparametern des Simulationsmodells wird ermittelt.
  • Zur Kalibrierung des Simulationsmodells kann ein Verfahren verwendet werden, bei dem zusätzlich zu dem oder den optimalen Werten des Parameters eine Verteilung oder ein Konfidenzband ausgegeben wird. Beispiele für solche Verfahren sind Bayessche Verfahren zur Kalibrierung. Alternativ können beliebige Kalibrierungsverfahren mit Methoden wie Cross Validation kombiniert werden. Bei einer solchen Variante wird ein Konfidenzband für mindestens einen Modellparameter bestimmt. Die Streuung ergibt sich in diesem Fall durch eine angenommene Verteilung innerhalb des Konfidenzbands. Basierend auf der Streuung und der angenommenen Verteilung der Modellparameter kann eine Menge von Modellparametern bestimmt, für welche eine Simulation durchgeführt werden soll. Diese Menge kann beispielsweise mit Methoden wie der Monte Carlo Methode oder Methoden zur statistischen Versuchsplanung bestimmt werden.
  • Insbesondere für jeden Wert des Modellparameters (oder bei mehreren Parametern: jede Kombination von Werten) wird abhängig von Eingangsparametern mit dem Simulationsmodell für das Produkt eine Simulation durchgeführt, mit welcher eine bestimmte Eigenschaft des Produkts getestet wird. Abhängig von einem Vergleich eines Ergebnisses der Simulation mit einer Anforderung an die bestimmte Eigenschaft wird für das Ergebnis der 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 wird eine zweite Klassifikation ermittelt. Wird diese Vorgehensweise für jeden der vorab bestimmten Werte des Modellparameters durchgeführt, so ergibt sich für das Ergebnis der zweiten Klassifikation ebenfalls eine Verteilung und eine Streuung. Abhängig von der ersten Klassifikation, der zweiten Klassifikation, einer Streuung der zweiten Klassifikation und der Streuung der Modellparameter des Simulationsmodells wird insbesondere bewertet, ob die Genauigkeit der Modellparameter für den angestrebten Simulationszweck ausreichend ist und ob die Genauigkeit des Simulationsmodells auf Grundlage neu durchzuführender Validierungsmessungen bewertet werden kann. Die Breite der Streuung ist darüber hinaus insbesondere ein Indikator dafür, inwieweit die Genauigkeit der Simulation von der Güte der verwendeten Kalibrierungsdaten abhängt. Abhängig vom Ergebnis werden ggf. neue Messungen angefordert und eine erneute Kalibrierung des Simulationsmodells durchgeführt.
  • 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, 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 stabile und aussagekräftige Metrik zur Bestimmung der Genauigkeit und Robustheit der Simulation.
  • Mit den beschriebenen Verfahren kann insbesondere ermittelt werden, ob ausreichend viele Daten zur Modellkalibrierung und -validierung verwendet wurden, um die für den Anwendungszweck benötigte Genauigkeit des Simulationsmodells zu erreichen. Die Breite der Streuung kann darüber hinaus als Indikator dafür herangezogen werden, inwieweit die Genauigkeit der Simulation von der Güte der verwendeten Kalibrierungsdaten abhängt und die Güte der Simulationsqualität durch zusätzliche Kalibrierungsmessungen verbessert werden kann. Zudem kann mit den beschriebenen Verfahren insbesondere ermittelt werden, ob ausreichend viele Daten zur Modellkalibrierung und -validierung verwendet wurden, um die Simulations- und Modellgenauigkeit bewerten zu können. Zudem kann ermittelt werden, ob die zur Modellkalibrierung und -validierung verwendeten Szenarien oder Stimuli dazu geeignet sind, die Genauigkeit der Simulation bezüglich eines gegebenen Simulationszwecks zu bewerten (Validation of Validation). Die Modellkalibrierungen können auch in Open-Ioop-Verfahren durchgeführt werden, wenn der Simulationszweck Closed-Ioop-Simulationen erfordert. Auf diese Weise kann ein Zusammenhang zwischen der Modellkalibrierung und -validierung im Open-Ioop-Verfahren und der Simulation im Closed-Ioop-Verfahren hergestellt werden.
  • Abhängig vom Simulationszweck können Anforderungen an die Genauigkeit der Modellparameter des Simulationsmodells abgeleitet werden. Diese Anforderungen können als Stopp-Kriterien verwendet werden, um festzustellen, ob genügend Kalibriermessungen zur Modellkalibrierung verwendet wurden.
  • In einer Variante des Verfahrens können Anforderungen an die Modellkalibrierung abgeleitet werden, auch wenn für den spezifischen Simulationszweck keine Referenzdaten, sondern nur Simulationsdaten zur Verfügung stehen. Aus den Anforderungen für die maximal zulässige Streuung der Modellparameter können sich Anforderungen für den maximal zulässigen Modellfehler in zukünftigen Projekten ableiten lassen.
  • Als eine weitere Erweiterung kann eine Bewertung eines Testraums erfolgen. Das Verfahren kann dabei Indikatoren liefern, für welche Bereiche eines Testraums die Simulationsgenauigkeit durch weitere Kalibrierungstests verbessert werden kann.
  • Die beschriebenen Verfahren können insbesondere zur Bewertung der Genauigkeit einer Simulationsumgebung und der verwendeten Modelle in Bezug auf die Freigabe von Tests eingesetzt werden. Zudem kann mit ihnen auch eine Bewertung der Genauigkeit der verwendeten Modelle in einer Hardware-in-the-loop-, Model-in-the-loop-, oder Simulation-in-the-loop-Umgebung für den Test einer Diagnosefunktion oder einer Detektionsfunktion erfolgen, beispielsweise Fahrassistenzfunktionen, sicherheitskritische Funktionen oder Diagnosefunktionen in einem Steuergerät.
  • Die Verfahren ermöglichen auch eine Klassifikation einer vorgegebenen Menge von Tests oder Szenarien. Auf Grundlage dieser Klassifikation kann bewertet werden, unter welchen Randbedingungen oder für welche Art von Inputs die Simulation zu ähnlichen Ergebnissen führt wie die Realität und unter welchen Randbedingungen bzw. für welche Eingangsgrößen die verwendeten Simulationsmodelle zu ungenau sind.
  • Die beschriebenen Verfahren können auch im Kontext von SOTIF-Simulationen für automatisierte Fahrfunktionen zum Einsatz kommen.
  • Zudem kann eine Bewertung der Zuverlässigkeit einer Simulationsumgebung in Bezug auf beliebige, vom Anwender definierte Klassifikationskriterien erfolgen.
  • 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 sowie
    • 2 einen Ausschnitt aus 1 mit Details zu Block 130.
  • 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.
  • 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. Bei manchen Verfahren werden zusätzlich eine Variation bzw. ein Konfidenzband für die Werte der Modellparameter bestimmt. Ein Beispiel sind Bayessche Verfahren zur Kalibrierung.
  • Ein solches Konfidenzband kann auch mit Hilfe von Methoden wie Cross Validation bestimmt werden. Dabei werden Teilmengen der Daten gebildet, in denen jeweils ein Teil der Simulationsdaten und zugehörigen Messdaten fehlt. Für jede Teilmenge ergeben sich andere Werte für die Modellparameter. Wird die Menge aller Parameterwerte betrachtet, so kann für jeden Modellparameter eine Verteilung angegeben werden.
  • Der Test einer Funktion erfolgt üblicherweise auf Grundlage vordefinierter Szenarien- oder Testkataloge. Diese sind häufig parametrierbar. Das Ziel einer Simulation ist es, zu einem beliebigen Zeitpunkt des Entwicklungsprozesses reale Messungen einzusparen. Um die Simulationsergebnisse mit der Realität abzugleichen und die Güte der Simulation bezogen auf den konkreten Anwendungsfall bestimmen zu können, werden in der Regel reale Messungen oder andere Referenzdaten (z.B. aus Simulationen mit höherer Genauigkeit oder anderen Testplattformen wie Software in the Loop (SIL), Hardware in the Loop (HIL) oder Vehicle in the Loop (VIL)) benötigt.
  • Bislang werden die Ergebnisse solcher Simulationsmodelle 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.
  • Im Folgenden werden Beispiele für den Einsatz von Klassifikatoren bzw. Klassifikationsverfahren im Rahmen einer Verifikation oder Validierung eines Produkts beschrieben, beispielsweise für die Validierung einer eigebetteten SoftwareFunktion, 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 Klassifikatoren 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.
  • Zudem kann im Block 130 ein Klassifikator trainiert werden, der es ermöglicht, die Genauigkeit oder Robustheit der Simulation für weitere Tests oder Szenarien durchzuführen, ohne entsprechende neue Referenzmessungen durchführen zu müssen.
  • 2 zeigt einen Ausschnitt aus 1 mit Details zu Block 130.
  • In 2 sind die angebundenen Blöcke 110 und 120 und 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 in 2 einen optionalen Block 132 zum Anlernen eines Klassifikators der Simulationsgüte. Dieser Block 132 beinhaltet hierzu insbesondere einen Algorithmus zum Vergleich unterschiedlicher möglicher Klassifikatoren und zur Auswahl des Klassifikators mit der größten Genauigkeit (Feature Selection). Dieser dient dazu, das Ergebnis der Klassifikation zu optimieren. Block 132 kann zum Anlernen des Klassifikators Informationen aus Block 131 erhalten.
  • 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 den Blöcken 132 und 133 erhalten.
  • Zur Merkmalsauswahl in Block 132, der Modellerstellung in Block 133 und Berechnung von Ausgangsgrößen 140 in Block 134 verfügt Block 130 insbesondere über Algorithmen des Maschinellen Lernens und Klassifizierungsalgorithmen bzw. kann auf eine entsprechende Bibliothek zugreifen, welche diese Algorithmen umfasst.
  • Für die beschriebenen Verfahren kann wie im Folgenden im Detail ausgeführt die Simulationsumgebung als Klassifikator interpretiert werden. Die Freiheitsgrade des Klassifikators sind dann die Modellparameter der Simulationsumgebung. Die genauen Werte der Modellparameter lassen sich nicht bestimmen. Stattdessen kann für die Modellparameter lediglich eine statistische Verteilung angegeben werden. Diese Verteilung gibt das Vertrauen (Konfidenz) wieder, das dem Simulationsmodell bzw. den damit erzielten Ergebnissen entgegengebracht wird. Eine solche Verteilung lässt sich beispielsweise mit Bayesschen Verfahren zur Kalibrierung bestimmen. Alternativ können beliebige Kalibrierungsverfahren mit Methoden wie Cross Validation kombiniert werden. Bei einer solchen Variante wird ein Konfidenzband für mindestens einen Modellparameter bestimmt. Die Streuung ergibt sich in diesem Fall durch eine angenommene Verteilung innerhalb des Konfidenzbands.
  • Zu Beginn eines solchen Verfahrens kann beispielsweise der Anwender vorgeben, welche Abweichung in den Simulationsergebnissen akzeptabel ist. Daraus werden Anforderungen für die Genauigkeit der Modellparameter abgeleitet. Zwischen dieser Streuung (Konfidenz) und der Verteilung der Modellparameter wird ein Zusammenhang hergestellt. Daraus lassen sich wiederum Stoppkriterien für die Modellkalibrierung und -validierung ableiten.
  • Derartige Verfahren beruhen auf der Beobachtung, dass viele Simulationsaufgaben als Klassifikationsproblem interpretiert werden können. 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.
  • Die Simulationsergebnisse werden statistisch ausgewertet. Nach einer vom Entwickler vorgegebenen Gruppierung werden die Ergebnisse zu Verteilungen zusammengefasst Beispielsweise wird angegeben, wie viele Tests aus einer gegebenen Menge „bestanden“ und wie viele „nicht bestanden waren“. In einer Konfusionsmatrix kann darüber hinaus z.B. erfasst werden, wie viele Tests in der Simulation „bestanden“ und zugleich in den Referenzdaten „nicht bestanden“ waren.
  • Weisen die Modellparameter, wie oben beschrieben, eine Streuung auf, so besitzen auch die Simulationsergebnisse und die daraus abgeleitete Klassifikation eine Streuung. Letztere Streuung ist ein Maß für das Vertrauen, das den Simulationsergebnissen entgegengebracht werden kann. Das Ziel solcher Verfahren ist, diese zweite, alleine auf Konfidenz beruhende, Streuung auf ein akzeptables Maß zu reduzieren.
  • Bei der Ausführung können in einem einfachen Fall alle durchgeführten Tests, die zur selben Klasse zugeordnet werden, addiert werden. Das Ergebnis sind in diesem Fall skalare Werte für die jeweilige Rate, z.B.: Rate „bestanden in der Simulation und nicht bestanden in der Realität“, Rate „bestanden in der Simulation und bestanden in der Realität“ und Rate „bestanden in der Simulation und nicht bestanden in der Realität“. Für jeden Wert des oder der Modellparameter ergibt sich eine andere Rate.
  • Werden die Raten in der Konfusionsmatrix nicht durch Summierung über alle Tests bestimmt, sondern nur jeweils für verschiedene Punkte in einem Eingangsgrößenraum, so muss eine weitere Dimension des Problems betrachtet werden. Zum einen wird die Unsicherheit (Konfidenz) der Modellparameter bestimmt. Zum anderen wird für jeden möglichen Wert eines Modellparameters eine große Zahl an Simulationen durchgeführt. Für jeden Wert der Eingangsgrößenparameter werden die relevanten Raten bestimmt (z.B. Rate „falsch positiv“ oder Rate „bestanden in der Simulation und nicht bestanden in der Realität“). Anstelle der Konfusionsmatrix kann auch eine andere etablierte Metrik zur Bewertung der Klassifikatoren verwendet werden, wie beispielsweise Information Gain.
  • Der Anwender kann definieren, welche Bereiche im Eingangsgrößenraum zusammengefasst werden sollen. Für jede dieser Gruppen von Testfällen oder Szenarien ergibt sich eine Wahrscheinlichkeitsverteilung, die mit der ursprünglichen Verteilung für die Modellparameter zusammenhängt.
  • In einer ersten beispielhaften Variante der Verfahren, bei denen die Simulationsumgebung als Klassifikator interpretiert wird, werden folgende Schritte iterativ wiederholte, bis die Werte der Modellparameter konvergieren oder ein anderes, vom Benutzer definiertes Ende-Kriterium erreicht ist:
    1. 1. Bestimmung initialer Werte für die Modellparameter nach einem etablierten Kalibrierungsverfahren; Bestimmung der Streuung der Modellparameter. Um die Streuung der Parameter zu bestimmen, können Verfahren eingesetzt werden, die auf Bayesscher Kalibrierung, auf Cross Validation oder anderen ähnlichen Verfahren beruhen. Wird durch das verwendete Kalibrationsverfahren lediglich ein Konfidenzband zur Verfügung gestellt, so ergibt sich die Streuung der Modellparameter durch eine angenommene Gleichverteilung innerhalb dieses Konfidenzbands.
    2. 2. Bestimmung einer Menge von Werten für die Modellparameter, anhand derer die Simulationen durchgeführt werden sollen: Um aus der Verteilung die Menge von Modellparametern zu bestimmen, können Verfahren wie Monte Carlo Simulation, Design of Experiment oder beliebige andere statistische Verfahren verwendet werden, die bei der Festlegung von Messdaten oder der Versuchsplanung zum Einsatz kommen.
    3. 3. Durchführung von Simulationen mit den ermittelten Modellparametern. Für jedes zu simulierende Szenario wird die Simulation mehrfach wiederholt. Dabei werden die Modellparameter gemäß der bei der Modellkalibrierung bestimmten Verteilung variiert.
    4. 4. Für jede Simulation Vergleich der Simulationsergebnisse mit den zugehörigen Ergebnissen aus den Referenzdaten.
    5. 5. Für jeden möglichen Wert der Modellparameter: Erstellung einer Konfusionsmatrix und Gewichtung entsprechend der Vorgaben des Anwenders. Für jeden Eintrag in der Konfusionsmatrix ergibt sich eine Verteilung, welche aus der Unsicherheit der Modellparameter resultiert. Anstelle der Konfusionsmatrix kann zur Bewertung der Simulationsgüte auch eine beliebige andere Metrik verwendet werden, die bei der Bewertung von Klassifikatoren zum Einsatz kommt (beispielsweise Information Gain)
    6. 6. Für jeden möglichen Wert der Modellparameter: Anhand vom Nutzer vorgegebener Akzeptanzkriterien wird bestimmt, ob die Simulationsgenauigkeit (bewertet mit der Streuung der Werte in der Konfusionsmatrix) ausreichend ist.
    7. 7. Werden die Schritte 5-6 auf Grundlage aller Werte für die Modellparameter aus Schritt 2 durchgeführt, so ergibt sich für die verwendete Genauigkeitsmetrik (Einträge aus Konfusionsmatrix, Information Gain oder ähnliches Maß) eine Verteilung. Diese Streuung ist ein Maß dafür, wie gut die Güte der Simulation auf Grundlage der vorhandenen Modellkalibrierung bewertet werden kann. Darüber hinaus ist diese Streuung ein Indikator dafür, inwieweit durch neue Kalibrierungsmessungen die Güte der Simulation verbessert werden kann.
    8. 8. Anhand der in 7 berechneten Streuung wird ein Stoppkriterium berechnet. Dieses zeigt an, ob die Güte der Simulations- und Modellgenauigkeit anhand der vorhandenen Kalibrierung der Modellparameter bewertet werden kann.
    9. 9. Falls dies nicht der Fall ist: Verbesserung der Modellkalibrierung, indem z.B. weitere Messungen und Simulationen herangezogen werden.
  • In der zweiten beispielhaften Variante wird a priori eine Gleichverteilung der Modellparameter in einem gewissen Wertebereich angenommen und die Streuung der Klassifikation der Simulationsergebnisse betrachtet. Für jeden Wert der Modellparameter werden die Einträge der Konfusionsmatrix einzeln bestimmt. Aus der maximal zulässigen Unsicherheit lässt sich ableiten, in welchem Wertebereich die Modellparameter liegen müssen bzw. wie stark diese maximal streuen dürfen, um die vorgegebene Genauigkeit zu erreichen.
  • 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 beispielsweise dazu verwenden, einen Virtual Test Classifier zu trainieren oder Anforderungen an die Simulationsgenauigkeit für weitere Projekte abzuleiten.
  • Stehen keine Referenzmessungen zur Verfügung, so lassen sich in einer dritten beispielhaften Variante dennoch Anforderungen an die Genauigkeit für das verwendete Simulationsmodell aufstellen. Werden beispielsweise Tests ausgewertet und klassifiziert, so kann der Anwender fordern, dass die Zahl der als bestanden gewerteten Tests innerhalb eines gewissen Konfidenzintervalls liegt. Die beschriebenen Vorgehensweisen nach der ersten Variante und der zweiten Variante lassen sich auf diesen Anwendungsfall dann unmittelbar übertragen.
  • Im Folgenden wird eine bevorzugte Erweiterung der beschriebenen Verfahren erläutert. Wenn ein vorgegebenes Optimierungskriterium erreicht und eine Optimierung abgeschlossen wurde, können auf Grundlage der zuletzt durchgeführten Simulationen wichtige Signale aus Simulation und Referenzdaten miteinander verglichen werden. Mit Hilfe standardisierter Metriken lassen sich für jede einzelne Simulation oder für alle Simulationen in ihrer Gesamtheit (ggf. kumulierte) Modellfehler bestimmen. Ein solcher Modellfehler 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) zu trainieren.
  • In einer weiteren bevorzugten Erweiterung kann eine Bewertung des Testraums erfolgen. Liegt die Wahrscheinlichkeit für ein Attribut der Klassifikation über einem vorab definierten Konfidenz-Grenzwert, so wird das Ergebnis übernommen.
  • Das Klassifikationsergebnis wird mit dem Klassifikationsergebnis aus der Simulation verglichen und das Gesamtergebnis in die Bewertung der Simulationsgenauigkeit übernommen. Führt der Klassifikator für die verwendeten Parameter und anderen Eingangsgrößen zu keinem eindeutigen Ergebnis (d.h. für keines der möglichen Attribute ist die Wahrscheinlichkeit größer als der Grenzwert), so ist dies ein Indikator, dass für den betreffenden Test bzw. das spezifisch parametrierte Szenario weitere Referenzdaten benötigt werden. Um die Unsicherheit zu reduzieren, werden Referenzdaten für diesen Punkt im Parameterraum beziehungsweise für diese Eingangsgrößen angefordert.
  • Werden nun alle Gruppen von Testfällen betrachtet, deren Ergebnisse jeweils zusammengefast wurden, so lassen sich diejenigen Gruppen von Testfällen identifizieren, für die das Klassifikationsergebnis nicht eindeutig ist. Dies kann dem Entwickler Hinweise darüber geben, für welche Testfälle die Aussagekraft der Simulation durch Modellverbesserung oder eine verbesserte Modellkalibrierung erhöht werden könnte.
  • 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
  • Als weitere beispielhafte Anwendung soll die Genauigkeit oder Robustheit einer Simulation aus einer Simulationsumgebung für eine Diagnose- oder Detektionsfunktion bestimmt werden.
  • Die Modellparameter für das Fahrzeugmodell werden üblicherweise auf Grundlage vordefinierter Fahrmanöver im open-loop bestimmt. Mit Hilfe des vorgestellten Verfahrens wird bewertet, ob die im open-loop durchgeführten Tests ausreichen, um das Modell für den genannten Anwendungszweck ausreichend zu kalibrieren und zu validieren. Eine Anforderung des Anwenders könnte sein, dass die Zahl der Tests, die vom Simulationsmodell als „bestanden“ bewertet werden, in den Referenzdaten jedoch „nicht bestanden“ sind, mit möglichst hoher Konfidenz (d.h. mit niedriger Streuung) wiedergegeben wird. Auf diese Weise lässt sich das Risiko minimieren, dass die Simulation zu falschen Entscheidungen führt.
  • 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 gewöhnlich stark vom Anwendungsfall ab. Soll in erster Linie das Risiko minimiert werden, dass falsch negative Ereignisse auftreten, so können diese Ergebnisse entsprechend gewichtet werden. Auch in diesem Fall kann der Anwender festlegen, dass die Größen, die von besonderem Interesse sind, mit niedriger Streuung und damit mit hoher Konfidenz ausgegeben werden.
  • 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.
  • Auch in diesem Fall können abhängig von einer Konfidenzausgabe des Klassifikators geeignete Punkte für Nachmessungen oder unsichere Regionen im Parameterraum identifiziert werden. Wiederum hängt es von der Priorisierung des Benutzers ab, wie er 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.
  • 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]

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: - ein Simulationsmodell wird kalibriert, - eine Streuung oder eine Verteilung von Modellparametern des Simulationsmodells werden ermittelt, - anhand dieser Streuung oder Verteilung wird eine Menge von Modellparametern ermittelt, für die eine oder mehrere Simulationen durchgeführt werden sollen, - abhängig von Eingangsparametern und den ermittelten Modellparametern wird mit dem Simulationsmodell für das Produkt eine Simulation durchgeführt, mit welcher eine bestimmte Eigenschaft des Produkts getestet wird, - abhängig von einem Vergleich eines Ergebnisses der Simulation mit einer Anforderung an die bestimmte Eigenschaft wird für das Ergebnis der 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 wird eine zweite Klassifikation ermittelt, - Ergebnisse der zweiten Klassifikation werden mit Hilfe eines Bewertungsmaßes bewertet und die Streuung des Bewertungsmaßes über die Modellparameter wird bestimmt, - abhängig von der ersten Klassifikation, der zweiten Klassifikation und der Streuung des Bewertungsmaßes über die Modellparameter des Simulationsmodells wird bestimmt, ob eine erneute Kalibrierung des Simulationsmodells durchgeführt wird, insbesondere indem bestimmt wird, ob die Modellparameter mit ausreichender Genauigkeit bekannt sind.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass abhängig von einer ausgegebenen Wahrscheinlichkeit oder Konfidenz für das Zutreffen einer bestimmten Klassifikation eine Übernahme oder ein Verwerfen der bestimmten Klassifikation erfolgt, insbesondere abhängig von einem Vergleich der ausgegebenen Wahrscheinlichkeit oder Konfidenz mit einer vorbestimmten Schwelle.
  3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass abhängig von einer ausgegebenen Wahrscheinlichkeit oder Konfidenz eine Anforderung weiterer Referenzdaten erfolgt oder neue Referenzdaten automatisch erzeugt werden, insbesondere abhängig von einem Vergleich der Wahrscheinlichkeit oder Konfidenz mit einer vorbestimmten Schwelle.
  4. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Referenzdaten aus einem Test am realen Produkt oder aus einer Referenzsimulation stammen.
  5. 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 Simulation bestimmt wird.
  6. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die erste Klassifikation und die zweite Klassifikation jeweils umfassen, ob das Produkt den Test bestanden hat oder nicht bestanden hat oder ob der Test nicht durchgeführt wurde, insbesondere, weil für eine Durchführung des Tests spezifizierte Bedingungen nicht erfüllt waren.
  7. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die bestimmte Eigenschaft eine Diagnose- oder Detektionsfunktion umfasst und 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.
  8. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die bestimmte Eigenschaft eine sicherheitskritische Eigenschaft des Produkts umfasst und die erste Klassifikation und die zweite Klassifikation jeweils umfassen, ob ein vordefiniertes, sicherheitsrelevantes Ereignis eingetreten ist oder nicht.
  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.
DE102021109130.6A 2021-04-13 2021-04-13 Verfahren zum Testen eines Produkts Pending DE102021109130A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102021109130.6A DE102021109130A1 (de) 2021-04-13 2021-04-13 Verfahren zum Testen eines Produkts

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102021109130.6A DE102021109130A1 (de) 2021-04-13 2021-04-13 Verfahren zum Testen eines Produkts

Publications (1)

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

Family

ID=83361948

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102021109130.6A Pending DE102021109130A1 (de) 2021-04-13 2021-04-13 Verfahren zum Testen eines Produkts

Country Status (1)

Country Link
DE (1) DE102021109130A1 (de)

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

Similar Documents

Publication Publication Date Title
DE102020205539A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
DE102018128289A1 (de) Verfahren und vorrichtung für eine autonome systemleistung und zur einstufung
DE102014102551A1 (de) Maschine und Verfahren zum Evaluieren von fehlschlagenden Softwareprogrammen
DE102019209540A1 (de) Verfahren und Vorrichtung zur optimalen Aufteilung von Testfällen auf unterschiedliche Testplattformen
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
DE102019134053A1 (de) Verfahren zur kontinuierlichen Absicherung im Fahrversuch applizierter automatisierter Fahrfunktionen
AT523850B1 (de) Computergestütztes Verfahren und Vorrichtung zur wahrscheinlichkeitsbasierten Geschwindigkeitsprognose für Fahrzeuge
DE202018106888U1 (de) Testvorrichtung
DE102021109129A1 (de) Verfahren zum Testen eines Produkts
DE102021109126A1 (de) Verfahren zum Testen eines Produkts
DE102021109130A1 (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
DE102021109131A1 (de) Verfahren zum Testen eines Produkts
DE102021109128A1 (de) Verfahren zum Testen eines Produkts
DE102020206327A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
DE102021109127A1 (de) Verfahren zum Testen eines Produkts
DE102020205131A1 (de) Verfahren und Vorrichtung zum Simulieren 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
DE102020204140A1 (de) Vorrichtung und automatisiertes Verfahren zur Auswertung von Sensormesswerten und Verwendung der Vorrichtung
DE102020206321A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
EP3173928B1 (de) Verfahren und vorrichtung zum überprüfen eines komponentenfehlerbaums
DE102021202335A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems