-
Die Erfindung betrifft Verfahren zum automatischen Erzeugen von Tests für die Software eines Fahrzeugs, insbesondere eines Kraftfahrzeugs.
-
Traditionell wird Software-Verifizierung während der Fahrzeugentwicklung auf unterschiedlichen Ebenen durchgeführt. Typischerweise folgen die unterschiedlichen Ebenen von Tests der architektonischen Zerlegung der Software.
-
Um die Komplexität der Entwicklung von Merkmalen zu mindern, wird eine Software in winzige Teile aufgeteilt, die Komponenten genannt werden. Eine Komponente kann eine von der Gesamt-Software verlangte Basis-Funktionalität implementieren, z. B. Verarbeiten der Geschwindigkeit eines Fahrzeugs, Verarbeiten des Zustands eines Verbrennungsmotors, usw. Diese Komponenten werden miteinander verbunden, um durch Austausch von Daten zu interagieren und um komplexere Funktionalität zu erzeugen, welche von der Software verlangt wird. Der Einfachheit halber oder um die Integration in eine vorhandene elektrische Architektur (Plattform, Motorsteuergerät, Software-Plug-in) zu erleichtern, können Zwischen-Komponenten erzeugt werden, die hierin Funktionen oder Subsysteme genannt werden. Diese Funktionen verbinden sich schließlich selbst miteinander, um die erwarteten Softwaremerkmale zu erzeugen.
-
Je nach der Komplexität der Software können mehrere Ebenen von funktioneller Zerlegung erzeugt werden. Hierin gilt eine Beschränkung auf drei Ebenen von Zerlegung. Im Allgemeinen werden diese funktionelle Zerlegung und die Definitionen von Komponenten, Funktionen und deren Verbindungen mittels einer Architektur wie z. B. einer Software-Architektur spezifiziert, die mittels Simulink, SysML, UML usw. modelliert werden kann. In einem Architektur-Diagramm wird jede Komponente oder Funktion durch einen Kasten dargestellt, der die Ein- und Ausgänge der Komponenten enthält. Komponenten werden dann verbunden, indem eine Linie zwischen den Eingängen bzw. Ausgängen gezogen wird, die Informationen austauschen sollen.
-
Um korrekte Implementierung und ausreichende Qualität sicherzustellen, wird die Software während ihrer Entwicklung auf den unterschiedlichen Ebenen von funktioneller Zerlegung getestet. So gibt es Unit-Tests (auch als Modultests oder Komponententests bezeichnet) zum Testen jeder Komponente, Funktions-Tests zum Testen jeder Funktion oder jedes Subsystems und schließlich Software- oder System-Tests zum Testen der Gesamt-Software.
-
Unit-Tests werden im Allgemeinen gut durch ein so genanntes xUnit-Framework unterstützt, das in den meisten Software-Entwicklungsumgebungen wie z. B. Java, .NET, Matlab/Simulink usw. vorhanden ist und das Definitionen von Tests erlaubt, die in der Entwicklungsumgebung automatisch durchgeführt werden können. Das xUnit-Framework kann auch ein externes Framework sein. Die Tests werden im Allgemeinen auf Basis von Anforderungen und/oder auf Basis von Software-Design-Erwägungen des Entwicklers der Komponente erzeugt.
-
Eine Ebene höher, auf der Funktions- oder Subsystem-Ebene, werden im Allgemeinen andere Test von Grund auf manuell erzeugt, jedoch nur, um einige kritische Aspekte der Software zu verifizieren, insbesondere in Bezug auf ISO26262 oder FMEA. Aus Zeit- und Ressourcengründen werden die Zwischen-Architekturebenen (Funktionen) im Allgemeinen nicht so intensiv getestet wie die Komponenten- oder Gesamtsystem-Ebenen. Diese Tests können Funktions- oder Subsystem-Integrationstests genannt werden.
-
Zum Schluss werden auf Systemebene neue Tests manuell und von Grund auf definiert und entweder in dedizierten XiL-Umgebungen oder im Fahrzeug durchgeführt. Anforderungen und insbesondere Anwendungsfälle können verwendet werden, um diese Tests spezifizieren zu helfen. Solche Tests können Merkmal-Tests, Endbenutzer-Tests oder System integrations-Tests genannt werden.
-
Auf Zwischenebenen und höheren Ebenen der Fahrzeugsoftware werden die Tests daher häufig von Grund auf neu geschrieben, häufig unter Verwendung einer anderen Syntax, ohne den Informationsreichtum zu berücksichtigen, der durch Unit-Tests und Architekturmodelle zur Verfügung gestellt wird.
-
Die
US 2015 0 363 296 A1 lehrt, Software-Tests zu erzeugen, um die Interaktion zwischen Funktionen zu testen, indem Unit-Tests wiederverwendet werden, und schlägt ein Verfahren vor, zu prüfen, ob der Test eines solchen Interaktion durch Wiederverwenden von vorhandenen Unit-Tests der Funktion erreicht werden kann. Dieses Ziel soll ohne extensive Analyse der Funktionen erreicht werden. Die vorgeschlagenen Verfahren sollen es ermöglichen, Unit-Testfälle mittels der durch jeden Unit-Test erreichten Testabdeckung auf eine hierarchische Weise zu klassifizieren. Daher ist es möglich, die resultierende Testabdeckung, die erreicht werden kann, zu verarbeiten, indem Unit-Testfälle kombiniert und wiederverwendet werden. Es ist auch möglich, einen Unit-Test auszuwählen, der laufen gelassen werden soll, um eine bestimmte Ziel-Testabdeckung zu erreichen.
-
Die
DE 10 311 864 A1 offenbart ein Verfahren zum automatischen Erzeugen von Funktions-Testfällen unter Verwendung eines Modells einer Software-Funktion. Dieses Modell wird erhalten, indem eine Software-Funktion mittels Standardkomponenten beschrieben wird. Solche Standardkomponenten sind von dem besonderen Software-Design unabhängige generische Baublöcke und können z. B. Logik-Gatter, Flipflops, Multiplexer usw. sein. Es wird beschrieben, wie der Test unter Verwendung dieser Informationen und durch Einführung eines Signalabstraktion beschrieben wird. Die Signalabstraktion wird dann verwendet, um dem Test besondere Werte (Stimuli und Akzeptanz) zuzuweisen, je nachdem, wie gut die Funktion getestet werden soll, z. B. im Sinne der Testabdeckung. Es wird vorgeschlagen, auf Basis einer Formalbeschreibung, die nicht der Code selbst ist, automatisch Software-Tests zu erzeugen, die von einer Maschine interpretiert werden können.
-
Die
US 7 490 319 B2 beschriebt ein Testwerkzeug, das von einer Rückverfolgbarkeitsmatrix Gebrauch macht, um Abhängigkeiten zwischen Software-Komponenten zu verfolgen. Die Rückverfolgbarkeitsmatrix erlaubt es, Hinweise zu geben, welche Tests von einer Modifizierung einer Anforderung oder Software oder durch Modifizierung von anderen Tests betroffen sind. Rückverfolgbarkeit wird bei Anwendungslebenszeit- oder Projektlebenszyklus-Management weithin verwendet, um hohe Software-Qualität zu gewährleisten.
-
Die
US 2015 0 135 158 A1 beschreibt ein System zum automatischen Planen und Ausführen von Tests, insbesondere ein Permanentintegrationssystem für testunterstützte Entwicklung von verteilter Software, die von verteilten Teams implementiert wird, insbesondere bei Client/Server-Anwendungen. Es werden Verfahren zum Konstruieren, Identifizieren und Herunterladen von Abhängigkeiten, Herunterladen von geeigneten Unit-Tests und Codes beschrieben, die notwendig sind, um Tests automatisch laufen zu lassen. Es wird vorgeschlagen, eine so genannte Mockup-Funktion zu definieren und zu verwenden, die verwendet werden kann, um fehlende Elemente oder Abhängigkeiten zu ersetzen, wodurch mindestens ein Teil der Tests laufen gelassen werden kann.
-
Die
KR 101 134 735 B1 schlägt vor, auf Basis von Software-Komponenten-Design-Informationen, die einem AUTOSAR-Modell entnommen werden, automatisch lauffähige Testanweisungen zu erzeugen. Das offenbarte Verfahren ist im Stande, Schnittstellen-Informationen zu sammeln und irgendeine Kombination von gültigen und ungültigen Werten zu generieren, um ausführbare Schnittstellen-Testfälle zu erzeugen. Das Verfahren ist auch im Stande, die Schnittstellen-Informationen zu verwenden, um Tests mit irgendeiner Kombination von Eingangs/Ausgangs-Stimuli zu beschicken.
-
Die
KR 101 618 872 B1 schlägt ein Permanentintegrationssystem auf Basis von Quellcode-Analysen und Software-Hierarchie-Analysen vor. Das System ist im Stande, die Tests auf eine kontrollierte Weise zu planen und durchzuführen. Je nach dem Ergebnis eines Tests wie z. B. eines Unit-Tests, zum Beispiel wenn der Test erfolgreich war, plant das System automatisch die nächste Testebene, indem der Quellcode und die Software-Architektur analysiert werden.
-
Der Erfindung liegt die Aufgabe zu Grunde, Fahrzeugsoftware-Tests auf höheren Architekturebenen automatisch gewinnen zu können.
-
Diese Aufgabe wird gemäß der Erfindung durch die in den unabhängigen Patentansprüchen angegebenen Verfahren gelöst.
-
Vorteilhafte Weiterbildungen der Erfindung sind in den abhängigen Patentansprüchen angegeben.
-
Ein Aspekt der Erfindung betrifft Verfahren, Algorithmen oder Module zum automatischen Erzeugen von Tests für die Software eines Fahrzeugs, insbesondere eines Kraftfahrzeugs, auf unterschiedlichen Software-Architekturebenen oberhalb einer Komponenten-Ebene, wobei Tests auf höherer Ebene unter Verwendung von Informationen aus einem Software-Architekturmodell aus Unit-Tests kombiniert werden.
-
Vorzugsweise werden die Tests auf höherer Ebene unter Verwendung von Informationen aus einem Software-Architekturmodell aus Unit-Tests kombiniert; die Tests auf höherer Ebene werden vorzugsweise automatisch in derselben Syntax wie Unit-Tests erzeugt und erlauben automatische Ausführung in einer xUnit-Testumgebung; und die Tests werden vorzugsweise automatisch in eine von Menschen lesbare Syntax übersetzt, die speziellen Syntaxregeln, einem speziellen Wörterbuch usw. folgt, und/oder automatisch auf ein Dynamometer, auf einen Prüfstand oder ein Fahrzeug oder autonomes Fahrzeug hochgeladen, womit eine automatische Verifizierung der Fahrzeug-Software erfolgt.
-
Die Kernidee der Erfindung ist, für Software-Komponenten geschriebene Unit-Tests unter Verwendung von Software-Design-Informationen einer insbesondere mittels UML oder SysML modellierten Software-Architektur automatisch zu Software-Tests auf höherer Ebene zu kombinieren. Zu diesem Zweck werden die Software Ein-/ Ausgänge zugeordnet und unter Verwendung der Design-Informationen an eine andere Hierarchie-Ebene zurückgesendet. Damit kann man fortfahren, bis die höchste Ebene der Software erreicht ist. Man muss weder irgendwelche Stimuli oder Wertekombinationen erzeugen, noch benötigt man Permanentintegration. Auch geht es bei der Erfindung nicht um automatische Planung und Ausführung von Tests.
-
Anders als in der o. g.
DE 10 311 864 A1 befasst sich die Erfindung nicht mit den Details einer Funktion oder einer Formalbeschreibung eines Funktionsalgorithmus, sondern nutzt vorhandene Software-Design-Informationen, wie sie von Architektur-Modellierungssprachen wie z. B. UML oder SysML geboten werden, um Unit-Tests zu Tests höherer Ebene zu kombinieren.
-
Anders als in der o. g.
US 7 490 319 B2 nutzt die Erfindung Software-Design-Informationen wie z. B. aus einem Software-Architekturmodell, um Unit-Tests zu Tests auf höherer Ebene zu kombinieren.
-
Anders als in der o. g.
KR 101 134 735 B1 nutzt die Erfindung Software-Design-Informationen zum automatischen Kombinieren von Tests durch Zuordnung von Signalen und deren Rücksendung an eine andere Hierarchie-Ebene des Designs, um Integrationstests zu erzeugen.
-
Das Verfahren oder die Algorithmen oder Module können eines, mehrere oder alle der folgenden Merkmale aufweisen: ein Software-Architekturmodell in einer Modellierungssprache (wie z. B. SysML oder UML); eine Signal-Datenbank, die eine genaue Definition aller auf unterschiedlichen Architekturebenen in einem Fahrzeug verwendeten Signale enthält, z. B. Name, Codierung, Typ, Größe, Wertebereich usw.; eine Sammlung von während der Entwicklung von Software-Ingenieuren definierten Unit-Tests; ein Signalanpassungsmodul zum Bestimmen, welche Signale einander zugeordnet oder miteinander verbunden werden; ein Zwischensignal-Erkennungsmodul zum Bestimmen, welche Signale zwischen zwei Software-Elementen auf derselben Architekturebene verbunden sind, z. B. zwischen zwei Komponenten oder zwei Funktionen; ein Testkombinationsmodul zum Gruppieren von Tests aller Elemente, die einem Element auf einer höheren Architekturebene zugewiesen sind, z. B. Komponenten, die einer Funktion zugewiesen sind; ein Testerzeugungsmodul zum Erzeugen von Tests auf einer höheren Architekturebene auf Basis der in den vorgenannten Modulen verarbeiteten Informationen; ein Testvereinfachungsmodul zum Anwenden von Signalzuordnung, logischer Vereinfachung, mathematischer Vereinfachung usw. auf einen erzeugten Test; ein Testübersetzungsmodul zum Übersetzen der erzeugten und vereinfachten Tests in Testanweisungen, die von einem Menschen interpretiert werden können, oder in Tests, die automatisch in einem Dynamometer, auf einen Prüfstand oder in einem Fahrzeug oder autonomen Fahrzeug durchgeführt werden können; eine Schnittstelle zu einem Projektlebenszyklus-Managementsystem zum automatischen Aktualisieren einer Testspezifikation und von Verknüpfungen mit zugehörigen Anforderungen.
-
Ein weiterer Aspekt der Erfindung betrifft Verfahren, Algorithmen oder Module zum automatischen Erzeugen von Tests für die Software eines Fahrzeugs, insbesondere eines Kraftfahrzeugs, auf einer höheren Architekturebene oberhalb einer niedrigen Architekturebene eines Architekturmodells, mit einem, mehreren oder allen der folgenden Merkmale: es werden Tests niederer Ebene (z. B. Unit-Tests) von Elementen der niedrigen Architekturebene (z. B. Komponenten), die einem Element (z. B. einer Funktion) der höheren Architekturebene zugewiesen sind, für welches die Tests erzeugt werden, gruppiert; es werden Zuordnungsregeln angewendet, um die Signalnamen der Elemente der niedrigen Architekturebene durch die Signalnamen von entsprechenden Elementen der höheren Architekturebene zu ersetzen; es werden Zuordnungsregeln angewendet, um die Signalwerte der Elemente der niedrigen Architekturebene durch die Signalwerte von entsprechenden Elementen der höheren Architekturebene zu ersetzen; es werden Zwischensignale zwischen den Elementen der niedrigen Architekturebene, die eine Interaktion zwischen diesen Elementen anzeigen, identifiziert; es werden Erweiterungsregeln angewendet, um Zwischensignale und Bedingungen für Zwischensignale durch Testanweisungen zu ersetzen, was zu der Erzeugung dieser Bedingungen führt; es werden unabhängige Testschritte und zugewiesene Kriterien für jene Tests erzeugt, die keine Zwischensignale enthalten.
-
Außerdem liefert die Erfindung ein Verfahren zum Vereinfachen eines wie vorstehend erzeugten Tests, bei dem einer, mehrere oder alle der folgenden Schritte durchgeführt werden: es wird logische Vereinfachung angewendet; es wird mathematische Vereinfachung angewendet; es wird Unit-Umwandlung angewendet; es werden Übersetzungsregeln angewendet, um den Test in eine von Menschen lesbare Sprache umzuwandeln; es werden Übersetzungsregeln angewendet werden, um den Test in eine maschinenlesbare Sprache umzuwandeln, die in einer externen Testumgebung wie z. B. einem Dynamometer, einem Prüfstand oder einem Fahrzeug oder autonomen Fahrzeug ausgeführt werden kann.
-
Weiterhin liefert die Erfindung ein Verfahren zum rekursiven und inkrementellen Durchführen der automatischen Testerzeugung für sämtliche in dem Architekturmodell beschriebenen unterschiedlichen Architekturebenen.
-
Weiterhin liefert die Erfindung ein Verfahren zum Modellieren einer Software-Architektur zur Durchführung eines der vorstehend beschriebenen Verfahren, das eines, mehrere oder alle der folgenden Merkmale aufweist: die Architektur ist in einer Modellierungssprache wie z. B. SysML oder UML geschrieben; die Architektur umfasst mindestens eine Komponenten-Ebene und eine Merkmal-Ebene; die Architektur achtet eine Signalnamenskonvention einer jeden Architekturebene; die Architektur erlaubt es, Architektur-Elemente einer niedrigen Ebene zu identifizieren, die einem Architektur-Elemente einer höheren Ebene zugewiesen sind; die Architektur enthält eine Definition, wie Signale zwischen Elementen derselben Architekturebene zu verbinden sind; die Architektur enthält eine Definition, wie Signale zwischen Elementen einer Architekturebene mit Signalen von Elementen einer anderen Architekturebene zu verbinden sind.
-
Weiterhin liefert die Erfindung ein Verfahren zum automatischen Aktualisieren eines Projektlebenszyklus-Managementsystems mit einem wie vorstehend beschrieben erzeugten Test, wobei das Projektlebenszyklus-Managementsystem eines, mehrere oder alle der folgenden Merkmale aufweist: die Erzeugung von zusätzlichen Test-Containern in dem Projektlebenszyklus-Managementsystem für jeden erzeugten Test; die Erzeugung von Verknüpfungen, die es erlauben, den erzeugten Test mit auf derselben Architekturebene definierten Anforderungen zu verknüpfen (diese können gewonnen werden, indem analysiert wird, wie die Anforderungen unterschiedlicher Architekturebenen miteinander verknüpft sind); eine Lückenanalyse zum Berichten der Anforderungen auf einer höheren Architekturebene, für die kein Test erzeugt worden ist, um die Aufgabe von Testingenieuren zu erleichtern, diese fehlenden Tests zu erzeugen.
-
Es folgt eine Beschreibung von Ausführungsbeispielen anhand der Zeichnungen. Darin zeigen:
- 1 ein Beispiel für ein Architekturmodell; und
- 2 eine Systemübersicht.
-
Es folgt eine Beschreibung eines Verfahrens zum automatischen Erzeugen von Testanweisungen (Test-Schritten und Akzeptanzkriterien) auf Systemebene oder Fahrzeugebene, die in einer dedizierten Umgebung ausführbar sind. Das Verfahren stützt sich auf eine Beschreibung der Architektur bzw. Software-Architektur des getesteten Systems, d. h. von dessen Komponenten und wie sie Informationen austauschen, auf eine Signal-Datenbank sowie auf sogenannte Unit-Tests, die entwickelt wurden, um die Komponenten in einer automatisierten Testumgebung wie z. B. einem xUnit-Framework zu verifizieren. Das Verfahren kombiniert die Unit-Tests im Anschluss an die Architekturdefinition, um automatisch Test für Software-Elemente auf einer höheren Architekturebene zu erzeugen, die in demselben automatisierten Test-Framework ausführbar sind oder die in einem Dynamometer, auf einem Prüfstand, in einem Fahrzeug oder einem autonomen Fahrzeug ausführbar sind. Zum Schluss kann das System die erzeugten Test automatisch laufen lassen und ein Projektlebenszyklus-Managementsystem aktualisieren.
-
Die hierin beschriebenen Verfahren und Algorithmen ermöglichen es, viele zusätzliche Tests auf Zwischenebenen und höheren Ebenen automatisch zu erzeugen, die unter Verwendung des erwähnten Informationsreichtums in beliebigen Umgebungen automatisch ausgeführt werden können, und sie ermöglichen es, auf Basis der Unit-Tests und auf Basis mancher Architekturmodelle der Software automatisch Fahrzeugsoftware-Tests auf Zwischenebenen und höheren Ebenen zu gewinnen.
-
Arbeitsprinzip:
-
Man betrachte das in 1 dargestellte vereinfachte Architekturmodell eines Stopp/Start-Merkmals, also eines Kraftfahrzeug-Ausstattungsmerkmals „Stopp/Start-Automatik“. Das Merkmal besteht aus zwei Funktionen ‚Fordere Stopp an‘ (Funktion 1 bzw. F1) und ‚Validiere Stopp-Anforderung‘ (Funktion 2 bzw. F2). Die Funktion ‚Fordere Stopp an‘ wurde in zwei Komponenten zerlegt, nämlich ‚Prüfe Stopp-Auslöser‘ (Komponente 1 bzw. C1) und ‚Prüfe Timer‘ (Komponente 2 bzw. C2). Die Funktion ‚Validiere Stopp-Anforderung‘ wurde in eine Komponente zerlegt, nämlich ‚Prüfe valide Stopp-Anforderung‘ (Komponente 3 bzw. C3).
-
Die Merkmale, Funktionen und Komponenten haben ihre eigenen Schnittstellen und Signal-Definitionen, wie zum Beispiel in einer Signal-Datenbank definiert. Das Architekturmodell beschreibt auch, wie diese Signale verbunden werden, um die Implementierung des Merkmals zu ermöglichen.
-
Unit-Tests:
-
Es sei nun angenommen, das die in Tabelle 1 aufgeführten Unit-Tests für jede Komponente definiert wurden. Zur Vereinfachung wurde nur ein Unit-Test pro Komponente definiert.
Tabelle 1:
| Test-Kennung | Komponente | Test-Beschreibung (Pseudocode) |
| C1 | C1 | Schritt 1: |
| | | If (C1_In_GearPos_Enum == NEUTRAL) and (C1_In_AccelPedalPos_Int <=0.01) and (C1_In_ClutchPedalPos_Int <=0.01) |
| | | Akzeptanz 1: |
| | | C1_Out_StopTriggerPresent_Bool = TRUE |
| C2 | C2 | Schritt 1: |
| | | Intern Clock = 0; |
| | | Start() Intern Clock; |
| | | If (Intern Clock > C2_In_StopDelay) |
| | | Akzeptanz 1: |
| | | C2_Out_TimerElapsed_Bool = TRUE |
| C3 | C3 | Schritt 1: |
| | | If (C3_In_StoplnhibitorPresent_Bool == TRUE) and (C3_In_StopTriggerPresent_Bool == TRUE) and (C3_In_TimerElapsed_Bool ==TRUE) |
| | | Akzeptanz 1: |
| | | C3_Out_StopRequestPresent_Bool = TRUE |
-
Durch Analysieren des Architekturmodells und möglicherweise der Signaldefinition in einer Signal-Datenbank wird das System aus den zur Verfügung stehenden Unit-Tests zuerst die Testanweisungen einer jeden Funktion gewinnen. Dies umfasst mindestens die folgenden Tests:
- 1. Identifiziere die der Funktion zugewiesenen Komponenten.
- 2. Identifiziere die Signalzuordnung zwischen einer jeden Komponente der Funktion (das Ausgangssignal einer der Komponenten in der Funktion könnte das Eingangssignal einer anderen Komponente der Funktion sein).
- 3. Identifiziere die Signalzuordnung zwischen einer jeden Komponente und der Funktion.
- 4. Identifiziere Interaktionen zwischen Komponenten einer Funktion (dies ist der Fall, wenn das Ausgangssignal einer der Komponenten in der Funktion das Eingangssignal einer anderen Komponente der Funktion ist).
- 5. Führe eine Analyse der Komponenten-Tests (Syntaxanalyse) durch und ordne die Signale so zu wie in den vorhergehenden Schritten identifiziert.
- 6. Kombiniere Komponenten-Tests in Übereinstimmung mit der Komponenten-Funktion-Zuweisung und in Übereinstimmung mit den Signalzuordnungen. Zum Beispiel werden die Tests von C1 und C2 kombiniert, um den Test von F1 in Tabelle 2 zu erhalten.
- 7. Führe eine Vereinfachung der Komponenten-Tests durch, indem Zwischensignale (d. h. Signalaustausche zwischen Komponenten innerhalb einer Funktion) durch die zu einem bestimmten Status des entsprechenden Signals passenden Tests ersetzt werden.
-
Allgemeiner können die Vereinfachungsschritte folgende Aufgaben enthalten:
- - Erweitere Tests, die zu dem Status von bestimmten Zwischensignalen passen, um einen Meta-Test zu erzeugen (ein Beispiel dafür wird weiter unten mit dem Merkmal-Test gegeben).
- - Erzeuge unabhängige Testschritte für diese Tests, die Signale umfassen, die keine Zwischensignale sind, d. h. keine Interaktion zwischen Komponenten (ein Beispiel dafür wird mit dem Test von F1 gegeben).
- - Zusätzlich könnte weitere Vereinfachung implementiert werden, wie z. B. Vereinfachung eines logischen Ausdrucks durch Anwenden der Regeln der Logik.
- - Zusätzlich könnte weitere Vereinfachung implementiert werden, wie z. B. Vereinfachung eines mathematischen Ausdrucks durch Anwenden von mathematischen Regeln (z. B. Faktorisierung usw.).
- - Zusätzlich könnte weitere Vereinfachung implementiert werden, wie z. B. Unit-Umwandlung, Unit-Übersetzung (z. B. kann der Wert eines Signals je nach der Ebene, auf der das Signal definiert ist, unterschiedlich decodiert werden).
-
In diesem Beispiel ist es nicht notwendig, da es keine Interaktion zwischen
C1 und
C2 in
F1 gibt. Daher kann der Test von
F1 als eine Folge von zwei unabhängigen Schritten mit dedizierten Akzeptanzkriterien durchgeführt werden. Dieser Fall wird jedoch besser auf der nächsten Test-Ebene veranschaulicht, nämlich der Merkmal-Test-Ebene. Das Ergebnis ist in der folgenden Tabelle 2 dargestellt.
Tabelle 2:
| Test-Kennung | Funktion | Test-Beschreibung (Pseudocode) |
| F1 | F1 | Schritt 1: |
| | | If (F1_In_GearPos_Enum == NEUTRAL) and (F1_In_AccelPedalPos_Int <=0.01) and (F1_In_ClutchPedalPos_Int <=0.01) |
| | | Akzeptanz 1: |
| | | F1_Out_StopTriggerPresent_Bool = TRUE |
| | | Schritt 2: |
| | | Intern Clock = 0; |
| | | Start() Intern Clock; |
| | | If (Intern Clock > F1_In_StopDelay) |
| | | Akzeptanz 2: |
| | | F1_Out_TimerElapsed_Bool = TRUE |
| F2 | F2 | Schritt: |
| | | If (F2_In_StopInhibitorPresent_Bool == TRUE) and (F2_In_StopTriggerPresent_Bool == TRUE) and (F2_In_TimerElapsed_Bool ==TRUE) |
| | | Akzeptanz: |
| | | F3_Out_StopRequestPresent_Bool = TRUE |
-
Merkmal-Test:
-
Durch Analysieren des Architekturmodells und möglicherweise der Signaldefinition in einer Signal-Datenbank wird das System dann aus den erzeugten Funktions-Tests die Testanweisungen des Merkmals gewinnen. Dies umfasst mindestens die folgenden Schritte, die den für die Erzeugung der Funktions-Tests benutzten Schritten entsprechen.
- 1. Identifiziere die dem Merkmal zugewiesenen Funktionen.
- 2. Identifiziere die Signalzuordnung zwischen einer jeden Funktion des Merkmals (das Ausgangssignal einer der Funktionen in dem Merkmal könnte das Eingangssignal einer anderen Funktion des Merkmals sein).
- 3. Identifiziere die Signalzuordnung zwischen einer jeden Funktion und dem Merkmal.
- 4. Identifiziere Interaktionen zwischen Funktionen eines Merkmals (dies ist der Fall, wenn das Ausgangssignal einer der Funktionen in dem Merkmal das Eingangssignal einer anderen Funktion des Merkmals ist).
- 5. Führe eine Analyse der Funktions-Tests (Syntaxanalyse) durch und ordne die Signale zu, wie in den vorhergehenden Schritten identifiziert.
- 6. Kombiniere Funktions-Tests in Übereinstimmung mit der Funktion-Merkmal-Zuweisung und in Übereinstimmung mit der Signalzuordnung. Zum Beispiel werden die Tests von F1 und F2 kombiniert, um den Test des Merkmals zu erhalten.
- 7. Führe eine Vereinfachung der Funktions-Tests durch, indem Zwischensignale (d. h. Signalaustausche zwischen Funktionen innerhalb eines Merkmals) durch die zu einem bestimmten Status des entsprechenden Signals passenden Tests ersetzt werden. In diesem Beispiel verbraucht der Test F2 das Signal F2_In_StopTriggerPresent_Bool unter der Bedingung F2_In_StopTriggerPresent_Bool == TRUE. Dieses Signal entspricht dem Signal F1_Out_StopTriggerPresent_Bool im Test F1. Zusätzlich beschreibt der Test F1 die Bedingungen, die dazu führen, den Wert dieses Signals auf TRUE (wahr) zu setzen. Daher kann im Test F2 das System die Bedingung F2_In_StopTriggerPresent_Bool == TRUE durch den Inhalt von F1 ersetzen. Derselbe Algorithmus kann auf die Bedingung F2_In_TimerElapsed_Bool ==TRUE des Tests F2 ersetzt werden. Zusätzlich benutzt in der Signal-Datenbank die Definition des Signals ‚GearPosition‘ nicht mehr eine Konstante NEUTRAL, sondern den Wert 0. Daher ersetzt dieser Wert nun den Wert NEUTRAL dieses Signals in dem Test.
-
Das Ergebnis ist in der folgenden Tabelle 3 dargestellt.
Tabelle 3:
| Test-Kennung | Merkmal | Test-Beschreibung (Pseudocode) |
| 1 | Stopp/Sta rt-Merkmal | Schritt: |
| | If (StopStartDisabled == TRUE) |
| | and |
| | | (If (GearPosition == 0) and (APdIPosition <=0.01) and (CPdIPosition <=0.01)) |
| | | and |
| | | (Intern Clock = 0; |
| | | Start() Intern Clock; |
| | | If (Intern Clock > StopDelayCal)) |
| | | Akzeptanz: |
| | | StopEngine = TRUE |
-
Die Tests F1, F2 und F3 wurden aus zur Verfügung stehenden Unit-Tests, aus einem Architektur-Modell und optional aus einer Signal-Datenbank erzeugt. Diese drei Tests können in derselben Testumgebung wie die Unit-Tests automatisch durchgeführt werden. In einer Weiterentwicklung ist es möglich, ein zusätzliches Verfahren anzuwenden, um den erzeugten Test in einer menschenähnlicheren Sprache neu zu formulieren oder darin zu übersetzen, so dass zum Beispiel ein Testingenieur diese Tests auf einem Dynamometer, auf einem Prüfstand oder in einem Fahrzeug ausführen kann.
-
In einer Weiterentwicklung können die Merkmal-Tests direkt auf ein autonomes Fahrzeug hochgeladen werden, das die Tests implementieren und prüfen kann, ob das Verhalten oder Ansprechen des Fahrzeugs den Akzeptanzkriterien entspricht.
-
2 zeigt eine Übersicht über das System. Darin sind:
- 1
- Software-Architekturmodell
- 2
- Signal-Datenbank
- 3
- Unit-Tests
- 4
- Signalanpassungsmodul
- 5
- Zwischensignal-Erkennungsmodul
- 6
- Testkombinationsmodul
- 7
- Testerzeugungsmodul
- 8
- Testvereinfachungsmodul
- 9
- Testübersetzungsmodul
- 10
- Projektlebenszyklus-Managementsystem
- 11
- Die Kern-Software, welche die vorgenannten Module 1 bis 10 koordiniert.
-
Das Software-Architekturmodell 1 ist in einer Modellierungssprache geschrieben. Die Signal-Datenbank2 enthält eine genaue Definition aller auf unterschiedlichen Architekturebenen in einem Fahrzeug verwendeten Signale. Die Unit-Tests 3 sind während der Entwicklung von Software-Ingenieuren definiert worden. Mit dem Signalanpassungsmodul 4 wird bestimmt, welche Signale einander zugeordnet oder miteinander verbunden werden. Mit dem Zwischensignal-Erkennungsmodul wird bestimmt, welche Signale zwischen zwei Software-Elementen auf derselben Architekturebene verbunden sind. Das Testkombinationsmodul 6 dient zum Gruppieren von Tests aller Elemente, die einem Element auf einer höheren Architekturebene zugewiesen sind. Das Testerzeugungsmodul 7 dient zum Erzeugen von Tests auf einer höheren Architekturebene auf Basis der in den Modulen 1 bis 6 verarbeiteten Informationen. Das Testvereinfachungsmodul 8 dient zum Anwenden von Signalzuordnung und Vereinfachung auf einen erzeugten Test. Das Testübersetzungsmodul 9 dient zum Übersetzen der erzeugten und vereinfachten Tests in Testanweisungen, die von einem Menschen interpretiert werden können, oder in Tests, die automatisch in einem Dynamometer, auf einen Prüfstand oder in einem Fahrzeug oder autonomen Fahrzeug durchgeführt werden können. Die Kern-Software 11 besitzt außerdem eine Schnittstelle zu einem Projektlebenszyklus-Managementsystem 10 zum automatischen Aktualisieren einer Testspezifikation und von Verknüpfungen mit zugehörigen Anforderungen.
-
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 20150363296 A1 [0010]
- DE 10311864 A1 [0011, 0022]
- US 7490319 B2 [0012, 0023]
- US 20150135158 A1 [0013]
- KR 101134735 B1 [0014, 0024]
- KR 101618872 B1 [0015]
