DE102009028871A1 - Method for testing memory e.g. RAM memory, of function testing system for switching off of electrical vehicle drive, involves executing memory testing routine after cycle of predetermined time intervals - Google Patents

Abstract

The method involves executing a memory testing routine, and testing a memory e.g. RAM memory and e.g. ROM memory, by the memory testing routine. The memory testing routine is executed again after cycle of predetermined time intervals. Memory contents of the memory are transferred into an intermediate memory. The memory contents in the memory are overwritten with a predetermined digital pattern to produce a pattern storage content. The pattern storage content is read from the memory, and the digital pattern is compared with the pattern content to test the memory. Independent claims are also included for the following: (1) a control device of a vehicle drive i.e. electrical vehicle drive, to perform a method for testing a memory i.e. function monitoring memory, of a function testing system (2) a computer program with a program code for performing a method for testing a memory i.e. function monitoring memory, of a function testing system.

Description

State of the art

The present invention relates to the field of memory verification.

In order to check a functionality of a complex system, for example a vehicle control system, functional tests are usually carried out in order to quickly recognize them in the event of a malfunction and then to carry out a safety-relevant action, for example switching off an electric vehicle drive. For this purpose, for example, in vehicles with electronic engine fill control systems, so-called e-gas systems, a 3-level monitoring concept is usually implemented in the engine control units. The core idea of the 3-level concept is mutual monitoring between a function computer used in the engine control unit and, for example, a separate module, which is used as a so-called watchdog. In this case, for example, the function computer and the monitoring module communicate via a question-answer communication protocol and preferably have separate shutdown paths, via which the power output stages can be switched off in the event of an error in order to ensure vehicle safety.

The level 1 denotes the actual functional software, which is used for engine operation and executed for example on the function computer of the engine control unit. In the second level, which is likewise carried out on the function computer, usually a permissible torque derived from an optionally simplified engine model is compared with an actual torque. Level 2 is executed in a Level 3 protected hardware area, where level 3 includes a command test, a program run check, an analog-to-digital converter test, and, for example, cyclic and full memory tests. In the Standard ECE-R100 It is also stipulated that a vehicle may not move unintentionally from standstill by more than 10 cm. This requirement applies in particular to newer vehicles with hybrid or electric drives.

However, due to the shorter delay time, an electric drive can build up a high torque faster than an internal combustion engine, which can also be negative, so that an electric vehicle can drive both forward and reverse from standstill with maximum acceleration. This can lead to safety-critical situations in the case of an unintentionally generated torque, because a clutch and a transmission with, for example, variable ratios in an electric vehicle are usually not present. The shaft of the electric drive is rather connected via a rigid connection with the drive train and thus with the pathogens. In hybrid or electric vehicles, therefore, the monitoring mechanisms must be able to detect potential functional failures much more quickly and react quickly in the event of detected malfunctions to meet the standard requirements. For example, while in vehicles with internal combustion engines an error response time of 500 ms is sufficient, it is necessary for electric vehicles to achieve an error reaction time which is shorter than 70 ms.

Disclosure of the invention

The present invention is based on the recognition that rapid and efficient functional monitoring can be realized on the basis of monitoring the digital memories, which are used, for example, for storing functional tests.

Thus, for example, in the case of the aforementioned 3-level concept, both RAM (Random Access Memory) and ROM (Read Only Memory) memory cells are used to store or temporarily store the monitoring results obtained in the respective level. For this purpose, the memories can be deterministically checked within predetermined time intervals, so that a guarantee of the real-time behavior of the system is possible.

By such memory monitoring within the predetermined time window is also achieved that other tasks that can be performed, for example, cooperative, are not unnecessarily delayed. Furthermore, deterministic memory monitoring achieves better reproducibility and better predictability of the error reaction time, in particular in the case of cyclical memory monitoring. In addition, the memory monitoring concept according to the invention allows a comfortable configuration option with regard to the error reaction time of the memory tests, in particular depending on the actual memory requirements of the functions of levels 2 and 3. The memory monitoring concept can be used flexibly and is also suitable, for example, for monitoring function-relevant events in any real-time communication systems or real-time control systems ,

According to one aspect, the invention relates to a method for checking a memory, for example a function monitoring memory a function check system, which may be a real-time system, comprising the steps of executing a memory check routine in which the at least one memory is checked n times, where n is a predetermined number of checks, and re-executing the memory check routine after a predetermined time interval has expired. Thus, the at least one memory is repeatedly executed at the expiration of the memory check routine, and the memory check routine itself can be repeatedly executed. Thus, not only the execution of the memory check routine but also the check of memory in the execution of the memory check routine is repeated deterministically rather than randomly. As a result, a fast and reliable detection of the fault reaction time is made possible in an advantageous manner.

