Beschreibung

Titel

Verfahren zur überwachung der Funktionsfähigkeit eines elektronischen Bausteins

Die Erfindung betrifft ein Verfahren zur überwachung der Funktionsfähigkeit eines elektronischen Bausteins in einem Steuergerät, ein solches Steuergerät sowie ein Computerprogramm und ein Computerprogrammprodukt zur Durchfüh- rung des Verfahrens.

Stand der Technik

Elektronische Steuergeräte werden bei Kraftfahrzeugen in unterschiedlichen Be- reichen eingesetzt, um diverse Abläufe zu steuern und/oder zu regeln. So ist der

Einsatz von Steuergeräten in Vorrichtungen zur Fahrzustandserkennung bekannt, bei denen unterschiedliche Größen, wie bspw. die Lenkwinkelgeschwindigkeit, aber auch optische Signale bzw. Bildsignale aufgezeichnet und ausgewertet werden, um einen kritischen Fahrzustand zu erkennen.

Die Druckschrift DE 10 2005 057 267 A1 beschreibt ein Verfahren und eine Vorrichtung zur Fahrzustandserkennung, bei denen der Verlauf eines den Fahrzustand charakterisierenden Signals ausgewertet und bei einem typischen Verlauf ein den Fahrzustand kennzeichnendes Signal erzeugt wird. Die Vorrichtung weist dabei eine elektronische Steuereinheit auf, die im wesentlichen aus Komponenten wie Eingangsschaltung, Rechner und Ausgangsschaltung besteht, wobei die einzelnen Komponenten zum gegenseitigen Daten- und Informationsaustausch mit einem Bussystem verbunden sind. Zur Erkennung von Fahrbahnrandmarkierungen wird eine Videokamera eingesetzt, die mit der Eingangsschaltung ver- bunden ist.

Zu beachten ist jedoch, dass videobasierte Fahrerassistenzsysteme aufgrund der Komplexität der Umwelt einen äußerst hohen Ressourcenbedarf haben. Dies spiegelt sich auch in der verwendeten Hardware wider. Zum Einsatz kommen äußerst leistungsfähige automotive zertifizierte Bausteine, deren Komplexität es zunehmend schwierig macht, die Hardware im Rahmen einer neben den Applikationen laufenden Selbstdiagnose vollständig, d.h. mit einer Testabdeckung von bspw. mehr als 90%, zu überwachen. Auch die überwachung von FPGAs im automobilen Umfeld ist bisher nicht zufriedenstellend gelöst.

Zur Gewährleistung der Funktionsfähigkeit der eingesetzten Steuergeräte sind unterschiedliche Vorgehensweisen bekannt. Dabei müssen Anforderungen an Hard- und Software formuliert werden, die einen sicheren Betrieb gestatten. Zur Vereinheitlichung der Entwicklungsprozesse und der überwachung im Betrieb werden normierte Vorgehensweisen angestrebt.

Die ISO 26262 ist eine vorgesehene ISO-Norm für sicherheitsrelevante Systeme in Kraftfahrzeugen, die ein Prozess-Rahmenwerk und Vorgehensmodell zusammen mit geforderten Aktivitäten und Arbeitsprodukten sowie anzuwendenden Methoden definiert. Die Umsetzung der Norm soll die funktionale Sicherheit eines elektronischen Systems in Kraftfahrzeugen gewährleisten.

Dabei wird eine Methode zur Gefahrenanalyse und Risikoabschätzung vorgeschlagen, bei der auf Grundlage der Systembeschreibung die möglicherweise gefährlichen Situationen identifiziert werden. Jede Gefahr wird dann mit einer Si- cherheitsanforderungsstufe von A bis D klassifiziert oder als nicht sicherheitsrelevant eingeordnet. Dazu muss für jede identifizierte Gefahr einzeln der Verletzungsgrad, die Häufigkeit der Situation und die Wertbarkeit der Situation durch den Fahrer abgeschätzt werden. Aus einer vorgegebenen Tabelle lässt sich dann für jede Gefahr die Einstufung QM (quality managed) oder ASIL (automotive sa- fety integrity level) A bis D ablesen.

