In-Vehicle Systems and Control Devices

Abstract

To detect at an early stage inconsistencies in the combination of software identification information in a plurality of control devices.SOLUTION: A slave ECU sends a second execution part number and a VMC request at the time of start-up. A master ECU executes VMC upon receiving the second execution part number at the time of initial check and sends a completion notification when a first execution part number and the second execution part number match. When the slave ECU is reset and restarted, the slave ECU sends the second execution part number and the VMC request. When the initial check has been executed, the master ECU executes VMC upon receiving the VMC request and sends the completion notification when the first execution part number and the second execution part number match.SELECTED DRAWING: Figure 8

Description

[Technical field]

[0001] The present disclosure relates to an in-vehicle system including a control device that is capable of updating software. [Background technology]

[0002] A vehicle is equipped with an on-board system that is composed of a plurality of actuators and a plurality of control devices that control each of the actuators. The functions of these control devices may be realized by software. By realizing the functions by software, it becomes possible to modify or add functions by receiving update programs even after the vehicle is released on the market. Furthermore, when modifying or adding functions that are performed in cooperation between a plurality of control devices, such as various driving assistance systems such as autonomous driving, it is necessary to update the software of all the control devices in question, and it is also necessary to confirm whether the updates have been performed appropriately in each control device.

[0003] For example, JP 2020-123253 A (Patent Document 1) discloses a technology in which, when the in-vehicle system is started up, identification information in a list stored in the memory unit of each ECU is compared, and the combination of software identification information recorded in the list is used to determine whether the combinations of software in each of multiple ECUs are consistent. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2020-123253 A Summary of the Invention [Problem to be solved by the invention]

[0005] The execution of the updated software may be performed the next time the in-vehicle system is started in order to switch over from the pre-update software to multiple ECUs at the same time. In this case, the next time the in-vehicle system is started, a check is also performed to see if the software was properly updated.

[0006] However, if some of the multiple control devices restart due to a malfunction such as a momentary power outage before the next startup of the in-vehicle system, the updated software will be executed only in the restarted control devices, and the combination of software identification information in the multiple control devices will remain in an inconsistent state at least until the next startup of the in-vehicle system, which may prevent functions from being modified or added properly.

[0007] The present disclosure has been made to solve the above-mentioned problems, and its purpose is to provide an in-vehicle system and a control device that can early detect inconsistencies in the combination of software identification information in multiple control devices. [Means for solving the problem]

[0008] An in-vehicle system according to an aspect of the present disclosure is an in-vehicle system configured by setting one of a plurality of storage areas set as storage areas for storing software as a startup storage area and including a plurality of control devices that can be started using the software stored in the startup storage area. The plurality of control devices include a master control device and a slave control device. When software stored in a storage area other than the startup storage area is updated in the slave control device, the master control device executes 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. When the slave control device receives the switching instruction, the slave control device sets the startup storage area at the next startup and requests the master control device to execute a consistency determination process for determining whether or not identification information of the software stored in the startup storage area is consistent between the plurality of control devices at each startup. The master control device executes the consistency determination process when it receives a request to execute the consistency determination process from the slave control device.

[0009] In this way, the master control device is requested to execute a consistency determination process each time a slave control device is started, and the consistency determination process is executed in the master control device. Therefore, when the memory area that stores the updated software is set as the startup memory area at the next startup, even if only the slave control device is restarted due to a malfunction or the like, the master control device is requested to execute the consistency determination process at the time of restart. This makes it possible to detect inconsistencies in the combination of software identification information in multiple control devices at an early stage.

[0010] In one embodiment, if the master control device determines that the identification information of the software stored in the startup memory area is not consistent among multiple control devices, the master control device prohibits the execution of the function realized by the software.

[0011] In this way, it is possible to prevent a function realized by software from being executed in a state where the combination of software identification information is not consistent among a plurality of control devices.

[0012] Furthermore, in one embodiment, the master control device transmits a completion notification to the slave control device after the consistency determination process is completed, and the slave control device uses the completion notification to decide whether or not to request execution of the consistency determination process.

[0013] In this way, for example, when there are multiple requests to execute the consistency determination process to the master control device, it is possible to prevent the consistency determination process from being executed unnecessarily.

[0014] In a further embodiment, the slave control device requests the master control device to determine whether or not the consistency determination process can be executed at the time of startup. The slave control device uses the result of the determination of whether or not the consistency determination process can be executed and a completion notification from the master control device to determine whether or not to request the execution of the consistency determination process.

[0015] In this way, by requesting a determination as to whether execution is possible before requesting execution of the consistency determination process, it is possible to prevent unnecessary requests to execute the consistency determination process.

[0016] In yet another embodiment, the slave control device includes a first control device and a second control device. When the master control device receives a request for determination of whether execution is possible from the first control device, the master control device transmits a determination result indicating that execution of the consistency determination process is possible to the first control device when a determination request from the second control device has not been received prior to the determination request from the first control device.

[0017] In this way, the master control device can execute the consistency judgment process in response to a request from the first control device by transmitting a judgment result indicating that the consistency judgment process can be executed to the first control device, which received a judgment request before the second control device.

[0018] Furthermore, in one embodiment, the master control device prohibits sending the determination result to the second control device when the second control device requests a determination of whether execution is possible after the first control device requests a determination of whether execution is possible.

[0019] In this way, it is possible to prevent requests to execute the consistency determination process from both the first control device and the second control device.

[0020] In yet another embodiment, the master control device transmits to the slave control device a first completion notification of the consistency determination process executed at startup and a second completion notification of the consistency determination process executed when execution of the consistency determination process is requested from the slave control device. When the slave control device receives the first completion notification and when it receives the second completion notification, it stops requesting execution of the consistency determination process, and when it does not receive the first completion notification, it requests execution of the consistency determination process.

[0021] In this way, it is possible to prevent the slave control device from unnecessarily requesting the execution of the consistency determination process.

[0022] A control device according to another aspect of the present disclosure is one of a plurality of control devices that sets one of a plurality of storage areas set as storage areas for storing software as a startup storage area and can be started up using the software stored in the startup storage area. When software stored in a storage area other than the startup storage area is updated in the other control device, the control device executes a switching instruction to the other control device to set the storage area in which the updated software is stored as the startup storage area. When the switching instruction is received in the other control device, the startup storage area is set at the next startup, and the control device is requested to execute a consistency determination process for determining whether or not identification information of the software stored in the startup storage area is consistent between the plurality of control devices at each startup. The control device executes the consistency determination process when it receives a request to execute the consistency determination process from the other control device.

[0023] A control device according to yet another aspect of the present disclosure is a control device that sets one of a plurality of storage areas set as storage areas for storing software as a startup storage area, and is one of a plurality of control devices that can be started up using the software stored in the startup storage area. When software stored in a storage area other than the startup storage area is updated, the control device, upon receiving a switching instruction to set the storage area in which the updated software is stored as the startup storage area, sets the startup storage area at the next startup, and requests a master control device of one of the plurality of control devices to execute a consistency determination process for determining whether identification information of the software stored in the startup storage area is consistent between the plurality of control devices at each startup. The consistency determination process is executed when the master control device receives a request to execute the consistency determination process from the control device. Effect of the Invention

[0024] According to the present disclosure, it is possible to provide an in-vehicle system and a control device that can detect an inconsistency in the combination of software identification information in a plurality of control devices at an early stage. [Brief description of the drawings]

