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

Abstract

The software update device (2), after transmitting a preparation request for software update of an ECU (40) of a vehicle, causes the vehicle to transition to a travel prohibited state, starts timing of a timer, determines whether or not a predetermined time has elapsed, and cancels the travel prohibited state of the vehicle when it is determined that the predetermined time has elapsed.

Description

Technical Field

[0001] This invention relates to a software update device, a software update method, and a software update system. Background Technology

[0002] The following technology is known: after the update processing unit confirms that the vehicle has changed to a prohibited driving state, it sends update information for the software program to the ECU, and after the status control unit confirms that the update processing has been completed, it removes the vehicle from the prohibited driving state (Patent Document 1).

[0003] Existing technical documents

[0004] Patent documents

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

[0006] The problem the invention aims to solve

[0007] However, the technology described in Patent Document 1 has the following problem: when the status control unit cannot confirm the completion of the update process, such as when an abnormality occurs and no update completion information is sent or received, the vehicle's prohibited driving state is maintained, and therefore the vehicle cannot start driving.

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

[0009] Solution for solving the problem

[0010] The present invention solves the above problems by the following process: after sending a software update preparation request for the vehicle's ECU, a timer is started, and it is determined whether a specified time has elapsed, so that the vehicle is put into a driving prohibition state. If it is determined that the specified time has elapsed, the driving prohibition state of the vehicle is lifted.

[0011] The effects of the invention

[0012] According to the present invention, even if the completion of the vehicle's software update cannot be confirmed after the update is completed, the vehicle can still be driven. Attached Figure Description

[0013] Figure 1 This is a block diagram illustrating an example of a software update system according to the first embodiment of the present invention.

[0014] Figure 2This is a timing diagram illustrating an example of the control processing of a software update method performed normally by the software update apparatus according to the first embodiment.

[0015] Figure 3 This is a timing diagram illustrating an example of the control processing of a software update method when an error occurs during execution by the software update apparatus according to the first embodiment.

[0016] Figure 4 This is a timing diagram illustrating an example of the control processing of a software update method when an error occurs during execution by the software update apparatus according to the first embodiment.

[0017] Figure 5 This is a timing diagram illustrating an example of the control processing of a software update method when an error occurs during execution by the software update apparatus according to the first embodiment.

[0018] Figure 6 This is a block diagram illustrating an example of a software update system according to the first embodiment of the present invention.

[0019] Figure 7 This is a block diagram of a software update system according to the second embodiment of the present invention. Detailed Implementation

[0020] The following describes one embodiment of the software update apparatus, software update method, and software update system involved in the present invention, based on the accompanying drawings.

[0021] <<First Implementation Method>>

[0022] Figure 1 This is a block diagram of a software update system according to the 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 sending and receiving data between a vehicle equipped with the software update device 2 and the server 1 via OTA communication (wireless communication), and is used for updating the software (firmware) of the Electronic Control Unit (ECU) included in the software update device 2. The software update system 100 is not limited to communication between the vehicle and the server 1, but can also be used for communication between vehicles (inter-vehicle connectivity) and communication between the server 1 and a user communication terminal.

[0023] Server 1 stores update data for the ECU software in a database and sends update data to the vehicle based on update requests. The update data is the latest software data. The update data may also include the time required for the software update. Server 1 manages campaigns on the database that include vehicle identification information (VIN), ECU identification information (e.g., ECU name), etc. For example, if the latest version of the ECU software has been uploaded, Server 1 sends an update request signal to obtain the information needed to update the software from the vehicle. The update request signal may also include the identification information (ID) of the software or ECU to be updated. The vehicle's software update device 2 sends a signal containing ECU update information (version information), etc., to Server 1 based on the request from Server 1. Server 1 determines whether the ECU software is the latest version based on the update information. If Server 1 determines that the current version of the ECU is an old version, it sends the latest software (update data, reprogramming data) to the vehicle. The vehicle's software update device 2 downloads the update data sent from Server 1. Then, the software update device 2 uses the update data to update the software of the ECU to be updated.

[0024] Vehicle users can request software updates via the vehicle's HMI (Human Machine Interface) and communication terminal (user communication terminal). The HMI and user communication terminal have information output devices such as displays and speakers, and connect to server 1 via OTA (Over-The-Air) communication. The HMI is the interface used for information input and output between the vehicle user and the vehicle system. Instructions related to software updates include agreeing to or canceling the update. Software update instructions may include whether to implement immediately or at a specified time. Furthermore, users can check the progress and content of the software update on the HMI and user communication terminal screens.

[0025] The software update device 2 is a device for controlling the software updates of the vehicle's ECU (target ECU 40). The software update device 2 includes an IVI (in-vehicle infotainment system) 10, a GW (gateway) 20, a BCM (body control module) 30, and the target ECU 40. The IVI 10, GW 20, BCM 30, and target ECU 40 are connected via communication networks such as CAN and LIN, enabling them to send and receive data. The target ECU 40 can be a single ECU or multiple ECUs. The ECUs are connected via communication networks such as CAN and LIN, enabling them to send and receive data. Furthermore, while the IVI 10, GW 20, and BCM 30 are described separately from the target ECU 40 in the description, the IVI 10, GW 20, and BCM 30 are also examples of ECUs that are subject to software updates.

