Software update device, software update method, and software update system

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

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

[0002] A technology is known in which an update processing unit confirms that the vehicle has transitioned to a driving-prohibited state, then sends update information for the software program to the ECU, and when a state control unit confirms that the update process has been completed, the transition of the vehicle to the driving-prohibited state is canceled (Patent Document 1).

[0003] JP 2019-86963 A

[0004] However, the technology described in Patent Document 1 has the problem that if the status 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 will remain in a prohibited state from traveling, preventing the vehicle from starting to travel.

[0005] The problem to be solved by the present invention is to provide a software update device, a software update method, and a software update system that enable a vehicle to start driving even after a software update of the vehicle has been completed, even if the completion of the software update cannot be confirmed.

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

[0007] 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.

[0008] 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 control processing of a software update method in normal operation executed by a software update device according to the first embodiment. FIG. 3 is a diagram showing an example of a sequence chart of control processing of a software update method in abnormal operation executed by a software update device according to the first embodiment. FIG. 4 is a diagram showing an example of a sequence chart of control processing of a software update method in abnormal operation executed by a software update device according to the first embodiment. FIG. 5 is a diagram showing an example of a sequence chart of control processing of a software update method in abnormal operation executed by a software update 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 a second embodiment of the present invention.

[0009] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, an embodiment of a software updating device, a software updating method, and a software updating system according to the present invention will be described with reference to the accompanying drawings.

[0010] <<First Embodiment>> Figure 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, etc. 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.

[0011] 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 also include the time required for the software update. The server 1 manages campaigns in a database, including vehicle identification information (VIN) and ECU identification information (e.g., ECU name). For example, when the latest version of the ECU software is uploaded, the server 1 transmits an update request signal to obtain information necessary for the software update from the vehicle. The update request signal may include identification information (ID) of the software or ECU to be updated. 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 up to date based on the update information. If the server 1 determines that the current ECU version is outdated, 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. Then, the software update device 2 uses the update data to update the software of the ECU to be updated.

[0012] A vehicle user can issue a software update instruction via an HMI (Human Machine Interface) provided in the vehicle or a communication terminal (user communication terminal) owned by the vehicle user. The HMI or user communication terminal has information output devices such as a display and a speaker, and is 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 software updates 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 and content of the software update on the screen of the HMI or user communication terminal.

[0013] The software update device 2 is a device that controls software updates of an ECU (target ECU 40) of a vehicle. The software update device 2 includes an in-vehicle infotainment (IVI) 10, a gateway (GW) 20, a body control module (BCM) 30, and a target ECU 40. The IVI 10, the gateway 20, the BCM 30, and the target ECU 40 are connected via a communication network such as a CAN or LIN, allowing data to be transmitted and received between them. The target ECU 40 may be a single ECU or multiple ECUs. The ECUs are connected via a communication network such as a CAN or LIN, allowing data to be transmitted and received between them. For the sake of explanation, the IVI 10, the gateway 20, and the BCM 30 are described separately from the target ECU 40, but the IVI 10, the gateway 20, and the BCM 30 are also examples of ECUs that are subject to software updates.

[0014] The target ECU 40 is an ECU that is the target of a software update. The target ECU 40 includes a body-related ECU, a driving-related ECU, a multimedia-related ECU, and a power-related ECU. Each ECU has functional blocks such as a microcomputer composed of a central processing unit (CPU), read-only memory (ROM), random access memory (RAM), and flash memory, a power supply circuit, a data transfer circuit, etc. The flash memory stores programs for implementing the ECU's software. The ECU's software is implemented by the microcomputer executing the programs stored in the flash memory to perform various processes.

[0015] The target ECU 40 also has a memory for storing software. During software update sequence control, the target ECU 40 communicates data with the IVI 10 to transmit version information for 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 target ECU's memory (installation). With both the old and new software stored in the memory, the target ECU 40 switches the target software from the old software to the new software (activation). Note that, in this embodiment, the software update process does not necessarily have to be performed in a continuous sequence. The target ECU 40 may first install the software and then activate it upon receiving a separate update start request. While, in this embodiment, the target ECU 40 communicates data with the IVI 10 during software update sequence control, this is not limiting; the target ECU 40 may also communicate data with the GW 20. Details will be described later.

