DE102005009955A1

DE102005009955A1 - Verfahren und Vorrichtung zum Überwachen eines Ablaufs einer Rechenvorrichtung

Info

Publication number: DE102005009955A1
Application number: DE200510009955
Authority: DE
Inventors: Thomas Dr. Stauner; Astrid SCHRÖDER; Martin Thiede
Original assignee: Bayerische Motoren Werke AG
Current assignee: Bayerische Motoren Werke AG
Priority date: 2005-03-04
Filing date: 2005-03-04
Publication date: 2006-09-07

Abstract

Es werden ein Verfahren und eine Vorrichtung zum Überwachen eines Ablaufs einer Rechenvorrichtung (1), insbesondere in einem Kraftfahrzeug, beschrieben, in der ein Überwachungsmittel (10) mit zumindest einem Sensormittel (11) vorgesehen ist, das dazu eingerichtet ist, ein Ereignis der Rechenvorrichtung (1) zu erkennen, und zumindest einem Erkennungsmittel (12), das dazu eingerichtet ist, das Verhalten des von dem Sensormittel (11) erkannten Ereignisses zu verfolgen, wobei das Überwachungsmittel (10) in ein Ablaufmuster (15) auf der Rechenvorrichtung (1) integriert ist und wobei das Überwachungsmittel (10) dazu eingerichtet ist, das Ablaufmuster (15) zu dessen Laufzeit zu überwachen, indem durch das Überwachungsmittel (10) erkannte Ereignisse (E1, E2) auf eine Abweichung von einem spezifizierten Zustand oder einer spezifizierten Zustandsänderung überprüft werden.

Description

Die Erfindung betrifft ein Verfahren und eine Vorrichtung zum Überwachen eines Ablaufs einer Rechenvorrichtung, insbesondere in einem Kraftfahrzeug.
Das Testen und Auffinden von Fehlern von Computersoftware oder Ablaufmustern ist zur Sicherstellung deren Qualität notwendig. Testverfahren sind langwierig und häufig mit manuellen Schritten verbunden. Das korrekte Verhalten einer Rechenvorrichtung wird im wesentlichen durch das Verhalten des darauf befindlichen Ablaufmusters bestimmt. Es ist deshalb ein grundsätzliches Bestreben, den Ablauf einer Rechenvorrichtung und damit den Ablauf eines Ablaufmusters korrekt sicherzustellen. Der Begriff „korrekt" ist in dieser Beschreibung so zu verstehen, dass das tatsächliche Verhalten der Rechenvorrichtung dem in der Theorie spezifizierten Verhalten entspricht.

Bislang werden die Korrektheit einer Rechenvorrichtung und der darauf ablaufenden Software in erster Linie durch Tests, gelegentlich auch durch formale Verifikation oder sogenannter Konstruktion (z.B. modellbasierte Generierung, Ascet), sichergestellt. Unter dem Begriff der formalen Verifikation versteht man den Nachweis der korrekten Funktion eines Ablaufmusters unter vorgegebenen Annahmen. Abweichungen von vorgegebenen Ablaufmustern, d.h. fehlerhafte Zustände einer Software, können momentan nur begrenzt erkannt werden. Insbesondere ist eine Erkennung von Fehlern während des Betriebs zur Laufzeit der Rechenvorrichtung in der Regel nicht möglich. Ebenso ist eine umfassende Prüfung des Verhaltens bzw. der Zustände eines Ablaufmusters, wie dies beispielsweise in einer Spezifikation des Verhaltens der Rechenvorrichtung niedergelegt ist, im Betrieb der Rechenvorrichtung nicht möglich.

Dies gilt umso mehr, wenn die Rechenvorrichtung Bestandteil eines Kraftfahrzeuges ist, da dort sehr beschränkte Hardware-Ressourcen zur Verfügung stehen und gleichzeitig die Echtzeitanforderungen besonders hoch sind. Dies gilt beispielsweise bei sicherheitsrelevanten Funktionen, wie einer elektronisch gesteuerten Aktivlenkung oder einem Antiblockiersystem usw.

Es besteht somit das grundsätzliche Problem, dass Fehler im Ablauf einer Rechenvorrichtung im Rahmen der durchgeführten Tests unerkannt bleiben und erstmalig im Betrieb der Rechenvorrichtung auftreten. Weist eine Rechenvorrichtung eine hohe Komplexität mit einer hohen Anzahl an einzelnen Rechnern auf, so ist eine formale Verifikation aufgrund des Aufwands in der Praxis nicht praktikabel.

Allgemein sind zum Überwachen eines Ablaufs einer Rechenvorrichtung auch Redundanzsysteme bekannt, bei denen eine gegenseitige Überwachung von zwei Rechnern der Rechenvorrichtung erfolgt. Dies bedeutet, dass die Ablaufmuster in jedem der Rechner in identischer Form vorhanden sind. Aufgrund der damit verbundenen hohen Kosten, ist eine derartige Vorgehensweise bei komplexen Rechenvorrichtungen, wie z.B. einem Bussystem mit einer Vielzahl an Steuergeräten in einem Kraftfahrzeug, nicht geeignet.

Zur Sicherstellung der Korrektheit eines Ablaufmusters in einer Rechenvorrichtung schlägt die WO 92/14202 vor, das Ablaufmuster nicht auszuführen, sondern die Programmausführung zu simulieren, wobei gleichzeitig eine Vielzahl an Simulationen ablaufen. Die Überprüfung auf Fehler und der Test finden somit vor dem eigentlichen Betrieb der Rechenvorrichtung statt. In dem vorgeschlagenen Verfahren werden kritische Eingangsvariablen für das Ablaufmuster definiert und Eingangswerte für diese Variablen werden festgelegt. Schließlich werden die vorverarbeiteten Eingangsvariablen einem Vergleich mit korrekt laufenden Ablaufmustern unterzogen. Der Nachteil dieser Vorgehensweise besteht darin, dass Fehler bei der Überprüfung des Ablaufmusters übersehen werden können, welche dann erst während des Betriebs der Rechenvorrichtung zu Tage treten.

