In-vehicle device, program, and program update method

Abstract

To provide an on-vehicle device and the like that efficiently perform operation check on the on-vehicle ECU to which a program is applied when performing processing to update the program of the on-vehicle ECU.SOLUTION: There is provided an on-vehicle device which acquires an update program transmitted from an external server outside a vehicle and performs processing to update a program of an on-vehicle ECU installed in the vehicle and includes a control unit which performs processing related to the update program. When acquiring the update program, the control unit: acquires an operation check scenario to perform operation check on the on-vehicle ECU being the update target from the external server; outputs the acquired update program and operation check scenario to the on-vehicle ECU being the update target; performs processing related to the operation check on the on-vehicle ECU being the update target on the basis of the operation check scenario; and performs processing related to the operation check on the on-vehicle ECU being the update target by substituting the other on-vehicle ECU other than the on-vehicle ECU being the update target.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to an in-vehicle device, a program, and a method for updating the program.

Background Art

[0002] Vehicles are equipped with an ECU (Electronic Control Unit) for controlling in-vehicle devices such as a drive control system for engine control and a body system for air conditioner control. The ECU includes an arithmetic processing unit such as an MPU, a rewritable non-volatile storage unit such as a RAM, and a communication unit for communicating with other ECUs, and controls the in-vehicle devices by reading and executing a control program stored in the storage unit. Furthermore, a communication device having a wireless communication function is mounted on the vehicle, and communicates with a program providing device connected to an external network via the communication device, and can download (receive) the control program of the ECU from the program providing device and update the control program of the ECU (see, for example, Patent Document 1).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, the communication device (relay device) of Patent Document 1 has a problem in that it does not consider the operation check when applying the downloaded control program to the ECU to be updated.

[0005] An object of the present disclosure is to provide an in-vehicle device or the like that can efficiently perform an operation check on an in-vehicle ECU to which a program has been applied when performing a process of updating the program of the in-vehicle ECU. [Means for solving the problem]

[0006] An in-vehicle device according to one aspect of the present disclosure is an in-vehicle device that acquires an update program transmitted from an external server outside the vehicle and performs processing for updating the program of an in-vehicle ECU installed in the vehicle, and comprises a control unit that performs processing related to the update program, wherein when acquiring the update program, the control unit acquires an operation verification scenario for performing operation verification on the in-vehicle ECU to be updated from the external server, outputs the acquired update program and the operation verification scenario to the in-vehicle ECU to be updated, performs processing related to operation verification on the in-vehicle ECU to be updated based on the operation verification scenario, and performs processing related to operation verification on the in-vehicle ECU to be updated by substituting another in-vehicle ECU other than the in-vehicle ECU to be updated based on the operation verification scenario. [Effects of the Invention]

[0007] According to one aspect of this disclosure, it is possible to provide an in-vehicle device, etc., that efficiently performs operational verification of an in-vehicle ECU to which a program has been applied when performing a process to update the program of the in-vehicle ECU. [Brief explanation of the drawing]

[0008] [Figure 1] This is a schematic diagram illustrating the configuration of an in-vehicle update system including an in-vehicle device according to Embodiment 1. [Figure 2] Figure 2 is a block diagram illustrating the physical configuration of an in-vehicle device. [Figure 3] This is an explanatory diagram illustrating the processing flow (sequence) by in-vehicle devices and the in-vehicle ECUs to be updated. [Figure 4] This is a flowchart illustrating the processing steps of the control unit of an in-vehicle device. [Figure 5] This is a flowchart illustrating the processing of the control unit of the in-vehicle device according to Embodiment 2. [Modes for carrying out the invention]

[0009] [Description of Embodiments in this Disclosure] First, embodiments of this disclosure will be listed and described. Furthermore, at least some of the embodiments described below may be combined in any way.

[0010] (1) An in-vehicle device according to one aspect of the present disclosure is an in-vehicle device that acquires an update program transmitted from an external server outside the vehicle and performs processing for updating the program of an in-vehicle ECU installed in the vehicle, and comprises a control unit that performs processing related to the update program, wherein when acquiring the update program, the control unit acquires an operation verification scenario for performing operation verification on the in-vehicle ECU to be updated from the external server, outputs the acquired update program and the operation verification scenario to the in-vehicle ECU to be updated, and performs processing related to operation verification on the in-vehicle ECU to be updated based on the operation verification scenario.

[0011] In this embodiment, the in-vehicle device (control unit) outputs an update program and an operation verification scenario to the in-vehicle ECU to be updated, and performs operation verification processing for the in-vehicle ECU to be updated based on the operation verification scenario. The operation verification scenario lists the execution procedures, such as processing sequences, scripts, or commands, that the in-vehicle device will perform for operation verification on the in-vehicle ECU to be updated. The in-vehicle ECU (in-vehicle ECU to be updated) that has obtained the update program and operation verification scenario from the in-vehicle device applies the obtained update program, and then performs operation verification processing for its own ECU based on the operation verification scenario obtained together with the update program. As a result, the in-vehicle ECU to be updated and the in-vehicle device perform operation verification of the in-vehicle ECU (in-vehicle ECU to be updated) to which the update program has been applied based on the same operation verification scenario, and operation verification in the actual environment of the vehicle in which these in-vehicle ECUs and in-vehicle devices are installed can be performed efficiently.

[0012] (2) In an in-vehicle device according to one aspect of the present disclosure, the control unit performs operation verification processing for the in-vehicle ECU to be updated by substituting another in-vehicle ECU other than the in-vehicle ECU to be updated based on the operation verification scenario.

[0013] In this embodiment, the in-vehicle device performs operational verification processing for the in-vehicle ECU to be updated by substituting other in-vehicle ECUs other than the in-vehicle ECU to be updated, thereby enabling efficient operational verification in accordance with the actual vehicle environment.

[0014] (3) An in-vehicle device according to one aspect of the present disclosure, wherein the operation verification scenario includes a processing sequence in which the control unit that replaces the other in-vehicle ECU transmits data to the in-vehicle ECU to be updated, and a processing sequence in which the in-vehicle ECU to be updated to which the update program has been applied transmits data to the other in-vehicle ECU that has been replaced by the control unit.

