electronic control device

Abstract

The objective of this invention is to provide a technique that allows the second control software to continue processing using peripheral circuitry even in the event of an anomaly related to the first control software. The electronic control device of this invention includes: a memory (3) storing the first control software and the second control software; a CPU (1) executing the first control software and the second control software; and peripheral circuitry (200) for use by the first control software and the second control software. The memory also includes a first buffer (313a) and a second buffer (323a). In a specific situation where an anomaly related to the first control software occurs, the CPU interrupts at least one of the storage processing of the first peripheral transmission information to the first buffer and the transmission processing of the first peripheral transmission information to a peripheral device.

Description

Technical Field

[0001] This disclosure relates to an electronic control device. Background Technology

[0002] A microcomputer (hereinafter referred to as a "microcomputer") includes a CPU (Central Processing Unit), memory, and peripheral devices. The peripheral devices include one or more peripheral circuits to provide various functions to the microcomputer. Patent Document 1 discloses a device for restarting a peripheral device in the event of an abnormal state.

[0003] Existing technical documents

[0004] Patent documents

[0005] Patent Document 1: Japanese Patent Application Publication No. 2011-138401 Summary of the Invention

[0006] The problem the invention aims to solve

[0007] Microcomputers with multiple control software programs have long been known to exist. However, due to limitations in size and cost, the number of peripheral circuits that can be integrated into a microcomputer is restricted. Consequently, there are situations where multiple control software programs share a single peripheral circuit.

[0008] Suppose that an anomaly occurs in one of the multiple control software programs (hereinafter referred to as "first control software") in the above configuration. Even in this situation, the other of the multiple control software programs (hereinafter referred to as "second control software") is required to use the external circuitry to continue processing. The device described in Patent Document 1 restarts the external circuitry. In this configuration, the second control software cannot use the external circuitry until the restart of the external circuitry is complete. Therefore, there is a problem that the second control software cannot continue processing.

[0009] Therefore, this disclosure provides a technique that allows the second control software to continue processing using external circuitry even in the event of an anomaly related to the first control software.

[0010] Technical means to solve the problem

[0011] In one or more embodiments, an electronic control device is provided. The electronic control device includes: a memory storing first control software and second control software; a CPU executing the first control software and the second control software; and peripheral circuitry used by the first control software and the second control software. The memory also includes a first buffer and a second buffer. The CPU is configured to perform the following processes: a first storage process, i.e., storing first peripheral transmission information (transmission information from the first control software to the peripheral circuit) into the first buffer; a second storage process, i.e., storing second peripheral transmission information (transmission information from the second control software to the peripheral circuit) into the second buffer; a first output process, i.e., outputting the first peripheral transmission information from the first buffer to the peripheral circuit; and a second output process, i.e., outputting the second peripheral transmission information from the second buffer to the peripheral circuit. The CPU is configured to, in the event of a specific condition related to an exception of the first control software, interrupt at least one of the first storage process and the first output process and continue the second storage process and the second output process.

[0012] The effects of the invention

[0013] Based on the above configuration, the electronic control device can continue processing related to the second control software (second storage processing and second output processing) even in specific situations where an anomaly related to the first control software occurs. Further features of the present invention will become clear from the description and accompanying drawings. Furthermore, issues, configurations, and effects other than those described above will be clarified through the following description of embodiments. Attached Figure Description

[0014] Figure 1 A diagram illustrating the hardware configuration of an electronic control device.

[0015] Figure 2 A diagram illustrating an example of software stored in memory.

[0016] Figure 3 This is an example of the configuration information related to the first accessible area in the first MPU.

[0017] Figure 4 This is an example of configuration information related to the second accessible area in the second MPU.

[0018] Figure 5 A diagram illustrating the connection relationship between the electronic control device and external equipment.

[0019] Figure 6 This diagram illustrates the operation of the CAN driver and the CAN controller.

[0020] Figure 7 A diagram illustrating an example of the input / output relationships between multiple software programs.

[0021] Figure 8 This is a flowchart illustrating the process of the first control software sending first peripheral transmission information.

[0022] Figure 9 A diagram illustrating an example of the data structure of the first buffer.

[0023] Figure 10 A diagram illustrating an example of the data structure for the second buffer.

[0024] Figure 11 To maintain the state transition diagram within the control task.

[0025] Figure 12 A diagram illustrating another example of the input / output relationships between multiple software programs.

[0026] Figure 13 A diagram illustrating another example of software stored in memory.

[0027] Figure 14 This is an example of a diagnostic information form.

[0028] Figure 15 This is an example of initializing a policy table.

[0029] Figure 16 This is an example of initializing a range table.

[0030] Figure 17 A diagram illustrating an example of the data structure for the first dummy buffer. Detailed Implementation

[0031] Hereinafter, several embodiments will be described with reference to the accompanying drawings. The drawings illustrate specific embodiments but are not intended to limit the scope of the invention.

[0032] The following embodiments relate to electronic control devices equipped with multiple control software programs. For simplicity, embodiments of electronic control devices equipped with two control software programs (first control software and second control software) will be described. However, the configuration of the electronic control device is not limited to this, and the electronic control device may also be equipped with other control software (e.g., third control software and fourth control software).

[0033] <Example 1>

[0034] (Overall Composition)

[0035] Figure 1This diagram illustrates the hardware configuration of an electronic control device. The electronic control device 1000 includes a microcomputer 900 and a power supply circuit 901. The microcomputer 900 includes a CPU 1, peripheral devices 2, a memory 3, and a bus 4. The CPU 1, peripheral devices 2, and memory 3 are interconnected via the bus 4. Therefore, the CPU 1 can access the peripheral devices 2 and the memory 3 via the bus 4.

[0036] Memory 3 stores multiple software programs. CPU 1 executes the software stored in memory 3.

[0037] The microcomputer 900 also features a self-reset signal output terminal 911 and an external reset terminal 912. The self-reset signal output terminal 911 and the external reset terminal 912 are respectively connected to the power supply circuit 901. The microcomputer 900 outputs a reset request signal to the power supply circuit 901 via the self-reset signal output terminal 911. The power supply circuit 901 inputs an external reset signal to the external reset terminal 912 based on the reset request signal. When the microcomputer 900 receives the external reset signal, the microcomputer 900 is restarted.

[0038] (CPU)

[0039] CPU 1 has multiple cores. Specifically, CPU 1 has a main CPU core 100, a first CPU core 101, and a second CPU core 102.

