Power supply control device, power supply control system, power supply control method, and power supply control program
The power supply control system optimizes power distribution to ECUs based on vehicle state during software updates, addressing unnecessary consumption by selectively supplying power only to required ECUs, thereby improving energy efficiency.
Patent Information
- Application Number
- PCT/JP2025/000167
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-03-28
- Filing Date
- 2025-01-07
- Publication Date
- 2025-10-02
AI Technical Summary
Existing power supply control systems in vehicles, particularly electric vehicles, result in unnecessary power consumption during software updates due to continuous power supply to ECUs that do not require it, leading to inefficiencies.
A power supply control device and method that dynamically manage power distribution to ECUs based on vehicle state, ensuring power is supplied only to those that need it during software updates, and not to those that do not, using a system that includes an OTA master, repeaters, and ECUs connected via CAN bus.
This approach effectively reduces unnecessary power consumption by optimizing power supply to ECUs during software updates, enhancing energy efficiency and reducing wastage.
Smart Images

Figure JP2025000167_02102025_PF_FP_ABST
Abstract
Description
Power supply control device, power supply control system, power supply control method, and power supply control program CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is based on Japanese Application No. 2024-053763 filed on March 28, 2024, the contents of which are incorporated herein by reference.
[0002] The present disclosure relates to a power supply control device, a power supply control system, a power supply control method, and a power supply control program.
[0003] A vehicle is equipped with a large number of electronic control units (hereinafter referred to as ECUs (Electronic Control Units)). For example, in non-electric vehicles such as gasoline-powered vehicles, power supply is collectively controlled for each power state group, such as +B, accessory (hereinafter referred to as ACC), and ignition (hereinafter referred to as IG). Therefore, if it is necessary to continue supplying power to the IG-related ECUs even after the IG is turned off, measures such as delay control to continue the power supply for a certain period of time after the IG is turned off, or control to switch between the activated state and the stopped state using a CAN command are required. On the other hand, in electric vehicles such as battery electric vehicles (hereinafter referred to as BEVs (Battery Electric Vehicles)) powered by an on-board battery, power supply control for all ECUs can be freely performed using software. Therefore, power supply control according to the vehicle state is required.
[0004] For example, with the diversification of vehicle control, such as driving 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 on 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).
[0005] Japanese Patent Application Laid-Open No. 2020-27627
[0006] In OTA repro, a campaign is identified by first performing a configuration synchronization phase, so OTA repro cannot begin unless power is supplied to all ECUs that support OTA repro, including ECUs that perform data communication with the OTA center, ECUs that relay software distributed from the OTA master to the target ECU, and ECUs equipped with display functions. On the other hand, if power is continued to be supplied to ECUs that are not part of the campaign among all ECUs that support OTA repro, unnecessary power consumption will result. Furthermore, as the phases after the configuration synchronization phase progress, ECUs that no longer require power supply will emerge, and continuing to supply power to ECUs that no longer require power will also result in unnecessary power consumption.
[0007] The present disclosure aims to appropriately reduce unnecessary power consumption when performing a software update phase.
[0008] A power supply control device according to one aspect of the present disclosure controls the supply of power to a control target device that is a target for power supply control when performing a series of processes related to a software update. When performing a software update phase, the power supply control device controls the supply of power to the control target device so that power is supplied to the control target device that requires power based on the vehicle state, and power is not supplied to the control target device that does not require power based on the vehicle state.
[0009] A power supply control system according to one aspect of the present disclosure includes a power supply control device that controls power supply to a control target device that is a target for power supply control when performing a series of processes related to a software update, and the control target device. When performing a software update phase, the power supply control device controls the power supply to the control target device so that power is supplied to the control target device that requires power based on a vehicle state, and power is not supplied to the control target device that does not require power based on the vehicle state.
[0010] A power supply control method of one embodiment of the present disclosure is a power supply control device that controls the power supply to a controlled device that is the object of power supply control when performing a series of processes related to a software update.When performing a phase related to a software update, a power control procedure is performed to control the power supply to the controlled device so that power is supplied to the controlled device that requires power supply based on the vehicle state, and power is not supplied to the controlled device that does not require power supply based on the vehicle state.
[0011] A power control program of one embodiment of the present disclosure causes a power control device that controls the power supply to a controlled device that is the object of power supply control when performing a series of processes related to a software update to execute a power control procedure that controls the power supply to the controlled device so that, when performing a phase related to a software update, power is supplied to the controlled device that requires power supply based on the vehicle state, and power is not supplied to the controlled device that does not require power supply based on the vehicle state.
[0012] According to one aspect of the present disclosure, when a software update phase is performed, power is supplied to control target devices that require power supply based on the vehicle state, and power is not supplied to control target devices that do not require power supply based on the vehicle state, thereby making it possible to appropriately suppress unnecessary power consumption when performing a software update phase.
[0013] 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 a ReproMaster, Fig. 3 is a diagram showing a vehicle status table, Fig. 4 is a diagram showing a trigger type table, Fig. 5 is a flowchart, Fig. 6 is a flowchart, Fig. 7 is a flowchart, Fig. 8 is a flowchart, Fig. 9 is a flowchart, Fig. 10 is a diagram showing a transition possibility determination table, Fig. 11 is a flowchart, Fig. 12 is a diagram showing a continuation possibility determination table, and Fig. 13 is a flowchart. FIG. 14 is a diagram showing an implementation feasibility determination table, FIG. 15 is a flowchart, FIG. 16 is a flowchart, FIG. 17 is a flowchart, FIG. 18 is a flowchart, FIG. 19 is a flowchart, FIG. 20 is a diagram showing the processing flow, FIG. 21 is a flowchart, FIG. 22 is a flowchart, FIG. 23 is a diagram showing the processing flow, FIG. 24 is a diagram showing the hierarchy, FIG. 25 is a diagram showing a diagnostic mask management table, and FIG. 26 is a flowchart.
[0014] An embodiment will be described below with reference to the drawings. As shown in FIG. 1 , a data communication system 1 (corresponding to a power supply control system) is configured to enable data communication between an over-the-air (OTA) center 2 and a vehicle-side system 3 installed in a vehicle. An unspecified number of vehicle-side systems 3 can communicate data with the OTA center 2. The vehicle is, for example, an electric vehicle such as a BEV powered by an on-board battery (corresponding to a power supply source). Unlike non-electric vehicles such as gasoline-powered vehicles, for example, electric vehicles can freely control the power supply of all ECUs installed in the vehicle using software.
[0015] The vehicle-side system 3 includes an in-vehicle communication device (hereinafter referred to as DCM (Data Communication Module)) 4 (corresponding to the device to be controlled), a central gateway (hereinafter referred to as CGW (Central Gateway)) 5, a first repeater 6 (corresponding to the device to be controlled or updated), a second repeater 7 (corresponding to the device to be controlled or updated), and a third repeater 8 (corresponding to the device to be controlled or updated). The CGW 5, the first repeater 6, the second repeater 7, and the third repeater 8 are referred to as a domain controller. The first repeater 6, the second repeater 7, and the third repeater 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 (corresponding to a device to be controlled), a remote diagnosis 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 power supply control 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 controlled or 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 devices to be controlled or devices to be updated) 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 devices to be controlled and devices to be updated) 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 a device to be controlled or updated) without going through a repeater. Of the multiple ECUs connected to the OBC 12, an 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 going through a repeater, the number of ECUs connected to the OBC 12 without going through a repeater is not limited to one.
[0030] The power control application 22 arranged in the second repeater 7 cooperates with the power control function unit 19 of the OTA master 14 as described above, 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. The OTA master 14 performs a power control method and executes a power control program.
[0031] When a start 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, the DCM 4, the in-vehicle HMI 10, the repeaters 6 to 8, and the ECUs 25 to 31 transition to a started state, and the supply of power from the in-vehicle battery is stopped. When a stop 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 started 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 supply of power from the in-vehicle battery is stopped.
[0032] The external tool 32, while attached to a connector arranged 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.
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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.
[0038] The OTA master 14 holds a vehicle status table as shown in FIG. 3 and manages the vehicle status using the vehicle status table. The OTA master 14 manages the vehicle status by classifying the power-on states in which the vehicle can be driven into "driving," "function degraded," and "emergency stop." The OTA master 14 manages the driving states by classifying the manual driving and the automatic driving. The OTA master 14 manages the power-off states in which the vehicle cannot be driven into "parked without a passenger," "parked with a passenger," "high-voltage start," and "high-voltage / temperature control start." The OTA master 14 manages the parked states in which the vehicle cannot be driven into "not charging" and "charging." The OTA master 14 manages the parked states in which the vehicle cannot be driven into "riding" and "discharging."
[0039] The ECUs in the activated state and the ECUs in the stopped state differ between the vehicle states illustrated in FIG. 3 . For example, an ECU that requires power supply during autonomous driving but not during manual driving may be activated during autonomous driving and stopped during manual driving. When the OTA master 14 controls the power supply during OTA (described later), if it performs control such as activating an ECU that needs to be activated during the OTA progress at that time (also referred to as the OTA scene), the ECUs in the activated state and the ECUs in the stopped state may differ from those when OTA is not in progress (also referred to as the original scene or reference scene). The ECUs in the activated state and the ECUs in the stopped state during OTA can also be understood as being the original scene to which the results of the OTA master 14's control of the power supply during OTA are additionally reflected.
[0040] The OTA master 14 holds a trigger type table as shown in Fig. 4 and manages OTA start triggers using the trigger type table. The OTA master 14 manages the following trigger types for the OTA start trigger: power-on, user operation, center push, and reservation time lapse.
[0041] Next, the operation of the above-described configuration will be described with reference to Figures 5 to 26. The following cases will be described as cases in which the OTA master 14 controls the power supply to the DCM 4, the in-vehicle HMI 10, the repeaters 6 to 8, and the ECUs 25 to 31 in cooperation with the power control application 22: (1) When the configuration synchronization phase is performed; (2) When a phase after the configuration synchronization phase is performed; (3) When function degradation is performed based on the remaining charge of the in-vehicle battery; (4) When it is determined whether or not to transition to OTA based on the vehicle state; (5) When it is determined whether or not to continue OTA based on the vehicle state; (6) When it is determined whether or not to implement OTA based on the trigger type, the importance of the campaign, and the remaining charge of the in-vehicle battery; (7) When a change in the vehicle state is prohibited when the activation phase is performed; (8) When it is determined whether or not to stop the power supply to the ECU based on the vehicle state.
[0042] (1) When the configuration synchronization phase is performed (see FIG. 5 ), the OTA master 14 starts the power supply control process and, upon detecting an OTA start trigger (S1), identifies the ECUs corresponding to the OTA by referring to the OTA-compatible ECU list. The OTA master 14 determines whether any of the identified ECUs corresponding to the OTA are in a stopped state (S2). If the OTA master 14 determines that any of the ECUs corresponding to the OTA are in a stopped state (S2: YES), it outputs a start-up request to the stopped ECU, transitions the stopped ECU to an activated state, and starts supplying power to the activated ECU (S3). That is, if the DCM 4, the in-vehicle HMI 10, the repeaters 6-8, and the ECUs 25-31 need to be activated during the configuration synchronization phase, the OTA master 14 transitions the DCM 4, the in-vehicle HMI 10, the repeaters 6-8, and the ECUs 25-31 to an activated state.
[0043] The OTA master 14 performs a configuration synchronization phase (S4). Upon completion of the configuration synchronization phase, the OTA master 14 refers to the campaign-eligible ECU list to identify ECUs that are not eligible for the campaign. The OTA master 14 determines whether any of the identified ECUs that are not eligible for the campaign are active (S5). If the OTA master 14 identifies an active ECU among the ECUs that are not eligible for the campaign (S5: YES), the OTA master 14 outputs a stop request to the active ECU, transitions the active ECU to a stopped state, and stops the power supply to the ECU that has been transitioned to a stopped state (S6). That is, when the OTA master 14 identifies an ECU that is not eligible for the campaign among the relays 6-8 and the ECUs 25-31, the OTA master 14 transitions the identified ECU to a stopped state.
[0044] The OTA master 14 then performs a download phase (S7), and upon completion of the download phase, performs an installation phase (S8), and upon completion of the installation phase, performs an activation phase (S9). Upon completion of the activation phase, the OTA master 14 performs an update completion notification phase (S10), and upon completion of the update completion notification phase, the OTA master 14 ends the power supply control process.
[0045] (2) When performing the configuration synchronization phase and subsequent phases (see FIGS. 6 and 7 ), the OTA master 14 starts the power supply control process and performs steps S1 to S4 described above. After completing the configuration synchronization phase, the OTA master 14 determines whether any ECUs not required for downloading are active (S15). If the OTA master 14 determines that any ECUs not required for downloading are active (S15: YES), the OTA master 14 outputs a stop request to the active ECU, transitions the active ECU to a stopped state, and stops the power supply to the ECU that has been transitioned to a stopped state (S16). That is, if the relays 6 to 8 and the ECUs 25 to 31 do not need to be active during the download phase, the OTA master 14 transitions the relays 6 to 8 and the ECUs 25 to 31 to a stopped state.
[0046] The OTA master 14 performs a download phase (S17), and upon completion of the download phase, determines whether any ECUs targeted for installation are in a stopped state (S18). If the OTA master 14 determines that any ECUs targeted for installation are in a stopped state (S18: YES), it outputs a start-up request to the stopped ECU, transitions the stopped ECU to an activated state, and starts supplying power to the ECU that has transitioned to the activated state (S19).
[0047] The OTA master 14 determines whether any ECUs that are not targets for installation are in an activated state (S20). If the OTA master 14 determines that any ECUs that are not targets for installation are in an activated state (S20: YES), the OTA master 14 outputs a stop request to the activated ECU, transitions the activated ECU to a stopped state, and stops the power supply to the ECU that has been transitioned to a stopped state (S21).
[0048] The OTA master 14 performs an installation phase (S22), and upon completion of the installation phase, determines whether any ECUs to be activated are in a stopped state (S23). If the OTA master 14 determines that any ECUs to be activated are in a stopped state (S23: YES), the OTA master 14 outputs a start-up request to the stopped ECU, transitions the stopped ECU to an activated state, and starts supplying power to the ECU that has transitioned to the activated state (S24).
[0049] The OTA master 14 determines whether any ECUs that are not the target of activation are in an activated state (S25). If the OTA master 14 determines that any ECUs that are not the target of activation are in an activated state (S25: YES), the OTA master 14 outputs a stop request to the activated ECU, transitions the activated ECU to a stopped state, and stops the power supply to the ECU that has been transitioned to a stopped state (S26).
[0050] The OTA master 14 performs an activation phase (S27), and upon completion of the activation phase, determines whether any ECUs that are the targets of the update completion notification are in a stopped state (S28). If the OTA master 14 determines that any ECUs that are the targets of the update completion notification are in a stopped state (S28: YES), the OTA master 14 outputs a start-up request to the stopped ECU, transitions the stopped ECU to an activated state, and starts supplying power to the ECU that has transitioned to the activated state (S29).
[0051] The OTA master 14 determines whether any ECUs that are not the target of the update completion notification are in an activated state (S30). If the OTA master 14 determines that any ECUs that are not the target of the update completion notification are in an activated state (S30: YES), the OTA master 14 outputs a stop request to the activated ECU, transitions the activated ECU to a stopped state, and stops the power supply to the ECU that has been transitioned to the stopped state (S31). The OTA master 14 performs an update completion notification phase (S32), and upon completion of the update completion notification phase, ends the power supply control process.
[0052] (3) When the function degeneration is performed based on the remaining charge of the vehicle battery (see FIG. 8), the OTA master 14 starts the power supply control process and, upon detecting an OTA start trigger (S1), determines whether the remaining charge of the vehicle battery is equal to or greater than a preset threshold (S41). If the OTA master 14 determines that the remaining charge of the vehicle battery is equal to or greater than the preset threshold (S41: YES), the OTA master 14 performs the above steps S2 to S10 and ends the power supply control process.
[0053] On the other hand, if the OTA master 14 determines that the remaining charge of the in-vehicle battery is less than a threshold (S41: NO), it degrades functions, suspends OTA (S42), and terminates the power supply control process. For example, if the OTA master 14 determines that the remaining charge of the in-vehicle battery is less than a first threshold, it stops entertainment functions such as music playback. For example, if the OTA master 14 determines that the remaining charge of the in-vehicle battery is less than a second threshold equal to or less than the first threshold, it stops the out-of-vehicle communication function. For example, if the OTA master 14 determines that the remaining charge of the in-vehicle battery is less than a third threshold equal to or less than the second threshold, it stops comfort functions such as air conditioning.
[0054] (4) When the OTA master 14 determines whether or not the transition to OTA is possible based on the vehicle state (see FIGS. 9 and 10), the OTA master 14 starts the power supply control process and, upon detecting an OTA start trigger (S1), refers to the transition possibility determination table shown in FIG. 10 and determines whether or not the transition to OTA is possible based on the vehicle state (S51). For example, if the power is on and the vehicle is traveling, the OTA master 14 determines that the transition to OTA is possible regardless of whether the vehicle is being driven manually or automatically. When the OTA master 14 determines that the transition to OTA is possible (S51: YES), it performs steps S2 to S10 described above and ends the power supply control process.
[0055] On the other hand, if the power is on and the function is degraded, the OTA master 14 determines that transition to OTA is not possible. If the OTA master 14 determines that transition to OTA is not possible (S51: NO), the OTA master 14 ends the power supply control process without transitioning to OTA.
[0056] (5) When determining whether or not OTA can be continued based on the vehicle state (see FIGS. 11 and 12), the OTA master 14 starts the power supply control process and, upon detecting an OTA start trigger (S1), refers to the continuation determination table shown in FIG. 12 and determines whether or not OTA can be continued based on the vehicle state (S61). In more detail, the OTA master 14 constantly monitors whether or not there is a change in the vehicle state. When the OTA start trigger is detected and a change in the vehicle state occurs between the start of the OTA and the end of the power supply control process upon completion of the OTA, the OTA master 14 refers to the continuation determination table shown in FIG. 12 and determines whether or not OTA can be continued after the change in the vehicle state. The continuation determination table contains information indicating vehicle states in which OTA can be performed and vehicle states in which OTA cannot be performed.
[0057] For example, if the vehicle state after the change is power-on and the vehicle is traveling, the OTA master 14 determines that the OTA can be continued whether the vehicle is being driven manually or automatically. When the OTA master 14 determines that the OTA can be continued (S61: YES), the OTA master 14 continues the OTA while continuing to supply power to ECUs that are required to be activated in the OTA progress at that time, even after the change in the vehicle state. For example, when the vehicle state changes from automatic driving to manual driving, if an ECU that is required to be activated during automatic driving but is not required to be activated during manual driving and is in a stopped state is included in the ECUs that are required to be activated in the OTA progress at that time, the OTA master 14 controls the supply of power to the ECU in cooperation with the power control app 22 even after the change to manual driving.
[0058] If the OTA master 14 determines that the OTA can be continued (S61: YES), it performs, for example, steps S2 to S10 described above, and then terminates the power supply control process. In step S2, the OTA master 14 determines whether any ECUs that need to be active during the OTA progress at that time will be in a stopped state after a change in the vehicle state exist. If it determines that any ECUs will be in a stopped state after the change in the vehicle state exist (S2: YES), it controls the power supply to keep those ECUs in an active state even after the change in the vehicle state (S3). In the series of processes from steps S61 to S3, the OTA master 14 may control the power supply to keep ECUs that will be in a stopped state in the changed vehicle state in an active state even after the change in the vehicle state, or it may control the power supply to transition ECUs that were temporarily in a stopped state due to the change in the vehicle state from a stopped state to an active state.
[0059] On the other hand, if the vehicle state after the change is power-on and the function is being degraded, the OTA master 14 determines that the OTA cannot be continued. When the OTA master 14 determines that the OTA cannot be continued (S61: NO), the OTA master 14 interrupts the OTA (S62) and ends the power supply control process.
[0060] Note that the OTA master 14 is not limited to determining whether or not the OTA can be continued when the vehicle state changes (S61) and controlling the power supply to the ECU when it is determined that the OTA can be continued (S2 to S3) before the configuration synchronization shown in FIG. 11 . The OTA master 14 may determine whether or not the OTA can be continued (S61) and control the power supply to the ECU that the OTA requires to be in an activated state at that timing every time it detects a change in the vehicle state during the OTA, from the start of the OTA to the completion of the OTA, excluding the activation phase. When the activation phase is performed, a change in the vehicle state is prohibited as described below in "(7) Case in which a change in the vehicle state is prohibited when the activation phase is performed."
[0061] 17 described later and before determining "YES" in step S107, the OTA master 14 determines whether to continue the installation by referring to the continuation determination table. If the OTA master 14 determines that the installation is possible, it continues the installation while continuing to supply power to the first target ECU, even if the first target ECU would be stopped in the changed vehicle state if the OTA were not taken into account.
[0062] After determining that the OTA cannot be continued in step S61 and suspending the OTA in step S62, the OTA master 14 may constantly monitor whether or not there is a change in the vehicle state in order to resume the OTA. Specifically, when the OTA master 14 detects a change in the vehicle state, the OTA master 14 may determine whether or not the OTA can be resumed by referring to the transition feasibility determination table shown in FIG. 10 and determining whether or not the vehicle state after the change allows transition to OTA. When the OTA master 14 determines that the OTA can be resumed, it resumes the OTA.
[0063] Note that the OTA master 14 may perform power control to prevent an ECU that is required to be in an activated state due to the progress of the OTA at that time from being stopped, not only when it determines that the OTA can be continued in a determination of whether to continue the OTA triggered by the detection of a change in the vehicle state, but also at all times during the OTA in cooperation with the power control app 22. For example, assuming an ECU that is periodically activated during autonomous driving and stopped after specific processing, if the ECU is an ECU that is required to be in an activated state due to the progress of the OTA, the OTA master 14 may control the power supply to continue supplying power to the ECU to maintain the activated state in cooperation with the power control app 22.
[0064] (6) When the OTA implementation possibility is determined based on the trigger type, the importance of the campaign, and the remaining charge of the in-vehicle battery (see FIGS. 13 and 14), the OTA master 14 starts the power supply control process, performs steps S1 to S4 described above, and, upon completing the configuration synchronization phase, determines whether the OTA implementation possibility is possible based on the vehicle state by referring to the implementation possibility determination table shown in FIG. 14 (S71). For example, if the trigger type is user intent, the importance of the campaign is high, and the remaining charge is equal to or greater than the first threshold, the OTA master 14 determines that the OTA implementation possibility is possible. If the OTA master 14 determines that the OTA implementation possibility is possible (S71: YES), it performs steps S5 to S10 described above and ends the power supply control process.
[0065] On the other hand, if the trigger type is user intent, the campaign importance is high, and the remaining charge is less than the first threshold, the OTA master 14 determines that OTA is not possible. If the OTA master 14 determines that OTA is not possible (S71: NO), the OTA master 14 ends the power supply control process without updating the software.
[0066] (7) When the activation phase is performed, a change in the vehicle state is prohibited (see FIG. 15). The OTA master 14 starts the power supply control process, performs steps S1 to S8 described above, and when the installation phase is completed, prohibits a change in the vehicle state (S81) and performs the activation phase (S9). When the activation phase is completed, the OTA master 14 releases the prohibition on a change in the vehicle state (S82) and performs the update completion notification phase (S10). When the update completion notification phase is completed, the OTA master 14 ends the power supply control process.
[0067] (8) Determining whether to stop the power supply to the ECU based on the vehicle status, and if it is determined that the power supply to the ECU can be stopped, stopping the power supply to the ECU (see FIG. 16 ): The OTA master 14 starts the power supply control process, performs steps S1 to S5 described above, and determines whether an activated ECU can be switched to a stopped state based on the vehicle status (S91). For example, if the ECU that controls driving during OTA while parked is an ECU that is not eligible for the campaign and is activated, the OTA master 14 determines that the activated ECU can be switched to a stopped state. If the OTA master 14 determines that the activated ECU can be switched to a stopped state (S91: YES), the OTA master 14 performs steps S6 to S10 described above, including step S6, which switches the ECU to a stopped state, and then terminates the power supply control process. The OTA master 14 performs the series of processes of steps S91 and S6 for each ECU that is not eligible for the campaign. In the above-described steps S15 and S16, steps S20 and S21, steps S25 and S26, and steps S30 and S31, the OTA master 14 may determine whether an ECU in an activated state can be switched to a stopped state based on the vehicle state for each ECU, as in steps S91 and S6, and switch that ECU to a stopped state if it has been determined that the ECU can be switched to a stopped state. An example of a method for determining whether an ECU can be switched to a stopped state based on the vehicle state is a method based on whether the vehicle is in a reference scene in which the ECU is in a stopped state, which will be described later.
[0068] On the other hand, if the ECU that controls driving during OTA while driving is not covered by the campaign and is in an activated state, the OTA master 14 determines that the activated ECU cannot be switched to a stopped state. If the OTA master 14 determines that the activated ECU cannot be switched to a stopped state (S91: NO), the OTA master 14 performs the above steps S7 to S10 without switching the activated ECU to a stopped state, and ends the power supply control process.
[0069] Next, the installation phase will be described with reference to Figures 17 to 19. The following cases will be described as cases in which the OTA master 14 controls the power supply to the ECUs 25 to 31 in cooperation with the power control application 22 during the installation phase: (1) When software is installed in series on the target ECUs (2) When software is installed in parallel on the target ECUs
[0070] (1) When software is installed serially on target ECUs (see FIGS. 17 to 20), the OTA master 14, upon completing the download phase, determines whether an activated target ECU exists (S101). If the OTA master 14 determines that an activated target ECU exists (S101: YES), the OTA master 14 determines whether the activated target ECU can be switched to a stopped state based on the vehicle state (S102). If the OTA master 14 determines that the activated target ECU can be switched to a stopped state (S102: YES), the OTA master 14 outputs a stop request to the activated target ECU, switches the activated target ECU to a stopped state, and stops the power supply to the target ECU switched to the stopped state (S103).
[0071] The OTA master 14 determines whether the target ECU that is first in the installation order is activated (S104). If the OTA master 14 determines that the target ECU that is first in the installation order is not activated (S104: NO), the OTA master 14 outputs an activation request to the stopped target ECU, transitions the stopped target ECU to an activated state, and starts supplying power to the activated target ECU (S105).
[0072] The OTA master 14 starts installing the software on the target ECU that is first in the installation order (S106) and waits for the completion of the software installation on the target ECU that is first in the installation order (S107). When the OTA master 14 determines that the software installation is complete (S107: YES), it determines whether the target ECU is in an activated state (S108). When the OTA master 14 determines that the target ECU is in an activated state (S108: YES), it determines whether the activated target ECU can be switched to a stopped state based on the vehicle state (S109). When the OTA master 14 determines that the activated target ECU can be switched to a stopped state (S109: YES), it outputs a stop request to the activated target ECU, switches the activated target ECU to a stopped state, and stops the power supply to the stopped target ECU (S110). In determining whether a target ECU in an active state can be transitioned to a stopped state based on the vehicle state, the OTA master 14 determines that the target ECU can be transitioned to a stopped state on the condition that the vehicle state is such that the target ECU is in a stopped state (i.e., a reference scene) when not in OTA. When the OTA master 14 is in the reference scene in which the target ECU is in an active state, the OTA master 14 determines that the target ECU cannot be transitioned to a stopped state.
[0073] The OTA master 14 determines whether the installation of the software to all target ECUs has been completed (S111). If the OTA master 14 determines that the installation of the software to all target ECUs has not been completed (S111: NO), the OTA master 14 performs the above-described process in order until the installation of the software to all target ECUs has been completed.
[0074] The OTA master 14 sets a variable "i" indicating the order to "2" (S112), and determines whether the target ECU that is the i-th in the installation order is activated (S113). "i" is a variable indicating the installation order. If the OTA master 14 determines that the i-th target ECU in the installation order is not activated (S113: NO), the OTA master 14 outputs an activation request to the stopped target ECU, transitions the stopped target ECU to an activated state, and starts supplying power to the activated target ECU (S114).
[0075] The OTA master 14 starts installing the software on the i-th target ECU in the installation order (S115) and waits for the software installation on the i-th target ECU to be completed (S116). When the OTA master 14 determines that the software installation is complete (S116: YES), it determines whether the target ECU is in an activated state (S117). When the OTA master 14 determines that the target ECU is in an activated state (S117: YES), it determines whether the activated target ECU can be switched to a stopped state based on the vehicle state (S118). When the OTA master 14 determines that the activated target ECU can be switched to a stopped state (S118: YES), it outputs a stop request to the activated target ECU, switches the activated target ECU to a stopped state, and stops the power supply to the stopped target ECU (S119).
[0076] The OTA master 14 determines whether the installation of the software to all target ECUs has been completed (S120). If the OTA master 14 determines that the installation of the software to all target ECUs has not been completed (S120: NO), the OTA master 14 adds "1" to the variable "i" (S121), returns to step S113, and performs step S113 and subsequent steps.
[0077] When the OTA master 14 determines that the software has been installed in all target ECUs (S120: YES), the installation phase is completed.
[0078] 20 , when the targets for installation are target ECU (A), target ECU (B), and target ECU (C), the OTA master 14 first starts the target ECU (A) and starts installing the software in the target ECU (A). After completing the installation of the software in the target ECU (A), the OTA master 14 stops the target ECU (A) and then starts the target ECU (B) and starts installing the software in the target ECU (B). After completing the installation of the software in the target ECU (B), the OTA master 14 stops the target ECU (B) and then starts the target ECU (C) and starts installing the software in the target ECU (C).
[0079] (2) When software installation is performed on target ECUs in parallel (see FIGS. 21 to 23 ), upon completion of the download phase, the OTA master 14 determines whether an activated target ECU exists (S131). If the OTA master 14 determines that a target ECU exists (YES in S131), it determines whether the activated target ECU can be switched to a stopped state based on the vehicle state (S132). If the OTA master 14 determines that the activated target ECU can be switched to a stopped state (YES in S132), it outputs a stop request to the activated target ECU, switches the activated ECU to a stopped state, and stops the power supply to the stopped target ECU (S133).
[0080] The OTA master 14 determines whether all target ECUs into which software is to be installed in parallel are activated (S134). If the OTA master 14 determines that none of the target ECUs are activated (S134: YES), it outputs an activation request to the target ECUs in the deactivated state, transitions the deactivated target ECUs to the activated state, and starts supplying power to the activated target ECUs (S135).
[0081] The OTA master 14 simultaneously starts installing software on the target ECUs where the software is to be installed in parallel (S136) and waits for the completion of the software installation on one of the target ECUs (S137). When the OTA master 14 determines that the installation of one of the software has been completed (S137: YES), it determines whether the target ECU is in an activated state (S138). When the OTA master 14 determines that the target ECU is in an activated state (S138: YES), it determines whether the activated target ECU can be switched to a stopped state based on the vehicle state (S139). When the OTA master 14 determines that the activated target ECU can be switched to a stopped state (S139: YES), it outputs a stop request to the activated target ECU, switches the activated ECU to a stopped state, and stops the power supply to the stopped target ECU (S140).
[0082] The OTA master 14 determines whether the installation of the software to all target ECUs to which the software is to be installed has been completed (S141). If the OTA master 14 determines that the installation of the software to all target ECUs to which the software is to be installed has not been completed (S141: NO), the OTA master 14 returns to step S137 and performs step S137 and subsequent steps. If the OTA master 14 determines that the installation of the software to all target ECUs to which the software is to be installed has been completed (S141: YES), the OTA master 14 completes the installation phase.
[0083] As shown in FIG. 23 , when the targets for installation are target ECU (A), target ECU (B), and target ECU (C), the OTA master 14 first simultaneously starts the target ECU (A), target ECU (B), and target ECU (C), and simultaneously starts installing software into the target ECU (A), target ECU (B), and target ECU (C). When the OTA master 14 completes installing the software into the target ECU (A), it stops the target ECU (A). When the OTA master 14 completes installing the software into the target ECU (B), it stops the target ECU (B). When the OTA master 14 completes installing the software into the target ECU (C), it stops the target ECU (C).
[0084] The procedure for performing installation according to layers will be described. As shown in FIG. 24 , when focusing on the number of relays from the OTA master 14, the first relay 6, the second relay 7, the third relay 8, and the ECU 31 are arranged on the first layer. The ECUs 25 to 30 are arranged on the second layer. In this embodiment, the number of relays is two, and the hierarchy is divided into the first and second layers. However, the number of relays may be three or more. When the number of relays is three, the hierarchy is divided into the first, second, and third layers.
[0085] When installing software into the ECUs 25-30 located on the second hierarchical level, the OTA master 14 keeps the relays located on the first hierarchical level above the second hierarchical level in an activated state. That is, when installing software into the ECUs 25, 26 located on the second hierarchical level, for example, the OTA master 14 keeps the first relay 6 located on the first hierarchical level above the second hierarchical level in an activated state. On the other hand, when not installing software into the ECUs 25-30 located on the second hierarchical level, the OTA master 14 keeps the relays located on the first hierarchical level above the second hierarchical level in a deactivated state. That is, when not installing software into the ECUs 25, 26 located on the second hierarchical level, for example, the OTA master 14 keeps the first relay 6 located on the first hierarchical level above the second hierarchical level in a deactivated state.
[0086] The OTA master 14 may install software in parallel to multiple repeaters and ECUs arranged in the same hierarchical layer. For example, the OTA master 14 may install software in the first repeater 6 and the second repeater 7 in parallel. For example, the OTA master 14 may install software in the ECUs 25 and 26 connected to the first repeater 6 and the ECUs 27 and 28 connected to the second repeater 7 in parallel.
[0087] The OTA master 14 may install software in parallel to relays and ECUs that are located in different layers and that are not connected to each other. For example, the OTA master 14 may install software in the first relay 6 and in the ECUs 27 and 28 connected to the second relay 7 in parallel.
[0088] The OTA master 14 may first install software on ECUs located in lower hierarchical levels, and then install software on relays and ECUs located in higher hierarchical levels. For example, the OTA master 14 may first install software on ECUs 25-30, and then install software on the first relay 6, the second relay 7, the third relay 8, and the ECU 31. In this case, the OTA master 14 may, for example, simultaneously start the first relay 6, the second relay 7, the third relay 8, and the ECUs 25-31, and sequentially shut down the ECUs and relays that have completed software installation. For example, the OTA master 14 may simultaneously start the first relay 6 and the ECUs 25 and 26, start installing software on the ECUs 25 and 26, and shut down the ECUs 25 and 26 once the installation is complete. The OTA master 14 then starts installing software on the first relay 6, and shuts down the first relay 6 once the installation is complete.
[0089] The OTA master 14 may first install software on relays and ECUs located in higher hierarchical levels, and then install software on ECUs located in lower hierarchical levels. For example, the OTA master 14 may first install software on the first relay 6, the second relay 7, the third relay 8, and the ECU 31, and then install software on the ECUs 25-30. In this case, the OTA master 14 may simultaneously start the first relay 6, the second relay 7, the third relay 8, and the ECU 31, sequentially start the ECUs 25-30 connected to the relays that have completed software installation, and simultaneously stop the ECUs and relays that have completed software installation. For example, the OTA master 14 may start the first relay 6, start installing software on the first relay 6, and upon completing the installation, start the ECUs 25 and 26 connected to the first relay 6. Thereafter, the OTA master 14 starts installing software into the ECUs 25 and 26, and when the installation is completed, shuts down the first relay device 6 and the ECUs 25 and 26 simultaneously.
[0090] The OTA master 14 adjusts the software installation period for the relays 6-8 and ECU 31 arranged on the first hierarchical layer so that the software installation period for the ECUs 25-30 arranged on the second hierarchical layer does not overlap. By adjusting the software installation period for the relays 6-8 arranged on the first hierarchical layer and the software installation period for the ECUs 25-30 arranged on the second hierarchical layer in parallel, the OTA master 14 can prevent an increase in the processing load, which would otherwise be caused by the relays 6-8 arranged on the first hierarchical layer installing the software and relaying the software to be installed on the ECUs 25-30 arranged on the second hierarchical layer, and can prevent errors from occurring due to the increased processing load.
[0091] The OTA master 14 may acquire the software installation order from the specification data and install the software on the repeaters and ECUs according to the installation order acquired from the specification data. Furthermore, when the OTA master 14 holds the connection relationships between the repeaters 6 to 8 and the ECU 31 arranged on the first hierarchical level and the ECUs 25 to 30 arranged on the second hierarchical level, the OTA master 14 may acquire the targets for software installation from the specification data, match the acquired targets with the held connection relationships to determine the installation order, and install the software on the repeaters and ECUs according to the determined installation order.
[0092] The procedure for activating according to the layer will be described below. The procedure for activating according to the layer is the same as the procedure for installing according to the layer described above.
[0093] When activating software installed in the ECUs 25-30 located on the second hierarchical level, the OTA master 14 keeps the relays located on the first hierarchical level above the second hierarchical level in an activated state. That is, when activating software installed in the ECUs 25, 26 located on the second hierarchical level, the OTA master 14 keeps the first relay 6 located on the first hierarchical level above the second hierarchical level in an activated state. When not activating software installed in the ECUs 25-30 located on the second hierarchical level, the OTA master 14 keeps the relays located on the first hierarchical level above the second hierarchical level in a deactivated state. That is, when not activating software installed in the ECUs 25, 26 located on the second hierarchical level, the OTA master 14 keeps the first relay 6 located on the first hierarchical level above the second hierarchical level in a deactivated state.
[0094] The OTA master 14 may activate software installed in multiple relays and ECUs arranged in the same hierarchical layer in parallel. For example, the OTA master 14 may activate software installed in the first relay 6 in parallel with software installed in the second relay 7. For example, the OTA master 14 may activate software installed in the ECUs 25 and 26 connected to the first relay 6 in parallel with software installed in the ECUs 27 and 28 connected to the second relay 7 in parallel.
[0095] The OTA master 14 may also activate software installed in relays and ECUs that are located in different layers that are not connected to each other in parallel. For example, the OTA master 14 may also activate software installed in the first relay 6 in parallel with software installed in the ECUs 27 and 28 connected to the second relay 7.
[0096] The OTA master 14 may first activate software installed in ECUs located in lower hierarchical levels, and then activate software installed in relays and ECUs located in higher hierarchical levels. For example, the OTA master 14 may first activate software installed in ECUs 25-30, and then activate software installed in the first relay 6, the second relay 7, the third relay 8, and the ECU 31. In this case, the OTA master 14 may simultaneously start the first relay 6, the second relay 7, the third relay 8, and the ECUs 25-31, and sequentially shut down the ECUs and relays that have completed software activation. For example, the OTA master 14 may simultaneously start the first relay 6 and the ECUs 25 and 26, start activating the software installed in the ECUs 25 and 26, and shut down the ECUs 25 and 26 once the activation is complete. Thereafter, the OTA master 14 starts activating the software installed in the first repeater 6, and when the activation is completed, stops the first repeater 6.
[0097] The OTA master 14 may first activate software installed on relays and ECUs located in higher hierarchical levels, and then activate software installed on ECUs located in lower hierarchical levels. For example, the OTA master 14 may first activate software installed on the first relay 6, the second relay 7, the third relay 8, and the ECU 31, and then activate software installed on the ECUs 25-30. In this case, the OTA master 14 may simultaneously start the first relay 6, the second relay 7, the third relay 8, and the ECU 31, sequentially start the ECUs 25-30 connected to the relays that have completed software installation, and simultaneously stop the ECUs and relays that have completed software installation. For example, the OTA master 14 may start the first relay 6, start activating the software installed on the first relay 6, and then, upon completion of the activation, start the ECUs 25 and 26 connected to the first relay 6. Thereafter, the OTA master 14 starts activating the software installed in the ECUs 25 and 26, and when the activation is completed, it simultaneously shuts down the first relay device 6 and the ECUs 25 and 26.
[0098] The OTA master 14 adjusts the period for activating software installed in the relays 6-8 and ECU 31 arranged in the first tier so that the period for activating software installed in the ECUs 25-30 arranged in the second tier does not overlap. By adjusting the period, the OTA master 14 can avoid a temporary interruption in relaying caused by the relays 6-8 arranged in the first tier activating software and the relaying of software installed in the ECUs 25-30 arranged in the second tier being performed in parallel.
[0099] The OTA master 14 may obtain the activation order of the software from the specification data and activate the software installed in the relays and ECUs according to the activation order obtained from the specification data.Alternatively, when the OTA master 14 holds the connection relationships between the relays 6 to 8 and the ECU 31 arranged in the first hierarchical layer and the ECUs 25 to 30 arranged in the second hierarchical layer, the OTA master 14 may obtain the target of software activation from the specification data, match the obtained target of activation with the held connection relationships to specify the activation order, and activate the software installed in the relays and ECUs according to the specified activation order.
[0100] The diagnostic mask will be described with reference to Figures 25 and 26. As shown in Figure 25, the OTA master 14 holds a diagnostic mask management table and manages the ECUs that are the targets of the diagnostic mask using the diagnostic mask management table. Data communication occurs between ECUs at a predetermined cycle, such as every second. If data communication between the ECUs is interrupted, for example, when one ECU installs or activates software, the other ECU normally detects the interruption of data communication as a diagnostic. However, a diagnostic mask is when the other ECU does not detect the interruption of data communication as a diagnostic.
[0101] The following describes a case where the diagnostic mask determination process is performed in the installation phase. When the OTA master 14 starts the diagnostic mask determination process, it determines whether the target ECU is in an activated state (S201). If the OTA master 14 determines that the target ECU is in a stopped state (S201: NO), it outputs a start-up request to the stopped target ECU, transitions the stopped target ECU to an activated state, and starts supplying power to the activated target ECU (S202).
[0102] The OTA master 14 determines whether there is an ECU that can be switched to a stopped state (S203). If the OTA master 14 determines that there is an ECU that can be switched to a stopped state (S203: YES), the OTA master 14 determines whether there is an ECU that requires a diagnostic mask when a stop request is output to the ECU that can be switched to a stopped state (S204). If the OTA master 14 determines that there is an ECU that requires a diagnostic mask (S204: YES), the OTA master 14 refers to the diagnostic mask management table and identifies the ECU that requires a diagnostic mask (S205).
[0103] When the OTA master 14 identifies an ECU that requires a diagnostic mask, it outputs a diagnostic mask setting request to the ECU that requires the diagnostic mask and sets the diagnostic mask in the ECU that requires the diagnostic mask (S206).The OTA master 14 outputs a stop request to the ECU that can be switched to a stopped state, switches the active target ECU to a stopped state, and stops the power supply to the target ECU that has been switched to the stopped state (S207).
[0104] The OTA master 14 waits for the completion of the installation of the software in the target ECU (S208), and when it determines that the installation of the software in the target ECU is complete (S208: YES), it outputs a diagnostic mask release request to the ECU in which the diagnostic mask is set, releases the diagnostic mask of the ECU in which the diagnostic mask is set (S209), and ends the diagnostic mask determination process. The above describes the case where the diagnostic mask determination process is performed in the installation phase, but the OTA master 14 also performs the diagnostic mask determination process in the activation phase in a similar manner.
[0105] As described above, according to the embodiment, the following advantageous effects can be obtained. When the OTA master 14 performs each phase of OTA configuration synchronization, download, installation, activation, and update completion notification, it supplies power to the relays 6-8 and ECUs 25-31 that require power supply based on the vehicle state, and does not supply power to the relays 6-8 and ECUs 25-31 that do not require power supply based on the vehicle state. This makes it possible to appropriately suppress unnecessary power consumption when performing each phase of OTA.
[0106] In the phase of installing software to multiple target ECUs, power is supplied to target ECUs that require power supply, and power is not supplied to target ECUs that do not require power supply. This makes it possible to appropriately suppress unnecessary power consumption when installing software to multiple target ECUs.
[0107] In the phase of activating software installed in multiple target ECUs, power is supplied to target ECUs that require power supply, and power is not supplied to target ECUs that do not require power supply. This makes it possible to appropriately suppress unnecessary power consumption when activating software installed in multiple target ECUs.
[0108] The present disclosure includes the following disclosures in addition to what is set forth in the claims: [1] A power supply control device (14) that controls power supply to a control target device that is a target for power supply control when performing a series of processes related to a software update, wherein, when performing a phase related to a software update, the power supply control device controls the power supply to the control target device so that power is supplied to the control target device that requires power supply based on a vehicle state, and power is not supplied to the control target device that does not require power supply based on the vehicle state.
[0109] [2] The power supply control device according to [1], which controls the power supply to the control target device when a configuration synchronization phase related to software update is performed.
[0110] [3] The power supply control device according to [1] or [2], which controls the power supply to the control target device when performing a phase subsequent to a configuration synchronization phase related to a software update.
[0111] [4] The power supply control device according to any one of [1] to [3], which controls the power supply to the control target device when performing functional degradation based on the remaining charge of the power supply source.
[0112] [5] The power supply control device according to any one of [1] to [4], which determines whether or not to proceed to software update based on a vehicle state and controls the power supply to the control target device.
[0113] [6] The power supply control device according to any one of [1] to [5], which determines whether or not software update can be continued based on a vehicle state and controls power supply to the control target device.
[0114] [7] A power supply control device according to any one of [1] to [6], which determines whether or not to perform a software update based on the trigger type, the importance of the campaign, and the remaining charge of the power supply source, and controls the power supply to the controlled device.
[0115] [8] The power supply control device according to any one of [1] to [7], which prohibits changes in the vehicle state when a specific phase related to a software update is performed.
[0116] [9] A power supply control device according to any one of [1] to [8], which determines whether or not the power supply to the control target device can be stopped based on the vehicle state, and stops the power supply to the control target device when it is determined that the power supply to the control target device can be stopped.
[0117]
[10] The power supply control device according to any one of [1] to [9], which is mounted on an electric vehicle powered by electric power from a power supply source.
[0118]
[11] The power supply control device according to any one of [1] to
[10] , which controls power supply to an update target device that is a target for updating software hierarchized as the control target device.
[0119]
[12] A power supply control device according to any one of [1] to
[11] , which controls the power supply of a greater number of on-board devices that are compatible with software updates and are installed in a vehicle than those in the configuration synchronization phase, such as the download phase, installation phase, and activation phase, which are phases subsequent to the configuration synchronization phase related to the software update, as the controlled devices that do not require power supply.
[0120]
[13] The power supply control device according to
[12] , wherein the vehicle is a battery-powered electric vehicle, and the vehicle states include a first vehicle state, a second vehicle state, a third vehicle state, a fourth vehicle state, and a fifth vehicle state, and the first vehicle state, the second vehicle state, the third vehicle state, the fourth vehicle state, and the fifth vehicle state are different in which on-board devices are powered and activated, and in which on-board devices are powered and deactivated, and the first vehicle state and the second vehicle state are power-on states in which at least the vehicle is capable of running, and the third vehicle state, the fourth vehicle state, and the fifth vehicle state are power-off states in which at least the vehicle is not capable of running, and in a phase after the configuration synchronization phase, if the control-target device that does not require power supply is in an activated state, the power supply control device controls not to supply power to the control-target device on condition that the control-target device has been identified as being capable of transitioning to a deactivated state based on the vehicle state.
[0121]
[14] When performing a software update phase and controlling the power supply to multiple controlled devices that do not require power supply, the power supply control device described in
[13] determines, for each controlled device that does not require power supply, whether the controlled device can be transitioned to a stopped state based on the vehicle state, and controls so as not to supply power to the controlled device that is identified as being able to be transitioned to a stopped state among the multiple controlled device that do not require power supply.
[0122] 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.
[0123] Although the OTA center 2 is used as an example to explain the case of wireless reprogramming, the present invention can also be applied to the case of wired reprogramming using an external tool 32 connected to the CGW 5 by wire.
[0124] 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 power supply control device (14) that controls the power supply to a controlled device that is the object of power supply control when performing a series of processes related to software update, wherein when performing a phase related to software update, the power supply to the controlled device is controlled so that power is supplied to the controlled device that requires power supply based on the vehicle state, and power is not supplied to the controlled device that does not require power supply based on the vehicle state.
2. The power supply control device according to claim 1, which controls the power supply to the controlled device when a configuration synchronization phase related to software update is performed.
3. The power supply control device according to claim 1, which controls the power supply to the controlled device when a phase subsequent to the configuration synchronization phase relating to software update is performed.
4. A power supply control device according to claim 1, wherein the power supply control device controls the power supply to the controlled device when the function degradation is performed based on the remaining charge of the power supply source.
5. The power supply control device according to claim 1, which determines whether or not to proceed to software update based on the vehicle state and controls the power supply to the controlled device.
6. The power supply control device according to claim 1, which determines whether or not software update can be continued based on the vehicle state and controls the power supply to the controlled device.
7. A power supply control device according to claim 1, which determines whether or not to perform a software update based on the trigger type, the importance of the campaign, and the remaining charge of the power supply source, and controls the power supply to the control target device.
8. The power supply control device according to claim 1, which prohibits changes in the vehicle state when a specific phase related to software update is performed.
9. A power supply control device as described in claim 1, which determines whether or not the power supply to the controlled device can be stopped based on the vehicle state, and stops the power supply to the controlled device when it is determined that the power supply to the controlled device can be stopped.
10. The power supply control device according to claim 1, which is mounted on an electric vehicle powered by electric power from a power supply source.
11. A power supply control device according to claim 1, which controls the power supply to an update target device that is a target for updating software hierarchized as the control target device.
12. A power supply control device as described in claim 1, which controls the power supply of a greater number of on-board devices that are compatible with software updates and are installed in a vehicle than those in the configuration synchronization phase, such as the download phase, installation phase, and activation phase, which are phases subsequent to the configuration synchronization phase related to the software update, as controlled devices that do not require power supply.
13. The power supply control device according to claim 12, wherein the vehicle is a battery-powered electric vehicle, the vehicle states include a first vehicle state, a second vehicle state, a third vehicle state, a fourth vehicle state, and a fifth vehicle state, the first vehicle state, the second vehicle state, the third vehicle state, the fourth vehicle state, and the fifth vehicle state each have a different on-board device that is powered and in an activated state and a different on-board device that is powered and in a stopped state, the first vehicle state and the second vehicle state are at least power-on states in which the vehicle is capable of running, and the third vehicle state, the fourth vehicle state, and the fifth vehicle state are at least power-off states in which the vehicle is not capable of running, and in a phase after the configuration synchronization phase, if the controlled device that does not require power supply is in an activated state, the power supply control device controls not to supply power to the controlled device on condition that the controlled device has been identified as being capable of transitioning to a stopped state based on the vehicle state.
14. A power supply control device as described in claim 13, in which when performing a software update phase and controlling the power supply to multiple controlled devices that do not require power supply, it identifies, for each controlled device that does not require power supply, whether the controlled device can be transitioned to a stopped state based on the vehicle state, and controls so as not to supply power to the controlled device that is identified as being able to be transitioned to a stopped state among the multiple controlled devices that do not require power supply.
15. A power supply control system (1) comprising a power supply control device (14) that controls the power supply to a control target device that is the target of power supply control when a series of processes related to software update is performed, and control target devices (4, 6 to 8, 10, 25 to 31) that are the target of power supply control, wherein the power supply control device controls the power supply to the control target devices so that when a phase related to software update is performed, power is supplied to the control target devices that require power supply based on the vehicle state, and power is not supplied to the control target devices that do not require power supply based on the vehicle state.
16. A power control method in a power control device (14) that controls the power supply to a controlled device that is the object of power supply control when performing a series of processes related to software update, wherein, when performing a phase related to software update, power is supplied to the controlled device that requires power supply based on the vehicle state, and power is not supplied to the controlled device that does not require power supply based on the vehicle state.
17. A power control program that causes a power control device (14) that controls the power supply to a controlled device that is the target of power supply control when performing a series of processes related to software updates to execute a power control procedure that controls the power supply to the controlled device so that, when performing a phase related to software updates, power is supplied to the controlled device that requires power based on the vehicle state, and power is not supplied to the controlled device that does not require power based on the vehicle state.
Citation Information
Patent Citations
On-vehicle relay device, on-vehicle communication system, communication program, and communication method
JP2021027448A
Vehicular master device, power supply management method for object for which rewriting is not to be carried out, and power supply management program for object for which rewriting is not to be carried out
WO2020032123A1
Vehicular electronic control system, progress display screen display control method, and progress display screen display control program
WO2020032194A1
Vehicle information communication system
WO2020032196A1
Vehicle control device, and vehicle control method
WO2022196418A1