WO2019012907A1

WO2019012907A1 - Computation device

Info

Publication number: WO2019012907A1
Application number: PCT/JP2018/022681
Authority: WO
Inventors: 拓下沢; 飯室　聡; 裕弘小田; 成沢　文雄; 林　正人
Original assignee: 日立オートモティブシステムズ株式会社
Priority date: 2017-07-12
Filing date: 2018-06-14
Publication date: 2019-01-17
Also published as: JP2019020864A; JP6802764B2

Abstract

A computation device comprising: a storage unit storing a first software module, a second software module, and a third software module each having the same function but implemented separately; a computation unit for executing the first software module, the second software module, and the third software module; a detection unit for detecting a failure on the basis of an output from the first software module and an output from the second software module implemented by the computation unit; and a failure identification unit for starting the use of the third software module when a failure is detected by the detection unit, and identifying the software module in which the failure occurred on the basis of an output from the first software module, an output from the second software module, and an output from the third software module.

Description

Arithmetic unit

The present invention relates to a computing device.

In the on-vehicle control device, the processing contents required are becoming more sophisticated, and the use of technology and software performed in general servers and workstations is also increasing. Such software is not created by the development method performed in the conventional on-vehicle controller, and its quality is not necessarily high. Moreover, in the on-vehicle control device, even if a failure such as a software bug occurs, the operation must be continued, and it is necessary not only to detect the failure but also to identify and separate the failure location. For this purpose, the final quality of the on-board control device is improved by checking a plurality of different implementations having the same function, and a majority decision is made to fail in one implementation. Even if occurs, the operation can be continued.
According to Patent Document 1, in a diagnosis and repair apparatus that executes processing by an application set in advance and compares the executed processing results to diagnose and repair data, predetermined data is divided into three or more data areas. Storage means for storing and writing the predetermined data in different formats into the three or more data areas, and reading and collating the data written in the three or more data areas when the application is executed Processing program execution means for executing the application using the restored data, performing predetermined repair when the results of the above are inconsistent, and the result of executing the application and at least one other diagnostic repair device A verification processing means is disclosed for verifying the result of executing the application.

Japan JP 2013-109532 gazette

The invention described in Patent Document 1 can not realize fault detection and fault identification using limited computing resources.

A computing device according to a first aspect of the present invention comprises: a storage unit storing a first software module having the same function and implemented differently and a second software module and a third software module; A first software module, the second software module, an operation unit that executes the third software module, an output of the first software module by the operation unit, and an output of the second software module When a detection unit for detecting a failure and the detection unit detect a failure, the use of the third software module is started, the output of the first software module, the output of the second software module, and the output of the second software module Based on the output of the third software module, and It includes a fault identification unit for identifying the Towea module.

According to the present invention, it is possible to realize fault detection and fault identification using limited computing resources.

Block diagram showing the configuration of the ECU 100 in the first embodiment A diagram showing an example of the first module input table 15 A diagram showing an example of the first module output table 16 A diagram showing an example of the first output comparison table 17 A diagram showing an example of the first module management table 18 Diagram showing an operation example of the ECU 100 Flow chart showing failure detection processing Flow chart showing failure identification processing Block diagram showing the configuration of the ECU 100A in the second embodiment Flowchart representing the operation of the first module execution unit 13B in the second embodiment Block diagram showing configuration of control system S in the third embodiment Flow chart showing fault identification processing in the third embodiment

-First embodiment-
Hereinafter, a first embodiment of an ECU that is a control device will be described with reference to FIGS. 1 to 8.

(Constitution)
FIG. 1 is a block diagram showing the configuration of the ECU 100, that is, an electronic control unit. The ECU 100 has a CPU 110, which is an arithmetic device, and a memory 120, which is a main storage area. The memory 120 stores a plurality of modules as described later.

A module is software that can be commonly used from a plurality of applications. A module is, for example, a library, a function, a part of a function, or an application specialized for commonly used functions. In the present embodiment, a module is software consisting of a plurality of functions called from an application, such as a dynamically linked library (Dynamic Link Library), and is independent of the application. The inputs to the module are the arguments to these functions. The output of the module is the return value of these functions. Further, in the present embodiment, three modules of a P module denoted by reference numeral 41, a Q module denoted by reference numeral 42, and an R module denoted by reference numeral 43 will be described, but these are collectively referred to simply as "module".

The P module 41, the Q module 42, and the R module 43 all have the same function, and it is expected that the same output can be obtained for the same input even when any module is used. . However, these modules have different implementations and are not binary matches. The P module 41, the Q module 42, and the R module 43 are, for example, a first implementation, a second implementation, and a third implementation of a standardized library. The reliability of the P module 41 and the Q module 42 is higher than that of the R module 43, in other words, the degree of perfection is high. For example, when the CPU 110 can execute both an application created for a 32-bit CPU and an application created for a 64-bit CPU, the following configuration may be used. That is, the P module 41 may be a first implementation for a 32-bit CPU, the Q module 42 may be a first implementation for a 64-bit CPU, and the R module 43 may be a second implementation for a 32-bit CPU.

The CPU 110 is an arithmetic device capable of general purpose calculation, and has two CPU cores operable in parallel, that is, a first CPU core 111 and a second CPU core 112. However, the CPU 110 may have three or more CPU cores, or may have a function that one CPU logically behaves as having a plurality of cores, a so-called hardware hyper threading function. Furthermore, the CPU 110 may be a single semiconductor chip, or may be a so-called SoC (System-on-Chip) in which a memory 120 described below is mounted on one semiconductor chip.

Memory 120 is a main storage device that is volatile, and is configured of, for example, a dynamic random access memory (DRAM). In the memory 120, a program including code executed by the CPU 110 and data to be read and written is disposed. In the present embodiment, the program used by the first CPU core 111 and the program executed by the second CPU core 112 are referred to as a first program 11 and a second program 21, respectively. The first program 11 and the second program 21 have the same configuration and perform the same operation. The first CPU core 111 and the second CPU core 112 can communicate, whereby the first program 11 and the second program 21 can exchange information.

