Master device, external device, data communication system, software update method, and software update program

Abstract

An OTA master (14) sequentially performs, as processes relating to software update, installation of software to an update target device, which is a target for software update, activation of the installed software, start of new bank by the activated software, and version consistency check, thereby bringing the update target device into a state in which control of the update target device can be initiated. When there are a plurality of update target devices, the plurality of update target devices are divided into a plurality of groups, and the installation, the activation, the start of new bank, and the version consistency check are performed, on a group-by-group basis, in prescribed update units and in a prescribed update order.

Description

Master device, external device, data communication system, software update method, and software update program CROSS-REFERENCE TO RELATED APPLICATIONS

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

[0002] The present disclosure relates to a master device, an external device, a data communication system, a software update method, and a software update program.

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

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

[0005] In OTA repro, control of the target ECU is started by sequentially installing software on the target ECU, activating the installed software, booting up the activated software, and checking version consistency. If there are multiple target ECUs, after booting up all of the target ECUs, a version consistency check is performed on the group of ECUs that are the subject of the version consistency check, including all of the target ECUs, and control of the multiple target ECUs is started simultaneously.

[0006] However, if there is a time difference in the timing of completion of new surface activation, the target ECU that completes new surface activation first will have to wait for the completion of new surface activation of the other target ECUs until it starts version consistency checks on the group of ECUs that are the subject of the version consistency check, including all of the multiple target ECUs.As a result, even if there is a request to start control of the target ECU that completed new surface activation first before control of the other target ECUs, it cannot be accommodated.

[0007] The present disclosure aims to start control of a specific update target device prior to control of other update target devices.

[0008] In one aspect of the present disclosure, a master device performs software update processing by sequentially installing software in an update target device that is the target of the software update, activating the installed software, booting up the device using the activated software, and checking version consistency, thereby bringing the update target device into a state where it can start controlling the update target device. If there are multiple update target devices, the master device divides the update target devices into multiple groups, and performs the installation, activation, booting up the device using the activated software, and checking version consistency on a group-by-group basis in a predetermined update unit and in a predetermined update order.

[0009] In one aspect of the present disclosure, a master device performs software update processing by sequentially installing software in an update target device that is the target of the software update, activating the installed software, booting up the device using the activated software, and checking version consistency, thereby bringing the update target device into a state where it can start controlling the update target device. If there are multiple update target devices, the master device divides the update target devices into multiple groups, and performs the booting up the device using the activated software on a group-by-group basis in a predetermined check unit and in a predetermined check order.

[0010] An external device according to one aspect of the present disclosure distributes campaign information related to software update processing to a master device that brings an update target device into a state where it can start controlling the update target device by sequentially installing software on the update target device, activating the installed software, booting up the new version using the activated software, and checking version consistency. The external device registers or distributes to the master device update unit order information indicating an update unit order for the installation, activation, booting up the new version, and version consistency check to be performed by the master device on a group basis in a predetermined update unit and in a predetermined update order.

[0011] An external device according to one aspect of the present disclosure distributes campaign information relating to software update processing to a master device that brings an update target device into a state where it can start controlling the update target device by sequentially installing software in the update target device, activating the installed software, booting the updated device using the activated software, and checking version consistency. The external device registers or distributes to the master device check unit sequence information indicating a check unit sequence for performing the booting the updated device and the version consistency check on a group basis in a predetermined check unit and a predetermined check sequence.

[0012] A data communication system according to one aspect of the present disclosure includes a master device that performs software update processing, including installing software in an update target device that is the target of a software update, activating the installed software, booting up the activated software, and checking version consistency, thereby bringing the update target device into a state where it can start control, and an external device that distributes campaign information related to the software update processing to the master device. The external device registers or distributes to the master device update unit order information indicating an update unit order in which the installation, activation, booting up the activated software, and version consistency check are performed in the master device on a group basis in a predetermined update unit and in a predetermined update order. The master device identifies the group unit based on the update unit order information acquired from the external device, divides multiple update target devices into multiple groups according to the identified group unit, and performs the installation, activation, booting up the activated software, and version consistency check on the group basis in a predetermined update unit and in a predetermined update order.

[0013] A data communication system according to one aspect of the present disclosure includes a master device that performs software update processing on an update target device, which is a target of software update, by sequentially installing software in the update target device, activating the installed software, booting the updated device to a new version using the activated software, and checking version consistency, thereby putting the update target device into a state where it can start control, and an external device that distributes campaign information related to the software update processing to the master device. The external device registers or distributes to the master device check unit order information indicating a check unit order for the master device to perform the booting to a new version and the version consistency check on a group basis in a predetermined check unit and in a predetermined check order. The master device identifies the group units based on the check unit order information acquired from the external device, divides multiple update target devices into multiple groups according to the identified group units, and performs the booting to a new version and the version consistency check on a group basis in a predetermined check unit and in a predetermined check order.

