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

Abstract

Verfahren (10) zum Prüfen eines technischen Systems, gekennzeichnet durch folgende Merkmale:- anhand gegebener Distributionen (33) werden Wertzuweisungen oder Variationen von Unsicherheitsparametern (34) des Systems berechnet,- mittels einer Simulation (11) des Systems werden Tests (12) in Variation der Unsicherheitsparameter (34) 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 unter Berücksichtigung der in der Simulation (11) oder am System beobachteten Unsicherheitsparameter (34) eine Einstufung der Tests (12) als entweder zuverlässig oder unzuverlässig 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 zuverlässig 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.
• 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. Hierbei wird ein „virtueller Test-Klassifikator“ zur Klassifikation bzw. Partitionierung von Testfällen für reale und virtuelle Tests zugrunde gelegt, 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 nachfolgend beschriebene Erweiterung berücksichtigt hierbei die inhärenten Unsicherheiten, welche jedem physikalischen System zwingend anhaften.
• Die Anwendung entsprechend erweiterter 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) und anderer kraftfahrzeugtechnischer Systeme genutzt werden, bei denen wiederholte Messungen Varianzen aufzeigen.
• Unterstützt werden ferner Simulationsmodelle, welche Unsicherheiten modellieren. Mit solchen Modellen lässt sich die Realität besser abbilden als mit Modellen, die Unsicherheiten nicht berücksichtigen. Neue Informationen liefert dem Benutzer in diesem Zusammenhang insbesondere die Berechnung der Modellunsicherheit, Anfangsbedingungen, Umgebungsparameter oder Parameterunsicherheiten des Simulationsmodells. Dadurch ergibt sich eine im Vergleich zu herkömmlichen Klassifikatoren verbesserte Aussagequalität und Entscheidungsqualität. Anstelle konventioneller Wahr-Falsch-Entscheidungen pro Test liefert die vorgeschlagene Methode etwa eine statistische Aussage bezüglich der Zuverlässigkeit des jeweiligen Tests. Der Benutzer wird zudem durch eine Visualisierung der Testfälle anhand von Konfidenzen unterstützt.
• 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 die Erzeugung der Entscheidungsgrenze des Klassifikators auf der Grundlage von Daten.
• 3 die Anwendung bzw. Berechnung von Prädiktionen des Klassifikators mit Unsicherheiten.
• 4 und 5 zwei Visualisierungen eines Klassifikationsergebnisses im ersten Quadranten eines der 1 entsprechenden Koordinatensystems.
• 6 die Visualisierung eines Klassifikationsergebnisses in einem durch die Testparameter aufgespannten Merkmalsraum.
• 7 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, eine Streuung von Unsicherheitsparametern (beim Training aus einem Intervall und bei der Prädiktion aus einer Verteilung), der Simulationsmodellfehler SMerrorX ausgewertet und die quantitative Spezifikation QSpec auf der Grundlage einer Simulation des SUT bewertet. Der virtuelle Testklassifikator verwendet als Eingabe SMerrorX, QSpec, eine Streuung der Unsicherheitsparameter und einen Schwellenwert (threshold) und trifft eine binäre Entscheidung dahingehend, ob das auf der Simulation basierende Testergebnis zuverlässig (trustworty) 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 Zuverlässigkeit 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.
• Unsicherheiten, die in der Simulation (11) modelliert werden, sind als zusätzliche Parameter modelliert (31), die abhängig oder unabhängig von den Eingabeparametern der Tests (12) die Simulation ansteuern. Die Unsicherheitsparameter (31) werden innerhalb von Intervallen oder einer Region gestreut, welche durch den Benutzer definiert wurde. Die Unsicherheitsparameter (31) können hierbei einer beliebigen Verteilung unterliegen, vorzugweise einer Gleichverteilung, jedoch muss gewährleistet sein, dass nur plausible Werte erzeugt werden, da die Entscheidungsgrenze (19) des VTC (18) durch den ungünstigsten beobachtbaren Fall (worst case) bestimmt ist. Eine Einschränkung auf plausible Werte lässt sich z. B. mit Intervallen oder Regionen modellieren. Unsicherheiten in der Messung werden berücksichtigt, indem zu jedem Test (12) eine oder mehrere reale Messungen (21) wiederholt werden (32).
• Diese Methode beruht auf der Erkenntnis, dass offene Verteilungen beim Training nicht zielführend sind. Das Training ist hier keine stochastische Methode, sondern die Berechnung des angesichts der beobachteten Samples ungünstigsten Falles. Der VTC bildet hier die Brücke zwischen Validation (Statistik) und Verifikation (kritischer oder ungünstigster Fall). Konkret reicht zum Training theoretisch ein einziges Sample aus, sofern es das richtige ist, und nur sinnvolle Samples sind zulässig, da anders als bei stochastischen Modellen erfindungsgemäß nicht gemittelt wird.
• Nimmt man beispielsweise an, dass ein Unsicherheitsparameter (31) die Streuung der Fahrzeuggeschwindigkeit betrifft. Bei einer physikalischen Verteilung ist jeder Wert unterhalb der Lichtgeschwindigkeit theoretisch möglich, wenn auch äußerst unwahrscheinlich. Bei der Worstcase-Betrachtung müsste eine Geschwindigkeit nahe der Lichtgeschwindigkeit ebenso berücksichtigt werden wie allen anderen Geschwindigkeiten, da für die Entscheidungsgrenze (19) nur der Worstcase relevant ist. Der VTC würde aufgrund eines solchen Extremfalls kein Modell als zuverlässig klassifizieren. Anders verhält es sich bei der Statistik-Berechnung in der Prädiktion: Würde hier eine Fahrzeuggeschwindigkeit nahe der Lichtgeschwindigkeit gemessen werden, wäre dieser Fall so selten, dass er das Gesamtergebnis kaum beeinflussen würde. Es sei ferner bemerkt, dass Streuung der Unsicherheitsparameter (31) sowie Wiederholungsmessungen (32) jeweils nur einmal vorliegen müssen, also auf eine Varianz der Unsicherheitsparameter oder Messungen verzichtet werden kann.
• Der Algorithmus lässt sich durch folgenden Pseudocode weiter präzisieren, wobei die Simulation (11) als „Sim“, das Erfüllungsmaß (13) als „Qspec“, der Klassifikator (18) als „VTC“, die Streuung der Unsicherheitsparameter (31) als „Real_u_Set“ und deren plausible Intervalle als „A_interval“ (30) bezeichnet werden:

Function VTC = VTC_UQ_train(Real_u_Set, Sim, Qspec, A_interval, VTC)

 QspecSimSet = empty
 QspecRealSet = empty
 For (u,real) in Real_u_Set:
      For a in A_interval:
              QspecSimSet.append(Qspec(Sim(u,a))
              QspecRealSet.append(real)
 DT_train = [QspecSimSet, QspecRealSet]
 VTC = VTC.train(DT_train) 

3 veranschaulicht die Anwendung bzw. Berechnung von Prädiktionen des Klassifikators mit Unsicherheiten. Gegeben sei hierbei ein trainierter VTC (18) mit dem zugehörigen Simulationsmodell (11), Tests (12), QSpec (13), und SMerrorX (14), ein Threshold (38), der angibt, wie viele Datenpunkte oder Variationen eines Tests mindestens positiv klassifiziert sein müssen, damit der Test insgesamt positiv klassifiziert wird, sowie Distributionen (33) für die Unsicherheitsparameter, die durch den Benutzer manuell definiert oder mit anderen Methoden automatisch ermittelt werden können.

Anhand dieser Distributionen (33) werden Werte der Unsicherheitsparameter berechnet (34). Für jeden Test (12) werden Simulation (11) und Klassifikation (18) jeweils für die Menge der Werte der Unsicherheitsparameter durchgeführt. Somit ergibt sich für jeden Test eine Menge von klassifizieren Datenpunkten im VTC-Raum. Wenn die Anzahl oder der Anteil der im Rahmen eines Tests positiv klassifizierten Punkte über dem definierten Threshold (38) liegt, dann wird der Test als zuverlässig, also positiv (39) bewertet, andernfalls negativ (40). Der Benutzer wird über diese Statistik zu jedem Test informiert (37); die statistischen Werte und konkrete Verteilung der Punkte zu einem beliebigen Test werden visualisiert (36).

Es sei bemerkt, dass, wenn im Rahmen der Berechnung (34) lediglich eine Instanz erzeugt wird, auch die Schleife (35) nur einmal ausgeführt wird.

Der Algorithmus lässt sich durch folgenden Pseudocode weiter präzisieren, wobei ferner die Distribution (33) als „f_A“, die Berechnung (34) als „f_A.get_samples()“, die Statistik (37) als „statistics“, der Schwellenwert (38) als „threshold“ und die resultierende Zuverlässigkeitsbewertung (39, 40) als „trust“ bezeichnet werden:

 Function trust, statistics = VTC_UQ_predict(u, Sim, Qspec, f_A, VTC, threshold)

 tmp = 0
 counter = 0
 For a in f_A.get samples():
        tmp = tmp + VTC.predict(Qspec(Sim(u,a)))
        counter = counter + 1
 statistics = (tmp/counter)
 trust = (statistics) > threshold

Die 4 und 5 zeigen eine erste Visualisierung (36) der Prädiktion von Testfällen unter Streuung in der Messung oder Simulation. Hier wird nur der rechte Quadrant dargestellt; in entsprechender Weise könnte jedoch auch der linke Quadrant visualisiert werden. Jede Gruppe (41, 42, 43) von Punkten entspricht einem Test (12). Die Punkte innerhalb einer Gruppe (41, 42, 43) ergeben sich durch Streuung der Unsicherheitsparameter (34). Wenn die Punkte innerhalt einer Gruppe (hier: 42) teils positiv und teils negativ prädiziert werden, dann wird die ganze Gruppe (42) positiv bewertet, wenn der Threshold wie in 4 überschritten ist, oder negativ, wenn der Threshold wie in 5 unterschritten ist.

6 skizziert eine zweite Visualisierung von Testfällen in einem durch zwei Testparameter (26, 27) aufgespannten Merkmalsraum der Testparameter (im Folgenden: „Parameterraum“) unter Streuung in der Messung oder Simulation. Die Visualisierung zeigt verschiedene Teilräume: Unzuverlässige Bereiche (15), ohne Betrachtung von Unsicherheiten als zuverlässig klassifizierte Bereiche (16) und erfindungsgemäß mit Streuung der Unsicherheitsparameter als zuverlässig klassifizierte Bereiche (17). Wie die Abbildung deutlich erkennen lässt, können sich die Klassifikationsbereiche (16, 17) der beiden Klassifikatoren (18) unterscheiden.

Die Punkte in der mit dem Bezugszeichen 23 versehenen Fläche stellen Testfälle dar, die nicht auf Grundlage von Simulationen freigegeben werden dürfen. Diese Testfälle sollten real gemessen werden. Alternativ können diese Punkte als Hinweis interpretiert werden, für welche Bereiche das Modell verbessert werden sollte. Nach einer Verbesserung des Modells sollte die Klassifikation neu vorgenommen werden.

Dieses Verfahren (10) kann beispielsweise in Software oder Hardware oder in einer Mischform aus Software und Hardware beispielsweise in einer Arbeitsstation (50) implementiert sein, wie die schematische Darstellung der 7 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]