[0016] The IVI 10 is a controller configured with a microcomputer including a processor, and provides a user with information related to vehicle driving, such as map information and traffic information, and entertainment information, such as music and video, via an HMI. The IVI 10 is an example of a "first controller" in the claims. In this embodiment, the IVI 10 has an information provision function that controls an HMI, such as an in-vehicle display, to provide information to a user, as well as a function related to software updates for the vehicle's ECUs. Specifically, as shown in FIG. 1 , the IVI 10 includes, as functional blocks, an update control unit 101 that controls software updates for the target ECUs 40, and a determination unit 102 that determines whether a predetermined time has elapsed using a timer. The IVI 10 transmits and receives data between the server 1 and the ECUs via OTA communication using the update control unit 101. When the IVI 10 receives 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 the "first controller" is not limited to this and may be another controller.

[0017] Here, the update control process of the IVI 10 will be described. To update the ECU software, the software update device 2 connects to the server 1 via OTA communication and receives update data from the server 1. When the IVI 10 receives the update data, it obtains consent for the software update from the user. The IVI 10 proposes a software update to the user via the vehicle's HMI and accepts an instruction to perform the software update from the user. When the user instructs it to perform the software update, the IVI 10 transmits a software update preparation request to the GW 20. The software update preparation request is a signal (preparation request signal) requesting that the vehicle be placed in a state in which a software update can be performed. The state in which a software update can be performed is a driving prohibition state in which the vehicle is prohibited from driving. For example, the BCM 30 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 BCM 30 completes the transition process to the driving prohibition state, the GW 20 transmits a state transition completion signal to the IVI 10. The state transition completion is a signal (transition completion signal) indicating that transition to a state in which software update can be executed has been completed.

[0018] When the IVI 10 receives a state transition completion notification 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 has been installed in the target ECU 40. The update start request is a signal (update start request signal) requesting the start of a software update. When the update start request is received, the target ECU 40 is activated. Furthermore, 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 performs a software update based on the update data.

[0019] When the IVI 10 receives an update completion from the target ECU 40, it transmits the update completion to the GW 20. The update completion is a signal (update completion signal) indicating that the software update in the target ECU 40 has been completed. When the BCM 30 has completed the release of the vehicle's travel prohibition state, the GW 20 transmits a release completion to the IVI 10. The release completion is a signal (release completion signal) indicating that the vehicle's travel prohibition state has been released. When the IVI 10 receives the release completion from the GW 20, it transmits the update completion to the server 1.

[0020] Furthermore, the IVI 10 executes a determination process using a timer via the determination unit 102 to determine whether 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 determination process in each controller (IVI 10, GW 20, BCM 30). In the determination process in the IVI 10, the second predetermined time is used as the threshold for the determination process. The first predetermined time and the third predetermined time will be described later. In the determination process, the IVI 10 starts timing using the timer when a user instructs the execution of a software update. For example, the start of timing the elapsed time is executed after transmitting a software update preparation request.

[0021] The IVI 10 determines whether a 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 IVI 10 determines that the second predetermined time has elapsed, it transmits a software update termination request to the GW 20. Specifically, the IVI 10 periodically determines whether the elapsed time measured by the timer has reached the second predetermined time, and if the elapsed time has reached the second predetermined time, it determines that the second predetermined time has elapsed. If the elapsed time has not reached the second predetermined time, the IVI 10 determines that the second predetermined time has not elapsed and continues to perform the determination process at regular intervals. The software update termination request is a signal (termination request signal) for requesting the termination of the software update.

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

[0023] The GW 20 is a controller configured by a microcomputer including a processor, and is a unit (gateway) that relays communications between units such as ECUs. The GW 20 is an example of a "second controller" in the claims. That is, the GW 20 has a relay function for relaying communications between the IVI 10 and the BCM 30, as well as a determination function for determining whether a predetermined time has elapsed using a timer. Specifically, as shown in FIG. 1 , the GW 20 includes a relay unit 201 and a determination unit 202 as functional blocks. Note that, in this embodiment, the GW 20 will be described as a "second controller" in the claims, but this is not limiting, and the "second controller" may be another controller.

