JP6502211B2 - Vehicle control device - Google Patents

Description

  The present invention relates to a vehicle control device.

  Many recent vehicle control systems consist of an electronic control unit (ECU) that operates computerized vehicle control devices, and an in-vehicle LAN (Local Area Network) that enables communication between multiple ECUs. It is done.

  Vehicle control systems are becoming more sophisticated, decentralized, and more complex as the environmental load reduction and safety requirements increase. As a result, standardization of the software architecture of ECUs, the electronic control of safety devices, and the mechanism for ensuring their safety are increasing.

  The car maker prepares a dedicated ECU for each of the distributed functions. Therefore, a plurality of ECUs having different specifications coexist in one vehicle control system. By introducing a standardized vehicle control device software architecture, it becomes easy to combine the ECUs with different specifications to construct a vehicle control system.

  In the AUTOSAR architecture described in Non-Patent Document 1 below, software is modularized in functional units dependent on a microcomputer, algorithmic units for control processing of sensors and actuators, and setting parameter units. Therefore, even if the microcomputer is changed according to, for example, a change in vehicle type, it is possible to cope with the changed specification only by correcting the module requiring the specification change, and it is not necessary to correct other modules.

  With the electronic control of safety devices in vehicle control equipment, functional safety mechanisms have been introduced into vehicle control systems. Functional safety is an idea of securing safety by transitioning to the safe side when a failure occurs in the electric / electronic system. For example, in the automotive functional safety standard ISO26262 described in Non-Patent Document 2 below, ASIL (Automotive Safety Integrity Level), which is a safety level unique to the standard, is provided. In order to comply with the highest level ASIL D, it is possible to prove to a third party that the functions relating to the safety of the vehicle control device are clearly configured separately as the main function / safety device / monitoring device. It has been demanded.

  According to ISO26262, it is required to prevent interference between software whose safety requirements are different. Since a general vehicle control system is configured by various control applications, a mechanism for preventing interaction between software configuring the system, such as a time protection function and a memory protection function, has recently been focused on. Specifically, it is a function to prevent the runaway software from accessing the memory area where data used by other software is stored and attempting to destroy the data when certain software runs away. Applying the AUTOSAR architecture in a common vehicle control system, the vehicle control system is known to be mixed with various ASIL software. Therefore, in order for existing software to conform to ISO26262, a mechanism for preventing interference between software is required.

  Patent Document 1 mentioned below refers to a configuration that has a diagnostic function for each function, determines its own state, and executes fail-safe processing according to its own function if an abnormality is detected. As a result, even if an abnormality occurs in the software, a mechanism for detecting the abnormality and a function to cope with the abnormality are incorporated, so that the influence of the software in which the abnormality has occurred can be prevented from spreading to other software.

JP, 2014-115950, A

AUTOSAR_EXP_LayeredSoftwareArchitecture ISO26262

  In a vehicle control system in which software having different safety levels is mixed, a protection function (time protection, memory protection) is required to prevent the influence from software with low safety levels. For example, time protection is applied to tasks and interrupt processing that are units to be processed by the OS (Operating System), and it is detected that the processing time exceeds an assumption (deadline over) so that an abnormality does not propagate to the entire system. Function.

  In the conventional vehicle control system as described in Patent Document 1, each process has a monitoring function, and when an abnormality is detected, the OS or the entire system is restarted or software reset as a failsafe process. This may interrupt the control process and may at least temporarily stop the operation of the vehicle control system. If the operation of the vehicle is stopped (even if it is temporary), the convenience is reduced, and therefore it is required to ensure the operation continuity of the entire vehicle control system.

  The present invention has been made in view of the problems as described above, and an object of the present invention is to provide a vehicle control device capable of securing operation continuity while performing abnormality processing.

  The vehicle control device according to the present invention determines the abnormal level of the system according to the cumulative number or frequency of the abnormality, and executes different fail-safe processing according to the abnormal level.

  According to the vehicle control device of the present invention, it is possible to execute the abnormality processing while securing the operation continuity.

