JP2020201986A - Software update device and software update method - Google Patents

Abstract

To provide a software update device capable of carrying out recovery processing suitable to various devices.SOLUTION: A software update device is connected to a control device. The software update device includes: an update control part which carries out processing to cause software of the control device to transit from a state before update to an update completion state; a recovery control information management part that acquires recovery control information; and a recovery control part that, when the software does not transit to the update completion state due to abnormality in update processing, carries out recovery processing to transit the software to the update completion state on the basis of the recovery control information. The recovery control information includes information indicating a recovery processing method, and the information indicating the recovery processing method is determined on the basis of a configuration of the control device.SELECTED DRAWING: Figure 2

Description

The present invention relates to a software update device, a software update method, and a software update system.

In recent years, with the development of driving support functions and automatic driving technology, the scale of software installed in electronic control devices (ECUs: Electronic Control Units) for automobiles has been increasing. Along with this, not only the number of recalls due to software defects but also the number of units that need to be dealt with each time is increasing. Therefore, there is an increasing need for a technique for remotely updating software mounted on an ECU. When updating software remotely, it is necessary to automate the process as much as possible, unlike the case where a mechanic has conventionally performed the update work with a dealer or the like. Therefore, even if an abnormality such as a power failure occurs and the update process is interrupted, it is important to be able to return to the normal state without assuming the operation of a mechanic or the like.
For example, in Patent Document 1, two areas for storing execution software are prepared, and when a software update abnormality occurs, normal software is selected and executed to affect the system even when the update abnormality occurs. No technology is disclosed.

Patent No. 4548601

The invention described in Patent Document 1 cannot be applied to a device having scarce memory resources, and it is difficult to cope with a variety of devices for updating software.

The software update device according to the first aspect of the present invention is a software update device connected to a control device, and is an update control unit that performs update processing for transitioning the software of the control device from the pre-update state to the update complete state. And the recovery control information management unit that acquires the recovery control information, and the update completed state of the software based on the recovery control information when the software has not transitioned to the update completed state due to an abnormality in the update process. The recovery control unit includes a recovery control unit that executes the recovery process of transitioning to, the recovery control information includes information indicating the recovery processing method, and the information indicating the recovery processing method is determined based on the configuration of the control device. To.
The software update method according to the second aspect of the present invention is a software update method executed by the software update device connected to the control device, and updates the software of the control device from the pre-update state to the update complete state. When the software has not transitioned to the update complete state due to processing, acquisition of recovery control information, and an abnormality in the update process, the software is updated to the update complete state based on the recovery control information. The recovery control information includes information indicating the recovery processing method, and the information indicating the recovery processing method is determined based on the configuration of the control device, including executing the recovery processing to transition to.

According to the present invention, recovery processing corresponding to various devices can be executed.

Diagram showing the configuration of the software update system FIG. 2A is a block diagram showing the hardware configuration of the gateway, and FIG. 2B is a block diagram showing the configuration of the gateway program running on the gateway. The figure which shows an example of the update state D1 FIG. 4A is a block diagram showing the hardware configuration of the engine control ECU, and FIG. 4B is a block diagram showing the configuration of the control program operating on the engine control ECU. FIG. 5A is a diagram showing a configuration example of a FROM having a small capacity, and FIG. 5B is a diagram showing a configuration example of a FROM having a large capacity. FIG. 6A is a diagram showing the configuration of the update package in the first embodiment, and FIG. 6B is a diagram showing the configuration of the ECU recovery control information in the first embodiment. Sequence diagram showing the entire update process for updating the software of the engine control ECU A sequence diagram showing a flow of software update processing executed between the gateway and the engine control ECU in step S4 of FIG. FIG. 9A is a conceptual diagram showing the processing of the restoration process S407 in the ECU having a small memory, and FIG. 9B is a conceptual diagram showing the processing of the restoration process S407 in the ECU having a large memory. FIG. 10A is a start-up sequence diagram of an ECU having a small memory, and FIG. 10B is a start-up sequence diagram of an ECU having a large memory. Flow chart showing recovery control processing performed by gateway 10 at startup Flow chart showing an example of recovery process S707 13 (a) and 13 (b) are diagrams showing an example of an update package corresponding to an automatic operation ECU, and FIG. 13 (c) is a diagram showing an example of screen display. Sequence diagram showing an example of recovery processing of the automatic operation ECU 15 (a) and 15 (b) are diagrams showing an example of an update package corresponding to the ADAS ECU, and FIG. 15 (c) is a diagram showing a screen display example. Sequence diagram showing an example of recovery processing of ADAS ECU 17 (a) and 17 (b) are diagrams showing an example of an update package corresponding to the engine control ECU, and FIG. 17 (c) is a diagram showing a screen display example. Sequence diagram showing an example of recovery processing of engine control ECU 19 (a) and 19 (b) are diagrams showing an example of an update package corresponding to the brake control ECU, and FIG. 19 (c) is a diagram showing a screen display example. Sequence diagram showing an example of recovery processing of the brake control ECU 21 (a) and 21 (b) are diagrams showing an example of an update package corresponding to the HVAC ECU, and FIG. 21 (c) is a diagram showing an example of screen display. Sequence diagram showing an example of recovery processing of HVAC ECU 23 (a) and 23 (b) are diagrams showing an example of an update package corresponding to the airbag ECU, and FIG. 23 (c) is a diagram showing an example of screen display. Sequence diagram showing an example of recovery processing of airbag ECU The figure which shows an example of the update package in the modification 6. A block diagram showing a configuration of a control program operating on an engine control ECU according to a second embodiment. Sequence diagram showing the process of the gateway acquiring recovery control information from the engine control ECU FIG. 28 (a) is a diagram showing the configuration of the update package in the third embodiment, and FIG. 28 (b) is a diagram showing the configuration of the ECU recovery control information in the third embodiment. 29 (a) is a diagram showing an example of recovery control information corresponding to the automatic operation ECU, FIG. 29 (b) is a diagram showing an example of screen display, and FIG. 29 (c) is a diagram showing an example of the update state D1. FIG. 30A is a sequence diagram showing an example of recovery control processing that differs depending on the interruption factor, and FIG. 30B is a sequence diagram showing an example of recovery control processing at the time of FROM failure.

-First Embodiment-
Hereinafter, the software update system according to the first embodiment will be described with reference to FIGS. 1 to 24. Although software update is described in this embodiment, it is not limited to software and can be applied to parameters, data, and the like.

<Definition of update and recovery>
The software "update" and "recovery" in the present embodiment are defined as follows. That is, the "update" of the software in the present embodiment is to transition the software from the pre-update state to the update complete state. Further, the "recovery" of the software in the present embodiment is to make a transition to the update complete state when the software has not transitioned to the update complete state due to an abnormality in the update process.
However, the software may be composed of a single program or may be composed of a plurality of programs. Further, the software may include not only the program but also various parameters necessary for executing the program, text information, audio information, image information and the like.

<Composition>
(System configuration)
FIG. 1 is a diagram showing a configuration of a software update system S according to the first embodiment. The software update system S includes a vehicle 1 and a server 2. The vehicle 1 and the server 2 are connected via the Internet 3 that connects the access network and the base, and the access network 4 provided by the communication service provider.
The vehicle 1 includes a gateway 10, a communication module 11, a Human Machine Interface (HMI) 12, an engine control ECU 13, a brake control ECU 14, an automatic driving ECU 15, an advanced driver assistance system (ADAS) ECU 16, an airbag ECU 17, and a heating ventilation air conditioning (HVAC). ) The ECU 18 and the vehicle 1 such as the vehicle management ECU 19 are provided with an ECU group required to realize a function such as running, and in-vehicle networks 10a and 10b connecting these ECU groups.

In this embodiment, an example of updating the control program of the engine control ECU 13 from the current version 2 to the new version 3 will be described. The previous version of this control program immediately before the current version 2 is 1.
The in-vehicle network is composed of Control Area Network (CAN) (registered trademark), Local Interconnect Network (LIN), FlexRay, Ethernet (registered trademark) and the like. In the present embodiment, the in-vehicle network 10b is composed of CAN, and the in-vehicle network 10a is composed of Ethernet. Further, although not shown in FIG. 1, each component in the vehicle such as various ECUs is connected to a storage battery by a power line to receive electric power.

The gateway 10 relays communication data between various ECUs, and as a software update device, updates software mounted on its own device and an ECU connected via an in-vehicle network.
The communication module 11 relays communication between the gateway 10, the HMI 12, various ECUs, and the server 2. The HMI 12 is a device for presenting information to a user who is an occupant of the vehicle 1 and receiving input from the user, and is composed of a display device for displaying a screen, an input device such as various switches, or a touch panel combining these. Will be done. The engine control ECU 13 controls the engine. The brake control ECU 14 controls the brake. The automatic driving ECU 15 recognizes the environment, gives an instruction to start the vehicle, and the like during automatic driving. The ADAS ECU 16 performs driving support control such as automatic braking. The airbag ECU 17 controls the airbag. The HVAC ECU 18 controls the air conditioning inside the vehicle. The vehicle management ECU 19 manages the vehicle state.

The server 2 includes a CPU, ROM, and RAM (not shown), and transmits the update package 5 required for software update to the gateway 10. The configuration of the update package 5 will be described later. The gateway 10 updates the software of each ECU based on the data included in the update package 5.

(Gateway configuration)
FIG. 2A is a block diagram showing a hardware configuration of the gateway 10. The gateway 10 includes a microcomputer 101, a FROM (FlashROM) 102, a communication I / F 104 for CAN, and a communication I / F 105 for Ethernet.
The microcomputer 101 includes a CPU 1011, an SRAM 1012, a FROM 1013, a CAN communication controller 1014, and an Ethernet communication controller 1015. The CPU 1011 of the microcomputer 101 executes a program stored in the FROM 1013, controls other components in the gateway 10, and gives a data transmission / reception instruction to other devices connected by the in-vehicle network to control the gateway 10. Make it work.

The FROM 102 is a non-volatile memory, and the received update package 5 is stored in the FROM 102.
The communication I / F 104 is an interface for CAN communication, and data is transmitted / received to / from the ECU connected to the in-vehicle network 10b via the in-vehicle network 10b based on the instruction of the microcomputer 101.
The communication I / F 105 is an interface for Ethernet communication, and transmits / receives data to / from a device connected to the in-vehicle network 10a via the in-vehicle network 10a based on an instruction of the microcomputer 101.

FIG. 2B is a block diagram showing a configuration of a gateway program 100 operating on the gateway 10.
The gateway program 100 that realizes the function of the gateway 10 is stored in the FROM 1013 of the microcomputer 101 and executed by the CPU 1011. In FIG. 2B, a functional group is represented as a block, and each block may be divided into a plurality of blocks, or some blocks may be integrated. Further, the control program may be realized by one software or may be realized by a combination of two or more softwares.
The gateway program 100 includes an update control unit 10001, an update data management unit 10002, an update status management unit 10003, a recovery control unit 10004, a recovery control information management unit 10005, a vehicle status management unit 10006, and a communication control unit 10007.

