Vehicle-mounted system and control device

Abstract

The present disclosure relates to an in-vehicle system and control devices. A plurality of control devices includes a master control device and a slave control device. When software stored in a storage area different from a startup storage area is updated in the slave control device, the master control device transmits a switching instruction to the slave control device to set the storage area in which the updated software is stored as the startup storage area. The slave control device is configured to implement the setting of the startup storage area at the next startup when the switching instruction is received, and to request the master control device to execute a matching determination process every time the startup is performed, the matching determination process being used to determine whether identification information of the software stored in the startup storage area matches among the plurality of control devices. Upon receiving the request from the slave control device, the master control device executes the matching determination process.

Description

Technical Field

[0001] This disclosure relates to vehicle-mounted systems and control devices. Background Technology

[0002] Vehicles are equipped with in-vehicle systems consisting of multiple actuators and multiple control devices that control each of them. The functions of these multiple control devices are sometimes implemented in software. Because they are implemented in software, even after a vehicle enters the market, functions can be modified or added by receiving updates. Furthermore, for modifications or additions to functions such as autonomous driving and other driver assistance systems that involve cooperation between multiple control devices, it is necessary to request software updates for all the control devices that are targeted, and to request confirmation that updates have been appropriately implemented for each control device.

[0003] For example, Japanese Patent Application Publication No. 2020-123253 discloses a technology that compares identification information of a list stored in the storage section of each ECU with the identification information of the software recorded in the list when the vehicle system is started, and uses the combination of identification information of the software recorded in the list to determine whether the combination of the software of the multiple ECUs matches.

[0004] In order to switch from the previous software across multiple ECUs, the updated software is sometimes executed during the next startup of the vehicle system. In this case, verification of whether the software update was appropriate is also performed during the next startup of the vehicle system.

[0005] However, if only some control devices restart due to adverse conditions such as a momentary power outage before the next startup of the vehicle system, only the updated software will be executed in the restarted part of the control devices. The mismatch in the combination of identification information of the software in the multiple control devices will continue at least until the next startup of the vehicle system, resulting in the inability to properly implement functional corrections or additions. Summary of the Invention

[0006] This disclosure provides an in-vehicle system and control device for detecting mismatches in combinations of software identification information as early as possible among multiple control devices.

[0007] The vehicle system disclosed in the first aspect includes multiple control devices. Each of these multiple control devices is configured to designate any one of multiple storage areas (which serve as storage areas for stored software) as a startup storage area, and to start the system using software stored in the startup storage area. The multiple control devices include a master control device and a slave control device. The master control device is configured to send a switching instruction to the slave control device, setting the storage area where the updated software is stored as the startup storage area, when software stored in a storage area different from the startup storage area is updated in the slave control device. The slave control device is configured to, upon receiving the switching instruction, implement the setting of the startup storage area at the next startup, and request the execution of a matching determination process from the master control device each time a startup occurs. This matching determination process determines whether the identification information of the software stored in the startup storage area matches among the multiple control devices. The master control device is configured to execute the matching determination process when the slave control device receives a request to execute the matching determination process.

[0008] In this way, whenever the control device starts, it requests the execution of the matching determination process from the main control device, and the main control device executes the matching determination process. Therefore, even if the storage area for the updated software is set as the startup storage area on the next startup, even if the system restarts only from the control device due to malfunctions, it requests the execution of the matching determination process from the main control device upon restart. As a result, mismatches in the combination of software identification information can be detected as early as possible by multiple control devices.

[0009] Based on the first form described above, the main control device can also be configured to prohibit the execution of functions implemented by the software when it is determined that the identification information of the software stored in the startup storage area does not match among multiple control devices.

[0010] In this way, it is possible to suppress the execution of software-implemented functions in multiple control devices when the combination of software identification information does not match.

[0011] Based on the first embodiment described above, the master control device can also be configured to send a completion notification to the slave control device after the matching determination process is completed. The slave control device can also be configured to use the completion notification to decide whether to request the execution of the matching determination process.

[0012] Thus, for example, in the case where there are requests to execute multiple matching determination processes for the main control device, it is possible to suppress the unnecessary execution of matching determination processes.

[0013] Based on the first form described above, the control device can also be configured to: request the main control device to determine whether the execution of the matching determination process is possible upon startup, and use the execution possibility determination result and completion notification from the main control device to decide whether to request the execution of the matching determination process.

[0014] In this way, by determining whether the request can be executed before the execution of the request matching decision process, the execution of unnecessary request matching decision processes can be suppressed.

[0015] Alternatively, based on the first configuration described above, the control device may include a first control device and a second control device. The main control device may also be configured such that, upon receiving an execution permission request from the first control device, if no permission request from the second control device has been received prior to the permission request from the first control device, it sends a permission result to the first control device indicating that the matching permission process can be performed.

[0016] In this way, the main control device can perform the matching determination process according to the request from the first control device by sending a determination result indicating that the matching determination process can be performed to the first control device that received the determination request before the second control device.

[0017] Based on the first configuration described above, the main control device can also be configured such that when it requests a decision on whether or not to perform the decision from the first control device and then requests a decision on whether or not to perform the decision from the second control device, it is prohibited to send the decision result to the second control device.

[0018] In this way, the execution of the matching determination process requested by both the first control device and the second control device can be suppressed.

[0019] Based on the first configuration described above, the master control device may also be configured to send a first completion notification of the matching determination process executed at startup and a second completion notification of the matching determination process executed after the slave control device requests the execution of the matching determination process. The slave control device may also be configured to: stop the request to execute the matching determination process when it receives the first completion notification and when it receives the second completion notification, and request the execution of the matching determination process when it does not receive the first completion notification.

[0020] This can suppress the unnecessary request for matching determination processing from the control device.

[0021] The control device according to the second aspect of this disclosure is any one of a plurality of control devices that sets any one of a plurality of storage areas, which are designated as storage areas for stored software, as a boot storage area and can be started using software stored in the boot storage area. The control device includes one or more processors configured to: when software stored in a storage area different from the boot storage area is updated in another control device, send a switching instruction to the other control device to set the storage area where the updated software is stored as the boot storage area; whenever another control device starts, receive a request to execute a matching determination process to determine whether the identification information of the software stored in the boot storage area matches among the plurality of control devices; and execute the matching determination process when receiving the request to execute the matching determination process from another control device. The other control devices are configured to: if a switching instruction is received, implement the setting of the boot storage area on the next startup.

[0022] The control device involved in the third aspect of this disclosure is any one of a plurality of control devices that sets any one of a plurality of storage areas, which stores software, as a boot storage area and can be started using software stored in the boot storage area. The control device includes one or more processors configured to: upon receiving a switching instruction to set the storage area where the updated software is stored as the boot storage area after updating software stored in a storage area different from the boot storage area, implement the setting of the boot storage area at the next startup; and request the execution of a matching determination process from any one of the plurality of control devices at each startup, wherein the matching determination process determines whether the identification information of the software stored in the boot storage area matches among the plurality of control devices. When the main control device receives the request to execute the matching determination process from the control device, the main control device executes the matching determination process.

[0023] According to various forms of this disclosure, a mismatched vehicle system and control device are provided that can detect combinations of software identification information as early as possible in multiple control devices.

[0024] The features, advantages, and technical and industrial significance of exemplary embodiments of the present invention will now be described with reference to the accompanying drawings, in which the same reference numerals denote the same elements. Attached Figure Description

[0025] Figure 1 This is a diagram used to illustrate an example of the structure of a communication system.

[0026] Figure 2This is a diagram that briefly illustrates an example of the structure of the electric vehicle in this embodiment.

[0027] Figure 3 This diagram is used to illustrate an example of the actions performed by the master ECU and the slave ECU.

[0028] Figure 4 This diagram illustrates an example of the action taken when the combination of product numbers executed in the master ECU and slave ECU becomes mismatched.

[0029] Figure 5 This is a flowchart illustrating an example of a process performed by the main ECU.

[0030] Figure 6 This is a flowchart representing an example of another process performed by the main ECU.

[0031] Figure 7 This is a flowchart illustrating an example of a process executed by the ECU.

[0032] Figure 8 This diagram is used to illustrate one example of the operation of the master ECU and one example of the operation of the slave ECU.

[0033] Figure 9 This is a diagram that briefly illustrates one example of the structure of an electric vehicle in a variant example.