It is a block diagram of ECU1. It is a figure which shows the structure of the time management table 510, and an example of data. It is a figure which shows the structure and data example of the process management table 520. FIG. It is a figure which shows the example of the operation condition management table 530. FIG. FIG. 7 is a diagram showing the configuration and data example of a function abnormality management table 540. FIG. 6 is a diagram showing the configuration and data example of a system abnormality management table 550. It is a figure which shows the example of the determination result management table 560. FIG. 5 is a flowchart illustrating an operation of a software control unit 401. It is a flowchart explaining operation | movement of the abnormality management table initialization part 402. FIG. It is a flowchart explaining operation | movement of the process execution part 403. FIG. It is a flow chart explaining operation of 10 ms processing execution part 404. It is a flowchart explaining operation | movement of 5 ms process execution part 405. FIG. It is a flowchart explaining operation | movement of the abnormality detection part 406. FIG. It is a flowchart explaining operation | movement of the function diagnostic part 407. FIG. FIG. 18 is a flowchart illustrating the operation of the system diagnosis unit 408. FIG. It is a flowchart explaining operation | movement of the abnormal level determination part 409. FIG. 5 is a flowchart illustrating an operation of the FS execution unit 410. It is a flowchart explaining operation | movement of the time management part 411. FIG.

  FIG. 1 is a block diagram of an ECU 1 according to an embodiment of the present invention. The ECU 1 is a device that electronically controls electric devices (for example, the throttle sensor 7 and the actuator 8 shown in FIG. 1) included in the vehicle, and includes a central processing unit (CPU) 2, a memory 3, and an input / output circuit 6. Prepare.

  The CPU 2 is a processor that executes a program stored in the memory 3. In the following, for convenience of description, each program may be described as an operation subject, but it is the CPU 2 that actually executes these programs.

  The memory 3 has a program storage area 4 and a data storage area 5. The program storage area 4 is a storage area for storing a program to be executed by the CPU 2 and includes a software control unit 401, an abnormality management table initialization unit 402, a process execution unit 403, a 10 ms process execution unit 404, a 5 ms process execution unit 405, and A detection unit 406, a function diagnosis unit 407, a system diagnosis unit 408, an abnormality level determination unit 409, an FS execution unit 410, and a time management unit 411 are stored. Details of these functional units will be described later. The data storage area 5 stores data tables described later with reference to FIGS.

  The input / output circuit 6 is a signal interface for transmitting a signal to an external device such as the throttle sensor 7 or the actuator 8 or receiving a signal from the external device.

  FIG. 2 is a diagram showing the configuration of the time management table 510 and an example of data. The time management table 510 is a data table that describes values related to time managed by the ECU 1. The time management table 510 has a name field 511, a threshold field 512, and a current value field 513.

  The name field 511 holds the names of data items managed by the time management table 510. Threshold field 512 holds the threshold for each data item. This field is empty for data items that do not have a threshold. The present value field 513 holds the present value of each data item.

  Specific examples of data items managed by the time management table 510 include, for example, a current value and an initialization threshold of a timer counter described later, and a current value of an execution cycle of each process described in the flowchart described later.

  FIG. 3 is a diagram showing the configuration of the process management table 520 and an example of data. The process management table 520 is a data table for managing parameters related to control processes (functions) managed by the OS. The process management table 520 includes an index field 521, a process name field 522, an execution cycle field 523, a safety level field 524, an execution time field 525, and an execution count field 526.

  The index field 521 indicates the execution order of the processing. The process name field 522 holds a name for specifying the process. The execution cycle field 523 indicates a cycle in which the process is performed. The security level field 524 holds the value of the security level of the software allocated to the process. In the case of “1”, it indicates that it is ASIL software (software with a high required security level), and in the case of “0”, it shows that it is QM software (which has a low required security level). The execution time field 525 holds the time it is assumed to take to perform the process. The number of times of execution field 526 holds the number of times it is assumed that the processing is performed per unit time.

  FIG. 4 is a diagram showing an example of the operation status management table 530. The operation status management table 530 is a data table for managing the operation status of the process managed by the OS. The operation status management table 530 has an index field 531, a process name field 532, an activation permission flag field 533, a start time field 534, an end time field 535, an execution time field 536, and an execution count field 537.

  The index field 531 indicates the execution order of the processing. The process name field 532 holds a name for specifying the process. The start permission flag field 533 holds a flag indicating whether the process is permitted to start in the current cycle. "0" indicates that activation is not possible, and "1" indicates that activation is permitted. The start time field 534 and the end time field 535 hold the time when the process started and the time when the process ended. The execution time field 536 holds the time actually taken to execute the processing. The number of times of execution field 537 holds the number of times the process is actually performed per unit time.

  FIG. 5 is a diagram showing a configuration of the function abnormality management table 540 and an example of data. The function abnormality management table 540 is a data table for managing an abnormal state of processing managed by the OS. The functional abnormality management table 540 has a process name field 541, a threshold field 542, and an abnormal counter field 543.

  The process name field 541 holds a name for specifying a process. The abnormality counter field 543 holds the number of times the process is determined to be abnormal. The threshold field 542 holds a threshold for determining whether or not the value of the abnormality counter field 543 is abnormal in FIG. 14 described later.

  FIG. 6 is a diagram showing the configuration of the system abnormality management table 550 and an example of data. The system abnormality management table 550 is a data table for managing an abnormal state at the system level (an abnormality across the entire ECU 1). The system abnormality management table 550 has a name field 551, a threshold field 552, and a value field 553.

  The name field 551 holds the name of the abnormal parameter managed by the system abnormality management table 550. The value field 553 holds the current value of the abnormal parameter. The threshold field 552 holds a threshold for determining a system abnormal level using the abnormal parameter.

  FIG. 7 is a diagram showing an example of the determination result management table 560. The determination result management table 560 is a data table for managing the abnormality determination results by the function diagnosis unit 407, the system diagnosis unit 408, and the abnormality level determination unit 409. The determination result management table 560 has a name field 561 and a value field 562. The name field 561 holds the name of the determination result managed by the determination result management table 560. The value field 562 holds the value of the determination result.

  FIG. 8 is a flowchart for explaining the operation of the software control unit 401. Hereinafter, each step of FIG. 8 will be described.

