DE102020215387A1

DE102020215387A1 - Verfahren zum Optimieren eines Testsatzes zur automatischen Qualifizierung eines virtuellen Modells für eine Kraftfahrzeugkomponente

Info

Publication number: DE102020215387A1
Application number: DE102020215387.6A
Authority: DE
Inventors: Matthias Glück; Patrick Bohle
Original assignee: Volkswagen AG
Current assignee: Volkswagen AG
Priority date: 2020-12-02
Filing date: 2020-12-04
Publication date: 2022-06-02

Abstract

Die Erfindung betrifft ein Verfahren zum Optimieren eines Testsatzes zur automatischen Qualifizierung eines virtuellen Modells zum Testen einer Kraftfahrzeugkomponente sowie ein System und ein Computerprogrammprodukt zur Durchführung eines derartigen Verfahrens. Im ersten Schritt 200 wird ein virtuelles Modell nach ISO-Norm 26262 zur Simulation der Hardware und der Software eines Steuergerätes erstellt; im zweiten Schritt 400 wird das virtuelle Modell mittels Code- und Toggle-Coverage-Metriken sowie Test-Impact-Analysen auf Lücken in der Modellabdeckung getestet und damit gezielt ein jeweils neuer optimierter Testsatz ermittelt, mit dem der zweite Verfahrensschritt wiederholt wird. Das Verfahren ermöglicht eine Angabe messbarer Qualitätsmetriken in der Modellentwicklung die für eine Qualitätsaussage für virtuelle Modelle zur Absicherung von Testprozessen benötigt werden.

Description

