Master device, vehicle system, activated execution control method, and activated execution control program

Abstract

An OTA host (14) performs software update on an electronic control device mounted on an electric vehicle that uses electric power from a vehicle-mounted battery as a power source, as an update target device of the software. The execution timing of controlling activation of the software in the update target device is controlled for each update target device.

Description

[0001] Cross-references to related applications

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

[0003] This disclosure relates to a main control device, a vehicle system, an activation execution control method, and an activation execution control procedure. Background Technology

[0004] Vehicles are equipped with numerous electronic control units (hereinafter referred to as ECUs (Electronic Control Units)). With the diversification of vehicle control functions such as driver assistance and autonomous driving, an OTA (Over-The-Air) reprogramming technology has been developed to wirelessly update the software of the ECUs. In OTA reprogramming, the OTA master controller on the vehicle side distributes the software downloaded from the OTA center to the target ECU, which is the device to be updated. By instructing the target ECU to update the software, the target ECU performs the software update (see, for example, Patent Document 1).

[0005] Existing technical documents

[0006] Patent documents

[0007] Patent document 1: Japanese Patent Application Publication No. 2020-27637.

[0008] In OTA reprogramming, after the software is installed and written to the target ECU, activation is performed to make the software installed on the target ECU effective. However, the target ECU cannot perform any actions during the activation process. For example, in non-electric vehicles such as gasoline cars that use gasoline as a power source, since they are composed of a fixed power system with only +B (constant power), auxiliary power (hereinafter referred to as ACC), and ignition (hereinafter referred to as IG), activation occurs, for example, after a certain period of time following the IG being disconnected. Therefore, in non-electric vehicles, if it is desired for an ECU that needs to operate even during periods such as when the IG is disconnected to continue its operation, activation cannot be performed.

[0009] On the other hand, in electric vehicles, such as battery electric vehicles (hereinafter referred to as BEVs) that are powered by electricity from an onboard battery, the power control of all ECUs can be freely performed via software. Therefore, unlike the non-electric vehicles mentioned above, the timing for activation is not limited to timing based on IG disconnection, but a mechanism for activation is required. Summary of the Invention

[0010] The purpose of this disclosure is to appropriately activate the software in the update target device in a configuration where the electronic control device of an electric vehicle powered by electricity from an on-board battery is the object of software update, i.e., the update target device.

[0011] One aspect of the master control device disclosed herein uses an electronic control unit mounted on an electric vehicle powered by electricity from an onboard battery as an update target device, which is a software update target device. The timing of the activation of the software in each of the update target devices is controlled.

[0012] One aspect of the vehicle system disclosed herein includes: a main control unit that identifies an electronic control device mounted on an electric vehicle powered by electricity from an onboard battery as an update target device, the update target device being a software update target; and the update target device. The main control unit controls the timing of activation of software in each of the update target devices.

[0013] The present disclosure discloses an activation execution control method in which, in a master control device, the activation execution timing of the software in each update target device is controlled. The master control device uses an electronic control device mounted on an electric vehicle powered by electricity from an on-board battery as the update target device for software update.

[0014] The present disclosure discloses an activation execution control program that causes a master control device to perform execution control steps, in which the execution timing of software activation in each update target device is controlled. The master control device uses an electronic control device mounted on an electric vehicle powered by electricity from an on-board battery as an update target device for software update.

[0015] According to one aspect of this disclosure, when updating software by using an electronic control device mounted on an electric vehicle powered by electricity from an onboard battery as the software update target (i.e., the update target device), the timing for activating the software in each update target device is controlled. This allows for appropriate activation of the software in the update target device.

[0016] According to one aspect of this disclosure, in a vehicle system comprising a main control device that updates software on an electronic control unit of an electric vehicle powered by electricity from an onboard battery (i.e., an update target device), and update target devices, when the main control device updates software on the electronic control unit of the electric vehicle powered by electricity from an onboard battery (i.e., an update target device), the timing for activating the software in each update target device is controlled. This allows for appropriate activation of the software in the update target device. Attached Figure Description

[0017] The above-mentioned and other objects, features, and advantages of this disclosure become more apparent from the accompanying drawings and the following detailed description. The drawings are as follows:

[0018] Figure 1 This is a diagram showing the overall structure of one implementation method.

[0019] Figure 2 It is a function block diagram of the reprogrammed main controller.

[0020] Figure 3 This is a diagram showing the list of active execution timers.

[0021] Figure 4 It is a diagram showing the hierarchy.

[0022] Figure 5 It's a flowchart.

[0023] Figure 6 It's a flowchart.

[0024] Figure 7 It's a flowchart.

[0025] Figure 8 It's a flowchart.

[0026] Figure 9 This is a diagram showing the diagnostic shielding management table.

[0027] Figure 10 It's a flowchart. Detailed Implementation

[0028] Hereinafter, one embodiment will be described with reference to the accompanying drawings. Figure 1As shown, the data communication system 1 is configured to enable OTA (Over-The-Air) center 2 to communicate with the vehicle system 3 installed in the vehicle. A large number of unspecified vehicle systems 3 can communicate with the OTA center 2. The vehicle is, for example, an electric vehicle such as a BEV (Battery Electric Vehicle) powered by electricity from an onboard battery. Unlike non-electric vehicles such as gasoline vehicles powered by gasoline, electric vehicles allow for flexible power control of all ECUs installed in the vehicle via software.

