Master device, vehicle system, software update method, and software update control program

Abstract

An OTA master (14) performs a series of processes related to a software update on an update target device to be subjected to the software update. When a vehicle transitions from a normal state to a functionally degraded state during execution of a software update, it is determined whether to continue or stop the software update. If it is determined that the software update should be continued, the software update is continued. If it is determined that the software update should be stopped, the software update is stopped.

Description

Master device, vehicle system, software update method, and software update control program CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is based on Japanese Application No. 2024-72799, filed on April 26, 2024, the contents of which are incorporated herein by reference.

[0002] The present disclosure relates to a master device, a vehicle system, a software update method, and a software update control program.

[0003] Vehicles are equipped with numerous electronic control units (hereinafter referred to as ECUs (Electronic Control Units)). With the diversification of vehicle control, such as driver assistance functions and autonomous driving functions, OTA (Over-the-Air) repro technology has been provided for wirelessly updating software installed in ECUs. In OTA repro, an OTA master in the vehicle distributes software downloaded from an OTA center to a target ECU, which is a device to be updated, and instructs the target ECU to update the software, causing the target ECU to update the software (see, for example, Patent Document 1).

[0004] Japanese Patent Application Laid-Open No. 2020-27627

[0005] In a vehicle, for example, when the power source becomes low while driving, it is conceivable that the vehicle will transition from the normal state to the degraded-function state in order to prioritize reaching the destination. For example, in an electric vehicle such as a BEV powered by electricity from an onboard battery, it is conceivable that the vehicle will transition from the normal state to the degraded-function state when the remaining battery charge becomes low. In a non-electric vehicle powered by fuel such as gasoline, it is conceivable that the vehicle will transition from the normal state to the degraded-function state when the remaining fuel charge becomes low. On the other hand, when the above-mentioned OTA reprogramming is performed while driving, it is conceivable that the vehicle will transition from the normal state to the degraded-function state during the OTA reprogramming. Furthermore, when OTA reprogramming is performed while parked, it is conceivable that the vehicle will transition from the normal state to the degraded-function state during the OTA reprogramming. Therefore, there is a need for a mechanism for controlling the behavior of OTA reprogramming when the vehicle transitions from the normal state to the degraded-function state.

[0006] The present disclosure aims to appropriately control the behavior of a software update when a vehicle transitions from a normal state to a degraded functionality state while a software update is being performed.

[0007] A master device of one aspect of the present disclosure is a master device that performs a series of processes related to a software update on an update target device that is the target of the software update, and when the vehicle transitions from a normal state to a functionally degraded state while the software update is being performed, determines whether to continue or stop the software update, and if it determines that the software update should be continued, it continues the software update, and if it determines that the software update should be stopped, it stops the software update.

[0008] A vehicle system according to one aspect of the present disclosure includes a master device that performs a series of processes related to a software update on an update target device that is the target of the software update, and the update target device, wherein the master device determines whether to continue or stop the software update when the vehicle transitions from a normal state to a degraded function state during the software update, and continues the software update if it determines that the software update should be continued, or stops the software update if it determines that the software update should be stopped.

[0009] In one aspect of the software update method of the present disclosure, a master device performs a series of processes related to a software update on an update target device that is the target of the software update, and when a vehicle transitions from a normal state to a functionally degraded state while the software update is being performed, the master device determines whether to continue or stop the software update, and if it determines that the software update should be continued, the master device continues the software update, or if it determines that the software update should be stopped, the master device performs an update determination procedure to stop the software update.

[0010] A software update control program according to one aspect of the present disclosure causes a master device, which performs a series of processes related to a software update on an update target device that is the target of the software update, to execute an update determination procedure that determines whether to continue or stop the software update when the vehicle transitions from a normal state to a functionally degraded state while the software update is being performed, and continues the software update if it determines that the software update should be continued, or stops the software update if it determines that the software update should be stopped.

[0011] According to one aspect of the present disclosure, when a vehicle transitions from a normal state to a degraded state during a software update, a determination is made as to whether to continue or stop the software update, and if it is determined that the software update should be continued, the software update is continued, and if it is determined that the software update should be stopped, the software update is stopped. This makes it possible to appropriately control the behavior of the software update when the vehicle transitions from the normal state to a degraded state during a software update.