The first program 11 includes a first application 12 and a first module execution unit 13. The first module execution unit 13 includes a P module 41, an R module 43, a first module input table 15, a first module output table 16, a first output comparison table 17, and a first module management table 18. Have. The second program 21 includes a second application 22 and a second module execution unit 23. The second module execution unit 23 includes the Q module 42, the R module 43, the second module input table 25, the second module output table 26, the second output comparison table 27, and the second module management table 28. Have.

The first application 12 and the second application 22 are in the same relationship of so-called binary match. The first program 11 and the second program 21 have the same configuration and perform the same operation. If any module provided in the first program 11 and the second program 21 operates without a fault such as a bug, the execution results of both applications become the same. By comparing the execution results of the first program 11 and the second program 21 using a verification device or the like (not shown) and using the final output of the ECU 100, safety and reliability are enhanced, and control software is It can be done.

The R module 43 included in the second program 21 is identical to the R module 43 included in the first program 11, that is, has a binary matching relationship. The second module input table 25, the second module output table 26, the second output comparison table 27, and the second module management table 28 respectively correspond to the first module input table 15, the first module output table 16, and the first output. The configuration is the same as that of each of the comparison table 17 and the first module management table 18. The configuration and operation of the first program 11 will be mainly described below.

The first application 12 of the first program 11 is software that realizes main functions in the ECU 100. In the present embodiment, one first application 12 is provided for simplicity, but a plurality of applications may be provided. When the first application 12 needs the function of the module, it calls the first module execution unit 13 to execute the module and obtain its output. Hereinafter, for the sake of simplicity, this process is expressed as “call a module from the first application 12”, but in practice, the first module execution unit 13 intervenes in the execution of the module as described later.

The first module execution unit 13 is called from the first application 12 to execute a module. The first module execution unit 13 selects and executes one module when called from the first application 12, and compares it with the execution result of the module in the second module execution unit 23 when a predetermined condition described later is satisfied. As described later, the second module execution unit 23 uses a module different from the first module execution unit 13. If it is determined by this comparison that there is no failure in any of the used modules, the calculation result is output to the first application 12. However, if it is determined that a failure has occurred in one of the modules due to a mismatch or the like, the first module execution unit 13 uses the other module to identify the faulty module. That is, normally, the ECU 100 uses only two different modules, one in each of the different modules, until it is determined that there is a failure in other words. Then, if it is determined that there is a fault, the third module is used to identify the faulty module.

In the first module input table 15, the input to the module is added every time the first application 12 calls the module and any input is performed. The first module output table 16 records the output each time the module performs an output. In the first output comparison table 17, information indicating whether the return value of each function is comparable for each function included in the module is recorded in advance. The first output comparison table 17 is referred to when determining whether to compare the outputs of the modules. The first module management table 18 describes the presence or absence of a module failure. Based on the description of the first module management table 18, the module to be executed is selected. Each configuration will be described in detail below.

(First module input table 15)
FIG. 2 is a diagram showing an example of the first module input table 15. However, FIG. 2 shows an example in which a plurality of functions are called at one time, and one call of one function corresponds to one line of the first module input table 15. Further, each row of the first module input table 15 is arranged in the order of being called. In the first column “No.” of the first module input table 15, the number of each row is stored. If the order and identification of each line are possible, identifiers other than numbers may be used. The second column “calling function” of the first module input table 15 stores information identifying the function called in each call, for example, the function name and the address address of the function. The third column “input” of the first module input table 15 stores the input to the module in each call. In the example shown in FIG. 2, although some input is made in all calls, information indicating that there is no argument in the case of a function having no input value and no argument, for example, “none” or “- "Is recorded. When the first application 12 calls a module, the first module execution unit 13 adds a new line to the first module input table 15, and records the identifier of the function and the input to the module.

(First module output table 16)
FIG. 3 is a diagram showing an example of the first module output table 16. Each row of the first module output table 16 corresponds to one output from any module. Since the outputs of the modules are generated in response to the inputs, each row of the first module output table 16 corresponds to a single invocation to the module, ie, each row of the first module input table 15. In the first column “No.” of the first module output table 16, the numbers of the respective rows are stored. If the order and identification of each line are possible, identifiers other than numbers may be used. The second column "output" of the first module output table 16 stores the output of the module in each call. If there is no output value, information indicating that there is no output value, for example, "none" or "-" is recorded. When the first module execution unit 13 executes the module and obtains its output, it adds a new line to the first module output table 16 and adds its output.

However, the first module output table 16 stores the outputs of all executed modules. Outputs of a plurality of modules may be stored in one table, or outputs may be stored in different tables for each module.

(First Output Matching Table 17)
FIG. 4 is a diagram showing an example of the first output comparison table 17. Each row of the first output comparison table 17 stores information indicating whether the output of each function provided in the module can be compared. The first column “function” of the first output matching table 17 stores an identifier of the function. The second column “output comparison division” of the first output comparison table 17 includes information indicating whether to compare the outputs of the functions, for example, “Compare”, “Ignore”, and “Compare if”. It is one of error. "Compare" indicates that the comparison is to be made, and "Ignore" indicates that the comparison is not to be made. "Compare if error" indicates that if the output is a value indicating an error, the contents are compared, and if it is successful, the comparison is not performed.

The function to which “Compare if error” is applied is, for example, the following function. That is, the function dynamically allocates a memory area and returns the start address of the allocated area with a positive integer when successful, and returns a type of error with a negative integer when unsuccessful. When this function is executed in each of a plurality of modules, if an area can be normally secured, the two will output different values and there is no point in comparing them. However, in case of failure, if the type of error is different, it is known that the module has some problem. Thus, by defining a function that compares outputs only under specific conditions, it is possible to reduce functions that do not compare, and it is possible to detect faults rather than simply using “Compare” and “Ignore”. You can increase the frequency.

