DE102011015444A1

DE102011015444A1 - Nethod and apperatus for operational-level functional and degradation fault analysis

Info

Publication number: DE102011015444A1
Application number: DE102011015444A
Authority: DE
Inventors: Dipankar Das; Partha P Chakrabarti; Purnendu Sinha
Original assignee: Indian Institutes of Technology; GM Global Technology Operations LLC
Current assignee: Indian Institutes of Technology; GM Global Technology Operations LLC
Priority date: 2010-04-02
Filing date: 2011-03-29
Publication date: 2011-12-01
Also published as: CN102214253B; US8108728B2; CN102214253A; US20110246831A1

Abstract

Es werden eine Vorrichtung und ein Verfahren zum Am Durchführen einer ”Was wäre wenn?”-Analyse für verschiedene Entwurfsoptionen von fehlertoleranten Systemen bereitstellt. Der Ansatz zur Fehlertoleranzanalyse behandelt Logikfehler und Qualitätsfehler, die aus einem Genauigkeitsverlust bei Signalwerten entstehen. Das Verfahren kann Qualitätsfehler detektieren, was ermöglichen kann, dass Systeme gebaut werden, die tolerant gegenüber Genauigkeitsverlusten sind. Es werden zwei Analyseschritte bereitgestellt, ein statischer und ein weiterer simulationsbasierter, die gemeinsam verwendet werden, um die Fehlertoleranz eines Kraftfahrzeugsystems oder eines anderen Systems zu prüfen. Während ein simulationsbasiertes Verfahren die Fehlertoleranz unter spezifischen Testfällen und Fehlerszenarien prüft, prüft das statische Analyseverfahren schnell alle Testfälle und Fehlerszenarien. Beim Durchführen der Analyse führt das statische Analyseverfahren Approximationen durch und jeder detektierte Fehler wird unter Verwendung des simulationsbasierten Verfahrens reproduziert. Alle Analyseoperationen werden an Verhaltensmodellen auf Betriebsebene der Anwendungen durchgeführt, wodurch die Kosten der Analyse verringert werden.

Description