[0014] A software update method according to one aspect of the present disclosure includes a master device that brings an update target device into a state where it can start controlling the update target device by sequentially performing the following processes related to a software update: installing software on the update target device that is the target of the software update, activating the installed software, booting up the device using the activated software, and checking version consistency; and if there are multiple update target devices, dividing the multiple update target devices into multiple groups and performing the installation, activation, booting up the device using the activated software, and checking version consistency on a group-by-group basis in a predetermined update unit and in a predetermined update order.

[0015] A software update method according to one aspect of the present disclosure includes a master device that brings an update target device into a state where it can start controlling the update target device by sequentially performing the following processes related to software update: installing software on the update target device that is the target of the software update, activating the installed software, booting up the device using the activated software, and checking version consistency; and if there are multiple update target devices, dividing the multiple update target devices into multiple groups and performing the booting up the device using the new version and the version consistency check on a group-by-group basis using a predetermined check unit and a predetermined check order.

[0016] A software update program according to one aspect of the present disclosure performs software update processing by sequentially installing software on an update target device that is the target of the software update, activating the installed software, booting up the device using the activated software, and checking version consistency. This puts the update target device into a state where it can begin control. If there are multiple update target devices, the program divides the multiple update target devices into multiple groups and executes an update procedure in which the installation, activation, booting up the device using the activated software, and version consistency check are performed on a group-by-group basis in a predetermined update unit and in a predetermined update order.

[0017] A software update program according to one aspect of the present disclosure performs software update processing by sequentially installing software on an update target device that is the target of the software update, activating the installed software, booting up the device using the activated software, and checking version consistency. This puts the update target device into a state where it can begin control, and if there are multiple update target devices, causes the master device to divide the multiple update target devices into multiple groups and execute an update procedure in which the booting up the device using the new version and the version consistency check are performed on a group-by-group basis in a predetermined check unit and in a predetermined check order.

[0018] According to one aspect of the present disclosure, when there are multiple update target devices that are the target of software updates, the multiple update target devices are divided into multiple groups, and installation, activation, new startup, and version consistency checks are performed on a group basis in a predetermined update unit and in a predetermined update order. A version consistency check for a specific update target device can be completed prior to version consistency checks for other update target devices, and control of a specific update target device can be started prior to control of the other update target devices.

[0019] According to one aspect of the present disclosure, when there are multiple update target devices that are the target of software updates, the multiple update target devices are divided into multiple groups, and new startup and version consistency checks are performed on a group-by-group basis in a predetermined check unit and a predetermined check order. A version consistency check for a specific update target device can be completed prior to version consistency checks for other update target devices, and control of a specific update target device can be started prior to control of the other update target devices.

[0020] According to one aspect of the present disclosure, update unit order information indicating an update unit order for installing, activating, starting a new version, and checking version consistency in groups in a master device according to a predetermined update unit and a predetermined update order is registered or distributed to the master device. In the master device, a version consistency check for a specific update target device can be completed prior to version consistency checks for other update target devices, and control of a specific update target device can be started prior to control of the other update target devices.

[0021] According to one aspect of the present disclosure, check unit order information indicating a check unit order for performing new surface startup and version consistency checks on a group basis in a master device according to a predetermined check unit and a predetermined check order is registered or distributed to the master device. In the master device, the version consistency check of a specific update target device can be completed prior to the version consistency checks of other update target devices, and control of the specific update target device can be started prior to control of the other update target devices.

[0022] According to one aspect of the present disclosure, an external device registers or distributes to a master device update unit order information indicating an update unit order for a master device to perform installation, activation, new version startup, and version consistency checks on a group basis in a predetermined update unit and in a predetermined update order. The master device identifies group units based on the update unit order information acquired from the external device, divides multiple update target devices into multiple groups according to the identified group units, and performs installation, activation, new version startup, and version consistency checks on a group basis in a predetermined update unit and in a predetermined update order. The master device can complete a version consistency check for a specific update target device before version consistency checks for other update target devices, and can start control of a specific update target device before control of the other update target devices.

[0023] According to one aspect of the present disclosure, an external device registers or distributes to the master device check unit order information indicating a check unit order for a master device to perform new surface startup and version consistency checks on a group basis in accordance with a predetermined check unit and a predetermined check order. The master device identifies group units based on the check unit order information acquired from the external device, divides multiple update target devices into multiple groups according to the identified group units, and performs new surface startup and version consistency checks on a group basis in accordance with the predetermined check unit and a predetermined check order. The master device can complete a version consistency check for a specific update target device prior to version consistency checks for other update target devices, and can start control of a specific update target device prior to control of the other update target devices.

