DE102015003928A1

DE102015003928A1 - Integrierte Schaltungsanordnung und Verfahren zur Prüfung der Sicherheitsintegrität und zur Gewährleistung der Verfügbarkeit von sicherheitsrelevanten Systemen

Info

Publication number: DE102015003928A1
Application number: DE102015003928.8A
Authority: DE
Inventors: Anmelder Gleich
Original assignee: Individual
Current assignee: Individual
Priority date: 2015-03-19
Filing date: 2015-03-19
Publication date: 2016-09-22

Abstract

Die Erfindung bezieht sich auf eine integrierte Schaltungsanordnung, die mindestens einen Satz von rekonfigurierbaren elektronischen Schaltungen umfasst und in einem sicherheitsrelevanten System verwendet wird. Die rekonfigurierbaren elektronischen Schaltungen werden zwecks einer Prüfung der Funktionstüchtigkeit von fehlererkennenden Sicherheitsmechanismen im betrachteten System und/oder zwecks der Bereitstellung der Funktionen von als fehlerhaft erkannten Komponenten angepasst werden. Ferner bezieht sich die Erfindung auf ein Verfahren zur Verwendung einer solchen integrierten Schaltungsanordnung in sicherheitsrelevanten Anwendungen.

Description

Die vorliegende Erfindung betrifft eine integrierte Schaltungsanordnung, wobei Schaltkreise zur Laufzeit selektiv rekonfiguriert werden, um die Sicherheitsintegrität von sicherheitsrelevanten Systemen zu prüfen und/oder die Verfügbarkeit derselben Systeme nach Erkennung einer Fehlersituation zu gewährleisten. Ferner betrifft die Erfindung ein Verfahren zur Prüfung der Sicherheitsintegrität und zur Gewährleistung der Verfügbarkeit von sicherheitsrelevanten Systemen mittels rekonfigurierbarer Schaltkreise.
BESCHREIBUNG
In modernen Kraftfahrzeugen führen programmierbare elektronische Steuergeräte (ECU: Electronic Control Unit) zunehmend komplexe und intelligente Funktionen aus. Für sicherheitsrelevante Anwendungen wie beispielsweise im Bereich der Fahrerassistenz und der Fahrwerksteuerung ist der Nachweis einer angeforderten Sicherheitsstufe sowohl für die Hardware als auch für die Software erforderlich. Das Kernstück der Hardware eines programmierbaren elektronischen Steuergeräts (ECU: Electronic Control Unit) bildet ein eingebetteter Mikrocontroller. Für diesen Mikrocontroller werden Softwareprogramme sowie eine Hardware-Architektur gemäß Normen der funktionalen Sicherheit wie der ISO 26262 entwickelt. Hardwareseitig werden Sicherheitsmechanismen zur Fehlererkennung im Mikrocontroller implementiert. Eine strukturelle Redundanz kann als fehlererkennender Sicherheitsmechanismus verwendet werden. Hierbei wird eine Hardware-Komponente mehrfach vorhanden sein, so dass Ausgänge von gleichen Komponenten zwecks einer Fehlererkennung verglichen werden. Aus Kostengründen wird nur die zweifache Redundanz typischerweise in der Automobilindustrie verwendet. Nicht-redundante weisen in der Regel eingebaute fehlererkennende Sicherheitsmechanismen wie beispielsweise eine CRC-Prüfung (CRC: Cyclic Redundancy Check) auf.
Nach dem Stand der Technik werden Sicherheitsmechanismen zur Laufzeit nicht ausreichend geprüft. Beispielsweise kann ein Fehler in CRC-Logikblöcken sehr lange unauffällig bleiben, da die Funktionstüchtigkeit der CRC-Logikblöcke nicht regelmäßig geprüft. Ein latenter Fehler in den logischen Gattern eines Sicherheitsmechanismus kann dafür sorgen, dass der entsprechende Sicherheitsmechanismus einen Fehler nicht erkennt und somit zu einer Gefährdung von Personen und/oder der Umwelt führen kann. Als Beispiel lässt sich die Implementierung von Kommunikationscontrollern wie dem CAN Controller in Mikrocontrollern heranführen. Ein CAN Controller weist folgende Hardware-basierte Sicherheitsmechanismen auf:

– Zyklische Redundanz-Prüfung (CRC: Cyclic Redundancy Check)
– Syntaktische Prüfung von Datentelegrammen (Form Check)
– Bit-Stuffing-Regel (Bit Stuffing Check)
– Bitüberwachung (Bit Monitoring)
– Prüfung des Bestätigungsbits (Acknowledge Check)