[0025] [Figure 1] FIG. 1 is a diagram illustrating an example of a configuration of a communication system. [Diagram 2] 1 is a diagram illustrating an example of a configuration of an electric vehicle according to an embodiment of the present invention; [Diagram 3] 4 is a diagram for explaining an example of operations performed by a master ECU and a slave ECU; FIG. [Figure 4] 11 is a diagram for explaining an example of an operation when a combination of execution part numbers between a master ECU and a slave ECU is inconsistent. FIG. [Diagram 5] 4 is a flowchart showing an example of a process executed by a master ECU. [Figure 6] 10 is a flowchart showing an example of another process executed by the master ECU. [Figure 7]4 is a flowchart showing an example of a process executed by a slave ECU. [Figure 8] 4 is a diagram for explaining an example of an operation of a master ECU and an example of an operation of a slave ECU; [Figure 9] FIG. 10 is a diagram illustrating an example of the configuration of an electric vehicle according to a modified example. [Figure 10] 10 is a diagram for explaining an example of operations performed by a master ECU and a plurality of slave ECUs in a modified example. FIG. [Figure 11] 10 is a flowchart showing an example of a process executed by a master ECU in a modified example. [Figure 12] 10 is a flowchart showing an example of another process executed by the master ECU in the modified example. [Figure 13] 10 is a flowchart showing an example of another process executed in each of the first slave ECU and the second slave ECU in the modified example. [Figure 14] 10A and 10B are diagrams for explaining an example of an operation of a master ECU and an example of an operation of each slave ECU in a modified example. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0026] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the drawings. In the drawings, the same or corresponding parts are designated by the same reference characters and their description will not be repeated.

[0027] Fig. 1 is a diagram for explaining an example of the configuration of a communication system 1. As shown in Fig. 1, the communication system 1 includes a management server 7, a communication network 6, and an electric vehicle 100 that can communicate with the management server 7 via the communication network 6.

[0028] The management server 7 is, for example, a computer including a CPU (Central Control Unit), various memories, and a communication interface. The management server 7 provides update information for various software to the multiple vehicles, and manages the update status of various software stored in each of the multiple vehicles. FIG. 1 shows an electric vehicle 100, which is one of the multiple vehicles, as an example. In the following description, information exchanged between the management server 7 and the electric vehicle 100 will be described, but the same applies to information exchanged between the management server 7 and other vehicles, and detailed description thereof will not be repeated.

[0029] In a storage device (not shown) of the management server 7, for example, identification information (hereinafter, referred to as a vehicle ID) that is unique information for identifying the electric vehicle 100 is stored in advance. The various software stored in the electric vehicle 100 includes, for example, control programs stored in each of a plurality of ECUs (Electronic Control Units) mounted on the electric vehicle 100. The management server 7 manages the identification information including the version information of the various software for each ECU of the electric vehicle 100. In the storage device of the management server 7, the version information of the software of the master ECU and the version information of the software of the slave ECU included in the electric vehicle 100 are stored in association with the vehicle ID, as described below. The management server 7 manages the version information of the software using a unique product number. When the management server 7 provides update information to the electric vehicle 100, the management server 7 manages the update status of the various software in the electric vehicle 100 using the product number corresponding to the provided update information.

[0030] For example, when software with a new part number (new version) is prepared, management server 7 requests electric vehicle 100 to update the control program, or provides software with the new part number to electric vehicle 100 in response to a request from electric vehicle 100.

[0031] Next, a specific configuration of the electric vehicle 100 in this embodiment will be described with reference to Fig. 2. Fig. 2 is a diagram that shows an example of the configuration of the electric vehicle 100 in this embodiment. As shown in Fig. 2, the electric vehicle 100 includes a master ECU 200, a slave ECU 210, a drive device 220, a DCM (Data Communication Module) 230, an ADS (Autonomous Driving System) 240, and a communication bus 250. The master ECU 200, the slave ECU 210, and the ADS 240 are communicatively connected via the communication bus 250.

[0032] The master ECU 200 is an ECU that instructs the slave ECU 210 to switch to software with an updated part number, which will be described later, and manages the update status of the software of each ECU including the master ECU 200. The master ECU 200 corresponds to a "master control device."

[0033] The master ECU 200 includes a CPU 201 and a memory 202. The CPU 201 executes a program stored in the memory 202, thereby executing various controls on a control target (for example, the DCM 230, etc.) of the master ECU 200. The memory 202 includes a first storage area 202A and a second storage area 202B. A control program for starting the master ECU 200 is stored in both the first storage area 202A and the second storage area 202B. The master ECU 200 sets one of the first storage area 202A and the second storage area 202B as a startup storage area, and at startup, executes the control program stored in the set startup storage area to start up. When the master ECU 200 receives update information from the management server 7 via the DCM 230, the master ECU 200 stores the control program updated using the update information in a storage area other than the storage area set as the startup storage area (hereinafter, may be referred to as an update storage area). When an updated program is stored in the update memory area, the master ECU 200 sets the update memory area as the startup memory area at the next startup, and also instructs the slave ECU 210 described later to set the update memory area as the startup memory area at the next startup.

[0034] Therefore, when the electric vehicle 100 is turned on (power on) by a start-up operation or the like by a user after the IG is turned off (power off), the updated control program stored in the startup storage area is executed and started in each of the master ECU 200 and the slave ECU 210. Note that the storage area that was set as the startup storage area until the start-up is set as an update storage area. Hereinafter, changing the startup storage area to set it anew may be referred to as switching the startup storage area.

[0035] The master ECU 200 acquires a product number of the updated control program stored in the slave ECU 210 (hereinafter referred to as an updated product number) from the management server 7 or the slave ECU 210, and stores it in the memory 202. Furthermore, the master ECU 200 acquires a product number of the control program being executed (hereinafter referred to as an execution product number) from the slave ECU 210, as will be described later, and stores it in the memory 202.

[0036] The DCM 230 is an in-vehicle communication module configured to be capable of wireless communication with the management server 7. The DCM 230 is configured to be capable of two-way data communication with the management server 7 in response to control signals from the master ECU 200. The DCM 230 is connected to the master ECU 200. The master ECU 200 transmits information about the electric vehicle 100, various requests, and the like to the management server 7 and receives update information for various software from the management server 7 via the DCM 230.

[0037] The slave ECU 210 includes a CPU 211 and a memory 212. The slave ECU 210 corresponds to a "slave control device." The CPU 211 executes a program stored in the memory 212, thereby executing various controls on a control target of the slave ECU 210 (for example, the drive device 220, etc.). The memory 212 includes a third storage area 212A and a fourth storage area 212B. A control program for starting the slave ECU 210 is stored in both the third storage area 212A and the fourth storage area 212B. The slave ECU 210 sets either the third storage area 212A or the fourth storage area 212B as a startup storage area, and at startup, executes the control program stored in the set startup storage area to start up. When the slave ECU 210 receives update information from the management server 7 via the DCM 230 and also receives an instruction from the master ECU 200 to switch the startup memory area, the slave ECU 210 sets the update memory area as the startup memory area for the next startup.

[0038] The drive device 220 is connected to the slave ECU 210 and performs a drive operation to drive the electric vehicle 100 in response to a control signal from the slave ECU 210. The drive device 220 includes, for example, a motor generator, a power storage device, and a PCU (Power Control Unit) (none of which are shown). The power storage device includes, for example, a secondary battery such as a nickel-metal hydride battery or a lithium-ion battery having a liquid or solid electrolyte, or a DC power source such as a capacitor. The PCU converts DC power from the power storage device into AC power and supplies it to the motor generator, or converts AC power generated in the motor generator into DC power and supplies it to the power storage device. The motor generator is a drive source for the electric vehicle 100 and also a power generation source, and drives the drive wheels to rotate or generates power by the rotation of the drive wheels. The drive device 220 may further include an internal combustion engine as a drive source or power generation source.

[0039] The ADS 240 is configured to be able to perform autonomous driving of the electric vehicle 100. Specifically, the ADS 240 acquires information (surrounding environment) indicating the state of the electric vehicle 100 from the master ECU 200, the slave ECU 210, and various sensors, and creates a travel plan using the acquired information, a destination, etc. The ADS 240 outputs various control requests for driving the electric vehicle 100 according to the created travel plan to the master ECU 200 and the slave ECU 210 that control various actuators including the drive unit 220.

[0040] In this embodiment, ADS240 is described as being built into electric vehicle 100, but it may also be configured as an autonomous driving kit that can be attached to a predetermined position, such as the roof top of electric vehicle 100, and can be removed from electric vehicle 100.

[0041] The electric vehicle 100 is driven in either an automatic driving mode in which automatic driving can be performed according to a control request from the ADS 240, or a manual driving mode in which driving can be performed according to various operations by the user (accelerator operation, brake operation, steering operation). As described above, an example has been described in which the master ECU 200 controls the DCM 230 and the slave ECU 210 controls the drive unit 220, but other actuators mounted on the electric vehicle 100 are controlled by at least one of the master ECU 200 and the slave ECU 210.

