DE102018210733A1 - Verfahren zum Überwachen wenigstens einer Recheneinheit - Google Patents

Verfahren zum Überwachen wenigstens einer Recheneinheit Download PDF

Info

Publication number
DE102018210733A1
DE102018210733A1 DE102018210733.5A DE102018210733A DE102018210733A1 DE 102018210733 A1 DE102018210733 A1 DE 102018210733A1 DE 102018210733 A DE102018210733 A DE 102018210733A DE 102018210733 A1 DE102018210733 A1 DE 102018210733A1
Authority
DE
Germany
Prior art keywords
monitoring module
software
software monitoring
processes
computing unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102018210733.5A
Other languages
English (en)
Inventor
Alexander Maletz
Gunnar Piel
Mikkel Liisberg
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Priority to DE102018210733.5A priority Critical patent/DE102018210733A1/de
Publication of DE102018210733A1 publication Critical patent/DE102018210733A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751Error or fault detection not based on redundancy
    • G06F11/0754Error or fault detection not based on redundancy by exceeding limits
    • G06F11/0757Error or fault detection not based on redundancy by exceeding limits by exceeding a time limit, i.e. time-out, e.g. watchdogs
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766Error or fault reporting or storing
    • G06F11/0784Routing of error reports, e.g. with a specific transmission path or data flow
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793Remedial or corrective actions

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Überwachen wenigstens einer Recheneinheit (110, 120, 130), in welcher eine Vielzahl von Prozessen (112, 113, 114, 123, 124, 127, 128, 129, 133, 134, 137, 138, 139) ausgeführt wird, mittels eines Systems aus Überwachungsmodulen (140, 111, 122, 126, 132, 136), die in verschiedene Hierarchieebenen eingeteilt sind, wobei in einer obersten Hierarchieebene ein oberstes Überwachungsmodul (140) als ein Hardwareüberwachungsmodul vorgesehen ist, wobei in wenigstens einer der obersten Hierarchieebene untergeordneten Hierarchieebene jeweils wenigstens ein Softwareüberwachungsmodul (111, 122, 126, 132, 136) vorgesehen ist, wobei jedes Softwareüberwachungsmodul (111, 122, 126, 132, 136) jeweils wenigstens einen zugewiesenen Prozess (112, 113, 114, 123, 124, 127, 128, 129, 133, 134, 137, 138, 139) überwacht und wobei jedes Softwareüberwachungsmodul (111, 122, 126, 132, 136) einer Hierarchieebene von einem übergeordneten Überwachungsmodul (140, 111, 122, 132) einer übergeordneten Hierarchieebene überwacht wird.