[0012] The above and other objects, features, and advantages of the present disclosure will become more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which Fig. 1 is a diagram showing the overall configuration of one embodiment, Fig. 2 is a functional block diagram of the ReproMaster, Fig. 3 is a diagram showing a control table, Fig. 4 is a flowchart, and Fig. 5 is a flowchart.

[0013] An embodiment will now be described with reference to the drawings. As shown in FIG. 1 , a data communication system 1 is configured to enable data communication between an over-the-air (OTA) center 2 and a vehicle system 3 installed in a vehicle. An unspecified number of vehicle systems 3 can communicate with the OTA center 2. The vehicle is, for example, an electric vehicle, such as a battery-powered vehicle (BEV), powered by an onboard battery. Unlike non-electric vehicles, such as gasoline-powered vehicles, electric vehicles can freely control the power supply of all ECUs installed in the vehicle using software. In this embodiment, the present invention is applied to an electric vehicle, and a transition from a normal state to a degraded-function state is illustrated based on a remaining battery level indicating the remaining charge of an onboard battery, which is the power source of the electric vehicle, as described below. However, the present invention may also be applied to a non-electric vehicle, and a transition from a normal state to a degraded-function state is based on the remaining charge of, for example, gasoline, which is the power source of the non-electric vehicle.

[0014] Furthermore, although the present embodiment illustrates an example in which the vehicle transitions from the normal state to the reduced-function state while driving, the present embodiment may also be applied to a case in which the vehicle transitions from the normal state to the reduced-function state while parking. The reduced-function state while driving refers to, for example, reducing the consumption of power sources while driving by stopping the operation of functions that are not related to driving while continuing the operation of functions related to driving. The reduced-function state while parking refers to, for example, reducing the frequency with which functions that are activated while parking are activated to reduce the consumption of power sources while parking.

[0015] The vehicle system 3 includes an in-vehicle communication device (hereinafter referred to as DCM (Data Communication Module)) 4, a central gateway (hereinafter referred to as CGW (Central Gateway)) 5, a first relay 6 (corresponding to the device to be updated), a second relay 7 (corresponding to the device to be updated), and a third relay 8 (corresponding to the device to be updated). The CGW 5, the first relay 6, the second relay 7, and the third relay 8 are referred to as domain controllers. The first relay 6, the second relay 7, and the third relay 8 are connected to the CGW 5, for example, via Ethernet (registered trademark).

[0016] The OTA center 2 generates and stores an update package including software and specification data to be updated. The OTA center 2 also stores update packages acquired from external sources, such as an OEM (Original Equipment Manufacturer). The OTA center 2 includes a configuration management function unit that manages the vehicle hardware and software configurations that may be targets for the update package distribution, and a distribution management function unit that manages the distribution of the update package to the vehicle. The software includes programs, data, libraries, etc. for operating the ECU.

[0017] The specification data includes information capable of identifying an ECU compatible with OTA, information capable of identifying a target ECU that is the target of the software update, information capable of identifying an installation target in the installation phase described below, information capable of identifying the order of installation, information capable of identifying an activation target in the activation phase described below, information capable of identifying the order of activation, etc. An ECU compatible with OTA is an ECU that can implement OTA. The OTA center 2 may include the specification data in an update package and distribute it to the vehicle, or may distribute the specification data to the vehicle separately from the update package without including the specification data in the update package.

[0018] The DCM 4 performs data communication with the OTA center 2 via a communication network. The communication network may include, for example, a mobile communication network using a 4G line or a 5G line, the Internet, Wi-Fi (Wireless Fidelity) (registered trademark), etc. The DCM 4 and the CGW 5 may be integrated, and the functions of the DCM 4 may be incorporated into the CGW 5. Alternatively, the functions of the DCM 4 and the CGW 5 may be incorporated into a display device or the like. When the DCM 4 receives an update package distributed from the OTA center 2, the DCM 4 forwards the received update package to the CGW 5. Software distributed from the OTA center 2 to the DCM 4 is, for example, OTA repro software. Inter-center communication, which is data communication between the OTA center 2 and the DCM 4, uses, for example, an SOVD format conforming to the SOVD communication specifications or a Rest (REpresentational State Transfer) API format conforming to the Rest API communication specifications. A software update using an update package distributed from the OTA center 2 is called wireless repro. On the other hand, a software update using an update package distributed from an external tool (described later) is called wired repro.