Mit steigendem ASIL steigen auch die Anforderungen an die Sicherheit, die in den nachfolgenden Teilen spezifiziert sind. An Gefahren der Klasse QM sind kei- ne Anforderungen gestellt, die über das übliche Qualitätsmanagement des Systemherstellers hinausgehen.

Die Norm definiert konkrete Anforderungen an Software und Hardware, sowohl für die Entwicklungsprozesse als auch für das Fehlverhalten im Feld, und beein- flusst bereits heute die Anforderungen an die Systeme im Fahrzeug. Besonderes Augenmerk verdient die Erkennung von permanenten zufälligen bzw. systematischen Fehlern. Dabei werden Prozesse empfohlen und zum Teil quantitative Forderungen an Ausfallraten und Testabdeckungen für die verschiedenen Sicherheitsstufen vorgegeben.

Die Norm adressiert die Absicherung von Systemen im automobilen Bereich, wenn es durch ein Versagen der Hardware oder durch Software- Implementierungsfehler im technischen Sinne zu einer Gefährdung kommen kann. Funktionale Unzulänglichkeiten, die bspw. durch unzureichende Umfelderfassung entstehen, werden nicht durch die Norm adressiert. Diese müssen ggf. über weitere Maßnahmen außerhalb der Norm adressiert werden. Die Software hat im Verständnis der Norm einen vernachlässigbar kleinen Fehler, wenn sie nach den Prozessen der Norm entwickelt wird. Dieses Sicherheitskonzept zeigt die Absicherung von E/E/PES-Systemen im Sinne der Norm. Diese Absicherung ist im allgemeinen durch die Hardware getrieben.

Betrachtete Fehlerarten sind u.a. permanent zufällige Fehler, wie bspw. eine defekte RAM-Zelle, systematische Fehler, wie bspw. eine falsch ausgelegte Betriebstemperatur, transiente Fehler, wie bspw. ein Single Event Upset (Bit- Kipper). Diese Fehler können sich auf Programm und Daten auswirken.

Vorgaben sind, dass das betrachtete System ausfallsicher (fail-safe) ist, d.h., dass das Abschalten des Systems im Fehlerfall immer sicher ist. Zudem führt ein Fehler, der zum Ausbleiben jeder Kommunikation führt (fail-silent), ebenfalls in den sicheren Zustand.

Offenbarung der Erfindung

Das erfindungsgemäße Verfahren dient zur überwachung der Funktionsfähigkeit eines elektronischen Bausteins in einem Kraftfahrzeug. Dabei wird dem elektro- nischen Baustein eine einen Fahrzustand des Kraftfahrzeugs betreffende Größe als Eingangssignal zur Verarbeitung zugeführt. Ein Ausgangssignal des elektro-

nischen Bausteins wird an eine elektronische Recheneinheit weitergeleitet, in der das Ausgangssignal mit diversitären Softwarealgorithmen weiterverarbeitet wird, wobei die Ausgaben der diversitären Softwarealgorithmen in einem Komparator miteinander verglichen werden. üblicherweise werden zwei Softwarealgorithmen eingesetzt, deren Ausgänge in dem Komparator miteinander verglichen werden.

Ein fehlgeschlagener Vergleich führt zu einem Fehlerfall.

Hinreichend komplexe und diversitäre Algorithmen kommen nur auf fehlerfreier Hardware zu äquivalenten Ergebnissen. Somit übernehmen diversitäre Algorith- men auch die Funktion der Selbstdiagnose auf komplexer Hardware.

Das Steuergerät mit dem elektronischen Baustein kommt bspw. bei einem videobasierten Fahrerassistenzsystem zum Einsatz, bei dem eine Fahrzustandsüber- wachung durchgeführt wird. Bei dieser Anwendung kann dem elektronischen Baustein ein Bildsignal als Eingangssignal zugeführt werden. Hierbei kann der elektronische Baustein, der bspw. als FPGA (field programmable gate array: vor Ort modifizierbarer Logikbaustein) ausgebildet ist, mit einer Testabdeckung von bspw. mehr als 90% überwacht werden.