Description

  • Die vorliegende Erfindung betrifft ein Verfahren zum Überwachen wenigstens einer Recheneinheit sowie eine Recheneinheit und ein System aus wenigsten zwei Recheneinheiten.
  • Stand der Technik
  • Moderne Recheneinheiten wie Steuergeräte, beispielsweise von Fahrzeugen, umfassen eine Prozessoreinheit zum Ausführen von Prozessen, welche einen zweckmäßigen Prozessor bzw. Prozessorkern (Core) oder auch einen Multicore-Prozessor umfassen kann. Multicore-Prozessoren umfassen dabei mehrere (wenigstens zwei) Prozessorkerne. Ein Prozessorkern umfasst dabei eine arithmetisch-logische Einheit (ALU), welche das eigentliche elektronische Rechenwerk zur Ausführung von Tasks, Programmen, Rechenbefehlen, etc. darstellt, und weiterhin einen lokalen Speicher. Ein derartiger lokaler Speicher ist insbesondere als ein Registersatz aus einem oder mehreren Registern ausgebildet.
  • Recheneinheiten können in verschiedene Domänen unterteilt sein, wobei in diesen einzelnen Domänen jeweils Prozesse unabhängig voneinander durchgeführt werden können. Jeder Domäne sind dabei individuell Ressourcen zugeordnet z.B. in Form von Laufzeit, Rechenkapazität und Speicher, so dass die einzelnen Domänen voneinander logisch getrennt sind und als separate Recheneinheiten betrachtet werden können. Beispielsweise können derartige Domänen durch virtuelle Systeme bzw. virtuelle Maschinen realisiert sein, in welchen jeweils voneinander getrennte Betriebssysteme oder Anwendungen als Prozesse ausgeführt werden können. Auf diese Weise können in einer realen, physischen Prozessoreinheit beispielsweise eine Vielzahl von virtuellen Prozessoreinheiten simuliert werden.
  • Zum Überwachen von Recheneinheiten bzw. von Prozessen, die von der Recheneinheit ausgeführt werden, können sog. Watchdogs vorgesehen sein, welche durch einen Datenaustausch beispielsweise in Form einer Frage-/Antwort-Kommunikation Fehler erkennen können. Beispielsweise wird von dem Watchdog zu diesem Zweck überprüft, ob der Datenaustausch bzw. die erhaltenen Antworten richtig sind und ob sie zu einem richtigen Zeitpunkt bzw. innerhalb eines vorgegebenen Zeitfensters eintreffen. Wenn dies nicht der Fall ist, kann auch einen Fehler der Recheneinheit bzw. des jeweiligen Prozesses rückgeschlossen werden. Derartige Watchdogs können in Hardware als ein separates Hardwareelement realisiert sein oder auch in Software, welche von einer Prozessoreinheit ausgeführt wird, wie beispielsweise in der DE 10 2009 038 434 A1 , der CN 104636212 A oder der CN 104199746 A beschrieben ist.
  • Offenbarung der Erfindung
  • Erfindungsgemäß werden ein Verfahren zum Überwachen wenigstens einer Recheneinheit sowie eine Recheneinheit und ein System aus wenigsten zwei Recheneinheiten mit den Merkmalen der unabhängigen Patentansprüche vorgeschlagen. Vorteilhafte Ausgestaltungen sind Gegenstand der Unteransprüche sowie der nachfolgenden Beschreibung.
  • Das vorliegende Verfahren eignet sich zur Überwachung einer einzelnen Recheneinheit oder zur Überwachung eines Systems aus mehreren Recheneinheiten, die miteinander in Kommunikationsverbindung stehen. In der wenigstens einen Recheneinheit wird eine Vielzahl von Prozessen ausgeführt. Diese verschiedenen Prozesse können somit beispielsweise in einer einzigen Recheneinheit oder insbesondere auch in verschiedenen Recheneinheiten ausgeführt werden. Durch das vorliegende Verfahren kann diese Vielzahl von Prozessen auf Fehler hin überwacht werden.
  • Im Rahmen des vorliegenden Verfahrens ist ein System aus Überwachungsmodulen bzw. Watchdogs vorgesehen, welche in verschiedene Hierarchieebenen eingeteilt sind. Die Überwachungsmodule sind also in wenigstens zwei Hierarchieebenen eingeteilt, wobei in jeder der Hierarchieebenen wenigstens ein Überwachungsmodul vorgesehen ist. Überwachungsmodule in einer höheren Hierarchieebene sind dabei Überwachungsmodulen in niedrigeren Hierarchieebenen übergeordnet. Zu diesem Zweck kann ein Überwachungsmodul einer höheren Hierarchieebene als ein Master vorgesehen sein und ein Überwachungsmodul einer niedrigeren Hierarchieebene als ein entsprechender Slave.
  • In einer obersten Hierarchieebene ist ein oberstes Überwachungsmodul als ein Hardwareüberwachungsmodul bzw. als ein Hardware-Watchdog vorgesehen. In wenigstens einer der obersten Hierarchieebene untergeordneten Hierarchieebene ist jeweils wenigstens ein Softwareüberwachungsmodul bzw. Software-Watchdog vorgesehen. Das Hardwareüberwachungsmodul ist somit zweckmäßigerweise als ein eigenes Hardwareelement vorgesehen und kann beispielsweise als eine Komponente in eine der Recheneinheiten implementiert sein oder auch als ein externes Element vorgesehen sein, welches mit der wenigstens einen Recheneinheit in Kommunikationsverbindung steht. Die einzelnen Softwareüberwachungsmodule sind insbesondere in der wenigstens einen Recheneinheit jeweils als ausgeführte Software implementiert.
    Dabei können beispielsweise von einer Prozessoreinheit einer Recheneinheit mehrere Softwareüberwachungsmodule ausgeführt werden, welche jeweils unterschiedlichen Hierarchieebenen zugewiesen sein können.
  • Somit ist insbesondere ein Hardwareüberwachungsmodul bzw. ein Hardware-Watchdog vorgesehen, welches einem System aus Softwareüberwachungsmodulen bzw. Software-Watchdogs übergeordnet ist und zur Überwachung der Softwareüberwachungsmodule bzw. Software-Watchdogs vorgesehen ist. Die Softwareüberwachungsmodule können somit insbesondere kaskadiert realisiert und zweckmäßigerweise auf eine Vielzahl von Hierarchieebenen verteilt sein.
  • Jedes Softwareüberwachungsmodul überwacht jeweils wenigstens einen zugewiesenen Prozess. Ferner wird jedes Softwareüberwachungsmodul einer Hierarchieebene von einem übergeordneten Überwachungsmodul einer übergeordneten Hierarchieebene überwacht, insbesondere von einem unmittelbar übergeordneten Überwachungsmodul einer unmittelbar übergeordneten Hierarchieebene. Somit überwacht jedes Softwareüberwachungsmodul ihm individuell zugewiesene Prozesse auf Fehler hin und wird wiederum selbst von einem ihm zugewiesenen übergeordneten Überwachungsmodul auf Fehler hin überwacht.
  • Insbesondere überwachen somit übergeordnete Softwareüberwachungsmodule ihnen individuell zugewiesene untergeordnete Softwareüberwachungsmodule, insbesondere in der unmittelbar untergeordneten Hierarchieebene. Ein oberstes dieser Softwareüberwachungsmodule in einer obersten Hierarchieebene der Softwareüberwachungsmodule wird zweckmäßigerweise von dem Hardwareüberwachungsmodul in der obersten Hierarchieebene überwacht. Wenn ein Softwareüberwachungsmodul einen Fehler eines unterlagerten Softwareüberwachungsmodul erkennt, kann dieser erkannte Fehler insbesondere an das Hardwareüberwachungsmodul weitergeleitet werden, welches dann entscheidet, wie mit dem fehlerhaften Softwareüberwachungsmodul weiter verfahren wird.
  • Das vorliegende Verfahren ermöglicht somit ein dediziertes Überwachen von Prozessen in einer oder mehreren Recheneinheiten mit einem Hardware-Watchdog und einem System aus insbesondere kaskadierten Software-Watchdogs. Insbesondere kann somit ein effektives Überwachen der einzelnen Prozesse ermöglicht werden, wobei zweckmäßigerweise nur ein einziger Hardware-Watchdog und eine Vielzahl von kaskadierten Software-Watchdogs verwendet werden, um effektiv individuelle dedizierte Prozesse in der Recheneinheit bzw. in dem System aus Recheneinheiten zu überwachen.
  • Mit Hilfe des vorliegenden Verfahrens wird es zweckmäßigerweise ermöglicht, komplexe Systeme zu überwachen, in welchen Prozesse nicht strikt sequentiell als Programm ablaufen, sondern in welchen eine Vielzahl von Prozessen bzw. Threads unabhängig voneinander in einer oder mehreren Recheneinheiten ablaufen und auch selbständig Threads erzeugen können. Insbesondere weisen derartig komplexe Systeme einen Kernel und mehrere Prozesse und Threads auf, die im sog. Benutzerraum (engl. „user space“) ablaufen. Üblicherweise ist es nicht ohne weiteres möglich, derartige komplexe softwareintensive Systeme mit einem einzigen Hardware-Watchdog zu überwachen. Durch die spezielle Kombination eines Hardware-Watchdogs und einer Vielzahl von kaskadierten Software-Watchdogs kann im Rahmen des vorliegenden Verfahrens dennoch eine effektive und sichere Überwachung ermöglicht werden.
  • Insbesondere kann sich die auf derartig komplexen Systemen ausgeführte Software über die Lebenszeit ändern z.B. aufgrund von Updates, Programmverbesserungen oder Programmerweiterungen. Das System aus Überwachungsmodulen kann an veränderte Software auf einfache Weise angepasst werden, beispielsweise indem neue Softwareüberwachungsmodule im Zuge von Updates in das System implementiert werden oder indem neuen Softwarekomponenten bzw. neu implementierten Prozessen bereits im System vorhandene Softwareüberwachungsmodule zugewiesen werden.
  • Besonders vorteilhaft eignet sich das vorliegen Verfahren für komplexe Systeme aus einer Vielzahl von Recheneinheiten, die z.B. jeweils als Mikroprozessor oder Mikrocontroller mit einer Vielzahl von Prozessorkernen (Multicore-Prozessoren) ausgebildet sein können, auf denen jeweils ein zweckmäßiges Betriebssystem (z.B. Linux) ausgeführt wird und die miteinander über ein zweckmäßiges Kommunikationssystem in Kommunikationsverbindung stehen, insbesondere über ein Bussystem wie CAN oder Ethernet. Die einzelnen Recheneinheiten können dabei beispielsweise unterschiedlich ausgestaltet sein und beispielsweise können auf den verschiedenen Recheneinheiten auch verschiedene Betriebssysteme ausgeführt werden.
  • Besonders bevorzugt umfasst das System wenigstens zwei Recheneinheiten, wobei eine der Recheneinheiten als eine Sicherheitsrecheneinheit („safety backbone“) vorgesehen ist, welche direkt mit dem externen Hardwareüberwachungsmodul kommuniziert. In dieser Sicherheitsrecheneinheit ist insbesondere ein in der Hierarchie oberstes der Softwareüberwachungsmodule vorgesehen, welchem nur noch das Hardwareüberwachungsmodul übergeordnet ist.
  • Neben der Sicherheitsrecheneinheit umfasst das System ferner wenigstens eine weitere Recheneinheit, in welcher jeweils sicherheitskritische, nicht-sicherheitskritische, dynamische und/oder statische Prozesse ausgeführt werden. In jeder dieser weiteren Recheneinheiten ist zweckmäßigerweise wenigstens ein Softwareüberwachungsmodul vorgesehen. Ferner ist in jeder dieser Recheneinheiten jeweils ein in der jeweiligen Recheneinheit oberstes Softwareüberwachungsmodul als ein Master vorgesehen, welches die weiteren jeweils als Slave vorgesehenen Softwareüberwachungsmodule in der jeweiligen Recheneinheit überwacht. Dieses oberste Softwareüberwachungsmodul der jeweiligen Recheneinheit kommuniziert wiederum insbesondere direkt mit dem Softwareüberwachungsmodul der Sicherheitsrecheneinheit und wird zweckmäßigerweise von diesem überwacht.
  • Ferner eignet sich das vorliegende Verfahren in besonders vorteilhafter Weise für Recheneinheiten, die als Multi-Domänen Recheneinheiten ausgebildet und in verschiedene Domänen unterteilt sind, in welchen also Prozesse jeweils unabhängig voneinander in voneinander unabhängigen, logisch getrennten Domänen durchgeführt werden. Somit ermöglicht das vorliegende Verfahren eine domänenübergreifende und ferner eine mehrere Recheneinheiten übergreifende Überwachung von Prozessen und kann zweckmäßigerweise an eine beliebige Software und Komplexität und Anzahl von Domänen angepasst werden.
  • Insbesondere ist für jede Domäne in einer Recheneinheit ein Softwareüberwachungsmodul vorgesehen, welches die in der jeweiligen Domäne ablaufenden Prozesse überwacht. In einer zentralen Domäne (sog. „Housekeeping-Domäne“) einer derartigen Multi-Domänen-Recheneinheit ist ein oberstes insbesondere als Master vorgesehenes Softwareüberwachungsmodul der jeweiligen Recheneinheit vorgesehen, welches die einzelnen in den übrigen Domänen vorgesehenen Softwareüberwachungsmodule überwacht und selbst wiederum zweckmäßigerweise von dem Softwareüberwachungsmodul der Sicherheitsrecheneinheit überwacht wird.
  • Besonders bevorzugt eignet sich das Verfahren zur Anwendung im Fahrzeugbereich. Komplexe Systeme wie obig beschrieben aus verschiedenen Recheneinheiten, die jeweils insbesondere auch als Multi-Domänen-Recheneinheiten ausgebildet sein können, gewinnen im (Kraft-) Fahrzeugbereich stetig an Bedeutung und werden insbesondere in Steuergeräten verwendet. Ein solches System besitzt insbesondere ein Vielfaches der Rechenleistung eines herkömmlichen Steuergeräts und wird oftmals als eingebettetes Hochleistungssteuergerät (engl. „embedded high-performance control unit“) oder als Fahrzeugcomputer (engl. „vehicle computer“ oder „in-vehicle computer“) bezeichnet. Beispielsweise finden derartige Systeme im Bereich des hochautomatisierten Fahrens Anwendung, um die Durchführung von komplexen Berechnungen mit hoher Rechenleistung zu ermöglichen.
  • Ferner kann die Integration kommerzieller Softwareanteile von Drittanbietern z.B. auf der Basis des Linux-Betriebssystems ermöglicht werden. In derartigen Systemen kommen dann zweckmäßigerweise keine herkömmlichen eingebetteten Betriebssysteme wie z.B. Ercosek zum Einsatz, welche auf herkömmliche Weise für Steuerungsanwendungen insbesondere im Kraftfahrzeugbereich verwendet werden. Daher ist es zumeist nicht möglich, eine Überwachung derartiger Systeme mittels herkömmlicher Überwachungssysteme des Kraftfahrzeugbereichs durchzuführen, welche zumeist durch einen Hardware-Watchdog realisiert sind. Das vorliegende Verfahren bietet die Möglichkeit, derartige komplexe Systeme in einem Kraftfahrzeug, insbesondere in einem Steuergerät eines Kraftfahrzeugs, zuverlässig zu überwachen und somit eine hohe Sicherheitsintegrität zu schaffen.
  • Insbesondere ermöglicht das vorliegende Verfahren die Anbindung einer oder mehrerer Multi-Domänen-Recheneinheiten, in welchen statische und dynamische Prozesse sowie sicherheitskritische und nicht sicherheitskritische Prozesse ausgeführt werden, an ein bestehendes Überwachungs-Konzept, wie es im Kraftfahrzeugbereich üblicherweise umgesetzt wird, anzubinden. Fehlerhafte Prozesse können insbesondere explizit erkannt werden und eine dedizierte, lokale Fehlerbehandlung wird ermöglicht. Ferner kann insbesondere zwischen sicherheitskritischen und nicht-sicherheitskritischen Prozessen und im Fehlerfall zwischen Verfügbarkeits- und Sicherheitsmaßnahmen unterschieden werden.
  • Vorteilhafterweise führt jedes Softwareüberwachungsmodul zur Überwachung des jeweiligen wenigstens einen zugewiesenen Prozesses eine Frage-/Antwort-Kommunikation und/oder eine Gut-/Schlecht-Prüfung durch. Insbesondere erfolgt die Kommunikation dabei geschützt mittels einer Ende-zu-Ende-Verschlüsselung. Die Kommunikation kann beispielsweise seriell oder paketorientiert erfolgen. Es ist insbesondere auch denkbar, dass nur Antworten zur Überprüfung übertragen werden. Beispielsweise können die Softwareüberwachungsmodule zur Überprüfung von sicherheitskritischen Prozessen eine Frage-/Antwort-Kommunikation durchführen und zur Überprüfung von nicht-sicherheitskritischen Prozessen eine Gut-/Schlecht-Prüfung. Alternativ können die Softwareüberwachungsmodule beispielsweise auch sowohl für sicherheitskritische als auch für nicht-sicherheitskritische Prozesse jeweils eine Gut-/Schlecht-Prüfung durchführen.
  • Vorzugsweise überwacht jedes Softwareüberwachungsmodul den jeweiligen wenigstens einen zugewiesenen Prozess im Hinblick auf Laufzeit, Lebendigkeit und/oder korrekte Ausführung hin. Somit wird von den Softwareüberwachungsmodulen insbesondere überwacht, ob die jeweiligen zugewiesenen Prozesse korrekt innerhalb zulässiger Laufzeiten ausgeführt werden oder ob die Prozesse beispielsweise abgestürzt oder eingefroren sind. Insbesondere wird von den Softwareüberwachungsmodulen somit jeweils eine Programmablaufkontrolle durchgeführt, besonders bevorzugt für sicherheitskritische Prozesse. Nicht-sicherheitskritische Prozesse können insbesondere auch dynamisch für eine Überwachung an- und abgemeldet werden, d.h. es kann insbesondere dynamisch eingestellt werden, ob ein Softwareüberwachungsmodul einen jeweiligen ihm zugewiesenen Prozess aktuell überwachen soll oder nicht.
  • Bevorzugt führt jedes Softwareüberwachungsmodul bei einem erkannten Fehler des jeweiligen wenigstens einen zugewiesenen Prozesses eine vorgegebene Maßnahme durch. Insbesondere kann als derartige Maßnahme eine Fehlerreaktion durchgeführt werden, um den erkannten Fehler zu beheben. Bei einem Fehler eines sicherheitskritischen Prozesses kann diese Fehlerreaktion insbesondere in derselben Hierarchieebene durchgeführt werden, welcher das den Fehler erkannte Softwareüberwachungsmodul zugewiesen ist. Bei erkanntem Fehler eines nicht-sicherheitskritischen Prozesses kann die entsprechende Fehlerreaktion zweckmäßigerweise in einer nächsthöheren Hierarchieebene durchgeführt werden.
  • Bei sicherheitskritischen Fehlern ist es oftmals notwendig, direkt und mit einer bestimmten Zeitvorgabe zu reagieren. In diesem Fall wird daher als entsprechende Maßnahme eine Fehlerreaktion zweckmäßigerweise in der Domäne ausgeführt, in welcher der jeweilige Fehler erkannt wird. Bei nicht-sicherheitskritischen Fehlern gibt es in der Regel eine Verfügbarkeits-Anforderung und daher wird die entsichernde Fehlerreaktion insbesondere auf einer höheren Ebene durchgeführt.
  • Gemäß einer vorteilhaften Ausführung wird als vorgegebene Maßnahme eine Ersatzreaktion bzw. Fehlerreaktion durch das jeweilige Softwareüberwachungsmodul durchgeführt bzw. eingeleitet. Vorzugsweise wird als derartige Fehlerreaktion ein Reset oder ein Neustart oder ein Deaktivieren des jeweiligen Prozesses, der jeweiligen Domäne oder der jeweiligen Recheneinheit durchgeführt. Bei erkanntem Fehler reagiert das Softwareüberwachungsmodul somit selbst und führt eine entsprechende Maßnahme zur Behebung des Fehlers selbst durch.
  • Vorteilhafterweise wird als Maßnahme der erkannte Fehler von dem jeweiligen Softwareüberwachungsmodul an ein Fehlermodul (engl. „Error Management Module“) übermittelt. Zweckmäßigerweise führt das Fehlermodul daraufhin die entsprechende Fehlerreaktion durch, also insbesondere Reset, Neustart oder Deaktivieren des Prozesses, der Domäne oder der Recheneinheit. In diesem Fall führt somit nicht das jeweilige Softwareüberwachungsmodul selbst eine Fehlerreaktion durch, sondern das Fehlermodul.
  • Vorzugsweise wird jedes Softwareüberwachungsmodul einer Hierarchieebene durch eine Frage-/Antwort-Kommunikation und/oder eine Gut-/Schlecht-Prüfung von dem jeweiligen übergeordneten Überwachungsmodul der übergeordneten Hierarchieebene überwacht. Insbesondere kann durch eine Frage-/Antwort-Kommunikation zwischen den einzelnen Software-Watchdogs innerhalb des kaskadierten Watchdog-Systems die korrekte Funktion der Kette zur Laufzeit geprüft werden. Die Kommunikation zwischen den Überwachungsmodulen verschiedener Hierarchieebenen erfolgt zweckmäßigerweise mittels einer Endezu-Ende-Verschlüsselung und kann ferner insbesondere über eine serielle oder eine paketorientierte Kommunikationsverbindung erfolgen, insbesondere über ein Bussystem wie CAN oder Ethernet.
  • Vorteilhafterweise werden die einzelnen Prozesse im Zuge einer Konfiguration den jeweiligen Softwareüberwachungsmodulen zugewiesen. Beispielsweise kann diese Konfiguration durchgeführt werden, bevor die wenigstens eine Recheneinheit in Betrieb genommen wird. Besonders vorteilhaft kann diese Konfiguration bei Bedarf angepasst oder erweitert werden, d.h. Prozesse können zweckmäßigerweise auch anderen Softwareüberwachungsmodulen zugewiesen werden, insbesondere dynamisch während der Laufzeit der wenigstens einen Recheneinheit. Ferner können somit auch neue Prozesse, die beispielsweise im Zuge eines Updates neu eingebracht wurden, Softwareüberwachungsmodulen zugewiesen werden.
  • Eine erfindungsgemäße Recheneinheit bzw. ein erfindungsgemäßes System aus wenigstens zwei derartigen Recheneinheiten ist, insbesondere programmtechnisch, dazu eingerichtet, ein erfindungsgemäßes Verfahren durchzuführen. Besonders bevorzugt ist die Recheneinheit bzw. das System aus Recheneinheiten in ein Steuergerät eines Kraftfahrzeugs implementiert.
  • Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.
  • Die Erfindung ist anhand von Ausführungsbeispielen in der Zeichnung schematisch dargestellt und wird im Folgenden unter Bezugnahme auf die Zeichnung beschrieben.
  • Figurenliste
    • 1 bis 3 zeigen jeweils schematisch ein Steuergerät eines Fahrzeugs in einem Blockschaltbild, das dazu eingerichtet ist, eine bevorzugte Ausführungsform eines erfindungsgemäßen Verfahrens durchzuführen.
  • Ausführungsform(en) der Erfindung
  • In 1 ist ein Steuergerät eines Fahrzeugs, beispielsweise für autonoms Fahren, schematisch in einem Blockschaltbild dargestellt und mit 100 bezeichnet.
  • Das Steuergerät 100 ist als ein System aus mehreren Recheneinheiten 110, 120, 130 ausgebildet. Die Recheneinheit 110 ist beispielsweise als ein Mikrocontroller ausgebildet, welcher einen Multicore-Prozessor aus einer Vielzahl von Prozessorkernen sowie weitere Peripherie umfasst, z.B. Analog-Digital-Wandler (ADC), Digital-Analog-Wandler (DAC) sowie Ein/-Ausgänge (E/A). Die Recheneinheiten 120 und 130 sind jeweils als Mikroprozessoren mit einer Vielzahl von Prozessorkernen ausgebildet.
  • Ferner umfasst das Steuergerät einen Netzwerkverteiler bzw. Netzwerkswitch 150. Über ein Kommunikationssystem 101, beispielsweise Ethernet, sind die Recheneinheiten 110, 120, 130 an den Netzwerkverteiler 150 angebunden und stehen somit miteinander in Kommunikationsverbindung. Über den Netzwerkverteiler 150 ist das Steuergerät 100 ferner an einen Kommunikationsbus 103 des Kraftfahrzeugs, z.B. CAN oder Ethernet, angebunden, und steht somit mit weiteren Steuergeräten des Kraftfahrzeugs in Kommunikationsverbindung.
  • Ferner ist eine Vielzahl von Sensoren 161, 162 und Aktoren 171, 172 an den Netzwerkverteiler 150 angebunden, beispielsweise ebenfalls über ein Ethernet-Kommunikationssystem 102. Das Steuergerät 100 kann somit Sensorwerte von Motorsensoren 161, 162 (beispielsweise Drehzahlsensor, Lambdasensor etc.) empfangen und über die Aktoren 171, 172 (z.B. Injektoren, Zündkerzen, Zylinderklappen etc.) den Motor ansteuern.
  • Zur Verarbeitung der Sensorwerte der Sensoren 161, 162 und zum Erstellen von Ansteuerbefehlen für die Aktoren 171, 172 basierend auf diesen Sensorwerten werden in den Recheneinheiten 110, 120 ,130 entsprechend Prozesse ausgeführt, welche sicherheitskritischer und nicht-sicherheitskritischer Natur sein können.
  • Es ist von Bedeutung, Fehler der einzelnen Recheneinheiten 110, 120, 130 bzw. der von den Recheneinheiten 110, 120, 130 ausgeführten Prozesse frühzeitig zu erkennen, um rechtzeitig auf derartige Fehler reagieren und diese beheben zu können.
  • Das Steuergerät 100 ist daher dazu eingerichtet, eine bevorzugte Ausführungsform eines erfindungsgemäßen Verfahrens durchzuführen bzw. gemäß einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens überwacht zu werden.
  • Zu diesem Zweck ist ein System aus Überwachungsmodulen bzw. Watchdogs vorgesehen, die in verschiedene Hierarchieebenen eingeteilt sind. Dabei ist in dem Steuergerät 100 ein Hardwareüberwachungsmodul 140 bzw. ein Hardware-Watchdog vorgesehen, welcher über die Ethernet Verbindung 101 an den Netzwerkverteiler 150 angebunden und mit den Recheneinheiten 110, 120, 130 in Kommunikationsverbindung steht.
  • Ferner wird in jeder der Recheneinheiten 110, 120, 130 jeweils wenigstens ein Softwareüberwachungsmodul bzw. Software-Watchdog ausgeführt. Das Hardwareüberwachungsmodul 140 bzw. der Hardware-Watchdog ist dabei als ein oberstes Überwachungsmodul in einer obersten Hierarchieebene vorgesehen. Die in den Recheneinheiten 110, 120, 130 implementierten Softwareüberwachungsmodule bzw. Software-Watchdogs sind diesem Hardware-Watchdog 140 untergeordnet. Jedes der Softwareüberwachungsmodule überwacht jeweils wenigstens einen ihm zugewiesenen Prozess und wird dabei jeweils von einem übergeordneten Überwachungsmodul einer übergeordneten Hierarchieebene überwacht.
  • Eine bevorzugte Ausführungsform des erfindungsgemäßen Verfahrens wird nachfolgend in Bezug auf 2 erläutert, in welcher Teile des Steuergeräts aus 1 schematisch in einem Blockschaltbild dargestellt sind. Identische Bezugszeichen in den Figuren beschreiben dabei gleiche oder baugleiche Elemente.
  • Wie in 2 dargestellt ist, wird in den Recheneinheiten 110, 120, 130 eine Vielzahl von Softwareüberwachungsmodulen 111, 122, 126, 132, 136 ausgeführt.
  • Die Recheneinheit 110 ist als eine Sicherheitsrecheneinheit ausgebildet, wobei das in der Recheneinheit 110 ausgeführte Softwareüberwachungsmodul 111 in einer insgesamt zweithöchsten Hierarchieebene angesiedelt und nur dem Hardwareüberwachungsmodul 140 in der obersten Hierarchieebene untergeordnet ist.
  • Das Softwareüberwachungsmodul 111 überwacht ihm zugewiesene, in der Recheneinheit 110 ausgeführte Prozesse 112, 113, 114 und ferner die Softwareüberwachungsmodule 122 und 132. Ferner wird das Softwareüberwachungsmodul 111 selbst von dem Hardwareüberwachungsmodul 140 überwacht.
  • In der Recheneinheit 120 sind zwei unabhängige, voneinander logisch getrennte Domänen 121 und 125 vorgesehen. In einer zentralen Domäne (sog. „Housekeeping Domäne“) 121 werden Prozesse 123 und 124 ausgeführt, die beispielsweise nicht-sicherheitskritisch und statisch sind, und in einer Anwendungsdomäne 125 werden Prozesse 127, 128, 129 ausgeführt, die beispielsweise sicherheitskritisch und dynamisch sind.
  • In der Domäne 121 ist das Softwareüberwachungsmodul 122 vorgesehen, welches die in dieser Domäne 121 ablaufenden Prozesse 123, 124 überwacht. Das in der Anwendungsdomäne 125 vorgesehene Softwareüberwachungsmodul 126 überwacht die dort ablaufenden Prozesse 127, 128, 129.
  • Ferner ist das Softwareüberwachungsmodul 122 der zentralen Domäne 121 in einer dritthöchsten Hierarchieebene vorgesehen und somit dem Softwareüberwachungsmodul 111 der Sicherheitsrecheneinheit 110 untergeordnet und wird von diesem überwacht.
  • Weiterhin überwacht das Softwareüberwachungsmodul 122 der zentralen Domäne 121 das Softwareüberwachungsmodul 126 in der Anwendungsdomäne 125, welches in einer vierthöchsten Hierarchieebene vorgesehen und dem Softwareüberwachungsmodul 122 somit untergeordnet ist.
  • Auf entsprechende Weise sind auch in der Recheneinheit 130 zwei voneinander logisch getrennte Domänen 131 und 135 vorgesehen. Auch dort werden in einer zentralen Domäne 131 Prozesse 133 und 134 ausgeführt und von dem Softwareüberwachungsmodul 132 überwacht. Auch dieses Softwareüberwachungsmodul 132 ist in der dritthöchsten Hierarchieebene vorgesehen und wird von dem Softwareüberwachungsmodul 111 der Sicherheitsrecheneinheit 110 überwacht.
  • In einer Anwendungsdomäne 135 werden Prozesse 137, 138, 139 ausgeführt und von dem Softwareüberwachungsmodul 136 überwacht. Das Softwareüberwachungsmodul 136 ist wiederum in der vierthöchsten Hierarchieebene vorgesehen und wird von dem übergeordneten Softwareüberwachungsmodul 132 der dritthöchsten Hierarchieebene überwacht.
  • Die einzelnen Softwareüberwachungsmodule überwachen die jeweiligen ihnen zugewiesenen Prozesse und Softwareüberwachungsmodule jeweils beispielsweise mittels einer Frage-/Antwort-Kommunikation und insbesondere mittels einer Gut-/Schlecht-Prüfung.
  • Wenn nun eines der Softwareüberwachungsmodule einen Fehler eines Prozesses oder eines Softwareüberwachungsmoduls erkennt, wird eine vorgegebene Fehlerreaktion durchgeführt, beispielsweise ein Neustart des Prozesses.
  • In 3 ist gemäß einer weiteren bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens ein Teil eines Steuergeräts schematisch in einem Blockschaltbild dargestellt.
  • In diesem Beispiel von 3 ist eine neben dem Mikrocontroller 110 eine weitere beispielsweise als Mikroprozessor ausgebildete Recheneinheit 200 vorgesehen, welche alternativ oder zusätzlich zu den als Mikroprozessor ausgebildeten Recheneinheiten 120, 130 aus den 1 und 2 vorgesehen sein kann.
  • Auch die Recheneinheit 200 ist in mehrere Domänen 210, 220, 230, 240 unterteilt. In einer zentralen Domäne 210 ist ein Software-Watchdog bzw. Softwareüberwachungsmodul 211 vorgesehen, welches in einer dritthöchsten Hierarchieebene vorgesehen ist und von dem ihm übergeordneten Softwareüberwachungsmodul 111 der Sicherheitsrecheneinheit 110 überwacht wird.
  • In den Domänen 220, 230 und 240 werden jeweils unabhängig voneinander Prozesse 222, 223 bzw. 232, 233 bzw. 242, 243 ausgeführt. In jeder Domäne 220, 230, 240 ist ferner jeweils ein Softwareüberwachungsmodul 221, 231, 241 zur Überwachung der in der jeweiligen Domäne ablaufenden Prozesse vorgesehen. Diese Softwareüberwachungsmodule 221, 231, 241 sind beispielsweise jeweils als Slaves implementiert und in einer vierthöchsten Hierarchieebene vorgesehen. Somit sind die Softwareüberwachungsmodule 221, 231, 241 dem Softwareüberwachungsmodul 211 der dritthöchsten Hierarchieebene, welches beispielsweise als Master vorgesehen ist, untergeordnet und werden von diesem überwacht.
  • 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 102009038434 A1 [0004]
    • CN 104636212 A [0004]
    • CN 104199746 A [0004]