[0024] 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 a first embodiment, Fig. 2 is a functional block diagram of a ReproMaster, Fig. 3 is a diagram showing pre- and post-update version information, Fig. 4 is a diagram showing update unit sequence information, Fig. 5 is a diagram showing an ASSY unit, Fig. 6 is a flowchart, Fig. 7 is a flowchart, Fig. 8 is a diagram showing a comparative processing flow, Fig. 9 is a diagram showing a processing flow, Fig. 10 is a diagram showing check unit sequence information showing a second embodiment, Fig. 11 is a flowchart, Fig. 12 is a flowchart, Fig. 13 is a flowchart, and Fig. 14 is a diagram showing a processing flow.

[0025] Hereinafter, several embodiments will be described with reference to the drawings. In the subsequent embodiments, the same parts as in the preceding embodiments will not be described. (First Embodiment)

[0026] A first embodiment will be described with reference to Figures 1 to 9. As shown in Figure 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.

[0027] 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).

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

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

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

[0031] 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).

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

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

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

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

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

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

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

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

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

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

[0042] The power control application 22 arranged in the second repeater 7 cooperates with the power control function unit 19 of the OTA master 14 as described above, and controls the power supply to the DCM 4, the in-vehicle HMI 10, the repeaters 6 to 8, and the ECUs 25 to 31 as the software update progresses. That is, the OTA master 14 cooperates the power control function unit 19 with the power control application 22, and controls the power supply to the repeaters 6 to 8 and the ECUs 25 to 31 that are capable of diagnostic communication via the diagnostic communication function unit 24.

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

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

[0045] A series of process phases related to software updates include a configuration synchronization phase, a download phase, an installation phase, an activation phase, a new startup phase, and a version consistency check 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.

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

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

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

[0049] The new activation phase is a phase in which the activated software is activated in the target ECU. That is, in the new activation phase, the OTA master 14 performs new activation, which activates the activated software in the target ECU. The version consistency check phase is a phase in which the consistency of the version of the activated software is checked. That is, in the version consistency check phase, the OTA master 14 performs a version consistency check to check the consistency of the software version. The software that is the target of the version consistency check includes the activated software. The update completion notification phase is a phase in which the OTA master 14 transmits the update completion notification to the OTA center 2 when it receives an update completion notification from the target ECU upon completion of activation.

[0050] The OEM, which is one of the organizations providing the OTA service, considers the update unit and update order for the OTA master 14 to perform software update processes such as installation, activation, new boot, and version consistency checks on an ASSY basis, and creates the results of this consideration as an update unit order list. An ASSY unit is, for example, a unit of multiple ECUs connected to the same repeater, or a unit of multiple ECUs that perform control in cooperation with each other, and corresponds to a group unit. An ASSY unit is a unit that does not cause an event that threatens safety and security, such as a domain controller unit for each function, or a unit that does not further subdivide ECUs that are subject to RxSWIN (Rx Software Identification Number) management as a legal requirement. The entire vehicle can also be considered a single ASSY.

[0051] For example, when the OTA center 2 receives an update unit order list from an OEM, the OTA center 2 analyzes the provided update unit order list and registers campaign information for the OTA master 14 to perform software update processing on an assembly-by-assembly basis. The campaign information includes pre- and post-update version information shown in FIG. 3 and update unit order information shown in FIG. 4. The pre- and post-update version information is information that can identify the software versions of each relay and each ECU before the software update and the software versions of each relay and each ECU after the update. The update unit order information is information that can identify the update unit and update order of each relay and each ECU. When it is time to distribute the campaign information, the OTA center 2 distributes the registered campaign information to the vehicle.

[0052] When the OTA master 14 receives the campaign information distributed from the OTA center 2, the OTA master 14 acquires pre- and post-update version information and update unit sequence information from the received campaign information, and identifies the update unit and the update sequence. For example, when the update unit sequence information is defined as shown in Fig. 4, the OTA master 14 identifies, as update units, an ASSY unit including the first relay, the first ECU, and the second ECU as sub-ASSY (A), an ASSY unit including the second relay, the third ECU, and the fourth ECU as sub-ASSY (B), an ASSY unit including the third relay and the fifth ECU as sub-ASSY (C), and an ASSY unit including the fourth ECU and the fifth ECU as sub-ASSY (D), as shown in Fig. 5. The OTA master 14 identifies the sub-ASSY (A) as the first update order, the sub-ASSY (B), the sub-ASSY (C) and the sub-ASSY (D) as the second update order, the chargeable related ECU as the third update order, and itself as the fourth update order.