[0026] The target ECU 40 is the ECU that becomes the target of software updates. The target ECU 40 includes the body system ECU, the driving system ECU, the multimedia system ECU, and the power system ECU. Each ECU has a microcomputer consisting of a CPU (Central Processing Unit), ROM (Read Only Memory), RAM (Random Access Memory), and flash memory, as well as power supply circuits, data transmission circuits, etc., as functional blocks. The flash memory stores the program used to implement the ECU's software. The microcomputer executes the program stored in the flash memory to perform various processes, thereby implementing the ECU's software.

[0027] Additionally, the target ECU 40 has a memory for storing software. In the timing control of software updates, the target ECU 40 communicates with the IVI 10 to send 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 contained in the update data is written (installed) into the target ECU's memory. With both the old and new software stored in the memory, the target ECU 40 will switch (activate) the software from the old software to the new software. Furthermore, in this embodiment, such software update processing does not necessarily have to be performed in a series of steps; the target ECU 40 may first perform software installation, and then perform activation upon receiving an update start request. Additionally, in this embodiment, the target ECU 40 communicates with the IVI 10 in the timing control of software updates, but is not limited to this; the target ECU 40 may also communicate with the GW 20. Details will be described later.

[0028] The IVI 10 is a controller comprised of a microcomputer including a processor, which provides users with vehicle-related information such as map information and traffic information, as well as entertainment-related information such as music and videos, via an HMI. The IVI 10 is an example of the "first controller" claimed in the claims. That is, in this embodiment, the IVI 10, in addition to having the function of controlling the HMI such as the in-vehicle display to provide information to the user, also has functions related to software updates of the vehicle's ECU. Specifically, as... Figure 1 As shown, the IVI 10 has an update control unit 101 and a determination unit 102 as functional blocks. The update control unit 101 controls the software update of the target ECU 40, and the determination unit 102 uses a timer to determine whether a predetermined time has elapsed. The IVI 10 sends and receives data between the server 1 and the ECU via OTA communication through the update control unit 101. When the IVI 10 receives the update data for the software update, it performs update control processing. Furthermore, in this embodiment, the IVI 10 is described as the "first controller" in the claims, but it is not limited thereto; the "first controller" may also be other controllers.

[0029] Here, the update control process of IVI 10 will be explained. Software update device 2 connects to server 1 via OTA communication to update the ECU software and receives update data from server 1. Upon receiving the update data, IVI 10 obtains the user's consent to the software update. IVI 10 proposes a software update to the user via the vehicle's HMI and receives the user's instruction to execute the software update. Upon receiving the user's instruction to execute the software update, IVI 10 sends a software update preparation request to GW 20. The software update preparation request is a signal requesting that the vehicle be placed in a state where the software update can be performed (preparation request signal). The state where the software update can be performed is a prohibited driving state that prevents the vehicle from driving. For example, the BCM 30 prevents the start switch (ignition switch or power switch) from turning on. Therefore, the vehicle cannot be driven during the software update. Upon completion of the transition process to the prohibited driving state in BCM 30, GW 20 sends a state transition completion signal to IVI 10. The state transition completion signal indicates that the transition to a state where the software update can be performed has been completed (transition completion signal).

[0030] Upon receiving a status transition completion notification from GW 20, IVI 10 sends the update data received from server 1 to target ECU 40. At this time, an update start request can be sent to target ECU 40 along with the update data, or the update data can be sent first, and then the update start request sent after target ECU 40 has installed the update data. The update start request is a signal used to request the start of a software update (update start request signal). Target ECU 40 performs activation upon receiving the update start request. Alternatively, the update start request can be sent directly from IVI 10 to target ECU 40, or it can be sent from IVI 10 via GW 20. Upon receiving the update start request, target ECU 40 performs a software update based on the update data.

[0031] Upon receiving an update completion notification from the target ECU 40, IVI 10 sends an update completion signal to GW 20. Update completion is a signal indicating that the software update in the target ECU 40 is complete (update completion signal). When the vehicle's driving restriction status is lifted in BCM 30, GW 20 sends a lifting completion signal to IVI 10. Lifting completion is a signal indicating that the vehicle's driving restriction status has been lifted (lifting completion signal). Upon receiving a lifting completion notification from GW 20, IVI 10 sends an update completion signal to server 1.

[0032] Additionally, IVI 10, through its determination unit 102, performs a determination process that uses a timer 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 processes of each controller (IVI 10, GW 20, BCM 30). In the determination process of IVI 10, the second predetermined time is used as the threshold for the determination process. The first and third predetermined times will be described later. In the determination process, if the user issues an instruction to execute a software update, IVI 10 starts timing the timer. For example, the timing of elapsed time begins after a software update preparation request has been sent.

