WO2025069251A1 - Software update device, software update method, and software update system - Google Patents

Abstract

After transmitting a preparation request for software update of an ECU (40) of a vehicle, a software update device (2) shifts the vehicle to the travel prohibition state, starts clocking by a timer, determines whether or not a prescribed time has elapsed, and releases the travel prohibition state of the vehicle when it is determined that the prescribed time has elapsed.

Description

Software update device, software update method and software update system

The present invention relates to a software update device, a software update method, and a software update system.

A technology is known in which, after an update processing unit has confirmed that the vehicle has transitioned to a driving-prohibited state, update information for the software program is sent to the ECU, and when a state control unit has confirmed that the update process has been completed, the transition of the vehicle to the driving-prohibited state is released (Patent Document 1).

JP 2019-86963 A

However, the technology described in Patent Document 1 has the problem that if the state control unit cannot confirm the completion of the update process, such as when an abnormality occurs and update completion information is not sent or received, the vehicle remains in a traveling prohibited state, and the vehicle cannot start traveling.

The problem that this invention aims to solve is to provide a software update device, a software update method, and a software update system that allow the vehicle to start driving even after the software update of the vehicle has been completed and the completion of the software update cannot be confirmed.

The present invention solves the above problem by sending a preparation request for a software update of the vehicle's ECU, starting timing using a timer, determining whether a predetermined time has elapsed, transitioning the vehicle to a traveling prohibited state, and releasing the traveling prohibited state of the vehicle if it is determined that the predetermined time has elapsed.

According to the present invention, even if the completion of the vehicle software update cannot be confirmed after the vehicle software update is completed, the vehicle can be started to be driven.

FIG. 1 is a block diagram showing an example of a software update system according to a first embodiment of the present invention. FIG. 2 is a diagram showing an example of a sequence chart of a control process of the software updating method in normal operation, which is executed by the software updating device according to the first embodiment. FIG. 3 is a diagram showing an example of a sequence chart of a control process of the software updating method in the event of an abnormality, which is executed by the software updating device according to the first embodiment. FIG. 4 is a diagram showing an example of a sequence chart of a control process of the software updating method in the event of an abnormality, which is executed by the software updating device according to the first embodiment. FIG. 5 is a diagram showing an example of a sequence chart of a control process of the software updating method in the event of an abnormality, which is executed by the software updating device according to the first embodiment. FIG. 6 is a block diagram showing an example of a software update system according to the first embodiment of the present invention. FIG. 7 is a block diagram of a software update system according to the second embodiment of the present invention.

Below, an embodiment of a software update device, software update method, and software update system according to the present invention will be described with reference to the drawings.

First Embodiment
1 is a block diagram of a software update system according to a first embodiment of the present invention. The software update system 100 includes a server 1 and a software update device 2. The software update system 100 is a system for transmitting and receiving data between the server 1 and a vehicle equipped with the software update device 2 via OTA communication (wireless communication), and is used for updating software (firmware) of an electronic control unit (ECU) included in the software update device 2. The software update system 100 is not limited to communication between a vehicle and the server 1, and may also be used for communication between vehicles (connected function between vehicles) or communication between the server 1 and a user communication terminal.

The server 1 stores update data for updating the ECU software in a database, and transmits the update data to the vehicle in response to an update request. The update data is the latest software data. The update data may include the time required for the software update. The server 1 manages campaigns including vehicle identification information (VIN) and ECU identification information (e.g., ECU name) on the database. For example, when the latest version of the ECU software is uploaded, the server 1 transmits an update request signal to obtain information required for software update from the vehicle. The update request signal may include identification information (ID) of the software to be updated or the ECU. In response to a request from the server 1, the vehicle software update device 2 transmits a signal including ECU update information (version information) to the server 1. The server 1 determines whether the ECU software is the latest version from the update information. If the server 1 determines that the current version of the ECU is old, it transmits the latest software (update data, repro data) to the vehicle. The vehicle software update device 2 downloads the update data transmitted from the server 1. The software update device 2 then uses the update data to update the software of the ECU to be updated.

The vehicle user can instruct the software to be updated via the HMI (Human Machine Interface) installed in the vehicle or a communication terminal (user communication terminal) owned by the user. The HMI and user communication terminal are equipped with information output devices such as a display and speaker, and are connected to the server 1 via OTA communication. The HMI is an interface for outputting and inputting information between the vehicle user and the vehicle system. Instructions regarding the software update include accepting or canceling the update. The software update instruction may include an instruction to perform the update immediately or at a specified time. The user can also check the progress of the software update and the update contents on the screen of the HMI or user communication terminal.

The software update device 2 is a device that controls software updates of the vehicle's ECU (target ECU 40). The software update device 2 includes an IVI (in-vehicle infotainment) 10, a GW (Gateway) 20, a BCM (Body Control Module) 30, and a target ECU 40. The IVI 10, GW 20, BCM 30, and target ECU 40 are connected by a communication network such as CAN or LIN, and are capable of transmitting and receiving data to and from each other. The target ECU 40 may be a single ECU or multiple ECUs. The ECUs are connected to each other by a communication network such as CAN or LIN, and are capable of transmitting and receiving data to and from each other. For the sake of explanation, the IVI 10, GW 20, and BCM 30 are described separately from the target ECU 40, but the IVI 10, GW 20, and BCM 30 are also examples of ECUs that are targets for software updates.