[0024] The GW 20 transmits and receives information between the IVI 10 and the BCM 30 via the relay unit 201. When the GW 20 receives a software update preparation request from the IVI 10, the GW 20 transmits a request to transition the vehicle to a traveling prohibited state to the BCM 30. The request to transition the vehicle to a traveling prohibited state is a signal (transition request signal) for requesting that the state of the vehicle be transitioned to a traveling prohibited state. Furthermore, when the GW 20 receives a software update preparation request from the IVI 10, the GW 20 may transmit an execution approval to the IVI 10. The execution approval is a signal (execution approval signal) for approving the transition of the vehicle to a traveling prohibited state.

[0025] The GW 20 receives a state transition completion from the BCM 30. When the GW 20 receives the state transition completion from the BCM 30, it transmits the state transition completion to the IVI 10. When the IVI 10 receives the state transition completion, it transmits an update start request to the target ECU 40. This causes a software update to be performed in the target ECU. After the software update is completed, the IVI 10 transmits a software update end request to the GW 20.

[0026] When the GW20 receives a software update termination request from the IVI10, the GW20 transmits a release request to the BCM30. The release request is a signal (release request signal) for requesting that the vehicle's travel prohibition state be released. When the GW20 receives a software update termination request from the IVI10, the GW20 may transmit an execution approval to the IVI10. The execution approval is a signal (execution approval signal) for approving the release of the vehicle's travel prohibition state. Upon receiving the release request, the BCM30 releases the vehicle's travel prohibition state and transmits 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, the GW20 transmits the release completion to the IVI10.

[0027] Furthermore, the GW 20 executes a determination process using a timer by the determination unit 202 to determine whether a predetermined time has elapsed. The specific method of the determination process is similar to the determination process in the IVI 10 and may be used as appropriate. In the determination process in the GW 20, a first predetermined time is used as a threshold value for the determination process. In the determination process, when the GW 20 receives a software update preparation request from the IVI 10, the GW 20 starts timing using a timer to determine whether 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. If the second predetermined time is 15 minutes, the first predetermined time is longer than 15 minutes, for example, 16 minutes. When the GW 20 determines that the first predetermined time has elapsed, it transmits a release request to the BCM 30. In this embodiment, by setting the length of time used in the judgment process to a different value, it is determined that the predetermined time has elapsed in GW20 at a timing later than the timing at which it is determined that the predetermined time has elapsed in IVI10. However, this is not limited to this, and the timing at which the timer in GW20 starts counting may be set later than the timing at IVI10.

[0028] In this embodiment, when the GW 20 receives a software update termination request from the IVI 10 or when it determines that a first predetermined time has elapsed, the GW 20 transmits a cancellation request to the BCM 30. As a result, even if a software update termination request is not transmitted from the IVI 10 for some reason, the GW 20 can transmit a cancellation request to the BCM 30 as time passes. Note that in this embodiment, it is not essential that the GW 20 (second controller) be provided with the determination unit 202, and it may be applied as appropriate as necessary.

[0029] The BCM 30 is a controller configured by 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, the BCM 30 has a vehicle state control function that controls the state of the vehicle in addition to the function of controlling the overall functions of the vehicle body. 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 prohibition 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 will be described as a "third controller" in the claims, but the "third controller" is not limited to this, and the "third controller" may be another controller.

[0030] After transmitting a software update preparation request, the BCM 30 causes the vehicle state control unit 301 to transition the vehicle to a driving prohibited state. For example, when a transition request is received from the GW 20, the BCM 30 transitions the vehicle to the driving prohibited state. In the driving prohibited state, the BCM 30 prohibits the ignition switch of the vehicle from being turned on. When the BCM 30 transitions the vehicle to the 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 executed (driving prohibited state).

[0031] When the BCM 30 receives a release request from the GW 20, the BCM 30 releases the vehicle's travel prohibition state by the vehicle state control unit 301. For example, the BCM 30 permits the ignition of the vehicle 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 release of the vehicle's travel prohibition state has been completed.

[0032] The BCM 30 executes a determination process using a timer by the determination unit 302 to determine whether a predetermined time has elapsed. The specific method of the determination process is similar to the determination process in the IVI 10 and may be used as appropriate. In the determination process in the BCM 30, a third predetermined time is used as a threshold value for the determination process. In the determination process, when the BCM 30 receives a transition request from the GW 20, the BCM 30 starts timing using a timer to determine whether 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 determines that the third predetermined time has elapsed, the BCM 30 releases the vehicle's travel prohibition state. In this embodiment, by setting different lengths of time to be used in the determination process, it is determined that a predetermined time has elapsed in BCM 30 at a timing later than when it is determined that a predetermined time has elapsed in IVI 10 and GW 20. However, this is not limited to this, and the timing at which the timer in BCM 30 starts counting may be set later than that in IVI 10 and GW 20.