Die Erfindung betrifft ein Verfahren zum Optimieren eines Testsatzes zur automatischen Qualifizierung eines virtuellen Modells zum Testen einer Kraftfahrzeugkomponente und ein Verfahren zur automatischen Qualifizierung eines virtuellen Modells zum Testen einer Kraftfahrzeugkomponente. Zudem betrifft die Erfindung Systeme und ein Computerprogrammprodukt zur Durchführung derartiger Verfahren.
Nahezu alle in modernen Kraftfahrzeugen im Fahrbetrieb anfallenden Steuer- und Regelungsaufgaben werden unter Verwendung von software-basierten, zumeist elektronischen Fahrzeugkomponenten bzw. -systemen ausgeführt. Beispielhaft für die Bandbreite der von diesen Komponenten oder Systemen im typischen Fahrbetrieb wahrgenommenen Aufgaben seien nur das automatische Abblenden bei Gegenverkehr einerseits und andererseits das hochautomatisierte Fahren mit mehreren Assistenzsystemen, bei dem die Überwachung des Fahrumfeldes unter vollständiger Kontrolle durch diese Systeme erfolgt, genannt.
Die Software trägt somit in modernen Kraftfahrzeugen nicht nur zur Komfortverbesserung für den Fahrer bei, sondern liefert auch einen wichtigen Beitrag zur Unfallvermeidung und zum Insassenschutz.
Mit den neuesten Entwicklungen hin zum autonomen bzw. fahrerlosen Fahren und zur Elektromobilität geht insoweit nicht nur eine vermehrte Verwendung von software-basierten Komponenten in einem Kraftfahrzeug einher, mithin eine Zunahme des Kostenanteils derartiger Systeme an den Gesamtfahrzeugkosten. Tatsächlich ist diese Entwicklung insbesondere auch durch eine qualitative Weiterentwicklung der vorhandenen Software- und Hardware-Lösungen bestimmt, die sich allein schon aus der Zahl und Komplexität der bereits beim teilautonomen Fahren zu berücksichtigenden Probleme ergibt.
Bei Elektrofahrzeugen kommen neue, hochkomplexe Fahrzeugkomponenten und -systeme vom elektrischen Bordnetz bis zur Lenkung hinzu. Da die neuen Komponenten in Elektrofahrzeugen unterschiedlicher Leistungsklassen im Rahmen der MEB- und PPE-Projekte (MEB, Modularer E-Antriebs-Baukasten; PPE, Premium Platform Electric) der Anmelderin zum Einsatz kommen, besteht somit die Notwendigkeit, einen Funktionssicherheitsnachweis entsprechend den Anforderungen in der jeweiligen Leistungsklasse zu erbringen.
In modernen Kraftfahrzeugen muss damit nicht nur jede software-basierte Einzelkomponente per se hohe Anforderungen bezüglich ihrer Funktionssicherheit erfüllen. Die Forderung nach einer hohen Funktionssicherheit muss gleichermaßen zuverlässig von allen derartigen Komponenten im Systemverbund unter Berücksichtigung spezifischer Leistungsklassen erfüllt werden.
Dies ist durch geeignete Funktionstests der einzelnen Fahrzeugkomponenten nachzuweisen. Insbesondere zur Absicherung von autonomen Fahrfunktionen kommen bei derartigen Funktionstests virtuelle Absicherungstechniken zum Einsatz, mit denen sehr hohe Fahrleistungen in großen Computer-Farmen simuliert werden, um so die Zuverlässigkeit einer Fahrzeugkomponente nachzuweisen.
Dabei wird in bekannter Weise eine jeweils zu prüfende Systemkomponente mit geeigneten Testsignalen beaufschlagt und die Systemantwort analysiert. Entsprechend der großen Zahl einzelner Systemkomponenten in einem modernen Kraftfahrzeug sind solche Tests nicht nur aufwendig, sie sind auch kostenintensiv.
Die Durchführung dieser Tests ist in der ISO-Norm 26262 für sicherheitsrelevante elektrische oder elektronische Systeme in Kraftfahrzeugen nach einem Mehr-Ebenen-Konzept (Ebene 1 - Systemebene, Ebene 2 - Hardwareebene, Ebene 3 - Softwareebene) geregelt. Danach ist jede Fehlfunktion im Hinblick auf Schweregrad (severity), Gefährdungsgrad (exposure) und Beherrschbarkeit (controllability) im Fahrbetrieb zu analysieren und einer von insgesamt fünf entsprechenden Gefährdungsstufen QM, ASIL A, ASIL B, ASIL C , ASIL D zuzuordnen, wobei ASIL D die höchste und QM die niedrigste Gefährdungsstufe bezeichnet (ASIL - Automotive Safety Integrity Level, QM - Quality Management). Ausgehend davon sind dann die in der Norm im Einzelnen genannten Abhilfemaßnahmen vorzusehen.
Die für die virtuelle Absicherung bisher verwendeten Modelle weisen meist nur eine sehr geringe Qualität auf, was sich negativ auf die Zuverlässigkeit solcher Tests auswirkt.
Da insbesondere an Fahrzeugkomponenten zum autonomen Fahren höhere Sicherheitsanforderungen zu stellen sind, werden viele Funktionen im Fahrzeug zunehmend von einem Qualitätsmanagement-Level (QM) auf einen ASIL-Level gehoben.
Entsprechend müssen auch die für die Simulation verwendeten Modelle zur virtuellen Absicherung einer autonomen Fahrfunktion höheren Qualitätsanforderungen genügen.
Die Qualität bzw. Aussagekraft dieser Modelle wird durch den Umfang der im Einzelnen bei der Modellerstellung berücksichtigten Einflussgrößen bzw. Modellparameter bestimmt.
Entsprechend den nach dem Mehr-Ebenen-Konzept gemäß ISO-Norm 26262 bei der Entwicklung eines virtuellen Modells einer Kraftfahrzeugkomponente berücksichtigten Modellparametern, lassen sich Modelle mit unterschiedlicher Aussagekraft bzw. Qualität definieren.
In Anlehnung an die ISO-Norm 26262 werden drei Ebenen bzw. Level unterschieden, wobei Level 1 die Software-Funktionalität, Level 2 zusätzlich virtuelle Hardware-Interaktionen und Level 3 sowohl die Software- als auch die Hardware-Funktionalität einer Systemkomponente betrifft.
Die Qualität eines Modells ist somit an den Entwicklungsgrad der Modellerstellung gebunden, wobei die Aussagekraft bzw. Genauigkeit einer Level 1-Simulation entsprechend am geringsten und einer Level 3-Simulation am höchsten ist. Voraussetzung für die Verwendbarkeit eines virtuellen Modells im Produktabsicherungsprozess ist, dass es den Erfordernissen der ISO-Norm 26262 genügt. Ein derartiger Qualitätsnachweis ist nach ISO-Norm 26262-8 für jedes virtuelle Modell entsprechend dem jeweiligen Entwicklungsgrad bzw. Entwicklungsstand einer Komponente zu erbringen.
Nach dem Stand der Technik werden bei diesen Tests von Kraftfahrzeugkomponenten die im Einzelnen verwendeten virtuellen Modelle üblicherweise statischen Analysen unterzogen, die sich lediglich auf die Einhaltung der Modellierungsregeln beziehen, also auf Vergleichen ohne Berücksichtigung zeitlicher Änderungen beruhen. Eine Erfassung und Absicherung von funktionalen Zusammenhängen bzw. zeitlichen Änderungen ist nur im Rahmen zusätzlicher Tests möglich, etwa nach dem sogenannten Back-to-Back-Verfahren. Mit Testverfahren dieser Art ist es möglich, einzelne Modellversionen und Entwicklungsstände einer Komponente dynamisch zu testen.
In US 2016/0329996 A1 sind beispielsweise ein Verfahren und ein System zur statischen Analyse eines virtuellen Modells eines elektrischen Bauteils angegeben, mit dem einzelne Ausgangssignale in Abhängigkeit von simulierten Steuersignalfehlern erfasst und visualisiert werden.
Aus US 2018/0137022 A1 ist eine virtuelle Entwicklungsumgebung für den Test von Kraftfahrzeugkomponenten mit mehreren Testprogrammen zur zeitgesteuerten Fehlereinspeisung und mithin zur dynamischen Analyse bekannt. Eine Kraftfahrzeugkomponente wird hiernach mittels eines virtuellen Modells analysiert, wozu Letzteres über eine geeignete Schnittstelle mit Testprogrammen in unterschiedlichen Programmsprachen zur Simulation verschiedener Betriebszustände der Kraftfahrzeugkomponente verbunden ist.
Da mit der Entwicklung hin zum hochautomatisierten Fahren auch die Anforderungen an die Funktionssicherheit der dafür vorgesehenen Einzelkomponenten und Systeme ständig steigen, kommen herkömmliche Prüftechniken allerdings zusehends an ihre funktionalen wie auch wirtschaftlichen Grenzen. So lassen sich insbesondere autonome Fahrfunktionen aufgrund der Vielzahl und Komplexität der dabei zu berücksichtigenden Parameterkombinationen mit Prüfständen üblicher Art schon heute nicht mehr zuverlässig absichern und skalieren. Der Einsatz von virtuellen Modellen ist damit nicht nur unerlässlich bei der Entwicklung derartiger Komponenten, sondern insbesondere auch bei der Absicherung der geforderten hohen Produktqualität. Den Qualitätsmerkmalen der in den Testprozessen eingesetzten Modelle kommt somit eine entscheidende Bedeutung zu.
Es besteht somit ein Bedarf an Prüfverfahren zur Absicherung hochkomplexer Systeme und Komponenten von Kraftfahrzeugen mittels virtueller Modelle, deren Qualitätsmerkmale zur Absicherung der gestiegenen hohen Sicherheitsstandards für das hochautomatisierte Fahren, unter Berücksichtigung spezifischer Leistungsklassen, auf wirtschaftliche Weise nachweisbar sind.
Der Erfindung liegt die Aufgabe zugrunde, messbare Qualitätsmetriken in der Modellentwicklung anzugeben, die eine Qualitätsaussage für virtuelle Modelle und damit eine Absicherung von Testprozessen ermöglichen, wie sie insbesondere im Rahmen von Prüfverfahren für hochkomplexe Systeme und Komponenten von Kraftfahrzeugen zum Einsatz kommen.
Die erfindungsgemäße Aufgabe wird durch die Gegenstände der unabhängigen Patentansprüche gelöst. Bevorzugte Weiterbildungen sind Gegenstand der Unteransprüche.
Ein erster Aspekt der Erfindung betrifft ein Verfahren zum Optimieren eines Testsatzes zur automatischen Qualifizierung von virtuellen Modellen für den Test von Kraftfahrzeugkomponenten, das sich zur automatischen Skalierung komplexer Parameterkombinationen eignet. Das Verfahren eignet sich damit insbesondere zur Nutzung in Testverfahren zur Absicherung von Systemen und Komponenten von Kraftfahrzeugen nach den Sicherheitsstandards für das hochautomatisierte Fahren, auf wirtschaftliche Weise und unter Berücksichtigung spezifischer Leistungsklassen. Das erfindungsgemäße Verfahren weist die im Folgenden beschriebenen Verfahrensschritte auf.
In einem ersten Schritt wird ein Modell einer zu testenden Kraftfahrzeugkomponente ausgehend von den jeweiligen Produktanforderungen erstellt. Nahezu jede Komponente eines modernen Kraftfahrzeugs weist aus Funktions- und Sicherheitsgründen wenigstens ein elektronisches Steuergerät (ECU, electronic control unit) auf, das insoweit einen Teil der Hardware der jeweiligen Komponente bildet und das deren Software zum Zusammenwirken mit dem Steuerungssystem des Gesamtfahrzeugs bereitstellt. Eine moderne Kraftfahrzeugkomponente kann damit auch als eingebettetes System bezeichnet werden. Eine funktionale Nachbildung einer derartigen realen Kraftfahrzeugkomponente mit geeigneten Algorithmen in Form eines Computerprogramms wird als virtuelles Modell, virtuelles Steuergerät oder virtuelle ECU bezeichnet.
Das in dem ersten Verfahrensschritt erstellte virtuelle Steuergerätemodell umfasst sowohl die Software- als auch die Hardware-Funktionalität einer Systemkomponente und ist insoweit imstande, auch virtuelle Hardware-Interaktionen mit größtmöglicher Aussagekraft bzw. Genauigkeit zu erfassen. Das virtuelle Steuergerätemodell erfüllt somit die Erfordernisse der ISO-Norm 26262 Level 3 für eine Verwendung im Produktabsicherungsprozess bei der Herstellung von Kraftfahrzeugen bzw. deren Komponenten. Ein virtuelles Steuergerätemodell, das diese Anforderungen erfüllt, wird als virtuelles Steuergerätemodell, Level 3 oder virtuelles ECU-Level 3-Modell, kurz vECU, bezeichnet. Das erstellte Steuergerätemodell ist folglich als virtuelles Steuergerätemodell, vECU, nach ISO-Norm 26262 Level 3 zur Simulation der Hardware und der Software wenigstens eines Steuergerätes einer zu testenden Kraftfahrzeugkomponente geeignet.
Im zweiten Verfahrensschritt wird das virtuelle Steuergerätemodell, vECU, mittels abgesicherter Black-Box-Testverfahren nach den Anforderungsvorgaben für die Hardware und die Software des wenigstens einen Steuergerätes der zu testenden Kraftfahrzeugkomponente, und mithin unter Berücksichtigung aller vorhandenen Anforderungsangaben für ein jeweils zu testendes Produkt, in insgesamt fünf Teilschritten getestet. Entsprechende Black-Box-basierte Testverfahren sind aus der realen Produktabsicherung bekannt. Sie eignen sich sowohl zum Testen von einzelnen Komponenten eines Kraftfahrzeugs als auch zum Testen des Gesamtfahrzeugs.
In einem ersten Teilschritt des zweiten Verfahrensschritts werden zunächst Testvektoren und Stimuli bzw. Anregungen an den Schnittstellen des wenigstens einen Steuergerätes der zu testenden Kraftfahrzeugkomponente aufgenommen. Dies geschieht auf einem Prüfstand herkömmlicher Art, wobei das reale Steuergerät mit vorgegebenen Eingangswerten angesteuert wird und die dabei auftretenden Ausgangswerte erfasst werden. Die Aufnahme oder Aufzeichnung, bzw. Speicherung, der Testvektoren und Stimuli oder Anregungen, bzw. Eingangswerte, und der zugehörigen Ausgangswerte oder Erwartungswerte, bzw. Systemantworten, erfolgt mit einem geeigneten elektronischen Speichergerät, vorzugsweise einem File-Server. Aus den aufgenommenen Testvektoren, Stimuli und Erwartungswerten wird dann wenigstens ein Testsatz für das virtuelle Steuergerätemodell, vECU, erstellt und aufgezeichnet.
In einem zweiten Teilschritt des zweiten Verfahrensschritts wird der wenigstens eine Testsatz mit dem virtuellen Steuergerätemodell, vECU, abgespielt.
In einem dritten Teilschritt des zweiten Verfahrensschritts werden Model-Code-Coverage-Metriken und/oder Interface-Toggle-Metriken von mit dem Testsatz erzeugten Code-Bereichen erhoben.
Model-Code-Coverage-Metriken erfassen Bereiche im Code einer Simulation, die von einem virtuellen Steuergerätemodell, vECU, nicht angesprochen bzw. bei der Simulation nicht einbezogen werden, während nicht initialisierte Schnittstellen eines virtuellen Steuergerätemodells, vECU, mit Interface-Toggle-Metriken zu identifizieren sind.
Durch die erfindungsgemäße Verwendung dieser Metriken ist es möglich, ein virtuelles Steuergerätemodell, vECU, im Hinblick auf seine Zuverlässigkeit zu bewerten. Um die höchste Modellgüte bzw. Zuverlässigkeit zu gewährleisten, muss ein virtuelles Steuergerätemodell, vECU, demnach in der Lage sein, alle Bereiche im Code einer Simulation zu erfassen sowie alle Schnittstellen zu initialisieren.
Da das nach dem ersten Verfahrensschritt erstellte virtuelle Steuergerätemodell, vECU, einer zu testenden Kraftfahrzeugkomponente unmittelbar auf den von einer realen Kraftfahrzeugkomponente zu erfüllenden Anforderungen basiert, sind eine lückenhafte Modell-Code-Abdeckung und/oder Schnittstelleninitialisierung als Zeichen für eine unvollständige Testabdeckung zu werten. Eine unvollständige Testabdeckung durch ein virtuelles Steuergerätemodell, vECU, entspricht insoweit einem nur unvollständigen Test des realen Produkts auf einem Prüfstand und erlaubt folglich keine zuverlässige Qualitätsaussage über eine auf diese Weise getestete reale Kraftfahrzeugkomponente. Insbesondere ist ein derartiges Testergebnis nicht geeignet, die hohen Anforderungen zu erfüllen, die an die Durchführung von Tests für sicherheitsrelevante elektrische oder elektronische Systeme in Kraftfahrzeugen nach den einschlägigen Normen zu stellen sind. Es besteht somit ein Bedarf, einem derartigen Mangel abzuhelfen.
Ausgehend von den vorausgegangenen Verfahrensschritten werden dazu in einem vierten Teilschritt des vierten Verfahrensschritts die Code-Bereiche der erfassten Model-Code-Coverage-Metriken und/oder Interface-Toggle-Metriken des wenigstens einen Testsatzes aggregiert und in Form einer Model-Code-Coverage- und/oder Interface-Toggle-Landkarte bereitgestellt.
Die durch Zusammenführung der erfassten unterschiedlichen Model-Code-Coverage-Metriken und/oder Interface-Toggle-Metriken erhaltene Model-Code-Coverage- bzw. Interface-Toggle-Landkarte repräsentiert ein insoweit vervollständigtes virtuelles Steuergerätemodell, vECU, das sich, falls vollständig, für eine valide Qualitätsaussage über eine reale Kraftfahrzeugkomponente eignet.
In einem fünften Teilschritt des vierten Verfahrensschritts wird dies durch Auswertung der Coverage-Metriken auf Lücken und nicht vollständige Abdeckung hin überprüft. Im Einzelnen wird dabei jeder Bereich der vorliegenden Model-Code-Coverage- bzw. Interface-Toggle-Landkarte betrachtet und festgestellt, ob er bei der Simulation der realen Kraftfahrzeugkomponente mit dem virtuellen Steuergerätemodell, vECU, angelaufen bzw. initialisiert wird oder nicht.
Die Simulation wird hierbei als vollständig bezeichnet, wenn das virtuelle Steuergerätemodell, vECU, das funktionale Verhalten der Hardware und der Software des wenigstens einen Steuergerätes, und mithin alle möglichen Systemzustände der zu testenden Kraftfahrzeugkomponente, vollständig erfasst, so dass alle Code-Bereiche in der Model-Code-Coverage- und/oder Interface-Toggle-Landkarte vollständig abdeckt sind. Das virtuelle Steuergerätemodell, vECU, stellt in diesem Fall ein finales Gesamtmodell der zu testenden Kraftfahrzeugkomponente dar.
Wenn nach dem fünften Teilschritt des vierten Verfahrensschritts noch nicht alle Bereiche der Model-Code-Coverage- und/oder Interface-Toggle-Landkarte vollständig abdeckt sind und damit eine oder beide dieser Landkarten zumindest noch eine Lücke aufweist, die für zumindest einen nur teilweise oder nicht durchlaufenen Code-Bereich und/oder zumindest eine nicht erfolgte Schnittstelleninitialisierung beim Ablauf des virtuellen Steuergerätemodell, vECU, steht, werden verfahrensgemäß alle vorausgegangenen Teilschritte des zweiten Verfahrensschritts mit einem jeweils weiteren, modifizierten Testsatz wiederholt) wobei im ersten Teilsschritt (420) jeweils wenigstens ein modifizierter Testsatz so erstellt wird, dass in der Model-Code-Coverage- und/oder Interface-Toggle-Landkarte zumindest ein zusätzlicher Code-Bereich abgedeckt wird. Der modifizierte Testsatz wird bevorzugt auf Grund der Eigenschaften der bisher nicht abgedeckten Code-Bereiche so erzeugt, dass davon auszugehen ist, dass in der weiteren Durchführung der Teilschritte des zweiten Verfahrensschrittes zumindest einer dieser bisher nicht abgedeckten Code-Bereiche abgedeckt wird. Das wiederholte Durchlaufen dieser Teilschritte erfolgt also mit dem Ziel, zusätzliche Anregungen des virtuellen Modells aufzufinden, um die festgestellten Lücken im Testumfang zu schließen. Somit führt dieses iterative Vorgehen zu einem optimierten Testsatz, der sich für eine valide Ermittlung einer Qualitätsaussage über eine reale Kraftfahrzeugkomponente eignet. Der mit dem optimierten Testsatz durchgeführte fünfte Teilschritt des zweiten Verfahrensschritts liefert folglich einen Hinweis über die Vollständigkeit der durchgeführten Tests und damit über die Qualität des verwendeten virtuellen Steuergerätemodells, vECU.
Das erfindungsgemäße Verfahren ermöglicht auf diese Weise vorteilhaft das Erstellen von optimierten Testsätzen, die imstande sind, die Software- und Hardware-Funktionalität einer Systemkomponente unter Einbeziehung virtueller Hardware-Interaktionen mit größtmöglicher Aussagekraft bzw. Genauigkeit zu erfassen.
Ein zweiter Aspekt der Erfindung betrifft ein Verfahren zur automatischen Qualifizierung von virtuellen Modellen für den Test von Kraftfahrzeugkomponenten, das sich zur Skalierung komplexer Parameterkombinationen, und damit insbesondere zur Absicherung von Systemen und Komponenten von Kraftfahrzeugen nach den Sicherheitsstandards für das hochautomatisierte Fahren, auf wirtschaftliche Weise und unter Berücksichtigung spezifischer Leistungsklassen, eignet. Das erfindungsgemäße Verfahren weist die im Folgenden beschriebenen Verfahrensschritte auf.
In einem ersten Schritt werden verfahrensgemäß die Anforderungen an die Hardware und die Software definiert bzw. bereitgestellt, die ein Steuergerät einer zu testenden Kraftfahrzeugkomponente erfüllen muss. Im Falle eines zu testenden Systems, wie etwa eines Lenksystems für ein selbstfahrendes Kraftfahrzeug, das sich aus einer Vielzahl einzelner Komponenten zusammensetzt, müssen dementsprechend Anforderungsvorgaben für jedes einzelne Steuergerät bereitgestellt werden, das von dem System umfasst ist.
In einem zweiten Schritt wird ein Modell einer zu testenden Kraftfahrzeugkomponente ausgehend von den jeweiligen Produktanforderungen erstellt. Nahezu jede Komponente eines modernen Kraftfahrzeugs weist aus Funktions- und Sicherheitsgründen wenigstens ein elektronisches Steuergerät (ECU, electronic control unit) auf, das insoweit einen Teil der Hardware der jeweiligen Komponente bildet und das deren Software zum Zusammenwirken mit dem Steuerungssystem des Gesamtfahrzeugs bereitstellt. Eine moderne Kraftfahrzeugkomponente kann damit auch als eingebettetes System bezeichnet werden. Eine funktionale Nachbildung einer derartigen realen Kraftfahrzeugkomponente mit geeigneten Algorithmen in Form eines Computerprogramms wird als virtuelles Modell, virtuelles Steuergerät oder virtuelle ECU bezeichnet.
Das in dem zweiten Verfahrensschritt erstellte virtuelle Steuergerätemodell umfasst sowohl die Software- als auch die Hardware-Funktionalität einer Systemkomponente und ist insoweit imstande, auch virtuelle Hardware-Interaktionen mit größtmöglicher Aussagekraft bzw. Genauigkeit zu erfassen. Das virtuelle Steuergerätemodell erfüllt somit die Erfordernisse der ISO-Norm 26262 Level 3 für eine Verwendung im Produktabsicherungsprozess bei der Herstellung von Kraftfahrzeugen bzw. deren Komponenten. Ein virtuelles Steuergerätemodell, das diese Anforderungen erfüllt, wird als virtuelles Steuergerätemodell, Level 3 oder virtuelles ECU-Level 3-Modell, kurz vECU, bezeichnet. Das erstellte Steuergerätemodell ist folglich als virtuelles Steuergerätemodell, vECU, nach ISO-Norm 26262 Level 3 zur Simulation der Hardware und der Software wenigstens eines Steuergerätes einer zu testenden Kraftfahrzeugkomponente geeignet.
In einem dritten Schritt wird diese Eignung nach Maßgabe der ISO-Norm 26262 nachgewiesen. Dazu wird das virtuelle Steuergerätemodell, vECU, unter Verwendung eines Back-to-Back-Verfahrens mittels einer Vielzahl von Metriken qualifiziert. Die Systemeinbindung einzelner Modellversionen und Entwicklungsstände einer Komponente wird dabei dynamisch anhand verschiedener Metriken, bzw. mathematischer Funktionen, in Form von Kennwerten erfasst, um funktionale Zusammenhänge abzubilden und die einzelnen Wirkzusammenhänge innerhalb vorgegebener Systemgrenzen abzusichern.
Der Nachweis, dass ein virtuelles Modell in der Testabsicherung derart gestaltet und abgesichert wurde, dass mögliche Fehler im Vorgehen ausgeschlossen sind und somit die Fehlerfreiheit eines Produktes gewährleistet werden kann, wird mit dem dritten und dem darauffolgenden vierten Verfahrensschritt nach Maßgabe der ISO-Norm 26262 erbracht.
Im vierten Verfahrensschritt wird das virtuelle Steuergerätemodell, vECU, mittels abgesicherter Black-Box-Testverfahren nach den Anforderungsvorgaben für die Hardware und die Software des wenigstens einen Steuergerätes der zu testenden Kraftfahrzeugkomponente, und mithin unter Berücksichtigung aller vorhandenen Anforderungsangaben für ein jeweils zu testendes Produkt, in insgesamt sechs Teilschritten getestet. Entsprechende Black-Box-basierte Testverfahren sind aus der realen Produktabsicherung bekannt. Sie eignen sich sowohl zum Testen von einzelnen Komponenten eines Kraftfahrzeugs als auch zum Testen des Gesamtfahrzeugs.
In einem ersten Teilschritt des vierten Verfahrensschritts werden zunächst Testvektoren und Stimuli bzw. Anregungen an den Schnittstellen des wenigstens einen Steuergerätes der zu testenden Kraftfahrzeugkomponente aufgenommen. Dies geschieht auf einem Prüfstand herkömmlicher Art, wobei das reale Steuergerät mit vorgegebenen Eingangswerten angesteuert wird und die dabei auftretenden Ausgangswerte erfasst werden. Eine spezifikationsgemäße Testdurchführung ist hierbei durch die vorausgegangenen Verfahrensschritte sichergestellt. Die Aufnahme oder Aufzeichnung, bzw. Speicherung, der Testvektoren und Stimuli oder Anregungen, bzw. Eingangswerte, und der zugehörigen Ausgangswerte oder Erwartungswerte, bzw. Systemantworten, erfolgt mit einem geeigneten elektronischen Speichergerät, vorzugsweise einem File-Server.
In einem zweiten Teilschritt des vierten Verfahrensschritts wird aus den aufgenommenen Testvektoren, Stimuli und Erwartungswerten wenigstens ein Testsatz für das virtuelle Steuergerätemodell, vECU, erstellt und aufgezeichnet.
In einem dritten Teilschritt des vierten Verfahrensschritts wird der wenigstens eine Testsatz mit dem virtuellen Steuergerätemodell, vECU, abgespielt.
In einem vierten Teilschritt des vierten Verfahrensschritts werden Model-Code-Coverage-Metriken und/oder Interface-Toggle-Metriken von mit dem Testsatz erzeugten Code-Bereichen erhoben.
Model-Code-Coverage-Metriken erfassen Bereiche im Code einer Simulation, die von einem virtuellen Steuergerätemodell, vECU, nicht angesprochen bzw. bei der Simulation nicht einbezogen werden, während nicht initialisierte Schnittstellen eines virtuellen Steuergerätemodells, vECU, mit Interface-Toggle-Metriken zu identifizieren sind.
Durch die erfindungsgemäße Verwendung dieser Metriken ist es möglich, ein virtuelles Steuergerätemodell, vECU, im Hinblick auf seine Zuverlässigkeit zu bewerten. Um die höchste Modellgüte bzw. Zuverlässigkeit zu gewährleisten, muss ein virtuelles Steuergerätemodell, vECU, demnach in der Lage sein, alle Bereiche im Code einer Simulation zu erfassen sowie alle Schnittstellen zu initialisieren.
Da das nach dem zweiten Verfahrensschritt erstellte virtuelle Steuergerätemodell, vECU, einer zu testenden Kraftfahrzeugkomponente unmittelbar auf den von einer realen Kraftfahrzeugkomponente zu erfüllenden Anforderungen basiert, sind eine lückenhafte Modell-Code-Abdeckung und/oder Schnittstelleninitialisierung als Zeichen für eine unvollständige Testabdeckung zu werten. Eine unvollständige Testabdeckung durch ein virtuelles Steuergerätemodell, vECU, entspricht insoweit einem nur unvollständigen Test des realen Produkts auf einem Prüfstand und erlaubt folglich keine zuverlässige Qualitätsaussage über eine auf diese Weise getestete reale Kraftfahrzeugkomponente. Insbesondere ist ein derartiges Testergebnis nicht geeignet, die hohen Anforderungen zu erfüllen, die an die Durchführung von Tests für sicherheitsrelevante elektrische oder elektronische Systeme in Kraftfahrzeugen nach den einschlägigen Normen zu stellen sind. Es besteht somit ein Bedarf, einem derartigen Mangel abzuhelfen.
Ausgehend von den vorausgegangenen Verfahrensschritten werden dazu in einem fünften Teilschritt des vierten Verfahrensschritts die Code-Bereiche der erfassten Model-Code-Coverage-Metriken und/oder Interface-Toggle-Metriken des wenigstens einen Testsatzes aggregiert und in Form einer Model-Code-Coverage- und/oder Interface-Toggle-Landkarte bereitgestellt.
Die durch Zusammenführung der erfassten unterschiedlichen Model-Code-Coverage-Metriken und/oder Interface-Toggle-Metriken erhaltene Model-Code-Coverage- bzw. Interface-Toggle-Landkarte repräsentiert ein insoweit vervollständigtes virtuelles Steuergerätemodell, vECU, das sich, falls vollständig, für eine valide Qualitätsaussage über eine reale Kraftfahrzeugkomponente eignet.
In einem sechsten Teilschritt des vierten Verfahrensschritts wird dies durch Auswertung der Coverage-Metriken auf Lücken und nicht vollständige Abdeckung hin überprüft. Im Einzelnen wird dabei jeder Bereich der vorliegenden Model-Code-Coverage- bzw. Interface-Toggle-Landkarte betrachtet und festgestellt, ob er bei der Simulation der realen Kraftfahrzeugkomponente mit dem virtuellen Steuergerätemodell, vECU, angelaufen bzw. initialisiert wird oder nicht.
Die Simulation wird hierbei als vollständig bezeichnet, wenn das virtuelle Steuergerätemodell, vECU, das funktionale Verhalten der Hardware und der Software des wenigstens einen Steuergerätes, und mithin alle möglichen Systemzustände der zu testenden Kraftfahrzeugkomponente, vollständig erfasst, so dass alle Code-Bereiche in der Model-Code-Coverage- und/oder Interface-Toggle-Landkarte vollständig abdeckt sind. Das virtuelle Steuergerätemodell, vECU, stellt in diesem Fall ein finales Gesamtmodell der zu testenden Kraftfahrzeugkomponente dar.
Wenn nach dem sechsten Teilschritt des vierten Verfahrensschritts noch nicht alle Bereiche der Model-Code-Coverage- und/oder Interface-Toggle-Landkarte vollständig abdeckt sind und damit eine oder beide dieser Landkarten zumindest noch eine Lücke aufweist, die für zumindest einen nur teilweise oder nicht durchlaufenen Code-Bereich und/oder zumindest eine nicht erfolgte Schnittstelleninitialisierung beim Ablauf des virtuellen Steuergerätemodell, vECU, steht, werden verfahrensgemäß alle vorausgegangenen Teilschritte des vierten Verfahrensschritts mit einem jeweils weiteren, modifizierten Testsatz solange wiederholt, bis alle Code-Bereiche in der Model-Code-Coverage- und/oder Interface-Toggle-Landkarte vollständig abgedeckt sind. Das wiederholte Durchlaufen dieser Teilschritte erfolgt also mit dem Ziel, zusätzliche Anregungen des virtuellen Modells aufzufinden, um die festgestellten Lücken im Testumfang zu schließen. Somit führt auch dieses iterative Vorgehen zu einem finalen Gesamtmodell, das sich für eine valide Qualitätsaussage über eine reale Kraftfahrzeugkomponente eignet. Der sechste Teilschritt des vierten Verfahrensschritts liefert folglich einen Hinweis über die Vollständigkeit der durchgeführten Tests und damit über die Qualität des verwendeten virtuellen Steuergerätemodells, vECU.
Das erfindungsgemäße Verfahren ermöglicht auf diese Weise eine gezielte Vervollständigung eines verwendeten virtuellen Steuergerätemodells, vECU, und das Erstellen von Testsätzen, die imstande sind, die Software- und Hardware-Funktionalität einer Systemkomponente unter Einbeziehung virtueller Hardware-Interaktionen mit größtmöglicher Aussagekraft bzw. Genauigkeit zu erfassen.
Um dies nachzuweisen, müssen die mithilfe des virtuellen Steuergerätemodells, vECU, gewonnenen Testergebnisse mit den entsprechenden Testergebnissen der realen Kraftfahrzeugkomponente übereinstimmen. Dieser Nachweis wird in einem fünften Verfahrensschritt erbracht. Dabei werden die mit dem finalen virtuellen Steuergerätemodell, vECU, erhaltenen Testergebnisse durch Vergleichstests mit der realen Kraftfahrzeugkomponente auf einem Prüfstand verifiziert.
In einem sechsten Schritt wird schließlich das finale virtuelle Steuergerätemodell, vECU, für eine automatische Qualifizierung der Hardware und der Software wenigstens eines Steuergerätes einer zu testenden Kraftfahrzeugkomponente nach ISO-Norm 26262 bereitgestellt.
Virtuelle Modelle von Kraftfahrzeugkomponenten, die nach dem erfindungsgemäßen Verfahren qualifiziert sind, eignen sich somit zur Verwendung in allen Steuergeräteprojekten, unabhängig von der Einstufung der funktionalen Sicherheit.
Durch die mit dem erfindungsgemäßen Verfahren sichergestellte Vergleichbarkeit von virtuellen und realen Testergebnissen, und mithin von virtuellem und realem Prüfverfahren, und die erfindungsgemäße Verwendung von Model-Code-Coverage- bzw. Interface-Toggle-Metriken, wird eine automatische Testvervollständigung ermöglicht und ein Nachweis über die Vollständigkeit des Testumfangs erbracht, der somit die Vorgaben der ISO-Norm 26262 Level 3 für den Test von Kraftfahrzeugkomponenten automatisch erfüllt und damit eine automatische ISO 26262-Qualifizierung ermöglicht.
Ein weiterer Aspekt der Erfindung betrifft ein System zum Optimieren eines Testsatzes zur automatischen Qualifizierung von virtuellen Steuergerätemodellen, vECU, für den Test von Kraftfahrzeugkomponenten nach der ISO-Norm 26262, das nach einem erfindungsgemäßen Verfahren, wie vorstehend beschrieben, ausgebildet ist.
Das System weist sechs Systemeinheiten zur Durchführung des erfindungsgemäßen Verfahrens auf.
Eine erste Systemeinheit ist für den Test der Hardware und Software wenigstens eines Steuergerätes einer zu testenden Kraftfahrzeugkomponente, bzw. eines Prüflings, mit einem Prüfstand oder mit mehreren Prüfständen für Kraftfahrzeugkomponenten oder Kraftfahrzeuge mittels abgesicherter Black-Box-Tests ausgebildet. Die erste Systemeinheit ermöglicht somit ein Anregen eines realen Prüflings mit Testvektoren und Stimuli, und eine Prüfung der daraus resultierenden Antworten auf eine Einhaltung von Erwartungswerten.
Eine zweite Systemeinheit ist vorgesehen, um die in der ersten Systemeinheit beim Test des realen Prüflings verwendeten Testvektoren und Stimuli aufzuzeichnen und für eine weitere Verwendung bereitzustellen. Die zweite Systemeinheit umfasst dazu zumindest einen File-Server mit einer geeigneten Software.
Eine dritte Systemeinheit ist zum Erstellen eines Testsatzes anhand der von der zweiten Systemeinheit bereitgestellten Testvektoren und Stimuli, zum Anwenden des Testsatzes auf ein virtuelles Steuergerätemodell, vECU, und zum Vergleichen der Modell-Antworten mit den anhand der ersten Systemeinheit erfassten Antworten wenigstens einer entsprechenden realen Kraftfahrzeugkomponente ausgebildet. Die dritte Systemeinheit umfasst dazu wenigstens ein erstes Computersystem mit einer geeigneten Software, welches ermöglicht, die von dem File-Server der zweiten Systemeinheit bereitgestellten Anregungsszenarien und Antworten auf das virtuelle Modell anzuwenden und die Antworten des virtuellen Modells mit den aufgezeichneten Antworten der realen Kraftfahrzeugkomponente zu vergleichen.
Eine vierte Systemeinheit umfasst wenigstens ein zweites Computersystem zum Abspielen des Testsatzes mit dem ebenfalls von der dritten Systemeinheit bereitgestellten virtuellen Steuergerätemodell, vECU, mittels eines Vektor-Replay-Verfahrens und mit einer geeigneten Software zum Erfassen von Model-Code-Coverage-Metriken und Interface-Toggle-Metriken von Code-Bereichen, die mit Hilfe des Testsatzes erzeugt wurden, zum Aggregieren der erzeugten Code-Bereiche der erfassten Model-Code-Coverage-Metriken und Interface-Toggle-Metriken des Testsatzes in einer Model-Code-Coverage-Landkarte bzw. Interface-Toggle-Landkarte und zum Bewerten des Testsatzes mittels einer Test-Impact-Analyse.
Eine fünfte Systemeinheit weist wenigstens ein drittes Computersystem mit einer geeigneten Software auf, das zum Überprüfen des mit dem virtuellen Steuergerätemodell, vECU, der dritten Systemeinheit möglichen Testumfangs gegenüber dem, mit der ersten Systemeinheit festgelegten, Testumfang der realen Kraftfahrzeugkomponente ausgebildet ist. Die fünfte Systemeinheit ist mithin insbesondere zum Überprüfen des mit dem virtuellen Steuergerätemodell, vECU, simulierten Verhaltens der Hardware und Software des wenigstens einen Steuergerätes der zu testenden Kraftfahrzeugkomponente auf Vollständigkeit in Bezug auf einen vorgegebenen Testumfang ausgebildet.
Darüber hinaus ist das wenigstens eine dritte Computersystem der fünften Systemeinheit mit einer geeigneten Software zur iterativen Durchführen von Testaktualisierungen unter Einbeziehung der ersten bis fünften Systemeinheit vorgesehen.
Die fünfte Systemeinheit ist insoweit zur Unterstützung bei der Entwicklung von Tests für damit erfasste Lücken im Testumfang des von der dritten Systemeinheit bereitgestellten virtuellen Modells geeignet, wie auch für eine eventuell erforderliche Testaktualisierung zum Schließen der festgestellten Testlücken anhand neuer Testinhalte bzw. Testsätze.
Ein sechste Systemeinheit umfasst wenigstens ein viertes Computersystem mit einer geeigneten Software zur Steuerung von Testwiederholungen, unter Einbeziehung der ersten bis fünften Steuereinheit, ausgebildet.
Ein weiterer Aspekt der Erfindung betrifft ein System zur automatischen Qualifizierung von virtuellen Steuergerätemodellen, vECU, für den Test von Kraftfahrzeugkomponenten nach der ISO-Norm 26262, das nach einem erfindungsgemäßen Verfahren, wie vorstehend beschrieben, ausgebildet ist.
Das System weist sechs Systemeinheiten zur Durchführung des erfindungsgemäßen Verfahrens auf.
Eine erste Systemeinheit ist für den Test der Hardware und Software wenigstens eines Steuergerätes einer zu testenden Kraftfahrzeugkomponente, bzw. eines Prüflings, mit einem Prüfstand oder mit mehreren Prüfständen für Kraftfahrzeugkomponenten oder Kraftfahrzeuge mittels abgesicherter Black-Box-Tests ausgebildet. Die erste Systemeinheit ermöglicht somit ein Anregen eines realen Prüflings mit Testvektoren und Stimuli, und eine Prüfung der daraus resultierenden Antworten auf eine Einhaltung von Erwartungswerten.
Eine zweite Systemeinheit ist vorgesehen, um die in der ersten Systemeinheit beim Test des realen Prüflings verwendeten Testvektoren und Stimuli aufzuzeichnen und für eine weitere Verwendung bereitzustellen. Die zweite Systemeinheit umfasst dazu zumindest einen File-Server mit einer geeigneten Software.
Eine dritte Systemeinheit ist zum Erstellen eines Testsatzes anhand der von der zweiten Systemeinheit bereitgestellten Testvektoren und Stimuli, zum Anwenden des Testsatzes auf ein virtuelles Steuergerätemodell, vECU, und zum Vergleichen der Modell-Antworten mit den anhand der ersten Systemeinheit erfassten Antworten wenigstens einer entsprechenden realen Kraftfahrzeugkomponente ausgebildet. Die dritte Systemeinheit umfasst dazu wenigstens ein erstes Computersystem mit einer geeigneten Software, welches ermöglicht, die von dem File-Server der zweiten Systemeinheit bereitgestellten Anregungsszenarien und Antworten auf das virtuelle Modell anzuwenden und die Antworten des virtuellen Modells mit den aufgezeichneten Antworten der realen Kraftfahrzeugkomponente zu vergleichen..
Eine vierte Systemeinheit umfasst wenigstens ein zweites Computersystem zum Abspielen des Testsatzes mit dem ebenfalls von der dritten Systemeinheit bereitgestellten virtuellen Steuergerätemodell, vECU, mittels eines Vektor-Replay-Verfahrens und mit einer geeigneten Software zum Erfassen von Model-Code-Coverage-Metriken und Interface-Toggle-Metriken von Code-Bereichen, die mit Hilfe des Testsatzes erzeugt wurden, zum Aggregieren der erzeugten Code-Bereiche der erfassten Model-Code-Coverage-Metriken und Interface-Toggle-Metriken des Testsatzes in einer Model-Code-Coverage-Landkarte bzw. Interface-Toggle-Landkarte und zum Bewerten des Testsatzes mittels einer Test-Impact-Analyse.
Eine fünfte Systemeinheit weist wenigstens ein drittes Computersystem mit einer geeigneten Software auf, das zum Überprüfen des mit dem virtuellen Steuergerätemodell, vECU, der dritten Systemeinheit möglichen Testumfangs gegenüber dem, mit der ersten Systemeinheit festgelegten, Testumfang der realen Kraftfahrzeugkomponente ausgebildet ist. Die fünfte Systemeinheit ist mithin insbesondere zum Überprüfen des mit dem virtuellen Steuergerätemodell, vECU, simulierten Verhaltens der Hardware und Software des wenigstens einen Steuergerätes der zu testenden Kraftfahrzeugkomponente auf Vollständigkeit in Bezug auf einen vorgegebenen Testumfang ausgebildet.
Darüber hinaus ist das wenigstens eine dritte Computersystem der fünften Systemeinheit mit einer geeigneten Software zur iterativen Durchführen von Testaktualisierungen unter Einbeziehung der ersten bis fünften Systemeinheit vorgesehen.
Die fünfte Systemeinheit ist insoweit zur Unterstützung bei der Entwicklung von Tests für damit erfasste Lücken im Testumfang des von der dritten Systemeinheit bereitgestellten virtuellen Modells geeignet, wie auch für eine eventuell erforderliche Testaktualisierung zum Schließen der festgestellten Testlücken anhand neuer Testinhalte bzw. Testsätze.
Ein sechste Systemeinheit umfasst wenigstens ein viertes Computersystem mit einer geeigneten Software zum Verifizieren der mit dem finalen virtuellen Steuergerätemodell, vECU, erhaltenen Testergebnisse durch Vergleichstests mit der realen Kraftfahrzeugkomponente auf einem Prüfstand. Darüber hinaus ist das von der sechsten Systemeinheit umfasste Computerprogramm zur Steuerung von Testwiederholungen, unter Einbeziehung der ersten bis fünften Steuereinheit, ausgebildet.
Ein weiterer Aspekt der Erfindung betrifft ein Computerprogrammprodukt, das einen computerlesbaren Programmcode bzw. computerlesbare Befehle umfasst, bei dessen bzw. deren Ausführung durch einen Computer dieser veranlasst wird, ein erfindungsgemäßes Verfahren zum Optimieren eines Testsatzes wie vorstehend beschrieben, durchzuführen. Noch ein weiterer Aspekt der Erfindung betrifft ein computerlesbares Speichermedium, umfassend ein Computerprogrammprodukt, das Befehle umfasst, bei deren Ausführung durch einen Computer dieser veranlasst wird, ein erfindungsgemäßes Verfahren zum Optimieren eines Testsatzes, wie vorstehend beschrieben durchzuführen. Das Speichermedium kann ein flüchtiger Speicher oder ein nicht-flüchtiger Speicher sein.
Ein weiterer Aspekt der Erfindung betrifft ein Computerprogrammprodukt, das einen computerlesbaren Programmcode bzw. computerlesbare Befehle umfasst, bei dessen bzw. deren Ausführung durch einen Computer dieser veranlasst wird, ein erfindungsgemäßes Verfahren zur automatischen Qualifizierung eines virtuellen Modells einer Kraftfahrzeugkomponente wie vorstehend beschrieben, durchzuführen. Noch ein weiterer Aspekt der Erfindung betrifft ein computerlesbares Speichermedium, umfassend ein Computerprogrammprodukt, das Befehle umfasst, bei deren Ausführung durch einen Computer dieser veranlasst wird, ein erfindungsgemäßes Verfahren zur automatischen Qualifizierung eines virtuellen Modells einer Kraftfahrzeugkomponente, wie vorstehend beschrieben durchzuführen. Das Speichermedium kann ein flüchtiger Speicher oder ein nicht-flüchtiger Speicher sein.
Bevorzugte Ausgestaltungen der Erfindung ergeben sich aus den übrigen, in den Unteransprüchen genannten Merkmalen.
In einer bevorzugter Ausgestaltung des erfindungsgemäßen Verfahrens erfolgt das Erstellen des virtuellen Steuergerätemodells, vECU, unter Verwendung von Matlab/Simulink, S-Funktionen und/oder Functional Mockup Units, FMU.
Matlab/Simulink ist ein Softwareprodukt der Firma The MathWorks zur System-Modellierung. Mittels S-Funktionen kann zusätzlicher Code in ein mit Matlab/Simulink erstelltes Modell integriert werden. Functional Mockup Units, FMU, stellen standardisierte Schnittstellen dar, die es erlauben, nicht auf Matlab/Simulink basierende Modelle in ein damit erstelltes virtuelles Modell zu integrieren.
In einer weiteren bevorzugten Durchführungsform des erfindungsgemäßen Verfahrens wird das virtuelle Steuergerätemodell, vECU, nach ISO-Norm 26262 Level 3 zur Simulation der Hardware und der Software des wenigstens einen Steuergerätes der zu testenden Kraftfahrzeugkomponente unter Einbeziehung von ausführbarem Code von kompilierten Programmen durchgeführt.
Zudem ist es bevorzugt, das Qualifizieren des virtuellen Steuergerätemodells, vECU, nach dem erfindungsgemäßen Verfahren unter Verwendung eines Back-to-Back-Verfahrens nach ISO-Norm 26262, Teil 8 mittels einer Vielzahl von Metriken durchzuführen.
Darüber hinaus werden in einer weiteren bevorzugten Durchführungsform des erfindungsgemäßen Verfahrens die zum Testen des virtuellen Steuergerätemodells, vECU, verwendeten Black-Box-Tests nach Maßgabe der ISO-Norm 26262 entwickelt und abgesichert. Alternativ ist es entweder bevorzugt, die Black-Box-Tests nach Maßgabe der Automotive Norm ASpice oder nach Maßgabe beider Normen, ISO 26262 und ASpice, zu entwickeln und abzusichern.
In einer weiteren bevorzugten Ausgestaltung des erfindungsgemäßen Verfahrens wird das virtuelle Steuergerätemodell, vECU, für eine Test-Impact-Analyse zur Priorisierung neuer Testsätze verwendet, um die funktionale Qualität eines aktualisierten virtuellen Modells, vECU, abzusichern.
In einer besonders bevorzugten Durchführungsform des erfindungsgemäßen Verfahrens wird der Nachweis einer funktionalen Vergleichbarkeit von Testergebnissen, die mit simulierten Kraftfahrzeugkomponenten gewonnen wurden und von Testergebnissen, die mittels realer Kraftfahrzeugkomponenten auf Prüfständen gewonnen wurden, unter Verwendung eines Vektor-Replay-Verfahrens erbracht. Das Vektor-Replay-Verfahren wird insoweit zur Bestimmung der Genauigkeit von virtuellen Steuergerätemodellen, vECU, und mithin zu deren Qualifizierung erfindungsgemäß eingesetzt.
Darüber hinaus wird in weiterer bevorzugter Ausgestaltung der Erfindung das virtuelle Steuergerätemodell, vECU, zur automatischen Qualifizierung, insbesondere zur automatischen Qualifizierung nach der ISO-Norm 26262, der Hardware und/oder der Software wenigstens eines Steuergerätes wenigstens einer Kraftfahrzeugkomponente, verwendet.
Die verschiedenen in dieser Anmeldung genannten Ausführungsformen der Erfindung sind, sofern im Einzelfall nicht anders ausgeführt, mit Vorteil miteinander kombinierbar.
Die Erfindung wird nachfolgend in Ausführungsbeispielen anhand der zugehörigen Zeichnungen weitergehend erläutert. Es zeigen:

1 ein schematisches Ablaufdiagramm der Verfahrensschritte des erfindungsgemäßen Verfahrens;
2 eine Anordnung zur Durchführung des erfindungsgemäßen Vektor-Replay-Verfahrens;
3 ein einfaches virtuelles Modell für eine beispielhafte Code-Coverage-/Toggle-Coverage-Analyse;
4 ein Beispiel einer nach dem erfindungsgemäßen Verfahren erstellten Code-Coverage-/Toggle-Coverage-Landkarte;
5 ein Beispiel einer Test-Impact-Analyse zur Modellanpassung nach dem erfindungsgemäßen Verfahren unter Verwendung der Code-Coverage-/Toggle-Coverage-Landkarte gemäß 4;
6 eine schematische Darstellung eines Systems zur automatischen Qualifizierung eines virtuellen Modells zum Testen einer Kraftfahrzeugkomponente nach dem erfindungsgemäßen Verfahren.

1 zeigt beispielhaft die einzelnen Verfahrensschritte des erfindungsgemäßen Verfahrens.
In einem ersten Verfahrensschritt 100 werden die von einer zu testenden Kraftfahrzeugkomponente zu erfüllenden Anforderungen vorgegeben. Im Einzelnen werden hierbei die Anforderungsvorgaben für die Hardware und die Software eines zu testenden Steuergerätes bereitgestellt.
In einem zweiten Verfahrensschritt 200 wird ein virtuelles Steuergerätemodell, vECU, nach Maßgabe der ISO-Norm 26262 Level 3 zur Simulation der Hardware und der Software des Steuergerätes der zu testenden Kraftfahrzeugkomponente erstellt.
In einem dritten Verfahrensschritt 300 wird das virtuelle Steuergerätemodell, vECU, der zu testenden Kraftfahrzeugkomponente qualifiziert. Dazu werden unter Verwendung eines Back-to-Back-Verfahrens eine Vielzahl von Kenngrößen bzw. Metriken erfasst.
In einem vierten Verfahrensschritt 400 wird das virtuelle Steuergerätemodell, vECU, mit abgesicherten Black-Box-Tests anhand der zuvor bereitgestellten Anforderungsvorgaben für die Hardware und für die Software des wenigstens einen Steuergerätes der zu testenden Kraftfahrzeugkomponente geprüft.
Die Prüfung des virtuellen Steuergerätemodells, vECU, wird erfindungsgemäß in sechs Teilschritten 410-460 durchgeführt:

Im ersten Teilschritt 410 werden Testvektoren und Stimuli an den Schnittstellen des Steuergerätes der zu testenden Kraftfahrzeugkomponente aufgenommen.

Im zweiten Teilschritt 420 wird anhand der aufgenommenen Testvektoren und Stimuli ein Testsatzes erstellt.
Im dritten Teilschritt 430 wird der Testsatz mittels eines Vektor-Replay-Verfahrens mit dem virtuellen Steuergerätemodell, vECU, abgespielt.
Im vierten Teilschritt 440 werden Model-Code-Coverage-Metriken von den, mit dem Testsatz erzeugten 23 Code-Bereichen erfasst.
Im fünften Teilschritt 450 werden die 23 erzeugten Code-Bereiche der erfassten Model-Code-Coverage-Metriken und/oder Interface-Toggle-Metriken des Testsatzes in einer Model-Code-Coverage- und/oder Interface-Toggle-Landkarte 40 aggregiert.
Im sechsten Teilschritt 460 wird das mit dem virtuellen Steuergerätemodell, vECU, simulierte funktionale Verhalten der Hardware und der Software des Steuergerätes der zu testenden Kraftfahrzeugkomponente auf Vollständigkeit überprüft. Dazu wird die Model-Code-Coverage- und/oder Interface-Toggle-Landkarte 40 analysiert.
Werden in der Model-Code-Coverage- und/oder Interface-Toggle-Landkarte 40 dabei Bereiche ohne oder mit nur teilweiser Abdeckung festgestellt, werden die Verfahrensschritte 410-460 mit jeweils einem veränderten Testsatz solange wiederholt, bis alle Code-Bereiche in der Model-Code-Coverage- und/oder Interface-Toggle-Landkarte 40 abgedeckt sind.
Wenn dies zutrifft, muss in einem fünften Verfahrensschritt 500 das mit dem somit finalen virtuellen Steuergerätemodell, vECU, erhaltene, und mittels der Model-Code-Coverage- und/oder Interface-Toggle-Landkarte 40 dokumentierte Testergebnis anhand von Vergleichstests mit der betreffenden realen Kraftfahrzeugkomponente auf einem Prüfstand verifiziert werden.
Stimmen die realen und die simulierten Testergebnisse überein, wird das finale virtuelle Steuergerätemodell, vECU, in einem sechsten Verfahrensschritt 600 für eine automatische Qualifizierung der Hardware und der Software von Steuergeräten zu testender Kraftfahrzeugkomponenten nach ISO-Norm 26262 bereitgestellt.
2 zeigt eine Anordnung 20 zur Durchführung des erfindungsgemäßen Vektor-Replay-Verfahrens, umfassend einen Prüfstand 22 mit einer realen Kraftfahrzeugkomponente 21 mit einem Steuergerät, einem File-Server 23, einem Computer 25 mit einem darauf gespeicherten ausführbaren virtuellen Modell 24 der realen Kraftfahrzeugkomponente.
Zum Testen der realen Kraftfahrzeugkomponente 21 ist der Prüfstand 22 elektrisch mit dem Steuergerät verbunden und so ausgebildet, dass damit erhältliche Testergebnisse nach Automotive Spice und ISO 26262 abzusichern sind. Der Prüfstand 22 ist zudem mit dem File-Server 23 verbunden, zum Speichern der beim Test der realen Kraftfahrzeugkomponente 21 auf dem Prüfstand 22 erhältlichen Testergebnisse in Form der verwendeten Anregungen und Erwartungswerte und zum Abspielen derselben mit dem auf dem Computer 25 gespeicherten virtuellen Modell 24 bei gleichzeitiger Aufzeichnung der Code- und Toggle-Coverage-Metriken des virtuellen Modells 24. Der Computer 25 ist dazu elektrisch mit dem File-Server 23 verbunden. Auf dem Computer 25 ist zudem eine geeignete Software zum Aggregieren aller Coverage-Metriken in einem finalen Gesamt-Report vorgesehen.
3 stellt ein einfaches virtuelles Modell dar, anhand dessen die Code- oder Toggle-Coverage-Analyse unter Bezugnahme auf 4 beispielhaft erläutert werden soll.
In 3 bezeichnen: A - eine erste Funktion 31, x - eine Eingangsgröße 310, a - ein Signal 311, b - ein Signal 312, B - eine Funktion 32 und y - ein Signal 320.
A berechnet aus den Werten von x die Signale a und b. Die Signale a und b haben die Wertebereiche a [0..2] und b [0..1]. Das Signal y aus Funktion B hat den Wertebereich y [0..5]. Der Code von Funktion B ist:

                    Func B() {
                      Wenn((a < 2) und (a >= 0)) {
                       y=a*b
                      } sonst {
                       y = b
                      } 
                    }