[0029] Vehicle system 3 includes an onboard communication unit (hereinafter referred to as DCM (Data Communication Module)) 4 (equivalent to an update object device), a central gateway (hereinafter referred to as CGW (Central Gateway)) 5, a first relay 6 (equivalent to an update object device), a second relay 7 (equivalent to an update object device), and a third relay 8 (equivalent to an update object device). CGW5, first relay 6, second relay 7, and third relay 8 are referred to as domain controllers. First relay 6, second relay 7, and third relay 8 are connected to CGW5, for example, via Ethernet (registered trademark).

[0030] OTA Center 2 generates and stores update packages containing the software and specification data of the update recipients. Additionally, OTA Center 2 stores update packages obtained from external sources, such as OEMs (Original Equipment Manufacturers). OTA Center 2 has a structure management function unit and a distribution management function unit. The structure management function unit manages the hardware and software structure of the vehicle side that can be the recipients of update packages, while the distribution management function unit manages the distribution of update packages to the vehicle side. The software includes programs, data, libraries, etc., used to activate the ECU.

[0031] The specification data includes information that identifies the ECU corresponding to the OTA, the target ECU that is the object of the software update, the installation object in the installation phase (described later), the installation order, the activation object in the activation phase (described later), and the activation order. The ECU corresponding to the OTA is the ECU capable of implementing the OTA. The OTA center 2 can include the specification data in the update package and distribute it to the vehicle, or it can distribute the specification data separately from the update package to the vehicle.

[0032] DCM4 communicates with OTA Center 2 via a communication network. The communication network may include, for example, a mobile communication network based on 4G or 5G lines, the Internet, or WiFi (Wireless Fidelity) (registered trademark). Alternatively, DCM4 and CGW5 may be integrated, with DCM4's functionality incorporated into CGW5's structure. Alternatively, either DCM4's functionality or CGW5's functionality may be incorporated into a display device or similar structure. When DCM4 receives an update packet from OTA Center 2, it forwards the received update packet to CGW5. The software distributed from OTA Center 2 to DCM4 may be, for example, OTA reprogramming software. Data communication between OTA Center 2 and DCM4, i.e., inter-center communication, may use, for example, the SOVD format according to the SOVD communication specification, or the RestAPI format according to the Rest (Representational State Transfer) API communication specification. Software updates based on update packets distributed from OTA Center 2 are called wireless reprogramming. On the other hand, software updates based on update packages distributed from external tools (described later) are called wired reprogramming.

[0033] The CGW5 features a reprogrammable main control unit 9, an in-vehicle HMI (Human Machine Interface) 10 (equivalent to a controlled device), remote diagnostics 11, and an in-vehicle client (hereinafter referred to as OBC) 12. Figure 2 As shown, the reprogramming master controller 9 has a downloader 13 and an OTA master controller 14 (equivalent to a master control device).

[0034] When the downloader receives a download execution request from the OTA host 14, it instructs the DCM4 to execute the download process. The downloader 13 downloads the update package from the OTA center 2 via the DCM4 by receiving the update package distributed from the OTA center 2 and forwarding the received update package from the DCM4. The downloaded update package is temporarily stored in the reprogramming host 9 or an external memory, as described later.

[0035] The OTA master controller 14 includes an update control function unit 15, a status 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, an active target ECU list storage unit 21, and an activation execution timing list storage unit 22. These functions are implemented through software processing by the CPU executing computer programs stored in a non-transient physical storage medium based on a microcomputer, or through hardware processing based on dedicated electronic circuits.

[0036] The update control function unit 15 has the function of controlling software updates. The status management function unit 16 has the function of managing the status of the software update target that accompanies the software update. The display control function unit 17 has the function of controlling the display in the vehicle HMI 10 that accompanies the software update. The write control function unit 18 has the function of controlling the installation of software to the software update target.

[0037] The OTA-compatible ECU list storage unit 20 stores information from the specification data that identifies the ECUs compatible with the OTA as an OTA-compatible ECU list. The target ECU list storage unit 21 stores information from the specification data that identifies the target ECU as a target ECU list. ECUs that are recorded in the target ECU list among the OTA-compatible ECUs are target ECUs, while ECUs that are not recorded in the target ECU list among the OTA-compatible ECUs are ECUs other than the target ECUs.

[0038] like Figure 3 As shown, the activation execution timing list storage unit 22 stores the information contained in the specification data that can determine the activation execution timing for each ECU as an activation execution timing list. For all ECUs, the condition for activation execution timing is that the vehicle's position is not in a avoidance zone. In other words, the timing indicating that the vehicle's position is not in a avoidance zone is the permissible timing for activation execution. Avoidance zones are, for example, areas with poor security.

[0039] For ECUs such as those for the display system, driving system, autonomous driving system, and body system, the absence of occupants is used as a condition for activation timing. In other words, the timing of activation when there are no occupants is an permissible timing. For example, for an air conditioning ECU, the absence of occupants and an interior temperature above a first threshold and below a second threshold are used as conditions for activation timing. Again, the timing of activation when there are no occupants and an interior temperature above a first threshold and below a second threshold is a permissible timing. For example, for a lighting ECU, the absence of occupants and an interior illuminance above a threshold are used as conditions for activation timing. Again, the timing of activation when there are no occupants and an interior illuminance above a threshold is a permissible timing. The absence of occupants is determined, for example, based on whether a certain amount of time has elapsed since the user exited the vehicle, or the user's usual usage patterns.