[0034] Figure 10 This diagram is used to illustrate an example of the actions performed by the main ECU and multiple slave ECUs in a modified example.

[0035] Figure 11 This is a flowchart illustrating an example of the processing performed by the main ECU in a variant example.

[0036] Figure 12 This is a flowchart illustrating an example of another process performed by the main ECU in a variant example.

[0037] Figure 13 This is a flowchart illustrating an example of another process executed by the first slave ECU and the second slave ECU, respectively, in a modified example.

[0038] Figure 14 This diagram is used to illustrate one example of the operation of the main ECU and one example of the operation of each slave ECU in the modified example. Detailed Implementation

[0039] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. Furthermore, identical or equivalent parts will be labeled with the same reference numerals in the drawings, and their descriptions will not be repeated.

[0040] Figure 1 This is a diagram used to illustrate an example of the structure of communication system 1. For example... Figure 1 As shown, the communication system 1 includes a management server 7, a communication network 6, and an electric vehicle 100 capable of communicating with the management server 7 via the communication network 6.

[0041] Management server 7 is, for example, a computer including a CPU (Central Processing Unit), various memory components, and communication interfaces. Management server 7 provides software update information to multiple vehicles and manages the update status of various software stored in multiple vehicles. Figure 1 The image shows an electric vehicle 100 as one of a group of vehicles. The following description will explain the information exchanged between the management server 7 and the electric vehicle 100, but the information exchanged between the management server 7 and other vehicles is the same and will not be described in detail again.

[0042] The management server 7's storage device (not shown) stores, for example, identification information (hereinafter referred to as vehicle ID) as inherent information for identifying the electric vehicle 100. Various software programs stored in the electric vehicle 100 include, for example, control programs stored separately in multiple ECUs (Electronic Control Units) mounted on the electric vehicle 100. The management server 7 manages the identification information, including version information of various software programs, on a per-ECU basis for the electric vehicle 100. As described later, the management server 7's storage device stores, corresponding to the vehicle ID, the version information of the main ECU software and the version information of the slave ECU software included in the electric vehicle 100. The management server 7 manages the software version information using inherent product numbers. When update information is provided to the electric vehicle 100, the management server 7 uses the product number corresponding to the provided update information to manage the update status of various software programs in the electric vehicle 100.

[0043] For example, if a new product number (new version) of software is to be prepared, the management server 7 requests the electric vehicle 100 to update the control program and provides the electric vehicle 100 with the new product number of software according to the request from the electric vehicle 100.

[0044] Next, refer to Figure 2 The specific structure of the electric vehicle 100 in this embodiment will be described below. Figure 2 This is a diagram that briefly illustrates an example of the structure of the electric vehicle 100 in this embodiment. (As shown...) Figure 2As shown, the electric vehicle 100 includes a main ECU 200, a slave ECU 210, a drive unit 220, a DCM (Data Communication Module) 230, an ADS (Autonomous Driving System) 240, and a communication bus 250. The main ECU 200, slave ECU 210, and ADS 240 are communicatively connected via the communication bus 250.

[0045] The main ECU 200 is the ECU that switches the software from the ECU 210 to the updated product number described later, and manages the update status of the software of all ECUs, including itself. The main ECU 200 corresponds to the "main control unit".

[0046] The main ECU 200 includes a CPU 201 and a memory 202. The main ECU 200 may include multiple CPUs 201 and multiple memories 202. The CPUs 201 execute programs stored in the memories 202 to perform various controls on objects controlled by the main ECU 200 (e.g., DCM 230). The memory 202 includes a first storage area 202A and a second storage area 202B. Either the first storage area 202A or the second storage area 202B stores a control program for starting the main ECU 200. The main ECU 200 designates either the first storage area 202A or the second storage area 202B as a startup storage area, and upon startup, executes and starts the control program stored in the designated startup storage area. When receiving update information from the management server 7 via the DCM 230, the main ECU 200 stores a control program updated using the update information in a storage area other than the startup storage area (hereinafter, there may be cases described as update storage areas). When the updated program is stored in the update storage area, the master ECU 200 sets the update storage area as the startup storage area for the next startup, and also instructs the slave ECU 210 (described later) to set the update storage area as the startup storage area for the next startup.

[0047] Therefore, if the electric vehicle 100 is switched back to the IG (power off) state due to a user-performed start-up operation after being disconnected from the IG (power on), the main ECU 200 and the slave ECU 210 execute the updated control program stored in the start-up storage area to start the vehicle. Furthermore, the storage area set as the start-up storage area up to the time of start-up is set as the update storage area. The following refers to the situation where the start-up storage area is changed and reset as a case of switching the start-up storage area.

[0048] The main ECU 200 obtains the product number (hereinafter referred to as the updated product number) of the updated control program stored in the slave ECU 210 from the management server 7 or from the slave ECU 210, and stores it in the memory 202. Furthermore, the main ECU 200 obtains the product number (hereinafter referred to as the executed product number) of the executing control program from the slave ECU 210 as described later, and stores it in the memory 202.

[0049] DCM230 is an on-board communication module configured to wirelessly communicate with management server 7. DCM230 is configured to perform bidirectional data communication with management server 7 based on control signals from main ECU 200. DCM230 is connected to main ECU 200. Main ECU 200 sends information related to electric vehicle 100, various requests, etc., to management server 7 via DCM230, or receives various software update information from management server 7.

[0050] The slave ECU 210 includes a CPU 211 and a memory 212. The slave ECU 210 may include multiple CPUs 211 and multiple memories 212. The slave ECU 210 corresponds to a "slave control device". The CPU 211 executes programs stored in the memory 212 to perform various controls on the controlled object (e.g., drive device 220, etc.) of the slave ECU 210. The memory 212 includes a third storage area 212A and a fourth storage area 212B. Either the third storage area 212A or the fourth storage area 212B stores a control program for starting the slave ECU 210. The slave ECU 210 sets either the third storage area 212A or the fourth storage area 212B as a startup storage area, and during startup, executes the control program stored in the set startup storage area to start the device. When an update is received from the management server 7 via DCM230 and an instruction to switch the startup storage area is received from the master ECU 200, the slave ECU 210 sets the update storage area as the startup storage area for the next startup.

[0051] The drive unit 220 is connected to the slave ECU 210 and performs drive actions to drive the electric vehicle 100 according to control signals from the slave ECU 210. The drive unit 220 includes, for example, a motor-generator, an energy storage device, and a PCU (Power Control Unit) (none shown). The energy storage device includes, for example, a secondary battery such as a nickel-metal hydride battery, a lithium-ion battery with a liquid or solid electrolyte, or a DC power source such as a capacitor. The PCU converts the DC power from the energy storage device into AC power to supply the motor-generator, or converts the AC power generated by the motor-generator into DC power to supply the energy storage device. The motor-generator is the drive source and generator of the electric vehicle 100, driving the drive wheels to rotate or generating electricity through the rotation of the drive wheels. Alternatively, the drive unit 220 may also include an internal combustion engine as a drive source or generator.

[0052] The ADS240 is configured to implement autonomous driving of the electric vehicle 100. Specifically, the ADS240 obtains information representing the state of the electric vehicle 100 (surrounding environment) from the main ECU 200, slave ECU 210, and various sensors, and uses the obtained information, destination, etc., to formulate a driving plan. Based on the formulated driving plan, the ADS240 outputs various control requests to the main ECU 200 and slave ECU 210, which control various actuators including the drive unit 220, to enable the electric vehicle 100 to move.

[0053] Furthermore, in this embodiment, the case where ADS240 is built into the electric vehicle 100 is described. However, for example, ADS240 may also be composed of an autonomous driving kit, which can be installed in a predetermined position such as the roof of the electric vehicle 100 and can be removed from the electric vehicle 100.

[0054] In the electric vehicle 100, driving is performed using either an automatic driving mode capable of implementing automatic driving based on control requests from the ADS 240, or a manual driving mode capable of performing driving actions corresponding to various user-operated actions (accelerator operation, brake operation, steering operation). Furthermore, as described above, as an example, the case where the main ECU 200 controls the DCM 230 and the slave ECU 210 controls the drive unit 220 has been explained; however, other actuators mounted in the electric vehicle 100 are controlled by at least one of the main ECU 200 and the slave ECU 210.