[0019] The CGW 5 includes a ReproMaster 9, an in-vehicle HMI (Human Machine Interface) 10, a remote diagnostics 11, and an onboard client (hereinafter referred to as OBC) 12. As shown in Fig. 2, the ReproMaster 9 includes a downloader 13 and an OTA master 14 (corresponding to a master device).

[0020] When a download execution request is input from the OTA master 14, the downloader 13 instructs the DCM 4 to execute the download process. The update package distributed from the OTA center 2 is received by the DCM 4, and the received update package is transferred from the DCM 4, whereby the downloader 13 downloads the update package from the OTA center 2 via the DCM 4. The downloaded update package is temporarily stored in the ReproMaster 9 or an external memory, which will be described later.

[0021] The OTA master 14 includes an update control function unit 15, a state management function unit 16, a display control function unit 17, a write control function unit (Flashing Adapter) 18, a power control function unit 19, an OTA-compatible ECU list storage unit 20, and a campaign target ECU list storage unit 21. These functions are realized by software processing in which a microcomputer executes a computer program stored in a non-transient physical storage medium using a CPU, or by hardware processing using a dedicated electronic circuit.

[0022] The update control function unit 15 has a function of controlling software updates. The state management function unit 16 has a function of managing the state of the software to be updated in accordance with the software update. The display control function unit 17 has a function of controlling the display on the in-vehicle HMI 10 in accordance with the software update. The write control function unit 18 has a function of controlling the installation of software to the software to be updated.

[0023] The OTA-compatible ECU list storage unit 20 stores information included in the specification data that can identify ECUs that are compatible with OTA as an OTA-compatible ECU list. The campaign target ECU list storage unit 21 stores information included in the specification data that can identify target ECUs as a campaign target ECU list. Among the ECUs that are compatible with OTA, an ECU that is recorded in the campaign target ECU list is the target ECU, and among the ECUs that are compatible with OTA, an ECU that is not recorded in the campaign target ECU list is an ECU that is not eligible for the campaign.

[0024] The power supply control function unit 19 refers to the OTA-compatible ECU list and identifies an ECU that supports OTA. The power supply control function unit 19 refers to the campaign target ECU list and identifies a target ECU. The power supply control function unit 19 cooperates with the power supply control app 22 located in the second relay 7 to control the power supply to the ECU as the software update progresses. Note that, although the present embodiment illustrates a case in which the power supply control function unit 19 cooperates with the power supply control app 22 to control the power supply to the ECU, a configuration in which a power control ECU that controls the power supply to the ECU is located may also be used. Targets for which the power supply control function unit 19 controls power supply include the DCM 4, the in-vehicle HMI 10, the first relay 6, the second relay 7, the third relay 8, etc.

[0025] The OBC 12 includes an arbitration function unit 23 and a diagnostic communication function unit 24. The arbitration function unit 23 is responsible for diagnostic communication between the ReproMaster 9 and the repeater or ECU, and arbitrates which diagnostic communication should be prioritized. The diagnostic communication function unit 24 performs diagnostic communication between the ReproMaster 9 and the repeater or ECU according to the arbitration result of the arbitration function unit 23.

[0026] The OBC 12 is connected to a plurality of ECUs 25, 26 (corresponding to devices to be updated) via a first repeater 6. The plurality of ECUs 25, 26 are connected to the first repeater 6 via, for example, a CAN bus. CAN communication between the first repeater 6 and the plurality of ECUs 25, 26 is data communication using a 29-bit CAN ID. Of the plurality of ECUs 25, 26 connected to the first repeater 6, an ECU whose software is to be updated can be the target ECU. Although the example shows a case where two ECUs are connected to the first repeater 6, the number of ECUs connected to the first repeater 6 is not limited to two.

[0027] Similarly, the OBC 12 is connected to a plurality of ECUs 27, 28 (corresponding to update target devices) via a second relay 7. The plurality of ECUs 27, 28 are connected to the second relay 7 via, for example, a CAN bus. CAN communication between the second relay 7 and the plurality of ECUs 27, 28 is data communication using a 29-bit CAN ID. Of the plurality of ECUs 27, 28 connected to the second relay 7, an ECU whose software is to be updated can be the target ECU. Although the example shows a case where two ECUs are connected to the second relay 7, the number of ECUs connected to the second relay 7 is not limited to two.