[0015] In this embodiment, the operation verification scenario includes a defined processing sequence for data transmission and reception between an in-vehicle device that replaces another in-vehicle ECU and the in-vehicle ECU to which the update program has been applied (the in-vehicle ECU to be updated), thus enabling efficient operation verification in accordance with the actual vehicle environment. Specifically, the in-vehicle ECU to which the update program has been applied attempts to send and receive data with another in-vehicle ECU based on the operation verification scenario, but this data transmission and reception is performed by the in-vehicle device that replaces the other in-vehicle ECU. As a result, while the in-vehicle ECU to which the update program has been applied performs operation verification in accordance with the actual operation (actual vehicle environment) in the vehicle, in reality, the in-vehicle device that replaces the other in-vehicle ECU is the one that responds based on the operation verification scenario. Therefore, by performing this operation verification, the operation verification of the in-vehicle ECU to which the update program has been applied can be efficiently performed without affecting the control of the vehicle itself.

[0016] (4) The in-vehicle device according to one aspect of the present disclosure is such that the operation confirmation scenario includes determination information for determining the result of the operation confirmation for the in-vehicle ECU to be updated, and the control unit performs processing related to the operation confirmation for the in-vehicle ECU to be updated, thereby obtaining the result of the operation confirmation, and determines the success or failure of the program update in the in-vehicle ECU to be updated based on the obtained result of the operation confirmation and the determination information included in the operation confirmation scenario.

[0017] In this aspect, the operation confirmation scenario includes determination information for determining the result of the operation confirmation for the in-vehicle ECU to be updated. The determination information includes, for example, the types of data assumed to be transmitted from the in-vehicle ECU to be updated, the transmission cycle, the assumed usage rate of the CPU or memory of the in-vehicle ECU, and the assumed values of the response responses when data for operation confirmation is transmitted from the in-vehicle device. The in-vehicle device (control unit) can efficiently determine whether the program update in the in-vehicle ECU to be updated has succeeded (success or failure) by comparing the determination information included in the operation confirmation scenario with various values included in the result of the operation confirmation.

[0018] (5) The in-vehicle device according to one aspect of the present disclosure is such that the control unit obtains the result of the self-diagnosis performed by the in-vehicle ECU to be updated based on the operation confirmation scenario from the in-vehicle ECU to be updated, and determines the success or failure of the program update in the in-vehicle ECU to be updated based on the obtained result of the self-diagnosis.

[0019] In this aspect, the in-vehicle ECU performs self-diagnosis processing in its own ECU based on the confirmation scenario obtained from the in-vehicle device. The self-diagnosis processing is a diagnosis process that does not communicate with other in-vehicle ECUs such as the in-vehicle device and corresponds to a self-diagnosis. The in-vehicle device obtains the result of the self-diagnosis from the in-vehicle ECU to be updated, and based on the result of the self-diagnosis, can efficiently determine whether the program update in the in-vehicle ECU to be updated has succeeded (success or failure) in order to determine the success or failure of the program update in the in-vehicle ECU to be updated.

[0020] (6) The in-vehicle device according to one aspect of the present disclosure, when the control unit performs relay processing of communication between a plurality of in-vehicle ECUs mounted on the vehicle, uses the relay log collected at that time to complement the operation confirmation scenario acquired from the external server, outputs the acquired update program and the complemented operation confirmation scenario to the in-vehicle ECU to be updated, and based on the complemented operation confirmation scenario, performs processing related to operation confirmation for the in-vehicle ECU to be updated.

[0021] In this aspect, the in-vehicle device functions as an in-vehicle relay device such as a gateway or Ethernet SW that performs relay processing of communication between a plurality of in-vehicle ECUs mounted on the vehicle. The in-vehicle device functioning as an in-vehicle relay device stores the relay log collected when performing relay processing in the storage unit. The relay log includes header information (source address, destination address, message ID, etc.), payload information, transmission / reception frequency or period, etc. of the Ethernet frame or CAN message that was the relay target. The in-vehicle device (control unit) can further adapt the operation confirmation scenario to the actual environment of the host vehicle by complementing, such as adding a note, to the operation confirmation scenario acquired from the external server using the relay log stored in the storage unit. By using the operation confirmation scenario (complemented operation confirmation scenario) with improved compatibility with the actual environment of the host vehicle, the accuracy of operation confirmation for the in-vehicle ECU to be updated can be improved.

[0022] (7) The in-vehicle device according to one aspect of the present disclosure, when the ignition switch of the vehicle is turned off, based on the operation confirmation scenario, performs processing related to operation confirmation for the in-vehicle ECU to be updated.

[0023] In this aspect, after the ignition switch of the vehicle is turned off, the in-vehicle device performs processing related to operation confirmation based on the operation confirmation scenario, so that it can perform processing related to operation confirmation without being affected by other in-vehicle ECUs that are only driven when the ignition switch is on, and without affecting those other in-vehicle ECUs.

[0024] (8) In an in-vehicle device according to one aspect of the present disclosure, the control unit outputs a sleep signal to other in-vehicle ECUs other than the in-vehicle ECU to be updated, to cause the other in-vehicle ECUs to transition to sleep mode, and after outputting the sleep signal, performs operation verification processing for the in-vehicle ECU to be updated based on the operation verification scenario.

[0025] In this embodiment, the in-vehicle device outputs a sleep signal to the other in-vehicle ECUs besides the one being updated, and then performs operation verification processing based on the operation verification scenario. As a result, the other in-vehicle ECUs transition to a sleep mode in which they do not perform data transmission and reception processing, and thus the operation verification processing can be performed without being affected by or influencing these other in-vehicle ECUs.

[0026] (9) A program according to one aspect of the present disclosure obtains an update program transmitted from an external server outside the vehicle, and causes a computer that performs processing to update the program of an in-vehicle ECU installed in the vehicle to obtain an operation verification scenario for performing operation verification on the in-vehicle ECU to be updated from the external server when obtaining the update program, outputs the obtained update program and the operation verification scenario to the in-vehicle ECU to be updated, and executes processing that performs operation verification on the in-vehicle ECU to be updated based on the operation verification scenario.

[0027] In this embodiment, the computer can function as an in-vehicle device that efficiently performs operational verification on the in-vehicle ECU to which the control program is applied when performing the process of updating the control program of the in-vehicle ECU.

[0028] (10) A method for updating a program according to one aspect of the present disclosure includes obtaining an update program transmitted from an external server outside the vehicle, and instructing a computer that performs processing for updating the program of an in-vehicle ECU installed in the vehicle to obtain an operation verification scenario for performing operation verification on the in-vehicle ECU to be updated from the external server when obtaining the update program, outputting the obtained update program and the operation verification scenario to the in-vehicle ECU to be updated, and executing processing that performs operation verification on the in-vehicle ECU to be updated based on the operation verification scenario.

[0029] In this embodiment, when performing the process of updating the control program of an in-vehicle ECU, it is possible to provide a program update method that efficiently performs operational verification on the in-vehicle ECU to which the control program is applied.