[0055] In the electric vehicle 100 with the above-described structure, the respective functions of the main ECU 200 and the slave ECU 210 are implemented by executing software as described above. Furthermore, by updating the software stored in the main ECU 200 and the slave ECU 210 respectively using update information received from the management server 7, existing functions can be corrected and new functions can be added. In order to properly execute the functions based on these updated software, the main ECU 200, for example, performs a matching determination process (hereinafter referred to as a version matching check (VMC)) after the IG is turned on, to confirm whether the combination of the execution product numbers of the software executed in the main ECU 200 and the slave ECU 210 matches.

[0056] For example, if the combination of execution product numbers in the master ECU 200 and slave ECU 210 is a predetermined combination, the master ECU 200 determines that the combination of execution product numbers matches. Predetermined combinations include, for example, combinations of product numbers before and after the update. For example, if the combination of execution product numbers matches the combination of updated product numbers, the master ECU 200 can confirm that a switch to the startup storage area has been appropriately performed.

[0057] Figure 3 This diagram illustrates an example of the actions performed in the main ECU 200 and the slave ECU 210. Figure 3 The text represents the operation history of the master ECU 200 and slave ECU 210.

[0058] For example, if the user performs the startup operation of the system used to start the electric vehicle 100, then as follows Figure 3 As shown in (A), the electric vehicle 100 is switched to the IG-on state. When the electric vehicle 100 is switched to the IG-on state, power is supplied to the main ECU 200 and the slave ECU 210 respectively, thereby starting the main ECU 200 and the slave ECU 210.

[0059] At this time, for example, such as Figure 3 As shown in (B), it is assumed that the ECU 210 sends the execution product number to the main ECU 200 after startup. For example, the ECU 210 sends the product number of the software stored in the startup storage area as the execution product number to the main ECU 200 after startup. Furthermore, the method for obtaining the product number of the software stored in the startup storage area can use known techniques, and its details will not be described.

[0060] like Figure 3As shown in (C), after the electric vehicle 100 enters the IG-on state, the main ECU 200 executes the VMC by initially receiving the execution product number from the slave ECU 210. Thus, the main ECU 200 can determine whether the combination of execution product numbers matches based on whether the combination of the first execution product number of the software being executed in the main ECU 200 and the second execution product number of the software being executed in the slave ECU 210 is a predetermined combination.

[0061] The main ECU 200 can obtain, for example, configuration information about a pre-determined combination from the management server 7, or it can use the updated information received from the management server 7 to obtain the combination of product numbers before and after the update as configuration information.

[0062] However, if the main ECU 200 instructs the slave ECU 210 to switch the startup storage area at the next startup, and the electric vehicle 100 restarts due to some adverse situation such as a momentary disconnection of the power supply to the slave ECU 210 during the period from when the main ECU 200 instructs the slave ECU 210 to switch the startup storage area at the next startup, there is a possibility that the startup storage area is switched only by the slave ECU 210.

[0063] For example, such as Figure 3 As shown in (D), when the ECU210 is reset due to some malfunction, as Figure 3 As shown in (E), ECU210 will restart. At this time, as... Figure 3 As shown in (F), even if an execution product number is sent to the main ECU 200, the VMC is not executed in the main ECU 200. Therefore, until the next startup of the main ECU 200, the execution product number of the main ECU 200 is the product number before the update, and the execution product number of the slave ECU 210 is the updated product number, thus creating a period in which the combination of execution product numbers in the main ECU 200 and the slave ECU 210 becomes mismatched.

[0064] Figure 4 This diagram illustrates an example of the action taken when the combination of product numbers executed in the main ECU 200 and the slave ECU 210 becomes mismatched. (See diagram for example.) Figure 4 As shown, the main ECU 200 includes a control unit 201A and a switching unit 201B. When updated software is stored in the update storage area, such as... Figure 4 As shown in (A), the control unit 201A sends a switching instruction to the switching unit 201B within the slave ECU 210 and the master ECU 200. If the switching unit 201B and the slave ECU 210 receive the switching instruction from the control unit 201A, then... Figure 4As shown in (B) and (C), the switching process for the boot storage area is performed respectively, and the update storage area is set for the next boot (and...). Figure 4 The (G) indicates the startup storage area corresponding to the IG being turned on.

[0065] However, subsequently, as Figure 4 As shown in (D), if the power supply from ECU 210 is interrupted at the moment of power generation, only ECU 210 will restart. As a result, ECU 210 starts using updated software, thus transforming into an electric vehicle 100. Figure 4 The period before the IG disconnection state shown in (F) occurs is the period during which the execution product number of the main ECU 200 is the product number of the software before the update, and the execution product number of the sub-ECU 210 is the product number of the software after the update, thus creating a period during which the combination of execution product numbers becomes mismatched.

[0066] Therefore, in this embodiment, when the slave ECU 210 starts up, it requests the master ECU 200 to execute a matching determination process. This matching determination process is used to determine whether the identification information (i.e., the execution product number) of the software stored in the startup storage area matches between the master ECU 200 and the slave ECU 210. The master ECU 200 executes the matching determination process (VMC) when it starts up and when the slave ECU 210 receives the request to execute the matching determination process.

[0067] In this way, when the slave ECU 210 starts up, it requests the execution of a matching determination process from the master ECU 200, and the master ECU 200 performs the matching determination process. Therefore, when the update storage area is set as the startup storage area for the next startup, even if only the ECU 210 restarts due to adverse conditions, the execution of the matching determination process is requested from the master ECU 200 upon restart. As a result, it is possible for the master ECU 200 and slave ECU 210 to detect mismatches in the combination of execution product numbers as early as possible.

[0068] The following is a reference. Figure 5 An example of the processing performed by the main ECU 200 will be explained below. Figure 5 This is a flowchart illustrating an example of a process performed by the main ECU 200. The flowchart shows a series of processes that are repeatedly executed by the main ECU 200 at a predetermined processing cycle.

[0069] In step (hereinafter referred to as S) 100, the main ECU 200 determines whether an initial check has not been performed. The main ECU 200 determines whether an initial check has not been performed, for example, based on the state of a flag indicating whether an initial check has been performed. For example, if the flag is in the off state, the main ECU 200 determines that an initial check has not been performed. The main ECU 200 may set the flag to the off state immediately after startup, or it may set the flag to the off state when the electric vehicle 100 changes to the IG off state. If it is determined that an initial check has not been performed (yes in S100), the main ECU 200 moves the processing to S102.

[0070] In S102, the main ECU 200 determines whether all execution product numbers have been obtained. For example, if the first execution product number and the second execution product number have been obtained, the main ECU 200 determines that all execution product numbers have been obtained. The main ECU 200, for example, obtains the product number of the software stored in the boot storage area of ​​the memory 202 as the first execution product number. The main ECU 200, for example, obtains the second execution product number from the slave ECU 210. If the main ECU 200 determines that all execution product numbers have been obtained (yes in S102), the process proceeds to S104.

[0071] In S104, the main ECU 200 performs a matching determination process. The main ECU 200 determines whether the combination of the first execution product number and the second execution product number is a predetermined combination. For example, the main ECU 200 compares the combination of the first execution product number and the second execution product number with the predetermined combinations stored in the memory 202 to determine whether they match. The method for obtaining the predetermined combinations is as described above, so its detailed description will not be repeated. The process then proceeds to S108. Furthermore, if the main ECU 200 determines that not all execution product numbers have been obtained (which was not the case in S102), the process proceeds to S106.

[0072] In S106, the main ECU 200 determines whether the waiting time for receiving the product number is longer than a predetermined time T1. The waiting time is, for example, the elapsed time from the moment it is determined that the initial check has not been performed. The predetermined time T1 is adjusted, for example, through experimentation. If the main ECU 200 determines that the waiting time for receiving the product number is longer than the predetermined time T1 (yes in S106), the process moves to S116. Furthermore, if the main ECU 200 determines that the waiting time for receiving the product number is less than or equal to the predetermined time T1 (no in S106), the process returns to S102.

[0073] In S108, the main ECU 200 determines whether the first execution product number and the second execution product number match. For example, if the combination of the first execution product number and the second execution product number is a predetermined combination such as the combination of the product numbers of the software before the update or the combination of the product numbers of the software after the update, the main ECU 200 determines that the first execution product number and the second execution product number match. If the main ECU 200 determines that the first execution product number and the second execution product number match (yes in S108), the process moves to S110. Furthermore, if the main ECU 200 determines that the first execution product number and the second execution product number do not match (no in S108), the process moves to S116.