[0040] The first CPU core 101 includes a first MPU (Memory Protection Unit) 101a. The first MPU 101a contains configuration information related to the region of memory 3 that the first CPU core 101 can access (hereinafter referred to as the "first accessible region"). The first MPU 101a permits the first CPU core 101 to access the first accessible region. The first MPU 101a prohibits the first CPU core 101 from accessing regions other than the first accessible region.

[0041] The second CPU core 102 includes a second MPU 102a. The second MPU 102a contains configuration information related to the regions of memory 3 that the second CPU core 102 can access (hereinafter referred to as "second accessible regions"). The second MPU 102a permits the second CPU core 102 to access the second accessible regions. The second MPU 102a prohibits the second CPU core 102 from accessing regions outside the second accessible regions.

[0042] Main CPU core 100 executes main OS (Operating System) 301 (reference) Figure 2 The first CPU core 101 executes the first control software 310 (see reference). Figure 2The second CPU core 102 executes the second control software 320 (see reference). Figure 2 Related processing.

[0043] CPU 1 is not limited to the above configuration. CPU 1 may also have four or more CPU cores. For example, CPU 1 may also have multiple first CPU cores 101. In this case, each of the multiple first CPU cores 101 includes a first MPU 101a. For example, CPU 1 may also have multiple second CPU cores 102. In this case, each of the multiple second CPU cores 102 includes a second MPU 102a.

[0044] (Peripheral equipment)

[0045] Peripheral device 2 has multiple peripheral circuits. Peripheral circuits refer to circuits other than the CPU 1 and memory 3, which are components of the microcomputer 900. Examples of peripheral circuits include CAN (Controller Area Network) controllers, analog-to-digital converters (A / D converters), direct memory access controllers, and GPIO (General Purpose Input / Output).

[0046] In this example, peripheral device 2 includes a common peripheral circuit 200, a first peripheral circuit 201, and a second peripheral circuit 202. The common peripheral circuit 200 includes a CAN controller 200a. The first peripheral circuit 201 includes a first GPIO pin 201a for analog applications. The second peripheral circuit 202 includes a second GPIO pin 202a for digital applications.

[0047] The shared peripheral circuit 200 is used by both the first control software 310 (i.e., the first CPU core 101) and the second control software 320 (i.e., the second CPU core 102). Furthermore, the shared peripheral circuit 200 is also accessed from the main CPU core 100.

[0048] The first peripheral circuit 201 is a peripheral circuit used only by the first control software 310 (i.e., the first CPU core 101). The second peripheral circuit 202 is a peripheral circuit used only by the second control software 320 (i.e., the second CPU core 102).

[0049] (software)

[0050] Figure 2 This diagram illustrates the software stored in memory 3. Memory 3 stores multiple software programs. Memory 3 stores control task 300, main OS 301, and CAN driver 302. The main CPU core 100 executes these software programs 300 to 302.

[0051] The software executed by the main CPU core 100 will be described below. In the following description, software 300 to 302 will be referred to as the subject. However, the main entity executing software 300 to 302 is the main CPU core 100, so the subject can also be replaced by the main CPU core 100.

[0052] The main OS 301 initializes the CAN driver 302. The CAN driver 302 is the software corresponding to the common peripheral circuit 200, which outputs action commands to the CAN controller 200a.

[0053] Then, the main OS 301 starts the first sub-OS 311 and the second sub-OS 321. That is, the main OS 301 sends the boot command of the first sub-OS 311 to the first CPU core 101 and the boot command of the second sub-OS 321 to the second CPU core 102.

[0054] Therefore, the main OS 301 starts the control task 300 at a 1ms cycle. In this example, the execution cycle of the control task 300 is 1ms, but it is not limited to this. The detailed processing of the control task 300 will be described later.

[0055] The memory 3 also stores the first control software 310, the first sub-OS 311, the first GPIO pin driver 312, and the first hypothetical CAN driver 313. The first CPU core 101 executes these software programs 310 to 313.

[0056] The software executed by the first CPU core 101 will be described below. In the following description, software 310 to 313 will be referred to as the subject. However, the entity executing software 310 to 313 is the first CPU core 101, so the subject can also be replaced with the first CPU core 101.

[0057] The first sub-OS 311 initializes the first GPIO pin driver 312 according to the startup command from the main OS 301. The first GPIO pin driver 312 is software that outputs action commands to the first GPIO pin 201a.

[0058] The first sub-OS 311 starts the first control software 310 according to the startup command from the main OS 301. The first control software 310 contains more than one task. The tasks of the first control software 310 are executed by the first sub-OS 311 at specified times. In this example, the first control software 310 sends the first peripheral transmission information at the specified time. The first peripheral transmission information is information sent to the CAN controller 200a.

[0059] Then, the first sub-OS 311 initializes the first hypothetical CAN driver 313 according to the boot command from the main OS 301. The first hypothetical CAN driver 313 is software located between the first control software 310 and the CAN driver 302, and is software that processes the first peripheral transmission information. Specifically, the first hypothetical CAN driver 313 includes a first buffer 313a. The first hypothetical CAN driver 313 stores the first peripheral transmission information in the first buffer 313a.

[0060] The memory 3 also stores the second control software 320, the second sub-OS 321, the second GPIO pin driver 322, and the second hypothetical CAN driver 323. The second CPU core 102 executes these software programs 320 to 323.

[0061] The software executed by the second CPU core 102 will be described below. In the following description, software 320 to 323 will be referred to as the subject. However, since the entity executing software 320 to 323 is the second CPU core 102, the subject can also be replaced with the second CPU core 102.

[0062] The second sub-OS 321 initializes the second GPIO pin driver 322 according to the startup command from the main OS 301. The second GPIO pin driver 322 is software that outputs action commands to the second GPIO pin 202a.

[0063] The second sub-OS 321 starts the second control software 320 according to the startup command from the main OS 301. The second control software 320 contains more than one task. The tasks of the second control software 320 are executed by the second sub-OS 321 at specified times. In this example, the second control software 320 sends second peripheral transmission information at specified times. The second peripheral transmission information is information sent to the CAN controller 200a.

[0064] Then, the second sub-OS 321 initializes the second hypothetical CAN driver 323 according to the boot command from the main OS 301. The second hypothetical CAN driver 323 is software located between the second control software 320 and the CAN driver 302, and is software that processes second peripheral transmission information. Specifically, the second hypothetical CAN driver 323 includes a second buffer 323a. The second hypothetical CAN driver 323 stores the second peripheral transmission information in the second buffer 323a.

[0065] (Settings in the first MPU)