[0033] IVI 10 determines whether a second specified time has elapsed based on the elapsed time. For example, the second specified time is the time required for the software update. The second specified time is set based on the time required for the software update. For example, the second specified time is the time required for the software update. If the time required for the software update is 15 minutes, the second specified time is set to 15 minutes. If IVI 10 determines that the second specified time has elapsed, it sends a software update termination request to GW 20. Specifically, IVI 10 periodically checks whether the elapsed time, obtained through a timer, has reached the second specified time. If the elapsed time has reached the second specified time, it determines that the second specified time has elapsed. If the elapsed time has not reached the second specified time, IVI 10 determines that the second specified time has not elapsed and continues to perform the determination process periodically. The software update termination request is a signal used to request the termination of the software update (termination request signal).

[0034] As described above, in this embodiment, the IVI 10 sends a termination request to the GW 20 when it receives a notification of update completion from the target ECU 40 or when it determines that a second predetermined time has elapsed. Therefore, even if an update completion notification is not received from the target ECU 40 for some reason, the IVI 10 can still send a termination request to the GW 20 based on the elapsed time. Furthermore, in this embodiment, the determination unit 102 is not essential for the IVI 10 (first controller), and can be appropriately applied as needed.

[0035] GW 20 is a controller comprised of a microcomputer including a processor, and serves as a gateway unit for relaying communication between various units such as the ECU. GW 20 is an example of the "second controller" claimed in the claims. That is, in addition to its relay function for communication between IVI 10 and BCM 30, GW 20 also has a function to determine whether a predetermined time has elapsed using a timer. Specifically, as... Figure 1 As shown, GW 20 includes a relay unit 201 and a determination unit 202 as functional blocks. Furthermore, in this embodiment, GW 20 is described as the "second controller" in the claims, but it is not limited thereto; the "second controller" may be other controllers.

[0036] GW 20 transmits and receives information with IVI 10 and BCM 30 via relay unit 201. Upon receiving a software update preparation request from IVI 10, GW 20 sends a vehicle transition request to BCM 30 to a prohibited driving state. This transition request is a signal (transition request signal) requesting the vehicle's state to change to a prohibited driving state. Additionally, upon receiving a software update preparation request from IVI 10, GW 20 may also send an execution approval to IVI 10. This execution approval is a signal (execution approval signal) approving the transition to a prohibited driving state.

[0037] GW 20 receives a status transition completion notification from BCM 30. Upon receiving this notification, GW 20 sends a status transition completion message to IVI 10. IVI 10, upon receiving the notification, sends an update start request to the target ECU 40. This initiates a software update in the target ECU. After the software update is complete, IVI 10 sends a software update end request to GW 20.

[0038] Upon receiving a software update completion request from IVI 10, GW 20 sends a release request to BCM 30. The release request is a signal requesting the removal of the vehicle's prohibited driving status (release request signal). GW 20 may also send an execution approval to IVI 10 upon receiving a software update completion request from IVI 10. Execution approval is a signal approving the removal of the vehicle's prohibited driving status (execution approval signal). Upon receiving the release request, BCM 30 removes the vehicle's prohibited driving status and sends a release completion signal to GW 20. Release completion is a signal indicating that the vehicle's prohibited driving status has been removed (release completion signal). Upon receiving a release completion signal from BCM 30, GW 20 sends a release completion signal to IVI 10.

[0039] Additionally, GW 20, through its determination unit 202, performs a determination process using a timer to determine whether a predetermined time has elapsed. The specific determination process is the same as that in IVI 10 and can be appropriately referenced. In the determination process of GW 20, a first predetermined time is used as a threshold for the determination process. In the determination process, upon receiving a software update preparation request from IVI 10, GW 20 starts timing the timer and determines whether the first predetermined time has elapsed. The first predetermined time is a longer time than a 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 be 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. If GW 20 determines that the first predetermined time has elapsed, it sends a release request to BCM 30. Furthermore, in this embodiment, the length of the time used in the determination process is set to a different length, so that the timing determined by GW 20 to have elapsed a predetermined time is later than the timing determined by IVI 10. However, it is not limited to this, the timing of the start of the timer in GW 20 can also be later than that of IVI 10.

[0040] In this embodiment, GW 20 sends a release request to BCM 30 when it receives a software update termination request from IVI 10 or when it determines that a first predetermined time has elapsed. Therefore, even if a software update termination request is not sent from IVI 10 for some reason, GW 20 can still send a release request to BCM 30 based on the elapsed time. Furthermore, in this embodiment, the determination unit 202 is not essential for GW 20 (the second controller), and can be appropriately applied as needed.