[0053] Next, the operation of the above-described configuration will be described with reference to FIGS. 6 to 9. Here, the campaign information distribution process performed by the OTA center 2 and the software update process performed by the OTA master 14 will be described. The following describes an example in which software downloads are performed sequentially for each update unit, but software downloads may also be performed all at once at the beginning regardless of the update unit. In other words, if the specifications are such that control of a specific repeater or ECU begins earlier than control of another repeater or ECU, software downloads may be performed sequentially for each update unit. If the specifications are not as described above, software downloads may also be performed all at once at the beginning regardless of the update unit.

[0054] (1-1) Campaign Information Distribution Process (See FIG. 6) The OTA center 2 starts the campaign information distribution process when it receives an update unit order list from, for example, an OEM. When the OTA center 2 starts the campaign information distribution process, it analyzes the provided update unit order list (A1) and registers campaign information for the OTA master 14 to perform software update processing on an ASSY basis (A2). Analysis of the update unit order list can be done manually or automatically. When it is time to distribute the campaign information, the OTA center 2 distributes the registered campaign information to the vehicle (A3), and ends the campaign information distribution process.

[0055] (1-2) Software Update Process (See FIG. 7) When the OTA master 14 receives campaign information distributed from the OTA center 2, it starts the software update process. When the OTA master 14 starts the software update process, it synchronizes the configuration information (B1). After completing the configuration information synchronization, the OTA master 14 acquires pre- and post-update version information and update unit order information from the campaign information, and identifies the update unit and update order (B2). For the repeater or ECU that belongs to the first update unit in the update order, the OTA master 14 downloads software (B3), installs the software (B4), activates the software (B5), and performs a new boot using the activated software (B6). After completing the new boot, the OTA master 14 performs an individual version consistency check for the update unit that has completed the new boot (B7).

[0056] Specifically, when the OTA master 14 completes the new version boot, it collects version information indicating the software versions to be executed at boot from all ECUs included in the update unit for which the new version boot has been completed. The OTA master 14 determines whether the collected version information is consistent with the updated version information included in the campaign information, and performs individual version consistency checks. If the OTA master 14 determines that the collected version information is consistent with the updated version information included in the campaign information, it determines that the check result of the individual version consistency check is positive. If the OTA master 14 determines that the collected version information is inconsistent with the updated version information included in the campaign information, it determines that the check result of the individual version consistency check is negative.

[0057] The update units that are the subject of individual version consistency checks include relays and ECUs that are subject to software updates and relays and ECUs that are not subject to software updates. Relays and ECUs that are subject to software updates are ECUs to which software is downloaded, installed, and activated. Relays and ECUs that are not subject to software updates are ECUs to which software is not downloaded, installed, or activated. Whether or not a software update is required is determined by software version information before and after the update. In the example shown in FIG. 3 above, the first relay and the first ECU are subject to software updates, while the second ECU is not subject to software updates. However, because the first relay, the first ECU, and the second ECU are included in the same sub-ASSY (A) of the same ASSY unit, the first relay, the first ECU, and the second ECU are all subject to individual version consistency checks of the sub-ASSY (A).

[0058] The OTA master 14 determines the results of the individual version consistency checks (B8), and if the results are positive and the version consistency checks are determined to be successful (B8: YES), it starts controlling the relays and ECUs that belong to the update units for which the version consistency checks were successful (B9). Specifically, the OTA master 14 starts controlling the relays and ECUs that belong to the update units for which the version consistency checks were successful by sending a control start instruction to the relays and ECUs that belong to the update units for which the version consistency checks were successful. The targets for which control is started include relays and ECUs that are subject to software updates and relays and ECUs that are not subject to software updates.

[0059] In the present embodiment, the OTA master 14 sends a control start instruction to a relay or ECU belonging to an update unit for which the version consistency check was successful. However, the relay or ECU may determine whether to start control based on, for example, status information indicating OTA completion transmitted from the OTA master 14 via control communication with the OTA master 14, and may start control if it determines that control should be started. That is, when the OTA master 14 determines that an individual version consistency check was successful, the OTA master 14 places the relay or ECU belonging to the update unit for which the version consistency check was successful in a state in which control can be started. The OTA master 14 may initiate control of the relay or ECU belonging to the update unit for which the version consistency check was successful, or may wait for the relay or ECU to initiate control.

[0060] The OTA master 14 determines whether or not there is an unupdated update unit (B10), and if it determines that there is an unupdated update unit (B10: YES), it returns to step B3, determines the update unit with the next highest update order, and repeats step B3 and subsequent steps for the repeater or ECU that belongs to the determined update unit with the next highest update order.