[0042] In the electric vehicle 100 having the above configuration, the functions of the master ECU 200 and the slave ECU 210 are realized by executing software as described above. The software stored in the master ECU 200 and the slave ECU 210 can be updated using update information received from the management server 7, thereby modifying existing functions and adding new functions. In order to properly execute the functions of the updated software, the master ECU 200 executes a consistency determination process (hereinafter, sometimes referred to as a version consistency check (VMC)) for checking whether or not a combination of execution part numbers of software executed in the master ECU 200 and the slave ECU 210 is consistent after the IG is turned on, for example.

[0043] For example, when the combination of execution part numbers in the master ECU 200 and the slave ECU 210 is a predetermined combination, the master ECU 200 determines that the combination of execution part numbers is consistent. The predetermined combination includes, for example, a combination of part numbers before and after an update. For example, when the combination of execution part numbers matches the combination of updated part numbers, the master ECU 200 can confirm that the switching of the startup storage area has been performed appropriately.

[0044] 3 is a diagram for explaining an example of operations performed by master ECU 200 and slave ECU 210. In FIG. 3, operation histories of master ECU 200 and slave ECU 210 are shown.

[0045] For example, when a start-up operation for starting up the system of electric vehicle 100 is performed by a user, electric vehicle 100 enters an IG-ON state, as shown in (A) of Fig. 3. When the IG-ON state is entered, power source power is supplied to master ECU 200 and slave ECU 210, whereby master ECU 200 and slave ECU 210 are started up.

[0046] At this time, it is assumed that the slave ECU 210 transmits an execution part number to the master ECU 200 after startup, for example, as shown in Fig. 3(B). The slave ECU 210 transmits, for example, the part number of the software stored in the startup storage area after startup as the execution part number to the master ECU 200. Note that the part number of the software stored in the startup storage area and the method of acquiring the software may be determined by known techniques, and detailed explanations thereof will not be given.

[0047] 3C, after the IG is turned on, the master ECU 200 executes VMC when it receives an execution part number for the first time from the slave ECU 210. This enables the master ECU 200 to determine whether the combination of the execution part numbers is consistent depending on whether the combination of the first execution part number of the software being executed in the master ECU 200 and the received second execution part number of the software being executed in the slave ECU 210 is a predetermined combination.

[0048] The master ECU 200 may, for example, acquire configuration information for a predetermined combination from the management server 7, or may acquire a combination of part numbers before and after the update as configuration information using update information received from the management server 7.

[0049] However, if the slave ECU 210 is restarted due to some malfunction, such as a momentary interruption in the power supply that supplies power to the slave ECU 210, after the master ECU 200 has instructed the slave ECU 210 to switch the startup memory area at the next startup and before the IG is turned off, the startup memory area may be switched only in the slave ECU 210.

[0050] For example, as shown in Fig. 3(D), if some malfunction occurs in slave ECU 210 and the slave ECU 210 is reset, the slave ECU 210 will restart as shown in Fig. 3(E). At this time, even if the execution part number is transmitted to master ECU 200 as shown in Fig. 3(F), VMC is not executed in master ECU 200. Therefore, until the next time master ECU 200 is started, the execution part number of master ECU 200 will be the part number before the update and the execution part number of slave ECU 210 will be the part number after the update, resulting in a period in which the combination of execution part numbers between master ECU 200 and slave ECU 210 is inconsistent.

[0051] 4 is a diagram for explaining an example of an operation when the combination of execution part numbers between the master ECU 200 and the slave ECU 210 is inconsistent. As shown in FIG. 4, the master ECU 200 includes a control unit 201A and a switching unit 201B. When updated software is stored in the update storage area, the control unit 201A transmits a switching instruction to the slave ECU 210 and the switching unit 201B in the master ECU 200 as shown in FIG. 4(A). Upon receiving the switching instruction from the control unit 201A, the switching units 201B and the slave ECU 210 each execute a switching process of the startup storage area as shown in FIG. 4(B) and (C), and set the update storage area as the startup storage area at the next startup (corresponding to the IG ON time shown in FIG. 4(G)).

[0052] However, if a momentary power interruption occurs in slave ECU 210 thereafter, as shown in Fig. 4(D), only slave ECU 210 is restarted. As a result, slave ECU 210 starts up using the updated software, and so during the period until the IG is turned off as shown in Fig. 4(F), the execution part number of master ECU 200 becomes the part number of the software before the update, and the execution part number of slave ECU 210 becomes the part number of the software after the update, resulting in a period in which the combination of execution part numbers is inconsistent.

[0053] Therefore, in this embodiment, the slave ECU 210 requests the master ECU 200 to execute a consistency determination process for determining whether or not the identification information (i.e., execution part number) of the software stored in the startup storage area is consistent between the master ECU 200 and the slave ECU 210 when the slave ECU 200 starts up and when the master ECU 200 receives a request from the slave ECU 210 to execute the consistency determination process (VMC).

[0054] In this way, when the slave ECU 210 is started up, the master ECU 200 is requested to execute the consistency determination process, and the consistency determination process is executed in the master ECU 200. Therefore, when the update storage area is set as the startup storage area at the next startup, even if only the slave ECU 210 is restarted due to a malfunction or the like, the master ECU 200 is requested to execute the consistency determination process at the time of restart. This makes it possible to detect an inconsistency in the combination of execution part numbers between the master ECU 200 and the slave ECU 210 at an early stage.

[0055] An example of the process executed by the master ECU 200 will be described below with reference to Fig. 5. Fig. 5 is a flowchart showing an example of the process executed by the master ECU 200. A series of processes shown in this flowchart is repeatedly executed by the master ECU 200 at predetermined processing intervals.

[0056] In step (hereinafter, step will be abbreviated as S) 100, master ECU 200 determines whether or not an initial check has not been performed. Master ECU 200 determines whether or not an initial check has not been performed, for example, based on the state of a flag indicating whether or not an initial check has been performed. Master ECU 200 determines that an initial check has not been performed, for example, when the flag is in an off state. Master ECU 200 may set the flag to an off state immediately after startup, or may set the flag to an off state when the IG is turned off. When master ECU 200 determines that an initial check has not been performed (YES in S100), the process proceeds to S102.

[0057] In S102, master ECU 200 determines whether all execution part numbers have been acquired. Master ECU 200 determines that all execution part numbers have been acquired when, for example, a first execution part number and a second execution part number have been acquired. Master ECU 200 acquires, for example, the part number of software stored in a startup storage area of ​​memory 202 as the first execution part number. Master ECU 200 acquires, for example, the second execution part number from slave ECU 210. If it is determined that all execution part numbers have been acquired (YES in S102), the process proceeds to S104.

[0058] At S104, master ECU 200 executes a consistency determination process. Master ECU 200 determines whether or not the combination of the first and second execution part numbers is a predetermined combination. For example, master ECU 200 compares the combination of the first and second execution part numbers with a predetermined combination stored in memory 202 to determine whether or not there is a match. The method of acquiring the predetermined combination is as described above, and therefore a detailed description thereof will not be repeated. Thereafter, the process proceeds to S108. If it is determined that not all execution part numbers have been acquired (NO at S102), the process proceeds to S106.

[0059] In S106, master ECU 200 determines whether the waiting time to receive the execution part number is longer than a predetermined time T1. The waiting time to receive the execution part number is, for example, the time that has elapsed since it was determined that the initial check had not been performed. The predetermined time T1 is adapted, for example, through experiments or the like. If it is determined that the waiting time to receive the execution part number is longer than the predetermined time T1 (YES in S106), processing proceeds to S116. Note that if it is determined that the waiting time to receive the execution part number is equal to or shorter than the predetermined time T1 (NO in S106), processing returns to S102.

