WO2010046200A1

WO2010046200A1 - Method for monitoring the functionality of an electronic module

Info

Publication number: WO2010046200A1
Application number: PCT/EP2009/062522
Authority: WO
Inventors: Tobias Stumber; Dietmar Merten; Michael Smuda Von Trzebiatowski
Original assignee: Robert Bosch Gmbh
Priority date: 2008-10-22
Filing date: 2009-09-28
Publication date: 2010-04-29
Also published as: DE102008043089A1

Abstract

The invention relates to a method for monitoring the functionality of an electronic module (12). In the method, a quantity relating to a driving state of the motor vehicle is fed to the electronic module (12) as an input signal, and an output signal of the electronic module (12) is transferred to an electronic arithmetic unit (14) in which said output signal is processed using diverse software algorithms. The outputs of the diverse software algorithms are compared to each other in a comparator (16).

Description

description

title

Method for monitoring the functionality of an electronic component

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.

State of the art

Electronic control units are used in motor vehicles in various areas to control and / or regulate various processes. That is how it is

Use of 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. To detect lane markings, a video camera is used, which is connected to the input circuit. It should be noted, however, that 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. Extremely powerful automotive-certified components are being used whose complexity makes it increasingly difficult to monitor the hardware completely, ie with a test coverage of, for example, more than 90% in the context of self-diagnostics running alongside the applications. Also, the monitoring of FPGAs in the automotive environment has not been satisfactorily resolved.

To ensure the functionality of the controllers used different approaches are known. Here, requirements for hardware and software must be formulated, which allow safe operation. To standardize the development processes and the monitoring during operation standardized procedures are aimed at.

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.

It proposes a 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. For this purpose, 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. From a given table, the classification QM (quality managed) or ASIL (automotive safety integrity level) A to D can then be read for each hazard.

As ASIL increases, so does the safety requirements specified in the following sections. There are no requirements for class QM hazards that go beyond the usual quality management of the system manufacturer. The standard defines concrete requirements for software and hardware, both for the development processes and for the malfunction in the field, and already influences the requirements for the systems in the vehicle today. Particular attention must be paid to the detection of permanent random or systematic errors. Processes are recommended and, in some cases, quantitative requirements for failure rates and test covers for the various security levels are specified.

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.

Considered types of 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.

Disclosure of the invention

The method according to the invention serves to monitor the operability of an electronic component in a motor vehicle. In this case, 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. Usually, two software algorithms are used whose outputs are compared in the comparator.

A failed comparison leads to an error.

Sufficiently complex and diverse algorithms only achieve equivalent results on error-free hardware. Thus, diverse algorithms also assume the function of self-diagnosis on complex hardware.

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. In this application, the electronic module, an image signal can be supplied as an input signal. In this case, 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%.

In an embodiment, 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. In this case, the processed test pattern and the output signal can be processed separately in the electronic processing unit, for example a microcontroller.

In the electronic processing unit, a test pattern verification can be performed. A failure of the test pattern analysis regularly leads to an error.

In an embodiment, the functionality of the comparator is monitored. For example we use a hardware independent 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. For further processing in the electronic processing unit, di- versitive software algorithms are used. A comparator is also provided which is adapted to compare outputs of the diversified software algorithms.

In a refinement, 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

Computer or a corresponding processing unit, in particular in a control device, as described above, is executed.

The presented method has, at least in some of the embodiments set out, a number of advantages. Thus, 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. In addition, if there are enough resources, existing hardware concepts can be used for both QM and ASIL A / B.

Further advantages and embodiment of the invention will become apparent from the description and the accompanying drawings. It is understood that the features mentioned above and those yet to be explained below can be used not only in the particular combination given, but also in other combinations or in isolation, without departing from the scope of the present invention.

Brief description of the drawings

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.

Embodiments of the invention

1 shows an embodiment of a control device, generally designated by the reference numeral 10 is shown. This 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.

In the illustrated embodiment, two diverse algorithms process the

Calculations of the electronic device 12 with respect to the actual image. 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).

2 shows a schematic representation of a device for Fahrzustandser- 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.

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). Within the device, 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. In the illustration, 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.

Relative to the different levels, the amount of data is plotted against the information content per date 164. Evident is the growth of the information content 164 of the data set 162 from the image plane 150 to the real environment 152. In this area are also transient

Error 156, which must be recognized.

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. 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. In the FPGA 402, the data preprocessing takes place. The result is stored in common memory of FPGA 402 and microcontroller 406, namely RAM 404. Based on these results, calculate in microcontroller 406 two diverse algorithms the object data. The results of the diverse algorithms are compared in the comparator 420.

In the FPGA 402, 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. In addition, a test pattern 456 is generated in this FPGA 454. In a unit 458, 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. To check the comparator 500, 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

Vehicle bus 512 (arrow 518).

A first critical error case, the so-called stuck-at-1 (permanent approval) must be recognized. 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).

Uncritical cases are a permanent rejection (stuck-at-O) because the system is fail-safe. Also not critical is a transient single error, which is negligible in relation to the error latency and the inertia of the driven actuator.

Claims

claims

1 . Method for monitoring the operability of an electronic component (12) in a control unit (10) used in a motor vehicle, the electronic component (12) being supplied with a quantity relating to a driving condition of the motor vehicle as an input signal for processing and an output signal of the electronic component Block (12) is forwarded to an electronic processing unit (14), in which the output signal with further diversified software algorithms (414, 416) is further processed, and wherein the outputs of the diverse software algorithms (414, 416) in a comparator (16, 420, 500 ) are compared.

2. The method of claim 1, wherein the electronic component (12) an image signal is supplied as an input signal.

3. The method of claim 1 or 2, wherein the electronic component

(12) additionally a test pattern (410, 456) is supplied for processing, which is processed in the electronic module (12) and the processed test pattern (410, 456) is forwarded to the electronic processing unit (14).

4. The method of claim 3, wherein in the electronic processing unit (14), the processed test pattern (410, 456) and the output signal are processed separately.

5. The method of claim 4, wherein in the electronic processing unit

(14) a test pattern verification is performed.

6. The method according to any one of claims 1 to 5, wherein the operability of the comparator (16, 420, 500) is monitored.

7. Control device for a motor vehicle, in particular for carrying out a method according to one of claims 1 to 6, with an electronic component (12) and an electronic computing unit (14), wherein the electronic component (12) for receiving and processing a Fahrzu is designed to size of the motor vehicle and the electronic computing unit (14) is designed for further processing of an output signal of the electronic module (12), in which diverse software algorithms (414, 416) are used, and wherein a comparator (16, 420 , 500), which is designed to compare outputs of the di- versitive software algorithms with each other.

8. Control device according to claim 7, wherein as the electronic component (12) an FPGA (60, 1 10, 402, 456) is used.

9. Control device according to claim 7 or 8, wherein a safety device for monitoring the comparator (16, 420, 500) is provided.

10. Computer program with program code means to perform all the steps of a method according to one of claims 1 to 6, when the computer program on a computer or a corresponding processing unit, in particular in a control device (10) according to one of claims 7 to 9, is executed ,

1 1. Computer program product with program code means which are stored on a computer-readable data carrier to carry out all the steps of a method according to one of claims 1 to 6, when the computer program is run on a computer or a corresponding computing unit, in particular in a control unit (10) according to one of the claims 7 to 9, is executed.