(FIG. 8: Step S401000)
The software control unit 401 calls the abnormality management table initialization unit 402. This step is to initialize each table for managing the current value. Details of this step will be described later with reference to FIG.

(FIG. 8: Step S401001)
The software control unit 401 calls the process execution unit 403. This step is for carrying out each control process executed by the ECU 1. The details of this step will be described later with reference to FIG.

(FIG. 8: Step S40102)
The software control unit 401 calls the abnormality detection unit 406. This step is for diagnosing an abnormality of each control process and an abnormality of the system level (an abnormality of the entire ECU 1). The details of this step will be described later with reference to FIG.

(FIG. 8: Step S401003)
The software control unit 401 calls the FS execution unit 410. This step is for executing a fail-safe process to shift the ECU 1 to a safe state. The details of this step will be described later with reference to FIG.

(FIG. 8: Step S401004)
The software control unit 401 calls the time management unit 411. The details of this step will be described later with reference to FIG.

(FIG. 8: Step S401005)
The software control unit 401 determines whether to end the operation based on, for example, whether or not an instruction to shut down the ECU 1 is given. If the operation is ended, the present flowchart is ended, and if it is continued, the process returns to step S401000.

  FIG. 9 is a flowchart for explaining the operation of the abnormality management table initialization unit 402. Hereinafter, each step of FIG. 9 will be described.

(FIG. 9: Step S402000)
The abnormality management table initialization unit 402 acquires the current value of the timer counter (the record in the first row of FIG. 2) from the time management table 510, and acquires the table initialization cycle (the record in the second row of FIG. 2). Do. If the remainder obtained by dividing the acquired timer counter by the acquired cycle (100 in this example) is 0, the process advances to step S402001; otherwise, this flowchart ends.