Claims (11)

  1. Verfahren zum Überwachen wenigstens einer Recheneinheit (110, 120, 130), in welcher eine Vielzahl von Prozessen (112, 113, 114, 123, 124, 127, 128, 129, 133, 134, 137, 138, 139) ausgeführt wird, mittels eines Systems aus Überwachungsmodulen (140, 111, 122, 126, 132, 136), die in verschiedene Hierarchieebenen eingeteilt sind, wobei in einer obersten Hierarchieebene ein oberstes Überwachungsmodul (140) als ein Hardwareüberwachungsmodul vorgesehen ist, wobei in wenigstens einer der obersten Hierarchieebene untergeordneten Hierarchieebene jeweils wenigstens ein Softwareüberwachungsmodul (111, 122, 126, 132, 136) vorgesehen ist, wobei jedes Softwareüberwachungsmodul (111, 122, 126, 132, 136) jeweils wenigstens einen zugewiesenen Prozess (112, 113, 114, 123, 124, 127, 128, 129, 133, 134, 137, 138, 139) überwacht und wobei jedes Softwareüberwachungsmodul (111, 122, 126, 132, 136) einer Hierarchieebene von einem übergeordneten Überwachungsmodul (140, 111, 122, 132) einer übergeordneten Hierarchieebene überwacht wird.
  2. Verfahren nach Anspruch 1, wobei jedes Softwareüberwachungsmodul (111, 122, 126, 132, 136) zur Überwachung des jeweiligen wenigstens einen zugewiesenen Prozesses (112, 113, 114, 123, 124, 127, 128, 129, 133, 134, 137, 138, 139) eine Frage-/Antwort-Kommunikation und/oder eine Gut-/Schlecht-Prüfung durchführt.
  3. Verfahren nach Anspruch 1 oder 2, wobei jedes Softwareüberwachungsmodul (111, 122, 126, 132, 136) den jeweiligen wenigstens einen zugewiesenen Prozess (112, 113, 114, 123, 124, 127, 128, 129, 133, 134, 137, 138, 139) im Hinblick auf Laufzeit, Lebendigkeit und/oder korrekte Ausführung hin überwacht.
  4. Verfahren nach einem der vorstehenden Ansprüche, wobei jedes Softwareüberwachungsmodul (111, 122, 126, 132, 136) bei einem erkannten Fehler des jeweiligen wenigstens einen zugewiesenen Prozesses (112, 113, 114, 123, 124, 127, 128, 129, 133, 134, 137, 138, 139) eine vorgegebene Maßnahme durchführt.
  5. Verfahren nach Anspruch 4, wobei als vorgegebene Maßnahme eine Fehlerreaktion durch das jeweilige Softwareüberwachungsmodul (111, 122, 126, 132, 136) durchgeführt wird.
  6. Verfahren nach Anspruch 4 oder 5, wobei als vorgegebene Maßnahme der erkannte Fehler von dem jeweiligen Softwareüberwachungsmodul (111, 122, 126, 132, 136) an ein Fehlermodul übermittelt wird.
  7. Verfahren nach einem der vorstehenden Ansprüche, wobei jedes Softwareüberwachungsmodul (111, 122, 126, 132, 136) einer Hierarchieebene durch eine Frage-/Antwort-Kommunikation und/oder eine Gut-/Schlecht-Prüfung von dem jeweiligen übergeordneten Überwachungsmodul (140, 111, 122, 132) der übergeordneten Hierarchieebene überwacht wird.
  8. Verfahren nach einem der vorstehenden Ansprüche, wobei die einzelnen Prozesse (112, 113, 114, 123, 124, 127, 128, 129, 133, 134, 137, 138, 139) im Zuge einer Konfiguration den jeweiligen Softwareüberwachungsmodulen (111, 122, 126, 132, 136) zugewiesen werden.
  9. Verfahren nach einem der vorstehenden Ansprüche, wobei Prozesse (123, 124, 127, 128, 129, 133, 134, 137, 138, 139) in der wenigstens einen Recheneinheit (120, 130) jeweils in voneinander unabhängigen Domänen (121, 125, 131, 135) ausgeführt werden.
  10. Verfahren nach einem der vorstehenden Ansprüche, wobei ein System aus wenigstens zwei Recheneinheiten (110, 120, 130) überwacht wird, die miteinander in Kommunikationsverbindung stehen.
  11. Recheneinheit oder System aus wenigstens zwei Recheneinheiten (110, 120, 130), mit Mitteln, um ein Verfahren nach einem der vorstehenden Ansprüche durchzuführen.