[0060] In S108, master ECU 200 determines whether the first and second execution part numbers match. For example, master ECU 200 determines that the first and second execution part numbers match when the combination of the first and second execution part numbers is a predetermined combination such as a combination of part numbers of software before the update or a combination of part numbers of software after the update. If it is determined that the first and second execution part numbers match (YES in S108), the process proceeds to S110. If it is determined that the first and second execution part numbers do not match (NO in S108), the process proceeds to S116.

[0061] In S110, master ECU 200 transmits information indicating that the consistency determination process has been completed (hereinafter, referred to as a completion notification) to slave ECU 210. Thereafter, the process proceeds to S112.

[0062] In S112, master ECU 200 sets a flag indicating whether or not an initial check has been performed to an ON state, after which the process proceeds to S114.

[0063] In S114, the master ECU 200 sets the autonomous driving to an allowed state. When the autonomous driving is set to an allowed state, the autonomous driving of the electric vehicle 100 using the ADS 240 can be performed. Therefore, when the autonomous driving mode is selected in the electric vehicle 100, the autonomous driving using the ADS 240 is performed.

[0064] In S116, master ECU 200 sets the automatic driving to a non-permitted state. When the automatic driving is set to a non-permitted state, if the automatic driving mode is selected, the driving mode is switched to the manual driving mode. Furthermore, even if an operation to select the automatic driving mode is performed while the manual driving mode is selected, the selection of the automatic driving mode is rejected.

[0065] Next, an example of another process executed by the master ECU 200 will be described with reference to Fig. 6. Fig. 6 is a flowchart showing an example of another process executed by the master ECU 200. A series of processes shown in this flowchart is repeatedly executed by the master ECU 200 at predetermined processing intervals.

[0066] In S150, master ECU 200 determines whether or not an initial check has been performed. The method of determining whether or not an initial check has been performed is as described above, and therefore detailed description thereof will not be repeated. If it is determined that an initial check has been performed (YES in S150), the process proceeds to S152.

[0067] In S152, master ECU 200 determines whether or not to receive a VMC request from slave ECU 210. The "VMC request" includes a request to execute a consistency determination process. If it is determined that a VMC request is received from slave ECU 210 (YES in S152), the process proceeds to S154. If it is determined that a VMC request is not received (NO in S152), the process returns to S152.

[0068] In S154, the master ECU 200 executes the consistency determination process. Since the consistency determination process is as described above, detailed description thereof will not be repeated. Thereafter, the process proceeds to S156.

[0069] In S156, master ECU 200 determines whether the first and second execution part numbers match. The method of determination is as described above, and therefore detailed description thereof will not be repeated. If it is determined that the first and second execution part numbers match (YES in S156), the process proceeds to S158.

[0070] In S158, master ECU 200 transmits a completion notification to slave ECU 210. The completion notification is as described above, and therefore detailed description thereof will not be repeated.

[0071] At S160, master ECU 200 sets the autonomous driving permission state. The operation of electric vehicle 100 in the autonomous driving permission state is as described above, and detailed description thereof will not be repeated. Thereafter, processing returns to S152. Note that, if it is determined that the first execution part number and the second execution part number do not match (NO at S156), processing proceeds to S162.

[0072] In S162, master ECU 200 sets the autonomous driving to a non-permitted state. The operation of electric vehicle 100 in the autonomous driving non-permitted state is as described above, and therefore detailed description thereof will not be repeated. The process then ends. Note that, if it is determined that the initial check has not been performed (NO in S150), this process ends.

[0073] Next, an example of processing executed by the slave ECU 210 will be described with reference to Fig. 7. Fig. 7 is a flowchart showing an example of processing executed by the slave ECU 210. A series of processing shown in this flowchart is repeatedly executed by the slave ECU 210 at predetermined processing intervals.

[0074] In S200, slave ECU 210 determines whether it is startup time. Slave ECU 210 determines that it is startup time of slave ECU 210 when startup processing for starting slave ECU 210 is being executed, for example. If it is determined that it is startup time of slave ECU 210 (YES in S200), the process proceeds to S202.

[0075] In S202, slave ECU 210 transmits the second execution part number to master ECU 200. As the second execution part number has been described above, detailed description thereof will not be repeated. Thereafter, the process proceeds to S204.

[0076] In S204, slave ECU 210 transmits a VMC request. The VMC request is as described above, and detailed description thereof will not be repeated. Slave ECU 210 may transmit the VMC request intermittently every time a predetermined time elapses, or may transmit the VMC request continuously.

[0077] In S206, slave ECU 210 determines whether or not a completion notification has been received from master ECU 200. The completion notification has been described above, and detailed description thereof will not be repeated. If it is determined that a completion notification has been received (YES in S206), the process proceeds to S208.

[0078] In S208, slave ECU 210 stops transmitting the VMC request. If a completion notification is not received from master ECU 200 (NO in S206), the process proceeds to S210.

[0079] In S210, slave 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 time elapsed from the time when the VMC request is transmitted. The predetermined time T2 is adapted, for example, through experiments or the like. If it is determined that the waiting time for receiving the completion notification is longer than predetermined time T2 (YES in S210), the process proceeds to S208. If it is determined that the waiting time for receiving the completion notification is equal to or shorter than predetermined time T2 (NO in S210), the process returns to S206. If it is determined that slave ECU 210 is not at startup (NO in S200), this process ends.

[0080] An example of the operation of master ECU 200 and slave ECU 210 based on the above-described structure and flowchart will be described with reference to FIG.

[0081] Fig. 8 is a diagram for explaining an example of the operation of the master ECU 200 and an example of the operation of the slave ECU 210. Fig. 8 shows the operation history of the master ECU 200 and the slave ECU 210.

[0082] For example, when a user performs a start-up operation to start up the system of electric vehicle 100, electric vehicle 100 enters an IG-ON state as shown in Fig. 8(A) . When the IG-ON state is entered, power source power is supplied to master ECU 200 and slave ECU 210, whereby master ECU 200 and slave ECU 210 are started up.

[0083] When it is determined that the slave ECU 210 is at startup (YES in S200), the second execution part number is sent to the master ECU 200 (S202) as shown in (B-1) of Figure 8, and a VMC request is sent to the master ECU 200 (S204) as shown in (B-2) of Figure 8.

[0084] In the master ECU 200, when it is determined that the initial check has not been performed (YES in S100), it is determined whether or not all the execution part numbers have been received (S102). When the first execution part number is acquired and the second execution part number is received from the slave ECU 210, it is determined that all the execution part numbers have been received (YES in S102), and the VMC is executed (S104) as shown in FIG. 8 (C-1). When the VMC is executed and it is determined that the first execution part number and the second execution part number match (YES in S108), a completion notice is transmitted to the slave ECU 210 as shown in FIG. 8 (C-2) (S110). Thereafter, a flag indicating whether or not the initial check has been performed is set to an ON state (S112), and automatic driving is permitted (S114). When the completion notice is received in the slave ECU 210 (YES in S206), the transmission of the VMC request is stopped (S208).

[0085] For example, as shown in Fig. 8(D), a case is assumed in which slave ECU 210 is reset due to some malfunction. As a result, when slave ECU 210 restarts as shown in Fig. 8(E), when it is determined that it is startup (YES in S200), the second execution part number is transmitted to master ECU 200 (S202) as shown in Fig. 8(F-1). Then, as shown in Fig. 8(F-2), a VMC request is transmitted to master ECU 200 (S204).

[0086] When master ECU 200 determines that the initial check has been performed (YES in S150), and receives a VMC request from slave ECU 210 (YES in S152), VMC is executed (S154) as shown in FIG. 8 (G-1). When VMC is executed and it is determined that the first execution part number and the second execution part number match (YES in S156), a completion notification is transmitted to slave ECU 210 (S158) as shown in FIG. 8 (G-2). Thereafter, autonomous driving is permitted (S160). When slave ECU 210 receives a completion notification (YES in S206), transmission of the VMC request is stopped (S208).

[0087] In this way, the second execution part number and the VMC request are transmitted to the slave ECU 210 every time the slave ECU 210 is started. Furthermore, in the master ECU 200, if the initial check has not been performed, the VMC is performed by receiving the second execution part number from the slave ECU 210. Furthermore, in the master ECU 200, if the initial check has been performed, the VMC is performed by receiving the VMC request from the slave ECU 210.