[0033] That is, 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 transmit 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, a timer is also provided in the BCM 30, and the determination unit determines whether the predetermined time has elapsed in response to an abnormality in the IVI 10 or the GW 20. The reason why the third predetermined time is longer than the first predetermined time and the second predetermined time is to prioritize execution of processing in a normal system in which the IVI 10 and the GW 20 are normal over processing in an abnormal system in which an abnormality occurs in the IVI 10 or the GW 20.

[0034] 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 conditions. 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.

[0035] 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 an 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 traveling prohibited state. In step S6, the BCM 30 transmits a state transition completion to the GW 20. In step S7, the GW 20 transmits the 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 an update completion to the IVI 10.

[0036] In step S11, the IVI 10 transmits a software update completion request to the GW 20. In step S12, the GW 20 transmits an execution approval to the IVI 10. In step S13, the GW 20 transmits a release request to the BCM 30. In step S14, the BCM 30 releases the vehicle's travel prohibition state. In step S15, the BCM 30 transmits a release completion to the GW 20. In step S16, the GW 20 transmits a release completion to the IVI 10. In step S17, the IVI 10 transmits an update completion to the server 1.

[0037] 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 determination process is executed in each controller. FIG. 3 shows an example of the control process when the IVI 10 is provided with a determination unit and determines whether a predetermined time has elapsed. FIG. 3 shows a sequence chart in which a step of starting timing in the IVI 10 (step S21) and a step of determining that a second predetermined time has elapsed (step S22) are added to the sequence chart of FIG. 2 . The same steps as those in FIG. 2 will not be described again, and the description of FIG. 2 will be used as appropriate. The example of FIG. 3 also shows a situation in which an abnormality has occurred in communication between the target ECU 40 and the IVI 10 for some reason, causing the IVI 10 to be unable to receive an update completion notification from the target ECU 40.

[0038] 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 a second predetermined time has elapsed, it transmits a termination request to the GW 20 (step S11). This allows the IVI 10 to transmit the termination request to the GW 20 even if an abnormality occurs in communication between the target ECU 40 and the IVI 10 for some reason and the IVI 10 is unable to receive a notification of update completion from the target ECU 40. The GW 20, which has received the termination request, transmits a release request to the BCM 30, which allows the BCM 30 to release the vehicle's travel prohibition state.

[0039] 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 illustrating 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 illustrated in FIG. 4 is an example of the control process when a determination process is executed in each controller. FIG. 4 illustrates an example of the control process when the GW 20 includes a determination unit and determines that a predetermined time has elapsed. FIG. 4 illustrates a sequence chart in which a step of starting timekeeping (step S31) and a step of determining that a first predetermined time has elapsed (step S32) are added to the sequence chart of FIG. 3 . Descriptions of the same steps as those in FIGS. 2 and 3 will be omitted, and the descriptions of FIGS. 2 and 3 will be used as appropriate. The example of FIG. 4 illustrates a situation in which an abnormality has occurred in 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.

[0040] 4 , when the IVI 10 transmits a preparation request to the GW 20 (step S2), the GW 20 transmits 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 transmits a release request to the BCM 30 (step S13). This allows the GW 20 to transmit the 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 vehicle's travel prohibition state.

[0041] 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 illustrating 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 illustrated in FIG. 5 is an example of the control process when a determination process is executed in each controller. FIG. 5 illustrates an example of the control process when the BCM 30 includes a determination unit and determines that a predetermined time has elapsed. FIG. 5 illustrates a sequence chart in which a step of starting timekeeping (step S51) in the BCM 30 and a step of determining that a third predetermined time has elapsed (step S52) are added to the sequence chart of FIG. 4 . Descriptions of the same steps as those in FIGS. 2, 3, and 4 will be omitted, and the descriptions of FIGS. 2, 3, and 4 will be used as appropriate. The example of FIG. 5 illustrates a situation in which an abnormality has occurred in communication between the GW 20 and the BCM 30 for some reason, making it impossible to receive a release request from the GW 20.