[0061] 4 and 5, the OTA master 14 performs an individual version consistency check on the sub-ASSY (A) as the first update unit in the update order, and if the check result of the sub-ASSY (A) is positive, the OTA master 14 can start control of the first relay, the first ECU, and the second ECU belonging to the sub-ASSY (A) prior to control of the other relays and ECUs. In other words, after starting control of the first relay, the first ECU, and the second ECU belonging to the sub-ASSY (A), the OTA master 14 performs software download and subsequent processes on the relays and ECUs belonging to the sub-ASSY (B), the sub-ASSY (C), and the sub-ASSY (D) as the second update unit in the update order.

[0062] On the other hand, when the check result of an individual version consistency check is negative and the OTA master 14 identifies a failure of the version consistency check (B8: NO), it performs a rollback (B11) and restores the update unit for which the version consistency check failure was identified, as well as the update unit for which the new plane startup has been completed and the version consistency check has been identified as successful, to the state before the software update, and terminates the software update process. For example, when the OTA master 14 identifies a failure of the version consistency check for the second update unit in the update order, it restores the first update unit in the update order for which the new plane startup has been completed and the version consistency check has been identified as successful, and the second update unit in the update order for which the new plane startup has been completed and the version consistency check failure has been identified, to the state before the software update.

[0063] If the OTA master 14 determines that there are no unupdated update units (B10: NO), it performs an overall version consistency check (B12). Specifically, the OTA master 14 determines that the targets of the overall version consistency check are all ECUs newly activated by looping through steps B3 to B10, and further includes ECUs belonging to each update unit that are not the targets of installation or activation. The targets of the overall version consistency check may also include ECUs that do not belong to any update unit. For example, the OTA master 14 determines that all ECUs whose versions are indicated in the version information included in the campaign information (see FIG. 3) are the ECUs to be checked in the overall version consistency check, regardless of whether they belong to any update unit indicated in the update unit order information included in the campaign information (see FIG. 4).

[0064] The ECUs whose versions are indicated in the version information included in the campaign information may also include ECUs that do not belong to any update unit. The targets of the overall version consistency check include all ECUs newly started by looping through steps B3 to B10, as well as ECUs belonging to each update unit that are not subject to installation or activation. This could be considered a predetermined group of ECUs indicated in the campaign information. For example, in a campaign in which the unit including the first relay 6, ECU 25, and ECU 26 is subject to update, and the unit including the second relay 7, ECU 27, and ECU 28 is also subject to update, but none of the third relay 8, ECU 29, and ECU 30 is subject to update, the third relay 8, ECU 29, and ECU 30 may also be included in the targets of the overall version consistency check.

[0065] The OTA master 14 collects version information indicating the version of software executed at startup from all ECUs to be checked in the overall version consistency check. The OTA master 14 determines whether the collected version information is consistent with the updated version information included in the campaign information, and performs the overall version consistency check. If the OTA master 14 determines that the collected version information is consistent with the updated version information included in the campaign information, it determines that the check result of the overall version consistency check is positive. If it determines that the collected version information is not consistent, it determines that the check result of the overall version consistency check is negative.

[0066] The OTA master 14 determines the check result of the overall version consistency check (B13), and if the check result of the overall version consistency check is positive and the version consistency check is determined to be successful (B13: YES), the OTA master 14 ends the software update process.

[0067] On the other hand, if the OTA master 14 determines that the overall version consistency check has failed (B13: NO), it also performs a rollback (B11) and loops through steps B3 to B10 to restore all update units that have completed new startup to the state before the software update, thereby terminating the software update process.

[0068] 8, for example, assume that the target ECUs are the first ECU, the second ECU, the third ECU, the fourth ECU, and the fifth ECU, and that the time required for downloading and installing software for each is 10 minutes, the time required for activating and restarting the software for the first and second ECUs is 1 minute, the time required for activating and restarting the software for the third and fourth ECUs is 2 minutes, and the time required for activating and restarting the software for the fifth ECU is 5 minutes. In a conventional method, the software downloads and installations for the first through fifth ECUs are performed serially, and the software activations for the first through fifth ECUs are simultaneously started and performed in parallel, which would require 55 minutes from the start of software download to the start of control for the first and second ECUs.

[0069] On the other hand, when performing the software update process shown in Fig. 7, if the software is downloaded and installed in the first ECU and the second ECU in series, the software is activated and restarted in the first ECU and the second ECU, and individual version checks are performed, it takes only 21 minutes from the start of software download to the start of control for the first ECU and the second ECU, as shown in Fig. 9. In other words, the control of the first ECU and the second ECU can be started prior to the control of the third ECU, the fourth ECU, and the fifth ECU.