[0088] Therefore, for example, in a case where updated software is stored in the update storage areas of master ECU 200 and slave ECU 210 and the update storage areas are set as startup storage areas at the next startup, even if some malfunction occurs in slave ECU 210 before the IG is turned off, causing the slave ECU 210 to restart and start up using the updated software, VMC is promptly executed in response to a VMC request from slave ECU 210 to master ECU 200. If it is determined by execution of VMC that the first execution part number and the second execution part number do not match (NO in S156), automatic driving is disabled (S162), and execution of the function using the updated software only in slave ECU 210 is suppressed.

[0089] As described above, according to the in-vehicle system of the present embodiment, a request is made to the master ECU 200 to execute VMC every time the slave ECU 210 is started, and the master ECU 200 executes VMC. Therefore, in a case where the update storage area is set as the startup storage area at the next startup, even if only the slave ECU 210 is restarted due to a malfunction or the like, a VMC request is transmitted to the master ECU 200 at the time of restart. This makes it possible to detect an inconsistency in the combination of execution part numbers in the master ECU 200 and the slave ECU 210 at an early stage. Therefore, it is possible to provide an in-vehicle system and a control device that can detect an inconsistency in the combination of software identification information at an early stage in a plurality of control devices.

[0090] Furthermore, if it is determined by execution of the VMC that the first execution part number and the second execution part number are not consistent, the execution of a function realized by the software stored in the startup storage area (for example, automatic driving using the ADS240) is not permitted (prohibited). In this way, it is possible to prevent a function such as automatic driving from being executed in a state in which the first execution part number and the second execution part number are not consistent.

[0091] Modifications will be described below.

[0092] In the above embodiment, a configuration in which the multiple ECUs mounted on electric vehicle 100 include master ECU 200 and slave ECU 210 has been described as an example, but the multiple ECUs may include master ECU 200 and multiple slave ECUs. In this modification, for example, a configuration in which the multiple ECUs mounted on electric vehicle 100 include master ECU 200, first slave ECU 210A, and second slave ECU 210B will be described as an example.

[0093] Fig. 9 is a diagram that shows an example of the configuration of an electric vehicle 100 in a modified example. The electric vehicle 100 shown in Fig. 9 differs from the configuration of the electric vehicle 100 shown in Fig. 2 in that it includes a first slave ECU 210A instead of the slave ECU 210, and further includes a second slave ECU 210B. The rest of the configuration is similar and is denoted by the same reference numerals. Therefore, detailed description thereof will not be repeated.

[0094] 2, and the second slave ECU 210B is different from the first slave ECU 210A in the detection targets of sensors, the control targets (for example, the steering system and the brake system), and the control operations. The other configurations are similar to those of the slave ECU 210. Therefore, detailed description of the first slave ECU 210A and the second slave ECU 210B will not be repeated.

[0095] Even in a configuration including multiple slave ECUs, problems similar to those occurring when there is a single slave ECU may occur.

[0096] Fig. 10 is a diagram for explaining an example of operations performed by master ECU 200 and a plurality of slave ECUs in the modified example. Fig. 10 shows operation histories of master ECU 200, first slave ECU 210A, and second slave ECU 210B.

[0097] For example, when a start-up operation for starting up the system of electric vehicle 100 is performed by a user, electric vehicle 100 enters an IG-ON state as shown in (A) of Fig. 10. When the IG-ON state is entered, power source power is supplied to each of master ECU 200, first slave ECU 210A, and second slave ECU 210B, thereby starting up master ECU 200, first slave ECU 210A, and second slave ECU 210B.

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

[0099] Furthermore, it is assumed that the second slave ECU 210B, like the first slave ECU 210A, transmits to the master ECU 200, for example, as shown in (C) of FIG. 10, the product number of the software to be stored in the startup memory area of ​​the memory of the second slave ECU 210B after startup as an execution product number.

[0100] As shown in (D) of Fig. 10, after the IG is turned on, the master ECU 200 executes VMC by receiving execution part numbers from each of the first slave ECU 210A and the second slave ECU 210B. This allows the master ECU 200 to determine whether the combination of the execution part numbers is consistent or not, depending on whether the combination of the first execution part number of the software being executed in the master ECU 200, the received second execution part number of the software being executed in the first slave ECU 210A, and the received third execution part number of the software being executed in each second slave ECU is a predetermined combination. The predetermined combination of execution part numbers is obtained in the same way as the predetermined combination of two execution part numbers in the above-mentioned embodiment. Therefore, detailed description thereof will not be repeated.

[0101] However, in this case as well, as in the above-described embodiment, after the master ECU 200 has instructed each of the first slave ECU 210A and the second slave ECU 210B to switch the startup memory area at the next startup, and before the IG is turned off, if either of the first slave ECU 210A or the second slave ECU 210B is restarted due to some malfunction such as a momentary power interruption, the startup memory area may be switched only in that slave ECU.

[0102] For example, as shown in FIG. 10E, when the first slave ECU 210A is reset due to some malfunction, the first slave ECU 210A is restarted. At this time, even if the execution part number is transmitted to the master ECU 200 as shown in FIG. 10F, the master ECU 200 does not execute VMC. Therefore, until the next time the master ECU 200 and the second slave ECU 210B are started, the execution part numbers of the master ECU 200 and the second ECU 210B are the part numbers before the update, and the execution part number of the first slave ECU 210A is the part number after the update, so that a period occurs in which the combination of the execution part numbers of the master ECU 200, the first slave ECU 210A, and the second slave ECU 210B is inconsistent. This may also occur when some malfunction occurs in the second slave ECU 210B.

[0103] Therefore, in this modification, the first slave ECU 210A and the second slave ECU 210B request the master ECU 200 to execute a consistency determination process for determining whether or not the identification information (i.e., execution product number) of the software stored in the startup storage area is consistent between the master ECU 200, the first slave ECU 210A, and the second slave ECU 210B at the time of startup of the master ECU 200 and when a request to execute the consistency determination process is received from the first slave ECU 210A or the second slave ECU 210B, the master ECU 200 executes the consistency determination process (VMC).

[0104] In this way, when the first slave ECU 210A or the second slave ECU 210B is started, the master ECU 200 is requested to execute the consistency determination process, and the consistency determination process is executed in the master ECU 200. Therefore, when the update storage area is set as the startup storage area at the next startup, even if the first slave ECU 210A or the second slave ECU 210B is restarted due to a malfunction or the like, the master ECU 200 is requested to execute the consistency determination process at the time of restart. This makes it possible to detect early inconsistencies in the combinations of execution part numbers among the master ECU 200, the first slave ECU 210A, and the second slave ECU 210B.

[0105] Hereinafter, an example of processing executed by the master ECU 200 in the modified example will be described with reference to Fig. 11. Fig. 11 is a flowchart showing an example of processing executed by the master ECU 200 in the modified example. A series of processing shown in this flowchart is repeatedly executed by the master ECU 200 at predetermined processing intervals.

[0106] The flowchart of Fig. 11 differs from the flowchart of Fig. 5 in that the processes of S300, S302, S304, S306 and S308 are executed instead of the processes of S102, S104, S106, S108 and S110. In the flowchart of Fig. 11, the same step numbers are assigned to the same processes as those in the flowchart of Fig. 5, and the process contents are also the same except as described below. Therefore, detailed description thereof will not be repeated.

[0107] If it is determined that the initial check has not been performed in master ECU 200 (YES in S100), the process proceeds to S300.

[0108] In S300, master ECU 200 determines whether all execution part numbers have been acquired. Master ECU 200 determines that all execution part numbers have been acquired when, for example, first execution part number, second execution part number, and third execution part number have been acquired. Master ECU 200 acquires, for example, the part number of software stored in a startup storage area of ​​memory 212 as the first execution part number. Master ECU 200 acquires, for example, the second execution part number from first slave ECU 210A. Furthermore, master ECU 200 acquires, for example, the third execution part number from second slave ECU 210B. If it is determined that all execution part numbers have been received (YES in S300), the process proceeds to S302.