[0040] For ECUs such as those used in charging systems, the non-charging period is used as a condition for activation timing. In other words, the timing during the non-charging period is the permissible timing for activation. The non-charging period is determined, for example, based on whether it is during driving or whether a certain amount of time has elapsed since the vehicle was removed. For ECUs such as DCM4 used in communication systems, the parking period is used as a condition for activation timing. In other words, the timing during the parking period is the permissible timing for activation. The conditions for activation timing are not limited to the examples. Furthermore, DCM4 issues an emergency alert due to an accident while driving and an emergency alert due to theft while parked. Additionally, a list of activation timings can be preset in the vehicle as setting information.

[0041] The power control function unit 19 determines the ECU corresponding to the OTA by referring to the OTA-compatible ECU list. The power control function unit 19 determines the target ECU by referring to the active target ECU list. The power control function unit 19 cooperates with the power control application 23 configured in the second relay 7 and controls the power supply to the ECU as the software update progresses. Furthermore, while this embodiment illustrates the case where the power control function unit 19 cooperates with the power control application 23 to control the power supply to the ECU, a structure could also be configured with a power control ECU that controls the power supply to the ECU. The objects to which the power supply is controlled by the power control function unit 19 include the DCM4, the vehicle HMI10, the first relay 6, the second relay 7, and the third relay 8.

[0042] The OBC12 includes a mediation function unit 24 and a diagnostic communication function unit 25. The mediation function unit 24 takes the reprogramming of diagnostic communication between the master controller 9 and the relay or ECU as the target and mediates which diagnostic communication should be performed first. The diagnostic communication function unit 25 performs the reprogramming of diagnostic communication between the master controller 9 and the relay or ECU according to the mediation result performed by the mediation function unit 24.

[0043] The OBC12 is connected to multiple ECUs 26 and 27 (equivalent to update target devices) via a first relay 6. The multiple ECUs 26 and 27 are connected to the first relay 6, for example, via a CAN bus. CAN communication between the first relay 6 and the multiple ECUs 26 and 27 is data communication using a 29-bit CAN ID. The ECU among the multiple ECUs 26 and 27 connected to the first relay 6 that is the target device for software updates can become the target ECU. Although the case of two ECUs connected to the first relay 6 is illustrated, the number of ECUs connected to the first relay 6 is not limited to two.

[0044] Similarly, OBC12 is connected to multiple ECUs 28 and 29 (equivalent to the update target devices) via a second relay 7. The multiple ECUs 28 and 29 are connected to the second relay 7, for example, via a CAN bus. CAN communication between the second relay 7 and the multiple ECUs 28 and 29 is data communication using a 29-bit CAN ID. The ECU among the multiple ECUs 28 and 29 connected to the second relay 7 that is the target device for software updates can become the target ECU. Although the case of two ECUs connected to the second relay 7 is illustrated, the number of ECUs connected to the second relay 7 is not limited to two.

[0045] Similarly, OBC12 is connected to multiple ECUs 30, 31 (equivalent to the update target devices) via a third relay 8. The multiple ECUs 30, 31 are connected to the third relay 8, for example, via a CAN bus. CAN communication between the third relay 8 and the multiple ECUs 30, 31 is data communication using a 29-bit CAN ID. The ECU among the multiple ECUs 30, 31 connected to the third relay 8 that is the target ECU for software updates can become the target ECU. Although the case of two ECUs connected to the third relay 8 is illustrated, the number of ECUs connected to the third relay 8 is not limited to two. CAN communication between the first relay 6 and multiple ECUs 26, 27, CAN communication between the second relay 7 and multiple ECUs 28, 29, and CAN communication between the third relay 8 and multiple ECUs 30, 31 can also be data communication using an 11-bit CAN ID.

[0046] Furthermore, the OBC12 connects to the ECU32 (equivalent to the update target device) without a relay. The ECU that becomes the software update target among the multiple ECUs connected to the OBC12 can be the target ECU. Although the case of one ECU connected to the OBC12 without a relay is illustrated, the number of ECUs connected to the OBC12 without a relay is not limited to one.

[0047] The power control application 23, configured in the second relay 7, cooperates with the power control function unit 19 of the OTA master controller 14 as described above, controlling the power supply to the DCM4, vehicle HMI10, relays 6-8, and ECUs 26-32 as software updates progress. That is, the OTA master controller 14 enables the power control function unit 19 to cooperate with the power control application 23, and controls the power supply to the relays 6-8 and ECUs 26-32, which are capable of diagnostic communication via the diagnostic communication function unit 25.

[0048] If DCM4, vehicle HMI10, repeaters 6-8, and ECUs 26-32 receive a start request from OTA master controller 14 while they are in a stopped state, they transition to the start state and begin power supply from the vehicle battery. If DCM4, vehicle HMI10, repeaters 6-8, and ECUs 26-32 receive a stop request from OTA master controller 14 while they are in a start state, they transition to the stop state and cease power supply from the vehicle battery.

