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

Abstract

An OTA master (14) adopts an electronic control device being mounted on an electric vehicle, which uses power from an on-vehicle battery as a power source, as a device to be updated, of which software is to be updated, and updates the software. An activation execution timing of the software in the device to be updated is controlled for each device to be updated.

Description

Master device, vehicle system, activation execution control method, and activation execution control program CROSS-REFERENCE TO RELATED APPLICATIONS

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

[0002] The present disclosure relates to a master device, a vehicle system, an activation execution control method, and an activation execution control program.

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

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

[0005] In OTA repro, after installing the software by writing it to the target ECU, the software installed on the target ECU is activated, but the target ECU cannot operate while the activation is in progress. For example, non-electric vehicles such as gasoline-powered vehicles have only fixed power systems such as +B, accessories (hereinafter referred to as ACC), and ignition (hereinafter referred to as IG), so activation is performed, for example, after a certain period of time has passed after the ignition is turned off. Therefore, in non-electric vehicles, if an ECU that needs to operate continues to operate even while the ignition is off, activation cannot be performed.

[0006] On the other hand, in electric vehicles such as battery electric vehicles (hereinafter referred to as BEVs) that use electricity from an on-board battery as a power source, power supply control for all ECUs can be freely performed by software. Therefore, unlike the non-electric vehicles described above, the timing of activation is not limited to when the ignition is turned off, but a mechanism for performing activation is still required.

[0007] The present disclosure aims to appropriately activate software in an update target device in a configuration in which the update target device is an electronic control device installed in an electric vehicle powered by electricity from an on-board battery.

[0008] In one aspect of the present disclosure, a master device controls software activation timing for each update target device, the update target device being an electronic control device mounted on an electric vehicle powered by an on-board battery.

[0009] A vehicle system according to one aspect of the present disclosure includes a master device that performs software updates on electronic control devices mounted on an electric vehicle powered by an on-board battery, the electronic control devices being the update target devices, and the master device controls the timing of software activation in each of the update target devices.

[0010] A method for controlling the execution of activation according to one aspect of the present disclosure includes controlling the timing of software activation in each update target device in a master device that performs software updates on electronic control devices mounted on an electric vehicle powered by power from an on-board battery, the electronic control devices being the update target devices.

[0011] An activation execution control program according to one embodiment of the present disclosure causes a master device that performs software updates on an electronic control device installed in an electric vehicle powered by electricity from an on-board battery as an update target device, which is the target of software updates, to execute an execution control procedure that controls the timing of software activation in the update target device for each update target device.

[0012] According to one aspect of the present disclosure, when a software update is performed on an electronic control device mounted on an electric vehicle powered by an on-board battery as an update target device, the timing of software activation in the update target device is controlled for each update target device, allowing the software in the update target device to be activated appropriately.

[0013] According to one aspect of the present disclosure, in a vehicle system including a master device that performs software updates on electronic control devices mounted on an electric vehicle powered by power from an on-board battery as update target devices, and the update target devices, when the master device performs software updates on electronic control devices mounted on an electric vehicle powered by power from an on-board battery as update target devices, the timing of software activation in the update target devices is controlled for each update target device, allowing the software in the update target devices to be activated appropriately.

[0014] 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 an activation execution timing list, Fig. 4 is a diagram showing a hierarchy, Fig. 5 is a flowchart, Fig. 6 is a flowchart, Fig. 7 is a flowchart, Fig. 8 is a flowchart, Fig. 9 is a diagram showing a diagnostic mask management table, and Fig. 10 is a flowchart.

[0015] An embodiment will be described below with reference to the drawings. As shown in Fig. 1, a data communication system 1 is configured to enable data communication between an over-the-air (OTA) center 2 and a vehicle system 3 installed in a vehicle. An unspecified number of vehicle systems 3 can communicate data with the OTA center 2. The vehicle is, for example, an electric vehicle such as a BEV powered by electricity from an on-board battery. Unlike non-electric vehicles such as gasoline-powered vehicles, electric vehicles can freely control the power supply to all ECUs installed in the vehicle using software.

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

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

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

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

[0020] The CGW 5 includes a ReproMaster 9, an in-vehicle HMI (Human Machine Interface) 10 (corresponding to the controlled device), 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 the master device).

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