[0028] Similarly, the OBC 12 is connected to a plurality of ECUs 29, 30 (corresponding to update target devices) via a third relay 8. The plurality of ECUs 29, 30 are connected to the third relay 8 via, for example, a CAN bus. CAN communication between the third relay 8 and the plurality of ECUs 29, 30 is data communication using a 29-bit CAN ID. Of the plurality of ECUs 29, 30 connected to the third relay 8, an ECU whose software is to be updated can be the target ECU. Although the example shows a case where two ECUs are connected to the third relay 8, the number of ECUs connected to the third relay 8 is not limited to two.

[0029] Furthermore, the OBC 12 is connected to an ECU 31 (corresponding to the device to be updated) without a repeater. Among the multiple ECUs connected to the OBC 12, the ECU whose software is to be updated can be the target ECU. While the example shows a case where one ECU is connected to the OBC 12 without a repeater, the number of ECUs connected to the OBC 12 without a repeater is not limited to one. The CAN communication between the first repeater 6 and the multiple ECUs 25, 26, the CAN communication between the second repeater 7 and the multiple ECUs 27, 28, and the CAN communication between the third repeater 8 and the multiple ECUs 29, 30 may be data communication using an 11-bit CAN ID.

[0030] As described above, the power control application 22 arranged in the second repeater 7 cooperates with the power control function unit 19 of the OTA master 14, and controls the power supply to the DCM 4, the in-vehicle HMI 10, the repeaters 6 to 8, and the ECUs 25 to 31 as the software update progresses. That is, the OTA master 14 cooperates the power control function unit 19 with the power control application 22, and controls the power supply to the repeaters 6 to 8 and the ECUs 25 to 31 that are capable of diagnostic communication via the diagnostic communication function unit 24. When a startup request is input from the OTA master 14 while the DCM 4, the in-vehicle HMI 10, the repeaters 6 to 8, and the ECUs 25 to 31 are in a stopped state, they transition to a started state, and power supply from the in-vehicle battery begins. When a stop request is input from the OTA master 14 to the DCM 4, the in-vehicle HMI 10, the repeaters 6 to 8, and the ECUs 25 to 31 in an activated state, the DCM 4, the in-vehicle HMI 10, the repeaters 6 to 8, and the ECUs 25 to 31 transition to a stopped state, and the power supply from the in-vehicle battery is stopped.

[0031] The external tool 32, while attached to a connector provided in the vehicle, delivers the update package to the OTA master 14. The external memory 33 functions as external storage for the OTA master 14, and as a temporary storage destination for the update package downloaded from the OTA center 2 as described above, and also as a temporary save destination for pre-update software when updating the software of the repeaters 6 to 8 and the ECUs 25 to 31.

[0032] A series of processing phases related to a software update includes a configuration synchronization phase, a download phase, an installation phase, an activation phase, and an update completion notification phase. The configuration synchronization phase is a phase in which the OTA center 2 synchronizes configuration information of the software and hardware of the ECU installed in the target vehicle with configuration information of the software and hardware of the ECU.

[0033] The download phase is a phase in which the OTA master 14 downloads an update package from the OTA center 2. Before performing the download phase, the OTA master 14 determines, for example, whether the software to be downloaded is legitimate, and whether the download can be completed by checking the data volume of the software to be downloaded against the remaining charge of the vehicle battery. If the OTA master 14 determines, for example, that the software to be downloaded is legitimate and that the remaining charge of the vehicle battery is sufficient for the data volume of the software to be downloaded, the OTA master 14 performs the download phase.

[0034] The installation phase is a phase in which the OTA master 14 installs software extracted from the update package into the target ECU. Installation means writing the software to a storage area of ​​the target ECU. Before performing the installation phase, the OTA master 14 determines, for example, whether the software to be installed is authentic, and whether the installation can be completed by comparing the data volume of the software to be installed with the remaining charge of the vehicle battery. If the OTA master 14 determines, for example, that the software to be installed is authentic and that the remaining charge of the vehicle battery is sufficient for the data volume of the software to be installed, the OTA master 14 performs the installation phase.