The update control unit 10001 communicates with the device connected to the in-vehicle network 10a via the communication control unit 10007, acquires the update package 5, and transmits the vehicle status and the software update processing status. The update package 5 acquired by the update control unit 10001 is stored in the FROM 102. As will be described in detail later, the update package 5 is composed of update control information 501 and recovery control information 502. Further, the update control unit 10001 communicates with the device connected to the in-vehicle network 10b via the communication control unit 10007, controls the ECU, and updates the software mounted on the ECU. Here, the software update is performed based on the update control information 501 acquired via the update data management unit 10002 and the vehicle system state acquired via the vehicle state management unit 10006.

The update data management unit 10002 acquires the update control information 501 from the FROM 102 and provides it to the update control unit 10001.
The update state management unit 1003 acquires the update state from the update control unit 10001 and stores it in the FROM 1013 as the update state D1. Further, the stored update state D1 is provided to the recovery control unit 1004.
The recovery control unit 1004 communicates with a device connected to the in-vehicle network 10b via the communication control unit 10007, and controls the ECU to perform software recovery processing. Here, the recovery process of the ECU is acquired via the update state D1 acquired via the update state management unit 1003, the recovery control information 502 acquired via the recovery control information management unit 10055, and the vehicle state management unit 10006. It is carried out based on the vehicle system condition.

The recovery control information management unit 10005 acquires the recovery control information 502 from the FROM 102 and provides it to the recovery control unit 1004.
The vehicle state management unit 10006 communicates with the devices connected to the in-vehicle networks 10a and 10b via the communication control unit 10007 to acquire the state of the vehicle system, and provides the vehicle state to the update control unit 10001 and the recovery control unit 10004. To do. The vehicle state is, for example, the on / off of the ignition, the start of running, and the like.

The communication control unit 10007 controls the CAN communication controller 1014 and the Ethernet communication controller 1015 in accordance with instructions from the update control unit 10001 and the like, and communicates with the devices connected to the in-vehicle networks 10a and 10b. When communicating with a device connected to the in-vehicle network 10a, the communication control unit 10007 analyzes and generates packets such as TCP / IP and UDP / IP. Further, when communicating with a device connected to the in-vehicle network 10a, the communication control unit 10007 analyzes and generates a CAN frame. In addition, the communication control unit 10007 generates and analyzes commands conforming to a diagnostic communication protocol such as Unified Digital Services (UDS).

FIG. 3 is a diagram showing an example of the update state D1 managed by the update state management unit 1003 of the gateway 10. FIG. 3 shows an example in which the update state D1 is managed as a table and the update state for each ECU is recorded.
The update state D1 includes fields of the ECU ID D101, the update start state D102, the processing block D103, the completion command D104, and the success block D105.

The ECU ID D101 is a field in which information for identifying the ECU is stored. The update start state D102 is a field in which identification information indicating whether or not the update process of the ECU has been started is stored, and for example, "not started", "started", or "update completed" is stored. The processing block D103 is a field in which the identification information of the block being processed is stored in the update processing of the ECU, and the block number and the like are stored. The completion command D104 is a field in which the identification information of the last successful command in the update process of the ECU is stored, and the command identification information such as "data transfer start request" is stored. The success block D105 is a field in which the identification information of the block in which the processing is successful is stored, and the block number and the like are stored.

The record D11 is a record indicating the update status of the automatic operation ECU 15, and the field of the ECU ID D101 stores the “automatic operation ECU”, and the field of the update start state D102 indicates that the update process is in progress. Is stored, "Block n-1" indicating that block n-1 is being processed is stored in the field of the processing block D103, and the data transfer start request has been accepted in the field of the completion command D104. A "data transfer start request" indicating that the data is transferred is stored, and a "Block n" indicating that the last block completed for processing is the block n is stored in the field of the success block D105.

The record D12 is a record indicating the update state of the engine control ECU 13, and indicates that the “engine control ECU” is stored in the field of the ECU ID D101 and the update process is not started in the field of the update start state D102. "Not started" is stored. Here, since the update of the engine control ECU has not been started, no value is set in the other fields of the record D12.
Here, two records, record D11 and record D12, have been described, but these records are created in the following cases. That is, it is created when the update package 5 received by the gateway 10 is described as the ECU to be updated. Further, this update state D1 is sequentially recorded as described later. By sequentially recording the update status D1 in this way, it is appropriate to recognize that the update is interrupted without being completed when the update is restored to normal and started after the update is interrupted, and the location where the update is interrupted is recognized. Recovery process can be started.

(Ignition configuration)
FIG. 4A is a block diagram showing a hardware configuration example of the engine control ECU 13. However, in each of the ECUs to which the software is updated in the present embodiment has at least the hardware configuration shown in FIG. 4A. The engine control ECU 13 includes a microcomputer 131 and a communication I / F 133 for CAN.
The microcomputer 131 includes a CPU 1311, SRAM 1312, FROM 1313, a communication controller 1314, and an I / O controller 1315. The microcomputer 131 executes a control program stored in the FROM 1313 to control other components in the engine control ECU 13 and a sensor / actuator 132 connected via I / O, and is connected by an in-vehicle network. Engine control is performed by instructing data transmission / reception with the equipment of. The sensor / actuator 132 executes engine control while acquiring data required for engine control according to instructions from the microcomputer 131.

FIG. 4B is a block diagram showing a configuration of a control program 130 that operates on the engine control ECU 13. However, in each of the ECUs to which the software is updated in the present embodiment has at least the same configuration as the control program 130 shown in FIG. 4B.
The control program 130 that realizes the functions of the ECU 13 is stored in the FROM 1313 of the microcomputer 131 and executed by the CPU 1311. In FIG. 4B, a functional group is represented as a block, and each block may be divided into a plurality of blocks, or some blocks may be integrated. Further, the control program may be realized by one software or may be realized by a combination of two or more softwares.

The control program 130 includes an update control unit 13001, a difference / compression restoration unit 13002, an update state management unit 13003, an FROM control unit 13004, a communication control unit 13005, and a control processing unit 13006.
The update control unit 13001 receives an operation command from the gateway 10 and data used for software update via the communication control unit 10005, and controls the difference / compression restoration unit 13002 and the FROM control unit 13004 to control the software update. To do. The difference / compression / restoration unit 13002 restores the latest version of the software, that is, the version 3 software, from the received difference data or compressed data according to the instruction of the update control unit 13001.

The update state management unit 13003 acquires the update state from the update control unit 13001 and stores it in the FROM 1313 as the update state D21. Further, the stored update state D21 is provided to the update control unit 13001. The FROM control unit 13004 writes the latest version of the software to the FROM 1313 according to the instruction of the update control unit 13001. The communication control unit 13005 controls the communication controller 1314 according to the instruction of the update control unit 13001 or the like, and communicates with the device connected to the in-vehicle network 10b. At the time of communication, the CAN frame is analyzed and configured. Further, the communication control unit 13005 generates and analyzes a command based on a diagnostic communication protocol such as UDS. The control processing unit 13006 controls the I / O controller 1315 and controls the sensor / actuator 132 to perform engine control.

FIG. 5 is a configuration diagram showing a configuration example of the FROM of the ECU. Two configurations will be described based on the amount of capacity of the FROM 1313. However, in the following, a large capacity of the FROM 1313 is also referred to as "a large amount of memory", and a small capacity of the FROM 1313 is also referred to as a "small amount of memory". Whether the capacity of the FROM 1313 is large or small, that is, whether the memory of the ECU is large or small depends on the practical amount of the FROM 1313, the size of the program stored in the FROM 1313, the nature of the program stored in the FROM 1313, the tendency of the amount of data stored in the FROM 1313, and the like. Judgment is based on. Generally, an ECU that executes complicated processing is classified as an ECU having a large memory in the present embodiment, and an ECU that executes only a simple processing is classified as an ECU having a small memory in the present embodiment. For example, the engine control ECU 13, the brake control ECU 14, the HVAC ECU 18, the airbag ECU 17, and the like are often classified as an ECU having a small memory, and the automatic operation ECU 15, the ADAS ECU 16 and the like are often classified as an ECU having a large memory.

FIG. 5A is a configuration example of FROM 1313 when the capacity is small.
The FROM 1313 is composed of a program area 1313aP0 and a Data area 1313aD0.
The program area 1313aP0 is composed of a plurality of blocks Block0 to BlockN, and stores the boot loader P1 and the control program P2. The version of this control program P2 is the current version 2 (described as "Ver.2" in the figure). The parameter D2 is stored in the Data area 1313aD0. Parameter D2 includes update state D21 and control parameter D22. The update state D21 is information indicating a state such as the progress of software update, and will be described in detail later. The control parameter D22 is a group of parameters used for the original engine control and brake control of the ECU.

FIG. 5B is a configuration example of FROM 1313 when the capacity is large.
The FROM 1313 is composed of a program area and a Data area 1313bD0. The program area is composed of two areas, namely BANK0 and BANK1, which are referred to as program area 1313bP0 and program area 1313bP1, respectively.

The program area 1313bP0 and the program area 1313bP1 are each composed of a plurality of blocks Block0 to BlockN. The boot loader P3 and the control program P4 are stored in the program area 1313bP0. The version of this control program P4 is the current version 2. Further, the control program P5 is stored in the program area 1313bP1. The version of this control program P5 is version 1 of the old version.
The parameter D3 is stored in the Data area 1313bD0. Parameter D3 includes update state D21, control parameter D22, and activation information D33.
In the start information D33, which of the two program areas to execute the control program recorded is set, and for example, "program area 1313bP0" and "program area 1313bP1" are set. The update state D21 and the control parameter D22 are as described above.

FIG. 6A is a configuration example of the update package 5 acquired by the gateway 10 from the server 2. The update package 5 is composed of update control information 501 and recovery control information 502.
The update control information 501 is composed of one common update control information 5011, one or more ECU update control information 5012, and one or more ECU update data 5013. The ECU update control information 5012 and the ECU update data 5013 exist for each ECU to be updated, and only one common update control information 5011 exists regardless of the number of ECUs to be updated.
The common update control information 5011 includes information such as a procedure and a threshold value used for checking the state of the entire vehicle system. For example, in the common update control information 5011, the ECU ID and CAN required for confirming the remaining battery level, the remaining threshold value that can be started, the presence / absence of HVAC, and the vehicle running state as the state confirmation required for starting the update. Contains ID and confirmation command information.

The ECU update control information 5012 is configured for each ECU to be updated, and the ECU update control information 5012 includes information on check items and update control procedures of each ECU.
The ECU update data 5013 is data used for software update of the ECU configured for each ECU to be updated, and is, for example, software itself, compressed software, or difference data between old and new software.

The recovery control information 502 is composed of one or more ECU recovery control information 5021, and may include one or more ECU recovery data 5022. The ECU recovery control information 5021 exists for each ECU to be updated, and the presence or absence of the ECU recovery data 5022 is determined based on the contents of the ECU recovery control information 5021. That is, the maximum number of ECU recovery data 5022 is the same as that of the ECU recovery control information 5021, and the minimum is zero.
The ECU recovery data 5022 is data to be added when additional data is required for the recovery of the ECU, and includes the software itself, compressed software, backup data generated from the XOR of the software in Block units, and the like.