[0070] While the above example illustrates a case where software downloads and installations are performed repeatedly on an ECU-by-ECU basis, the same applies to a case where software is downloaded in a batch and only software installations are performed repeatedly on an ECU-by-ECU basis. For example, the campaign information may include a flag that identifies whether to adopt a conventional method that does not perform individual version checks or the method that performs individual version checks shown in FIG. 7 . By determining the flag, the OTA master 14 selects either a conventional method that does not perform individual version checks or the method that performs individual version checks shown in FIG. 7 and performs the software update. Alternatively, the user may be able to select either a conventional method that does not perform individual version checks or the method that performs individual version checks shown in FIG. 7 .

[0071] As described above, the first embodiment provides the following advantageous effects. The OTA master 14 performs installation, activation, new startup, and version consistency checks on a sub-ASSY basis. A version consistency check for a specific repeater or ECU can be completed before a version consistency check for other repeaters or ECUs, and control of a specific repeater or ECU can be started before control of other repeaters or ECUs.

[0072] Second Embodiment A second embodiment will be described with reference to Fig. 10 to Fig. 14. In the first embodiment, downloading, installation, activation, new version startup, and version consistency check are performed on a group basis in an update unit order, whereas in the second embodiment, new version startup and version consistency check are performed on a group basis in a check unit order.

[0073] The campaign information includes the check unit sequence information shown in Fig. 10. When the OTA master 14 receives the campaign information distributed from the OTA center 2, it acquires the pre- and post-update version information and the check unit sequence information from the received campaign information, and specifies the check unit and the check sequence.

[0074] (2-1) Campaign Information Distribution Process (See FIG. 11) The OTA center 2 starts the campaign information distribution process when it receives a check unit sequence list, for example, from an OEM. When the OTA center 2 starts the campaign information distribution process, it analyzes the provided check unit sequence list (A1) and registers campaign information for the OTA master 14 to perform software update processing on an ASSY basis (A12). Analysis of the check unit sequence list can be done manually or automatically. When it is time to distribute the campaign information, the OTA center 2 distributes the registered campaign information to the vehicle (A13) and ends the campaign information distribution process.

[0075] (2-2) Software Update Processing (See FIGS. 12 and 13) The OTA master 14 starts the software update processing when it receives campaign information distributed from the OTA center 2. When the OTA master 14 starts the software update processing, it synchronizes the configuration information (B21). When the configuration information synchronization is completed, the OTA master 14 acquires pre- and post-update version information and check unit sequence information from the campaign information, and specifies the check unit and check sequence (B22).

[0076] The OTA master 14 downloads the software (B23), installs the software (B24), activates the software (B25), and determines whether there is an update target that has not yet been activated (B26). If the OTA master 14 determines that there is an update target that has not yet been activated (B26: YES), the OTA master 14 returns to step B23 and repeats step B23 and subsequent steps.

[0077] If the OTA master 14 determines that there are no update targets for which activation has not been completed (B26: NO), it performs a new version activation using the activated software (B27). When the OTA master 14 completes the new version activation, it performs an individual version consistency check for the update unit for which activation has been completed (B28).

[0078] The OTA master 14 determines the results of each individual version consistency check (B29). If the result of each individual version consistency check is positive and the version consistency check is successful (B29: YES), the OTA master 14 starts control of the repeaters and ECUs belonging to the update unit for which the version consistency check was successful (B30). The OTA master 14 determines whether there are any unchecked check units (B31). If the OTA master 14 determines that there are any unchecked check units (B31: YES), the OTA master 14 returns to step B27 and repeats step B27 and subsequent steps.

[0079] On the other hand, if the OTA master 14 determines that the individual version consistency checks have failed (B29: NO), it performs a rollback (B32), restores the software to the state before the update, including the update unit that has completed the new startup, and terminates the software update process.

[0080] If the OTA master 14 determines that there are no unchecked check units (B31: NO), it performs an overall version consistency check (B33). The OTA master 14 determines the check result of the overall version consistency check (B34), and if the check result of the overall version consistency check is positive and it determines that the version consistency check has been successful (B34: YES), it ends the software update process.

[0081] On the other hand, if the OTA master 14 determines that the overall version consistency check has failed (B34 NO), it also performs a rollback (B32) and restores the state to the state before the software update, including the update unit that has completed new startup, and terminates the software update process.

[0082] 12 and 13, if the software is downloaded and installed in the first through fifth ECUs in series, the software is activated and restarted in the first and second ECUs, and individual version checks are performed, it takes only 51 minutes from the start of software download to the start of control for the first and second ECUs, as shown in Fig. 14. That is, in this case too, control of the first and second ECUs can be started prior to control of the third, fourth, and fifth ECUs.