[0022] 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, a campaign target ECU list storage unit 21, and an activation execution timing list storage unit 22. 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.

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

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

[0025] As shown in Fig. 3, the activation execution timing list storage unit 22 stores information that can identify the activation execution timing for each ECU included in the specification data as an activation execution timing list. For all ECUs, the activation execution timing condition is that the vehicle's location is not in an avoid area. This can also be said to indicate that the timing when the vehicle is not in an avoid area is an allowable timing for activation execution. An avoid area is, for example, an area with poor security.

[0026] For example, for the display system ECU, driving system ECU, autonomous driving system ECU, and body system ECU, the condition for the timing of activation is that there is no occupant present. This can also be interpreted as indicating that the timing when there is no occupant present is an acceptable timing for activation. For example, for the air conditioning system ECU, the condition for the timing of activation is that there is no occupant present and the interior temperature is equal to or greater than a first threshold and equal to or less than a second threshold. This can also be interpreted as indicating that the timing when there is no occupant present and the interior temperature is equal to or greater than the first threshold and equal to or less than the second threshold is an acceptable timing for activation. For example, for the lighting system ECU, the condition for the timing of activation is that there is no occupant present and the interior illuminance is equal to or greater than a threshold. This can also be interpreted as indicating that the timing when there is no occupant present and the interior illuminance is equal to or greater than a threshold is an acceptable timing for activation. The absence of an occupant is determined, for example, based on whether a certain amount of time has passed since the user got out of the vehicle or on the user's usual usage pattern.

[0027] For example, for a charging ECU, the condition for the timing to activate is that the vehicle is not charging. This can also be said to indicate that the timing when the vehicle is not charging is an acceptable timing for activation. Whether the vehicle is not charging is determined based on, for example, whether the vehicle is moving or whether a certain amount of time has passed since the driver got off. For example, for a communication ECU, the condition for the timing to activate is that the vehicle is stopped. This can also be said to indicate that the timing when the vehicle is stopped is an acceptable timing for activation. The conditions for the timing to activate are not limited to the conditions shown in the example. Note that the DCM 4 issues an emergency call in the event of an accident while the vehicle is moving, and an emergency call in the event of theft while the vehicle is parked. The activation timing list can also be set in advance as setting information in the vehicle.

[0028] 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 23 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 23 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.

[0029] The OBC 12 includes an arbitration function unit 24 and a diagnostic communication function unit 25. The arbitration function unit 24 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 25 performs diagnostic communication between the ReproMaster 9 and the repeater or ECU according to the arbitration result of the arbitration function unit 24.

[0030] The OBC 12 is connected to a plurality of ECUs 26, 27 (corresponding to update target devices) via a first repeater 6. The plurality of ECUs 26, 27 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 26, 27 is data communication using a 29-bit CAN ID. Of the plurality of ECUs 26, 27 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.

[0031] Similarly, the OBC 12 is connected to a plurality of ECUs 28, 29 (corresponding to devices to be updated) via a second relay 7. The plurality of ECUs 28, 29 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 28, 29 is data communication using a 29-bit CAN ID. Of the plurality of ECUs 28, 29 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.

[0032] Similarly, the OBC 12 is connected to a plurality of ECUs 30, 31 (corresponding to update target devices) via a third relay 8. The plurality of 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 plurality of ECUs 30, 31 is data communication using a 29-bit CAN ID. An ECU that is the target of software update among the plurality of ECUs 30, 31 connected to the third relay 8 can be the target ECU. While the example illustrates a case in which two ECUs are connected to the third relay 8, the number of ECUs connected to the third relay 8 is not limited to two. CAN communication between the first relay 6 and the plurality of ECUs 26, 27, CAN communication between the second relay 7 and the plurality of ECUs 28, 29, and CAN communication between the third relay 8 and the plurality of ECUs 30, 31 may be data communication using an 11-bit CAN ID.

[0033] The OBC 12 is also connected to an ECU 32 (corresponding to the device to be updated) without a relay. Of the multiple ECUs connected to the OBC 12, the ECU whose software is to be updated can be the target ECU. While the example shows a case where one ECU is connected to the OBC 12 without a relay, the number of ECUs connected to the OBC 12 without a relay is not limited to one.