In Ausgestaltung wird dem elektronischen Baustein zusätzlich ein Testmuster zugeführt, das in dem elektronischen Baustein verarbeitet wird. Das verarbeitete Testmuster wird dann an die elektronische Recheneinheit weitergeleitet. Dabei kann das verarbeitete Testmuster und das Ausgangssignal getrennt in der elektronischen Recheneinheit, bspw. ein Mikrocontroller, weiterverarbeitet werden.

In der elektronischen Recheneinheit kann eine Testmusterverifikation durchgeführt werden. Ein Fehlschlagen der Testmusteranalyse führt regelmäßig zu einem Fehlerfall.

In Ausgestaltung wird die Funktionsfähigkeit des Komparators überwacht. Hierzu wir bspw. ein in Hardware unabhängiger SCON (safety Controller) eingesetzt.

Das beschriebene Steuergerät für ein Kraftfahrzeug dient insbesondere zur Durchführung eines Verfahrens der vorstehend beschriebenen Art. Dieses weist einen elektronischen Baustein, bspw. ein FPGA, und eine elektronischen Recheneinheit, bspw. einen Mikrocontroller, auf, wobei der elektronische Baustein

zur Aufnahme und zur Verarbeitung einer einen Fahrzustand des Kraftfahrzeugs betreffenden Größe ausgebildet ist und die elektronische Recheneinheit zur Weiterverarbeitung eines Ausgangssignal des elektronischen Bausteins ausgelegt ist. Bei der Weiterverarbeitung in der elektronischen Recheneinheit werden di- versitäre Softwarealgorithmen eingesetzt. Es ist weiterhin ein Komparator vorgesehen, der dafür ausgelegt ist, Ausgaben der diversitären Softwarealgorithmen miteinander zu vergleichen.

In Ausgestaltung ist eine Sicherheitseinrichtung zur überwachung des Kompara- tors, bspw. ein in Hardware unabhängiger SCON, vorgesehen.

Das vorgestellte Computerprogramm umfasst Programmcodemittel, um alle Schritte eines vorstehend beschriebenen Verfahrens durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Rechen- einheit, insbesondere in einem Steuergerät der beschriebenen Art, ausgeführt wird.

Das Computerprogrammprodukt weist diese Programmcodemittel auf, die auf einem computerlesbaren Datenträger gespeichert sind, um alle Schritte eines vor- gestellten Verfahrens durchzuführen, wenn das Computerprogramm auf einem

Computer oder einer entsprechenden Recheneinheit, insbesondere in einem Steuergerät, wie dies vorstehend beschrieben ist, ausgeführt wird.

Das vorgestellte Verfahren weist, zumindest in einigen der dargelegten Ausfüh- rungen, eine Reihe von Vorteilen auf. So kann eine generische überwachung des elektronischen Bausteins und damit eines FPGA ohne Verwendung expliziter Hardwareeigenschaften des FPGA durchgeführt werden. Die Verwendung diver- sitärer Algorithmen in der elektronischen Recheneinheit vereinfacht auf hohem Abstraktionsniveau die aufwendige Selbstdiagnose der Recheneinheit stark. Da- her können selbst komplexe MikroController in einem ASIL-B-Steuergerät eingesetzt werden. Außerdem können, wenn genügend Ressourcen vorhanden sind, bestehende Hardwarekonzepte sowohl für QM als auch für ASIL-A/B verwendet werden.

Weitere Vorteile und Ausgestaltung der Erfindung ergeben sich aus der Beschreibung und den beiliegenden Zeichnungen.

Es versteht sich, dass die voranstehend genannten und die nachstehend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, oh- ne den Rahmen der vorliegenden Erfindung zu verlassen.

Kurze Beschreibung der Zeichnungen

Figur 1 zeigt in schematischer Darstellung eine Ausführungsform eines Steuer- geräts.

Figur 2 zeigt in schematischer Darstellung ein Hardwarekonzept einer Vorrichtung zur Erkennung des Fahrzustands.