[0109] In S302, master ECU 200 executes a consistency determination process. Master ECU 200 determines whether or not the combination of the first execution part number, the second execution part number, and the third execution part number is a predetermined combination. Thereafter, the process proceeds to S308. If it is determined that not all execution part numbers have been acquired (NO in S300), the process proceeds to S304.

[0110] In S304, master ECU 200 determines whether the reception waiting time for the execution part number is longer than predetermined time T1. The reception waiting time and predetermined time T1 have been described above, and therefore detailed description thereof will not be repeated. If it is determined that the reception waiting time for the execution part number is longer than predetermined time T1 (YES in S304), the process proceeds to S116. If it is determined that the reception waiting time for the execution part number is equal to or shorter than predetermined time T1 (NO in S304), the process returns to S300.

[0111] In S306, master ECU 200 determines whether the first, second, and third execution part numbers are consistent. For example, master ECU 200 determines that the first, second, and third execution part numbers are consistent when the combination of the first, second, and third execution part numbers is a predetermined combination such as a combination of part numbers of software before an update or a combination of part numbers of software after an update. If it is determined that the first, second, and third execution part numbers are consistent (YES in S306), the process proceeds to S308. If it is determined that the first, second, and third execution part numbers are not consistent (NO in S306), the process proceeds to S116.

[0112] In S308, the master ECU 200 transmits a completion notification of the consistency determination process at the time of the master startup (hereinafter, referred to as a completion notification at the time of the master startup). The master ECU 200 transmits the completion notification at the time of the master startup to each of the first slave ECU 210A and the second slave ECU 210B. After that, the process proceeds to S112.

[0113] Next, an example of another process executed by the master ECU 200 in the modified example will be described with reference to Fig. 12. Fig. 12 is a flowchart showing an example of another process executed by the master ECU 200 in the modified example. A series of processes shown in this flowchart is repeatedly executed by the master ECU 200 at predetermined processing intervals.

[0114] The flowchart of Fig. 12 differs from the flowchart of Fig. 6 in that instead of the processes of S152, S154, S156, and S158, the processes of S400, S402, S404, S406, S408, S410, S412, S414, and S416 are executed. In the flowchart of Fig. 12, the same step numbers are assigned to the same processes as those in the flowchart of Fig. 6, and the process contents are also the same except as described below. Therefore, detailed description thereof will not be repeated.

[0115] If it is determined that the initial check has been performed in master ECU 200 (YES in S150), the process proceeds to S400.

[0116] In S400, master ECU 200 determines whether or not it has received a VMC state confirmation (n) (n is 1 or 2). For example, master ECU 200 determines that it has received a VMC state confirmation (n) when it receives a VMC state confirmation (1) from first slave ECU 210A or when it receives a VMC state confirmation (2) from second slave ECU 210B. Details of VMC state confirmation (1) and VMC state confirmation (2) will be described later. If it is determined that it has received a VMC state confirmation (n) (YES in S400), the process proceeds to S402. Note that if it is determined that it has not received a VMC state confirmation (n) (NO in S400), the process returns to S400.

[0117] In S402, master ECU 200 determines whether or not to receive VMC state confirmation (m) (m is 1 or 2 other than n). If master ECU 200 receives VMC state confirmation (1) in S400, it determines whether or not to receive VMC state confirmation (2). Alternatively, if master ECU 200 receives VMC state confirmation (2) in S400, it determines whether or not to receive VMC state confirmation (1). If it is determined that VMC state confirmation (m) has been received (YES in S402), the process proceeds to S404. Note that if it is determined that VMC state confirmation (m) has not been received (NO in S402), the process proceeds to S406.

[0118] In S404, master ECU 200 does not permit transmission of VMC possible (m), which is a notification indicating that VMC can be performed. For example, when master ECU 200 receives VMC state confirmation (1) in S400, master ECU 200 does not permit transmission of VMC possible (2) to second slave ECU 210B. Also, for example, when master ECU 200 receives VMC state confirmation (2) in S400, master ECU 200 does not permit transmission of VMC possible (1) to first slave ECU 210A. Thereafter, the process proceeds to S406.

[0119] In S406, the master ECU 200 transmits VMC possible (n). For example, when the master ECU 200 receives a VMC state confirmation (1) in S400, the master ECU 200 transmits VMC possible (1) to the first slave ECU 210A. VMC possible (1) includes information indicating that VMC can be performed at the request of the first slave ECU 210A. Furthermore, for example, when the master ECU 200 receives a VMC state confirmation (2) in S400, the master ECU 200 transmits VMC possible (2) to the second slave ECU 210B. VMC possible (2) includes information indicating that VMC can be performed at the request of the second slave ECU 210B. Thereafter, the process proceeds to S408.

[0120] In S408, master ECU 200 determines whether or not VMC request (n) is received. For example, when master ECU 200 receives VMC state confirmation (1) in S400, master ECU 200 determines that VMC request (n) is received when VMC request (1) from first slave ECU 210A is received. VMC request (1) includes a VMC execution request to master ECU 200 whose transmission source is first slave ECU 210A. Also, for example, when master ECU 200 receives VMC state confirmation (2) in S400, master ECU 200 determines that VMC request (n) is received when VMC request (2) from second slave ECU 210B is received. VMC request (2) includes a VMC execution request to master ECU 200 whose transmission source is second slave ECU 210B. If it is determined that a VMC request (n) has been received (YES at S408), the process proceeds to S410.

[0121] In S410, master ECU 200 executes a consistency determination process. The consistency determination process is similar to the process of S302, and therefore detailed description thereof will not be repeated. Thereafter, the process proceeds to S414. If it is determined that a VMC request (n) has not been received (NO in S408), the process proceeds to S412.

[0122] In S412, master ECU 200 determines whether or not a VMC request (m) has been received. For example, when master ECU 200 receives VMC state check (1) in S400, it determines that a VMC request (m) has been received when it receives VMC request (2). For example, when master ECU 200 receives VMC state check (2) in S400, it determines that a VMC request (m) has been received when it receives VMC request (1). If it is determined that a VMC request (m) has been received (YES in S412), the process returns to S408. Note that if it is determined that a VMC request (m) has not been received (NO in S412), the process returns to S408.

[0123] At S414, master ECU 200 determines whether the first, second, and third execution part numbers are consistent. The method of determination is as described above, and therefore detailed description thereof will not be repeated. If it is determined that the first, second, and third execution part numbers are consistent (YES at S414), processing proceeds to S416. However, if it is determined that the first, second, and third execution part numbers are not consistent (NO at S414), processing proceeds to S162.

[0124] In S416, master ECU 200 transmits a completion notification. Master ECU 200 transmits the completion notification to each of first slave ECU 210A and second slave ECU 210B. Thereafter, the process proceeds to S418.

[0125] In S418, master ECU 200 permits transmission of VMC possible (m). Master ECU 200, for example, permits transmission of VMC possible (m) after disallowing transmission in S404. Thereafter, the process proceeds to S160.

[0126] Next, an example of a process executed by each of the first slave ECU 210A and the second slave ECU 210B will be described with reference to FIG. 13. FIG. 13 is a flowchart showing an example of another process executed by each of the first slave ECU 210A and the second slave ECU 210B in the modified example. Note that "n" shown in the flowchart shown in FIG. 13 is a value indicating an execution subject. For example, when n=1, the flowchart in FIG. 13 shows a process executed by the first slave ECU 210A. Also, when n=2, the flowchart in FIG. 13 shows a process executed by the second slave ECU 210B. In the following description, a case where the execution subject of the process shown in the flowchart in FIG. 13 is the first slave ECU 210A will be described as an example. The case where the execution subject is the second slave ECU 210B is the same, so detailed description thereof will not be repeated.

[0127] In S500, first slave ECU 210A determines whether or not it is startup. The method of determination is the same as the method of determination in the process of S200 described above, and therefore detailed description thereof will not be repeated. If it is determined that it is startup (YES in S500), the process proceeds to S502. Note that if it is determined that it is not startup (NO in S500), this process ends.

[0128] In S502, the first slave ECU 210A transmits the second execution part number as the execution part number (n) to the master ECU 200. Thereafter, the process proceeds to S504.