DE102018210733.5A 2018-06-29 2018-06-29 Verfahren zum Überwachen wenigstens einer Recheneinheit Pending DE102018210733A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102018210733.5A DE102018210733A1 (de) 2018-06-29 2018-06-29 Verfahren zum Überwachen wenigstens einer Recheneinheit

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102018210733.5A DE102018210733A1 (de) 2018-06-29 2018-06-29 Verfahren zum Überwachen wenigstens einer Recheneinheit

Publications (1)

Publication Number Publication Date
DE102018210733A1 true DE102018210733A1 (de) 2020-01-02

Family

ID=68886040

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102018210733.5A Pending DE102018210733A1 (de) 2018-06-29 2018-06-29 Verfahren zum Überwachen wenigstens einer Recheneinheit

Country Status (1)

Country Link
DE (1) DE102018210733A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102020209228A1 (de) 2020-07-22 2022-01-27 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Überwachen wenigstens einer Recheneinheit

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009038434A1 (de) 2009-08-21 2011-02-24 Delphi Delco Electronics Europe Gmbh Prozessoranlage zur Steuerung mehrerer Funktionskomponenten eines Fahrzeugs
CN104199746A (zh) 2014-09-01 2014-12-10 中国东方电气集团有限公司 一种多任务软件看门狗的实现方法
CN104636212A (zh) 2014-12-29 2015-05-20 漳州科能电器有限公司 一种嵌入式操作***看门狗实现方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009038434A1 (de) 2009-08-21 2011-02-24 Delphi Delco Electronics Europe Gmbh Prozessoranlage zur Steuerung mehrerer Funktionskomponenten eines Fahrzeugs
CN104199746A (zh) 2014-09-01 2014-12-10 中国东方电气集团有限公司 一种多任务软件看门狗的实现方法
CN104636212A (zh) 2014-12-29 2015-05-20 漳州科能电器有限公司 一种嵌入式操作***看门狗实现方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102020209228A1 (de) 2020-07-22 2022-01-27 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Überwachen wenigstens einer Recheneinheit