According to one embodiment, the memory check routine is executed within a predetermined routine time interval, which may be variable. This advantageously defines a specific time window for executing the memory check routine, so that further, for example cooperative, tasks or tasks can nevertheless be executed.

According to one embodiment, the memory check routine is executed periodically within a predetermined period or cyclically within a predetermined cycle time. Repeated execution of the parent memory check routine performs a deterministic memory check that allows for rapid detection of fault response times or faults.

According to one embodiment, when executing the memory check routine, i. H. within the routine time interval, the checks of the at least one memory periodically or cyclically, for example, immediately consecutive executed, thereby advantageously enabling a rapid detection of the fault reaction time within a routine time interval.

According to one embodiment, a duration of one or each of the n checks of the at least one memory is predetermined upon execution of the memory check routine. This advantageously ensures that each check can be made longer or shorter depending on, for example, the number of checks or the number of memories to be checked.

According to one embodiment, the at least one memory is no longer checked after n checks until the memory check routine is executed again. As a result, it is advantageously achieved that the non-check time between execution of the respective memory check routine can be used to perform other tasks.

According to one embodiment, one or each check of the at least one memory is performed within a predeterminable check time interval. Thus, advantageously, the total time of the checks performed within a memory check routine can be determined.

According to an embodiment, a time period of the predetermined time interval is predetermined for executing the memory check routine. This advantageously ensures that the memory check routine does not unnecessarily hinder the execution of further routines.

According to one embodiment, a time interval between the executions of two consecutive memory check routines is predetermined or depends on a type of the data storable in the at least one memory. If the at least one memory is used, for example, for storage in the aforementioned levels 2 and 3, then this can be checked cyclically, for example, whereby the cycle duration is predetermined by the time interval. On the other hand, if the at least one memory is used, for example, by the functions of level 1, then this can only be checked once per driving cycle, for example. In the latter case, the time interval between the executions of two consecutive memory check routines is determined, for example, by a drive cycle distance.

According to one embodiment, each time the at least one memory is checked, a number of memories are checked. This advantageously achieves that a memory block with the number of memories can be checked during the execution of the memory check routine.

According to one embodiment, a checking time interval available for checking the at least one memory depends on a number of memories also to be checked in this checking time interval. This advantageously ensures that several memories can be checked within the same checking time interval.

According to one embodiment, the memory is a RAM memory or a ROM memory.

According to one embodiment, at least one or every check of the a memory, which may be, for example, a RAM memory, the steps of transferring the memory contents of the at least one memory into a buffer, overwriting the memory contents in the at least one memory with a predetermined digital pattern to generate a pattern memory content, reading out the memory Sample memory content from the at least one memory and comparing the digital pattern with the sample memory content to check the memory. As a result, it is advantageously achieved that the relevant memory areas which are used to store the memory contents are checked in a decided manner.

According to one embodiment, in one or each check of the at least one memory, which may be a ROM memory, the steps of combining, for example, adding, the memory contents of the at least one memory with memory contents of at least one further memory to obtain a result of the combination , and comparing the result of the association with a reference link result, which may be predetermined, for example, to check the at least one memory, for example function memory, and the at least one further memory, for example function memory. The check is thus advantageously carried out on the basis of the result of the connection, which may be a check sum, for example.

According to a further aspect, the invention relates to a control device of a vehicle drive, in particular of an electric vehicle drive, which is set up in terms of programming, to carry out the method according to the invention for checking at least one memory. The control unit can be designed, for example, to execute the abovementioned three functional levels in order to check a vehicle drive.

According to a further aspect, the invention relates to a computer program with a program code for carrying out the method for checking at least one memory when the computer program is executed on an electronic computer.

Further embodiments will be explained with reference to the accompanying drawings. Show it:

1 a flowchart of the method for checking a memory according to an embodiment; and

2 a flowchart of the method for verifying a memory according to another embodiment.

1 shows a basic flowchart of a method for verifying at least one memory, for example, a function monitoring memory of a function monitoring system. The method comprises the in 1a illustrated step 101 executing a memory check routine during which the step 103 the checking of the at least one memory is performed, for example, several times. After a predetermined time interval or immediately thereafter, the memory check routine in step 105 run again.