Die Funktionstüchtigkeit dieser Sicherheitsmechanismen wird in der Regel nur in der Entwicklungsphase intensiv geprüft. Somit kann der Ausfall eines CAN Sicherheitsmechanismus zur Laufzeit im normalen Betriebsmodus unauffällig bleiben und das Auftreten eines latenten Fehlers ermöglichen. Daher ist eine Verbesserung der Implementierung von sicherheitsrelevanten Systemen hinsichtlich einer Erkennung von latenten Fehlern in funktionalen Sicherheitsmechanismen im normalen Betriebsmodus von elektronischen Steuergeräten (ECU) sehr wünschenswert. In Anbetracht von modernen Normen der funktionalen Sicherheitsnormen gelten Sicherheitsmechanismen in einem sicherheitsbezogenen System als zuverlässig, wenn sie zur Laufzeit im normalen Betriebsmodus getestet werden können. Diese Anforderung zielt auf die frühzeitige Erkennung von latenten Fehlern in Sicherheitsmechanismen ab.
In vielen Automotive-Anwendungen werden sicherheitsrelevante elektronische Funktionen ausgeschaltet, nachdem ein Sicherheitsmechanismus einen Fehler erkannt hat. Hierbei gilt das Ausschalten einer sicherheitsrelevanten Funktion als ein sicherer Zustand. Als Beispiele hierfür lassen sich ABS (ABS: Antiblockiersystem) und (ESP: Elektronisches Stabilitätsprogramm) Regelfunktionen nennen. Die hydraulische Bremsanlage dient als Rückfallebene für die ABS und ESP elektronischen Regelfunktionen. In Elektro-Fahrzeugen ist diese hydraulische Rückfallebene nicht vorhanden. Das Bremsen erfolgt mittels einer elektronischen Steuerung von dedizierten Elektromotoren. Das Ausschalten dieser elektronischen Steuerung nach Erkennung eines Fehlers wäre in diesem Fall kein sicherer Zustand, da die Bremsfunktion für das entsprechende Rad nicht mehr vorhanden wäre. In diesem Fall ist eine Erhöhung der Verfügbarkeit der elektronischen Steuerung neben der Erfüllung von funktionalen Sicherheitsanforderungen unausweichlich.
Dieser Offenbarung liegt nun die Aufgabe zugrunde, einen effektiven Weg zur Gewährleistung der funktionalen Sicherheitsintegrität im Hinblick auf die frühzeitige Erkennung von latenten Fehlern in Sicherheitsmechanismen sowie eine kostengünstige Möglichkeit zur Erhöhung der Verfügbarkeit von sicherheitsrelevanten Systemen vorzuschlagen. Das funktionale Sicherheitskonzept eines Unternehmens beruht in der Regel auf einer bewährten Architektur des eingebetteten Mikrocontrollers und dessen Verbindungen zu anderen elektronischen Komponenten. Diese Offenbarung schlägt vor, eine bewährte Architektur eines Mikrocontrollers mit rekonfigurierbaren Logikblöcken gezielt zu ergänzen. Die Vermischung von festverdrahteten und rekonfigurierbaren Logikblöcken ist an sich nicht neu und wurde beispielsweise in den XILINX ZYNQ-7000 und ALTFRA Cyclone-V integrierten Bausteinen bereits realisiert. Als Zielarchitekturen für sicherheitsrelevante Anwendungen rufen solche universalen Plattformen einen hohen Aufwand in der Validierungsphase des Sicherheitskonzepts hervor, da die daraus resultierenden Suchräume für die Fehlerbaumanalyse (FTA: Fault Tree Analysis) sowie für die Fehlermöglichkeits- und Einflussanalyse (FMEA: Failure Mode and Effect Analysis) einen sehr hohen Komplexitätsgrad erreichen kann. Gemäß dieser Offenbarung werden rekonfigurierbare Logikblöcke maßgeschneidert in eine bewährte Sicherheitsarchitektur eingefügt. Eine grundsächliche Veränderung der betrachteten Sicherheitsarchitektur wird vorteilhaft vermieden, um die nach jahrelanger Erfahrung erreichte funktionale Sicherheitsintegritätsstufe nicht zu beeinträchtigen. Nach vorgegebenen oder vorgebbaren Kriterien werden sicherheitsrelevante Module der Sicherheitsarchitektur in Gruppen aufgeteilt. Jeder Gruppe wird ein Satz von logischen rekonfigurierbaren Blöcken zugewiesen, die auf die möglichen Konfigurationsszenarien gemäß dieser Offenbarung zugeschnitten sind. Die zugefügten rekonfigurierbaren Logikblöcke werden vorteilhaft so verwendet, dass sie im normalen Betriebsmodus zur Prüfung der Funktionstüchtigkeit der in der Sicherheitsarchitektur vorhandenen Sicherheitsmechanismen dienen und nach Erkennung und Lokalisierung eines Fehlers das fehlerhafte Modul ersetzen.
Die vorgeschlagene Lösung lässt sich wie folgt anhand von zwei redundanten Modulen näher darstellen. Die zwei Module werden mit den gleichen Daten eingespeist und laufen synchron zueinander. Ausgangssignale dieser Module werden umgehend verglichen. Somit gilt der Komparator dieser Ausgangssignale als Sicherheitsmechanismus. Ein Satz von logischen rekonfigurierbaren Blöcken wird den zwei redundanten Modulen zugewiesen. Im normalen Betriebsmodus werden diese rekonfigurierbaren Logikblöcke als ein Testmodul für den Komparator vorbereitet. Die rekonfigurierebaren Logikblöcke werden so angeschlossen, dass sie abwechselnd und in einer beabsichtigten Weise die Eingangswerte des Komparators verfälschen können. Hierfür werden kurze Testintervalle im normalen Betriebsmodus vorgesehen. In einem Testintervall werden die rekonfigurierbaren Logikblöcke mindestens einen Test für den Komparator generieren und durchführen, so dass eine hohe Fehlerabdeckung für diesen Komparator nach einer vorgegebenen oder vorgebbaren Zeitdauer erreicht wird. Bei der Bestimmung dieser Zeitdauer kann die statistisch mittlere Zeitdauer zwischen zwei Ausfällen (MTBF: Mean Time Between Time) vorzugsweise in Betracht gezogen werden.
Falls der Komparator einen Fehler meldet, soll das ganze elektronische System nicht wie in einer herkömmlichen Anwendung ausgeschaltet werden, stattdessen soll das fehlerhafte redundante Modul ermittelt werden und selektiv deaktiviert. Nach Erkennung des Fehlers werden die Ausgänge der redundanten Module vom Rest des Systems getrennt. Anschließend werden eingebaute partielle Selbsttests (partial BIST: Built-in-self-tests) in jedem redundanten Modul durchgeführt, um festzustellen, ob ein permanenter Hardwarefehler vorliegt. Wenn der Hardwarefehler nur transient war, werden die nachträglich durchgeführten BISTs die zwei redundanten Module als fehlerfrei angezeigt haben. Im Falle eines permanenten Fehlers wird ein redundantes Modul als fehlerhaft identifiziert. Das als fehlerfrei befundene Modul wird zur Gewährleistung der Verfügbarkeit des elektronischen Systems weiter verwendet. Um die Sicherheitsstufe des elektronischen Systems weiter hoch halten zu können, werden die zugewiesenen rekonfigurierbaren Logikblöcke vorzugsweise so angepasst, dass das fehlerbehaftete Modul ergänzt wird. Somit kann der auf der Modulredundanz basierende Sicherheitsmechanismus wieder realisiert werden. Vor und/oder nach der Anpassung der rekonfigurierbaren Logikblöcke werden BIST-Verfahren für digitale rekonfigurierbare Schaltkreise angewandt.
Ein weiteres Beispiel für die Verwendung der vorgeschlagenen Lösung bezieht sich auf die frühe Erkennung von latenten Fehlern in funktionalen Sicherheitsmechanismen sowie auf eine Erhöhung der Verfügbarkeit von Kommunikationscontrollern. In mehreren sicherheitsrelevanten Anwendungen tauschen Mikrocontroller Daten über verschiedene Kommunikationscontroller wie beispielsweise über CAN, Ethernet oder FlexRay Controller aus. Gemäß der vorgeschlagenen Lösung wird eine Menge von rekonfigurierbaren Logikblöcken einer Gruppe von Kommunikationscontrollern zugeordnet. Hierbei können die ausgewählten Kommunikationscontroller vom gleichen Typ oder unterschiedlich sein. Im normalen Betriebsmodus werden die zugeordneten rekonfigurierbaren Logikblöcke nach einer vorgegebenen oder vorgebbaren Zeitdauer so angepasst, dass ein Prüfungszeitschlitz für jeden Kommunikationscontroller vorgesehen wird. In diesem Zeitschlitz werden Sicherheitsmechanismen des betrachteten Kommunikationscontrollers im Hinblick auf latente Fehler geprüft. Für jede Fehlerart und jeden zu prüfenden Sicherheitsmechanismus erfolgt eine gezielte Fehlerstimulation mittels der rekonfigurierbaren Logikblöcke. Der Prozessor in einem einfachen Mikrocontroller oder mindestens ein Prozessor in einem Multiprozessor-fähigen Mikrocontroller wird so programmiert, dass er die Prüfung von Sicherheitsmechanismen von allen Kommunikationscontrollern in einer vorgegebenen oder vorgebbaren Reihenfolge initiiert und überwacht. In einem Kraftfahrzeug kann die Prüfung der funktionalen Sicherheitsintegrität von Sicherheitsmechanismen von Kommunikationscontrollern beispielsweise immer nach dem Einschalten oder nach dem Ausschalten der Zündung des Motors erfolgen. Hierbei soll die Zeitdauer der Prüfung kleiner gehalten werden, so dass die Prüfung ohne großen Aufwand in die herkömmlichen Testsequenzen der elektronischen und programmierbaren Komponenten in einem Kraftfahrzeug während der Zündungs- oder der Ausschaltphase integriert werden kann. Nach dem Stand der Technik wäre eine Zeitdauer kleiner als 50 Millisekunden vorstellbar.
Falls ein Fehler in einem Sicherheitsmechanismus erkannt wird, sorgt ein Fehlermanagement-Modul dafür, dass der entsprechende Kommunikationscontroller nicht mehr am Datentransfer über den Datenbus teilnimmt. Je nach interner Auslegung kann die Trennung vom Datenbus unmittelbar erfolgen oder erst, nachdem der betroffene Kommunikationscontroller eine Mitteilung über seine anstehende Nichtverfügbarkeit an andere Kommunikationsteilnehmer gesendet hat. Nach der Trennung des Kommunikationscontrollers vom Datenbus werden eingebaute Selbsttests (BIST: Built-in-self-tests) sowohl im betroffenen Kommunikationscontroller als auch in den zur Überwachung verwendeten rekonfigurierbaren Logikblöcken. Falls ein permanenter Fehler im Kommunikationscontroller bestätigt wird, werden die zugehörigen rekonfigurierbaren Logikblöcke so angepasst, dass der komplette Kommunikationscontroller oder nur Teile des Kommunikationscontrollers ersetzt werden. Nach dieser Anpassung können eingebaute Selbsttests (BIST: Built-in-self-tests) für die neue Konfiguration der rekonfigurierbaren Logikblöcke stattfinden.
Falls eingebaute Selbsttests (BIST: Built-in-self-tests) einen Fehler in den rekonfigurierbaren Logikblöcken anzeigen, dürfen diese rekonfigurierbaren Logikblöcke nicht mehr zuverlässig weder zur Prüfung der funktionalen Integrität von Sicherheitsmechanismen noch zur Gewährleistung der Verfügbarkeit verwendet werden. Folglich muss der Fehler signalisiert werden, indem der passende Fehlercode beispielsweise in den Fehlerspeicher eines Fahrzeugs oder eines elektronischen Steuergeräts eingetragen wird. Wenn eine Störung sich als transienter Fehler erweist, werden der Fehlertyp sowie eine Zeitangabe des Fehlereintritts zwecks der Verfolgbarkeit von transienten Fehlern aufgenommen. Falls der gleiche Fehlertyp mit einer vorgegebenen oder vorgebbaren Häufigkeit auftritt, werden die zugeordneten rekonfigurierbaren Logikblöcke nach einer Durchführung von geeigneten eingebauten Selbsttests (BIST: Built-in-self-tests) so angepasst, dass der mit transienten Störungen behaftete Kommunikationscontroller ersetzt wird. Je nach Anwendung können diese eingebauten Selbsttests (BIST: Built-in-self-tests) im Offline- und/oder Online-Betrieb durchgeführt werden.
ZEICHNUNGEN
Die Erfindung wird im Weiteren anhand von folgenden Zeichnungen näher erläutert.
Es zeigen:
1 eine schematische Darstellung der Module in einer herkömmlichen Sicherheitsarchitektur,
2 den Aufbau einer herkömmlichen Integration von festverdrahten und rekonfigurierbaren Logikblöcken in Form einer SoPC (System an Programmable Chip) Plattform,
3 eine erfindungsgemäß vorgeschlagene Zuordnung von rekonfigurierbaren Logikblöcken zu den sicherheitsrelevanten Modulen eines Mikrocontrollers,
4 eine erfindungsgemäß angepasste Integration eines Paars redundanter Module mit rekonfigurierbaren Logikblöcken in einer Sicherheitsarchitektur,
5 eine erfindungsgemäß angepasste Integration von zwei Paaren redundanter Module mit rekonfigurierbaren Logikblöcken in einer Sicherheitsarchitektur eines Mikrocontrollers,
6 eine herkömmliche Sicherheitsarchitektur eines Mikrocontrollers mit zwei Paaren redundanter Prozessorkerne,
7 eine Anpassung der in 6 dargestellten Sicherheitsarchitektur mit rekonfigurierbaren Logikblöcken nur im Peripherie-Bereich des Mikrocontrollers,
8 die in 7 dargestellte Architektur mit einem Fehler in einem Peripherie-Modul,
9 eine Anpassung der in 7 dargestellten Sicherheitsarchitektur mit rekonfigurierbaren Logikblöcken im Peripherie-Bereich sowie im Bereich der Prozessorkerne des Mikrocontrollers,
10 beispielsweise ein Ablaufdiagramm zur Verwendung der vorgeschlagenen Anpassung von Sicherheitsarchitekturen von Mikrocontrollern,
11 die Verbindung der in 9 geschilderten Systemarchitektur mit einem externen Diagnosegerät über einen Datenbus.
In einer herkömmlichen Sicherheitsarchitektur einer Schaltungsanordnung werden unterschiedliche Sicherheitsmechanismen zur Fehlererkennung eingebaut. Für jedes sicherheitsrelevante Modul können diese Sicherheitsmechanismen intern oder als externes Modul implementiert werden. Hierbei erfüllt ein Modul oder eine Gruppe von Modulen eine bestimmte Regel-, Überwachung- und/oder Regelaufgabe. In 1 dienen die Module 1'', 2'' und 3'' zur Überwachung der Module 1, 2 und 3 jeweils. Hierbei kann ein solches Modul 1'', 2'' oder 3'' eine exakte Kopie des zu überwachenden Moduls 1, 2 oder 3 oder nur die gleiche Funktion implementieren. Für jedes Paar (1, 1''), (2, 2'') oder (3, 3'') werden die Ausgänge kontinuierlich verglichen. Weitere Module wie die Kommunikationscontroller 6 und 8 in 1 weisen interne Sicherheitsmechanismen wie die CRC-Prüfung (CRC: Cyclic Redundancy Check) auf. Falls ein der in den Modulen 6 und 8 eingebauter Sicherheitsmechanismus ausfällt, wird der Fehler nach dem Stand der Technik nicht erkannt, da ein Test von fehlererkennenden Sicherheitsmechanismen nicht vorgeschrieben und dementsprechend nicht implementiert ist. Falls der Komparator für ein Modulpaar (1, 1''), (2, 2'') oder (3, 3'') fehlerhaft ist oder ein interner fehlererkennender Sicherheitsmechanismus in einem Modul unauffällig ausgefallen ist, wird ein latenter Fehler in diesem Fall vorliegt. Ein solcher latenter Fehler kann in Zusammenhang mit einem anderen Fehler zu einer Gefährdung führen. In herkömmlichen Sicherheitsarchitekturen weisen in der Regel kein systematisches Prüfverfahren zur frühen Erkennung von solchen latenten Fehlern auf.
Rekonfigurierbare Logikblöcke bergen die Möglichkeit zur Verbesserung der Verfügbarkeit von Systemen in sich. Nach Erkennung eines Fehlers können rekonfigurierbare Logikblöcke dynamisch angepasst werden, so dass die gewünschte Funktion gewährleistet wird. 2 zeigt eine herkömmliche Integration von festverdrahteten und rekonfigurierbaren Logikblöcken innerhalb einer SoPC (System an Programmable Chip) Architektur. Hierbei werden rekonfigurierbare Logikblöcke zusammenhängend im Modul 16 zur Verfügung gestellt. Eine solche Zusammenlegung in einem oder mehreren Modulen bietet den Vorteil, dass die vorhandenen rekonfigiurierbaren Logikblöcke universal angepasst werden können, um ein anderes Modul 4, 5, 6, 7 oder 8 funktional zu ersetzen oder ein zusätzliches Module mit einer anderen Funktion zu implementieren. Eine solche SoPC Architektur zeigt jedoch Nachteile, wenn eine hohe Verfügbarkeit eines Systems in Zusammenhang mit funktionalen Sicherheitsanforderungen angestrebt wird. Aus dem daraus resultierenden großen Rekonfigurationsspektrum ergeben sich sehr komplexe Muster für die Analyse von möglichen Fehlern. Die entsprechenden Fehlerbaumanalyse (FTA: Fault Tree Analysis) und Fehlermöglichkeits- und Einflussanalyse (FMEA: Failure Mode and Effect Analysis) werden einen hohen Aufwand hervorrufen. Weiterhin ist eine physikalische Trennung zwischen rekonfigurierbaren Logikblöcken erforderlich, wenn diese Blöcke als Ersatzkomponenten von unterschiedlichen sicherheitsrelevanten Modulen vorgesehen werden. Zwischen verschiedenen sicherheitsrelevanten Bereichen einer Sicherheitsarchitektur müssen mögliche Interferenzen oder gemeinsame Fehlerursachen (Common-Cause Failures/CCF) vermieden werden. Hinzu kommt auch die Tatsache, dass eine auf Funktionen bezogene partielle Durchführung von eingebauten Selbsttests (BIST: Built-in-self-tests) ohne klare physikalische Trennung auf der Layout-Ebene erschwert wird.
Um diese Nachteile zu umgehen, schlägt die vorliegende Offenbarung eine Partitionierung einer Sicherheitsarchitektur vor, bei der jede Partition ein oder mehrere Module der Sicherheitsarchitektur sowie die ihr zugeteilten rekonfigurierbaren Logikblöcke umfasst. Diese Partitionierung ist in 3 veranschaulicht. In jeder Partition 21, 22, 23 oder 24 soll die ausgewählte Menge von rekonfigurierbaren Logikblöcken zur Prüfung der Sicherheitsmechanismen sowie zur Verbesserung der Verfügbarkeit der betroffenen Module dienen. Da der Konfigurationsraum auf die Funktionen und Sicherheitsmechanismen der in einer Partition vorhandenen Module beschränkt ist, lässt sich der Aufwand der Fehleranalysen (Fehlerbaumanalyse/FTA: Fault Tree Analysis, Fehlermöglichkeits- und Einflussanalyse/FMEA: Failure Mode and Effect Analysis, ...) in beherrschbaren Rahmen halten. Der Partition 24 beispielsweise wird der Satz 34 von rekonfigurierbaren Logikblöcken so zugeschnitten, dass die fehlererkennenden Sicherheitsmechanismen der sicherheitsrelevanten Module 6, 7 und 8 der Reihe nach geprüft werden können. Nötigenfalls kann der Satz 34 von rekonfigurierbaren Logikblöcken angepasst werden, um jedes der sicherheitsrelevanten Module 6, 7 und 8 zu ersetzen. Weiterhin ermöglicht diese Partitionierung eine effiziente Durchführung von eingebauten partiellen Selbsttests (partial BISTs). Lokale partielle BISTs können in einer Partition einwandfrei durchgeführt werden, ohne die Funktionen von anderen Partitionen zu beeinträchtigen. Für redundante Module kann eine Partition einem einzigen Modulpaar oder einer Gruppe von Modulpaaren zugeordnet werden. 4a zeigt eine herkömmliche Sicherheitsarchitektur, in der die redundanten Module 1 und 1'' synchron laufen und immer die gleichen gültigen Ausgangssignale liefern sollen. Hierbei wird nur ein Module 1 oder 1'' als aktive Komponente weiter geschaltet, während das andere Modul zur Überwachung verwendet wird. Diese Ausgangssignale werden anhand des Komparators 11 fortlaufend verglichen. Erfindungsgemäß werden nun rekonfigurierbare Logikblöcke hinzugefügt, um die Funktionstüchtigkeit des Komparators 11 prüfen zu können und gegebenenfalls ein Modul 1 oder 1'' nach dessen Ausfall zielgerecht zu ersetzen. Für das Modulpaar (1, 1'') wird die rekonfigurierbare Einheit 31 verwendet. Wie in 4b veranschaulicht, werden diese rekonfigurierbaren Logikblöcke innerhalb der rekonfiguriebaren Einheit 31 im normalen Betriebsmodus so angepasst, dass Testmuster für den Komparator 11 generiert werden können. Hierfür wird die Untermenge 110 von rekonfigurierbaren Logikblöcken direkt mit dem Komparator 11 verbunden. Falls ein der zwei redundanten Module 1 oder 1'' nach der Durchführung von eingebauten partiellen Selbsttests (partial BIST) als fehlerhaft identifiziert wird, lässt sich die Untermenge 112 von rekonfigurierbaren Logikblöcken als Ersatzmodul so verwenden, die Untermenge 110 als eine Erweiterung des Komparators 11 konfiguriert. Mit dem 3-zu-1 Multiplexer 111 wird das aktive Modul unter den redundanten Modulen 1, 1'' und dem Ersatzmodul 112 bestimmt. Die Anpassung von sämtlichen rekonfigurierbaren Logikblöcken innerhalb der Funktionseinheit 31 wird durch das Steuerwerk 115 gemäß vorhandener Konfigurationsszenarien 114a, 114b, ... und 114n angesteuert und überwacht. Dieses für das Modulpaar (1, 1'') verwendete Konzept kann erweitert werden, um das Generieren von Testmustern für Komparatoren sowie die Bereitstellung von Ersatzmodulen für mehrere Modulpaare mittels einer einzigen rekonfigurierbaren Einheit zu ermöglichen. Beispielsweise steht die rekonfigurierbare Einheit 32 in 3 für die Modulpaare (2, 2'') und (3, 3'') zur Verfügung. Eine Beschaltung dieser Modulpaare in einer herkömmlichen Sicherheitsarchitektur ist in 5a veranschaulicht, während 5b eine erfindungsgemäß erweiterte Sicherheitsarchitektur zeigt. Für jedes Modulpaar (2, 2'') oder (3, 3'') wird jeweils ein 3-zu-1 Multiplexer 121 oder 131 implementiert, um die Auswahl des aktiven Moduls zu ermöglichen. Die rekonfigurierbare Einheit 32 wird im normalen Betriebsmodus so konfiguriert, dass sie die Funktionsblöcke 120, 130, 150, 151, 160, 161 und 170 umfasst. Hierbei werden die Funktionsblöcke 120 und 130 im normalen Betriebsmodus zum Testen der Komparatoren 12 und 13 dienen. Wenn ein der redundanten Module aufgrund eines erkannten Fehlers ersetzt wird, können die im Funktionsblock 120 oder 130 verwendeten rekonfigurierbaren digitalen Schaltkreise für die Bildung eines passenden Komparators in Betracht gezogen werden. Die vorgesehenen Konfiguration 171a bis 171n werden in einem nicht-flüchtigen Speicher vorliegen und zur Laufzeit je nach Bedarf in den Funktionsblock 170 geladen. Der Funktionsblock 150 überwacht das Umschalten zwischen den verschiedenen Konfigurationen und unterstützt auch das Generieren von Testmustern für die Komparatoren 12 und 13 sowie die Bereitstellung eines Ersatzmoduls nach dem Ausfall eines Teils in einem Modulpaar (2, 2'') oder (3, 3''). Vor jeder neuen Konfigurationsänderung der rekonfigurierbaren Einheit 31 werden die entsprechenden eingebauten partiellen FPGA Selbsttests (partial FPGA BIST) für programmierbare logische Schaltungen (FPGA: Field Programmable Gate Array). Die Ausführung der eingebauten partiellen FPGA Selbsttests (partial FPGA BIST) wird vom Funktionsblock 150 überwacht.
In der in 6 veranschaulichten herkömmlichen Sicherheitsarchitektur eines Mikrocontrollers 40 wird jeder Prozessorkern 102 oder 112 nach dem Redundanzprinzip überwacht. Bei einer symmetrischen Redundanz sind die im Paar gekoppelten Prozessorkerne (102, 102'') oder (112, 112'') identisch, während asymmetrische Paare diese Eigenschaft nicht aufweisen. Jedem Paar von redundanten Prozessorkernen (102, 102'') und (112, 112'') ist ein Komparator 204 oder 214 zugeordnet, der jeglichen Unterschied bei jedem gültigen Datenzugriff der Prozessorkerne erkennen soll. Jeder Prozessorkern 102, 102'', 112 oder 112'' verfügt jeweils über eine eigene Debug-Schnittstelle. Diese Debug-Schnittstellen 203, 203'', 213 und 213'' sowie die Debug-Pins 262 sind an dem internen zentralen Debugger-Hardwaremodul 230 angeschlossen. In einer Entwicklungsumgebung kann ein Debug-Adapter 70 mittels einer Verbindung mit den Debug-Pins 262 dazu dienen, Debugger-Kommandos in den Mikrocontroller zu transportieren und einen Datenaustausch zwischen der Entwicklungsumgebung und internen Komponenten des Mikrocontrollers anzusteuern. Über eine Busmatrix 220 können die vorhandenen Prozessorkerne auf Speicherblöcke 221 und 222 sowie auf Peripherie-Module 241, 242, 243 und 244 zugreifen. Hierbei ist die Anzahl von Speicherblöcken und Peripherie-Modulen implementierungsabhängig. In der Regel zählt die Redundanz nicht zu den Sicherungsmechanismen von Peripherie-Modulen in sicherheitsrelevanten Mikrocontrollern, bei denen eine Reduzierung der Implementierungskosten wie beispielsweise im Automotive-Bereich angestrebt wird. Stattdessen weisen Peripherie-Module gewöhnlich eingebaute fehlererkennende Sicherheitsmechanismen auf. Nach dem Stand der Technik wird die Funktionstüchtigkeit der in einem Peripherie-Modul eingebauten Sicherheitsmechanismen zur Laufzeit nicht getestet. Somit kann der Ausfall eines Sicherheitsmechanismus lange Zeit unentdeckt bleiben und in Form eines latenten Fehlers zu einer Gefährdung beitragen.
In 7 wird eine Partition 411 im Mikrocontroller 41 so definiert, dass eine aus rekonfigurierbaren Logikblöcken bestehende Einheit 302 einer Gruppe von Peripherie-Modulen 241, 242, 243 und 244 zugeordnet wird. Bestehend aus rekonfigurierbaren Logikblöcken wird das Steuerwerk 301 Steuersignale für die Einheit 302 in verschiedenen Konfigurationsszenarien generieren und die Überwachung der Konfigurationsänderungen unterstützen. Im Modul 303 werden Daten für verschiedene Konfigurationsszenarien vollständig oder teilweise bereitgehalten. Zur Betriebszeit wird die Einheit 302 nach einer vorgegebenen oder vorgebbaren Zeitdauer rekonfiguriert, um ein oder mehrere Sicherheitsmechanismen von jedem der vorhandenen Peripherie-Module 241, 242, 243 oder 244 zu prüfen. Hierfür wird die rekonfigurierbare Einheit 302 mittels der rekonfigurierbaren Logikblöcke der Einheit 312 auf Schnittstellen der zu prüfenden Peripherie-Module zugreifen. Ein Kommunikationscontroller als Peripherie-Modul wird beispielsweise Daten bitseriell durch RX und TX Leitungen mit der rekonfigurierbare Einheit 302 austauschen. Somit kann die Einheit 302 Sicherheitsmechanismen eines Kommunikationscontrollers gezielt mit fehlerhaften Datentelegrammen prüfen. Die Anbindung der Einheit 312 kann ohne Veränderung oder mit einer zweckmäßigen Anpassung der Schnittstelle eines Peripherie-Moduls realisiert werden. In 8 wird das Peripherie-Modul 243 beispielsweise verändert, so dass weitere Zugriffsmöglichkeiten für die rekonfigurierbare Einheit 312 in das angepasste Peripherie-Module 243'' realisiert werden. Die Konfigurationsszenarien werden so ausgelegt, dass eine hohe Abdeckung bei der Erkennung von Fehlern in Sicherheitsmechanismen aller Peripherie-Module der betrachteten Partition 411 angestrebt wird. Das Zeitintervall zwischen zwei aufeinanderfolgenden Prüfvorgängen von den gleichen Sicherheitsmechanismen wird vorzugsweise von der mittleren Betriebsdauer zwischen Ausfällen (MTBF: Mean Time Between Failures) oder bis zum Ausfall (MTTF: Mean Time to Failure) abgeleitet. Ein Fehler in einem Peripherie-Modul wie beispielsweise im Peripherie-Modul 241 gemäß der Darstellung in 8 kann entweder eine Funktion oder einen Sicherheitsmechanismus beeinträchtigen. Ein Fehler in einer implementierten Funktion soll durch im Peripherie-Modul 241 vorhandene Sicherheitsmechanismen erkannt werden, während die Erkennung eines Fehlers in einem Sicherheitsmechanismus mithilfe der vorgeschlagenen rekonfigurierbaren Funktionseinheit 302 in der Partition 411 erfolgen soll. Nach Erkennung eines Fehlers im Peripherie-Modul 241 wird das rekonfigurierbare Steuerwerk 301 den Fehlerzustand beispielsweise mittels einer Unterbrechungsanforderung (Interrupts) an ein der Paare oder an alle Paare von redundanten Prozessorkernen (202, 202'') und (212, 212'') melden. Daraufhin wird eine kurze Auszeit entweder für den ganzen Mikrocontroller 41 oder nur für die Partition 411 und die betroffenen Funktionen angelegt, um eingebaute partielle Selbsttests (Partial BISTs) für die als fehlerhaft eingestufte Partition durchzuführen. Diese Tests sollen die fehlerhaften Komponenten in der Partition herausfinden, damit die Auswahl der passenden Konfiguration zur Erhaltung der hohen Verfügbarkeit der betroffenen Funktionen ermöglicht wird. Danach wird die rekonfigurierbare Funktionseinheit 302 so angepasst, dass sie als Ersatz des ausgefallenen oder fehlerhaften Peripherie-Moduls 241 fungiert. Durch den Multiplexer 252 wird die angepasste Funktionseinheit 302 auf alle Pins zugreifen, die dem ausgefallenen oder fehlerhaften Peripherie-Modul 241 zugeordnet waren. Somit kann der Mikrocontroller 41 mit der angepassten Funktionseinheit 302 als Ersatz des ausgefallenen oder fehlerhaften Peripherie-Moduls 241 weiter funktionsfähig bleiben.
Das anhand von 8 erläuterte Konzept lässt sich auch auf die Prüfung von Sicherheitsmechanismen von oder in Prozessorkernen erweitern. Ein Beispiel hierfür ist in 9 geschildert. Der Mikrocontroller 42 umfasst zwei Prozessorpaare (202, 202'') und (212, 212''), wofür eine Partition 422 vorgesehen ist. In dieser Partition wird eine rekonfigurbare Funktionseinheit 353 zur normalen Betriebszeit die Komparatoren 204 und 214 prüfen. Ähnlich wie in 5 werden die gleichen rekonfigurabren Logikblöcke den zwei Prozessorpaaren (202, 202'') oder (212, 212'') zugeordnet. Mit den rekonfigurierbaren Teilen 355 und 356 können Fehlermuster für die Komparatoren 204 und 214 vorbereitet und zu den richtigen Zeitpunkten eingespeist, um die Funktionskorrektheit der Komparatoren zu prüfen. Wenn ein Fehler in einem Komparator 204 oder 214 erkannt wird, meldet die rekonfigurbare Funktionseinheit 353 den Fehler an das entsprechende Prozessorpaar (202, 202'') oder (212, 212''). Daraufhin wird eine Unterbrechung (Interrupt) ausgelöst, um die Durchführung von eingebauten partiellen Selbsttests (Partial BISTs) sowohl von festverdrahteten als auch von rekonfigurierbaren Logikblöcken in der Partition 422 vorzubereiten. Für diese Durchführung ist eine vorgegebene oder vorgebbare Zeitdauer, nach der ein Ergebnis der eingebauten partiellen Selbsttests (Partial BISTs) erwartet wird.
Wenn die BISTs einen Prozessor als fehlerhaft identifizieren, wird die rekonfigurierbare Einheit 353 zur Bildung einer neuen Recheneinheit als Ersatz dieses Prozessors oder des entsprechenden Prozessorpaars angepasst. Dafür werden zusätzliche rekonfigurierbare Logikblöcke in den funktionalen Einheiten 352, 360, 361, 362, 363 und 364 so verbunden, dass das Debugging vom in der rekonfigurierbaren Einheit 353 zu bildenden Prozessor oder Prozessorpaar ermöglicht wird. Die rekonfigurierebare Einheit 360 wird die Funktionalität der internen Hardware-Debugger Einheit 351 erweitern.
Ein weiterer Vorteil der in 7, 8 und 9 veranschaulichten Architekturen besteht darin, dass ein auf einem Prozessorkern laufende Softwareprogramm die Prüfung eines Sicherheitsmechanismus anfordern kann. Eine solche Anforderung wird in 9 an die rekonfigurierbare Einheit 302 über das Modul 311 gesendet, so dass die entsprechenden Konfigurationsszenarien ausgewählt und durchgeführt werden. Als Anlass dieser Anforderungsart kann eine Fehlermeldung dienen. Weiterhin kann ein Softwareprogramm eine solche Anforderung in der Start- und/oder in der Endphase einer Anwendung sowie je nach Auslegung zu einem beliebigen Zeitpunkt stellen.
Wie in 10 geschildert, wird die ganze Anwendung nach der Meldung eines internen Fehlers zuerst angehalten. In jeder Partition, die vom Fehler betroffen ist, werden eingebaute partielle Selbsttests (partial BISTs) sowohl für festverdrahtete als auch für rekonfigurierbare Logikblöcke durchgeführt. Für festverdrahtete Logikblöcke sollen die entsprechenden BISTs 702 zur Fehlerlokalisierung beitragen, um die Auswahl der passenden Konfiguration zu ermöglichen. Diese BISTs 702 sollen vorzugsweise eine sehr hohe Fehlerabdeckung aufweisen. Wenn kein Fehler von den BISTs 702 bestätigt wird, kann die Entscheidung im Block 706 getroffen werden, ob der Fehler nur transient war und ob die Anwendung nach Ergreifung von vorgegebenen oder vorgebbaren Maßnahmen wieder in Betrieb genommen wird. Die BISTs 701 sollen feststellen, ob die rekonfigurierbaren Logikblöcke noch zuverlässig zur Gewährleistung der Verfügbarkeit der Anwendung verwendet werden können. Falls die BISTs 701 einen Fehler erkennen, wird eine Anpassung der rekonfigurierbaren Logikblöcke in der betroffenen Partition nicht mehr als Möglichkeit zur Gewährleistung der Verfügbarkeit der Anwendung in Betracht gezogen. Die vorgeschlagene Vorgehensweise zur Erhöhung der Verfügbarkeit einer Anwendung kommt in der Phase 710 zum Einsatz, wenn eine genaue Fehlerlokalisierung in den festverdrahteten Schalkreisen erfolgt und kein Fehler in den rekonfigurierbaren Logikblöcken erkannt wird. Nach einer Anpassung der rekonfigurierbaren Logikblöcke wird das ganze System hinsichtlich der gezielten Funktionen in der Phase 711 noch einmal geprüft. Eine Wiederherstellung der Anwendung mit sämtlichen Funktionen in der Phase 712 ist nur nach einem erfolgreichen Abschluss der Prüfungsphase 711 zulässig.
Die vorgeschlagene Lösung kann auch im Offline-Betrieb angewandt werden. 11 zeigt, wie ein Diagnosegerät 95 über ein Bussystem 91 auf die elektronischen Steuergeräte 90a und 90b eines Kraftfahrzeugs 99 zugreift. Das Diagnosegerät 95 kann Konfigurationsszenarien eines Mikrocontrollers 42a oder 42b aktualisieren. Weiterhin kann eine Anpassung der rekonfigurierbaren Logikblöcke einer funktionalen Partition in einem Mikrocontroller 42a oder 42b mithilfe eines Diagnosegeräts 95 durchgeführt und geprüft werden. Hierfür werden Software-Erweiterungsmodule 96 hinzugefügt, die im Diagnosegerät 95 die Ausführung der oben erwähnten neuen Funktionen übernehmen. Gegebenenfalls wird die Hardware-Implementierung des Diagnosegeräts 95 angepasst, um beispielsweise Daten für verschieden Konfigurationsszenarien speichern zu können.
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 Nicht-Patentliteratur