(First module management table 18)
FIG. 5 is a diagram showing an example of the first module management table 18. Each row of the first module management table 18 stores the operation status of each module. The first column "module" of the first module management table 18 stores an identifier for identifying a module. The operation status of the module is stored in the next column "Operation Status". The operating status indicates whether the module is normal or there is a problem with “OK” and “NG”, respectively. In the initial state, all modules are "OK", and as will be described later, the output is not matched, a faulty module is identified, and a module identified as faulty is "NG". The first module execution unit 13 can continue to use a module without a fault by obtaining an output using a module whose “operation status” is “OK” among the modules.

(Operation example)
FIG. 6 is a diagram showing an operation example of the ECU 100. As shown in FIG. 6 (a) to 6 (d) all show information at the same time, FIG. 6 (a) shows the first module input table 15, and FIG. 6 (b) shows the output of the P module 41. 6C shows the second module output table 26 which is the output of the Q module 42, and FIG. 6D shows the first output of the R module 43. It is a figure which shows the example of module output Table 16A. The first output comparison table 17 will be described using the example illustrated in FIG. Although the output of the R module 43 is included in the first module output table 16, it will be described here as being stored in the first module output table 16A independent of the first module output table 16 for the sake of explanation.

First, the P module 41 and the Q module 42 were operated by using the first program 11 and the second program 21 respectively. As a result, as described in the first module input table 15 of FIG. 6A, there are three module calls, and Function A, Function B, and Function C are called in this order. The outputs of the P module 41 at this time were 0, 100, and -1 in order as shown in the first module output table 16 of FIG. 6 (b). On the other hand, the outputs of the Q module 42 were 0, 200, and -2, respectively, as shown in the second module output table 26 of FIG. 6C.

According to the first output collating table 17 shown in FIG. 4, since the Function A is "Compare", the collation is performed, but the outputs of the P module 41 and the Q module 42 coincide and there is no problem. Since the next Function B is "Ignore", no matching is performed, and the outputs of the P module 41 and the Q module 42 do not match but there is no problem. The last Function C is “Compare if error”, and the outputs of the P module 41 and the Q module 42 are errors since they are both negative numbers.

Therefore, the outputs of P module 41 and Q module 42 are compared. When the outputs of the two are compared, it is judged that there is a failure in either of the P module 41 and the Q module 42 because they are “1” and “2”. Here, in order to determine which one has a fault, the same input is made to the R module 43, and the result shown in the first module output table 16A of FIG. 6D is obtained. The output of Function C where the outputs of the P module 41 and the Q module 42 do not match is the result "-2" in FIG. 6 (d). That is, the output of the R module 43 matches the Q module 42 and does not match the P module 41. By majority, it can be identified that the Q module 42 and the R module 43 are normal and the P module 41 has a failure.

(flowchart)
FIGS. 7 and 8 are flowcharts showing the operation of the first module execution unit 13 that implements the operation example described with reference to FIG. FIG. 7 shows details of fault detection processing, and FIG. 8 shows details of fault identification processing. The operation of the second module execution unit 23 included in the second program 21 is substantially the same as the operation of the first module execution unit 13 of the first program 11. Hereinafter, only the first module execution unit 13 of the first program 11 will be described in common with both.

The first module execution unit 13 executes a program whose operation is represented by the flowchart of FIG. 7 when the first application 12 calls a module. When the first application 12 calls a module, the first module execution unit 13 is given an identifier and an input value of a function of the module. The first module execution unit 13 adds the identifier and the input value to a new line of the first module input table 15 (S701). Next, the first module execution unit 13 selects a module for executing a call of the first application 12 (S702).

The modules are selected from the modules included in the first module execution unit 13 from the modules that are “OK” in the first module management table 18. However, the first module execution unit 13 selects a module so that the modules operated by the first program 11 and the second program 21 are different. For that purpose, for example, the first module execution unit 13 selects modules in ascending order, and the second module execution unit 23 selects modules in descending order. The selection in ascending order is a selection method in which the P module 41 is selected with the highest priority, the Q module 42 is selected when the P module 41 is NG, and the R module 43 is selected when the Q module 42 is also NG. Selection in descending order is a selection method in which selection is performed in the reverse order of ascending order. However, since modules not provided in each program can not be selected, the ascending order and the descending order are in the order described above, and the modules provided in the program are selected.

The first module execution unit 13 executes the function of the selected module to obtain an output value (S703). Next, in order to perform collation, the contents of the second module output table 26 in the second module execution unit 23 of the second program 21 are acquired (S705). The first module execution unit 13 changes the processing target line (hereinafter referred to as “processing target line”) for each row described in the first module output table 16 one by one for the processing of S706 to S710 described below. It is made to execute repeatedly (S705A). However, when the first module execution unit 13 performs all operations shown in FIG. 7 every time the first application 12 calls a module, only one row is described in the output table, and therefore S705A and S710A described later are not present. You may handle it.

The first module execution unit 13 specifies the calling function in the processing target line, acquires the output comparison class of the function with reference to the first output comparison table 17, and determines whether the output comparison class is “Ignore”. It is determined (S706). If the first module execution unit 13 determines that the output comparison classification is "Ignore" (S706: Yes), the process proceeds to S710A. If it is determined that the output comparison class is not "Ignore" (S706: No), the first module execution unit 13 determines whether the output comparison class is "Compare if error" (S707). If the first module execution unit 13 determines that the output comparison classification is “Compare if error” (S 707: Yes), it proceeds to S 708. If the first module execution unit 13 determines that the output comparison classification is not "Compare if error" (S706: No), the process proceeds to S710.