FIG. 6B is a diagram showing the configuration of the ECU recovery control information 5021. The ECU recovery control information 5021 includes the ECU ID 5021 that identifies the ECU, the start timing 50212 that indicates the timing to start recovery, the display content 50213 that indicates the content to be displayed on the screen on the display device of the HMI 12, the recovery method 50214 that is the recovery method, and It consists of recovery data URI50215 for acquiring additional recovery data.
The ECU ID 50221 is information for identifying the ECU. The recovery start timing 50212 indicates the timing at which the recovery process by the gateway 10 is started. The recovery start timing 50212 is, for example, "immediate" indicating immediately after the system has recovered from an abnormality, "starting running" indicating after starting running and stabilizing the power supply, and then the engine transitions from the operating state to the stopped state. “IGN-OFF” or the like indicating the time is set.

The display content 50213 stores display message information in which a message to be presented to the user when the system recovers from an abnormality, and an outline of the display content are stored. The outline of the displayed contents is, for example, "warning", "warning", and "urgent". Specific examples displayed based on the display content 50213 will be described later.
The recovery method 50214 indicates the procedure for recovering the ECU, and "differential resume", "compression recovery", "server cooperation", "block recovery", and the like are set. "Difference resume" is a recovery processing method that restarts the difference update from the abnormally interrupted location. "Compressed recovery" is a recovery processing method in which compressed software is bundled with recovery control information 502 as ECU recovery data 5022, and the entire software is replaced by using this, so-called full update. "Server cooperation" is a recovery processing method in which compressed software is re-downloaded from the server 2 and so-called full update is performed. In "block recovery", the software is divided into a plurality of blocks, the block XOR data obtained by calculating the XOR of each block is bundled as ECU recovery data 5022, and the missing part of the software is not lost with the block XOR data. This is a recovery processing method that recovers from a block.

The recovery data URI 50215 is set to the URI in which the gateway 10 acquires the recovery data when the recovery method 50214 is "server cooperation". When the recovery method 50214 is other than "server cooperation", the recovery data URI50215 is set to "Null" which means that no information is set. The location where the resource indicated by this URI is stored may be server 2 or other than server 2.

FIG. 7 is a sequence diagram showing the flow of the entire update process for updating the software of the engine control ECU 13. Here, it will be described that only the engine control ECU 13 is the update target, and the other ECUs are not the update targets.
When new software for the engine control ECU 13 is created, the operator of the server 2 prepares to distribute this software to the engine control ECU 13, creates an update package 5, and registers it in the server 2 (S1). The update package 5 may be created by the operator, or may be created by the server 2 based on the created new software and the setting file.

After the preparation for distribution is completed, the gateway 10 downloads the update package 5 from the server 2 via the communication module 11 and holds it in the FROM 102 of the gateway 10 when the engine is started (S2). After that, when the engine state changes from starting to stopping, the version of the engine control ECU 13 to be updated is checked, the state of the ECU to be updated is acquired, and before obtaining the consent of the user using the HMI 12. After performing the process S3, the software update process S4 of the engine control ECU 13 is performed. Finally, the post-processing S5 for confirming the rewriting state of the update target ECU 13 is performed to complete the update process. The start timing of the pre-process S3, software update process S4, and post-process S5, which are update processes, may be immediately after the completion of download process S2, a predetermined time, or the like, in addition to when the engine is stopped. Hereinafter, the software update process represented by reference numeral S4 will be described in detail.

FIG. 8 is a sequence diagram showing a flow of software update processing executed between the gateway 10 and the engine control ECU 13 in step S4 of FIG. 7. Here, an example of updating the engine control ECU 13 is shown, but this operation is basically the same for other ECUs. In FIG. 8, the processing required depending on the situation is indicated by a broken line arrow.
In the following description, it is assumed that the transmission / reception of data in the gateway 10 is performed via the communication control unit 10007, and the transmission / reception of data in the engine control ECU 13 is performed via the communication control unit 13005.

First, the update control unit 10001 of the gateway 10 transmits a session change request to the engine control ECU 13 (S401). This session change request includes special mode identification information for software rewriting. When the update control unit 13001 of the engine control ECU 13 receives the session change request transmitted from the gateway 10 in step S402, the update control unit 13001 shifts the internal state to the mode specified by the session change request, and then sends an acceptance response to the gateway 10. Transmit (S402).

When the update control unit 10001 of the gateway 10 receives the acceptance response transmitted from the engine control ECU 13 in step S402, it records that the update application process is started in the update state D1 via the update state management unit 1003 (S402R). .. Next, the update control unit 10001 of the gateway 10 reads the ECU update control information 5012 via the update data management unit 10002, and starts processing for each processing block described in the ECU update control information 5012. That is, the update control unit 10001 identifies the first processing block described in the ECU update control information 5012, and records the block as a “processing block” in the update state D1 via the update state management unit 1003 (S403R). ..

Then, the update control unit 10001 transmits a data transfer start request for the block to the engine control ECU 13 (S403). This data transfer start request includes, for example, information such as a data format, a data size to be transmitted, and a write destination address indicating a write destination of the transmitted data. When the communication control unit 13005 of the engine control ECU 13 receives the data transfer start request transmitted from the gateway 10 in step S403, the communication control unit 13005 transmits an acceptance response to the gateway 10 (S404). This acceptance response includes information such as a data size that can be received by the engine control ECU 13 at one time. When the update control unit 10001 of the gateway 10 receives this acceptance response, it records a "data transfer start request" as a command that succeeds in the update state D1 via the update state management unit 1003 (S404R).

Next, the update control unit 10001 of the gateway 10 reads the update data corresponding to the block currently being processed from the update data 5013, divides the update data into data sizes that can be received by the engine control ECU 13 at one time, and transmits the update data to the engine control ECU 13. (S405). Here, the transmission data is further divided into CAN frames and transmitted. When the update control unit 13001 of the engine control ECU 13 receives the data transmitted from the gateway 10 in step S405, the update control unit 13001 instructs the difference / compression restoration unit 13002 to start the restoration process S407. This restoration process S407 will be described in detail later. Here, if the restoration process takes a long time, a standby response is transmitted to the gateway 10 (S406). When the restoration process S407 is completed, the update control unit 13001 of the engine control ECU 13 transmits a reception response S408 to the gateway 10. The gateway 10 and the engine control ECU 13 repeat the processes (transfer process S430) from steps S405 to S408 until all the transfer of the update data corresponding to the divided block currently being processed is completed.

When the transfer process S430 is completed, the update control unit 10001 of the gateway 10 records "data transfer" as a command that succeeds in the update state D1 via the update state management unit 1003 (S408R), and sends a transfer completion notification to the engine control ECU 13. (S409). Upon receiving the transfer completion notification transmitted from the gateway 10 in step S409, the update control unit 13001 of the engine control ECU 13 issues a data writing instruction to the FROM control unit 13004 in step S411. In response to this instruction, the FROM control unit 13004 writes the new software or a part thereof, which is restored by the difference / compression restoration unit 13002 and temporarily stored in the SRAM 1312 or the FROM 1313, to the FROM 1313. Here, if it takes time to write the data to the FROM 1313, a standby response is transmitted to the gateway 10 (S410). When the update control unit 13001 succeeds in writing to the FROM 1313, the update control unit 13003 records the block written as a completed block in the update state D21 (S411R) via the update state management unit 13003, and transmits an acceptance response to the gateway 10. (S412).

When the update control unit 10001 of the gateway 10 receives the acceptance response transmitted from the engine control ECU 13 in step S412, it records in the update state D1 that the rewriting process of the block is completed via the update state management unit 1003. S412R). The gateway 10 and the engine control ECU 13 repeat the processes (block restoration / write process S420) from steps S403R to S412R until all the transfer and write processes corresponding to all the blocks to be processed are completed. When the restoration / writing process S420 of all the blocks to be processed is completed, the update control unit 10001 of the gateway 10 records that the rewrite process is completed in the update state D1 via the update state management unit 1003 (S415R).

Next, the update control unit 10001 of the gateway 10 transmits a session change request to the engine control ECU 13 (S413). This session change request includes the identification information of the normal mode for returning to the normal mode. When the update control unit 13001 of the engine control ECU 13 receives the session change request transmitted from the gateway 10 in step S413, the update control unit 13001 shifts the internal state to the normal mode specified in the session change request, and then makes an acceptance response to the gateway 10. Is transmitted (S414).
In this way, by sequentially recording the update status, after the update is interrupted, when it is restored to normal and started, the update is interrupted without being completed, and how far the update has been interrupted can be determined. It can be recognized and the appropriate recovery process can be started.

FIG. 9 is a conceptual diagram showing the processing of the restoration processing S407 in the ECU.
FIG. 9A is a conceptual diagram showing the processing of the restoration processing S407 in the ECU having a small memory. Upon receiving the restoration instruction from the update control unit 13001, the difference / compression restoration unit 13002 receives from the gateway 10 and reads a part of the update data 5013a stored in the SRAM 1312. In the case of compressed update, since the update data is compressed, it is decompressed and output to the restoration area D5 as the version 3 control program P22. In the case of differential update, since the update data is differential data, the differential / compression restoration unit 13002 first reads a part or all of the current version 2 control program P21 necessary for restoration. Then, the difference / compression restoration unit 13002 combines these to restore the version 3 control program P22 and outputs it to the restoration area D5.

In the present embodiment, the restoration area D5 is secured in the Data area 1313aD0 of the FROM 1313, but may be secured in, for example, an empty area of the program area (BlockN of 1313aP0) or SRAM 1312. When the data area 1313aD0 of the FROM 1313 or the free area of the program area (BlockN of 1313aP0) is used as the restore area D5, even if the update is interrupted during the erasing / writing of Flash, it can be restarted from the middle. However, depending on the specifications of the microcomputer 131, it may take time to access the Data area 1313a and the update time may become long. Further, depending on the specifications of the microcomputer 131, the empty area of the software may be rewritten less frequently. Further, when SRAM 1312 is used as a restoration area, if it is interrupted at the time of Flash write processing S411, recovery processing by differential resume cannot be performed. In the restored version 3 control program P22, in the Flash writing process S411 of FIG. 8, the update control unit 13001 overwrites the corresponding area of the FROM 1313 via the FROM control unit 13004. In FIG. 9A, the update control unit 13001 and the FROM control unit 13004 are not shown.

As described above, by sequentially restoring the received data, the difference update can be performed without accumulating all the difference data necessary for reconstructing the version 3 control program P22.
However, if the difference data is sufficiently small and can be stored in the surplus area of the memory, it is not always necessary to sequentially restore according to this procedure, and the restoration process may be started after receiving all the data. However, in either case, it is necessary to overwrite the running control program, so if the update is interrupted, the control program will not operate normally.