[0074] In S110, the master ECU 200 sends a message to the slave ECU 210 indicating that the matching determination process has been completed (hereinafter referred to as a completion notification). Afterwards, the process proceeds to S112.

[0075] In S112, the main ECU 200 sets the status of the flag indicating whether the initial check has been performed to the on state. Then, the process moves to S114.

[0076] In S114, the main ECU 200 sets the autonomous driving mode to the permitted state. With the autonomous driving mode set to the permitted state, autonomous driving of the electric vehicle 100 using ADS 240 can be implemented. Therefore, in the electric vehicle 100, when the autonomous driving mode is selected, autonomous driving using ADS 240 is implemented.

[0077] In S116, the main ECU 200 sets autonomous driving to a prohibited state. When autonomous driving is prohibited, if the autonomous driving mode is selected, it switches to manual driving mode. Furthermore, even if the user attempts to select autonomous driving mode while in manual driving mode, the selection of autonomous driving mode is rejected.

[0078] Next, refer to Figure 6 An example of another process performed by the main ECU 200 will be described below. Figure 6 This is a flowchart illustrating an example of another process performed by the main ECU 200. The series of processes shown in this flowchart are repeatedly executed by the main ECU 200 at a predetermined processing cycle.

[0079] In S150, the main ECU 200 determines whether an initial check has been performed. The method for determining whether an initial check has been performed is as described above, and therefore its detailed explanation will not be repeated. If the main ECU 200 determines that an initial check has been performed (yes in S150), the process proceeds to S152.

[0080] In S152, the master ECU 200 determines whether it has received a VMC request from the slave ECU 210. A "VMC request" includes an execution request for the matching determination process. If the master ECU 200 determines that a VMC request has been received from the slave ECU 210 (yes in S152), the process proceeds to S154. Conversely, if the master ECU 200 determines that a VMC request has not been received (no in S152), the process returns to S152.

[0081] In S154, the main ECU 200 performs a matching determination process. The matching determination process is as described above, so its detailed explanation will not be repeated. Afterwards, the process moves to S156.

[0082] In S156, the main ECU 200 determines whether the first execution product number and the second execution product number match. The determination method is as described above, therefore, its detailed explanation will not be repeated. If the main ECU 200 determines that the first execution product number and the second execution product number match (yes in S156), the process proceeds to S158.

[0083] In S158, the master ECU 200 sends a completion notification to the slave ECU 210. As described above, the completion notification will not be repeated in detail.

[0084] In S160, the main ECU 200 sets the autonomous driving mode to the permitted state. The actions of the electric vehicle 100 in the permitted autonomous driving state are as described above, and therefore their detailed explanation will not be repeated. Afterwards, the process returns to S152. Furthermore, if the main ECU 200 determines that the first execution product number and the second execution product number do not match (not the case in S156), the process moves to S162.

[0085] In S162, the main ECU 200 sets the autonomous driving mode to a prohibited state. The actions of the electric vehicle 100 in the prohibited autonomous driving state are as described above, and therefore their detailed explanation will not be repeated. Afterwards, the process ends. Furthermore, if the main ECU 200 determines that the initial check has not been completed (not in S150), the process ends.

[0086] Next, refer to Figure 7 An example of the processing performed by ECU210 will be explained below. Figure 7 This is a flowchart illustrating an example of a process executed by ECU 210. The flowchart shows a series of processes that are repeatedly executed by ECU 210 at a predetermined processing cycle.

[0087] In S200, it is determined from ECU210 whether it is a startup time. For example, if a startup process for starting ECU210 is being executed, ECU210 determines that it is a startup time. If ECU210 determines that it is a startup time (yes in S200), the process moves to S202.

[0088] In S202, the second execution product number is sent from ECU210 to the main ECU200. As described above, the detailed explanation of the second execution product number will not be repeated. The process then proceeds to S204.

[0089] In S204, a VMC request is sent from ECU 210. As described above, the VMC request will not be repeated in detail. ECU 210 may send VMC requests intermittently at predetermined intervals, or it may send VMC requests continuously.

[0090] In S206, ECU210 determines whether a completion notification has been received from master ECU200. The details of the completion notification are as described above and will not be repeated here. If a completion notification has been received (yes in S206), the process proceeds to S208.

[0091] In S208, the transmission of VMC requests is stopped from ECU210. Furthermore, if no completion notification is received from the main ECU200 (which was not the case in S206), processing is moved to S210.

[0092] In S210, ECU 210 determines whether the waiting time for receiving the completion notification is longer than a predetermined time T2. The waiting time for receiving the completion notification is, for example, the elapsed time since the VMC request was sent. The predetermined time T2 is adjusted, for example, through experimentation. If ECU 210 determines that the waiting time for receiving the completion notification is longer than the predetermined time T2 (yes in S210), the process proceeds to S208. Furthermore, if it determines that the waiting time for receiving the completion notification is less than or equal to the predetermined time T2 (no in S210), the process returns to S206. Additionally, if ECU 210 determines that the process did not originate from the start-up of ECU 210 (no in S200), the process ends.

[0093] Side reference Figure 8 An example of the operation of the master ECU 200 and slave ECU 210 based on the above structure and flowchart will be explained.

[0094] Figure 8This diagram illustrates one example of the operation of the main ECU 200 and one example of the operation of the slave ECU 210. Figure 8 The operation history of the master ECU 200 and slave ECU 210 is shown in the figure.

[0095] For example, if the user performs the startup operation of the system used to start the electric vehicle 100, then as follows Figure 8 As shown in (A), the electric vehicle 100 is switched to the IG-on state. When the electric vehicle 100 is switched to the IG-on state, power is supplied to the main ECU 200 and the slave ECU 210 respectively, thereby starting the main ECU 200 and the slave ECU 210.

[0096] If ECU210 determines that it is starting (in S200 it is), then as follows Figure 8 As shown in (B-1), the second execution product number is sent to the main ECU 200, and (S202) as follows. Figure 8 As shown in (B-2), a VMC request is sent to the main ECU 200 (S204).

[0097] In the main ECU 200, if it is determined that the initial check has not been performed (yes in S100), it is determined whether all execution product numbers have been received (S102). If the first execution product number is obtained and the second execution product number is received from the slave ECU 210, it is determined that all execution product numbers have been received (yes in S102), such as... Figure 8 As shown in (C-1), VMC is executed (S104). If VMC is executed and the main ECU 200 determines that the first execution product number matches the second execution product number (yes in S108), then... Figure 8 As shown in (C-2), a completion notification is sent to the ECU 210 (S110). Subsequently, a flag indicating whether an initial check has been performed is set to the on state (S112), and autonomous driving is permitted (S114). If a completion notification is received from the ECU 210 (yes in S206), the ECU 210 stops sending VMC requests (S208).

[0098] For example, such as Figure 8 As shown in (D), it is assumed that the ECU210 is reset due to some malfunction. Therefore, as... Figure 8 As shown in (E), when restarting from ECU210, if ECU210 determines that it is a startup (as in S200), as follows: Figure 8 As shown in (F-1), the second execution product number (S202) is sent to the main ECU 200. Furthermore, as... Figure 8 As shown in (F-2), a VMC request is sent to the main ECU 200 (S204).

[0099] If the main ECU 200 determines that an initial check has been performed (yes in S150), and a VMC request is received from the slave ECU 210 (yes in S152), then... Figure 8 As shown in (G-1), VMC is executed (S154). If VMC is executed and the main ECU 200 determines that the first execution product number matches the second execution product number (yes in S156), then... Figure 8 As shown in (G-2), a completion notification is sent to ECU 210 (S158). Subsequently, autonomous driving is permitted (S160). If a completion notification is received from ECU 210 (yes in S206), the transmission of VMC requests is stopped (S208).

[0100] Thus, at each startup, the slave ECU 210 sends a second execution product number and a VMC request. Additionally, if the master ECU 200 has not performed an initial check, VMC is performed by receiving the second execution product number from the slave ECU 210. And, if the master ECU 200 has performed an initial check, VMC is performed by receiving a VMC request from the slave ECU 210.