In S708, whether or not the output value of the process target line in the first program 11 and the output value of the process target line in the second program 21 are both values indicating success at S708. Determine if it is a value indicating failure. If the first module execution unit 13 determines that both are values indicating success, the evaluation is unnecessary, and thus the process proceeds to S710A, and if it is determined that at least one is a value indicating failure, the process proceeds to step S709. In step S709, whether or not the output value of the process target line in the first program 11 and the output value of the process target line in the second program 21 are both values indicating an error in step S709. Determine if it is a value that indicates an error.

If the first module execution unit 13 determines that both are values indicating an error, the process proceeds to step S710 for comparison, and if it is determined that only one is a value indicating an error, the fault identifying process of step S720 is performed. move on. However, the details of the failure identification processing will be described later with reference to FIG. In step S710, the first module execution unit 13 determines whether the output value of the processing target line in the first program 11 and the output value of the processing target line in the second program 21 match. If the first module execution unit 13 determines that the two match, the process proceeds to step S710A. If the first module execution unit 13 determines that the two do not match, the first module execution unit 13 proceeds to the failure identification process of step S720.

In step S710A, the first module execution unit 13 determines whether all the rows in the output table have been processed, and if it is determined that there is a row not to be processed, the row is set as the process target in step S706. Return. If the first module execution unit 13 determines that all the rows in the output table have been processed, the process proceeds to step S711. In step S711, the first module execution unit 13 erases the information stored in the first module input table 15 and the first module output table 16. Thereby, when the process shown in FIG. 7 is executed next, it is possible to avoid the same matching being performed, and it is possible to shorten the next matching time. Next, the first module execution unit 13 passes the output value obtained in S703 to the first application 12 and ends the processing shown in FIG. 7 (S712).

FIG. 8 is a flowchart showing the details of the failure identification process. The process shown in the flowchart of FIG. 8 is executed when a negative determination is made in step S709 or step S710 of FIG. In FIG. 8, first, the first module execution unit 13 is a module that is “OK” from the first module management table 18 and is a module other than the module used by itself and the module that performed the output obtained in S705. Is selected (S801). The specification of the module that has performed the output obtained in S705 may be acquired from the second program 21 by communication, or may be specified according to a method of selecting a module in the second module execution unit 23, which is obtained in advance. The module selected in step S801 is hereinafter referred to as a substitute module. The first module execution unit 13 inputs the input value described in the first module input table 15 to the alternative module for the function whose output is not matched in the process shown in FIG. 7 and obtains the output value (S802) ).

Then, the first module execution unit 13 compares the output value with the two previous values (S803). The first module execution unit 13 determines whether the output of the alternative module matches one of the two output values compared in S710 of FIG. 7 (S804). When it is determined that the first module execution unit 13 matches one of the two (S804: Yes), the first module execution unit 13 determines that there is a failure in the module that has output the non-matching module. It is set as NG (S805). Then, the first module execution unit 13 clears the contents of the first module input table 15 and the first module output table 16 as in S711 (S806). Furthermore, the first module execution unit 13 outputs the output value of the majority, that is, the output value of the alternative module to the first application 12 (S807), and ends the processing shown in FIG.

If the first module execution unit 13 determines that the outputs of all the three modules do not match in S804 (S804: No), the first module execution unit 13 shifts to processing at the time of failure in consideration of the possibility of failure in all modules. (S811). The process at the time of failure is, for example, a process of securing safety by limiting functions such as the degeneration operation. However, the case of reaching S811 is a case where two or more modules have the same problem, for example, a bug, and the occurrence probability is extremely low.

(Description of operation)
The first program 11 and the second program 21 are respectively operated by applications performing the same operation. For this reason, the operations of the first program 11 and the second program 21 perform the same operation unless there is a fault such as a bug in the module. Further, as shown in FIG. 1, the modules provided in the first program 11 and the second program 21 are a P module 41 and an R module 43, and a Q module 42 and an R module 43, respectively. Since the first program 11 prioritizes the P module 41 and the second program 21 prioritizes and selects the Q module 42, the first program 11 and the second program 21 respectively input the same input to different modules. Therefore, these outputs are expected to be the same value, which the first module execution unit 13 collates. If the two do not match, it is known that there is a failure in one of the modules, so that it is possible to prevent the first application 12 from using the output of the failed module as it is.

Furthermore, if the two do not match, the first module execution unit 13 selects the R module 43 in the above example as an alternative module, and the first module execution unit 13 executes the R module 43 to generate a third output value. Get The first module execution unit 13 compares the three values of the P module 41, the Q module 42, and the R module 43, and determines the correct output by majority decision. Then, the first module execution unit 13 determines that the module that has output the output value belonging to the minority group in the majority vote is the module having a fault, and records “NG” in the operation status of that module in the first module management table 18.

The first application 12 continues to operate using the majority value according to the majority rule described above. Then, if it is determined that there is a failure in the P module 41, for example, the first module execution unit 13 uses the R module 43 in subsequent module calls. As a result, even if it is determined that one of the modules is faulty, the collation by the two modules can be continued, and the first application 12 can prevent the operation based on the output of the wrong module. That is, it is possible to obtain both the effect of continuing processing even if one module has a fault and the effect of securing security by checking the outputs of the two types of modules.

Furthermore, the use of computational resources in the ECU 100 is mostly in the first application 12 that implements functions, and is less used by modules. As described above, since the ECU 100 compares the outputs of the modules, the consumption of the computing resources of the CPU 110 and the storage resources of the memory 120 can be reduced as compared with the case of comparing the outputs of the first application 12. Furthermore, since the ECU 100 executes only two types of modules until the failure identification processing is performed, it is possible to similarly reduce the use of computation resources.