FIG. 9B is a conceptual diagram showing the processing of the restoration processing S407 in an ECU having a large amount of memory. Upon receiving the restoration instruction from the update control unit 13001, the difference / compression restoration unit 13002 receives the restoration instruction from the gateway 10 and reads out a part of the update data 5013b stored in the SRAM 1312. In the case of compressed update, since the update data is compressed software, it is decompressed and output to the restoration area D100 as the version 3 control program P52. In the present embodiment, the restoration area D100 is secured in the SRAM 1312. In the case of differential update, since the update data is differential data, the differential / compression restoration unit 13002 reads a part or all of the current control program P4 required for restoration, and combines these to control program P52 of version 3. Is restored and output to the restored area D100. In the restored new software P52, in the Flash writing process S411 of FIG. 8, the update control unit 13001 overwrites the corresponding area of the FROM 1313 via the FROM control unit 13004. Here, the version 3 control program P52 overwrites the BANK1 version 1 control program P51. Further, here, the update control unit 13001 and the FROM control unit 13004 are not shown.
As described above, when updating the ECU equipped with the memory for storing two control programs, the storage area of the control program is duplicated, and the area for storing the currently executed control program is used. By restoring and storing the control program in another area, even if the update is interrupted, the running control program is not damaged and normal operation can be continued.

FIG. 10 is an example of an ECU activation sequence.
FIG. 10A is a start-up sequence diagram of an ECU having a small memory.
In the ECU with a small memory, the boot loader P1 is started first (S601). The boot loader P1 verifies the control program P2 stored in the program area (S602). As a result of the verification, if it is determined that there is no problem in the control program P2 (S603: YES), the control program P2 is started (S604). Further, as a result of the verification, if it is determined that there is a problem in the control program P2, the control program P2 is not executed and the gateway 10 waits for a control instruction as an emergency mode (S605). At this time, the Block Size, which is a transfer parameter defined by ISO 15765-2, may be set to 0 as a setting peculiar to the emergency mode, and burst transfer of CAN frames may be performed. As a result, communication efficiency can be improved. The case where it is determined that there is a problem in the control program P2 is, for example, a case where the software does not exist or a case where the verification result is abnormal.

FIG. 10B is a start-up sequence diagram of an ECU having a large amount of memory.
In an ECU having a large memory, the boot loader P3 is started first (S651). The boot loader P3 reads the start information D33 in the parameter D3 of the Data area 1313bD0 (S652) and executes the control program recorded in the start information D33 (S653). For example, when the start information D33 is "program area 1313bP0", the version 2 control program P4 on the program area 1313bP0 is executed.

FIG. 11 is a flowchart showing a recovery control process performed by the gateway 10 at startup.
When the gateway 10 is activated, the recovery control unit 1004 of the gateway 10 acquires the update start state D102 recorded in the update state D1 via the update state management unit 1003 (S701). When the recovery control unit 1004 determines that there is no ECU for which the update has been started, that is, there is no interrupted update (S702: NO), the recovery control unit 1004 performs a normal gateway 10 activation process (S713).

When it is determined that there is an ECU for which the update has been started, that is, there is an interrupted update (S702: YES), the recovery control unit 1004 notifies the server 2 that there is an interrupted update (S703). Then, the recovery control unit 1004 acquires the start timing 50212 from the ECU recovery control information 5021 corresponding to the ECU ID via the recovery control information management unit 10055 (S704).
When it is determined that the start timing 50212 is "immediate" (S705: YES), an "emergency" screen display command is output to the HMI 12 according to the display content 50213 of the recovery control information 5021 (S706), and the recovery process is performed. Start (S707). However, in this case, in order to start the recovery process as soon as possible, the command to the HMI 12 may be after the recovery process is started, or the two processes may be executed at the same time. Details of the recovery process S707 will be described later.

If the start timing 50212 is other than "immediate", the display content 50213 of the recovery control information 5021 is acquired (S708), and if it is determined that the display content is "warning", the "warning" screen is displayed on the HMI 12. Make a display request (S710).
On the other hand, when it is determined that the displayed content is "warning", a screen display request for "warning" is made to HMI 12 (S711). After transmitting the screen display request, it waits for an update start trigger such as running start or IGN-OFF (S712). After that, when the occurrence of the trigger event for starting the update is detected, the recovery process is started (S707). When the recovery process S707 is completed, a normal startup process is performed (S713).

FIG. 12 is a flowchart showing an example of the recovery process S707 according to the first embodiment.
The recovery control unit 1004 of the gateway 10 acquires the recovery method 50214 from the recovery control information 5021 corresponding to the ECU ID via the recovery control information management unit 10055 (S70701), and proceeds to step S70702.
When it is determined that the recovery method 50214 is "difference resume" (S70702: YES), the recovery control unit 1004 acquires the processing block recorded in the update state D1 via the update state management unit 1003 (S70703). , The difference update process is restarted from the block with the ECU (S70704).

When it is determined that the recovery method 50214 is not "difference resume" (S70702: NO), the recovery control unit 1004 determines whether or not the recovery method 50214 is "server cooperation". When it is determined that the recovery method 50214 is "server cooperation" (S70705: YES), the recovery control unit 1004 receives the recovery data URI50215 from the recovery control information 5021 corresponding to the ECU ID via the recovery control information management unit 10055. (S70706), and the compressed data is acquired as recovery data from the URI (S70707).

When it is determined that the recovery method 50214 is not "server cooperation" (S70705: NO), the recovery control unit 1004 determines whether or not the recovery method 50214 is "compressed recovery". When it is determined that the recovery method 50214 is "compressed recovery" (S70709: YES), the recovery control unit 1004 receives the compressed data from the ECU recovery data 5022 corresponding to the ECU ID via the recovery control information management unit 10055. Acquire (S70710).
The recovery control unit 1004 acquires the compressed data in step S70707 or S70710, and then performs a recovery process with the ECU using the acquired compressed data (S70708).

When it is determined that the recovery method 50214 is not "compressed recovery" (S70709: NO), the recovery control unit 1004 passes through the recovery control information management unit 10055 and blocks XOR data from the ECU recovery data 5022 corresponding to the ECU ID. (S70711), and a recovery process by block recovery is performed with the ECU (S70712).
In this way, by executing the recovery control process when an update abnormality occurs based on the recovery control information 502 transmitted from the server 2 together with the update control information 501 as the update package 5, it is composed of a large number of ECUs having different resources and characteristics. Even if an update error occurs in the system, recovery is started at an appropriate timing according to the impact on the vehicle system, the impact on the system due to the interruption of the update is accurately communicated to the user, and the characteristics of the ECU to be updated The software can be updated normally by executing the recovery process according to the recovery sequence.

(Operation example)
Hereinafter, an operation example of the recovery process of the automatic operation ECU 15, the ADAS ECU 16, the engine control ECU 13, the brake control ECU 14, the HVAC ECU 18, and the airbag ECU 17 will be described with reference to FIGS. 13 to 24.

(Operation example-Automatic operation ECU)
The configuration of the update package 5a corresponding to the automatic operation ECU 15, the display example on the HMI 12, and the operation sequence will be described with reference to FIGS. 13 and 14.
FIG. 13A is a diagram showing the configuration of the update package 5a when the update target is only the automatic operation ECU 15, and FIG. 13B is a diagram showing the configuration of the automatic operation ECU recovery control information 5021a included in the update package 5a. 13 (c) is a diagram showing a display example of the HMI 12 based on the automatic operation ECU recovery control information 5021a.

As shown in FIG. 13A, the update package 5a in the case where the update target is only the automatic operation ECU 15 includes update control information 5011, automatic operation ECU update control information 5012a, and automatic operation ECU update data 5013a. It is composed of 501a and recovery control information 502a including automatic operation ECU recovery control information 5021a.
As shown in FIG. 13B, the automatic operation ECU recovery control information 5021a is set to "automatic operation ECU" in the ECU ID 50221a, "running start" is set in the start timing 50212a, and the display content 50213a is set. "Caution" and display message information (not shown) are set, "difference resume" is set in the recovery method 50214a, and "NUML" meaning that no information is set is set in the recovery data URI50215a. ..

The recovery control unit 1004 causes the display device of the HMI 12 to output the screen display G10a shown in FIG. 13C based on the display content 50213a. This screen display G10a notifies the user that the software update has been interrupted and the updated function cannot be used as the function restricted state of the vehicle 1 due to the recovery process, and the interrupted update is automatically applied. It is a reminder that it will be done.

FIG. 14 is a sequence diagram showing an example of recovery processing of the automatic operation ECU 15. For example, when the update process of the automatic operation ECU 15 is interrupted due to the power supply to the gateway 10 being cut off and the power supply is restarted, the recovery process is executed as follows. The automatic operation ECU 15 is classified into an ECU having a large amount of memory, and can store two control programs as shown in FIG. 5 (b).
When the gateway 10 is activated, the process shown in FIG. 11 is started. That is, first, in step S901a, it is confirmed whether or not there is an interrupted update (S701 and S702 in FIG. 11 and S901a in FIG. 14).

Further, in parallel with the processing of the gateway 10, the automatic operation ECU 15 performs the activation processing shown in FIG. 10B. Here, since the update is interrupted, the start information D33 has not been rewritten yet, and the start of the control program recorded in the program area 1313bP0 is specified, the automatic operation ECU 15 starts the current version 2 control program P4. To do.
When the gateway 10 determines that the update of the automatic operation ECU 15 is interrupted from the update start state D102 of the update state D21 (S901a), the gateway 10 performs the following processing in step S903a. That is, the gateway 10 reads the start timing 50212a from the automatic operation ECU recovery control information 5021a corresponding to the automatic operation ECU 15, and determines that the timing to start the recovery process of the automatic operation ECU 15 is after the start of traveling.

Next, in step S904a, the gateway 10 reads the display content 50213a from the automatic operation ECU recovery control information 5021a, and issues a request to the HMI 12 to display a warning screen based on the display content 50213a. Based on this request, the HMI 12 displays the attention alert screen illustrated in G10a of FIG. 13C on the display device (S905a). When the gateway 10 detects the start of travel, which is a trigger to start the recovery process in step S906a, it reads the recovery method 50214a of the automatic operation ECU recovery control information 5021a, and determines that the recovery process method is "difference resume" ( S907a). As described above, the recovery by "differential resume" is a method in which when the differential update is interrupted, the update can be completed in a short time by restarting the differential update from the interrupted block. The gateway 10 reads the processing block D103 in the update state D21 in order to determine the point at which the resume starts (S908a). After determining the block to start the resume, the gateway 10 executes the software update process S4 of FIG. 8 from the block in step 909a to complete the update of the automatic operation ECU 15.

When the control program has abundant memory like the automatic operation ECU 15 and the control program can be duplicated, the updated control program is restored or stored in an area different from the area where the control program currently being executed is stored. It has the following advantages because it can be used. That is, even if the update is interrupted, the running control program is not damaged, and normal operation can be maintained by starting the running control program at the time of restart. Therefore, by configuring the recovery control information 502a as described above and using it, the gateway 10 does not have to complete the update immediately even if the update of the automatic operation ECU 15 is interrupted, and the gateway 10 does not have to complete the update immediately during the next run. You can restart the update.
The gateway 10 notifies the user that the update has been interrupted and that the interrupted update is automatically restarted during traveling by displaying a warning screen on the HMI 12. Further, since the update status is recorded in the update status D1, the recovery execution can be started from the interruption point, that is, the update can be restarted, and the update can be completed quickly.
In the above-mentioned example, an example of displaying a warning screen when the update of the automatic operation ECU 15 is interrupted is shown. However, for example, when the update of the automatic driving ECU 15 is performed completely in the background while the vehicle is running and is completed without the user being aware of it, the warning screen may be controlled so as not to be displayed. In this case, the display content 50213a in FIG. 13 is set to "no screen display" instead of "attention".