The target ECU 40 is an ECU that is the target of a software update. The target ECUs 40 include body system ECUs, driving system ECUs, multimedia system ECUs, and power system ECUs. Each ECU has functional blocks such as a microcomputer consisting of a CPU (Central Processing Unit), ROM (Read Only Memory), RAM (Random Access Memory), and flash memory, as well as a power supply circuit, a data transfer circuit, etc. The flash memory stores programs for realizing the ECU's software. The ECU's software is realized when the microcomputer executes the programs stored in the flash memory to perform various processes.

The target ECU 40 also has a memory that stores software. In the software update sequence control, the target ECU 40 performs data communication with the IVI 10 to transmit version information of the target ECU 40, install update data, and activate the update data. More specifically, when the target ECU 40 receives update data, the software included in the update data is written to the memory of the target ECU (installation). With the old and new software stored in the memory, the target ECU 40 switches the software to be processed from the old software to the new software (activation). In this embodiment, such processing for software update does not necessarily have to be performed in a series of steps, and the target ECU 40 may first install the software, and then perform activation when it receives a separate update start request. In this embodiment, the target ECU 40 performs data communication with the IVI 10 in the software update sequence control, but this is not limited to this, and the target ECU 40 may perform data communication with the GW 20. Details will be described later.

IVI10 is a controller consisting of a microcomputer including a processor, and provides the user with information related to vehicle driving, such as map information and traffic information, and entertainment information such as music and video, via the HMI. IVI10 is an example of the "first controller" in the claims. That is, in this embodiment, IVI10 has an information providing function of controlling an HMI such as an in-vehicle display to provide information to the user, as well as a function related to software updates of the vehicle's ECU. Specifically, as shown in FIG. 1, IVI10 has, as functional blocks, an update control unit 101 that controls software updates of the target ECU 40, and a determination unit 102 that uses a timer to determine whether a predetermined time has elapsed. IVI10 transmits and receives data between the server 1 and the ECU via OTA communication using the update control unit 101. When IVI10 acquires update data for a software update, it executes an update control process. In this embodiment, the IVI 10 is described as the "first controller" in the claims, but this is not limiting and the "first controller" may be another controller.

Here, the update control process of IVI10 will be described. In order to update the software of the ECU, the software update device 2 connects to the server 1 via OTA communication and receives update data from the server 1. When the IVI10 receives the update data, it obtains consent for the software update from the user. The IVI10 proposes the software update to the user via the vehicle's HMI and accepts an instruction to execute the software update from the user. When the user instructs to execute the software update, the IVI10 transmits a preparation request for the software update to the GW20. The preparation request for the software update is a signal (preparation request signal) for requesting that the vehicle be put into a state in which the software update can be executed. The state in which the software update can be executed is a driving prohibition state in which the vehicle is prohibited from driving. For example, the BCM30 prohibits the start switch (ignition switch or power switch) from being turned on. This prevents the vehicle from driving during the software update. When the process of transitioning to a traveling prohibited state in the BCM 30 is completed, the GW 20 transmits a state transition completion to the IVI 10. The state transition completion is a signal (transition completion signal) indicating that the transition to a state in which a software update can be performed has been completed.

When the IVI 10 receives a state transition completion from the GW 20, it transmits the update data received from the server 1 to the target ECU 40. At this time, an update start request may be transmitted to the target ECU 40 together with the update data, or the update data may be transmitted to the target ECU 40 first, and the update start request may be transmitted after the update data is installed in the target ECU 40. The update start request is a signal (update start request signal) for requesting to start a software update. When the update start request is received, the target ECU 40 is activated. In addition, the update start request may be transmitted directly from the IVI 10 to the target ECU 40, or the update start request may be transmitted from the IVI 10 to the target ECU 40 via the GW 20. When the target ECU 40 receives the update start request, it executes a software update based on the update data.

When the IVI 10 receives update completion from the target ECU 40, it transmits update completion to the GW 20. Update completion is a signal (update completion signal) indicating that the software update in the target ECU 40 has been completed. When the GW 20 has completed releasing the vehicle's driving prohibition state in the BCM 30, it transmits release completion to the IVI 10. Release completion is a signal (release completion signal) indicating that the vehicle's driving prohibition state has been released. When the IVI 10 receives release completion from the GW 20, it transmits update completion to the server 1.

Furthermore, the IVI10 executes a judgment process using a timer by the judgment unit 102 to judge whether or not a predetermined time has elapsed. In this embodiment, the predetermined time includes a first predetermined time, a second predetermined time, and a third predetermined time. These times are threshold times used in the judgment process in each controller (IVI10, GW20, BCM30). In the judgment process in the IVI10, the second predetermined time is used as the threshold for the judgment process. The first predetermined time and the third predetermined time will be described later. In the judgment process, the IVI10 starts timing using the timer when a command to execute a software update is received from the user. For example, timing of the elapsed time starts after a request to prepare for the software update is sent.