According to the first embodiment described above, the following effects can be obtained.
(1) The ECU 100 includes the memory 120 in which the P module 41, the Q module 42, and the R module 43 having the same function and different mounting are stored, the P module 41, the Q module 42, and the R module 43. It comprises a CPU 110 to be executed and a first module execution unit 13 and a second module execution unit 23 (S706 to S710 in FIG. 7) for detecting a fault based on the output of the P module 41 and the output of the Q module 42 by the CPU 110. Further, when a fault is detected by the fault detection process shown in FIG. 7, the ECU 100 starts using the R module 43, and based on the output of the P module 41, the output of the Q module 42, and the output of the R module 43. The first module execution unit 13 and the second module execution unit 23 (S804 in FIG. 8) for identifying a faulty software module are provided. That is, the ECU 100 has three modules but uses only two of them until a fault is detected, and uses a third module to identify a faulty module when a fault is detected. Therefore, the ECU 100 can realize fault detection and fault identification using limited computing resources.

(2) The ECU 100 stops the use of the software module identified as having a fault (S804 to S805 in FIG. 8). Therefore, the ECU 100 can continue the operation using a fault-free software module.

(3) When the first module execution unit 13 identifies one of the P module 41 and the Q module 42 as a faulty software module (S804 in FIG. 8: Yes, S805), the ECU 100 determines the P module 41 and the Q module. The fault is detected based on the software module not identified as having a fault among 42 and the output of the R module 43 (S702 in FIG. 7).

(4) The P module 41, the Q module 42, and the R module 43 include a software module for a 32-bit CPU and a software module for a 64-bit CPU. In order to enable execution in a wide range of environments, in other words, a library is often created for each of a 32-bit CPU and a 64-bit CPU in order to support multiple types of CPUs. By utilizing them, it is possible to implement the first embodiment described above by creating one library with a unique implementation.

(5) The P module 41 and the Q module 42 are executed in parallel by different CPU cores. Therefore, the outputs of the P module 41 and the Q module 42 can be obtained quickly to quickly determine the presence or absence of a failure.

(6) Each of the P module 41, the Q module 42, and the R module 43 includes a plurality of functions. A first output comparison table 17 is provided which defines the operations of S706 and S707 of failure detection processing for each of a plurality of functions. The first module execution unit 13 refers to the first output comparison table 17 to determine the failure detection condition for each function. Therefore, the ECU 100 can cope with a software module including a function whose output value is not constant even if a normal operation is performed, for example, a function of dynamically securing a memory area and returning the top address of the secured area. it can.

(Modification 1)
In FIG. 7, although output matching is always performed, matching may not be performed each time a module is called. For example, module calls may be checked a fixed number of times, for example, every three times. In this case, the number of calls is counted using a counter, and collation is performed only when it is a multiple of three. Further, the matching may be performed for a predetermined time, for example, every 10 ms. In this case, using a timer device or the like that measures time, collation is performed when 10 ms or more has elapsed since the previous collation. When the collation is not performed, the input and output of the call of the module are added to the first module input table 15 and the first module output table 16.

In this case, since the clear process (S711) is not performed, the collation can be performed later collectively. The output of the obtained module may be passed to the first application 12 as it is. Thereby, the following effects can be obtained. If the matching process is performed each time, the control process of the first application 12 may be affected by the time of the matching process. Therefore, the influence can be reduced by collectively performing the matching process according to some criteria. Furthermore, it is also possible to perform the matching process at a timing with little influence such as the waiting time of the periodic process. In addition, when performing collation collectively, there is a possibility that the wrong value has already been output to the application. Therefore, when a failure is detected, the application using the module in which the failure is detected needs to take action such as continuing the execution taking over the state of the other normal application.

(Modification 2)
In the flowcharts shown in FIGS. 7 and 8, even after the fault is identified, module selection is performed to maintain the dual system. However, if a failure is identified, the application using the module in which the failure is detected may be stopped, and thereafter only the other application may continue to operate. The present modification is particularly effective when it is difficult for an application using a module in which a failure is detected to take over the state of the other normal application to continue execution. That is, this modification is useful as a temporary process up to restart and repair.

(Modification 3)
In the embodiment described above, both the first program 11 and the second program 21 execute the process shown in the flowchart of FIG. However, when the modules selected by the first program 11 and the second program 21 as alternative modules are the same, for example, the R module 43 as described above, only one process is sufficient. Therefore, only the module execution unit of one of the programs may perform the execution of the alternative module and the comparison process (S801 to S804), and the result may be transmitted to the other module execution unit. According to this modification, in the other program or CPU core in which the collation process is not performed, another process can be executed during that time, and the utilization efficiency of the CPU can be improved.

(Modification 4)
The ECU 100 has three modules of the P module 41, the Q module 42, and the R module 43, but may have four or more types of modules. For example, the first program 11 may have a P module 41 and an R module 43, and the second program 21 may have a Q module 42 and a Z module. In this case, in the failure identification process, the first module execution unit 13 of the first program 11 executes the R module 43, and the second program 21 executes the Z module.

If the number of modules is even and it is 2: 2 and it is not possible to determine the majority, an odd number of modules may be added and a plurality of modules may be executed in each module execution unit. According to this modification, the probability of failure can be further reduced by using more types of modules. Also, by using N types of modules having the same functions and different implementations, the operations described in the first embodiment until faults occur in N-2 modules, that is, fault detection processing and fault identification processing Can continue. This has the effect of improving the continuity and availability of the operation.

(Modification 5)
The “output comparison classification” of the first output comparison table 17 shows only three types of “Compare, Ignore, and“ Compare if error ”in FIG. However, the “output comparison classification” is not limited to this. For example, a section may be provided to compare only on success regardless of the type of error, or a section may be provided to compare only error or success. Furthermore, a division may be provided in which only part of the output value, for example, the upper 3 bits and the lower 1 bit are compared. According to this modification, by creating the section in accordance with the specification of the module to be used, it is possible to improve the accuracy of the failure determination and to perform the failure detection promptly.