[0101] Therefore, for example, when the updated software is stored in the update storage area of ​​the main ECU 200 and the slave ECU 210 and the update storage area is set as the startup storage area for the next startup, even if the slave ECU 210 restarts due to some adverse condition and is started using the updated software before the electric vehicle 100 enters the IG disconnect state, the VMC is executed quickly according to the VMC request from the slave ECU 210 to the main ECU 200. If the execution of the VMC determines that the first execution product number and the second execution product number do not match (not in S156), the execution of the function using the updated software only in the slave ECU 210 is suppressed by making the automatic driving state unpermitted (S162).

[0102] As described above, in the vehicle system according to this embodiment, whenever the ECU 210 is started, the execution of VMC is requested from the main ECU 200, and the main ECU 200 executes VMC. Therefore, even if the update storage area is set as the startup storage area for the next startup, a VMC request is sent to the main ECU 200 upon restart, even if only the ECU 210 is restarted due to adverse conditions. This allows the main ECU 200 and the ECU 210 to detect mismatches in the combination of execution product numbers as early as possible. Therefore, a vehicle system and control device that can detect mismatches in the combination of software identification information among multiple control devices as early as possible is provided.

[0103] Furthermore, if the execution of the VMC determines that the first execution product number and the second execution product number do not match, the execution of functions implemented by software stored in the boot storage area (e.g., automatic driving using ADS240) becomes disabled (prohibited). In this way, it is possible to suppress the execution of functions such as automatic driving when the first execution product number and the second execution product number do not match.

[0104] The following describes some variations.

[0105] In the above embodiment, a structure of multiple ECUs mounted on the electric vehicle 100, including a master ECU 200 and a slave ECU 210, has been described as an example. However, the multiple ECUs may also include a master ECU 200 and multiple slave ECUs. In this modified example, for example, a structure of multiple ECUs mounted on the electric vehicle 100 including a master ECU 200, a first slave ECU 210A, and a second slave ECU 210B will be described as an example.

[0106] Figure 9 This is a diagram that briefly illustrates one example of the structure of the electric vehicle 100 in the modified example. Figure 9 The electric vehicle 100 shown is Figure 2 The electric vehicle 100 shown in the comparison differs in that it includes a first slave ECU 210A instead of the original ECU 210, and also includes a second slave ECU 210B. Other than this, the structure is the same and is labeled with the same reference numerals. Therefore, its detailed description will not be repeated.

[0107] The first ECU210A, for example, has a similar Figure 2 The second slave ECU 210B has the same structure as the first slave ECU 210A. However, compared with the first slave ECU 210A, the second slave ECU 210B differs in the sensor detection objects, control objects (e.g., steering system, braking system, etc.), and control actions. Aside from these differences, it has the same structure as the slave ECU 210A. Therefore, detailed descriptions of each of the first slave ECU 210A and the second slave ECU 210B will not be repeated.

[0108] Even in structures that include multiple slave ECUs, the same problem arises as when there is only one slave ECU.

[0109] Figure 10 This diagram illustrates one example of the actions performed by the main ECU 200 and multiple slave ECUs in a modified example. Figure 10 The operation history of the master ECU 200, the first slave ECU 210A, and the second slave ECU 210B is shown.

[0110] For example, if the user performs the startup operation of the system used to start the electric vehicle 100, then as follows Figure 10 As shown in (A), the electric vehicle 100 is switched to the IG-on state. When the electric vehicle 100 is switched to the IG-on state, power is supplied to the main ECU 200, the first slave ECU 210A and the second slave ECU 210B respectively, thereby starting the main ECU 200, the first slave ECU 210A and the second slave ECU 210B.

[0111] At this time, for example, such as Figure 10 As shown in (B), it is assumed that after startup, the first slave ECU 210A sends the product number of the software stored in the startup storage area of ​​the memory of the first slave ECU 210A as the execution product number to the master ECU 200.

[0112] And, for example, such as Figure 10 As shown in (C), it is assumed that the second slave ECU 210B, like the first slave ECU 210A, sends the product number of the software stored in the startup storage area of ​​the second slave ECU 210B's memory as the execution product number to the master ECU 200 after startup.

[0113] like Figure 10 As shown in (D), after the electric vehicle 100 enters the IG-on state, the main ECU 200 executes VMC by receiving the execution product number from each of the first slave ECU 210A and the second slave ECU 210B. Thus, the main ECU 200 can determine whether the combination of execution product numbers matches by checking whether the combination of the first execution product number of the software currently being executed by the main ECU 200, the second execution product number of the software currently being executed by the first slave ECU 210A, and the third execution product number of the software currently being executed by the second slave ECU 210B is a predetermined combination. The predetermined combination of execution product numbers can be obtained in the same way as the two predetermined combinations of execution product numbers in the above embodiment. Therefore, its detailed description will not be repeated.

[0114] However, in this case, similar to the above-described implementation, when the master ECU 200 instructs the first slave ECU 210A and the second slave ECU 210B to switch the start-up storage area for the next start-up, and during the period until the electric vehicle 100 enters the IG disconnected state, if either the first slave ECU 210A or the second slave ECU 210B restarts due to some adverse condition such as a momentary power disconnection, there is a possibility that the switch of the start-up storage area is performed only by that slave ECU.

[0115] For example, such as Figure 10 As shown in (E), when the first slave ECU 210A resets due to some malfunction, the first slave ECU 210A restarts. At this time, as... Figure 10 As shown in (F), even if an execution product number is sent to the master ECU 200, the VMC is not executed in the master ECU 200. Therefore, until the next startup of the master ECU 200 and the second slave ECU 210B, the execution product number of the master ECU 200 and the second slave ECU 210B is the product number before the update, and the execution product number of the first slave ECU 210A is the updated product number. This results in a period where the combination of execution product numbers in the master ECU 200, the first slave ECU 210A, and the second slave ECU 210B becomes mismatched. The same period of mismatched execution product number combinations may also occur if certain adverse conditions occur in the second slave ECU 210B.

[0116] Therefore, in this modified example, the first slave ECU 210A and the second slave ECU 210B request the execution of a matching determination process from the master ECU 200 upon their respective startup. This matching determination process is used to determine whether the software identification information (i.e., the execution product number) stored in the startup storage area matches between the master ECU 200, the first slave ECU 210A, and the second slave ECU 210B. The master ECU 200 executes the matching determination process (VMC) upon startup of the master ECU 200 and upon receiving a request for execution of the matching determination process from either the first slave ECU 210A or the second slave ECU 210B.

[0117] In this way, when the first slave ECU 210A or the second slave ECU 210B starts up, the execution of the matching determination process is requested from the master ECU 200, and the master ECU 200 performs the matching determination process. Therefore, when the update storage area is set as the startup storage area for the next startup, even if the first slave ECU 210A or the second slave ECU 210B restarts due to adverse conditions, the execution of the matching determination process is requested from the master ECU 200 upon restart. As a result, mismatches in the combination of execution product numbers can be detected as early as possible in the master ECU 200, the first slave ECU 210A, and the second slave ECU 210B.

[0118] The following is a reference. Figure 11 An example of the processing performed by the main ECU 200 in the modified example will be described. Figure 11 This is a flowchart illustrating an example of the processing performed by the main ECU 200 in a modified example. The flowchart shows a series of processes that are repeatedly executed by the main ECU 200 at a predetermined processing cycle.

[0119] Figure 11 Flowcharts and Figure 5 The flowchart comparison shows that the difference lies in the fact that the processes that replace S102, S104, S106, S108, and S110 are instead executed as S300, S302, S304, S306, and S308. Figure 11 In the flowchart, for the... Figure 5 The flowcharts are identical, assigning the same step numbers, and the processing content is also the same, except as described below. Therefore, their detailed descriptions will not be repeated.

[0120] If the main ECU 200 determines that the initial check has not been performed (yes in S100), the process is moved to S300.

[0121] In S300, the main ECU 200 determines whether all execution product numbers have been obtained. For example, if the first execution product number, the second execution product number, and the third execution product number have been obtained, the main ECU 200 determines that all execution product numbers have been obtained. The main ECU 200, for example, obtains the product number of the software stored in the boot storage area of ​​the memory 212 as the first execution product number. The main ECU 200, for example, obtains the second execution product number from the first slave ECU 210A. And, for example, the main ECU 200 obtains the third execution product number from the second slave ECU 210B. If the main ECU 200 determines that all execution product numbers have been received (yes in S300), the process moves to S302.

