DE10312557A1

DE10312557A1 - Verfahren zur Überprüfung der funktionalen Sicherheit von elektronischen Systemen eines Fahrzeugs

Info

Publication number: DE10312557A1
Application number: DE2003112557
Authority: DE
Inventors: Frank Henecker; Ulrich Dr. Siebel; Andreas Breuer
Original assignee: Audi AG; Volkswagen AG
Current assignee: Audi AG; Volkswagen AG
Priority date: 2003-03-21
Filing date: 2003-03-21
Publication date: 2004-10-14
Anticipated expiration: 2023-03-22
Also published as: DE10312557B4

Abstract

Der Erstellungsaufwand von Applikationen beziehungsweise Funktionsmodellen soll reduziert werden. Hierzu wird ausgenutzt, dass in Fahrzeugen vielfach auch Diagnosemodelle zum Ermitteln von Fehlerursachen eingesetzt werden. Diese Diagnosemodelle können üblicherweise auch Funktionsverhalten bestimmter Komponenten simulieren und so parallel zum Funktionsmodell in der Applikation eingesetzt werden. Um aus sicherheitstechnischen Gründen eine gewisse Diversität zu gewährleisten, muss daher nicht ein Funktionsmodell mehrfach entwickelt werden, sondern es kann auf das Diagnosemodell zurückgegriffen werden.

Description

Die vorliegende Erfindung betrifft ein Verfahren zum Überprüfen der funktionalen Sicherheit von elektronischen Systemen eines Fahrzeugs und/oder mindestens einer seiner Komponenten. Dabei werden hier sowie in den nachfolgenden Ausführungen unter dem Begriff „Fahrzeug" neben Kraftfahrzeugen auch Flugzeuge, Schiffe und schienengeführte Fahrzeuge verstanden.

Sicherheitskritische Applikationen zur Steuerung von Fahrzeugen müssen hinsichtlich ihrer Korrektheit, Zuverlässigkeit und Vollständigkeit besondere Anforderungen erfüllen (siehe Norm IEC 61508, Funktionale Sicherheit, sicherheitsbezogene elektrische, elektronische, programmierbare elektronische Systeme). Eine derartig kritische Applikation wird beispielsweise für die elektronische Steuerung der Bremsen eines Kraftfahrzeugs benötigt.

Die speziellen sicherheitstechnischen Anforderungen können für betroffene Applikationsanteile dadurch erfüllt werden, dass sie diversitär entwickelt werden, d. h. es werden unterschiedliche Entwicklungstools verwendet, eventuell werden sie parallel erstellt. Nach Abschluss der vollständigen Entwicklung werden die beiden unabhängig voneinander entstandenen Applikationen parallel zur Laufzeit eingesetzt und so permanent auf Richtigkeit, Vollständigkeit usw. überprüft. Es wird also beispielsweise das Funktionsmodell eines Fahrzeugs zweimal unabhängig voneinander entwickelt und parallel eingesetzt, so dass mit hoher Wahrscheinlichkeit davon ausgegangen werden kann, dass das daraus resultierende Funktionsverhalten korrekt und zuverlässig ist.

Der Aufwand für derartige diversitären Prozesse und Implementierungen ist erheblich, da zwei voneinander unabhängige Systeme entwickelt werden müssen.

Die Aufgabe der vorliegenden Erfindung besteht somit darin, den Aufwand für die Entwicklung von Funktionsapplikationen beziehungsweise Funktionsmodellen zu reduzieren.

Erfindungsgemäß wird diese Aufgabe gelöst durch eine Verfahren zum Überprüfen der funktionalen Sicherheit von elektronischen Systemen eines Fahrzeugs und/oder mindestens einer seiner Komponenten durch Bereitstellen eines Funktionsmodells zur Modellierung einer Funktion des Fahrzeugs oder der mindestens einen Komponente, Bereitstellen eines Diagnosemodells, durch das das Funktionsverhalten des Fahrzeugs und/oder der mindestens einen Komponente zumindest teilweise modelliert wird, zum Überwachen des Fahrzeugs und/oder der mindestens einen Komponente und paralleles Einsetzen des Diagnosemodells und Funktionsmodells hinsichtlich des Funktionsverhaltens der Fahrzeugs und/oder der Komponente.