[0066] Figure 3This diagram illustrates the configuration information related to the first accessible area in the first MPU 101a. The first CPU core 101 has read and write rights to the storage areas of software 310-313. The first CPU core 101 does not have read or write rights to areas outside the storage areas of software 310-313. Therefore, it is possible to prevent the first control software 310 (i.e., the first CPU core 101) from affecting the main OS 301 and the second control software 320.

[0067] (Settings in the second MPU)

[0068] Figure 4 This diagram illustrates the configuration information related to the second accessible area in the second MPU 102a. The second CPU core 102 has read and write rights to the storage areas of software 320-323. The second CPU core 102 does not have read or write rights to areas outside the storage areas of software 320-323. Therefore, it is possible to prevent the second control software 320 (i.e., the second CPU core 102) from affecting the main OS 301 and the first control software 310.

[0069] Furthermore, the main CPU core 100 can access all areas of memory 3.

[0070] (Connection to external control devices constitutes the connection)

[0071] Figure 5 This diagram illustrates the connection relationship between the electronic control device 1000 and external devices. The processing functions of the first control software 310 and the second control software 320 will be explained below.

[0072] First control software

[0073] Multiple sensors 511 and multiple actuators 512 are configured outside the electronic control device 1000. The multiple sensors 511 and multiple actuators 512 are respectively connected to the first GPIO pin 201a.

[0074] The first control software 310 accesses the first GPIO pin 201a to input analog signals to each of the plurality of actuators 512. Furthermore, the first control software 310 receives analog signals from each of the plurality of sensors 511 via the first GPIO pin 201a. The first control software 310 then sends first peripheral transmission information based on these analog signals.

[0075] In this example, the first peripheral transmission information is a CAN message sent from the first control software 310 to each of the other electronic control devices 540. Furthermore, the first peripheral transmission information is output to the CAN controller 200a via the first buffer 313a, as described later. The CAN controller 200a receives the first peripheral transmission information. The CAN controller 200a converts the first peripheral transmission information into a physical signal and transmits the physical signal to the other electronic control devices 540 via the CAN bus 530.

[0076] Second control software

[0077] Multiple sensors 521 and multiple actuators 522 are configured externally to the electronic control device 1000. The multiple sensors 521 and multiple actuators 522 are respectively connected to the second GPIO pin 202a.

[0078] The second control software 320 accesses the second GPIO pin 202a to input digital signals to each of the plurality of actuators 522. Furthermore, the second control software 320 receives digital signals from each of the plurality of sensors 521 via the second GPIO pin 202a. The second control software 320 then sends second peripheral transmission information based on these digital signals.

[0079] In this example, the second peripheral transmission information is a CAN message sent from the second control software 320 to each of the other electronic control devices 540. Furthermore, the second peripheral transmission information is output to the CAN controller 200a via the second buffer 323a, as described later. The CAN controller 200a receives the second peripheral transmission information. The CAN controller 200a converts the second peripheral transmission information into a physical signal and transmits this physical signal to the other electronic control devices 540 via the CAN bus 530.

[0080] (Operation of CAN driver and CAN controller)

[0081] Figure 6 This diagram illustrates the general operation of the CAN driver 302 and the CAN controller 200a. The following describes the process of the first control software 310 sending the first peripheral transmission information. The CAN driver 302 stores the first peripheral transmission information in a designated location in the internal register 200b of the CAN controller 200a. The CAN controller 200a stores the first peripheral transmission information into a CAN frame 600 according to the specified CAN protocol. Subsequently, the CAN controller 200a converts the CAN frame 600 into a physical signal and sends it to the CAN bus 530.

[0082] Furthermore, when the second control software 320 sends second peripheral transmission information, the CAN driver 302 and the CAN controller 200a also perform the same actions as described above.

[0083] (Software actions)

[0084] Figure 7 This diagram illustrates the input / output relationships between multiple software programs. In this example, two hypothetical CAN drivers (i.e., a first hypothetical CAN driver 313 and a second hypothetical CAN driver 323) exist before the CAN driver 302. The first control software 310 and the second control software 320 use the first hypothetical CAN driver 313 and the second hypothetical CAN driver 323, respectively. The control task 300 alternately accesses the first hypothetical CAN driver 313 and the second hypothetical CAN driver 323, alternately outputting the first peripheral transmission information 710 and the second peripheral transmission information 720 to the CAN driver 302. Thus, a single CAN driver 302 can be used while separating the processing of the first control software 310 from the processing of the second control software 320.

[0085] Specifically, the first control software 310 sends the first peripheral transmission information 710 to the first hypothetical CAN driver 313. The first hypothetical CAN driver 313 stores the first peripheral transmission information 710 in the first buffer 313a.

[0086] The second control software 320 sends the second peripheral transmission information 720 to the second hypothetical CAN driver 323. The second hypothetical CAN driver 323 stores the second peripheral transmission information 720 in the second buffer 323a.

[0087] Control task 300 retrieves the first peripheral transmission information 710 from the first buffer 313a and outputs the first peripheral transmission information 710 to the CAN driver 302.

[0088] Control task 300 retrieves the second peripheral transmission information 720 from the second buffer 323a and outputs the second peripheral transmission information 720 to the CAN driver 302.

[0089] Below, on Figure 7 The specific processing methods of the various software programs shown are explained.

[0090] First control software

[0091] Figure 8This diagram illustrates the processing flow when the first control software 310 sends the first peripheral transmission information 710. The first control software 310 specifies the CAN message ID and data as the first peripheral transmission information 710. The first control software 310 calls CAN_send_virtio1(ID,data). CAN_send_virtio1(ID,data) is the command to send the first peripheral transmission information 710 to the first hypothetical CAN driver 313. The first peripheral transmission information 710 contains the CAN message ID 711 and data 712.

[0092] First hypothetical CAN driver

[0093] When the first control software 310 calls CAN_send_virtio1(ID,data), the first hypothetical CAN driver 313 receives the first peripheral transmission information 710. The first hypothetical CAN driver 313 stores the first peripheral transmission information 710 into the first buffer 313a.

[0094] Second control software

[0095] The process of the second control software 320 sending the second peripheral transmission information 720 is the same. The second control software 320 specifies the CAN message ID and data as the second peripheral transmission information 720. The second control software 320 calls CAN_send_virtio2(ID,data). CAN_send_virtio2(ID,data) is the command to send the second peripheral transmission information 720 to the second imaginary CAN driver 323. For example... Figure 7 As shown, the second peripheral transmission information 720 includes CAN message ID 721 and data 722.

[0096] Second hypothetical CAN driver