(FIG. 9: Step S402000: Supplement)
This step is for initializing an abnormality count (the number of times each function or the entire system is determined to be abnormal) every cycle defined by the time management table 510. It is also conceivable to make an anomaly judgment using the cumulative number without initializing the anomaly count. In this case, when the cumulative number reaches a certain level, it is regarded as a system level abnormality. This is equivalent to performing fail-safe etc. when serious abnormalities in the whole system level are reached ignoring relatively minor abnormalities. However, in actual operation, minor errors often occur frequently in each functional element provided in the ECU. For example, a memory bit error often occurs, but the error correction function allows the control process to proceed normally, and is not considered abnormal. Even if it is a small-scale abnormality, depending on the frequency and the number of occurrence points, it may have a serious influence on or approach the operation of the entire ECU 1. Therefore, in the present embodiment, the abnormality count is periodically reset in order to detect a small-scale instantaneous error that actually occurs even if an abnormality does not occur at the system level. If you do not reset the abnormal count at all, or set the reset cycle too long, it will not change from counting the cumulative count, so reset cycle should be set in advance to an appropriate value that can detect an instantaneous error. .

(FIG. 9: Steps S402001 to S402003)
The abnormality management table initialization unit 402 includes an abnormality counter field 543 (S402001) of the function abnormality management table 540, a value field 553 (S402002) of the system abnormality management table 550, and a start time field 534 to an execution count field of the operation status management table 530. 537 (S402003) is initialized.

  FIG. 10 is a flowchart for explaining the operation of the process execution unit 403. Hereinafter, each step of FIG. 10 will be described.

(FIG. 10: Step S403000)
The process execution unit 403 acquires the current value of the timer counter (the record in the first row of FIG. 2) from the time management table 510. If the remainder obtained by dividing the obtained timer counter by 10 is 0, the process proceeds to step S403001, and otherwise skips to step S403002.

(FIG. 10: Step S403001)
The process execution unit 403 calls the 10 ms process execution unit 404. The 10 ms processing execution unit 404 executes control processing to be performed in a 10 ms cycle. The operation of the 10 ms process execution unit 404 will be described later with reference to FIG. The processing execution unit 403 does not have to wait for the processing completion of the 10 ms processing execution unit 404 in this step, and can call 10 ms processing execution unit and immediately proceed to step S 403 002 to execute parallel processing of 10 ms cycle.

(FIG. 10: step S403002)
The process execution unit 403 acquires the current value of the timer counter from the time management table 510. If the remainder obtained by dividing the obtained timer counter by 5 is 0, the process advances to step S403003; otherwise, this flowchart ends.

(FIG. 10: step S403003)
The processing execution unit 403 calls the 5 ms processing execution unit 405. The 5 ms processing execution unit 405 executes control processing to be performed in a 5 ms cycle. The operation of the 5 ms process execution unit 405 will be described later with reference to FIG.

(FIG. 10: supplement to steps S40300 and S403002)
The reason why the timer counter is divided by 10 and 5 in these steps is that functions whose execution cycle fields 523 are 10 and 5 are registered in the process management table 520, respectively. These execution cycles may be acquired in advance, or may be acquired at an appropriate time (for example, before S403000) in this flowchart.

  FIG. 11 is a flowchart for explaining the operation of the 10 ms process execution unit 404. Hereinafter, each step of FIG. 11 will be described.

(FIG. 11: Step S404000)
If the execution cycle field 523 of the i-th process managed by the process management table 520 is 10 (ms), the 10 ms process execution unit 404 further sets the start permission flag field 533 of the process from the operation status management table 530. get. If the execution cycle field 523 is 10 and the value of the start permission flag field 533 is 1, the process proceeds to step S404001, otherwise i is incremented and then this step is performed again.

(FIG. 11: Step S404001)
The 10 ms process execution unit 404 acquires the current value of the timer counter from the time management table 510, and records the value in the start time field 534 of the i-th record of the operation status management table 530.

(FIG. 11: Steps S404002 to S404003)
The 10 ms process execution unit 404 executes the i-th process (S404002). The 10 ms process execution unit 404 increments the number of times of execution field 537 of the i-th record of the operation status management table 530 by one.

(FIG. 11: Step S404004)
The 10 ms processing execution unit 404 acquires the current value of the timer counter from the time management table 510, and records the value in the end time field 535 of the i-th record of the operation status management table 530.

(FIG. 11: Step S404005)
The 10 ms process execution unit 404 confirms whether or not the execution of all the processes to be executed in a 10 ms cycle has been completed. If all the processing has been completed, the present flowchart is ended. If not, i is incremented and the process returns to step S404000.