[0034] The power control application 23 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 26 to 32 as the software update progresses. That is, the OTA master 14 cooperates the power control function unit 19 with the power control application 23, and controls the power supply to the repeaters 6 to 8 and the ECUs 26 to 32 that are capable of diagnostic communication via the diagnostic communication function unit 25.

[0035] When a start request is input from the OTA master 14 to the DCM 4, the in-vehicle HMI 10, the repeaters 6 to 8, and the ECUs 26 to 32 while they are in a stopped state, they transition to a started state and the supply of power from the in-vehicle battery begins. When a stop request is input from the OTA master 14 to the DCM 4, the in-vehicle HMI 10, the repeaters 6 to 8, and the ECUs 26 to 32 while they are in a started state, they transition to a stopped state and the supply of power from the in-vehicle battery is stopped.

[0036] The external tool 33, while attached to a connector provided in the vehicle, delivers the update package to the OTA master 14. The external memory 34 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-8 and the ECUs 26-32.

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

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

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

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

[0041] 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 indicating the software update status from the target ECU.

[0042] In the OTA master 14, when target ECUs are arranged in a hierarchical structure and multiple ECUs to be activated are located in different hierarchical layers, the activation of the multiple ECUs to be activated is performed in the order of the hierarchical layers. As shown in FIG. 4 , in terms of the number of relays from the OTA master 14, the first relay 6, the second relay 7, the third relay 8, and the ECU 32 are arranged in the first hierarchical layer. The ECUs 26 to 31 are arranged in the second hierarchical layer. In this embodiment, the number of relays is two, and the hierarchical layers are the first and second hierarchical layers. However, the number of relays may be three or more. In the case where the number of relays is three, the hierarchical layers are the first, second, and third hierarchical layers.

[0043] When multiple ECUs to be activated are arranged in layers, the OTA master 14 prioritizes activation of ECUs in lower layers. That is, the OTA master 14 activates ECUs in lower layers before activating ECUs in higher layers. That is, the OTA master 14 activates ECUs in higher layers after the activation of ECUs in lower layers is completed. This prevents the relay of data communication between the OTA master 14 and the ECU in the lower layer currently being activated from being interrupted by the activation of an ECU in the higher layer that relays the data communication.

[0044] The specification data distributed from the OTA center 2 defines the activation order in which priority is given to ECUs in lower hierarchical levels, and the OTA master 14 identifies the activation order by analyzing the specification data. Furthermore, when the OTA master 14 holds the connection relationships between the relays 6-8 and the ECU 32 arranged in the first hierarchical level and the ECUs 26-31 arranged in the second hierarchical level, the OTA master 14 may acquire the targets for software activation from the specification data, and identify the activation order by comparing the acquired targets for activation with the setting information indicating the connection relationships it holds.

[0045] Next, the operation of the above-described configuration will be described with reference to FIGS. 5 to 10. When the OTA master 14 starts a software update process and detects an OTA start trigger (S1), it refers to the OTA-compatible ECU list to identify ECUs that support OTA. The OTA master 14 determines whether any of the identified ECUs that support OTA are in a stopped state (S2). If the OTA master 14 identifies any of the ECUs that support OTA as being in a stopped state (S2: YES), it outputs a startup request to the stopped ECU, transitions the stopped ECU to an activated state, and starts supplying power to the activated ECU (S3). That is, during the configuration synchronization phase, if the DCM 4, the in-vehicle HMI 10, the repeaters 6 to 8, and the ECUs 26 to 32 need to be activated, the OTA master 14 transitions the DCM 4, the in-vehicle HMI 10, the repeaters 6 to 8, and the ECUs 26 to 32 to their activated states.

[0046] The OTA master 14 performs a configuration synchronization process (S4). Upon completion of the configuration synchronization process, 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, stops the power supply to the ECU that has been transitioned to a stopped state (S6), and performs a download process. 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 26-32, the OTA master 14 transitions the identified ECU to a stopped state and performs a download process.