[0097] When the second control software 320 calls CAN_send_virtio2(ID,data), the second hypothetical CAN driver 323 receives the second peripheral transmission information 720. The second hypothetical CAN driver 323 stores the second peripheral transmission information 720 into the second buffer 323a.

[0098] First buffer

[0099] Figure 9The diagram shows the data structure of the first buffer 313a. The first buffer 313a has a circular buffer structure, which is one of the implementation methods of the First-In-First-Out queue. Each element of the first buffer 313a is a structure composed of CAN message ID and data. The entity of the circular buffer is a structure array buffer_virtio1

[12] . Furthermore, for ease of explanation, the number of elements in the array is set to 12 here, but it is not limited to this.

[0100] When the first control software 310 calls CAN_send_virtio1(ID,data), the first hypothetical CAN driver 313 calculates the index backward (backward ← (backward + 1) % 12) representing the end position of the buffer as follows. Here, "%" is the operator for finding the remainder when (backward + 1) is divided by 12. Furthermore, if the index backward is at the end of the array (backward = 11), the first hypothetical CAN driver 313 substitutes "0" into backward. The first hypothetical CAN driver 313 stores the first peripheral transmission information 710 into buffer_virtio1[backward]. Thus, the first hypothetical CAN driver 313 stores the first peripheral transmission information 710 at the very end of the first buffer 313a. Hereinafter, this storage process of the first peripheral transmission information 710 will be referred to as the "first storage process".

[0101] Second buffer

[0102] Figure 10 The diagram shows the data structure of the second buffer 323a. The second buffer 323a has a circular buffer structure, which is one of the implementation methods of the First-In-First-Out queue. Each element of the second buffer 323a is a structure composed of CAN message ID and data. The entity of the circular buffer is a structure array buffer_virtio2

[12] . Furthermore, for ease of explanation, the number of elements in the array is set to 12 here, but it is not limited to this.

[0103] When the second control software 320 calls CAN_send_virtio2(ID,data), the second hypothetical CAN driver 323 calculates the index backward (backward ← (backward + 1) % 12) representing the end position of the buffer as follows. Furthermore, if the index backward is at the end of the array (backward = 11), the second hypothetical CAN driver 323 substitutes "0" into backward. The second hypothetical CAN driver 323 stores the second peripheral transmission information 720 into buffer_virtio2[backward]. Thus, the second hypothetical CAN driver 323 stores the second peripheral transmission information 720 at the very end of the second buffer 323a. Hereinafter, this storage process of the second peripheral transmission information 720 will be referred to as the "second storage process".

[0104] • Control task

[0105] Control task 300 retrieves the first peripheral transmission information 710 from the first buffer 313a. For example... Figure 9 As shown, control task 300 extracts the data buffer_virtio1[forward] contained in the index forward, which represents the position of the buffer head, as the first peripheral transmission information 710. Then, control task 300 performs an operation on the index forward as follows (forward ← (forward + 1) % 12). Furthermore, if the index forward is at the end of the array (forward = 11), control task 300 substitutes "0" into the index forward. Control task 300 outputs the first peripheral transmission information 710 to the CAN driver 302. Hereinafter, this output processing of the first peripheral transmission information 710 will be referred to as "first output processing".

[0106] Control task 300 retrieves the second peripheral transmission information 720 from the second buffer 323a. For example... Figure 10 As shown, control task 300 extracts the data buffer_virtio2[forward] contained in the index forward, which represents the position of the buffer head, as the second peripheral transmission information 720. Then, control task 300 performs an operation on the index forward as follows (forward ← (forward + 1) % 12). Furthermore, if the index forward is at the end of the array (forward = 11), control task 300 substitutes "0" into the index forward. Control task 300 outputs the second peripheral transmission information 720 to the CAN driver 302. Hereinafter, this output processing of the second peripheral transmission information 720 will be referred to as "second output processing".

[0107] Figure 11 To maintain the state transition diagram within control task 300. As mentioned above, control task 300 is a task started by the main OS 301 with a 1ms cycle. Control task 300 alternately executes the first output processing and the second output processing.

[0108] For example, assume that control task 300 is now in the first state St1. In this case, control task 300 performs the first output processing.

[0109] After executing the first output processing, control task 300 determines whether the second buffer 323a is empty. If the second buffer 323a is not empty, control task 300 transitions from the first state St1 to the second state St2. On the other hand, if the second buffer 323a is empty and the first buffer 323a is not empty (i.e., only the second buffer 323a is empty), control task 300 maintains the first state St1. In this case, control task 300 repeats the first output processing.

[0110] Furthermore, if both the first buffer 313a and the second buffer 323a are empty after the control task 300 performs the first output processing, the control task 300 transitions from the first state St1 to the third state St3. In this case, the control task 300 does nothing. Subsequently, if the first buffer 313a is not empty (that is, if the first peripheral transmission information 710 is stored in the first buffer 313a), the control task 300 transitions from the third state St3 to the first state St1. Alternatively, if the second buffer 323a is not empty (that is, if the second peripheral transmission information 720 is stored in the second buffer 323a), the control task 300 transitions from the third state St3 to the second state St2.

[0111] Assume that control task 300 has transitioned from state 1 to state 2. In this case, control task 300 performs the second output processing.

[0112] After executing the second output processing, control task 300 determines whether the first buffer 313a is empty. If the first buffer 313a is not empty, control task 300 transitions from the second state St2 to the first state St1. On the other hand, if the first buffer 313a is empty and the second buffer 313a is not empty (i.e., only the first buffer 313a is empty), control task 300 maintains the second state St2. In this case, control task 300 repeats the second output processing.

[0113] Furthermore, if both the first buffer 313a and the second buffer 323a are empty after the control task 300 performs the second output processing, the control task 300 transitions from the first state St1 to the third state St3. In this case, the control task 300 performs no action. Subsequently, if the first buffer 313a is not empty (i.e., the first peripheral transmission information 710 is stored in the first buffer 313a), the control task 300 transitions from the third state St3 to the first state St1. Alternatively, if the second buffer 323a is not empty (i.e., the second peripheral transmission information 720 is stored in the second buffer 323a), the control task 300 transitions from the third state St3 to the second state St2.

[0114] (Features of this embodiment)

[0115] In the electronic control device 1000, malfunctions related to the first control software 310 may occur. Hereinafter, such situations will be referred to as "specific situations". Specific situations include, for example, situations where the first control software 310 malfunctions, as well as situations where software and hardware related to the first control software 310 malfunction.

[0116] In this example, a specific situation means that at least one of the following situations (1) to (3) has occurred.