(Figure 11: Supplement)
The 10 ms process execution unit 404 does not have to wait for each process to complete before starting the next process, and can execute each process in parallel. In that case, steps S404001 to S404004 will be executed in parallel for each process.

  FIG. 12 is a flowchart for explaining the operation of the 5 ms process execution unit 405. The operation of the 5 ms process execution unit 405 is substantially the same as that of the 10 ms process execution unit 404, except that the process in which the value of the execution cycle field 523 is 5 is targeted.

  FIG. 13 is a flowchart illustrating the operation of the abnormality detection unit 406. Hereinafter, each step of FIG. 13 will be described.

(FIG. 13: Step S406000)
The abnormality detection unit 406 acquires the current value of the timer counter from the time management table 510, and acquires the diagnostic cycle (the third line record in FIG. 2). If the remainder obtained by dividing the acquired timer counter by the acquired period (20 in this example) is 0, the process proceeds to step S406001. Otherwise, this flowchart ends.

(FIG. 13: Step S406001)
The abnormality detection unit 406 calls the function diagnosis unit 407. This step is for detecting each functional abnormality. The details of this step will be described later with reference to FIG.

(FIG. 13: step S406002)
The abnormality detection unit 406 calls the system diagnosis unit 408. This step is to detect an abnormality at the system level (the entire ECU 1 level). The details of this step will be described later with reference to FIG.

(FIG. 13: Step S406003)
The abnormality detection unit 406 calls the abnormality level determination unit 409. This step is to determine the abnormal level of the ECU 1. The details of this step will be described later with reference to FIG.

  FIG. 14 is a flowchart for explaining the operation of the function diagnosis unit 407. Hereinafter, each step of FIG. 14 will be described.

(FIG. 14: Step S407000)
The function diagnosis unit 407 acquires the values of the start time field 534 and the end time field 535 of the process i from the operation status management table 530, calculates the execution time of the process i based on the difference, and stores it in the execution time field 536 Do.

(FIG. 14: Step S407001)
The function diagnosis unit 407 compares the execution time calculated in step S407000 with the execution time field 525 of the process i stored in the process management table 520. If the calculated execution time is larger, the process skips to step S407003. If the calculated execution time is smaller, the process proceeds to step S407002.

(FIG. 14: Step S407002)
The function diagnosis unit 407 acquires the execution frequency field 537 of the process i from the operation status management table 530, and compares it with the execution frequency field 526 of the process i stored in the process management table 520. If the number of execution times field 537 is larger, the process proceeds to step S407003, and if smaller, the process skips to step S407004.

(FIG. 14: Step S407003)
The function diagnosis unit 407 increments the abnormality counter field 543 of the i-th record of the function abnormality management table 540 by one. When the safety level field 524 of the process i is “1”, “1” is stored in the value field 562 of the high priority process abnormality flag stored in the determination result management table 560.

(FIG. 14: Step S407003: Supplement)
In the present embodiment, different fail-safe processing is performed according to the abnormality level of the entire ECU 1 as described later with reference to FIG. Therefore, it is necessary to determine the level of system abnormality in accordance with the degree of failure occurring. If a function with a high required safety level is broken, it is considered that the degree of failure is high. For this function, a special flag for managing an abnormal state is provided and managed.

(FIG. 14: Step S407004)
The function diagnosis unit 407 determines whether the diagnosis has been completed for all the processes. If the diagnosis is completed, the process proceeds to step S407005. Otherwise, the value of i is incremented and the process returns to step S407000.

(FIG. 14: Step S407005)
The function diagnosis unit 407 compares the abnormality counter field 543 and the threshold field 542 of each record of the function abnormality management table 540. If the abnormality counter field 543 is larger, it is determined that the function is abnormal. The function diagnosis unit 407 stores the number of functions determined to be abnormal in the value field 562 of the number of function abnormalities in the determination result management table 560.

  FIG. 15 is a flowchart for explaining the operation of the system diagnosis unit 408. Hereinafter, each step of FIG. 15 will be described.