(Operation example-ADAS ECU)
15 and 16 will be used to describe the configuration of the update package 5b corresponding to the ADAS ECU 16, a display example on the HMI 12, and an operation sequence.
FIG. 15A is a diagram showing the configuration of the update package 5b when the update target is only the ADAS ECU 16, and FIG. 15B is a diagram and a diagram showing the configuration of the ADAS ECU recovery control information 5021b included in the update package 5b. FIG. 15 (c) is a diagram showing a display example of the HMI 12 based on the ADAS ECU recovery control information 5021b.

As shown in FIG. 15A, the update package 5b when the update target is only the ADAS ECU 16 includes the common update control information 5011, the ADAS ECU update control information 5012b, and the update control information 501b including the ADAS ECU update data 5013b. It is composed of recovery control information 502b including ADAS ECU recovery control information 5021b.
As for the ADAS ECU recovery control information 5021b, as shown in FIG. 15B, "ADAS ECU" is set in the ECU ID 50221b, "IGN-OFF" is set in the start timing 50212b, and "IGN-OFF" is set in the display content 50213b. "Caution" and display message information (not shown) are set, "difference resume" is set in the recovery method 50214b, and "NUML" meaning that no information is set in the recovery data URI50215b is set.

The recovery control unit 1004 causes the display device of the HMI 12 to output the screen display G10b shown in FIG. 15C based on the display content 50213b. This screen display G10b notifies the user that the software update has been interrupted and the updated function cannot be used as the function restricted state of the vehicle 1 due to the recovery process, and the interrupted update is next to IGN. -OFF, that is, a reminder that the ignition is applied when the ignition is turned off.

FIG. 16 is a sequence diagram showing an example of recovery processing of the ADAS ECU 16. For example, when the update process of the ADAS ECU 16 is interrupted due to the power supply to the gateway 10 being cut off and the power supply is restarted, the recovery process is executed as follows. The ADAS ECU 16 is classified into an ECU having a large amount of memory, and can store two control programs as shown in FIG. 5 (b).
When the gateway 10 is activated, the process shown in FIG. 11 is started. That is, first, in step S901b, it is confirmed whether or not there is an interrupted update (S701 and S702 in FIG. 11 and S901b in FIG. 16).

Further, in parallel with the processing of the gateway 10, the ADAS ECU 16 performs the activation processing shown in FIG. 10B. Here, since the update is interrupted, the start information D33 has not been rewritten yet, and the start of the control program recorded in the program area 1313bP0 is specified, the ADAS ECU 16 starts the current version 2 control program P4. ..
When the gateway 10 determines that the update of the ADAS ECU 16 is interrupted from the update start state D102 of the update state D21 (S901b), the gateway 10 performs the following processing in step S903b. That is, the gateway 10 reads the start timing 50212b from the ADAS ECU recovery control information 5021b corresponding to the ADAS ECU 16, and determines that the timing for starting the recovery process of the ADAS ECU 16 is IGN-OFF.

Next, in step S904b, the gateway 10 reads the display content 50213b from the ADAS ECU recovery control information 5021b, and issues a request to the HMI 12 to display a warning screen based on the display content 50213b. Based on this request, the HMI 12 displays the attention alert screen illustrated in G10b of FIG. 15C on the display device (S905b). When the ignition OFF signal, which is a trigger for starting the recovery process in step S906b, is input from the vehicle 1, the gateway 10 detects this (S907b), reads the recovery method 50214b of the ADAS ECU recovery control information 5021b, and recovers. It is determined that the processing method is "difference resume" (S908b). As described above, the recovery by "differential resume" is a method in which when the differential update is interrupted, the update can be completed in a short time by restarting the differential update from the interrupted block. The gateway 10 reads the processing block D103 in the update state D21 in order to determine the point at which the resume starts (S909b). After determining the block to start the resume, the gateway 10 executes the software update process S4 of FIG. 8 from the block in step 910b to complete the update of the ADAS ECU 16.

Since the ADAS ECU 16 also has abundant memory like the automatic operation ECU 15, it has the same advantages as the automatic operation ECU 15.
The gateway 10 informs the user that the update has been interrupted and that the interrupted update is restarted by the ignition off by displaying a warning screen on the HMI 12. Further, since the update status is recorded in the update status D1, the recovery execution can be started from the interruption point, that is, the update can be restarted, and the update can be completed quickly.

(Operation example-Engine control ECU)
The configuration of the update package 5c corresponding to the engine control ECU 13, the display example on the HMI 12, and the operation sequence will be described with reference to FIGS. 17 and 18.
FIG. 17A is a diagram showing the configuration of the update package 5c when the update target is only the engine control ECU 13, and FIG. 17B is a diagram showing the configuration of the engine control ECU recovery control information 5021c included in the update package 5c. 17 (c) is a diagram showing a display example of HMI 12 based on engine control ECU recovery control information 5021c.

As shown in FIG. 17A, the update package 5c when the update target is only the engine control ECU 13 includes update control information 5011, engine control ECU update control information 5012c, and engine control ECU update data 5013c. It is composed of 501c and recovery control information 502c including engine control ECU recovery control information 5021c.
As shown in FIG. 17B, the engine control ECU recovery control information 5021c is set to "engine control ECU" in the ECU ID 50221c, "immediate" is set in the start timing 50212c, and "immediate" is set in the display content 50213c. "Urgent" and non-illustrated display message information are set, "difference resume" is set in the recovery method 50214c, and "NULL" meaning that no information is set is set in the recovery data URI50215c.

The recovery control unit 1004 causes the display device of the HMI 12 to output the screen display G10c shown in FIG. 17C based on the display content 50213c. This screen display G10c notifies the user that the software update is interrupted and the vehicle 1 cannot be used as the function restricted state of the vehicle 1 due to the recovery process, and the interrupted update is being recovered immediately. Is shown.

FIG. 18 is a sequence diagram showing an example of recovery processing of the engine control ECU 13. For example, when the update process of the engine control ECU 13 is interrupted due to the power supply to the gateway 10 being cut off and the power supply is restarted, the recovery process is executed as follows. The engine control ECU 13 is classified into an ECU having a small memory, and as shown in FIG. 5A, only one control program can be stored.
When the gateway 10 is activated, the process shown in FIG. 11 is started. That is, first, in step S901c, it is confirmed whether or not there is an interrupted update (S701 and S702 in FIG. 11 and S901c in FIG. 18).

Further, in parallel with the processing of the gateway 10, the engine control ECU 13 performs the activation processing shown in FIG. 10A. Here, since the update is interrupted and a part of the current version 2 control program is overwritten by a part of the version 3 control program, a problem occurs in the verification of the control program P2 and it is urgent. It is started in the mode (S902c).
When the gateway 10 determines that the update of the engine control ECU 13 is interrupted from the update start state D102 of the update state D21 (S901c), the gateway 10 performs the following processing in step S903c. That is, the gateway 10 reads the start timing 50212c from the engine control ECU recovery control information 5021c corresponding to the engine control ECU 13, and determines that the timing to start the recovery process of the engine control ECU 13 is immediate.

Next, the gateway 10 reads the display content 50213c from the engine control ECU recovery control information 5021c in step S904c, and issues a request to the HMI 12 to display an emergency screen based on the display content 50213c. Based on this request, the HMI 12 displays an emergency screen illustrated in G10c of FIG. 17 (c) on the display device (S905c). Since the gateway 10 starts the recovery process immediately, when an emergency screen display request is issued to the HMI 12 in step S904c, the recovery method 50214c of the engine control ECU recovery control information 5021c is immediately read, and the recovery process method is "difference". It is determined to be "resume" (S906c). The gateway 10 reads the processing block D103 in the update state D21 in order to determine the point at which the resume starts in step S907c. After determining the block to start the resume, the gateway 10 executes the software update process S4 of FIG. 8 from the block in step 908c to complete the update of the engine control ECU 13.

In the case of an ECU having a small memory such as the engine control ECU 13, it is necessary to update while overwriting a single control program. Therefore, if the update is interrupted, the control program cannot operate normally. Therefore, if the update of the engine control ECU 13 is interrupted, the engine cannot be controlled and the vehicle cannot travel. By configuring the recovery control information 502c as described above and using the recovery control information 502c, the gateway 10 determines that when the update of the engine control ECU 13 is interrupted, it is necessary to immediately restart the interrupted update. Further, the gateway 10 informs the user that the vehicle cannot be used and that the restart of the interrupted update is immediately started by displaying an emergency screen on the HMI 12. Further, since the update status is recorded in the update status D1, the recovery execution can be started from the interruption point, that is, the update can be restarted, and the update can be completed quickly.

(Operation example-Brake control ECU)
A configuration of the update package 5d corresponding to the brake control ECU 14, a display example on the HMI 12, and an operation sequence will be described with reference to FIGS. 19 and 20.
FIG. 19A is a diagram showing the configuration of the update package 5d when the update target is only the brake control ECU 14, and FIG. 19B is a diagram showing the configuration of the brake control ECU recovery control information 5021d included in the update package 5d. 19 (c) is a diagram showing a display example of the HMI 12 based on the brake control ECU recovery control information 5021d.

As shown in FIG. 19A, the update package 5d when the update target is only the brake control ECU 14 includes update control including common update control information 5011, brake control ECU update control information 5012d, and brake control ECU update data 5013d. It is composed of information 501d, brake control ECU recovery control information 5021d, and recovery control information 502d including brake control ECU recovery data 5022d.
As for the brake control ECU recovery control information 5021d, as shown in FIG. 19B, "brake control ECU" is set in the ECU ID 50221d, "immediate" is set in the start timing 50212d, and "immediate" is set in the display content 50213d. "Urgent" and not shown display message information are set, "compressed recovery" is set in the recovery method 50214d, and "NULL" meaning that no information is set in the recovery data URI50215d is set.

The recovery control unit 1004 causes the display device of the HMI 12 to output the screen display G10d shown in FIG. 19C based on the display content 50213d. This screen display G10d notifies the user that the software update is interrupted and the vehicle 1 cannot be used as the function restricted state of the vehicle 1 due to the recovery process, and the interrupted update is being recovered immediately. Is shown.

FIG. 20 is a sequence diagram showing an example of recovery processing of the brake control ECU 14. For example, when the update process of the brake control ECU 14 is interrupted due to the power supply to the gateway 10 being cut off and the power supply is restarted, the recovery process is executed as follows. The brake control ECU 14 is classified into an ECU having a small memory, and as shown in FIG. 5A, only one control program can be stored.
When the gateway 10 is activated, the process shown in FIG. 11 is started. That is, first, in step S901d, it is confirmed whether or not there is an interrupted update (S701 and S702 in FIG. 11 and S901d in FIG. 20).