[0041] BCM 30 is a controller comprised of a microcomputer including a processor, and is the ECU that controls the functions of the entire vehicle body. BCM 30 is an example of the "third controller" claimed in the claims. That is, in addition to controlling the functions of the entire vehicle body, BCM 30 also has vehicle state control functions to control the vehicle's state. Specifically, as... Figure 1 As shown, the BCM 30 includes a vehicle state control unit 301 and a determination unit 302 as functional modules. The vehicle state control unit 301 controls the transition and release of the vehicle from a prohibited driving state, and the determination unit 302 uses a timer to determine whether a predetermined time has elapsed. Furthermore, in this embodiment, the BCM 30 is described as the "third controller" in the claims, but it is not limited thereto; the "third controller" can also be other controllers.

[0042] After sending a software update preparation request, the BCM 30 switches the vehicle to a prohibited driving state via the vehicle state control unit 301. For example, upon receiving a switch request from the GW 20, the BCM 30 switches the vehicle to a prohibited driving state. In the prohibited driving state, the BCM 30 prevents the vehicle's ignition switch from being turned on. After switching the vehicle to the prohibited driving state, the BCM 30 sends a state transition completion signal to the GW 20. State transition completion is a signal (transition completion signal) indicating that the vehicle has been switched to a state where a software update can be performed (prohibited driving state).

[0043] Upon receiving a release request from GW 20, BCM 30 releases the vehicle's prohibited driving state via vehicle state control unit 301. For example, BCM 30 allows the vehicle's ignition to be turned on. After releasing the vehicle's prohibited driving state, BCM 30 sends a release completion signal to GW 20. Release completion is a signal indicating that the vehicle's prohibited driving state has been released (release completion signal).

[0044] BCM 30, through determination unit 302, performs a determination process that uses a timer to determine whether a predetermined time has elapsed. The specific determination process is the same as that in IVI 10 and can be appropriately referenced. In the determination process of BCM 30, a third predetermined time is used as the threshold for the determination process. In the determination process, when BCM 30 receives a change request from GW 20, it starts timing the timer and determines whether the third predetermined time has elapsed. The third predetermined time is a time longer than the time required for the software update. For example, the third predetermined time is a time longer than the first predetermined time. If the first predetermined time is 16 minutes, the third predetermined time is, for example, 40 minutes. If BCM 30 determines that the third predetermined time has elapsed, it removes the vehicle's prohibition from driving. Furthermore, in this embodiment, the length of time used in the determination process is set to a different length, so that timing that is later than the timing determined by IVI 10 and GW 20 to have elapsed a predetermined time is determined by BCM 30 to have elapsed a predetermined time. However, it is not limited to this, the timing of the start of the timer in BCM 30 can also be later than that of IVI 10 and GW 20.

[0045] That is, in this embodiment, the BCM 30 removes the vehicle's prohibited driving state when it receives a release request from the GW 20 or when it determines that a third predetermined time has elapsed. Therefore, even if a release request is not sent from the GW 20 for some reason, the BCM 30 can still remove the vehicle's prohibited driving state based on the elapsed time. As described above, in this embodiment, as a response to the situation where IVI 10 and GW 20 malfunction, a timer is also set in the BCM 30, and the determination unit determines whether a predetermined time has elapsed. The reason why the third predetermined time is longer than the first and second predetermined times is to ensure that processing in a normal system where IVI 10 and GW 20 are functioning normally is performed before processing in an abnormal system where IVI 10 and GW 20 malfunction.

[0046] Next, use Figure 2 The process of controlling the software update method executed by the software update apparatus according to the first embodiment will be described. Figure 2 This is a timing diagram illustrating an example of the control processing of a software update method performed normally by the software update apparatus in the first embodiment. Figure 2 The control process shown is an example of control processing where no decision processing is performed in each controller. That is, Figure 2 This illustrates an example of control processing when all controllers are functioning normally, rather than control processing when controllers malfunction and are unable to send or receive information.

[0047] In step S1, server 1 sends update data to IVI 10. In step S2, IVI 10 sends a software update preparation request to GW 20. In step S3, GW 20 sends execution approval to IVI 10. In step S4, GW 20 sends a transition request to BCM 30. In step S5, BCM 30 transitions the vehicle to a prohibited driving state. In step S6, BCM 30 sends a state transition completion message to GW 20. In step S7, GW 20 sends a state transition completion message to IVI 10. In step S8, IVI 10 sends an update start request to target ECU 40. At this time, update data can be sent either together with the update start request or sent first. In step S9, target ECU 40 performs a software update based on the update data according to the update start request. In step S10, target ECU 40 sends an update completion message to IVI 10 after the software update.

[0048] In step S11, IVI 10 sends a software update completion request to GW 20. In step S12, GW 20 sends an execution approval request to IVI 10. In step S13, GW 20 sends a release request to BCM 30. In step S14, BCM 30 removes the vehicle's driving restriction status. In step S15, BCM 30 sends a release completion request to GW 20. In step S16, GW 20 sends a release completion request to IVI 10. In step S17, IVI 10 sends an update completion request to Server 1.