[0122] In S302, the main ECU 200 performs a matching determination process. The main ECU 200 determines whether the combination of the first execution product number, the second execution product number, and the third execution product number is a predetermined combination. Then, the process moves to S308. Furthermore, if the main ECU 200 determines that not all execution product numbers have been obtained (which is not the case in S300), the process moves to S304.

[0123] In S304, the main ECU 200 determines whether the waiting time for receiving the product number is longer than a predetermined time T1. The waiting time and the predetermined time T1 are explained in detail above, so they will not be repeated here. If the main ECU 200 determines that the waiting time for receiving the product number is longer than the predetermined time T1 (yes in S304), the process proceeds to S116. Furthermore, if the main ECU 200 determines that the waiting time for receiving the product number is less than or equal to the predetermined time T1 (no in S304), the process returns to S300.

[0124] In S306, the main ECU 200 determines whether the first, second, and third execution product numbers match. For example, if the combination of the first, second, and third execution product numbers is a predetermined combination such as the combination of product numbers of the software before the update or the combination of product numbers of the software after the update, the main ECU 200 determines that the first, second, and third execution product numbers match. If the main ECU 200 determines that the first, second, and third execution product numbers match (yes in S306), the process moves to S308. Furthermore, if the main ECU 200 determines that the first, second, and third execution product numbers do not match (no in S306), the process moves to S116.

[0125] In S308, the master ECU 200 sends a completion notification of the matching determination process during host startup (hereinafter referred to as the host startup completion notification). The master ECU 200 sends the host startup completion notification to the first slave ECU 210A and the second slave ECU 210B respectively. Thereafter, the process moves to S112.

[0126] Next, refer to Figure 12 An example of another process performed by the main ECU 200 in the modified example will be described. Figure 12 This is a flowchart illustrating an example of another process performed by the main ECU 200 in a modified example. The series of processes shown in this flowchart are repeatedly executed by the main ECU 200 at a predetermined processing cycle.

[0127] Figure 12 Flowcharts and Figure 6 The flowchart comparison shows that the difference lies in the fact that the processes that replace S152, S154, S156, and S158 are instead executed as S400, S402, S404, S406, S408, S410, S412, S414, and S416. Figure 12 In the flowchart, for the... Figure 6 The flowcharts are identical, assigning the same step numbers, and the processing content is also the same, except as described below. Therefore, their detailed descriptions will not be repeated.

[0128] If the main ECU 200 determines that an initial check has been performed (yes in S150), the process is moved to S400.

[0129] In S400, the main ECU 200 determines whether a VMC status acknowledgment (n) has been received (n is 1 or 2). For example, if a VMC status acknowledgment (1) is received from the first slave ECU 210A, or if a VMC status acknowledgment (2) is received from the second slave ECU 210B, the main ECU 200 determines that a VMC status acknowledgment (n) has been received. Details regarding VMC status acknowledgment (1) and VMC status acknowledgment (2) will be described later. If it is determined that a VMC status acknowledgment (n) has been received (yes in S400), the process moves to S402. Furthermore, if it is determined that a VMC status acknowledgment (n) has not been received (no in S400), the process returns to S400.

[0130] In S402, the main ECU 200 determines whether it has received a VMC status confirmation (m) (m is 1 or 2 other than n). If a VMC status confirmation (1) is received in S400, the main ECU 200 determines whether it has received a VMC status confirmation (2). Alternatively, if a VMC status confirmation (2) is received in S400, the main ECU 200 determines whether it has received a VMC status confirmation (1). If it is determined that the main ECU 200 has received a VMC status confirmation (m) (yes in S402), the process moves to S404. Furthermore, if the main ECU 200 determines that it has not received a VMC status confirmation (m) (no in S402), the process moves to S406.

[0131] In S404, the master ECU 200 disables the transmission of VMC enable (m), which indicates that VMC can be executed. For example, when a VMC status confirmation (1) is received in S400, the master ECU 200 disables the transmission of VMC enable (2) from the second slave ECU 210B. Additionally, for example, when a VMC status confirmation (2) is received in S400, the master ECU 200 disables the transmission of VMC enable (1) from the first slave ECU 210A. The process then proceeds to S406.

[0132] In S406, the master ECU 200 sends a VMC status confirmation (n). For example, if a VMC status confirmation (1) is received in S400, the master ECU 200 sends a VMC status confirmation (1) to the first slave ECU 210A. The VMC status confirmation (1) contains information indicating that a VMC based on the request of the first slave ECU 210A can be executed. Additionally, for example, if a VMC status confirmation (2) is received in S400, the master ECU 200 sends a VMC status confirmation (2) to the second slave ECU 210B. The VMC status confirmation (2) contains information indicating that a VMC based on the request of the second slave ECU 210B can be executed. Afterwards, the process proceeds to S408.

[0133] In S408, the master ECU 200 determines whether it has received a VMC request (n). For example, if a VMC status acknowledgment (1) is received in S400, the master ECU 200 determines that it has received a VMC request (n) when it receives a VMC request (1) from the first slave ECU 210A. The VMC request (1) includes an execution request for the master ECU 200's VMC, with the sending source set to the first slave ECU 210A. Alternatively, for example, if a VMC status acknowledgment (2) is received in S400, the master ECU 200 determines that it has received a VMC request (n) when it receives a VMC request (2) from the second slave ECU 210B. The VMC request (2) includes an execution request for the master ECU 200's VMC, with the sending source set to the second slave ECU 210B. If the master ECU 200 determines that it has received a VMC request (n) (yes in S408), the process moves to S410.

[0134] In S410, the main ECU 200 performs a matching determination process. This matching determination process is the same as in S302, so its detailed explanation will not be repeated. Afterwards, the process moves to S414. Furthermore, if the main ECU 200 determines that it has not received a VMC request (n) (which is not the case in S408), the process moves to S412.

[0135] In S412, the main ECU 200 determines whether a VMC request (m) has been received. For example, if a VMC status confirmation (1) is received in S400, the main ECU 200 determines that a VMC request (m) has been received when it receives a VMC request (2). For example, if a VMC status confirmation (2) is received in S400, the main ECU 200 determines that a VMC request (m) has been received when it receives a VMC request (1). If the main ECU 200 determines that a VMC request (m) has been received (yes in S412), the process returns to S408. Furthermore, if the main ECU 200 determines that a VMC request (m) has not been received (no in S412), the process returns to S408.

[0136] In S414, the main ECU 200 determines whether the first, second, and third execution product numbers match. The determination method is as described above, so its detailed explanation will not be repeated. If the main ECU 200 determines that the first, second, and third execution product numbers match (yes in S414), the process proceeds to S416. Conversely, if the main ECU 200 determines that the first, second, and third execution product numbers do not match (no in S414), the process proceeds to S162.

[0137] In S416, the master ECU 200 sends a completion notification. The master ECU 200 sends completion notifications to the first slave ECU 210A and the second slave ECU 210B respectively. Afterwards, processing moves to S418.

[0138] In S418, the main ECU 200 permits the transmission of VMC(m). For example, in S404, the main ECU 200 may disallow transmission but permit the transmission of VMC(m). Subsequently, the process proceeds to S160.

[0139] Next, refer to Figure 13 An example of the processing performed by the first slave ECU 210A and the second slave ECU 210B will be described. Figure 13 This is a flowchart illustrating an example of another process executed by the first slave ECU 210A and the second slave ECU 210B, respectively, in a modified example. Furthermore, Figure 13 The "n" shown in the flowchart represents the value of the executing entity. For example, when n = 1, Figure 13 The flowchart illustrates the processing performed by the first ECU 210A. Furthermore, when n=2, Figure 13 The flowchart illustrates the processing performed by the second ECU 210B. In the following description, [the process will be...]. Figure 13 The flowchart shows the case where the execution subject is the first slave ECU 210A, which will be used as an example for explanation. The case where the execution subject is the second slave ECU 210B is the same, so its detailed explanation will not be repeated.

[0140] In S500, the first slave ECU 210A determines whether it is a startup time. The determination method is the same as that in the process of S200 described above, so its detailed description will not be repeated. If the first slave ECU 210A determines that it is a startup time (yes in S500), the process moves to S502. Furthermore, if the first slave ECU 210A determines that it is not a startup time (no in S500), the process ends.

[0141] In S502, the first slave ECU 210A sends the second execution product number as the execution product number (n) to the master ECU 200. Then, the processing proceeds to S504.

