DE102016203965A1

DE102016203965A1 - Überwachung eines Rechensystems

Info

Publication number: DE102016203965A1
Application number: DE102016203965.2A
Authority: DE
Inventors: Mikkel Liisberg
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2016-03-10
Filing date: 2016-03-10
Publication date: 2017-09-14
Also published as: CN107179980B; US10282240B2; CN107179980A; US20170262325A1

Abstract

Ein Rechensystem ist zum dynamischen Ausführen von Prozessen eingerichtet. Ein Verfahren zum Überwachen des Rechensystems umfasst Schritte des Bestimmens einer Anzahl auf dem Rechensystem laufender Prozesse; des Bestimmens einer maximal erwarteten Anzahl Prozesse; des Bestimmens, dass mehr Prozesse laufen als erwartet; und des Deaktivierens des Rechensystems.

Description

Die Erfindung betrifft die Überwachung eines Rechensystems. Insbesondere betrifft die Erfindung die Überwachung eines Rechensystems, das zum dynamischen Ausführen von Prozessen eingerichtet ist.
Stand der Technik
In einer sicherheitsrelevanten Anwendung, beispielsweise an Bord eines Kraftfahrzeugs, wird eine Steueraufgabe üblicherweise mittels eines Rechensystems bearbeitet, das ausschließlich zum Ausführen von statischen Prozessen eingerichtet ist. Welche und wie viele Prozesse auf dem Rechensystem ablaufen, wird dabei üblicherweise zum Zeitpunkt der Bereitstellung von Programmen entschieden, die die Prozesse implementieren. Außerdem wird üblicherweise darauf geachtet, dass Software unterschiedlicher Prozesse nicht mehrfach verwendet wird. Das bedeutet, dass keine Funktionalität beispielsweise in mehrfach genutzten Bibliotheken bereitgestellt wird. Dadurch kann sichergestellt werden, dass die Prozesse getrennt voneinander und möglichst ausfallsicher ausgeführt sind. Insbesondere kann verhindert werden, dass ein Prozess Probleme für einen anderen Prozess bereitet. Ein derartiges Rechensystem umfasst üblicherweise ein Echtzeit-Betriebssystem wie OSEK-OS.
Um auch eine Funktionalität eines Drittanbieters zu unterstützen, ist ein solches statisches System jedoch schlecht geeignet. Es kann daher ein Rechensystem verwendet werden, das zum dynamischen Ausführen von Prozessen eingerichtet ist und ein Betriebssystem wie beispielsweise Linux umfasst. Dabei kann jedoch problematisch sein, dass ein Prozess einen anderen beeinträchtigen oder viele Prozesse so viel Verarbeitungsleistung erfordern können, dass ein wichtiger Prozess nicht zuverlässig ausgeführt werden kann.
Der Erfindung liegt die Aufgabe zugrunde, eine Technik zum Überwachen eines Rechensystems bereitzustellen, die einen verbesserten Schutz gegen unerwartet ausgeführte Prozesse bereitstellt. Die Erfindung löst diese Aufgabe mittels der Gegenstände der unabhängigen Ansprüche. Unteransprüche geben bevorzugte Ausführungsformen wieder.
Offenbarung der Erfindung
Ein Rechensystem ist zum dynamischen Ausführen von Prozessen eingerichtet. Ein Verfahren zum Überwachen des Rechensystems umfasst Schritte des Bestimmens einer Anzahl auf dem Rechensystem laufender Prozesse; des Bestimmens einer maximal erwarteten Anzahl Prozesse; des Bestimmens, dass mehr Prozesse laufen als erwartet; und des Deaktivierens des Rechensystems.
Das Rechensystem kann ein übliches programmierbares Computersystem umfassen, das beispielsweise an Bord eines Kraftfahrzeugs angeordnet sein kann. Das Computersystem kann einen oder mehrere Prozessoren mit jeweils einer oder mehreren Recheneinheiten, eine oder mehrere Kommunikationsschnittstellen und einen oder mehrere Speicher umfassen. Anders ausgedrückt kann das Computersystem auf übliche Weise, zentral oder dezentral, aufgebaut sein. Durch seine Eignung zur Ausführung dynamischer Prozesse können zur Laufzeit neue Prozesse gestartet oder bestehende Prozesse beendet werden. Durch das Überwachen einer erwarteten Maximalzahl von Prozessen kann unmittelbar darauf reagiert werden, wenn ein zusätzlicher, überzähliger Prozess gestartet wird. Dieser Prozess kann allgemein schädlich sein oder zusammen mit den erwarteten Prozessen die Belastung einer ausführenden Hardware (Computersystem) so weit erhöhen, dass die Ausführsicherheit eines oder mehrerer Prozesse gefährdet ist.
Das Bestimmen der Anzahl auf dem Rechensystem laufender Prozesse kann einfach durchgeführt werden, viele Betriebssysteme bieten hierfür eine Schnittstelle oder bereits ein fertiges Werkzeug an. Bei einem Unix-Betriebssystem kann dies insbesondere das Systemprogramm ps („process status“) sein.
Durch das Deaktivieren kann sich das Rechensystem an das Prinzip des „silent fail“ (in etwa: lautloses Versagen) halten, indem es bei Bekanntwerden eines Fehlers das Ausgeben von möglicherweise falschen Informationen, Bestimmungen, Berechnungen oder Steuersignalen durch einen der Prozesse verhindert. Die Arbeit des Rechensystems wird unmittelbar eingestellt um zu verhindern, dass durch falsche Ergebnisse weiterer Schaden angerichtet wird.
In einer weiteren bevorzugten Ausführungsform werden Systemrechte der laufenden Prozesse bestimmt, die bestimmten Systemrechte werden mit vorbestimmten Systemrechen verglichen, es wird bestimmt, dass einer der laufenden Prozesse erweiterte Systemrechte erlangt hat, und das Rechensystem wird deaktiviert.
Die Systemrechte können einfach auf entsprechende Weise wie die Anzahl der auf dem Rechensystem laufenden Prozesse bestimmt werden. Beispielsweise kann das Systemprogramm ps dazu verwendet werden, in Erfahrung zu bringen, auf welche Speicherbereiche ein angezeigter Prozess Schreibzugriff hat. Stimmt diese Angabe mit einem vorbestimmten Systemrecht, beispielsweise einer Aufstellung von rechtmäßig durch den Prozess beschreibbaren Speicherteilen, überein, so kann das Rechensystem ebenfalls deaktiviert werden.
Das Deaktivieren kann auf unterschiedliche Weisen erfolgen. In einer ersten Variante umfasst das Deaktivieren das Rücksetzen des Rechensystems. Dadurch werden alle laufenden Prozesse beendet und können bei einem anschließenden, erneuten Hochfahren des Rechensystems neu gestartet werden. Ein fehlerhaft gestarteter Prozess oder ein Prozess, der erweiterte Systemrechte erlangt hat, kann so unschädlich gemacht werden.
Das Rücksetzen kann das Ausführen einer Software-Rücksetzanforderung umfassen. Anders ausgedrückt kann das Verfahren ein Verarbeitungssignal absetzen, das beispielsweise von einem Betriebssystem des Rechensystems empfangen wird und das Rücksetzen des Rechensystems herbeiführt (Reset). Das Rücksetzen des Rechensystems per Software kann vorteilhafterweise den Einsatz zusätzlicher Hardware einsparen, wodurch Kosten bei Herstellung und Betrieb des Rechensystems verringert sein können. In einer anderen Ausführungsform kann auch eine Rücksetzanforderung in Hardware bewirkt werden, wie unten genauer beschrieben wird.
Das Rechensystem kann eine Verarbeitungseinrichtung und einen Überwachungsschaltkreis umfassen, wobei das Deaktivieren durch den Überwachungsschaltkreis gesteuert wird. Die Sicherheit, mit der das Rücksetzen des Rechensystems ausgelöst wird, kann dadurch gesteigert sein.
Allgemein ist bevorzugt, dass das Verfahren periodisch ausgeführt wird. Die Integrität des Rechensystems kann so fortlaufend sichergestellt sein.
Der oben erwähnte Überwachungsschaltkreis kann insbesondere einen Wachhund-Zeitgeber („watchdog timer“) umfassen, der bei Ablaufen das Rechensystem deaktiviert, wobei der Zeitgeber auf einen vorbestimmten Wert gesetzt wird, wenn das Rechensystem nicht deaktiviert werden soll. Der Wachhund-Zeitgeber kann auf diese Weise sicher für ein Rücksetzen des Rechensystems sorgen, wenn, beispielsweise durch einen Fehler in einem der Prozesse, das oben beschriebene Verfahren versagt, beispielsweise weil die Anzahl oder Systemrechte der laufenden Prozesse nicht bestimmt werden können.
In einer anderen Variante umfasst das Rechensystem eine Kommunikationsschnittstelle, wobei das Deaktivieren ein Abschalten der Kommunikationsschnittstelle umfasst. Dadurch kann unmittelbar verhindert werden, dass einer der Prozesse eine unerwünschte Außenwirkung mittels einer Nachricht über die Kommunikationsschnittstelle veranlasst. Durch das Abschalten der Kommunikationsschnittstelle kann ein Teil des Rechensystems faktisch deaktiviert werden, ohne andere Teile des Rechensystems funktionsunfähig zu machen.
In einer weiteren Ausführungsform sind einem der Prozesse mehrere leichtgewichtige Prozesse (Threads) zugeordnet, wobei das Rechensystem deaktiviert wird, wenn eine Anzahl Threads eine erwartete maximale Anzahl übersteigt.
Dadurch kann verhindert werden, dass ein Prozess mehr Threads startet als beabsichtigt. Dadurch kann verhindert werden, dass mehr Threads gestartet werden als für einen sicheren Betrieb des Rechensystems toleriert werden kann.
Ein Thread unterscheidet sich im Allgemeinen dadurch von einem Prozess, dass mehrere Threads, die zum gleichen Prozess gehören, gegenseitigen Zugriff auf Variablen oder Speicherbereiche haben können, ohne dass hierfür ein spezieller Mechanismus zur Interprozesskommunikation wie ein Semaphor oder ein mehrfach genutzter Speicherbereich aktiv angefordert werden muss.
Ein Computerprogrammprodukt umfasst Programmcodemittel zur Durchführung des oben beschriebenen Verfahrens, wenn das Computerprogrammprodukt auf einer Verarbeitungseinrichtung, insbesondere dem Rechensystem, abläuft oder auf einem computerlesbaren Datenträger gespeichert ist.
Ein Rechensystem ist dazu eingerichtet, dynamische Prozesse und das oben beschriebene Verfahren auszuführen. Dadurch kann das Rechensystem einerseits dazu verwendet werden, dynamische Prozesse auszuführen, die beispielsweise von einem Drittanbieter implementiert sein können, und andererseits die Ausführsicherheit eines ablaufenden Prozesses zu verbessern bzw. sicherzustellen.
Kurze Beschreibung der Figuren
Die Erfindung wird nun mit Bezug auf die beigefügten Figuren genauer beschrieben, wobei
1 ein Rechensystem, insbesondere zur Anwendung an Bord eines Kraftfahrzeugs;
2 eine schematische Darstellung eines Prozesses, der in einem Betriebssystem auf einem Rechensystem abläuft;
3 eine schematische Darstellung eines Rechensystems mit einem externen Wachhund-Zeitgeber; und
4 ein Ablaufdiagramm eines Verfahrens zur Steuerung eines Rechensystems
darstellt.
1 zeigt ein Rechensystem 100, insbesondere zur Anwendung an Bord eines Kraftfahrzeugs. Das Rechensystem 100 ist dazu eingerichtet, eine Steueraufgabe an Bord des Kraftfahrzeugs auszuführen. Das Rechensystem 100 umfasst bevorzugterweise ein Steuergerät 105, das bevorzugterweise mit einem oder mehreren Sensoren 110 verbunden ist und weiter bevorzugt eine Kommunikationsschnittstelle 115 zur Kommunikation mit einer anderen Einrichtung wie einem weiteren Steuergerät 105 oder einer Benutzerschnittstelle aufweist. Die Kommunikation mit der Kommunikationsschnittstelle 115 und/oder den Sensoren 110 kann beispielsweise mittels eines Netzwerks 120 erfolgen. Als ausführende Einrichtung umfasst das Steuergerät 105 eine oder mehrere Verarbeitungseinrichtungen 125, die jeweils durch einen programmierbaren Mikrocomputer oder eine CPU mit einem oder mehreren Kernen realisiert sein kann. Auf jeder Verarbeitungseinrichtung 125 läuft bevorzugterweise ein Betriebssystem 130, wobei sich auch ein Betriebssystem 130 über mehrere Verarbeitungseinrichtungen 125 erstrecken kann.
Das Rechensystem 100 ist dazu eingerichtet, dynamisch Prozesse 135 auszuführen. Die Prozesse 135 können dynamisch gestartet und beendet werden, wobei das Starten durch das Betriebssystem 130, durch einen anderen Prozess 135 oder auf der Basis eines beispielsweise zeitlichen Ereignisses erfolgen kann. Jeder Prozess 135 kann einen oder mehrere leichtgewichtige Prozesse (Threads) 140 umfassen. Dabei laufen alle Threads 140 eines Prozesses 135 üblicherweise als User-Threads in der gleichen Umgebung und mit den gleichen Betriebsmitteln, die dem übergeordneten Prozess 135 zugeordnet sind.
Ein Prozess 135 kann insbesondere eine Steuerungsaufgabe wahrnehmen, wobei eine Umgebungsvariable mittels eines Sensors 110 abgetastet, das Ergebnis verarbeitet und mittels der Kommunikationsschnittstelle 115 ein Aktor betätigt werden kann, der üblicherweise direkt oder mittelbar auf den Sensor 110 zurückwirkt.
Um das Ausführen von Prozessen 135 auf dem Rechensystem 100 zu ermöglichen, die zu einem Zeitpunkt der Konzeption des Rechensystems 100 noch nicht bekannt waren, sich seit der Konzeption verändert (weiterentwickelt) haben oder erst später auf dem Rechensystem 100 installiert wurden, wird vorgeschlagen, nicht nur ein Betriebssystem 130 zu verwenden, das die Ausführung dynamischer Prozesse 135 erlaubt, sondern zusätzlich dafür zu sorgen, dass nicht übermäßig viele Prozesse 135 auf dem Rechensystem 100 laufen.
2 zeigt eine schematische Darstellung eines Prozesses 135, der in einem Betriebssystem 130 auf einem Rechensystem 100 wie dem von 1 abläuft. Das Betriebssystem 130 stellt eine Überwachungsfunktion 205 bereit, die dazu eingerichtet ist, Informationen über Prozesse 135, die auf dem Rechensystem 100 ablaufen oder zum Ablaufen bereitstehen, zu liefern. Bei einem Unix-artigen Betriebssystem 130 kann die Überwachungsfunktion 205 beispielsweise das Systemprogramm ps umfassen, das die gewünschten Informationen von einem Dateisystem 210 des Betriebssystems 130 abfragen kann. Unter Unix weist ein Prozess 135 Eigenschaften einer Datei auf, die über das Dateisystem 210 verwaltet werden können. Bei anderen Betriebssystemen 130 kann ein anderer Mechanismus eingesetzt werden.
Es wird vorgeschlagen, die Überwachungsfunktion 205 dazu zu verwenden, mittels eines Verfahrens 215 Informationen über laufende Prozesse 135 oder Threads 140 zu erlangen und zu analysieren. Wird dabei eine Anomalie festgestellt, so kann eine Maßnahme eingeleitet werden, die das Versenden eines Signals 220 umfassen kann, das dafür sorgt, dass möglichst alle Prozesse 135, die auf dem Rechensystem 100 ablaufen, möglichst sofort beendet werden, inhibiert werden oder ihre Kommunikation, insbesondere zu einem Aktor, unterbrochen wird.
3 zeigt eine schematische Darstellung eines Rechensystems 100 mit einem externen Wachhund-Zeitgeber („watchdog“) 305. Wird durch das Verfahren 215 bestimmt, dass eine Unregelmäßigkeit an einem der Prozesse 135 oder einem der Threads 140 vorliegt, so kann eine interne Aktion durchgeführt werden, die rein softwarebasiert ist, oder eine externe Aktion, die den Wachhund-Zeitgeber 305 erfordert. Beide Aktionen können das Ausgeben eines Signals 220 umfassen, um entweder das Rechensystem 100 rückzusetzen (Reset) 100 oder eine Unterbrechung einer Kommunikation mittels der Kommunikationsschnittstelle 115 zu bewirken. Wird der Wachhund-Zeitgeber 305 nicht verwendet, so kann über das Verfahren 215 selbst oder über das Betriebssystem 130 das Rücksetzen oder Sperren der Kommunikationsschnittstelle 115 ausgelöst werden.
Andererseits können beide Funktionalitäten auch unabhängig voneinander über den Wachhund-Zeitgeber 305 bewirkt werden. Hierbei ist besonders von Vorteil, dass der Wachhund-Zeitgeber 305 dazu angesteuert werden kann, die beschriebene Maßnahme einzuleiten, wenn ein komplementäres Signal 220, das besagt, dass keine Anomalie festgestellt wurde, länger als eine vorbestimmte Zeit ausbleibt. Das Verfahren 215 wird bevorzugterweise periodisch durchgeführt und immer dann, wenn keine Anomalie bestimmt wurde, wird der Wachhund-Zeitgeber 305 auf eine Zeit gesetzt, die der Periodendauer der Ausführung des Verfahrens 215 entspricht oder sie übersteigt. Beispielsweise kann das Verfahren 215 sekündlich durchgeführt werden und der Wachhund-Zeitgeber 305 immer dann, wenn keine Anomalie festgestellt wurde, auf eine Laufzeit von ≥ 1 Sekunde eingestellt werden. Kann das Verfahren 215 einmal nicht ausgeführt werden, beispielsweise weil seine Ausführung länger als eine Sekunde in Anspruch nimmt oder wichtige Systemressourcen des Rechensystems 100 nicht verfügbar sind, so läuft der Wachhund-Zeitgeber 305 ab und bewirkt das Unterbrechen der Kommunikation über die Kommunikationsschnittstelle 115 oder ein Rücksetzen des Rechensystems 100 bzw. des Steuergeräts 105 oder auch nur einer der Verarbeitungseinrichtungen 125.
4 zeigt ein Ablaufdiagramm eines Verfahrens 400 zur Steuerung eines Rechensystems 100 wie dem einer der vorangehenden Figuren. Das Verfahren 400 kann insbesondere dem Verfahren 215 von 2 entsprechen. In der folgenden Beschreibung wird von einer Anzahl Prozessen 135 ausgegangen, dabei ist das Verfahren 400 in entsprechender Weise auch für Threads 140 geeignet. Das Verfahren 400 wird bevorzugterweise periodisch ausgeführt, beispielsweise gesteuert durch einen Zeitgeber.
In einem ersten Schritt 405 wird eine maximale Anzahl Prozesse 135 bestimmt, von der erwartet wird, dass sie auf dem Rechensystem 100 (gleichzeitig) ablaufen. Diese maximale Anzahl kann fest vorgegeben sein und beispielsweise nur dann verändert werden, wenn ein neuer Prozess 135 auf dem Rechensystem 100 installiert bzw. nachgerüstet wird. In einer anderen Ausführungsform kann die maximale Anzahl Prozesse 135 auch dynamisch sein, indem vor dem Starten eines Prozesses 135 eine entsprechende Nachricht beispielsweise an das Betriebssystem 130 geschickt wird, um die maximale Anzahl Prozesse 135 entsprechend anzupassen.
In einem Schritt 410 wird die aktuelle Anzahl Prozesse 135 bestimmt. Dazu kann insbesondere die Überwachungsfunktion 205 verwendet werden. In einer weiteren Ausführungsform können auch weitere Informationen über die Prozesse 135 abgefragt werden, insbesondere die vorliegenden Systemberechtigungen der laufenden Prozesse 135.
In einem Schritt 415 werden die gewonnenen Informationen daraufhin untersucht, ob eine Unregelmäßigkeit vorliegt. Insbesondere kann überprüft werden, ob die aktuelle Anzahl Prozesse 135 die bestimmte maximale Anzahl Prozesse 135 übersteigt. Ist dies der Fall, so kann das Verfahren 400 mit einem Schritt 435 fortfahren, der unten noch genauer beschrieben wird.
Andernfalls können in einem Schritt 420 vorbestimmte Systemrechte eines oder mehrerer Prozesse 135 bestimmt werden. In einem Schritt 425 können dann, ähnlich wie in Schritt 410, Informationen über Systemrechte von Prozessen 135 auf dem Rechensystem 100 bestimmt werden. In einem Schritt 430 werden die vorbestimmten und die tatsächlichen Systemrechte miteinander verglichen und der Schritt 435 kann angesteuert werden, falls die tatsächlichen Systemrechte eines Prozesses 135 die vorbestimmten Systemrechte übersteigen. Andernfalls kann das Verfahren 400 zum Schritt 405 zurückkehren und erneut durchlaufen.
Im Schritt 435 wird optional eine Kommunikation mittels der Kommunikationsschnittstelle 115 unterbunden. Dazu kann die Kommunikationsschnittstelle 115 abgeschaltet werden oder ein Teil des Betriebssystems 130, das zur Benutzung der Kommunikationsschnittstelle 115 erforderlich ist, kann den Zugriff verweigern.
Zusätzlich oder alternativ kann in einem Schritt 440 ein Rücksetzen des Rechensystems 100 veranlasst werden. Die Schritte 435 und 440 können unabhängig voneinander jeweils per Software oder per Hardware, insbesondere mittels des Wachhund-Zeitgebers 305, veranlasst werden, wie oben ausgeführt ist.