[0049] Next, use Figure 3 The process of controlling the software update method executed by the software update apparatus according to the first embodiment will be described. Figure 3 This is a timing diagram illustrating an example of the control processing of a software update method when an error occurs, as performed by the software update apparatus in the first embodiment. Figure 3 The control process shown is an example of control processing where decision processing is performed in each controller. Figure 3 The example shown is a control process where the IVI 10 has a determination unit and determines whether a predetermined time has elapsed. Figure 3 It shows the Figure 2 The timing diagram is obtained by adding the step of starting timing (step S21) and the step of determining that the second predetermined time has elapsed (step S22) in IVI 10. For the same reason, the timing diagram is obtained by adding the step of starting timing (step S21) and the step of determining that the second predetermined time has elapsed (step S22). Figure 2 Explanations of the same steps are omitted, and appropriate references are used. Figure 2 The explanation. Additionally. Figure 3 An example is a situation where communication between object ECU 40 and IVI 10 becomes abnormal for some reason, preventing IVI 10 from receiving the update completion message from object ECU 40.

[0050] like Figure 3 As shown, when server 1 sends update data to IVI 10 (step S1), IVI 10, after sending a preparation request to GW 20 (step S2), starts timing (step S21). Then, if IVI 10 determines in step S22 that a second predetermined time has elapsed, it sends a termination request to GW 20 (step S11). Thus, even if communication between object ECU 40 and IVI 10 is abnormal for some reason, preventing IVI 10 from receiving the update completion from object ECU 40, IVI 10 can still send a termination request to GW 20. Upon receiving the termination request, GW 20 sends a release request to BCM 30, thereby enabling BCM 30 to release the vehicle from the prohibited driving state.

[0051] Next, use Figure 4 The process of controlling the software update method executed by the software update apparatus according to the first embodiment will be described. Figure 4 This is a timing diagram illustrating an example of the control processing of a software update method when an error occurs, as performed by the software update apparatus in the first embodiment. Figure 4 The control process shown is an example of control processing where decision processing is performed in each controller. Figure 4 The example shown is a control process where the GW 20 has a determination unit and determines that a predetermined time has elapsed. Figure 4 It shows the Figure 3 The timing diagram is obtained by adding the step of starting the timing in GW 20 (step S31) and the step of determining that the first predetermined time has elapsed (step S32). For the time interval... Figure 2 and Figure 3 Explanations of the same steps are omitted, and appropriate references are used. Figure 2 and Figure 3 The explanation. Additionally. Figure 4 An example is a situation where communication between IVI10 and GW20 becomes abnormal for some reason, preventing GW20 from receiving the termination request from IVI10.

[0052] like Figure 4 As shown, when IVI 10 sends a preparation request to GW 20 (step S2), GW 20, after sending execution approval to IVI 10 (step S3), starts timing (step S31). Then, if GW 20 determines in step S32 that a first predetermined time has elapsed, it sends a release request to BCM 30 (step S13). Thus, even if communication between IVI 10 and GW 20 is abnormal for some reason, preventing GW 20 from receiving the termination request from IVI 10, GW 20 can still send a release request to BCM 30. Upon receiving the release request, BCM 30 can release the vehicle from the prohibited driving state.

[0053] Next, use Figure 5 The process of controlling the software update method executed by the software update apparatus according to the first embodiment will be described. Figure 5 This is a timing diagram illustrating an example of the control processing of a software update method when an error occurs, as performed by the software update apparatus in the first embodiment. Figure 5 The control process shown is an example of control processing where decision processing is performed in each controller. Figure 5 The image shows an example of control processing where the BCM 30 has a determination unit and determines that a predetermined time has elapsed. Figure 5 It shows the Figure 4The timing diagram is obtained by adding the step of starting the timing (step S51) and the step of determining that the third predetermined time has elapsed in BCM 30 (step S52). For the time interval... Figure 2 , Figure 3 as well as Figure 4 Explanations of the same steps are omitted, and appropriate references are used. Figure 2 , Figure 3 as well as Figure 4 The explanation. Additionally. Figure 5 An example is a situation where communication between GW 20 and BCM 30 becomes abnormal for some reason, making it impossible to receive a release request from GW 20.

[0054] like Figure 5 As shown, when GW 20 sends a change request to BCM 30 (step S4), BCM 30 changes the vehicle to a prohibited driving state (step S5) and then starts timing (step S51). Then, if BCM 30 determines in step S52 that a third predetermined time has elapsed, it releases the prohibited driving state of the vehicle (step S14). Therefore, even if communication between GW 20 and BCM 30 is abnormal for some reason, preventing BCM 30 from receiving the release request from GW 20, BCM 30 can still release the prohibited driving state of the vehicle.

[0055] In this embodiment, IVI 10 (first controller), GW 20 (second controller), and BCM 30 (third controller) are each equipped with a decision unit. In the software update system, since IVI 10 and GW 20 control and manage the system, timers are set on IVI 10 and GW 20 to perform decision processing as a response to system anomalies. However, there are also cases where IVI 10 and GW 20, as the system's control and management sides, malfunction. As a last resort to prevent such situations, a timer is also set on the BCM 30 side for decision processing.