[0035] The activation phase is a phase in which the installed software is activated in the target ECU. Before performing the activation phase, the OTA master 14 determines, for example, whether the software to be activated is authentic, and whether the activation can be completed by comparing the data volume of the software to be activated with the remaining charge of the vehicle battery. If the OTA master 14 determines, for example, that the software to be activated is authentic and that the remaining charge of the vehicle battery is sufficient for the data volume of the software to be activated, the OTA master 14 performs the activation phase.

[0036] The update completion notification phase is a phase in which the OTA master 14 transmits an update completion notification to the OTA center 2 when the OTA master 14 receives an update completion notification from the target ECU upon completion of activation.

[0037] As shown in FIG. 3 , the OTA master 14 maintains a control table indicating whether to continue or stop an OTA when a transition from a normal state to a reduced-function state occurs during execution of the OTA. ECUs involved in the OTA include the ECU to be updated and ECUs synchronized with the ECU to be updated. When reduced-function mode is prioritized, the OTA is stopped regardless of whether the ECU to be reduced-function is an ECU involved in the OTA or an ECU not involved in the OTA. When OTA is prioritized, the OTA is continued if the ECU to be reduced-function is an ECU not involved in the OTA, and is stopped if the ECU to be reduced-function is an ECU involved in the OTA. In other words, when OTA is prioritized, the OTA is continued if the ECU to be reduced-function is not an ECU involved in the OTA, and is stopped if the ECU to be reduced-function is an ECU involved in the OTA.

[0038] The transition from the normal state to the degraded-function state may be initiated by a passenger operation or automatically without a passenger operation. A condition for the automatic transition is, for example, when the remaining battery charge falls below a first threshold. The ECU targeted for degraded function transition when the normal state transitions to the degraded-function state because the remaining battery charge falls below the first threshold while the vehicle is parked may be different from the ECU targeted for degraded function transition when the normal state transitions to the degraded-function state because the remaining battery charge falls below the first threshold while the vehicle is driving. The ECU targeted for degraded function transition when the normal state transitions to the degraded-function state due to a passenger operation may be different from the ECU targeted for degraded function transition when the normal state transitions to the degraded-function state automatically without a passenger operation. Incidentally, an ECU synchronized with the ECU targeted for update, which is included in the ECUs involved in OTA, is an ECU that performs some processing for performing the update while the update of the ECU targeted for update is in progress and that needs to be in a non-degraded state during the update. For example, if the ECU to be updated is ECU 30 in Figure 1, the ECUs that need to be in a non-degenerate state during the update include an in-vehicle communication device 4 that communicates with the OTA center 2 regarding the update, a CGW 5 having an OTA master 14, and a third repeater 8 that relays communication regarding the update between the OTA master 14 and the ECU 30 to be updated.

[0039] Next, the operation of the above-described configuration will be described with reference to Figures 4 and 5. When the OTA master 14 starts or resumes OTA, it starts a degraded transition determination process. When the OTA master 14 starts the degraded transition determination process, it determines whether or not the OTA has transitioned from the normal state to the degraded function state, and whether or not the OTA has been completed (S1, S2). When the OTA master 14 determines that the OTA has been completed without transitioning from the normal state to the degraded function state (S2: YES), it ends the degraded transition determination process.

[0040] When the OTA master 14 determines that the OTA has transitioned from the normal state to the degraded-function state before the OTA is completed (S1: YES), it determines whether the transition from the normal state to the degraded-function state was initiated by an occupant (S3). When the OTA master 14 determines that the transition from the normal state to the degraded-function state was initiated by an occupant (S3: YES), it determines whether the ECUs involved in the OTA are included as ECUs subject to degraded function (S4). When the OTA master 14 determines that the ECUs involved in the OTA are included as ECUs subject to degraded function (S4: YES), it stops the OTA (S5, which corresponds to the update determination procedure) and ends the degraded transition determination process.

[0041] OTA may be stopped in the middle of the above-mentioned phase or after the phase is completed. For example, if it becomes necessary to stop OTA while downloading software, the OTA may be stopped in the middle of the download or after the download is completed. If OTA is stopped in the middle of a download, the software that has not yet been downloaded will be downloaded first when the OTA is resumed. Similarly, if it becomes necessary to stop OTA while installing software, the OTA may be stopped in the middle of the installation or after the installation is completed. If OTA is stopped in the middle of an installation, the software that has not yet been installed will be installed first when the OTA is resumed.