(Modification 6)
In the embodiment described above, the first program 11 and the second program 21 each include only one application. However, each program may have a plurality of applications using modules. In this case, a column identifying the calling application is added to the first module input table 15, and information indicating the relationship between the calling application and the called function is stored. According to this modification, even when the module is shared and used by a plurality of applications, the effects of the above-described embodiment can be obtained.

(Modification 7)
In the embodiment described above, the P module 41 and the R module 43 which are software modules are described as being different from the first application 12. However, the software module is a statically linked library and may be pre-installed in the first application 12. In this case, for example, the input to the P module 41 and the output from the P module 41 are executed inside the first application 12.

(Modification 8)
In S801 of FIG. 8, an alternative module was selected as follows. The first module execution unit 13 is a module whose operation status is “OK” in the first module management table 18, and selects a module other than the module used by itself and the module which performed the output obtained in S705. That is, in S801, a module which was not used by any of the first module execution unit 13 and the second module execution unit 23 was selected. However, the module which is not executed by itself, that is, the module which has produced the output obtained in S 705 may be further executed.

According to this modification, the following effects can be obtained.
(7) The CPU 110 includes the first CPU core 111 and the second CPU core 112. The fault identifying unit outputs the output of the P module 41 calculated by the second CPU core 112 when the output of the P module 41 calculated by the first CPU core 111 does not match the output of the Q module 42 calculated by the second CPU core 112. And the output of the Q module 42 calculated by the first CPU core 111, it is identified that the first CPU core 111 or the second CPU core 112 has a fault.

Therefore, this modification can also cope with hardware failures. For example, the output value of the P module 41 executed by the first program 11 is the output value A, the output value of the Q module 42 executed by the second program 21 is the output value B1, and the output value of the Q module 42 executed by the first program 11 Is an output value B, and an output value of the R module 43 which is an alternative module executed by the first program 11 is an output value C. At this time, the ECU 100 compares the output value B1 with the output value B2 to determine whether the mismatch between the output value A and the output value B1 is due to hardware failure of the CPU core or the like that has executed the output value B1. Can.

(Modification 9)
Selection of a module in S702 of FIG. 7 may be performed based on a preset priority. In this case, for example, the priority is set to each row of the first module management table 18. Then, the first module execution unit 13 selects a module whose operation status is “OK” and which has the highest priority. The same applies to the second module management table 28 and the second module execution unit 23.

(Modification 10)
The first CPU core 111 and the second CPU core 112 may read an area of the memory 120 in which necessary information is stored, instead of performing communication between CPU cores. However, in this case, it is necessary to confirm that the other CPU core also obtains the output of the module. This confirmation is apparent when using synchronous communication, and may be performed by checking the number of lines recorded in the first module output table 16. If the other CPU core does not obtain the output of the module, it waits until the other CPU core obtains the output of the module.

(Modification 11)
The plurality of modules described above may be libraries of different versions or different revisions having the same functions for the same architecture. The implementation may differ depending on the version or revision.
Furthermore, the plurality of modules described above may not be identical in all functions, and may include other functions as long as they include functions used from the application. For example, when an application calls a function A, a function B, and a function C provided in a module, one module may include only functions A to C, and another module may further include a function D in addition to the functions A to C .

-Second embodiment-
A second embodiment of the ECU, which is a control device, will be described with reference to FIGS. 9 to 10. In the following description, the same components as in the first embodiment will be assigned the same reference numerals and differences will be mainly described. The points that are not particularly described are the same as in the first embodiment. The present embodiment differs from the first embodiment mainly in that only one CPU core is provided.

FIG. 9 is a block diagram showing the configuration of ECU 100A in the second embodiment. In FIG. 9, the CPU 110 </ b> A of the ECU 100 </ b> A has a first CPU core 111. The first CPU core 111 operates the first program 11. The first module execution unit 13B of the first program 11 operates three modules of the P module 41, the Q module 42, and the R module 43.

FIG. 10 is a flowchart showing the operation of the first module execution unit 13B in the second embodiment. In FIG. 10, the same processes as in FIG. 7 in the first embodiment are assigned the same step numbers. That is, the difference from FIG. 7 is that S702A is executed instead of S702, S703A is executed instead of S703, and S705 is not executed. The other steps are the same as those in FIG.

When S701 is executed, the first module execution unit 13B selects two modules for executing a call of the first application 12 (S702A). This selection method is the same as in the first embodiment. Then, the first module execution unit 13B executes the function of each of the selected modules to obtain an output value (S703A). The subsequent processing is the same as that of the first embodiment, and thus the description thereof is omitted.

In the present embodiment, when the first application 12 calls a module on the first CPU core 111, the first module execution unit 13 executes a calculation using the P module 41 and the Q module 42, and compares their output values Do. That is, in the first embodiment, the execution of modules separately performed by the first program 11 and the second program 21 is performed in one program. Therefore, the process performed for fault detection is the same as that of the first embodiment in that the process of giving the same input to two different modules and comparing their outputs. Further, as in the first embodiment, the alternative module is selected and executed in order to identify a fault and the output thereof is obtained. Furthermore, it is the same as the third modification of the first embodiment in that there is only one program for executing and comparing alternative modules. That is, in this embodiment as well, detection and identification of a fault similar to the first embodiment are possible.

Comparing this embodiment with the first embodiment, in order to execute two modules with one CPU core at each module call, computing resources per one CPU core necessary for fault detection Will increase. However, in the present embodiment, since a plurality of CPU cores are not required, the number of CPU cores required on the ECU 100 can be reduced. Therefore, the effect of reducing the cost of the ECU 100 or the effect of increasing the efficiency can be obtained by performing another process in the CPU core that is not used. Also in the present embodiment, the modification described in the first embodiment can be applied similarly.