[0056] Furthermore, embodiments of the controller equipped with a determination unit are not limited to those described above. Either IVI 10 or GW 20, serving as the control and management side, may have a determination unit. For example, IVI 10 may not have a determination unit, while GW 20 and BCM 30 may have determination units. Alternatively, GW 20 may not have a determination unit, while IVI 10 and BCM 30 may have determination units. Alternatively, BCM 30 may not have a determination unit, while IVI 10 and GW 20, serving as the control and management side, may have determination units. Additionally, as other embodiments, IVI 10 and GW 20 may not have determination units, while BCM 30 may have a determination unit. Alternatively, GW 20 and BCM 30 may not have determination units, while IVI 10 may have a determination unit. Alternatively, IVI 10 and BCM 30 may not have determination units, while GW 20 may have a determination unit. Descriptions of the structures and processes in each embodiment are omitted, but appropriate descriptions related to the structures and processes described above are referenced.

[0057] In addition, in this embodiment, during the timing control of software updates, the target ECU 40 communicates with the IVI 10, but it is not limited to this; the target ECU 40 may also communicate with the GW 20. Figure 6 This is a block diagram illustrating an example of a software update system according to the first embodiment. Figure 6 It is shown in Figure 1 This diagram illustrates an example of a software update system where data transmission and reception occur between the IVI 10 and the target ECU 40, rather than between the IVI 10 and the target ECU 40. Figure 6 As shown, IVI 10 can also send update data and update start requests to the target ECU 40 via GW 20, and receive update completion from the target ECU 40 via GW 20.

[0058] As described above, the software update apparatus according to this embodiment includes: an update control unit that controls the software update of a vehicle's ECU; a vehicle state control unit that controls the transition of the vehicle to a prohibited driving state and the release of the prohibited driving state; and a determination unit that uses a timer to determine whether a predetermined time has elapsed. The update control unit sends a software update preparation request. After the update control unit sends the software update preparation request, the determination unit starts timing and determines whether a predetermined time has elapsed. After the update control unit sends the software update preparation request, the vehicle state control unit transitions the vehicle to a prohibited driving state, and if the determination unit determines that a predetermined time has elapsed, it releases the prohibited driving state. Therefore, even if the completion of the vehicle's software update cannot be confirmed after it is completed, driving of the vehicle can still begin.

[0059] As described above, in the software update method according to this embodiment, the software update apparatus performs the following processes: sending a software update preparation request for the vehicle's ECU; after sending the software update preparation request, changing the vehicle to a prohibited driving state; after sending the software update preparation request, starting a timer and determining whether a predetermined time has elapsed; and if it is determined that the predetermined time has elapsed, releasing the prohibited driving state of the vehicle. Therefore, even if the completion of the vehicle's software update cannot be confirmed after it is completed, driving of the vehicle can still begin.

[0060] As described above, the software update system according to this embodiment includes: a vehicle ECU; an update control unit that controls the software update of the ECU; a vehicle state control unit that controls the transition of the vehicle to a prohibited driving state and the release of the prohibited driving state; and a determination unit that uses a timer to determine whether a predetermined time has elapsed. The update control unit sends a software update preparation request. After the update control unit sends the software update preparation request, the determination unit starts timing and determines whether a predetermined time has elapsed. After the update control unit sends the software update preparation request, the vehicle state control unit transitions the vehicle to a prohibited driving state, and if the determination unit determines that a predetermined time has elapsed, it releases the prohibited driving state. Therefore, even if the completion of the vehicle's software update cannot be confirmed after it is completed, driving of the vehicle can still begin.

[0061] Furthermore, the software update apparatus 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 sends a software update preparation request to the second controller via the update control unit. Upon receiving the software update preparation request from the first controller, the second controller sends a request to the third controller to change the vehicle to a prohibited driving state, starts a timer via the determination unit, and determines whether a first predetermined time has elapsed. If the first predetermined time has elapsed, the second controller sends a request to the third controller to remove the prohibited driving state. Upon receiving the request to change the vehicle to a prohibited driving state from the second controller, the third controller changes the vehicle to a prohibited driving state via the vehicle state control unit. Upon receiving the request to remove the prohibited driving state from the second controller, the third controller removes the prohibited driving state via the vehicle state control unit. Therefore, even if the completion of the vehicle's software update cannot be confirmed in the third controller due to some abnormality in the first controller, the vehicle can still be driven after the software update is completed.

[0062] Furthermore, in the software update apparatus according to this embodiment, the first controller also includes a determination unit. When the vehicle user gives an instruction to execute a software update, the update control unit sends a software update preparation request to the second controller. The determination unit starts a timer and determines whether a second predetermined time has elapsed. If the second predetermined time has elapsed, the first controller sends a software update termination request to the second controller. Upon receiving the software update termination request from the first controller, the second controller sends a vehicle driving prohibition request to the third controller. Therefore, even if some communication abnormality occurs between the first controller and the ECU (Electronic Control Unit) to be updated, a driving prohibition request is sent to the third controller, allowing the vehicle to be driven after the software update is completed.