[0042] If the OTA master 14 determines that the ECUs to be subject to function degeneration do not include ECUs involved in OTA (S4: NO), it compares the remaining battery charge with a first threshold and determines whether the remaining battery charge is less than the first threshold (S6). If the OTA master 14 determines that the remaining battery charge is not less than the first threshold (S6: NO), it continues the OTA (S7, corresponding to the update determination procedure) and determines whether the OTA is complete (S8). If the OTA master 14 determines that the OTA is not complete (S8: NO), it returns to step S6 and repeats step S6 and subsequent steps. If the OTA master 14 determines that the OTA is complete (S8: YES), it ends the degeneration transition determination process.

[0043] If the OTA master 14 determines that the transition from the normal state to the degraded function state is not due to an occupant operation (S3: NO), or if the remaining battery charge is less than the first threshold (S6: YES), the OTA master 14 determines whether or not the ECUs to be subject to the degraded function include an ECU involved in the OTA (S9). If the OTA master 14 determines that the ECUs to be subject to the degraded function include an ECU involved in the OTA (S9: YES), the OTA master 14 stops the OTA (S10, which corresponds to the update determination procedure), and ends the degraded transition determination process.

[0044] When the OTA master 14 determines that the ECUs to be subject to function degeneration do not include ECUs involved in OTA (S9: NO), it determines the importance of the OTA and determines whether the OTA is important (S11). An important OTA is, for example, an OTA that is directly involved in driving, such as acceleration / deceleration, stopping, or turning, or an OTA that requires urgency. When the OTA master 14 determines that the OTA is not important (S11: NO), it stops the OTA (S10) and ends the degeneration transition determination process.

[0045] When the OTA master 14 determines that the OTA is important (S11: YES), it compares the remaining battery charge with a second threshold and determines whether the remaining battery charge is less than the second threshold (S12). The second threshold may be the same as or different from the first threshold. When the OTA master 14 determines that the remaining battery charge is less than the second threshold (S12: NO), it stops the OTA (S10, which corresponds to the update determination procedure) and ends the degeneration transition determination process.

[0046] If the OTA master 14 determines that the remaining battery charge is not less than the second threshold (S12: NO), it continues the OTA (S13, which corresponds to the update determination procedure) and determines whether the OTA is complete (S14). If the OTA master 14 determines that the OTA is not complete (S14: NO), it returns to step S12 and repeats step S12 and subsequent steps. If the OTA master 14 determines that the OTA is complete (S14: YES), it ends the degeneration transition determination process.

[0047] The above example illustrates a case where an OTA is continued if it is determined to be non-important, provided that the remaining battery charge is not less than the second threshold. However, the OTA may also be continued regardless of whether the remaining battery charge is less than the second threshold.

[0048] In the embodiment described above, when the vehicle transitions from a normal state to a functionally degraded state while a software update is being performed, the OTA master 14 determines whether to continue or stop the software update depending on whether the vehicle has transitioned from the normal state to a functionally degraded state (S1: YES).If it is determined that the software update should be continued, the OTA master 14 continues the software update (S7, S13), and if it is determined that the software update should be stopped, the OTA master 14 stops the software update (S5, S10).

[0049] As a first modification, the OTA master 14 may be configured to determine whether to continue or stop the software update when the vehicle transitions from the normal state to the degraded-function state during a software update before transitioning from the normal state to the degraded-function state. If the OTA master 14 determines that the software update should be continued, it continues the software update even after transitioning from the normal state to the degraded-function state. If the OTA master 14 determines that the software update should be stopped, it stops the software update in response to the transition from the normal state to the degraded-function state.

[0050] Before transitioning from the normal state to the reduced-function state, the OTA master 14 determines whether an ECU that is a target of reduced-function degeneration when the OTA master 14 automatically transitions from the normal state to the reduced-function state is involved in a software update. If the OTA master 14 determines that an ECU that is a target of reduced-function degeneration is involved in a software update, the OTA master 14 determines before transitioning from the normal state to the reduced-function state that the software update should be stopped in response to the automatic transition from the normal state to the reduced-function state. In this case, when the OTA master 14 determines that the OTA master 14 will automatically transition from the normal state to the reduced-function state, the OTA master 14 stops the software update.

