DE102016224253A1 - Verfahren zum Überwachen eines Sensorsystems eines Fahrzeugs und Sensorsystem - Google Patents

Verfahren zum Überwachen eines Sensorsystems eines Fahrzeugs und Sensorsystem Download PDF

Info

Publication number
DE102016224253A1
DE102016224253A1 DE102016224253.9A DE102016224253A DE102016224253A1 DE 102016224253 A1 DE102016224253 A1 DE 102016224253A1 DE 102016224253 A DE102016224253 A DE 102016224253A DE 102016224253 A1 DE102016224253 A1 DE 102016224253A1
Authority
DE
Germany
Prior art keywords
test
processing unit
self
processing
sensor data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE102016224253.9A
Other languages
English (en)
Inventor
Bernd Mueller
Giuseppe Montalbano
Oliver Lange
Sebastian Bolk
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Priority to DE102016224253.9A priority Critical patent/DE102016224253A1/de
Publication of DE102016224253A1 publication Critical patent/DE102016224253A1/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G01MEASURING; TESTING
    • G01RMEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317Testing of digital circuits
    • G01R31/3181Functional testing
    • G01R31/3187Built-in tests
    • GPHYSICS
    • G01MEASURING; TESTING
    • G01RMEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/005Testing of electric installations on transport means
    • G01R31/006Testing of electric installations on transport means on road vehicles, e.g. automobiles or trucks

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Chemical & Material Sciences (AREA)
  • Combustion & Propulsion (AREA)
  • General Engineering & Computer Science (AREA)
  • Traffic Control Systems (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Überwachen eines Sensorsystems (100) eines Fahrzeugs, wobei das Sensorsystem (100) eine Verarbeitungseinheit (104) zum Verarbeiten von Sensordaten (106) und eine Selbsttesteinheit (108) zum Durchführen eines testmusterbasierten Selbsttests der Verarbeitungseinheit (104) aufweist. Dabei werden die Sensordaten (106) eingelesen und es wird in Abhängigkeit von einer zeitlichen Struktur der Sensordaten (106) der Selbsttest durchgeführt.

Description

  • Stand der Technik
  • Die Erfindung geht aus von einer Vorrichtung oder einem Verfahren nach Gattung der unabhängigen Ansprüche. Gegenstand der vorliegenden Erfindung ist auch ein Computerprogramm.
  • Videosysteme im Automobil können wie viele andere Automobilsysteme Mikroprozessoren verwenden. Wenn sicherheitsrelevante Funktionen umgesetzt werden, kann ein Fehler in der Hardware des Mikroprozessors sicherheitskritische Auswirkungen haben. Deswegen ist eine geeignete Überwachung des Mikroprozessors erforderlich.
  • Zur Überwachung von Prozessoren, insbesondere eines Rechenkerns, auch Core oder allgemein Logik genannt, sind verschiedene Verfahren bekannt. Beispielsweise können beim Start-up Testroutinen in Software verwendet werden. Während des Betriebs kann beispielsweise ein Hardware- oder Software-Lockstep verwendet werden. Zusätzlich können softwarebasierte Tests während der Laufzeit durchgeführt werden. Ferner können Watchdogs, Kontrollfluss-Checks oder ähnliche systemübergreifende Maßnahmen zur Überwachung eingesetzt werden.
  • Vor diesem Hintergrund werden mit dem hier vorgestellten Ansatz ein Verfahren zum Überwachen eines Sensorsystems eines Fahrzeugs, ein Sensorsystem, das dieses Verfahren verwendet, sowie schließlich ein entsprechendes Computerprogramm gemäß den Hauptansprüchen vorgestellt. Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen der im unabhängigen Anspruch angegebenen Vorrichtung möglich.
  • Offenbarung der Erfindung
  • Es wird ein Verfahren zum Überwachen eines Sensorsystems eines Fahrzeugs vorgestellt, wobei das Sensorsystem eine Verarbeitungseinheit zum Verarbeiten von Sensordaten und eine Selbsttesteinheit zum Durchführen eines testmusterbasierten Selbsttests der Verarbeitungseinheit aufweist, wobei das Verfahren folgende Schritte umfasst:
    • Einlesen der Sensordaten; und
    • Durchführen des Selbsttests in Abhängigkeit von einer zeitlichen Struktur der Sensordaten.
  • Unter einem Sensorsystem kann beispielsweise ein System zur Überwachung eines Umfelds des Fahrzeugs verstanden werden. Hierzu kann das Sensorsystem beispielsweise einen die Sensordaten liefernden Umfeldsensor in Form einer Kamera, eines Lidar-, Radar- oder Ultraschallsensors aufweisen. Unter einer Verarbeitungseinheit kann beispielsweise ein Prozessor, insbesondere ein Mikroprozessor, ein Rechenkern, eine Logik, ein Speicherbaustein oder eine Kombination aus den genannten Komponenten verstanden werden. Unter einer Selbsttesteinheit kann im Allgemeinen eine Einheit mit einem Testmustergenerator zum Generieren eines Testmusters, auch Test Pattern Generator (TPG) genannt, und einem Testantwortauswerter, auch Test Response Evaluator (TRE) oder Output Response Analyzer (ORA) genannt, verstanden werden. Insbesondere kann die Selbsttesteinheit ausgebildet sein, um den Selbsttest online, d. h. während eines laufenden Betriebs, einer Initialisierungsphase oder einer Ruhezeit des Sensorsystems, durchzuführen. Die Selbsttesteinheit kann beispielsweise in die Verarbeitungseinheit integriert sein, um den Selbsttest auf der Verarbeitungseinheit durchführen zu können. In diesem Sinne kann unter einem Selbsttest ein sogenannter eingebauter Selbsttest, auch built-in self-test (BIST) genannt, verstanden werden. Dabei wird der Verarbeitungseinheit das Testmuster zugeführt und die von der Verarbeitungseinheit unter Verwendung des Testmusters erzeugte Testantwort ausgewertet. Je nach Ausführungsform der Verarbeitungseinheit kann es sich bei dem Selbsttest um einen LBIST für eine Logik oder einen MBIST für einen Speicher handeln.
  • Bei den Sensordaten kann es sich um eine Folge von Frames handeln. Unter einem Frame kann etwa ein Einzelbild oder ein sonstiger Datenframe mit einer bestimmten Dauer verstanden werden. Unter einer zeitlichen Struktur kann eine Gruppierung oder eine Einteilung der Daten in einzelne, vorzugsweise unterschiedliche Datenblöcke wie die Frames verstanden werden. Hierbei kann beim Durchführen des Selbsttests die Taktung und/oder die Länge der Datenblöcke zur Steuerung, insbesondere zur zeitlichen Steuerung, des Selbsttest verwendet werden.
  • Beispielsweise kann die Verarbeitungseinheit zumindest eine Recheneinheit zum Verarbeiten von Signalen oder Daten, zumindest eine Speichereinheit zum Speichern von Signalen oder Daten, zumindest eine Schnittstelle zu einem Sensor oder einem Aktor zum Einlesen von Sensorsignalen von dem Sensor oder zum Ausgeben von Daten- oder Steuersignalen an den Aktor und/oder zumindest eine Kommunikationsschnittstelle zum Einlesen oder Ausgeben von Daten aufweisen, die in ein Kommunikationsprotokoll eingebettet sind. Die Recheneinheit kann beispielsweise ein Signalprozessor, ein Mikrocontroller oder dergleichen sein, wobei die Speichereinheit ein Flash-Speicher, ein EPROM oder eine magnetische Speichereinheit sein kann. Die Kommunikationsschnittstelle kann ausgebildet sein, um Daten drahtlos und/oder leitungsgebunden einzulesen oder auszugeben, wobei eine Kommunikationsschnittstelle, die leitungsgebundene Daten einlesen oder ausgeben kann, diese Daten beispielsweise elektrisch oder optisch aus einer entsprechenden Datenübertragungsleitung einlesen oder in eine entsprechende Datenübertragungsleitung ausgeben kann.
  • Der hier vorgestellte Ansatz beruht auf der Erkenntnis, dass die Überwachung eines beispielsweise videobasierten Systems eines Fahrzeugs mithilfe eines onlinefähigen BIST (built-in self-test; „eingebauter Selbsttest“), etwa ein LBIST (logic built-in self-test) oder MBIST (memory built-in self-test), während eines laufenden Betriebs des Systems erfolgen kann. Dabei kann der BIST durch Software in der Form aktiviert werden, dass eine Synchronisation mit den beispielsweise von einer Videoeinheit des Systems gelieferten Frames gewährleistet wird. Somit wird ein Überwachungskonzept ermöglicht, das insbesondere hinsichtlich der Besonderheiten von Videoanwendungen eine ausreichend hohe Überwachungsgüte gewährleisten kann, wobei die Überwachungsgüte im Wesentlichen durch eine angemessene Diagnostic Coverage für Core- oder Logikfehler gekennzeichnet ist. Eine derartige Überwachung hat den Vorteil, dass auf sehr kostenintensive Lockstep-Lösungen verzichtet werden kann.
  • Gemäß einer Ausführungsform können die Sensordaten eine Folge von Frames repräsentieren. Entsprechend kann der Schritt des Durchführens zumindest teilweise während der Dauer eines Frames ausgeführt werden. Dadurch ist es möglich, den Selbsttest während des laufenden Betriebs des Sensorsystems durchzuführen.
  • Hierbei kann im Schritt des Durchführens der Selbsttest am Anfang oder am Ende oder sowohl am Anfang als auch am Ende des Frames durchgeführt werden. Dadurch kann eine zur Durchführung des Selbsttests erforderliche Rechenzeit minimiert werden.
  • Das Verfahren kann gemäß einer weiteren Ausführungsform einen Schritt des Verarbeitens der Sensordaten umfassen. Der Schritt des Verarbeitens kann zumindest teilweise während der Dauer des Frames ausgeführt werden. Dadurch wird eine Verarbeitung der Sensordaten zusätzlich zur Durchführung des Selbsttests ermöglicht.
  • Es ist vorteilhaft, wenn der Schritt des Verarbeitens und der Schritt des Durchführens sequenziell ausgeführt werden. Dadurch kann sichergestellt werden, dass zur Durchführung des Selbsttests eine ausreichend lange Rechenzeit zur Verfügung steht.
  • Gemäß einer weiteren Ausführungsform kann das Verfahren einen Schritt des Sicherns von in der Verarbeitungseinheit gespeicherten Daten vor dem Schritt des Durchführens umfassen, um eine Sicherungskopie zu erhalten. Dadurch können Daten der Verarbeitungseinheit, die bei der Durchführung des Selbsttests zerstört werden, erhalten werden.
  • Des Weiteren kann in einem Schritt des Wiederherstellens ein Arbeitszustand der Verarbeitungseinheit nach dem Schritt des Durchführens wiederhergestellt werden. Unter einem Arbeitszustand kann ein Zustand der Verarbeitungseinheit verstanden werden, in der die Verarbeitungseinheit eine ihr zugeordnete Softwarefunktion ausführen kann. Durch diese Ausführungsform kann nach Durchführung des Selbsttests eine Softwarefähigkeit der Verarbeitungseinheit wiederhergestellt werden.
  • Dabei kann im Schritt des Wiederherstellens der Arbeitszustand unter Verwendung der Sicherungskopie wiederhergestellt werden. Dadurch kann der Arbeitszustand besonders effizient wiederhergestellt werden.
  • Von Vorteil ist ferner eine Ausführungsform des hier vorgestellten Ansatzes bei demim Schritt des Durchführens ein Anlegen zumindest eines Testmusters (beispielsweise in der Form eines BIST; BIST = Build-in-self-test = eingebauter Selbstest) an der Verarbeitungseinheit ausgeführt wird, wobei durch das Testmuster Hardwarebestandteile der Verarbeitungseinheit angesprochen werden, insbesondere in Form von Scan Chains, die in einem Betrieb der Verarbeitungseinheit zur Verarbeitung von Sensordaten nicht angesprochen werden. Eine solche Ausführungsform des hier vorgestellten Ansatzes bietet den Vorteil einer präzisen und zugleich zuverlässigen Überprüfungsmöglichkeit von Bereichen der Verarbeitungseinheit.
  • Gemäß einer weiteren Ausführungsform können im Schritt des Sicherns Konfigurationsdaten der Verarbeitungseinheit gesichert werden. Dadurch kann eine erneute Konfiguration der Verarbeitungseinheit erleichtert werden.
  • Zudem kann das Verfahren einen Schritt des Vergleichens der Konfigurationsdaten mit Referenzkonfigurationsdaten unter Verwendung der Sicherungskopie umfassen, um eine Konfiguration der Verarbeitungseinheit zu überprüfen. Dadurch können transiente Fehler in den Konfigurationsdaten zuverlässig nachgewiesen werden.
  • Gemäß einer weiteren Ausführungsform kann im Schritt des Durchführens der Selbsttest unter Verwendung zumindest zweier unterschiedlicher Testmuster durchgeführt werden. Dadurch kann die Effizienz des Selbsttests erhöht werden.
  • Dieses Verfahren kann beispielsweise in Software oder Hardware oder in einer Mischform aus Software und Hardware implementiert sein.
  • Der hier vorgestellte Ansatz schafft ferner ein Sensorsystem mit folgenden Merkmalen:
    • einer Verarbeitungseinheit zum Verarbeiten von Sensordaten; und
    • einer Selbsttesteinheit, die ausgebildet ist, um einen testmusterbasierten Selbsttest der Verarbeitungseinheit in Abhängigkeit von einer zeitlichen Struktur der Sensordaten durchzuführen.
  • Gemäß einer Ausführungsform kann die Selbsttesteinheit in die Verarbeitungseinheit integriert oder Teil der Verarbeitungseinheit sein, um den Selbsttest auf der Verarbeitungseinheit durchzuführen. Dadurch können zusätzliche Bausteine zur Überprüfung der Verarbeitungseinheit entfallen.
  • Von Vorteil ist auch ein Computerprogrammprodukt oder Computerprogramm mit Programmcode, der auf einem maschinenlesbaren Träger oder Speichermedium wie einem Halbleiterspeicher, einem Festplattenspeicher oder einem optischen Speicher gespeichert sein kann und zur Durchführung, Umsetzung und/oder Ansteuerung der Schritte des Verfahrens nach einer der vorstehend beschriebenen Ausführungsformen verwendet wird, insbesondere wenn das Programmprodukt oder Programm auf einem Computer oder einer Vorrichtung ausgeführt wird.
  • Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:
    • 1 eine schematische Darstellung eines Sensorsystems gemäß einem Ausführungsbeispiel;
    • 2 eine schematische Darstellung eines Prozessors mit einer Mehrzahl von Verarbeitungseinheiten gemäß einem Ausführungsbeispiel;
    • 3 ein Ablaufdiagramm eines Verfahrens gemäß einem Ausführungsbeispiel;
    • 4 eine schematische Darstellung einer Synchronisation eines Selbsttests in einem Verfahren gemäß einem Ausführungsbeispiel; und
    • 5 eine schematische Darstellung einer Synchronisation eines Selbsttests in einem Verfahren gemäß einem Ausführungsbeispiel.
  • In der nachfolgenden Beschreibung günstiger Ausführungsbeispiele der vorliegenden Erfindung werden für die in den verschiedenen Figuren dargestellten und ähnlich wirkenden Elemente gleiche oder ähnliche Bezugszeichen verwendet, wobei auf eine wiederholte Beschreibung dieser Elemente verzichtet wird.
  • 1 zeigt eine schematische Darstellung eines Sensorsystems 100 gemäß einem Ausführungsbeispiel. Das Sensorsystem 100 umfasst einen Umfeldsensor 102 zum Erfassen eines Umfelds eines Fahrzeugs, beispielsweise eine Kamera, einen Radar-, Lidar- oder Ultraschallsensor, eine Verarbeitungseinheit 104 zum Verarbeiten von Sensordaten 106 des Umfeldsensors 102, hier als Rechenkern oder Logik realisiert, sowie eine Selbsttesteinheit 108, hier ein LBIST-Controller, die ausgebildet ist, um auf der Verarbeitungseinheit 104 einen testmusterbasierten Selbsttest, auch LBIST (logic built-in self-test) genannt, durchzuführen und anhand dieses Selbsttests eine Funktionsfähigkeit der Verarbeitungseinheit 104 zu überwachen.
  • Zur Durchführung des Selbsttests ist die Selbsttesteinheit 108 ausgebildet, um ein von einem Testmustergenerator 110 generiertes Testmuster 112 an die Verarbeitungseinheit 104 zu senden, wobei die Verarbeitungseinheit 104 ausgebildet ist, um unter Verwendung des Testmusters 112 eine Testantwort 114 zu erstellen und an die Selbsttesteinheit 108 zurückzusenden. Durch Auswerten der Testantwort 114 ist die Selbsttesteinheit 108 in der Lage zu erkennen, ob die Funktionsfähigkeit der Verarbeitungseinheit 104 gegeben ist oder nicht. Dabei führt die Selbsttesteinheit 108 den Selbsttest in Abhängigkeit von einer zeitlichen Struktur der während des Selbsttests von der Verarbeitungseinheit 104 eingelesenen Sensordaten 106, d. h. synchronisiert mit dem Einlesen der Sensordaten 106, durch. Diese Sensordaten 106 repräsentieren beispielsweise eine Folge von Frames. Dementsprechend führt die Selbsttesteinheit 108 den Selbsttest synchron mit der Folge der Frames durch, wobei die Durchführung zumindest teilweise während der Dauer eines Frames erfolgt, d. h., zumindest ein Teil einer für die Bearbeitung eines Frames erforderlichen Rechenzeit wird für die Durchführung des Selbsttests verwendet.
  • Gemäß einem Ausführungsbeispiel ist die Selbsttesteinheit 108 in die Verarbeitungseinheit 104 eingebaut. Der von der Selbsttesteinheit 108 durchgeführte Selbsttest wird deshalb auch als eingebauter Selbsttest bezeichnet. Beispielsweise sind die Verarbeitungseinheit 104 und die Selbsttesteinheit 108 jeweils als Bausteine eines (Mikro-)Prozessors realisiert.
  • 2 zeigt eine schematische Darstellung eines Prozessors 200 mit einer Mehrzahl von Verarbeitungseinheiten 104 gemäß einem Ausführungsbeispiel. Bei den Verarbeitungseinheiten 104 kann es sich jeweils um eine vorangehend anhand von 1 beschriebene Verarbeitungseinheit in Form eines Rechenkerns, auch Core genannt, bzw. einer Logik handeln. Der Prozessor 200 ist mit dem Umfeldsensor 102, hier einem Imager, verbunden, um die Sensordaten 106 einzulesen und zu verarbeiten.
  • 3 zeigt ein Ablaufdiagramm eines Verfahrens 300 gemäß einem Ausführungsbeispiel. Das Verfahren 300 zum Überwachen eines Sensorsystems eines Fahrzeugs kann beispielsweise im Zusammenhang mit einem vorangehend anhand der 1 und 2 beschriebenen Sensorsystem durchgeführt werden. Dabei werden in einem Schritt 310 die Sensordaten des Umfeldsensors eingelesen. In einem weiteren Schritt 320 wird der eingebaute Selbsttest oder BIST in Abhängigkeit von der zeitlichen Struktur der Sensordaten, d. h. synchronisiert mit dem Einlesen, durchgeführt. Je nach Ausführungsbeispiel wird im Schritt 320 ein LBIST oder MBIST durchgeführt.
  • Gemäß einem Ausführungsbeispiel erfolgt vor dem Schritt 320 eine Vorbereitung auf den bevorstehenden Selbsttest, indem in einem Schritt 330 eine Sicherungskopie von in der Verarbeitungseinheit gespeicherten Daten erstellt wird, insbesondere von Daten, die im Zuge des Selbsttests gelöscht oder zerstört werden. Um die Softwarefähigkeit der Verarbeitungseinheit wiederherzustellen, wird gemäß einem weiteren Ausführungsbeispiel in einem Schritt 340 nach Beendigung des Selbsttests ein Arbeitszustand der Verarbeitungseinheit wiederhergestellt, wobei der Arbeitszustand als ein Zustand der Verarbeitungseinheit zu betrachten ist, in dem die Verarbeitungseinheit die ihr zugeordnete Funktion der Verarbeitung der Sensordaten erfüllen kann. Insbesondere erfolgt die Wiederherstellung dieses Arbeitszustands beispielsweise unter Verwendung der vorangehend im Schritt 330 erstellten Sicherungskopie.
  • 4 zeigt eine schematische Darstellung einer Synchronisation eines Selbsttests in einem Verfahren gemäß einem Ausführungsbeispiel, etwa einem vorangehend anhand von 3 beschriebenen Verfahren. Gezeigt sind die Sensordaten 106 in Form eines Datenstroms, der schematisch mit einer Mehrzahl von Datenblöcken 400, die je einen Frame der Sensordaten 106 repräsentieren, dargestellt ist. Bei den Frames handelt es sich je nach Ausführung des Umfeldsensors um Einzelbilder oder sonstige Datenframes. Unterhalb des Datenstroms ist eine Folge von Tasks dargestellt, die ähnlich wie die Sensordaten 106 je durch einen Verarbeitungsblock 402 gekennzeichnet sind und je einem der Datenblöcke 400 zugeordnet sind.
  • Die Folge der Verarbeitungsblöcke 402 ist beispielhaft durch einen einzelnen Testblock 404, bestehend aus einem Bearbeitungsschritt 406 und einem Testschritt 408, unterbrochen, wobei im Testschritt 408 der Selbsttest durchgeführt wird und im Bearbeitungsschritt 406 zumindest eine Basisbearbeitung eines dem Testblock 404 zugeordneten Frames durchgeführt wird. Die Durchführung des Selbsttests erfolgt zumindest teilweise während einer Dauer des entsprechenden Frames.
  • 5 zeigt eine schematische Darstellung einer Synchronisation eines Selbsttests in einem Verfahren gemäß einem Ausführungsbeispiel. Im Unterschied zu 4 umfassen die in 5 gezeigten Verarbeitungsblöcke 402 je den Testschritt 408 sowie einen Taskschritt 500, der zur Bearbeitung eines zugehörigen Frames dient. Dabei werden die Testschritte 408 jeweils am Ende eines Datenblocks 400 ausgeführt. Zusätzlich oder alternativ erfolgt die Durchführung des Selbsttests oder auch nur eines Teils des Selbsttests in den Testschritten 408 zu Beginn eines Datenblocks 400.
  • Nachfolgend werden verschiedene Ausführungsbeispiele des hier vorgestellten Ansatzes anhand der 1 bis 5 nochmals mit anderen Worten beschrieben.
  • Beispielsweise liegt dem Verfahren 300 ein videobasiertes Sensorsystem 100 zugrunde, bei dem von einer Kamera über geeignete Linsen Licht mit einem Imager 102 erfasst wird.
  • Vom Imager 102 werden Frames, beispielsweise in Form von 1024 × 980 Pixeln, regelmäßig an den Prozessor 200 gesendet. Typischerweise erfolgt dies alle x ms; ein nicht streng periodisches Verhalten ist aber auch möglich. Innerhalb des Prozessors 200 befindet sich mindestens eine Verarbeitungseinheit 104 in Form eines Core oder auch einer anderen Logik. Diese Logik wertet Informationen aus den Frames aus, etwa indem auch die Folge der Frames und nicht nur ein einzelner Frame betrachtet wird. Die Verarbeitung der Frames erfolgt beispielsweise auch in Stufen, etwa in einer pixelnahen Stufe, in einer Stufe auf einer Objektebene oder auch in einer Stufe, in der Aktorkommandos abgeleitet werden. Jede Stufe kann dabei durch eine eigene Hardwarelogik oder einen eigenen Hardwarekern realisiert sein, die auf den jeweiligen Verarbeitungsschritt optimiert sind. Die Stufen können seriell aufeinander aufbauen oder auch parallel in der Verarbeitung sein.
  • Die meisten solcher Stufen sind sicherheitstechnisch zu betrachten, da sie einen sicherheitsrelevanten Einfluss ausüben können. In der Regel bedeutet dies, dass eine geeignete Überwachung einzuführen ist. Gemäß dem hier vorgestellten Ansatz erfolgt die Überwachung der Verarbeitungseinheit 104 in Form eines Rechenkerns oder einer Logik beispielsweise durch einen onlinefähigen LBIST. Dies ist ein testbasierter Ansatz, der eine geeignete Hardwareunterstützung erfordert.
  • Hierbei legt der LBIST-Controller 108 Testmuster 112 an die zu testende Logik an und überprüft, ob die Testantwort 114 korrekt ist. Kennzeichnend für einen LBIST ist, dass beim Anlegen der Testmuster 112 Hardwarebestandteile, beispielsweise in Form von Scan Chains, verwendet werden, die im normalen Betrieb nicht durch Software (direkt) angesprochen werden können. Diese Hardwarestrukturen sind in der Regel für Testprozeduren bei der Fertigung vorgesehen. Da der LBIST Informationen in der getesteten Hardware zerstört, ist eine Interaktion von Software mit einer durch den LBIST beeinflussten Hardware eher schwierig vorherzusagen und wird daher vermieden.
  • Der LBIST wird nun online, d. h. im Betrieb, durchgeführt, und zwar zeitlich in einer solchen Form, dass das Starten des LBIST mit dem Empfangen von Frames synchronisiert ist. Dazu ist zunächst die Einbettung in ein onlinefähiges Software-Framework erforderlich. Der LBIST wird sozusagen eingepackt oder eingehüllt zwischen die beiden Schritte 330, 340, wie sie in 3 gezeigt sind.
  • Vor der Durchführung des LBIST oder eines LBIST-Teils ist ein Vorbereitungsschritt 330 erforderlich. Logikinterne Informationen, die durch den LBIST zerstört werden, werden dabei gesichert. Ferner sollte sichergestellt werden, dass während des geplanten Ablaufs des Tests kein anderes Task Rechenzeit benötigt. Ebenfalls werden beispielsweise Konfigurationsdaten der Logik in diesem Schritt zurückgelesen und mit korrekten Konfigurationsdaten verglichen. Durch ein erneutes Auslesen der Konfigurationsdaten bei der Vorbereitung kann die Existenz transienter Fehler nachgewiesen werden, die seit der letzten Durchführung des Tests in den Konfigurationsdaten aufgetreten sind.
  • Im Schritt 320 wird dann der Test oder ein Testteil durchgeführt. Während des Tests ist die Logik nicht benutzbar. Es ist vorteilhaft, wenn andere Rechenkerne oder Logiken davon nicht beeinflusst werden und noch zur Verfügung stehen.
  • Im Schritt 340 wird die Logik wieder in einen Zustand gebracht, der es erlaubt, dass die beabsichtigte Funktion wieder dargestellt werden kann, beispielsweise dass Software auf dem Core korrekt ablaufen kann. Dies erfolgt beispielsweise durch ein Beschreiben der Konfigurationsparameter oder ein Bereinigen interner Zustände, je nach Ausführungsbeispiel verbunden mit einem Laden der zuvor im Schritt 330 gesicherten Daten.
  • Die Synchronisation mit den Frames kann in verschiedener Form geschehen.
  • Wie in 4 gezeigt, findet beispielsweise zu jedem Frame eine Verarbeitung statt, auch als Task bezeichnet. Lediglich beispielhaft ist die Verarbeitung in 4 leicht phasenverschoben dargestellt. Die Framesynchronisation läuft in der Form ab, dass für einen Frame anstelle der normalen Bearbeitung der Test durchgeführt wird. Optional kann zusätzlich noch eine Basisbearbeitung in diesem Slot durchgeführt werden.
  • Eine andere Form der Synchronisation ist in 5 gezeigt. Dabei wird zu jedem Frame ein Teil des Tests durchgeführt. Vorteilhaft ist die Durchführung des Tests am Ende oder am Anfang eines Bearbeitungsschritts, da dann der Aufwand für die einhüllenden Schritte 330, 340 minimiert ist. Dieses Verfahren hat den Vorteil, dass für den Test kein ganzer Frame geopfert werden muss.
  • Entscheidend für beide Varianten der Synchronisation ist aber, dass die Durchführung des Tests innerhalb der Fehlertoleranzzeit abläuft.
  • Gemäß einem weiteren Ausführungsbeispiel wird zusätzlich oder alternativ zu einer Logik ein Speicherblock in einem MBIST getestet. Analog zur Logik erfolgt die Einbindung des Tests hierbei ebenfalls in synchronisierter Form, wie in den 4 und 5 gezeigt. Entscheidend für eine Systemeinbindung ist, dass der zu testende Speicherblock vom Rest des Systems hinreichend gut getrennt ist, sodass die Nichtverfügbarkeit des Speichers während des Tests im System realisierbar ist. Damit das Verfahren effektiv angewendet werden kann, sollte der zu testende Speicher bei jedem Frame neu beschrieben werden, damit das Löschen des Speichers durch den Test keine Rolle spielt. Alternativ werden Ersatzspeicher in der Größe der zu testenden Speicher vorgehalten.
  • Je nach Ausführungsbeispiel kann der Test in Hard- oder Software durchgeführt werden, wobei eine hardwareunterstützte Lösung in der Regel effizienter ist und eine höhere Überwachungsgüte erreicht.
  • Denkbar sind auch Kombinationen zwischen den unterschiedlichen Framesynchronisationsverfahren aus den 4 und 5 und den verschiedenen Testarten LBIST und MBIST.
  • Eine besonders hohe Testabdeckung wird beispielsweise durch die Verwendung möglichst vieler und gut ausgewählter Testmuster erreicht. Für ein gegebenes Sicherheitslevel, bei Kraftfahrzeugen ASIL A, B, C, D, werden damit Zielabdeckungen von beispielsweise 90, 97 oder 99 Prozent abgeleitet. Die Überwachungsgüte kann erhöht werden, indem mehr Testmuster verwendet werden. Beispielsweise wird bei der Verwendung von drei Testmustersätzen angenommen, dass jeder der drei Testmustersätze ausreicht, um eine 90-prozentige Überwachungsgüte zu erreichen, dass aber die Ressourcen nur ausreichen, um innerhalb einer Fehlertoleranzzeit einen der Testmustersätze abzuarbeiten. Stattdessen wird nun für ein erstes Fehlertoleranzintervall ein erster Testmustersatz verwendet, für ein zweites Fehlertoleranzintervall ein zweiter Testmustersatz verwendet usw. Es erfolgt somit ein gestaffelter Test mit verschiedenen Testmustersätzen in aufeinanderfolgenden Intervallen. In Summe wird dadurch eine höhere Überwachungsgüte erreicht, allerdings nicht innerhalb der Fehlertoleranzzeit. Sicherheitstechnisch ist dies aber dennoch ein Vorteil, da die Fehlertoleranzzeit aus der Betrachtung des ungünstigsten anzunehmenden Falles resultiert.
  • Umfasst ein Ausführungsbeispiel eine „und/oder“-Verknüpfung zwischen einem ersten Merkmal und einem zweiten Merkmal, so ist dies so zu lesen, dass das Ausführungsbeispiel gemäß einer Ausführungsform sowohl das erste Merkmal als auch das zweite Merkmal und gemäß einer weiteren Ausführungsform entweder nur das erste Merkmal oder nur das zweite Merkmal aufweist.

Claims (15)

  1. Verfahren (300) zum Überwachen eines Sensorsystems (100) eines Fahrzeugs, wobei das Sensorsystem (100) eine Verarbeitungseinheit (104) zum Verarbeiten von Sensordaten (106) und eine Selbsttesteinheit (108) zum Durchführen eines testmusterbasierten Selbsttests der Verarbeitungseinheit (104) aufweist, wobei das Verfahren (300) folgende Schritte umfasst: Einlesen (310) der Sensordaten (106); und Durchführen (320; 408) des Selbsttests in Abhängigkeit von einer zeitlichen Struktur der Sensordaten (106).
  2. Verfahren (300) gemäß Anspruch 1, bei dem die Sensordaten (106) eine Folge von Frames (400) repräsentieren, wobei der Schritt des Durchführens (320; 408) zumindest teilweise während der Dauer eines Frames (400) ausgeführt wird.
  3. Verfahren (300) gemäß Anspruch 2, bei dem im Schritt des Durchführens (320; 408) der Selbsttest am Anfang und/oder am Ende des Frames (400) durchgeführt wird.
  4. Verfahren (300) gemäß Anspruch 2 oder 3, mit einem Schritt des Verarbeitens (402, 406; 500) der Sensordaten (106), wobei der Schritt des Verarbeitens (402, 406; 500) zumindest teilweise während der Dauer des Frames (400) ausgeführt wird.
  5. Verfahren (300) gemäß Anspruch 4, bei dem der Schritt des Verarbeitens (402, 406; 500) und der Schritt des Durchführens (320; 408) sequenziell ausgeführt werden.
  6. Verfahren (300) gemäß einem der vorangegangenen Ansprüche, mit einem Schritt des Sicherns (330) von in der Verarbeitungseinheit (104) gespeicherten Daten vor dem Schritt des Durchführens (320; 408), um eine Sicherungskopie zu erhalten.
  7. Verfahren (300) gemäß einem der vorangegangenen Ansprüche, mit einem Schritt des Wiederherstellens (340) eines Arbeitszustands der Verarbeitungseinheit (104) nach dem Schritt des Durchführens (320; 408), insbesondere wobei im Schritt des Wiederherstellens (340) der Arbeitszustand unter Verwendung der Sicherungskopie wiederhergestellt wird.
  8. Verfahren (300) gemäß einem der vorangegagenen Ansprüche, im Schritt des Durchführens (320; 408) ein Anlegen zumindest eines Testmusters (112) an der Verarbeitungseinheit (104) ausgeführt wird, wobei durch das Testmuster (112) Hardwarebestandteile der Verarbeitungseinheit (104) angesprochen werden, insbesondere in Form von Scan Chains, die in einem Betrieb der Verarbeitungseinheit (104) zur Verarbeitung von Sensordaten (106) nicht angesprochen werden.
  9. Verfahren (300) gemäß Anspruch 6 oder 7, bei dem im Schritt des Sicherns (330) Konfigurationsdaten der Verarbeitungseinheit (104) gesichert werden.
  10. Verfahren (300) gemäß Anspruch 9, mit einem Schritt des Vergleichens der Konfigurationsdaten mit Referenzkonfigurationsdaten unter Verwendung der Sicherungskopie, um eine Konfiguration der Verarbeitungseinheit (104) zu überprüfen.
  11. Verfahren (300) gemäß einem der vorangegangenen Ansprüche, bei dem im Schritt des Durchführens (320; 408) der Selbsttest unter Verwendung zumindest zweier unterschiedlicher Testmuster (112) durchgeführt wird.
  12. Sensorsystem (100) mit folgenden Merkmalen: einer Verarbeitungseinheit (104) zum Verarbeiten von Sensordaten (106); und einer Selbsttesteinheit (108), die ausgebildet ist, um einen testmusterbasierten Selbsttest der Verarbeitungseinheit (104) in Abhängigkeit von einer zeitlichen Struktur der Sensordaten (106) durchzuführen.
  13. Sensorsystem (100) gemäß Anspruch 12, bei dem die Selbsttesteinheit (108) in die Verarbeitungseinheit (104) integriert oder Teil der Verarbeitungseinheit (104) ist, um den Selbsttest auf der Verarbeitungseinheit (104) durchzuführen.
  14. Computerprogramm, das ausgebildet ist, um das Verfahren (300) gemäß einem der Ansprüche 1 bis 11 auszuführen und/oder anzusteuern.
  15. Maschinenlesbares Speichermedium, auf dem das Computerprogramm nach Anspruch 14 gespeichert ist.
DE102016224253.9A 2016-12-06 2016-12-06 Verfahren zum Überwachen eines Sensorsystems eines Fahrzeugs und Sensorsystem Withdrawn DE102016224253A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102016224253.9A DE102016224253A1 (de) 2016-12-06 2016-12-06 Verfahren zum Überwachen eines Sensorsystems eines Fahrzeugs und Sensorsystem

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102016224253.9A DE102016224253A1 (de) 2016-12-06 2016-12-06 Verfahren zum Überwachen eines Sensorsystems eines Fahrzeugs und Sensorsystem

Publications (1)

Publication Number Publication Date
DE102016224253A1 true DE102016224253A1 (de) 2018-06-07

Family

ID=62164199

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102016224253.9A Withdrawn DE102016224253A1 (de) 2016-12-06 2016-12-06 Verfahren zum Überwachen eines Sensorsystems eines Fahrzeugs und Sensorsystem

Country Status (1)

Country Link
DE (1) DE102016224253A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021003582A1 (de) 2020-08-28 2022-03-03 Sew-Eurodrive Gmbh & Co Kg Programmierbare Signalverarbeitungseinheit und Verfahren zum Betrieb einer programmierbaren Signalverarbeitungseinheit

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021003582A1 (de) 2020-08-28 2022-03-03 Sew-Eurodrive Gmbh & Co Kg Programmierbare Signalverarbeitungseinheit und Verfahren zum Betrieb einer programmierbaren Signalverarbeitungseinheit
WO2022042929A1 (de) 2020-08-28 2022-03-03 Sew-Eurodrive Gmbh & Co. Kg Programmierbare signalverarbeitungseinheit und verfahren zum betrieb einer programmierbaren signalverarbeitungseinheit

Similar Documents

Publication Publication Date Title
DE102018113625A1 (de) Fehlerinjektionstestvorrichtung und -verfahren
DE102011086530A1 (de) Mikroprozessorsystem mit fehlertoleranter Architektur
DE102007048608A1 (de) Testeinrichtung, Anzeigevorrichtung und Verfahren zum Überprüfen einer Gültigkeit von Anzeigesignalen
DE102013203358A1 (de) System und verfahren zum verifizieren der integrität eines sicherheitskritischen fahrzeugsteuerungssystems
DE102009030774A1 (de) Verfahren zur rechnergestützten Erfassung von Fehlern beim Ablauf von einem oder mehreren softwarebasierten Programmen in einem System aus Komponenten
DE3336977A1 (de) Ausfallsicheres verfahren fuer einen fahrzeugcomputer
DE102019131865A1 (de) Verfahren und vorrichtung zur eigendiagnose der ram-fehlererkennungslogik eines antriebsstrangcontrollers
DE102017210787A1 (de) Verfahren und Vorrichtung zum Ermitteln von Anomalien in einem Kommunikationsnetzwerk
DE102016224253A1 (de) Verfahren zum Überwachen eines Sensorsystems eines Fahrzeugs und Sensorsystem
DE112016007054B4 (de) Anzeigevorrichtung und Anzeigesteuerverfahren
WO2018082836A1 (de) Verfahren und vorrichtung zum überwachen eines bildsensors
DE102006006843B4 (de) Verfahren zum Antworten auf einen Steuermodulausfall
EP3739479B1 (de) Verfahren zur fehlersuche in der programmlogik eines systems verteilter programmierbarer gatteranordnungen
DE102004051966A1 (de) Verfahren, Betriebssystem und Rechengerät zum Abarbeiten eines Computerprogramms
DE102017214610B4 (de) Verfahren zum Überprüfen von zumindest einer Fahrzeugfunktion sowie Prüfvorrichtung
DE102018201710A1 (de) Verfahren und Vorrichtung zum Überprüfen einer Funktion eines neuronalen Netzes
WO2016206847A1 (de) Verfahren und vorrichtung zum absichern einer programmzählerstruktur eines prozessorsystems und zum überwachen der behandlung einer unterbrechungsanfrage
DE102015209033A1 (de) Verfahren und Vorrichtung zum Liefern einer Prüfantwort
DE102009038248A1 (de) Verfahren zum Entfernen modularer Software
EP3789832B1 (de) Vorrichtung und verfahren zur ausführung einer sicherheitsfunktion
DE102018210733A1 (de) Verfahren zum Überwachen wenigstens einer Recheneinheit
WO2017153411A1 (de) Verfahren zum betreiben eines steuergeräts für ein kraftfahrzeug
DE102017116081A1 (de) Verfahren und Vorrichtung zum Konfigurieren einer Ausführungseinrichtung und zum Erkennen eines Betriebszustands derselben
DE102022134058A1 (de) Prüfaufbau und Verfahren zum Testen eines Steuergerätes
DE19642843A1 (de) Steuergerät

Legal Events

Date Code Title Description
R005 Application deemed withdrawn due to failure to request examination