The IVI10 judges whether the second predetermined time has elapsed based on the elapsed time. For example, the second predetermined time is the time required for the software update. The second predetermined time is set based on the time required for the software update. For example, the second predetermined time is set to the time required for the software update. If the time required for the software update is 15 minutes, the second predetermined time is set to 15 minutes. If the IVI10 judges that the second predetermined time has elapsed, it transmits a request to terminate the software update to the GW20. Specifically, the IVI10 judges at regular intervals whether the elapsed time measured by the timer has reached the second predetermined time, and judges that the second predetermined time has elapsed when the elapsed time has reached the second predetermined time. If the elapsed time has not reached the second predetermined time, the IVI10 judges that the second predetermined time has not elapsed, and continues to execute the judgment process at regular intervals. The request to terminate the software update is a signal (termination request signal) for requesting the software update to be terminated.

As described above, in this embodiment, when the IVI 10 receives update completion from the target ECU 40 or when it determines that the second predetermined time has elapsed, it transmits a termination request to the GW 20. This allows the IVI 10 to transmit a termination request to the GW 20 as time elapses, even if the target ECU 40 does not transmit update completion for some reason. Note that in this embodiment, it is not essential that the IVI 10 (first controller) is provided with the determination unit 102, and this may be applied appropriately as necessary.

The GW20 is a controller composed of a microcomputer including a processor, and is a unit (gateway) that relays communication between each unit such as an ECU. The GW20 is an example of a "second controller" in the claims. That is, the GW20 has a relay function for relaying communication between the IVI10 and the BCM30, as well as a judgment function for using a timer to judge whether a predetermined time has elapsed. Specifically, as shown in FIG. 1, the GW20 has a relay unit 201 and a judgment unit 202 as functional blocks. Note that in this embodiment, the GW20 is described as a "second controller" in the claims, but is not limited to this, and the "second controller" may be another controller.

The GW20 transmits and receives information between the IVI10 and the BCM30 via the relay unit 201. When the GW20 receives a software update preparation request from the IVI10, it transmits a request to transition the vehicle to a traveling prohibited state to the BCM30. The request to transition the vehicle to a traveling prohibited state is a signal (transition request signal) requesting that the vehicle state be transitioned to a traveling prohibited state. In addition, when the GW20 receives a software update preparation request from the IVI10, it may transmit an execution approval to the IVI10. The execution approval is a signal (execution approval signal) approving the transition of the vehicle to a traveling prohibited state.

The GW20 receives a state transition completion from the BCM30. When the GW20 receives the state transition completion from the BCM30, it transmits the state transition completion to the IVI10. When the IVI10 receives the state transition completion, it transmits an update start request to the target ECU40. This causes a software update to be performed in the target ECU. After the software update is completed, the IVI10 transmits a software update end request to the GW20.

When the GW20 receives a request to end the software update from the IVI10, it sends a release request to the BCM30. The release request is a signal (release request signal) requesting that the vehicle's travel prohibition state be released. When the GW20 receives a request to end the software update from the IVI10, it may send an execution approval to the IVI10. The execution approval is a signal (execution approval signal) approving the release of the vehicle's travel prohibition state. The BCM30 that receives the release request releases the vehicle's travel prohibition state and sends a release completion to the GW20. The release completion is a signal (release completion signal) indicating that the vehicle's travel prohibition state has been released. When the GW20 receives the release completion from the BCM30, it sends a release completion to the IVI10.

Furthermore, the GW20 executes a judgment process using a timer by the judgment unit 202 to judge whether or not a predetermined time has elapsed. The specific method of the judgment process is similar to the judgment process in the IVI10, and may be used as appropriate. In the judgment process in the GW20, the first predetermined time is used as a threshold value for the judgment process. In the judgment process, when the GW20 receives a software update preparation request from the IVI10, the GW20 starts timing using a timer to judge whether or not the first predetermined time has elapsed. The first predetermined time is longer than the second predetermined time. The first predetermined time is set based on the time required for the software update. For example, the first predetermined time is set to a time longer than the time required for the software update. When the second predetermined time is 15 minutes, the first predetermined time is longer than 15 minutes, for example, 16 minutes. When the GW20 judges that the first predetermined time has elapsed, it transmits a release request to the BCM30. In this embodiment, by setting the length of time used in the determination process to a different value, it is determined that the predetermined time has elapsed in GW20 at a later timing than when it is determined that the predetermined time has elapsed in IVI10. However, this is not limited to the above, and the timing at which the timer in GW20 starts counting may be set to be later than that of IVI10.

In this embodiment, when the GW 20 receives a software update termination request from the IVI 10 or when it determines that the first predetermined time has elapsed, it transmits a cancellation request to the BCM 30. This allows the GW 20 to transmit a cancellation request to the BCM 30 in response to the passage of time, even if the IVI 10 does not transmit a software update termination request for some reason. Note that in this embodiment, it is not essential that the GW 20 (second controller) is provided with a determination unit 202, and this may be applied appropriately as necessary.