Eine Code-Coverage von 100% wird für folgende die Wertepaare erreicht:

a = 0; b = 0 \to y = 0

a = 2; b = 1 \to y = 1.

Das Signal y kann somit maximal nur 1 werden, wenn gilt: Signal a = 1 und Signal b = 1, basierend auf den oben angegebenen Wertebereichen für a und b; bei a = 2 gilt die Sonst-Bedingung, wonach y der Wert von b zugewiesen wird. Damit sind zwar 100% Code-Coverage zu erreichen, nicht jedoch eine Toggle-Coverage von 100%, da der Wertebereich von y nicht ausgeschöpft wird; die Werte im Bereich 2 ... 5 werden nicht erreicht. In 4 entspricht dies einem nicht abgedeckten Funktionsbereich 42, bei dem die Code- oder Toggle-Coverage ebenfalls kleiner 100% ist.

Dieses kleine Code-Beispiel soll verdeutlichen, dass zum Erreichen einer Toggle-Coverage von 100% kein geeignetes Eingangsszenarium vorliegt. Das bedeutet, dass entweder die Spezifikation des virtuellen Modells fehlerhaft ist oder dass ein Implementierungsfehler des virtuellen Modells vorliegt.

4 zeigt ein Beispiel einer nach dem erfindungsgemäßen Verfahren erstellten Code-Coverage-/Toggle-Coverage-Landkarte 40, bzw. eines Gesamt-Reports, wie er mit dem erfindungsgemäßen Verfahren erhältlich ist.

