DE102020205539A1 - Verfahren und Vorrichtung zum Prüfen eines technischen Systems - Google Patents

Verfahren und Vorrichtung zum Prüfen eines technischen Systems Download PDF

Info

Publication number
DE102020205539A1
DE102020205539A1 DE102020205539.4A DE102020205539A DE102020205539A1 DE 102020205539 A1 DE102020205539 A1 DE 102020205539A1 DE 102020205539 A DE102020205539 A DE 102020205539A DE 102020205539 A1 DE102020205539 A1 DE 102020205539A1
Authority
DE
Germany
Prior art keywords
measure
simulation
tests
error
fulfillment
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
DE102020205539.4A
Other languages
English (en)
Inventor
Daniel SEILER-THULL
Thomas Heinz
Joachim Sohns
Christoph Gladisch
Philipp Glaser
Ji Su Yoon
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 DE102020205539.4A priority Critical patent/DE102020205539A1/de
Priority to US17/197,548 priority patent/US11243858B2/en
Priority to CN202110471055.0A priority patent/CN113590456A/zh
Publication of DE102020205539A1 publication Critical patent/DE102020205539A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/26—Functional testing
    • G06F11/261—Functional testing by simulating additional hardware, e.g. fault simulation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G06F11/0772—Means for error signaling, e.g. using interrupts, exception flags, dedicated error registers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/2257—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using expert systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/26—Functional testing
    • G06F11/263—Generation of test inputs, e.g. test vectors, patterns or sequences ; with adaptation of the tested hardware for testability with external testers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F18/00—Pattern recognition
    • G06F18/20—Analysing
    • G06F18/21—Design or setup of recognition systems or techniques; Extraction of features in feature space; Blind source separation
    • G06F18/217—Validation; Performance evaluation; Active pattern learning techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F18/00—Pattern recognition
    • G06F18/20—Analysing
    • G06F18/24—Classification techniques
    • G06F18/24765—Rule-based classification

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Data Mining & Analysis (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Artificial Intelligence (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Bioinformatics & Computational Biology (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Evolutionary Biology (AREA)
  • Evolutionary Computation (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Verfahren (10) zum Prüfen eines technischen Systems, gekennzeichnet durch folgende Merkmale:- mittels einer Simulation (11) des Systems werden Tests (12) durchgeführt,- die Tests (12) werden hinsichtlich eines Erfüllungsmaßes (13) einer quantitativen Anforderung an das System und eines Fehlermaßes (14) der Simulation (11) ausgewertet,- abhängig vom Erfüllungsmaß (13) und Fehlermaß (14) wird eine Einstufung (15) der Tests (12) als entweder zuverlässig (16) oder unzuverlässig (17) vorgenommen.

Description

  • Die vorliegende Erfindung betrifft ein Verfahren zum Prüfen eines technischen Systems. Die vorliegende Erfindung betrifft darüber hinaus eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium.
  • Stand der Technik
  • 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. Hinlänglich bekannt ist beispielsweise die Generierung von Testfällen aus Modellen, 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 wird 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. 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.
  • DE10303489A1 offenbart ein derartiges Verfahren zum Testen von Software einer Steuereinheit eines Fahrzeugs, eines Elektrowerkzeugs oder eines Robotiksystems, bei dem durch ein Testsystem eine von der Steuereinheit steuerbare Regelstrecke wenigstens teilweise simuliert wird, indem Ausgangssignale von der Steuereinheit erzeugt werden und diese Ausgangssignale der Steuereinheit zu ersten Hardware-Bausteinen über eine erste Verbindung übertragen werden und Signale von zweiten Hardware-Bausteinen als Eingangssignale zur Steuereinheit über eine zweite Verbindung übertragen werden, wobei die Ausgangssignale als erste Steuerwerte in der Software bereitgestellt werden und zusätzlich über eine Kommunikationsschnittstelle in Echtzeit bezogen auf die Regelstrecke zum Testsystem übertragen werden.
  • 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 von Simulationsmodellen nach dem Stand der Technik aufgrund fehlenden Vertrauens in ihre Zuverlässigkeit nur begrenzt in Freigabeentscheidungen einbezogen.
  • Offenbarung der Erfindung
  • Die Erfindung stellt ein Verfahren zum Prüfen eines technischen Systems, eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium gemäß den unabhängigen Ansprüchen bereit.
  • Der erfindungsgemäße Ansatz fußt auf der Erkenntnis, dass die Güte von Simulationsmodellen für die korrekte Vorhersagbarkeit der damit erzielbaren Testergebnisse entscheidend ist. Auf dem Gebiet des MBT beschäftigt sich die Teildisziplin der Validierung mit der Aufgabe, reale Messungen mit Simulationsergebnissen zu vergleichen. Dazu werden verschiedene Metriken, Maßzahlen oder andere Vergleicher verwendet, die Signale miteinander verknüpfen und die im Folgenden zusammenfassend als Signalmetriken (SM) bezeichnet werden sollen. Beispiele für derartige Signalmetriken sind Metriken, die Größe, Phasenverschiebung und Korrelationen vergleichen. Einige Signalmetriken sind durch einschlägige Normen definiert, z. B. gemäß
    ISO 18571.
  • Allgemeiner ausgedrückt unterstützen Unsicherheitsquantifizierungstechniken die Abschätzung der Simulations- und Modellgüte. Das Ergebnis einer Bewertung der Modellgüte unter Heranziehung einer Signalmetrik oder allgemeiner unter Verwendung einer Unsicherheitsquantifizierungsmethode für eine bestimmte Eingabe X, bei der es sich um einen Parameter oder ein Szenario handeln kann, wird nachfolgend als Simulationsmodell-Fehlermetrik - kurz: Fehlermetrik - SMerrorX bezeichnet. Zur Verallgemeinerung (Interpolation und Extrapolation) von SMerrorX für bisher nicht betrachtete Eingaben, Parameter oder Szenarien X können maschinelle Lernmodelle etwa auf der Grundlage sogenannter Gaußprozesse verwendet werden.
  • Bei der Verifizierung wird der Prüfling (system under test, SUT) typischerweise anhand einer Anforderung, Spezifikation oder Leistungskennzahl untersucht. Es ist zu beachten, dass Boolesche Anforderungen oder Spezifikationen oft in quantitative Messungen umgewandelt werden können, indem man Formalismen wie die Signal-Temporallogik (signal temporal logic, STL) verwendet. Derartige Formalismen können als Grundlage einer quantitativen Semantik dienen, die sich insofern als Verallgemeinerung der Verifikation darstellt, als ein positiver Wert die Erfüllung und ein negativer Wert die Verletzung einer Anforderung indiziert. Im Folgenden werden solche Anforderungen, Spezifikationen oder Leistungsmaße zusammenfassend als „quantitative Anforderungen“ (QSpec) bezeichnet.
  • Derlei quantitative Anforderungen können entweder anhand des realen SUT oder eines Modells desselben - gleichsam eines „virtuellen SUT“ - überprüft werden. Zum Zwecke dieser Verifikation werden Kataloge mit Testfällen zusammengestellt, denen ein SUT genügen muss, um zu entscheiden, ob es die gewünschten Leistungs- und Sicherheitseigenschaften aufweist. Ein solcher Testfall kann parametrisiert werden und so eine beliebige Anzahl von Einzeltests abdecken.
  • Vor diesem Hintergrund trägt der vorgeschlagene Ansatz dem Bedürfnis nach belastbaren Testergebnissen Rechnung, um die Leistungs- und Sicherheitseigenschaften eines SUT zu gewährleisten. Gerade bei der Durchführung von Tests anhand einer Simulation des Systems oder einer Teilkomponente - anstelle des realen Systems - gilt es sicherzustellen, dass die Simulationsergebnisse vertrauenswürdig sind.
  • Ein Ziel dieses Ansatzes besteht folglich darin, auf der Grundlage von Simulationen derart zuverlässige Testergebnisse zu erhalten, dass diese als Ersatz für reale Testfälle dienen können. Dadurch sollen die Kosten für das Testen durch die Reduzierung der Anzahl tatsächlicher Versuche gesenkt werden.
  • Gegeben sei hierbei eine Reihe von Tests, z. B. ein Testkatalog oder ein parametrischer Test, denen das SUT genügen sollte. Die vorliegende Lösung sieht eine Unterteilung der Testmenge in zwei Testsätze vor: zum einen Tests, die auf dem realen System durchgeführt werden müssen, und zum anderen Tests, die auch auf der Grundlage einer Simulation vorgenommen werden können.
  • Dabei ermöglicht der vorgeschlagene Ansatz die Beratung des Endbenutzers, ob ein virtueller Test vertrauenswürdig ist oder nicht. Beratung eines Benutzers, wenn ein Test auf dem realen System ausgeführt werden soll. Automatisches Einleiten der Ausführung eines realen Tests, wenn der virtuelle Test nicht als zuverlässig einzustufen ist.
  • Ein Vorzug der erfindungsgemäßen Lösung für diese Aufgabe besteht darin, dass sie im Gegensatz zu Konzepten, die ausschließlich auf Validierung oder ausschließlich auf Verifizierung basieren, beide Ansätze auf geschickte Weise vereint. Dazu wird ein „virtueller Test-Klassifikator“ eingeführt, welcher die Erfordernisse von Modellvalidierung und Produkttest kombiniert. Dies wird durch die Verknüpfung von Informationen aus der Validierung von Simulations- und Modellgüte (SMerrorX) einerseits und Testanforderungen (QSpec) andererseits erreicht.
  • Die Anwendung entsprechender Tests kommt auf unterschiedlichsten Feldern in Betracht. Zu denken ist beispielsweise an die funktionale Sicherheit automatisierter Systeme, wie sie etwa zur Automatisierung von Fahrfunktionen (automated driving) genutzt werden.
  • Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen des im unabhängigen Anspruch angegebenen Grundgedankens möglich. So kann eine automatisierte, computer-implementierte Testumgebung vorgesehen sein, um die Qualität der getesteten Hardware- oder Softwareprodukte weitgehend selbsttätig zu verbessern.
  • Figurenliste
  • Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:
    • 1 einen virtuellen Test-Klassifikator.
    • 2 einen ersten Ansatz zur Erzeugung der Entscheidungsgrenze des Klassifikators auf der Grundlage von Daten.
    • 3 einen zweiten Ansatz zur Erzeugung der Entscheidungsgrenze des Klassifikators auf der Grundlage einer formellen Lösung.
    • 4 die Beschreibung eines erfindungsgemäßen Verfahrens aus Anwendungssicht.
    • 5 die Visualisierung eines Klassifikationsergebnisses in einem durch die Testparameter aufgespannten Merkmalsraum.
    • 6 schematisch ein Steuergerät gemäß einer zweiten Ausführungsform.
  • Ausführungsformen der Erfindung
  • Erfindungsgemäß wird im Rahmen eines Tests X, welcher als Testfall einem Testkatalog entnommen oder als Instanz eines parametrischen Tests gewonnen werden kann, der Simulationsmodellfehler SMerrorX ausgewertet und die quantitative Spezifikation QSpec auf der Grundlage einer Simulation des SUT bewertet. Der virtuelle Testklassifikator verwendet als Eingabe SMerrorX und QSpec und trifft eine binäre Entscheidung dahingehend, ob das auf der Simulation basierende Testergebnis vertrauenswürdig ist oder nicht.
  • Gemäß dem in der Informatik und insbesondere Mustererkennung üblichen Sprachgebrauch ist als Klassifikator hierbei jedweder Algorithmus oder jedwede mathematische Funktion zu verstehen, welche einen Merkmalsraum auf eine Menge von Klassen abbildet, die im Zuge einer Klassifizierung gebildet und voneinander abgegrenzt wurden. Um entscheiden zu können, in welche Klasse ein Objekt einzustufen oder zu klassieren (umgangssprachlich auch: „klassifizieren“) ist, zieht der Klassifikator sogenannte Klassen- oder Entscheidungsgrenzen heran. Sofern eine Unterscheidung zwischen Verfahren und Instanz nicht von Bedeutung ist, wird der Begriff „Klassifikator“ in der Fachsprache und auch nachfolgend teilweise gleichbedeutend mit „Einstufung“ oder „Klassierung“ verwendet.
  • 1 illustriert eine solche Einstufung im vorliegenden Anwendungsbeispiel. Hierbei entspricht jeder Punkt einem Test, der im Wege der Simulation durchgeführt und für den das Erfüllungsmaß (13) der Anforderung QSpec sowie das Fehlermaß (14) SMerrorX berechnet wurden. QSpec ist in diesem Fall so definiert, dass es einen positiven Wert annimmt, wenn der Test vermuten lässt, dass das System der jeweiligen Anforderung genügt (Bezugszeichen 24), und negativ, wenn das System die Anforderung verfehlt (Bezugszeichen 25).
  • Wie die Abbildung erkennen lässt, unterteilt die Entscheidungsgrenze (19) des Klassifikators (18) den Raum in vier Klassen A, B, C und D. Tests der Klasse A würden vom System mit hoher Zuverlässigkeit bestanden. Für Tests der Klassen B und C liefert die Simulation lediglich unzuverlässige Ergebnisse; derartige Tests sind daher auf dem realen System durchzuführen. Tests der Klasse D würden auf dem System mit hoher Zuverlässigkeit fehlschlagen.
  • Dieser virtuelle Test-Klassifikator (18) gründet auf der Überlegung, dass eine in der Simulation nur knapp erfüllte Anforderung nur dann die Erprobung des realen Systems ersetzen kann, wenn von einem allenfalls marginalen Modellfehler (14) auszugehen ist. Andererseits kann bei einem betragsmäßig hohen Erfüllungsmaß (13) der quantitativen Anforderung QSpec, also einer bei weitem übererfüllten oder deutlich verfehlten Vorgabe, eine gewisse Abweichung der Simulationsergebnisse von entsprechenden experimentellen Messungen hingenommen werden.
  • Da diese Betrachtungsweise die Kenntnis des Modellfehlers SMerrorX des Simulationsmodells voraussetzt, wird davon ausgegangen, dass letzteres im Vorfeld der Verwendung des virtuellen Test-Klassifikators (18) einer Verifikation und Validierung unterzogen wurde. Im Rahmen dieser Validierung sollte - z. B. auf der Grundlage eines Gaußprozesses oder anderweitig durch maschinelles Lernen - ein verallgemeinertes Modell gebildet werden, das SMerrorX für ein gegebenes X liefert. Dabei ist zu beachten, dass die Vertrauenswürdigkeit der Simulation entscheidend von der Korrektheit dieses generalisierten Modells abhängt.
  • 2 verdeutlicht einen möglichen Ansatz zur Ziehung der Entscheidungsgrenze (19 - 1) des Klassifikators (18) auf der Grundlage von Daten. Im einfachsten Fall verläuft die Grenze (19) hierbei entlang einer Ursprungsgeraden. Die Steigung der Geraden ist vorzugsweise so zu wählen, dass alle Punkte, in denen sich das Erfüllungsmaß (13) der quantitativen Anforderung QSpec zwischen Simulation (11) und realer Messung (21) im Vorzeichen unterscheidet - also gleichsam alle Tests (12), bei denen das Simulationsmodell versagt -, in den Bereichen C und B liegen und diese Bereiche zudem möglichst klein sind.
  • In Betracht kommt ferner eine allgemeinere, z. B. polynomielle Entscheidungsgrenze (19), deren Funktionskurve mittels linearer Programmierung derart angepasst wird, dass sie das Kriterium eines Klassifikators (18) VTC erfüllt. Auch in diesem Fall liegen alle Punkte, in denen sich das Erfüllungsmaß (13) der quantitativen Anforderung QSpec zwischen Simulation (11) und realer Messung (21) im Vorzeichen unterscheidet - also gleichsam alle Tests (12), bei denen das Simulationsmodell versagt -, in den Bereichen C und B.
  • 3 veranschaulicht den alternativen Ansatz, den Klassifikator (18) durch das Lösen (23) eines formalen Gleichungssystems zu definieren, welchem die Definitionsgleichungen des Erfüllungsmaßes (13) und Fehlermaßes (14) zugrunde liegen. Die resultierende Funktion, welche dem aus diesen beiden Maßen gebildeten Merkmalsvektor (13, 14) einen Wahrheitswert zuordnet, lässt sich wahlweise deterministisch oder stochastisch angeben.
  • Für die Zwecke der folgenden Ausführungen seien I die Eingabemenge,
    O die - unter Umständen auch Eingaben umfassende - Ausgabemenge und m1, m2: I → O das Systemmodell und reale System als Funktionen, die lediglich für eine endliche Anzahl an Eingaben durch Simulation (11) bzw. experimentelle Messung (21) beobachtet werden können. Ferner sei q: O × O → ℝ der Simulationsmodellfehler SMerrorX, also das Abstands- oder Fehlermaß (14) zweier einander entsprechender Ausgaben. Schließlich sei Iε := {i | q(m1(i), m2(i) = ε} die Menge sämtlicher Eingaben, für welche dieses Fehlermaß (14) den Wert ε annimmt.
  • Ausgehend von diesen Definitionen kann die Abweichung des Erfüllungsmaßes (13) einer Anforderung für jede Eingabe i ∈ Iε wie folgt durch einen Term nach oben beschränkt werden, der weder von m1 noch von m2 abhängt: ∀ ∈ ∀ i ∈ I ∈ : | p ( m 1 ( i ) ) − p ( m 2 ( i ) ) | ≤ sup j ∈ I ∈ | p ( m 1 ( j ) ) − p ( m 2 ( j ) ) |                                                      ≤ sup ( o 1 , o 2 ) ∈ q − 1 ( ∈ ) | p ( o 1 ) − p ( o 2 ) |
    Figure DE102020205539A1_0001
  • Somit ergibt sich der Klassifikator (18) zu VTC ( ∈ , δ ) = { W    falls | δ | > sup ( o 1 , o 2 ) ∈ q − 1 ( ∈ ) | p ( o 1 ) − p ( o 2 ) | F    andernfalls .
    Figure DE102020205539A1_0002
  • Das Simulationsmodell wird hierbei im Fall VTC(ε, δ) = W als zuverlässig in dem Sinne eingestuft, dass m1 und m2 hinsichtlich p übereinstimmen. Es ist zu beachten, dass der Klassifikator (18) die Umkehrung von q erfordert.
  • Ein wesentlicher Vorteil dieser Darstellung besteht darin, dass der virtuelle Test-Klassifikator (18) unabhängig von m1 und m2 formuliert werden kann, da er nur vom Erfüllungsmaß (13) der quantitativen Anforderung und Fehlermaß (14) abhängt. Ausgehend von einem einzigen Fehlermaß (14) und einer Mehrzahl n quantitativer Anforderungen lassen sich somit n virtuelle Test-Klassifikatoren (18) berechnen, nämlich einer für jede Anforderung. Daher ist das Modell nur einmal in Bezug auf das Fehlermaß (14) und nicht etwa im Hinblick auf jede einzelne Anforderung zu validieren.
  • Diese Betrachtung lässt sich auf einfache Weise für eine Mehrzahl m an Fehlermaßen und eine Mehrzahl n quantitativer Anforderungen verallgemeinern, wobei m typischerweise sehr klein und n groß ausfällt. In diesem Fall können n · m virtuelle Test-Klassifikatoren (18) berechnet werden. Wenn einer dieser Klassifikatoren (18) den Wert W liefert, kann das Simulationsergebnis als zuverlässig angesehen werden. Dies ermöglicht eine präzisere Einstufung, da einige Fehlermaße (14) für bestimmte Anforderungen geeigneter sein mögen als andere.
  • Alternativ lässt sich der virtuelle Test-Klassifikator (18) in einem stochastischen Rahmen definieren, in welchem die Eingaben als - gemäß einer beliebigen Wahrscheinlichkeitsdichtefunktion - zufällig verteilt angenommen werden. Hierzu bezeichne Fε(δ) := P(|p(m1(i)) - p(m2(i))| ≤ δ |q(m1(i), m2(i)) = ε) die bedingte kumulative Verteilungsfunktion der Abweichung des Erfüllungsmaßes (13) unter der Annahme, dass das Fehlermaß (14) den Wert ε annimmt. Bei einem Schwellenwert τ ∈ (0,1) der Wahrscheinlichkeit, dass der Klassifikator (18) die richtige Entscheidung trifft - der Wert τ liegt somit typischerweise nahe 1 -, kann der virtuelle Test-Klassifikator (18) wie folgt definiert werden: VTC ( ∈ , δ ) = { W    falls | δ | > inf F ∈ − 1 ( τ ) F    andernfalls
    Figure DE102020205539A1_0003
  • 4 beleuchtet ein erfindungsgemäßes Verfahren (10) aus Anwendungssicht unter folgenden Annahmen:
    • • Ein Simulationsmodell (11) sowie eine Menge von Tests (12) mitsamt definierten Eingaben sind vorgegeben.
    • • Die Anforderungen QSpec sind quantifizierbar und vorgegeben und werden im Rahmen eines Überwachungssystems implementiert, das die Tests (12) hinsichtlich des Erfüllungsmaßes (13) dieser Anforderungen auswertet. In der Abbildung beziehen sich beide Erfüllungsmaße (13) auf dieselbe Anforderung QSpec, die jedoch einmal anhand der Simulation (11) und einmal im Wege experimenteller Messung (21) am System bewertet wird.
    • • SMerrorX ist ein Fehlermaß (14), das im Vorfeld definiert wurde. Für einige Testeingaben wurden also bereits Simulation (11) und Messung (21) durchgeführt, und das Fehlermaß (14) verallgemeinert die entsprechenden Tests (12) auf neue, bislang nicht durchgeführte Experimente mit einer gewissen Zuverlässigkeit, die z. B. durch eine Ober- und Untergrenze für das Fehlermaß (14) bestimmt wird. Für den Klassifikator (18 - 1 bis 3) wird lediglich das ungünstigste, also höchste Fehlermaß (14) herangezogen. Es sei angemerkt, dass der Klassifikator (18) zur weiteren Verfeinerung des Fehlermaßes (14) verwendet werden kann.
  • Unter diesen Annahmen mag sich das Verfahren (10) wie folgt gestalten:
    1. 1. Der Klassifikator (18) wird gemäß den obigen Erläuterungen definiert.
    2. 2. Die Tests (12) werden mittels Simulation (11) und experimenteller Messung (21) durchgeführt, wobei Ausgangssignale erzeugt werden.
    3. 3. Die Ausgangssignale werden jeweils hinsichtlich des Erfüllungsmaßes (13) der Anforderungen QSpec und des Fehlermaßes (14) der Simulation (11) gemäß dem SMerrorX-Fehlermodell ausgewertet.
    4. 4. Das einerseits in der Simulation (11) und andererseits in der Messung (21) genommene Erfüllungsmaß (13) und Fehlermaß (14) werden dem Klassifikator (18) zugeführt.
    5. 5. Für jeden Test (12) nimmt der Klassifikator (18) eine Einstufung (15) in eine der folgenden Klassen (A, B, C, D - 1) vor: Der Test (12) war in der Simulation (11) erfolgreich und sein Ergebnis ist zuverlässig (16); der Test ist in der Simulation (11) fehlgeschlagen und sein Ergebnis ist zuverlässig (16); oder das Ergebnis der Simulation (11) ist unzuverlässig (17).
    6. 6. Zuverlässige (16) Testergebnisse, für welche die Simulation (11) nunmehr als vertrauenswürdig gilt, werden einer entsprechenden Datenbank (31) hinzugefügt.
    7. 7. Unzuverlässige (17) Tests (12) können zum Anlass genommen werden, dem Benutzer die Durchführung einer entsprechenden Messung (21) am System zu empfehlen (32).
    8. 8. Optional kann eine derartige Messung (21) manuell oder automatisch eingeleitet werden.
    9. 9. Sofern die Entscheidungsgrenze (19 - 1) des Klassifikators (18), wie zu 2 erläutert auf der Grundlage von Daten gezogen wurde, kann dieser - ebenfalls optional - anhand der Ergebnisse der Messung (21) aktualisiert und mittels dieser Datenpunkte verbessert (33) werden.
  • 5 skizziert die mögliche Visualisierung eines Klassifikationsergebnisses in einem durch die Testparameter aufgespannten Merkmalsraum der Testparameter (im Folgenden: „Parameterraum“). Für bestimmte Parameter (26, 27) eines Tests (12) - abbildungsgemäß exemplarisch Abstand (26) und Masse (27) eines in die eigene Fahrspur einscherenden Fahrzeuges - werden das Erfüllungsmaß (13) und Fehlermaß (14) jeweils als Punkte im Parameterraum dargestellt. In einer virtuellen Testumgebung (29) erfolgt sodann die Visualisierung (28) der Einstufung (15) des Tests (12) durch den Klassifikator (18) im Parameterraum.
  • Dieses Verfahren (10) kann beispielsweise in Software oder Hardware oder in einer Mischform aus Software und Hardware beispielsweise in einer Arbeitsstation (30) implementiert sein, wie die schematische Darstellung der 6 verdeutlicht.
  • 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 10303489 A1 [0004]
  • Zitierte Nicht-Patentliteratur
    • ISO 18571 [0007]

Claims (11)

  1. Verfahren (10) zum Prüfen eines technischen Systems, insbesondere eines zumindest teilautonomen Roboters oder Fahrzeuges, gekennzeichnet durch folgende Merkmale: - mittels einer Simulation (11) des Systems werden Tests (12) durchgeführt, - die Tests (12) werden hinsichtlich eines Erfüllungsmaßes (13) einer quantitativen Anforderung an das System und eines Fehlermaßes (14) der Simulation (11) ausgewertet, - abhängig vom Erfüllungsmaß (13) und Fehlermaß (14) wird eine Einstufung (15) der Tests (12) als entweder zuverlässig (16) oder unzuverlässig (17) vorgenommen.
  2. Verfahren (10) nach Anspruch 1, gekennzeichnet durch folgende Merkmale: - die Einstufung (15) erfolgt durch einen Klassifikator (18) anhand eines Merkmalsvektors (13, 14) und - das Erfüllungsmaß (13) und Fehlermaß (14) bilden Komponenten des Merkmalsvektors (13, 14).
  3. Verfahren (10) nach Anspruch 2, gekennzeichnet durch folgende Merkmale: - der Klassifikator (18) bildet den Merkmalsvektor (13, 14) auf eine von mehreren Klassen (A, B, C, D) ab und - die Einstufung (15) erfolgt innerhalb vorgegebener Entscheidungsgrenzen (19) zwischen den Klassen (A, B, C, D).
  4. Verfahren (10) nach Anspruch 3, gekennzeichnet durch folgende Merkmale: - in einer Vorbereitungsphase (20) wird die Simulation (11) durch experimentelle Messung (21) am System bestätigt, - die Entscheidungsgrenzen (19) werden derart gezogen, dass das einerseits in der Simulation (11) und andererseits in der Messung (21) genommene Erfüllungsmaß (13) geringstmöglich abweicht und - vorzugsweise werden weitere in der Vorbereitungsphase (20) durchzuführende Tests (12) selbsttätig ausgewählt (22).
  5. Verfahren (10) nach Anspruch 3, gekennzeichnet durch folgende Merkmale: - der Klassifikator (18) wird durch das Lösen (23) eines Gleichungssystems definiert und - das Gleichungssystem umfasst Definitionsgleichungen des Erfüllungsmaßes (13) und Fehlermaßes (14).
  6. Verfahren (10) nach einem der Ansprüche 1 bis 5, gekennzeichnet durch folgendes Merkmal: - das Auswerten erfolgt derart, dass das Erfüllungsmaß (13) positiv ist, wenn das System der Anforderung genügt (24), und negativ, wenn das System die Anforderung verfehlt (25).
  7. Verfahren (10) nach einem der Ansprüche 1 bis 6, gekennzeichnet durch folgendes Merkmal: - für bestimmte Parameter (26, 27) der Tests (12) werden das Erfüllungsmaß (13) und Fehlermaß (14) jeweils in einem durch die Parameter (26, 27) aufgespannten Merkmalsraum dargestellt und - nach dem Auswerten erfolgt eine Visualisierung (28) der Einstufung (15) im Merkmalsraum.
  8. Verfahren (10) nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass eine automatische Verbesserung von durch das Prüfen erkannten Fehlern des Systems erfolgt.
  9. Computerprogramm, welches eingerichtet ist, das Verfahren (10) nach einem der Ansprüche 1 bis 8 auszuführen.
  10. Maschinenlesbares Speichermedium, auf dem das Computerprogramm nach Anspruch 9 gespeichert ist.
  11. Vorrichtung (30), die eingerichtet ist, das Verfahren (10) nach einem der Ansprüche 1 bis 8 auszuführen.
DE102020205539.4A 2020-04-30 2020-04-30 Verfahren und Vorrichtung zum Prüfen eines technischen Systems Pending DE102020205539A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
DE102020205539.4A DE102020205539A1 (de) 2020-04-30 2020-04-30 Verfahren und Vorrichtung zum Prüfen eines technischen Systems
US17/197,548 US11243858B2 (en) 2020-04-30 2021-03-10 Method and device for testing a technical system
CN202110471055.0A CN113590456A (zh) 2020-04-30 2021-04-29 用于检查技术系统的方法和设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102020205539.4A DE102020205539A1 (de) 2020-04-30 2020-04-30 Verfahren und Vorrichtung zum Prüfen eines technischen Systems

Publications (1)

Publication Number Publication Date
DE102020205539A1 true DE102020205539A1 (de) 2021-11-04

Family

ID=78242987

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020205539.4A Pending DE102020205539A1 (de) 2020-04-30 2020-04-30 Verfahren und Vorrichtung zum Prüfen eines technischen Systems

Country Status (3)

Country Link
US (1) US11243858B2 (de)
CN (1) CN113590456A (de)
DE (1) DE102020205539A1 (de)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021201505A1 (de) 2021-02-17 2022-08-18 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Prüfen eines technischen Systems
US20220269593A1 (en) * 2021-02-24 2022-08-25 The Boeing Company Automatic generation of integrated test procedures using system test procedures
DE102021202335A1 (de) 2021-03-10 2022-09-15 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Prüfen eines technischen Systems
DE102021109129A1 (de) 2021-04-13 2022-10-13 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Testen eines Produkts
DE102021109127A1 (de) 2021-04-13 2022-10-13 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Testen eines Produkts
DE102021109128A1 (de) 2021-04-13 2022-10-13 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Testen eines Produkts
DE102021109131A1 (de) 2021-04-13 2022-10-13 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Testen eines Produkts
DE102021109126A1 (de) 2021-04-13 2022-10-13 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Testen eines Produkts
DE102021109130A1 (de) 2021-04-13 2022-10-13 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Testen eines Produkts

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102020210563A1 (de) * 2020-08-20 2022-02-24 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zur Beurteilung von Validierungspunkten für ein Simulationsmodell
CA3146217C (en) 2021-04-12 2023-07-11 Qa Consultants Inc. System and method for integration testing

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10303489A1 (de) 2003-01-30 2004-08-12 Robert Bosch Gmbh Verfahren und Vorrichtung zum Testen von Software einer Steuereinheit eines Fahrzeugs

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9014481B1 (en) * 2014-04-22 2015-04-21 King Fahd University Of Petroleum And Minerals Method and apparatus for Arabic and Farsi font recognition
US11047806B2 (en) * 2016-11-30 2021-06-29 Kla-Tencor Corporation Defect discovery and recipe optimization for inspection of three-dimensional semiconductor structures

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10303489A1 (de) 2003-01-30 2004-08-12 Robert Bosch Gmbh Verfahren und Vorrichtung zum Testen von Software einer Steuereinheit eines Fahrzeugs

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ISO 18571

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021201505A1 (de) 2021-02-17 2022-08-18 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Prüfen eines technischen Systems
US20220269593A1 (en) * 2021-02-24 2022-08-25 The Boeing Company Automatic generation of integrated test procedures using system test procedures
US11960385B2 (en) * 2021-02-24 2024-04-16 The Boeing Company Automatic generation of integrated test procedures using system test procedures
DE102021202335A1 (de) 2021-03-10 2022-09-15 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Prüfen eines technischen Systems
DE102021109129A1 (de) 2021-04-13 2022-10-13 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Testen eines Produkts
DE102021109127A1 (de) 2021-04-13 2022-10-13 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Testen eines Produkts
DE102021109128A1 (de) 2021-04-13 2022-10-13 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Testen eines Produkts
DE102021109131A1 (de) 2021-04-13 2022-10-13 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Testen eines Produkts
DE102021109126A1 (de) 2021-04-13 2022-10-13 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Testen eines Produkts
DE102021109130A1 (de) 2021-04-13 2022-10-13 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Testen eines Produkts
US12045156B2 (en) 2021-04-13 2024-07-23 Robert Bosch Gmbh Method for testing a product

Also Published As

Publication number Publication date
CN113590456A (zh) 2021-11-02
US20210342239A1 (en) 2021-11-04
US11243858B2 (en) 2022-02-08

Similar Documents

Publication Publication Date Title
DE102020205539A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
DE102019209540A1 (de) Verfahren und Vorrichtung zur optimalen Aufteilung von Testfällen auf unterschiedliche Testplattformen
EP3709166B1 (de) Verfahren und system zur sicheren signalmanipulation für den test integrierter sicherheitsfunktionalitäten
EP3757792A2 (de) Verfahren und vorrichtung zum prüfen eines systems, zur auswahl realer tests und zum testen von systemen mit komponenten maschinellen lernens
DE102020205540A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
DE202018106888U1 (de) Testvorrichtung
DE102020206321A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
DE102009004531B4 (de) Verfahren zum Verifizieren eines Fertigungsprozesses
DE102020206327A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
DE102020205977A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
DE102020206324A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
DE102020206322A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
EP3757698A1 (de) Verfahren und vorrichtung zur bewertung und auswahl von signal-vergleichsmetriken
DE102020205527A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
DE102020206323A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
DE102021201505A1 (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
WO2015035438A1 (de) Verfahren zur verifizierung generierter software sowie verifizierungseinrichtung zum durchführen eines solchen verfahrens
DE102020205131A1 (de) Verfahren und Vorrichtung zum Simulieren eines technischen Systems
DE102021109130A1 (de) Verfahren zum Testen eines Produkts
DE102019211076A1 (de) Verfahren und Vorrichtung zum Validieren einer Simulation eines technischen Systems
DE102021109126A1 (de) Verfahren zum Testen eines Produkts
DE102021200298A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
DE102020215779A1 (de) Verfahren zur Verifizierung eines implementierten neuronalen Netzwerks
DE102021109129A1 (de) Verfahren zum Testen eines Produkts