-
Die Erfindung betrifft ein Verfahren zum Testen eines Steuergeräts, eine Anordnung zum Durchführen des Verfahrens sowie ein Computerprogramm und ein maschinenlesbares Speichermedium.
-
Stand der Technik
-
Zum Testen von Steuergeräten und insbesondere der in Steuergeräten ablaufenden Software sind unterschiedliche Verfahren bzw. Techniken bekannt. Eine bekannte Technik zum automatisierten Testen von Software wird als Fuzzing-Testing bezeichnet. Bei dieser Technik wird das zu testende Programm an einer oder mehreren Eingabeschnittstellen immer wieder mit Daten beschickt. Es handelt sich hierbei um fehlerhafte bzw. falsch gebildete, unerwartete oder zufällige Daten. Dem liegt die Überlegung zugrunde, dass mit solchen Daten Situationen im Betrieb der Software bzw. des Programms erzeugt werden, die mit anderen Testverfahren nicht erreicht werden können. So können Programme bei nicht plausiblen Daten ungewollt abstürzen. Auf diese Weise können Sicherheitslücken im Programm, die ansonsten verborgen bleiben, erkannt werden.
-
Fuzzing-Testing, was nachfolgend als Fuzzing-Testen bezeichnet wird, wird folglich dazu verwendet, um Sicherheitseinschränkungen und andere Fehler in Computersoftware und in eingebetteten Systemen zu erkennen. Dieses Verfahren umfasst das Senden von falsch gebildeten, nicht erwarteten oder vollkommen zufälligen Daten als Eingabe für eine Zielanwendung, die dann überwacht wird, um Ausnahmefälle, wie bspw. Programmabstürze, Überläufe oder ein undefiniertes Verhalten zu erkennen. Eine der Hauptvorteile des Fuzzing-Testens besteht darin, dass es keine genaue Kenntnis der Funktionalität der Anwendung erfordert.
-
Es wird hierin der Fokus auf die Kommunikation von Steuergeräten (ECU: electronic control unit) in Kraftfahrzeugen gelegt. Zu beachten ist, dass es bereits allgemein erhältliche Werkzeuge bzw. tools gibt, um Ethernet und CAN (controller area network) basierte Protokolle einem Fuzzing-Test zu unterziehen. Daneben gibt es auch eine Mutation-basierte Werkzeugumgebung für ein sogenanntes black box Fuzzing-Testen. Dies ist ein black-box Werkzeug bzw. Tool, bei dem der Quellcode nicht als Eingabe zur Verfügung steht.
-
Die eingesetzte Software hilft dabei, Risiken hinsichtlich der Sicherheit und andere Implementierungsfehler in automotiven eingebetteten Geräten mit Hilfe von falsch gebildeten Ethernet- oder CAN-Nachrichten zu erkennen. Um die Kosten und die Zeit für die Testvorbereitung zu minimieren, wird keine für das Zielgerät spezifische Software oder Hardware, wie bspw. Testmittel- bzw. -agent, Testhilfsprogramm bzw. Debugger, verwendet. Das Ergebnis des Tests wird durch Überwachen der Integrität der Zielanwendung bestimmt, im einfachsten Fall durch Erfassen eines Absturzes der Anwendung. Es wird in diesem Zusammenhang auf 1 verwiesen.
-
Ein anderer Ansatz beim Fuzzing-Testen ist das sogeannte white box source code fuzzing bzw. white box Fuzzing-Testen, bei dem der Quellcode bzw. Sourcecode oder die Anwendung in einer Debug-Umgebung ausgeführt wird. Dabei wird die Programmausführung während des Fuzzing-Prozesses genau überwacht. In diesem Fall ist beides, die Testabdeckung und der genaue Ort jedes gefundenen Fehlers, während des Testens verfügbar. Auf diese Weise können Eingaben so angepasst werden, dass mit diesen eine maximale Abdeckung erreicht wird und dass bereits identifizierte Abstürze vermieden werden.
-
Der vornehmliche Nachteil des black box Fuzzing-Testens besteht darin, dass es ohne Zugriff auf den internen Zustand des Geräts nicht möglich ist, die Abdeckung und den Fortgang des Testprozesses im Allgemeinen und im Besonderen eine konkrete Eingabe geeignet zu testen. Es ist nur eine binäre Rückgabe verfügbar, die lediglich bestimmt, ob die Zielanwendung abgestürzt ist oder nicht. Es werden keine zusätzlichen Informationen bereitgestellt. Selbst wenn diese Daten nach der Ausführung des Testfalls verfügbar werden, ist diese Rückgabe nicht ausreichend, um die Wirksamkeit einer Eingabe zu erkennen und geeignete Modifikationen während des Tests an dieser vorzunehmen. Daher wird bei diesem Ansatz die Eingabe zufällig manipuliert, ohne irgendeine Intelligenz und ohne irgendeine Rückmeldung zu dem Fortgang des Testens bezüglich der Teile der getesteten Anwendung.
-
White box basierte Softwareansätze überwachen den internen Zustand der Zielanwendung während des Tests und sammeln nützliche Daten, wie bspw. eine Codeabdeckung, um die Testfälle zu evaluieren. Diese Information wird dann berücksichtigt, wenn zusätzliche Eingaben erzeugt werden, so dass ein umfangreicherer Code abgedeckt wird oder spezifische Funktionen öfter getroffen werden. Der Nachteil dieses Ansatzes besteht darin, dass Software in einer sterilen, simulierten Umgebung und nicht auf der tatsächlichen Hardwareumgebung ausgeführt wird.
-
Für eingebettete Anwendungen kann der Unterschied aufgrund von Echtzeitanforderungen, einer begrenzten Leistungsfähigkeit der darunter liegenden Hardware-Implementierung und anderer Effekte der Realität dahingehend wichtig sein, dass es nicht einmal möglich oder machbar ist, den white box Ansatz für die integrierte Anwendung zu implementieren.
-
Offenbarung der Erfindung
-
Vor diesem Hintergrund werden ein Verfahren mit den Merkmalen des Anspruchs 1, eine Anordnung gemäß Anspruch 9, ein Computerprogramm nach Anspruch 10 sowie ein maschinenlesbares Speichermedium gemäß Anspruch 11 vorgestellt. Ausführungsformen ergeben sich aus den abhängigen Ansprüchen und aus der Beschreibung.
-
Es wird vorgeschlagen, die beiden eingangs vorgestellten Ansätze, das white box Fuzzing-Testen und das black box Fuzzing-Testen, miteinander zu kombinieren. Unter white box Testen wird eine Methode zum Testen einer Software bezeichnet, bei der die Tests mit Kenntnissen über die innere Funktionsweise des zu testenden Systems entwickelt werden.
-
Mit black box Testen wird eine Methode zum Testen einer Software bezeichnet, bei der Tests anhand der Spezfikation bzw. Anforderung entwickelt werden. Die Tests werden somit ohne Kentnisse über die innere Funktionsweise bzw. Implementierung des zu testenden Systems entwickelt. Black box Tests werden eingesetzt, um Fehler hinsichtlich der Spezifikation zu erkennen. Um Fehler in bestimmten Komponenten oder gar in fehlerauslösenden Komponenten selbst zu erkennen, werden jedoch white box Tests eingesetzt.
-
Black box Tests sind im Vergleich zu white box Tests regelmäßig aufwändiger in der Durchführung, ermöglichen aber typischerweise eine bessere Verifikation des Gesamtsystems.
-
Das vorgestellte Verfahren dient zum Testen eines Steuergeräts mit einer Test-Recheneinheit und sieht vor, dass an einer Schnittstelle des Steuergeräts Daten bzw. Testdaten eingegeben werden und Zustände des Steuergeräts in Reaktion auf diese eingegebenen Daten überwacht werden, wobei das Steuergerät über die Schnittstelle und über mindestens einen Betriebsdatenkanal mit der Test-Recheneinheit verbunden wird, und als Schnittstelle eine JTAG-Debug-Schnittstelle verwendet wird.
-
Die eingegebenen Daten sind bspw. zufällige Daten, insbesondere vollkommen zufällige Daten, unerwartete Daten und/oder fehlerhaft gebildete bzw. falsche Daten.
-
Es wird insbesondere vorgeschlagen, ein black-box Fuzzing-Testen on target, d. h. gerichtet auf ein Zielsystem, mit einer Schnittstelle über JTAG (Joint Test Action Group) zu erweitern und die Debug-Information zu verwenden, um den internen Zustand der ECU während des Fuzzing-Prozesses zu überwachen. Dieser Ansatz kombiniert somit die Vorteile der beiden bekannten Methoden.
-
Die Grundlage des neuen Ansatzes besteht darin, JTAG zu verwenden. JTAG bezeichnet eine Methode für das Testen und Debuggen integrierter Schaltungen.
-
Dabei wird angestrebt, integrierte Schaltungen auf Funktionen zu testen, während sie sich bereits in ihrer Arbeitsumgebung befinden.
-
Ein Zugriff auf JTAG steht in den meisten ECUs während der Entwicklung zur Verfügung. JTAG ist eine übliche Hardware-Debug-Schnittstelle, die einen direkten Zugriff auf die Chips auf dem Board ermöglicht. Mit Hilfe lediglich einiger Pins sind verschiedene Hardware-Debug-Features verfügbar. Es ist möglich, auf den Speicher des Geräts zuzugreifen, die Firmware auszugeben, den Wert der Register zu lesen oder den Stapel zu analysieren. Es ist wichtig, darauf hinzuweisen, dass für die Funktionen weder der Binärcode noch der Quellcode erforderlich sind.
-
Die Idee besteht darin, die Funktionalität von JTAG zu debuggen, um auf den internen Zustand der Anwendung während des Tests zuzugreifen. Auf diese Weise ist es möglich, nützliche Informationen aus dem Speicher des Geräts zu extrahieren, wie bspw. der Wert der verschiedenen Register. Durch Nutzung der frisch erhaltenen Informationen können intelligente Algorithmen verwendet werden, um Testfälle zu generieren, was typischerweise dazu führt, die Effizienz der Tests zu steigern.
-
Dieser Ansatz kann dazu verwendet werden, als Vorabtest zum Erhalten von Informationen vor dem eigentlichen Test zu dienen, oder selbst während eines tatsächlichen Tests, um die Testfälle kontinuierlich zu entwickeln und auf diese Weise die Effizienz zu steigern.
-
Zusätzlich ist zu beachten, dass, wenn ein Problem auftritt und das getestete Gerät einfriert oder erneut startet, es möglich ist, die Debug-Schnittstelle zu verwenden, um zusätzliche Informationen zu extrahieren. Im Falle eines Einfrierens werden der Programmzähler und der Stacktrace bzw. die Stapelspeicherzurückverfolgung direkt nützliche Informationen für den Entwickler bereitstellen. Somit kann der Grund für das Einfrieren erkannt bzw. identifiziert werden. Wenn die Anwendung während des Tests erneut startet oder regelmäßig abstürzt, ist es möglich, den Hardware-Debugger zu verwenden, um den Inhalt des Speichers und der Register auszulesen, bevor ein Neustart alle diese Informationen, die den Zustand der Software betreffen, löschen, wenn das Problem auftritt.
-
Die vorgestellte Anordnung dient zum Durchführen des beschriebenen Verfahrens und ist bspw. in einer Hardware und/oder Software implementiert. Die Anordnung kann in einem Steuergerät, bspw. in dem zu testenden Steuergerät, integriert oder als solches ausgebildet sein. Das Computerprogramm zum Durchführen des Verfahrens kann in diesem Steuergerät implementiert sein und mit einer Recheneinheit des Steuergeräts zur Ausführung kommen.
-
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und den beiliegenden Zeichnungen.
-
Es versteht sich, dass die voranstehend genannten und die nachstehend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
-
Figurenliste
-
- 1 zeigt in einem Flussdiagramm einen Ablauf eines bekannten Verfahrens.
- 2 zeigt in einem Flussdiagramm einen Ablauf einer Ausführungsform des vorgestellten Verfahrens.
- 3 zeigt in einem Diagramm die Verbindungen zwischen HardwareElementen.
-
Ausführungsformen der Erfindung
-
Die Erfindung ist anhand von Ausführungsformen in den Zeichnungen schematisch dargestellt und wird im Folgenden unter Bezugnahme auf die Zeichnungen ausführlich beschrieben.
-
1 zeigt in einem Flussdiagramm einen Ablauf eines bekannten Verfahrens zum Testen einer Software
-
2 zeigt in einem Flussdiagramm einen Ablauf einer Ausführungsform des vorgestellten Verfahrens.
-
3 zeigt eine Hardwareumgebung mit Verbindungen.
-
1 zeigt in einem Flussdiagramm einen möglichen Ablauf eines Verfahrens nach dem Stand der Technik. In einem ersten Schritt 10 werden richtige bzw. korrekte Nachrichten gesammelt. Dann werden in einem Schritt 12 zufällige Testszenarien erzeugt. Dann werden in einem Schritt 14 korrekte Nachrichten falsch gebildet. Hierbei werden intelligent entwickelte Szenarien (Schritt 18) berücksichtigt. Anschließend werden in einem Schritt 20 nicht korrekte Nachrichten gesendet. Daraufhin wird in einem Schritt 22 das Zielgerät überwacht. Es wird dann in einem Schritt 24 überprüft, ob das Gerät abgestürzt ist. Ist dies der Fall, wird in einem Schritt 26 eine Fehlerreproduktion versucht und anschließend in einem Schritt 28 ein Testergebnis bestimmt.
-
Ergibt die Überprüfung in Schritt 24, dass dies nicht gegeben ist, so erfolgt direkt ein Sprung zu Schritt 28. Abschließend springt der Programmablauf zurück zu Schritt 12.
-
2 zeigt in einem Flussdiagramm einen möglichen Ablauf des vorgestellten Verfahrens. In einem ersten Schritt 50 werden richtige bzw. korrekte Nachrichten gesammelt. Dann werden in einem Schritt 52 zufällige Testszenarien erzeugt. Darauf werden in einem Schritt 54 korrekte Nachrichten falsch gebildet. Hierbei werden intelligent entwickelte Szenarien (Schritt 58) berücksichtigt. Anschließend werden in einem Schritt 60 nicht korrekte Nachrichten gesendet. Daraufhin wird in einem Schritt 62 das Zielgerät überwacht. In einer Schleife 64 wird dann in einem Schritt 66 eine kontinuierliche Rückmeldung gesammelt.
-
Wie oft diese Schleife 64 durchlaufen wird, hängt von der Spezifikation und dem Protokoll des getesteten Geräts ab. Eine Rückmeldung kann nach jeder Nachricht oder nach jedem Block von Nachrichten gesammelt werden.
-
Es wird dann in einem Schritt 68 überprüft, ob das Gerät abgestürzt ist. Ist dies der Fall, werden in einem Schritt 70 Register ausgelesen, in einem Schritt 72 ein Fehler reproduziert und anschließend in einem Schritt 72 ein Testergebnis bestimmt.
-
Ergibt die Überprüfung in Schritt 68, dass dies nicht gegeben ist, so erfolgt direkt ein Sprung zu Schritt 72. Abschließend springt der Programmablauf zurück zu Schritt 58.
-
Auf Schritt 66 kann die Durchführung eines Schrittes 80 erfolgen, bei dem eine binäre Abdeckung evaluiert wird. Dies hängt von dem konkreten Anwendungsfall ab. Bspw. kann nach einer definierten Anzahl von Nachrichten in einem Testfall zu Schritt 80 übergegangen werden, um die binäre Abdeckung zu evaluieren. Es wird dann in einem Schritt 82 überprüft, ob der Test abgeschlossen ist. Ist dies der Fall, so wird das Verfahren beendet (Schritt 84). Ist dies nicht der Fall, so wird mit Schritt 58 das Verfahren fortgeführt.
-
3 zeigt eine Anordnung 100 von Hardwareelementen zur Durchführung des Verfahrens und verdeutlicht insbesondere die Verbindungen zwischen diesen Hardwareelementen.
-
Die Darstellung zeigt ein zu testendes Gerät bzw. Steuergerät 102 mit einer JTAG-Schnittstelle 104, einer CAN-Schnittstelle 106, einer Ethernet-Schnittstelle 108 und einer weiteren geeigneten Schnittstelle 110. Weiterhin sind eine JTAG-Debug-Schnittstelle 120 mit einer JTAG-Schnittstelle 122 und einer USB-Schnittstelle 124 gezeigt. Über diese USB-Schnittstelle 124 ist ein Testerrechner bzw. eine Test-Recheneinheit 130 mit einer USB-Schnittstelle 132 angebunden.
-
Weiterhin ist eine automotive Schnittstelle 140 gezeigt mit einer CAN-Schnittstelle 142, einer Ethernet-Schnitstelle 144, einer weiteren Schnittstelle 146 und einer USB-Schnittstelle 148.
-
Die vorgestellte Lösung erfordert lediglich die Funktion grundlegender Hardware- und Softwarewerkzeuge. Darüber hinaus sind diese nicht gerätespezifisch, vielmehr stellen diese eine allgemeine Einrichtung dar, die mit den meisten eingebetteten Systemen arbeitet. Zunächst ist eine JTAG-fähige Debug-Schnittstelle erforderlich. Solche Schnittstellen sind kostengünstig und weit verbreitet. Die Debug-Schnittstelle ist mit dem Zielgerät über JTAG und mit dem Test-Computer bspw. über USB zu verbinden. Das Zielgerät ist mit dem Test-Computer nur durch die Betriebsdatenkanäle, wie bspw. Ethernet, CAN usw., zu verbinden.
-
Auf der Softwareseite ist eine Debugger-Software erforderlich, die in der Lage ist, die Debug-Schnittstelle anzusteuern. Diese kann von irgendeinem Test-Rahmenwerk durch einen einfachen TCP/IP-Sockel gesteuert werden.
-
Mit dem Debugger ist es möglich, die Softwareausführung anzuhalten, Hardware-breakpoints zu setzen, Speicher und Register zu lesen, die Stapelspeicherzurückverfolgung bzw. Stacktrace auszulesen usw. Alle diese Merkmale sind während des Fuzzing-Testens nützlich und mit dem gezeigten Ansatz sind diese alle auf der tatsächlichen physischen ECU während der Testausführung verfügbar.
-
Um sicherzustellen, dass einige definierte kritische Teile der Software getestet werden, kann man breakpoints bei diesen kritischen Funktionen setzen. Somit hält die Testausführung, wenn diese breakpoints erreicht werden. Weiterhin können Eingaben der gegenwärtigen Eingabe angeglichen werden, um weiter den gesamten Funktionsbereich zu testen, oder diese zu vermeiden, wenn der Bereich bereits ausreichend abgedeckt ist.
-
Für eine Abschätzung des gesamten abgedeckten Softwarebereichs wird die Testausführung periodisch angehalten, der Ausführungszeiger abgerufen und fortgeführt. Die Verteilung der Zeiger zeichnet eine Karte der Binärcode-Abdeckung auf.
-
Für eine genauere Zielgebung kann die Codeausführung auf dem Ziel synchron mit den gesendeten Nachrichten angehalten werden und mit einer gewissen Feineinstellung ist es möglich, jede Nachricht mit ihrem spezifischen Beitrag für die Codeabdeckung zu erhalten. Kombiniert mit einem AI-Ansatz (AI: artificial intelligence; künstliche Intelligenz) können weitere Nachrichten erzeugt werden, um die Codeabdeckung zu maximieren, was zu einer signifikant verbesserten Testeffizienz und Wirksamtkeit führt.