-Third embodiment-
A third embodiment of the ECU, which is a control device, will be described with reference to FIGS. 11 to 12. In the following description, the same components as in the first embodiment will be assigned the same reference numerals and differences will be mainly described. The points that are not particularly described are the same as in the first embodiment. The present embodiment differs from the first embodiment mainly in that another ECU is used to identify a fault.

FIG. 11 is a block diagram showing the configuration of a control system S in the third embodiment. The control system S includes a first ECU 1001, a second ECU 1002, and an alternative execution ECU 1003. The first ECU 1001, the second ECU 1002, and the alternative execution ECU 1003 each include a first network interface 119, a second network interface 219, and a third network interface 1110, and can communicate with each other via the network X. The physical characteristics of the network X and the communication protocol used in the network X are not particularly limited. The network X corresponds to, for example, CAN (Car Area Network) or IEEE 802.3.

The first ECU 1001 includes a CPU 110 and a memory 120. The second ECU 1002 includes a CPU 210 and a memory 220. The alternative execution ECU 1003 includes a CPU 310 and a memory 320. The hardware configuration of the CPU 110, the CPU 210, and the CPU 310 is the same as that of the CPU 110 in the first embodiment. As shown in FIG. 11, the P module 41 is stored in the first ECU 1001, the Q module 42 is stored in the second ECU 1002, and the R module 43 is stored in the alternative execution ECU 1003. The first module execution unit 13C corresponds to the first module execution unit 13 in the first embodiment, but differs from the first module execution unit 13 in that the R module 43 is not provided. The second module execution unit 23C corresponds to the second module execution unit 23 in the first embodiment, but differs from the second module execution unit 23 in that the R module 43 is not provided.

The first CPU core 111 built in the CPU 110 of the first ECU 1001 performs the same operation as the first CPU core 111 in the first embodiment. However, the present embodiment is different from the first embodiment in that communication with the second CPU core 112 is performed via the network X. Further, the first module execution unit 13C of the first ECU 1001 does not execute the R module 43 itself, and acquires an execution result from the alternative execution ECU 1003.

The second CPU core 112 built in the CPU 210 of the second ECU 1002 performs the same operation as the second CPU core 112 in the first embodiment. However, the present embodiment is different from the first embodiment in that communication with the first CPU core 111 is performed via the network X. In addition, the second module execution unit 23C of the second ECU 1002 does not execute the R module 43 itself, and acquires an execution result from the alternative execution ECU 1003.

The alternative execution ECU 1003 executes the R module 43 to identify a faulty module at the time of fault detection. The alternative execution ECU 1003 includes, in the memory 320, an alternative module execution unit 1140 that identifies a failure. The alternative module execution unit 1140 is executed by the CPU core 1151. The alternative module execution unit 1140 includes an R module 43 for fault identification, a module input reception unit 1141, and a module output transmission unit 1142. The module input reception unit 1141 receives an input for performing a function of a module through the third network interface 1110. The module output transmission unit 1142 transmits, through the third network interface 1110, an output obtained by executing the function of the module.

When receiving an input value from the first ECU 1001 or the second ECU 1002, the alternative module execution unit 1140 inputs the input value to the R module 43. Then, the alternative module execution unit 1140 transmits the obtained calculation result to the transmission source of the input value.

FIG. 12 is a flowchart showing failure identification processing in the first module execution unit 13C and the second module execution unit 23C in the present embodiment. In FIG. 12, the same processes as in FIG. 8 in the first embodiment are assigned the same step numbers. That is, the difference from FIG. 8 is that S1201 is executed instead of S801, and S1202 is executed instead of S802. The other steps are the same as those in FIG. Hereinafter, the operation of the first module execution unit 13C will be described on behalf of the first module execution unit 13C and the second module execution unit 23C.

When the fault identification process is started, the first module execution unit 13C transmits an input value to the alternative execution ECU 1130 (S1201). Then, the first module execution unit 13C receives, from the alternative execution ECU 1130, the calculation result using the R module 43 by the alternative module execution unit 1140 (S1202). The other steps are the same as those in FIG.

According to the third embodiment described above, even when ECUs executing the respective modules are different, it is possible to detect and specify a fault as in the first embodiment.

(Modification 1 of the third embodiment)
In the third embodiment described above, the first program 11 and the second program 21 are executed in different ECUs. However, similar to the ECU 100 in the first embodiment, it may be executed in different CPU cores of the same ECU. In this case, the fault detection process is the same as that of the first embodiment, and only the fault identification process is the process described in the third embodiment. This can reduce the number of required ECUs.

(Modification 2 of the third embodiment)
The first program 11 and the second program 21 may be executed in different CPU cores of the same ECU, and the same ECU may further include a third CPU core that executes the alternative module execution unit 1140. In this case, the network interface 1110 and the communication network bus 1120 can be realized as performing inter-core communication in the same ECU. This allows the number of required ECUs to be one.

(Modification 3 of the third embodiment)
In the third embodiment described above, only one set of the first ECU 1101 and the second ECU 1102 is shown. However, there may be a plurality of sets of ECUs that perform the same processing. The alternative execution ECU 1130 may be shared by these sets of ECUs. Since the alternative execution ECU 1130 operates only when a failure is detected, the operation rate of the alternative execution ECU 1130 is low. Therefore, the operation rate of the alternative execution ECU 1130 can be improved by executing the process according to the request from the plurality of sets of ECUs.

Also, in this case, the plurality of ECUs may use the same module or different modules. For example, there are a module S having a function A, a module T, a module U and a module V having a function B, a module W and a module X, and the module S, the module T, the module V and the module W are stored in different ECUs The case is In this case, the alternative execution ECU 1130 includes the module X and the module W, and the calculation result of the module X or the module W according to the input value input from each ECU including the module S, the module T, the module V, and the module W When transmitted to each ECU, the following effects can be obtained. That is, the number of required alternative execution ECUs can be reduced.