Further, in parallel with the processing of the gateway 10, the brake control ECU 14 performs the activation processing shown in FIG. 10A. Here, since the update is interrupted and a part of the current version 2 control program is overwritten by a part of the version 3 control program, a problem occurs in the verification of the control program P2 and it is urgent. It is started in the mode (S902d).
When the gateway 10 determines that the update of the brake control ECU 14 is interrupted from the update start state D102 of the update state D21 (S901d), the gateway 10 performs the following processing in step S903d. That is, the gateway 10 reads the start timing 50212d from the brake control ECU recovery control information 5021d corresponding to the brake control ECU 14, and determines that the timing to start the recovery process of the brake control ECU 14 is immediate.

Next, the gateway 10 reads the display content 50213d from the brake control ECU recovery control information 5021d in step S904d, and issues a request to the HMI 12 to display an emergency screen based on the display content 50213d. Based on this request, the HMI 12 displays an emergency screen illustrated in G10d of FIG. 19 (c) on the display device (S905c). Since the gateway 10 immediately starts the recovery process, when an emergency screen display request is issued to the HMI 12 in step S904d, the recovery method 50214d of the brake control ECU recovery control information 5021d is immediately read, and the recovery process method is "compressed". It is determined to be "recovery" (S906d). As described above, the recovery by the "compression recovery" method is a method of reliably recovering by writing the entire area of the software or writing the damaged area, that is, repairing, using the compressed data of the software. .. In step S907d, the gateway 10 reads the brake control ECU recovery data 5022d, which is the compressed data of the version 3 control program included in the update package 5d. Then, the gateway 10 executes the software update process S4 of FIG. 8 using the read brake control ECU recovery data 5022d, and completes the update of the brake control ECU 14.

Since the brake control ECU 14 also has a small memory like the engine control ECU 13, the recovery control information 502c is configured as described above, and by using this, the gateway 10 updates the interrupted update when the update of the brake control ECU 14 is interrupted. Judge that it is necessary to restart immediately. Further, the gateway 10 informs the user that the vehicle cannot be used and that the restart of the interrupted update is immediately started by displaying an emergency screen on the HMI 12. Further, by including the compressed data of the version 3 control program as the brake control ECU recovery data 5022d and repairing the control program, the following problems of the differential resume can be avoided. That is, in the differential resume, there is a problem that the processing time becomes long by using the Data area 1313a as the restoration area, and there is a problem that the program area which may have a small number of rewrites is used. Then, these problems can be avoided. Further, in the block recovery described later, if the ECU is interrupted again during software restoration, the subsequent restoration cannot be performed, but in the case of restoration by compressed data, it is possible to deal with the interruption again.

(Operation example-HVAC ECU)
21 and 22 will be used to describe the configuration of the update package 5e corresponding to the HVAC ECU 18, a display example on the HMI 12, and an operation sequence.
21 (a) is a diagram showing the configuration of the update package 5e when the update target is only the HVAC ECU 18, and FIG. 21 (b) is a diagram and a diagram showing the configuration of the HVAC ECU recovery control information 5021e included in the update package 5e. 21 (c) is a diagram showing a display example of the HMI 12 based on the HVAC ECU recovery control information 5021e.

As shown in FIG. 21A, the update package 5e when the update target is only the HVAC ECU 18 includes the common update control information 5011, the HVAC ECU update control information 5012e, and the update control information 501e including the HVAC ECU update data 5013e. It is composed of recovery control information 502e including HVAC ECU recovery control information 5021e.
As shown in FIG. 21B, the HVAC ECU recovery control information 5021e is set to "HVAC ECU" in the ECU ID 50221e, "IGN-OFF" is set in the start timing 50212e, and "IGN-OFF" is set in the display content 50213e. "Warning" and display message information (not shown) are set, "server cooperation" is set for the recovery method 50214e, and recovery data is stored in the recovery data URI 50215e "htttps: //example.jp/". "data" is set.

The recovery control unit 1004 causes the display device of the HMI 12 to output the screen display G10e shown in FIG. 21 (c) based on the display content 50213e. This screen display G10e notifies the user that the software update is interrupted and the HVAC function cannot be used as the function restricted state of the vehicle 1 due to the recovery process, and communication with the server 2 is required for the recovery. This is a warning indicating that.

FIG. 22 is a sequence diagram showing an example of recovery processing of the HVAC ECU 18. For example, when the update process of the HVAC ECU 18 is interrupted due to the power supply to the gateway 10 being cut off and the power supply is restarted, the recovery process is executed as follows. The HVAC ECU 18 is classified into an ECU having a small memory, and as shown in FIG. 5A, only one control program can be stored.
When the gateway 10 is activated, the process shown in FIG. 11 is started. That is, first, in step S901e, it is confirmed whether or not there is an interrupted update (S701 and S702 in FIG. 11 and S901e in FIG. 22).

Further, in parallel with the processing of the gateway 10, the HVAC ECU 18 performs the activation processing shown in FIG. 10A. Here, since the update is interrupted and a part of the current version 2 control program is overwritten by a part of the version 3 control program, a problem occurs in the verification of the control program P2 and it is urgent. It is started in the mode (S902e).
When the gateway 10 determines that the update of the HVAC ECU 18 is interrupted from the update start state D102 of the update state D21 (S901e), the gateway 10 performs the following processing in step S903e. That is, the gateway 10 reads the start timing 50212e from the HVAC ECU recovery control information 5021e corresponding to the HVAC ECU 18, and determines that the ignition OFF timing is when the recovery process of the HVAC ECU 18 is started.

Next, the gateway 10 reads the display content 50213e from the HVAC ECU recovery control information 5021e in step S904e, and issues a request to the HMI 12 to display a warning screen based on the display content 50213e. Based on this request, the HMI 12 displays a warning screen illustrated in G10e of FIG. 21 (c) (S905e).

When the gateway 10 receives the ignition OFF signal (step S906e), it detects this (S907e). Then, the recovery method 50214e of the HVAC ECU recovery control information 5021e is read out, and it is determined that the recovery processing method is "server cooperation" (S908e). As described above, the recovery by the "server cooperation" method is a method of acquiring the data necessary for completing or rolling back the interrupted update from the server 2 at the time of recovery. When the communication module 11 detects that communication with the server 2 has been enabled, the gateway 10 receives this notification from the communication module 11 (S909e). Then, the gateway 10 transmits a recovery data acquisition request to the recovery data URI50215d of the server 2 via the communication module 11 (step 910e), and receives the recovery data (S911e). Further, the gateway 10 performs an update process using the received recovery data (S912e), and completes the update of the HVAC ECU 18.

Like the engine control ECU 13 and the brake control ECU 14, the HVAC ECU 18 also has a small memory and needs to be updated while overwriting a single control program. Therefore, if the update is interrupted, the control program cannot operate normally. Therefore, when the update of the HVAC ECU 18 is interrupted, the HVAC control cannot be performed, but the influence on the running of the vehicle 1 is small. When the recovery control information 502e is configured as described above and the gateway 10 interrupts the update of the HVAC ECU 18, it is not necessary to immediately control the HVAC ECU 18 to complete the update, and the server 2 is linked by the server. After downloading the necessary data from, the update will be restarted when the next ignition is turned off. In addition, the gateway 10 indicates that the HVAC function cannot be used because the update is interrupted, that it is necessary to move to a communicable environment in order to restart the update, and that the restart of the interrupted update can be started when the ignition is turned off. Is transmitted to the user by displaying a warning screen on the HMI 12.

Further, the gateway 10 can acquire the data used for the recovery process from the URI described in the recovery data URI50215. Furthermore, by configuring the system to acquire the necessary recovery data from the server and repair the ECU software only when an abnormality occurs infrequently, additional memory for storing the recovery data and backup data in the gateway 10 and the ECU can be provided. There is no need to prepare, and the system can be built at low cost.

(Operation example-airbag ECU)
The configuration of the update package 5f corresponding to the airbag ECU 17, the display example on the HMI 12, and the operation sequence will be described with reference to FIGS. 23 and 24.
FIG. 23 (a) is a diagram showing the configuration of the update package 5f when the update target is only the airbag ECU 17, and FIG. 23 (b) is a diagram showing the configuration of the airbag ECU recovery control information 5021f included in the update package 5f. 23 (c) is a diagram showing a display example of the HMI 12 based on the airbag ECU recovery control information 5021f.

As shown in FIG. 23A, the update package 5f when the update target is only the airbag ECU 17 is the update control information including the common update control information 5011, the airbag ECU update control information 5012f, and the airbag ECU update data 5013f. It is composed of 501f, recovery control information 502f including airbag ECU recovery control information 5021f, and airbag ECU recovery data 5022f.
As for the airbag ECU recovery control information 5021f, as shown in FIG. 23B, "airbag ECU" is set in the ECU ID 50221f, "IGN-OFF" is set in the start timing 50212f, and the display content 50213f is set. Is set with "warning" and display message information (not shown), "block recovery" is set for the recovery method 50214f, and "NULL" is set, which means that no information is set for the recovery data URI50215f. ..

The recovery control unit 1004 causes the display device of the HMI 12 to output the screen display G10f shown in FIG. 23 (c) based on the display content 50213f. This screen display G10f notifies the user that the software update has been interrupted and the airbag cannot be used as the function restricted state of the vehicle 1 due to the recovery process, and the timing for restarting the interrupted update is the next ignition. Indicates that the timing is OFF.

FIG. 24 is a sequence diagram showing an example of recovery processing of the airbag ECU 17. For example, when the update process of the airbag ECU 17 is interrupted due to the power supply to the gateway 10 being cut off and the power supply is restarted, the recovery process is executed as follows. The airbag ECU 17 is classified into an ECU having a small memory, and as shown in FIG. 5A, only one control program can be stored.
When the gateway 10 is activated, the process shown in FIG. 11 is started. That is, first, in step S901f, it is confirmed whether or not there is an interrupted update (S701 and S702 in FIG. 11 and S901f in FIG. 24).

Further, in parallel with the processing of the gateway 10, the airbag ECU 17 performs the activation processing shown in FIG. 10A. Here, since the update is interrupted and a part of the current version 2 control program is overwritten by a part of the version 3 control program, a problem occurs in the verification of the control program P2 and it is urgent. It is started in the mode (S902f).
When the gateway 10 determines that the update of the airbag ECU 17 is interrupted from the update start state D102 of the update state D21 (S901f), the gateway 10 performs the following processing in step S903f. That is, the gateway 10 reads the start timing 50212f from the airbag ECU recovery control information 5021f corresponding to the airbag ECU 17, and determines that the ignition OFF timing is when the recovery process of the airbag ECU 17 is started.

Next, the gateway 10 reads the display content 50213f from the airbag ECU recovery control information 5021f in step S904f, and issues a request to the HMI 12 to display a warning screen based on the display content 50213f. Based on this request, the HMI 12 displays a warning screen illustrated in G10f of FIG. 23 (c) (S905f). When the gateway 10 receives the ignition OFF signal, which is a trigger for starting the recovery process (S906f), the gateway 10 detects this (S907f). Then, the gateway 10 reads the recovery method 50214f of the airbag ECU recovery control information 5021f, determines that the recovery processing method is "block recovery" (S908f), and determines that the airbag ECU recovery data included in the update package 5f. Read 5022f (S909f).

