-
Die
Erfindung betrifft ein Verfahren zur Fehlerüberwachung
eines Rechnersystems mit mindestens zwei Recheneinheiten, wobei
das Rechnersystem zwischen einem ersten und einem zweiten Betriebsmodus
umgeschaltet wird und der erste Betriebsmodus einem Performanzmodus
und der zweite Betriebsmodus einem Vergleichsmodus entspricht sowie
eine Vorrichtung zur Durchführung des Verfahrens.
-
In
vielen Bereichen der Technik, wie beispielsweise in der Automobilindustrie
oder der Automatisierungstechnik gibt es eine Vielzahl von Anwendungen,
bei denen ein Fehler in der Hardware eines mit einem Mikroprozessor
betriebenen Rechnersystems sicherheitsrelevante Konsequenzen haben kann.
Um diese Konsequenzen zu vermeiden oder zumindest ihre Auswirkungen
zu verringern, werden Überwachungsmaßnahmen eingesetzt,
die auftretende Fehler detektieren sollen.
-
Aus
der
DE 10 2005
037 261 A1 sind ein Verfahren und eine Vorrichtung zur
Erzeugung eines Signals bei einem Rechnersystem mit mehreren Komponenten
bekannt, bei welchen zwischen zwei Betriebsmodi umgeschaltet wird.
Das Rechnersystem arbeitet mit zwei Recheneinheiten. Die unterschiedlichen
Betriebsmodi zielen darauf ab, dass die Prozessoreinheit mindestens
in einem so genannten Performanzmodus als auch in einem Vergleichsmodus
betrieben wird. In dem Performanzmodus führen die in dem
Rechnersystem enthaltenen Recheneinheiten unterschiedliche Programme
aus. Im Vergleichsmodus werden dagegen von beiden Recheneinheiten identische
Programme ausgeführt und das Ergebnis beider Recheneinheiten
miteinander verglichen. Bei einer Differenz der Ergebnisse wird
ein Fehlersignal ausgelöst.
-
Der
Erfindung liegt die Aufgabe zugrunde, eine Verfahren und eine Vorrichtung
anzugeben, bei welchem das Rechnersystem mit mindestens zwei Recheneinheiten,
das in unterschiedlichen Betriebsmodi arbeiten kann, regelmäßig
einen sicheren Zustand einnimmt.
-
Der
Vorteil der Erfindung besteht darin, dass sowohl der Vergleichsmodus
als auch der Performanzmodus auf Fehler überwacht wird.
Es wird überprüft, ob das Rechnersystem rechtzeitig
wieder in den Vergleichsmodus wechselt, bei welchen festgestellt
wird, ob die Recheneinheiten korrekt arbeiten. Durch die Verwendung
eines Mustererkennungsalgorithmus, der die zeitliche Abfolge der
Betriebsmodi überwacht, wird auf einen Fehler erkannt,
wenn eine zeitliche Bedingung, die vom Mustererkennungsalgorithmus überwacht
wird, in der Abfolge der Betriebsmodi nicht eingehalten wird. Da
der Mustererkennungsalgorithmus eine gleichzeitige Überwachung von
mehreren Größen, die den jeweiligen Betriebsmodus
charakterisieren, zulässt, kann auf Grund der Vielzahl
zu überwachenden Bedingungen, schon bei der Abweichung
von nur einer Bedingung rechtzeitig auf einen Fehler geschlossen
werden. Durch die Erfindung wird auch ein Fehler in dem Performanzmodus,
der ein Zurückschalten in den Vergleichsmodus verhindert,
erkannt und ein sicherer Zustand eingenommen.
-
Das
erfindungsgemäße Verfahren erlaubt möglichst
viele Programmteile im leistungsfähigen Performanzverfahren
laufen zu lassen, da dadurch eine hohe Rechenleistung erreicht wird.
Gleichzeitig werden alle Programmteile mit einer hohen Fehlererkennung überwacht,
was insbesondere für sicherheitsrelevante Anwendungen von
besonderer Bedeutung ist.
-
Eine
besonders einfache Überwachungsmöglichkeit ist
gegeben, wenn der Mustererkennungsalgorithmus das Auftreten des
Vergleichsmodus überwacht, in dem das Auftreten eines Modussignals
bewertet wird. Dieses Modussignal wird während der Arbeit
des Vergleichsmodus aktiv gesetzt und ist im Performanzmodus inaktiv.
Das Modussignal ist also immer genau dann aktiv, wenn die Daten der
beiden Recheneinheiten verglichen werden.
-
In
vielen Fällen reicht die Überwachung des Modussignals
als solches aber nicht aus, sondern das zeitliche Verhalten des
Modussignals muss ebenfalls überwacht werden. So wechselt
das Rechnersystem mehr oder weniger regelmäßig
zwischen Performanz- und Vergleichsmodus hin und her. Ein fehlerhaftes
Verhalten in der zeitlichen Abfolge des Modussignals kann durch
einen Vergleich mit vorgegebenen Referenzwerten er kannt werden.
Somit lässt sich auch einfach feststellen, ob die Umschaltung
in den Vergleichsmodus, d. h. die Aktivierung des Modussignals,
zum richtigen Zeitpunkt erfolgt ist.
-
Wird
der Vergleichsmodus in einem Rechnersystem als besonders sicherer
Modus angesehen, so können die Sicherheitsziele der vorgegebenen
Anwendung dadurch erreicht werden, dass der Vergleichsmodus immer
wieder rechtzeitig angenommen wird. Es wird die Dauer des Vergleichsmodus und/oder
des Performanzmodus überwacht. Ergibt sich ein Unterschied
zu einem vorgegebenen Referenzwert, wird auch hier auf einen Fehler
erkannt.
-
In
einer Ausgestaltung erfolgt eine Überprüfung dadurch,
dass durch den Mustererkennungsalgorithmus die maximale Dauer, in
der der Performanz- und/oder der Vergleichsmodus nicht unterbrochen
werden, überwacht wird. Vorteilhafterweise können
Unter- und Obergrenzen für diese Zeiträume angegeben
werden. Darüber hinaus ist eine Überwachung von
periodischen Folgen von wechselnden Zeiträumen möglich.
Die Zahl der Überwachungsmuster ist dabei sehr vielfältig
und kann immer konkret auf den jeweiligen Anwendungsfall abgestimmt werden.
Diese Realisierung lässt sich besonders einfach durch eine
Kombination von Hard- und Software einstellen.
-
In
einer Weiterbildung der Erfindung wird durch den Mustererkennungsalgorithmus
die Zahl der Aktivierungen des Performanz- und/oder des Vergleichsmodus überwacht.
-
Wenn
der Anwendungsbereich durch einen hohen Grad an Periodizität
gekennzeichnet ist, wie es beispielsweise in Echtzeitanwendungen
im Automobilbereich der Fall ist, ist die Fehlerüberwachung durch
den Mustererkennungsalgorithmus besonders einfach realisierbar,
indem das periodische Auftreten des Vergleichsmodus überwacht
wird. Das heißt, das Rechnersystem nimmt im fehlerfreien
Fall den Vergleichsmodus immer nach einer festen Periode an.
-
Alternativ
wird überwacht, ob der Vergleichsmodus nach dem letzten
Zeitpunkt seiner Aktivierung genau zu einem bestimmten Zeitpunkt
wieder angenommen wird.
-
In
einer besonders komfortablen Ausführung der Erfindung überwacht
der Mustererkennungsalgorithmus das Verhältnis von Vergleichsmodus
und Performanzmodus in nerhalb eines vorgegebenen Zeitraumes. Dieser
Zeitraum sollte dabei vorteilhafterweise einer Periode entsprechen.
Dabei wird zunächst ein so genanntes Budget festgelegt,
das Ober- und/oder Untergrenzen für eine Reihe von zu messenden
Größen angibt, die von dem Mustererkennungsalgorithmus überwacht
werden. Beispielsweise kann das Budget die Maximaldauer des Verbleibens
des Rechensystems im Vergleichsmodus genauso limitieren, wie die
Maximaldauer des Arbeitens des Rechnersystems im Performanzmodus. Das
gleiche gilt für eine Minimaldauer. Darüber hinaus
werden die Zahl der Moduswechsel oder die Zahl der Wechsel in eine
bestimmte Richtung limitiert. Bei dieser Konfiguration ist einmal
die Einhaltung des Zeitraumes, also die Periode, für die
ein Budget vorgegeben ist, zu überwachen. Zum anderen muss
die Einhaltung des Budgets innerhalb der Periode überwacht
werden.
-
In
einer anderen Weiterbildung der Erfindung ist eine Vorrichtung zur
Fehlerüberwachung eines Rechnersystems mit mindestens zwei
Recheneinheiten dargestellt, wobei das Rechnersystem zwischen einem
ersten und einem zweiten Betriebsmodus umschaltet und der erste
Betriebsmodus einem Performanzmodus und der zweite Betriebsmodus
einem Vergleichsmodus entspricht. Bei einem mit mindestens zwei
Recheneinheiten arbeitenden Rechnersystem, das in unterschiedlichen
Betriebsmodi arbeiten kann, ist die regelmäßig
Annahme eines sicheren Zustands gewährleistet, wenn es
eine Überwachungslogik mit einer die Betriebsmodi überwachenden Mustererkennungsalgorithmus
enthält, wobei die Überwachungslogik ein Fehlersignal
ausgibt, wenn mindestens ein Betriebsmodus von dem Mustererkennungsalgorithmus
abweicht. Durch die Abbildung des Mustererkennungsalgorithmus in
der Hardware der Überwachungslogik lässt sich
die Fehlerüberwachung einfach realisieren.
-
Durch
die Verwendung eines Zählers überwacht der Mustererkennungsalgorithmus
der Überwachungslogik den Vergleichsmodus, in dem das Auftreten
eines Modussignals gezählt wird.
-
Durch
Timer lässt sich einfach das zeitliche Verhalten von Performanz-
und/oder Vergleichsmodus durch den Mustererkennungsalgorithmus der Überwachungslogik
bewerten.
-
Darüber
hinaus weist die Überwachungslogik eine Schnittstelle auf,
an welcher die Eingangsdaten anliegen, die mit dem Mustererkennungsalgorithmus
bewertet werde.
-
Die
Erfindung lässt zahlreiche Ausführungsbeispiele
zu. Eines davon soll anhand der in der Zeichnung dargestellten Figuren
näher erläutert werden.
-
Es
zeigt:
-
1 Überwachungslogik
für ein Rechnersystem mit mindestens zwei Recheneinheiten
-
2 Überwachungsbeispiel
für die Maximaldauer des Performanzmodus
-
3 Überwachungsbeispiel
für das periodische Annehmen des Vergleichsmodus
-
4 Überwachungsmuster
für ein erstes Budget
-
5 Überwachungsmuster
für ein zweites Budget
-
6 Überwachungslogik
mit einem Software-Interface
-
Gleiche
Merkmale sind mit gleichen Bezugszeichen versehen.
-
1 zeigt
eine Überwachungslogik 100, in welcher hardwaremäßig
ein Mustererkennungsalgorithmus abgelegt ist, der die Arbeit nicht
weiter dargestellter Recheneinheiten, die einmal im Performanzmodus
und zum anderen in einem Vergleichsmodus arbeiten, überwacht.
Für die Realisierung des Mustererkennungsalgorithmus werden
ein oder mehrere Timer 101 benötigt, die mit jeder
steigenden Flanke des Systemtaktes oder einem aus dem Systemtakt abgeleiteten
Takt inkrementiert werden. Um den Wechsel eines Modussignals registrieren
zu können, ist ein Zähler 102 vorhanden.
Ein Speicher 103 registriert Referenzwerte, Konfigurationsparameter
und Timerwerte. Zum Vergleich von Ist-Werten mit Soll-Werten ist
ein Komparator 104 notwendig. Darüber hinaus ist
eine Logik 105 zur Mittelwertbildung in die Überwachungslogik 100 integriert.
Als Eingangssignale erhält die Überwachungslogik 100 den
Systemtakt 106, ein Signal 107 für den
System Reset und das Modussignal 108. Weiterhin ist eine
Anbindung 109 an den internen, nicht weiter dargestellten Systembus
vorhanden.
-
Das
Ausgangssignal der Überwachungslogik 100, welches über
die Anbindung 109 an den internen Systembus ausgegeben
wird, ist ein 1 Bit breites Fehlersignal, über das eine
Abweichung vom erwarteten zeitlichen Verhalten des Modussignals
signalisiert wird. Fehlersignal aktiv bedeutet, dass ein Fehler
in der zeitlichen Abfolge des Modussignals aufgetreten ist. Außer
einem 1 Bit breiten Signal ist auch ein Dual Rail oder eine andere
Implementierung möglich, die diese Information übermitteln
kann.
-
Bei
der Initialisierung der Überwachungslogik 100 muss
eine anwendungsspezifische Konfiguration per Software erfolgen.
Dabei wird vorteilhafterweise während der Konfiguration
das Fehlersignal aktiviert, da während der Konfiguration
keine Überwachung stattfindet. Zur Konfiguration wird ein
Konfigurationsbit gesetzt, welches einen Schutz gegen fehlerhafte
Konfigurationszugriffe darstellt. Eine Umkonfiguration der Überwachungslogik 100 während des
Betriebes ist also nicht möglich, ohne das Konfigurationsbit
zu setzen. Sollte versehentlich eine Konfiguration während
des Betriebes der Überwachungslogik 100 erfolgen,
wird in dem Moment, wo das Konfigurationsbit gesetzt wird, automatisch
das Fehlersignal der Überwachungslogik 100 aktiviert. Die Überwachungslogik 100 beginnt
die Überwachung des Modussignals 108, sobald das
Konfigurationsbit gelöscht ist.
-
Liegt
ein Resetsignal 107 an, startet die Überwachungslogik
mit einem nicht gesetzten Konfigurationsbit und somit aktivem Fehlersignal.
Ein einmal gesetztes Fehlersignal kann erst nach einer Neukonfiguration,
d. h. nach Setzen und anschließendem Löschen des
Konfigurationsbits, wieder zurückgesetzt werden.
-
Um
einen flexibleren Einsatz bei der Initialisierung zu ermöglichen,
wird zwischen dem Abschluss der Konfiguration der Überwachungslogik 100 und
dem Start der Überwachung durch die Überwachungslogik 100 eine
Pufferzeit vorgehalten.
-
Die Überwachungslogik 100 soll
durch Überwachung des zeitlichen Verhaltens des Modussignals überprüfen,
ob das Rechnersystem in der gewünschten Art und Weise arbeitet.
Dabei sind prinzipiell drei Arbeitsmodi zu unterscheiden, für
die die Überwachung des Modussignals unterschiedlich durchzuführen
ist.
-
Bei
einem permanenten Performanzmodus wird das Rechnersystem ausschließlich
im Performanzmodus betrieben. Eine Umschaltung in den Vergleichsmodus
findet nie statt. Das Modussignal wird daher nie aktiviert. Die
Aktivierung des Modussignals stellt somit einen Fehlerfall dar.
-
Arbeitet
das Rechnersystem in einem permanenten Vergleichsmodus, findet nie
eine Umschaltung in den Performanzmodus statt. Das Modussignal ist
daher permanent aktiviert. Ein zu erkennender Fehlerzustand ist
in diesem Fall die Deaktivierung des Modussignals.
-
In
einem dritten Fall wechselt das Rechnersystem mehr oder weniger
regelmäßig zwischen Performanz- und Vergleichsmodus
hin und her. Ein fehlerhaftes Verhalten in der zeitlichen Abfolge
des Modussignals wird durch Vergleich mit gespeicherten Referenzwerten
erkannt.
-
Die Überwachung
des Modussignals im permanenten Performanz- bzw. Vergleichsmodus
wird durch Vergleich des Modussignals mit den konstanten Werten „0” und „1” realisiert.
-
Bei
der Überwachung des Wechsels zwischen Performanz- und Vergleichsmodus
muss durch die Überwachungslogik neben der Beobachtung
des Modussignals sichergestellt werden, dass alle Wechsel zwischen
Performanz- und Vergleichsmodus zur richtigen Zeit stattfinden und
wenn möglich, dass dabei die richtigen Softwaretasks ausgeführt
werden.
-
Die Überwachungslogik 100 kann
nun verschiedene Überwachungsmuster überwachen.
Bei der Annahme, dass der Vergleichsmodus ein besonders sicherer
Modus ist, können die Sicherheitsziele der Anwendung dadurch
erreicht werden, dass sichergestellt wird, dass der Vergleichsmodus
immer wieder rechtzeitig angenommen wird. Es wird überprüft,
ob der Vergleichsmodus spätestens nach einer gewissen Dauer,
beispielsweise alle x ms angenommen wird. D. h. es erfolgt eine Überwachung
der maximalen Dauer, in der der Performanzmodus nicht unterbrochen
wird. Dies wird durch einen Timer realisiert, der periodisch inkrementiert
oder dekrementiert wird. Es wird dabei ein Timer verwendet, der
bei Erreichen eines bestimmten Wertes (z. B. 0) abläuft und
ein entsprechendes Signal ausgibt.
-
Die Überwachung
ist in 2 dargestellt. Den Ausgangspunkt im Block 200 bildet
der Performanzmodus, in welchem sich das Rechnersystem befindet.
Im Block 201 wird der Timer initialisiert und beginnt im
Block 202 zu laufen. Darauf hin wird im Block 203 abgefragt,
ob der Vergleichsmodus vor Ablauf des Timers angenommen wird, was
einfach anhand des Vorhandenseins des Modussignals festgestellt
werden kann. Ist dies nicht der Fall, gibt die Überwachungslogik 100 im
Block 204 ein Fehlersignal aus.
-
Wird
der Vergleichsmodus vor Ablauf des Timers angenommen, wird mit dem Übergang
zum Vergleichsmodus der Timer angehalten (Block 205). Das
Rechnersystem arbeitet nun im Vergleichsmodus (Block 206).
Im Block 207 springt das Rechnersystem in den Performanzmodus.
Bei diesem Zustandsübergang wird im Block 208 der
Timer neu aufgezogen. Es wird zum Block 202 zurückgekehrt,
in welchen der Timer abläuft und die Überwachung
beginnt von neuem.
-
Ein
anderes Überwachungsmuster besteht darin, das die Überwachung
darauf achtet, dass der Vergleichsmodus im fehlerfreien Fall immer
nach einer festen Periode angenommen wird. Dies ist besonders vorteilhaft,
wenn alle Tasks des Vergleichsmodus periodisch sind. Dabei wird überprüft,
ob der Vergleichsmodus nach dem letzten Zeitpunkt seiner Aktivierung
genau zu einem bestimmten Zeitpunkt wieder angenommen wird. Dieser
Zeitpunkt ist mit einem so genannten Jitter versehen, was bedeutet, dass
der bestimmte Zeitpunkt in einem vorgegebenen Zeitfenster liegen
darf.
-
Mit
Hilfe von 3 soll dieses Überwachungsmuster
erläutert werden. Auch hier befindet sich das Rechnersystem
zunächst im Performanzmodus (Block 300). Im Block 301 wird
ein Timer initialisiert, wobei der Timer im Block 302 läuft.
Im Block 303 wird abgefragt, ob der Vergleichsmodus im
richtigen Zeitfenster angenommen wurde. Ist dies nicht der Fall,
gibt die Überwachungslogik 100 im Block 304 eine
Fehlermeldung aus.
-
Wurde
der Vergleichsmodus im richtigen Zeitfenster angenommen, wird mit
dem Übergang des Rechnersystems vom Performanzmodus in
den Vergleichsmodus der Timer angehalten (Block 305). Das
Rechnersystem arbeitet im Block 306 im Vergleichsmodus.
Im Block 207 springt es wieder in den Performanzmodus,
wobei mit diesem Zustandwechsel des Rechnersystems der Timer neu
aufgezogen wird (Block 308). Der Timer beginnt im Block 302 wieder
zu laufen und die Überwachung beginnt von vorn. Der Timer überwacht
hier nicht auf eine Maximallänge sondern auf einen Zeitraum.
-
In
einer weiteren Ausgestaltung besteht die Möglichkeit, eine
Budgeteinhaltung des Verhältnisses von Vergleichsmodus
und Performanzmodus innerhalb einer Periode zu überwachen.
Dazu ist einerseits die Einhaltung einer Periode, für die
jeweils ein Budget vorgegeben wird, zum anderen die Einhaltung des
Budgets innerhalb der Periode zu überwachen. Beispielsweise
soll innerhalb einer Periode von 40 ms der Performanzmodus für
39 ms und der Vergleichsmodus für 1 ms verwendet werden.
Dabei wird als erste Überprüfung überwacht,
ob alle 40 ms ein Budgetupdate, also eine Neufestsetzung des Budget stattfindet,
wobei das Budget periodisch von der Software freigegeben wird. Die
zweite Überprüfung besteht darin, ob das Verhältnis
von Performanzmodus zu Vergleichsmodus in einem akzeptablen Rahmen, vorteilhafterweise
39:1, liegt.
-
Die
prinzipielle Form eines Budgets wird in 4 erläutert.
Das Budget 400, gibt Obergrenzen für eine Reihe
von Größen an, die von der Überwachungslogik 100 gemessen
werden. In der Budgeteinheit 401 wird die Maximaldauer,
z. B. x ms, für den Vergleichsmodus limitiert. Die Maximaldauer,
z. B y ms, für den Performanzmodus wird in der Budgeteinheit 402 limitiert.
Eine Limitierung der Zeit bis zum nächsten Budgetupdate
z. B. z ms, erfolgt in der Budgeteinheit 403. Anstelle
von ms kann die Maximaldauer auch in Taktzyklen oder einem Vielfachen
von Taktzyklen angegeben werden. Die maximale Anzahl der Moduswechsel
n wird in der Budgeteinheit 404 festgelegt, während
in der Budgeteinheit 405 die maximale Anzahl m der Wechsel
vom Vergleichsmodus in den Performanzmodus festgelegt wird.
-
Ein
Budget, bei welchem nicht nur Obergrenzen sondern auch Untergrenzen überwacht
werden, ist in 5 dargestellt. Das Budget 500 besteht
dabei aus der Budgeteinheit 501, bei welchen das Minimum
x1 und das Maximum x2 für den Verbleib des Rechnersystems
im Vergleichsmodus festgelegt wird. In der Budgeteinheit 502 sind
das Minimum y1 und das Maximum y2 für den Verbleib des
Rechnersystems im Performanzmodus beschrieben. Der Zeitraum (Minimum
z1 und Maximum z2) bis zum nächsten Budgetupdate ist in
der Budgeteinheit 503 angeführt. Auch der Wechsel
des Modussignals, welches mit der Budgeteinheit 504 überwacht
wird, beträgt eine Anzahl von Minimum n1 bis Maximum n2. Die
Anzahl der Wechsel vom Vergleichsmodus in den Performanzmodus kann
von Minimum m1 bis Maximum m2 betragen (Budgeteinheit 505).
-
Neben
den angeführten Bedingungen können je nach Anwendungsfall
noch weitere Bedingungen hinzugefügt werden.
-
Eine
Budgetüberwachung verläuft wie folgt:
Zu
jeder Budgeteinheit gibt es einen Zähler. Das Budget einer
Budgeteinheit, beispielsweise der Budgeteinheit 401, wo
die maximalen x-Werte des Aufenthaltes in einem Vergleichsmodus
limitiert sind, wird mit Hilfe dieses Zählers verwaltet.
Der Zähler, der zur Budgeteinheit 401 gehört,
wird bei jedem Systemtakt erhöht, bei dem sich das System
im Vergleichsmodus befindet. Der Zähler, der zur Budgeteinheit 402 gehört,
wird bei Systemtakten erhöht, bei denen sich das System
im Performanzmodus befindet. Der Zähler, der zur Budgeteinheit 403 gehört
wird bei jedem Systemtakt erhöht.
-
Ein
Zähler für den Moduswechsel (Budgeteinheiten 404 oder 504)
wird bei jedem Moduswechsel inkrementiert. Soll wie bei den Budgeteinheiten 405 und 505 nur
eine bestimmte Richtung des Moduswechsels gezählt werden,
wird dies entsprechend selektiert.
-
Bei
jedem update eines Zählers findet ein Vergleich des Zählwertes
mit dem in dem Speicher abgelegten Maximalwert der jeweiligen Budgeteinheit
statt. Ist der Maximalwert überschritten, gibt die Überwachungslogik 100 eine
Fehlermeldung aus.
-
Bei
dem Budgetupdate werden alle Zählerwerte aller Budgeteinheiten 401, 402, 403 mit
den abgespeicherten Minimalwerten verglichen. Ist ein Minimalwert
unterschritten, wird wieder eine Fehlermeldung ausgegeben. Tritt
kein Fehler auf, werden alle Zähler wieder initialisiert.
-
Eine
Möglichkeit das nächste Budgetupdate innerhalb
der Überwachungslogik 100 zu definieren, besteht
darin, dass eine vorgegebene Zeit definiert wird. Alternativ dazu
wird das Budget nach einer fest vorgegebenen Zahl an Wechseln des
Modus wieder aktualisiert. Eine weitere Möglichkeit besteht
darin, dass nach einer fest vorgegeben Zeit der nächste Moduswechsel
Auslöser des Budgetupdates ist.
-
Die
Zähler können natürlich auch über
Dekrementierung implementiert werden. Dann führt ein Budgetupdate
zum Setzen auf einen neuen Maximalwert. Anstatt bei jedem Systemtakt
eine De- oder Inkrementierung durchzuführen, kann auch
in einer gröberen Einheit gezählt werden, beispielsweise
alle 8 Takte.
-
Darüber
hinaus kann das Budgetupdate durch eine Software ermöglicht
werden, welche auf die Überwachungslogik 100 zugreift.
Dazu benötigt die Überwachungslogik 100 ein
Interface, welches in 6 dargestellt ist. Es besteht
aus einem Konfigurationsinterface 110 für das
Budget, in welchem alle Werte der Budgeteinheiten 401 bis 405 bzw. 501 bis 505 abgelegt
sind, und einem Bedienerinterface 111 für das
Budgetupdate. Dieses Bedienerinterface 111 wird durch die
Software angesprochen. Dabei reicht ein Bit aus, welches regelmäßig
innerhalb des Budgets gesetzt wird oder das seinen Wert ändert.
-
Das
Budgetupdate durch Software stellt eine zusätzliche Überwachungsmöglichkeit
dar, bei welcher sichergestellt ist, dass innerhalb des richtigen Zeitfensters
der Teil der Software, der für eine Bedienung des Budgetupdates
notwendig ist, auch tatsächlich abläuft.
-
Sollte
es notwendig sein, eine bestimmte Budgetinformation nicht zu überwachen,
wird der entsprechende Maximalwert des Budgetanteils auf 0 gesetzt.
-
Um
die Speicherkapazitäten so gering wie möglich
zu halten, reicht es aus, nur die x- und z-Werte zu zählen,
da der y-Wert sich aus beiden berechnen lässt.
-
Entsprechendes
gilt für die Moduswechsel. Eine weitere Optimierung besteht
darin, dass beispielsweise in der Budgeteinheit 501 nicht
x1 und x2 gespeichert werden, sondern nur x1 und die feststehende
Differenz zu x2.
-
In
einer gegebenen Implementierung mit einer dann festen Zahl von Budgeteinheiten
ist es vorzugsweise konfigurierbar, welche Größen
in einem Budget verwaltet werden und welche Bedingung eine Zählerinkrementierung/-dekrementierung
auslöst.
-
Wenn
die Bedienung des Budgetupdates über die Software erfolgt,
wird in einer erweiterten Implementierung bei der Bedienung ein
bestimmter Wert in das Bedienerinterface geschrieben. Durch Vergleich
mit vorher bekannten Werten wird überprüft, ob
im mer die richtige Form der Bedienung erfolgt ist. Erzeugt beispielsweise
eine korrekt ablaufende Software eine bestimmte Reihenfolge der
Werte, kann festgestellt werden, ob die Software auch von den richtigen
Stellen aus die Bedienung vornimmt. Somit wird eine Kontrollflussüberwachung
unterstützt.
-
Über
eine Verkopplung von aufeinander folgenden Werten, beispielsweise über
ein Multiinputshiftregister MISR wird diese Kontrollflussüberwachung
implementiert. Aufeinander folgende Werte werden so verknüpft,
dass ein Vergleich des resultierenden Endergebnisses mit einem offline
berechneten Wert sehr gute Fehlerentdeckungseigenschaften aufweist.
-
Neben
den schon erläuterten Möglichkeiten der Musterüberwachung,
besteht eine weitere Alternative darin, die Dauer des ununterbrochenen
Aufenthaltes im Performanz- und/oder Vergleichsmodus zu überwachen,
wobei Unter- und Obergrenzen dieser Zeiträume angegeben
werden können. Es werden Muster in diesen Zeiträumen überwacht,
wie beispielsweise periodische Folgen 1 ms Vergleichsmodus, 5 ms
Performanzmodus, 2 ms Vergleichsmodus, 10 ms Performanzmodus usw.
-
Über
einen Timer und einen oder zwei Zähler kann die Zahl der
Aktivierungen von Vergleichsmodus oder Performanzmodus oder beiden
pro Zeiteinheit gemessen werden.
-
Für
bestimmte Versuche und Tests wird die Überwachung durch
eine entsprechende Konfiguration deaktiviert.
-
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
-
- - DE 102005037261
A1 [0003]