Die Aufgabe der vorliegenden Erfindung besteht darin, ein Verfahren und eine Vorrichtung zum Überwachen eines Ablaufs einer Rechenvorrichtung anzugeben, mit welchen auch unerwartete Fehler während des Ablaufs einer Rechenvorrichtung entdeckt und behandelt werden können, so dass die Rechenvorrichtung keinen undefinierten Zustand annehmen kann.

Diese Aufgabe wird mit einem Verfahren gemäß den Merkmalen des Patentanspruches 1, mit einer Vorrichtung gemäß den Merkmalen des Patentanspruches 12 sowie mit einem Computerprogrammprodukt gemäß den Merkmalen des Patentanspruches 18 gelöst.

Vorteilhafte Ausgestaltungen ergeben sich jeweils aus den abhängigen Patentansprüchen.

Der Grundgedanke der vorliegenden Erfindung besteht darin, den Ablauf einer Rechenvorrichtung, insbesondere in einem Kraftfahrzeug, dadurch zu überwachen, dass die in der Spezifikation eines Ablaufmusters enthaltenen Informationen in geeigneter Weise zur Überwachung des Ablaufmusters in dieses integriert werden.

Das Verfahren zum Überwachen eines Ablaufs der Rechenvorrichtung ist durch die folgende Schritte gekennzeichnet: Es wird zunächst ein Ablaufmuster in der Rechenvorrichtung vorgesehen. Es ist ferner ein Überwachungsmittel vorgesehen, mit zumindest einem Sensormittel, das dazu eingerichtet ist, ein Ereignis der Rechenvorrichtung zu erkennen, und mit zumindest einem Erkennungsmittel, das dazu eingerichtet ist, das Verhalten der Rechenvorrichtung auf das von dem Sensormittel erkannte Ereignis zu verfolgen. In einem weiteren Schritt wird das Überwachungsmittel in das Ablaufmuster integriert. Es erfolgt eine Überwachung des Ablaufmusters zu dessen Laufzeit, indem durch das Überwachungsmittel erkannte Ereignisse auf eine Abweichung von einem spezifizierten Zustand oder einer spezifizierten Zustandsänderung überprüft werden.

Das Überwachungsmittel stellt hierbei kein Hardware-realisiertes Element der Rechenvorrichtung dar, sondern es handelt sich vielmehr um ein Computerprogrammprodukt, welches in das als Software ausgeführte Ablaufmuster in geeigneter Weise integriert ist. Demgemäß ist das Sensormittel ein „Software-Sensor" und das Erkennungsmittel ist ebenfalls softwaremäßig realisiert. Diese Vorgehensweise ermöglicht es, das Verhalten des Ablaufmusters zu dessen Laufzeit im Betrieb zu überwachen. Es ist insbesondere möglich, ein von der Spezifikation abweichendes Verhalten zu detektieren und geeignet zu behandeln.

Dabei wird als Annahme zugrunde gelegt, dass die Spezifikation derart festgelegt ist, dass aufgrund dieser das Auftreten eines Fehlers, d.h. eines falschen oder nicht spezifizierten Ablaufmusters, in der Rechenvorrichtung nicht möglich ist.

Durch die Überwachung des Ablaufmusters zur Laufzeit können Fehler erkannt werden, die beispielsweise in vorangegangenen Tests nicht erkannt wurden. Die Betriebssicher heit des Ablaufmusters bzw. der Rechenvorrichtung wird dadurch erhöht. Ein weiterer Vorteil besteht darin, dass im Vorfeld durchgeführte Tests als Nebenprodukt unterstützt werden. Das Testsystem muss dabei lediglich die Eingangsdaten der Rechenvorrichtung bereitstellen, wobei die durch die Rechenvorrichtung ermittelten Ausgangsdaten von dem Überwachungsmittel überprüft werden. Das Verfahren kann zum Verhindern von Fehlern sowie zur Verbesserung der Diagnose, im Falle auftretender Fehler, eingesetzt werden.

Gemäß einer zweckmäßigen Ausgestaltung ist der Schritt des Erzeugens des Überwachungsmittels vorgesehen, in dem ein spezifiziertes Verhalten des Ablaufmusters mit zumindest einem Ereignis und dem zumindest einen Ereignis zugeordneten Zuständen und Zustandsänderungen festgelegt wird, wobei das spezifizierte Verhalten in einen Programmcode umgesetzt wird. Mit anderen Worten sieht dieser Schritt vor, dass das z.B. in textlicher Form vorliegende spezifizierte Verhalten des Ablaufmusters in eine durch die Rechenvorrichtung lesbare und verarbeitbare Form umgesetzt wird.

Das Erzeugen des Überwachungsmittels kann folgende Schritte umfassen: Zunächst wird die Spezifikation des Verhaltens in einen Zustandsautomaten umgewandelt, der zumindest eines der erkannten Ereignisse verarbeiten kann. Dann werden die in dem Zustandsautomaten definierten Zustände und Zustandsänderungen in den Programmcode umgewandelt. Die Erzeugung des Überwachungsmittels kann unter Verwendung geeigneter Rechenmittel und Rechenalgorithmen automatisch erfolgen. Dies gilt insbesondere für das Überführen der Zustandsautomaten in den Programmcode.

In einer weiteren Ausgestaltung ist in dem Zustandsautomat, der ein von dem Sensormittel erkanntes Ereignis verarbeitet, zumindest eine Variable definiert, die bei der Umwandlung der in dem Zustandsautomaten definierten Zustände und Zustandsänderungen in den Programmcode berücksichtigt werden. Dies können beispielsweise zeitliche Bedingungen an Aktionen sowie Bedingungen über Werte bestimmter Attribute sein.

Bei der Erzeugung des Überwachungsmittels besteht die Idee der Erfindung somit darin, die z.B. im Fließtext verfasste Spezifikation des Verhaltens einer Rechenvorrichtung derart zu formalisieren, dass sie als Grundlage für die Generierung des Überwachungsmittels dienen kann. Die zur Erstellung der Spezifikation verwendete Formatisierung oder Programmiersprache umfasst beispielsweise temporale Logiken oder die Verwendung von MSCs (Message Seqence Charts). Bevorzugt werden sogenannte endliche Automaten verwendet, wie z.B. Timed Security Automata (TSA), die eine Variante der endlichen Automaten darstellen. Endliche Automaten eignen sich besonders zur Spezifikation von Abläufen innerhalb einer Rechenvorrichtung. Mit einem endlichen Automaten kann das Verhalten der Rechenvorrichtung beschrieben werden. Durch die Konstruktion des Zustandsautomaten wird damit formal spezifiziert, wie sich die Rechenvorrichtung bzw. das in der Rechenvorrichtung ablaufende Ablaufmuster zu verhalten hat.