Dieser Gesamt-Report gibt Auskunft über alle nicht angelaufenen Code-Fragmente des virtuellen Modells. Jeder einzelne Block der Darstellung stellt eine Funktion des virtuellen Modells, vECU, dar. Nicht vollständig abgedeckte Funktionsbereiche können z.B. nicht durchlaufene Code Zweige des virtuellen Modells sein oder nicht angeregte Eingangssignale eines Funktionsbereichs (Toggle-Coverage).

Diese Lücken sind durch neue Anregungsszenarien für das virtuelle Modell zu schließen. Sind keine Szenarien zur Schließung dieser Funktionslücken auffindbar, kann dies ein Hinweis auf sog. Dead-Code-Bereiche des Modells sein. Unter Cyber-Security-Gesichtspunkten sollten solche Code-Bereiche ggf. entfernt werden.

Die auf der Grundlage der neuen Anregungsszenarien für das virtuelle Modell entwickelten Tests müssen anschließend noch einmal in der realen Prüfstands-Welt mit dem Prüfling bzw. der Kraftfahrzeugkomponente nachgetestet werden. Darüber hinaus müssen die Testspezifikationen angepasst werden und die Testszenarien in den Gesamt-Report aufgenommen werden, wenn diese auf Testlücken hinweisen.

5 zeigt noch einmal die in 4 dargestellte Code-Coverage-/Toggle-Coverage-Landkarte 40, in der allerdings die Code-Bereiche so angegeben sind, wie sie sich nach einem weiteren Durchlaufen des virtuellen Steuergerätemodells, vECU, mit einem zweiten, modifizierten Testsatz ergeben können. Der hier dargestellte Gesamt-Report dient somit als Grundlage für eine erfindungsgemäße Test-Impact-Analyse. In 5 sind neben den von dem virtuellen Steuergerätemodell, vECU, vollständig abgedeckten Funktionsbereichen 51 auch nicht abgedeckte Funktionsbereiche 53 und nicht vollständig bzw. nur teilweise abgedeckte Funktionsbereiche 52 dargestellt.