The BCM 30 is a controller composed of a microcomputer including a processor, and is an ECU that controls the overall functions of the vehicle body. The BCM 30 is an example of a "third controller" in the claims. That is, in addition to the function of controlling the overall functions of the vehicle body, the BCM 30 has a vehicle state control function that controls the state of the vehicle. Specifically, as shown in FIG. 1, the BCM 30 has, as functional blocks, a vehicle state control unit 301 that controls the transition and release of the vehicle's travel prohibited state, and a determination unit 302 that uses a timer to determine whether a predetermined time has elapsed. Note that in this embodiment, the BCM 30 is described as the "third controller" in the claims, but is not limited to this, and the "third controller" may be another controller.

After sending a software update preparation request, the BCM 30 causes the vehicle to transition to a driving prohibited state by the vehicle state control unit 301. For example, when a transition request is received from the GW 20, the BCM 30 transitions the vehicle to a driving prohibited state. In the driving prohibited state, the BCM 30 prohibits the vehicle's ignition switch from being turned on. When the BCM 30 transitions the vehicle to a driving prohibited state, it transmits a state transition completion to the GW 20. The state transition completion is a signal (transition completion signal) indicating that the vehicle has transitioned to a state in which a software update can be performed (driving prohibited state).

When the BCM 30 receives a release request from the GW 20, the vehicle state control unit 301 releases the vehicle's travel prohibition state. For example, the BCM 30 allows the vehicle ignition to be turned on. When the BCM 30 releases the vehicle's travel prohibition state, it transmits a release completion to the GW 20. The release completion is a signal (release completion signal) indicating that the vehicle's travel prohibition state has been released.

The BCM 30 executes a judgment process using a timer by the judgment unit 302 to judge whether or not a predetermined time has elapsed. The specific method of the judgment process is similar to the judgment process in the IVI 10, and may be used as appropriate. In the judgment process in the BCM 30, the third predetermined time is used as a threshold value for the judgment process. In the judgment process, when the BCM 30 receives a transition request from the GW 20, the BCM 30 starts timing using a timer and judges whether or not the third predetermined time has elapsed. The third predetermined time is longer than the time required for the software update. For example, the third predetermined time is longer than the first predetermined time. If the first predetermined time is 16 minutes, the third predetermined time is, for example, 40 minutes. When the BCM 30 judges that the third predetermined time has elapsed, it releases the travel prohibition state of the vehicle. In this embodiment, by setting different lengths of time to be used in the determination process, the BCM 30 determines that a predetermined time has elapsed at a later timing than the IVI 10 and GW 20 determine that a predetermined time has elapsed, but this is not limited thereto, and the BCM 30 may start timing the timer later than the IVI 10 and GW 20.

In other words, in this embodiment, the BCM 30 releases the vehicle's travel prohibition state when it receives a release request from the GW 20 or when it determines that the third predetermined time has elapsed. As a result, even if the GW 20 does not send a release request for some reason, the BCM 30 can release the vehicle's travel prohibition state as time passes. As described above, in this embodiment, as a measure to be taken when an abnormality occurs in the IVI 10 and the GW 20, a timer is also provided in the BCM 30, and the determination unit determines whether or not a predetermined time has elapsed. The reason that the third predetermined time is longer than the first predetermined time and the second predetermined time is to prioritize the execution of processing in the normal system where the IVI 10 and the GW 20 are normal over processing in the abnormal system where an abnormality occurs in the IVI 10 and the GW 20.

Next, the procedure of the control process of the software update method executed by the software update device according to the first embodiment will be described with reference to FIG. 2. FIG. 2 is a diagram showing an example of a sequence chart of the control process of the software update method executed by the software update device according to the first embodiment under normal circumstances. The control process shown in FIG. 2 is an example of the control process when a determination process is not executed in each controller. In other words, FIG. 2 shows an example of the control process when each controller functions normally, rather than the control process when an abnormality occurs in each controller and information cannot be sent or received.

In step S1, the server 1 transmits update data to the IVI 10. In step S2, the IVI 10 transmits a software update preparation request to the GW 20. In step S3, the GW 20 transmits execution approval to the IVI 10. In step S4, the GW 20 transmits a transition request to the BCM 30. In step S5, the BCM 30 transitions the vehicle to a prohibited driving state. In step S6, the BCM 30 transmits a state transition completion to the GW 20. In step S7, the GW 20 transmits a state transition completion to the IVI 10. In step S8, the IVI 10 transmits an update start request to the target ECU 40. At this time, the update data may be transmitted together with the update start request, or the update data may be transmitted first. In step S9, the target ECU 40 performs a software update based on the update data in accordance with the update start request. In step S10, after the software update, the target ECU 40 transmits a completion of the update to the IVI 10.

In step S11, IVI10 sends a request to GW20 to end the software update. In step S12, GW20 sends an execution approval to IVI10. In step S13, GW20 sends a release request to BCM30. In step S14, BCM30 releases the vehicle's travel prohibition state. In step S15, BCM30 sends a release completion to GW20. In step S16, GW20 sends a release completion to IVI10. In step S17, IVI10 sends an update completion to server 1.