Der Vorteil dieses Verfahrens besteht darin, dass das Diagnosemodell zur sicherheitsrelevanten Funktionsüberprüfung in der Applikation und ggf. während des Entwicklungsprozesses eingesetzt wird. Da auch in dem Diagnosemodell das Funktionsverhalten des Kraftfahrzeugs beziehungsweise einer seiner Komponenten zumindest teilweise simuliert wird, können die von dem System oder Funktionsmodell gelieferten Steuerungswerte beziehungsweise Simulationsergebnisse mit denen des Diagnosemodells verglichen werden. Der Entwicklungsaufwand für die Applikation kann somit deutlich reduziert werden, da ein Diagnosemodell in dem Fahrzeug in der Regel ebenfalls verwendet wird.

Vorzugsweise basiert das Diagnosemodell auf einem fahrzeugunabhängigen Diagnosealgorithmus. Durch die Verwendung eines Algorithmus mit universeller Grundstruktur kann der Entwicklungsaufwand weiter reduziert werden.

Das Diagnosemodell und das Funktionsmodell sollten unterschiedliche Grundstrukturen besitzen. Dies dient dazu, dass der Grad der Diversität vergrößert wird.

Das Funktionsmodell ist vorzugsweise signalorientiert und liefert somit signalorientierte Steuerungs- beziehungsweise Simulationswerte. Die signalorientierte Verarbeitung hat Vorteile bei der Steuerung von Komponenten.

Demgegenüber sollte das Diagnosemodell komponentenorientiert sein und somit komponentenorientierte Simulationsergebnisse liefern. Die Komponentenbezogenheit hat Vorteile bei der Ortung von Fehlerursachen.

Da das Funktionsmodell signalorientiert und das Diagnosemodell komponentenorientiert ist, sind schon ihre Grundstrukturen stark diversitär ausgeprägt.

Das Vergleichen der Steuerungs- beziehungsweise Simulationswerte des Funktions- und Diagnosemodells kann ein Überprüfen auf Vollständigkeit umfassen. Dabei kann eine Überprüfung der Vollständigkeit sowohl der Eingangsgrößen als auch der Ausgangsgrößen erfolgen. Die Überprüfung hinsichtlich der Vollständigkeit kann sich auf das gesamte Modell beziehungsweise die gesamte Applikation oder aber auf Teilbereiche beziehen.

Die vorliegende Erfindung wird nun anhand der beigefügten Zeichnung näher erläutert, die ein Blockschaltbild des Verfahrens gemäß einer Ausführungsform der vorliegenden Erfindung wiedergibt.
Das nachfolgend näher beschriebene Ausführungsbeispiel stellt eine bevorzugte Ausführungsform der vorliegenden Erfindung dar.
Wie in der Zeichnung in Schritt 1 dargestellt ist, wird eine zentrale Anforderung in Form eines Lastenhefts für ein Steuerungssystem erstellt. Im Hinblick darauf wird entsprechend Schritt 2 ein Funktionsmodell mit den entsprechenden Entwicklungstools entwickelt. Dieses erste Entwicklungsteam ist speziell für Funktionsmodelle zuständig.
Ein zweites Entwicklungsteam entwickelt gemäß Schritt 3 in der Zeichnung ein Diagnosemodell. Dieses dient zum zielgerichteten Auffinden einer Fehlerursache aufgrund von detektierten oder eingegebenen Symptomen. In dem Diagnosemodell wird mindestens das Ok-Verhalten modelliert. Dieses Verhalten gibt Aufschluss darüber, welche Signale vorliegen müssten, wenn kein Fehler vorliegen würde. Auf diese Weise kann diejenige Komponente ausfindig gemacht werden, deren Funktion defekt ist.
An das Diagnosemodell werden grundsätzlich andere Anforderungen gestellt als an das Funktionsmodell. Zum Beispiel kann das Diagnosemodell auch wesentlich gröber als das Funktionsmodell gestaltet sein. Vielfach genügt es nämlich, dass ein ganzes Modul als fehlerhaft erkannt wird, während ihr Funktionsverhalten beziehungsweise ihre Simulation wesentlich feinstufiger erfolgen muss. Ein weiterer Unterschied zwischen dem Funktionsmodell und dem Diagnosemodell besteht darin, dass das Funktionsmodell signalorientiert ist, während das Diagnosemodell komponentenorientiert ist. Dies lässt sich beispielhaft an einer Reihenschaltung von Widerständen erklären. Für das Funktionsmodell ist beispielsweise lediglich der durch die Gesamtschaltung fließende Strom von Interesse. Im Gegensatz dazu muss von dem Diagnosemodell beispielsweise erkannt werden, welcher der beiden Widerstände defekt ist.
Die genannten unterschiedlichen Anforderungen an das Diagnose- beziehungsweise Funktionsmodell bedingen, dass beide Modelle mit unterschiedlichen Algorithmen realisiert werden. Da mit beiden Modellen das Funktionsverhalten mindestens einer Komponente oder des gesamten Fahrzeugs abgebildet wird, entsteht durch die unterschiedlichen Algorithmen eine Diversität. Der Grad der Diversität kann noch dadurch erhöht werden, dass für die Entwicklung des Funktionsmodells beispielsweise ein Steuerungsentwicklungsteam zuständig ist, wogegen für die Entwicklung des Diagnosemodells ein Diagnoseteam zuständig ist.
Mit Hilfe beider Modelle kann nun das Funktionsverhalten gemäß Schritt 4 in der Zeichnung überprüft und gegenseitig miteinander verglichen. Auf diese Weise kann ermittelt werfen, ob die einzelnen Modell zu den gleichen Ergebnissen hinsichtlich des Funktionsverhaltens führen. Dabei wird nicht nur die Qualität der Simulationsergebnisse, sondern auch deren Quantität überprüft. Entsprechend der Überprüfung kann das ein oder andere Modell ergänzt werden.
Vorteilhaft ist nun, dass das Diagnosemodell zur Überprüfung der sicherheitsrelevanten Funktion eingesetzt wird und so automatisch die Diversität beim Einsatz in der Applikation und ggf. während des Entwicklungsprozesses gewährleistet wird, die den sicherheitstechnischen Entwurfs- und Implementationsanforderungen genügt.
Ein konkreter Anwendungsfall wäre beispielsweise ein elektronisches Bremssystem. Sowohl das Entwicklungsteam der Bremsfunktion als auch das Diagnoseteam gehen von einer zentralen Spezifikation, z. B. Lastenheft, aus. Das Entwicklungsteam für die Bremsfunktion und das Diagnoseteam realisieren ihre jeweilige Applikation entkoppelt voneinander. Ein Vergleichslauf kann Hinweise darauf ergeben, ob ein Modell oder beide Modelle ergänzt werden müssen. Der parallele Einsatz von beiden Systemen (Funktions- und Diagnosemodell) garantiert so die geforderte Diversität.
Die beiden gemeinsam entwickelten Modelle, das Diagnosemodell und das Funktionsmodell können in das jeweilig vorgesehene Steuergerät im Kraftfahrzeug implementiert werden. Ferner besteht die Möglichkeit, beide Modelle in einem einzigen Steuergerät gemeinsam zu implementieren. Letzteres hat den Vorteil, dass weniger Daten beispielsweise über Busleitungen übertragen werden müssen. Falls jedoch getrennte Steuergeräte, ein Funktionssteuergerät und ein Diagnosesteuergerät, vorgesehen sind, ist dies hinsichtlich der Ausfallsicherheit von Vorteil.