Similar Documents

Publication Publication Date Title
EP2641176B1 (de) Mikroprozessorsystem mit fehlertoleranter architektur
DE60019038T2 (de) Intelligente Fehlerverwaltung
DE112018002176T5 (de) Anormalitätsbestimmungsvorrichtung, Anormalitätsbestimmungsverfahren und Anormalitätsbestimmungsprogramm
DE102014201682A1 (de) Verfahren zur Koexistenz von Software mit verschiedenen Sicherheitsstufen in einem Multicore-Prozessorsystem
EP3864547B1 (de) Verfahren zur detektion sicherheitsrelevanter datenflüsse
CN111090915B (zh) 自动驾驶仿真方法、装置和存储介质
EP1639465B1 (de) Verfahren zur überwachung des programmlaufs in einem mikro-computer
DE102017204745A1 (de) Architektur und Vorrichtung für eine fortschrittliche Arbitration in integrierten Steuerungen
DE102017201032A1 (de) Redundante Prozessorarchitektur
DE10357118A1 (de) Laden von Software-Modulen
DE102012207215A1 (de) Verfahren und Vorrichtung zur Überwachung von Funktionen eines Rechnersystems, vorzugsweise eines Motorsteuersystems eines Kraftfahrzeuges
DE102005037403A1 (de) Verfahren zum Überprüfen der Funktionsfähigkeit der Arithmetik-Logik-Einheit (ALU) eines Steuermoduls
DE102007006614A1 (de) Anwendung einer verteilten Diagnosearchitektur in AUTOSAR
DE102015202326A1 (de) Verfahren zum Betreiben einer Datenverarbeitungseinheit eines Fahrerassistenzsystems und Datenverarbeitungseinheit
DE102019201607A1 (de) Steuerungssystem für ein Kraftfahrzeug
EP2203795B1 (de) Fahrzeug-steuereinheit mit einem versorgungspannungsüberwachten mikrocontroller sowie zugehöriges verfahren
DE102018210733A1 (de) Verfahren zum Überwachen wenigstens einer Recheneinheit
DE102013021231A1 (de) Verfahren zum Betrieb eines Assistenzsystems eines Fahrzeugs und Fahrzeugsteuergerät
EP3566398B1 (de) Verfahren und halbleiterschaltkreis zum schützen eines betriebssystems eines sicherheitssystems eines fahrzeugs
DE102006006843B4 (de) Verfahren zum Antworten auf einen Steuermodulausfall
DE102011007467A1 (de) Mehrkernige integrierte Mikroprozessorschaltung mit Prüfeinrichtung, Prüfverfahren und Verwendung
DE102019111564A1 (de) Verfahren und system zum konfigurieren von filterobjekten für eine controller area network-steuerung
DE10328059A1 (de) Verfahren und Vorrichtung zur Überwachung eines verteilten Systems
EP3705993B1 (de) System und verfahren zum auffinden und identifizieren von rechenknoten in einem netzwerk
DE102009002898A1 (de) Verfahren zur Aktualisierung eines Steuergeräts eines Fahrzeugs