[0142] In S504, the first slave ECU 210A sends the VMC status confirmation (1) as the VMC status confirmation (n) to the master ECU 200. Thereafter, the processing is moved to S506.

[0143] In S506, the first slave ECU 210A determines whether it has received a completion notification during host startup. If the first slave ECU 210A determines that it has received a completion notification during host startup (yes in S506), the process moves to S508.

[0144] In S508, the first slave ECU 210A stops sending VMC status confirmation (1) and VMC request (1). For example, if VMC status confirmation (1) is being sent, the first slave ECU 210A stops sending VMC status confirmation (1). Additionally, if VMC status confirmation (1) and VMC request (1) are being sent, the first slave ECU 210A stops sending VMC status confirmation (1) and VMC request (1). Furthermore, if the first slave ECU 210A determines that it has not received the completion notification during host startup (not in S506), the process is moved to S510.

[0145] In S510, the first slave ECU 210A determines whether it has received a VMC (n) from the master ECU 200. If the first slave ECU 210A receives a VMC (1) from the master ECU 200, it determines that it has received a VMC (n). If the first slave ECU 210A determines that it has received a VMC (n) (yes in S510), the process moves to S512. Furthermore, if the first slave ECU 210A determines that it has not received a VMC (1) (no in S510), the process returns to S506.

[0146] In S512, the first slave ECU 210A sends a VMC request (n) to the master ECU 200. The first slave ECU 210A sends the VMC request (1) as a VMC request (n) to the master ECU 200. Thereafter, the processing moves to S514.

[0147] In S514, the first slave ECU 210A determines whether a completion notification has been received from the master ECU 200. If it is determined that a completion notification has been received (yes in S514), the process moves to S508. Otherwise, if it is determined that no completion notification has been received (no in S514), the process moves to S516.

[0148] In S516, the first slave ECU 210A determines whether the waiting time for receiving the completion notification is longer than a predetermined time T2. As described above, the waiting time for receiving the completion notification and the predetermined time T2 will not be explained in detail again. If the first slave ECU 210A determines that the waiting time for receiving the completion notification is longer than the predetermined time T2 (yes in S516), the process proceeds to S508. Furthermore, if the first slave ECU 210A determines that the waiting time for receiving the completion notification is less than or equal to the predetermined time T2 (no in S516), the process returns to S514.

[0149] Side reference Figure 14 An example of the operation of the main ECU 200, the first slave ECU 210A, and the second slave ECU 210B in this modified example based on the flowchart described above will be explained.

[0150] Figure 14 This diagram illustrates one example of the operation of the main ECU 200 and one example of the operation of each slave ECU in the modified example. Figure 14 The operation history of the master ECU 200, the first slave ECU 210A, and the second slave ECU 210B is shown.

[0151] For example, if the user performs the startup operation of the system used to start the electric vehicle 100, then as follows Figure 14 As shown in (A), the electric vehicle 100 is switched to the IG-on state. When the electric vehicle 100 is switched to the IG-on state, the main ECU 200 supplies power to the first slave ECU 210A and the second slave ECU 210B respectively, thereby starting the main ECU 200, the first slave ECU 210A and the second slave ECU 210B.

[0152] If it is determined that the first slave ECU210A is starting (yes in S500), then as follows Figure 14 As shown in (B-1), the second execution product number (S502) is sent to the main ECU 200, and as... Figure 14 As shown in (B-2), a VMC status confirmation (1) (S504) is sent to the main ECU 200.

[0153] Similarly, if it is determined that the second ECU210B is starting (in S500), then... Figure 14 As shown in (C-1), the third execution product number (S502) is sent to the main ECU 200, and as... Figure 14 As shown in (C-2), a VMC status confirmation (2) (S504) is sent to the main ECU200.

[0154] In the main ECU 200, if it is determined that the initial check was not performed (yes in S100), it is determined whether all execution product numbers have been received (S300). If the first execution product number is obtained, and the second execution product number is received from the first slave ECU 210A and the third execution product number is received from the second slave ECU 210B, it is determined that all execution product numbers have been received (yes in S300), such as... Figure 14 As shown in (D-1), VMC is executed (S302). If VMC is executed and it is determined that the first execution product number, the second execution product number, and the third execution product number match (yes in S306), a completion notification for host startup is sent to the first slave ECU 210A and the second slave ECU 210B respectively (S308). Thereafter, a flag indicating whether an initial check has been performed is set to the on state (S112), and automatic driving is permitted (S114).

[0155] If a completion notification for host startup is received from the first ECU 210A (yes in S506), the transmission of VMC status confirmation (1) is stopped (S508). Furthermore, if a completion notification for host startup is received from the second ECU 210B (yes in S506), the transmission of VMC status confirmation (2) is stopped (S508).

[0156] For example, such as Figure 14 As shown in (E), the first slave ECU 210A is reset due to some malfunction. Therefore, in the event of a restart of the first slave ECU 210A, when it is determined that a startup has occurred (as in S500), as... Figure 14 As shown in (F-1), the second execution product number (S502) is sent to the main ECU 200. Furthermore, as... Figure 14 As shown in (F-2), a VMC status confirmation (1) (S504) is sent to the main ECU 200.

[0157] If it is determined that an initial check has been performed (yes in S150), the main ECU 200 receives a VMC status confirmation (1) from the first slave ECU 210A. Furthermore, if no VMC status confirmation (2) is received (no in S402), as follows... Figure 14 As shown in (I), VMC can be sent to the first ECU210A (1)(S406).

[0158] If, in the first case, a completion notification for host startup is not received from ECU210A (no in S506) but a VMC is received (1) (yes in S510), then... Figure 14 As shown in (J), a VMC request (1) (S512) is sent to the main ECU 200.

[0159] If the main ECU 200 receives a VMC request (1) (yes in S408), then as follows Figure 14 As shown in (K), VMC (S410) is executed. If VMC is executed, it is determined whether the first executed product number, the second executed product number, and the third executed product number match.

[0160] like Figure 14 As shown in (G), during the execution of VMC, for example, if the second slave ECU 210B is reset due to some malfunction and thus restarts, when it is determined that it is starting (in S500), as follows: Figure 14 As shown in (H-1), the third execution product number (S502) is sent to the main ECU 200, and as... Figure 14 As shown in (H-2), a VMC status confirmation (2) (S504) is sent to the main ECU 200.

[0161] If the main ECU 200 determines that the first execution product number, the second execution product number, and the third execution product number match (in S414, this is true), then... Figure 14 As shown in (L-1), a completion notification is sent to the first slave ECU 210A, and as... Figure 14 As shown in (L-2), a completion notification is sent to the second ECU 210B (S416). Furthermore, the permission status of the VMC (2) is maintained (S418), and autonomous driving is permitted (S160).

[0162] If a completion notification is received from ECU210A in the first step (yes in S514), the transmission of VMC status confirmation (1) and VMC request (1) is stopped (S508).

[0163] On the other hand, since the transmission of VMC status confirmation (2) from the second slave ECU 210B to the master ECU 200 is ongoing, if it is determined that VMC status confirmation (2) has been received (yes in S400) and VMC status confirmation (1) has not been received (no in S402), then... Figure 14 As shown in (M), VMC can be sent to the second ECU210B (2)(S406).

[0164] If the second ECU210B does not receive a completion notification for host startup (No in S506) and receives a VMC (2) (Yes in S510), then... Figure 14 As shown in (N), a VMC request (2) (S512) is sent to the main ECU200.

[0165] If the main ECU 200 receives a VMC request (2) (yes in S408), then as follows Figure 14 As shown in (O), VMC (S410) is executed. If VMC is executed, it is determined whether the first executed product number, the second executed product number, and the third executed product number match.

[0166] If the main ECU 200 determines that the first execution product number, the second execution product number, and the third execution product number match (in S414, this is true), then... Figure 14 As shown in (P-1), a completion notification is sent to the first slave ECU 210A, and as... Figure 14 As shown in (P-2), a completion notification is sent to the second ECU 210B (S416). Furthermore, the permission status of the VMC (1) is maintained (S418), and autonomous driving is permitted (S160).

[0167] If a completion notification is received from ECU210B in the second step (yes in S514), the transmission of VMC status confirmation (2) and VMC request (2) is stopped (S508).