[0049] When external tool 33 is installed in the connector configured in the vehicle, it distributes the update package to the OTA master unit 14. External memory 34 functions as an external storage device for the OTA master unit 14. It not only serves as a temporary storage destination for update packages downloaded from OTA center 2 as described above, but also serves as a temporary bypass destination for the software before the update when the software of relay units 6-8 and ECUs 26-32 is updated.

[0050] The software update process involves a series of stages, including configuration synchronization, download, installation, activation, and update completion notification. The configuration synchronization stage, within the OTA center 2, synchronizes the software and hardware configuration information of the ECU (Electronic Control Unit) in the target vehicle with the software and hardware configuration information of that ECU.

[0051] The download phase is the stage in which the OTA master controller 14 downloads the update package from the OTA center 2. Before the download phase, the OTA master controller 14 makes judgments such as whether the downloaded software is legitimate and whether the data volume of the downloaded software and the remaining charge of the vehicle battery are sufficient to complete the download. When it is determined that, for example, the downloaded software is legitimate and the remaining charge of the vehicle battery is sufficient for the data volume of the downloaded software, the OTA master controller 14 proceeds with the download phase.

[0052] The installation phase is the stage in which the software extracted from the update package is installed to the target ECU in the OTA master controller 14. Installation refers to writing the software into the storage area of ​​the target ECU. Before proceeding with the installation phase, the OTA master controller 14 determines, for example, whether the software to be installed is legitimate, and whether the amount of data in the software and the remaining charge of the vehicle battery are sufficient to complete the installation. When it is determined that, for example, the software to be installed is legitimate, and the remaining charge of the vehicle battery is sufficient relative to the amount of data in the software to be installed, the OTA master controller 14 proceeds with the installation phase.

[0053] The activation phase is the phase in which the software to be installed in the target ECU is activated. Before the activation phase, the OTA master controller 14 determines, for example, whether the software to be activated is legitimate, and whether the amount of data in the software to be activated and the remaining charge of the vehicle battery are sufficient to complete the activation process. When it is determined that, for example, the software to be activated is legitimate, and the remaining charge of the vehicle battery is sufficient relative to the amount of data in the software to be activated, the OTA master controller 14 proceeds with the activation phase.

[0054] The update completion notification stage is the stage in which the OTA master controller 14 sends an update completion notification to the OTA center 2 when it receives an update completion notification indicating the software update status from the target ECU.

[0055] The target ECUs of the OTA master controller 14 are configured hierarchically. When multiple ECUs are located at different levels, they are activated in a hierarchical order. For example... Figure 4 As shown, considering the number of relay layers from the OTA master controller 14, the first relay 6, the second relay 7, the third relay 8, and ECU 32 are configured in the first layer. ECUs 26 to 31 are configured in the second layer. In this embodiment, the case where there are two relay layers and the hierarchy is divided into the first and second layers is illustrated, but the number of relay layers can also be three or more. In the case of three relay layers, the hierarchy is divided into the first, second, and third layers.

[0056] When multiple ECUs are hierarchically activated, the OTA master controller 14 prioritizes the activation of lower-level ECUs. That is, the OTA master controller 14 activates lower-level ECUs before activating higher-level ECUs. In other words, the activation of higher-level ECUs is performed only after the activation of lower-level ECUs is complete. This prevents data communication from being disrupted during the activation of lower-level ECUs due to the activation of higher-level ECUs that relay data communication between the lower-level ECUs and the OTA master controller 14.

[0057] In the specification data distributed from OTA center 2, the activation order is defined according to the order of ECUs at the lower priority level. OTA master controller 14 determines the activation order by parsing the specification data. Alternatively, while maintaining the connection relationship between relays 6-8 and ECU 32 configured in the first level and ECUs 26-31 configured in the second level, OTA master controller 14 obtains the objects to be activated from the specification data and checks the obtained objects to be activated against the setting information indicating the maintained connection relationship to determine the activation order.

[0058] Next, regarding the function of the above-mentioned components, please refer to... Figures 5 to 10 Please provide an explanation.

[0059] The OTA master controller 14 begins software update processing. When OTA is detected to be triggered (S1), it refers to the OTA-corresponding ECU list to determine the ECU corresponding to the OTA. The OTA master controller 14 determines whether there is a stopped ECU among the determined OTA-corresponding ECUs (S2). When it is determined that there is a stopped ECU among the OTA-corresponding ECUs (S2: Yes), the OTA master controller 14 outputs a start request to the stopped ECU, causing the stopped ECU to transition to the start state, and begins to supply power to the ECU that has transitioned to the start state (S3). That is, during the configuration synchronization phase, if DCM4, vehicle HMI10, repeaters 6-8, and ECUs 26-32 need to be in the start state, the OTA master controller 14 causes DCM4, vehicle HMI10, repeaters 6-8, and ECUs 26-32 to transition to the start state.