Claims

Verfahren zum Überprüfen der funktionalen Sicherheit von elektronischen Systemen eines Fahrzeugs und/oder mindestens einer seiner Komponenten gekennzeichnet durch Bereitstellen (2) eines Funktionsmodells zur Modellierung einer Funktion des Fahrzeugs oder der mindestens einen Komponente, Bereitstellen (3) eines Diagnosemodells, durch das das Funktionsverhalten des Fahrzeugs und/oder der mindestens einen Komponente zumindest teilweise modelliert wird, zum Überwachen des Fahrzeugs und/oder der mindestens einen Komponente und paralleles Einsetzen (5) des Diagnosemodells und Funktionsmodells hinsichtlich des Funktionsverhaltens der Fahrzeugs und/oder der Komponente.
Verfahren nach Anspruch 1, wobei das Diagnosemodell auf einem fahrzeugunabhängigen Diagnosealgorithmus basiert.
Verfahren nach Anspruch 1 oder 2, wobei das Diagnosemodell und das Funktionsmodell jeweils eine unterschiedliche Grundstruktur besitzen.
Verfahren nach einem der Ansprüche 1 bis 3, wobei das Funktionsmodell signalorientiert ist und somit signalorientierte Simulationsergebnisse liefert.
Verfahren nach einem der Ansprüche 1 bis 4, wobei das Diagnosemodell komponentenorientiert ist und somit komponentenorientierte Simulationsergebnisse liefert.
Verfahren nach einem der Ansprüche 1 bis 5, wobei Simulationsergebnisse und/oder Steuerungswerte des Funktionsmodells mit Simulationsergebnissen des Diagnosemodells betreffend das Funktionsverhalten des Fahrzeugs und/oder der mindestens einen Komponente verglichen werden.
Verfahren nach einem der Ansprüche 1 bis 6, wobei das Vergleichen der Simulationsergebnisse zumindest in Teilbereichen ein Überprüfen auf Vollständigkeit der Simulationsergebnisse umfasst.