Running the memory check routine 101 For example, it can be executed periodically, for example every 10 ms, by a higher-level controller, for example by a higher-level software task. To determine the number n of repetitions of the step 103 the checking of the at least one memory may further in step 107 a count can be increased or decreased. After performing the step n times 103 the counter of the at least one memory is checked 107 reset again. The step 107 however, within the step 103 be executed.

1B illustrates the cyclical execution of the step 103 monitoring the at least one memory, the number of cycles being determined, for example, by means of a routine 109 is ensured. Starting with a start state 111 is doing in step 113 first checked whether a count is less than a predetermined limit count. If the counter reading is greater than or equal to the limit count, it will be in a final state 115 passed over in which the step 103 is no longer running. Otherwise, in step 117 the meter reading is increased by 1. Then, for example, in step 119 checking a first memory or a first group of memories, for example a RAM test for X RAM cells. Subsequently or in parallel to this, in step 121 a further check of another memory or group of memories, for example a ROM test for Y ROM cells, may be performed. Subsequently, in step 123 the step 103 rechecking the at least one memory.

In the 1 The method steps illustrated can be implemented in software as software tasks, for example, using a program executed or executable on an electronic computer.

In this case, the software task calls 103 the function 109 on. In this function, it is first checked whether the counter value is smaller than the limit counter reading ("Counter_Limit") is not. If so, then it is incremented; for X RAM cells, the RAM test is then performed and for Y ROM cells the ROM test is then performed. Subsequently, the software task 103 started again. If "Counter" is already equal to or greater than "Counter_Limit", then the software task 103 not restarted. Only in a next cycle, for example in a 10 ms cycle, the software task 103 , again from the function 101 started.

2 clarifies the timing of the in 2 illustrated method steps. In this case, for example, the step 101 each after expiration of a time interval 201 , for example, after the lapse of 10 ms, be executed again. Furthermore, the term 203 the respective verification step 103 be parameterizable. In addition, the number can 205 the repetitions of the verification step 103 be parameterizable.

The parameters or calibration variables X and Y now allow the runtime of each call of the function 109 be varied. You can set X and Y through experiments so that each call from the function 109 no longer than "Runtime_Limit", for example no longer than 150 μs, with the aim that the real-time behavior of the entire system does not deteriorate, so that: Runtime (X, Y) ≤ Runtime_Limit

In this case, "transit time" is preferably proportional to "X" and "Y", d. H. the more RAM / ROM cells are checked, the longer the runtime.

Then, the number of RAM and ROM cells (N_RAM and N_ROM, respectively) used, for example, by the level 2 and 3 functions can be determined. The limits of the RAM / ROM areas can be determined after an SW build by analyzing a MAP file. Subsequently, the parameter "Counter Limit" can be selected so that all of these RAM and ROM cells can be checked within the desired time: X · Counter_Limit ≤ N_RAM / Debouncing_Limit Y · Counter_Limit ≤ N_ROM / Debouncing_Limit

Debouncing_Limit is used to ensure debouncing on sporadic errors, so that transient errors can be tolerated to increase system availability. This means that an error reaction is triggered only when a RAM or ROM error is detected several times in succession.

In the 3-level concept, the RAM and ROM memory cells, i. H. Monitor memories used by the Level 2 and Level 3 functions are cyclically tested. The RAM and ROM memory cells used by the Level 1 functions, on the other hand, can only be tested once per drive cycle. Advantageously, the audit memories can be tested cyclically because they are used by the level 2 and level 3 functions, and because an error in the audit memory could cause the level 2 and level 3 functions to not respond correctly. so that a mistake could lead to a hazard.

To check the RAM memory cells, the actual contents are first copied to another memory area; then a particular pattern, z. 0x5A5A5A5A, written in the cells being tested; then it is checked whether the pattern has been written in the cells as desired by reading out the contents. Finally, if there are no errors, the original contents are copied back.

In order to check the ROM memory cells, the contents of a ROM area are linked together, for example added up, and finally compared with a checksum calculated previously off-line. If the checksum, which has been calculated during runtime, does not match the checksum calculated offline, an error response, e.g. As a control unit reset triggered.

These test runs need runtimes, mainly because the memory accesses cost runtime. The error response time of these cyclic RAM / ROM tests therefore depends on the level-2 and -3 memory consumption. The more RAM / ROM cells are checked, the longer the time during which all these cells can be checked once. The error response time also depends on the CPU clock and other factors.

In some projects, so many Level 2 and Level 3 RAM / ROM cells are needed, so an error response time of approximately 70 ms can be achieved if up to 30% of the CPU runtime for the cyclic RAM / ROM tests is available. The cyclic RAM / ROM tests usually run in the 10 ms task. 30% of the CPU runtime means that for each 10 ms cycle, the RAM / ROM tests alone take 3 ms to run.

