-
Stand der Technik
-
Die
Erfindung betrifft ein Verfahren zur Verbesserung der Analysierbarkeit
von Softwarefehlern in einem Mikrocontroller, bei dem ein dem Mikrocontroller
zugeordnetes Überwachungsmodul
mindestens eine Funktion des Mikrocontrollers überprüft und ein Signal erzeugt,
falls eine Fehlfunktion des Mikrocontrollers erkannt wird, wobei
das Signal zumindest mittelbar einen Neustart des Mikrocontrollers
bewirkt und wobei bei dem Neustart mindestens ein während des
Betriebs des Mikrocontrollers ablaufendes Softwareelement neu gestartet
wird.
-
Die
Erfindung betrifft ferner ein System zur Verbesserung der Analysierbarkeit
von Softwarefehlern in einem Überwachungsmodul,
wobei dem Mikrocontroller ein Überwachungsmodul
zur Überprüfung mindestens
einer Funktion des Mikrocontrollers zugeordnet ist. Falls eine Fehlfunktion
des Mikrocontrollers erkannt wird, ist mittels des Überwachungsmoduls
ein Signal erzeugbar, wobei das Signal zumindest mittelbar einen
Neustart des Mikrocontrollers bewirkt und wobei bei dem Neustart
mindestens ein während
des Betriebs des Mikrocontrollers ablaufendes Softwareelement neu
gestartet wird.
-
Mikrocontroller
umfassen neben dem auch als CPU bezeichneten Prozessor häufig Peripheriefunktionen,
die auf einem einzelnen Chip zusammen angeordnet sind. Mikrocontroller
werden beispielsweise in so genannten eingebetteten Systemen eingesetzt.
Ein eingebettetes System bezeichnet einen elektronischen Rechner,
der in einem technischen Kontext eingebunden ist. Eingebettete Systeme
werden beispielsweise eingesetzt, um ein technisches System zu steuern,
zu regeln und/oder zu überwachen.
-
Ein
auch als Reset bezeichneter Neustart eines eingebetteten Systems
und insbesondere eines Mikrocontrollers kann häufig sowohl durch Hardware als
auch durch Software veranlasst werden. Ein durch Hardware veranlasster
Neustart erfolgt regelmäßig bei
Einschalten der Stromversorgung (power-up-reset). Weitere Hardware-Neustarts
können in
Abhängigkeit
von einem aktuellen Einsatz des eingebetteten Systems beziehungsweise
Mikrocontrollers vorgesehen sein.
-
Um
eine Fehlfunktion eines Mikrocontrollers erkennen und möglichst
zuverlässig
einen definierten Zustand wieder herstellen zu können, ist es insbesondere bei
sicherheitskritischen Anwendungen bekannt, ein Überwachungsmodul vorzusehen.
Das Überwachungsmodul
wird beispielsweise als Watchdog bezeichnet und ermöglicht eine
Kommunikation mit dem Mikrocontroller. Entspricht die Kommunikation
nicht einem erwarteten Verhalten, so wird von einer Fehlfunktion
des Mikrocontrollers ausgegangen. Das Überwachungsmodul kann in solchen
Fällen
beispielsweise einen Hardware-Neustart des Mikrocontrollers veranlassen.
-
Bei
einem Hardware-Neustart wird der Mikrocontroller in einen definierten
Anfangszustand versetzt. Dabei werden Speicherbereiche des Mikrocontrollers,
insbesondere Registerinhalte, überschrieben.
Hierbei werden insbesondere der so genannte Befehlszähler (program
counter), die Adresse des so genannten Programmstacks oder kurz
Stacks und eine möglicherweise
in einem Register abgelegte Rücksprungadresse
neu initialisiert beziehungsweise gelöscht. Üblicherweise bleibt bei einem
während
des Betriebs initiierten Neustart der Inhalt eines dem Mikrocontroller
zugeordneten Arbeitsspeichers, der häufig als RAM bezeichnet wird,
erhalten.
-
Infolge
eines eingeleiteten Hardware-Neustarts beginnt der Mikrocontroller
mit der Ausführung einer
so genannten Boot-Sequenz. Hierbei wird ein Softwareelement ausgeführt, das
den Mikrocontroller in einen definierten, beispielsweise den für das eingebettete
System vorgesehenen Ausgangszustand versetzt. Hierzu kann der Arbeitsspeicher
in geeigneter Weise mit definierten Werten initialisiert werden und
es kann möglicherweise
weitere Software in den Arbeitsspeicher geladen werden.
-
Moderne
Mikrocontroller bieten die Möglichkeit
zu unterscheiden, ob ein Hardware-Neustart durch das Einschalten
der Stromversorgung oder durch ein anders Ereignis veranlasst worden
ist. Beispielsweise kann ein Mikrocontroller so feststellen, ob
ein Neustart durch das Überwachungsmodul
veranlasst worden ist.
-
Bei
einem Neustart, der durch eine Software ausgelöst wird, wird während des
Betriebs des Mikrocontrollers in die Boot-Sequenz gesprungen, so
dass diese ausgeführt
wird. Hierbei wird der Mikrocontroller folglich nicht hardwareseitig
in den Ausgangszustand versetzt, sondern es werden lediglich die
Initialisierungen vorgenommen, die in der Boot-Sequenz durch Programmierung
vorgesehen sind. Allerdings kann auch durch eine Software ein Hardware-Neustart
veranlasst werden. Dies kann dadurch geschehen, dass der Mikrocontroller
den Sprung auf die Adresse der Boot-Sequenz erkennt und automatisch hardwareseitige
Initialisierungen vornimmt. Außerdem
kann eine Software den Mikrocontroller zur Ausführung eines Hardware-Neustarts
auffordern. Hierzu kann beispielsweise ein Signal auf einen hierfür vorgesehenen
Eingang des Mikrocontrollers gelegt werden.
-
Vom
Markt her sind Mikrocontroller mit internem Überwachungsmodul bekannt, die
es ermöglichen,
im Falle einer durch das Überwachungsmodul erkannten
Fehlfunktion des Mikrocontrollers statt eines Hardware-Neustarts
eine als Interrupt bezeichnete Unterbrechung bei dem Mikrocontroller
auszulösen.
Ein Interrupt ermöglicht
es, ein aktuell ablaufendes Programm zu unterbrechen, um eine andere, meist
kurze aber zeitkritische Verarbeitung durchzuführen. Ist das Überwachungsmodul
außerhalb
des Mikrocontrollers angeordnet, so kann vorgesehen sein, dass das Überwachungsmodul
im Falle des Erkennens einer Fehlfunktion ein Signal auf eine so
genannte Interrupt-Leitung des Mikrocontrollers legt und dadurch
den Interrupt auslöst.
Im Unterschied zu einem Hardware-Neustart führt ein durch das Überwachungsmodul
ausgelöster
Interrupt nicht dazu, dass der Mikrocontroller in den Ausgangszustand versetzt
wird und insbesondere der aktuelle Prozessorzustand bei der Abarbeitung
eines Interrupts nicht verloren geht. Dadurch ist es möglich, das
unterbrochene Programm nach Durchführung des Interrupts wieder
fortzusetzen.
-
Grundsätzlich sind
eine Vielzahl von Interrupts durch Software abschaltbar, wodurch
diese von dem Mikrocontroller nicht beachtet werden. Abschaltbare
Interrupts werden als maskierbare Interrupts bezeichnet. Arbeitet
ein Überwachungsmodul
nun derart, dass es bei Erkennen einer Fehlfunktion des Mikrocontrollers
einen Interrupt auslöst,
kann es geschehen, dass das System sich aktuell in einem Zustand
befindet, in dem durch das Überwachungsmodul
ausgelöste
Ereignisse nicht verarbeitet werden können. Dies ist beispielsweise
dann der Fall, wenn eine auf dem Mikrocontroller ablaufende Software eine
Abschaltung des Interrupts vornimmt und den Interrupt fehlerhafterweise
nicht wieder freigibt. Um ein derartiges Fehlerszenario auszuschließen, löst bei eingebetteten
Systemen, die in sicherheitskritischen Bereichen angewendet werden,
ein Überwachungsmodul-Ereignis stets einen
Hardware-Neustart – zumindest
mittelbar – aus.
-
Fehlfunktionen
eines Mikrocontrollers treten häufig
durch eine fehlerhafte Software auf, die aktuell auf dem Mikrocontroller
ausgeführt
wird. Beispielsweise kann sich eine aktuell ausgeführte Software
in einer so genannten Endlosschleife befinden. Dies führt dazu,
dass der Teil der Software, der sonst das Überwachungsmodul bedient, nicht
mehr ausgeführt werden
kann. Eine weitere Fehlfunktion kann sich ergeben, wenn die Abarbeitung
eines Teils der Software längere
Zeit in Anspruch nimmt als dies zulässig ist. Dies kann dazu führen, dass
eine Bedienung des Überwachungsmoduls
nicht mehr rechtzeitig erfolgt. Ein nochmals weiteres Beispiel für eine fehlerhafte Software
ist die bereits beschriebene Sperrung von Interrupts, die fehlerhafterweise
nicht wieder freigegeben wird, so dass eine Bearbeitung des auslösenden Ereignisses
eines Überwachungsmoduls
nicht mehr durchgeführt
werden kann, wenn dies durch einen Interrupt veranlasst werden soll.
-
Grundsätzlich werden Überwachungsmodule
zur Kompensation von Softwarefehlern eingesetzt, die beim Betrieb
des Mikrocontrollers oder des eingebetteten Systems in dem tatsächlichen
Anwendungsumfeld, also im so genannten Feld, auftreten können. Während der
Entwicklung eines Systems hingegen steht das Aufspüren und
das anschließende
Beseitigen von Softwarefehlern im Vordergrund. Zwar gibt es eine
Reihe von Methoden und Werkzeugen, die das Aufspüren von Softwarefehlern unterstützen, jedoch
ist es unmöglich,
mittels eines allgemeinen Verfahrens vorab sämtliche mögliche Softwarefehler zu entdecken.
Folglich muss damit gerechnet werden, dass stets Fehler in der Software
auftreten können.
-
Viele
Softwarefehler führen – zumindest während der
Systementwicklung – zu
Fehlfunktionen, die von dem Überwachungsmodul
erkannt werden und das Überwachungsmodul
zur Auslösung
eines Hardware-Neustarts veranlassen. Allerdings sind durch den
Hardware-Neustart die Informationen über den Systemzustand zum Zeitpunkt
des Auftretens des Hardware-Neustarts verloren gegangen, da die
Registerinhalte gelöscht
werden und weitere Speicher neu initialisiert werden. Damit ist
es meist nicht möglich,
die Ursache des Problems einzugrenzen. Häufig ist es ferner schwierig,
ein aufgetretenes Problem zu reproduzieren. Somit erweisen sich
in der Praxis gerade solche Fehler, die Ereignisse des Überwachungsmoduls
auslösen,
als besonders schwer aufspürbar.
Der Nutzen, der durch den Einsatz eines Überwachungsmoduls während des
eigentlichen Betriebs des Mikrocontrollers dadurch erreicht wird,
dass das Gesamtsystem in einem definierten Ausgangszustand durch
den Hardware-Neustart gesetzt werden kann, erweist sich also während der
Fehleranalyse als nachteilig.
-
Aufgabe
der Erfindung ist es, eine Möglichkeit
vorzuschlagen, die einerseits das Herbeiführen eines definierten Ausgangszustands
ermöglicht,
falls während
des Betriebs des Mikrocontrollers eine Fehlfunktion durch das Überwachungsmodul
erkannt wird, und andererseits die Fehleranalyse auch im Falle von
Hardware-Neustarts erleichtert.
-
Offenbarung der Erfindung
-
Die
Aufgabe wird durch ein Verfahren der eingangs genannten Art dadurch
gelöst,
dass während
des fehlerfreien Betriebs des Mikrocontrollers in dem Mikrocontroller
das Abspeichern mindestens einer Zustandsinformation in einem Speicher
veranlasst wird, wobei die Zustandsinformation mindestens den Stand
eines Befehlszählers
umfasst und wobei der Speicher bei einem Neustart nicht sofort überschrieben
oder gelöscht
wird. Während
des Neustarts oder nach erfolgtem Neustart erfolgt dann ein Zugriff
auf die in dem Speicher abgelegte Zustandsinformation, die dann
für eine
Analyse eines Softwarefehlers zur Verfügung gestellt wird.
-
Erfindungsgemäß wird folglich
während
einer fehlerfreien Ausführung
des Softwareelements oder mit Erkennen einer Fehlfunktion eine Zustandsinformation
oder mehrere Zustandsinformationen in einem Speicherbereich abgespeichert,
wobei der Speicherbereich so gestaltet ist, dass er bei einem Neustart
nicht sofort überschrieben
oder gelöscht wird.
Beispielsweise ist der Speicherbereich nicht als ein eingangs beschriebenes
Register in dem Mikrocontroller ausgebildet, falls diese bei einem
Hardware-Neustart initialisiert werden würden. Damit ist sichergestellt,
dass bei erfolgtem Neustart des Mikrocontrollers beziehungsweise
des eingebetteten Systems eine oder mehrere Zustandsinformationen
verfügbar
sind, die dann eine Analyse der Software ermöglichen, um den Fehler zu identifizieren.
-
Vorzugsweise
werden zu mehreren Zeitpunkten mindestens einen Befehlszähler umfassende
Zustandsinformationen abgespeichert. Bei der Analyse des Softwarefehlers
stehen folglich eine Mehrzahl von Zustandsinformationen zur Verfügung und
es wird jeweils der Befehlszähler
ermittelt, bei dessen Abspeichern der Stack die geringste Verschachtelungstiefe
aufwies. Damit ist es möglich
mit höherer
Genauigkeit die fehlerhafte Software zu identifizieren.
-
Ein
Abspeichern der Zustandsinformation kann gemäß einer vorteilhaften Ausführungsform durch
eine Hardwareschaltung veranlasst werden. Beispielsweise kann vorgesehen
sein, dass der Befehlszähler
und möglicherweise
weitere Zustandsinformationen kontinuierlich in einem speziellen
Register gespeichert bzw. gespiegelt wird. Dieses Register kann
dann während
des Neustarts ausgelesen und die Inhalte weiterverarbeitet werden.
Ergänzend
oder alternativ hierzu kann vorgesehen sein, dass bei dem Auftreten
eines Resets eine Zustandsinformation abgespeichert wird.
-
Gemäß einer
anderen vorteilhaften Ausführungsform
wird ein Abspeichern der Zustandsinformation durch ein Softwareelement
veranlasst. Hierzu wird vorteilhafterweise ein Interrupt in dem
Mikrocontroller ausgelöst
zu dessen Behandlung eine so genannte Interrupt-Service-Routine
(ISR) ausgeführt wird.
Die ISR veranlasst in dem Mikrocontroller nun das Abspeichern der
mindestens einen Zustandsinformation, wobei die Zustandsinformation
mindestens den Stand eines Befehlszählers vor dem Aufruf der ISR
umfasst. Es wird folglich während
des fehlerfreien Betriebs des Mikrocontrollers oder spätestens mit
Erkennen einer Fehlfunktion ein Interrupt ausgelöst. Bei der Behandlung des
Interrupts ist die ISR derart programmiert, dass eine Zustandsinformation oder
mehrere Zustandsinformationen in dem Speicherbereich abgespeichert
werden, wobei der Speicherbereich wie bereits dargestellt so gestaltet ist,
dass er bei einem Neustart nicht sofort überschrieben oder gelöscht wird.
-
Besondere
Vorteile können
sich ergeben bei einer Ausführungsform,
bei der ein Abspeichern von Zustandsinformation sowohl durch eine
Hardwareschaltung als auch durch eine Interrupt-Service-Routine
veranlasst werden kann. Damit wird eine nochmals verbesserte Fehleranalyse
ermöglicht.
-
Die
Aufgabe wird ferner durch ein System zur Verbesserung der Analysierbarkeit
der eingangs genannten Art dadurch gelöst, dass das System zur Durchführung des
erfindungsgemäßen Verfahrens hergerichtet
ist.
-
Weitere
Merkmale der Erfindung sind in den abhängigen Unteransprüchen genannt.
-
Erfindungsgemäß wird in
dem Mikrocontroller mindestens eine ausgewählte Zustandsinformation vor
oder bei Eintritt eines bestimmten Ereignisses gesichert, so dass
diese Zustandsinformation bei beziehungsweise nach einem Neustart
noch zur Verfügung
steht.
-
Gemäß einer
ersten Ausführungsform
werden die Zustandsinformationen automatisch in einem Hardware-Register
abgespeichert. Beispielsweise kann vorgesehen sein, dass während des
fehlerfreien Betriebs des Mikrocontrollers stets der aktuelle Stand
des Befehlszählers
in dem Hardware-Register abgespeichert wird. Dieser steht dann während eines Neustarts
oder nach einem Neustart für
eine Analyse zur Verfügung.
-
Gemäß einer
anderen Ausführungsform
werden die Zustandsinformationen durch den Mikrocontroller beim
Auftreten eines oder mehrerer Ereignisse veranlasst. Ein derartiges
Ereignis ist beispielsweise ein Hardware-Reset. Dies bedeutet, dass
vor dem tatsächlichen
Rücksetzen
des Mikrocontrollers zunächst
eine Abspeicherung der Zustandsinformationen durch eine auf dem
Mikrocontroller realisierte Schaltung durchgeführt wird. Eine Abspeicherung der
Zustandsinformationen kann auch dann veranlasst werden, wenn ein
Sprung in der aktuell ausgeführten
Software auf eine Adresse erfolgt, die der Boot-Sequenz zugeordnet
ist. Es wird hier folglich vor Ausführung der Boot-Sequenz zunächst die
Abspeicherung der Zustandsinformationen veranlasst. Ist in dem Mikrocontroller
ein Watchdog ausgebildet, so kann ein Watchdog-Ereignis ebenfalls
die Abspeicherung der Zustandsinformationen veranlassen. Ferner
kann eine Eingangsleitung des Mikrocontrollers speziell dafür vorgesehen
sein, ein Signal zu empfangen, das eine Abspeicherung der Zustandsinformationen
bewirkt. Es ist ferner vorstellbar, einen Mikrocontroller um einen
zusätzlichen
Eingang zu erweitern, auf dem von außerhalb die Abspeicherung der
Zustandsinformationen angefordert werden kann. Gemäß einer
anderen vorteilhaften Ausführungsform
wird auf der dedizierten Eingangsleitung ein Watchdog-Ereignis eines
externen Watchdogs angelegt, das dann ein Abspeichern der Zustandsinformationen
in dem Mikrocontroller bewirkt, sobald das Watchdog-Ereignis ausgelöst wird
und das entsprechende Signal auf der dedizierten Eingangsleitung
anliegt.
-
Wird
das Abspeichern der Zustandsinformationen durch die oben beschriebenen
hardwareseitigen Mittel realisiert, so ist es besonders vorteilhaft, wenn
die Zustandsinformationen den aktuellen Wert des auch als Befehlszähler bezeichneten
Programmzählers,
eine Rücksprungadresse,
eine Interrupt-Maske, eine Adresse des Stacks, aktuelle Interrupt-Flags
und/oder sonstige Registerinhalte umfassen.
-
Die
Sicherung der Zustandsinformationen innerhalb des Mikrocontrollers
erfolgt an Stellen, die zur Einleitung der Boot-Sequenz nicht notwendigerweise
mit anderen Werten belegt werden. Bei einem Hardware-Reset müssen beispielsweise
Programmzähler
und Interrupt-Maske
zwingend neu initialisiert werden. Diese können deshalb für die Sicherung
der Zustandsinformationen nicht genutzt werden. Vorzugsweise erfolgt
die Sicherung der Zustandsinformationen:
- – In dedizierten
Registern, die nur für
diesen Zweck vorgesehen sind,
- – in
ohnehin vorhandenen Adress- bzw. Datenregistern des Prozessor-Rechenkerns,
deren vorherige Inhalte hierdurch allerdings überschrieben werden,
- – in
einem dedizierten RAM-Bereich.
-
Ein
Abspeichern der Zustandsinformationen ist auch dann möglich, wenn
keine der oben genannten zusätzlichen
Hardwaremaßnahmen
durchgeführt werden
sollen. Bei diesen Ausführungsformen
wird durch eine Softwaremaßnahme
das Abspeichern der Zustandsinformationen veranlasst. Bei den hier
vorgeschlagenen Softwaremaßnahmen
wird die Verwendung bzw. Verwendbarkeit von Interrupts vorausgesetzt.
Die Zustandsinformationen werden hierbei innerhalb einer Interrupt-Routine
(ISR) erfasst. Die erfassten Zustandsinformationen können entweder bereits
in der Interrupt-Routine verarbeitet werden oder später nach
Auftreten eines Hardware-Resets in der Boot-Sequenz. Die Auswahl der zu speichernden Informationen über den
Systemzustand kann flexibel zum Zeitpunkt der Erstellung der Softwaremaßnahme oder
bei entsprechender Softwaregestaltung sogar während des Betriebs des Systems
gewählt
werden. Wird die Zustandsinformation innerhalb der ISR erfasst,
so muss berücksichtigt
werden, dass nicht die Zustandsinformation, also beispielsweise
der Programmzähler,
relevant ist, der aktuell innerhalb der ISR vorliegt, sondern es
sind die Zustandsinformationen, die zum Zeitpunkt der Interrupt-Auslösung vorliegen.
Eine Möglichkeit
für die
Ermittlung der tatsächlich
relevanten Zustandsinformationen auch innerhalb einer Interrupt-Routine
besteht darin, den sogenannten Stack auszuwählen, auf dem sich beispielsweise
der Programmzähler
zum Zeitpunkt der Interrupt-Auslösung
befindet. Grundsätzlich
gilt bei den vorgeschlagenen Softwaremaßnahmen, dass zusätzlich zu
den oben genannten Zustandsinformationen auch der Inhalt der Stacks
bzw. Auszüge
davon, Inhalte von Variablen und/oder Werte von Prozessoreingangssignalen
abgespeichert werden können.
-
Als
Zustandsinformationen wird vorzugsweise der Wert des Befehlszählers bzw.
Programmzählers,
eine Rücksprungadresse,
eine Interrupt-Maske, eine Adresse des Stacks und/oder eines oder
mehrere Interrupt-Flags ausgewählt.
-
Der
Befehlszähler
zeigt an, welche Instruktion von dem Mikrocontroller als nächstes abzuarbeiten
gewesen wäre
und ermöglicht
damit Rückschlüsse, welche
Instruktion aktuell abgearbeitet wird.
-
Wird
das Abspeichern der Zustandsinformationen durch einen Interrupt
veranlasst beziehungsweise durch die ISR, die zur Behandlung des
Interrupts ausgeführt
wird, ermöglicht
die Angabe der Rücksprungadresse
festzustellen, in welchem Programmteil die Abarbeitung durch den
Mikrocontroller infolge des aufgetretenen Interrupts unterbrochen worden
ist, da die Rücksprungadresse
angibt, an welcher Stelle die Abarbeitung des Programms fortgesetzt
werden soll, nachdem die Behandlung des Interrupts beendet ist.
Erfindungsgemäß kann diese Rücksprungadresse
nun abgespeichert werden, so dass diese Information auch nach Beenden
der Interrupt-Behandlung und insbesondere auch während beziehungsweise nach
einem Neustart noch zur Verfügung
steht.
-
Die
Interrupt-Maske ist ein Register, das eine aktuelle Prioritätsebene
des Prozessors und damit die Priorität des laufenden Programms in
Bezug auf die Behandlung von Programmunterbrechungen anzeigt. Unterbrechungsanforderungen
können
ein laufendes Programm nur dann unterbrechen, wenn eine der aktuellen
Unterbrechung zugeordnete Priorität eine höhere Priorität hat als
die Ebene, in der der Prozessor aktuell arbeitet. Interrupts mit
einer geringeren Priorität
können
folglich nicht abgearbeitet werden.
-
Der
Stack ist ein Bereich im Arbeitsspeicher, in dem lokale Variablen
abgelegt werden. Die Stack-Adresse ermöglicht damit unter Umständen einen
Zugriff auf lokale Variablen.
-
Interrupt-Flags
zeigen an, welche Interrupts aktuell behandelt werden sollen beziehungsweise welche
so genannten Interrupt-Requests aktuell vorliegen.
-
Vorteilhafterweise
werden weitere Registerinhalte abgespeichert, so dass möglichst
genau nachvollzogen werden kann, wie der Zustand des Systems bei
Abspeicherung der Zustandsinformationen war.
-
Erfindungsgemäß erfolgt
die Sicherung der Zustandsinformationen innerhalb des Mikrocontrollers
in Speicherbereichen, die bei der Einleitung der Boot-Sequenz nicht
mit anderen Werten belegt und damit überschrieben werden. Bei einem
Hardware-Neustart werden beispielsweise der Befehlszähler und
die Interruptmaske zwingend überschrieben.
Sollen diese während
des Neustarts aber zur Auswertung vorliegen, müssen diese Werte vorher abgespeichert
werden. Dies wird im Falle einer softwarebasierten Realisierung
des erfindungsgemäßen Verfahrens
durch die ISR, die den ausgelösten
Interrupt behandelt, veranlasst.
-
Vorzugsweise
erfolgt eine Sicherung der Zustandsinformationen in dedizierten
Registern, die für das
Abspeichern der Zustandsinformationen reserviert sind. Dies gewährleistet,
dass die Zustandsinformationen stets verfügbar sind und nicht überschrieben
werden können,
verhindert jedoch, dass diese Register für den allgemeinen Betrieb zur
Verfügung
stehen. Um stets alle Register zur Verfügung zu haben, kann deshalb
vorgesehen sein, in dem Prozessor vorhandene Adress- beziehungsweise
Datenregister für
die Sicherung der Zustandsinformationen zu verwenden. Hierbei werden
jedoch die vorherigen Inhalte in diesen Registern überschrieben.
Besonders vorteilhaft ist es auch, die Zustandsinformationen in
einem dedizierten RAM-Bereich abzuspeichern.
-
Vorzugsweise
erfolgt in der Boot-Sequenz, die dem Hardware-Neustart folgt, eine
Analyse des Grundes für
den Neustart sowie eine Analyse beziehungsweise Weiterverarbeitung
der gespeicherten Zustandsinformationen. Es kann dann vorgesehen sein,
die Zustandsinformationen persistent zu speichern, zum Beispiel
in einem hierfür
vorgesehenen Bereich eines EEPROM, oder die Zustandsinformationen
auf eine hierfür
vorgesehene Protokollleitung des Mikrocontrollers auszugeben. Ferner
kann vorgesehen sein, die in der Interrupt-Routine erfassten Zustandsinformationen
bereits teilweise oder vollständig
innerhalb der Interrupt-Routine selbst zu verarbeiten.
-
Gemäß einer
Ausführungsform
wird die zu speichernde Zustandsinformation flexibel zum Zeitpunkt
der Erstellung der Software oder bei entsprechender Softwaregestaltung
während
des Betriebs des Systems gewählt.
Für die
Analyse des Softwarefehlers sind jedoch nicht die Informationen
des Zustandes des Mikrocontrollers während der Ausführung der
Interrupt-Service-Routine relevant, sondern es sind die Informationen
des Zustandes zum Zeitpunkt der Interruptauslösung. Diese Information kann während der
Ausführung
des ISR ermittelt werden. Beispielsweise befindet sich der Stand
des Befehlszählers
zum Zeitpunkt der Interruptauslösung
bei vielen Prozessoren als Returnadresse auf dem Stack oder in einem
dem System bekannten Register. Die Analyse des Softwarefehlers wird
ferner erleichtert, wenn der Inhalt beziehungsweise Auszüge des Stacks,
Inhalte von Variablen und/oder Werte von Eingangssignalen zu dem
Prozessor beziehungsweise Mikrocontroller, die Interruptmaske, eine
Adresse eines Stacks, mindestens ein in einem Stack abgespeicherter
Wert, der Inhalt mindestens einer Variablen, der Wert mindestens
eines Interruptflags, der Inhalt mindestens eines weiteren Registers,
eine Unwinding-Information und/oder der Wert mindestens eines Eingangssignals
des Mikrocontrollers abgespeichert werden.
-
Grundsätzlich ist
es vorstellbar, dass der Interrupt durch das Überwachungsmodul ausgelöst wird
und dann durch die ISR die Speicherung der Zustandsinformationen
veranlasst wird. Dies hat jedoch den Nachteil, dass im Falle fehlerhaft
abgeschalteter Interrupts das Überwachungsmodul
unwirksam werden würde.
In besonders sicherheitskritischen Anwendungen wird deshalb von
dem Überwachungsmodul
die Auslösung
eines Hardware-Neustarts veranlasst.
-
In
einer anderen Ausführungsform
erfolgt die Auslösung
des Interrupts durch einen hierfür
vorgesehenen, programmierbaren Timer, wobei ein Ablaufen des Timers
den Interrupt auslöst.
Der Timer kann hierbei so programmiert werden, dass er möglichst kurz
vor dem Überwachungsmodul-Ereignis
abläuft. Im
Fall des Auftretens des durch den Timer ausgelösten Interrupts wird dann durch
die ISR der Systemzustand zumindest temporär gesichert. Folgt danach ein
Ereignis, das einen Hardware-Neustart auslöst, so können die gesicherten Zustandsinformationen
in der Boot-Sequenz verwendet und dort endgültig und dauerhaft gesichert
werden. Die Bedienung des Überwachungsmoduls,
das Rücksetzen
des Timers und das Löschen
beziehungsweise Wiederzurverfügungstellen
temporärer
Daten erfolgt dann innerhalb desselben Softwareelements.
-
Der
Ablauf des Timers kann sich jedoch auch an anderen Systemereignissen
orientieren. Beispielsweise wird der Timer so programmiert, dass
er periodisch abläuft
und hierbei jedes Mal den Systemzustand speichert. Erfolgt dann
ein Hardware-Neustart, steht in der Boot-Sequenz jeweils die Zustandsinformation
zum Zeitpunkt des letzen Timer-Interrupts zur Verfügung.
-
Vorteilhafterweise
wird die Ablaufdauer des Timers dynamisch variiert. Beispielsweise
ist das Überwachungsmodul
derart ausgestaltet, dass dieses nach einer vorgegebenen Zeitspanne,
zum Beispiel 500 ms, einen Hardware-Neustart auslöst, falls das Überwachungsmodul
nicht innerhalb dieser Zeitspanne ein Signal von dem Mikrocontroller
erhält. Hierbei
kann vorgesehen sein, dass das Signal beispielsweise alle 200 ms
erwartet wird. In diesem Beispiel könnte der Timer derart eingestellt
sein, dass er alle 400 ms einen Interrupt auslöst, wobei der Timer immer dann
rückgesetzt
wird, wenn von dem Mikrocontroller das Bedienungssignal (in einem
Abstand von jeweils 200 ms) an das Überwachungsmodul übermittelt
wird. Löst
der Timer nun tatsächlich
einen Interrupt aus (nach 400 ms), so erfolgt dies, weil der Timer
nicht zu den Zeitpunkten 200 ms und 400 ms rückgesetzt worden ist. Zu dem
Zeitpunkt 400 ms ist folglich bereits bekannt, dass ein Fehler im
Zeitablauf vorliegt. Bei dieser vorteilhaften Ausführungsform könnte deshalb
vorgesehen sein, dass der Interrupt eine Umprogrammierung des Timers
derart veranlasst, dass dieser nun beispielsweise in 10 ms Abständen einen
Interrupt auslöst,
so dass in Zeitabständen
von 10 ms die Zustandsinformationen gespeichert werden. Wird nun
beispielsweise nach 500 ms tatsächlich
ein Hardware-Neustart durchgeführt, so
stehen Zustandsinformationen zur Verfügung, die maximal 10 ms vor
der Auslösung
des Hardware-Neustarts abgespeichert worden sind. Selbstverständlich sind
die oben genannten Zeitangaben lediglich beispielhaft zu verstehen.
-
Die
Verwendung eines dynamisch programmierbaren Timers hat damit den
Vorteil, dass der Timer so eingestellt werden kann, dass möglichst
unmittelbar vor Ausführung
eines Hardware-Neustarts die Zustandsinformationen abgespeichert
werden und somit für
die Auswertung des Softwarefehlers möglichst aktuelle Informationen
zur Verfügung
stehen. Besonders vorteilhaft ist es, wenn für die Analyse der Softwarefehler
nicht nur die aktuellsten Zustandsinformationen, sondern auch Zustandsinformationen,
die zu früheren
Zeitpunkten abgespeichert worden sind, zur Verfügung stehen. Beispielsweise kann
vorgesehen sein, dass jeweils die drei aktuellsten Zustandsinformationen
temporär
abgespeichert bleiben, so dass diese nach beziehungsweise während der
Durchführung
des Hardware-Neustarts für eine
Analyse des Softwarefehlers zur Verfügung stehen.
-
Gemäß einer
weiteren bevorzugten Ausführungsform
kann anstelle oder in Ergänzung
zu dem Timer-Interrupt ein bereits vorhandener Interrupt verwendet
werden, der durch ein Systemereignis ausgelöst wird. Bei diesem Interrupt
wird dann die ISR dahingehend verändert, dass diese ein Abspeichern der
Zustandsinformationen veranlasst. Dies hat die Vorteile, dass – sofern
kein Timer-Interrupt verwendet wird – kein spezieller Timer vorgesehen
werden muss und dieser auch nicht programmiert werden muss. Es kann
folglich mit nur geringem Aufwand auch in bestehenden Systemen eine
Speicherung der Zustandsinformationen dadurch erreicht werden, dass
eine oder mehrere Interrupt-Service-Routinen durch geeignete Programmierung
zur Abspeicherung der Zustandsinformationen befähigt werden. Vorzugsweise werden
hierzu möglichst
hochfrequent aufgerufene Interrupts verwendet, um im Falle eines Hardware-Neustarts
möglichst
aktuelle Zustandsinformationen vorhalten zu können.
-
Um
eine persistente Speicherung der Zustandsinformationen zu erreichen,
können
unterschiedliche Speicherbereiche vorgesehen werden, die jeweils
einer Ereignisquelle oder mehreren Ereignisquellen zugeordnet sind.
In einem System, in dem verschiedene Interrupts beziehungsweise
verschiedene ISRs eine Zustandssicherung vornehmen, kann vorgesehen
sein, dass jede verwendete ISR die von dieser abgespeicherten Zustandsinformationen
in einem dieser ISR zugeordneten Speicherbereich ablegt. Damit kann
besonders einfach bei der Analyse des Softwarefehlers festgestellt
werden, durch welche ISR die jeweilig Zustandsinformation abgespeichert
worden ist. Es kann jedoch auch vorgesehen sein, dass mehrere ISRs
die Zustandsinformationen in einem gemeinsamen Speicherbereich abspeichern.
Hierbei kann dann sehr einfach die aktuellste Zustandsinformation
bei der Analyse des Softwarefehlers festgestellt werden, da dies
beispielsweise auch die zuletzt abgespeicherte Zustandsinformation ist,
unabhängig
davon, von welcher ISR die Abspeicherung dieser Zustandsinformation
veranlasst worden ist.
-
Ferner
kann vorgesehen sein, für
eine bestimmte Ereignisquelle, also beispielsweise für durch das Überwachungsmodul
ausgelöste
Ereignisse, die Zustandsinformationen von nur einem einzigen Ereignis
abzuspeichern. Dies könnte
das jeweils erste Ereignis oder aber auch das jeweils letzte Ereignis sein.
Besonders bevorzugt ist es hierbei, Zustandsinformationen zu jeweils
mehreren Ereignissen abzuspeichern. Beispielsweise kann vorgesehen
sein, die ersten fünf
Zustandsinformationen abzuspeichern. Ebenso kann vorgesehen sein,
jeweils die letzten drei Zustandsinformationen abzuspeichern. Eine Auswahl
der Anzahl der Ereignisse kann insbesondere auch von der durchzuführenden
Analyse beziehungsweise der zu analysierenden Software abhängig sein.
-
Ein
typischer Softwarefehler liegt beispielsweise dann vor, wenn die
Software unbeabsichtigt in eine Endlosschleife läuft. Dies führt in vielen Fällen dazu,
dass der Teil der Software, der das Überwachungsmodul bedient, indem
es Signale an das Überwachungsmodul übersendet,
nicht mehr ausgeführt
werden kann. Ist das Überwachungsmodul
ein so genanntes Timeout-Überwachungsmodul,
so löst das Überwachungsmodul
nach Ablauf einer vorgegebenen Zeit, innerhalb der kein Signal von
dem Mikrocontroller an das Überwachungsmodul übermittelt wird,
ein Überwachungsmodul-Ereignis aus, das
einen Hardware-Neustart oder die Auslösung eines Interrupt bei dem
Mikrocontroller veranlasst.
-
Mittels
des erfindungsgemäßen Verfahrens beziehungsweise
des erfindungsgemäßen Systems ist
die Speicherung des Befehlszählers
entweder zum Zeitpunkt des Überwachungsmodul-Ereignisses beziehungsweise
des Hardware-Neustarts oder zumindest in zeitlicher Nähe zu diesem
möglich.
Meist wird dann der abgespeicherte Befehlszähler auf eine Stelle innerhalb
des Programmcodes zeigen, die sich innerhalb der Endlosschleife
befindet oder der gespeicherte Befehlszähler verweist auf eine Stelle
innerhalb einer Unterroutine, die aus der Endlosschleife heraus
aufgerufen wird. Es ist jedoch vorstellbar, dass in dem Moment,
da der Hardware-Neustart ausgelöst
wird, das Überwachungsmodul-Ereignis
auftritt oder der Ausführung
der ISR gerade eine andere Interrupt-Routine die Endlosschleife
unterbrochen hat und deshalb diese andere Interrupt-Routine ausgeführt wird.
Um auch in diesen Fällen
eine Analyse des Software-Fehlers zu ermöglichen, wird vorzugsweise
für jeden
möglichen
Interrupt von der zugehörigen
ISR eine Rücksprungadresse
abgespeichert, die dann bei einem darauf folgenden Hardware-Neustart zumindest
während
der Durchführung
der Boot-Sequenz einen Zugriff auf diese abgespeicherte Rücksprungadresse
ermöglicht.
Die Rücksprungadresse
würde dann
auf den Programmcode innerhalb der Endlosschleife verweisen. Zusätzlich könnten Teile
des Stacks abgespeichert werden, so dass nochmals eine verbesserte
Analyse des Softwarefehlers ermöglicht
wird. Sind in dem Stack so genannte Unwinding-Informationen vorhanden,
so werden diese Unwinding-Informationen ebenfalls durch die ISR
abgespeichert. Unwinding-Informationen ermöglichen das Erkennen einer
Aufrufhierarchie, also welche Routinen von welchen anderen Routinen
aufgerufen worden sind. Bereits durch die ISR kann dadurch zwischen
Daten einerseits und Rücksprungadressen
andererseits auf dem Stack unterschieden werden und es kann vorgesehen
sein, dass lediglich die Unwinding-Informationen, nicht jedoch andere Daten
für eine
spätere
Analyse des Software-Fehlers abgespeichert werden. Dadurch kann
der für
das Abspeichern der Informationen benötigte Speicherplatz möglichst
gering gehalten werden.
-
Im
Falle mehrerer Hardware-Neustarts beziehungsweise bei einer dynamisch
programmierbaren Ablaufdauer eines Timers, der zu einem Interrupt führt, ist
es vorteilhaft, bei der Analyse des Softwarefehlers jeweils den
Befehlszähler
zu ermitteln, bei dessen Abspeichern der Stack die geringste Verschachtelungstiefe
aufwies. Damit ist es verbessert möglich, den Befehlszähler innerhalb
der eigentlichen Endlosschleife zu ermitteln und nicht innerhalb einer
Funktion oder Routine, die von der Endlosschleife aus aufgerufen
worden ist. Zumindest wird dadurch erreicht, dass durch den Befehlszähler die Stelle
ermittelt werden kann, die innerhalb einer Funktion ist, die – ausgehend
von der Endlosschleife – eine
möglichst
geringe Aufruftiefe aufweist. Ist beispielsweise das Überwachungsmodul
so ausgestaltet, dass es nach 500 ms ein Überwachungsmodul-Ereignis auslöst, falls
es innerhalb dieser Zeit kein Signal von dem Mikrocontroller empfangen
hat, so könnte – wie oben
bereits beschrieben – ein
Timer derart programmiert sein, dass er nach 400 ms einen Interrupt
auslöst.
Es sei ferner angenommen, dass das Überwachungsmodul im fehlerfreien
Zustand von dem Mikrocontroller bereits jeweils nach 200 ms ein
Signal erhält,
dann ist bei einem Ablauf des Timers (nach 400 ms) das Problem beziehungsweise der
Softwarefehler bereits vorher (200 ms) aufgetreten. Im Falle einer
Endlosschleife befindet sich die Software zu dem Zeitpunkt, in dem
der Timer abläuft, folglich
bereits innerhalb der Endlosschleife. Würde nun der Timer nach dem
ersten Ablauf auf ein kleineres Intervall, beispielsweise 10 ms,
programmiert werden, dann würden
vor dem Überwachungsmodul-Ereignis circa 10
Interrupts aufgerufen werden. Wird bei jedem Aufruf des Interrupts
durch die ISR eine entsprechende Information zumindest bis zu der Durchführung einer
Boot-Sequenz in
einem darauffolgenden Hardware-Neustart abgespeichert, so können diese
Zustandsinformationen dazu genutzt werden, den Programmzähler innerhalb
der Endlosschleife mit der geringsten Aufruftiefe zu ermitteln und
damit den tatsächlich
aufgetretenen Softwarefehler möglichst
genau zu identifizieren.
-
Das
erfindungsgemäße Verfahren
und das erfindungsgemäße System
haben damit den Vorteil, dass auch nach dem Auftreten eines unerwarteten Neustarts,
beispielsweise infolge eines Überwachungsmodul-Ereignisses,
Einstiegspunkte für
eine Analyse des Softwarefehlers vorliegen, so dass eine Analyse
des Softwarefehlers beziehungsweise eine Analyse der Ursachen des
Fehlers, insbesondere eine Identifizierung des fehlerhaften Programmcodes,
möglich
ist.
-
Ferner
wird erreicht, dass im Falle eines durch ein Überwachungsmodul ausgelösten Ereignisses
stets die Durchführung
eines Hardware-Neustarts möglich
ist und dennoch eine Analyse des Softwarefehlers vorteilhaft durchgeführt werden
kann, da die abgespeicherten Zustandsinformationen für die Analyse
während
beziehungsweise nach dem Hardware-Neustart zur Verfügung stehen. Dadurch, dass das
Abspeichern der Zustandsinformation durch die ISRs veranlasst wird,
kann dies bei nahezu allen bestehenden Systemen nachträglich implementiert werden.
Insbesondere können
die hierzu verwendeten Parameter, also beispielsweise die Auswahl
der abzuspeichernden Zustandsinformationen sowie die Zeitpunkte
beziehungsweise Abstände
des Abspeicherns und den oder die jeweiligen Interrupts, die ein Abspeichern
veranlassen sollen, sehr spezifisch an das zugrunde liegende System
beziehungsweise an die auszuführenden
Software angepasst werden.
-
Weitere
Merkmale und Vorteile der Erfindung sind in den Zeichnungen dargestellt.
Es zeigen:
-
1 eine
schematische Darstellung eines eingebetteten Systems, das zur Durchführung des erfindungsgemäßen Verfahrens
hergerichtet ist; und
-
2 ein
schematisiertes Ablaufdiagramm einer möglichen Ausführungsform
des erfindungsgemäßen Verfahrens.
-
In 1 ist
ein eingebettetes System 1 dargestellt, das beispielsweise
in einem Steuergerät
in einem Kraftfahrzeug eingesetzt ist. Das eingebettete System umfasst
einen Mikrocontroller 2 und ein Überwachungsmodul 3,
das mit dem Mikrocontroller 2 über eine oder mehrere Datenleitungen 15,
die beispielsweise auch als ein Bussystem ausgebildet sein können, verbunden
ist. Das Überwachungsmodul 3 kann
beispielsweise auch innerhalb des Mikrocontrollers ausgebildet sein,
wobei eine Kommunikation mit dem Überwachungsmodul 3 über ein
internes Bussystem ermöglicht
werden könnte.
-
In
dem Mikrocontroller 2 sind Register 4 ausgebildet,
die einen Befehlszähler 5 umfassen.
Der Mikrocontroller 2 umfasst ferner ein RAM (Random Access
Memory) 6. In dem RAM 6 sind als Speicher 7 und
als Stack 8 bezeichnete Speicherbereiche ausgebildet.
-
Der
Mikrocontroller 2 umfasst ferner eine Schaltungslogik 9,
mittels der ein Abspeichern von Zustandsinformationen veranlasst
werden kann. Des weiteren sind in dem Mikrocontroller 2 eine
in 1 nicht dargestellte Funktionseinheit zur Initiierung
eines Hardware-Neustarts und ein so genannter Interrupt-Handler 10,
der in Abhängigkeit
von einer vorliegenden Interrupt-Anfrage eine Interrupt-Service-Routine 11 auswählt, ausgebildet.
Liegt ein einen Interrupt auslösendes
Ereignis vor, so wird dies an den Interrupt-Handler 10 übermittelt.
Der Interrupt-Handler 10 entscheidet, ob die auch als Unterbrechungsanforderung
bezeichnete Interrupt-Anfrage aktuell bearbeitet werden soll oder
nicht. Hierzu wird beispielsweise geprüft, ob die aktuell angefragte Unterbrechung
maskiert ist. Ist dies nicht der Fall, so wird eine Interrupt-Service-Routine
(ISR) 11 aus einer Mehrzahl von ISRs 11 ausgewählt. Die
Interrupt-Service-Routine 11 umfasst hierbei Instruktionen,
die zur Behandlung des Interrupts ausgeführt werden.
-
In
dem Mikrocontroller 2 sind ferner ein erster Timer 12 und
ein zweiter Timer 13 ausgebildet. In dem Überwachungsmodul 3 ist
ein Timer 14 ausgebildet.
-
Bei
einer möglichen
Ausführungsform
des in 1 dargestellten Systems 1 veranlasst
der Timer 12, dass in regelmäßigen Abständen ein Signal über die
Datenleitung 15 von dem Mikrocontroller 2 an das Überwachungsmodul 3 übermittelt
wird. Das in dem Überwachungsmodul 3 angekommene
Signal bewirkt dann ein Rücksetzen
des Timers 14. Wird der Timer 14 nicht rückgesetzt,
so löst
dieser ein Überwachungsmodul-Ereignis
aus und es wird ein Signal von dem Überwachungsmodul 3 über die
Datenleitung 15 an den Mikrocontroller 2 übermittelt.
Dieses Signal kann dann einen Hardware-Neustart des Mikrocontrollers 2 durch
Aktivierung der Funktionseinheit zur Initiierung des Hardware-Neustarts oder die
Auslösung
eines Interrupts bewirken. Der Timer 14 ist hierbei derart
programmiert, dass dieser bei einem fehlerfreien Betrieb des Mikrocontrollers 2 stets
rechtzeitig rückgesetzt
wird, so dass kein Überwachungsmodul-Ereignis
auftritt. Beispielsweise veranlasst der Timer 12, dass
nach jeweils 200 ms ein Rücksetz-Signal
an das Überwachungsmodul 3 und
dort an den Timer 14 übermittelt
wird. Der Timer 14 ist in diesem Beispiel so programmiert,
dass dieser beispielsweise 500 ms nach einem Rücksetzen ein Überwachungsmodul-Ereignis
auslöst,
wenn der Timer 14 nicht vorher erneut rückgesetzt worden ist.
-
Das
in 1 dargestellte Ausführungsbeispiel des erfindungsgemäßen Systems 1 ermöglicht sowohl
eine softwarebasierte Realisierung als auch eine hardwarebasierte
Realisierung des erfindungsgemäßen Verfahrens,
da ein Abspeichern sowohl durch einen Interrupt als auch durch die
Schaltungslogik 9 veranlasst werden kann.
-
Eine
mögliche
Ausführungsform
des erfindungsgemäßen Verfahrens,
das beispielsweise auf dem System 1 abläuft, ist in 2 stark
schematisiert dargestellt. Hierbei ist der Betrieb des Mikrocontrollers 2 in
zwei Betriebsmodi unterteilt. In einem ersten Betriebsmodus 100 wird
ein Neustart des Mikroprozessors und dort insbesondere eine Boot-Sequenz durchgeführt. In
einem zweiten Betriebsmodus 200 ist der Mikrocontroller
initialisiert und arbeitet bestimmungsgemäß. Beispielsweise wird in dem
Betriebsmodus 200 eine Anwendungssoftware ausgeführt.
-
Zunächst wird
in einem Schritt 101 beispielsweise durch Aktivieren der
Funktionseinheit zur Initiierung des Hardware-Neustarts der Neustart
des Mikrocontrollers 2 eingeleitet. In einem Schritt 102 wird geprüft, wodurch
der aktuelle Neustart veranlasst worden ist. Ergibt die Prüfung, dass
der aktuelle Neustart durch das Überwachungsmodul 3 veranlasst worden
ist, so wird in einem Schritt 103 die mittels des erfindungsgemäßen Verfahrens
abgespeicherte Zustandsinformation beispielsweise aus dem Speicher 7 ausgelesen
und für
eine dauerhafte Speicherung in einem nicht dargestellten EEPROM,
der dem Mikrocontroller 2 zugeordnet ist, abgespeichert und/oder
es wird diese Zustandsinformation auf einer in 1 ebenfalls
nicht dargestellten Protokollleitung zur Verfügung gestellt, so dass diese
von außerhalb zur
Analyse eines möglicherweise
aufgetretenen Softwarefehlers herangezogen werden kann.
-
Wurde
der Neustart nicht durch das Überwachungsmodul 3 veranlasst,
so erfolgt – möglicherweise
nach Abarbeitung einer Vielzahl von weiteren Instruktionen und Initialisierungsschritten,
die Teil der Boot-Sequenz sind oder sich an diese anschließen – ein Übergang
in den zweiten Betriebsmodus 200, in dem der Mikrocontroller
bestimmungsgemäß betrieben
wird. In dem zweiten Betriebsmodus 200 wird nun eine Software
auf dem Mikrocontroller ausgeführt,
die zu Fehlern führen
kann. Während
der Ausführung
der Software wird – getriggert
durch eine Vielzahl möglicher
Ereignisse, beispielsweise durch einen Timerinterrupt – in einem
Schritt 201 geprüft, ob
ein vorgebbares Ereignis eingetreten ist. Das vorgebbare Ereignis
kann beispielsweise der Ablauf eines Timers sein, der das einen
ein durch das Überwachungsmodul
und insbesondere ein durch den Timer 13 veranlasster Interrupt
sein. Das Ereignis kann ferner der Aufruf eines weiteren, bereits
in dem System vorhandenen Interrupts sein, bei dem die zugeordnete
ISR erfindungsgemäß programmiert
ist. Die in dem Schritt 201 durchgeführte Prüfung kann beispielsweise derart
ausgebildet sein, dass durch den Interrupt-Handler 10 geprüft wird,
ob aktuell eine Unterbrechungsanforderung durch den Timer 13 vorliegt.
-
Wird
in dem Schritt 201 erkannt, dass das vorgebbare Ereignis
aufgetreten ist, so wird in einem Schritt 202 eine Speicherung
der Zustandsinformationen veranlasst, so dass diese Zustandsinformation bei
einem Hardware-Neustart aus dem Speicher 7 ablesbar ist.
Als abzuspeichernde Zustandsinformation wird beispielsweise der
Befehlszähler 5 aus
einem der Register 4 in einen Speicherbereich des Speichers 7 übertragen.
Ferner kann vorgesehen sein, eine oder mehrere Informationen des
Stacks 8 in den Speicher 7 zu schreiben. Die Informationen des
Stacks 8 beinhalten beispielsweise eine Rücksprungadresse
und Unwinding-Informationen.
-
Es
wird dann die bestimmungsgemäße Ausführung der
auf dem Mikrocontroller 2 ablaufenden Software fortgesetzt
und es wird wieder die Prüfung in
dem Schritt 201 durchgeführt.
-
Selbstverständlich sind
eine Vielzahl weiterer Ausführungsformen
vorstellbar. Insbesondere können
die vorstehend beschriebenen Merkmale beliebig kombiniert werden.
-
Beispielsweise
ist es vorstellbar, dass der Speicher 7 nicht in dem RAM 6,
sondern ebenfalls als eines der Register 4 ausgebildet
ist. Ferner ist es vorstellbar, dass ergänzend und/oder anstelle des
Timers 13 die Auslösung
eines in dem Mikrocontroller 2 bereits vorhandenen Interrupts
ein Abspeichern von Zustandsinformationen während des Betriebs des Mikrocontrollers
bewirkt. Insbesondere ist es vorstellbar, dass der Timer 13 als
programmierbarer Timer ausgebildet ist und dass dieser derart verändert wird,
dass zunächst
in größeren Zeitabständen ein Abspeichern
der Zustandsinformation erfolgt und nach einem bestimmten Intervall
ein Abspeichern in verkürzten
Zeitabständen
möglich
ist. Ist das Überwachungsmodul 3 wie
in 1 beispielhaft beschrieben ausgebildet, so kann
vorgesehen sein, dass der Timer 13 in Zeitabständen von
200 ms ein Abspeichern der Zustandsinformationen veranlasst. Nach 400
ms wird der Timer 13 derart umprogrammiert, dass dieser
in Abständen
von 10 ms ein Abspeichern der Zustandsinformationen bewirkt. Dies
bedeutet, dass bei dem Eintritt eines Überwachungsmodul-Ereignisses,
das beispielsweise nach weiteren 100 ms durch den Timer 14 ausgelöst werden
würde, über 10 Systemzustandsinformationen
abgespeichert sein können,
falls die Anzahl der zu jedem Zeitpunkt maximal vorzuhaltenden Zustandsinformationen
nicht niedriger gewählt
ist. In Abhängigkeit
davon, welcher Art die zu analysierenden Softwarefehler sind und
in Abhängigkeit
von dem in dem eingebetteten System 1 vorhandenen Ressourcen
kann vorgesehen sein, jeweils nur die aktuellste Zustandsinformation
abzuspeichern oder es kann vorgesehen sein, mehrere Zustandsinformationen
abzuspeichern und beispielsweise vorzusehen, dass zu keinem Zeitpunkt
mehr als eine vorgebbare Anzahl, beispielsweise 5 Zustandsinformationen,
in dem Speicher 7 vorgehalten werden. Für die Speicherung jeder weiteren
erfassten und abzuspeichernden Zustandsinformation wird dann eine
bereits abgespeicherte Zustandsinformation überschrieben wird.
-
Liegen
für die
Softwareanalyse zu mehreren Zeitpunkten abgespeicherte Zustandsinformationen vor,
so kann jeweils der Befehlszähler
ermittelt werden, bei dessen Abspeichern der Stack innerhalb einer
vermuteten Endlosschleife die geringste Verschachtelungstiefe aufwies.
Damit kann erreicht werden, dass stets eine Funktion ermittelbar
ist, die ausgehend von dem fehlerhaften Softwareelement eine möglichst
geringe Aufruftiefe aufweist, so dass eine verbesserte Eingrenzung
des Fehlers ermöglicht wird.
-
Ferner
kann das System derart ausgebildet sein, dass ein Signal von dem Überwachungsmodul 3 nur
in bestimmten Zeitfenstern übermittelt
werden kann, so dass auch das Überwachungsmodul-Ereignis
nur innerhalb dieser Zeitfenster ausgelöste werden kann. Wird der Interrupt
nun durch den Timer 13 ausgelöst, so ist der Timer vorteilhafterweise
derart programmiert ist, dass der Interrupt zumindest so kurz vor
dem Zeitfenster ausgelöst
wird, dass das Abspeichern der Zustandsinformation in dem Speicher 7 durch
die Interrupt-Service-Routine 11 vor einem durch das Signal
ausgelösten
Hardware-Neustart gewährleistet
ist.