[0047] Upon completing the download process, the OTA master 14 performs an installation process (S8). Upon completing the installation process, the OTA master 14 determines whether there are multiple target ECUs requiring synchronized activation, in other words, whether the activation of multiple ECUs to be activated needs to be performed synchronously (S9). Multiple ECUs requiring synchronized activation typically have a mutually linked relationship. Identification information, such as an ECU ID, that can identify the ECUs that require synchronized activation and identify the ECUs that require synchronized activation is stored, for example, in the specification data. The OTA master 14, for example, references the specification data to determine whether the activation of multiple ECUs to be activated needs to be performed synchronously and identifies the ECUs that require synchronized activation.

[0048] If the OTA master 14 determines that the activation of multiple ECUs to be activated does not need to be synchronized (S9: NO), it performs a first activation process (S10) for each ECU to be activated, the details of which are shown as a flowchart in FIG. 6 , in order to activate all ECUs to be activated. When the OTA master 14 starts the first activation process, it identifies the ECUs to be activated (S13). If there are multiple ECUs to be activated, the OTA master 14 identifies one of the multiple ECUs to be activated as the target ECU for the first activation process in S13. After identifying the target ECU, the OTA master 14 checks the vehicle status (S14), checks the status of the ECU to be activated (S15), and determines whether the ECU to be activated is in a state where software activation can be performed (S16).

[0049] For example, when the OTA master 14 confirms in step S14 that the remaining charge of the in-vehicle battery, which is the vehicle state, is equal to or greater than a predetermined remaining charge, and when the OTA master 14 confirms in step S15 that the state of the ECU to be activated is not in a predetermined fault state by reading a DTC (Diagnostic Trouble Code) or the like, the OTA master 14 determines in step S16 that the ECU to be activated is in a state in which software activation can be executed. When the OTA master 14 confirms at least either that the remaining charge of the in-vehicle battery is less than a predetermined remaining charge or that the state of the ECU to be activated is in a predetermined fault state by reading a DTC or the like, the OTA master 14 determines that the ECU to be activated is not in a state in which software activation can be executed.

[0050] If the OTA master 14 determines that the software is not in a state where activation can be executed (S16: NO), the OTA master 14 ends the first activation process and returns to the software update process. When the OTA master 14 returns to the software update process, the OTA master 14 performs an update completion notification process and ends the software update process.

[0051] When the OTA master 14 determines that the software is in a state where activation can be executed (S16: YES), it refers to the activation execution timing list and determines whether the activation execution condition is met for the ECU identified as the target of the first activation process (S17). The activation execution condition is that the current time is within the allowable activation execution timing for the ECU identified as the target of the first activation process. For example, if the allowable activation execution timing for the ECU identified as the target of the first activation process is that there is no occupant and the interior temperature is equal to or greater than a first threshold and equal to or less than a second threshold, the activation execution condition is that there is no occupant and the interior temperature is equal to or greater than the first threshold and equal to or less than the second threshold.

[0052] When the OTA master 14 determines that the activation execution conditions are met (S17: YES), it sends an activation execution instruction to the ECU to be activated and activates the software in the ECU to be activated (S18, corresponding to the execution control procedure). That is, if the ECU to be activated is, for example, a display ECU or a driving ECU, the OTA master 14 determines that the activation execution conditions are met and activates the software if the vehicle is not located in an avoidance area and there is no occupant present. For example, if the ECU to be activated is an air conditioning ECU, the OTA master 14 determines that the activation execution conditions are met and activates the software if the vehicle is not located in an avoidance area, there is no occupant present, and the interior temperature is equal to or greater than a first threshold and equal to or less than a second threshold.

[0053] The OTA master 14 broadcasts to all ECUs an activation in progress notification indicating that activation is in progress, including ECU identification information that can identify the ECU to be activated (S19), and terminates the first activation process for the ECU to be activated that has been identified as the processing target. When the OTA master 14 has terminated the first activation process for all ECUs to be activated, the OTA master 14 returns to the software update process.

[0054] On the other hand, if the OTA master 14 determines that activation of multiple ECUs to be activated synchronously (S9: YES), it performs a second activation process (S11) for each ECU to be activated, the details of which are shown as flowcharts in FIGS. 7 and 8 , in order to activate all ECUs to be activated. When the OTA master 14 starts the second activation process, it identifies the ECUs to be activated (S20). If there are multiple ECUs to be activated, the OTA master 14 identifies one of the multiple ECUs to be activated as the target ECU for the second activation process in S20. After identifying the ECU to be activated, the OTA master 14 checks the vehicle status (S21), checks the status of the ECU to be activated (S22), and determines whether the ECU to be activated is in a state where software activation can be performed (S23). When the OTA master 14 determines that the ECU to be activated is not in a state in which software activation can be executed (S23: NO), the OTA master 14 ends the second activation process and returns to the software update process.