Figur 3 zeigt in einem Blockschaltbild den Aufbau der Software in einer Vorrichtung zur Fahrzustandserkennung.

Figur 4 zeigt den übergang von einem unkritischen zu einem kritischen transienten Fehler.

Figur 5 zeigt ein Systemkonzept für ein Steuergerät zur Fahrzustandserfassung.

Figur 6 verdeutlicht die Detektion permanenter FPGA-Fehler.

Figur 7 zeigt ein mögliches Komparatorkonzept.

Ausführungsformen der Erfindung

In Figur 1 ist eine Ausführung eines Steuergeräts, insgesamt mit der Bezugsziffer 10 bezeichnet, dargestellt. Dieses Steuergerät 10 weist einen elektronischen

Baustein 12, in diesem Fall ein FPGA, und eine elektronische Recheneinheit 14, in dieser Ausführung einen MikroController, auf. Weiterhin ist in dem Steuergerät 10 ein Komparator 16 und ein Controller 18 zur überwachung des Komparators 16 gegeben.

In dem elektronischen Baustein 12 ist ein Bereich 20 zum Ablegen eines Algorithmus und ein Generator 22 zum Erzeugen eines Testmusters vorgesehen.

In der elektronischen Einheit 14 sind ein erster Bereich 24 für einen ersten Algo- rithmus, ein zweiter Bereich 26 für einen zweiten Algorithmus und ein dritter Bereich 28 für eine Testmusterverifikation vorgesehen.

Ein Bildgeber 30 gibt erfasste Bildsignale an den elektronischen Baustein 12 weiter. In den Datenfluss der Bildsignale werden vor der Bearbeitung durch den elektronischen Baustein 12 Testmuster sowohl vor als auch nach den relevanten

Bilddaten eingespeist. Die Testmuster werden ohne Sonderbehandlung durch den Baustein 12 verarbeitet. Das Ergebnis der Berechnungen kann in einem Block-RAM (nicht dargestellt) zwischen dem Baustein 12 und der Recheneinheit 14 abgelegt werden. Hierbei ist es nicht relevant, ob es sich bei dem Baustein 12 und der Recheneinheit 14 um getrennte oder integrierte Komponenten handelt.

Die Ergebnisse des Bausteins 12 werden getrennt nach Bild und Testmuster in der Recheneinheit 14 weiterverarbeitet. Eine Testmusterverifikation vergleicht das Baustein- 12 Ergebnis des Testmusters mit bekannten Sollwerten.

Bei der dargestellten Ausführung verarbeiten zwei diversitäre Algorithmen die

Berechnungen des elektronischen Bausteins 12 bezüglich des tatsächlichen Bildes. Der Komparator 16 stellt den Single point failure der Recheneinheit 14 dar. In diesem werden die beiden diversitären Softwarekanäle verglichen und bei festgestellter äquivalenz auf einen Fahrzeugbus 32 gegeben. Der Komparator 16 wird dabei durch den in Hardware unabhängigen SCON (safety Controller) überwacht.

In Figur 2 ist in schematischer Darstellung eine Vorrichtung zur Fahrzustandser- kennung dargestellt. Diese Vorrichtung, die mit der Bezugsziffer 50 bezeichnet ist, umfasst einen Leistungsanschluss 52, der mit dem elektrischen System des

Fahrzeugs verbunden ist (Pfeil 54), einen Controller 56, einen NVM-Speicher 58 (non volatile memory: nichtflüchtiger Speicher), einen FPGA 60, einen Bildgeber 62, einen Blockspeicher 64 und eine Linseneinheit 70.

Einfallendes Licht 72 wird von der Linseneinheit 70 erfasst und an den Bildgeber 62 weitergegeben. Der Bildgeber 62 gibt Bilddaten, wie mit Pfeil 74 verdeutlicht, an den FPGA 60 weiter.

Der FPGA 60 umfasst eine Logikeinheit 76, einen eingebetteten Kern 78 und einen Bereich 80 zum Ablegen der Algorithmen. Weiterhin ist der FPGA 60 mit dem Blockspeicher 64, und dem NVM-Speicher 58 verbunden. Nach außen kommuniziert der FPGA 60 mit einem fahrzeugeigenen CAN-Bus (Doppelpfeil 82) und über den Controller 56 mit einem weiteren Feldbussystem (Doppelpfeil 86), bspw. ein FlexRay.