[0168] Thus, on the first slave ECU 210A, whenever it starts, it sends a second execution product number and VMC status confirmation (1), and if VMC can be executed, it sends a VMC request (1). And on the second slave ECU 210B, whenever it starts, it sends a third execution product number and VMC status confirmation (2), and if VMC can be executed, it sends a VMC request (2).

[0169] Additionally, in the main ECU 200, VMC is executed by receiving the second and third execution product numbers without performing an initial check. Furthermore, in the main ECU 200, if an initial check has been performed, VMC is executed by receiving a VMC request (1) after the transmission and reception of VMC status confirmation (1) and VMC enable (1). Alternatively, in the main ECU 200, if an initial check has been performed, VMC is executed by receiving a VMC request (2) after the transmission and reception of VMC status confirmation (2) and VMC enable (2).

[0170] Therefore, for example, when the updated software is stored in the update storage area of ​​the main ECU 200, the first slave ECU 210A, and the second slave ECU 210B, and the update storage area is set as the startup storage area for the next startup, even if the electric vehicle 100 restarts and starts using the updated software due to some adverse condition occurring in at least one of the first slave ECU 210A and the second slave ECU 210B before it enters the IG disconnect state, the VMC is executed quickly according to the VMC request from the first slave ECU 210A or the second slave ECU 210B. If the execution of the VMC determines that the first execution product number, the second execution product number, and the third execution product number do not match (not in S414), the execution of functions using the updated software only in the first slave ECU 210A or the second slave ECU 210B is suppressed by making the autonomous driving state unpermitted (S162).

[0171] As described above, according to the vehicle system involved in this variation, even when there are more than two slave ECUs, it is possible to detect mismatches in the combination of software identification information as early as possible by multiple control devices.

[0172] Furthermore, assuming that, after an initial check has been performed (yes in S150), both the first slave ECU 210A and the second slave ECU 210B restart at different times due to some adverse condition, and receive a VMC status confirmation (2) immediately after receiving the VMC status confirmation (1). In this case, the transmission of VMC status confirmation (2) remains in a disabled state until the next transmission completion notification, thus suppressing the transmission of VMC status confirmation (2) corresponding to the receipt of VMC status confirmation (2). In this way, it is possible to suppress the parallel requests for VMC execution from both the first slave ECU 210A and the second slave ECU 210B.

[0173] Furthermore, in this modified example, when a VMC completion notification is received for a VMC request (1) from the first slave ECU 210A, and VMC status confirmation (2) from the second slave ECU 210B is continuously being sent, the case where VMC is executed by sending and receiving VMC availability (2) and VMC request (2) from the master ECU 200 has been described. However, for example, the notification content of the completion notification (e.g., whether product number matching or mismatch is performed) can be used to determine whether VMC execution is necessary. For example, if the notification content of the completion notification is about performing product number matching, it is determined that VMC will not be executed repeatedly; or if the notification content of the completion notification is about performing product number mismatch, it is determined that VMC will be executed again. In this way, unnecessary VMC execution can be suppressed.

[0174] Furthermore, in this modified example, the case in which VMC is executed based on a VMC request from either the first slave ECU 210A or the second slave ECU 210B after an initial check has been performed, and the case in which VMC is executed based on a VMC request from the other slave ECU, are illustrated as examples. However, in the case of executing VMC based on a VMC request from one slave ECU, even if a VMC request is received from the other slave ECU, VMC may not be executed. In this way, unnecessary execution of VMC can be suppressed.

[0175] Furthermore, in this modified example, the case in which VMC is executed based on a VMC request from either the first slave ECU 210A or the second slave ECU 210B after an initial check has been performed, and the case in which VMC corresponding to a VMC request from the other slave ECU is executed after a completion notification is received, is described as an example. However, if a completion notification is not received within a certain period of time, VMC corresponding to a VMC request from the other slave ECU may also be executed.

[0176] Furthermore, the aforementioned variations can also be implemented by combining all or part of them appropriately.

[0177] All points of the embodiments disclosed herein should be considered illustrative and not intended to limit the invention. The scope of the invention is not limited by the foregoing description, but is indicated by the claims and is intended to include all equivalents thereof and all modifications within the scope of the claims.

Claims

1. A vehicle-mounted system, characterized in that, The vehicle-mounted system includes multiple control devices. The plurality of control devices are respectively configured as follows: Designate any one of the multiple storage areas specified as storage areas for storage software as the boot storage area. Start using the software stored in the startup storage area. The plurality of control devices include a master control device and a slave control device. The main control device is configured such that, when software stored in a storage area different from the startup storage area is updated in the slave control device, it sends a switching instruction to the slave control device to set the storage area where the updated software is stored as the startup storage area. The control device is configured as follows: Upon receiving the switching instruction, the configuration of the boot storage area will be implemented upon the next startup. Each time the system starts up, it requests the execution of a matching determination process from the main control device. This matching determination process is used to determine whether the identification information of the software stored in the startup storage area matches among the multiple control devices. The main control device is configured to execute the matching determination process upon receiving a request from the slave control device to execute the matching determination process. The main control device is configured to send a completion notification to the slave control device after the matching determination process is completed. The slave control device is configured to use the completion notification to determine whether to request the execution of the matching determination process.

2. The vehicle-mounted system according to claim 1, characterized in that, The main control device is configured to prohibit the execution of functions implemented by the software when it is determined that the identification information of the software stored in the startup storage area does not match among multiple control devices.

3. The vehicle-mounted system according to claim 1, characterized in that, The control device is configured as follows: At startup, a determination is requested from the main control device as to whether the matching determination process can be executed. The execution feasibility determination result from the main control device and the completion notification are used to determine whether to request the execution of the matching determination process.

4. The vehicle-mounted system according to claim 3, characterized in that, The control device includes a first control device and a second control device. The main control device is configured to: when receiving the execution permission determination request from the first control device, if no determination request from the second control device has been received before the determination request from the first control device, send a determination result indicating that the matching determination process can be performed to the first control device.

5. The vehicle-mounted system according to claim 4, characterized in that, The main control device is configured such that when it requests the execution permission determination from the first control device and then requests the execution permission determination from the second control device, it prohibits sending the determination result to the second control device.

6. The vehicle-mounted system according to any one of claims 1 to 5, characterized in that, The main control device is configured to send a first completion notification of the matching determination process executed at startup to the slave control device, and a second completion notification of the matching determination process executed when the slave control device requests the execution of the matching determination process. The control device is configured as follows: Upon receiving the first completion notification and the second completion notification, the request to stop the execution of the matching determination process is made. If the first completion notification is not received, request the execution of the matching determination process.

7. A control device, wherein the control device is any one of a plurality of control devices that can designate any one of a plurality of storage areas, which are designated as storage areas for stored software, as a boot storage area and can be started using software stored in the boot storage area, characterized in that, The control device includes one or more processors, which are configured as follows: When software stored in a storage area different from the startup storage area is updated in another control device, a switching instruction is sent to the other control device to set the storage area where the updated software is stored as the startup storage area, wherein the other control device is configured to implement the setting of the startup storage area on the next startup if it receives the switching instruction. Whenever one of the other control devices is activated, a request is received to execute a matching determination process to determine whether the identification information of the software stored in the startup storage area matches among the plurality of control devices; and Upon receiving a request from the other control devices to execute the matching determination process, the matching determination process is executed. The control device is configured to send a completion notification to the other control devices after the matching determination process is completed. The other control devices are configured to use the completion notification to determine whether to request the execution of the matching determination process.

8. A control device, wherein the control device is any one of a plurality of storage areas designated as storage areas for storing software, which is configured as a boot storage area and is capable of being started using software stored in the boot storage area, characterized in that, The control device includes one or more processors, which are configured as follows: If software stored in a storage area different from the startup storage area is updated, and a switching instruction is received to set the storage area where the updated software is stored as the startup storage area, then the setting of the startup storage area will be implemented on the next startup. and Each time the system starts up, it requests the execution of a matching determination process from any one of the plurality of control devices. This matching determination process determines whether the software identification information stored in the startup storage area matches among the plurality of control devices. Specifically, when the main control device receives the request to execute the matching determination process from the control device, the main control device executes the matching determination process. After the matching determination process is completed in the main control device, a completion notification is sent to the control device. The control device is configured to use the completion notification to determine whether to request the execution of the matching determination process.

Images