[0060] The OTA master controller 14 performs configuration synchronization processing (S4). Upon completion of the configuration synchronization processing, it refers to the list of active target ECUs to determine ECUs other than the active targets. The OTA master controller 14 determines whether there is an ECU in a running state among the determined ECUs other than the active targets (S5). When the OTA master controller 14 determines that there is an ECU in a running state among the ECUs other than the active targets (S5: Yes), it outputs a stop request to the ECU in the running state, causing the ECU in the running state to transition to a stop state, stopping the power supply to the ECU that has transitioned to the stop state (S6), and performs download processing. That is, when the OTA master controller 14 determines that there is an ECU other than the active targets among the relays 6-8 and ECUs 26-32, it causes the determined ECU other than the active targets to transition to a stop state and performs download processing.

[0061] Upon completion of the download process, the OTA master controller 14 performs the installation process (S8). During installation, the OTA master controller 14 determines whether there are multiple target ECUs that need to be activated simultaneously; in other words, it determines whether the activation of multiple target ECUs needs to be performed simultaneously (S9). Multiple ECUs that need to be activated simultaneously are typically in a cooperative relationship. Identification information such as the ECU IDs of the ECUs that need to be activated simultaneously, and the ECUs that require simultaneous activation, is stored, for example, in specification data. The OTA master controller 14, for example, refers to the specification data to determine whether the activation of multiple target ECUs needs to be performed simultaneously, and identifies the ECUs that require simultaneous activation.

[0062] When it is determined that simultaneous activation of multiple ECUs is not required (S9: No), in order to activate all ECUs that are considered as activation targets, the OTA master controller 14 performs a process on each ECU that is considered as an activation target. Figure 6 The details are shown in the flowchart for the first activation process (S10). When the first activation process begins, the OTA master controller 14 determines the ECU to be activated (S13). If there are multiple ECUs to be activated, in S13, the OTA master controller 14 determines one of the multiple ECUs to be activated as the processing object for the first activation process. When the ECU to be activated is determined, the OTA master controller 14 confirms the vehicle status (S14), confirms the status of the ECU to be activated (S15), and determines whether the ECU to be activated is in a state where it can execute software activation (S16).

[0063] When it is confirmed in step S14 that, for example, the remaining charge level of the vehicle battery (as a vehicle state) is above a specified remaining amount, and when it is confirmed in step S15, through reading a DTC (Diagnostic Trouble Code), that the state of the ECU to be activated is not a specified fault state, the OTA master controller 14 determines in step S16 that the ECU to be activated is in a state capable of executing software activation. Conversely, if the OTA master controller 14 confirms that the remaining charge level of the vehicle battery is less than a specified remaining amount, or that the state of the ECU to be activated is a specified fault state through reading a DTC, etc., at least one of these conditions is met, the OTA master controller 14 determines that the ECU to be activated is not in a state capable of executing software activation.

[0064] When it is determined that the system is not in an activated state capable of executing the software (S16: No), the OTA master controller 14 ends the first activation process and returns to the software update process. Upon returning to the software update process, the OTA master controller 14 performs an update completion notification and ends the software update process.

[0065] When it is determined that the system is in an activated state capable of executing software (S16: Yes), the OTA master controller 14 refers to the activation execution timing list and determines whether the activation execution condition is met for the ECU that is determined to be the first activation processing target (S17). The activation execution condition is that the current time is within the permissible activation execution timing for the ECU that is determined to be the first activation processing target. For example, if the permissible activation execution timing for the ECU that is determined to be the first activation processing target is that there are no occupants and the interior temperature is above a first threshold and below a second threshold, then the current situation of no occupants and the interior temperature being above the first threshold and below the second threshold is the activation execution condition.

[0066] When the activation execution conditions are determined to be met (S17: Yes), the OTA master controller 14 sends the activation execution instruction to the ECU to be activated and executes the activation of the software in the ECU to be activated (S18, equivalent to executing the control step). That is, for example, if the ECU to be activated is a display system ECU or a driving system ECU, if the vehicle is not in a avoidance zone and there are no occupants, the OTA master controller 14 determines that the activation execution conditions are met and executes the software activation. For example, if the ECU to be activated is an air conditioning system ECU, if the vehicle is not in a avoidance zone, there are no occupants, and the interior temperature is above a first threshold and below a second threshold, the OTA master controller 14 determines that the activation execution conditions are met and executes the software activation.

[0067] The OTA master unit 14 broadcasts an activation execution notification to all ECUs (S19). This activation execution notification contains ECU identification information that identifies the ECU to be activated and indicates the intention to perform activation during the process, and terminates the first activation process for the ECU identified as the activation target. When the first activation process has been terminated and all ECUs identified as activation targets have been processed, the OTA master unit 14 returns to software update processing.

[0068] On the other hand, when it is determined that the activation of multiple ECUs needs to be performed simultaneously (S9: Yes), in order to activate all ECUs that are activation targets, the OTA master controller 14 performs a process on each ECU that is an activation target. Figure 7 and Figure 8 The details of the second activation process are illustrated in the flowchart (S11). When the second activation process begins, the OTA master controller 14 determines the ECU to be activated (S20). If there are multiple ECUs to be activated, in S20, the OTA master controller 14 determines one of the multiple ECUs to be activated as the processing object for the second activation process. When the ECU to be activated is determined, the OTA master controller 14 confirms the vehicle status (S21), confirms the status of the ECU to be activated (S22), and determines whether the ECU to be activated is in a state capable of executing software activation (S23). When it is determined that the ECU to be activated is not in a state capable of executing software activation (S23: No), the OTA master controller 14 ends the second activation process and returns to the software update process.