TECHNISCHES GEBIET
Die vorliegende Erfindung betrifft ein Verfahren und eine Vorrichtung zum Bereitstellen einer Fehlertoleranzanalyse in einem Kraftfahrzeugsystem oder einem anderen komplexen System.
HINTERGRUND DER ERFINDUNG
Mit der Ausbreitung von Elektronik und Software als Bausteine in Kraftfahrzeugsystemen und anderen relativ komplexen Systemen hat sich die Fehlertoleranz zu einer grundsätzlichen Entwurfsanforderung entwickelt. Es ist daher wünschenswert, Systeme zu entwickeln, die ihre Funktionalität trotz Störungen in der Elektronik, der Kommunikation und/oder in Verarbeitungskomponenten auf Systemebene bewahren. Ein Ausfall bestimmter elektronischer Komponenten kann Veränderungen beim Verhalten auf Systemebene verursachen. Beispielsweise kann eine Haftfehler-Bedingung (engl. stuck-at-fault condition) in einem Mikroprozessor, der zur Bereitstellung elektrischer Signale in einem Steer-By-Wire-Fahrzeugsystem ausgelegt ist, eine relativ hohe Schwankung beim Ausgangslenkmoment im Vergleich mit einer defekten mechanischen Lenksäule verursachen. Außerdem müssen Kraftfahrzeugsysteme strengen Industrieanforderungen genügen, welche spezielle Fehlertoleranzanforderungen umfassen.
Ein Ausfall von elektrischen Komponenten in einem System kann aufgrund von Komponentendefekten und einer alterungsbedingten Verschlechterung auftreten. Chips, Sensoren, Stromversorgungen und elektromechanische Stellglieder können permanent oder vorübergehend oder einfach dadurch ausfallen, dass sie im Lauf der Zeit zunehmend weniger genau werden. Außerdem können Hardwarefehler und Softwareprogrammierfehler vorübergehende und permanente Ausfälle verursachen, die sich als Störungen in der Ausgabe eines Controllers auf Systemebene und letztendlich in der Funktion beliebiger Stellglieder, die im System angeordnet sind, manifestieren können. Komponenten wie etwa Sensoren, Softwarebausteine und Hardwarebausteine können sporadische Qualitätsfehler mit sich bringen, die von einer Verschiebung der Signaltrajektorie bis zu fehlerhaften transienten Ausgaben führen, die zu einem Verlust der Signalgenauigkeit führen können.
ZUSAMMENFASSUNG DER ERFINDUNG
Folglich werden hier ein Verfahren und eine Vorrichtung bereitgestellt, die auf einem Computer oder einer Hostmaschine beruhen und eine Fehlertoleranzanalyse (FT-Analyse) in einem Kraftfahrzeugsystem oder einem anderen relativ komplexen System ermöglichen, wobei dies in den frühen Entwurfsstadien stattfindet, beispielsweise bei der Analyse auf Betriebsebene und/oder den Entwurfs/Modellierungsstadien. Eine integrierte Grundstruktur stellt eine logische Analyse sowie eine Qualitätsanalyse bereit und ermöglicht außerdem zukünftige Zuverlässigkeitsanalyseerweiterungen. Zusätzlich zur Analyse der Fehlertoleranz eines Kraftfahrzeugsystems führt die Erfindung eine ”Was wäre wenn?” oder hypothetische Analyse für verschiedene fehlertolerante Kraftfahrzeugsystem-Entwurfsoptionen durch, wie nachstehend offengelegt wird. Somit kann das vorliegende Verfahren und die vorliegende Vorrichtung Qualitätsfehler detektieren, was wiederum das Aufbauen von Systemen unterstützen kann, die tolerant gegenüber Präzisionsverlusten sowohl bei Hardware- als auch Softwarekomponenten sind.
Der vorgeschlagene Ansatz besteht aus zwei Analyseverfahren oder Schritten, von denen einer statisch und der andere simulationsbasiert ist, welche gemeinsam verwendet werden, um die Fehlertoleranz eines gegebenen Systems zu bewerten. Ein Vorteil des vorliegenden FT-Analyseansatzes besteht darin, dass alle Operationen über Verhaltensmodelle im Betrieb oder auf Betriebsebene der Anwendungen durchgeführt werden, z. B. unter Verwendung von Simulink, MATRIXx oder einer anderen Modellierungssoftware, wodurch die Kosten der Analyse relativ zu herkömmlichen Verfahren potentiell verringert werden können.
Insbesondere umfasst ein Verfahren zum Analysieren der FT-Fähigkeiten eines Systems, dass ein Satz von FT-Anforderungen, der eine funktionale Beschreibung definiert, auf berührbaren Medien, die für eine Hostmaschine zugänglich sind, aufgezeichnet wird; dass die Hostmaschine verwendet wird, um ein Modell des Systems zu erzeugen; dass das Verhalten eines Satzes von in dem Modell dargestellten Komponenten des Systems automatisch als eine diskrete Nachschlagetabelle (LUT) abstrahiert oder charakterisiert wird; und dass die Hostmaschine zum Verarbeiten oder Analysieren der FT-Fähigkeiten des Systems über die diskrete LUT und die funktionale Beschreibung verwendet wird. Das Analysieren der FT-Fähigkeiten des Systems umfasst, dass ein vorbestimmter Satz von Logikfehlern und Qualitätsfehlern des Systems analysiert wird.
Es wird hier auch eine Vorrichtung zum Analysieren der FT-Fähigkeiten des Systems bereitgestellt. Die Vorrichtung umfasst die Hostmaschine, die berührbare Medien und einen Algorithmus zur Ausführung des vorstehend angegebenen Verfahrens beherbergt.
Die vorstehenden Merkmale und Vorteile und andere Merkmale und Vorteile der vorliegenden Erfindung ergeben sich leicht aus der folgenden genauen Beschreibung der besten Arten zum Ausführen der Erfindung, wenn sie in Verbindung mit den beiliegenden Zeichnungen gelesen wird.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 ist eine schematische Darstellung eines Modells auf Betriebsebene und einer Hostmaschine, die zum Ausführen einer Fehlertoleranzanalyse eines Kraftfahrzeugsystems oder eines anderen Systems verwendet werden können;
2A ist eine Aufzeichnung eines ersten Signalstörungstyps, der über das vorliegende Verfahren bewertet werden kann;
2B ist eine Aufzeichnung eines zweiten Signalstörungstyps, der über das vorliegende Verfahren bewertet werden kann;
2C ist eine Aufzeichnung eines dritten Signalstörungstyps, der über das vorliegende Verfahren bewertet werden kann;
2D ist eine Aufzeichnung eines vierten Signalstörungstyps, der über das vorliegende Verfahren bewertet werden kann;
2E ist eine Aufzeichnung eines fünften Signalstörungstyps, der über das vorliegende Verfahren bewertet werden kann;
2F ist eine Aufzeichnung eines sechsten Signalstörungstyps, der über das vorliegende Verfahren bewertet werden kann;
3 ist eine schematische Veranschaulichung eines Fehlerinjektionsmechanismus zum Einleiten von Störungen in ein Signal;
4 ist eine schematische Veranschaulichung einer qualitätszentrierten simulationsbasierten Analyse eines Systems gemäß einer Ausführungsform;
5A ist eine schematische Veranschaulichung eines ersten Schritts in einer qualitätszentrierten statischen Analysegrundstruktur;
5B ist eine schematische Veranschaulichung eines zweiten Schritts in einer qualitätszentrierten statischen Analysegrundstruktur;
5C ist eine schematische Veranschaulichung eines dritten Schritts in einer qualitätszentrierten statischen Analysegrundstruktur;
6A ist eine Aufzeichnung eines Eingangssignals über die Zeit;
6B ist eine Aufzeichnung eines Ausgangssignals über die Zeit;
6C ist eine Nachschlagetabelle, die mit der vorliegenden Methodik verwendet werden kann; und
7 ist eine schematische Veranschaulichung einer Boolschen Schaltung für die Qualitätsanalyse des Modells auf Betriebsebene von 5A–C.
BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM
Mit Bezug auf die Zeichnungen, in denen gleiche Bezugszeichen in den verschiedenen Ansichten gleiche oder ähnliche Komponenten bezeichnen und mit 1 beginnend, kann ein Modell 10 auf Betriebsebene unter Verwendung einer Hostmaschine 15 erzeugt werden, wobei automatisierte Schaltungsanalysen der Fehlertoleranz (FT) eines gegebenen Systems über die Hostmaschine 15 ausführbar sind. Die Hostmaschine 15 enthält berührbare Medien, auf denen eine FT-Beschreibung bzw. FT-Spezifikation 20 aufgezeichnet ist. Unter Verwendung der Hostmaschine 15 und des hier offengelegten Ansatzes wird eine FT-Analyse für Kraftfahrzeugsysteme und andere komplexe Systeme ermöglicht.
Die Hostmaschine 15 kann als ein digitaler Computer ausgestaltet sein, der allgemein einen Mikroprozessor oder eine zentrale Verarbeitungseinheit, Festwertspeicher (ROM), Speicher mit wahlfreiem Zugriff (RAM), elektrisch löschbaren programmierbaren Festwertspeicher (EEPROM), einen Hochgeschwindigkeitstaktgeber, Analog/Digital (A/D)- und Digital/Analog (D/A)-Schaltungen und Eingabe/Ausgabe-Schaltungen und -Einrichtungen (I/O) sowie geeignete Signalaufbereitungs- und Pufferschaltungen umfasst. Jeder Algorithmus, der in der Hostmaschine 15 vorhanden ist oder für diese zugänglich ist, kann auf einem Speichermedium gespeichert sein und von der Hostmaschine ausgeführt werden, um die jeweilige Funktionalität bereitzustellen.
Die Hostmaschine 15 stellt auch die Fähigkeit zur Durchführung einer ”Was wäre wenn?” oder hypothetischen Entwurfsmodifikationsanalyse für verschiedene Systementwurfsoptionen bereit. Bei der Verwendung hierin ermöglicht eine ”Was wäre wenn?”-Analyse einem Entwickler, der mit einem Entwurf arbeitet, Modifikationen an dem Entwurf in der Hoffnung auf eine Verbesserung bei der FT dieses Entwurfs durchzuführen. Um zu bestätigen, dass die Modifikation tatsächlich funktioniert hat, müsste der Entwickler prüfen, ob sich die FT des Systems verbessert oder verringert. Daher wird es dem Entwickler ermöglicht, zu untersuchen, was passieren würde, wenn diese Veränderungen am Entwurf durchgeführt würden. Die vorgeschlagene Methodik spricht diese Frage des Entwicklers aus der Perspektive der FT an. Es sei angemerkt, dass es andere Werkzeuge geben kann, welche die ”Was wäre wenn?”-Analyse beispielsweise aus der Perspektive des Leistungsverbrauchs ansprechen.
Das Modell 10 von 1 enthält Sensoren 12, Stellglieder 14, eine Steuerlogik 16 mit verschiedenen Softwareoperationen 17 und ein Modell auf Anlagenebene 18. Modellierungssprachen auf Betriebsebene, beispielsweise Simulink, MATRIXx usw. können verwendet werden, um eine vielseitige Grundstruktur zur Modellierung der verschiedenen Aspekte und Abstraktionen von Kraftfahrzeugsystemen und anderen Systemen bereitzustellen. Resultierende Modelle sind in der Lage, nicht nur Modelle auf Funktionsebene des Kraftfahrzeugsystems darzustellen, sondern auch einige Details der Architekturplattform, auf der das Kraftfahrzeugsystem ausgeführt wird, z. B. die Zuordnung zu einem Prozessor, Puffern, Bussen usw.
Die Steuerlogik 16 kann aus verschiedenen gekoppelten oder miteinander in Beziehung stehenden Softwareoperationen bestehen, in 1 beispielsweise OP1-5. Das Anlagenmodell 18 kann ein mathematisches Modell der Dynamiken der verschiedenen miteinander verbundenen oder mechanischen Komponenten eines gegebenen Systems sein, z. B. eines relativ komplexen Kraftfahrzeugsystems, gemäß einer möglichen Ausführungsform etwa eine By-Wire-Lenk- oder Bremseinrichtung, obwohl im Umfang der vorliegenden Erfindung auch Nicht-Kraftfahrzeugsysteme analysiert werden können.
Das Modell 10 besteht aus den Operationen 17, die jeweils Eingangs- und Ausgangsanschlüsse aufweisen, und aus Eingangssignalen 13 in Eingangsanschlüsse 21 hinein und Ausgangssignalen 13A aus Ausgangsanschlüssen 23 heraus. Die Signale 13, 13A stellen eine virtuelle Verbindung zwischen verschiedenen Operationen dar und können physikalischen Größen entsprechen, z. B. einer von einem Filter erzeugten Ausgangsspannung, oder sie können einem Datenwert entsprechen, der von einem Softwarebaustein erzeugt wird.
Jede Operation 17 in 1 entspricht einer funktionalen Komponente des speziellen Systems, das diagnostiziert wird, wobei die funktionale Komponente einen Sensor 12, einen Softwarecode-Baustein und eine analoge Komponente usw. umfasst. Eine Semantik diskreter Ereignisse wird hier in Betracht gezogen, da mehrere Operationen 17 auf Softwarekomponenten abgebildet sind, d. h. mit abgetasteten Signalen in diskreten Schritten arbeiten. Jedes Signal 13 bezeichnet einen Wert der bei jedem Zeitfenster von der ”Quellen”-Operation aktualisiert wird.
1 zeigt ein mögliches Modell, das in breitem Sinn schematischen Darstellungen mehrerer Modelle auf Betriebsebene eines Kraftfahrzeugsystems ähnelt. Jede Operation 17 im Modell 10 entspricht entweder einer Aufgabe einer speziellen Steuerungsanwendung, einer Sensoroperation, einer Stellgliedoperation oder mechanischen Teilen/Komponenten der durch das Modell 18 dargestellten Anlage. Jede Operation 17 kann entweder als eine logische oder eine arithmetische Funktion, eine Zustandsmaschine wie etwa eine finite Zustandsmaschine (FSM) 24 oder ein hybrider I/O-Automat 22 dargestellt sein. Das Modell 20 verwendet Nachschlagetabelien (LUTs) in einem LUT-basierten Werteschätzblock 19. Bei der Ausführungsform von 1 wählt ein FT-Wahlblock 11 einen Eingang, z. B. von entweder OP5 oder einem LUT-basierten Schätzblock 19, und überträgt den Wert an seinen Ausgang. Um diese Wahl durchzuführen, detektiert der FT-Wahlblock 11 auf der Grundlage anwenderdefinierter Kriterien, ob einer der zwei Eingänge fehlerhaft ist, z. B. durch Überprüfen, ob der Eingangswert in einen bestimmten Bereich fällt, und wählt dann den nicht fehlerhaften Eingang. Wenn beide Eingänge nicht fehlerbehaftet sind, wählt der FT-Wahlblock 11 einen vordefinierten Eingang, z. B. den Eingang von OP5. Es wird angemerkt, dass der LUT-basierte Schätzblock 19 nicht mit den Qualitäts-LUTs in Beziehung steht, die in dem nachstehend beschriebenen Charakterisierungsschritt aufgebaut werden. Bei vielen Kraftfahrzeugsystemen wird eine LUT verwendet, um den Wert eines Signals ”A” aus anderen Signalen als A zu schätzen. Dies trägt zur Vergrößerung der FT des Systems bei, falls die Quelle des Signals A ausfällt.
Bei den meisten interessierenden Kraftfahrzeugsystemen ist die Steuerlogik 16 fast vollständig softwarebasiert, weshalb die Signale 13 unmittelbar in Datenobjekte umgesetzt werden können, die als Eingänge an Steuersoftwarekomponenten bereitgestellt werden. Darüber hinaus können viele Steuerkomponenten durch eine Zeitsteuerung ausgelöst werden, sodass sie bei speziellen zeitlichen Augenblicken mit der Ausführung starten oder diese wieder aufnehmen. Zum Beispiel kann OP4 von 1 so ausgestaltet sein, dass sie erst dann abläuft, wenn eine vorbestimmte Dauer, z. B. 5 ms, seit dem Start der Ausführung vergangen ist, selbst wenn Eingänge früher verfügbar sind. Andere Operationen 17, die in 1 als OP1, OP2, OP3 und OP5 beschriftet sind, können in Abhängigkeit vom Modell 10 auf eine ähnliche oder eine andere Weise ablaufen. Kanten zwischen Operationen bezeichnen eine virtuelle funktionale Verbindung zwischen diesen, welche die Ausgangstrajektorie einer Quellenoperation als die Eingangstrajektorie für die Zieloperation zuordnen.
ANSATZ ZUR FEHLERTOLERANZANALYSE
Immer noch mit Bezug auf 1 wird ein Ansatz zur automatisierten Analyse eines gegebenen FT-Systems, z. B. eines Kraftfahrzeugsystems, über die Hostmaschine 15 bereitgestellt. Der Ansatz besteht aus zwei Analysemethodiken oder Schrittsätzen, die gemeinsam verwendet werden, um die Toleranz eines Kraftfahrzeugsystems gegenüber verschiedenen Logik- und Qualitätsfehlern zu prüfen: (I) einem statischen Analyseschritt und (II) einem Fehlerinjektions- und Simulationsschritt auf Betriebsebene. Die statische Analyse führt eine näherungsweise aber schnelle Bewertung eines Satzes vorbestimmter Fehlerszenarien durch. Danach verifiziert der simulationsbasierte Validierungsschritt für jedes Fehlerszenario und jeden Eingang, der zu einer Verletzung kalibrierter FT-Anforderungen führt, ob die Verletzung falsch ist oder nicht.
Modelle und die Analyse auf Betriebsebene werden typischerweise nur auf der Implementierungsebene angesprochen. Dies erfordert die geeignete Abstraktion von Störungen auf Implementierungsebene auf die Betriebsebene und das Modellieren relevanter Implementierungsdetails in einem geeigneten Modell auf Betriebsebene. Die Abstraktion verschiedener Störungstypen auf geeignete Manifestationen in Modellen auf Betriebsebene wird nachstehend erörtert. Die vorliegende Methodik konzentriert sich stattdessen auf eine qualitätszentrierte Analyse und ermöglicht Schlussfolgerungen über die Abweichung des Verhaltens von beispielsweise einem Kraftfahrzeugsystem mit injizierten Fehlern, statt Schlussfolgerungen aus den Trajektorien der Kraftfahrzeugsystemsignale zu ziehen. Die simulationsbasierte Grundstruktur stellt eine Abtastspur der Abweichung zwischen dem Verhalten eines fehlerfreien Systems und eines Systems mit injizierten Fehlern bereit. Andererseits zieht der Schritt der statischen Analyse nur Schlussfolgerungen über die Qualität oder den Betrag der Störung der verschiedenen Signale, ohne sich mit Details der tatsächlichen Signaltrajektorien zu befassen.
SIMULATIONSBASIERTE ANALYSE VON MODELLEN AUF BETRIEBSEBENE
Immer noch mit Bezug auf 1 werden die meisten Analyse- und Syntheseschritte an Modellen auf Betriebsebene durchgeführt, wie etwa dem Modell 10, um eine schnellere Durchlauf- und Analysezeit auf einem höheren Granularitätsniveau vorteilhaft zu nutzen. Eine der wichtigsten Anforderungen einer Grundstruktur zur Fehlersimulation auf Betriebsebene ist die Modellierung verschiedener Qualitäts- und Logikfehler bei der Abstraktion auf Betriebsebene. Der Ursprung von Fehlern liegt typischerweise in Details einer Implementierung auf Schaltungsebene oder Zuordnungsebene. Beispielsweise verursacht eine Softwarestörung ein transientes Bitkippen in einer Speicherzelle oder einem Register, oder eine temperaturinduzierte Verschiebung der Stromversorgung eines Sensors verursacht eine Verschiebung des Ausgangssignals. Diese Fehler werden auf das Niveau von Modellen auf Betriebsebene abstrahiert, z. B. das Modell 10, wobei immer noch das Wesen der Weise, auf welche ein Fehler einen Signalwert beeinflusst, bewahrt wird.
Die Auswirkungen verschiedener Fehlertypen können in einem Modell auf Betriebsebene, wie etwa dem Modell 10 von 1, abstrahiert werden. Beispielsweise können abstrahiert werden: (1) Sensorfehler, die zu zusätzlichem Rauschen am Ausgang und einer Verschiebung der Ausgangssignaltrajektorie führen, z. B. Fehler durch Rauschen und Verschiebung; (2) fehlende Daten von Sensoren, die zu willkürlichen Sensorausgaben oder Impulsspitzen in bestimmten Zeitfenstern führen, z. B. beispielhafte fehlende Daten von einer Kamera; (3) Softwareprogrammierfehler und Hardwarestörungen, die sich nicht in jedem Ausführungslauf manifestieren, können als Impulsspitzenfehler in bestimmten Zeitfenstern betrachtet werden, in denen sie ausgeführt werden. Diese Impulsspitzenfehler führen eine Überapproximation des Defekts durch, der durch den Programmierfehler/die Störung eingebracht wird, indem sie den maximalen Wert erzeugen, der für das Signal in diesem Zeitfenster möglich ist; und (4) Präzisionsverluste bei Softwarekomponenten werden als Trajektorienverschiebungen modelliert. Diese Verschiebungen können aufgrund von Softwarefehlern beim Festlegen des Typs von Variablen und aufgrund einer Portierung von Steuersoftware auf eingebettete Kraftfahrzeugplattformen auftreten, die viele hochpräzise Operationen und Fließkommaoperationen möglicherweise nicht unterstützen.
Außerdem können abstrahiert werden: (5) Logikfehler, die durch geeignete Komponenten in der Hardwareschicht detektiert werden, sodass ein Stillschweigen bei Fehlern implementiert werden kann. Es wird angenommen, dass Operationen derart instrumentiert werden, dass sie in dem Fall ein Stillschweigen bei Fehlern aufweisen, bei dem irgendein wesentliches Eingangssignal das Stillschweigen bei Fehlern anzeigt; (6) Driften/Versätze bei Takten/Impulsen, die zu Verzögerungsfehlern führen, die sich durch eine Zeitablaufverzögerung für Ausgangssignale und eine Veränderung bei der Verzögerung manifestieren, die mit Zeitgebern verbunden ist. Variationen bei Ausführungsverzögerungen von Softwareaufgaben können auch Veränderungen bei Abtastraten und der Signalerzeugung verursachen, die zu Verzögerungsfehlern führen; und (7) durch Hardware ausgeglichene Softwarestörungen manifestieren sich als Impulsspitzen, d. h. plötzliche und kurze Veränderungen an Signalen, wie etwa ein Impulsspitzenfehler.
Einige der vorstehend erwähnten Fehler stammen nicht von Softwaresteuerkomponenten des Kraftfahrzeugsystems. Aufgrund der Fehlerfortpflanzung werden ihre Auswirkungen unter Anderem jedoch dennoch an den Ausgängen verschiedener Softwaresteuerkomponenten beobachtet. Daher soll jedes Analyseverfahren die Fortpflanzung der vorstehend erwähnten Fehler über verschiedene Typen von Software-, Hardware- und mechanischen Komponenten des Anlagenmodells 18 hinweg ansprechen.
Der Reihe nach mit Bezug auf 2A–F kann jeder Typ der Qualitätsverschlechterung einem geeigneten Maß zur Kennzeichnung des Ausmaßes der Qualitätsverschlechterung, d. h. der Störung zugeordnet werden. 2A stellt ein ”sauberes” oder nicht fehlerhaftes Signal 30 dar. 2B stellt eine Verschiebungsstörung bei der Signaltrajektorie des Signals 30 dar, bei der die Qualität durch die maximale Abweichung des Signalwerts zwischen dem Signal 30 und dem Signal 30A bei allen zeitlichen Augenblicken beschrieben wird. 2C stellt ein Signalrauschen dar, bei dem eine Qualität durch die Amplitude des überlagerten zusätzlichen Rauschsignals 30B beschrieben wird, das weißes Rauschen, Gaußsches Rauschen usw. umfasst.
Mit 2D fortfahrend treten Impulsspitzen 30C aufgrund von durch Hardware ausgeglichenen Softwarestörungen, Software-Programmierfehlern, transienten Hardwarestörungen und/oder transienten Sensorstörungen, wie etwa fehlenden Sensordaten, auf. Die Qualität wird durch die Anzahl von Impulsspitzen 30D beschrieben. Der Spitzenwert der Impulsspitzen 30D ist durch die Obergrenze des Betriebsbereichs oder Datentyps im Fall, dass das Signal aus digitalen Daten besteht, begrenzt. 2E stellt eine Verzögerung bei der Erzeugung des geeigneten Signals 30D dar, für die das Maß der Qualitätsverschlechterung die Verzögerung ist, egal ob positiv oder negativ.
Oft führt ein Verzögerungsfehler zu einer Impulsspitze oder zum Einbringen eines zufälligen Rauschens, wie in 2F gezeigt ist. Dies kann passieren, wenn die Signaltrajektorie bis hin zu t_pre Zeiteinheiten von einer Operation (OP1) und danach von einer anderen (OP2) erzeugt wird, wie in 1 gezeigt ist. Beispielsweise wird angenommen, dass OP1 aufgrund eines Verzögerungsfehlers die Ausführung in t_pre – τ Zeiteinheiten abschließt und dass OP2 erst startet, wenn t_pre Zeiteinheiten vergangen sind. In diesem Fall erzeugt keine Operation in der Zeitspanne t_pre – τ bis t_pre das Signal und folglich kann die Signaltrajektorie in dieser Zeitspanne zufällig oder ein Satz von Impulsspitzen sein.
Es gibt drei Eingänge an die Grundstruktur zur simulationsbasierten Fehlertoleranzanalyse, nämlich (1) einen Testfall, (2) ein Fehlerszenario und (3) Beschreibungen der FT-Anforderung. Testfälle beschreiben typischerweise einen Satz typischer sowie kritischer Manöver oder Aufgabensequenzen, die von dem Kraftfahrzeugsystem durchgeführt werden. Zudem können Testfälle auch erzeugt werden, um eine gerichtete Analyse des Kraftfahrzeugsystems durchzuführen. Gewöhnlich werden die Sensoreingänge, die vom Anwender kommen, durch diese Testfälle modelliert. Im Fall, dass nur ein Teil des Systems getestet wird, werden auch bestimmte Signale von der ”Anlage”, die durch das Anlagenmodell 18 in 1 dargestellt ist, welche in Ansprechen auf Steuersignale von einem anderen Untersystem erzeugt wurden, in die Testfolge aufgenommen.
Der zweite Eingang an die Grundstruktur zur simulationsbasierten Fehlerinjektion ist die Beschreibung des Fehlerszenarios, unter welchem das System analysiert werden muss. Fehlerszenarien können explizit beschrieben sein, indem ein Satz von Fehlern angegeben wird, die auftreten müssen. Im Fall von Qualitätsfehlern muss zusätzlich zu den Informationen darüber, welche Fehler auftreten, auch das Maß der Qualitätsverschlechterung angegeben werden. Daher ist ein Fehlerszenario ein Satz von Dreiergruppen der Form (Ort, Fehlertyp, Maß), wobei Ort das Signal beschreibt, das durch den Fehler beeinflusst wird, und wobei der Fehlertyp und das Maß den Typ bzw. das Maß der Störung beschreiben. Es wird angemerkt, dass das Maß für Logikfehler irrelevant ist. Zum Beispiel kann ein Fehlerszenario angeben, dass ”höchstens fünf Impulsspitzen, d. h. Typ und Maß, durch alle Softwarekomponenten eingeführt werden dürfen”.
Während Fehlerszenarien als Eingänge an die Analysegrundstruktur beschrieben werden, ist es wichtig, die Korrelation zwischen verschiedenen Fehlern zu berücksichtigen. Es ist klar, dass Softwareaufgaben, die dem gleichen Prozessor zugeordnet sind, einige gemeinsame Fehler aufgrund des Prozessors erleiden werden. Auf ähnliche Weise werden Sensoren vom gleichen Hersteller gewöhnlich an ähnlichen Fehlern leiden, während eine gemeinsame Stromversorgung mehrere korrelierte Rausch- und Signalverschiebungsfehler in alle Sensoren einbringt, die sie mit Leistung versorgt. Diese Korrelationen müssen durch jede Grundstruktur zur FT-Analyse erfasst werden. Im Fall, dass die Korrelation zwischen Fehlern durch einen Korrelationskoeffizienten zwischen 0 und 1 oder zwischen 0% und 100% Korrelation beschrieben wird, können für die Analyse mehrere Monte-Carlo-Fehlersimulationen durchgeführt werden, wie auf dem Gebiet verstanden wird.
Abgesehen von der expliziten Fehlerszenarienbeschreibung besteht ein weiterer Weg zur Beschreibung von Fehlerszenarien in einer impliziten Beschreibung, indem eine Untergrenze für die Wahrscheinlichkeit des Auftretens eines Satzes von Fehlern gesetzt wird, die während eines Durchlaufs des Systems auftreten. Wenn die Wahrscheinlichkeit individueller Fehler und die Korrelation zwischen Fehlern bekannt ist, dann kann die Wahrscheinlichkeit eines Satzes von Fehlern berechnet werden. Eine Wahrscheinlichkeitsgrenze beschreibt dann alle Fehlerszenarien, bei denen die vorstehend berechnete Wahrscheinlichkeit größer als die Grenze ist. Derartige Wahrscheinlichkeitsgrenzen stehen typischerweise in Beziehung mit Sicherheitsanforderungen eines Kraftfahrzeugsystems, beispielsweise von IEC-Sicherheitsintegritätsebenen.
Es sei angemerkt, dass im Fall von Qualitätsfehlern nicht nur die Wahrscheinlichkeit des Auftretens des Fehlers, sondern auch die Wahrscheinlichkeit des Erhaltens verschiedener Qualitätsverschlechterungsmaße bereitgestellt werden muss. Tatsächlich kann die Wahrscheinlichkeit eines Qualitätsfehlers durch eine Funktion beschrieben werden: P_quality: Maß → [0, 1] bildet das Maß der Qualitätsverschlechterung auf die Wahrscheinlichkeit des Auftretens des Fehlers mit diesem Maß ab. Ein Maßwert von Null (0) gibt an, dass der Fehler nicht aufgetreten ist. Während Testfälle für eine gerichtete FT-Analyse erzeugt werden, wird die Erzeugung nicht nur des Testfallmanövers, z. B. Sensoreingänge, sondern auch des entsprechenden Fehlerszenarios benötigt. Außerdem wird die FT-Analyse oft an der Differenz zwischen den ”korrekten” Steuersignalen und den fehlerhaften Signalen durchgeführt und nicht an dem fehlerhaften Signal allein. Diese Sachverhalte fügen dem Problem der Testfallerzeugung für die FT-Analyse eine zusätzliche Dimension hinzu.
Der dritte Satz von Eingängen an die Grundstruktur zur simulationsbasierten Fehleranalyse ist der Satz von FT-Anforderungen, der durch das System erfüllt werden muss. Diese FT-Anforderungen bilden die Beschreibung, der das System auch bei dem Vorhandensein von Fehlern genügen muss. Es gibt verschiedene Wege zur Beschreibung von FT-Anforderungen. Logische und zeitliche Eigenschaften, welche die Entwurfsabsicht des Systems beschreiben, können als Beschreibung für den FT-Analyseschritt verwendet werden. Zudem können spezielle Eigenschaften zur Prüfung von Grenzen für die Qualitätsverschlechterung beschrieben werden, z. B. eine Obergrenze für den Betrag an überlagertem Rauschen. Abgesehen davon können mehr betroffene Eigenschaften beschrieben werden, bei denen eine akzeptable Qualitätsverschlechterung eine Funktion der Zeit ist.
Mit den drei gegebenen Eingängen an die FT-Analysegrundstruktur besteht der simulationsbasierte FT-Mechanismus aus einer Fehlerinjektion, einer Simulation des Modells auf Betriebsebene und einer Überprüfung von Aussagen, die den FT-Anforderungseigenschaften entsprechen. Somit wird hier eine ”Fehlerinjektions”-Operation dargestellt, die Störungen von verschiedenen (und mehreren) Typen in ein Signal einbringt. Diese Störungen entsprechen den Fehlern jeder Operation, die durch das Fehlerszenario analysiert werden soll. Diese Operation empfängt als Eingang die Typen von Qualitätsfehlern und die Qualitätsverschlechterungsmaße für jeden verschiedenen Typ von Qualitätsfehler.
Zudem werden auch Informationen über Logikfehler als Eingang von der ”Fehlerinjektions”-Operation aufgenommen. Diese Eingänge, welche die Qualitätsfehler quantifizieren und anzeigen, ob ein Logikfehler in einem speziellen Signal existiert oder nicht, werden aus dem speziellen Fehlerszenario erhalten, das analysiert wird. Die ”Fehlerinjektions”-Operation führt dann Qualitätsfehler und Logikfehler über Eingänge in diese Operation ein. Es sei angemerkt, dass nicht alle Typen von Qualitätsfehlern in jeden Signaltyp eingeführt werden können. Beispielsweise kann ein Signal, das von einer Softwarekomponente erzeugt wird (ein Datensignal), welches die Variation eines Fließkomma-Datenobjekts über die Zeit darstellt, nicht durch einen Qualitätsfehler wie etwa ”Rauschen” beeinflusst werden, der gewöhnlich auf Sensoren und analoge Komponenten beschränkt ist. Ein derartiges Signal kann jedoch durch einen ”Impulsspitzen”-Fehler beeinflusst werden, wenn ein Softwareprogrammierfehler in einem Zeitfenster aufgerufen wird. Außerdem kann ein derartiges Signal durch einen ”Verschiebungs”-Fehler im Fall von Genauigkeitsverlusten aufgrund von Umwandlungen von Fließkomma in Festkomma beim Portieren auf eine eingebettete Plattform, oder aufgrund eines Typumwandlungs-Programmierfehlers, beeinflusst werden.
Mit Bezug auf 3 ist eine beispielhafte Fehlerinjektionsoperation 40 gezeigt. Die Fehlerinjektionsoperation 40 leitet Rauschstörungen und Verschiebestörungen in eine Signalleitung oder einen Ausgang 42 ein. Die Eingänge an diese Operation sind die Signalleitungen oder der Ausgang 42, der Fehlertyp 44, der Abweichungsbetrag 46 und die Rauschamplitude 48. Der Eingangsfehlertyp steuert den Typ der Störung, die in das Signal eingeleitet werden soll, welche entweder ein Rauschen oder eine Verschiebung oder beides oder keine der zwei Störungen sein kann. Der Betrag der Abweichung bzw. die Amplitude des Rauschens der Eingänge geben den Betrag an Verschiebung, der eingeleitet werden soll, und die Amplitude des Rauschsignals, das überlagert werden soll, an. Somit kann ein Entwickler die Typen und den Betrag von Präzisionsstörungen steuern, die in das Signal eingeleitet werden sollen. Die ”Fehlerinjektions”-Operation überlagert die gewählten Störungen mit dem Signal-”Ausgang”, um den ”Ausgang mit injizierter Störung” 49 zu erzeugen. Dieser ”Ausgang mit injizierter Störung” 49 kann anschließend der Eingang für irgendeine andere Operation sein, wodurch sich die injizierten Störungen fortpflanzen.
Gemäß einer Ausführungsform wird eine ”Fehlerinjektions-”Operation in jedem Signal platziert, wodurch eine Fehlereinleitungs-Infrastruktur ermöglicht wird, die einem beliebigen anwenderdefinierten Fehlerszenario entspricht. Diese ”Fehlerinjektions”-Operationen werden in der gleichen Modellierungssprache wie das Modell auf Betriebsebene geschrieben, z. B. Simulink. Anschließend wird das Modell 10 von 1 mit dem Testfall und den Fehlerszenarien als Eingängen unter Verwendung der geeigneten Grundstruktur zur Simulation auf Betriebsebene simuliert, um eine Fehlersimulation zu ermöglichen. Aussagen über Werte von Signalen werden unter Verwendung von Verifikationsfolgen geprüft, welche durch die Simulationsgrundstruktur bereitgestellt werden, oder durch Ausgeben und Analysieren von Abtastspuren, die bei diskreten Zeitschritten erfasst wurden.
Mit Bezug auf 4 ist eine qualitätszentrierte simulationsbasierte Analyse 50 an einem einfachen Kraftfahrzeugsystem, das aus einem Sensor 12, einem Stellglied 14 und einer Steuerungsoperation besteht, schematisch veranschaulicht. An der Oberseite von 4 ist ein ”goldenes Modell” 50A gezeigt und an der Unterseite ist ein fehlerinjiziertes Modell 50B gezeigt. Die Fehlerinjektion wird in verschiedenen Signalen durchgeführt, um die Auswirkungen von Fehlern von verschiedenen Komponenten zu erfassen. Der Unterschied bei der Trajektorie mit Bezug auf ein fehlerfreies Modell wird beschafft und es werden Schlussfolgerungen daraus gezogen.
Wie vorstehend angemerkt wurde, besteht zusätzlich zu der Grundstruktur zur Analyse von Modellen auf Betriebsebene mit Fehlerinjektionen ein Interesse an der Durchführung einer qualitätszentrierten Analyse. Die qualitätszentrierte Analyse zieht Schlussfolgerungen über die Qualität der Signale und nicht über den tatsächlichen Wert derselben. Daher besteht Interesse an der Abweichung der Trajektorie von Signalen, die durch ein fehlerhaftes System erzeugt werden, von denjenigen, die durch ein fehlerfreies System erzeugt werden. Dafür kann ein Simulationsaufbau verwendet werden, bei dem das natürliche/goldene Modell 50A und das fehlerinjizierte Modell 50B gleichzeitig simuliert werden und der Unterschied zwischen den Signalen 54A, 54B durch eine Differenzoperation 52 beschafft wird.
Die Differenz 56 beschreibt die Abweichung des fehlerhaften Signals 54B vom nicht fehlerhaften Signal 54A. Aussagen, die Schlussfolgerungen über die Qualität des Signals, d. h. die Abweichung vom fehlerfreien Verhalten ziehen, werden dann mit der Abtastspur überprüft, die als Ausgang der Differenzoperation 52 erhalten wird. Die Definition der Abweichung eines fehlerhaften Signals und der Typ der verwendeten Differenzoperation 52 hängen vom Typ des Fehlers ab, der analysiert wird. Die am häufigsten verwendete Differenzoperation weist die Semantik der ”Subtraktions”-Operation von Simulink auf und wird durch diese in Modellen auf Betriebsebene implementiert.
Die Semantik kann durch ein beispielhaftes Paar diskretisierter Signale veranschaulicht werden, welche als Eingänge an die ”Differenz”-Operation gegeben sind, so dass sie den gleichen Zeitschritt (δ) aufweisen und die Signalamplituden zum Zeitschritt t_i v 1 / i bzw. v 2 / i sind. Der Ausgang dieser Operation ist eine Trajektorie mit dem Zeitschritt δ und die Signalamplitude bei jedem Zeitschritt t_i ist die Differenz der Amplituden der zwei Eingangssignale beim Schritt t_i(v 1 / i – v 2 / i ). Dieser Typ von Differenzoperation ist beim Ziehen von Schlussfolgerungen über Verschiebungs-, Rausch- (verwendet mit einem Spaltenfilter) und Impulsspitzenstörungen nützlich. Ein anderer Typ von Differenzoperation führt eine Analyse von Signalabweichungen im Frequenzbereich durch, um Schlussfolgerungen über Verzögerungsfehler zu ziehen. In Abhängigkeit vom Umfang und den Anforderungen der Analyse können auch mehrere andere Typen von Differenzoperationen verwendet werden, ohne den beabsichtigten Umfang der Erfindung zu verlassen.
Eine wichtige Komponente eines jeden simulationsbasierten Aufbaus, ob qualitätszentriert oder anderweitig, ist ein Verfahren zum Bewerten des Abdeckungsgrads der simulationsbasierten Validierung für die bereitgestellte Testfolge. Es kann sein, dass herkömmliche Vorstellungen des Abdeckungsgrads auf der Grundlage der Prüfung durchlaufener Zustände oder eines Codeabdeckungsgrads, der Übergänge oder des Zweigabdeckungsgrads und von variablen Werten für die Fehlertoleranzanalyse nicht ausreichen. Die vorstehend erwähnten Metriken des Abdeckungsgrads stellen oft eine grobe Vorstellung von getesteten Ausführungsszenarien bereit, sowohl fehlerfreie als auch mit Fehlerbehebung. Diese Metriken sind jedoch beim Abschätzen des tatsächlich verbleibenden Simulationsrestaufwands unzureichend, da viele getestete Ausführungs- und Fehlerszenarien äquivalent zu Modulo [engl.: equivalent modulo] der analysierten Fehlertoleranzanforderungen sein können.
Qualitätsverschlechterungen werden durch Dreiergruppen beschrieben, die den Typ des Fehlers, die Größe des Fehlers und den Ort des Fehlers enthalten. Ein Fehlersimulationsdurchlauf ist mit einem Satz von Qualitätsverschlechterungsdreiergruppen verbunden, die bei der Fehlersimulation an verschiedenen Signalen (Orten) beobachtet werden. Es gibt eine kausale Beziehung zwischen diesen Dreiergruppen aufgrund der kausalen Beziehung zwischen verschiedenen Operationen im Modell auf Betriebsebene (wenn beispielsweise eine Operation mit einem Eingangssignal I und einem Ausgangssignal O gegeben ist, wird eine Störung A im Signal O aufgrund einer Störung B im Signal I verursacht). Der Abdeckungsgrad kann als die Anzahl derartiger kausaler Beziehungen definiert werden, die zwischen Qualitätsverschlechterungsdreiergruppen vorhanden sind, welche während der Fehlersimulation beobachtet werden. Andere ähnliche Techniken können auch verwendet werden, z. B. ist das Zählen der Anzahl beobachteter Fehler-Dreiergruppen ein anderes Maß des Abdeckungsgrads. Mehrere Dreiergruppen können auch als äquivalent betrachtet werden, wenn sie für einen gegebenen Fehlertyp und Fehlerort ähnliche Größen der Störung aufweisen, oder auf der Grundlage anderer Kriterien. In derartigen Fällen werden die kausalen Beziehungen zwischen Dreiergruppen auf geeignete Weise modifiziert.
Statische Analyse von Modellen auf Betriebsebene
Mit Bezug auf 5A–C ist ein wichtiger Bestandteil des vorgeschlagenen Ansatzes zum Entwerfen eines fehlertoleranten Systems ein statisches Analyseverfahren, welches alle Fehlerszenarien und Testfälle Modulo eines benutzerspezifizierten Abstraktionsniveaus schnell analysiert. Dieses statische Analyseverfahren ist ein qualitätszentriertes Analyseverfahren, da es aus der Qualitätsverschlechterung von Signalen statt der tatsächlichen Signaltrajektorie Schlussfolgerungen zieht. Die Schritte des Analyseverfahrens sind in 5A–C zusammengefasst.
Das statische Analyseverfahren geht in zwei Schritten vor, nämlich einem Charakterisierungsschritt (5B) und einem symbolischen Analyseschritt (5C). Im Charakterisierungsschritt von 5B wird eine Simulation an individuellen Operationen durchgeführt, z. B. OP1–OP4 von 5A, mit unterschiedlichen Testfällen und mit einem variierenden Betrag an Qualitätsstörung der Eingangssignale, während die Qualitätsverschlechterung der Ausgangssignale aufgezeichnet wird. Zusätzliche Charakterisierungssimulationen werden durchgeführt, indem Qualitätsstörungen in die Ausgangssignale dadurch eingeleitet werden, dass variierende Qualitätsstörungen in das Eingangssignal eingeleitet werden.
Die Qualitätsverschlechterungen sowohl der Eingangs- als auch der Ausgangssignale werden quantifiziert und durch symbolische Nachschlagetabellen 60A–D, d. h. LUTs, wie in 5C gezeigt ist, codiert. Dies ermöglicht, dass die aufgezeichneten Qualitäten von Eingang gegen Ausgang als eine LUT dargestellt werden können. Somit ist das Verhalten jeder Operation nach der Charakterisierung durch eine LUT 60A–D abstrahiert, die nur über die quantifizierte Eingangsqualität und Ausgangsqualität der Operation von 5A Schlussfolgerungen zieht.
Mit Bezug auf 6A–C ist in 6C eine beispielhafte Qualitäts-LUT für Verschiebungsstörungen, welche die Ausgangsqualität für verschiedene Eingangsqualitäten bei einer Trajektorienverschiebung beschreiben, für einen Dreieckswelleneingang (6A bzw. 6B) auf eine Sättigungsoperation gezeigt. Eine Sättigungsoperation schneidet das Eingangssignal bei einer anwenderspezifizierten Obergrenze 57 von 6A ab. Bei diesem Beispiel wird eine Sättigungsoperation betrachtet, die als eine Softwarekomponente implementiert ist. Bei dieser Softwareimpelementierung kann eine Trajektorie durch eine geeignet diskretisierte Sequenz von Fest/Fließkommazahlen dargestellt sein, von denen jede den Signalwert (die Amplitude) bei bestimmten diskreten Zeitfenstern darstellt.
Es wird das erwartete (goldene) Eingangssignal betrachtet, das eine dreieckige Trajektorie mit der Amplitude 57 von 6A ist, während störungsbehaftete Eingangssignale dreieckige Trajektorien mit verschiedenen Amplituden sind, die größer als das Niveau der Amplitude 57 sind. Daher weisen die störungsbehafteten Eingangssignale eine Verschiebung der Trajektorie zum goldenen Eingang auf, welche durch die maximale Differenz zwischen den Amplituden der störungsbehafteten und goldenen Signale charakterisiert ist. Verschiedene Symbole können verwendet werden, um quantifizierte Amplitudenverschiebungen zu codieren, um die Qualität von Eingangssignalen zu beschreiben. Wenn die Amplitudenverschiebung zwischen 0 und 10 liegt, kann beispielsweise das Symbol ”1” verwendet werden, um dies zu beschreiben. Auf ähnliche Weise kann ”2” verwendet werden, um eine Verschiebung zwischen 10 und 20 zu beschreiben, eine ”3”, um eine Verschiebung zwischen 20 und 30 zu beschreiben usw.
Beispielsweise weist das Eingangssignal ”Abweichung 1” in 6A eine Amplitudenverschiebung zwischen 20 und 30 auf und wird folglich durch das Symbol ”3” charakterisiert. Bei diesem Sättigungsblockbeispiel ist der goldene Ausgang der gleiche wie der Eingang, eine Dreieckswelle mit der Amplitude 57. Störungsbehaftete Eingangssignale jedoch, die eine Amplitude aufweisen, die größer als das Niveau der Amplitude 57 ist, werden durch die Sättigungsoperation abgeschnitten. In diesem Fall werden die Maximalverschiebungen der Amplituden für die störungsbehafteten Ausgangssignale in 6B durch vertikale Linien 65 veranschaulicht. Durch die Verwendung von Symbolen, um diese Verschiebungen zu beschreiben, wie es bei den Eingangssignalen durchgeführt wurde, wird die Qualität verschiedener störungsbehafteter Ausgangstrajektorien erhalten. Zum Beispiel weist das Ausgangssignal, das dem Eingangssignal ”Abweichung 1” (Qualität ”3”) entspricht, eine Verschiebung der Amplitude zum goldenen Ausgang zwischen 10 und 20 auf und weist folglich eine Qualität von ”2” auf.
Daher beträgt bei einer Eingangsqualität von ”3” die Ausgangssignalqualität ”2”. Das spezielle Symbol ”0” dass es keine Verschiebung mm goldenen Eingang/Ausgang gibt. Die Nachschlagetabelle 60 von 6C enthält eine Zuordnung von Eingangs- zu Ausgangsqualitäten für alle Eingangsqualitäten, die einer benutzerdefinierten Quantifizierung der Amplitudenverschiebung entsprechen. Bei dem Beispiel in 6A–C sind die Qualitätssymbole auf der Grundlage einer einheitlichen Quantifizierung der Amplitudenverschiebung zwischen den goldenen und störungsbehafteten Signalen gewählt. Diese einheitliche Quantifizierung bestand aus dem Unterteilen der Amplitudenverschiebung in Intervalle der Größe 10, beispielsweise das Intervall [10, 20].
Allgemein kann es jedoch sein, dass eine einheitliche Quantifizierung nicht die Basis zum Aufbauen einer LUT ist. Zum Beispiel können Amplitudenverschiebungen in fünf Niveaus zwischen [0, 10] und nur zwei Niveaus zwischen [10, 20] quantifiziert sein. Diese uneinheitlichen Quantifizierungsniveaus können durch die Anforderungen der Fehlertoleranzanalyse geführt sein. Ein weiterer wichtiger Aspekt der qualitätszentrierten Analyse stammt von der Tatsache, dass die Ausgangssignalqualität einer Operation nicht nur von der Eingangssignalqualität, sondern auch vom Typ des Signals (bei dem aktuellen Beispiel eine ”Dreieckswelle”) und dem Status der Operation abhängt (z. B. verschiedene Konfigurationen einer umkonfigurierbaren Operation).
Folglich wird ein zusätzliches Attribut verwendet, welches das Merkmal genannt wird, um verschiedene Typen von Eingangssignalen und Operationsverhaltensweisen zu unterscheiden. Zum Beispiel ist ”Dreieckswelle” ein Eingangsmerkmal für das Beispiel in 6A–C. Die Qualitäts-LUT für diesen Typ von Eingangssignal unterscheidet sich von derjenigen eines anderen Typs von Signal, z. B. einer Rechteckwelle. Die LUTs speichern daher Eingangs-Ausgangs-Qualitäten für verschiedene Merkmale. Obwohl möglicherweise mehrere Simulationsläufe durchgeführt werden müssen, um einzelne Operationsblocks zu charakterisieren, ist dieser Charakterisierungsschritt eine einmalige Aufgabe und die erhaltene LUT kann über verschiedene Entwürfe hinweg wieder verwendet werden. Sobald der Charakterisierungsschritt abgeschlossen ist, kann die qualitätszentrierte Analyse durch eine Reihe von Nachschlageoperationen für ein gegebenes Fehlerszenario und einen gegebenen Testfall durchgeführt werden.
Mit Bezug auf 7 kann durch Unterteilen der Qualitätsverschlechterung (Abweichung vom erwarteten Verhalten) in Intervalle jeder LUT-Eintrag durch ein Symbol codiert werden, welches das Intervall beschreibt, zu dem er gehört. Nach der Quantifizierung bildet eine LUT daher symbolische Eingänge auf symbolische Ausgangseinträge ab und kann durch eine algebraische Analyse verändert werden. Durch Codieren der Symbole in Boolscher Logik kann jede Nachschlagetabelle unter Verwendung einer Boolschen Schaltung 70 modelliert werden. Da ein Modell auf Betriebsebene aus Operationen und Verbindungen dazwischen besteht, kann das Qualitätsverhalten eines vollständigen Modells auf Betriebsebene als eine Boolsche Schaltung 70 dargestellt werden, die aus Unterschaltungen, welche LUTs darstellen, und geeigneten Verbindungen dazwischen besteht.
Alle Fehlerszenarien und Testfälle können bei der Granularität der Quantifizierung geprüft werden, indem eine Erfüllbarkeit gesucht wird, d. h. eine SAT-Lösung für eine Boolsche Schaltung 70, die das Qualitätsverhalten des Modells auf Betriebsebene modelliert. Neben der statischen SAT-basierten Analyse kann auch die Satisfiability Modulo Theory (SMT-Lösung) oder ein simulationsbasiertes Verfahren, wie auf dem Gebiet verstanden wird, verwendet werden, sobald jede Operation charakterisiert und durch eine Qualitäts-LUT dargestellt ist. Ein Weg zum Ausführen dieser Analyse innerhalb der Grundstruktur von Modellen auf Betriebsebene, die durch Simulink bereitgestellt wird, besteht im Ersetzen von Operationen durch Qualitäts-LUTs und dem anschließenden Ausführen einer Simulation eines derartigen Modells.
Die Quantifizierung verringert die Genauigkeit der Analyse und folglich muss ein störungsbehafteter Durchlauf, der im Boolschen Analyseaufbau gefunden wird, im Modell auf Betriebsebene geprüft werden. Zu diesem Zweck müssen das Fehlerszenario (einschließlich des Maßes jedes Fehlers) und der Testfall, der den störungsbehafteten Lauf verursacht, beschafft werden. Diese Einheiten sind Eingänge in die Boolsche Schaltung, die das Qualitätsverhalten modelliert, und werden durch den SAT-Löser [engl.: SAT-solver] für die erfüllbare Instanz bereitgestellt. Somit kann der störungsbehaftete Durchlauf, der durch die SAT-Analyse detektiert wurde, im Simulationsaufbau auf Betriebsebene reproduziert werden.
Immer noch mit Bezug auf 7 besteht ein für diese Grundstruktur anzusprechender Sachverhalt im Bereitstellen eines Beweises, dass die Quantifizierung die Störung immer überapproximiert. Wenn in diesem Fall keine störungsbehafteten Durchläufe durch die statische Analyse gefunden werden können, dann gibt es eine Garantie, dass es keinen störungsbehafteten Durchlauf im Modell auf Betriebsebene gibt. In der Schaltung 70 von 7 sind die Nachschlagetabellen der Operationen OP1, OP2, OP3, und OP4 von 5A als Unterschaltungen QC-OP1, QC-OP2, QC-OP3 und QC-OP4 dargestellt. Das charakterisierte Modell der Anlage ist als die Schaltung QC-ANLAGE dargestellt. Die komplette Schaltung weist sechs Eingänge auf, nämlich Eingangsqualität, Eingangsmerkmal, op1-Fehler, op2-Fehler, op3-Fehler und op4-Fehler.
Die Signale Eingangsqualität und Eingangsmerkmal sind die Qualität (ein Symbol) des Eingangs an den Sensor bzw. der Testfall, der analysiert wird. Die anfänglichen Eingänge an die Sensoren werden als rein angenommen und somit ist die Qualität jedes Eingangssignals eine zuvor zugewiesene Konstante ”0”. Es wird angenommen, dass die verschiedenen Typen möglicher Eingangssignaltrajektorien, die verschiedenen Testfällen entsprechen, a priori bekannt sind, und daher kann ”Eingangsmerkmal” auf ein beliebiges Symbol eines endlichen Satzes von Symbolen gesetzt werden, wobei jedes Symbol einen Signaltyp beschreibt. Beispielsweise könnte α eine Sinuswelle der Amplitude ”1” beschreiben und β könnte eine Kosinuswelle der Amplitude ”1” beschreiben, während γ eine Sinuswelle der Amplitude ”2” beschreiben könnte.
Bei den meisten Entwürfen, wie etwa demjenigen, der hier erörtert und in 5A und 7 gezeigt ist, gibt es einen Rückkopplungskreis von den Ausgängen der Anlage zu den Eingängen der Sensoren. Dieser Rückkopplungskreis wird für die qualitätszentrierte Analyse entfernt, da die Qualität über das vollständige Simulationsfenster (die Zeitspanne, für welche die Simulation durchgeführt wird) definiert ist und eine auf Nachschlagetabellen beruhende Analyse ohne irgendeine Rückkopplung die Analyse für das Simulationsfenster abdeckt. Das zu analysierende Fehlerszenario ist ein Eingang in diese Schaltung und der Satz von Fehlern für jede Operation wird durch die Eingänge op1-Fehler, op2-Fehler, op3-Fehler und op4-Fehler zugeordnet. Diese Eingänge lenken die Typen und Stärken von Störungen, die durch die Operationen OP1, OP2, OP3 bzw. OP4 manifestiert sind.
Wenn mehrere Operationen auf einem einzigen Prozessor abgebildet worden sind, dann gibt es eine Korrelation zwischen den Fehlertypen, die jede Operation zeigt. Dies kann durch zusätzliche Boolsche Beschränkungen modelliert werden. Neben Schaltungsblöcken, die Operationen des Kraftfahrzeugsystems entsprechen, gibt es zwei zusätzliche Schaltungsblöcke, die sicherstellen, dass jeder Ausgang mit niedriger Qualität für ein genügend wahrscheinliches Fehlerszenario bemerkt wird. Der erste Block prüft, ob die endgültige Ausgangsqualität kleiner als eine vom Anwender angegebene Grenze ist (der Ausgang des Blocks ist wahr). Der zweite Block (FEHLERVALIDITATS-PRÜFVORRICHTUNG) prüft, ob das Fehlerszenario, das gerade analysiert wird, ein Fehlerszenario ist, das für den Entwickler von Interesse ist.
Beispielsweise wird ein Analyseaufbau betrachtet, bei dem Fehlerszenarien implizit angegeben sind, indem eine Grenze für die erwartete Ausfallwahrscheinlichkeit des Kraftfahrzeugsystems (durch Sicherheitsintegritätsniveaus) vorgegeben wird und die Wahrscheinlichkeit des Auftretens verschiedener Fehler angegeben wird und keine Korrelation zwischen Fehlern angenommen wird. In diesem Fall kann eine FEHLERVALIDITATS-PRÜFVORRICHTUNG eingesetzt werden, um zu prüfen, ob die Wahrscheinlichkeit des Auftretens des Fehlerszenarios größer als die Sollwahrscheinlichkeit für das Auftreten von Fehlern des Systems (P_system) ist. Zum Aufbauen dieses beispielhaften FEHLERVALIDITATS-PRÜFVORRICHTUNGS-Blocks unter der Annahme keiner Korrelation zwischen Fehlern wird zuerst die kleinste Wahrscheinlichkeit für das Auftreten eines Fehlers für eine beliebige Operation beschafft (P_smallest). Dann wird für jeden Fehlertyp f, count_f =
Sp_f/p_smallest
berechnet, wobei S > 1 ein Skalierungsfaktor ist. Danach berechnet die ”Fehlervaliditäts-Prüfvorrichtung” bei jeder Bewertung der Schaltung die Summe aller count_f für alle aktivierten Fehler f. Dann prüft sie, ob diese Summe kleiner als eine Obergrenze ist:
SPsystem/p_smallest
(Σ_fisenabledcount_f <
SPsystem/p_smallest
Wenn dies der Fall ist, dann ergibt die ”Fehlervaliditäts-Prüfvorrichtung” einen wahren Ausgang, der anzeigt, dass das Fehlerszenario zulässig ist. Es sei angemerkt, dass eine Überapproximation von SPsystem/p_smallest durch
SPsystem/p_smallest
bereitgestellt wird, während
Sp_f/p_smallest
den Wert von SPf/psmallest unterschätzt. Dies stellt sicher, dass dieser Teil der Analyse, die von dem vorstehend erwähnten Verfahren durchgeführt wird, überapproximiert ist.
Synthese fehlertoleranter Kraftfahrzeugsysteme
Die Abstraktion des Qualitätsverhaltens einer Operation als eine symbolische Nachschlagetabelle bietet mehrere Gelegenheiten zur Gestaltung von Synthesealgorithmen für fehlertolerante Kraftfahrzeugsysteme. Wie vorstehend erläutert wurde, kann das Qualitätsverhalten individueller Operationen als Schaltungen modelliert werden, wie auch Mechanismen zur Schlussfolgerung der Wahrscheinlichkeit des Auftretens von Fehlerszenarien. Dies ermöglicht es, verfügbare Schaltungssyntheseverfahren anzuwenden, um Schaltungen durch Kombination von Unterschaltungen aufzubauen, welche verschiedenen Operationen entsprechen (zusammen mit der Teilschaltung zur Schlussfolgerung der Wahrscheinlichkeit des Auftretens von Fehlerszenarien). Wenn eine Schaltung mit dem gewünschten Satz von Ausgangsqualitäten synthetisiert werden kann, dann liefert das Ersetzen der Teilschaltungen mit qualitätsabstrahierenden Nachschlagetabellen durch die zugehörigen Operationen in der Topologie, die durch den Synthesemechanismus hergeleitet wurde, das Modell auf Funktionsebene des gewünschten fehlertoleranten Kraftfahrzeugsystems.
Das vorstehend offengelegte Verfahren ermöglicht die Verwendung entweder einer LUT-basierten Simulation oder eines statischen Analyseverfahrens beruhend auf diskreten LUTs oder von beiden, um ein Gegenbeispiel zu detektieren und um das Gegenbeispiel in der FT-Beschreibung 20 von 1 zu reproduzieren. Das Gegenbeispiel beschreibt einen Satz von Fehlerwerten in verschiedenen Komponenten des Systems, wobei die Fehlerwerte bewirken, dass sich das System derart verhält, dass es gegen die FT-Anforderungen verstößt, die in der FT-Beschreibung 20 offengelegt sind. Die Verwendung des statischen Analyseverfahrens auf der Grundlage von LUTs kann das Verwenden einer Modellprüfung, das Lösen einer Boolschen Erfüllbarkeit, das Lösen der Satisfiability Modulo Theory, Suchalgorithmen usw. umfassen.
Bei der Verwendung hierin ist der Ausdruck ”Gegenbeispiel” im FT-Kontext ein Satz von Werten von Fehlern in verschiedenen Komponenten, z. B. die Amplitude eines Rauschens, eine Verschiebung und/oder die Anzahl von Impulsspitzen bei den Sensoren 12 von 1, die Anzahl von Impulsspitzen bei den verschiedenen Softwareblöcken in dem Modell 10 von 1 usw., welcher bewirkt, dass sich das bewertete System auf eine Weise verhält, welche gegen die FT-Anforderungen verstößt, die als eine funktionale Beschreibung erfasst wurden. Wenn es beispielsweise einen Rauschpegel von 5% am Ausgang des Sensors 1 in 1 gibt und es eine 1%-ige Verschiebung am Ausgang von OP5 in der gleichen Figur gibt, dann weist der endgültige Ausgang eine Verschiebung von 12% auf. Wenn die Funktionsbeschreibung von FT-Anforderungen aus der Dreiergruppe <endgültiger Ausgang, 10%, Verschiebung> war, was bedeutet, dass die Amplitude der Verschiebung beim ”endgültigen Ausgang” kleiner als 10% sein soll, dann verletzt die Verschiebung von 12% diese Anforderung. Das Gegenbeispiel ist hier ”Rauschen von 5% am Ausgang von Sensor 1 und Verschiebung von 1% am Ausgang von OP5”, die Bedingung, welche das System zu einem fehlerhaften Verhalten treibt, wie es durch die FT-Anforderungen beschrieben ist. Obwohl die Gegenbeispiele in einem nativen Modell reproduziert wurden, können die Gegenbeispiele verwendet werden, um die Genauigkeit der Verhaltensabstraktion von Modellen auf Betriebsebene in diskrete LUTs zu verbessern.
Obwohl die besten Arten zum Ausführen der Erfindung im Detail beschrieben wurden, werden Fachleute auf dem Gebiet, das diese Erfindung betrifft, verschiedene alternative Entwürfe und Ausführungsformen zum Umsetzen der Erfindung in die Praxis im Umfang der beigefügten Ansprüche erkennen.

Claims

Verfahren zur Analyse der Fehlertoleranzfähigkeit (FT-Fähigkeit) eines Systems, wobei das Verfahren umfasst, dass ein Satz kalibrierter FT-Anforderungen, welcher eine funktionale Beschreibung für das System definiert, auf berührbaren Medien, die für eine Hostmaschine zugänglich sind, aufgezeichnet wird; die Hostmaschine verwendet wird, um ein Modell auf Betriebsebene des Systems zu erzeugen; ein Verhalten eines Satzes von Komponenten des Systems, die durch das Modell dargestellt sind, automatisch als eine diskrete Nachschlagetabelle (LUT) charakterisiert wird; und die Hostmaschine verwendet wird, um die FT-Fähigkeit des Systems über die diskrete LUT und die funktionale Beschreibung zu analysieren; wobei die Analyse der FT-Fähigkeit des Systems umfasst, dass ein vorbestimmter Satz von Logikfehlern und Qualitätsfehlern des Systems analysiert wird.
Verfahren nach Anspruch 1, das ferner umfasst, dass: ein alternatives Entwurfsszenario für das System auf den berührbaren Medien aufgezeichnet wird; und das alternative Entwurfsszenario über die Hostmaschine unter Verwendung der LUT und der funktionalen Beschreibung automatisch analysiert wird.
Verfahren nach Anspruch 1, das ferner umfasst, dass: über die Hostmaschine als ein erster Satz von Schritten alle möglichen Kombinationen von Eingängen und Fehlerszenarien in der funktionalen Beschreibung geprüft werden; und über die Hostmaschine als ein zweiter Satz von Schritten ein FT-Status des Systems unter einem Satz kalibrierter Testfälle und Fehlerszenarien unter Verwendung der LUT geprüft wird.
Verfahren nach Anspruch 1, das ferner umfasst, dass: das Vorhandensein einer Verletzung der FT-Anforderungen während des ersten Satzes von Schritten ermittelt wird; und ein Satz von Systemverhaltensweisen, der zu der Verletzung führt, in einem zweiten Modell reproduziert wird.
Verfahren nach Anspruch 1, das ferner umfasst, dass: das charakterisierte Qualitätsverhalten der Komponenten in der LUT gespeichert wird; und die LUT unter Verwendung der Hostmaschine verarbeitet wird, um das Qualitätsverhalten des Systems zu ermitteln.
Verfahren nach Anspruch 1, das ferner umfasst, dass: eine LUT-basierte Simulation und/oder ein auf einer diskreten LUT basierendes statisches Analyseverfahren zum Detektieren eines Gegenbeispiels verwendet werden; und das Gegenbeispiel in der FT-Beschreibung automatisch reproduziert wird; wobei das Gegenbeispiel einen Satz von Fehlerwerten in verschiedenen Komponenten des Satzes von Komponenten beschreibt, wobei die Fehlerwerte bewirken, dass sich das System auf eine Weise verhält, die die FT-Anforderungen verletzt.
Verfahren nach Anspruch 6, das umfasst, dass das auf der LUT basierende statische Analyseverfahren verwendet wird, wobei das Verwenden des auf der LUT basierenden statischen Analyseverfahrens umfasst, dass eine Modellprüfung, das Lösen eines Boolschen Erfüllbarkeitsproblems, das Lösen einer Satisfiability Modulo Theory und/oder Suchalgorithmen verwendet werden.
Verfahren nach Anspruch 1, das ferner umfasst, dass: ein Testfall, ein Fehlerszenario und die Fehlertoleranz-Anforderungsbeschreibungen jeweils in die Hostmaschine eingegeben werden, wobei: das Fehlerszenario ein Satz von Dreiergruppen in der Form eines Orts, eines Fehlertyps und eines Maßes ist; der Ort ein Signal bezeichnet, das durch den Fehler betroffen ist; und der Fehlertyp und das Maß den Typ bzw. das Maß der Störung bezeichnen.
Verfahren nach Anspruch 1, wobei das Modell einen FT-Wahlblock enthält und das Verfahren ferner umfasst, dass der FT-Wahlblock verwendet wird, um einen nicht fehlerbehafteten Eingang zu detektieren und zu wählen und um den nicht fehlerbehafteten Eingang an einen Ausgang des FT-Wahlblocks zu übertragen.
Vorrichtung, die zur Analyse der Fehlertoleranzfähigkeiten (FT-Fähigkeiten) eines Systems ausgelegt ist, wobei die Vorrichtung umfasst: eine Hostmaschine; und berührbare Medien, die für die Hostmaschine zugänglich sind, und auf denen eine funktionale Beschreibung aufgezeichnet ist, die einen formellen Satz von Fehlertoleranzanforderungen (FT-Anforderungen) definiert; wobei die Hostmaschine ausgelegt ist, um: ein Modell auf Betriebsebene des Systems unter Verwendung der Hostmaschine zu erzeugen; das Verhalten eines Satzes von Komponenten des Modells als eine diskrete Nachschlagetabelle (LUT) zu charakterisieren; und die FT-Fähigkeit des Systems unter Verwendung der diskreten LUT und der funktionalen Beschreibung zu analysieren, wobei das Analysieren der FT-Fähigkeit umfasst, dass ein vorbestimmter Satz von Logikfehlern und Qualitätsfehlern des Systems analysiert wird.