Die Test Impact Analyse wird genutzt, um zu ermitteln, welche Tests benötigt werden, um neue Code-Fragmente 52, 53, die in ein virtuelles Modell durch Modellanpassungen hinzugekommen sind, durch schon existierende Tests abzudecken. Mittels einer geeigneten Optimierungs-Software wird daraus der kleinstmögliche Testsatz ermittelt, der erforderlich ist, um jeweils vor einer Modellanpassung die maximale Code- und Toggle-Coverage zu erreichen.

Nach erfolgter Modellanpassung wird wiederum mittels der Optimierungs-Software auf der Grundlage des neuen Testsatzes berechnet, ob es damit möglich ist, bisher nicht erfasste Code-Bereiche abzudecken; in 5 werden die Bereiche 53 teilweise angelaufen, während die Bereiche 52 nicht angelaufen werden. Somit ist für die Bereiche 53 der Testsatz jedenfalls bereits teilweise vorhanden und muss lediglich angepasst werden um eine vollständige Abdeckung zu erreichen, der dann im Gesamt-Report als Bereich 51 erscheint. Für alle Code-Bereiche 52 sind hingegen neue Tests zu entwickeln.

Die Test-Impact-Analyse stellt insoweit eine besonders vorteilhafte Möglichkeit dar, gezielt einzelne Tests zu priorisieren und mithin den für eine Bewertung eines aktualisierten virtuellen Modells benötigen Zeitaufwand wesentlich zu verringern. Somit stellt das erfindungsgemäße Verfahren eine besonders zeitsparende Vorgehensweise dar, um eine Aussage über die funktionale Qualität des aktualisierten virtuellen Modells zu erhalten.

Am Beispiel der 5 stellt sich dieses vorteilhafte Vorgehen wie folgt dar: Als erstes werden die Bereiche 53 und die Bereiche 52 getestet; hierbei wird davon ausgegangen, dass die vorgenannten priorisierten Modellanpassungen ohne negativen Einfluss auf die Bereiche 51 vorgenommen werden können, d.h., dass durch die Modellanpassungen keine existierende Funktion zerstört wird.

Nach einer Anpassung der Testinhalte für die Bereiche 53 und einer Erstellung der neuen Testinhalte für die Bereiche 52 müssen die betreffenden Code-Bereiche vollständig abgedeckt sein und mithin als Bereiche 51 im Gesamt-Report erscheinen. Im Anschluss daran, kann aus den Testinhalten der Bereiche 52, 53 und den existierenden Testinhalten der Bereiche 51 der minimalen Testsatz berechnet werden, mit dem eine vollständige Code- und Toggle-Coverage und somit eine vollständige Erfassung aller Funktionen eines Steuergerätes einer zu testenden Kraftfahrzeugkomponente von dem virtuellen Steuergerätemodell, vECU erreicht wird. Dieser Testsatz kann für eine Freigabe des angepassten virtuellen Modells genutzt werden.

6 zeigt in schematischer Darstellung ein System 60 zur automatischen Qualifizierung eines virtuellen Modells zum Testen einer Kraftfahrzeugkomponente nach dem erfindungsgemäßen Verfahren. Von dem System 60 umfasst sind:

Eine erste Systemeinheit 61 mit einem Prüfstand 22 zum Anregen des realen Prüflings und zur Prüfung der Antworten auf Einhaltung von Erwartungswerten.

Eine zweite Systemeinheit 62 mit einem File-Server zum Aufzeichnen der Anregungswerte und Antworten und zum Bereitstellen derselben für eine weitere Verwendung.