[0051] When the OTA master 14 determines that the ECU to be subject to reduced functionality is not involved in a software update, it determines whether the software update is an important software update before transitioning from the normal state to the reduced-function state. If the OTA master 14 determines that the software update is not an important software update, it determines, before transitioning from the normal state to the reduced-function state, that the software update will be stopped in response to the automatic transition from the normal state to the reduced-function state. In this case, the OTA master 14 stops the software update when it determines that the automatic transition from the normal state to the reduced-function state will occur. If the OTA master 14 determines that the software update is important, it determines, before transitioning from the normal state to the reduced-function state, that the software update will continue even if the automatic transition from the normal state to the reduced-function state occurs until the remaining battery charge further drops below a second threshold. In this case, even if it determines that the automatic transition from the normal state to the reduced-function state occurs, the OTA master 14 continues the software update until the remaining battery charge further drops below the second threshold.

[0052] As a second variant, the OTA master 14 may be configured to determine whether to continue or stop the software update when the vehicle transitions from the normal state to the reduced-function state while the software update is being performed, before transitioning from the normal state to the reduced-function state, and if it is determined that the software update should be stopped, to stop the software update in response to the transition from the normal state to the reduced-function state; and if it is not determined that the software update should be stopped before transitioning from the normal state to the reduced-function state, to determine whether to continue or stop the software update in response to the transition from the normal state to the reduced-function state.

[0053] As described above, the embodiment and modified examples can achieve the following advantageous effects. When a vehicle transitions from a normal state to a degraded-function state during OTA execution, the OTA master 14 determines whether to continue or stop the OTA. If it determines that the OTA should be continued, the OTA is continued. If it determines that the OTA should be stopped, the OTA is stopped. This makes it possible to appropriately control the behavior of the OTA when the vehicle transitions from the normal state to the degraded-function state during OTA execution. Furthermore, although the above describes an example of a configuration in which the OTA master 14 determines whether to continue or stop the OTA when the vehicle transitions from the normal state to the degraded-function state during OTA execution, the determination may be made by a device other than the OTA master 14, such as the OTA center 2. For example, the OTA center 2 determines whether to continue or stop the OTA when the vehicle transitions from the normal state to the degraded-function state during OTA execution, and notifies the OTA master 14 of the determination result. The OTA master 14 continues the OTA when it determines, based on the notification from the OTA center 2, that the OTA should be continued. When it determines, based on the notification from the OTA center 2, that the OTA should be stopped, the OTA master 14 stops the OTA.

[0054] The present disclosure includes the following disclosures in addition to what is set forth in the claims: [1] A master device (14) that performs a series of processes related to a software update on an update target device that is the target of the software update, the master device determining whether to continue or stop the software update when a vehicle transitions from a normal state to a degraded function state during the software update, and continuing the software update if it is determined that the software update should be continued, and stopping the software update if it is determined that the software update should be stopped.

[0055] [2] The master device according to any one of [1], which determines whether to continue or stop the software update based on whether the degeneration target device that is the target of the function degeneration is involved in the software update.

[0056] [3] A master device according to [1] or [2], which determines whether the transition from the normal state to the degraded function state is due to an occupant's operation, and determines whether to continue or stop the software update, taking into account the result of the determination.

[0057] [4] The master device according to any one of [1] to [3], which, when the software update is continued, continuously determines whether to continue or stop the software update.

[0058] [5] The master device according to any one of [1] to [4], which determines whether to continue or stop updating the software based on the remaining power of the vehicle's power source.

[0059] [6] The master device according to any one of [1] to [5], which determines whether to continue or stop a software update based on the importance of the software update.

[0060] [7] A master device according to any one of [1] to [6], which determines whether to continue or stop a software update when the vehicle transitions from the normal state to the degraded function state while a software update is being performed, in response to the vehicle transitioning from the normal state to the degraded function state while a software update is being performed.

[0061] [8] A master device according to any one of [1] to [6], which determines whether to continue or stop the software update when the vehicle transitions from the normal state to the degraded function state while a software update is being performed, before the vehicle transitions from the normal state to the degraded function state, and if it is determined that the software update should be continued, continues the software update even when the vehicle transitions from the normal state to the degraded function state, and if it is determined that the software update should be stopped, stops the software update in response to the vehicle transitioning from the normal state to the degraded function state.

