DE102022114286A1

DE102022114286A1 - Verfahren zum Rekonstruieren eines Laufzeitfehlers eines Softwaremoduls eines Kraftfahrzeug- Steuergeräts sowie Speichermedium und Prozessorschaltung

Info

Publication number: DE102022114286A1
Application number: DE102022114286.8A
Authority: DE
Inventors: Frank Pelster
Original assignee: Cariad SE
Current assignee: Cariad SE
Priority date: 2022-06-07
Filing date: 2022-06-07
Publication date: 2023-12-07

Abstract

Die Erfindung betrifft ein Verfahren zum Rekonstruieren eines Laufzeitfehlers (15) eines Softwaremoduls (12, 42), der in einem Steuergerät (14) eines Kraftfahrzeugs (13) stattfand und der durch ein Fehlerprotokoll beschrieben ist, wobei in einer Prozessorschaltung (10) ein Konfigurationsdatensatz (31), der ein Laufzeitszenario mit einem zu testenden Betriebssystemzustand (18, 30) definiert, gespeichert gehalten wird und das Softwaremodul (12, 42) in dem Betriebssystem (11, 17) durch ein Koppelmodul ausgeführt wird, welches einen jeweiligen Systemaufruf (25) aus dem Softwaremodul (12, 42) entgegen nimmt oder welchem der jeweilige Systemaufruf (25) durch das Betriebssystem (11, 17) zugeführt wird, und das zu dem jeweiligen Systemaufruf (25) Antwortdaten (29) generiert, die unabhängig von einem aktuellen Zustand des Betriebssystems (11, 17) gemäß dem durch den Konfigurationsdatensatz (31) definierten, zu testenden Betriebssystemzustand (18, 30) erzeugt werden, und diese Antwortdaten (29) an das Softwaremodul (12, 42) als Antwort auf den Systemaufruf (25) übergeben werden.

Description