ISO 26262 [0002]

Claims

Eine integrierte Schaltungsanordnung (20), deren elektronische Schaltkreise nach Funktionszugehörigkeit zuordenbar sind, wobei mindestens eine Funktion eine Rechen-, eine Überwachungs-, und/oder eine Regelaufgabe erfüllt und/oder eine Datenübertragung über einen Datenbus (9a) ansteuert, wobei die zu mindestens einer Funktion oder zu mindestens einer Gruppe von Funktionen gehörenden elektronischen Schaltkreise zu einer Partition zusammengefasst werden, wobei einer Partition ein Satz von rekonfigurierbaren elektronischen Schaltkreisen einer Partition zugeteilt wird, wobei mindestens eine Funktion in einer Partition Hardware- und/oder Softwaresicherheitsmechanismen zur Erkennung von Fehlern in den entsprechenden Hardwarekomponenten und/oder von fehlerhaften Daten an den Kommunikationsschnittstellen von Hardwarekomponenten aufweist, dadurch gekennzeichnet, dass eine Anpassung von rekonfigurierbaren elektronischen Schaltkreisen in einer Partition zwecks einer gezielten Prüfung der Funktionstüchtigkeit von fehlererkennenden Sicherheitsmechanismen und/oder zwecks der Bereitstellung der Funktionen von als fehlerhaft erkannten elektronischen Komponenten in derselben Partition erfolgt.
Eine integrierte Schaltungsanordnung nach Anspruch 1, dadurch gekennzeichnet, dass die Prüfung der Funktionstüchtigkeit von fehlererkennenden Sicherheitsmechanismen und die Bereitstellung der Funktionen von als fehlerhaft erkannten Komponenten in einer Partition im Online-Betrieb und/oder im Offline-Betrieb erfolgen.
Eine integrierte Schaltungsanordnung nach einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass vorgegebene oder vorgebbare Regeln zur physikalischen Trennung von Partitionen im Hinblick auf eine Vermeidung von Fehlern infolge gemeinsamer Ursachen (Common-Cause Failures/CCF) eingehalten werden.
Eine integrierte Schaltungsanordnung nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass Konfigurationsdaten für mindestens ein Anpassungsszenario zur Prüfung von fehlererkennenden Sicherheitsmechanismen in einem Speicherelement gespeichert und im Online-Betrieb verwendet wird, wobei eine Prüfung von fehlererkennenden Sicherheitsmechanismen immer nach einem vorgegebenen oder vorgebbaren Zeitintervall zur Laufzeit und/oder beim Starten und/oder Ausschalten des Systems durchgeführt wird.
Eine integrierte Schaltungsanordnung nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Schaltungsanordnung als Mikrocontroller realisiert ist, wobei rekonfigurierbare Schaltkreise zur Prüfung der Funktionstüchtigkeit von im Mikrocontroller vorhandenen fehlererkennenden Sicherheitsmechanismen sowie zur Bereitstellung der Funktionen von als fehlerhaft erkannten Prozessorkernen und/oder Peripheriemodulen des Mikrocontrollers dienen.
Eine integrierte Schaltungsanordnung nach Anspruch 5, dadurch gekennzeichnet, dass ein auf dem Mikrocontroller laufendes Softwareprogramm eine Prüfung der Funktionstüchtigkeit von fehlererkennenden Sicherheitsmechanismen und/oder eine Änderung des Hardware-Aufbaus einer Funktion mittels rekonfigurierbarer Schaltkreise in einer Partition anfordern kann.
Eine integrierte Schaltungsanordnung nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass partielle Selbsttests (partial BISTs) in mindestens einer Partition eingebettet sind, wobei diese eingebauten partiellen Selbsttests (partial BISTs) nach Erkennung eines Fehlers in einer Komponente und/oder in einem Sicherheitsmechanismus in der betroffenen Partition durchgeführt werden, um den Fehler zu lokalisieren und somit die Auswahl eines passenden Konfigurationsszenarios von rekonfigurierbaren Schaltkreisen zu ermöglichen.
Eine integrierte Schaltungsanordnung nach Anspruch 7, dadurch gekennzeichnet, dass eingebaute partielle Selbsttests (partial BISTs) im Offline- und/oder im Online-Betrieb eines Systems durchgeführt werden.
Verfahren zur Prüfung der Sicherheitsintegrität und zur Gewährleistung der Verfügbarkeit eines sicherheitsrelevanten Systems, wobei das sicherheitsrelevante System mindestens eine Funktion für eine Rechen-, eine Überwachungs- und/oder eine Regelaufgabe liefert und/oder eine Datenübertragung über einen Datenbus (9a) ansteuert, wobei die zu mindestens einer Funktion oder zu mindestens einer Gruppe von Funktionen gehörenden elektronischen Schaltkreise zu einer Partition zusammengefasst werden, wobei einer Partition ein Satz von rekonfigurierbaren elektronischen Schaltkreisen zugeteilt wird, wobei mindestens eine Funktion in einer Partition Hardware- und/oder Softwaresicherheitsmechanismen zur Erkennung von Fehlern in den entsprechenden Hardwarekomponenten und/oder von fehlerhaften Daten an den Kommunikationsschnittstellen von Hardwarekomponenten aufweist, dadurch gekennzeichnet, dass eine Anpassung von rekonfigurierbaren elektronischen Schaltkreisen in einer Partition zwecks einer gezielten Prüfung der Funktionstüchtigkeit von fehlererkennenden Sicherheitsmechanismen und/oder zwecks der Bereitstellung der Funktionen von als fehlerhaft erkannten elektronischen Komponenten in derselben Partition erfolgt.
Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass partielle Selbsttests (partial BISTs) in mindestens einer Partition eingebettet sind, wobei diese eingebauten partiellen Selbsttests (partial BISTs) nach Erkennung eines Fehlers in einer Komponente und/oder in einem Sicherheitsmechanismus in der betroffenen Partition durchgeführt werden, um den Fehler zu lokalisieren und somit die Auswahl eines passenden Konfigurationsszenarios von rekonfigurierbaren Schaltkreisen zu ermöglichen.
Verwendung einer integrierten Schaltungsanordnung nach einem der Ansprüche 1 bis 8 oder eines Verfahrens nach einem der Ansprüche 9 oder 10 in der Automobil- oder Automatisierungsindustrie.