[0042] 5 , when the GW 20 transmits a transition request to the BCM 30 (step S4), the BCM 30 transitions the vehicle to a traveling prohibited state (step S5), and then starts timing using a timer (step S51). Then, when the BCM 30 determines in step S52 that a third predetermined time has elapsed, it releases the traveling prohibited state of the vehicle (step S14). This allows the BCM 30 to release the traveling prohibited state of the vehicle even if an abnormality occurs in communication between the GW 20 and the BCM 30 for some reason and the BCM 30 is unable to receive a release request from the GW 20.

[0043] In this embodiment, the IVI 10 (first controller), the GW 20 (second controller), and the BCM 30 (third controller) each include a determination unit. In the software update system, the IVI 10 and the GW 20 control and manage the system, so that if an abnormality occurs in the system, the control and management side can take action by providing timers in the IVI 10 and the GW 20 to perform a determination process. However, there are cases where an abnormality occurs in the IVI 10 and the GW 20, which are the control and management side of the system. As a last resort in preparation for such a case, the BCM 30 also has a timer provided to perform a determination process.

[0044] Note that the examples of the controller including the determination unit are not limited to the above. Either the IVI10 or the GW20, which are on the control / management side, may include a determination unit. For example, the IVI10 may not include a determination unit, and the GW20 and the BCM30 may include a determination unit. The GW20 may not include a determination unit, and the IVI10 and the BCM30 may include a determination unit. The BCM30 may not include a determination unit, and the IVI10 and the GW20, which are on the control / management side, may include a determination unit. In another example, the IVI10 and the GW20 may not include a determination unit, and the BCM30 may include a determination unit. The GW20 and the BCM30 may not include a determination unit, and the IVI10 may include a determination unit. The IVI10 and the BCM30 may not include a determination unit, and the GW20 may include a determination unit. The configurations and processes in each example will not be described, but the above-described descriptions of the configurations and processes will be used as appropriate.

[0045] In addition, in the present embodiment, in the software update sequence control, the target ECU 40 performs data communication with the IVI 10. However, this is not limiting, 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 in which data is transmitted and received between the GW 20 and the target ECU 40 in the software update system of FIG. 1 , rather than between the IVI 10 and the target ECU 40. 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.

[0046] 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 of the vehicle to a driving prohibition state and release of the transition, and a determination unit that uses a timer to determine whether a predetermined time has elapsed. The update control unit transmits a software update preparation request. After the update control unit transmits the software update preparation request, the determination unit starts timing using the timer and determines whether 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 driving prohibition state, and if the determination unit determines that the predetermined time has elapsed, releases the vehicle's driving prohibition state. This allows the vehicle to start driving after the vehicle software update is completed, even if completion of the vehicle software update cannot be confirmed.

[0047] 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 after the software update has been completed, even if the completion of the vehicle's software update cannot be confirmed.

[0048] 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 of the vehicle to a driving prohibition state and release of the transition, and a determination unit that uses a timer to determine whether a predetermined time has elapsed. The update control unit transmits a software update preparation request. After the update control unit transmits the software update preparation request, the determination unit starts timing using the timer and determines whether 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 driving prohibition state, and releases the vehicle's driving prohibition state when the determination unit determines that the predetermined time has elapsed. This allows the vehicle to start driving after the vehicle software update is completed, even if completion of the vehicle software update cannot be confirmed.

[0049] The software update device according to the present embodiment includes a first controller including an update control unit, a second controller including a determination unit, and a third controller including 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, it transmits a request to transition the vehicle to a driving prohibition state to the third controller, and the determination unit starts timing using a timer to determine whether a first predetermined time has elapsed. If it determines that the first predetermined time has elapsed, it transmits a request to release the vehicle's driving prohibition state to the third controller. When the third controller receives the request to transition the vehicle to a driving prohibition state from the second controller, it transitions the vehicle to a driving prohibition state via the vehicle state control unit, and when it receives a request to release the vehicle's driving prohibition state from the second controller, it releases the vehicle's driving prohibition state via the vehicle state control unit. This allows the vehicle to start driving after the software update is complete, even if the third controller is unable to confirm completion of the vehicle software update due to some abnormality occurring in the first controller.

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