[0030] [Details of the Embodiments of the Invention] The present invention will be specifically described based on the drawings illustrating its embodiments. An in-vehicle device 2 according to an embodiment of this disclosure will be described below with reference to the drawings. However, the present invention is not limited to these examples and is intended to include all modifications within the meaning and scope equivalent to the claims as indicated by the claims.

[0031] (Embodiment 1) The embodiments will be described below with reference to the drawings. Figure 1 is a schematic diagram showing the configuration of the in-vehicle update system S according to Embodiment 1. Figure 2 is a block diagram showing the configuration of the in-vehicle device 2, etc. The in-vehicle update system S includes an external communication device 1 and an in-vehicle device 2 mounted on the vehicle C, and transmits packages (update programs, operation verification scenarios) obtained from a program provision device S1 connected via an external network N to the in-vehicle ECU 3 (Electronic Control Unit / in-vehicle control device) mounted on the vehicle C.

[0032] The program provider S1 is a computer such as a server connected to an external network N, such as the Internet or a public telephone network, and is equipped with a storage unit S11 such as RAM (Random Access Memory), ROM (Read Only Memory), or a hard disk, and corresponds to an external server outside the vehicle. The program provider S1 stores in its storage unit S11 a program or data for controlling the in-vehicle ECU 3, which was created by the manufacturer of the in-vehicle ECU 3. This program or data is transmitted to the vehicle C as an update program, as described below, and is used to update the program or data of the in-vehicle ECU 3 installed in the vehicle C. The program provider S1 (external server) configured in this way is also called an OTA (Over The Air) server. The in-vehicle ECU 3 installed in the vehicle can update (reprogram) the program it runs by obtaining the update program transmitted wirelessly from the program provider S1 and applying it as the program that executes the update program.

[0033] Hereafter, the program will be described as including program code containing control structures for processing by the in-vehicle ECU 3, and an external file containing data referenced when executing the program code. When the update program is sent, this program code and the external file containing the data are sent from the program provider S1 as, for example, an encrypted archive file. When the program provider S1 sends the update program, it generates a package containing the update program and sends the generated package to the vehicle C. The package includes, for example, package information (campaign information) which is information related to the program update, information about the in-vehicle ECU to be updated (target information), an update program to be applied to the in-vehicle ECU to be updated, and an operation verification scenario for verifying the operation when the update program is applied to the in-vehicle ECU.

[0034] Vehicle C is equipped with an external communication device 1, an in-vehicle device 2, a display device 5, and multiple in-vehicle ECUs 3 for controlling various in-vehicle devices. The external communication device 1 and the in-vehicle device 2 are connected via a harness such as a serial cable. The in-vehicle device 2 and the in-vehicle ECUs 3 are connected via an in-vehicle network 4 that supports communication protocols such as CAN (Control Area Network / registered trademark) or Ethernet (registered trademark).

[0035] The external communication device 1 includes an external communication unit (not shown) and an input / output I / F (not shown) (interface) for communicating with the in-vehicle device 2. The external communication unit is a communication device for wireless communication using mobile communication protocols such as 3G, LTE, 4G, 5G, and WiFi, and transmits and receives data with the program provider device S1 via an antenna 11 connected to the external communication unit. Communication between the external communication device 1 and the program provider device S1 is performed via an external network such as a public telephone network or the Internet.

[0036] The input / output interface (I / F) of the external communication device 1 is a communication interface for, for example, serial communication with the in-vehicle device 2. The external communication device 1 and the in-vehicle device 2 communicate with each other via a harness such as a serial cable connected between the input / output interfaces. In this embodiment, the external communication device 1 is a separate device from the in-vehicle device 2, and these devices are connected to enable communication via the input / output interface, etc., but this is not limited to this. The external communication device 1 may also be built into the in-vehicle device 2 as a component of the in-vehicle device 2.

[0037] The in-vehicle device 2 includes a control unit 20, a storage unit 21, and an in-vehicle communication unit 23. The in-vehicle device 2 is configured to receive update programs (packages) from the program provider device S1 via wireless communication from the external communication device 1, and to transmit these update programs to a predetermined in-vehicle ECU 3 (the in-vehicle ECU 3 to be updated) via the in-vehicle network 4. In other words, the in-vehicle device 2 functions as an OTA master (reprogram master) that controls program updates in the in-vehicle ECU 3 to be updated.

[0038] The on-board device 2 is a gateway (on-board relay device) that manages multiple buses (segments), such as the control system on-board ECU 3, the safety system on-board ECU 3, and the body system on-board ECU 3, and relays communication between these buses (segments) and on-board ECU 3. In other words, the on-board device 2 functions as a CAN gateway for relaying the CAN protocol and as a Layer 2 switch or Layer 3 switch for relaying the TCP / IP protocol. In addition to relaying communications, the on-board device 2 may also function as a PLB (Power LAN Box) that distributes and relays power output from a power supply device such as a secondary battery and supplies power to on-board devices such as actuators connected to itself. Alternatively, the on-board device 2 may be configured as a functional part of a body ECU that controls the entire vehicle C. Alternatively, the on-board device 2 may be configured as an integrated ECU that controls the overall vehicle, such as a central control unit such as a vehicle computer.

[0039] The control unit 20 is composed of a CPU (Central Processing Unit) or an MPU (Micro Processing Unit), and performs various control and calculation processes by reading and executing a control program P (program product) and data that have been pre-stored in the storage unit 21.

[0040] The storage unit 21 is composed of volatile memory elements such as RAM (Random Access Memory) or non-volatile memory elements such as ROM (Read Only Memory), EEPROM (Electrically Erasable Programmable ROM), or flash memory, and stores control programs and data referenced during processing in advance. The control program P (program product) stored in the storage unit 21 may be a control program P (program product) read from a recording medium 211 that the in-vehicle device 2 can read. Alternatively, the control program may be downloaded from an external computer (not shown) connected to a communication network (not shown) and stored in the storage unit 21.

[0041] Furthermore, the memory unit 21 stores vehicle configuration information, which aggregates the configuration information of each on-board ECU installed in the vehicle. The vehicle configuration information includes, for example, the manufacturing number (serial number), ECU part number (model number), software part number, current version, previous version of the program, number of operating surfaces, operating surfaces, MAC (Media Access Control) address, IP address, last update completion date and time, repro status, and VIN (Vehicle Identification Number).