In Figur 3 ist in einem Blockschaltbild der Aufbau der in einer Fahrzustandser- kennungsvorrichtung eingesetzten Software dargestellt. In einem ersten Block 100 sind externe Daten enthalten, in einem zweiten Block die Daten und Pro- gramme der Vorrichtung zur Fahrerszustandserkennung und in einem dritten

Block 104 die ausgegebenen Daten.

Die externen Daten umfassen Bildsensordaten 106 und Fahrzeugsensordaten 108. Die Bildsensordaten 106 werden an den FPGA 1 10 weitergegeben, in dem eine Bildvorverarbeitung und Datenreduktion vorgenommen wird (Block 1 12). Innerhalb der Vorrichtung ist weiterhin einen MikroController 1 14 vorgesehen. Dieser erfasst die Bilddaten des FPGA 1 10 und führt eine Objektbildung in der Bildebene durch (Block 1 16). Die Fahrzeugsensordaten 108 werden zusätzlich zur realen Objektbildung (Block 1 18) und zur Zustandsschätzung (Block 120) heran- gezogen.

Das FPGA 1 10 im Kontext der betrachteten Funktion dient somit der Datenreduktion auf Ebene der Low-Level-Bildverarbeitung. Aus Sicht des FPGA 1 10 ist daher jedes Bild vollständig neu und ohne Bezug auf vorangegangene Bilder.

Transiente Fehler im Datenfluss des FPGA 1 10 entsprechen dem allgemeinen Sensorrauschen. Die Verarbeitung verrauschter Eingangssignale ist eine funktionale Anforderung an die Algorithmik. Das verwirklichte Sicherheitskonzept konzentriert sich daher auf die Erkennung permanenter Fehler des FPGA 1 10.

Die algorithmische Logik der Objektbildung wird in dem Mikrocontroller 1 14 berechnet. Hierbei wird nicht nur eine Einzelbildauswertung, wie dies beim FPGA 1 10 der Fall ist, durchgeführt. In Folge der zeitlichen Korrelation ist es nicht möglich, transiente Fehler zu vernachlässigen. Die Erkennung transienter und per- manenter Fehler ist durch das Sicherheitskonzept adressiert.

Figur 4 verdeutlicht den übergang von einem unkritischen zu einem kritischen transienten Fehler. In der Darstellung ist eine zweidimensionale Bildebene 150 einer realen Umgebung 152 gegenübergestellt. Ein Bereich 154 zeigt unkritische transiente Fehler und ein Bereich 156 transiente Fehler, die erkannt werden müssen.

Ein Bildgeber 158 erzeugt die Daten der Bildebene 150, die in ein reales Modell bzw. die reale Umgebung 152 überführt und an einen Fahrzeugbus 160 weiter- gegeben werden.

In Bezug zu den unterschiedlichen Ebenen ist die Datenmenge im Verhältnis zum Informationsgehalt pro Datum 164 aufgetragen. Zu erkennen ist das Anwachsen des Informationsgehalts 164 der Datenmenge 162 von der Bildebene 150 hin zu der realen Umgebung 152. In diesem Bereich liegen auch transiente

Fehler 156 vor, die erkannt werden müssen.

In Figur 5 ist ein mögliches Systemkonzept für ein Steuergerät, dass bei einer Fahrzustandserfassung zum Einsatz kommt, wiedergegeben. Die Darstellung zeigt einen Bildgeber, einen FPGA 402, ein RAM 404, einen Mikrocontroller 406 und einen Fahrzeugbus 408.

Der FPGA 402 weist ein Testmuster 410 und einen ersten Algorithmus 412 auf. In dem Mikrocontroller 406 sind ein erster Algorithmus 414, ein zweiter Algorith- mus 416, ein Testmusterverifikator 418 und ein Komparator 420 vorgesehen.