Claims

Verfahren (400) zum Überwachen eines Rechensystems (100), das zum dynamischen Ausführen von Prozessen (135) eingerichtet ist, wobei das Verfahren (400) folgende Schritte umfasst: – Bestimmen (410) einer Anzahl auf dem Rechensystem (100) laufender Prozesse (135); – Bestimmen (405) einer maximal erwarteten Anzahl Prozesse (135); – Bestimmen (415), dass mehr Prozesse (135) laufen als erwartet; und – Deaktivieren (435, 440) des Rechensystems (100).
Verfahren (400) nach Anspruch 1, ferner folgende Schritte umfassend: – Bestimmen (425) von Systemrechten der laufenden Prozesse (135); – Vergleichen (430) der bestimmten Systemrechte mit vorbestimmten Systemrechten; – Bestimmen (430), dass einer der laufenden Prozesse (135) erweiterte Systemrechte erlangt hat; und – Deaktivieren (435, 440) des Rechensystems (100).
Verfahren (400) nach Anspruch 1 oder 2, wobei das Deaktivieren das Rücksetzen (440) des Rechensystems (100) umfasst.
Verfahren (400) nach Anspruch 3, wobei das Rücksetzen (440) das Ausführen einer Software-Rücksetzanforderung umfasst.
Verfahren (400) nach Anspruch 3, wobei das Rechensystem (100) eine Verarbeitungseinrichtung (125) und einen Überwachungsschaltkreis (305) umfasst und das Deaktivieren (435, 440) durch den Überwachungsschaltkreis (305) gesteuert wird.
Verfahren (400) nach einem der vorangehenden Ansprüche, wobei das Verfahren (400) periodisch ausgeführt wird
Verfahren (400) nach Ansprüchen 5 und 6, wobei der Überwachungsschaltkreis einen Wachhund-Zeitgeber (305) umfasst, der bei Ablaufen das Rechensystem (100) deaktiviert (435, 440), wobei der Zeitgeber (305) auf einen vorbestimmten Wert gesetzt wird, wenn das Rechensystem (100) nicht deaktiviert werden soll.
Verfahren (400) nach einem der vorangehenden Ansprüche, wobei das Rechensystem (100) eine Kommunikationsschnittstelle (115) umfasst und das Deaktivieren ein Abschalten (435) der Kommunikationsschnittstelle (115) umfasst.
Verfahren (400) nach einem der vorangehenden Ansprüche, wobei einem der Prozesse (135) mehrere leichtgewichtige Prozesse (140) zugeordnet sind und das Rechensystem (100) deaktiviert wird, wenn eine Anzahl leichtgewichtiger Prozesse (140) eine erwartete maximale Anzahl leichtgewichtiger Prozesse (140) übersteigt.
Computerprogrammprodukt mit Programmcodemitteln zur Durchführung des Verfahrens (400) nach einem der vorangehenden Ansprüche, wenn das Computerprogrammprodukt auf einer Verarbeitungseinrichtung (125) abläuft oder auf einem computerlesbaren Datenträger gespeichert ist.
Rechensystem (100), das dazu eingerichtet ist, dynamische Prozesse (135) und ein Verfahren (400) nach einem der Ansprüche 1 bis 9 auszuführen.