(FIG. 15: Step S408000)
The system diagnosis unit 408 acquires the value of the abnormality counter field 543 for all processes from the function abnormality management table 540. The system diagnosis unit 408 divides the total value of the acquired abnormality counters by the total number of processes (for example, the number of records in the function abnormality management table 540) to calculate an average value of the number of function abnormality times. The system diagnosis unit 408 stores the calculated average value in the value field 553 of the record that records the average number of function malfunction in the system malfunction management table 550.

(FIG. 15: Step S408000: Supplement)
In this flowchart, the average value of the abnormality count is used as the determination index of the system abnormality level from the viewpoint of simplicity of processing, but other values may be used. For example, each process may be weighted according to the importance, and the abnormality count of each process may be multiplied by the weight to obtain the total value, and the result may be stored in the value field 553 and used as a judgment index of the system abnormality level. it can.

(FIG. 15: Step S408001)
The system diagnosis unit 408 compares the average value calculated in step S408000 with the threshold field 552 of the average number of functional abnormality times stored in the system abnormality management table 550. If the calculated average value is larger, the process proceeds to step S408002, and if smaller, the process skips to step S408003.

(FIG. 15: Step S408002)
The system diagnosis unit 408 increments the value field 553 of the record recording the system abnormality counter of the system abnormality management table 550 by one.

(FIG. 15: Step S408003)
The system diagnosis unit 408 compares the value field 553 of the system malfunction counter with the threshold field 552 of the system malfunction counter stored in the system malfunction management table 550. If the value field 553 is larger, the process proceeds to step S408004, and if smaller, the flowchart ends.

(FIG. 15: Step S408004)
The system diagnosis unit 408 stores “1” in the value field 562 of the record in which the system abnormality flag of the determination result management table 560 is recorded.

  FIG. 16 is a flowchart for explaining the operation of the abnormal level determination unit 409. Hereinafter, each step of FIG. 16 will be described.

(FIG. 16: Step S409000)
The abnormality level determination unit 409 acquires the value field 562 of the system abnormality flag from the determination result management table 560. If the value of the system abnormality flag is "1", the process proceeds to step S409001. If the value is "0", the process skips to step S409002.

(FIG. 16: Step S409001)
The abnormal level determination unit 409 stores “3” in the value field 562 of the record for recording the abnormal level of the determination result management table 560.

(FIG. 16: step S409002)
The abnormal level determination unit 409 acquires the value field 562 of the high priority process abnormality flag from the determination result management table 560. If the value of the high priority process abnormality flag is "1", the process proceeds to step S409001. If the value is "0", the process proceeds to step S409003.

(FIG. 16: Steps S409001 to S409002: Supplement)
The system malfunction flag is a flag that is set when the system malfunction counter is greater than or equal to the threshold in step S408003. The system abnormality counter is counted up when the average value of the number of functional abnormalities is equal to or more than a threshold. That is, since the system abnormality flag indicates that a large number of functions are abnormal, it is considered that the system abnormality level is high when this is set. Therefore, the abnormal level in this case is determined to be the highest "3" in this flowchart. Further, since the high priority process abnormality flag indicates that the process with a high degree of safety requirement is abnormal, it is treated as the system abnormality flag.

(FIG. 16: Steps S409003 to S409004)
The abnormality level determination unit 409 acquires the value field 562 of the number of functional abnormalities from the determination result management table 560. If the number of functional abnormalities is larger than 2, "2" is stored in the value field 562 of the record recording the abnormal level of the determination result management table 560 in step S409004. If the number of functional abnormalities is 2 or less, the process proceeds to step S409005.

(FIG. 16: Steps S409005 to S409006)
If the functional abnormality number is larger than one, the abnormal level determination unit 409 stores “1” in the value field 562 of the record recording the abnormal level of the determination result management table 560 in step S409006. If the number of functional abnormalities is less than or equal to one, this flowchart ends.

(FIG. 16: Steps S409003 to S409006: Supplement)
In this flowchart, the abnormality level is set based on the number of functional abnormalities, but the number as the reference is not limited to that shown in this flowchart, and can be appropriately determined based on, for example, the total number of functions.

  FIG. 17 is a flowchart illustrating the operation of the FS execution unit 410. Hereinafter, each step of FIG. 17 will be described.