[0083] As described above, the second embodiment provides the following advantageous effects. The OTA master 14 performs new startup and version consistency checks on a sub-ASSY basis. As in the first embodiment, the version consistency check for a specific repeater or ECU can be completed before the version consistency checks for other repeaters or ECUs, and control of a specific repeater or ECU can be started before control of other repeaters or ECUs.

[0084] In addition to the claims, the present disclosure also includes the following: [1] A master device (14) that, as a process related to a software update, sequentially performs the following steps in order to install software in an update target device that is the target of the software update, activate the installed software, start up the new version using the activated software, and check version consistency, thereby putting the update target device into a state where it can start control, wherein, when there are multiple update target devices, the master device divides the multiple update target devices into multiple groups and performs the installation, activation, start up the new version, and check version consistency on a group basis in a predetermined update unit and in a predetermined update order.

[0085] [2] The master device according to [1], which identifies the predetermined update unit and the predetermined update order based on update unit order information acquired from an external device, and divides the plurality of update target devices into a plurality of groups.

[0086] [3] A master device according to [1] or [2], which, when there are multiple update target devices, divides the multiple update target devices into multiple groups and determines, before starting a software update, whether to perform the installation, activation, new startup, and version consistency check on a group basis in a predetermined update unit and in a predetermined update order.

[0087] [4] A master device (14) that, as part of software update processing, sequentially performs the following steps to install software on an update target device that is the target of software update, activate the installed software, perform a new version boot using the activated software, and check version consistency, thereby bringing the update target device into a state where it can begin control; if there are multiple update target devices, the master device divides the multiple update target devices into multiple groups and performs the new version boot and version consistency check on a group-by-group basis using a specified check unit and a specified check order.

[0088] [5] The master device according to [4], which identifies the predetermined check unit and the predetermined check order based on check unit order information acquired from an external device, and divides the plurality of update target devices into a plurality of groups.

[0089] [6] A master device according to [4] or [5], which, when there are multiple update target devices, divides the multiple update target devices into multiple groups and determines, before starting the software update, whether to perform the new surface startup and the version consistency check on a group basis using a specified check unit and a specified check order.

[0090] [7] The master device according to any one of [1] to [6], wherein the plurality of groups are groups in which no events that threaten safety occur.

[0091] [8] A master device according to any one of [1] to [7], wherein, when a version consistency check of any group is found to have failed, the master device returns all groups, including those that have completed the new startup, to the state before the software update.

[0092] [9] A master device according to any one of [1] to [8], wherein, upon completion of the individual version consistency checks for all groups, the master device performs the overall version consistency check for all update target devices.

[0093]

[10] The master device according to [9], wherein when a consistency failure is identified in the overall version consistency check, all groups are restored to the state before the software update.

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

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

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

Claims

1. A master device (14) that, as part of software update processing, sequentially performs the following steps to bring an update target device into a state where it can begin control: installing software on the update target device, activating the installed software, booting up the device using the activated software, and checking version consistency; and, if there are multiple update target devices, the master device divides the multiple update target devices into multiple groups and performs the installation, activation, booting up the device using the activated software, and checking version consistency on a group-by-group basis in a predetermined update unit and in a predetermined update order.

2. The master device according to claim 1, wherein the predetermined update unit and the predetermined update sequence are identified based on update unit sequence information acquired from an external device, and the plurality of update target devices are divided into a plurality of groups.

3. A master device as described in claim 1, which, when there are multiple update target devices, divides the multiple update target devices into multiple groups and determines, before starting the software update, whether to perform the installation, activation, new startup, and version consistency check on a group basis in a specified update unit and in a specified update order.

4. A master device (14) that, as part of software update processing, sequentially performs the following steps to bring the update target device into a state where it can begin control: installing software on the update target device that is the target of the software update, activating the installed software, booting up the device using the activated software, and checking version consistency. When there are multiple update target devices, the master device divides the multiple update target devices into multiple groups and performs the booting up the device using the new version and the version consistency check on a group-by-group basis using a specified check unit and in a specified check order.

5. The master device according to claim 4, wherein the predetermined check unit and the predetermined check order are identified based on check unit order information acquired from an external device, and the plurality of update target devices are divided into a plurality of groups.

6. A master device as described in claim 4, which, when there are multiple update target devices, divides the multiple update target devices into multiple groups and determines, before starting the software update, whether to perform the new surface startup and the version consistency check on a group basis using a specified check unit and a specified check order.

7. The master device according to claim 1 or 4, wherein the plurality of groups are groups in which no events that threaten safety occur.

8. The master device according to claim 1 or 4, wherein when a version consistency check failure is identified for any group, the master device returns all groups, including the group that has completed the new startup, to the state before the software update.