[0129] In S504, the first slave ECU 210A transmits the VMC state confirmation (1) as the VMC state confirmation (n) to the master ECU 200. Thereafter, the process proceeds to S506.

[0130] In S506, the first slave ECU 210A determines whether or not a master startup completion notification has been received. If it is determined that a master startup completion notification has been received (YES in S506), the process proceeds to S508.

[0131] In S508, the first slave ECU 210A stops transmitting the VMC state check (1) and the VMC request (1). For example, if the VMC state check (1) is being transmitted, the first slave ECU 210A stops transmitting the VMC state check (1). Also, for example, if the VMC state check (1) and the VMC request (1) are being transmitted, the first slave ECU 210A stops transmitting the VMC state check (1) and the VMC request (1). Note that if it is determined that the completion notification at the time of master startup has not been received (NO in S506), the process proceeds to S510.

[0132] In S510, first slave ECU 210A determines whether or not VMC possible (n) is received from master ECU 200. When first slave ECU 210A receives VMC possible (1) from master ECU 200, it determines that VMC possible (n) has been received. If it is determined that VMC possible (n) has been received (YES in S510), the process proceeds to S512. Note that if it is determined that VMC possible (1) has not been received (NO in S510), the process returns to S506.

[0133] In S512, the first slave ECU 210A transmits a VMC request (n) to the master ECU 200. The first slave ECU 210A transmits the VMC request (1) as the VMC request (n) to the master ECU 200. Thereafter, the process proceeds to S514.

[0134] In S514, first slave ECU 210A determines whether or not a completion notification has been received from master ECU 200. If it is determined that the completion notification has been received (YES in S514), the process proceeds to S508. On the other hand, if it is determined that the completion notification has not been received (NO in S514), the process proceeds to S516.

[0135] In S516, first slave ECU 210A determines whether the waiting time for receiving the completion notification is longer than predetermined time T2. The waiting time for receiving the completion notification and predetermined time T2 have been described above, and therefore detailed description thereof will not be repeated. If it is determined that the waiting time for receiving the completion notification is longer than predetermined time T2 (YES in S516), control proceeds to S508. Note that if it is determined that the waiting time for receiving the completion notification is equal to or shorter than predetermined time T2 (NO in S516), control returns to S514.

[0136] An example of the operations of the master ECU 200, the first slave ECU 210A, and the second slave ECU 210B in this modified example based on the above-described flowchart will be described with reference to FIG.

[0137] 14 is a diagram for explaining an example of the operation of the master ECU 200 and an example of the operation of each slave ECU in the modified example. In FIG 14, the operation history of the master ECU 200, the first slave ECU 210A, and the second slave ECU 210B is shown.

[0138] For example, when a start-up operation for starting up the system of electric vehicle 100 is performed by a user, electric vehicle 100 enters an IG-ON state as shown in (A) of Fig. 14. When the IG-ON state is entered, power source power is supplied to each of master ECU 200, first slave ECU 210A, and second slave ECU 210B, thereby starting up master ECU 200, first slave ECU 210A, and second slave ECU 210B.

[0139] When it is determined that the first slave ECU 210A is starting up (YES at S500), the second execution part number is sent to the master ECU 200 (S502), as shown in FIG. 14 (B-1), and a VMC status confirmation (1) is sent to the master ECU 200 (S504), as shown in FIG. 14 (B-2).

[0140] Similarly, when it is determined that the second slave ECU 210B is starting up (YES at S500), the third execution part number is sent to the master ECU 200 (S502), as shown in FIG. 14 (C-1), and a VMC status confirmation (2) is sent to the master ECU 200 (S504), as shown in FIG. 14 (C-2).

[0141] In the master ECU 200, when it is determined that the initial check has not been performed (YES in S100), it is determined whether or not all the execution part numbers have been received (S300). When the first execution part number is acquired, the second execution part number is received from the first slave ECU 210A, and the third execution part number is received from the second slave ECU 210B, it is determined that all the execution part numbers have been received (YES in S300), and as shown in FIG. 14 (D-1), the VMC is executed (S302). When it is determined that the first execution part number, the second execution part number, and the third execution part number match after the VMC is executed (YES in S306), a completion notification at the time of master startup is transmitted to each of the first slave ECU 210A and the second slave ECU 210B (S308). Thereafter, a flag indicating whether or not the initial check has been performed is set to an on state (S112), and automatic driving is permitted (S114).

[0142] When the first slave ECU 210A receives a completion notification of the master startup (YES in S506), the transmission of the VMC state check (1) is stopped (S508). Furthermore, when the second slave ECU 210B receives a completion notification of the master startup (YES in S506), the transmission of the VMC state check (2) is stopped (S508).

[0143] For example, as shown in Fig. 14(E), first slave ECU 210A is reset due to some malfunction. If first slave ECU 210A is restarted, when it is determined that it is startup (YES in S500), the second execution part number is transmitted to master ECU 200 (S502) as shown in Fig. 14(F-1). Then, as shown in Fig. 14(F-2), a VMC state check (1) is transmitted to master ECU 200 (S504).

[0144] When it is determined that the initial check has been performed (YES in S150), master ECU 200 receives a VMC state confirmation (1) from first slave ECU 210A. If master ECU 200 does not receive a VMC state confirmation (2) (NO in S402), master ECU 200 transmits VMC possible (1) to first slave ECU 210A (S406), as shown in (I) of FIG.

[0145] In the first slave ECU 210A, if the first slave ECU 210A does not receive a completion notification at master startup (NO at S506) but receives VMC possible (1) (YES at S510), a VMC request (1) is sent to the master ECU 200 (S512), as shown in (J) of FIG. 14.

[0146] When master ECU 200 receives VMC request (1) (YES in S408), VMC is executed (S410) as shown in Fig. 14(K). When VMC is executed, it is determined whether the first execution part number, the second execution part number, and the third execution part number are consistent.

[0147] During execution of VMC, for example, if the second slave ECU 210B is reset due to some malfunction and restarts, as shown in FIG. 14(G), when it is determined that it is startup time (YES in S500), as shown in FIG. 14(H-1), the third execution part number is transmitted to the master ECU 200 (S502), and, as shown in FIG. 14(H-2), a VMC status confirmation (2) is transmitted to the master ECU 200 (S504).

[0148] When the master ECU 200 determines that the first, second, and third execution part numbers are consistent (YES in S414), a completion notification is sent to the first slave ECU 210A as shown in Fig. 14(L-1), and a completion notification is sent to the second slave ECU 210B as shown in Fig. 14(L-2) (S416). Then, the permission for sending VMC possible (2) is maintained (S418), and autonomous driving is permitted (S160).

[0149] When first slave ECU 210A receives the completion notification (YES in S514), the transmission of VMC state confirmation (1) and VMC request (1) is stopped (S508).

[0150] On the other hand, since the second slave ECU 210B continues to send the VMC state confirmation (2) to the master ECU 200, it is determined that the VMC state confirmation (2) has been received (YES in S400), and if the VMC state confirmation (1) has not been received (NO in S402), VMC possible (2) is sent to the second slave ECU 210B (S406), as shown in (M) of Figure 14.

[0151] In the second slave ECU 210B, if the second slave ECU 210B does not receive a completion notification at the time of master startup (NO in S506) but receives VMC possible (2) (YES in S510), as shown in (N) of Figure 14, a VMC request (2) is sent to the master ECU 200 (S512).

[0152] When master ECU 200 receives VMC request (2) (YES in S408), VMC is executed (S410) as shown in (O) of Fig. 14. When VMC is executed, it is determined whether the first execution part number, the second execution part number, and the third execution part number are consistent.

[0153] When the master ECU 200 determines that the first, second, and third execution part numbers are consistent (YES in S414), a completion notification is sent to the first slave ECU 210A as shown in (P-1) of Fig. 14, and a completion notification is sent to the second slave ECU 210B as shown in (P-2) of Fig. 14 (S416). Then, the permission for sending VMC possible (1) is maintained (S418), and autonomous driving is permitted (S160).

[0154] When the second slave ECU 210B receives the completion notification (YES in S514), the transmission of the VMC state confirmation (2) and the VMC request (2) is stopped (S508).

