[go: up one dir, main page]

WO2010046200A1 - Verfahren zur überwachung der funktionsfähigkeit eines elektronischen bausteins - Google Patents

Verfahren zur überwachung der funktionsfähigkeit eines elektronischen bausteins Download PDF

Info

Publication number
WO2010046200A1
WO2010046200A1 PCT/EP2009/062522 EP2009062522W WO2010046200A1 WO 2010046200 A1 WO2010046200 A1 WO 2010046200A1 EP 2009062522 W EP2009062522 W EP 2009062522W WO 2010046200 A1 WO2010046200 A1 WO 2010046200A1
Authority
WO
WIPO (PCT)
Prior art keywords
electronic
electronic component
comparator
test pattern
fpga
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.)
Ceased
Application number
PCT/EP2009/062522
Other languages
English (en)
French (fr)
Inventor
Tobias Stumber
Dietmar Merten
Michael Smuda Von Trzebiatowski
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
Publication of WO2010046200A1 publication Critical patent/WO2010046200A1/de
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1479—Generic software techniques for error detection or fault masking
    • G06F11/1487—Generic software techniques for error detection or fault masking using N-version programming
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/04—Monitoring the functioning of the control system
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/04—Monitoring the functioning of the control system
    • B60W2050/041—Built in Test Equipment [BITE]