[0063] Furthermore, in the software update apparatus according to this embodiment, the first predetermined time is longer than the second predetermined time. Therefore, even if the second predetermined time has elapsed but no software update termination request is sent from the first controller, a request to lift the driving restriction state can be sent to the third controller based on the elapsed time determination in the second controller.

[0064] Furthermore, in the software update apparatus according to this embodiment, the third controller also includes a determination unit. When the third controller receives a request from the second controller to change the vehicle to a prohibited driving state, the determination unit starts a timer and determines whether a third predetermined time has elapsed. If the third controller determines that the third predetermined time has elapsed, the vehicle state control unit removes the prohibited driving state from the vehicle. Therefore, even if a request to remove the prohibited driving state is not sent to the third controller due to some abnormality in the first and second controllers, the vehicle can still be driven after the software update is completed.

[0065] Furthermore, in the software update apparatus according to this embodiment, the third predetermined time is longer than the first predetermined time. Therefore, even if no request to lift the driving restriction state is sent from the second controller after the first predetermined time has elapsed, the driving restriction state can be lifted based on the elapsed time determination in the third controller.

[0066] Furthermore, in the software update apparatus according to this embodiment, the vehicle status control unit prevents the vehicle's ignition switch from being turned on when driving is prohibited. Therefore, it is possible to prevent the ignition switch from being turned on during a software update.

[0067] Furthermore, in the software update apparatus according to this embodiment, the determination unit sets a predetermined time based on the time required for the software update contained in the update data. Therefore, even if the completion of the vehicle's software update cannot be confirmed, the vehicle can begin operation after the required update time has elapsed.

[0068] <<Second Implementation Method>>

[0069] In the first embodiment, the GW 20 between IVI 10 and BCM 30 relays information transmission and reception. However, in the second embodiment, IVI 10 and BCM 30 directly transmit and receive information. Figure 7 The software update system according to the second embodiment of the present invention will be described below. Figure 7 This is a block diagram of a software update system according to the second embodiment of the present invention. The structures other than those described below are the same as those in the first embodiment described above. In the following description, descriptions of structures and control processes identical to those in the first embodiment are omitted, and for omitted descriptions, appropriate references are made to the descriptions in the first embodiment.

[0070] 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 status control unit 301 and a determination unit 302. Upon receiving update data from the server 1, the IVI 10 sends a software update preparation request to the BCM 30 via the update control unit 101. Upon receiving a status transition completion notification from the BCM 30, the IVI 10 sends an update start request to the target ECU 40. Upon receiving an update completion notification from the target ECU 40, the IVI 10 sends a release request to the BCM 30. Upon receiving an update completion notification from the BCM 30, the IVI 10 sends an update completion notification to the server 1. Alternatively, after sending the preparation request, the IVI 10 may start a timer via the determination 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.

[0071] Upon receiving a software update preparation request from IVI 10, BCM 30 transitions the vehicle to a prohibited driving state via Vehicle Status Control Unit 301. After transitioning to the prohibited driving state, BCM 30 sends a status transition completion message to IVI 10. Upon receiving a release request from IVI 10, BCM 30 releases the prohibited driving state. After releasing the prohibited driving state, BCM 30 sends a release completion message to IVI 10. Furthermore, after the vehicle transitions to the prohibited driving state, BCM 30 starts a timer via Determination Unit 302 and determines whether a first predetermined time has elapsed. If the first predetermined time has elapsed, BCM 30 releases the prohibited driving state via Vehicle Status Control Unit 301. After releasing the prohibited driving state, BCM 30 sends a release completion message to IVI 10.

[0072] Furthermore, in this embodiment, IVI 10 (first controller) includes an update control unit and a determination unit, and BCM 30 (second controller) includes a vehicle state control unit and a determination unit. However, embodiments of controllers including a determination unit are not limited to this. Alternatively, BCM 30 may not have a determination unit, while IVI 10 may have a determination unit. Alternatively, IVI 10 may not have a determination unit, while BCM 30 may have a determination unit.

[0073] As described above, the software update apparatus according to this embodiment includes: a first controller, which includes an update control unit; and a second controller, which includes a determination unit and a vehicle state control unit. The first controller sends a software update preparation request to the second controller via the update control unit. Upon receiving the software update preparation request from the first controller, the second controller uses the vehicle state control unit to put the vehicle into a prohibited driving state, the determination unit starts a timer, and determines whether a first predetermined time has elapsed. If it is determined that the first predetermined time has elapsed, the vehicle state control unit removes the prohibited driving state from the vehicle. Therefore, even if the completion of the vehicle's software update cannot be confirmed in the second controller due to some abnormality in the first controller, the vehicle can still be driven after the software update is completed.

[0074] Furthermore, the embodiments described above are provided for ease of understanding of the present invention and are not intended to limit the present invention. Therefore, the essence of the elements disclosed in the above embodiments is that they also include all design modifications and equivalents that fall within the technical scope of the present invention.