[0117] (1) The first control software 310 performs processing other than normal processing (so-called exception processing). Here, normal processing is the transmission processing of the first peripheral transmission information 710. Exception processing includes, for example, access outside the first accessible area (out-of-area access) and processing related to missed deadlines.

[0118] (2) The software related to the first control software 310 (e.g., the first GPIO pin driver 312) has malfunctioned.

[0119] (3) An abnormality has occurred in the hardware related to the first control software 310. Such hardware may include (a) the CPU 1 and memory 3, (b) the sensor 511 and actuator 522 connected to the first GPIO pin 201a, and (c) the common peripheral circuit 200, which is the transmission target of the first peripheral transmission information 710.

[0120] Under specific conditions, the first control software 310 sends a first interrupt instruction to the first hypothetical CAN driver 313. The first interrupt instruction includes an instruction to interrupt the first storage process and an instruction to initialize the first buffer 313a. The first hypothetical CAN driver 313 interrupts (disables) the first storage process according to the first interrupt instruction. Furthermore, the first hypothetical CAN driver 313 initializes the first buffer 313a according to the first interrupt instruction (that is, sets the first buffer 313a to empty). The first hypothetical CAN driver 313 can initialize the first buffer 313a by substituting the index `backward` representing the end position of the buffer into the index `forward` representing the head position of the buffer.

[0121] Thus, the first hypothetical CAN driver 313 interrupts the first memory processing and initializes the first buffer 313a according to the first interrupt instruction. Since the first buffer 313a becomes empty, the control task 300 maintains the second state St2 (see reference). Figure 11 In other words, control task 300 interrupts the first output processing. On the other hand, control task 300 continues the second storage processing and the second output processing.

[0122] According to this embodiment, two hypothetical CAN drivers 313 and 323 exist in the front stage of the CAN driver 302. The first control software 310 and the second control software 320 use the first hypothetical CAN driver 313 and the second hypothetical CAN driver 323, respectively. The control task 300 alternately accesses the first hypothetical CAN driver 313 and the second hypothetical CAN driver 323 to alternately output the first peripheral transmission information 710 and the second peripheral transmission information 720 to the CAN driver 302. In this way, the processing of the first control software 310 and the processing of the second control software 320 are separated. Therefore, even in the event of a specific situation where an abnormality related to the first control software 310 occurs, the second control software 320 can continue the second storage processing and the second output processing. That is, the second control software 320 can continue to send the second peripheral transmission information 720 to the CAN controller 200a.

[0123] Furthermore, under certain circumstances, inappropriate first peripheral transmission information 710 may be output to the CAN driver 302. Since the first hypothetical CAN driver 313 initializes the first buffer 313a, such problems can be prevented from occurring.

[0124] In this example, the first CPU core 101 executes the processing related to the first control software 310, and the second CPU core 102 executes the processing related to the second control software 320. Therefore, the two CPU cores 101 and 102 can continue processing independently of each other. This prevents processing executed by one CPU core from affecting processing executed by the other CPU core.

[0125] Furthermore, the same procedure is performed in the event of an exception related to the second control software 320. The second control software 320 sends a second interrupt instruction to the second hypothetical CAN driver 323. The second interrupt instruction contains instructions to interrupt the second storage process and to initialize the second buffer 323a. The second hypothetical CAN driver 323 interrupts (disables) the second storage process according to the second interrupt instruction. Then, the second hypothetical CAN driver 323 initializes the second buffer 323a. The second hypothetical CAN driver 323 can initialize the second buffer 323a by substituting the index backward, representing the end position of the buffer, into the index forward, representing the head position of the buffer.

[0126] <Example 2>

[0127] The configuration of the electronic control device 1000 in Embodiment 2 will be described below. The description will focus on the differences from Embodiment 1. Figure 12 This is a diagram illustrating the input / output relationships between multiple software programs in this example. Control task 300 is configured to perform all processes, including first storage processing, second storage processing, first output processing, and second output processing.

[0128] Control task 300 receives first peripheral transmission information 710 from first control software 310 and performs first storage processing. Subsequently, control task 300 receives second peripheral transmission information 720 from second control software 320 and performs second storage processing.

[0129] Control Task 300 according to Figure 11 The state transition diagram is used to perform the first output processing and the second output processing.

[0130] Under specific conditions, the first control software 310 sends a third interrupt instruction to the control task 300. The third interrupt instruction contains only an instruction to interrupt the first storage process. The control task 300 interrupts the first storage process according to the third interrupt instruction. The control task 300 continues the first output process until the first buffer 313a becomes empty. When the first buffer 313a becomes empty, the control task 300 interrupts the first output process. On the other hand, the control task 300 continues the second storage process and the second output process.

[0131] Based on the above configuration, even under specific circumstances, the second control software 320 can continue the second storage processing and the second output processing.

[0132] In another example, the third interrupt instruction contains only an instruction to interrupt the first output processing. Control task 300 interrupts the first output processing according to the third interrupt instruction. Control task 300 may also continue only the first storage processing. Control task 300 may also continue the first storage processing until all elements of the array in the first buffer 313a are filled. When all elements of the array in the first buffer 313a are filled, control task 300 interrupts the first storage processing. On the other hand, control task 300 continues the second storage processing and the second output processing.

[0133] In another example, control task 300 may also interrupt both the first storage processing and the first output processing under certain circumstances. Thus, the first peripheral transmission information 710 within the first buffer 313a can be retained.

[0134] <Example 3>

[0135] The configuration of the electronic control device 1000 in Embodiment 3 will be described below. The description will focus on the differences from Embodiment 1. Figure 13 As shown, in this example, memory 3 also stores initialization task 304 and diagnostic task 305. The main CPU core 100 also executes these software programs 304 and 305. The same symbols are used for components identical to those in Embodiment 1, and their descriptions are omitted.

[0136] The main OS 301 initializes the CAN driver 302. The main OS 301 starts the control task 300 and the initialization task 304 with a 1ms cycle. In this example, the execution cycle of the control task 300 and the initialization task 304 is 1ms, but it is not limited to this.

[0137] Then, the main OS 301 starts the diagnostic task 305 with a period of 10ms. In this example, the execution period of the diagnostic task 305 is 10ms, but it is not limited to this.

[0138] (Diagnostic Information Form)

[0139] Figure 14 An example of a diagnostic information table 1400 generated for diagnostic task 305. Diagnostic information table 1400 contains diagnostic object 1401 and status 1402 as constituent items. Diagnostic object 1401 is the hardware or software that becomes the object of diagnosis. Status 1402 is information indicating whether diagnostic object 1401 is in a normal or abnormal state.