Eine dritte Systemeinheit 63 die zum Anwenden der von der zweiten Systemeinheit 62 bereitgestellten Anregungswerte oder Anregungsszenarien und Antworten auf das virtuelle Modell und zum Vergleichen der Antworten des virtuellen Modells mit den aufgezeichneten Antworten des realen Prüflings vergleicht. Die dritte Systemeinheit 63 weist dazu ein erstes Computersystem mit dem darauf gespeicherten virtuellen Steuergerätemodell, vECU, und mit einer geeigneten Software auf.

Eine vierte Systemeinheit 64 zum Aufzeichnen der Code- und Toggle-Coverage-Metriken beim Abspielen der Tests mit dem von der dritten Systemeinheit 63 bereitgestellten virtuellen Modell und zum Auswerten der aufgezeichneten Code- und Toggle-Coverage-Metriken sowie Bewerten der Tests mit der Test-Impact-Analyse. Die vierte Systemeinheit 64 ist dazu mit einem zweiten Computersystem mit einer geeigneten Software ausgebildet.

Eine fünfte Systemeinheit 65 ist zur Unterstützung der Entwicklung von Tests für die mit der vierten Systemeinheit 64 festgestellten funktionalen Lücken des virtuellen Modells und zur anschließenden Testaktualisierung durch Schließen der festgestellten Simulationslücken des Modells ausgebildet. Die fünfte Systemeinheit 65 weist dazu ein drittes Computersystem mit einer geeigneten Software auf.

Eine sechste Systemeinheit 66 mit einem vierten Computersystem mit einer geeigneten Software ist schließlich zum Anwenden der mit der fünften Systemeinheit 65 aktualisierten Tests auf den realen Prüfling vorgesehen und zur Steuerung von Testwiederholungen unter Einbeziehung aller Systemeinheiten 61-66, solange, bis keine neuen Tests bzw. Testaktualisierungen mehr anzugeben sind.

Bezugszeichenliste

100: erster Verfahrensschritt
200: zweiter Verfahrensschritt
300: dritter Verfahrensschritt
400: vierter Verfahrensschritt
410: ersten Teilschritt des vierten Verfahrensschritts
420: zweiter Teilschritt des vierten Verfahrensschritts
430: dritter Teilschritt des vierten Verfahrensschritts
440: vierter Teilschritt des vierten Verfahrensschritts
450: fünfter Teilschritt des vierten Verfahrensschritts
460: sechster Teilschritt des vierten Verfahrensschritts
500: fünfter Verfahrensschritt
20: Anordnung für Vektor-Replay-Verfahren
21: Kraftfahrzeugkomponente
22: Prüfstand
23: File-Server
24: virtuelles Modell der Kraftfahrzeugkomponente
25: Computer
30: virtuelles Modell
31: Funktion A
310: Eingangsgröße x
311: Signal a
312: Signal b
32: Funktion B
320: Signal y
40: Model-Code-Coverage-/Interface-Toggle-Landkarte, Gesamtreport
41: vollständig abgedeckte/r Funktionsbereich / Code-Coverage / Toggle-Coverage
42: nicht abgedeckte/r Funktionsbereich / Code-Coverage / Toggle-Coverage
50: Model-Code-Coverage-/Interface-Toggle-Landkarte für Test-Impact-Analyse
51: vollständig abgedeckte/r Funktionsbereich / Code-Coverage / Toggle-Coverage
52: nicht vollständig abgedeckte/r Funktionsbereich / Code-Coverage / Toggle-Coverage
53: nicht abgedeckte/r Funktionsbereich / Code-Coverage / Toggle-Coverage
60: System zur automatischen Qualifizierung von virtuellen Modellen
61: erste Systemeinheit
62: zweite Systemeinheit
63: dritte Systemeinheit
64: vierte Systemeinheit
65: fünfte Systemeinheit
66: sechste Systemeinheit

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

US 2016/0329996 A1 [0018]
US 2018/0137022 A1 [0019]

Claims

Verfahren zum Optimieren eines Testsatzes zur automatischen Qualifizierung von virtuellen Modellen für den Test von Kraftfahrzeugkomponenten, gekennzeichnet durch die Verfahrensschritte: Erstellen (200) eines virtuellen Steuergerätemodells, vECU, nach ISO-Norm 26262 zur Simulation der Hardware und der Software wenigstens eines Steuergerätes; Testen (400) des virtuellen Steuergerätemodells, vECU, mit abgesicherten Black-Box-Testverfahren mit den Schritten: - Erstellen (420) wenigstens eines Testsatzes anhand von an den Schnittstellen des wenigstens einen Steuergerätes aufgenommenen Testvektoren und Stimuli; - Abspielen (430) des Testsatzes mit dem virtuellen Steuergerätemodell, vECU; - Erfassen (440) von Model-Code-Coverage-Metriken und/oder Interface-Toggle-Metriken von, mit dem Testsatz erzeugten, Code-Bereichen; - Aggregieren (450) der erzeugten Code-Bereiche der erfassten Model-Code-Coverage-Metriken und/oder Interface-Toggle-Metriken des Testsatzes in einer Model-Code-Coverage- und/oder Interface-Toggle-Landkarte (40); - Überprüfen (460) der Model-Code-Coverage- und/oder Interface-Toggle-Landkarte (40) auf Vollständigkeit, Wiederholen der Verfahrensschritte (420) bis (460), wobei im Verfahrensschritt (420) jeweils wenigstens ein modifizierter Testsatz so erstellt wird, dass in der Model-Code-Coverage- und/oder Interface-Toggle-Landkarte zumindest ein zusätzlicher Code-Bereich abgedeckt wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Erstellen (200) des virtuellen Steuergerätemodells, vECU, mittels Matlab/Simulink, S-Function und/oder Functional Mockup Units, FM erfolgt.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass das virtuelle Steuergerätemodell, vECU, nach ISO-Norm 26262 zur Simulation der Hardware und der Software des wenigstens einen Steuergerätes der zu testenden Kraftfahrzeugkomponente ausführbaren Code von kompilierten Programmen umfasst.
Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die zum Testen (400) des virtuellen Steuergerätemodells, vECU, verwendeten Black-Box-Tests nach der ISO-Norm 26262 und/oder der ASpice-Norm entwickelt und abgesichert werden.
Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass das virtuelle Steuergerätemodell, vECU, für eine Test-Impact-Analyse zur Priorisierung neuer Testsätze zur Absicherung der funktionalen Qualität eines aktualisierten virtuellen Modells, vECU, verwendet wird.
Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass das Vektor-Replay-Verfahren gemäß den Verfahrensschritten (420) bis (430), zum Nachweisen einer funktionalen Vergleichbarkeit von Testergebnissen mit simulierten Kraftfahrzeugkomponenten und deren Genauigkeit im Vergleich zu Testergebnissen mit realen Kraftfahrzeugkomponenten von Prüfständen für die Qualifizierung von virtuellen Steuergerätemodellen, vECU, verwendet wird.
System (60) zum Optimieren eines Testsatzes zur automatischen Qualifizierung von virtuellen Modellen, insbesondere von virtuellen Steuergerätemodellen, vECU, für den Test von Kraftfahrzeugkomponenten gemäß einem Verfahren nach einem der Ansprüche 1 bis 4, gekennzeichnet durch: eine erste Systemeinheit (61), umfassend wenigstens einen Prüfstand (22) für Kraftfahrzeugkomponenten zum Durchführen von abgesicherten Black-Box-Tests für die Hardware und die Software wenigstens eines Steuergerätes einer zu testenden Kraftfahrzeugkomponente; eine zweite Systemeinheit (62), umfassend wenigstens einen File-Server (23) mit einer geeigneten Software zum Aufzeichnen und Bereitstellen von Testvektoren und Stimuli des wenigstens einen Steuergerätes der zu testenden Kraftfahrzeugkomponente; eine dritte Systemeinheit (63), umfassend wenigstens ein erstes Computersystem mit einem darauf gespeicherten virtuellen Steuergerätemodell, vECU, und mit einer geeigneten Software zum Erstellen eines Testsatzes anhand der bereitgestellten Testvektoren und Stimuli, zum Anwenden desselben auf das virtuelle Steuergerätemodell, vECU, und zum Vergleichen der Modell-Antworten mit den für die wenigstens eine Kraftfahrzeugkomponente ermittelten Antworten; eine vierte Systemeinheit (64), umfassend wenigstens ein zweites Computersystem zum Abspielen des Testsatzes mit dem virtuellen Steuergerätemodell, vECU, mittels eines Vektor-Replay-Verfahrens, und mit einer geeigneten Software zum Erfassen von Model-Code-Coverage-Metriken und/oder Interface-Toggle-Metriken von, mit dem Testsatz erzeugten, Code-Bereichen, Aggregieren der erzeugten Code-Bereiche der erfassten Model-Code-Coverage-Metriken und/oder Interface-Toggle-Metriken des Testsatzes in einer Model-Code-Coverage- und/oder Interface-Toggle-Landkarte (40; 50) und Bewerten des Testsatzes mittels einer Test-Impact-Analyse; eine fünfte Systemeinheit (65), umfassend wenigstens ein drittes Computersystem mit einer geeigneten Software zur Steuerung von Testwiederholungen mit jeweils einem modifizierten Testsatz, wobei der modifizierte Testsatz bewirkt, dass in der Model-Code-Coverage- und/oder Interface-Toggle-Landkarte zumindest ein zusätzlicher Code-Bereich abgedeckt wird.
Computerprogrammprodukt, das einen computerlesbaren Programmcode umfasst, der bei der Ausführung durch einen Computer diesen veranlasst, ein Verfahren nach einem der Ansprüche 1 bis 4 durchzuführen.