Next, the procedure of the control process of the software update method executed by the software update device according to the first embodiment will be described with reference to FIG. 3. FIG. 3 is a diagram showing an example of a sequence chart of the control process of the software update method executed by the software update device according to the first embodiment when an abnormality occurs. The control process shown in FIG. 3 is an example of the control process when a judgment process is executed in each controller. FIG. 3 shows an example of the control process when the IVI 10 is provided with a judgment unit and judges whether or not a predetermined time has elapsed. FIG. 3 shows a sequence chart in which a step (step S21) of starting timekeeping in the IVI 10 and a step (step S22) of judging that a second predetermined time has elapsed are added to the sequence chart of FIG. 2. The explanation of the same steps as in FIG. 2 will be omitted, and the explanation of FIG. 2 will be used as appropriate. Also, the example of FIG. 3 shows a situation in which an abnormality has occurred in the communication between the target ECU 40 and the IVI 10 for some reason, and the IVI 10 cannot receive the update completion from the target ECU 40.

As shown in FIG. 3, when the server 1 transmits update data to the IVI 10 (step S1), the IVI 10 transmits a preparation request to the GW 20 (step S2) and then starts timing using a timer (step S21). Then, when the IVI 10 determines in step S22 that the second predetermined time has elapsed, it transmits a termination request to the GW 20 (step S11). This allows the IVI 10 to transmit a termination request to the GW 20 even if an abnormality occurs for some reason in the communication between the target ECU 40 and the IVI 10 and the IVI 10 is unable to receive a completion of the update from the target ECU 40. The GW 20 that receives the termination request transmits a release request to the BCM 30, and the BCM 30 can release the vehicle's travel prohibition state.

Next, the procedure of the control process of the software update method executed by the software update device according to the first embodiment will be described with reference to FIG. 4. FIG. 4 is a diagram showing an example of a sequence chart of the control process of the software update method executed by the software update device according to the first embodiment when an abnormality occurs. The control process shown in FIG. 4 is an example of the control process when a judgment process is executed in each controller. FIG. 4 shows an example of the control process when the GW 20 has a judgment unit and judges that a predetermined time has elapsed. FIG. 4 shows a sequence chart in which a step (step S31) of starting clocking in the GW 20 and a step (step S32) of judging that a first predetermined time has elapsed are added to the sequence chart of FIG. 3. The explanation of the same steps as in FIG. 2 and FIG. 3 will be omitted, and the explanation of FIG. 2 and FIG. 3 will be used as appropriate. Also, the example of FIG. 4 shows a situation in which an abnormality has occurred in the communication between the IVI 10 and the GW 20 for some reason, and the GW 20 cannot receive a termination request from the IVI 10.

As shown in FIG. 4, when the IVI 10 sends a preparation request to the GW 20 (step S2), the GW 20 sends an execution approval to the IVI 10 (step S3) and then starts timing using a timer (step S31). Then, when the GW 20 determines in step S32 that the first predetermined time has elapsed, it sends a release request to the BCM 30 (step S13). This allows the GW 20 to send a release request to the BCM 30 even if an abnormality occurs in the communication between the IVI 10 and the GW 20 for some reason and the GW 20 cannot receive the termination request from the IVI 10. The BCM 30 that receives the release request can release the travel prohibition state of the vehicle.

Next, the procedure of the control process of the software update method executed by the software update device according to the first embodiment will be described with reference to FIG. 5. FIG. 5 is a diagram showing an example of a sequence chart of the control process of the software update method executed by the software update device according to the first embodiment when an abnormality occurs. The control process shown in FIG. 5 is an example of the control process when a judgment process is executed in each controller. FIG. 5 shows an example of the control process when the BCM 30 has a judgment unit and judges that a predetermined time has elapsed. FIG. 5 shows a sequence chart in which a step (step S51) of starting timekeeping in the BCM 30 and a step (step S52) of judging that a third predetermined time has elapsed are added to the sequence chart of FIG. 4. The explanation of the same steps as in FIG. 2, 3, and 4 will be omitted, and the explanations of FIG. 2, 3, and 4 will be used as appropriate. In addition, the example of FIG. 5 shows a situation in which an abnormality has occurred in the communication between the GW 20 and the BCM 30 for some reason, and a release request cannot be received from the GW 20.

As shown in FIG. 5, when the GW20 sends a transition request to the BCM30 (step S4), the BCM30 transitions the vehicle to a traveling prohibited state (step S5) and then starts timing using a timer (step S51). Then, when the BCM30 determines in step S52 that the third predetermined time has elapsed, it releases the traveling prohibited state of the vehicle (step S14). This allows the BCM30 to release the traveling prohibited state of the vehicle even if an abnormality occurs for some reason in the communication between the GW20 and the BCM30 and the BCM30 cannot receive a release request from the GW20.