Claims (9)

1. Verfahren (10) zum Prüfen eines technischen Systems, insbesondere eines zumindest teilautonomen Roboters oder Fahrzeuges, gekennzeichnet durch folgende Merkmale: - anhand gegebener Distributionen (33) werden Wertzuweisungen oder Variationen von Unsicherheitsparametern (34) des Systems berechnet, - mittels einer Simulation (11) des Systems werden Tests (12) in Variation der Unsicherheitsparameter (34) 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 unter Berücksichtigung der in der Simulation (11) oder durch Wiederholungen der Tests (12) am System beobachteten Unsicherheitsparameter (34) eine Einstufung der Tests (12) als entweder zuverlässig oder unzuverlässig vorgenommen.
2. Verfahren (10) nach Anspruch 1, gekennzeichnet durch folgende Merkmale: - die Einstufung 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) fallweise auf eine erste Klasse (A) mit positivem Erfüllungsmaß (13) in der Simulation (11) und den Tests (12) am System, eine zweite Klasse (B) mit positivem Erfüllungsmaß (13) in der Simulation (11) und negativem Erfüllungsmaß (13) in den Tests (12) am System, eine dritte Klasse (C) mit negativem Erfüllungsmaß (13) in der Simulation (11) und positivem Erfüllungsmaß (13) in den Tests (12) am System oder eine vierte Klasse (D) mit negativem Erfüllungsmaß (13) in der Simulation (11) und den Tests (12) am System ab und - die Einstufung 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, vorzugsweise wiederholte 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 einem der Ansprüche 1 bis 4, 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).
6. Verfahren (10) nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass eine automatische Verbesserung von durch das Prüfen erkannten Fehlern des Systems erfolgt.
7. Computerprogramm, welches eingerichtet ist, das Verfahren (10) nach einem der Ansprüche 1 bis 6 auszuführen.
8. Maschinenlesbares Speichermedium, auf dem das Computerprogramm nach Anspruch 7 gespeichert ist.
9. Vorrichtung (50), die eingerichtet ist, das Verfahren (10) nach einem der Ansprüche 1 bis 6 auszuführen.

Images