[0069] When it is determined that the ECU of the target ECU is in an activated state capable of executing software (S23: Yes), the OTA master controller 14 refers to the activation execution timing list and determines whether the activation execution condition of the target ECU is met (S24). The activation execution condition is that the current time is within the allowable timing for activation execution for the ECU of the target ECU, which is determined to be the processing object of the second activation process. When it is determined that the activation execution condition is met for the target ECU (S24: Yes), the OTA master controller 14 determines whether the activation execution condition is met for the synchronization target ECU (S25). The activation execution condition is that the current time is within the allowable timing for activation execution for the synchronization target ECU.

[0070] When the activation execution conditions for the ECU of the synchronization target are determined to be met (S25: Yes), the OTA master controller 14 determines whether the ECU of the synchronization target and the ECU of the activation target are at the same level (S26). When it is determined that the ECU of the synchronization target and the ECU of the activation target are at the same level (S26: Yes), the OTA master controller 14 sends the activation execution instruction to the ECU of the activation target and executes the activation of the software in the ECU of the activation target (S27, equivalent to executing the control step).

[0071] The OTA master controller 14 broadcasts an activation execution notification to all ECUs (S28). This activation execution notification contains ECU identification information that can identify the ECU to be activated and indicates the intention to perform activation during the process. It then terminates the second activation process for the ECU identified as the activation target. When the second activation process has been terminated and all ECUs to be activated have been processed, the OTA master controller 14 returns to the software update process.

[0072] When it is determined that the ECU of the synchronization target and the ECU of the activation target are not at the same level, but at a lower level (S26: No), the OTA master controller 14 determines whether the activation in the ECU of the synchronization target at that lower level is complete (S29). When it is determined that the activation in the ECU of the synchronization target at that lower level is complete (S29: Yes), the OTA master controller 14 performs the above steps S27 and S28, ends the second activation process, and returns to the software update process.

[0073] The OTA master controller 14 prioritizes the activation of lower-level ECUs as described above. For example, it first activates the software installed on ECUs 26-31, and then activates the software installed on the first relay 6, the second relay 7, the third relay 8, and ECU 32. In this case, the OTA master controller 14, for example, simultaneously starts the first relay 6, the second relay 7, the third relay 8, and ECUs 26-32, and sequentially stops the ECUs and relays that have completed software activation. For example, the OTA master controller 14 simultaneously starts the first relay 6 and ECUs 26 and 27, begins the activation of the software installed on ECUs 26 and 27, and stops ECUs 26 and 27 upon completion of the activation. Afterward, the OTA master controller 14 begins the activation of the software installed on the first relay 6, and stops the first relay 6 upon completion of the activation.

[0074] Furthermore, the OTA master unit 14 can also activate software installed to multiple relay units and ECUs configured at the same level in parallel. For example, the OTA master unit 14 can activate software installed to ECUs 26 and 27 connected to the first relay unit 6 and software installed to ECUs 28 and 29 connected to the second relay unit 7 in parallel. The OTA master unit 14 can also activate software installed to the first relay unit 6 and software installed to the second relay unit 7 in parallel.

[0075] The OTA master unit 14 can also activate software installed on different levels of relays and ECUs that are not connected in parallel. For example, the OTA master unit 14 can also activate software installed on the first relay 6 and software installed on ECUs 28 and 29 connected to the second relay 7 in parallel.

[0076] The OTA master controller 14 is adjusted so that the activation period for software installed in the relays 6-8 and ECU 32 configured in the first level does not overlap with the activation period for software installed in the ECUs 26-31 configured in the second level. By making the above adjustment, the OTA master controller 14 can avoid temporary relay interruptions caused by the parallel activation of software in the relays 6-8 configured in the first level and the relaying of software installed in the ECUs 26-31 configured in the second level.

[0077] Regarding diagnostic shielding reference Figures 9 to 10 Please provide an explanation. For example... Figure 9As shown, the OTA master controller 14 maintains a diagnostic mask management table and uses this table to manage the ECUs for which diagnostic masking is performed. Data communication between ECUs occurs at predetermined intervals, such as 1 second. When, for example, one ECU activates software, causing a data communication interruption between ECUs, although the other ECU would normally detect the interruption as a diagnostic, failing to detect it is considered diagnostic masking.

[0078] When the diagnostic shielding determination process begins, the OTA master controller 14 determines whether the target ECU is in the startup state (S31). When it is determined that the target ECU is in the stop state (S31: No), the OTA master controller 14 outputs a startup request to the target ECU in the stop state, causing the target ECU in the stop state to transition to the startup state, and begins to supply power to the target ECU that has transitioned to the startup state (S32).

[0079] The OTA master controller 14 determines whether there is an ECU capable of transitioning to a stop state (S33). When it is determined that there is an ECU capable of transitioning to a stop state (S33: Yes), the OTA master controller 14 determines whether there is an ECU that needs to be diagnostically disabled if a stop request is output to the ECU capable of transitioning to a stop state (S34). When it is determined that there is an ECU that needs to be diagnostically disabled (S34: Yes), the OTA master controller 14 refers to the diagnostically disabled management table to determine the ECU that needs to be diagnostically disabled (S35).