In this embodiment, IVI10 (first controller), GW20 (second controller), and BCM30 (third controller) each have a judgment unit. In the software update system, IVI10 and GW20 control and manage the system, so if an abnormality occurs in the system, the control and management side can take action by providing timers in IVI10 and GW20 to perform judgment processing. However, there are cases where an abnormality occurs in IVI10 and GW20, which are the control and management side of the system. As a last resort in such cases, a timer is also provided on the BCM30 side to perform judgment processing.

Note that the examples of the controller having a judgment unit are not limited to the above. Either IVI10 or GW20, which are the control/management side, may have a judgment unit. For example, IVI10 may not have a judgment unit, and GW20 and BCM30 may have a judgment unit. GW20 may not have a judgment unit, and IVI10 and BCM30 may have a judgment unit. BCM30 may not have a judgment unit, and IVI10 and GW20, which are the control/management side, may have a judgment unit. In other examples, IVI10 and GW20 may not have a judgment unit, and BCM30 may have a judgment unit. GW20 and BCM30 may not have a judgment unit, and IVI10 may have a judgment unit. IVI10 and BCM30 may not have a judgment unit, and GW20 may have a judgment unit. The configuration and processing in each embodiment will not be described here, but the above-mentioned explanations of the configuration and processing will be used as appropriate.

In addition, in this embodiment, in the sequence control of the software update, the target ECU 40 performs data communication with the IVI 10, but this is not limited thereto, and the target ECU 40 may perform data communication with the GW 20. FIG. 6 is a block diagram showing an example of a software update system according to the first embodiment. FIG. 6 is a diagram showing an example of a case where data is transmitted and received between the GW 20 and the target ECU 40, rather than between the IVI 10 and the target ECU 40, in the software update system of FIG. 1. As shown in FIG. 6, the IVI 10 may transmit update data and an update start request to the target ECU 40 via the GW 20, and receive update completion from the target ECU 40 via the GW 20.

As described above, the software update device according to this embodiment includes an update control unit that controls software updates of the vehicle's ECU, a vehicle state control unit that controls transition and release of the vehicle's travel-prohibited state, and a determination unit that uses a timer to determine whether or not a predetermined time has elapsed. The update control unit transmits a software update preparation request. The determination unit starts timing with the timer after the update control unit transmits the software update preparation request, and determines whether or not the predetermined time has elapsed. After the update control unit transmits the software update preparation request, the vehicle state control unit transitions the vehicle to a travel-prohibited state, and releases the vehicle's travel-prohibited state if the determination unit determines that the predetermined time has elapsed. This allows the vehicle to start traveling after the vehicle's software update is completed, even if the completion of the vehicle's software update cannot be confirmed.

As described above, in the software update method according to this embodiment, the software update device transmits a preparation request for a software update of the vehicle's ECU, transitions the vehicle to a driving prohibition state after transmitting the software update preparation request, starts timing using a timer after transmitting the software update preparation request, determines whether a predetermined time has elapsed, and releases the vehicle's driving prohibition state if it determines that the predetermined time has elapsed. This allows the vehicle to start driving even if the completion of the vehicle's software update cannot be confirmed after the vehicle's software update has been completed.

As described above, the software update system according to this embodiment includes an ECU for a vehicle, an update control unit that controls software updates for the ECU, a vehicle state control unit that controls transition and release of the vehicle's travel-prohibited state, and a determination unit that uses a timer to determine whether or not a predetermined time has elapsed. The update control unit transmits a software update preparation request. The determination unit starts timing using a timer after the update control unit transmits the software update preparation request, and determines whether or not the predetermined time has elapsed. After the update control unit transmits the software update preparation request, the vehicle state control unit transitions the vehicle to a travel-prohibited state, and releases the vehicle's travel-prohibited state if the determination unit determines that the predetermined time has elapsed. This allows the vehicle to start traveling after the vehicle software update is completed, even if the completion of the vehicle software update cannot be confirmed.

The software update device according to this embodiment includes a first controller having an update control unit, a second controller having a determination unit, and a third controller having a vehicle state control unit. The first controller transmits a software update preparation request to the second controller by the update control unit. When the second controller receives the software update preparation request from the first controller, it transmits a request to transition the vehicle to a traveling prohibited state to the third controller, and the determination unit starts timing by a timer to determine whether a first predetermined time has elapsed. When it determines that the first predetermined time has elapsed, it transmits a request to release the traveling prohibited state of the vehicle to the third controller. When the third controller receives a request to transition the vehicle to a traveling prohibited state from the second controller, it transitions the vehicle to a traveling prohibited state by the vehicle state control unit, and when it receives a request to release the traveling prohibited state of the vehicle from the second controller, it releases the traveling prohibited state of the vehicle by the vehicle state control unit. As a result, even if the completion of the software update of the vehicle cannot be confirmed in the third controller due to some abnormality occurring in the first controller, the vehicle can start traveling after the software update of the vehicle is completed.