[0042] The storage unit 21 stores relay route information (routing table) used for relay processing for communication between in-vehicle ECUs 3 or between in-vehicle ECUs 3 and an external server 100. The format of this relay route information is determined based on the communication protocol. If the communication protocol is CAN, the CAN relay route information includes the message identifier (CAN-ID) included in the CAN message and the relay destination associated with the CAN-ID (the I / O port number of the CAN communication unit 232). If the communication protocol is TCP / IP, the TCP / IP relay route information includes the destination address (MAC address or IP address) included in the IP packet and the relay destination associated with the destination address (the physical port number of the Ethernet communication unit 231). This relay route information (routing table) may also be included in the vehicle configuration information.

[0043] The storage unit 21 also stores relay logs collected when relaying communication between multiple in-vehicle ECUs. These relay logs include, for example, header information (source address, destination address, message ID, etc.) of the relayed Ethernet frame or CAN message, payload information, transmission / reception frequency or period, and may be associated with a timestamp indicating the communication history. As a result, the relay logs can be used as data indicating the communication status and communication history in the actual operating environment (actual vehicle environment) of the vehicle on which the in-vehicle device is installed.

[0044] The input / output interface 22 is a communication interface for serial communication, similar to the input / output interface of the external communication device 1. Through the input / output interface 22, the in-vehicle device 2 is connected to the external communication device 1, the display device 5 (HMI device), and the IG switch 6 which starts and stops the vehicle C, enabling communication between them.

[0045] The in-vehicle communication unit 23 is an input / output interface (CAN transceiver, Ethernet PHY unit) using communication protocols such as CAN (Control Area Network), CAN-FD (CAN with Flexible Data Rate), or Ethernet (Ethernet / registered trademark), and functions as a communication unit for communication between the in-vehicle device 2 and the in-vehicle ECU 3. Multiple in-vehicle communication units 23 are provided, and each of the communication lines 41 (Ethernet cable, CAN bus), i.e., each bus, that constitute the in-vehicle network 4 is connected to each of the in-vehicle communication units 23. By providing multiple in-vehicle communication units 23 in this way, the in-vehicle network 4 may be divided into multiple buses (segments), and the in-vehicle ECU 3 may be connected to each segment according to the function of the in-vehicle ECU 3. The control unit 20 of the in-vehicle device 2 communicates with the in-vehicle ECU 3 connected to the in-vehicle network 4 via the in-vehicle communication unit 23.

[0046] The in-vehicle ECU 3, like the in-vehicle device 2, includes a control unit (not shown), a memory unit (not shown), and an in-vehicle communication unit (not shown). The memory unit is composed of volatile memory elements such as RAM (Random Access Memory) or non-volatile memory elements such as ROM (Read Only Memory), EEPROM (Electrically Erasable Programmable ROM), or flash memory, and stores the program or data of the in-vehicle ECU 3. This program or data is subject to updates by update programs transmitted from a program provider and relayed by the in-vehicle device 2. The in-vehicle communication unit of the in-vehicle ECU 3, like the in-vehicle device 2, is composed of, for example, a CAN transceiver or an Ethernet PHY unit, and communicates with the in-vehicle device 2 via this in-vehicle communication unit.

[0047] The display device 5 is an HMI (Human Machine Interface) device, such as a car navigation display. The display device 5 is connected to the input / output I / F 22 of the in-vehicle device 2 via a harness such as a serial cable. The display device 5 displays data or information output from the control unit 20 of the in-vehicle device 2 via the input / output I / F 22.

[0048] Figure 3 is an explanatory diagram illustrating the processing flow (sequence) by the in-vehicle device 2 and the in-vehicle ECU 3 to be updated. When performing program update processing in the in-vehicle ECU 3 to be updated using the update program, the processing sequences of the program provider device S1 (OTA server), the in-vehicle device 2 (OTA master), and the in-vehicle ECU 3 to be updated (target ECU) will be explained.

[0049] The in-vehicle device 2 outputs (transmits) the vehicle configuration information of vehicle C (the vehicle itself) to the program supply device S1 (S01). The in-vehicle device 2 acquires program information and model information, etc., that are regularly applied to each in-vehicle ECU 3, and generates and stores vehicle configuration information by aggregating this information. The in-vehicle device 2 may also include the VIN (Vehicle Identification Number) in the vehicle configuration information.

[0050] The program provider S1 generates a package containing the update program and an operation verification scenario (S02). The program provider S1 generates the package based on the vehicle configuration information obtained from the in-vehicle device 2. The package includes package information (campaign information) which is information related to the program update, information about the in-vehicle ECU3 to be updated (target information), an update program to be applied to the in-vehicle ECU3 to be updated, and an operation verification scenario for verifying the operation when the update program is applied to the in-vehicle ECU3. The operation verification scenario lists the execution procedures such as processing sequences, scripts, or commands that the in-vehicle device 2 performs for operation verification on the in-vehicle ECU3 to be updated. The operation verification scenario further includes processing sequences for operation verification performed by the in-vehicle ECU3 to be updated, and judgment information for verifying (success or failure) the results of the operation verification by the in-vehicle device 2 and the in-vehicle ECU3 to be updated. Based on the vehicle configuration information transmitted from the in-vehicle device 2, the program provider S1 can generate an operation verification scenario that conforms to the actual environment of the vehicle C on which the in-vehicle device 2 is installed. The program supply device S1 outputs (transmits) the generated package to the in-vehicle device 2 (S03).

[0051] The in-vehicle device 2 stores the package acquired (received) from the program provider S1 in the storage unit S11 (S04). The in-vehicle device 2 may transition from normal mode (the state during normal operation of vehicle C) to update mode by acquiring the package from the program provider S1. The in-vehicle device 2 outputs (transmits) the update program and operation verification scenario contained in the package to the in-vehicle ECU 3 to be updated (S05).

[0052] The in-vehicle ECU3 to be updated stores the update program and operation verification scenario acquired (received) from the in-vehicle device 2 in its memory unit (S06). Upon receiving the update program and operation verification scenario from the in-vehicle device 2, the in-vehicle ECU3 to be updated enters update mode.

[0053] The memory unit of the in-vehicle ECU3 to be updated includes a first memory area where the currently applied program (current version of the program) is stored, and a second memory area where previously applied programs (older versions of the program) are stored. The in-vehicle ECU3 to be updated may store the update program and operation verification scenario acquired from the in-vehicle device 2 in the second memory area, thereby saving (storing) the update program, etc., without overwriting the current version of the program stored in the first memory area. By having a two-sided memory unit having a first memory area and a second memory area, the in-vehicle ECU3 to be updated can reliably perform a rollback process to revert to the old version of the program.