In einer weiteren Ausgestaltung des erfindungsgemäßen Verfahrens ist vorgesehen, bei der Umwandlung des Zustandsautomaten in den Programmcode zumindest einen weiteren Transformationsschritt vorzunehmen, in dem eine formale Spezifikation erstellt wird, wie sich das zu überwachende Ablaufmuster zu verhalten hat. Diese Spezifikation stellt einen Zwischenschritt, ausgehend von der ursprünglichen Spezifikation in Form eines endlichen Automaten, dar. Die Transformation kann dazu verwendet werden, das Überwachungsmittel besonders einfach automatisch zu generieren.

Gemäß einer weiteren bevorzugten Ausgestaltung umfasst der Schritt des Integrierens des Überwachungsmittels in das Ablaufmuster das Einbringen des Programmcodes in einen Ablaufmusterprogrammcode. Nachdem in dem Schritt des Erzeugens des Überwachungsmittels das spezifizierte Verhalten der Rechenvorrichtung in eine durch die Rechenvorrichtung lesbare Form in Form eines Computerprogrammprodukts gebracht wurde, wird in dem Schritt des Integrierens des Überwachungsmittels dieser vorliegende Programmcode in den Programmcode des Ablaufmusters integriert. Die Integration kann dabei das Hinzufügen zusätzlicher Codezeilen in den Ablaufmusterprogrammcode umfassen. Die Integration kann auch das Vorsehen zusätzlicher Objekte oder Module umfassen. Es ist auch eine Kombination der genannten Möglichkeiten denkbar.

Gemäß einer weiteren Ausgestaltung des erfindungsgemäßen Verfahrens wird beim Feststellen einer Abweichung von einem spezifizierten Zustand oder einer spezifizierten Zustandsänderung durch das Überwachungsmittel eine, insbesondere in der Rechenvorrichtung oder in dem Ablaufmuster, definierte Reaktion eingeleitet. Die Reaktion kann in der Signalisierung einer Abweichung von der Spezifikation, in dem Speichern des Zustands in einem in der Rechenvorrichtung vorgesehenen Speicher oder dem Initiieren einer vordefinierten Routine des Ablaufmusters, bestehen. Konkret wird die Abweichung durch den Erkenner des Überwachungsmittels festgestellt, der anhand des Verhaltens auf ein von dem Sensormittel erkannten Ereignisses hin ein spezifiziertes von einem nicht spezifizierten Verhalten unterscheiden kann.

Zweckmäßigerweise erfolgt bei der Detektion eines Ereignisses durch das Überwachungsmittel, genauer das Sensormittel des Überwachungsmittels, ein Funktionsaufruf in dem Ablaufmusterprogrammcode. Die Integration des Überwachungsmittels in dem Ablaufmuster schafft somit die Möglichkeit, an vordefinierten Stellen in dem Ablaufmuster eine Überprüfung dessen Verhaltens durchzuführen und bei einer Abweichung von einem spezifizierten Verhalten eine vorgegebene Funktion, die beispielsweise die Signalisierung, das Speichern von Variablen oder ähnliches beinhalten kann, aufzurufen.

Gemäß einer Variante ist das Überwachungsmittel in einem Rechner einer Mehrzahl an Rechnern vorgesehen, und dieser Rechner der Mehrzahl an Rechnern der Rechenvorrichtung wird auf sein Ablaufmuster hin überwacht. Gemäß einer anderen Variante ist das Überwachungsmittel in zumindest zwei Rechnern einer Mehrzahl an Rechnern der Rechenvorrichtung vorgesehen, und es wird die Interkommunikation zwischen den Rechnern der Rechenvorrichtung überwacht. Welche der beiden Varianten, gegebenenfalls in einer Kombination, gewählt wird, hängt von der Vorgehensweise der Integration des Überwachungsmittels in das Ablaufmuster ab.

Mit der erfindungsgemäßen Vorrichtung sind die gleichen Vorteile verbunden, wie sie vorstehend in Verbindung mit dem Verfahren beschrieben wurden.

In der erfindungsgemäßen Vorrichtung zum Überwachen eines Ablaufs einer Rechenvorrichtung ist ein Überwachungsmittel mit zumindest einem Sensormittel vorgesehen, das dazu eingerichtet ist, ein Ereignis der Rechenvorrichtung zu erkennen. Es ist zumindest ein Erkennungsmittel vorgesehen, das dazu eingerichtet ist, das Verhalten der Rechenvorrichtung auf das von dem Sensormittel erkannte Ereignis hin zu verfolgen, wobei das Überwachungsmittel in ein Ablaufmuster auf der Rechenvorrichtung integriert ist und wobei das Überwachungsmittel dazu eingerichtet ist, das Ablaufmuster zu dessen Laufzeit zu überwachen, indem durch das Überwachungsmittel erkannte Ereignisse auf eine Abweichung von einem spezifizierten Zustand oder einer spezifizierten Zustandsänderung überprüft werden.

In einer Ausgestaltung weist die Rechenvorrichtung eine Mehrzahl an miteinander gekoppelten Rechnern auf, wobei das Überwachungsmittel in zumindest einem der Rechner angeordnet ist.

In einer anderen Ausgestaltung ist die Rechenvorrichtung ein Bussystem, insbesondere in einem Kraftfahrzeug, und die Rechner sind Busteilnehmer dieses Bussystems, die über eine Busleitung miteinander gekoppelt sind, über welche der Austausch von Nachrichten möglich ist. Ein Busteilnehmer stellt dabei ein Steuergerät eines Bussystems dar.

In einer weiteren Ausgestaltung ist das Überwachungsmittel ein Computerprogrammprodukt, das in das Ablaufmuster integriert ist.