(FIG. 17: Steps S410000 to S410001)
The FS execution unit 410 acquires, from the determination result management table 560, the value field 562 of the record in which the abnormal level is recorded. If the abnormality level is "3", the ECU 1 is software reset in step S410001. Otherwise, the process proceeds to step S410002.

(FIG. 17: steps S41002 to S410003)
If the abnormality level is “2”, the FS execution unit 410 determines that the activation permission flag field 533 of all functions for which the safety level field 524 is “0” (that is, the required safety level is low) in step S410003. Is set to "0" (ie, it can not be activated). Otherwise, the process proceeds to step S410004.

(FIG. 17: Step S410004)
If the abnormality level is “1”, the FS execution unit 410 sets the activation permission flag field 533 of the function whose abnormality counter field 543 exceeds the threshold field 542 to “0” in step S410005 (that is, makes the activation impossible). ). If not, this flowchart ends.

  FIG. 18 is a flowchart for explaining the operation of the time management unit 411. Hereinafter, each step of FIG. 18 will be described.

(FIG. 18: Steps S411000 to S411001)
The time management unit 411 increments the current value of the timer counter stored in the time management table 510.

(Figure 18: Step)
The time management unit 411 acquires the threshold field 512 of the timer counter stored in the time management table 510. If the current value of the timer counter exceeds the threshold field 512, the current value of the timer counter is set to 0 in step S411002. If not, this flowchart ends.

<Summary of the Invention>
The ECU 1 according to the present embodiment determines the system abnormality level based on the number of functional abnormalities per unit time, and executes fail-safe processing according to the system abnormality level. Therefore, for example, when the system abnormality level is low, the operation continuity of the ECU 1 can be enhanced by executing the fail-safe operation while maintaining as many functions as possible.

  The ECU 1 according to the present embodiment manages the operating condition of each function, and determines an abnormal level of the entire system based on the operating condition. As a result, appropriate fail-safe processing can be executed and dealt with before a serious abnormal state that hinders the operation of the entire ECU 1 is reached.

  The ECU 1 according to the present embodiment considers that the system abnormality level is higher than the case where the other functions are abnormal if the function having the high required safety level is abnormal. Thus, control conforming to a standard that strictly defines the safety level, such as AUTOSAR, can be realized.

<About the modification of the present invention>
The present invention is not limited to the embodiments described above, but includes various modifications. For example, the embodiments described above are described in detail in order to explain the present invention in an easy-to-understand manner, and are not necessarily limited to those having all the configurations described. In addition, part of the configuration of one embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of one embodiment. In addition, another configuration can be added to, deleted from, or replaced with a part of the configuration of each embodiment.

  In the above embodiment, the ECU 1 has an architecture conforming to ISO26262, but the subject of the present invention is not limited to this and may have other functional units. For example, a non-volatile memory (backup RAM) for storing data or a water temperature sensor may be provided. Further, the present invention can be applied to general control devices that control electric devices provided in a vehicle.

  In the above embodiment, each threshold value is only one, but for example, the upper limit value or the lower limit value can be used to express the range of the threshold value. That is, any type of threshold can be used as long as abnormality determination can be performed.

  In the above embodiment, 5 ms cycle processing and 10 ms cycle processing are dealt with for simplicity of explanation, but the present invention can be applied to processing of other cycles. The same applies to functions other than cyclic processing.

  In the above embodiment, two values of ASIL (1) and QM (0) are illustrated as values of the safety level field 524, but three or more safety levels may be provided. Although the abnormal levels 1 to 3 are exemplified in the above embodiment, more abnormal levels can be provided.

  In the above embodiment, the three fail-safe processes described in FIG. 17 have been exemplified according to the number of abnormal levels, but other fail-safe processes can also be performed, and more can be performed according to the number of abnormal levels. Many failsafe processes can also be provided. In any case, if the abnormal level is high, it is desirable to implement fail-safe processing that is more secure.

  Each of the above configurations, functions, processing units, processing means, etc. may be realized by hardware, for example, by designing part or all of them with an integrated circuit. Further, each configuration, function, etc. described above may be realized by software by the processor interpreting and executing a program that realizes each function. Information such as a program, a table, and a file for realizing each function can be stored in a memory, a hard disk, a recording device such as a solid state drive (SSD), a recording medium such as an IC card, an SD card, or a DVD.

  1: ECU, 2: CPU, 3: memory, 401: software control unit, 402: abnormality management table initialization unit, 403: processing execution unit, 404: 10 ms processing execution unit, 405: 5 ms processing execution unit, 406: abnormality Detection unit 407: Function diagnosis unit 408: System diagnosis unit 409: Abnormal level determination unit 410: FS execution unit 411: Time management unit 510: Time management table 520: Process management table 530: Operation status Management table, 540: Function abnormality management table, 550: System abnormality management table, 560: Judgment result management table.