[0054] After the IG switch 6 of vehicle C is turned off, the in-vehicle device 2 issues an activation request (instruction to apply the update program) to the in-vehicle ECU 3 to be updated (S07). After the IG switch 6 of vehicle C is turned off, the in-vehicle device 2 issues an activation request (instruction to apply the update program) by, for example, sending a control signal (activation request signal) to the in-vehicle ECU 3 to be updated. The trigger for the activation request is said to be the turning off of the IG switch 6, but it is not limited to this, and the in-vehicle device 2 may issue an activation request triggered by pre-configured scheduling information or a multicast of sleep signals, etc.

[0055] The in-vehicle ECU3 to be updated switches from the currently applied program to the update program in response to an activation request from the in-vehicle device 2 (S08). The in-vehicle ECU3 to be updated outputs (transmits) information (activation result) indicating that it has switched to the update program to the in-vehicle device 2 (S09). As described above, the in-vehicle ECU3 to be updated is equipped with a two-sided memory unit having a first memory area and a second memory area, and the switch to the update program is performed by enabling (activating) the second memory area in which the update program is stored.

[0056] The in-vehicle device 2 requests the in-vehicle ECU 3 to be updated to transition to operation verification mode according to the operation verification scenario stored in the memory unit 21 (S10). The in-vehicle device 2 requests the transition to operation verification mode by, for example, transmitting a control signal (operation verification mode transition signal) to the in-vehicle ECU 3 to be updated.

[0057] The in-vehicle ECU3 to be updated transitions to the operation verification mode in response to a request from the in-vehicle device 2 to transition to the operation verification mode (S11). The in-vehicle ECU3 to be updated, having transitioned to the operation verification mode, executes the update program based on the operation verification scenario. The operation verification scenario includes a sequence related to self-diagnostic processing (individual diagnosis) performed within its own ECU (within the in-vehicle ECU3 to be updated). The in-vehicle ECU3 to be updated, having transitioned to the operation verification mode, performs self-diagnostic processing (individual diagnosis) within its own ECU based on the operation verification scenario.

[0058] The in-vehicle device 2 outputs (transmits) operation verification data to the in-vehicle ECU 3 to be updated based on the operation verification scenario (S12). When outputting the operation verification data to the in-vehicle ECU 3 to be updated, the in-vehicle device 2 substitutes for other in-vehicle ECU 3s that the in-vehicle ECU 3 normally communicates with. When substituting for other in-vehicle ECU 3s, the in-vehicle device 2 may transmit an Ethernet frame with the IP address of the other in-vehicle ECU 3 as the source address. Alternatively, when substituting for other in-vehicle ECU 3s, the in-vehicle device 2 may transmit a CAN message including the CAN-ID used by the other in-vehicle ECU 3.

[0059] The in-vehicle ECU3 to be updated outputs (transmits) response data to the in-vehicle device 2 in response to operation verification data transmitted from the in-vehicle device 2 that has replaced the other in-vehicle ECU3 (S13). The processing sequence of data transmission and reception between the in-vehicle device 2 that has replaced the other in-vehicle ECU3 and the in-vehicle ECU3 to be updated is performed based on the operation verification scenario. In this processing sequence, control of sensors or actuators connected to the in-vehicle ECU3 to be updated may be omitted or disabled. The in-vehicle device 2 and the in-vehicle ECU3 to be updated may store the response values ​​in these data transmission and reception processing sequences, or measured values ​​(actual values) such as the amount of communication traffic, and save them as operation verification results.

[0060] The in-vehicle ECU3 to be updated outputs (transmits) the results of the standalone diagnostic and the results of the operation verification through data transmission and reception with the in-vehicle device 2 to the in-vehicle device 2 (S14). The operation verification scenario includes standalone diagnostic judgment information for determining the results of the standalone diagnostic. This standalone diagnostic judgment information is the expected values ​​of the process list, CPU usage, memory usage, etc., that are generated in the in-vehicle ECU3 to be updated when the update program is executed (activated).

[0061] The in-vehicle ECU3 to be updated determines the result of the individual diagnostic by comparing various measured values ​​in the individual diagnostic results with various expected values ​​in the individual diagnostic judgment information. If the measured values ​​in the individual diagnostic results match the expected values ​​in the individual diagnostic judgment information, the in-vehicle ECU3 to be updated determines that the result of the individual diagnostic performed based on the operation verification scenario is positive (program update successful). If the measured values ​​in the individual diagnostic results do not match the expected values ​​in the individual diagnostic judgment information, the in-vehicle ECU3 to be updated determines that the result of the individual diagnostic performed based on the operation verification scenario is negative (program update failed).

[0062] The in-vehicle device 2 stores the results of operation verification through data transmission and reception with the in-vehicle ECU 3 to be updated in the storage unit 21 (S15). The in-vehicle device 2 stores the results of operation verification output from the in-vehicle ECU 3 to be updated in the storage unit 21. Furthermore, the in-vehicle device 2 also stores the results of operation verification performed by its own device in the storage unit 21.

[0063] The in-vehicle device 2 determines whether the program update in the in-vehicle ECU 3 to be updated was successful or not (success or failure) by comparing the determination information included in the operation confirmation scenario with various values ​​(measured values, actual values) included in the operation confirmation results (S16). The determination information includes, for example, expected values ​​regarding the response data from the in-vehicle ECU 3 to be updated to the operation confirmation data transmitted from the in-vehicle device 2 that replaces another in-vehicle ECU 3 to the in-vehicle ECU 3 to be updated. The expected values ​​regarding the response data include, for example, the presence or absence of response data, type (header information), data length, payload information, and the response value of the response data.

[0064] The in-vehicle device 2 verifies the results of the operation check by comparing the actual values ​​such as the presence or absence of response data from the in-vehicle ECU 3 to be updated, the data length, or the reply response value, with the judgment information (expected value regarding the response data) included in the operation check scenario during data transmission and reception with the in-vehicle ECU 3 to be updated. If the response data from the in-vehicle ECU 3 to be updated conforms to the judgment information, i.e., the expected value (expected value regarding the response data) defined in the operation check scenario, the in-vehicle device 2 determines that the result of the operation check performed based on the operation check scenario is positive (the program update was successful). If the response data from the in-vehicle ECU 3 to be updated does not conform to the judgment information, i.e., the expected value (expected value regarding the response data) defined in the operation check scenario, the in-vehicle device 2 determines that the result of the operation check performed based on the operation check scenario is negative (the program update failed).

[0065] Furthermore, the in-vehicle device 2 determines whether the program update in the in-vehicle ECU 3 to be updated was successful or not (success or failure) based on the results of the individual diagnostic obtained from the in-vehicle ECU 3 to be updated and the results of the operation verification through data transmission and reception with the in-vehicle device 2. In other words, the in-vehicle device 2 determines the success or failure of the program update in the in-vehicle ECU 3 to be updated based on three verification results: the results of the operation verification regarding the transmission and reception of operation verification data from its own side, the results of the operation verification regarding the transmission and reception of operation verification data from the in-vehicle ECU 3 side, and the results of the individual diagnostic in the in-vehicle ECU 3. If all three verification results are positive, the in-vehicle device 2 determines that the program update in the in-vehicle ECU 3 to be updated was successful. By obtaining these three verification results in a real vehicle environment, the accuracy of the program update success or failure determination can be improved.