Basically, there is the option of cyclic RAM / ROM tests, for example, in addition to or between the cyclic checks in to run a so-called background task. This means that this taks is then called by the operating system when no other tasks need to be called, that is, only when the operating system is "idle". However, such a background task can not completely replace the deterministic memory check of the invention because the response time of the cyclic RAM / ROM tests is difficult to predict. Because during the development of an Embedded Control project, the software modules are usually changed until the start of production (SOP, Start of Production). As a result, the computing capacity available for the background task is not constant and is known shortly before SOP. Moreover, no statement can be made regarding the error response time because the background task has the lowest priority in the operating system and there is no guarantee that it will be called often enough within a certain time. If one then determines that the computing capacity is insufficient to ensure the required error reaction time, then it is already too late to optimize elsewhere.

Therefore, the solution with background task is not or exclusively out of the question, so that RAM / ROM tests according to the invention are preferably called cyclically deterministic in order to ensure the required error response time safely. Preferably, for this purpose, the RAM / ROM consumption of the level 2 and 3 functions can already be estimated in the early phase of the development, so that a sufficient computing capacity for the cyclic RAM / ROM tests can be reserved by the cyclic RAM / ROM tests consume almost exactly the computing capacity or runtime in the early stages of development, as in serial applications, so that if other software modules were to consume more run time, resulting in processor overload, this problem would be detected in real time and optimization measures initiated can be.

The cyclic memory checks, for example the RAM / ROM tests, can be called in a so-called "cooperative task". If the cyclic RAM / ROM tests, z. B. 3 ms runtime in a 10-ms cycle can be performed in one piece, then preferably other cooperative tasks are not called as long as the cyclic RAM / ROM tests are still running.

QUOTES INCLUDE IN THE DESCRIPTION

This list of the documents listed by the applicant has been generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited non-patent literature

• Standard ECE-R100 [0003]

Claims (15)

Method for checking at least one memory, in particular a function monitoring memory of a function checking system, comprising: executing ( 101 ) a memory check routine in which the at least one memory is checked n times, where n is a predeterminable number of checks ( 103 ); and run again ( 105 ) the memory check routine after a predetermined time interval. The method of claim 1, wherein the memory check routine is executed within a predetermined routine time interval. The method of claim 1 or 2, wherein the memory check routine is executed periodically within a predetermined period or cyclically within a predetermined cycle time. Method according to one of the preceding claims, wherein, when the memory check routine is executed, the checks ( 103 ) of the at least one memory periodically or cyclically, in particular immediately consecutive executed. Method according to one of the preceding claims, wherein the at least one memory is no longer checked after n checks until the memory check routine is executed again. Method according to one of the preceding claims, wherein one, in particular exactly one, verification ( 103 ) of the at least one memory is performed within a predeterminable checking time interval. Method according to one of the preceding claims, wherein a time duration of the predetermined time interval is predetermined or depends on a type of the data storable in the at least one memory. Method according to one of the preceding claims, wherein a time interval between the embodiments ( 101 . 105 ) is predetermined by two consecutive memory check routines or depends on a type of data storable in the at least one memory. Method according to one of the preceding claims, whereby at each check ( 103 ) of the at least one memory a number of memories is checked. Method according to one of the preceding claims, whereby a check ( 103 ) of the at least one memory available Verprüfungszeitintervall depends on a number of also in this Verification time interval to be checked memories. Method according to one of the preceding claims, wherein the memory is a RAM memory or a ROM memory. Method according to one of the preceding claims, wherein during a check ( 103 ), in particular with each check, of the at least one memory, in particular of a RAM memory, the following steps are carried out: transferring the memory contents of the at least one memory into an intermediate memory; Overwriting the memory contents in the at least one memory with a predetermined digital pattern to produce a pattern memory content; Reading the pattern memory contents from the at least one memory; and comparing the digital pattern with the sample memory content to check the memory. Method according to one of the preceding claims, wherein during a check ( 103 ), in particular during each check, of the at least one memory, in particular of a ROM memory, the following steps are carried out: linking the memory contents of the at least one memory with memory contents of at least one further memory in order to obtain a logic result; and comparing the result of the association with a reference link result to check the at least one function memory and the at least one further function memory. Control device of a vehicle drive, in particular of an electric vehicle drive, which is set up by the program, to carry out the method according to one of claims 1 to 13. Computer program with a program code for carrying out the method according to one of claims 1 to 13, when the computer program is executed on an electronic computer.

Images