In addition, in the software update device according to this embodiment, the first controller further includes a determination unit, and when an instruction to execute a software update is received from the user of the vehicle, the first controller transmits a software update preparation request to the second controller via the update control unit, and the determination unit starts timing using a timer to determine whether a second predetermined time has elapsed, and when it is determined that the second predetermined time has elapsed, transmits a software update termination request to the second controller. When the second controller receives a software update termination request from the first controller, it transmits a request to release the vehicle's travel prohibition state to the third controller. As a result, even if some abnormality occurs in the communication between the first controller and the ECU that is the target of the software update, the request to release the travel prohibition state is transmitted to the third controller, so that the vehicle can start traveling after the vehicle's software update is completed.

Furthermore, in the software update device according to this embodiment, the first predetermined time is longer than the second predetermined time. As a result, if a request to end the software update is not sent from the first controller even after the second predetermined time has elapsed, a request to release the travel prohibition state can be sent to the third controller according to the determination of the elapsed time in the second controller.

In addition, in the software update device according to this embodiment, the third controller further includes a determination unit, and when a request to transition to a vehicle driving prohibited state is received from the second controller, the determination unit starts timing using a timer to determine whether or not a third predetermined time has elapsed, and when it is determined that the third predetermined time has elapsed, the vehicle state control unit releases the vehicle's driving prohibited state. As a result, even if a request to release the driving prohibited state is not sent to the third controller due to some abnormality occurring in the first controller or the second controller, the vehicle can start driving after the software update for the vehicle is completed.

Furthermore, in the software update device according to this embodiment, the third predetermined time is longer than the first predetermined time. As a result, if a request to release the travel prohibition state is not sent from the second controller even after the first predetermined time has elapsed, the travel prohibition state can be released according to the determination of the elapsed time in the third controller.

In addition, in the software update device according to this embodiment, the vehicle state control unit prohibits the vehicle's ignition switch from being turned on when the vehicle is in a driving prohibited state. This makes it possible to prevent the ignition switch from being turned on during a software update.

In addition, in the software update device according to this embodiment, the determination unit sets the predetermined time based on the time required for the software update, which is included in the update data for the software update. This allows the vehicle to start traveling when the time required for the software update has elapsed, even if the completion of the vehicle software update cannot be confirmed.

<<Second embodiment>>
In the first embodiment, the GW 20 provided between the IVI 10 and the BCM 30 relays the transmission and reception of information, but in the second embodiment, the IVI 10 and the BCM 30 directly transmit and receive information. A software update system according to a second embodiment of the present invention will be described with reference to FIG. 7. FIG. 7 is a block diagram of a software update system according to a second embodiment of the present invention. The configuration other than the configuration described below is the same as that of the first embodiment described above, and in the following description, the same configuration and control process as those of the first embodiment will be omitted, but the description of the first embodiment will be appropriately used in the omitted description.

In the second embodiment, IVI10 (first controller) includes an update control unit 101 and a judgment unit 102. BCM30 (second controller) includes a vehicle state control unit 301 and a judgment unit 302. When IVI10 receives update data from the server 1, it transmits a software update preparation request to BCM30 via the update control unit 101. When IVI10 receives a state transition completion from BCM30, it transmits an update start request to the target ECU40. When IVI10 receives an update completion from the target ECU40, it transmits a cancellation request to BCM30. When IVI10 receives an update completion from BCM30, it transmits an update completion to the server 1. After transmitting the preparation request, IVI10 may start timing using a timer via the judgment unit 102 and determine whether a second predetermined time has elapsed. If the IVI 10 determines that the second predetermined time has elapsed, it sends a release request to the BCM 30.

When the BCM 30 receives a software update preparation request from the IVI 10, the vehicle state control unit 301 transitions the vehicle to a driving prohibition state. After transitioning the vehicle to a driving prohibition state, the BCM 30 transmits a state transition completion to the IVI 10. When the BCM 30 receives a release request from the IVI 10, it releases the vehicle's driving prohibition state. After releasing the vehicle's driving prohibition state, the BCM 30 transmits a release completion to the IVI 10. After transitioning the vehicle to a driving prohibition state, the BCM 30 starts timing using a timer using the determination unit 302 and determines whether or not a first predetermined time has elapsed. When the BCM 30 determines that the first predetermined time has elapsed, the vehicle state control unit 301 releases the vehicle's driving prohibition state. After releasing the vehicle's driving prohibition state, the BCM 30 transmits a release completion to the IVI 10.

In this embodiment, IVI10 (first controller) includes an update control unit and a judgment unit, and BCM30 (second controller) includes a vehicle state control unit and a judgment unit, but examples of controllers including a judgment unit are not limited to this. BCM30 may not include a judgment unit, and IVI10 may include a judgment unit. IVI10 may not include a judgment unit, and BCM30 may include a judgment unit.

As described above, the software update device according to this embodiment includes a first controller having an update control unit, and a second controller having a determination unit and a vehicle state control unit. The first controller transmits a software update preparation request to the second controller via the update control unit. When the second controller receives the software update preparation request from the first controller, the vehicle state control unit transitions the vehicle to a driving prohibition state, and the determination unit starts timing using a timer to determine whether a first predetermined time has elapsed, and when it is determined that the first predetermined time has elapsed, the vehicle state control unit releases the vehicle's driving prohibition state. As a result, even if the second controller is unable to confirm the completion of the vehicle's software update due to some abnormality occurring in the first controller, the vehicle can start driving after the vehicle's software update is completed.