Eine weitere Ausgestaltung sieht vor, dass das Überwachungsmittel zur Überwachung zumindest eines der Rechner der Rechenvorrichtung ausgebildet ist. Eine andere Ausgestaltung sieht vor, dass das Überwachungsmittel zur Überwachung der Interkommunikation zwischen zumindest zwei Rechnern der Rechenvorrichtung ausgebildet ist.

Die Erfindung beschreibt ferner ein Computerprogrammprodukt, bei dem in ein eine Recheneinheit steuerndes Ablaufmuster ein Überwachungsmittel integriert ist, das eine computerlesbare Spezifikation des Verhaltens des Ablaufmusters umfasst und das dazu eingerichtet ist, zur Laufzeit des Ablaufmusters ein von der Spezifikation abweichendes Verhalten festzustellen und eine Reaktion hierauf einzuleiten.

Die Erfindung wird nachfolgend anhand der Figuren näher erläutert. Es zeigen:
1 eine erfindungsgemäße Vorrichtung zum Überwachen eines Ablaufs einer Rechenvorrichtung,
2 eine erfindungsgemäße Rechenvorrichtung mit einer Mehrzahl an Rechnern, bei der die Vorrichtung zum Überwachen in einem der Rechner integriert ist,
3 eine weitere Rechenvorrichtung mit einer Mehrzahl an Rechnern, bei der die Vorrichtung zum Überwachen in mehreren Rechnern verteilt ist,
4 eine schematische Darstellung, aus der das der Vorrichtung zum Überwachen zugrunde liegende Prinzip hervorgeht,
5 eine schematische Darstellung, aus der das Erzeugen des Überwachungsmittels hervorgeht,
6 eine Spezifikation eines beispielhaften Ablaufmusters als Zustandsautomat,
7 eine schematische Darstellung eines Beispiels für den Datenfluss in einem MML-Programm,
8 einen Beispiel-MML-Code, der die Definition des Filter-Moduls aus 7 beschreibt,
9 eine schematische Darstellung des Vorgehens zur Generierung von Programmcode aus MML-Code, und
10 eine Tabelle über Anwendungsmöglichkeiten der Vorrichtung zur Überwachung einer Rechenvorrichtung.
1 zeigt zwei als Busteilnehmer ausgebildete Rechner 4 einer Rechenvorrichtung 1, wobei in der linken Hälfte eine Darstellung ohne das erfindungsgemäße Überwachungsmittel und in der rechten Hälfte eine Darstellung mit dem erfindungsgemäßen Überwachungsmittel gezeigt ist. In dem Rechner 4 sind in der Figur nicht näher dargestellte Komponenten vorgesehen, die es erlauben, ein Ablaufmuster 15 (Software) aufzubringen und zum Ablauf zu bringen. Der Rechner 4 verfügt über eine Mehrzahl an Datenein- und -ausgängen 7, über die Daten in den Rechner 4 und von dem Rechner 4 übertragen werden können. Die Funktionalität des Rechners ist im wesentlichen durch das Ablaufmuster 15 bestimmt. Das Ablaufmuster 15 empfängt die über die Datenein- und -ausgänge 7 gelieferten Informationen, bearbeitet diese gemäß dem Ablaufmuster 15 und stellt z. B. Ergebnisse an zumindest einigen der Datenein- und -ausgänge zur Verfügung. Der rei bungslose Ablauf des Ablaufmusters 15 ist im wesentlichen durch ein sorgfältiges Testen sichergestellt.
Um im Falle eines auftretenden Fehlers eine nicht definierte Fehlfunktion des Rechners 4 zu vermeiden, ist der im rechten Teil der 1 dargestellte Rechner 4 mit einem Überwachungsmittel 10 versehen, welches Sensoren 11 und Erkenner 12 aufweist. Die in 1 dargestellte Anzahl an vier Sensoren 11 und einem Erkenner 12 ist lediglich beispielhaft gewählt und könnte in der Praxis beliebig gewählt werden. Die schematische Darstellung zeigt dabei zwei Sensoren 11, die die über die Datenein- und -ausgänge 7 übertragenen Nachrichten filtern und dem Erkenner 12 zuführen. Des weiteren sind zwei Sensoren 11 im Inneren des Ablaufmusters 15 vorgesehen, welche bestimmte Ereignisse des Ablaufmusters 15 detektieren und die erkannten Ereignisse dem Erkenner 12 zuführen. Die Sensoren 11 und der Erkenner 12 sind in Form von Softwarecodeabschnitten ausgebildet, die in weiter unten beschriebener Weise an geeigneter Stelle in das Ablaufmuster 15 integriert sind.
In 2 ist eine Rechenvorrichtung 1 dargestellt, welche insgesamt vier Rechner 2, 3, 4, 5 aufweist, von denen der Rechner 4 in der oben beschriebenen Weise mit einem Überwachungsmittel 10 ausgestattet ist. Ein alternatives Ausgestaltungsbeispiel ist in 3 dargestellt, welches beispielhaft lediglich drei Rechner 2, 3, 4 umfasst, wobei das Überwachungsmittel 10 verteilt in sämtlichen der Rechner 2, 3, 4 angeordnet ist. In beiden Ausführungsbeispielen sind die Rechner über eine Busleitung 6 miteinander gekoppelt, über welche die Rechner Nachrichten austauschen können. Während das Ausführungsbeispiel gemäß 2 lediglich eine Überwachung des Verhaltens des Ablaufmusters des Rechners 4 vorsieht, kann mit der in 3 gezeigten Darstellung die Interkommunikation, d.h. das Zusammenspiel der einzelnen Komponenten, überwacht werden. Die Überwachung des Ablaufmusters der Rechenvorrichtung kann im Betrieb damit auf zweierlei Weise durchgeführt werden. Es ist eine Überwachung auf Komponentenebene möglich, innerhalb der das Überwachungsmittel einen Rechner der Rechenvorrichtung als Komponente der Rechenvorrichtung überwacht. Es ist ebenfalls eine Überwachung auf Systemebene möglich, auf der das Zusammenspiel der einzelnen Komponenten, d.h. Rechner der Rechenvorrichtung, überwacht wird.
In einer anderen, nicht dargestellten, Ausführungsform, könnte auch eine Kombination der beiden dargestellten Formen gemäß 2 und 3 vorgesehen sein.
Um das erfindungsgemäße Überwachungsmittel auf einem oder einer Mehrzahl an Rechnern integrieren zu können, ist folgende Vorgehensweise zweckmäßig. Voraussetzung ist eine Spezifikation, welche das gewünschte Verhalten einer Rechenvorrichtung, d.h. eines Ablaufmusters der Rechenvorrichtung, genau und detailliert beschreibt. Diese Spezifikation, oder Teile der Spezifikation, der zu überwachenden Rechenvorrichtung werden in einer geeigneten Sprache formalisiert. Aus der erstellten formalen Spezifikation wird das Überwachungsmittel vor Inbetriebnahme der Rechenvorrichtung generativ, d.h. automatisiert, erzeugt. Die relevanten Informationen aus der in formalisierter Form vorliegenden Spezifikation, werden dabei in das Überwachungsmittel eingearbeitet. Das die Spezifikation enthaltende Überwachungsmittel wird zusammen mit dem Ablaufmuster auf die Rechenvorrichtung, d.h. entweder einen oder eine Mehrzahl an Rechnern, aufgebracht. Das Überwachungsmittel ist so ausgebildet, dass dieses den üblichen Ablauf der Rechenvorrichtung nicht beeinflusst. Während des Betriebs der Rechenvorrichtung, bei welchem es sich beispielsweise um ein Bussystem in einem Kraftfahrzeug handeln kann, sammelt diese alle zur Erfüllung seiner Überwachungsaufgabe relevanten Informationen. Dies geschieht unter Verwendung der eingangs beschriebenen Softwaresensoren, die Teil des generierten Überwachungsmittels sind. Dabei können diese Softwaresensoren z.B. auch Messwerte von gegebenenfalls in der Rechenvorrichtung vorgesehenen Hardwaresensoren verarbeiten. Beim Feststellen einer Abweichung von der Spezifikation wird eine vordefinierte Reaktion eingeleitet. Diese kann in einer Signalisierung, einem Speichern (z.B. von Fehlerwerten oder Variableninhalten) oder dem Anstoßen einer beliebigen Reaktion bestehen. Letzteres könnte beispielsweise das Abschalten bzw. Neustarten der Rechenvorrichtung, das Verhindern der die Spezifikation verletzenden Aktion des Ablaufmusters oder dergleichen bestehen.
Der Ablauf der Überwachung geht aus 4 besser hervor. Aus dieser wird die logische Sicht der Abläufe verständlich. In der zu überwachenden Rechenvorrichtung 1 sind Softwaresensoren 11 angebracht, die entsprechend ihres Typs bestimmte Ereignisse in der Rechnervorrichtung 1 beobachten. Detektiert einer der Sensoren 11 ein relevantes Ereignis E1 bzw. E2, so leitet er dieses an den Erkenner 12 weiter, der anhand der eingehenden Ereignisse das Verhalten des zu überwachenden Systems verfolgt und Abweichun gen vom spezifizierten Verhalten erkennt. Im Fall einer erkannten Abweichung kann der Erkenner 12 eine Reaktion, wie oben beschrieben, anstoßen. Die Sensoren und der Erkenner bilden zusammen das Überwachungsmittel. Aus logischer Sicht ist das spezifizierte Verhalten, das der Erkenner mit dem tatsächlichen Verhalten der Rechenvorrichtung vergleicht, in einer Erkennerkonfiguration festgeschrieben. In der Praxis ist diese Information in dem Erkenner 12 eingearbeitet. Die Informationen, an welchen Stellen in der zu überwachenden Rechenvorrichtung welche Sensoren 11 platziert werden sollen, ist in einer Sensorkonfiguration enthalten, die im Rahmen der Formalisierung der Spezifikation erstellt wird.
5 beschreibt in einer schematischen Form eine mögliche Erzeugung des Überwachungsmittels aus der Rechenvorrichtung zugrunde liegenden Spezifikation. Bei diesem Verfahrensschritt geht es darum, die Spezifikation der Rechenvorrichtung derart zu formalisieren, dass sie als Grundlage der Generierung des Überwachungsmittels im nächsten Schritt dienen kann. Hierzu bedient sich die Erfindung sogenannter Timed Security Automata (TSA), die eine Variante sogenannter endlicher Automaten darstellen. Endliche Automaten eigenen sich besonders zur Spezifikation von Abläufen innerhalb eines Teilsystems. TSAs sind eine Klasse von endlichen Automaten, die im Rahmen der Erfindung für den Zweck der Überwachung dienen. Diese, auch als Zustandsautomaten bezeichneten endlichen Automaten, werden in eine weitere Sprache (MML) transformiert, aus welcher eine automatische Generierung des Überwachungsmittels möglich ist. Die Nutzung anderer Formate ist prinzipiell möglich.
In 6 ist ein TSA für ein Beispiel dargestellt, der einen Teil des Verhaltens der Rechenvorrichtung beschreibt. Anschaulich läuft dieser Zustandsautomat im später generierten Überwachungsmittel parallel zum zu überwachenden Ablaufmuster und überwacht und prüft deren Verhalten. Durch das Bereitstellen von TSAs wird damit formal spezifiziert, wie sich das Ablaufmuster zu verhalten hat. Der beispielhafte Zustandsautomat kann sich in zwei Zuständen „inactive" und „active" befinden. An den Kanten (Pfeile) zwischen diesen Zuständen stehen Aktionen des zu überwachenden Ablaufmusters, die vom Überwachungsmittel beobachtet werden sollen. Befindet sich der Zustandsautomat in einem bestimmten Zustand und führt das überwachte Ablaufmuster eine Aktion aus, die an einer ausgehenden Kante angeschrieben ist, so folgt der Zustandsautomat der Kante in diesen Zustand, auf den diese zeigt. Ist der Zustandsautomat beispielsweise im Zu stand „inactive" und die überwachte Software führt die Aktion „trigger" durch, so geht der Zustandsautomat in den Zustand „active" über. Derartige Aktionen werden durch die Softwaresensoren festgestellt. Der Zustandsautomat läuft so lange parallel zur überwachten Software, bis diese eine Aktion durchführt, die an keiner der von dem aktuellen Zustand ausgehenden Kanten angeschrieben ist. In diesem Fall bleibt der Zustandsautomat stehen, es wurde eine Abweichung vom spezifizierten Verhalten erkannt. Hierauf können verschiedene Reaktionen vom Überwachungsmittel angestoßen werden. Zusätzlich können in einem TSA Bedingungen an Aktionen sowie Bedingungen über Werte bestimmter Attribute, wie z.B. einer Fahrzeuggeschwindigkeit, spezifiziert werden.
Die in 5 dargestellte Sprache MML ist eine Implementierung eines speziell auf die Überwachungsaufgabe zugeschnittenen Sprachkonzeptes. Die TSAs werden in MML-Beschreibungen bzw. MML-Module transformiert. Die Transformation dient der Erleichterung der Transformation der Spezifikation in das Softwarecodeabschnitte aufweisende Überwachungsmittel.
Eine MML-Spezifikation besteht aus mehreren Modulen. Ähnlich wie bei TSAs arbeiten die Module im Betrieb der Rechenvorrichtung zusammen, um deren Verhalten zu prüfen. Die Interaktion der Module basiert dabei auf der Weitergabe von Ereignissen und Zustandswerten und hat damit Ähnlichkeit zu einer elektronischen Schaltung. Dies ist in 7 in einem Beispiel näher dargestellt. Es gibt zwei spezielle Arten von Modulen: Module, die Software-Sensoren in der Spezifikation repräsentieren und Module, die Software-Aktoren repräsentieren. Software-Aktoren dienen zur Durchsetzung von Reaktionen des Überwachungsmittels in der Rechnervorrichtung. Die übrigen Module verarbeiten eingehende Ereignisse und Zustände und produzieren ausgehende Ereignisse und Zustände. Dies ist in 7 näher dargestellt. Die Abbildung zeigt ein Beispiel für eine MML-Spezifikation auf Modulebene. Zwei Sensoren „CAN-Sensor" und „White Box Sensor" erzeugen die Ereignisse „send", „receive" und „trigger". Die Ereignisse „send" und „receive" werden von einem Modul „Filter 1" aufgenommen, das unter bestimmten Umständen das Ereignis „adjustSeat" erzeugt und die Zustandsvariable „speed" zur Verfügung stellt. Ein weiteres Modul „Automat1" übernimmt die Ausgaben des Moduls „Filter1" sowie das Ereignis „trigger" auf und erzeugt unter bestimmten Umständen das Ereignis „reject". Dieses Ereignis wird von dem als Aktor ausgebildeten Modul „Alarm" aufgenommen.
Eine MML-Spezifikation besteht einerseits aus der Kombination von Modulen, andererseits aus dem „Innenleben" der einzelnen Module. Wie ein spezielles Modul intern arbeitet, wird in MML in textueller Form festgelegt. Das in 8 dargestellte Beispiel zeigt die Definition des Moduls „Filter1" aus dem Modulnetz gemäß 7. Wesentlicher Bestandteil der Beschreibung sind die sogenannten „Eventhandler", die definieren, wie ein Modul auf ein eingehendes Ereignis reagiert. Das Modul „Filter1" muss auf die eingehenden Ereignisse „send" und „receive" reagieren. Ähnlich einem Funktions- oder Methodenaufruf einer Programmiersprache wird dazu die Reaktion definiert. Mögliche Reaktionen der Module sind das Lesen von eingehenden Zustandsvariablen und Vergleiche ihrer Werte, das Schreiben von ausgehenden Zustandsvariablen sowie das Erzeugen von ausgehenden Ereignissen.
Erfolgt eine Transformation eines TSAs in MML, so wird tatsächlich nur ein einziges MML-Modul aus dem Zustandsautomaten erzeugt. Mit anderen Worten wird ein MML-Modul durch Angabe eines TSA festgelegt. Auch in einem MML können zeitliche Bedingungen einer zu formalisierenden Spezifikation festgehalten werden. Prinzipiell ist es auch möglich, die Spezifikation unter Auslassung der Definition der Zustandsautomaten unmittelbar in einer MML-geeigneten Form vorzusehen.
Bei der Generierung des Überwachungsmittels geht es darum, die MML-Module einer Spezifikation sowie deren Interaktion über Ereignisse und Zustände in den Programmcode einer Programmiersprache zu überführen. Hierzu kann beispielsweise C als Sprache verwendet werden. Die Grundidee für die Umwandlung einer MML-Beschreibung in Softwarecodeabschnitte besteht darin, Ereignisse durch Funktionsaufrufe abzubilden.
9 zeigt in der linken Hälfte einen Ausschnitt aus einem MML-Modulnetz in einer anderen Notation. Die mit X und Y bezeichneten Ovale stellen Module dar, die Rechtecke in den Modulen X und Y sind Eventhandler. Die mit A, B und C bezeichneten Kreise repräsentieren Ereignisse. In diesem Beispiel empfängt das Modul X die Ereignisse A und B und erzeugt das Ereignis C. Dieses wird von Modul Y aufgenommen. In dem Eventhandler 1 ist dabei die Reaktion des Moduls X auf Ereignis A definiert, in Eventhandler 2 die auf Ereignis B. Eventhandler 3 und 4 definieren jeweils eine Reaktion von Modul Y auf Ereignis C. Im rechten Teil der Figur ist der generierte Softwarecodeabschnitt angedeutet.
Für jedes Ereignis im Modulnetz wird eine gleichnamige Funktion erzeugt, die im Wesentlichen den Code für alle Eventhandler enthält, die auf das Ereignis reagieren sollen. Das Auslösen der Ereignisse wird später im Betrieb durch Aufrufen der gleichnamigen Funktionen weiter gegeben.
Sensoren werden in MML durch spezielle Module repräsentiert. Aus diesen Modulen werden Softwarecodeabschnitte erzeugt, die direkt in das zu überwachende Ablaufmuster eingefügt werden, um dort relevante Veränderungen feststellen zu können. Das Einfügen erfolgt automatisiert.
Durch die Verwendung von Funktionsaufrufen kann die Überwachung zur Laufzeit mit minimalem Aufwand erfolgen. Der generierte Code ist ähnlich effizient wie handgeschriebener Code. Gleichzeitig bietet die Generierung wesentliche Vorteile gegenüber einem manuell erstellten Code: Der Generator sorgt dafür, dass keine Konflikte durch gleiche Namensgebung von Programmvariablen auftreten. Das vorgegebene Modulkonzept sorgt für Übersichtlichkeit und Wartbarkeit des Überwachungsmittels. Gleichzeitig kann der Generator sicherstellen, dass im Überwachungscode keine ungewollten Schleifen versteckt sind, die zur Laufzeit Ressourcen kosten oder die Rechnervorrichtung in ihrem Ablauf beträchtlich stören können. Ein besonderer Vorteil besteht darin, dass keine Beeinflussung durch die Beobachtung erfolgt.
Nach der Erzeugung des Überwachungsmittels wird dieses auf die Rechnervorrichtung aufgebracht. Die Grundannahme ist dabei, dass der oder die entsprechenden Rechner über freie Ressourcen verfügen. Das generierte Überwachungsmittel ist hoch effizient hinsichtlich seines Speicher- und Rechenzeitbedarfs. Wie hoch die Ressourcenanforderungen für ein spezielles Überwachungsmittel sind, hängt von der Spezifikation ab, die als Eingabe der Generierung dient (z.B. MML oder TSA). Prinzipiell ist es dabei möglich, den Ressourcenbedarf eines Überwachungsszenarios bei der Generierung durch den Generator berechnen zu lassen. Ebenso ist eine Analyse der benötigen Rechenzeit je überwachtem Ereignis möglich. Auf diese Weise kann abgesehen werden, ob die Überwachung jedes überwachten Ereignisses erwartungsgemäß funktionieren kann. Wird beispielsweise ein Ereignis von einem Softwaresensor aus einem Interrupt heraus gemeldet, so darf die Überwachung die Abarbeitung des Interrupts meist nicht über eine bestimmte Grenze hinaus verzögern.
Mit der Erfindung werden somit ein Verfahren und eine Vorrichtung bereitgestellt, die das bestimmungsgemäße Funktionieren eines Ablaufmusters in einer Rechenvorrichtung sicherstellen bzw. überwachen. Bei der Anwendung in einem Kraftfahrzeug bedeutet dies, dass der Benutzer des Kraftfahrzeugs ein korrektes Funktionieren erfährt. Dadurch kann insbesondere auch seine Sicherheit verbessert werden, da Fehlreaktionen unterbunden werden.
Darüber hinaus sind weitere Anwendungen für die Überwachung denkbar. So könnte beispielsweise vor Auslieferung einer Rechenvorrichtung das Überwachungsmittel in der Entwicklung eingesetzt werden. Dies kann einmal zur Vereinfachung von Test des Ablaufmusters und zum anderen zur Messung von schwer zugänglichen Parametern, z.B. Tasklaufzeiten, vorgesehen sein. Zur Unterstützung der Diagnose kann ein Überwachungsmittel Fehlersituationen oder anderweitig interessante Situationen erkennen und für den Fahrer unsichtbar in Fehlerspeichereinträgen vermerken. Insbesondere umfangreichere Abbilder des Kontextes in einer solchen Situation brauchen nur dann gespeichert werden, wenn es wirklich notwendig ist. Letztendlich ist es möglich, mit Hilfe des Überwachungsmittels Teile der Anwendungslogik zu programmieren.
Durch die Überwachung eines Ablaufmusters in einer Rechenvorrichtung, insbesondere einem Bussystem in einem Kraftfahrzeug, können zur Laufzeit Fehler erkannt werden, die in Tests nicht offenbar wurden. Die erkannten Fehler können signalisiert und/oder unterbunden werden. Die Betriebssicherheit der Rechenvorrichtung wird dadurch erhöht. Mit steigendem Anteil an sensitiven Daten wird auch Informationssicherheit relevant und kann verbessert werden. Durch die Erkennung von Fehlerzuständen kann die Diagnose durch Erfassung des Fehlerkontextes unterstützt werden. Dies ist mit minimalem Aufwand möglich.
Aus der in 10 gezeigten Tabelle werden verschiedene Anwendungsmöglichkeiten der Erfindung ersichtlich. Im Vorfeld des Betriebs (Pre-Deployment) kann die Erfindung während eines Profilings zum Aufzeichnen von Task-Wechseln oder zum Messen des Ressourcenbedarfs einer Komponente eingesetzt werden. Allgemein kann die Erfindung auch im Rahmen von Tests, z.B. Integrationstests, Akzeptanztests oder Komponententests verwendet werden. Während des Betriebs der Rechenvorrichtung (Post-Deployment) kann die Sicherheit und Stabilität der Rechenvorrichtung durch zusätzliche Sicherheitschecks, durch eine zur Laufzeit mögliche Prüfung des Verhaltens gegen die Spezifikation und zum Durchsetzen von strengen Beschränkungen innerhalb des Ablaufmusters eingesetzt werden. Darüber hinaus besteht die Möglichkeit einer Funktionserweiterung des Ablaufmusters der Rechenvorrichtung, bei der die Systemintegrität in jedem Fall sichergestellt ist. Im Rahmen von Diagnoseverfahren können Fehlersituationen protokolliert und fehlerhafte Komponenten ermittelt werden.