Der Datenfluss ist bspw. einkanalig von dem Bildgeber 400 zu dem FPGA 402. In dem FPGA 402 findet die Datenvorverarbeitung statt. Das Ergebnis wird im gemeinsamen Speicher von FPGA 402 und Mikrocontroller 406, nämlich dem RAM 404, abgelegt. Auf Basis dieser Ergebnisse berechnen im Mikrocontroller 406

zwei diversitäre Algorithmen die Objektdaten. Die Ergebnisse der diversitären Algorithmen werden in dem Komparator 420 verglichen.

In dem FPGA 402 werden die Bilddaten um definierte und nicht statische Test- muster 410 erweitert, die ohne Sonderbehandlung in dem FPGA 402 bearbeitet werden. Das Ergebnis der Testmuster 410 wird in dem MikroController 406 überprüft.

Voraussetzung ist die hinreichende Diversifizierung der Algorithmen auf Basis gleicher FPGA-Ergebnisse, was eine Vorverarbeitung ermöglicht, und dass hinreichend diversitäre Algorithmen auf einer fehlerhaften Hardware nicht zum gleichen Ergebnis kommen. Von Vorteil ist, dass das Hardware-Grundkonzept übernommen werden kann. Weiterhin vorteilhaft ist die gute Erkennung systematischer und zufälliger transienter/permanenter Fehler.

In Figur 6 ist die Detektion permanenter FPGA-Fehler verdeutlicht. Ein Bildgeber gibt Bilddaten 452 an ein FPGA 454. In diesem FPGA 454 wird zusätzlich ein Testmuster 456 erzeugt. In einer Einheit 458 erfolgt eine Testmusterverifikation, so dass ein Datensatz 460 mit Bilddaten 452 und Testmuster 456 vorliegt. Die Testmuster 456 zu Beginn und am Ende jedes Bildes ermöglichen eine vollständige Testabdeckung des FPGA 454 (pipelining im FPGA). Der Datensatz 460 wird weitergeleitet (Pfeil 462).

Das Testmuster 456 am Anfang und am Ende des eigentlichen Bildes stellt für den aktuellen Zyklus sicher, dass keine permanenten Fehler vorliegen. Die Muster sind nicht konstant, sondern werden in jedem Zyklus gegeneinander vescho- ben. Der Speicher in dem FPGA 454 wird vollständig abgetastet. Die Ergebnisse werden blockweise in der Ergebnisliste abgelegt. Die Position des Ergebnisblocks innerhalb der Liste wird ebenfalls rotiert. Der relevante Speicherbereich ist dadurch abgesichert.

In Figur 7 ist ein mögliches Komparatorkonzept gezeigt. Die Darstellung zeigt einen Komparator 500 mit zwei Eingängen, nämlich einen Kanal A 502 und einen Kanal B 504. Zu beachten ist, dass in jedem mehrkanaligen System der Ver- gleich der Kanäle 502 und 504 der einzige "single point of failure" ist.

Die Darstellung zeigt weiterhin einen SCON 506, einen CRC (cyclic redundancy check) 508, einen Nachrichtenzähler 510 und einen Fahrzeugbus 512. Zur überprüfung des Komparators 500 sendet der SCON 506 eine sogenannte Challenge (Pfeil 514) und empfängt eine Antwort bzw. Response (Pfeil 516). Je nach Aus- gang der überprüfung sendet der SCON 506 ein enable oder disable zu dem

Fahrzeugbus 512 (Pfeil 518).

Ein erster kritischer Fehlerfall, der sogenannte stuck-at-1 (permanente Zustimmung) muss erkannt werden. Der SCON 506 stellt eine Anfrage, die zur Ableh- nung führen muss. Antwortet der Komparator 500 falsch, gibt der SCON 506 den

Fahrzeugbus 512 nicht frei (disable).

Unkritische Fälle sind eine permanente Ablehnung (stuck-at-O), da das System fail-safe ist. Weiterhin unkritisch ist ein transienter einmaliger Fehler, der in Be- zug zur Fehler-Latenzzeit und der Trägheit der angesteuerten Aktuatorik zu vernachlässigen ist.