[0075] Explanation of reference numerals in the attached figures

[0076] 100… Software Update System

[0077] 1… server

[0078] 2…Software update device

[0079] 101…Update Control Department

[0080] 102, 202, 302… Judgment Department

[0081] 301…Vehicle Status Control Department

Claims

1. A software update device, comprising: Update the control unit, which is the software update of the electronic control unit (ECU) that controls the vehicle; The vehicle status control unit controls the transition of the vehicle to a prohibited driving state and the release of the prohibited driving state of the vehicle. as well as The judgment unit uses a timer to determine whether a specified time has elapsed. The update control unit sends a preparation request for the software update. After the update control unit sends the software update preparation request, the determination unit starts the timer and determines whether the predetermined time has elapsed. After the update control unit sends the software update preparation request, the vehicle status control unit puts the vehicle into a prohibited driving state. If the determination unit determines that the predetermined time has elapsed, the vehicle status control unit removes the vehicle from the prohibited driving state.

2. The software update apparatus according to claim 1, wherein, The system includes a first controller, a second controller, and a third controller, wherein the first controller includes the update control unit, the second controller includes the determination unit, and the third controller includes the vehicle state control unit. The first controller sends a software update preparation request to the second controller through the update control unit. Upon receiving the software update preparation request from the first controller, the second controller sends a request to the third controller to transition the vehicle to a prohibited driving state. The determination unit then starts the timer and determines whether a first predetermined time has elapsed. If the second controller determines that the first predetermined time has elapsed, it sends a request to the third controller to lift the vehicle's driving restriction status. Upon receiving a request from the second controller to change the vehicle to a prohibited driving state, the third controller, through the vehicle state control unit, changes the vehicle to a prohibited driving state. Upon receiving a request from the second controller to lift the vehicle's driving restriction status, the third controller lifts the driving restriction status of the vehicle through the vehicle status control unit.

3. The software update apparatus according to claim 2, wherein, The first controller also includes the determination unit. When the user of the vehicle gives the instruction to perform the software update, the first controller sends a software update preparation request to the second controller through the update control unit, the determination unit starts the timer, and determines whether a second predetermined time has elapsed. If the first controller determines that the second predetermined time has elapsed, it sends a request to the second controller to end the software update. Upon receiving a request from the first controller to end the software update, the second controller sends a request to the third controller to remove the vehicle's prohibited driving status.

4. The software update apparatus according to claim 3, wherein, The first specified time is longer than the second specified time.

5. The software update apparatus according to any one of claims 2 to 4, wherein, The third controller also includes the determination unit. Upon receiving a request from the second controller to transition the vehicle to a prohibited driving state, the third controller starts the timer via the determination unit and determines whether a third predetermined time has elapsed. When the third controller determines that the third predetermined time has elapsed, it releases the vehicle from the driving prohibition state through the vehicle status control unit.

6. The software update apparatus according to claim 5, wherein, The third specified time is longer than the first specified time.

7. The software update apparatus according to claim 1, wherein, The system includes a first controller and a second controller, wherein the first controller includes the update control unit, and the second controller includes the determination unit and the vehicle state control unit. The first controller sends a software update preparation request to the second controller through the update control unit. Upon receiving the software update preparation request from the first controller, the second controller, through the vehicle status control unit, switches the vehicle to a prohibited driving state, and through the determination unit, starts the timer and determines whether a first predetermined time has elapsed. If the second controller determines that the first predetermined time has elapsed, it will release the vehicle from the driving prohibition state through the vehicle status control unit.

8. The software update apparatus according to any one of claims 1 to 7, wherein, The vehicle status control unit prevents the ignition switch of the vehicle from being turned on during the prohibited driving state.

9. The software update apparatus according to claim 1, wherein, The determination unit sets the specified time based on the time required for the software update contained in the update data of the software update.

10. A software update method, which is a software update method executed by a software update device, wherein, The software update device performs the following processing: Send a request to prepare for a software update of the vehicle's electronic control unit (ECU). After sending the software update preparation request, the vehicle is put into a prohibited driving state; After sending the software update preparation request, start the timer and determine whether the specified time has elapsed; as well as If it is determined that the specified time has elapsed, the vehicle's driving restriction status will be lifted.

11. A software update system, comprising: The vehicle's electronic control unit is called the ECU; Update control unit, which controls the software update of the ECU; The vehicle status control unit controls the transition of the vehicle to a prohibited driving state and the release of the prohibited driving state of the vehicle. as well as The judgment unit uses a timer to determine whether a specified time has elapsed. The update control unit sends a preparation request for the software update. After the update control unit sends the software update preparation request, the determination unit starts the timer and determines whether the predetermined time has elapsed. After the update control unit sends the software update preparation request, the vehicle status control unit puts the vehicle into a prohibited driving state. If the determination unit determines that the predetermined time has elapsed, the vehicle status control unit removes the vehicle from the prohibited driving state.

Images