(Modification 4 of the third embodiment)
In the third modification of the third embodiment described above, there may be a plurality of alternative execution ECUs 1130. Furthermore, the ECU that executes one of the programs may have the function of the alternative execution ECU 1130. As a result, compared to the case of the third modification, even if one failure specifying ECU fails, the failure specifying function can be continued by the other ECUs.

When the ECU executing the program also has a function as the alternative execution ECU 1130, each alternative execution ECU 1130 may have a function to monitor the processing load size and the fault situation in the other alternative execution ECU 1130. In this case, the alternative module execution unit 1140 has a function of transmitting information indicating the magnitude of the current calculation load of the CPU 310 and whether or not arithmetic processing using the R module 43 is performed to surrounding devices. The first module execution unit 13C and the second module execution unit 23C determine an alternative execution ECU 1130 that executes an operation using the R module 43 based on the information received from each alternative execution ECU 1130. Specifically, the first module execution unit 13C and the second module execution unit 23C specify the alternative execution ECU 1130 that has not performed the calculation using the R module 43 and has the lowest calculation load of the CPU 310, and The alternative execution ECU 1130 is made to execute an operation using the R module 43.

According to this modification, the following effects can be obtained.
(8) The first ECU 1001 includes a first network interface 119 for communicating with another computing device, and an alternative module execution unit 1140 for outputting the magnitude of the current calculation load to the other computing device via the communication unit. . The first module execution unit 13C determines an alternative execution ECU 1003 that calculates the output of the third software module based on the received current calculation load. Therefore, the loads of the plurality of alternative execution ECUs 1003 can be equalized.

(Modification 5 of the third embodiment)
In the third embodiment described above, the failure identification process is executed by the first module execution unit 13C of the first ECU 1001 or the second module execution unit 23C of the second ECU 1002. However, the fault identification process may be executed in the alternative module execution unit 1140. In this case, the substitute execution ECU 1003 also acquires the output value of the module executed in the first ECU 1001 and the second ECU 1002. The fault identification process in the alternative module execution unit 1140 is the same as S803 and S804 in FIG. The alternative module execution unit 1140 transmits, to each ECU, information indicating the module in which the failure is identified. The first module execution unit 13C and the second module execution unit 23C receive the information, and execute the processing after S805. According to this modification, it is possible to balance the processing load of the first module execution unit 13C and the second module execution unit 23C of the first ECU 1001 and the second ECU 1002 with the processing load of the alternative module execution unit 1140.

Although each CPU core operates one program in the embodiment and modification described above, each CPU core may operate a plurality of programs, and a plurality of CPU cores may operate one program. You may share it. In this case, a part or all of the code executed by each CPU core or a part or all of the data used by the CPU core may be different, and only different codes and data may be stored. . Alternatively, the code executed by the CPU 110 or the data to be read only may be arranged in the non-volatile memory, and the data to be read and written may be stored in the volatile memory.

Each embodiment and modification mentioned above may be combined respectively. Although various embodiments and modifications have been described above, the present invention is not limited to these contents. Other embodiments considered within the scope of the technical idea of the present invention are also included within the scope of the present invention.

The disclosure content of the following priority basic application is incorporated herein by reference.
Japanese Patent Application 2017-136657 (filed on July 12, 2017)

DESCRIPTION OF SYMBOLS 3 ... Module 11 ... 1st program 12 ...

1st application

13, 13B, 13C ... 1st module execution part 15 ... 1st module input Table 16 ... 1st module output table 17 ... 1st output collation table 18 ... 1st module Management table 21 ... second program 22 ...

second application

23, 23 C ... second module execution unit 25 ... second module input table 26 ... second module output table 27 ... second output comparison table 28 ... second module management table 41 ... P module 42 ... Q module 43 ... R module 110 ... CPU
111 ... 1st CPU core 112 ... 2nd CPU core

Claims

A storage unit in which a first software module having the same function and implemented differently and a second software module and a third software module are stored;
The first software module, the second software module, and an operation unit that executes the third software module;
A detection unit that detects a fault based on an output of the first software module by the arithmetic unit and an output of the second software module;
When the detection unit detects a failure, it starts using the third software module, and the output of the first software module, the output of the second software module, and the output of the third software module And a failure identifying unit for identifying a software module having a failure based on.
In the arithmetic device according to claim 1,
A computing device for stopping the use of the software module identified as having a fault by the fault identification unit.
In the arithmetic device according to claim 2,
When the fault identifying unit identifies any one of the first software module and the second software module as a faulty software module, the detection unit determines the first software module and the second software module. And a computing device that detects a fault based on a software module not identified as having a fault and an output of the third software module.
In the arithmetic device according to claim 1,
A computing device including a software module for a 32-bit CPU and a software module for a 64-bit CPU in the first software module, the second software module, and the third software module.
In the arithmetic device according to claim 1,
A computing device in which the first software module and the second software module are executed in parallel.
In the arithmetic device according to claim 1,
The arithmetic unit comprises a first core and a second core,
The failure identifying unit is configured to output the second core when the output of the first software module calculated by the first core does not match the output of the second software module calculated by the second core. An operation that specifies that there is a fault in the first core or the second core using the calculated output of the first software module and the output of the second software module calculated by the first core apparatus.
In the arithmetic device according to claim 1,
A communication unit that communicates with the other arithmetic device;
And a load calculation unit for outputting the current calculation load size to the other arithmetic device via the communication unit,
The operation specifying unit further includes an operation command unit that determines the operation unit that calculates the output of the third software module based on the received current calculation load.
In the arithmetic device according to claim 1,
Each of the first software module, the second software module, and the third software module includes a plurality of functions.
It further comprises an output matching table that defines the operation of the detection unit for each of the plurality of functions,
The detection unit determines the failure detection condition for each of the functions with reference to the output comparison table.