[0140] Diagnostic task 305 monitors each diagnostic object 1401 in the diagnostic information table 1400 at a period of 10ms to ensure they are functioning normally. Based on this, diagnostic task 305 updates the status 1402 of the diagnostic information table 1400.

[0141] For example, diagnostic task 305 verifies whether the hardware of the electronic control unit 1000 is functioning correctly. This hardware includes the main CPU core 100, the first CPU core 101, the second CPU core 102, the CAN controller 200a, the first GPIO pin 201a, and the second GPIO pin 202a.

[0142] Furthermore, diagnostic task 305 confirms whether no memory errors have occurred in the first accessible region (the region of memory 3 accessible by the first CPU core 101) and the second accessible region (the region of memory 3 accessible by the second CPU core 102). Memory errors can be detected by methods such as parity checking and CRC (Cyclic Redundancy Check), or by other methods.

[0143] Diagnostic task 305 verifies whether the first control software 310 is operating normally. Diagnostic task 305 can determine that the first control software 310 has malfunctioned if it is performing exception handling. Furthermore, diagnostic task 305 verifies whether the second control software 320 is operating normally.

[0144] If the diagnostic object 1401 is determined to be operating normally, the diagnostic task 305 sets the corresponding state 1402 to "normal". If the diagnostic object 1401 is determined to be abnormal, the diagnostic task 305 sets the corresponding state 1402 to "abnormal". Thus, the initialization task 304 can confirm whether each diagnostic object 1401 is operating normally by referring to the diagnostic information table 1400.

[0145] Furthermore, the diagnostic information table 1400 is not limited to the examples described above. Diagnostic task 305 can also confirm whether the first sub-OS 311 and the second sub-OS 321 are operating normally.

[0146] Figure 15 An example of the initialization strategy table 1500 maintained for initialization task 304. Initialization strategy table 1500 contains the object 1501 that encountered an exception and initialization strategy 1502 as constituent items. Initialization strategy 1502 indicates which initialization process to perform. In this example, the initialization processes include overall initialization, first initialization, and second initialization.

[0147] Initialization task 304 determines whether diagnostic object 1401 has encountered an anomaly by referring to diagnostic information table 1400. If diagnostic object 1401 has encountered an anomaly, initialization task 304 obtains the initialization strategy 1502 corresponding to the diagnostic object (i.e., the object 1501 that encountered the anomaly) by referring to initialization strategy table 1500. Initialization task 304 then performs initialization processing according to the obtained initialization strategy 1502.

[0148] In the event of an anomaly in the main CPU core 100, initialization task 304 performs overall initialization processing. Furthermore, in the event of an anomaly in the CAN controller 200a, initialization task 304 performs overall initialization processing.

[0149] On the other hand, if an anomaly occurs in the "hardware and software 1510 related to the first CPU core 101", the initialization task 304 performs the first initialization process.

[0150] Furthermore, if an anomaly occurs in the "hardware and software 1520 related to the second CPU core 102", the initialization task 304 performs the second initialization process.

[0151] Figure 16 An example of the initialization range table 1600 maintained for initialization task 304. Initialization range table 1600 indicates which hardware and software each initialization process initializes.

[0152] The overall initialization process initializes all hardware and software. Initialization task 304 performs the overall initialization process as follows: Initialization task 304 outputs a reset request signal to power circuit 901 via self-reset signal output terminal 911. Power circuit 901 inputs an external reset signal to external reset terminal 912 based on the reset request signal. When microcomputer 900 receives the external reset signal, microcomputer 900 is restarted. Thus, all hardware and software on microcomputer 900 are initialized.

[0153] The first initialization process initializes the hardware and software related to the first CPU core 101. The initialization task 304 performs the first initialization process as follows: The initialization task 304 restarts the first CPU core 101. Then, the initialization task 304 restarts the first sub-OS 311. Subsequently, the initialization task 304 sends a specified startup command to the first sub-OS 311. The first sub-OS 311 initializes the first GPIO pin driver 312 according to the startup command from the initialization task 304. Then, the first sub-OS 311 initializes the first hypothetical CAN driver 313. As a result, the first buffer 313a becomes empty. Then, the first sub-OS 311 restarts the first control software 310. Then, the first sub-OS 311 initializes the first accessible area.

[0154] The second initialization process initializes the hardware and software related to the second CPU core 102. The initialization task 304 performs the second initialization process as follows: The initialization task 304 restarts the second CPU core 102. Then, the initialization task 304 restarts the second sub-OS 321. Subsequently, the initialization task 304 sends a specified startup command to the second sub-OS 321. The second sub-OS 321 initializes the second GPIO pin driver 322 according to the startup command from the initialization task 304. Then, the second sub-OS 321 initializes the second hypothetical CAN driver 323. As a result, the second buffer 323a becomes empty. Then, the second sub-OS 321 restarts the second control software 320. Then, the second sub-OS 321 initializes the second accessible area.

[0155] As described above, initialization task 304 changes the hardware and software to be initialized based on the hardware and software that has encountered an exception. For example, in the hardware and software 1510 related to the first CPU core 101 (see reference...) Figure 15 In the event of an anomaly, initialization task 304 performs a first initialization process. Initialization task 304 may initialize only the hardware and software 1510 related to the first CPU core 101. During the execution of the first initialization process, the first storage process and the first output process are interrupted. On the other hand, during the execution of the first initialization process, the second hypothetical CAN driver 323 continues the second storage process, and the control task 300 continues the second output process. Therefore, the second control software 320 can continue sending the second peripheral transmission information 720 to the CAN controller 200a.

[0156] Hardware and software related to the second CPU core 102 1520 (reference) Figure 15In the event of an anomaly, initialization task 304 performs a second initialization process. Initialization task 304 may initialize only the hardware and software 1520 related to the second CPU core 102. During the execution of the second initialization process, the second storage process and the second output process are interrupted. On the other hand, during the execution of the second initialization process, the first hypothetical CAN driver 313 continues the first storage process, and the control task 300 continues the first output process. Therefore, the first control software 310 can continue sending the first peripheral transmission information 710 to the CAN controller 200a.

[0157] <Example 4>

[0158] The configuration of the electronic control device 1000 in Embodiment 4 will be described below. The description will focus on the differences from Embodiment 3. The memory 3 includes a region for managing a first initialization processing flag and a region for managing a second initialization processing flag.