[0062] Although the present disclosure has been described with reference to the embodiments, it is understood that the present disclosure is not limited to the embodiments or structures. The present disclosure also encompasses various modifications and modifications within the scope of equivalents. In addition, various combinations and forms, as well as other combinations and forms including only one element, more than one element, or less than one element, are also within the scope and spirit of the present disclosure.

[0063] Although the OTA center 2 is used as an example to explain a case where wireless reprogramming is performed, the present invention can also be applied to a case where wired reprogramming is performed using an external tool 32 connected to the CGW 5 by wire.

[0064] The control unit and the method described herein may be implemented by a special-purpose computer configured by configuring a processor and memory programmed to perform one or more functions embodied in a computer program. Alternatively, the control unit and the method described herein may be implemented by a special-purpose computer configured by configuring a processor with one or more dedicated hardware logic circuits. Alternatively, the control unit and the method described herein may be implemented by one or more special-purpose computers configured by combining a processor and memory programmed to perform one or more functions with a processor configured with one or more hardware logic circuits. Furthermore, the computer program may be stored as instructions executed by a computer on a computer-readable non-transitory tangible storage medium.

Claims

1. A master device (14) that performs a series of processes related to software updates on an update target device that is the target of the software update, and that determines whether to continue or stop the software update when the vehicle transitions from a normal state to a functionally degraded state while the software update is being performed, and continues the software update if it determines that the software update should be continued, or stops the software update if it determines that the software update should be stopped.

2. The master device according to claim 1, wherein the master device determines whether to continue or stop the software update based on whether the device to be degraded, which is the target of the functional degradation, is involved in the software update.

3. The master device according to claim 1, which determines whether the transition from the normal state to the reduced function state is due to an operation by a passenger, and determines whether to continue or stop the software update based on the result of the determination.

4. The master device according to claim 1, wherein when software updating is continued, the master device continuously determines whether to continue or stop the software updating.

5. The master device according to claim 1, which determines whether to continue or stop software update based on the remaining power of the vehicle's power source.

6. The master device according to claim 1, wherein the master device determines whether to continue or stop a software update based on the importance of the software update.

7. A master device as described in claim 1, which determines whether to continue or stop the software update when the vehicle transitions from the normal state to the degraded function state while the software update is being performed, in response to the vehicle transitioning from the normal state to the degraded function state while the software update is being performed.

8. A master device as described in claim 1, which determines whether to continue or stop the software update when the vehicle transitions from the normal state to the degraded function state while a software update is being performed, before the vehicle transitions from the normal state to the degraded function state, and if it is determined that the software update should be continued, continues the software update even when the vehicle transitions from the normal state to the degraded function state, and if it is determined that the software update should be stopped, stops the software update in response to the vehicle transitioning from the normal state to the degraded function state.

9. A vehicle system (3) comprising a master device (14) that performs a series of processes related to software updates on update target devices that are the targets of software updates, and the update target devices (6 to 8, 25 to 31), wherein the master device determines whether to continue or stop the software update when the vehicle transitions from a normal state to a degraded function state while the software update is being performed, and continues the software update if it determines that the software update should be continued, or stops the software update if it determines that the software update should be stopped.

10. A software update method in which a master device (14) performs a series of processes related to software updates on an update target device that is the target of the software update, the method including: determining whether to continue or stop the software update when the vehicle transitions from a normal state to a degraded function state while the software update is being performed; continuing the software update if it is determined that the software update should be continued; and stopping the software update if it is determined that the software update should be stopped.

11. A software update control program that causes a master device (14) that performs a series of processes related to software updates on an update target device that is the target of a software update to execute an update determination procedure that determines whether to continue or stop the software update when the vehicle transitions from a normal state to a functionally degraded state while the software update is being performed, and continues the software update if it determines that the software update should be continued, or stops the software update if it determines that the software update should be stopped.

12. A software update method in a data communication system (1) comprising a center device (2), a master device (14) that performs a series of processes related to software updates using update data acquired from the center device on update target devices that are the targets of software updates, and the update target devices (6-8, 25-31), the method including: determining whether to continue or stop the software update when a vehicle transitions from a normal state to a degraded function state while the software update is being performed; continuing the software update if it is determined that the software update should be continued; and stopping the software update if it is determined that the software update should be stopped.

Images