9. The master device according to claim 1 or 4, wherein, when the version consistency check for each group is completed for all groups, the master device performs the version consistency check for all update target devices as a whole.

10. The master device according to claim 9, wherein when a consistency failure is identified in the overall version consistency check, the master device returns all groups to the state before the software update.

11. An external device (2) that distributes campaign information regarding software update processing to a master device that brings the update target device into a state where it can start controlling the update target device by sequentially installing software on the update target device that is the target of the software update, activating the installed software, booting up the new version using the activated software, and checking version consistency, and registers or distributes to the master device update unit sequence information that indicates an update unit sequence for performing the installation, activation, booting up the new version, and version consistency check on a group basis in the master device according to a specified update unit and a specified update sequence.

12. An external device as described in claim 11, which distributes to the master device determination information for the master device to determine whether or not the installation, activation, new surface startup and version consistency check should be performed on a group basis in a specified update unit and in a specified update order.

13. An external device (2) that distributes campaign information regarding software update processing to a master device that brings the update target device into a state where it can start controlling by sequentially installing software on the update target device that is the target of the software update, activating the installed software, booting up the new version using the activated software, and checking version consistency, and that registers or distributes to the master device check unit sequence information that indicates a check unit sequence for the booting up the new version and the version consistency check to be performed on a group basis in the master device using a specified check unit and a specified check sequence.

14. An external device according to claim 13, which distributes to the master device determination information for the master device to determine whether or not the new surface startup and the version consistency check should be performed on a group basis in a predetermined check unit and in a predetermined check order.

15. A data communication system (1) comprising: a master device (14) that performs software update processing by sequentially installing software on an update target device that is the target of the software update, activating the installed software, booting up to the new version using the activated software, and checking version consistency, thereby putting the update target device into a state where it can start being controlled; and an external device (2) that distributes campaign information regarding software update processing to the master device, wherein the external device registers or distributes to the master device update unit sequence information indicating an update unit sequence for the installation, activation, booting up to the new version, and version consistency check to be performed by the master device on a group basis in a predetermined update unit and in a predetermined update order; and the master device identifies the group unit based on the update unit sequence information acquired from the external device, divides a plurality of update target devices into a plurality of groups according to the identified group unit, and performs the installation, activation, booting up to the new version, and version consistency check on a group basis in a predetermined update unit and in a predetermined update order.

16. A data communication system (1) comprising a master device (14) that performs software update processing by sequentially installing software on an update target device that is the target of the software update, activating the installed software, booting up the device to a new version using the activated software, and checking version consistency, thereby putting the update target device into a state where it can start being controlled, and an external device (2) that distributes campaign information regarding software update processing to the master device, wherein the external device registers or distributes to the master device check unit sequence information indicating a check unit sequence for the new version startup and version consistency check to be performed on a group basis in the master device using a predetermined check unit and a predetermined check order, and the master device identifies the group unit based on the check unit sequence information acquired from the external device, divides a plurality of update target devices into a plurality of groups according to the identified group units, and performs the new version startup and version consistency check on a group basis using a predetermined check unit and a predetermined check order.

17. A software update method in which a master device (14) performs software update processing by sequentially installing software on an update target device that is the target of the software update, activating the installed software, booting up the device using the activated software, and checking version consistency, thereby putting the update target device into a state where it can begin control, and when there are multiple update target devices, dividing the multiple update target devices into multiple groups and performing the installation, activation, booting up the device using the activated software, and checking version consistency on a group basis in a predetermined update unit and in a predetermined update order.

18. A software update method in which a master device (14) performs software update processing by sequentially installing software on an update target device that is the target of the software update, activating the installed software, booting up the device using the activated software, and checking version consistency, thereby putting the update target device into a state where it can start controlling the update target device, and when there are multiple update target devices, dividing the multiple update target devices into multiple groups and performing the booting up the device using the new version and the version consistency check on a group basis in a specified check unit and in a specified check order.

19. A software update program that, as part of software update processing, causes a master device (14) to bring the update target device into a state where it can begin control by sequentially installing software on the update target device that is the target of the software update, activating the installed software, booting up the device using the activated software, and checking version consistency, and, if there are multiple update target devices, divides the multiple update target devices into multiple groups and executes a check procedure in which the installation, activation, booting up the device using the activated software, and checking version consistency are performed on a group-by-group basis in a predetermined update unit and in a predetermined update order.

20. A software update program that, as part of the software update process, installs software on the update target device, activates the installed software, launches the activated software, and checks for version consistency, sequentially, to bring the update target device into a state where it can begin control. If there are multiple update target devices, the program divides the multiple update target devices into multiple groups and executes a check procedure in which the launches the new version and checks for version consistency are performed on a group-by-group basis in a specified check unit and in a specified check order.

Images