[0159] The first initialization processing flag is managed within the first accessible area. The first initialization processing flag takes the value either True or False. During the period when the first initialization process is executed, the first initialization processing flag is set to True. During the period when the first initialization process is not executed, the first initialization processing flag is set to False.

[0160] When the first initialization process flag is set to False, the first hypothetical CAN driver 313 performs the first storage process, and the control task 300 performs the first output process. The initialization task 304 sets the first initialization process flag to True when it begins the first initialization process. Therefore, the first hypothetical CAN driver 313 interrupts the first storage process, and the control task 300 interrupts the first output process. When the first initialization process is complete, the initialization task 304 sets the first initialization process flag to False. Therefore, the first hypothetical CAN driver 313 resumes the first storage process, and the control task 300 resumes the first output process. Based on the above configuration, the first storage process and the first output process can be resumed upon completion of the first initialization process.

[0161] The second initialization processing flag is managed within the second accessible area. The second initialization processing flag takes the value either True or False. During the period when the second initialization process is executed, the second initialization processing flag is True. During the period when the second initialization process is not executed, the second initialization processing flag is False.

[0162] When the second initialization process flag is set to False, the second hypothetical CAN driver 323 performs the second storage process, and the control task 300 performs the second output process. The initialization task 304 sets the second initialization process flag to True when the second initialization process begins. Therefore, the second hypothetical CAN driver 323 interrupts the second storage process, and the control task 300 interrupts the second output process. When the second initialization process is complete, the initialization task 304 sets the second initialization process flag to False. Therefore, the second hypothetical CAN driver 323 resumes the second storage process, and the control task 300 resumes the second output process. Based on the above configuration, the second storage process and the second output process can be resumed upon completion of the second initialization process.

[0163] This example can also be applied to Embodiment 1. For instance, the first hypothetical CAN driver 313 sets the first initialization process flag to True when initializing the first buffer 313a. The first hypothetical CAN driver 313 interrupts the first storage process, and the control task 300 interrupts the first output process. The first hypothetical CAN driver 313 sets the first initialization process flag to False when the initialization of the first buffer 313a is complete. Therefore, the first hypothetical CAN driver 313 resumes the first storage process, and the control task 300 resumes the first output process.

[0164] <Example 5>

[0165] The configuration of the electronic control device 1000 in Embodiment 5 will be described below. The description will focus on the differences from Embodiment 1. In this example, the memory 3 further includes a first dummy buffer. Figure 17 A diagram illustrating the data structure of the first dummy buffer 313b. The first dummy buffer 313b has a circular buffer structure, which is one of the implementation methods of the First-In-First-Out queue. Each element of the first dummy buffer 313b is a wait process for a specified time tm (so-called wait processing). The entity of the circular buffer is a structure array dummy_buffer_virtio1

[12] . Furthermore, for ease of explanation, the number of elements in the array is set to 12 here, but it is not limited to this.

[0166] The aforementioned time tm is the average processing time from the moment the first control software 310 calls CAN_send_virtio1(ID,data) until the moment the CAN driver 302 stores the first peripheral transmission information 710 in the internal register 200b of the CAN controller 200a. In other words, time tm is the average time it takes for the first peripheral transmission information 710 to travel from the first control software 310 to the CAN controller 200a. Given that the average processing time is 50ms, the wait time tm is set to 50ms.

[0167] Under the aforementioned specific conditions, the first control software 310 sends a first interrupt command to the first hypothetical CAN driver 313. The first hypothetical CAN driver 313 interrupts the first storage process according to the first interrupt command. The first hypothetical CAN driver 313 initializes the first buffer 313a.

[0168] Here, the first hypothetical CAN driver 313 obtains the number of first peripheral transmission messages 710 stored in the first buffer 313a before initializing the first buffer 313a. That is, the first hypothetical CAN driver 313 obtains the number of elements in the array storing the first peripheral transmission messages 710 in the first buffer 313a. For example, assume that 7 out of 12 elements store the first peripheral transmission messages 710. In this case, the first hypothetical CAN driver 313 stores the same number of wait processes in the first dummy buffer 313b.

[0169] The first hypothetical CAN driver 313 stores 7 wait transactions into the first dummy buffer 313b. For example... Figure 17 As shown, the first hypothetical CAN driver 313 performs wait processing on each of the storage locations dummy_buffer_virtio1[0] to dummy_buffer_virtio1[6]. Furthermore, the first hypothetical CAN driver 313 substitutes “0” for the forward index of the buffer front end and “6” for the backward index of the buffer back end.

[0170] Under certain conditions, control task 300 retrieves data from the first dummy buffer 313b instead of the first buffer 313a. Specifically, control task 300 retrieves the data contained in the index `forward` representing the buffer head position of the first dummy buffer 313b (i.e., wait processing) and performs wait processing. Then, control task 300 performs the operation `forward(forward←(forward+1)%12)` on the index. Additionally, if the index `forward` is at the end of the array (`forward=11`), control task 300 substitutes "0" into the index `forward`. Next, control task 300 performs the second output processing.

[0171] Thus, control task 300 alternately retrieves data from the first dummy buffer 313b and the second buffer 323a. That is, control task 300 alternately executes wait processing (50ms standby processing) and second output processing.

[0172] Furthermore, the first hypothetical CAN driver 313 can also store wait processing data to the first virtual buffer 313b at a predetermined first cycle under specific conditions. Thus, the first hypothetical CAN driver 313 simulates the moment when the first control software 310 calls CAN_send_virtio1(ID,data). The first cycle for the first hypothetical CAN driver 313 to store wait processing data is the average value of the time intervals between calls to CAN_send_virtio1(ID,data) by the first control software 310. Moreover, the first cycle is not limited to a fixed period; it can also be a value calculated using the average value of the aforementioned time intervals as a parameter according to a Poisson probability process.

[0173] Control task 300 typically executes the first output processing and the second output processing alternately. Therefore, control task 300 essentially executes the second output processing at regular intervals. In contrast, in embodiment 1, control task 300 executes the second output processing continuously without executing the first output processing (see reference). Figure 11 Therefore, the execution cycle of the second output processing is extremely short. In this example, because control task 300 alternates between wait processing and the second output processing, the execution cycle of the second output processing is kept within a certain period.

[0174] <Example 6>

[0175] The configuration of the electronic control device 1000 in Embodiment 6 will be described. In this example, the first control software 310 is software that controls the engine in a hybrid electric vehicle (hereinafter referred to as "HEV"). For example, the first control software 310 is software used by the engine to generate torque. The first control software 310 sends information related to the target torque value to be generated by the engine (such as the intake valve opening, fuel injection quantity, and ignition timing) as first peripheral transmission information 710.