1: Rechenvorrichtung
2: Rechner
3: Rechner
4: Rechner
5: Rechner
6: Busleitung
7: Datenein- und -ausgang
10: Überwachungsmittel
11: Sensormittel
12: Erkennermittel
15: Ablaufmuster
A: Ereignis
B: Ereignis
C: Ereignis
X: Modul
Y: Modul

Claims

Verfahren zum Überwachen eines Ablaufs einer Rechenvorrichtung (1), insbesondere in einem Kraftfahrzeug, gekennzeichnet durch die Schritte: – Vorsehen eines Ablaufmusters (15) in der Rechenvorrichtung (1), – Vorsehen eines Überwachungsmittels (10) mit zumindest einem Sensormittel (11), das dazu eingerichtet ist, ein Ereignis der Rechenvorrichtung (1) zu erkennen, und zumindest einem Erkennungsmittel (12), das dazu eingerichtet ist, das Verhalten der Rechenvorrichtung auf das von dem Sensormittel erkannte Ereignis zu verfolgen, – Integrieren des Überwachungsmittels (10) in das Ablaufmuster (15), – Überwachen des Ablaufmusters (15) zu dessen Laufzeit, indem durch das Überwachungsmittel (10) erkannte Ereignisse (E1, E2) auf eine Abweichung von einem spezifizierten Zustand oder einer spezifizierten Zustandsänderung überprüft werden.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Schritt des Erzeugens des Überwachungsmittels (10) vorgesehen ist, in dem ein spezifiziertes Verhalten des Ablaufmusters (15) mit zumindest einem Ereignis (E1, E2) und dem zumindest einen Ereignis zugeordneten Zuständen und Zustandsänderungen festgelegt wird, wobei das spezifizierte Verhalten in einen Programmcode umgesetzt wird.
Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass das Erzeugen des Überwachungsmittels (10) folgende Schritte umfasst: – Umwandlung der Spezifikation des Verhaltens in einem Zustandsautomaten, der zumindest eines der von dem Sensormittel erkannten Ereignisse verarbeiten kann, und – Umwandlung zumindest der in dem Zustandsautomaten definierten Zustände und Zustandsänderungen in den Programmcode.
Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass in dem Zustandsautomat, der ein von dem Sensormittel erkanntes Ereignis verarbeitet, zumindest eine Variable definiert ist, die bei der Umwandlung der in dem Zustandsautomaten definierten Zustände und Zustandsänderungen in den Programmcode berücksichtigt wird.
Verfahren nach einem der Ansprüche 2 bis 4, dadurch gekennzeichnet, dass bei der Umwandlung des Zustandsautomaten in den Programmcode zumindest ein weiterer Transformationsschritt vorgenommen wird, in dem eine formale Spezifikation erstellt wird, wie sich das zu überwachende Ablaufmuster zu verhalten hat.
Verfahren nach einem der Ansprüche 2 bis 5, dadurch gekennzeichnet, dass das Erzeugen des Überwachungsmittels (10), und insbesondere das Überführen in den Programmcode, automatisch erfolgt.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Schritt des Integrierens des Überwachungsmittels (10) in das Ablaufmuster (15) das Einbringen des Programmcodes in einen Ablaufmusterprogrammcode umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass beim Feststellen einer Abweichung von einem spezifizierten Zustand oder einer spezifizierten Zustandsänderung durch das Überwachungsmittel eine, insbesondere in der Rechenvorrichtung oder in dem Ablaufmuster, definierte Reaktion eingeleitet wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bei der Detektion eines Ereignisses durch das Überwachungsmittel (10) ein Funktionsaufruf in dem Ablaufmusterprogrammcode erfolgt.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Überwachungsmittel (10) in einem Rechner (4) einer Mehrzahl an Rechnern (2, 3, 4, 5) vorgesehen ist, und dieser Rechner der Mehrzahl an Rechnern (2, 3, 4, 5) der Rechenvorrichtung (1) auf sein Ablaufmuster überwacht wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Überwachungsmittel (10) in zumindest zwei Rechnern (2, 3, 4) einer Mehrzahl an Rechnern (2, 3, 4, 5) vorgesehen ist, und die Interkommunikation zwischen den Rechnern der Rechenvorrichtung (1) überwacht wird.
Vorrichtung zum Überwachen eines Ablaufs einer Rechenvorrichtung (1), insbesondere in einem Kraftfahrzeug, in der ein Überwachungsmittel (10) mit zumindest einem Sensormittel (11) vorgesehen ist, das dazu eingerichtet ist, ein Ereignis der Rechenvorrichtung (1) zu erkennen, und zumindest einem Erkennungsmittel (12), das dazu eingerichtet ist, das Verhalten des von dem Sensormittel (11) erkannten Ereignisses zu verfolgen, wobei das Überwachungsmittel (10) in ein Ablaufmuster auf der Rechenvorrichtung (1) integriert ist, und wobei das Überwachungsmittel (10) dazu eingerichtet ist, das Ablaufmuster zu dessen Laufzeit zu überwachen, indem durch das Überwachungsmittel (10) erkannte Ereignisse auf eine Abweichung von einem spezifizierten Zustand oder einer spezifizierten Zustandsänderung überprüft werden.
Vorrichtung nach Anspruch 12, dadurch gekennzeichnet, dass die Rechenvorrichtung (1) eine Mehrzahl an miteinander gekoppelten Rechnern (2, 3, 4, 5) aufweist, wobei das Überwachungsmittel (10) in zumindest einem der Rechner angeordnet ist.
Vorrichtung nach Anspruch 12 oder 13, dadurch gekennzeichnet, dass die Rechenvorrichtung (1) ein Bussystem, insbesondere in einem Kraftfahrzeug, ist und die Rechner (2, 3, 4, 5) Busteilnehmer dieses Bussystems sind, die über eine Busleitung (6) miteinander gekoppelt sind, über welche der Austausch von Nachrichten möglich ist.
Vorrichtung nach einem der Ansprüche 12 bis 14, dadurch gekennzeichnet, dass das Überwachungsmittel (10) ein Computerprogrammprodukt darstellt, das in das Ablaufmuster integriert ist.
Vorrichtung nach einem der Ansprüche 12 bis 15, dadurch gekennzeichnet, dass das Überwachungsmittel (10) zur Überwachung zumindest eines der Rechner (4) der Rechenvorrichtung ausgebildet ist.
Vorrichtung nach einem der Ansprüche 12 bis 16, dadurch gekennzeichnet, dass das Überwachungsmittel (10) zur Überwachung der Interkommunikation zwischen zumindest zwei Rechnern (2, 3, 4) der Rechenvorrichtung (1) ausgebildet ist.
Computerprogrammprodukt, dadurch gekennzeichnet, dass in ein eine Rechenvorrichtung (1) steuerndes Ablaufmuster ein Überwachungsmittel (10) integriert ist, das eine computerlesbare Spezifikation des Verhaltens des Ablaufmusters umfasst und das dazu eingerichtet ist, zur Laufzeit des Ablaufmusters ein von der Spezifikation abweichendes Verhalten festzustellen und eine Reaktion hierauf einzuleiten.