[0155] In this way, the first slave ECU 210A transmits the second execution part number and VMC status check (1) every time it is started, and if VMC execution is possible, transmits a VMC request (1). Furthermore, the second slave ECU 210B transmits the third execution part number and VMC status check (2) every time it is started, and if VMC execution is possible, transmits a VMC request (2).

[0156] Furthermore, in the master ECU 200, if an initial check has not been performed, VMC is executed by receiving the second execution part number and the third execution part number. Furthermore, in the master ECU 200, if an initial check has been performed, VMC is executed by receiving a VMC request (1) after transmitting and receiving a VMC state check (1) and VMC possible (1). Alternatively, in the master ECU 200, if an initial check has been performed, VMC is executed by receiving a VMC request (2) after transmitting and receiving a VMC state check (2) and VMC possible (2).

[0157] Therefore, for example, when updated software is stored in the update storage areas of the master ECU 200, the first slave ECU 210A, and the second slave ECU 210B, and the update storage areas are set as startup storage areas at the next startup, even if some malfunction occurs in at least one of the first slave ECU 210A and the second slave ECU 210B before the IG is turned off, causing restart and startup using the updated software, VMC is promptly executed in response to a VMC request from the first slave ECU 210A or the second slave ECU 210B. When it is determined by execution of VMC that the first execution part number, the second execution part number, and the third execution part number are not consistent (NO in S414), automatic driving is disabled (S162), and execution of the function using the updated software is suppressed only in the first slave ECU 210A or the second slave ECU 210B.

[0158] As described above, according to the in-vehicle system of this modified example, even when the in-vehicle system includes two or more slave ECUs, it is possible to detect inconsistencies in the combination of software identification information in a plurality of control devices at an early stage.

[0159] It is assumed that when the initial check has been performed (YES in S150), both the first slave ECU 210A and the second slave ECU 210B are restarted at different times due to some malfunction, and a VMC state confirmation (2) is received immediately after receiving a VMC state confirmation (1). In this case, transmission of VMC possible (2) in response to reception of the VMC state confirmation (2) is suppressed because transmission of VMC possible (2) is not permitted until the next completion notification is transmitted. In this manner, it is possible to suppress requests for VMC execution from both the first slave ECU 210A and the second slave ECU 210B in parallel.

[0160] In this modification, when a VMC completion notification for a VMC request (1) is received from the first slave ECU 210A, if the transmission of a VMC state confirmation (2) from the second slave ECU 210B continues, VMC is executed by transmitting and receiving VMC possible (2) and VMC request (2) from the master ECU 200. However, for example, the necessity of executing VMC may be determined using the notification content of the completion notification (for example, whether the execution part numbers are consistent or not). For example, if the notification content of the completion notification indicates that the execution part numbers are consistent, it is determined not to execute VMC redundantly, or if the notification content of the completion notification indicates that the execution part numbers are not consistent, it is determined to execute VMC again. In this way, it is possible to prevent unnecessary execution of VMC.

[0161] Furthermore, in this modification, when the initial check has been performed, the case where VMC is executed in response to a VMC request from either one of first slave ECU 210A or second slave ECU 210B and the case where VMC is executed in response to a VMC request from the other has been described as an example, but when VMC is executed in response to a VMC request from one, VMC may not be executed even if a VMC request is received from the other ECU. In this way, it is possible to prevent VMC from being executed unnecessarily.

[0162] Furthermore, in this modified example, when an initial check has already been performed, VMC is executed in response to a VMC request from either the first slave ECU 210A or the second slave ECU 210B, and after a completion notification is received, VMC is executed in response to a VMC request from the other ECU. However, if a completion notification is not received for a certain period of time, VMC may be executed in response to a VMC request from the other ECU.

[0163] The above-described modified examples may be implemented in whole or in part in appropriate combination.

[0164] The embodiments disclosed herein should be considered to be illustrative and not restrictive in all respects. The scope of the present invention is defined by the claims, not the above description, and is intended to include all modifications within the meaning and scope of the claims. [Explanation of symbols]

[0165] 1 communication system, 6 communication network, 7 management server, 100 electric vehicle, 200 master ECU, 201 CPU, 201A control unit, 201B switching unit, 202, 212 memory, 202A first storage area, 202B second storage area, 210 slave ECU, 210A first slave ECU, 210B second slave ECU, 212A third storage area, 212B fourth storage area, 220 drive device, 250 communication bus.

Claims

1. An in-vehicle system including a plurality of control devices that can be activated using the software stored in a startup storage area, the in-vehicle system including a plurality of control devices that can be activated using the software stored in the startup storage area, the in-vehicle system comprising: The plurality of control devices include a master control device and a slave control device, when software stored in a storage area different from the startup storage area is updated in the slave control device, the master control device executes 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; When the slave control device receives the switching instruction, the slave control device sets the startup storage area at the next startup, and requests the master control device to execute a consistency determination process for determining whether or not the identification information of the software stored in the startup storage area is consistent between the multiple control devices at each startup. the master control device executes the consistency determination process when a request to execute the consistency determination process is received from the slave control device; the master control device transmits a completion notification to the slave control device after completing the consistency determination process; The slave control device uses the completion notification to determine whether or not to request execution of the consistency determination process.

2. 2. The in-vehicle system according to claim 1, wherein the master control device prohibits execution of a function realized by the software when it is determined that identification information of the software stored in the startup memory area is not consistent among the multiple control devices.

3. The slave control device includes: requesting the master control device to determine whether or not the consistency determination process can be executed at the time of startup; The in-vehicle system according to claim 1 , further comprising: a determination unit that determines whether or not to request execution of the consistency determination process using the execution possibility determination result and the completion notification from the master control device.

4. the slave control device includes a first control device and a second control device; The in-vehicle system of claim 3, wherein when the master control device receives a determination request from the first control device as to whether or not the execution is possible, the master control device transmits a determination result to the first control device indicating that the consistency determination process is possible when the master control device has not received the determination request from the second control device before the determination request from the first control device.

5. 5. The in-vehicle system according to claim 4, wherein the master control device prohibits transmission of the determination result to the second control device when the second control device requests a determination of whether or not execution is possible after the first control device requests a determination of whether or not execution is possible.

6. the master control device transmits to the slave control device a first completion notification of the consistency determination process executed at the time of startup and a second completion notification of the consistency determination process executed when execution of the consistency determination process is requested from the slave control device; An in-vehicle system as described in any one of claims 1 to 5, wherein the slave control device stops requesting execution of the consistency determination process when it receives the first completion notification and when it receives the second completion notification, and requests execution of the consistency determination process when it does not receive the first completion notification.

7. A control device of a plurality of control devices that sets one of a plurality of storage areas set as storage areas for storing software as a startup storage area and can be started up using the software stored in the startup storage area, when software stored in a storage area different from the startup storage area is updated in the other control device, the control device executes a switching instruction to the other control device to set the storage area in which the updated software is stored as the startup storage area; When the other control device receives the switching instruction, the setting of the startup storage area is performed at the next startup, and the control device is requested to execute a consistency determination process for determining whether or not the identification information of the software stored in the startup storage area is consistent between the multiple control devices at each startup. the control device executes the consistency determination process when receiving a request to execute the consistency determination process from the other control device; The control device transmits a completion notification to the other control device after completing the consistency determination process; The other control device uses the completion notification to determine whether or not to request execution of the consistency determination process.

8. A control device of a plurality of control devices that sets one of a plurality of storage areas set as storage areas for storing software as a startup storage area and can be started up using the software stored in the startup storage area, When the control device receives a switching instruction to set the startup memory area to the memory area in which the updated software is stored in a case where software stored in a memory area different from the startup memory area is updated, the control device sets the startup memory area at the next startup and requests a master control device among the multiple control devices to execute a consistency determination process for determining whether or not identification information of the software stored in the startup memory area is consistent between the multiple control devices at each startup, the master control device executes the consistency determination process when a request for execution of the consistency determination process is received from the control device; a completion notification is sent to the control device after the consistency determination process is completed in the master control device; The control device determines whether or not to request execution of the consistency determination process using the completion notification.

Images