[0051] In addition, in the software update device according to this embodiment, the first predetermined time is longer than the second predetermined time, so that if the first controller does not transmit a request to terminate the software update even after the second predetermined time has elapsed, the second controller can transmit a request to cancel the travel prohibition state to the third controller in accordance with the determination of the elapsed time.

[0052] In the software update device according to this embodiment, the third controller further includes a determination unit, and when a request to transition the vehicle to a driving prohibition state is received from the second controller, the determination unit starts timing using a timer to determine whether a third predetermined time has elapsed, and when it determines that the third predetermined time has elapsed, the vehicle state control unit releases the driving prohibition state of the vehicle. As a result, even if a request to release the driving prohibition 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 of the vehicle is completed.

[0053] Furthermore, in the software update device according to this embodiment, the third predetermined time is longer than the first predetermined time, so that if the second controller does not send a request to release the travel prohibition state after the first predetermined time has elapsed, the travel prohibition state can be released in accordance with the determination of the elapsed time by the third controller.

[0054] Furthermore, 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 travel prohibited state. This prevents the ignition switch from being turned on during a software update.

[0055] 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 it cannot be confirmed that the vehicle's software update has been completed.

[0056] <<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 using FIG. 7 . FIG. 7 is a block diagram of a software update system according to the second embodiment of the present invention. Configurations other than those described below are the same as those in the first embodiment described above, and in the following description, descriptions of the same configurations and control processes as in the first embodiment will be omitted, but the descriptions of the first embodiment will be used where appropriate for the omitted descriptions.

[0057] In the second embodiment, the IVI 10 (first controller) includes an update control unit 101 and a determination unit 102. The BCM 30 (second controller) includes a vehicle state control unit 301 and a determination unit 302. When the IVI 10 receives update data from the server 1, the update control unit 101 transmits a software update preparation request to the BCM 30. When the IVI 10 receives a state transition completion from the BCM 30, the IVI 10 transmits an update start request to the target ECU 40. When the IVI 10 receives an update completion from the target ECU 40, the IVI 10 transmits a cancellation request to the BCM 30. When the IVI 10 receives an update completion from the BCM 30, the IVI 10 transmits an update completion to the server 1. After transmitting the preparation request, the IVI 10 may start time measurement using a timer using the determination unit 102, and determine whether a second predetermined time has elapsed. When the IVI 10 determines that the second predetermined time has elapsed, the IVI 10 transmits a release request to the BCM 30.

[0058] When the BCM 30 receives a software update preparation request from the IVI 10, the BCM 30 causes the vehicle to transition to a driving prohibition state via the vehicle state control unit 301. After transitioning the vehicle to the 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, the BCM 30 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. Furthermore, after transitioning the vehicle to the driving prohibition state, the BCM 30 starts time measurement using a timer via the determination unit 302 and determines whether a first predetermined time has elapsed. When the BCM 30 determines that the first predetermined time has elapsed, the BCM 30 releases the vehicle's driving prohibition state via the vehicle state control unit 301. After releasing the vehicle's driving prohibition state, the BCM 30 transmits a release completion to the IVI 10.

[0059] In this embodiment, the IVI 10 (first controller) includes an update control unit and a determination unit, and the BCM 30 (second controller) includes a vehicle state control unit and a determination unit, but examples of controllers including a determination unit are not limited to this. The BCM 30 may not include a determination unit, and the IVI 10 may include a determination unit. The IVI 10 may not include a determination unit, and the BCM 30 may include a determination unit.

[0060] As described above, the software update device according to this embodiment includes a first controller including an update control unit and a second controller including 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, the determination unit starts timing using a timer to determine whether a first predetermined time has elapsed, and if it determines that the first predetermined time has elapsed, the vehicle state control unit releases the vehicle's driving prohibition state. This allows the vehicle to start driving after the vehicle software update is complete, even if the second controller is unable to confirm completion of the vehicle software update due to some abnormality occurring in the first controller.

[0061] It should be noted that 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-described embodiments is intended to include all design modifications and equivalents that fall within the technical scope of the present invention.

[0062] 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