[0055] When the OTA master 14 determines that the ECU to be activated is in a state in which software activation can be executed (S23: YES), it refers to the activation execution timing list and determines whether the activation execution condition for the ECU to be activated is met (S24). The activation execution condition is that the current time is within the allowable timing for activation execution for the ECU to be activated identified as the processing target of the second activation process. When the OTA master 14 determines that the activation execution condition for the ECU to be activated is met (S24: YES), it determines whether the activation execution condition for the ECU to be synchronized is met (S25). The activation execution condition is that the current time is within the allowable timing for activation execution for the ECU to be synchronized.

[0056] When the OTA master 14 determines that the activation execution condition is met for the ECU to be synchronized (S25: YES), it determines whether the ECU to be synchronized and the ECU to be activated are in the same hierarchical layer (S26).When the OTA master 14 determines that the ECU to be synchronized and the ECU to be activated are in the same hierarchical layer (S26: YES), it sends an instruction to execute activation to the ECU to be activated, and activates the software in the ECU to be activated (S27, which corresponds to the execution control procedure).

[0057] The OTA master 14 broadcasts to all ECUs an activation in progress notification indicating that activation is in progress, including ECU identification information that can identify the ECU to be activated (S28), and terminates the second activation process for the ECU to be activated that has been identified as the processing target. When the OTA master 14 has terminated the second activation process for all ECUs to be activated, the OTA master 14 returns to the software update process.

[0058] If the OTA master 14 determines that the ECU to be synchronized is not in the same hierarchical level as the ECU to be activated but is in a lower hierarchical level (S26: NO), it determines whether activation has been completed in the ECU to be synchronized in the lower hierarchical level (S29).If the OTA master 14 determines that activation has been completed in the ECU to be synchronized in the lower hierarchical level (S29: YES), it performs steps S27 and S28 described above, ends the second activation process, and returns to the software update process.

[0059] As described above, the OTA master 14 prioritizes activation of ECUs in lower hierarchical levels, activating software installed in, for example, ECUs 26-31 first, followed by software installed in the first repeater 6, the second repeater 7, the third repeater 8, and ECU 32. In this case, the OTA master 14 simultaneously activates, for example, the first repeater 6, the second repeater 7, the third repeater 8, and ECUs 26-32, and sequentially shuts down the ECUs and repeaters that have completed software activation. The OTA master 14 simultaneously activates, for example, the first repeater 6 and ECUs 26 and 27, starts activating the software installed in the ECUs 26 and 27, and shuts down the ECUs 26 and 27 upon completion of the activation. The OTA master 14 then starts activating the software installed in the first repeater 6, and shuts down the first repeater 6 upon completion of the activation.

[0060] Furthermore, 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 ECUs 26 and 27 connected to the first relay 6 in parallel with software installed in the ECUs 28 and 29 connected to the second relay 7. 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.

[0061] 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 28 and 29 connected to the second relay 7.

[0062] The OTA master 14 adjusts the period for activating software installed in the relays 6-8 and ECU 32 arranged in the first hierarchical layer so that the period for activating software installed in the ECUs 26-31 arranged in the second hierarchical layer 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 hierarchical layer activating software and the relaying of software installed in the ECUs 26-31 arranged in the second hierarchical layer being performed in parallel.

[0063] The diagnostic mask will be described with reference to Figures 9 and 10. As shown in Figure 9, 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 one second. For example, if one ECU activates software and data communication between the ECUs is interrupted, the other ECU would normally detect 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.