[0066] If the in-vehicle device 2 determines that the program update has been successful, it requests the in-vehicle ECU 3 to be updated to switch to normal mode (S17). The in-vehicle ECU 3 to be updated switches to normal mode in response to the request from the in-vehicle device 2 (S18). Upon receiving the request from the in-vehicle device 2 to switch to normal mode, the program update in the in-vehicle ECU 3 is completed, and the in-vehicle ECU 3 switches to a state (normal mode) in which it performs control in the normal manner when the vehicle C is driving, etc.

[0067] If at least one of the three verification results is negative, the in-vehicle device 2 determines that the program update in the in-vehicle ECU 3 to be updated has failed. If the in-vehicle device 2 determines that the program update has failed, it may request the in-vehicle ECU 3 to be updated to perform a rollback process. Based on these three verification results, the in-vehicle device 2 may decide whether to perform a rollback process or transition to a degraded mode. The in-vehicle device 2 may also notify the operator of the vehicle C, for example, by outputting the fact that the program update has failed to a display device 5.

[0068] The in-vehicle device 2 outputs (transmits) the results of the operation verification according to the operation verification scenario to the program supply device S1 (S19). The program supply device S1, having received the operation verification results output from the in-vehicle device 2, stores the results in its own storage unit S11. This enables the synchronization of information regarding program updates based on packages between the in-vehicle device 2 and the program supply device S1.

[0069] Figure 4 is a flowchart illustrating the processing of the control unit 20 of the in-vehicle device 2. The control unit 20 of the in-vehicle device 2 routinely performs the following processing, for example, when the vehicle C is in the startup state (IG switch 6 is on).

[0070] The control unit 20 of the in-vehicle device 2 outputs (transmits) vehicle configuration information of vehicle C (the vehicle itself) to the program supply device S1 (S101). The output of vehicle configuration information by the control unit 20 of the in-vehicle device 2 to the program supply device S1 is not limited to when performing program update processing for the in-vehicle ECU 3, and the output of such vehicle configuration information may be performed on a regular basis. That is, the control unit 20 of the in-vehicle device 2 acquires program information and model information applied to all in-vehicle ECU 3 installed in vehicle C (the vehicle itself) on a regular basis or periodically, and stores the acquired and aggregated information as vehicle configuration information. The control unit 20 of the in-vehicle device 2 may also transmit vehicle configuration information including the VIN to the program supply device S1 on a regular basis or periodically. As a result, the program supply device S1 identifies the target vehicle C based on the vehicle configuration information including the VIN and creates a package corresponding to the identified vehicle C. The package created by the program provider S1 includes package information (campaign information), which is information related to the program update; information about the in-vehicle ECU3 to be updated (target information); an update program (update data); and an operation verification scenario.

[0071] The control unit 20 of the in-vehicle device 2 obtains a package containing the update program and operation verification scenario from the program supply device S1 (S102). The control unit 20 of the in-vehicle device 2 communicates with the program supply device S1 via the external communication device 1 and obtains the package from the program supply device S1. The control unit 20 of the in-vehicle device 2 stores the obtained package in the storage unit 21.

[0072] The control unit 20 of the in-vehicle device 2 outputs the update program and operation verification scenario to the in-vehicle ECU 3 to be updated (S103). By outputting the operation verification scenario to the in-vehicle ECU 3 to be updated, the operation verification scenario is shared by the in-vehicle device 2 and the in-vehicle ECU 3 to be updated. That is, the in-vehicle device 2 and the in-vehicle ECU 3 to be updated can perform operation verification processing based on the same operation verification scenario. In addition to outputting the update program and operation verification scenario to the in-vehicle ECU 3 to be updated, the control unit 20 of the in-vehicle device 2 may also output an activation request to the in-vehicle ECU 3 indicating that the update program should be applied.

[0073] The control unit 20 of the in-vehicle device 2 outputs a request to the in-vehicle ECU 3 to be updated to transition to operation verification mode (S104). Upon receiving the request to transition to operation verification mode from the in-vehicle device 2, the in-vehicle ECU 3 to be updated begins executing operation verification based on the operation verification scenario when applying the update program.

[0074] The control unit 20 of the in-vehicle device 2 outputs operation verification data to the in-vehicle ECU 3 to be updated based on the operation verification scenario (S105). In normal conditions (normal mode), such as when vehicle C is in motion, the target of data communication by the in-vehicle ECU 3 to be updated is not the in-vehicle device 2, but another in-vehicle ECU 3. In contrast, in the operation verification scenario, the in-vehicle device 2 substitutes for the other in-vehicle ECU 3 in order to simulate the operation of that other in-vehicle ECU 3. As a result, the in-vehicle ECU 3 to be updated in operation verification mode executes a series of processing sequences, including data transmission and reception, with the in-vehicle device 2 which has substituted for the other in-vehicle ECU 3. Based on the operation verification scenario, the control unit 20 of the in-vehicle device 2 outputs operation verification data to the in-vehicle ECU 3 to be updated, and the in-vehicle ECU 3 to be updated also outputs response data based on the operation verification scenario. In other words, the control unit 20 of the in-vehicle device 2 and the in-vehicle ECU 3 to be updated start transmitting and receiving data in accordance with the actual vehicle environment using the same operation verification scenario.

[0075] The control unit 20 of the in-vehicle device 2 acquires the results of the operation check based on the operation check scenario (S106). The in-vehicle ECU 3 to be updated outputs the results of the individual diagnostic and the operation check results regarding the transmission and reception of operation check data from its own ECU side to the in-vehicle device 2. The control unit 20 of the in-vehicle device 2 acquires these results from the in-vehicle ECU 3 to be updated. Furthermore, the control unit 20 of the in-vehicle device 2 acquires the results of the operation check regarding the transmission and reception of operation check data from its own device side. As described above, in the operation check performed based on the operation check scenario, various measured values ​​are stored in the storage unit 21 of the in-vehicle device 2. The control unit 20 of the in-vehicle device 2 acquires the results of the operation check regarding the transmission and reception of operation check data from its own device side by referring to the storage unit 21 of its own device. In other words, the control unit 20 of the in-vehicle device 2 acquires these three operation check results.