The gateway 10 reads the processing block D103 in the update state D21 in order to determine the point at which the resume starts in step S910f. After determining the block to start the resume, the gateway 10 executes the software update process S4 of FIG. 8 from the block next to the block in step 911f, and completes the update of the airbag ECU 17 other than the interrupted block. In step S912f, the gateway 10 transmits the recovery data acquired in step S909f to the airbag ECU 17. In step S913f, the airbag ECU 17 restores the interrupted block (damaged block) from the received recovery data and the updated software block other than the interrupted block.

In the case of an ECU having a small memory such as the airbag ECU 17, it is necessary to update while overwriting a single control program. Therefore, if the update is interrupted, the control program cannot operate normally. Therefore, when the update of the airbag ECU 17 is interrupted, the airbag control cannot be performed, but the influence on the running of the vehicle 1 is small. By configuring the recovery control information 502f as described above and using this, the gateway 10 does not have to immediately control the ECU to complete the update when the update of the airbag ECU 17 is interrupted, and the next ignition. It can be seen that the update should be restarted when it is OFF. In addition, the HMI 12 displays a warning screen to inform the user that the update has been interrupted, that the airbag function cannot be used, and that the restart of the interrupted update can be started when the ignition is turned off. ..

According to the first embodiment described above, the following effects can be obtained.
(1) A software update device, for example, a gateway 10, is connected to a control device, for example, an ECU, and an update control unit 10001 that performs an update process for transitioning the software of the ECU, for example, a control program from a pre-update state to an update complete state. The recovery control information management unit 10055 that acquires the recovery control information 502 and the control program transition to the update complete state based on the recovery control information 502 when the control program has not transitioned to the update complete state due to an abnormality in the update process. It includes a recovery control unit 1004 that executes recovery processing.
Since the gateway 10 executes the recovery process of the ECU based on the recovery control information 502, various recovery processes can be executed based on the description of the recovery control information 502, and the recovery process corresponding to various devices, for example, various ECUs. Can be executed. In other words, by executing the recovery control process when an error occurs in the update based on the recovery control information 502, even if an error occurs in the update in a system consisting of many ECUs with different resources and characteristics, it is appropriate. Recovery processing can be performed.

(2) The recovery control information 502 includes a start timing 50212 which is information on a timing for starting the recovery process. Therefore, the gateway 10 can perform various actions such as immediate execution or the next ignition OFF at the timing of executing recovery based on the recovery control information 502. The setting of the start timing 50212 in the recovery control information 502 is determined according to, for example, the role of the ECU in the vehicle.

(3) When the gateway 10 is a device mounted on the vehicle and the control device controls at least one of the engine and the brake of the vehicle, the recovery control information is information indicating that the timing to start the recovery process is immediate. including. Therefore, the gateway 10 can immediately start the recovery process for the engine control ECU 13 and the brake control ECU 14 which are indispensable for traveling the vehicle.

(4) The recovery control information 502 includes information indicating a recovery processing method. Therefore, the gateway 10 can properly use recovery processing methods such as differential resume, compression recovery, server cooperation, and block recovery for each ECU based on the recovery control information 502.

(5) The recovery processing method is determined based on the configuration of the ECU, for example, the amount of memory capacity. Since the amount of resources required for processing is specified to some extent by the type of ECU, the configuration of the ECU is also related to the type of ECU. That is, it can be said that the recovery processing method is determined based on the type of ECU. Therefore, appropriate recovery processing can be performed according to the configuration of the ECU and the type of the ECU.

(6) The recovery control information 502 includes recovery data corresponding to the recovery processing method. Therefore, the gateway 10 can execute the recovery process using the recovery data included in the recovery control information 502.

(7) The recovery control information 502 includes the display content 50213 which is information for screen display, and the software update device sets the function restriction state of vehicle 1 by the recovery process based on the information for screen display to the occupant of vehicle 1. As screens for notifying the user, the screens shown in FIGS. 13 (c), 15 (c), 17 (c), 19 (c), 21 (c), and 23 (c) are displayed. It is provided with a display control unit, that is, a recovery control unit 10004, which outputs a signal for outputting to the HMI 12.
Therefore, the gateway 10 can notify the user how the function of the vehicle 1 is restricted during the execution of the recovery process, and can improve the convenience of the user by communicating the situation to the user. it can.

(Modification example 1)
In the above-described embodiment, the gateway 10 plays a role of a software update device that updates the control program mounted on each ECU. However, the function of the gateway program 100 described above may be mounted on the communication module 11 or the HMI 12. Further, another device (not shown) connected to the in-vehicle network 10a or 10b may have a function of the gateway program 100.

(Modification 2)
In the first embodiment described above, it is assumed that when the gateway 10 accesses the recovery data URI50215, compressed software is obtained. However, the resource identified by the recovery data URI50215 may be differential data for rolling back from the updated software to the current software, XOR data for software blocks, or even corrupted block data. Then, the gateway 10 executes a process matching the received data.

(Modification 3)
In the recovery data URI50215 included in the recovery control information 502, "Null", which means that the information is not set, is set when the recovery method 50214 is other than "server cooperation". However, when the recovery data is included in the ECU recovery control information 502, "LOCAL" indicating that may be set in the recovery data URI50215.

(Modification example 4)
In the first embodiment, recovery is defined as transitioning to the update complete state when the software has not transitioned to the update complete state due to an abnormality in the update process. However, recovery may be performed by transitioning to the pre-update state when the software has not transitioned to the update complete state due to an abnormality in the update process. In other words, so-called rollback may be used as recovery. In this case, the ECU recovery data 5022 includes information necessary for executing rollback, for example, XOR data between blocks of software before update, and the recovery control unit 1004 rolls back using the ECU recovery data 5022. To execute.

(Modification 5)
The gateway 10 may use more network bandwidth than usual when executing the recovery process. For example, the gateway 10 usually sets the number of data transmissions per second or the amount of data transmitted per second with a sufficient margin for the load on the network. Then, the gateway 10 allows a larger number of data transmissions than usual or a larger amount of data than usual when executing the recovery process. As a result, the recovery process can be executed quickly.

Further, the gateway 10 may use the network bandwidth more than usual, or may use the network bandwidth more than usual and set the priority of the data frame related to the recovery process higher than usual.
Further, the gateway 10 does not use more network bandwidth than usual for all recovery processes, but may use more network bandwidth than usual only under certain conditions. The specific conditions are, for example, that the display content 50213 of the ECU recovery control information 5021 is "urgent" and that the recovery method 50214 clearly indicates that the bandwidth is increased.

(Modification 6)
The combination of the update control procedure included in the ECU update control information 5012 and the recovery method 50214 of the ECU recovery control information 5021 may be a specific combination. For example, the update control procedure may be differential update, and the recovery method 50214 may be a combination of compression recovery.
FIG. 25 is a diagram showing a configuration of the update package 5d when the update target is only the brake control ECU 14 in the modification 6. As shown in FIG. 25B, the brake control ECU update control information 5012d is composed of, for example, an ECU ID 50121d that identifies the ECU, a start timing 50122d that indicates the timing to start updating, and an update method 50124d that indicates the update control procedure. .. Since the update method 50124d is the difference update, the brake control ECU update data 5013d is the difference data between the latest software and the current software. Since the recovery method 50214d is a compression recovery, the brake control ECU recovery data 5022d is the latest compressed software.

In this case, the update method, which normally completes the process in a short time, executes the differential update, and when an abnormality occurs in the update, the entire area of the software is written to ensure recovery. Therefore, it is possible to achieve both speed of processing and ensuring safety.
Note that the update control procedure may be differential update, the recovery method 50214 may be server-linked, and the latest version of software in which the data acquired based on the recovery data URI is compressed may be used.
Further, when the definition of "recovery" is to be changed to the update completed state or the state before the update when the software has not been changed to the update completed state due to an abnormality in the update process, it is shown in FIG. An example may be as follows. That is, the brake control ECU update data 5013d may be the difference data between the latest software and the current software, and the brake control ECU recovery data 5022d may be the compressed current software.

-Second embodiment-
A second embodiment of the software update system S will be described with reference to FIGS. 26 to 27. In the following description, the same components as those in the first embodiment are designated by the same reference numerals, and the differences will be mainly described. The points not particularly described are the same as those in the first embodiment. This embodiment is different from the first embodiment in that recovery control information is mainly stored in the ECU whose software is updated.

(Constitution)
The hardware configuration of the gateway 10 and the configuration of the gateway program 100 in the second embodiment are the same as those in the first embodiment. However, the operation of the gateway program 100 is partially different as described later.
The hardware configuration of the ECU in the second embodiment is the same as that in the first embodiment. The configuration of the control program of the ECU will be described.
FIG. 26 is a block diagram showing a configuration of a control program 130 operating on the engine control ECU 13 according to the second embodiment. However, in each of the ECUs to which the software is updated in the present embodiment has at least the same configuration as the control program 130 shown in FIG. 26.

The control program 130 in the second embodiment further includes a storage area for recovery control information 13007 in addition to the configuration in the first embodiment. The recovery control information 13007 includes the same information as the recovery control information 502 in the first embodiment. However, the recovery control information 13007 stores only the information about the ECU that stores the recovery control information 13007, that is, the engine control ECU 13. In other words, the recovery control information 13007 includes one ECU recovery control information, and includes a maximum of one ECU recovery data. The recovery control information 13007 may be set in advance at the time of shipment from the factory of the engine control ECU 13, or may be set after shipment. The components other than the recovery control information 13007 are the same as those in FIG. 4B.

(Recovery control information acquisition operation)
FIG. 27 is a sequence diagram showing a process in which the gateway 10 acquires recovery control information 13007 from the engine control ECU 13. The gateway 10 acquires recovery control information 13007 from the engine control ECU 13 as follows before updating the control software of the engine control ECU 13, for example, immediately before the update.
The update control unit 10001 of the gateway 10 transmits a recovery control information acquisition request to the engine control ECU 13 (S801). Upon receiving the recovery control information acquisition request, the update control unit 13001 of the engine control ECU 13 reads the recovery control information 13007 and transmits it to the gateway 10 (S802). Upon receiving this, the gateway 10 executes the recovery process in the same manner as in the first embodiment using the received recovery control information 13007.
Although the description has been given here by taking the engine control ECU 13 as an example, other ECUs can be implemented with the same configuration and sequence.

According to the second embodiment described above, the following effects can be obtained.
(1) The ECU includes a storage area for recovery control information 13007, which is information used for recovery processing of the ECU, and provides recovery control information 13007 in response to a request from the gateway 10.
Therefore, the gateway 10 can acquire information on the recovery process for each ECU from the ECU physically nearby instead of the server 2 connected via the Internet 3, and perform the recovery process. Further, if there is a discrepancy between the actual vehicle configuration and the vehicle configuration managed by the server 2 due to the addition or replacement of the ECU, appropriate recovery control information cannot be obtained from the server, but the server 2 and the server 2 Even if there is a difference in the configuration of the actual vehicle system, recovery control can be appropriately performed.