[0064] When the OTA master 14 starts the diagnostic mask determination process, it determines whether the target ECU is in an activated state (S31). If the OTA master 14 determines that the target ECU is in a stopped state (S31: 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 (S32).

[0065] The OTA master 14 determines whether there is an ECU that can be switched to a stopped state (S33). If the OTA master 14 determines that there is an ECU that can be switched to a stopped state (S33: 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 (S34). If the OTA master 14 determines that there is an ECU that requires a diagnostic mask (S34: YES), the OTA master 14 refers to the diagnostic mask management table and identifies the ECU that requires a diagnostic mask (S35).

[0066] 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 (S36).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 (S37).

[0067] The OTA master 14 waits for the software activation to be completed for the target ECU (S38), and when it determines that the software activation to the target ECU has been completed (S38: 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 (S39), and terminates the diagnostic mask determination process.

[0068] As described above, the embodiment can achieve the following advantageous effects: When the OTA master 14 performs software updates on the DCM 4, repeaters 6-8, and ECUs 26-32 mounted on an electric vehicle powered by power from an on-board battery, the timing of software activation is controlled for each of the DCM 4, repeaters 6-8, and ECUs 26-32. This allows appropriate software activation in the DCM 4, repeaters 6-8, and ECUs 26-32.

[0069] The present disclosure includes the following disclosures in addition to what is set forth in the claims: [1] A master device (14) that performs software updates on electronic control devices mounted on an electric vehicle powered by power from an on-board battery as update target devices that are software update targets, the master device controlling the timing of software activation in the update target devices for each update target device.

[0070] [2] The master device according to [1], which controls the timing of the activation for each of the update target devices by referring to at least one of campaign information acquired from an external device and preset setting information.

[0071] [3] The master device according to [1] or [2] controls the timing of the activation for each of the update target devices based on at least one of vehicle position information indicating the position of the electric vehicle, occupant presence information indicating the presence or absence of an occupant, and charging status information indicating the charging status.

[0072] [4] A master device according to any one of [1] to [3], which, when it is determined that a synchronization target device to be synchronized with the update target device exists in the same hierarchical level as the update target device, simultaneously activates software in the update target device and activates software in the synchronization target device.

[0073] [5] A master device according to any one of [1] to [4], which, when it is determined that a synchronization target device to be synchronized with the update target device exists at a lower level than the update target device, activates the software on the update target device after completing activation of the software on the synchronization target device.

[0074] [6] The master device according to any one of [1] to [5], wherein the master device controls, for each update target device, the timing of activation execution within the allowable timing based on the allowable timing of activation execution of the update target device.

[0075] [7] A master device as described in [6], wherein when the update target devices include a first update target device and a second update target device that requires activation to be executed in synchronization with the first update target device, the master device controls the activation execution timing of the first update target device to be within the first allowable timing of the first update target device and within the second allowable timing of the second update target device based on the allowable timing of activation execution of each of the first update target device and the second update target device, and controls the activation execution timing of the second update target device to be within the first allowable timing and the second allowable timing.

[0076] [8] A master device as described in [7], which, when the second update target device is connected between the master device and the first update target device, controls the activation period of the first update target device and the activation period of the second update target device so that they do not overlap within the first allowable timing and the second allowable timing.

[0077] [9] A master device as described in [8], which activates the first update target device within the first allowable timing and the second allowable timing, and activates the second update target device after activation of the first update target device is completed.

[0078]

[10] A master device according to any one of [6] to [9], which controls the timing of activation by referring to at least one of campaign information acquired from an external device indicating the allowable timing and preset setting information.

[0079]

[11] The master device according to

[10] , wherein at least one of the campaign information and the setting information indicates, as the allowable timing, timing relating to at least one of the location of the electric vehicle, the presence or absence of an occupant, and whether the electric vehicle is being charged.

[0080]

[12] A master device described in any one of claims [1] to

[11] , which, when starting to activate software in the update target device, if it identifies that there is a diagnostic mask target device that is the target of diagnostic masking, sends a diagnostic mask setting request to the diagnostic mask target device.

[0081]

[13] The master device according to

[12] , which transmits the diagnostic mask setting request to the diagnostic mask target device and also transmits information capable of identifying the update target device to the diagnostic mask target device.

[0082]

[14] The master device according to

[12] or

[13] , which transmits a diagnostic mask release request to the diagnostic mask target device when the execution of software activation in the update target device is completed.

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

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

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

A master device (14) that performs software update on an electronic control device mounted on an electric vehicle powered by an on-board battery as an update target device, the update target device being an update target, comprising: a master device that controls the timing of software activation in each of the update target devices; 　 2. The master device according to claim 1, wherein the timing of executing the activation is controlled for each of the update target devices by referring to at least one of campaign information acquired from an external device and preset setting information.

2. The master device according to claim 1, wherein the timing of executing the activation is controlled for each of the update target devices based on at least one of vehicle position information indicating a position of the electric vehicle, occupant presence information indicating the presence or absence of an occupant, and charge state information indicating a charging state. 　 A master device as described in claim 1, which, when it is determined that a synchronization target device to be synchronized with the update target device exists in the same hierarchical level as the update target device, activates software in the update target device and activates software in the synchronization target device simultaneously. 　 A master device as described in claim 1, wherein when it is determined that a synchronization target device to be synchronized with the update target device exists at a lower level than the update target device, the master device completes software activation on the synchronization target device before activating software on the update target device.

2. The master device according to claim 1, wherein the master device controls, for each of the update target devices, the timing of the activation to be performed within an allowable timing based on the allowable timing of the activation of the update target device. 　 A master device as described in claim 6, wherein when the update target devices include a first update target device and a second update target device that requires activation to be executed synchronized with the first update target device, the master device controls the activation execution timing of the first update target device to be within the first allowable timing of the first update target device and within the second allowable timing of the second update target device based on the allowable timing of activation execution of each of the first update target device and the second update target device, and controls the activation execution timing of the second update target device to be within the first allowable timing and the second allowable timing. 　 A master device as described in claim 7, which controls the activation period of the first update target device and the activation period of the second update target device so that they do not overlap within the first allowable timing and the second allowable timing when the second update target device is connected between the master device and the first update target device. 　 A master device as described in claim 8, which activates the first update target device within the first allowable timing and the second allowable timing, and activates the second update target device after activation of the first update target device is completed.

7. The master device according to claim 6, wherein the timing of activation is controlled by referring to at least one of campaign information acquired from an external device in which the allowable timing is indicated and preset setting information.

11. The master device according to claim 10, wherein at least one of the campaign information and the setting information indicates, as the allowable timing, timing related to at least one of a location of the electric vehicle, the presence or absence of an occupant, and whether the electric vehicle is being charged. 　 A master device as described in claim 1, which, when starting to activate software in the update target device, identifies the existence of a diagnostic mask target device that is the target of diagnostic masking, sends a diagnostic mask setting request to the diagnostic mask target device.

13. The master device according to claim 12, wherein the master device transmits the diagnostic mask setting request to the diagnostic mask target device and transmits information capable of identifying the update target device to the diagnostic mask target device.

14. The master device according to claim 12, wherein when the execution of software activation in the update target device is completed, the master device transmits a diagnostic mask release request to the diagnostic mask target device. 　 A vehicle system (3) comprising a master device (14) that performs software updates on electronic control devices mounted on an electric vehicle powered by electricity from an on-board battery, the electronic control devices being the update target devices that are the subject of software updates, and the update target devices (4, 6 to 8, 26 to 32), wherein the master device controls the timing of software activation in the update target devices for each update target device. 　 When the master device starts activating software in the update target device, if the master device identifies that a diagnostic mask target device that is a target for diagnostic masking exists, the master device transmits a diagnostic mask setting request to the diagnostic mask target device; 10. The vehicle system according to claim 9, wherein the diagnostic mask target device transitions from a diagnostic detection enabled state to a diagnostic detection disabled state when the diagnostic mask setting request is received from the master device. 　 When the diagnostic mask target device has completed the activation of the software in the update target device, the diagnostic mask target device transmits a diagnostic mask release request to the diagnostic mask target device; 11. The vehicle system according to claim 10, wherein the diagnostic mask target device returns from a diagnostic detection disabled state to a diagnostic detection enabled state when a diagnostic mask release request is received from the master device. 　 A master device (14) for updating software of an electronic control device mounted on an electric vehicle powered by an on-board battery as an update target device, the software of which is to be updated, A method for controlling execution of activation, the method comprising controlling, for each of the update target devices, the timing of execution of software activation in the update target devices. 　 A master device (14) performs software update on an electronic control device mounted on an electric vehicle powered by an on-board battery as an update target device, the update target device being an update target of the software. an activation execution control program that executes an execution control procedure that controls the timing of software activation in the update target device for each update target device;

Images