[0080] When an ECU requiring diagnostic masking is identified, the OTA master controller 14 outputs a diagnostic masking setting request to the ECU requiring diagnostic masking and sets diagnostic masking for the ECU requiring diagnostic masking (S36). The OTA master controller 14 outputs a stop request to the ECU that can transition to a stop state, causing the target ECU in the start state to transition to a stop state, and stops the power supply to the target ECU that has transitioned to the stop state (S37).

[0081] The OTA master controller 14 waits for the software activation to the target ECU to be completed (S38). When it is confirmed that the software activation to the target ECU is completed (S38: Yes), it outputs a diagnostic mask removal request to the ECU that has the diagnostic mask set, removes the diagnostic mask of the ECU that has the diagnostic mask set (S39), and ends the diagnostic mask determination process.

[0082] As described above, according to the embodiment, the following effects can be obtained. In the OTA master controller 14, when updating the software of DCM4, repeaters 6-8, and ECU26-32 installed in an electric vehicle powered by electricity from the vehicle battery, the timing for activating the control software of each of DCM4, repeaters 6-8, and ECU26-32 is executed. The activation of the software in DCM4, repeaters 6-8, and ECU26-32 can be performed appropriately.

[0083] In addition to the information described in the claimed scope, this disclosure also includes the following disclosures. [1]

[0085] A master control device (14) updates the software of an electronic control device installed in an electric vehicle powered by electricity from an on-board battery. This update target device is the object of the software update.

[0086] The timing of the activation of the software in each of the updated target devices is controlled. [2]

[0088] As described in [1], the main control device, wherein,

[0089] The activation timing is controlled for each of the update target devices by referring to at least one of the activity information obtained from external devices and the preset setting information. [3]

[0091] As described in [1] or [2], the main control device, wherein,

[0092] The activation timing is controlled for each of the following: vehicle location information indicating the location of the electric vehicle, occupant presence information indicating whether there are occupants, and charging status information indicating the charging status. [4]

[0094] As described in any of [1] to [3], the main control device, wherein,

[0095] When it is determined that a synchronization object device, which is the object to be synchronized with the update object device, exists at the same level as the update object device, the software in the update object device and the software in the synchronization object device are activated simultaneously. [5]

[0097] As described in any of [1] to [4], the main control device, wherein,

[0098] When it is determined that the update object device exists at a lower level compared to the synchronization object device that is being synchronized with the update object device, the software in the update object device is activated after the software in the synchronization object device has been activated. [6]

[0100] As described in any of [1] to [5], the main control device, wherein,

[0101] For each of the update target devices, the activation execution time is controlled within the allowable time based on the activation execution allowable time of the update target device. [7]

[0103] As described in [6], the main control device, in which,

[0104] In the case where the update target device includes a first update target device and a second update target device that needs to be activated in sync with the first update target device, the activation execution timing of the first update target device is controlled within a first permissible timing of the first update target device and within a second permissible timing of the second update target device, based on the permissible timing of the activation execution of the first update target device and the second update target device, and the activation execution timing of the second update target device is controlled within the first permissible timing and within the second permissible timing. [8]

[0106] As described in [7], the main control device, in which,

[0107] When a second update target device is connected between the main control device and the first update target device, control is performed such that the activation period of the first update target device and the activation period of the second update target device do not overlap within the first allowable time period and within the second allowable time period. [9]

[0109] As described in [8], the main control device, in which,

[0110] The first update target device is activated within the first allowable time period and the second allowable time period, and the second update target device is activated after the activation of the first update target device is completed.

[10]

[0112] As described in any of [6] to [9], the main control device, wherein,

[0113] The activation execution timing is controlled by referring to at least one of the activity information obtained from an external device and the preset setting information shown in the illustration.

[11]

[0115] As described in

[10] , the main control device, in which,

[0116] At least one of the activity information and the setting information, as the permissible timing, indicates a timing related to at least one of the following: the location of the electric vehicle, whether there are occupants, and whether the electric vehicle is charging.

[12]

[0118] As described in any of [1] to

[11] , the main control device, wherein,

[0119] When the activation of the software in the updated target device begins, if it is determined that there is a diagnostic shielding target device that is a diagnostic shielding target, a diagnostic shielding setting request is sent to the diagnostic shielding target device.

[13]

[0121] As described in

[12] , the main control device, in which,

[0122] The diagnostic masking setting request is sent to the diagnostic masking target device, and information that can determine the update target device is also sent to the diagnostic masking target device.

[14]

[0124] As described in

[12] or

[13] , the main control device, wherein,

[0125] Once the activation of the software in the updated target device is completed, a diagnostic mask removal request is sent to the diagnostic mask target device.

[0126] Although this disclosure is based on embodiments, it should be understood that this disclosure is not limited to those embodiments or structures. This disclosure also includes various modifications and equivalent variations. Furthermore, various combinations and methods, and even those containing only one element therein, or more or fewer other combinations and methods, also fall within the scope and spirit of this disclosure.

[0127] Although OTA Center 2 was exemplified and the case of wireless reprogramming was explained, it can also be applied to the case of wired reprogramming based on external tool 33 connected to CGW5 via a wired connection.