-Third embodiment-
A third embodiment of the software update system S will be described with reference to FIGS. 28 to 30. In the following description, the same components as those in the first embodiment are designated by the same reference numerals, and the differences will be mainly described. The points not particularly described are the same as those in the first embodiment. This embodiment is different from the first embodiment in that recovery control information is mainly stored for each interruption factor. Further, "recovery" in the present embodiment means that the software has not transitioned to the update complete state due to an abnormality in the update process, and cannot be transitioned to the update complete state due to a fatal abnormality. In some cases, it also includes an operation of notifying the user to that effect. By the notification, the user can confirm that a fatal abnormality has occurred in the vehicle and take necessary measures such as contacting the dealer.

(Constitution)
The hardware configuration of the gateway 10 and the configuration of the gateway program 100 in the third embodiment are the same as those in the first embodiment. However, the operation of the gateway program 100 is partially different as described later.
The hardware configuration of the ECU in the third embodiment is the same as that in the first embodiment.

FIG. 28A is a configuration example of the update package 5 in the third embodiment. As shown in FIG. 28A, the configuration of the update package 5 in the third embodiment is the same as that in the first embodiment, and the point that reference numeral 5023 is used for the ECU recovery control information will be described below. The configuration of the ECU recovery control information 5023 is different from that of the first embodiment.
FIG. 28B is a diagram showing the configuration of the ECU recovery control information 5023 according to the third embodiment. The ECU recovery control information 5023 further includes one recovery control information number 50231 and one or more interruption factors 50232 in addition to the configuration of the ECU recovery control information 5021 according to the first embodiment. The ECU recovery control information 5023 includes a start timing 50212, a display content 50213, a recovery method 50214, and recovery data URI50215 corresponding to the respective interruption factors 50232. The number of recovery control information 50231 indicates how many interruption factors 50232 are included in the ECU recovery control information 5023. The interruption factor 50232 indicates a factor for which the update was interrupted. In the following, the combination of the interruption factor 50232, the start timing 50212, the display content 50213, the recovery method 50214, and the recovery data URI50215 included in the ECU recovery control information 5023 will be referred to as factor-specific recovery control information 50230.

(Operation example)
A configuration example of recovery control information 5023a, a display example on the HMI 12, a configuration example of the update state D1a, and an operation when different recovery controls are performed for the automatic operation ECU 15 for each interruption factor using FIGS. 29 and 30. Shows the sequence.

As shown in FIG. 29 (a), the recovery control information 5023a according to the third embodiment is composed of the ECU ID 50221a, the number of recovery control information 50231a, and the recovery control information 50230a for each factor. "Automatic operation ECU" is set for ECU ID 50221a, "2" is set for the number of recovery control information 50231, "power cutoff / communication cutoff" is set for the first interruption factor 50232a, and the start timing 50212a is set. Is set to "start running", "caution" and display message information (not shown) are set in the display content 50213a, "difference resume" is set in the recovery method 50214a, and information is set in the recovery data URI50215a. "NULL" which means that it is not done is set. "Immediate" is set for the second interruption factor 50232a2, "immediate" is set for the start timing 50212a2, and "emergency" is set for the display content 50213a2, and information prompting the dealer to be guided as display message information (not shown). Is set, "Null" meaning that no information is set in the recovery method 50214a2 is set, and "Null" meaning that no information is set is set in the recovery data URI50215a2.

The recovery control unit 1004 causes the display device of the HMI 12 to output the screen display G10a2 shown in FIG. 29B based on the display content 50213a2. The screen display G10a2 is a display indicating that the software update has been interrupted due to a fatal error and it is necessary to contact the dealer in order to recover.

As shown in FIG. 29 (c), the update state D1a in the third embodiment includes the interruption factor D106 in addition to the information of the update state D1 in the first embodiment. The interruption factor D106 is a field in which the factor for which the update is interrupted is stored, and for example, "power failure", "communication disconnection", "FROM failure", etc. are stored.

The record D11a is a record indicating the update state of the automatic operation ECU 15 in the third embodiment, and "FROM failure" is stored in the field of the interruption factor D106. By recording the interruption factor D106 in this way, it is possible to recognize the cause of the interruption of the update and start an appropriate recovery process.

FIG. 30 is a sequence diagram showing an example of recovery processing of the automatic operation ECU 15 according to the third embodiment. For example, the ignition is turned on again after the update process of the automatic operation ECU 15 is interrupted due to a power supply interruption to the gateway 10 and then the power supply is restarted, or after the update process is interrupted due to a failure of the FROM of the automatic operation ECU 15. Then, the recovery process is executed as follows.
When the gateway 10 is activated, first, in step S901a, it is confirmed whether or not there is an interrupted update (S701 and S702 in FIG. 11 and S901a in FIG. 30).

Further, in parallel with the processing of the gateway 10, the automatic operation ECU 15 performs the activation processing shown in FIG. 10B. Here, since the update is interrupted, the start information D33 has not been rewritten yet, and the start of the control program recorded in the program area 1313bP0 is specified, the automatic operation ECU 15 starts the current version 2 control program P4. To do.
When the gateway 10 determines that the update of the automatic operation ECU 15 is interrupted from the update start state D102 of the update state D21 (S901a), the gateway 10 performs the following processing in step S910a2. That is, the gateway 10 reads the interruption factor D106 corresponding to the automatic operation ECU 15 from the update state D1a, and determines the interruption factor. When the interruption factor is "power interruption / communication interruption" (S910a2: "communication disconnection / power interruption"), then, in step S911a2, the interruption factor is "power interruption / communication interruption" from the automatic operation ECU recovery control information 5023a. Read the recovery control information and perform recovery processing based on the recovery control information. The recovery process based on the recovery control information in which the interruption factor is “power failure / communication disconnection” is the same as the processes from step S903a to step S909a in FIG. When the interruption factor is "FROM failure" (S910a2: "FROM failure"), then, in step S912a2, the recovery control information whose interruption factor is "FROM failure" is read from the automatic operation ECU recovery control information 5023a, and recovery control is performed. Performs recovery processing based on information.

The recovery process based on the recovery control information in which the interruption factor is "FROM failure" is performed by the procedure shown in FIG. 30B. That is, the gateway 10 reads the start timing 50212a2 when the interruption factor is "FROM failure" from the automatic operation ECU recovery control information 5023 corresponding to the automatic operation ECU 15, and the timing to start the recovery process of the automatic operation ECU 15 is immediate. Is determined to be. Next, in step S903a2, the gateway 10 reads out the display content 50213a2 when the interruption factor is "FROM failure" from the automatic operation ECU recovery control information 5023, and issues a request to the HMI 12 to display an emergency screen based on the display content 50213a2. (S911a2). Based on this request, the HMI 12 displays the emergency screen illustrated in G10a2 of FIG. 29 (b) on the display device (S912a2).

According to the third embodiment described above, the following effects can be obtained.
(1) The recovery control information 5023 includes recovery control information for each abnormality factor, and the gateway 10 selects the recovery process to be applied according to the abnormality factor.
If the cause of the update interruption is a FROM failure, hardware replacement is required and it is difficult to perform recovery by the system alone.Therefore, the applicable recovery process may differ depending on the interruption factor. There is. By configuring the recovery control information 5023 as described above and using it, the gateway 10 executes different recovery processes depending on, for example, when a fatal abnormality occurs in the ECU and when it does not, and information appropriate for the user. Can be conveyed.

The present invention is not limited to the above-mentioned examples, and includes various modifications. For example, the above-described embodiment has been described in detail in order to explain the present invention in an easy-to-understand manner, and is not necessarily limited to those having all the described configurations. Further, it is possible to replace a part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. In addition, it is possible to add / delete / replace other configurations or change the order of processing in each processing for a part of the configuration of each embodiment. For example, in the present embodiment, the software update device is the gateway 10, but the communication module 11 and the HMI 12 may be the software update device.

Further, each of the above configurations, functions, processing units, processing means and the like may be realized by hardware by designing a part or all of them by, for example, an integrated circuit. Further, each of the above configurations, functions, and the like may be realized by software by the processor interpreting and executing software that realizes each function.
In addition, the control lines and information lines indicate those that are considered necessary for explanation, and do not necessarily indicate all the control lines and information lines in the product. In practice, it can be considered that almost all configurations are interconnected.
Although various embodiments and modifications have been described above, the present invention is not limited to these contents. Other aspects conceivable within the scope of the technical idea of the present invention are also included within the scope of the present invention.

S ... Software update system
1 ... Vehicle
2 ... Server 10 ... Gateway 13 ... Engine control ECU
14 ... Brake control ECU
10001… Update control unit 10004… Recovery control unit 10055… Recovery control information management unit 502… ECU recovery control information 5021… ECU recovery control information 5022… ECU recovery data 50212… Recovery start timing 50212… Start timing 50213… Display contents 50214… Recovery method

The present invention, software update device, and relates to a software update process.

The invention described in Patent Document 1 cannot complete the update when an abnormality occurs in the software update .

The software update device according to the first aspect of the present invention is a software update device connected to a control device, and is an update control unit that performs update processing for transitioning the software of the control device from the pre-update state to the update complete state. And the recovery control information management unit that acquires the recovery control information, and the update completed state of the software based on the recovery control information when the software has not transitioned to the update completed state due to an abnormality in the update process. The recovery control unit includes a recovery control unit that executes the recovery process of transitioning to the above, and the recovery control unit changes the communication setting between the software update device and the control device when executing the recovery process .
The software update method according to the second aspect of the present invention is an update method executed by the software update device connected to the control device, and is an update process for transitioning the software of the control device from the pre-update state to the update complete state. When the software has not transitioned to the update complete state due to an abnormality in the update process, the software is put into the update complete state based on the recovery control information. Execute the recovery process to be transitioned, and when executing the recovery process, it includes changing the communication setting between the software update device and the control device .

According to the present invention, it is possible to quickly execute the recovery process for transitioning to the update completion state .

Claims (3)

A software updater that is connected to the control device
An update control unit that performs update processing that transitions the software of the control device from the pre-update state to the update complete state.
The recovery control information management unit that acquires recovery control information,
A recovery control unit that executes recovery processing for transitioning the software to the update completion state based on the recovery control information when the software has not transitioned to the update completion state due to an abnormality in the update processing is provided.
The recovery control information includes information indicating the recovery processing method.
A software update device, characterized in that information indicating a recovery processing method is determined based on the configuration of the control device. The software update device according to claim 1 and
A software update system including a server that transmits the recovery control information to the software update device. A software update method executed by a software update device connected to a control device.
Performing an update process for transitioning the software of the control device from the pre-update state to the update complete state,
Acquiring recovery control information and
When the software has not transitioned to the update completed state due to an abnormality in the update process, the recovery process for transitioning the software to the update completed state is executed based on the recovery control information.
The recovery control information includes information indicating the recovery processing method.
The information indicating the recovery processing method is a software update method determined based on the configuration of the control device.

Images