1. A software update device comprising: an update control unit that controls software updates of a vehicle's ECU; a vehicle state control unit that controls the transition of the vehicle to a driving prohibition state and the release of the transition; and a judgment unit that uses a timer to determine whether or not a predetermined time has elapsed, wherein the update control unit transmits a preparation request for the software update, and the judgment unit starts timing using the timer after the update control unit transmits the preparation request for the software update and determines whether or not the predetermined time has elapsed, and the vehicle state control unit transitions the vehicle to a driving prohibition state after the update control unit transmits the preparation request for the software update, and releases the driving prohibition state of the vehicle if the judgment unit determines that the predetermined time has elapsed.

2. A software update device as described in claim 1, comprising: a first controller having the update control unit; a second controller having the determination unit; and a third controller having the vehicle state control unit, wherein the first controller transmits a preparation request for the software update to the second controller via the update control unit, and the second controller, when receiving the preparation request for the software update from the first controller, transmits a request to transition the vehicle to a driving prohibited state to the third controller, and starts timing with the timer via the determination unit to determine whether a first predetermined time has elapsed, and when determining that the first predetermined time has elapsed, transmits a request to release the driving prohibited state of the vehicle to the third controller, and the third controller, when receiving a request to transition the vehicle to a driving prohibited state from the second controller, transitions the vehicle to a driving prohibited state via the vehicle state control unit, and when receiving a request to release the driving prohibited state of the vehicle from the second controller, releases the driving prohibited state of the vehicle via the vehicle state control unit.

3. A software update device as described in claim 2, wherein the first controller further comprises the judgment unit, and when a command to perform the software update is received from a user of the vehicle, the first controller transmits a preparation request for the software update to the second controller via the update control unit, the judgment unit starts timing using the timer and judges whether a second predetermined time has elapsed, and when it is determined that the second predetermined time has elapsed, the second controller transmits a request to terminate the software update to the second controller, and when the second controller receives the request to terminate the software update from the first controller, the second controller transmits a request to lift the vehicle's travel prohibition state to the third controller.

4. A software updating device according to claim 3, wherein the first predetermined time is longer than the second predetermined time.

5. A software update device as claimed in any one of claims 2 to 4, wherein the third controller further comprises the determination unit, and when a request for transitioning the vehicle to a driving prohibited state is received from the second controller, the determination unit starts timing using the timer to determine whether or not a third specified time has elapsed, and when it is determined that the third specified time has elapsed, the vehicle state control unit releases the driving prohibited state of the vehicle.

6. A software updating device according to claim 5, wherein the third predetermined time is longer than the first predetermined time.

7. A software update device as described in claim 1, comprising: a first controller having the update control unit; and a second controller having the judgment unit and the vehicle state control unit, wherein the first controller transmits a preparation request for the software update to the second controller via the update control unit, and when the second controller receives the preparation request for the software update from the first controller, the vehicle state control unit transitions the vehicle to a driving prohibited state, the judgment unit starts timing using the timer and judges 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 driving prohibited state of the vehicle.

8. A software update device according to any one of claims 1 to 7, wherein the vehicle state control unit prohibits an ignition switch of the vehicle from being turned on when the vehicle is in the travel prohibited state.

9. A software update device according to claim 1, wherein the determination unit sets the predetermined time based on the time required for the software update, which is included in update data for the software update.

10. A software update method executed by a software update device, wherein the software update device transmits a preparation request for a software update of an ECU of a vehicle, transitions the vehicle to a driving prohibited state after transmitting the software update preparation request, starts timing using a timer after transmitting the software update preparation request and determines whether a predetermined time has elapsed, and releases the driving prohibited state of the vehicle if it determines that the predetermined time has elapsed.

11. A software update system comprising: an ECU for a vehicle; an update control unit that controls software updates for the ECU; a vehicle state control unit that controls the transition of the vehicle to a driving-prohibited state and the release of the state; and a judgment unit that uses a timer to determine whether or not a predetermined time has elapsed, wherein the update control unit transmits a preparation request for the software update, and the judgment unit starts timing with the timer after the update control unit transmits the preparation request for the software update and determines whether or not the predetermined time has elapsed, and the vehicle state control unit transitions the vehicle to a driving-prohibited state after the update control unit transmits the preparation request for the software update, and releases the driving-prohibited state of the vehicle when the judgment unit determines that the predetermined time has elapsed.

Images