[0076] The control unit 20 of the in-vehicle device 2 determines whether the program update in the in-vehicle ECU 3 to be updated was successful (S107). The operation verification scenario includes determination information for determining the result of the operation verification. The control unit 20 of the in-vehicle device 2 determines whether the program update was successful by comparing various measured values, which are the results of the operation verification, with the expected values ​​included in the determination information. For example, if all measured values ​​are within the range of the expected values, the control unit 20 of the in-vehicle device 2 determines that the program update was successful. For example, if all measured values ​​are not within the range of the expected values, the control unit 20 of the in-vehicle device 2 determines that the program update was unsuccessful.

[0077] If the program update is successful (S107:YES), the control unit 20 of the in-vehicle device 2 requests the in-vehicle ECU 3 to be updated to switch to normal mode (S108). If the control unit 20 of the in-vehicle device 2 determines that the program update was successful, it requests the in-vehicle ECU 3 to be updated to switch to normal mode, for example by outputting a control signal (normal mode transition signal). Upon receiving the request to switch to normal mode, the in-vehicle ECU 3 to be updated switches to normal mode.

[0078] If the program update is unsuccessful (S107:NO), i.e., the program update fails, the control unit 20 of the in-vehicle device 2 requests the in-vehicle ECU 3 to be updated to perform a rollback process (S1071). If it is determined that the program update has failed, the control unit 20 of the in-vehicle device 2 requests a rollback process, for example, by outputting a control signal (rollback signal) to the in-vehicle ECU 3 to be updated. Alternatively, the control unit 20 of the in-vehicle device 2 may decide whether to request a rollback process or transition to a degraded mode, depending on the results of the operation check.

[0079] The control unit 20 of the in-vehicle device 2 outputs (transmits) the results of the operation verification according to the operation verification scenario to the program supply device S1 (S109). The control unit 20 of the in-vehicle device 2 outputs (transmits) the results of the operation verification according to the operation verification scenario to the program supply device S1 via the external communication device 1. Alternatively, the control unit 20 of the in-vehicle device 2 may output the results of the operation verification according to the operation verification scenario to the display device 5 and notify the operator of vehicle C of the results.

[0080] According to this embodiment, the in-vehicle ECU3 and in-vehicle device 2 to be updated perform operational verification of the in-vehicle ECU3 (the in-vehicle ECU3 to be updated) to which the update program has been applied, based on the same operational verification scenario. This enables efficient operational verification in the actual environment of the vehicle C on which these in-vehicle ECU3 and in-vehicle device 2 are installed. In the operational verification processing sequence based on the operational verification scenario, the in-vehicle device 2 substitutes for other in-vehicle ECU3s other than the in-vehicle ECU3 to be updated. This allows the in-vehicle ECU3 to be updated to perform simulated data transmission with the other in-vehicle ECU3s, enabling efficient operational verification in accordance with the actual environment of vehicle C.

[0081] (Embodiment 2) Figure 5 is a flowchart illustrating the processing of the control unit 20 of the in-vehicle device 2 according to Embodiment 2. The control unit 20 of the in-vehicle device 2 outputs (transmits) vehicle configuration information of vehicle C (the vehicle itself) to the program supply device S1 (S201). The control unit 20 of the in-vehicle device 2 obtains a package containing the update program and operation confirmation scenario from the program supply device S1 (S202). The control unit 20 of the in-vehicle device 2 performs the processing of S201 and S202 in the same way as the processing S101 and S102 of Embodiment 1.

[0082] The control unit 20 of the in-vehicle device 2 uses relay logs collected when relaying communication between multiple in-vehicle ECUs 3 to complement the operation verification scenario (S203). The in-vehicle device 2 is equipped with multiple in-vehicle communication units 23 and functions as an in-vehicle relay device that relays communication between in-vehicle ECUs 3 connected to these in-vehicle communication units 23. When relaying communication between these in-vehicle ECUs 3, the control unit 20 of the in-vehicle device 2 stores relay logs in the storage unit 21 based on the data (Etherframes, CAN messages) that were relayed. These relay logs include, for example, header information (source address, destination address, message ID, etc.), payload information, transmission / reception frequency or period of the relayed Etherframe or CAN message, and represent data indicating the communication status in the actual operating environment (actual vehicle environment) of the vehicle C on which the in-vehicle device 2 is installed.

[0083] The control unit 20 of the in-vehicle device 2 uses relay logs to add or modify sequences related to data transmission and reception included in the operation verification scenario, thereby further supplementing the operation verification scenario generated by the program provider S1 to better reflect the actual vehicle environment. The control unit 20 of the in-vehicle device 2 then performs subsequent processing using the supplemented operation verification scenario. In other words, in subsequent processing, the operation verification scenario used by the control unit 20 of the in-vehicle device 2 and the in-vehicle ECU 3 to be updated is the operation verification scenario supplemented using relay logs.

[0084] The control unit 20 of the in-vehicle device 2 outputs the update program and operation verification scenario to the in-vehicle ECU 3 to be updated (S204). The control unit 20 of the in-vehicle device 2 performs the process in S204 in the same way as the process S103 of Embodiment 1.

[0085] The control unit 20 of the in-vehicle device 2 outputs a sleep signal to the other in-vehicle ECU3s other than the in-vehicle ECU3 to be updated (S205). The control unit 20 of the in-vehicle device 2 can identify all in-vehicle ECU3s installed in vehicle C (the vehicle itself) by referring to, for example, vehicle configuration information or routing tables used for relay processing. The control unit 20 of the in-vehicle device 2 identifies the other in-vehicle ECU3s other than the in-vehicle ECU3 to be updated among all the in-vehicle ECU3s installed in vehicle C (the vehicle itself). The control unit 20 of the in-vehicle device 2 outputs (transmits) a sleep signal to the identified other in-vehicle ECU3s to transition them into sleep mode. The other in-vehicle ECU3s that receive the sleep signal transition into sleep mode and stop processing such as sending and receiving data. This prevents any impact on the other in-vehicle ECU3s other than the in-vehicle ECU3 to be updated, while allowing the program update process to be carried out on the in-vehicle ECU3 to be updated. Although the control unit 20 of the in-vehicle device 2 is described as outputting a sleep signal, it is not limited to this, and the control unit 20 of the in-vehicle device 2 may also restrict communication between the in-vehicle ECU 3 to be updated and other in-vehicle ECUs 3 by stopping relay processing within its own device.