Die Erfindung betrifft ein Verfahren zum Rekonstruieren eines Laufzeitfehlers, der in einem Softwaremodul eines Steuergeräts eines Kraftfahrzeugs beobachtet wurde und durch ein Fehlerprotokoll beschrieben ist. Das Ermitteln eines Auslösers oder einer Ursache eines solchen Laufzeitfehlers im Nachhinein anhand eines Fehlerprotokolls kann sehr aufwendig sein. Zu der Erfindung gehören auch ein computerlesbares Speichermedium, mittels welchem eine Prozessorschaltung derart programmiert oder ausgestaltet werden kann, dass sie das Verfahren durchführt, sowie eine Prozessorschaltung, die dazu eingerichtet ist, das Verfahren durchzuführen.
Ereignet sich in einem Kraftfahrzeug ein Laufzeitfehler in der Software eines Steuergeräts, so ist man im Nachhinein daran interessiert, die Ursache oder den Auslöser für den Laufzeitfehler zu identifizieren. Dies kann beispielsweise in einem Labor eines Herstellers des Steuergeräts oder des Kraftfahrzeugs stattfinden. Dort ist dann als Information über den Laufzeitfehler in der Regel lediglich das Fehlerprotokoll verfügbar, das beispielsweise nur im Nachhinein die Ereignisse nach Auftreten des Laufzeitfehlers beschreibt, also beispielsweise das Softwaremodul angibt, in welchem der Laufzeitfehler aufgetreten ist.
Ein Softwaremodul stellt in einem Steuergerät eines Kraftfahrzeugs die Grundlage für einen eigenen Prozess im Betriebssystem des Kraftfahrzeugs dar, ist also beispielsweise als eigenständige binäre Executable-Datei implementiert. Innerhalb eines Softwaremoduls gibt es eine Vielzahl von Einzelfunktionen, die Teilschritte der Funktionalität des Softwaremoduls bereitstellen, sodass hier die Identifizierung derjenigen Einzelfunktion, die den Laufzeitfehler verursacht hat, gewünscht ist. Eine Einzelfunktion kann beispielsweise in einer individuellen Quellcode-Datei programmiert sein, die die sogenannte Funktionsdefinition beinhaltet. Beispiele für solche Quellecode-Dateien sind .c-Dateien und .cpp-Dateien. Um Einzelfunktionen zu testen, können sie beispielsweise mittels eines Debuggers individuell oder voneinander getrennt ausgeführt werden und die im Funktionsaufruf beinhalteten Aufrufparameter können mit Testwerten belegt werden (sog. Unit-Testing). Erfahrungsgemäß lassen sich hierdurch nur sehr grobe Falschprogrammierungen innerhalb einer Einzelfunktion identifizieren, da weder das Wechselspiel mit anderen Einzelfunktionen noch das Wechselwirken mit der Laufzeitumgebung, in welcher das fertige Softwaremodul im Steuergerät ausgeführt wird, in Betracht gezogen werden. So kann beispielsweise eine Zeitverzögerung, die durch eine hohe Auslastung des Steuergeräts verursacht werden kann, mittels eines Debuggers für eine Einzelfunktion im Unit-Testing nicht nachvollzogen werden.
Im Gegensatz dazu kann ein fertiges Steuergerät als Hardware getestet werden, indem , im Labor elektrische Signalanschlüsse des Steuergeräts mit simulierten Signalen beaufschlagt werden, die ein Verhalten anderer Fahrzeugkomponenten vortäuschen oder nachempfinden. Bei dieser Form des Testens verbleibt aber das Steuergerät während des Tests als eine Blackbox, da das Steuergerät unter Echtzeitbedingungen betrieben wird und kein Anhalten des Steuergeräts zum Überprüfen eines Zwischenzustands eines Softwaremoduls möglich ist. Damit kann das Zusammenwirken der Einzelfunktionen nur begrenzt analysiert werden.
Aus der US 2020 / 0125472 A1 ist bekannt, dass während einer Fahrt eines Kraftfahrzeugs darin Fahrszenarien aufgezeichnet werden können, die später als Testfälle beispielsweise in einer Simulation rekonstruiert werden können.
Aus der US 2005 / 0283664 A1 ist bekannt, aus mehreren Testszenarien automatisiert solche auszuwählen, die zum Überprüfen eines zu testenden Softwaremoduls geeignet sind.
Aus der US 2020 / 0278922 A1 ist bekannt, an Signalanschlüssen eines zu testenden Geräts künstliche Signale, die das Verhalten anderer Geräten nachstellen, bereitzustellen oder zu erzeugen, damit das zu testende Gerät in derselben Weise betrieben werden kann, wie in einer realen Umgebung, in welcher das Gerät mit den anderen Geräten verbunden ist.
Der Erfindung liegt die Aufgabe zugrunde, bei Erkennen eines Laufzeitfehlers eines Softwaremoduls beim Betrieb eines Steuergeräts eines Kraftfahrzeugs im Nachhinein das Softwaremodul erneut in denjenigen Betriebszustand zu versetzen, in welchem sich der Laufzeitfehler ergeben hat, um einen Rückschluss auf die Fehlerursache zu ermöglichen.
Die Aufgabe wird durch die Gegenstände der unabhängigen Patentansprüche gelöst. Vorteilhafte Weiterentwicklungen ergeben sich durch die abhängigen Patentansprüche, die folgende Beschreibung sowie die Figur.
Als eine Lösung umfasst die Erfindung ein Verfahren zum Rekonstruieren eines Laufzeitfehlers eines Softwaremoduls, der sich in einem Steuergerät eines Kraftfahrzeugs ereignet hat oder dort stattfand und der durch ein Fehlerprotokoll beschrieben ist. Das Fehlerprotokoll kann beispielsweise angeben, welches Steuermodul den Laufzeitfehler verursacht hat und/oder es kann Zustandsdaten des Steuergeräts beinhalten.
Die Erfindung geht davon aus, dass das Softwaremodul in der Weise einen komplexen Aufbau oder eine komplexe Struktur aufweist, dass das Softwaremodul mehrere beim Ausführen miteinander wechselwirkende Einzelfunktionen umfasst und zumindest eine dieser Einzelfunktionen zumindest einen Systemaufruf zum Interagieren mit einem das Softwaremodul ausführenden Betriebssystem des Steuergeräts umfasst. Ein Betriebssystem verwaltet die Systemressourcen der Prozessorschaltung, beispielsweise den Arbeitsspeicher (RAM - Random Access Memory) und/oder den nicht-volatilen Speicher (beispielsweise Flash-Speicher) und/oder den Netzwerkanschluss (BUS-Controller und/oder NAC - Network Access Controller). Eine Einzelfunktion eines Softwaremoduls kann nicht direkt auf eine solche Systemressource zugreifen, sondern muss eine entsprechende „Anfrage“ beim Betriebssystem stellen, was durch den sogenannten Systemaufruf oder SysCall erfolgt, der in der Hardware des das Softwaremodul ausführenden Mikroprozessors einen Sprung oder eine Verschiebung des Programmzählers oder Programm-Pointers in einen Adressbereich des Betriebssystems bewirkt, und zwar dort auf einen sogenannten Handler des SysCalls. Ein solcher Handler kann dann für das Softwaremodul den Zugriff auf die Systemressource durchführen oder zumindest vorbereiten, ohne dass sich hierdurch eine Kollision an der Systemressource mit einem anderen Softwaremodul ergibt, da das Betriebssystem den exklusiven Zugriff auf die Systemressource hat. Das Softwaremodul kann in der beschriebenen Weise mehrere miteinander wechselwirkende Einzelfunktionen aufweisen, sodass der Test also es nicht erfordert, Einzelfunktionen, beispielsweise aus einzelnen Quelltext-Dateien, isoliert zu prüfen. Die Einzelfunktionen können in einem Quellcode des Softwaremoduls aber jeweils in der bekannten Weise durch Funktionsdefinitionen implementiert sein, wie sie auch für einen Unit-Test geeignet sind.
Die Erfindung erlaubt es zu prüfen, ob sich der Laufzeitfehler bei der Interaktion mit dem Betriebssystem ereignet hat. Bei dem Verfahren der Erfindung wird hierzu in einer (z.B. fahrzeugexternen) Prozessorschaltung ein Konfigurationsdatensatz bereitgestellt oder gespeichert gehalten, der ein Laufzeitszenario mit einem zu testenden Betriebssystemzustand definiert. Das Laufzeitszenario kann z.B. auch noch Signalverläufe von Signalen angeben, mit denen das Softwaremodul beaufschlagt oder konfrontiert werden soll.
Die Prozessorschaltung dient dabei als Testplattform, in der der Betriebszustand oder allgemein das Laufzeitszenario nachgestellt wird. Die Prozessorschaltung führt hierzu ein Betriebssystem aus wie dasjenige, das auch in dem Steuergerät des Kraftfahrzeugs vorhanden war, Durch den Konfigurationsdatensatz wird dafür zumindest eine Betriebsbedingung definiert, sodass sich für den Betrieb des Softwaremoduls in dem Betriebssystem eine entsprechende Randbedingung oder Betriebsumgebung durch den Konfigurationsdatensatz ergibt. Beispielsweise kann der Konfigurationsdatensatz vorgeben, dass für den RAM eine Belegung von 99% angenommen werden soll. Mit dieser zumindest einen Randbedingung wird durch die Prozessorschaltung das Softwaremodul in Betrieb genommen oder ausgeführt. Es muss nicht dasselbe Softwaremodul aus dem Steuergerät sein, sondern es reicht ein gleichartiges Softwaremodul, also dieselbe Softwareversion, aber eine andere Kopie des Binärcodes. Dieses wird somit in einem gleichartigen Betriebssystem, also einem Betriebssystem, wie es auch in dem Steuergerät beim Entstehen des Laufzeitfehlers das Softwaremodul ausgeführt hat, betrieben. Allerdings wird das Softwaremodul nicht direkt in dem Betriebssystem betrieben, wie es in dem Steuergerät der Fall war. Stattdessen wird das Softwaremodul durch die Prozessorschaltung in dem Betriebssystem durch ein Koppelmodul ausgeführt, welches den jeweiligen Systemaufruf aus der zumindest einen Einzelfunktion des Softwaremoduls selbst direkt entgegennimmt (also nicht das Betriebssystem nimmt den Systemaufruf entgegen) oder welchem der jeweilige Systemaufruf durch das Betriebssystem zugeführt wird, anstatt dass er durch das Betriebssystem unmittelbar beantwortet wird. Hierzu kann das Betriebssystem dahingehend umgestaltet werden, dass der Handler für den Systemaufruf die Aufrufdaten des Systemaufrufs an das Koppelmodul durchreicht. Es kann also ein Koppelmodul zum Entgegennehmen eines Systemaufrufs angepasst werden oder das Betriebssystem kann zum Weiterleiten des Systemaufrufs in das Koppelmodul angepasst werden. Das Koppelmodul generiert zu dem jeweiligen Systemaufruf Antwortdaten, die bevorzugt unabhängig von einem aktuellen tatsächlichen Zustand des Betriebssystems sind, sondern stattdessen gemäß dem zu testenden Betriebssystemzustand erzeugt werden, der durch den Konfigurationsdatensatz definiert ist. So besteht in der beschriebenen Weise beispielsweise der zu testende Betriebszustand darin, dass ein RAM des Steuergeräts voll ist (z.B. Belegung zu 99%), sodass kein weiterer Speicher für das Softwaremodul reserviert werden kann. Dagegen kann das tatsächlich laufende Betriebssystem, welches das Softwaremodul und das Koppelmodul ausführt, noch ausreichend RAM zur Verfügung haben. In dem Koppelmodul wird der jeweilige Systemaufruf aber in der Weise behandelt, wie es durch die Konfigurationsdaten vorgegeben ist, also beispielsweise wie bei vollem RAM. Somit wird beispielsweise ein Systemaufruf zum Allokieren von weiterem Datenspeicher (z.B. der Aufruf malloc() - memory allocation) negativ beschieden werden, da gemäß dem zu testenden Betriebszustand kein RAM mehr zur Verfügung steht oder dieser voll ist. Diese Antwortdaten werden an das Softwaremodul als Antwort auf den Systemaufruf übergeben. Somit ergibt sich aus Sicht oder im Prozess-Kontext des Softwaremoduls ein Betrieb in einem Betriebssystem, das den zu testenden Betriebszustand aufweist.
Bei dem Verfahren werden des Weiteren ein Speicherabbild des ausgeführten Softwaremoduls und/oder ein Laufzeitprotokoll des Softwaremoduls bereitgestellt, mittels welchem das Betriebsverhalten des Softwaremoduls mit dem Fehlerprotokoll verglichen werden kann. Beispielweise kann das Speicherabbild aktuelle Werte von Variablen und/oder einen Stack-Trace des Softwaremoduls anzeigen. Ergibt sich eine Übereinstimmung mit dem Fehlerprotokoll, so wird daraus der Rückschluss gezogen, dass durch den Konfigurationsdatensatz derjenige Betriebssystemzustand beschrieben ist, der zu dem Laufzeitfehler geführt hat, wie er im Fehlerprotokoll protokolliert ist. Ein geeignetes Speicherbild kann beispielsweise mittels eines sogenannten Debuggers ermittelt werden. Ein Laufzeitprotokoll kann beispielsweise Ausgabesignale des Softwaremoduls enthalten und im Kraftfahrzeug durch das Steuergerät erzeugt worden sein (z.B. als sogenannten Fehlereintrag in ein Fehlerprotokoll).
In der Prozessorschaltung wird also ein gleichartiges Softwaremodul (wie im Steuergerät) in einem gleichartigen Betriebssystem (wie im Steuergerät) betrieben, allerdings ist zwischen Softwaremodul und Betriebssystem ein Koppelmodul, also beispielsweise eine weitere Software, vorgesehen, die den Zugriff der Einzelfunktionen des Softwaremoduls auf das Betriebssystem (Systemaufrufe) abfängt oder umleitet, um in dem Koppelmodul die Antwortdaten, die von der Einzelfunktion als Antwort auf den Systemaufruf hin erwartet werden, dahingehend zu manipulieren oder festzulegen, wie es durch den Konfigurationsdatensatz definiert ist, um einen zu testenden Betriebssystemzustand vorzutäuschen oder zu simulieren.
Durch die Erfindung ergibt sich der Vorteil, dass das Softwaremodul im Ganzen betrieben werden kann, also nicht nur seine Einzelfunktionen in Unit-Tests unabhängig voneinander getestet werden, und hierbei auch die Wechselwirkung des Softwaremoduls mit dem Betriebssystem nachgestellt oder geprüft werden kann, was bei einem Betrieb des Steuergeräts (Hardware in the Loop) nicht möglich wäre. Das Verfahren ist insofern ein Verfahren mit Reverse-Engineering-Ansatz, als dass potentielle oder hypothetische Betriebssystemzustände als zu testende Betriebszustände vorgegeben werden können, und überprüft werden kann, ob ein solcher Betriebssystemzustand Ursache des Laufzeitfehlers war. Der Konfigurationsdatensatz kann aber auch beispielsweise anhand des Fehlerprotokolls erzeugt werden, falls in dem Fehlerprotokoll entsprechende Zustandsdaten des Betriebssystems des Kraftfahrzeugs gespeichert sind, wie sie vor dem Laufzeitfehler bis hin zum Eintreten des Laufzeitfehlers vorhanden waren. Da mittels des Verfahrens ein vollständiges Softwaremodul in einem simulierten Szenario nach Art oder mit den Vorzügen eines Unit-Testing getestet werden kann, wird das Verfahren hier auch als „Scenario-Based-Unit-Testing“ bezeichnet.
Die Erfindung umfasst auch Weiterentwicklungen, durch die sich zusätzliche Vorteile ergeben.
Die besagte Prozessorschaltung, auf welcher der beschriebene Test des Softwaremoduls durchgeführt wird, kann in dem Steuergerät selbst vorhanden sein oder sie kann in einem Computersystem beispielsweise in einem Labor des Herstellers des Steuergeräts und/oder des Kraftfahrzeugs bereitgestellt sein. Beispiele für ein Softwaremodul, wie es als Ganzes in der Prozessorschaltung getestet werden kann, sind beispielsweise ein Glättungsfilter, wie es zum Verarbeiten oder Bearbeiten von Messsignalen in dem Steuergerät verwendet werden kann, und/oder ein Health-Management-Modul, das beispielsweise eine Speicherbelegung und/oder einen Prozessorlast in dem Steuergerät protokolliert oder überwacht.
Besonders kritische Systemaufrufe, die zu Laufzeitfehler führen können und die deshalb mittels des Verfahrens durch das Koppelmodul bevorzugt überwacht werden, sind insbesondere die folgenden.
In einer Weiterentwicklung umfasst der zumindest eine Systemaufruf eine Speicherreservierung (beispielsweise malloc()) und/oder eine Speicherfreigabe (free()). Der durch den Konfigurationsdatensatz vorgegebene Betriebssystemzustand ist ein vorbestimmter Belegungszustand des Speichers, beispielsweise des RAMs. Insbesondere handelt es sich um einen Belegungszustand, durch welchen die Speicherreservierung und/oder Speicherfreigabe zu einem Fehler des Systemaufrufs als Antwortdaten führt.
Beispielsweise kann der verbleibende verfügbare Speicher vom Datenvolumen her kleiner sein als durch die Speicherreservierung angefragt wird. Zusätzlich oder alternativ dazu kann der Belegungszustand derart gewählt werden, dass es zu einer Verzögerung beim Bereitstellen der Antwortdaten kommt. Entsprechende Betriebssystemzustände sind dem Fachmann bekannt, beispielsweise durch Einstellen einer Verfügbarkeit an freiem Speicher von 0 Prozent. Eine Verzögerung kann beispielsweise nachgebildet werden, indem in dem Koppelmodul eine Zeitmanipulation der von dem Softwaremodul für seine Operationen zugrunde gelegten Zeit vorgenommen wird. In dem Koppelmodul kann hierzu die Zeit des Betriebssystem-Zeit-Aufrufes (Beispiel clock_gettime()) manipuliert werden und somit dem Softwaremodul jeder zeitliche Ablauf manipulieret/ simuliert werden. Dieser Ansatz hat zusätzlich den Vorteil, dass eine zu testende Code-Sequenz nur immer die Zeit dauert die aller hintereinander angefügten Programmschritten an Zeit kosten. Die tatsächlichen zeitlichen Abstände zwischen den Programmschritten spart man durch die Manipulation der Zeit ein. Beispiel: Das Softwaremodul wird durch einen Timer 4-mal die Stunde geweckt um eine Berechnung durchzuführen. Die zu testende Zeit in dem Verfahren (Scenario-Based-Unit-Testing) würde 4-mal die Berechnung betragen und 4-mal die Manipulation der Betriebssystem-Zeit. Alle einzelnen Programmschritte werden sequenziell ausgeführt und der Software-Durchlauf durch das Softwaremodul ist eins-zu-eins der gleiche wie in der Realität. Dieser Ansatz erbringt eine zeitlichen Zusatz-Gewinn beim Testen.
Ein weiterer wichtiger Systemaufruf ist das Interagieren mit einem Datennetzwerk. Eine Weiterentwicklung umfasst, dass der zumindest eine Systemaufruf ein Auslesen von Empfangsdaten aus einem Empfangspuffer eines Netzwerkanschlusses eines Datennetzwerks anfordert. Ein solcher Systemaufruf kann beispielsweise der Zugriff auf eine sogenannte IP-Socket (IP - Internetprotokoll) sein, wie er als Systemaufruf recv() bekannt ist. Als zu testender Betriebszustand wird durch den Konfigurationsdatensatz ein vorbestimmter Belegungszustand des Datennetzwerks und/oder des Netzwerkanschlusses vorgegeben, durch welchen insbesondere das Zurückgeben der Antwortdaten um ein durch den Konfigurationsdatensatz vorgegebenen Zeitdauerwert manipuliert wird und/oder die Empfangsdaten für den Systemaufruf sogar unzugänglich oder nicht vorhanden sind. Mit anderen Worten kann beispielsweise wieder mit der beschriebenen Zeitmanipulation eine Verzögerung beim Übergeben der Antwortdaten an das Softwaremodul forciert oder vorgetäuscht werden. Zusätzlich oder alternativ dazu kann als Antwortdaten beispielsweise eine Fehlermeldung generiert werden, die besagt, dass der Netzwerkanschluss nicht zugänglich ist oder keine Netzwerkdaten vorhanden sind. Somit kann die Reaktion des Softwaremoduls auf ein überlastetes Datennetzwerk und/oder ein unzugängliches Datennetzwerk und/oder den Ausfall einer Datenquelle geprüft werden.
Gemäß einer Weiterbildung umfasst der zumindest eine Systemaufruf eine Timer-Operation eines Betriebssystem-Timers des Betriebssystems. Eine solche Timer-Operation kann beispielsweise eine mittels des Systemaufrufs definierte Funktion oder Einsprungadresse aufrufen, wenn der Wert des Timers abgelaufen ist. Mittels des zu testenden Betriebssystemzustands kann ein Fachmann beispielsweise ein vorbestimmtes Timerverhalten vorgeben, beispielsweise einen Jitter des Timers simulieren oder nachbilden.
Als Laufzeitfehler kann beispielsweise ein falscher interner Variablenwert und/oder ein Zählerüberlauf und/oder eine ungültiger Pointer detektiert werden.
Gemäß einer Weiterbildung wird für den Fall, dass durch die Prozessorschaltung der Laufzeitfehler detektiert wird, der Konfigurationsdatensatz, der zu diesem Laufzeitfehler geführt hat, einer Sammlung von Konfigurationsdatensätzen einer Testumgebung für neue Softwaremodule hinzugefügt. Das Detektieren eines Laufzeitfehlers kann mit einer Logik aus dem Stand der Technik durchgeführt werden, wie sie auch beispielsweise zum Erzeugen eines Fehlerprotokolls bekannt ist. Ein Betriebssystem kann z.B. einen Laufzeitfehler detektieren (z.B. einen void-Pointer). Durch Hinzufügen des Konfigurationsdatensatzes zu der Sammlung ergibt sich nach mehreren solcher Fehlerüberprüfungen eine Sammlung für eine Testumgebung, die in der Lage ist, ein neues Softwaremodul auf all diejenigen Fehlerquellen zu prüfen, die durch die gesammelten Konfigurationsdatensätze definiert sind. Entsprechend kann dann zumindest eine Weiterentwicklung oder Neuversion des Softwaremoduls, also ein Nachfolger oder eine Aktualisierung des Softwaremoduls, vor der Installation in dem Steuergerät des Kraftfahrzeugs systematisch getestet werden, und die Installation im Steuergerät erfolgt nur für den Fall, dass das neue Softwaremodul zuvor in der Testumgebung für alle Konfigurationsdatensätze ohne Laufzeitfehler betrieben werden konnte. Somit ergibt sich eine wachsende Sammlung an Konfigurationsdatensätzen, um jedes neue Softwaremodul auf bekannte Ursachen für Laufzeitfehler prüfen zu können. Die Testumgebung kann beispielsweise die beschriebene Prozessorschaltung selbst umfassen, die auch zum Rekonstruieren der Laufzeitfehler genutzt wurde. Hierzu kann beispielsweise auch ein sogenannter Debugger verwendet werden. Die Implementierung in dem Steuergerät kann dahingehend automatisiert erfolgen, als dass sie blockiert wird, solange nicht für alle Konfigurationsdatensätze ein Betrieb ohne Laufzeitfehler detektiert wurde.
Wie bereits ausgeführt wurde, kann der Konfigurationsdatensatz für ein Reverse-Engineering einen solchen Betriebssystemzustand beschreiben, für den vermutet wird, dass er zu dem Laufzeitfehler geführt hat. Gemäß einer Weiterbildung werden mehrere Konfigurationsdatensätze vorgesehen, die mehrere zu testende Betriebssystemzustände beschreiben, von denen jeder als ein Auslöser des Laufzeitfehlers geprüft werden soll. Mit anderen Worten kann der Fachmann mittels mehrerer Konfigurationsdatensätze mögliche potentielle Betriebssystemzustände systematisch prüfen lassen, ob sie die Ursache für den Laufzeitfehler sind. Jeder der Konfigurationsdatensätze beschreibt also einen anderen der zu testenden Betriebssystemzustände. Somit kann eine systematisierte Suche nach einer Ursache für eine Laufzeitumgebung erfolgen. Die Konfigurationsdatensätze können beispielsweise nacheinander in einer sogenannten FOR-Schleife bei der Prozessorschaltung eingestellt werden und dann jeweils der Betrieb des Softwaremoduls erfolgen.
Um das Softwaremodul von dessen Start an zu testen, ist für den Fall, dass das Softwaremodul eine ausführbare Binärdatei, also ein Binary Executable, ist, durch das Koppelmodul vorgesehen, dass dieses das Softwaremodul als sogenannten Kindprozess (Child Process) startet. Somit läuft das Softwaremodul als eigenständiger Prozess im Betriebssystem und ist durch seine Beziehung als Kindprozess mit dem Koppelmodul als Elternprozess verknüpft, um die Systemaufrufe übertragen zu können. Das Softwaremodul und Koppelmodul können alternativ auch als ein einziges Binary Executable kompiliert und/oder gelinkt werden.
Zusätzlich oder alternativ dazu ist vorgesehen, dass das Koppelmodul zum Starten des Softwaremoduls dessen Hauptfunktion, also eine sogenannte main-Funktion (main()), in der Weise aufruft, wie es in dem Steuergerät des Kraftfahrzeugs auch durch das dortige Betriebssystem erfolgt ist, bevor es zu dem Laufzeitfehler kam. Somit ist sichergestellt, dass für das Rekonstruieren des Laufzeitfehlers die vollständigen Verarbeitungsschritte des Softwaremoduls in der Prozessorschaltung ausgeführt werden. Dieser Ansatz ist besonders bevorzugt im hier beschriebenen Scenario-Based-Unit-Testing. Das Softwaremodul wird immer durch seine main-Funktion (main()) gestartet und danach durch den Konfigurationsdatensatz in seinen Fehlerzustand/ Laufzeitfehler getrieben.
Gemäß einer Weiterbildung wird in der Prozessorschaltung dem zu testenden Softwaremodul eine eigene Systemzeit mittels einer simulierten Systemuhr und/oder mittels eines dem Softwaremodul bereitgestellten Zählerregisters vorgegeben. Die Systemzeit, die das Softwaremodul zu dessen Laufzeit sieht oder bereitgestellt bekommt, kann sich also von der Systemzeit der Prozessorschaltung unterscheiden. Diese für das Softwaremodul vorgesehene Systemzeit wird dabei nur dann inkrementiert oder läuft nur dann weiter, während die Prozessorschaltung vorbestimmte Verfahrensschritte durchführt. Andernfalls ist diese Systemzeit für das Softwaremodul angehalten, während dagegen die Systemzeit der Prozessorschaltung weiterlaufen kann. Hierdurch ergibt sich der Vorteil, dass ein Betrieb des Softwaremoduls durch Anhalten von dessen Prozess, also durch Stillstand von dessen Programmzähler, angehalten werden kann und mittels der Prozessorschaltung, die natürlich noch weiterläuft, eine Analyse des Zustands des Softwaremoduls durchgeführt werden kann, beispielsweise eine Analyse des Speicherabbilds des angehaltenen Softwaremoduls. Dies sind Verfahrensschritte, die nicht Teil des Betriebs im Steuergerät selber sein würden, weshalb die Systemzeit für das Softwaremodul angehalten wird. Somit ist verhindert, dass es zu einem Echtzeit-Laufzeitfehler im Softwaremodul kommt, nur weil die Prozessorschaltung zusätzliche Analyseschritte durchführt, die nicht Bestandteil des Betriebs des Softwaremoduls im Steuergerät sein würden. Dem Softwaremodul können durch Manipulieren von dessen Systemzeit Echtzeitbedingungen vorgetäuscht werden, beispielsweise der durchgehende Betrieb einer Oszillatorschaltung, deren Signal von dem Softwaremodul empfangen und verarbeitet wird. Die Systemzeit kann zusätzlich oder alternativ auch vorgestellt werden, um Zeitsprünge zu simulieren, um somit den zeitlichen Ablauf von Konfigurationsdatensätze extrem zu verkürzen.
Gemäß einer Weiterbildung wird auch eine zusätzliche Interaktion des Softwaremoduls mit anderen Signalquellen und/oder Senken simuliert, sodass nicht nur Systemaufrufe überprüft werden. Hierzu umfasst die zumindest eine Einzelfunktion des Softwaremoduls einen Signalaustausch über zumindest eine API (Application Programming Interface) mit zumindest einem anderen Softwaremodul (beispielsweise einem Signalfilter und/oder einer IPC - Interprocess Communication) - und/oder über eine Hardwareschnittstelle mit zumindest einer Geräteressource (beispielsweise einem Batteriemanagement und/oder einem Mikrokontroller). Der jeweilige Konfigurationsdatensatz gibt dabei jeweils für diese API und/oder die Hardwareschnittstelle auf das Softwaremodul einwirkende Eingangssignale vor. Somit wird also das Softwaremodul auch über diese Schnittstellen (API und/oder Hardwareschnittstelle) getriggert oder angeregt oder zu einer Reaktion angeregt. Dieses jeweilige Eingangssignal simuliert dabei ein Verhalten des zumindest einen anderen Softwaremoduls und/oder der zumindest einen Geräteressource. Somit sind das jeweilige andere Softwaremodul und/oder die Geräteressource nicht für den Betrieb beim Nachstellen oder Rekonstruieren des Laufzeitfehlers notwendig. Es reichen deren Signale, die als Eingangssignale auf das Softwaremodul einwirken. Insgesamt bildet das zumindest eine Eingangssignal in seiner zeitlichen Abfolge der Signalwerte ein Betriebsszenario nach, wie es auch in dem Kraftfahrzeug abgelaufen sein kann, bis es zu dem Laufzeitfehler kam. Eingangssignale der beschriebenen Art können beispielsweise durch Mitschneiden oder Abspeichern korrespondierender Betriebssignale im Kraftfahrzeug beispielsweise durch einen Protokollschreiber ermittelt oder erzeugt werden. Somit kann eine reale Fahrsituation nachempfunden werden. Dies hat sich als vorteilhaft erwiesen im Vergleich zu künstlichen Eingangssignalen, die durch einen Simulator ohne tatsächliches Fahrereignis erstellt wurden.
Für Anwendungsfälle oder Anwendungssituationen, die sich bei dem Verfahren ergeben können und die hier nicht explizit beschrieben sind, kann vorgesehen sein, dass gemäß dem Verfahren eine Fehlermeldung und/oder eine Aufforderung zur Eingabe einer Nutzerrückmeldung ausgegeben und/oder eine Standardeinstellung und/oder ein vorbestimmter Initialzustand eingestellt wird.
Das beschriebene Kraftfahrzeug ist bevorzugt als Kraftwagen, insbesondere als Personenkraftwagen oder Lastkraftwagen, oder als Personenbus oder Motorrad ausgestaltet.
Zu der Erfindung gehört auch die Prozessorschaltung, die dazu eingerichtet ist, eine Ausführungsform des erfindungsgemäßen Verfahrens durchzuführen. Die Prozessorschaltung kann hierzu zumindest einen Mikroprozessor und/oder zumindest einen Mikrocontroller und/oder zumindest einen FPGA (Field Programmable Gate Array) und/oder zumindest einen DSP (Digital Signal Processor) aufweisen. Des Weiteren kann die Prozessorschaltung Programmcode aufweisen, der dazu eingerichtet ist, bei Ausführen durch die Prozessorschaltung die Ausführungsform des erfindungsgemäßen Verfahrens durchzuführen. Der Programmcode kann in einem Datenspeicher der Prozessorschaltung gespeichert sein.
Als eine weitere Lösung umfasst die Erfindung auch ein computerlesbares Speichermedium, umfassend Programmcode, der bei der Ausführung durch eine Prozessorschaltung eines Computers oder eines Computerverbunds diese veranlasst, eine Ausführungsform des erfindungsgemäßen Verfahrens auszuführen. Das Speichermedium kann z.B. zumindest teilweise als ein nichtflüchtiger Datenspeicher (z.B. als eine Flash-Speicher und/oder als SSD - solid state drive) und/oder zumindest teilweise als ein flüchtiger Datenspeicher (z.B. als ein RAM - random access memory) bereitgestellt sein. Das Speichermedium kann in der Prozessorschaltung in deren Datenspeicher angeordnet sein. Das Speichermedium kann aber auch beispielsweise als sogenannter Appstore-Server im Internet betrieben sein. Durch den Computer oder Computerverbund kann eine Prozessorschaltung mit zumindest einem Mikroprozessor bereitgestellt sein. Der Programmcode können als Binärcode oder Assembler und/oder als Quellcode einer Programmiersprache (z.B. C) und/oder als Programmskript (z.B. Python) bereitgestellt sein.
Die Erfindung umfasst auch die Kombinationen der Merkmale der beschriebenen Ausführungsformen. Die Erfindung umfasst also auch Realisierungen, die jeweils eine Kombination der Merkmale mehrerer der beschriebenen Ausführungsformen aufweisen, sofern die Ausführungsformen nicht als sich gegenseitig ausschließend beschrieben wurden.
Im Folgenden sind Implementierungsbeispiele der Erfindung beschrieben. Hierzu zeigt die einzige Figur:

Fig. eine schematische Darstellung einer Ausführungsform der erfindungsgemäßen Prozessorschaltung.

Bei den im Folgenden erläuterten Ausführungsbeispielen handelt es sich um bevorzugte Ausführungsformen der Erfindung. Bei den Ausführungsbeispielen stellen die beschriebenen Komponenten der Ausführungsformen jeweils einzelne, unabhängig voneinander zu betrachtende Merkmale der Erfindung dar, welche die Erfindung jeweils auch unabhängig voneinander weiterbilden. Daher soll die Offenbarung auch andere als die dargestellten Kombinationen der Merkmale der Ausführungsformen umfassen. Des Weiteren sind die beschriebenen Ausführungsformen auch durch weitere der bereits beschriebenen Merkmale der Erfindung ergänzbar.
In der Figur bezeichnen gleiche Bezugszeichen jeweils funktionsgleiche Elemente.
Die Figur zeigt eine Prozessorschaltung 10, die beispielsweise als ein Computer oder ein Verbund aus mehreren Computern beispielsweise in einem Entwicklungslabor oder in einer Werkstatt betrieben werden kann. Mittels der Prozessorschaltung 10 kann ein Betriebssystem 11 ausgeführt oder betrieben werden, um mittels des Betriebssystems ein Softwaremodul 12 auszuführen oder zu betreiben, das einem Softwaremodul 12' gleicht, das in einem Kraftfahrzeug 13 in einem Steuergerät 14 betrieben worden wurde, als es bei dem Betrieb des Softwaremoduls 12' im Steuergerät 14 zu einem Laufzeitfehler 15 gekommen war, der in Protokolldaten eines Fehlerprotokolls 16 beschrieben ist.
Mittels der Prozessorschaltung 10 kann nun der Betrieb des Softwaremoduls 12 in dem Betriebssystem 17 des Steuergeräts 14 dahingehend nachgestellt oder simuliert werden, als dass das Softwaremodul 12 in einen Zustand oder eine Umgebung gebracht wird, in welcher sich der Laufzeitfehler 15 erneut ereignet. In der Prozessorschaltung 10 ist dabei aber der Zustand des Softwaremoduls 12 beobachtbar oder analysierbar, sodass eine Ursache des Laufzeitfehlers 15 ermittelt werden kann.
Das Betriebssystem 11 der Prozessorschaltung 10 oder das in der Prozessorschaltung 10 für das Softwaremodul 12 betriebene Betriebssystem 11, wenn es beispielsweise in einer virtuellen Umgebung ausgeführt wird, kann vom Typ oder der Ausgestaltung dem Betriebssystem 17 gleichen. Allerdings ist ein Betriebssystemzustand 18 des Betriebssystems 11 natürlich durch den Betrieb in der Prozessorschaltung 10 gegeben und muss nicht unbedingt zu dem Laufzeitfehler 15 führen.
Das Erkennen oder das Ermitteln der Ursache des Laufzeitfehlers 15 im Softwaremodul 12 kann daher insofern aufwendig sein, als dass in dem Softwaremodul 12 dessen Modulfunktionalität 19 durch mehrere einzelne Einzelfunktionen 20 gebildet sein kann, die auch beispielsweise aus unterschiedlichen Quellcode-Dateien 21 gebildet worden sein können. Entsprechend kann nach dem Kompilieren der Quellcode-Dateien 21 das Softwaremodul 12 durch Kombinieren der kompilierten Quellcode-Dateien 21 mittels eines Linkers ein komplexes Zusammenspiel der Einzelfunktionen 20 gebildet worden sein, die sich auch dahingehend gegenseitig beeinflussen können, als dass hierdurch ebenfalls eine mögliche Ursache für den Laufzeitfehler 15 besteht.
Eine weitere mögliche Ursache für den Laufzeitfehler 15 kann gewesen sein, dass an einer API ein Austausch von Daten mit zumindest einem anderen Softwaremodul 40 falsch oder nicht programmgemäß durchgeführt wurde.
Eine weitere Fehlerursache kann an einer Hardwareschnittstelle 22 durch einen Austausch von Daten und/oder Signalen mit zumindest einer Geräteressource 23 des Steuergeräts 14 vorgekommen sein.
Ein besonders schwierig zu analysierender Fehler ist an einer Systemschnittstelle 24 möglich, über welche das Softwaremodul 12 mittels Systemaufrufen 25 mit dem Betriebssystem 11 interagiert, um auf zumindest eine Systemressource 26, beispielsweise einen RAM (Random Access Memory) und/oder eine Datei eines Dateisystems (file system) und/oder eine Netzwerkkarte (NIC) zuzugreifen.
Um insbesondere dieses Zusammenspiel oder diese Wechselwirkung mit dem Betriebssystem 11 zu überprüfen, kann daher in der Prozessorschaltung 10 das Softwaremodul 12 nicht direkt durch das Betriebssystem 11 gestartet worden sein, sondern in der Prozessorschaltung 10 ist in dem Betriebssystem 11 ein Koppelmodul 27 vorgesehen, welches zunächst gestartet oder ausgeführt worden sein kann. Das Koppelmodul 27 kann als eine Software implementiert sein. Mittels des Koppelmoduls 27 kann dann das Softwaremodul 12 beispielsweise als Kindprozess (Child Process) gestartet worden sein, sodass im Betriebssystem 11 der Prozess des Koppelmoduls 27 und der Prozess des Softwaremoduls 12 voneinander abhängige Prozesse sind (Parent Process und Child Process).
Zudem kann durch das Koppelmodul beim Betriebssystem 11 eingestellt worden sein, dass jeder oder eine Auswahl von Systemaufrufen 25 entweder direkt einen Aufruf in einer Funktion (im Binärcode) in dem Koppelmodul 27 bewirkt oder das Betriebssystem 11 den Systemaufruf 25 entgegennimmt und dessen Aufrufdaten an das Koppelmodul 27 weiterleitet. Eine Möglichkeit für eine solche Manipulation eines Systemaufrufs 25 ist beispielsweise durch den an sich für Betriebssysteme bekannten Mechanismus PTRACE bekannt. Mittels des Systemaufrufs 25 wird für das Softwaremodul 12 und damit für alle Einzelfunktionen 20 die Interaktion oder das Zusammenspiel mit dem Betriebssystem 11 gesteuert.
Alternativ dazu können das Koppelmodul und das Softwaremodul als ein einziges Programm (Binary Executable) verlinkt sein, was den Zugriff auf Systemaufrufe vereinfachen kann.
Startpunkt jeden Tests, die main-Funktion (main()) des Softwaremoduls.
Indem nun in dem Koppelmodul 27 nicht der tatsächliche Betriebssystemzustand 18 des Betriebssystems 11 für die Entscheidung oder das Beantworten oder das Erzeugen von Antwortdaten 29 zu dem Systemaufruf 25 zugrunde gelegt wird, sondern ein künstlicher oder simulierter, zu testender Betriebssystemzustand 30, kann für das Softwaremodul 12 vorgetäuscht oder simuliert werden, dass sich das Betriebssystem 11 in einem zu testenden Betriebssystemzustand 30 befindet, da das Softwaremodul 12 bevorzugt keine andere Interaktion oder keinen anderen Datenaustausch mit dem Betriebssystem 11 durchführt. Der zu testende Betriebssystemzustand 30 kann beispielsweise auf der Grundlage der Protokolldaten des Fehlerprotokolls 16 eingestellt oder zugrundegelegt werden. Dem Softwaremodul 12 kann somit durch das Koppelmodul 27 ein simuliertes Betriebssystem OS' im Betriebssystemzustand 30 präsentiert werden, den ein Fachmann durch Festlegen eines entsprechenden Konfigurationsdatensatzes 31 als den zu testenden Betriebssystemzustand 30 derart einstellen kann, wie er als Fehlerursache vermutet wird, um den Laufzeitfehler 15 zu erklären oder auszulösen.
Auch die zumindest eine Geräteressource 23 und/oder das zumindest eine andere Softwaremodul 40 können in dem Betriebssystem 11 durch Software-Dummies 32 nachgebildet werden, um auch die Interaktion mit Geräteressourcen 23 und/oder anderen Softwaremodulen 40 nachzubilden. Insgesamt ergibt sich ein Laufzeitszenario. Das Softwaremodul 12 wird damit in derselben Weise betrieben, wie in dem Steuergerät 14 und dessen Betriebssystem 17. Durch Verändern oder Einstellen oder Variieren des zu testenden Betriebssystemzustands 30 kann somit überprüft werden, ob das Softwaremodul 12 auf einem bestimmten Betriebssystemzustand 30 mit dem Laufzeitfehler 15 reagiert hat.
Es können zum Beispiel auch in einer Ablaufschleife 34 mehrere unterschiedliche Konfigurationsdatensätze 31 geprüft werden. Der Konfigurationsdatensatz 31 kann beispielsweise auch Zeitsignale vorgeben, um einen zeitlichen Verlauf eines Betriebs des Softwaremoduls 12 nachzustellen oder zu prüfen. Zudem kann für das Softwaremodul 12 in dem Koppelmodul 27 auch eine Systemuhr oder Systemzeit 35 künstlich eingestellt werden, die sich von einer Systemzeit 36 des Betriebssystems 11 unterscheidet. Somit kann beispielsweise die Systemzeit 35 für das Softwaremodul 12 angehalten werden, während eine Analyse eines Zustands des Softwaremoduls 12, beispielsweise das Abfragen eines Speicherabbilds 37 (z.B. Variablenwert) oder eines Funktionsstacks 38 des Softwaremoduls 12 (z.B. als Stack-Trace) ausgeführt wird. In einem Betrieb des Steuergeräts 14 wäre dies nicht möglich, da hier Echtzeitbedingungen gelten würden, also Signale verlorengehen oder nicht verarbeitet würden durch das Softwaremodul 12, während ein Speicherabbild 37 gezogen wird oder ausgelesen wird.
In einem Labor könnte eine Einzelfunktion 20 isoliert auf Grundlage von deren Quellcode-Datei 21 in einem sogenannten Unit-Test analysiert werden. Ein solcher Unittest ist aber nicht in der Lage, ganze Einzelfunktionen 20 im Verbund oder Zusammenspiel als Softwaremodul 12 zu betreiben und zu analysieren.
Um alle Einzelfunktionen 20 im Zusammenspiel als das Softwaremodul 12 zu analysieren, wäre stattdessen der Betrieb des Steuergeräts 14 im Labor notwendig, wobei hierzu die elektrischen Anschlüsse des Steuergeräts 14 mit künstlichen Signalen beaufschlagt werden könnten. Dies kann aber das innerhalb des Steuergeräts 14 vorhandene Betriebssystem 17 nicht analysieren, also das Zusammenspiel zwischen dem Softwaremodul 12 und dem ausführenden Betriebssystem über die Systemaufrufe 25. Erst durch den Betrieb über das Koppelmodul 27 im Betriebssystem 11 der Prozessorschaltung 10 ist es möglich, auch eine Rückwirkung oder Auswirkung eines zu testenden Betriebssystemzustands 30 auf das Softwaremodul 12 daraufhin zu überprüfen und/oder gezielt einzustellen, ob sich der Laufzeitfehler 15 ergibt. Um hierbei systematisch vorgehen zu können, kann der zu testende Betriebssystemzustand 30 auf der Grundlage der Protokolldaten des Fehlerprotokolls 16 eingestellt werden. Es kann aber beispielsweise auch auf „Verdacht“ von einem Entwickler ein zu testender Betriebssystemzustand 30 eingestellt werden.
Wird ein solcher Betriebssystemzustand 30 detektiert, der zu dem Laufzeitfehler 15 geführt hat, so kann der entsprechende Konfigurationsdatensatz in eine Testumgebung 40 übernommen werden, die eine Sammlung 41 von Konfigurationsdatensätzen 31 aufweist, die bei einem neu integrierten Softwaremodul 42 zu überprüfen sind, bevor das Softwaremodul 42 in einem Kraftfahrzeug 13 in dessen Steuergerät 14 installiert wird. Somit ist sichergestellt, dass nur ein solches Softwaremodul 42 in einem Kraftfahrzeug 13 in dessen Steuergerät 14 installiert wird, das alle bekannten oder bekannte Betriebssystemzustände 30 ohne Laufzeitfehler 15 übersteht, wo zuvor Softwaremodule 12 einen Laufzeitfehler verursacht haben.
Somit kann in einem Steuergerät 14 zum bekannten Laufzeitfehler 15 eine systematische Überprüfung neuer Softwaremodule 42 vor deren Freischalten oder Übermitteln in ein Steuergerät 14 (beispielsweise bei OTA-Update - Over the Air-Update) vorgenommen werden. Der Test eines neuen Softwaremoduls 42 vor dem Aussenden oder Übermitteln in ein Kraftfahrzeug 13 kann auch automatisiert beispielsweise in einem Backend 44 des Kraftfahrzeugs 13, also einem stationären Server, erfolgen, der mit dem Steuergerät 14 beispielsweise über eine Internetverbindung und/oder Funkverbindung gekoppelt sein kann, wie dies an sich bekannt ist.
Das Implementierungsbeispiel zeigt, dass das hier beschriebene Verfahren (der Scenario-Based-Unit-Testing-Ansatz) zusätzlich zur Fehlerbehebung und/oder Nachstellung, auch bei neuen Anforderungen genutzt werden kann, indem zuerst ein oder mehrere Konfigurationsdatensätze erstellt werden, die mit der momentanen Implementierung des Softwaremoduls fehlschlagen. Nach Implementierung einer neuen Anforderung / eines neuen Softwaremoduls sollte die neuen Konfigurationsdatensätze erfolgreich und ohne Fehler durchlaufen.
Insgesamt zeigen die Beispiele, wie szenariobasierte Softwaremodul-Tests bereitgestellt werden können, indem main() (d.h. die Hauptfunktion oder Einsprungfunktion) mit jedem Testfall gestartet wird, um Betriebsszenarien auszuführen/zu überprüfen, anstatt künstliche Einheitstestfälle zu testen.
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 20200125472 A1 [0005]
US 20050283664 A1 [0006]
US 20200278922 A1 [0007]