[0128] The control unit and methods described in this disclosure can be implemented by a dedicated computer, which is provided by comprising a processor and memory programmed to perform one or more functions embodied in a computer program. Alternatively, the control unit and methods described in this disclosure can also be implemented by a dedicated computer, which is provided by comprising a processor constructed using one or more dedicated hardware logic circuits. Alternatively, the control unit and methods described in this disclosure can also be implemented by one or more dedicated computers, which are composed of a combination of a processor and memory programmed to perform one or more functions and a processor constructed of one or more hardware logic circuits. Furthermore, the computer program, as instructions executed by the computer, can also be stored in a computer-readable, non-transient physical storage medium.

Claims

1. A master control device (14) that updates the software of an electronic control device mounted on an electric vehicle powered by electricity from an on-board battery, wherein the update target device is the object of the software update, characterized in that, The timing of the activation of the software in each of the updated target devices is controlled.

2. The main control device as described in claim 1, characterized in that, The activation timing is controlled for each of the update target devices by referring to at least one of the activity information obtained from external devices and the preset setting information.

3. The main control device as described in claim 1, characterized in that, The activation timing is controlled for each of the following: vehicle location information indicating the location of the electric vehicle, occupant presence information indicating whether there are occupants, and charging status information indicating the charging status.

4. The main control device as described in claim 1, characterized in that, When it is determined that a synchronization object device, which is the object to be synchronized with the update object device, exists at the same level as the update object device, the software in the update object device and the software in the synchronization object device are activated simultaneously.

5. The main control device as described in claim 1, characterized in that, When it is determined that the update object device exists at a lower level compared to the synchronization object device that is being synchronized with the update object device, the software in the update object device is activated after the software in the synchronization object device has been activated.

6. The main control device as described in claim 1, characterized in that, For each of the update target devices, the activation execution time is controlled within the allowable time based on the activation execution allowable time of the update target device.

7. The main control device as described in claim 6, characterized in that, In the case where the update target device includes a first update target device and a second update target device that needs to be activated in sync with the first update target device, the activation execution timing of the first update target device is controlled within a first permissible timing of the first update target device and within a second permissible timing of the second update target device, based on the permissible timing of the activation execution of the first update target device and the second update target device, and the activation execution timing of the second update target device is controlled within the first permissible timing and within the second permissible timing.

8. The main control device as described in claim 7, characterized in that, When a second update target device is connected between the main control device and the first update target device, control is performed such that the activation period of the first update target device and the activation period of the second update target device do not overlap within the first allowable time period and within the second allowable time period.

9. The main control device as described in claim 8, characterized in that, The first update target device is activated within the first allowable time period and the second allowable time period, and the second update target device is activated after the activation of the first update target device is completed.

10. The main control device as described in claim 6, characterized in that, The activation execution timing is controlled by referring to at least one of the activity information obtained from an external device and the preset setting information, which are shown as permissible timing.

11. The main control device as described in claim 10, characterized in that, At least one of the activity information and the setting information, as the permissible timing, indicates a timing related to at least one of the electric vehicle's location, whether there are occupants, and whether the electric vehicle is charging.

12. The main control device as described in claim 1, characterized in that, When the activation of the software in the updated target device begins, if it is determined that there is a diagnostic shielding target device that is a diagnostic shielding target, a diagnostic shielding setting request is sent to the diagnostic shielding target device.

13. The main control device as described in claim 12, characterized in that, The diagnostic masking setting request is sent to the diagnostic masking target device, and information that can determine the update target device is also sent to the diagnostic masking target device.

14. The main control device as described in claim 12 or 13, characterized in that, Once the activation of the software in the updated target device is completed, a diagnostic mask removal request is sent to the diagnostic mask target device.

15. A vehicle system (3) comprising: a main control unit (14) that uses an electronic control device mounted on an electric vehicle powered by electricity from an on-board battery as an update target device, the update target device being a software update target; and said update target devices (4, 6-8, 26-32), characterized in that, The main control device controls the timing of software activation in each of the update target devices.

16. The vehicle system as claimed in claim 9, characterized in that, When the activation of the software in the updated target device begins, and a diagnostic masking target device is identified as a diagnostic masking target device, the main control device sends a diagnostic masking setting request to the diagnostic masking target device. When the diagnostic shielding target device receives a diagnostic shielding setting request from the main control device, it transitions from a valid diagnostic detection state to an invalid diagnostic detection state.

17. The vehicle system as claimed in claim 10, characterized in that, After completing the activation of the software in the updated target device, the diagnostic shielding target device sends a diagnostic shielding removal request to the diagnostic shielding target device. When the diagnostic shielding device receives a diagnostic shielding release request from the main control device, it recovers from the invalid state of diagnostic detection to the valid state of diagnostic detection.

18. An activation execution control method, characterized in that, The execution timing of activating the software in each updated target device is included in the main control device (14). The main control device will update the software of the electronic control device of the electric vehicle, which is powered by electricity from the vehicle battery, as the update target device.

19. An activated execution control program, characterized in that, The main control device (14) executes an execution control step, in which the execution timing for activating the software in each update target device is controlled. The main control device updates the software of the electronic control unit of the electric vehicle, which is powered by electricity from the vehicle battery. The update target device is the object of the software update.

Images