[0086] The control unit 20 of the in-vehicle device 2 outputs a request to the in-vehicle ECU 3 to be updated to transition to operation verification mode (S206). Based on the operation verification scenario, the control unit 20 of the in-vehicle device 2 outputs operation verification data to the in-vehicle ECU 3 to be updated (S207). The control unit 20 of the in-vehicle device 2 obtains the result of the operation verification according to the operation verification scenario (S208). The control unit 20 of the in-vehicle device 2 determines whether the program update in the in-vehicle ECU 3 to be updated was successful or not (S209). If the program update was successful (S209: YES), the control unit 20 of the in-vehicle device 2 requests the in-vehicle ECU 3 to be updated to transition to normal mode (S210). If the program update was unsuccessful (S209: NO), i.e., the program update failed, the control unit 20 of the in-vehicle device 2 requests the in-vehicle ECU 3 to be updated to perform a rollback process (S2091). The control unit 20 of the in-vehicle device 2 outputs (transmits) the results of the operation verification according to the operation verification scenario to the program supply device S1 (S211). The control unit 20 of the in-vehicle device 2 performs the processing from S206 to S211 in the same way as the processing from S104 to S109 in Embodiment 1.

[0087] According to this embodiment, the in-vehicle device 2 can improve the suitability of the operation verification scenario to the actual environment of the vehicle by using the relay log obtained when relay processing is performed to supplement the operation verification scenario obtained from the external server, such as by adding to it. By using the operation verification scenario (supplemented operation verification scenario) which has improved suitability to the actual environment of the vehicle in this way, the accuracy of operation verification when applying the update program to the in-vehicle ECU 3 to be updated can be improved.

[0088] The embodiments disclosed herein should be considered in all respects to be illustrative and not restrictive. The scope of this disclosure is indicated by the claims, not in the sense described above, and all modifications within the sense and scope equivalent to the claims are intended. [Explanation of Symbols]

[0089] C Vehicle S In-vehicle update system S1 Program Provisioning Device S11 storage section 1. External communication device 11 Antennas 2 Onboard equipment 20 Control Unit 21 Memory section 211 Recording media P Control Program (Program Product) 22 Input / Output Interfaces 23 In-vehicle communications unit 3 In-vehicle ECU 4. In-vehicle network 41 Communication lines 5 Display device 6 IG switch

Claims

1. An in-vehicle device that obtains update programs transmitted from an external server outside the vehicle and performs processing to update the program of the in-vehicle ECU installed in the vehicle, The system includes a control unit that performs processing related to the aforementioned update program, The control unit, When obtaining the aforementioned update program, an operational verification scenario for performing operational verification on the in-vehicle ECU to be updated is obtained from the external server. The acquired update program and the operation verification scenario are output to the vehicle ECU to be updated. Based on the aforementioned operational verification scenario, the process for verifying the operation of the in-vehicle ECU to be updated is performed. Based on the aforementioned operational verification scenario, the operational verification process for the vehicle ECU to be updated is performed by substituting another vehicle ECU other than the vehicle ECU to be updated. The aforementioned operational verification scenario is: The control unit that replaces the other in-vehicle ECU includes a processing sequence for transmitting data to the in-vehicle ECU to be updated, The update program is applied to the updated vehicle ECU, and the update program is applied to the vehicle ECU that transmits data to the other vehicle ECU that has been replaced by the control unit, including a processing sequence. In-vehicle device.

2. The aforementioned operation verification scenario includes determination information for determining the result of the operation verification for the in-vehicle ECU to be updated. The control unit, By performing a process related to operational verification on the in-vehicle ECU to be updated, the results of the operational verification are obtained. Based on the acquired operational verification results and the judgment information included in the operational verification scenario, the success or failure of the program update in the in-vehicle ECU to be updated is determined. The in-vehicle device according to claim 1.

3. The control unit, The results of the standalone diagnostic performed by the vehicle ECU to be updated based on the operation verification scenario are obtained from the vehicle ECU to be updated. Based on the results of the individual diagnostic test obtained, the success or failure of the program update in the in-vehicle ECU to be updated is determined. The in-vehicle device according to claim 2.

4. The control unit, The relay logs collected during the relay processing of communication between multiple in-vehicle ECUs installed in the vehicle are used to supplement the operation verification scenario obtained from the external server. The acquired update program and the supplemented operational verification scenario are output to the vehicle ECU to be updated. Based on the aforementioned supplemented operational verification scenario, the process for verifying the operation of the in-vehicle ECU to be updated is performed. The in-vehicle device according to any one of claims 1 to 3.

5. When the vehicle's IG switch is turned off, the control unit performs an operation verification process for the in-vehicle ECU to be updated, based on the operation verification scenario. The in-vehicle device according to any one of claims 1 to 4.

6. The control unit, To other in-vehicle ECUs besides the in-vehicle ECU to be updated, a sleep signal is output to cause the other in-vehicle ECUs to transition to sleep mode. After outputting the sleep signal, the system performs operation verification processing for the in-vehicle ECU to be updated, based on the operation verification scenario. The in-vehicle device according to any one of claims 1 to 5.

7. The computer receives update programs sent from an external server outside the vehicle and processes them to update the program of the vehicle's onboard ECU. When obtaining the aforementioned update program, an operational verification scenario for performing operational verification on the in-vehicle ECU to be updated is obtained from the external server. The acquired update program and the operation verification scenario are output to the vehicle ECU to be updated. Based on the aforementioned operational verification scenario, the process for verifying the operation of the in-vehicle ECU to be updated is performed. Based on the aforementioned operational verification scenario, the operational verification process for the vehicle ECU to be updated is performed by substituting another vehicle ECU other than the vehicle ECU to be updated. The aforementioned operational verification scenario is: The computer that replaces the other in-vehicle ECU transmits a processing sequence to the in-vehicle ECU to be updated, The update program applied to the updated vehicle ECU includes a processing sequence that transmits data to the other vehicle ECU replaced by the computer. A program that executes a process.

8. The computer receives update programs sent from an external server outside the vehicle and processes them to update the program of the vehicle's onboard ECU. When obtaining the aforementioned update program, an operational verification scenario for performing operational verification on the in-vehicle ECU to be updated is obtained from the external server. The acquired update program and the operation verification scenario are output to the vehicle ECU to be updated. Based on the aforementioned operational verification scenario, the process for verifying the operation of the in-vehicle ECU to be updated is performed. Based on the aforementioned operational verification scenario, the operational verification process for the vehicle ECU to be updated is performed by substituting another vehicle ECU other than the vehicle ECU to be updated. The aforementioned operational verification scenario is: The computer that replaces the other in-vehicle ECU transmits a processing sequence to the in-vehicle ECU to be updated, The update program applied to the updated vehicle ECU includes a processing sequence that transmits data to the other vehicle ECU replaced by the computer. How to update the program that executes the process.

Images