Claims

Verfahren zum Rekonstruieren eines Laufzeitfehlers (15) eines Softwaremoduls (12, 42), der in einem Steuergerät (14) eines Kraftfahrzeugs (13) stattfand und der durch ein Fehlerprotokoll beschrieben ist, wobei das Softwaremodul (12, 42) mehrere beim Ausführen miteinander wechselwirkende Einzelfunktionen umfasst und zumindest eine der Einzelfunktionen zumindest einen Systemaufruf (25) zum Interagieren mit einem das Softwaremodul (12, 42) ausführenden Betriebssystem (11, 17) des Steuergeräts (14) umfasst, dadurch gekennzeichnet, dass in einer Prozessorschaltung (10) • ein Konfigurationsdatensatz (31), der ein Laufzeitszenario mit einem zu testenden Betriebssystemzustand (18, 30) definiert, gespeichert gehalten wird und • das Softwaremodul (12, 42) in dem Betriebssystem (11, 17) durch ein Koppelmodul ausgeführt wird, welches den jeweiligen Systemaufruf (25) aus dem Softwaremodul (12, 42) entgegen nimmt oder welchem der jeweilige Systemaufruf (25) durch das Betriebssystem (11, 17) zugeführt wird, und • das zu dem jeweiligen Systemaufruf (25) Antwortdaten (29) generiert, die gemäß dem durch den Konfigurationsdatensatz (31) definierten, zu testenden Betriebssystemzustand (18, 30) erzeugt werden, und die Antwortdaten (29) an das Softwaremodul (12, 42) als Antwort auf den Systemaufruf (25) übergeben werden, und • ein Speicherabbild des ausgeführten Softwaremoduls (12, 42) und/oder ein Laufzeitprotokoll des Softwaremoduls (12, 42) für einen Vergleich mit dem Fehlerprotokoll bereitgestellt wird.
Verfahren nach Anspruch 1, wobei der zumindest eine Systemaufruf (25) eine Speicherreservierung und/oder eine Speicherfreigabe umfasst und der zu testende Betriebssystemzustand (18, 30) ein vorbestimmter Belegungszustand eines Speichers ist, durch welchen die Speicherreservierung und/oder Speicherfreigabe zu einem Fehler als Antwortdaten (29) und/oder zu verzögerten Antwortdaten (29) führt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der zumindest eine Systemaufruf (25) ein Auslesen von Daten aus einem Empfangspuffer eines Netzwerkanschlusses eines Datennetzwerks anfordert und der zu testende Betriebssystemzustand (18, 30) ein vorbestimmter Belegungszustand des Datennetzwerks und/oder des Netzwerkanschlusses ist, durch welchen das Übergeben der Antwortdaten (29) um einen durch den Konfigurationsdatensatz (31) vorgegebenen Zeitdauerwert verzögert wird und/oder die Daten für den Systemaufruf (25) unzugänglich sind.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der zumindest eine Systemaufruf (25) eine Timer-Operation eines Betriebssystem (11, 17)-Timers umfasst und der zu testenden Betriebssystemzustand (18, 30) ein vorbestimmtes Timerverhalten vorgibt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei mehrere Konfigurationsdatensätze (31) vorgesehen sind, die mehrere zu testende Betriebssystemzustände (18, 30) beschreiben, von jeder als ein Auslöser des Laufzeitfehlers (15) geprüft werden soll, wobei jeder der Konfigurationsdatensätze (31) einen anderen der zu testenden Betriebssystemzustände (18, 30) beschreibt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei für den Fall, dass durch die Prozessorschaltung (10) der Laufzeitfehler (15) detektiert wird, der Konfigurationsdatensatz (31) einer Sammlung (41) von Konfigurationsdatensätzen (31) einer Testumgebung (40) für neue Softwaremodule (12, 42) hinzugefügt wird und zumindest eine Weiterentwicklung des Softwaremoduls (12, 42) in dem Steuergerät (14) des Kraftfahrzeugs (13) implementiert und betrieben wird, nur falls das neue Softwaremodul (12, 42) zuvor durch die Testumgebung (40) für alle Konfigurationsdatensätze (31) ohne Laufzeitfehler (15) betrieben wurde.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Softwaremodul (12, 42) eine ausführbare Binärdatei ist und durch das Koppelmodul als Kindprozess gestartet wird, und/oder wobei zum Starten des Softwaremoduls (12, 42) eine Hauptfunktion des Softwaremoduls (12, 42) in der Weise aufgerufen wird, wie es in dem Steuergerät (14) durch dessen Betriebssystem (11, 17) erfolgt ist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei in der Prozessorschaltung (10) dem Softwaremodul (12, 42) eine eigene Systemzeit (35) mittels einer simulierten Systemuhr und/oder eines dem Softwaremodul (12, 42) bereitgestellten Zählerregisters vorgegeben wird, wobei die Systemzeit (35) nur dann inkrementiert wird, während die Prozessorschaltung (10) vorbestimmte Verfahrensschritte durchführt, und andernfalls anhalten ist, und/oder die Systemzeit (35) zum Überbrücken einer Wartephase vorgestellt wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die zumindest eine Einzelfunktion einen Signalaustausch über zumindest eine API (20) mit zumindest einem anderen Softwaremodul (12, 42) und/oder über eine Hardwareschnittstelle (22) mit zumindest einer Geräteressource (23) umfasst und der jeweilige Konfigurationsdatensatz (31) jeweiliges über die API (20) und/oder die Hardwareschnittstelle (22) auf das Softwaremodul (12, 42) einwirkendes Eingangssignal vorgibt, welches ein Verhalten des zumindest einen anderen Softwaremoduls (12, 42) und/oder der zumindest einen Geräteressource (23) simuliert, und sich durch eine zeitliche Abfolge des zumindest einen Eingangssignals ein Betriebsszenario nachgebildet wird.
Computerlesbares Speichermedium aufweisend Programminstruktionen, die bei Ausführen durch eine Prozessorschaltung (10) diese dazu veranlassen, ein Verfahren nach einem der vorhergehenden Ansprüche durchzuführen.
Prozessorschaltung (10) mit einem Speichermedium nach Anspruch 10.