Claims (7)

A vehicle control device for controlling the operation of a vehicle, wherein
An abnormality detection unit that detects an abnormality in a system unit having a plurality of individual functions,
An abnormal level determination unit that determines an abnormal level of the system unit;
Equipped with
The system unit includes a process execution unit that executes the individual function,
The abnormality detection unit detects the abnormality individually for each of the individual functions,
The abnormality level determination unit determines an abnormality level of the system unit based on an abnormality detection result by the abnormality detection unit for each of the plurality of individual functions.
The abnormality level determination unit may calculate an abnormality count value calculated based on an accumulated number of the abnormalities detected by the abnormality detection unit for each individual function, or the abnormality detected by the abnormality detection unit for each individual function. If the abnormality frequency value calculated based on the frequency per predetermined time exceeds a predetermined frequency threshold, a system abnormality counter indicating an abnormality in the system unit is counted up;
The abnormality level determination unit determines that the abnormality level is the highest when the system abnormality counter exceeds a predetermined system abnormality threshold.
The abnormality detection unit executes the individual function within a predetermined time if the time taken for the process execution unit to execute the individual function exceeds a predetermined execution time threshold. If the number of executions exceeds a predetermined number of executions threshold, the accumulated number or the frequency for the individual function is counted up,
The abnormality detection unit determines that the individual function whose accumulated number or frequency exceeds a predetermined threshold is abnormal.
The vehicle control device according to claim 1, wherein the abnormality level determination unit determines the abnormality level in accordance with the number of the individual functions determined to be abnormal by the abnormality detection unit . The vehicle control device, the response to the cumulative number of abnormality detection section detects the abnormality, stepwise executes abnormality processing of the system unit, e Bei failsafe execution unit,
The vehicle control device according to claim 1, wherein the fail-safe execution unit executes the abnormality processing corresponding to the abnormality level determined by the abnormality level determination unit . The vehicle control device includes a processing management table in which a value defining the safety level required by the individual function is described.
The abnormality detection unit detects the abnormality individually for each of the individual functions,
The abnormality level determination unit determines that the safety level is less than the predetermined level when the abnormality detection unit detects the abnormality for the individual function whose safety level defined by the processing management table is equal to or higher than a predetermined level. The vehicle control device according to claim 1, wherein the abnormality level is determined to be higher than the case where the abnormality detection unit detects the abnormality with respect to the individual function. The process execution unit measures a required time from the start to the completion of the individual function, or the number of times of execution of the individual function within a predetermined time,
The abnormality detection unit may count up the cumulative number or the frequency when the required time exceeds a predetermined execution time threshold or when the number of executions exceeds a predetermined number of executions threshold. the vehicle control apparatus according to claim 1, wherein. The fail-safe execution unit is configured to initialize the system unit by software reset as the abnormality processing when the abnormality level determined by the abnormality level determination unit is equal to or higher than a predetermined high abnormality level. The vehicle control device according to claim 2. Before SL failsafe execution unit, if the abnormal level of the abnormal level determination unit determines is below a predetermined low abnormal level, the as abnormality processing, the individual function which the abnormality detection section detects the abnormality The vehicle control device according to claim 2, wherein the vehicle control device prohibits activation of the vehicle control device. Before Symbol vehicle control apparatus includes a process management table describing values that define the security level of the individual function requests,
The failsafe execution unit defines the processing management table as the abnormality processing when the abnormality level determined by the abnormality level determination unit is less than a predetermined high abnormality level and exceeds a predetermined low abnormality level. The vehicle control device according to claim 2, wherein the activation of all the individual functions whose safety level is lower than a predetermined level is prohibited.

Images