[0176] The second control software 320 is software that controls multiple power sources (engine and inverter-motor) in the HEV. The second control software 320 sends information related to the target torque values ​​that should be generated by the engine and inverter-motor respectively as second peripheral transmission information 720.

[0177] HEVs use the engine as a power source for generating electricity and the motor as a power source for driving. In this example, the software for engine control and the software for HEV control are integrated into a single microcomputer 900. Therefore, cost reduction is achieved.

[0178] <Example 7>

[0179] The configuration of the electronic control device 1000 in Example 7 will be described. In this example, the first control software 310 is QM (Quality Management) software that complies with the functional safety standard ISO 26262. The second control software 320 is ASIL (Automotive Safety Integrity Level)-C software.

[0180] Therefore, the safety standards required by the second control software 320 are higher than those required by the first control software 310. Even in the event of an anomaly related to the first control software 310, the second control software 320, with its higher safety standards, can continue sending the second peripheral transmission information 720 to the CAN controller 200a. Anomalies related to the first control software 310 do not affect the second control software 320, thus enabling the electronic control device 1000 to implement the FFI (Freedom From Interference) function.

[0181] <Example 8>

[0182] The configuration of the electronic control device 1000 in Embodiment 8 will be described. It can also be configured such that, under certain circumstances, the second control software 320, in addition to performing normal processing (the transmission processing of the second peripheral transmission information 720), also performs a portion of the processing of the first control software 310. According to the above configuration, even under certain circumstances, the electronic control device 1000 can maintain the processing of both the first control software 310 and the second control software 320.

[0183] For example, the first control software 310, as described above, is software that controls the engine. The second control software 320, as described above, is software that controls multiple power sources (engine and inverter-motor) in the HEV. In this case, the second control software 320 may also, under certain circumstances, execute a portion of the processing of the first control software 310 (outputting information related to the target torque value to be generated by the engine).

[0184] <Example 9>

[0185] The configuration of the electronic control device 1000 in Embodiment 9 will be described. Under certain circumstances, the second control software 320 may also reduce its own functionality. For example, the second control software 320 may change the content of the data in the second peripheral transmission information 720 or change the execution speed of the normal processing (the transmission processing of the second peripheral transmission information 720). Based on the above configuration, the second control software 320 can increase the likelihood of continuing processing.

[0186] For example, the first control software 310 controls the engine, and the second control software 320 controls multiple power sources (engine and inverter-motor) in the HEV. In this configuration, the second control software 320 can change the target value of the torque generated by the inverter-motor to a relatively small value under certain conditions, so that the vehicle runs with minimal torque (i.e., performs fail-safe driving). According to this configuration, a vehicle that has malfunctioned can be moved to a safe location.

[0187] The embodiments of the present invention have been described in detail above, but the present invention is not limited to the described embodiments, and various design changes can be made without departing from the spirit of the invention as set forth in the claims. For example, the described embodiments are detailed descriptions made to illustrate the present invention in an easily understandable manner, and are not necessarily limited to having all the described configurations. Furthermore, a part of the configuration of one embodiment can be replaced with the configuration of another embodiment, and the configuration of one embodiment can be added to the configuration of another embodiment. Moreover, other configurations can be added, deleted, or replaced in a part of the configuration of each embodiment.

[0188] Symbol Explanation

[0189] 1000… Electronic control device

[0190] 1…CPU

[0191] 2…peripheral equipment

[0192] 3… Memory

[0193] 4…bus

[0194] 300… Control Task

[0195] 301…Main OS

[0196] 302…CAN driver

[0197] 310…First Control Software

[0198] 311…First Sub-OS

[0199] 312…First GPIO pin driver

[0200] 313…First hypothetical CAN driver

[0201] 313a…First Buffer

[0202] 320…Second Control Software

[0203] 321…Second Sub-OS

[0204] 322…Second GPIO pin driver

[0205] 323…Second Hypothetical CAN Driver

[0206] 323a…Second buffer.

Claims

1. A vehicle control device, characterized in that, have: A memory that stores the first control software and the second control software; CPU, which executes the first control software and the second control software; and The peripheral circuitry is used by both the first and second control software. The memory also includes a first buffer and a second buffer. The CPU is configured to perform the following processes: The first storage process stores the transmission information from the first control software to the peripheral circuit, i.e., the first peripheral transmission information, into the first buffer. The second storage process stores the transmission information from the second control software to the peripheral circuit, i.e., the second peripheral transmission information, into the second buffer. The first output processing outputs the first peripheral transmission information from the first buffer to the peripheral circuit. as well as The second output processing involves outputting the second peripheral transmission information from the second buffer to the peripheral circuit. The CPU is configured to, in the event of a specific condition related to the first control software exception, interrupt at least one of the first storage processing and the first output processing and continue the second storage processing and the second output processing.

2. The vehicle control device according to claim 1, characterized in that, The CPU is configured to perform a first initialization process that initializes the first buffer under the specific conditions.

3. The vehicle control device according to claim 2, characterized in that, The CPU is configured to initialize the software and hardware related to the first control software during the first initialization process.

4. The vehicle control device according to claim 2, characterized in that, The CPU is configured to resume the first storage processing and the first output processing after the first initialization processing is completed.

5. The vehicle control device according to claim 1, characterized in that, The memory also includes a first dummy buffer. The first dummy buffer includes standby processing for a specified period of time. The CPU is configured to alternately execute the standby processing and the second output processing under the specific conditions.

6. The vehicle control device according to claim 5, characterized in that, The specified time is the average time it takes for the first peripheral information to travel from the first control software to the peripheral circuit.

7. The vehicle control device according to claim 1, characterized in that, The safety standards required by the second control software are higher than those required by the first control software.

8. The vehicle control device according to claim 1, characterized in that, The second control software is configured to be part of the processing of the first control software under the specific conditions.

9. The vehicle control device according to claim 1, characterized in that, The first control software is software that controls the engine in a hybrid electric vehicle. The second control software is software that controls the engine and motor in the hybrid electric vehicle.

10. The vehicle control device according to claim 1, characterized in that, The specific situation includes at least one of the following: The first control software performs exceptional processing beyond the normal processing; The software related to the first control software malfunctioned; and The hardware associated with the first control software malfunctioned.

11. The vehicle control device according to claim 1, characterized in that, The CPU includes at least a first CPU core and a second CPU core. The first CPU core is configured to execute the first control software. The second CPU core is configured to execute the second control software.

Images