Definitions

  • the invention relates to a method for monitoring the functionality of an electronic component in a control unit, such a control unit and a computer program and a computer program product for carrying out the method.
  • Electronic control units are used in motor vehicles in various areas to control and / or regulate various processes. That is how it is
  • control devices in devices for driving state recognition known in which different sizes, such as.
  • the steering angle speed, but also optical signals or image signals are recorded and evaluated to detect a critical driving condition.
  • the publication DE 10 2005 057 267 A1 describes a method and a device for driving state recognition, in which the course of a signal characterizing the driving state is evaluated and in a typical course a signal characterizing the driving state is generated.
  • the device in this case has an electronic control unit, which consists essentially of components such as input circuit, computer and output circuit, wherein the individual components are connected for mutual data and information exchange with a bus system.
  • an electronic control unit which consists essentially of components such as input circuit, computer and output circuit, wherein the individual components are connected for mutual data and information exchange with a bus system.
  • a video camera is used, which is connected to the input circuit.
  • video-based driver assistance systems have a very high resource requirement due to the complexity of the environment. This is also reflected in the hardware used.
  • ISO 26262 is an intended ISO standard for automotive safety-related systems that defines a process framework and process model together with required activities and work products as well as applicable methods.
  • the implementation of the standard is intended to ensure the functional safety of an electronic system in motor vehicles.
  • hazard analysis and risk assessment method that identifies potentially dangerous situations based on the system description.
  • Each hazard is then classified with a safety requirement level from A to D or classified as non-safety relevant.
  • the level of injury, the frequency of the situation and the value of the situation by the driver must be estimated individually for each identified hazard.
  • the classification QM (quality managed) or ASIL (automotive safety integrity level) A to D can then be read for each hazard.
  • the standard addresses the protection of systems in the automotive sector, if it can come through a failure of the hardware or by software implementation errors in the technical sense to a hazard. Functional inadequacies, which, for example, result from inadequate detection of the surroundings, are not addressed by the standard. If necessary, these must be addressed via further measures outside the standard.
  • the software has a negligible error in understanding the standard if it is developed according to the processes of the standard. This safety concept shows the protection of E / E / PES systems in the sense of the standard. This protection is generally driven by the hardware.
  • errors are u.a. permanently random errors, such as a defective RAM cell, systematic errors, such as, for example, an incorrectly designed operating temperature, transient errors, such as, for example, a single event upset (bit dump). These errors can affect program and data.
  • the specifications are that the system under consideration is fail-safe, ie that switching off the system in the event of a fault is always safe. In addition, an error that leads to failure of any communication (fail-silent), also in the safe state.
  • the method according to the invention serves to monitor the operability of an electronic component in a motor vehicle.
  • a quantity relating to a driving state of the motor vehicle is supplied to the electronic module as an input signal for processing.
  • An output signal from the The electronic module is forwarded to an electronic processing unit in which the output signal is processed further with diverse software algorithms, the outputs of the diversified software algorithms being compared in a comparator.
  • two software algorithms are used whose outputs are compared in the comparator.
  • the control unit with the electronic component is used, for example, in a video-based driver assistance system in which a driving condition monitoring is performed.
  • the electronic module an image signal can be supplied as an input signal.
  • the electronic component which is designed, for example, as FPGA (field programmable gate array: locally modifiable logic module), can be monitored with a test coverage of, for example, more than 90%.
  • the electronic component is additionally supplied with a test pattern, which is processed in the electronic component.
  • the processed test pattern is then forwarded to the electronic processing unit.
  • the processed test pattern and the output signal can be processed separately in the electronic processing unit, for example a microcontroller.
  • test pattern verification In the electronic processing unit, a test pattern verification can be performed. A failure of the test pattern analysis regularly leads to an error.
  • the functionality of the comparator is monitored.
  • SCON safety controller
  • the described control unit for a motor vehicle is used in particular for carrying out a method of the type described above.
  • This has an electronic component, for example an FPGA, and an electronic processor, for example a microcontroller, wherein the electronic component is designed for receiving and processing a driving condition of the motor vehicle size and the electronic processing unit is designed for further processing of an output signal of the electronic component.
  • di- versitive software algorithms are used for further processing in the electronic processing unit.
  • a comparator is also provided which is adapted to compare outputs of the diversified software algorithms.
  • a safety device for monitoring the comparator for example a hardware-independent SCON, is provided.
  • the presented computer program comprises program code means for carrying out all the steps of a method described above when the computer program is executed on a computer or a corresponding computing unit, in particular in a control unit of the type described.
  • the computer program product comprises these program code means which are stored on a computer-readable data carrier in order to carry out all the steps of a presented method when the computer program is stored on a computer-readable data carrier
  • the presented method has, at least in some of the embodiments set out, a number of advantages.
  • a generic monitoring of the electronic component and thus an FPGA without the use of explicit hardware properties of the FPGA can be performed.
  • the use of divergent algorithms in the electronic arithmetic unit greatly simplifies the complex self-diagnosis of the arithmetic unit at a high level of abstraction. Therefore, even complex microcontrollers can be used in an ASIL-B control unit.
  • existing hardware concepts can be used for both QM and ASIL A / B.
  • Figure 1 shows a schematic representation of an embodiment of a control device.
  • Figure 2 shows a schematic representation of a hardware concept of a device for detecting the driving condition.
  • Figure 3 shows a block diagram of the structure of the software in a device for driving condition detection.
  • FIG. 4 shows the transition from an uncritical to a critical transient error.
  • FIG. 5 shows a system concept for a control unit for driving state detection.
  • FIG. 6 illustrates the detection of permanent FPGA errors.
  • FIG. 7 shows a possible comparator concept.
  • control unit 10 has an electronic
  • Module 12 in this case an FPGA, and an electronic processing unit 14, in this embodiment, a microcontroller on. Furthermore, a comparator 16 and a controller 18 for monitoring the comparator 16 are provided in the control unit 10. In the electronic module 12, an area 20 for storing an algorithm and a generator 22 for generating a test pattern is provided.
  • a first region 24 for a first algorithm, a second region 26 for a second algorithm, and a third region 28 for a test pattern verification are provided in the electronic unit 14.
  • An imager 30 passes captured image signals to the electronic device 12. In the data flow of the image signals before the processing by the electronic module 12 test pattern both before and after the relevant
  • Input image data The test patterns are processed by the module 12 without special treatment.
  • the result of the calculations can be stored in a block RAM (not shown) between the block 12 and the arithmetic unit 14. In this case, it is not relevant whether the module 12 and the computing unit 14 are separate or integrated components.
  • the results of the block 12 are processed separately according to image and test pattern in the arithmetic unit 14.
  • a test pattern verification compares the block 12 result of the test pattern with known setpoints.
  • the comparator 16 represents the single-point failure of the arithmetic unit 14. In this, the two diverse software channels are compared and given a detected equivalence on a vehicle bus 32. The comparator 16 is monitored by the hardware-independent SCON (safety controller).
  • FIG. 2 shows a schematic representation of a device for FahrSchser- recognition is shown.
  • This device designated by the reference numeral 50, includes a power port 52 which is connected to the electrical system of the
  • Vehicle (arrow 54), a controller 56, a nonvolatile memory (NVM) memory 58, an FPGA 60, an imager 62, a block memory 64 and a lens unit 70.
  • Incident light 72 is detected by the lens unit 70 and relayed to the imager 62.
  • the imager 62 passes image data to the FPGA 60, as indicated by arrow 74.
  • the FPGA 60 includes a logic unit 76, an embedded core 78 and an area 80 for storing the algorithms. Furthermore, the FPGA 60 is connected to the block memory 64, and the NVM memory 58. To the outside, the FPGA 60 communicates with an on-board CAN bus (double arrow 82) and via the controller 56 with another fieldbus system (double arrow 86), for example a FlexRay.
  • an on-board CAN bus double arrow 82
  • another fieldbus system double arrow 86
  • FIG. 3 shows a block diagram of the structure of the software used in a driving state identification device. External data is contained in a first block 100, in a second block the data and programs of the driver condition detection device and in a third block
  • Block 104 the output data.
  • the external data includes image sensor data 106 and vehicle sensor data 108.
  • the image sensor data 106 is passed to the FPGA 110, where image preprocessing and data reduction is performed (block 1 12).
  • a microcontroller 1 14 is further provided. This captures the image data of the FPGA 1 10 and performs object formation in the image plane (block 1 16).
  • the vehicle sensor data 108 is used in addition to the real object formation (block 1 18) and the state estimation (block 120).
  • the FPGA 1 10 in the context of the considered function thus serves the data reduction at the level of low-level image processing. From the point of view of the FPGA 1 10, every picture is completely new and without reference to previous pictures.
  • Transient errors in the data flow of the FPGA 1 10 correspond to the general sensor noise.
  • the processing of noisy input signals is a functional requirement for the algorithms.
  • the implemented security concept therefore focuses on the detection of permanent faults of the FPGA 1 10.
  • the algorithmic logic of the object formation is calculated in the microcontroller 14. In this case, not only a single image evaluation, as is the case with the FPGA 1 10 carried out. Due to the temporal correlation, it is not possible to neglect transient errors.
  • the detection of transient and permanent errors is addressed by the security concept.
  • FIG. 4 illustrates the transition from an uncritical to a critical transient error.
  • a two-dimensional image plane 150 is juxtaposed with a real environment 152.
  • a region 154 shows non-critical transient errors and a region 156 transient errors that must be detected.
  • An imager 158 generates the data of the image plane 150, which is converted into a real model or the real environment 152 and forwarded to a vehicle bus 160.
  • the amount of data is plotted against the information content per date 164.
  • FIG. 5 shows a possible system concept for a control unit that is used in a driving condition detection.
  • the illustration shows an imager, an FPGA 402, a RAM 404, a microcontroller 406 and a vehicle bus 408.
  • the FPGA 402 includes a test pattern 410 and a first algorithm 412.
  • a first algorithm 414 In the microcontroller 406, a first algorithm 414, a second algorithm 416, a test pattern verifier 418 and a comparator 420 are provided.
  • the data flow is, for example, one-channel from the imager 400 to the FPGA 402.
  • the data preprocessing takes place.
  • the result is stored in common memory of FPGA 402 and microcontroller 406, namely RAM 404.
  • microcontroller 406 calculates in microcontroller 406 two diverse algorithms the object data.
  • the results of the diverse algorithms are compared in the comparator 420.
  • the image data is expanded by defined and non-static test patterns 410, which are processed in the FPGA 402 without special treatment.
  • the result of the test pattern 410 is checked in the microcontroller 406.
  • a prerequisite is sufficient diversification of the algorithms on the basis of the same FPGA results, which allows preprocessing, and that sufficiently diverse algorithms on a faulty hardware do not come to the same result.
  • the advantage is that the basic hardware concept can be adopted.
  • Another advantage is the good recognition of systematic and random transient / permanent errors.
  • FIG. 6 illustrates the detection of permanent FPGA errors.
  • An imager outputs image data 452 to an FPGA 454.
  • a test pattern 456 is generated in this FPGA 454.
  • a test pattern verification takes place, so that a data record 460 with image data 452 and test pattern 456 is present.
  • the test patterns 456 at the beginning and at the end of each image allow complete test coverage of the FPGA 454 (pipelining in the FPGA).
  • the record 460 is forwarded (arrow 462).
  • the test pattern 456 at the beginning and at the end of the actual image ensures for the current cycle that there are no permanent errors.
  • the patterns are not constant, but are shuffled against each other each cycle.
  • the memory in the FPGA 454 is completely scanned.
  • the results are stored in blocks in the result list.
  • the position of the result block within the list is also rotated. The relevant memory area is thereby protected.
  • FIG. 7 shows a possible comparator concept.
  • the illustration shows a comparator 500 with two inputs, namely a channel A 502 and a channel B 504. It should be noted that in each multi-channel system, the comparison of the channels 502 and 504 is the only "single point of failure".
  • the illustration also shows a SCON 506, a cyclic redundancy check (CRC) 508, a message counter 510 and a vehicle bus 512.
  • CRC cyclic redundancy check
  • the SCON 506 sends a so-called challenge (arrow 514) and receives a response (arrow) 516). Depending on the outcome of the check, the SCON 506 sends an enable or disable to the
  • CRC cyclic redundancy check
  • Vehicle bus 512 (arrow 518).
  • stuck-at-1 permanent approval
  • the SCON 506 makes a request that must lead to a rejection. If the comparator 500 answers incorrectly, the SCON 506 gives the
  • Vehicle bus 512 not free (disable).

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Transportation (AREA)
  • Mechanical Engineering (AREA)
  • Traffic Control Systems (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Es werden ein Verfahren Überwachung der Funktionsfähigkeit eines elektronischen Bausteins (12) vorgestellt. Bei dem Verfahren wird dem elektronischen Baustein (12) eine einen Fahrzustand des Kraftfahrzeugs betreffende Größe als Eingangssignal zugeführt und ein Ausgangssignal des elektronischen Bausteins (12) an eine elektronische Recheneinheit (14) weitergeleitet, in der dieses Ausgangssignal mit diversitären Softwarealgorithmen weiterverarbeitet wird. Die Ausgaben der diversitären Softwarealgorithmen werden in einem Komparator (16) miteinander verglichen.

Description

Beschreibung
Titel
Verfahren zur Überwachung der Funktionsfähigkeit eines elektronischen Bausteins
Die Erfindung betrifft ein Verfahren zur Überwachung der Funktionsfähigkeit eines elektronischen Bausteins in einem Steuergerät, ein solches Steuergerät sowie ein Computerprogramm und ein Computerprogrammprodukt zur Durchfüh- rung des Verfahrens.
Stand der Technik
Elektronische Steuergeräte werden bei Kraftfahrzeugen in unterschiedlichen Be- reichen eingesetzt, um diverse Abläufe zu steuern und/oder zu regeln. So ist der
Einsatz von Steuergeräten in Vorrichtungen zur Fahrzustandserkennung bekannt, bei denen unterschiedliche Größen, wie bspw. die Lenkwinkelgeschwindigkeit, aber auch optische Signale bzw. Bildsignale aufgezeichnet und ausgewertet werden, um einen kritischen Fahrzustand zu erkennen.
Die Druckschrift DE 10 2005 057 267 A1 beschreibt ein Verfahren und eine Vorrichtung zur Fahrzustandserkennung, bei denen der Verlauf eines den Fahrzustand charakterisierenden Signals ausgewertet und bei einem typischen Verlauf ein den Fahrzustand kennzeichnendes Signal erzeugt wird. Die Vorrichtung weist dabei eine elektronische Steuereinheit auf, die im wesentlichen aus Komponenten wie Eingangsschaltung, Rechner und Ausgangsschaltung besteht, wobei die einzelnen Komponenten zum gegenseitigen Daten- und Informationsaustausch mit einem Bussystem verbunden sind. Zur Erkennung von Fahrbahnrandmarkierungen wird eine Videokamera eingesetzt, die mit der Eingangsschaltung ver- bunden ist. Zu beachten ist jedoch, dass videobasierte Fahrerassistenzsysteme aufgrund der Komplexität der Umwelt einen äußerst hohen Ressourcenbedarf haben. Dies spiegelt sich auch in der verwendeten Hardware wider. Zum Einsatz kommen äußerst leistungsfähige automotive zertifizierte Bausteine, deren Komplexität es zunehmend schwierig macht, die Hardware im Rahmen einer neben den Applikationen laufenden Selbstdiagnose vollständig, d.h. mit einer Testabdeckung von bspw. mehr als 90%, zu überwachen. Auch die Überwachung von FPGAs im automobilen Umfeld ist bisher nicht zufriedenstellend gelöst.
Zur Gewährleistung der Funktionsfähigkeit der eingesetzten Steuergeräte sind unterschiedliche Vorgehensweisen bekannt. Dabei müssen Anforderungen an Hard- und Software formuliert werden, die einen sicheren Betrieb gestatten. Zur Vereinheitlichung der Entwicklungsprozesse und der Überwachung im Betrieb werden normierte Vorgehensweisen angestrebt.
Die ISO 26262 ist eine vorgesehene ISO-Norm für sicherheitsrelevante Systeme in Kraftfahrzeugen, die ein Prozess-Rahmenwerk und Vorgehensmodell zusammen mit geforderten Aktivitäten und Arbeitsprodukten sowie anzuwendenden Methoden definiert. Die Umsetzung der Norm soll die funktionale Sicherheit eines elektronischen Systems in Kraftfahrzeugen gewährleisten.
Dabei wird eine Methode zur Gefahrenanalyse und Risikoabschätzung vorgeschlagen, bei der auf Grundlage der Systembeschreibung die möglicherweise gefährlichen Situationen identifiziert werden. Jede Gefahr wird dann mit einer Si- cherheitsanforderungsstufe von A bis D klassifiziert oder als nicht sicherheitsrelevant eingeordnet. Dazu muss für jede identifizierte Gefahr einzeln der Verletzungsgrad, die Häufigkeit der Situation und die Wertbarkeit der Situation durch den Fahrer abgeschätzt werden. Aus einer vorgegebenen Tabelle lässt sich dann für jede Gefahr die Einstufung QM (quality managed) oder ASIL (automotive sa- fety integrity level) A bis D ablesen.
Mit steigendem ASIL steigen auch die Anforderungen an die Sicherheit, die in den nachfolgenden Teilen spezifiziert sind. An Gefahren der Klasse QM sind kei- ne Anforderungen gestellt, die über das übliche Qualitätsmanagement des Systemherstellers hinausgehen. Die Norm definiert konkrete Anforderungen an Software und Hardware, sowohl für die Entwicklungsprozesse als auch für das Fehlverhalten im Feld, und beein- flusst bereits heute die Anforderungen an die Systeme im Fahrzeug. Besonderes Augenmerk verdient die Erkennung von permanenten zufälligen bzw. systematischen Fehlern. Dabei werden Prozesse empfohlen und zum Teil quantitative Forderungen an Ausfallraten und Testabdeckungen für die verschiedenen Sicherheitsstufen vorgegeben.
Die Norm adressiert die Absicherung von Systemen im automobilen Bereich, wenn es durch ein Versagen der Hardware oder durch Software- Implementierungsfehler im technischen Sinne zu einer Gefährdung kommen kann. Funktionale Unzulänglichkeiten, die bspw. durch unzureichende Umfelderfassung entstehen, werden nicht durch die Norm adressiert. Diese müssen ggf. über weitere Maßnahmen außerhalb der Norm adressiert werden. Die Software hat im Verständnis der Norm einen vernachlässigbar kleinen Fehler, wenn sie nach den Prozessen der Norm entwickelt wird. Dieses Sicherheitskonzept zeigt die Absicherung von E/E/PES-Systemen im Sinne der Norm. Diese Absicherung ist im allgemeinen durch die Hardware getrieben.
Betrachtete Fehlerarten sind u.a. permanent zufällige Fehler, wie bspw. eine defekte RAM-Zelle, systematische Fehler, wie bspw. eine falsch ausgelegte Betriebstemperatur, transiente Fehler, wie bspw. ein Single Event Upset (Bit- Kipper). Diese Fehler können sich auf Programm und Daten auswirken.
Vorgaben sind, dass das betrachtete System ausfallsicher (fail-safe) ist, d.h., dass das Abschalten des Systems im Fehlerfall immer sicher ist. Zudem führt ein Fehler, der zum Ausbleiben jeder Kommunikation führt (fail-silent), ebenfalls in den sicheren Zustand.
Offenbarung der Erfindung
Das erfindungsgemäße Verfahren dient zur Überwachung der Funktionsfähigkeit eines elektronischen Bausteins in einem Kraftfahrzeug. Dabei wird dem elektro- nischen Baustein eine einen Fahrzustand des Kraftfahrzeugs betreffende Größe als Eingangssignal zur Verarbeitung zugeführt. Ein Ausgangssignal des elektro- nischen Bausteins wird an eine elektronische Recheneinheit weitergeleitet, in der das Ausgangssignal mit diversitären Softwarealgorithmen weiterverarbeitet wird, wobei die Ausgaben der diversitären Softwarealgorithmen in einem Komparator miteinander verglichen werden. Üblicherweise werden zwei Softwarealgorithmen eingesetzt, deren Ausgänge in dem Komparator miteinander verglichen werden.
Ein fehlgeschlagener Vergleich führt zu einem Fehlerfall.
Hinreichend komplexe und diversitäre Algorithmen kommen nur auf fehlerfreier Hardware zu äquivalenten Ergebnissen. Somit übernehmen diversitäre Algorith- men auch die Funktion der Selbstdiagnose auf komplexer Hardware.
Das Steuergerät mit dem elektronischen Baustein kommt bspw. bei einem videobasierten Fahrerassistenzsystem zum Einsatz, bei dem eine Fahrzustandsüber- wachung durchgeführt wird. Bei dieser Anwendung kann dem elektronischen Baustein ein Bildsignal als Eingangssignal zugeführt werden. Hierbei kann der elektronische Baustein, der bspw. als FPGA (field programmable gate array: vor Ort modifizierbarer Logikbaustein) ausgebildet ist, mit einer Testabdeckung von bspw. mehr als 90% überwacht werden.
In Ausgestaltung wird dem elektronischen Baustein zusätzlich ein Testmuster zugeführt, das in dem elektronischen Baustein verarbeitet wird. Das verarbeitete Testmuster wird dann an die elektronische Recheneinheit weitergeleitet. Dabei kann das verarbeitete Testmuster und das Ausgangssignal getrennt in der elektronischen Recheneinheit, bspw. ein Mikrocontroller, weiterverarbeitet werden.
In der elektronischen Recheneinheit kann eine Testmusterverifikation durchgeführt werden. Ein Fehlschlagen der Testmusteranalyse führt regelmäßig zu einem Fehlerfall.
In Ausgestaltung wird die Funktionsfähigkeit des Komparators überwacht. Hierzu wir bspw. ein in Hardware unabhängiger SCON (safety Controller) eingesetzt.
Das beschriebene Steuergerät für ein Kraftfahrzeug dient insbesondere zur Durchführung eines Verfahrens der vorstehend beschriebenen Art. Dieses weist einen elektronischen Baustein, bspw. ein FPGA, und eine elektronischen Recheneinheit, bspw. einen Mikrocontroller, auf, wobei der elektronische Baustein zur Aufnahme und zur Verarbeitung einer einen Fahrzustand des Kraftfahrzeugs betreffenden Größe ausgebildet ist und die elektronische Recheneinheit zur Weiterverarbeitung eines Ausgangssignal des elektronischen Bausteins ausgelegt ist. Bei der Weiterverarbeitung in der elektronischen Recheneinheit werden di- versitäre Softwarealgorithmen eingesetzt. Es ist weiterhin ein Komparator vorgesehen, der dafür ausgelegt ist, Ausgaben der diversitären Softwarealgorithmen miteinander zu vergleichen.
In Ausgestaltung ist eine Sicherheitseinrichtung zur Überwachung des Kompara- tors, bspw. ein in Hardware unabhängiger SCON, vorgesehen.
Das vorgestellte Computerprogramm umfasst Programmcodemittel, um alle Schritte eines vorstehend beschriebenen Verfahrens durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Rechen- einheit, insbesondere in einem Steuergerät der beschriebenen Art, ausgeführt wird.
Das Computerprogrammprodukt weist diese Programmcodemittel auf, die auf einem computerlesbaren Datenträger gespeichert sind, um alle Schritte eines vor- gestellten Verfahrens durchzuführen, wenn das Computerprogramm auf einem
Computer oder einer entsprechenden Recheneinheit, insbesondere in einem Steuergerät, wie dies vorstehend beschrieben ist, ausgeführt wird.
Das vorgestellte Verfahren weist, zumindest in einigen der dargelegten Ausfüh- rungen, eine Reihe von Vorteilen auf. So kann eine generische Überwachung des elektronischen Bausteins und damit eines FPGA ohne Verwendung expliziter Hardwareeigenschaften des FPGA durchgeführt werden. Die Verwendung diver- sitärer Algorithmen in der elektronischen Recheneinheit vereinfacht auf hohem Abstraktionsniveau die aufwendige Selbstdiagnose der Recheneinheit stark. Da- her können selbst komplexe MikroController in einem ASIL-B-Steuergerät eingesetzt werden. Außerdem können, wenn genügend Ressourcen vorhanden sind, bestehende Hardwarekonzepte sowohl für QM als auch für ASIL-A/B verwendet werden.
Weitere Vorteile und Ausgestaltung der Erfindung ergeben sich aus der Beschreibung und den beiliegenden Zeichnungen. Es versteht sich, dass die voranstehend genannten und die nachstehend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, oh- ne den Rahmen der vorliegenden Erfindung zu verlassen.
Kurze Beschreibung der Zeichnungen
Figur 1 zeigt in schematischer Darstellung eine Ausführungsform eines Steuer- geräts.
Figur 2 zeigt in schematischer Darstellung ein Hardwarekonzept einer Vorrichtung zur Erkennung des Fahrzustands.
Figur 3 zeigt in einem Blockschaltbild den Aufbau der Software in einer Vorrichtung zur Fahrzustandserkennung.
Figur 4 zeigt den Übergang von einem unkritischen zu einem kritischen transienten Fehler.
Figur 5 zeigt ein Systemkonzept für ein Steuergerät zur Fahrzustandserfassung.
Figur 6 verdeutlicht die Detektion permanenter FPGA-Fehler.
Figur 7 zeigt ein mögliches Komparatorkonzept.
Ausführungsformen der Erfindung
In Figur 1 ist eine Ausführung eines Steuergeräts, insgesamt mit der Bezugsziffer 10 bezeichnet, dargestellt. Dieses Steuergerät 10 weist einen elektronischen
Baustein 12, in diesem Fall ein FPGA, und eine elektronische Recheneinheit 14, in dieser Ausführung einen MikroController, auf. Weiterhin ist in dem Steuergerät 10 ein Komparator 16 und ein Controller 18 zur Überwachung des Komparators 16 gegeben. In dem elektronischen Baustein 12 ist ein Bereich 20 zum Ablegen eines Algorithmus und ein Generator 22 zum Erzeugen eines Testmusters vorgesehen.
In der elektronischen Einheit 14 sind ein erster Bereich 24 für einen ersten Algo- rithmus, ein zweiter Bereich 26 für einen zweiten Algorithmus und ein dritter Bereich 28 für eine Testmusterverifikation vorgesehen.
Ein Bildgeber 30 gibt erfasste Bildsignale an den elektronischen Baustein 12 weiter. In den Datenfluss der Bildsignale werden vor der Bearbeitung durch den elektronischen Baustein 12 Testmuster sowohl vor als auch nach den relevanten
Bilddaten eingespeist. Die Testmuster werden ohne Sonderbehandlung durch den Baustein 12 verarbeitet. Das Ergebnis der Berechnungen kann in einem Block-RAM (nicht dargestellt) zwischen dem Baustein 12 und der Recheneinheit 14 abgelegt werden. Hierbei ist es nicht relevant, ob es sich bei dem Baustein 12 und der Recheneinheit 14 um getrennte oder integrierte Komponenten handelt.
Die Ergebnisse des Bausteins 12 werden getrennt nach Bild und Testmuster in der Recheneinheit 14 weiterverarbeitet. Eine Testmusterverifikation vergleicht das Baustein- 12 Ergebnis des Testmusters mit bekannten Sollwerten.
Bei der dargestellten Ausführung verarbeiten zwei diversitäre Algorithmen die
Berechnungen des elektronischen Bausteins 12 bezüglich des tatsächlichen Bildes. Der Komparator 16 stellt den Single point failure der Recheneinheit 14 dar. In diesem werden die beiden diversitären Softwarekanäle verglichen und bei festgestellter Äquivalenz auf einen Fahrzeugbus 32 gegeben. Der Komparator 16 wird dabei durch den in Hardware unabhängigen SCON (safety Controller) überwacht.
In Figur 2 ist in schematischer Darstellung eine Vorrichtung zur Fahrzustandser- kennung dargestellt. Diese Vorrichtung, die mit der Bezugsziffer 50 bezeichnet ist, umfasst einen Leistungsanschluss 52, der mit dem elektrischen System des
Fahrzeugs verbunden ist (Pfeil 54), einen Controller 56, einen NVM-Speicher 58 (non volatile memory: nichtflüchtiger Speicher), einen FPGA 60, einen Bildgeber 62, einen Blockspeicher 64 und eine Linseneinheit 70. Einfallendes Licht 72 wird von der Linseneinheit 70 erfasst und an den Bildgeber 62 weitergegeben. Der Bildgeber 62 gibt Bilddaten, wie mit Pfeil 74 verdeutlicht, an den FPGA 60 weiter.
Der FPGA 60 umfasst eine Logikeinheit 76, einen eingebetteten Kern 78 und einen Bereich 80 zum Ablegen der Algorithmen. Weiterhin ist der FPGA 60 mit dem Blockspeicher 64, und dem NVM-Speicher 58 verbunden. Nach außen kommuniziert der FPGA 60 mit einem fahrzeugeigenen CAN-Bus (Doppelpfeil 82) und über den Controller 56 mit einem weiteren Feldbussystem (Doppelpfeil 86), bspw. ein FlexRay.
In Figur 3 ist in einem Blockschaltbild der Aufbau der in einer Fahrzustandser- kennungsvorrichtung eingesetzten Software dargestellt. In einem ersten Block 100 sind externe Daten enthalten, in einem zweiten Block die Daten und Pro- gramme der Vorrichtung zur Fahrerszustandserkennung und in einem dritten
Block 104 die ausgegebenen Daten.
Die externen Daten umfassen Bildsensordaten 106 und Fahrzeugsensordaten 108. Die Bildsensordaten 106 werden an den FPGA 1 10 weitergegeben, in dem eine Bildvorverarbeitung und Datenreduktion vorgenommen wird (Block 1 12). Innerhalb der Vorrichtung ist weiterhin einen MikroController 1 14 vorgesehen. Dieser erfasst die Bilddaten des FPGA 1 10 und führt eine Objektbildung in der Bildebene durch (Block 1 16). Die Fahrzeugsensordaten 108 werden zusätzlich zur realen Objektbildung (Block 1 18) und zur Zustandsschätzung (Block 120) heran- gezogen.
Das FPGA 1 10 im Kontext der betrachteten Funktion dient somit der Datenreduktion auf Ebene der Low-Level-Bildverarbeitung. Aus Sicht des FPGA 1 10 ist daher jedes Bild vollständig neu und ohne Bezug auf vorangegangene Bilder.
Transiente Fehler im Datenfluss des FPGA 1 10 entsprechen dem allgemeinen Sensorrauschen. Die Verarbeitung verrauschter Eingangssignale ist eine funktionale Anforderung an die Algorithmik. Das verwirklichte Sicherheitskonzept konzentriert sich daher auf die Erkennung permanenter Fehler des FPGA 1 10. Die algorithmische Logik der Objektbildung wird in dem Mikrocontroller 1 14 berechnet. Hierbei wird nicht nur eine Einzelbildauswertung, wie dies beim FPGA 1 10 der Fall ist, durchgeführt. In Folge der zeitlichen Korrelation ist es nicht möglich, transiente Fehler zu vernachlässigen. Die Erkennung transienter und per- manenter Fehler ist durch das Sicherheitskonzept adressiert.
Figur 4 verdeutlicht den Übergang von einem unkritischen zu einem kritischen transienten Fehler. In der Darstellung ist eine zweidimensionale Bildebene 150 einer realen Umgebung 152 gegenübergestellt. Ein Bereich 154 zeigt unkritische transiente Fehler und ein Bereich 156 transiente Fehler, die erkannt werden müssen.
Ein Bildgeber 158 erzeugt die Daten der Bildebene 150, die in ein reales Modell bzw. die reale Umgebung 152 überführt und an einen Fahrzeugbus 160 weiter- gegeben werden.
In Bezug zu den unterschiedlichen Ebenen ist die Datenmenge im Verhältnis zum Informationsgehalt pro Datum 164 aufgetragen. Zu erkennen ist das Anwachsen des Informationsgehalts 164 der Datenmenge 162 von der Bildebene 150 hin zu der realen Umgebung 152. In diesem Bereich liegen auch transiente
Fehler 156 vor, die erkannt werden müssen.
In Figur 5 ist ein mögliches Systemkonzept für ein Steuergerät, dass bei einer Fahrzustandserfassung zum Einsatz kommt, wiedergegeben. Die Darstellung zeigt einen Bildgeber, einen FPGA 402, ein RAM 404, einen Mikrocontroller 406 und einen Fahrzeugbus 408.
Der FPGA 402 weist ein Testmuster 410 und einen ersten Algorithmus 412 auf. In dem Mikrocontroller 406 sind ein erster Algorithmus 414, ein zweiter Algorith- mus 416, ein Testmusterverifikator 418 und ein Komparator 420 vorgesehen.
Der Datenfluss ist bspw. einkanalig von dem Bildgeber 400 zu dem FPGA 402. In dem FPGA 402 findet die Datenvorverarbeitung statt. Das Ergebnis wird im gemeinsamen Speicher von FPGA 402 und Mikrocontroller 406, nämlich dem RAM 404, abgelegt. Auf Basis dieser Ergebnisse berechnen im Mikrocontroller 406 zwei diversitäre Algorithmen die Objektdaten. Die Ergebnisse der diversitären Algorithmen werden in dem Komparator 420 verglichen.
In dem FPGA 402 werden die Bilddaten um definierte und nicht statische Test- muster 410 erweitert, die ohne Sonderbehandlung in dem FPGA 402 bearbeitet werden. Das Ergebnis der Testmuster 410 wird in dem MikroController 406 überprüft.
Voraussetzung ist die hinreichende Diversifizierung der Algorithmen auf Basis gleicher FPGA-Ergebnisse, was eine Vorverarbeitung ermöglicht, und dass hinreichend diversitäre Algorithmen auf einer fehlerhaften Hardware nicht zum gleichen Ergebnis kommen. Von Vorteil ist, dass das Hardware-Grundkonzept übernommen werden kann. Weiterhin vorteilhaft ist die gute Erkennung systematischer und zufälliger transienter/permanenter Fehler.
In Figur 6 ist die Detektion permanenter FPGA-Fehler verdeutlicht. Ein Bildgeber gibt Bilddaten 452 an ein FPGA 454. In diesem FPGA 454 wird zusätzlich ein Testmuster 456 erzeugt. In einer Einheit 458 erfolgt eine Testmusterverifikation, so dass ein Datensatz 460 mit Bilddaten 452 und Testmuster 456 vorliegt. Die Testmuster 456 zu Beginn und am Ende jedes Bildes ermöglichen eine vollständige Testabdeckung des FPGA 454 (pipelining im FPGA). Der Datensatz 460 wird weitergeleitet (Pfeil 462).
Das Testmuster 456 am Anfang und am Ende des eigentlichen Bildes stellt für den aktuellen Zyklus sicher, dass keine permanenten Fehler vorliegen. Die Muster sind nicht konstant, sondern werden in jedem Zyklus gegeneinander vescho- ben. Der Speicher in dem FPGA 454 wird vollständig abgetastet. Die Ergebnisse werden blockweise in der Ergebnisliste abgelegt. Die Position des Ergebnisblocks innerhalb der Liste wird ebenfalls rotiert. Der relevante Speicherbereich ist dadurch abgesichert.
In Figur 7 ist ein mögliches Komparatorkonzept gezeigt. Die Darstellung zeigt einen Komparator 500 mit zwei Eingängen, nämlich einen Kanal A 502 und einen Kanal B 504. Zu beachten ist, dass in jedem mehrkanaligen System der Ver- gleich der Kanäle 502 und 504 der einzige "single point of failure" ist. Die Darstellung zeigt weiterhin einen SCON 506, einen CRC (cyclic redundancy check) 508, einen Nachrichtenzähler 510 und einen Fahrzeugbus 512. Zur Überprüfung des Komparators 500 sendet der SCON 506 eine sogenannte Challenge (Pfeil 514) und empfängt eine Antwort bzw. Response (Pfeil 516). Je nach Aus- gang der Überprüfung sendet der SCON 506 ein enable oder disable zu dem
Fahrzeugbus 512 (Pfeil 518).
Ein erster kritischer Fehlerfall, der sogenannte stuck-at-1 (permanente Zustimmung) muss erkannt werden. Der SCON 506 stellt eine Anfrage, die zur Ableh- nung führen muss. Antwortet der Komparator 500 falsch, gibt der SCON 506 den
Fahrzeugbus 512 nicht frei (disable).
Unkritische Fälle sind eine permanente Ablehnung (stuck-at-O), da das System fail-safe ist. Weiterhin unkritisch ist ein transienter einmaliger Fehler, der in Be- zug zur Fehler-Latenzzeit und der Trägheit der angesteuerten Aktuatorik zu vernachlässigen ist.

Claims

Ansprüche
1 . Verfahren zur Überwachung der Funktionsfähigkeit eines elektronischen Bausteins (12) in einem Steuergerät (10), das in einem Kraftfahrzeug eingesetzt wird, wobei dem elektronisches Baustein (12) eine einen Fahrzustand des Kraftfahrzeugs betreffende Größe als Eingangssignal zur Verarbeitung zugeführt wird und ein Ausgangssignal des elektronischen Bausteins (12) an eine elektronische Recheneinheit (14) weitergeleitet wird, in der das Ausgangssignal mit diversitären Softwarealgorithmen (414, 416) weiterverarbeitet wird, und wobei die Ausgaben der diversitären Softwarealgorithmen (414, 416) in einem Komparator (16, 420, 500) miteinander verglichen werden.
2. Verfahren nach Anspruch 1 , bei dem dem elektronischen Baustein (12) ein Bildsignal als Eingangssignal zugeführt wird.
3. Verfahren nach Anspruch 1 oder 2, bei dem dem elektronischen Baustein
(12) zusätzlich ein Testmuster (410, 456) zu Verarbeitung zugeführt wird, das in dem elektronischen Baustein (12) verarbeitet wird und das verarbeitete Testmuster (410, 456) an die elektronische Recheneinheit (14) weitergeleitet wird.
4. Verfahren nach Anspruch 3, bei dem in der elektronischen Recheneinheit (14) das verarbeitete Testmuster (410, 456) und das Ausgangssignal getrennt weiterverarbeitet werden.
5. Verfahren nach Anspruch 4, bei dem in der elektronischen Recheneinheit
(14) eine Testmusterverifikation durchgeführt wird.
6. Verfahren nach einem der Ansprüche 1 bis 5, bei dem die Funktionsfähigkeit des Komparators (16, 420, 500) überwacht wird.
7. Steuergerät für ein Kraftfahrzeug, insbesondere zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 6, mit einem elektronischen Baustein (12) und einer elektronischen Recheneinheit (14), wobei der elektronische Baustein (12) zur Aufnahme und zur Verarbeitung einer einen Fahrzu- stand des Kraftfahrzeugs betreffenden Größe ausgebildet ist und die elektronische Recheneinheit (14) zur Weiterverarbeitung eines Ausgangssignal des elektronischen Bausteins (12) ausgelegt ist, bei welcher diversitäre Softwarealgorithmen (414, 416) eingesetzt werden, und wobei ein Kompara- tor (16, 420, 500) vorgesehen ist, der dafür ausgelegt ist, Ausgaben der di- versitären Softwarealgorithmen miteinander zu vergleichen.
8. Steuergerät nach Anspruch 7, bei dem als elektronischer Baustein (12) ein FPGA (60, 1 10, 402, 456) dient.
9. Steuergerät nach Anspruch 7 oder 8, bei dem eine Sicherheitseinrichtung zur Überwachung des Komparators (16, 420, 500) vorgesehen ist.
10. Computerprogramm mit Programmcodemitteln, um alle Schritte eines Verfahrens nach einem der Ansprüche 1 bis 6 durchzuführen, wenn das Com- puterprogramm auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere in einem Steuergerät (10) nach einem der Ansprüche 7 bis 9, ausgeführt wird.
1 1 . Computerprogrammprodukt mit Programmcodemitteln, die auf einem com- puterlesbaren Datenträger gespeichert sind, um alle Schritte eines Verfahrens nach einem der Ansprüche 1 bis 6 durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere in einem Steuergerät (10) nach einem der Ansprüche 7 bis 9, ausgeführt wird.
PCT/EP2009/062522 2008-10-22 2009-09-28 Verfahren zur überwachung der funktionsfähigkeit eines elektronischen bausteins Ceased WO2010046200A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102008043089.7 2008-10-22
DE200810043089 DE102008043089A1 (de) 2008-10-22 2008-10-22 Verfahren zur Überwachung der Funktionsfähigkeit eines elektronischen Bausteins

Publications (1)

Publication Number Publication Date
WO2010046200A1 true WO2010046200A1 (de) 2010-04-29

Family

ID=41314652

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2009/062522 Ceased WO2010046200A1 (de) 2008-10-22 2009-09-28 Verfahren zur überwachung der funktionsfähigkeit eines elektronischen bausteins

Country Status (2)

Country Link
DE (1) DE102008043089A1 (de)
WO (1) WO2010046200A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102016203266A1 (de) * 2016-02-29 2017-08-31 Zf Friedrichshafen Ag Verfahren zum Betreiben einer Anzeigevorrichtung und Anzeigevorrichtung
US12428054B2 (en) 2021-05-28 2025-09-30 Kevin Arnold Method and device for obtaining data relating to road conditions

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102012200423A1 (de) * 2011-05-11 2012-11-15 Continental Automotive Gmbh Ansteuermodul für eine elektrische Vakuumpumpe
CN105759763B (zh) * 2016-04-01 2018-05-29 沈阳东软医疗系统有限公司 一种多叶光栅的控制方法及系统
DE102022211670A1 (de) 2022-11-04 2024-05-08 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zur frühzeitigen Erkennung von Fehlern von wenigstens einer auf einer Leiterplatine montierten elektronischen Komponente
DE102024203383A1 (de) 2024-04-12 2025-10-16 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und ein System zur Aktivierung einer sicherheitsrelevanten Funktion eines Fahrzeuges

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002032742A1 (de) * 2000-10-21 2002-04-25 Robert Bosch Gmbh Verfahren zum steuern eines steer-by-wire-lenksystems
WO2003056427A2 (de) * 2001-12-21 2003-07-10 Robert Bosch Gmbh Verfahren und vorrichtung zur steuerung einer funktionseinheit eines kraftfahrzeugs
DE10229342A1 (de) * 2002-06-29 2004-01-29 Robert Bosch Gmbh Grafik-Datenverarbeitungs-Einrichtung sowie Grafik-Datenverarbeitungs-System und Verfahren zur Aufbereitung eines grafischen Elements
WO2007054275A2 (de) * 2005-11-12 2007-05-18 Diehl Aerospace Gmbh Verfahren zum überwachen der ansteuerung von bilddarstellungen
WO2008046686A1 (de) * 2006-10-19 2008-04-24 Robert Bosch Gmbh Verfahren zum betreiben eines steuergeräts

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102005057267A1 (de) 2005-12-01 2007-06-06 Robert Bosch Gmbh Verfahren und Vorrichtung zur Fahrerzustandserkennung

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002032742A1 (de) * 2000-10-21 2002-04-25 Robert Bosch Gmbh Verfahren zum steuern eines steer-by-wire-lenksystems
WO2003056427A2 (de) * 2001-12-21 2003-07-10 Robert Bosch Gmbh Verfahren und vorrichtung zur steuerung einer funktionseinheit eines kraftfahrzeugs
DE10229342A1 (de) * 2002-06-29 2004-01-29 Robert Bosch Gmbh Grafik-Datenverarbeitungs-Einrichtung sowie Grafik-Datenverarbeitungs-System und Verfahren zur Aufbereitung eines grafischen Elements
WO2007054275A2 (de) * 2005-11-12 2007-05-18 Diehl Aerospace Gmbh Verfahren zum überwachen der ansteuerung von bilddarstellungen
WO2008046686A1 (de) * 2006-10-19 2008-04-24 Robert Bosch Gmbh Verfahren zum betreiben eines steuergeräts

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
KOPETZ H ED - KOPETZ H: "Chapter 6: fault tolerance", REAL-TIME SYSTEMS : DESIGN PRINCIPLES FOR DISTRIBUTED EMBEDDED APPLICATIONS; [KLUWER INTERNATIONAL SERIES IN ENGINEERING AND COMPUTER SCIENCE], NORWELL, MA : KLUWER ACADEMIC PUBL, US, 1 January 1998 (1998-01-01), USA, pages 119 - 143, XP002561456, ISBN: 978-0-7923-9894-3 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102016203266A1 (de) * 2016-02-29 2017-08-31 Zf Friedrichshafen Ag Verfahren zum Betreiben einer Anzeigevorrichtung und Anzeigevorrichtung
US12428054B2 (en) 2021-05-28 2025-09-30 Kevin Arnold Method and device for obtaining data relating to road conditions

Also Published As

Publication number Publication date
DE102008043089A1 (de) 2010-04-29

Similar Documents

Publication Publication Date Title
EP3709166B1 (de) Verfahren und system zur sicheren signalmanipulation für den test integrierter sicherheitsfunktionalitäten
DE102017210156B4 (de) Vorrichtung und Verfahren zum Ansteuern eines Fahrzeugmoduls
WO2018233935A1 (de) Vorrichtung und verfahren zur ansteuerung eines fahrzeugmoduls in abhängigkeit eines zustandssignals
EP2447843B1 (de) Verfahren zur Verifizierung eines Anwendungsprogramms einer fehlersicheren Speicherprogrammierbaren Steuerung, und Speicherprogrammierbare Steuerung zur Ausführung des Verfahrens
WO2010046200A1 (de) Verfahren zur überwachung der funktionsfähigkeit eines elektronischen bausteins
DE102013203358A1 (de) System und verfahren zum verifizieren der integrität eines sicherheitskritischen fahrzeugsteuerungssystems
DE102017105174A1 (de) Verfahren zum Erzeugen von Trainingsdaten für die Überwachung einer Gefahrenquelle
EP1533505A2 (de) Verfahren und Vorrichtung zur Fehlerdiagnose in Steuereinrichtungen einer Brennkraftmaschine eines Kraftfahrzeugs
DE102017103724B4 (de) Vorrichtung und Verfahren zum Steuern eines Sensorbauelements eines Sicherheitssystems eines Objekts, Steuerungssystem für ein Automobilfahrzeug und Sensorbauelement für ein Sicherheitssystem eines Automobilfahrzeugs
DE102015202326A1 (de) Verfahren zum Betreiben einer Datenverarbeitungseinheit eines Fahrerassistenzsystems und Datenverarbeitungseinheit
EP1860565A1 (de) Verfahren zur Funktionsprüfung eines Steuergeräts für ein Kraftfahrzeug
EP3535965B1 (de) Verfahren und vorrichtung zum überwachen eines bildsensors
EP2405317B1 (de) Verfahren zur sicheren Parametrierung eines Sicherheitsgeräts
EP3378006B1 (de) Verfahren zum laden eines sicheren speicherabbilds eines mikrocontrollers und anordnung mit einem mikrocontroller
DE102009012887B4 (de) Verfahren zum Prüfen einer nicht korrekten Installation von Fahrzeugsensoren
DE102017123911A1 (de) Verfahren und Vorrichtung zum Überwachen der Reaktionszeit einer durch ein Sicherheitssystem bereitgestellten Sicherheitsfunktion
DE102017123910A1 (de) Verfahren und Vorrichtung zum Überwachen der Sicherheitsintegrität einer durch ein Sicherheitssystem bereitgestellten Sicherheitsfunktion
DE102014213503A1 (de) Verfahren zum Überwachen einer Software in einem Straßenfahrzeug
EP3659032A1 (de) Verfahren zum betreiben eines steuergerätes und vorrichtung mit zugehörigem steuergerät
EP3789832B1 (de) Vorrichtung und verfahren zur ausführung einer sicherheitsfunktion
EP2435915B1 (de) Verringerung der reaktionszeit in einem system zur überwachung eines funktionsrechners
DE102015221951A1 (de) Verfahren zur Überprüfung einer Überwachungsfunktion
DE102019209136A1 (de) Verfahren zur Absicherung einer Funktionsüberwachung eines Steuergeräts eines Fahrzeuges
EP4098927B1 (de) Sensoranordnung und verfahren zum betrieb einer sensoranordnung
DE102024207302A1 (de) Computer-implementiertes Verfahren zum Generieren von Testszenarien zum Testen von einem technischen System

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09783481

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 09783481

Country of ref document: EP

Kind code of ref document: A1