The above-described embodiments have been described to facilitate understanding of the present invention, and are not intended to limit the present invention. Therefore, each element disclosed in the above embodiments is intended to include all design modifications and equivalents that fall within the technical scope of the present invention.

100: Software update system 1: Server 2: Software update device 101: Update control unit 102, 202, 302: Determination unit 301: Vehicle state control unit

Claims (11)

An update control unit that controls software updates of an ECU of a vehicle;
a vehicle state control unit that controls transition and release of the vehicle to a traveling prohibited state;
A determination unit that determines whether or not a predetermined time has elapsed using a timer,
The update control unit transmits a preparation request for the software update,
the determination unit starts time measurement by the timer after the update control unit transmits a preparation request for the software update, and determines whether or not the predetermined time has elapsed;
The vehicle state control unit is
After the update control unit transmits the software update preparation request, the vehicle is transitioned to a traveling prohibited state,
The software update device, when the determination unit determines that the predetermined time has elapsed, releases a travel prohibition state of the vehicle. 2. The software update device according to claim 1,
a first controller including the update control unit, a second controller including the determination unit, and a third controller including the vehicle state control unit,
The first controller is
transmitting a preparation request for the software update to the second controller by the update control unit;
The second controller is
when a preparation request for the software update is received from the first controller, a request for transitioning the vehicle to a traveling prohibited state is transmitted to the third controller, and the determination unit starts time measurement by the timer to determine whether a first predetermined time has elapsed;
When it is determined that the first predetermined time has elapsed, a request to release the travel prohibition state of the vehicle is transmitted to the third controller;
The third controller is
When a request for transitioning the vehicle to a traveling prohibited state is received from the second controller, the vehicle state control unit transitions the vehicle to a traveling prohibited state,
When a request to release the travel prohibition state of the vehicle is received from the second controller, the software update device releases the travel prohibition state of the vehicle by the vehicle state control unit. 3. The software update device according to claim 2,
The first controller is
The determination unit is further provided,
when a command to execute the software update is received from a user of the vehicle, the update control unit transmits a preparation request for the software update to the second controller, and the determination unit starts time measurement by the timer to determine whether a second predetermined time has elapsed;
transmitting a request to the second controller to terminate the software update when it is determined that the second predetermined time has elapsed;
The software update device wherein the second controller transmits a request to the third controller to release a travel prohibition state of the vehicle when the second controller receives a request to terminate the software update from the first controller. 4. The software update device according to claim 3,
The software updating device, wherein the first predetermined time is longer than the second predetermined time. The software update device according to any one of claims 2 to 4,
The third controller is
The determination unit is further provided,
when a request for transitioning to a traveling prohibited state of the vehicle is received from the second controller, the determination unit starts time measurement by the timer and determines whether a third predetermined time has elapsed;
When it is determined that the third predetermined time has elapsed, the software update device causes the vehicle state control unit to release the prohibition on traveling of the vehicle. 6. The software update device according to claim 5,
The software updating device, wherein the third predetermined time is longer than the first predetermined time. 2. The software update device according to claim 1,
a first controller including the update control unit; and a second controller including the determination unit and the vehicle state control unit,
The first controller is
transmitting a preparation request for the software update to the second controller by the update control unit;
The second controller is
when a preparation request for the software update is received from the first controller, the vehicle state control unit transitions the vehicle to a traveling prohibited state, and the determination unit starts time measurement by the timer to determine whether a first predetermined time has elapsed;
When it is determined that the first predetermined time has elapsed, the software update device causes the vehicle state control unit to release a travel prohibition state of the vehicle. The software update device according to any one of claims 1 to 7,
The vehicle state control unit is configured to prohibit an ignition switch of the vehicle from being turned on when the vehicle is in the traveling prohibited state. 2. The software update device according to claim 1,
The software update device, wherein the determination unit sets the predetermined time based on a time required for the software update, which is included in update data of the software update. A software update method performed by a software update device, comprising:
The software update device includes:
Sending a preparation request for software update of the ECU of the vehicle;
After transmitting the software update preparation request, transitioning the vehicle to a driving prohibited state,
After transmitting the software update preparation request, starting time measurement by a timer and determining whether a predetermined time has elapsed;
The software update method includes canceling the prohibition on driving of the vehicle when it is determined that the predetermined time has elapsed. The vehicle's ECU;
An update control unit that controls software updates of the ECU;
a vehicle state control unit that controls transition and release of the vehicle to a traveling prohibited state;
A determination unit that determines whether or not a predetermined time has elapsed using a timer,
The update control unit transmits a preparation request for the software update,
the determination unit starts time measurement by the timer after the update control unit transmits a preparation request for the software update, and determines whether or not the predetermined time has elapsed;
The vehicle state control unit is
After the update control unit transmits the software update preparation request, the vehicle is transitioned to a traveling prohibited state,
A software update system that releases a travel prohibition state of the vehicle when the determination unit determines that the predetermined time has elapsed.

Images