JP2017043166A - Vehicle control device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a vehicle control device that can secure operation continuation property while executing anomaly processing.SOLUTION: The vehicle control device determines an anomaly level of a system depending on a cumulative number or frequency of anomaly and executes various fail-safe processing depending on the anomaly level.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a vehicle control device.

  Many vehicle control systems in recent years are composed of an electronic control unit (ECU) that operates electronic vehicle control equipment and an in-vehicle LAN (Local Area Network) that enables communication between a plurality of ECUs. Has been.

  Vehicle control systems are becoming increasingly sophisticated, distributed, and complicated as the demands on environmental load reduction and safety increase. As a result, the importance of the standardization of the software architecture of the ECU, the electronic control of the safety device, and the safety ensuring mechanism is increasing.

  A car manufacturer prepares a dedicated ECU for each distributed function. Therefore, a plurality of ECUs having different specifications are mixed in one vehicle control system. By introducing a standardized software architecture of the vehicle control device, it becomes easy to construct a vehicle control system by combining ECUs with different specifications.

  In the AUTOSAR architecture described in Non-Patent Document 1 below, software is modularized in units of functions that depend on the microcomputer, algorithm units of sensor and actuator control processing, and units of setting parameters. Therefore, even if the microcomputer is changed in accordance with, for example, the change of the vehicle type, it is possible to cope with the changed specification only by correcting the module that requires 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 the idea of ensuring safety by making the system transition to the safe side when a failure occurs in the electrical / electronic system. For example, in the functional safety standard ISO26262 for automobiles described in Non-Patent Document 2 below, ASIL (Automatic 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 related to the safety of the vehicle control device are clearly separated as the main function / safety device / monitoring device. It has been demanded.

  In ISO 26262, it is required to prevent interference between software having different safety requirements. Since a general vehicle control system is configured by various control applications, a mechanism for preventing an interaction between software constituting the system such as a time protection function and a memory protection function has recently attracted attention. Specifically, when a certain software runs away, the function prevents the runaway software from accessing the memory area where data used by other software is stored and destroying the data. When the AUTOSAR architecture is applied to a general vehicle control apparatus, it is known that various ASIL software are mixed in the vehicle control system. Therefore, in order for existing software to comply with ISO26262, a mechanism for preventing interference between software is required.

  The following Patent Document 1 refers to a configuration that has a diagnostic function for each function, determines its own state, and performs a fail-safe process according to its function when an abnormality is detected. As a result, even if an abnormality occurs in the software, a mechanism for detecting the abnormality and a function for dealing 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 level is mixed, a protection function (time protection, memory protection) for preventing influence from software having a low safety level is required. For example, time protection is applied to a task or interrupt process that is a unit processed by an OS (Operating System), detects that the processing time exceeds the expected (deadline over), and prevents the abnormality from propagating to the entire system. It is a function to make.

  In the conventional vehicle control system 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 fail-safe process. As a result, the control process is interrupted, and the operation of the vehicle control system may at least temporarily stop. When the operation of the vehicle stops (even if it is temporary), the convenience is reduced. 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 above-described problems, and an object of the present invention is to provide a vehicle control device that can ensure operation continuity while performing abnormality processing.

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

  According to the vehicle control device of the present invention, the abnormality process can be executed while ensuring the operation continuity.

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

  FIG. 1 is a configuration diagram of an ECU 1 according to the embodiment of the present invention. The ECU 1 is an apparatus that electronically controls electric devices (for example, the throttle sensor 7 and the actuator 8 shown in FIG. 1) provided in the vehicle. The ECU 1 includes an arithmetic device (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 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 10ms process execution unit 404, a 5ms process execution unit 405, and an abnormality. A detection unit 406, a function diagnosis unit 407, a system diagnosis unit 408, an abnormal 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 a configuration of the time management table 510 and data examples. 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 name of the data item managed by the time management table 510. The threshold value field 512 holds a threshold value for each data item. This field is empty for data items that do not have a threshold. The current value field 513 holds the current value of each data item.

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

  FIG. 3 is a diagram illustrating a configuration of the process management table 520 and data examples. 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 frequency field 526.

  The index field 521 indicates the execution order of 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 executed. The safety level field 524 holds the value of the software safety level assigned to the processing. “1” indicates that the software is ASIL software (software requiring a high safety level), and “0” indicates QM software (low security level required). The execution time field 525 holds a time that is assumed to be required for executing the processing. The execution frequency field 526 holds the number of times that the process is assumed to be executed per unit time.

  FIG. 4 is a diagram illustrating 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 processing managed by the OS. The operation status management table 530 includes an index field 531, a process name field 532, a start permission flag field 533, a start time field 534, an end time field 535, an execution time field 536, and an execution frequency field 537.

  The index field 531 indicates the execution order of processing. The process name field 532 holds a name for specifying the process. The activation permission flag field 533 holds a flag indicating whether the process is permitted to be activated 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 starts and the time when the process ends. The execution time field 536 holds the time actually taken to execute the processing. The execution count field 537 holds the number of times the process is actually executed per unit time.

  FIG. 5 is a diagram illustrating a configuration and data example of the functional abnormality management table 540. The function abnormality management table 540 is a data table for managing an abnormal state of a process managed by the OS. The functional abnormality management table 540 includes a process name field 541, a threshold field 542, and an abnormality 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 that the process is determined to be abnormal. The threshold value field 542 holds a threshold value for determining whether or not the value of the abnormality counter field 543 in FIG. 14 described later is abnormal.

  FIG. 6 is a diagram illustrating a configuration of the system abnormality management table 550 and a data example. The system abnormality management table 550 is a data table for managing a system level abnormal state (abnormality over 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 names of the abnormality parameters 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 the system abnormality level using the abnormality parameter.

  FIG. 7 is a diagram illustrating 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 for initializing 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 processing execution unit 403. This step is for carrying out each control process executed by the ECU 1. 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 abnormality of each control process and abnormality of the system level (abnormality of the ECU 1 as a whole). 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 fail-safe processing for shifting the ECU 1 to the safe state. 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. 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 an instruction to shut down the ECU 1 is given. If the operation is to be terminated, this flowchart is terminated.

  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 (record on the first line in FIG. 2) from the time management table 510 and also acquires the table initialization cycle (record on the second line in FIG. 2). To do. If the remainder obtained by dividing the acquired timer counter by the acquisition period (100 in this example) is 0, the process proceeds to step S402001, and if not, this flowchart is ended.

(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) for each period defined by the time management table 510. It is also conceivable to perform abnormality determination using the cumulative number without initializing the abnormality count. In this case, the system level is regarded as abnormal when the cumulative number reaches a certain level. This is equivalent to performing fail-safe etc. at the time when a serious abnormality at the entire system level is reached ignoring relatively minor abnormality. However, in actual operation, there are often cases where minor errors frequently occur in each functional element provided in the ECU. For example, bit errors in the memory often occur, but the control processing proceeds normally by the error correction function, and this is not regarded as abnormal. Even if it is a small-scale abnormality, depending on the frequency and the number of occurrence places, there is a possibility that the operation of the entire ECU 1 may be seriously affected or approached. Therefore, in the present embodiment, the abnormality count is periodically reset in order to detect even a small-scale instantaneous error that actually occurs even if no system level abnormality is reached. If the abnormal count is not reset at all, or if the reset cycle is set to an extremely long time, it does not differ from counting the cumulative number of times, so the reset cycle is 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 frequency field of the operation status management table 530. 537 (S402003) are respectively 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 (record on the first line in FIG. 2) from the time management table 510. If the remainder obtained by dividing the acquired timer counter by 10 is 0, the process proceeds to step S403001. Otherwise, the process skips to step S403002.

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

(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 acquired timer counter by 5 is 0, the process proceeds to step S403003, and if not, this flowchart ends.

(FIG. 10: Step S403003)
The process execution unit 403 calls the 5 ms process execution unit 405. The 5 ms process execution unit 405 executes a control process to be performed at a cycle of 5 ms. 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 the functions whose execution period 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 point in the flowchart (for example, before S403000).

  FIG. 11 is a flowchart for explaining the operation of the 10 ms processing 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 activation permission flag field 533 of the process from the operation status management table 530. get. If the execution period field 523 is 10 and the activation permission flag field 533 is 1, the process proceeds to step S404001. Otherwise, i is incremented and 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 execution count field 537 of the i-th record in 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 all the processes to be executed at a cycle of 10 ms have been completed. If all the processes are completed, this flowchart is ended. Otherwise, i is incremented, and the process returns to step S404000.

(Figure 11: Supplement)
The 10 ms process execution unit 404 does not have to start the next process after waiting for each process to be completed, and can execute each process in parallel. In that case, steps S404001 to S404004 are 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 for explaining 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 also acquires the diagnosis cycle (record on the third line in FIG. 2). If the remainder obtained by dividing the acquired timer counter by the acquisition period (20 in this example) is 0, the process proceeds to step S406001, and if not, this flowchart is ended.

(FIG. 13: Step S406001)
The abnormality detection unit 406 calls the function diagnosis unit 407. This step is for detecting each functional abnormality. 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 for detecting an abnormality at the system level (the entire ECU 1 level). 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 for determining the abnormal level of the ECU 1. 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. To 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 longer, the process skips to step S407003, and if it is shorter, the process proceeds to step S407002.

(FIG. 14: Step S407002)
The function diagnosis unit 407 acquires the execution count field 537 of the process i from the operation status management table 530 and compares it with the execution count field 526 of the process i stored in the process management table 520. If the execution count 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 in the function abnormality management table 540 by one. When the safety level field 524 of the processing i is “1”, “1” is further stored in the value field 562 of the high priority processing abnormality flag stored in the determination result management table 560.

(FIG. 14: Step S407003: Supplement)
In the present embodiment, as will be described later with reference to FIG. 16, different fail-safe processes are executed according to the abnormality level of the ECU 1 as a whole. Therefore, it is necessary to determine the system abnormality level according to the degree of failure that has occurred. When a function having a high safety level is required to be broken, the degree of the failure is considered to be high. Therefore, for such a function, a flag for managing an abnormal state is specially set and managed.

(FIG. 14: Step S407004)
The function diagnosis unit 407 determines whether diagnosis has been completed for all 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 value field 542 of each record in 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 calculates the average value of the number of functional abnormalities by dividing the total value of the acquired abnormality counters by the total number of processes (for example, the number of records in the functional abnormality management table 540). 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 abnormalities in the system abnormality management table 550.

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

(FIG. 15: Step S408001)
The system diagnosis unit 408 compares the average value calculated in step S408000 and the threshold value field 552 of the average function abnormality count 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 that records the system abnormality counter in the system abnormality management table 550 by one.

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

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

  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 system abnormality flag value field 562 from the determination result management table 560. If the value of the system abnormality flag is “1”, the process proceeds to step S409001, and if it 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 that records the abnormal level in the determination result management table 560.

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

(FIG. 16: Steps S409001 to S409002: Supplement)
The system abnormality flag is a flag that is set when the system abnormality counter is greater than or equal to the threshold value in step S408003. The system abnormality counter is counted up when the average value of the number of functional abnormalities is greater than or equal to a threshold value. That is, since the system abnormality flag indicates that many 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 set to the highest “3” in this flowchart. Further, the high priority process abnormality flag indicates that the process having a high safety requirement is abnormal, so that it is handled in the same manner 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 greater than 2, “2” is stored in the value field 562 of the record that records the abnormal level in 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 number of functional abnormalities is greater than 1, the abnormal level determination unit 409 stores “1” in the value field 562 of the record that records the abnormal level of the determination result management table 560 in step S409006. If the number of functional abnormalities is 1 or less, this flowchart is terminated.

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

  FIG. 17 is a flowchart for explaining 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 the value field 562 of the record that records the abnormal level from the determination result management table 560. If the abnormal level is “3”, the ECU 1 is software reset in step S 40001. Otherwise, the process proceeds to step S410002.

(FIG. 17: Steps S41002 to S410003)
If the abnormal level is “2”, the FS execution unit 410 determines that the safety level field 524 is “0” (that is, the required safety level is low) in step S410003. Is set to “0” (that is, activation is disabled). 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 in which the abnormality counter field 543 exceeds the threshold field 542 to “0” (that is, activation is disabled) in step S410005. ). Otherwise, this flowchart is terminated.

  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 value field 512, the current value of the timer counter is set to 0 in step S411002. Otherwise, this flowchart is terminated.

<Summary of the present invention>
The ECU 1 according to the present embodiment determines a 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 continuity of the operation of the ECU 1 can be improved by executing the fail-safe operation while maintaining as many functions as possible.

  The ECU 1 according to the present embodiment manages the operation status of each function and determines the abnormal level of the entire system based on the operation status. Thereby, before reaching the serious abnormal state which becomes obstacle to operation | movement of ECU1 whole, appropriate fail safe process can be performed and coped with.

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

<Modification of the present invention>
The present invention is not limited to the above-described embodiments, and includes various modifications. For example, the above-described embodiments have been described in detail for easy understanding of the present invention, and are not necessarily limited to those having all the configurations described. Further, a part of the configuration of a certain embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of a certain embodiment. In addition, it is possible to add, delete, and replace other configurations for a part of the configuration of each embodiment.

  In the above embodiment, ECU1 is equipped with the architecture based on ISO26262, However, The object of this invention is not restricted to this, You may provide the other function part. For example, a non-volatile memory (backup RAM) for storing data and a water temperature sensor may be provided. The present invention can also be applied to general control devices that control electric devices provided in a vehicle.

  In the above embodiment, there is only one threshold value. However, for example, a threshold range can be expressed using an upper limit value, a lower limit value, or the like. That is, any type of threshold value can be used as long as abnormality determination can be performed.

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

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

  In the above embodiment, the three fail-safe processes described in FIG. 17 are illustrated according to the number of abnormal levels, but other fail-safe processes can be performed, and more depending on 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 perform fail-safe processing that is more safely defeated.

  Each of the above-described configurations, functions, processing units, processing means, and the like may be realized in hardware by designing a part or all of them, for example, with an integrated circuit. Each of the above-described configurations, functions, and the like may be realized by software by interpreting and executing a program that realizes each function by the processor. Information such as programs, tables, and files for realizing each function can be stored in a recording device such as a memory, a hard disk, an SSD (Solid State Drive), or 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: Anomaly management table initialization unit, 403: Process execution unit, 404: 10 ms process execution unit, 405: 5 ms process execution unit, 406: Abnormal 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: determination result management table.

Claims (10)

A vehicle control device for controlling the operation of a vehicle,
An anomaly detector that detects an anomaly in the system unit having a plurality of individual functions
An abnormal level determination unit for determining an abnormal level of the system unit;
With
The vehicle control apparatus, wherein 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 vehicle control device includes:
The vehicle control device according to claim 1, further comprising a fail-safe execution unit that executes the abnormal-time process of the system unit in a stepwise manner according to the accumulated number of the abnormalities detected by the abnormality detection unit. The system unit includes a process execution unit that executes the individual function,
The abnormality level determination unit determines the abnormality level based on a cumulative number of the abnormality detected by the abnormality detection unit or a frequency per predetermined time of the abnormality detected by the abnormality detection unit,
The vehicle control device according to claim 2, wherein the fail-safe execution unit executes the abnormality process corresponding to the abnormality level determined by the abnormality level determination unit. The vehicle control device includes a process management table that describes a value that defines a safety level required by the individual function,
The abnormality detection unit detects the abnormality individually for each individual function,
When the abnormality detection unit detects the abnormality for the individual function whose safety level defined by the process management table is equal to or higher than a predetermined level, the safety level is less than the predetermined level. The vehicle control device according to claim 1, wherein the abnormality level of the individual function is determined to be higher than when the abnormality detection unit detects the abnormality. The abnormality detection unit detects the abnormality individually for each individual function,
The abnormality level determination unit has an abnormality frequency value calculated based on the cumulative number of times for each individual function or an abnormality frequency value calculated based on the frequency for each of the individual functions exceeding a predetermined frequency threshold value. If so, count up the system abnormality counter indicating the abnormality of the system part,
The vehicle control device according to claim 3, wherein the abnormality level determination unit determines that the abnormality level is highest when the system abnormality counter exceeds a predetermined system abnormality threshold. The process execution unit measures a required time from the start of the individual function to completion, or the number of executions of the individual function within a predetermined time,
The abnormality detection unit counts 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 execution number threshold. 4. The vehicle control device according to claim 3, wherein The abnormality detection unit detects the abnormality individually for each individual function,
The abnormality detection unit executes the individual function when the time required for the process execution unit to execute the individual function exceeds a predetermined execution time threshold or when the process execution unit executes the individual function within a predetermined time. When the number of performed times exceeds a predetermined execution frequency threshold, the cumulative number or the frequency for the individual function is counted up,
The abnormality detection unit determines that the individual function whose cumulative number or frequency exceeds a predetermined threshold is abnormal,
The vehicle control device according to claim 3, wherein the abnormality level determination unit determines the abnormality level according to the number of the individual functions that the abnormality detection unit has determined to be abnormal. The fail safe execution unit, when the abnormal level determined by the abnormal level determination unit is equal to or higher than a predetermined high abnormal level, initializes the system unit by software reset as the abnormal process. The vehicle control device according to claim 2. The abnormality detection unit detects the abnormality individually for each individual function,
When the abnormality level determined by the abnormality level determination unit is equal to or lower than a predetermined low abnormality level, the fail-safe execution unit performs the individual function in which the abnormality detection unit detects the abnormality as the abnormality process. The vehicle control device according to claim 2, wherein starting is prohibited. The abnormality detection unit detects the abnormality individually for each individual function,
The vehicle control device includes a process management table that describes a value that defines a safety level required by the individual function,
When the abnormal level determined by the abnormal level determination unit is less than a predetermined high abnormal level and exceeds a predetermined low abnormal level, the fail safe execution unit defines the processing management table as the abnormal time process. The vehicle control device according to claim 2, wherein activation of all the individual functions whose safety level is equal to or lower than a predetermined level is prohibited.

Images