CN114730259A

CN114730259A - Electronic control system for vehicle, host device for vehicle, rewriting instruction method based on specific mode, and rewriting instruction program based on specific mode

Info

Publication number: CN114730259A
Application number: CN202080073696.4A
Authority: CN
Inventors: 原田雄三; 上原一浩
Original assignee: Denso Corp
Current assignee: Denso Corp
Priority date: 2019-08-28
Filing date: 2020-08-25
Publication date: 2022-07-08
Also published as: JP7264256B2; US20220179644A1; JPWO2021039796A1; WO2021039796A1; DE112020004017T5

Abstract

In an electronic control system (1) for a vehicle, an ECU (19) writes update data received from a host device (11) into a nonvolatile memory, rewrites a program, and writes incomplete temporary software in a write area of the update data in the nonvolatile memory. The host device is provided with: a specific mode determination unit (95a) that determines whether or not a specific mode is set; and a rewrite instruction unit (95b) that, when the specific mode determination unit determines that the specific mode is set, instructs the ECU to write update data based on the specific mode.

Description

Electronic control system for vehicle, host device for vehicle, rewriting instruction method based on specific mode, and rewriting instruction program based on specific mode

Cross Reference to Related Applications

The present application claims priority from japanese application No. 2019-155685, filed on 28/8/2019, and is incorporated herein in its entirety.

Technical Field

The present invention relates to an electronic control system for a vehicle, a host device for a vehicle, a rewriting instruction method based on a specific mode, and a rewriting instruction program based on a specific mode.

Background

In recent years, with diversification of vehicle Control such as a driving assistance function and an automatic driving function, a program for vehicle Control, diagnosis, and the like of an electronic Control unit (hereinafter referred to as an ecu (electronic Control unit)) mounted on a vehicle has been increasingly scaled. In addition, with version upgrading due to improvement of functions and the like, opportunities to rewrite (reprogram) programs of the ECUs are increasing. On the other hand, with the development of communication networks and the like, technologies for networking automobiles have been increasingly popularized. In view of such circumstances, for example, patent document 1 proposes the following technique: the vehicle-side main device is provided as a relay device, and The vehicle-side main device distributes update data received from The center device by wireless to The ECU to be rewritten, and rewrites The program of The ECU to be rewritten by OTA (Over The Air).

Patent document 1: japanese patent laid-open publication No. 2016-224898

In a factory environment for manufacturing a vehicle, an ECU is mounted on the vehicle in a vehicle production line, the ECU mounted on the vehicle is wired to a factory device, update data is distributed from the factory device to the ECU mounted on the vehicle, and writing of the update data is instructed to the ECU, whereby the ECU writes the update data. However, in such a step, the next step cannot be performed until the update data is written, and if the number of ECUs incorporated in the vehicle increases, the operating efficiency significantly decreases. On the other hand, there is a method of writing update data in advance in an ECU and incorporating the ECU in which the update data is written in a vehicle, but in such a step, it is necessary to prepare ECUs of plural product numbers due to a difference in program depending on the class of the vehicle or the like, and there is a problem that the stock of ECUs to be managed increases. In addition, in a dealer environment where a vehicle is repaired, for example, when an ECU is replaced due to a failure or the like, there is a problem that, similarly to a factory environment, it is necessary to prepare ECUs of plural product numbers due to a difference in program depending on the rank of each vehicle or the like, and the stock of ECUs to be managed increases. In view of such circumstances, there is a demand for reducing the inventory of ECUs to be managed in a factory environment, a dealer environment, or the like.

Disclosure of Invention

The purpose of the present disclosure is to reduce the inventory of electronic control devices that are managed under a predetermined environment such as a factory environment or a dealer environment, and to appropriately write update data.

According to one aspect of the present disclosure, the host device for a vehicle distributes update data to the electronic control device to be rewritten, and instructs the electronic control device to be rewritten to write the update data. When receiving the update data from the vehicle host device, the electronic control device writes the received update data in the nonvolatile memory and rewrites the program. The electronic control device writes incomplete temporary software in a write area of the non-volatile memory where data is updated. In a vehicle main device, a specific mode determination unit determines whether or not a specific mode is set. When the specific mode determination unit determines that the specific mode is set, the rewrite instruction unit instructs the electronic control device to write the update data based on the specific mode.

In the electronic control device, the update data can be written by writing incomplete temporary software in the write area of the update data in the nonvolatile memory. In the vehicle main device, when the specific mode is set, writing of update data based on the specific mode is instructed to the electronic control device. In a predetermined environment such as a factory environment or a dealer environment, by preparing in advance an electronic control device in which incomplete temporary software is written in a write area of update data, it is possible to reduce the stock of the electronic control device to be managed and to write update data appropriately.

According to one aspect of the present disclosure, the host device for a vehicle instructs the electronic control device to be rewritten to write the update data, and distributes the update data to the electronic control device to be rewritten. When receiving the update data from the vehicle host device, the electronic control device writes the received update data in the nonvolatile memory and rewrites the program. The center device transmits the update data and the specification data to the vehicle main device. The electronic control device writes incomplete temporary software in a write area of the non-volatile memory where data is updated. In the vehicle main device, the specific mode determination unit determines whether or not a specific mode different from a normal mode in which the user performs an operation related to updating of data is set, based on the specification data received from the center device. When the specific mode determination unit determines that the specific mode is set, the rewrite instruction unit controls the specific mode-based update process, which is an update process in which a part of the normal mode-based update process is omitted.

In the electronic control device, the update data can be written by writing incomplete temporary software in the write area of the update data in the nonvolatile memory. In the vehicle main device, when the specific mode is set, the specific mode-based update process is controlled as an update process in which a part of the normal mode-based update process is omitted. In a predetermined environment such as a factory environment or a dealer environment, by preparing in advance an electronic control device in which incomplete temporary software is written in a write area of update data, it is possible to reduce the stock of the electronic control device to be managed and to write update data appropriately.

Drawings

The above objects, and other objects, features, and advantages of the present disclosure will become more apparent from the following detailed description with reference to the accompanying drawings. Wherein, the attached drawings are as follows:

fig. 1 is a diagram showing an overall configuration of an embodiment.

Fig. 2 is a diagram showing an electrical configuration of the CGW.

Fig. 3 is a diagram showing an electrical structure of the DCM.

Fig. 4 is a diagram showing an electrical configuration of the ECU.

Fig. 5 is a diagram showing a connection mode of a power supply line.

Fig. 6 is a diagram showing a method of packaging the rebuilt data and the distribution specification data.

Fig. 7 is a diagram showing rewriting specification data for DCM.

Fig. 8 is a diagram showing rewriting specification data for CGW.

Fig. 9 is a diagram showing distribution specification data.

Fig. 10 is a diagram showing a method of unpacking a distribution packet.

Fig. 11 is a diagram showing a normal operation mode of the embedded single-sided individual memory.

Fig. 12 is a diagram showing a mode of a rewrite operation in the embedded single-sided individual memory.

Fig. 13 is a diagram showing a normal operation mode in the download-type single-sided individual memory.

Fig. 14 is a diagram showing a mode of a rewrite operation in the download-type single-sided individual memory.

Fig. 15 is a diagram showing a normal operation mode in the embedded single-sided suspend memory.

Fig. 16 is a diagram showing a mode of a rewrite operation in the embedded single-sided suspend memory.

Fig. 17 is a diagram showing a normal operation mode in the download-type single-sided suspend memory.

Fig. 18 is a diagram showing a mode of a rewrite operation in the download-type single-sided suspend memory.

Fig. 19 is a diagram showing a normal operation mode of the embedded dual-sided memory.

Fig. 20 is a diagram showing a mode of a rewrite operation in the embedded dual-sided memory.

Fig. 21 is a diagram showing a normal operation mode in the download-type dual-sided memory.

Fig. 22 is a diagram showing a mode of a rewrite operation in the download-type dual-sided memory.

Fig. 23 is a diagram showing a mode of rewriting an application program.

Fig. 24 is a diagram showing a mode of rewriting an application program.

Fig. 25 is a diagram showing a mode of rewriting an application program.

Fig. 26 is a timing chart showing a method of rewriting an application program by power control.

Fig. 27 is a timing chart showing a method of rewriting an application program by power control.

Fig. 28 is a timing chart showing a method of rewriting an application program by power supply self-holding.

Fig. 29 is a timing chart showing a method of rewriting an application program by power supply self-holding.

Fig. 30 is a diagram showing stages.

Fig. 31 is a diagram showing a screen in a normal state.

Fig. 32 is a diagram showing a screen when an activity notification is generated.

Fig. 33 is a diagram showing a screen at the time of activity notification.

Fig. 34 is a diagram showing a screen at the time of download approval.

Fig. 35 is a diagram showing a screen at the time of download approval.

Fig. 36 is a diagram showing a screen during download execution.

Fig. 37 is a diagram showing a screen during download execution.

Fig. 38 is a diagram showing a screen when downloading is completed.

Fig. 39 is a diagram showing a screen at the time of installation approval.

Fig. 40 is a diagram showing a screen at the time of installation approval.

Fig. 41 is a diagram showing a screen during installation execution.

Fig. 42 is a diagram showing a screen during installation execution.

Fig. 43 is a diagram showing a screen at the time of activation approval.

Fig. 44 is a diagram showing a screen when IG is on.

Fig. 45 is a diagram showing a screen at the time of the confirmation operation.

Fig. 46 is a diagram showing a screen at the time of the confirmation operation.

Fig. 47 is a functional block diagram of the center device.

FIG. 48 is a functional block diagram of a DCM.

Fig. 49 is a functional block diagram of a CGW.

Fig. 50 is a functional block diagram of a CGW.

Fig. 51 is a functional block diagram of the ECU.

Fig. 52 is a functional block diagram of the in-vehicle display.

Fig. 53 is a functional block diagram of a transmission determination unit that distributes packets.

Fig. 54 is a flowchart showing a transmission determination process of a distribution packet.

Fig. 55 is a functional block diagram of a download determination unit that distributes packets.

Fig. 56 is a flowchart showing download determination processing of a distribution packet.

Fig. 57 is a functional block diagram of a transfer determination unit for write data.

Fig. 58 is a flowchart showing a transfer determination process of write data.

Fig. 59 is a functional block diagram of the acquisition determination unit of write data.

Fig. 60 is a flowchart showing a write data acquisition determination process.

Fig. 61 is a functional block diagram of an instruction judging unit mounted.

Fig. 62 is a flowchart showing an instruction determination process of mounting.

Fig. 63 is a diagram showing a mode of instructing mounting.

Fig. 64 is a diagram showing a mode of instructing mounting.

Fig. 65 is a diagram showing a method of generating a random value.

Fig. 66 is a functional block diagram of a security access key management unit.

Fig. 67 is a flowchart showing a process of generating a security access key.

Fig. 68 is a diagram showing a method of generating a security access key.

Fig. 69 is a flowchart showing the security access key removal process.

Fig. 70 is a diagram showing a flow of processing for verifying write data.

Fig. 71 is a functional block diagram of a verification unit for writing data.

Fig. 72 is a flowchart showing the verification process of write data.

Fig. 73 is a diagram showing a mode in which processes related to verification of write data are distributed.

Fig. 74 is a diagram showing a mode in which processes for verifying write data are distributed.

Fig. 75 is a diagram showing a mode in which processes related to verification of write data are distributed.

Fig. 76 is a diagram showing a mode in which processing for verifying write data is distributed.

Fig. 77 is a diagram showing the flow of verification of write data and rewriting of an application program.

Fig. 78 is a diagram showing a flow of verification of write data and rewriting of an application program.

Fig. 79 is a functional block diagram of a transmission control unit of data storage plane information.

Fig. 80 is a flowchart showing a transmission control process of data storage plane information.

Fig. 81 is a sequence diagram showing a method of notifying the double-sided rewriting information.

Fig. 82 is a functional block diagram of a power management unit to be rewritten.

Fig. 83 is a flowchart showing a power management process for a non-rewritable object.

Fig. 84 is a diagram showing transition among the startup state, the stop state, and the sleep state.

Fig. 85 is a diagram showing transition among the startup state, the stop state, and the sleep state.

Fig. 86 is a diagram showing a connection mode of a power supply line.

Fig. 87 is a flowchart showing a process of monitoring the remaining battery level.

Fig. 88 is a functional block diagram of a file transfer control unit.

Fig. 89 is a flowchart showing a file transfer control process.

Fig. 90 is a diagram showing a method of giving and receiving a file.

Fig. 91 is a diagram showing a method of giving and receiving a file.

Fig. 92 is a diagram showing a divided file and a write file.

Fig. 93 is a diagram showing a manner in which the CGW transmits a transmission request to the DCM.

Fig. 94 is a diagram showing a manner in which the CGW sends a transmission request to the DCM.

Fig. 95 is a diagram showing a mode in which the CGW distributes write data to the ECU to be rewritten.

Fig. 96 is a diagram showing a mode in which the CGW distributes write data to the ECU to be rewritten.

Fig. 97 is a diagram showing a mode in which the CGW distributes write data to the ECU to be rewritten.

Fig. 98 is a diagram showing a connection mode of the ECU.

Fig. 99 is a functional block diagram of a distribution control unit for write data.

Fig. 100 is a diagram showing a bus load table.

Fig. 101 is a diagram showing a table to which an ECU to be rewritten belongs.

Fig. 102 is a flowchart showing write data distribution control processing.

Fig. 103 is a diagram showing a method of distributing write data.

Fig. 104 is a diagram showing a method of distributing write data.

Fig. 105 is a diagram showing a method of distributing write data while the vehicle is traveling.

Fig. 106 is a diagram showing a method of distributing write data during parking.

Fig. 107 is a diagram showing the distribution amount of write data.

Fig. 108 is a diagram showing the distribution amount of write data.

Fig. 109 is a functional block diagram of an instruction unit of an activation request.

Fig. 110 is a flowchart showing an instruction process of an activation request.

Fig. 111 is a diagram showing a manner of indicating an activation request.

Fig. 112 is a functional block diagram of the activated execution control section.

Fig. 113 is a flowchart showing the rewriting process.

Fig. 114 is a flowchart showing an activated execution control process.

Fig. 115 is a functional block diagram of a packet section to be rewritten.

Fig. 116 is a flowchart showing a group management process for a rewrite target.

Fig. 117 is a flowchart showing a group management process of a rewrite target.

Fig. 118 is a diagram showing a manner of grouping rewriting objects.

Fig. 119 is a functional block diagram of the rollback execution control unit.

Fig. 120 is a flowchart showing the determination processing of the rollback method.

Fig. 121 is a flowchart showing a cancellation request determination process.

Fig. 122 is a flowchart showing a cancellation request determination process.

Fig. 123 is a flowchart showing a cancellation request determination process.

Fig. 124 is a flowchart showing a cancellation request determination process.

Fig. 125 is a flowchart showing a cancellation request determination process.

Fig. 126 is a diagram showing a mode of executing rollback.

Fig. 127 is a diagram showing a mode of executing rollback.

Fig. 128 is a diagram showing a mode of executing rollback.

Fig. 129 is a diagram showing a mode of executing rollback.

Fig. 130 is a diagram showing a mode of executing rollback.

Fig. 131 is a functional block diagram of a display control unit that rewrites the progress status.

Fig. 132 is a flowchart showing a display control process of the rewriting progress status.

Fig. 133 is a flowchart showing display control processing for rewriting progress.

Fig. 134 is a diagram of a screen showing a rewriting progress state.

Fig. 135 is a diagram of a screen showing a rewriting progress state.

Fig. 136 is a diagram of a screen showing a rewriting progress state.

Fig. 137 is a diagram of a screen showing the rewriting progress.

Fig. 138 is a diagram of a screen showing the rewriting progress.

FIG. 139 is a view showing transition of a progress chart display.

Fig. 140 is a diagram showing transition of the progress chart display.

Fig. 141 is a diagram showing transition of the progress chart display.

FIG. 142 is a view showing transition of a progress chart display.

Fig. 143 is a diagram of a screen showing a rewriting progress state.

Fig. 144 is a functional block of the matching determination unit of the difference data.

Fig. 145 is a flowchart showing the matching judgment processing of the difference data.

Fig. 146 is a diagram showing a mode of determining the matching of the difference data.

Fig. 147 is a diagram showing a method of determining the matching of difference data.

Fig. 148 is a functional block diagram of the rewrite execution control unit.

Fig. 149 is a flowchart showing a normal operation process.

Fig. 150 is a flowchart showing the rewriting operation processing.

Fig. 151 is a flowchart showing information notification processing.

Fig. 152 is a flowchart showing verification processing of the rewrite program.

Fig. 153 is a diagram showing a method of transmitting identification information and write data.

Fig. 154 is a diagram showing a method of transmitting identification information and write data.

Fig. 155 is a flowchart showing the installation instruction processing.

Fig. 156 is a functional block diagram of a session establishing unit.

Fig. 157 is a diagram showing a configuration of a program.

Fig. 158 is a diagram showing state transition.

Fig. 159 is a diagram showing state transition.

Fig. 160 is a diagram showing state transition.

Fig. 161 is a diagram showing mediation of a session.

Fig. 162 is a diagram showing mediation of a session.

Fig. 163 is a flowchart showing the state transition management processing in the first state.

Fig. 164 is a flowchart showing the state transition management processing in the first state.

Fig. 165 is a flowchart showing the state transition management processing in the first state.

Fig. 166 is a flowchart showing state transition management processing in the second state.

Fig. 167 is a flowchart showing state transition management processing in the second state.

Fig. 168 is a diagram showing a configuration of a program.

Fig. 169 is a diagram showing state transition.

Fig. 170 is a functional block diagram of the determination section of the retry point.

Fig. 171 is a diagram showing the configuration of a flash memory.

Fig. 172 is a flowchart showing a process of setting a process flag.

Fig. 173 is a flowchart showing a process of determining a process flag.

Fig. 174 is a flowchart showing a process of determining a process flag.

Fig. 175 is a functional block diagram of a synchronization control unit in a progress state.

Fig. 176 is a functional block diagram of the synchronization control unit in the progress state.

Fig. 177 is a diagram showing a mode of transmitting and receiving the progress status signal.

Fig. 178 is a flowchart showing the synchronization control processing of the progress state.

Fig. 179 is a flowchart showing a synchronization control process of the progress state.

Fig. 180 is a flowchart showing a display process of the progress state.

Fig. 181 is a functional block diagram of a transmission control unit that displays control information.

Fig. 182 is a flowchart showing a transmission control process of display control information.

Fig. 183 is a functional block diagram of a reception control unit for display control information.

Fig. 184 is a flowchart showing a reception control process of display control information.

Fig. 185 is a diagram showing information included in the distribution specification data.

Fig. 186 is a functional block diagram of a screen display control unit for progressive display.

Fig. 187 is a diagram showing rewriting specification data.

Fig. 188 is a diagram showing a screen at the time of menu selection.

Fig. 189 is a diagram showing a screen at the time of selection by the user.

Fig. 190 is a diagram showing a screen at the time of user registration.

Fig. 191 is a flowchart showing the screen display control processing for progress display.

Fig. 192 is a flowchart showing a screen display control process of progress display.

Fig. 193 is a diagram showing a message frame.

Fig. 194 is a diagram showing a screen when the activation approval is given.

Fig. 195 is a diagram showing the setting of whether or not the item is displayed.

Fig. 196 is a diagram showing setting of whether or not items are displayed.

Fig. 197 is a diagram showing a screen at the time of activation approval.

Fig. 198 is a diagram showing a data communication method.

Fig. 199 is a diagram showing a message frame at the time of an activity notification.

Fig. 200 is a diagram showing a message frame at the time of download approval.

Fig. 201 is a diagram showing a message frame when installation approval is given.

Fig. 202 is a diagram showing a message frame at the time of activation approval.

Fig. 203 is a diagram showing screen transition.

Fig. 204 is a diagram showing a screen at the time of generation of an activity notification.

Fig. 205 is a diagram showing a screen at the time of download approval.

Fig. 206 is a diagram showing a screen at the time of download approval.

Fig. 207 is a diagram showing a screen during download execution.

Fig. 208 is a diagram showing a screen when downloading is completed.

Fig. 209 is a diagram showing a screen at the time of installation approval.

Fig. 210 is a diagram showing a screen when activation approval is given.

Fig. 211 is a functional block diagram of a report control unit for program update.

Fig. 212 is a flowchart showing a program update report control process.

Fig. 213 is a diagram showing a report method of the pointer.

Fig. 214 is a diagram showing transition of a report method in a case where a rewrite target is a dual-sided memory.

Fig. 215 is a diagram showing transition of the report method in the case where the rewrite target is the single-sided suspend memory.

Fig. 216 is a diagram showing transition of a report method in a case where a rewrite target is a single-sided individual memory.

Fig. 217 is a diagram showing a connection method.

Fig. 218 is a functional block of an execution control unit for self-holding a power supply in CGW.

Fig. 219 is a functional block of an execution control portion of power supply self-holding in the ECU.

Fig. 220 is a flowchart showing the execution control processing for power supply self-holding in CGW.

Fig. 221 is a flowchart showing an execution control process of power supply self-holding in the ECU.

Fig. 222 is a diagram showing a period during which power supply self-holding is required.

Fig. 223 is a functional block diagram of a rewrite instruction unit based on overwriting of configuration information.

Fig. 224 is a flowchart showing overwrite instruction processing based on the overlay of the configuration information.

Fig. 225 is a diagram showing a mode in which rewriting of an application program and overwriting of configuration information are mixed.

Fig. 226 is a diagram showing a mode in which rewriting of an application program and overwriting of configuration information are mixed.

Fig. 227 is a diagram showing a method of transmitting/receiving configuration information.

Fig. 228 is a functional block of a rewrite instruction unit that writes back configuration information.

Fig. 229 is a flowchart showing rewrite instruction processing based on write back of configuration information.

Fig. 230 is a flowchart showing rewrite instruction processing based on write back of configuration information.

Fig. 231 is a flowchart showing rewrite instruction processing based on write back of configuration information.

Fig. 232 is a diagram showing a mixed mode of rewriting of the application program and writing back of the configuration information.

Fig. 233 is a diagram showing a mode in which rewriting of an application and writing back of configuration information are mixed.

Fig. 234 is a diagram showing a hybrid system of rewriting of an application program and writing back of configuration information.

Fig. 235 is a diagram showing a mixed system of rewriting of an application program and writing back of configuration information.

Fig. 236 is a diagram showing a mixed mode of rewriting of the application program and writing back of the configuration information.

Fig. 237 is a diagram showing a mode in which rewriting of an application program and writing of configuration information are mixed.

Fig. 238 is a diagram showing a method of transmitting/receiving configuration information.

Fig. 239 is a diagram showing a scheme of transmitting and receiving configuration information.

Fig. 240 is a diagram showing the configuration of the flash memory.

Fig. 241 is a functional block diagram of a rewrite instruction unit based on a specific mode.

Fig. 242 is a diagram showing a connection mode to a plant.

Fig. 243 is a diagram showing a manner of connection with a dealer apparatus.

Fig. 244 is a flowchart showing rewrite instruction processing in the specific mode.

Fig. 245 is a flowchart showing the rewrite processing by the specific mode.

Fig. 246 is a diagram showing the contents of the factory mode-based rewriting and the dealer mode-based rewriting.

Fig. 247 is an overall sequence diagram showing a method of rewriting an application program.

Fig. 248 is an overall sequence diagram showing a method of rewriting an application program.

Fig. 249 is a sequence diagram of the whole of the manner in which an application is rewritten.

Fig. 250 is an overall sequence diagram showing a method of rewriting an application program.

Fig. 251 is an overall sequence diagram showing a manner of rewriting an application program.

Fig. 252 is an overall sequence diagram showing a method of rewriting an application program.

Fig. 253 is an overall sequence diagram showing a method of rewriting an application program.

Fig. 254 is an overall sequence diagram showing a method of rewriting an application program.

Fig. 255 is an overall sequence diagram showing a method of rewriting an application program.

Fig. 256 is an overall sequence diagram showing a method of rewriting an application program.

Fig. 257 is an overall sequence diagram showing a method of rewriting an application program.

Fig. 258 is a diagram showing the overall configuration of the vehicle information communication system according to the first embodiment.

Fig. 259 is a diagram showing an electrical configuration of the CGW.

Fig. 260 is a diagram showing an electrical configuration of the ECU.

Fig. 261 is a diagram showing a connection mode of a power supply line.

Fig. 262 is a diagram showing a method of packaging the reprogramming data and the distribution specification data.

Fig. 263 is a diagram showing a manner of unpacking a distribution packet.

Fig. 264 is a block diagram showing a part of the center device mainly related to each function of the server.

Fig. 265 is an image diagram showing a flow of processing in the center device.

Fig. 266 is a diagram showing an example of the vehicle configuration information registered in the configuration information DB.

Fig. 267 is a diagram showing an example of programs and data registered in the ECU reprogramming data DB.

Fig. 268 is a diagram showing an example of specification data registered in the ECU metadata DB.

Fig. 269 is a diagram showing an example of the configuration information of the vehicle registered in the individual vehicle information DB.

Fig. 270 is a diagram showing an example of distribution packet data registered in the packet DB.

Fig. 271 is a diagram showing an example of activity data registered in the activity DB.

Fig. 272 is a flowchart showing a process of generating programs and data registered in the ECU reprogramming data DB.

Fig. 273 is a flowchart showing an example of processing for generating specification data registered in the ECU metadata DB.

Fig. 274 is a diagram showing an example of specification data.

Fig. 275 is a diagram showing an example of a bus load table.

Fig. 276 is a flowchart showing a process of generating a distribution packet registered in the packet DB.

Fig. 277 is a diagram graphically showing the contents of a packet file.

Fig. 278 is a sequence diagram showing a flow of processing executed between the center device and the vehicle-side system in the second embodiment.

Fig. 279 is a flowchart showing a process performed by the center device.

Fig. 280 is a diagram graphically showing the contents of processing performed in steps D6 and D7 of the flowchart shown in fig. 279.

Fig. 281 is a flowchart showing a process in the case of transmitting a hash value from the vehicle-side system to the center device.

Fig. 282 is a sequence diagram showing a flow of processing executed between the center device and the vehicle-side system in the third embodiment.

Fig. 283 is a flowchart showing the processing performed by the center device.

Fig. 284 is a sequence diagram showing a state in which the center apparatus notifies the EV vehicle and the legacy vehicle by SMS.

Fig. 285 is a sequence diagram showing a flow of processing executed between the center device and the vehicle-side system in the fourth embodiment.

Fig. 286 is a diagram graphically showing processing performed among suppliers, a center device, and a vehicle-side system in the fifth embodiment.

Fig. 287 is a sequence diagram (1) showing a flow of processing performed among the suppliers, the center device, and the vehicle-side system.

Fig. 288 is a sequence diagram (2) showing a flow of processing performed among the suppliers, the center device, and the vehicle-side system.

Fig. 289 is a sequence diagram (fig. 3) showing a flow of processing performed among the suppliers, the center device, and the vehicle-side system.

Fig. 290 is a modification (1) of the first embodiment, and is a diagram showing a data format of a packet DB in a case where a plurality of packets are associated with one activity.

Fig. 291 is a diagram showing the data format of an activity DB in the case where a plurality of packets are associated with one activity.

Fig. 292 is a diagram corresponding to fig. 273 in the case where specification data is generated for each group.

Fig. 293 is a diagram corresponding to fig. 276 in the case where distribution packets are generated by groups.

Fig. 294 is a modification (2) of the first embodiment, and shows the processing contents of the packet generation tool.

Detailed Description

Hereinafter, an embodiment will be described with reference to the drawings. A vehicle program rewriting system (corresponding to a vehicle electronic Control system) is a system capable of rewriting, by OTA (Over The Air), application programs such as vehicle Control and diagnosis that are installed in an electronic Control device (hereinafter referred to as an ecu (electronic Control unit)). In the present embodiment, the description has been given of the case where the application program is rewritten by wire or wirelessly, but the present invention can also be applied to the case where data used in various applications, such as map data used in a map application and control parameters used in an ECU, are rewritten by wire or wirelessly.

The rewriting of the application program by the wire includes not only acquiring the application program from the outside of the vehicle via the wire and rewriting the application program, but also acquiring various data used when the application program is executed from the outside of the vehicle via the wire and rewriting the data. Rewriting of an application by wireless includes acquiring an application from outside the vehicle via wireless and rewriting the application, and acquiring various data used when the application is executed from outside the vehicle via wireless and rewriting the data.

As shown in fig. 1, the vehicle program rewriting system 1 includes a center device 3 on the communication network 2 side, a vehicle-side system 4 on the vehicle side, and a display terminal 5. The communication network 2 includes, for example, a mobile communication network using a 4G line or the like, the internet, WiFi (Wireless Fidelity) (registered trademark), and the like. In the present embodiment, the configuration of the vehicle side will be mainly described, and the configuration of the center device 3 will be described in detail with reference to fig. 234 to 270.

The display terminal 5 is a terminal having a function of receiving an operation input from a user and a function of displaying various screens, and is a mobile terminal 6 such as a smartphone or tablet that can be carried by the user, and an in-vehicle display 7 disposed in a vehicle compartment. The mobile terminal 6 can perform data communication with the center device 3 via the communication network 2 when it is within the communication range of the mobile communication network. The in-vehicle display 7 may be connected to the vehicle-side system 4 and may also have a navigation function. The in-vehicle display 7 may be an in-vehicle display ECU having a function of an ECU, or may have a function of controlling display to a center display, a meter display, or the like.

When the user is outside the vehicle and within the communication range of the mobile communication network, the user can perform the procedure for rewriting the application program by performing operation input while checking various screens for rewriting the application program by the mobile terminal 6. The user can perform the procedure for rewriting the application program by performing an operation input while checking various screens for rewriting the application program on the in-vehicle display 7 in the vehicle. That is, the user can use the mobile terminal 6 and the in-vehicle display 7 separately outside and inside the vehicle compartment, and perform the procedure for rewriting the application program.

The center device 3 integrates the program update function on the communication network 2 side in the vehicle program rewriting system 1, and functions as an OTA center. The center device 3 includes a file server 8, a web server 9, and a management server 10, and the servers 8 to 10 are configured to be capable of data communication with each other. That is, the center device 3 includes a plurality of different servers for each function.

The file server 8 is a server that manages files of the application programs distributed from the center apparatus 3 to the vehicle-side system 4. The file server 8 manages update Data (hereinafter, also referred to as "reprogramming-Data") provided from a supplier or the like, which is a provider of an application program distributed from the center apparatus 3 to the vehicle-side system 4, write Data, distribution specification Data provided from an OEM (Original Equipment Manufacturer), a vehicle state acquired from the vehicle-side system 4, and the like. The file server 8 is capable of performing data communication with the vehicle-side system 4 via the communication network 2, and when a download request of a distribution packet is generated, transmits the distribution packet in which the reprogramming data and the distribution specification data are packaged into one file to the vehicle-side system 4.

The web server 9 is a server for managing web information. The web server 9 transmits the web data managed by itself in response to a request from a web browser provided in the mobile terminal 6 or the like. The management server 10 is a server that manages personal information of users registered in the rewriting service of the application program, a rewriting history of the application program for each individual vehicle, and the like.

The vehicle-side system 4 includes a host device 11 (corresponding to a vehicle host device). The host device 11 includes a DCM (Data Communication Module) 12 (corresponding to an in-vehicle Communication device) and a CGW (Central Gate Way) 13 (corresponding to a vehicle gateway device). DCM12 and CGW13 are connected via a first bus 14 to enable data communication. The DCM12 communicates data with the center apparatus 3 via the communication network 2. When the DCM12 downloads the distribution package from the file server 8, it extracts write data from the downloaded distribution package, and transmits the extracted write data to the CGW 13.

The CGW13 has a data relay function, and when acquiring write data from the DCM12, instructs the writing of the acquired write data to the rewrite target ECU that is the rewrite target of an application program, and distributes the write data to the rewrite target ECU. When the writing of the write data is completed and the rewriting of the application is completed in the ECU to be rewritten, CGW13 instructs the ECU to be rewritten to activate the application after the completion of the rewriting.

The host device 11 integrates a program update function on the vehicle side in the vehicle program rewriting system 1, and functions as an OTA host. Note that, although fig. 1 illustrates a configuration in which the DCM12 and the vehicle-mounted display 7 are connected to the same first bus 14, a configuration in which the DCM12 and the vehicle-mounted display 7 are connected to different buses may be employed. In addition, CGW13 may have a part or whole structure of the function of DCM12, or DCM12 may have a part or whole structure of the function of CGW 13. That is, in the host apparatus 11, the DCM12 and the CGW13 may be assigned functions at any time. The host apparatus 11 may be configured by 2 ECUs of DCM12 and CGW13, or may be configured by one integrated ECU having the functions of DCM12 and CGW 13.

In addition to the first bus 14, a second bus 15, a third bus 16, a fourth bus 17, and a fifth bus 18 are connected to the CGW13 as buses on the vehicle interior side, and various ECUs 19 are connected via the buses 15 to 17, and a power management ECU20 is connected via the bus 18.

The second bus 15 is, for example, a bus of a vehicle body system network. The ECU19 connected to the second bus 15 is an ECU that controls the vehicle body system. The ECU that controls the vehicle body system includes, for example, a door ECU that controls locking/unlocking of a door, a meter ECU that controls display on a meter display, an air conditioner ECU that controls driving of an air conditioner, a window ECU that controls opening/closing of a window, a safety ECU that is driven for theft prevention of a vehicle, and the like.

The third bus 16 is, for example, a bus of a travel system network. The ECU19 connected to the third bus 16 is an ECU that controls the running system. The ECU that controls the traveling system includes, for example, an engine ECU that controls driving of an engine, a brake ECU that controls driving of a brake, an ECT (Electronic Controlled Transmission) ECU that controls driving of an automatic Transmission, a power steering ECU that controls driving of power steering, and the like.

The fourth bus 17 is for example a bus of a multimedia system network. The ECU19 connected to the fourth bus 17 is an ECU that controls the multimedia system. The ECU that controls the multimedia System is, for example, a navigation ECU that controls a navigation System, an ETC ECU that controls an Electronic Toll Collection System (ETC), or the like. The buses 15 to 17 may be buses of systems other than the vehicle body system network, the traveling system network, and the multimedia system network. The number of buses and the number of ECUs 19 are not limited to the illustrated configuration.

The electric power source management ECU20 is an ECU that manages electric power supplied to the DCM12, the CGW13, various ECUs 19, and the like.

The sixth bus 21 is connected to the CGW13 as a bus on the vehicle outer side. A DLC (Data Link Coupler) connector 22 to which a tool 23 (corresponding to a service tool) is detachably connected is connected to the sixth bus 21. The vehicle-interior buses 14 to 18 and the vehicle-exterior bus 21 are each constituted by a CAN (Controller Area Network, registered trademark) bus, for example, and the CGW13 performs data communication with the DCM12, the various ECUs 19 and the tool 23 in accordance with the data communication standard and the diagnostic communication standard (uds) (ISO 14229) of the CAN. Further, DCM12 and CGW13 may be connected via ethernet, and DLC connector 22 and CGW13 may be connected via ethernet.

Upon receiving the write data from the CGW13, the ECU19 to be rewritten writes the received write data in a flash memory (corresponding to a nonvolatile memory) to rewrite the application program. In the above configuration, CGW13 functions as a reprogramming master that distributes write data to rewrite target ECU19 when receiving a request to acquire write data from rewrite target ECU 19. The rewrite target ECU19 functions as a reprogramming device that, when receiving write data from the CGW13, writes the received write data in a flash memory to rewrite an application.

As a method of rewriting the application program, there are a method of performing rewriting by wire and a method of performing rewriting by wireless. The method of rewriting the application program by wire is a method of rewriting the ECU19 to be rewritten by using an application program acquired from the outside of the vehicle through wire. Specifically, if tool 23 is connected to DLC connector 22, tool 23 transmits the write data to CGW 13. The CGW13 functions as a gateway, transmits a wired rewrite request to the rewrite target ECU19, instructs the rewrite target ECU19 to write (install) write data, and distributes the write data transmitted from the tool 23 to the rewrite target ECU 19. The distribution of the write data to the rewrite target ECU19 is to relay the write data.

The method of rewriting the application program by wireless is a method of rewriting the ECU19 to be rewritten by using an application program acquired wirelessly from outside the vehicle. Specifically, when the DCM12 downloads the distribution package from the file server 8, it extracts the write data from the downloaded distribution package and transfers the write data to the CGW 13. The CGW13 functions as a rewriting tool that instructs the rewrite target ECU19 to write (install) write data, and distributes the write data transmitted from the DCM12 to the rewrite target ECU 19.

The diagnostic ECU19 may be a wired diagnostic system or a wireless diagnostic system. The wired diagnosis method is a method of diagnosing the ECU19 from outside the vehicle via a wired line. Specifically, if the tool 23 is connected to the DLC connector 22, the tool 23 transmits a diagnostic request to CGW 13. CGW13 functions as a gateway, transmits a diagnosis request to diagnosis target ECU19, and distributes a diagnosis command transmitted from tool 23 to diagnosis target ECU 19. The diagnosis target ECU19 performs a diagnosis process corresponding to the diagnosis command received from the CGW 13.

The wireless diagnosis method is a method of diagnosing the ECU19 from outside the vehicle via wireless. Specifically, if the diagnostic command is transmitted as a diagnostic request from the center apparatus 3 to the DCM12, the DCM12 transmits the diagnostic command to the CGW 13. CGW13 functions as a gateway and distributes a diagnosis command to ECU19 to be diagnosed as a diagnosis request. The diagnosis target ECU performs a diagnosis process corresponding to the diagnosis command received from CGW 13.

As shown in fig. 2, CGW13 includes a microcomputer (hereinafter, referred to as a "microcomputer") 24, a data transmission circuit 25, a power supply circuit 26, and a power supply detection circuit 27 as electrical functional blocks. The microcomputer 24 includes a CPU (Central Processing Unit) 24a, a ROM (Read Only Memory) 24b, a RAM (Random Access Memory) 24c, and a flash Memory 24 d. The flash memory 24d includes a secure area from which information cannot be read out from outside the CGW 13. The microcomputer 24 executes various control programs stored in the non-transitory tangible storage medium to perform various processes, thereby controlling the operation of the CGW 13.

The data transmission circuit 25 controls data communication between the buses 14 to 18, 21 according to the data communication standard of the CAN and the diagnostic communication standard. The power supply circuit 26 inputs a battery power supply (hereinafter referred to as a + B power supply), an accessory power supply (hereinafter referred to as an ACC power supply), and an ignition power supply (hereinafter referred to as an IG power supply). The power supply detection circuit 27 detects the voltage value of the + B power supply, the voltage value of the ACC power supply, and the voltage value of the IG power supply input from the power supply circuit 26, compares these detected voltage values with a predetermined voltage threshold, and outputs the comparison result to the microcomputer 24. The microcomputer 24 determines whether the + B power supply, the ACC power supply, and the IG power supply supplied from the outside to the CGW13 are normal or abnormal, based on the comparison result input from the power supply detection circuit 27.

As shown in fig. 3, the DCM12 has the microcomputer 28, the radio circuit 29, the data transmission circuit 30, the power supply circuit 31, and the power supply detection circuit 32 as electrical functional blocks. The microcomputer 28 has a CPU28a, a ROM28b, a RAM28c, and a flash memory 28 d. The flash memory 28d includes a secure area in which information cannot be read from outside the DCM 12. The microcomputer 28 executes various control programs stored in the non-transitory tangible storage medium to perform various processes, and controls the operations of the DCM 12. A flash memory for storing data downloaded from the center device 3 may also be provided in the CGW 13.

The wireless circuit 29 controls data communication with the center apparatus 3 via the communication network 2. The data transmission circuit 30 controls data communication with the bus 14 in accordance with the data communication standard of CAN. The power supply circuit 31 receives + B power supply, ACC power supply, and IG power supply. The power supply detection circuit 32 detects the voltage value of the + B power supply, the voltage value of the ACC power supply, and the voltage value of the IG power supply input from the power supply circuit 31, compares these detected voltage values with a predetermined voltage threshold, and outputs the comparison result to the microcomputer 28. The microcomputer 28 determines whether the + B power supply, the ACC power supply, and the IG power supply supplied from the outside to the DCM12 are normal or abnormal, based on the comparison result input from the power supply detection circuit 32.

DCM12 has a vehicle position detection function for detecting a vehicle position by, for example, a GPS (Global Positioning System). The flash memory 28d of the DCM12 has a sufficient memory capacity to store the distribution packets downloaded from the center apparatus 3, and has a larger memory capacity than the flash memory 24d of the CGW 13. That is, since the flash memory 28d of the DCM12 has a sufficient memory capacity, even if the flash memory 24d of the CGW13 has no sufficient memory capacity, the host apparatus 11 can download the distribution packet from the center apparatus 3 and accumulate the downloaded distribution packet in the DCM 12.

As shown in fig. 4, the ECU19 has the microcomputer 33, the data transmission circuit 34, the power supply circuit 35, and the power supply detection circuit 36 as electrical function blocks. The microcomputer 33 has a CPU28a, a ROM28b, a RAM33c, and a flash memory 28 d. The flash memory 28d includes a safety region in which information cannot be read from outside the ECU 19. The microcomputer 33 executes various control programs stored in the non-transitory tangible storage medium to perform various processes, thereby controlling the operation of the ECU 19.

The data transmission circuit 34 controls data communication with the buses 15 to 17 according to the data communication standard of the CAN. The power supply circuit 35 inputs a + B power supply, an ACC power supply, and an IG power supply. The power supply detection circuit 36 detects the voltage value of the + B power supply, the voltage value of the ACC power supply, and the voltage value of the IG power supply input from the power supply circuit 35, compares these detected voltage values with a predetermined voltage threshold, and outputs the comparison result to the microcomputer 33. The microcomputer 33 determines whether the + B power supply, the ACC power supply, and the IG power supply supplied from the outside to the ECU19 are normal or abnormal, based on the comparison result input from the power supply detection circuit 27. The ECU19 has basically the same configuration except for the difference in load of, for example, sensors, actuators, and the like connected to the ECU.

The in-vehicle display 7 has the same configuration as the ECU19 shown in fig. 4. The electric power source management ECU20 has the same configuration as the ECU19 shown in fig. 4. The power supply management ECU20 is connected to be able to perform data communication with the power supply control circuit 43 described later.

As shown in fig. 5, the electric power source management ECU20, CGW13, and ECU19 are connected to the + B electric power source line 37, ACC electric power source line 38, and IG electric power source line 39 as electric power source supply lines. The + B power supply line 37 is connected to the positive electrode of the vehicle battery 40. The ACC power supply line 38 is connected to the positive electrode of the vehicle battery 40 via an ACC switch 41. When the user performs the ACC operation, the ACC switch 41 is switched from off to on, and the output voltage of the vehicle battery 40 is applied to the ACC power supply line 38. For example, if the vehicle is of a type in which a key is inserted into an insertion opening, the ACC operation is an operation in which the key is inserted into the insertion opening and turned from the "OFF" position to the "ACC" position, and if the vehicle is of a type in which a start button is pressed, the ACC operation is an operation in which the start button is pressed once.

The IG power supply line 39 is connected to a positive electrode of the vehicle battery 40 via an IG switch 42. When the user performs an IG operation, the IG switch 42 is switched from off to on, and the output voltage of the vehicle battery 40 is applied to the IG power supply line 39. For example, in a vehicle of a type in which a key is inserted into an insertion opening, the IG operation is an operation of inserting the key into the insertion opening and turning the key from the "OFF" position to the "ON" position, and in a vehicle of a type in which a start button is pressed, the IG operation is an operation of pressing the start button twice. The negative electrode of the vehicle battery 40 is grounded.

When both the ACC switch 41 and the IG switch 42 are off, only the + B power is supplied to the vehicle-side system 4. A state in which only + B power is supplied to the vehicle-side system 4 is referred to as a + B power state. When the ACC switch 41 is on and the IG switch 42 is off, the ACC electric power and the + B electric power are supplied to the vehicle-side system 4. The state in which the ACC power supply and the + B power supply are supplied to the vehicle-side system 4 is referred to as an ACC power supply state. When both the ACC switch 41 and the IG switch 42 are turned on, the + B power source, the ACC power source, and the IG power source are supplied to the vehicle-side system 4. A state in which the + B power supply, the ACC power supply, and the IG power supply are supplied to the vehicle-side system 4 is referred to as an IG power supply state. In addition to the above-described power supply states, a power supply state to which power is supplied suitable for updating by a wireless program may be considered.

The ECU19 differs in the activation condition depending on the electric power source state, and is classified into a + B electric power source system ECU activated in the + B electric power source state, an ACC system ECU activated in the ACC electric power source state, and an IG system ECU activated in the IG electric power source state. The ECU19 driven for use in, for example, vehicle theft prevention is classified as a + B power supply system ECU. The ECU19 driven for use in a non-travel system such as audio is classified as an ACC system ECU. The ECU19 driven for use in a traveling system such as engine control is classified as an IG system ECU.

The + B electric power system ECU is connected to the + B electric power line 37, the ACC electric power line 38, and the IG electric power line 39, and is configured to select the + B electric power line 37 in the + B electric power state, the ACC electric power line 38 in the ACC electric power state, and the IG electric power line 39 in the IG electric power state. The ACC system ECU is connected to an ACC power supply line 38 and an IG power supply line 39, and selects the ACC power supply line 38 in the ACC power supply state and the IG power supply line 39 in the IG power supply state. The IG system ECU is connected to an IG power supply line 39.

The CGW13 transmits the activation request to the ECU19 in the sleep state, thereby causing the ECU19 to which the activation request is transmitted to shift from the sleep state to the activation state. In addition, CGW13 transmits a sleep request to ECU19 in the active state, thereby causing ECU19 as a transmission destination of the sleep request to shift from the active state to the sleep state. For example, CGW13 can cause specific ECU19 to shift to an active state or a sleep state by making waveforms of transmission signals to buses 15 to 17 different. That is, the ECU19 determines the activation request waveform and the sleep request waveform in advance, and the ECU19 shifts from the sleep state to the activation state when receiving the activation request waveform suitable for itself, and shifts from the activation state to the sleep state when receiving the sleep request waveform suitable for itself from the CGW 13.

For example, when the ECU (ID1) and the ECU (ID2) are in the activated state, the CGW13 transmits the first waveform to cause the ECU (ID1) to transition from the activated state to the sleep state, and holds the ECU (ID2) in the activated state. When the ECU (ID1) and the ECU (ID2) are in the activated state, the CGW13 transmits the second waveform to hold the ECU (ID1) in the activated state, and to shift the ECU (ID2) from the activated state to the sleep state.

The power supply control circuit 43 is connected in parallel to the ACC switch 41 and the IG switch 42. The CGW13 transmits a power control request to the power management ECU20, causing the power management ECU20 to control the power control circuit 43. That is, the CGW13 connects the ACC power supply line 38, the IG power supply line 39 and the positive electrode of the vehicle battery 40 inside the electric power supply control circuit 43 by transmitting an electric power source activation request as an electric power source control request to the electric power source management ECU 20. In this state, even if the ACC switch 41 and the IG switch 42 are off, the ACC power source and the IG power source are supplied to the vehicle-side system 4. In addition, the CGW13 turns off the positive electrodes of the ACC power supply line 38, the IG power supply line 39 and the vehicle battery 40 inside the electric power supply control circuit 43 by transmitting an electric power source stop request as an electric power source control request to the electric power source management ECU 20.

The DCM12, CGW13, ECU19, and power management ECU20 each have a power self-holding circuit and have a power self-holding function of holding power supply from the vehicle battery 40. That is, when the vehicle electric power source is switched from the ACC electric power source or the IG electric power source to the + B electric power source in the activated state, the DCM12, the CGW13, the ECU19, and the electric power source management ECU20 do not immediately shift from the activated state to the stopped state or the sleep state after the switching, but continue the activated state for a predetermined time (for example, several minutes) by the electric power supply from the vehicle battery 40, and self-hold the drive electric power source. DCM12, CGW13, ECU19, and electric power source management ECU20 shift from the activated state to the deactivated state or the sleep state after a prescribed time has elapsed since the vehicle electric power source was switched from the ACC electric power source or the IG electric power source to the + B electric power source. For example, in the case of the ECU19 of the engine control system, various data related to engine control acquired while the vehicle is running are stored as logs by operating the power supply self-holding function after the vehicle power supply is switched from the ACC power supply or the IG power supply to the + B power supply.

Next, a distribution packet distributed from the center device 3 to the host device 11 will be described. As shown in fig. 6, in the vehicle program rewriting system 1, rewriting data is generated based on written data supplied from a supplier of a supplier as an application program and rewriting specification data (corresponding to specification data) supplied from an OEM. The rewriting specification data may be generated in the center device 3. The write data supplied from the supplier includes differential data corresponding to a difference between the old application and the new application and all data corresponding to the entire new application. The differential data and the entire data may be compressed by a known data compression technique. Fig. 6 illustrates a case where the differential data is supplied from the suppliers a to C as the write data, and the rebuilt data is generated from the encrypted differential data and the certifier of the ECU (ID1) supplied from the supplier a, the encrypted differential data and the certifier of the ECU (ID2) supplied from the supplier B, the encrypted differential data and the certifier of the ECU (ID3) supplied from the supplier C, and the rewriting specification data supplied from the OEM.

The authenticator is data given to each write data in order to verify the integrity of the differential data, and is generated from, for example, the ecu (id), the key information associated with the ecu (id), and the differential data. Here, when rewriting of the application is cancelled in the middle, write data for writing back (rolling back) to the old version may be included in the rebuilt data.

The rewriting specification data provided from the OEM includes information relating to rewriting of the application, such as information enabling specification of the ECU19 to be rewritten, information enabling specification of the rewriting order in the case where there are a plurality of ECUs 19 to be rewritten, and information enabling specification of a rollback method described later. The rewriting specification data is data defining operations related to rewriting in the DCM12, the CGW13, the rewrite target ECU19, and the like. The rewriting specification data is classified into the rewriting specification data for DCM used in DCM12 and the rewriting specification data for CGW used in CGW 13.

As shown in fig. 7, the rewriting specification data for DCM includes specification data information and ECU information. The specification data information includes address information and a file name. The ECU information includes address information and the like referred to when the update program (write data) of each rewrite target ECU19 is transmitted to the CGW13, the number of which corresponds to the number of rewrite target ECUs 19. Specifically, the ECU information includes at least an ID (ECU (ID)) for identifying the ECU, a reference address (update program acquisition address) for acquiring the update program, an update program size, a reference address (rollback program acquisition address) for acquiring the rollback program, and a rollback program size. The rollback program is a program (write data) for returning the application program to the original version when rewriting of the application program is cancelled in the middle.

As shown in fig. 8, the rewriting specification data for CGW includes group information, a bus load table, a battery load, a vehicle state at the time of rewriting, and ECU information. The rewriting specification data for CGW may include rewriting procedure information, displayed scene information, and the like in addition to these. The group information is information indicating a group to which the ECU19 to be rewritten belongs and a rewriting order, and defines, for example, as the first group information, contents of an application to be rewritten in the order of the ECU (ID1), the ECU (ID2), and the ECU (ID3), and defines, as the second group information, contents of an application to be rewritten in the order of the ECU (ID4), the ECU (ID5), and the ECU (ID 6). The bus load table is a table shown in the later-described diagram 100, and will be described in detail later. The battery load is information indicating a lower limit value of the remaining battery level of the vehicle battery 40 that can be permitted in the vehicle. The vehicle state at the time of rewriting is information indicating which state the vehicle state is in.

The ECU information is information related to the rewrite target ECU19, and includes at least an ECU _ ID (corresponding to device identification information), a connection bus (corresponding to bus identification information), a connection power supply, security access key information, a memory type, a rewriting method, a power supply self-holding time, rewrite plane information, an update program version, an update program acquisition address, an update program size, a rollback program version, a rollback program acquisition address, a rollback program size, and a write data type.

The connection bus means a bus to which the ECU19 is connected. The connection power source represents a power line to which the ECU19 is connected. The secure access key information indicates key information used for authentication of CGW13 to access rewrite target ECU19, and includes a random value or unique information, a key pattern, and a decryption operation pattern. The memory type indicates whether the memory mounted on the ECU19 to be rewritten is a single-sided individual memory, a single-sided suspend memory (also referred to as a pseudo dual-sided memory), or a dual-sided memory. The rewriting method indicates which of the rewriting by power supply self-holding and the rewriting by power supply control is performed. The power supply self-hold time indicates a time for continuing the power supply self-hold when the rewriting method is based on the rewriting of the power supply self-hold. The rewrite plane information indicates which plane is an operation plane and which plane is a non-operation plane. The working surface is also called the start surface and the non-working surface is also called the rewrite surface.

The update program version indicates a version of the update program. The update program acquisition address indicates an address of the update program. The update program size indicates the data size of the update program. The rollback program version represents a version of the rollback program. The rollback program acquisition address represents the address of the rollback program. The rollback program size represents the data size of the rollback program. The write data type indicates which type of the differential data and the entire data the write data is. The rewriting specification data may include information defined by the system itself, in addition to the above information.

When the DCM12 acquires the rewriting specification data for the DCM, the acquired rewriting specification data for the DCM is analyzed. When DCM12 analyzes the rewriting specification data for the DCM, it controls the operation related to rewriting such as acquiring write data from an address where an update program of ECU19 to be rewritten is stored, and transferring the acquired write data to CGW 13.

When the CGW13 acquires the rewriting specification data for CGW, the acquired rewriting specification data for CGW is analyzed. When CGW13 analyzes the rewriting specification data for CGW, it controls operations related to rewriting such as requesting DCM12 to transfer a predetermined size amount of an update program of rewrite target ECU19 or distributing write data to rewrite target ECU19 in a designated order, based on the analysis result.

The above-described rebuilt data is registered in the file server 8, and distribution specification data provided from the OEM is registered. The distribution specification data supplied from the OEM is data defining operations related to display of various screens in the display terminal 5. As shown in fig. 9, the distribution specification data includes language information, display words, packet information, image data, display modes, display control programs, and the like.

When the display terminal 5 acquires the distribution specification data from CGW13, it analyzes the acquired distribution specification data and controls the display of various screens according to the analysis result. The display terminal 5 displays a display sentence acquired from the distribution specification data in a superimposed manner on a display frame held in advance, or executes a display control program acquired from the distribution specification data, for example. The distribution specification data may include information defined by the system itself, in addition to the above information.

When the reprogramming data and the distribution specification data are registered, the file server 8 encrypts the registered reprogramming data to generate a distribution packet in which a packet authentication character for authenticating the packet, the encrypted reprogramming data, and the distribution specification data are stored. The certifier is data given to verify the integrity of the reprogramming data and the distribution specification data, and is generated from, for example, key information, reprogramming data, and distribution specification data associated with CGW 13. When receiving a download request of the distribution packet from the outside, the file server 8 transmits the distribution packet to the DCM 12. In addition, fig. 6 illustrates a case where the file server 8 generates a distribution package in which the reprogramming data and the distribution specification data are stored, and transmits the reprogramming data and the distribution specification data to the DCM12 as one file at the same time, but the reprogramming data and the distribution specification data may be transmitted to the DCM12 as different files. That is, the file server 8 may first send the distribution specification data to the DCM12, and then send the reassembled data to the DCM 12. In this case, the distribution specification data and the rebuilt data may be given authentication codes.

As shown in fig. 10, when the DCM12 downloads the distribution packet from the file server 8, the integrity of the encrypted reprogramming data is verified by using the packet authenticator stored in the downloaded distribution packet. If the verification result is positive, DCM12 decrypts the encrypted reassembled data. When the DCM12 decrypts the encrypted reprogramming data, the decrypted reprogramming data is unpacked (upnp ackaging), divided into encrypted differential data and an authenticator, rewriting specification data for DCM, and rewriting specification data for CGW, and extracted. Fig. 10 illustrates an example of the case where the encrypted differential data and the certifier are divided into the ECU (ID1), the ECU (ID2), the ECU (ID3), the DCM rewrite specification data, and the CGW rewrite specification data.

Next, the flash memory 33d of the ECU19 will be described with reference to fig. 11 to 22. The flash memory 33d of the ECU19 is classified into a single-sided individual memory having a flash memory surface on the 1 plane, a single-sided suspended memory having a flash memory surface on the 2 plane, and a double-sided memory having a flash memory surface on the substantially 2 plane, according to the memory configuration. After that, the ECU19 equipped with the single-sided individual memory is referred to as a single-sided individual memory ECU, the ECU19 equipped with the single-sided suspended memory is referred to as a single-sided suspended memory ECU, and the ECU19 equipped with the double-sided memory is referred to as a double-sided memory ECU.

Since the single-sided individual memory has a flash memory surface on one side, it is impossible to rewrite an application program in executing the application program without using the concept of an operation surface and a non-operation surface. On the other hand, since the single-sided suspend memory and the double-sided memory have a configuration in which the 2-sided flash memory is provided, there are concepts of an operating side and a non-operating side, and an application program of the non-operating side can be rewritten among application programs that execute the operating side. Since the dual-sided memory has a flash memory surface on the completely separated 2-side, the application can be rewritten at any timing during vehicle running or the like. The single-sided suspend memory is configured by dividing a single-sided individual memory into 2 sides in a pseudo manner, and there is a limit to the timing at which reading and writing can be normally performed, and the application cannot be rewritten while the vehicle is traveling, and can be rewritten during parking with the IG power off.

The single-sided individual memory, the single-sided suspended memory, and the double-sided memory are of a reprogramming firmware embedded type (hereinafter, referred to as an embedded type) in which reprogramming firmware is embedded, and a reprogramming firmware download type (hereinafter, referred to as a download type) in which reprogramming firmware is downloaded from the outside, respectively. The reprogramming firmware is firmware for rewriting the application program.

The structure of each flash memory will be explained in sequence below.

(A) Single-sided single memory

(A-1) Embedded Single-sided Individual memory

The embedded single-sided individual memory will be described with reference to fig. 11 and 12. The embedded single-sided individual memory has a differential engine operating area, an application area, and a boot program area. Version information, parameter data, application programs, firmware, and a normal vector table are arranged in the application program area. In the boot area, a boot program, a progress state point 2, a progress state point 1, boot judgment information, wireless reprogramming firmware, wired reprogramming firmware, a boot judgment program, and a boot time vector table are arranged.

As shown in fig. 11, when executing normal operations of application processes such as a vehicle control process and a diagnostic process, the microcomputer 33 executes a start judgment program, searches for a start address by referring to the guidance-time vector table and the normal-time vector table, and executes a predetermined address of the application program.

When the microcomputer 33 executes the rewriting operation of the rewriting process of the application program, it executes the wireless or wired reprogramming of the firmware without executing the application program. Fig. 12 shows an operation of rewriting an application program using differential data as an update program. As shown in fig. 12, the microcomputer 33 temporarily stores the application program as old data in the differential engine operation area. The microcomputer 33 reads the old data temporarily stored in the differential engine operating region, and restores new data from the read old data and the differential data stored in the RAM33c by the differential engine included in the embedded reprogramming firmware. When new data is generated from the old data and the differential data, the microcomputer 33 writes the new data to a predetermined address of the memory to rewrite the application program.

(A-2) download type single-sided individual memory

The download-type single-sided individual memory will be described with reference to fig. 13 and 14. The download type is different from the embedded type in that the wireless reprogramming firmware and the wired reprogramming firmware are downloaded from the outside, and the wireless reprogramming firmware and the wired reprogramming firmware are deleted after the application program is rewritten. In the case of updating the application program by wireless, wireless reprogramming firmware executed by each ECU19 is included in the reprogramming data shown in fig. 6, for example, in advance. The ECU19 receives the wireless reprogramming firmware for the self-ECU from the CGW13, and stores the received wireless reprogramming firmware for the self-ECU in the RAM.

As shown in fig. 13, when executing normal operations of application processes such as a vehicle control process and a diagnostic process, the microcomputer 33 executes a start judgment program in the same manner as the embedded type, searches for a start address by referring to the guidance-time vector table and the normal-time vector table, and executes a predetermined address of the application program.

As shown in fig. 14, the microcomputer 33 temporarily stores the application program as old data in the differential engine operation area when the rewrite operation of the rewrite processing of the application program is executed. The microcomputer 33 reads the old data temporarily stored in the differential engine operation area, and restores new data from the read old data and the differential data stored in the RAM33c by the differential engine included in the reprogramming firmware downloaded from the outside. When new data is generated from the old data and the differential data, the microcomputer 33 writes the new data to rewrite the application program.

(B) Single-sided suspend memory

(B-1) Embedded Single-sided suspend memory

The embedded single-sided suspend memory will be described with reference to fig. 15 and 16. The embedded single-sided nonvolatile memory has a differential engine operating region, an application region, and a boot region. The reprogramming firmware for updating the program is arranged in the boot program area in the same manner as the single-sided individual memory, and is not the target of program update. An application area that is an object of program update has an a-plane and a B-plane in a pseudo manner, and version information, an application, and a normal-time vector table are arranged on the a-plane and the B-plane, respectively. The boot area is provided with a boot program, a reprogramming firmware, a reprogramming vector table, a boot plane determination function, boot plane determination information, and a boot vector table.

As shown in fig. 15, the microcomputer 33 executes a boot program to determine which of the a-plane and the B-plane is the operation plane from the respective start plane determination information of the a-plane and the B-plane by the start plane determination function when executing normal operations of application processes such as a vehicle control process and a diagnostic process. When the microcomputer 33 determines that the a-plane is the operating plane, it refers to the normal time vector table of the a-plane to search for the start address and executes the application program of the a-plane. Similarly, when the microcomputer 33 determines that the B-plane is the operating plane, it refers to the normal time vector table of the B-plane to search for the start address, and executes the application program of the B-plane. In fig. 15, the reprogramming firmware is arranged in the boot program area, but the reprogramming firmware may be arranged in each area of the a-plane or the B-plane as a target of program update.

As shown in fig. 16, when the microcomputer 33 executes the rewrite operation of the rewrite processing of the application program of the non-operating plane, it temporarily stores the application program of the non-operating plane as old data in the differential engine operating area. The microcomputer 33 reads the old data temporarily stored in the differential engine operating region, and restores new data from the read old data and the differential data stored in the RAM33c by the differential engine embedded in the reprogramming firmware. When new data is generated from the old data and the differential data, the microcomputer 33 writes the new data into the non-operating surface to rewrite the application program of the non-operating surface. Fig. 16 illustrates a case where the a-plane is an operating plane and the B-plane is a non-operating plane.

(B-2) download type single-sided suspend memory

The download type single-sided suspend memory will be described with reference to fig. 17 and 18. The download type is different from the above-described embedded type in the point that the reprogramming firmware and the reprogramming vector table are downloaded from the outside and deleted after the application program is rewritten.

As shown in fig. 17, when executing normal operations of application processes such as a vehicle control process and a diagnostic process, the microcomputer 33 executes a boot program, determines whether the a-plane or the B-plane is an operating plane by determining whether the a-plane or the B-plane is new or old from the respective start-up plane determination information of the a-plane and the B-plane by the start-up plane determination function, as in the embedded type. When the microcomputer 33 determines that the a-plane is the operating plane, it refers to the normal time vector table of the a-plane to search for the start address and executes the application program of the a-plane. Similarly, when the microcomputer 33 determines that the B-plane is the operating plane, it refers to the normal time vector table of the B-plane to search for the start address, and executes the application program of the B-plane.

As shown in fig. 18, when the microcomputer 33 executes the rewrite operation of the rewrite processing of the application program, the application program on the non-operating surface is temporarily stored as old data in the differential engine operating area. The microcomputer 33 reads the old data temporarily stored in the differential engine operating region, and restores new data from the read old data and the differential data stored in the RAM33c by the differential engine in the re-programmed firmware downloaded from the outside. When new data is generated from the old data and the differential data, the microcomputer 33 writes the new data to rewrite the application program. Fig. 18 illustrates a case where the a surface is an operating surface and the B surface is a non-operating surface. In this way, in the single-sided suspend memory, the rewriting of the application program of the B-side can be executed in the background while the application program of the a-side is executed.

(C) Double-sided memory

(C-1) Embedded type double-sided memory

The embedded dual-sided memory will be described with reference to fig. 19 and 20. The embedded single-sided individual memory has an application program area and a rewrite program area on the a-side, an application program area and a rewrite program area on the B-side, and a boot program area. In the boot area, the boot program is configured to be unable to be rewritten. The boot program includes a boot switching function and a boot-time vector table. Version information, parameter data, application programs, firmware, and a normal vector table are arranged in each application program area. In each rewrite program area, a program for controlling rewrite, rewrite progress management information 2, rewrite progress management information 1, startup plane determination information, wireless rewrite firmware, wired rewrite firmware, and a boot-time vector table are arranged. A boot program, a boot switching function, and a boot-time vector table are arranged in the boot area.

As shown in fig. 19, the microcomputer 33 executes the boot program both at the time of executing the normal operation of the application processing such as the vehicle control processing and the diagnostic processing and at the time of executing the rewrite operation of the rewrite processing of the application program of the non-operating plane, determines whether the application program is new or old by the boot exchange function based on the respective startup plane determination information of the a plane and the B plane, and determines which of the a plane and the B plane is the operating plane. When determining that the a-plane is the operating plane, the microcomputer 33 searches for the start address with reference to the guide time vector table of the a-plane and the normal time vector table of the a-plane, and executes the application program of the a-plane. Similarly, when the microcomputer 33 determines that the B-plane is the operating plane, it refers to the guide-time vector table of the B-plane and the normal-time vector table of the B-plane to search for the start address, and executes the application program of the B-plane.

As shown in fig. 20, when the microcomputer 33 executes the rewrite operation of the rewrite processing of the application program on the non-operating side, the application program on the non-operating side is temporarily stored as old data in the differential engine operation area. The microcomputer 33 reads the old data temporarily stored in the differential engine operating region, and restores new data from the read old data and the differential data stored in the RAM33c by the differential engine embedded in the reprogramming firmware. When new data is generated from the old data and the differential data, the microcomputer 33 writes the new data into the non-operating surface and rewrites the application program of the non-operating surface. The old data temporarily stored in the differential engine operating area may be targeted for an application program of the operating plane or may be targeted for an application program of the non-operating plane. In this case, when the application program of the operating plane is targeted, the data of the non-operating plane is erased before the new data is written. Here, when the rebuilt data acquired from the outside of the vehicle is not the differential data but all the data (full data), the acquired rebuilt data is written as new data to the non-operating surface. Fig. 20 illustrates a case where the a-plane is an operating plane and the B-plane is a non-operating plane. The old data temporarily stored in the differential engine operating area may be targeted for an application program of the operating plane or may be targeted for an application program of the non-operating plane. When the execution addresses of the application programs need to be matched, the application programs on the non-operating surface are saved as old data.

(C-2) download type dual-sided memory

The download-type dual-sided memory will be described with reference to fig. 21 and 22. The download type is different from the embedded type in that the wireless reprogramming firmware and the wired reprogramming firmware are downloaded from the outside, and the wireless reprogramming firmware and the wired reprogramming firmware are deleted after the application program is rewritten.

As shown in fig. 21, the microcomputer 33 executes the boot program, determines whether the application is the active side or the active side by the boot exchange function based on the respective active side determination information of the a-side and the B-side, determines which of the a-side and the B-side is the active side, and executes the application program of the active side to execute the application processing, in the same manner as the embedded type, both at the time of executing the application processing such as the vehicle control processing, the normal operation of the diagnosis processing, and the rewrite operation of the rewrite processing of the application of the non-active side.

As shown in fig. 22, when the microcomputer 33 executes the rewrite operation of the rewrite processing of the application program, the application program on the non-operating surface is temporarily stored as old data in the differential engine operating area. The microcomputer 33 reads the old data temporarily stored in the differential engine operating region, and restores new data from the read old data and the differential data stored in the RAM33c by the reprogramming firmware downloaded from the outside. When new data is generated from the old data and the differential data, the microcomputer 33 writes the new data into the non-operating surface and rewrites the application program of the non-operating surface. The old data temporarily stored in the differential engine operating area may be targeted for an application program of the operating plane or may be targeted for an application program of the non-operating plane. In this case, when the application program of the operating plane is targeted, the data of the non-operating plane is erased before the new data is written. Here, when the rebuilt data acquired from the outside of the vehicle is not the differential data but all the data (full data), the acquired rebuilt data is written as new data to the non-operating surface. Fig. 22 illustrates a case where the a-plane is an operating plane and the B-plane is a non-operating plane. The old data temporarily stored in the differential engine operating area may be targeted for an application program of the operating plane or may be targeted for an application program of the non-operating plane. In this way, in the dual-sided memory, the rewriting of the application program on the B-side can be executed in the background while the application program on the a-side is executed.

As described above, in both the embedded type and the download type, the application program and the rewrite program for rewriting the application program are arranged in each application area. In fig. 20 and 22, the application program is shown as the reprogramming object, but the rewriting program may be performed as the reprogramming object. In addition, when it is desired that the rewrite program cannot be rewritten, the rewrite program may be arranged in the boot area. The program for wired rewriting may be arranged in the guide area so that, for example, the dealer or the like can reliably rewrite data by wired communication via the tool 23.

Next, the entire procedure of rewriting the application program will be described with reference to fig. 23 to 25. Here, although a case where the user operates the mobile terminal 6 as the display terminal 5 to rewrite the application program during parking is described, the same applies to a case where the user operates the in-vehicle display 7 to rewrite the application program during parking. The distribution packet transmitted from the center apparatus 3 to the DCM12 stores one or more write data of the rewrite target ECU 19. That is, in the distribution packet, if there is one rewrite target ECU19, one piece of write data for the one rewrite target ECU19 is stored, and if there are a plurality of rewrite target ECUs 19, a plurality of pieces of write data for each of the plurality of rewrite target ECUs 19 are stored. Here, there are 2 rewrite target ECUs 19, and the 2 rewrite target ECUs 19 are referred to as rewrite target ECUs (ID1) and rewrite target ECUs (ID 2). The ECUs 19 other than the ECU to be rewritten (ID1) and the ECU to be rewritten (ID2) are referred to as other ECUs.

When it is determined that a request for transmitting a version notification signal is received from the host device 11, for example, the ECU to be rewritten (ID1) and the ECU to be rewritten (ID2) each determine that the transmission condition of the version notification signal is satisfied. When the transmission condition of the version notification signal is satisfied, the rewrite target ECU (ID1) transmits a version notification signal including version information of the application stored in itself and the ECU (ID) capable of identifying itself to the host apparatus 11. Upon receiving the version notification signal from the rewrite target ECU (ID1), the host apparatus 11 transmits the received version notification signal to the center apparatus 3. Similarly, when the transmission condition of the version notification signal is satisfied, the ECU (ID2) to be rewritten transmits a version notification signal including the version of the application program stored in itself and the ECU (ID) that can identify itself to the host apparatus 11. Upon receiving the version notification signal from the rewrite target ECU (ID2), the host apparatus 11 transmits the received version notification signal to the center apparatus 3.

When the center apparatus 3 receives the version notification signal from the rewrite target ECU (ID1) and the rewrite target ECU (ID2), it identifies the version of the application and the ECU (ID) included in the received version notification signal, and determines whether or not there is write data to be distributed to the rewrite target ECU19 which is the source of the version notification signal. The center device 3 determines the version of the current application program of the rewriting target ECU19 based on the version notification signal received from the rewriting target, and compares the version of the current application program with the latest version being managed.

If the version specified by the version notification signal is the same value as the latest version being managed, the center device 3 determines that there is no write data to be distributed to the rewrite target ECU19 of the transmission source of the version notification signal, and does not need to update the application stored in the rewrite target ECU 19. On the other hand, if the version specified by the version notification signal is a value smaller than the latest version under management, the center device 3 determines that there is write data to be distributed to the rewrite target ECU19 of the transmission source of the version notification signal, and needs to update the application stored in the rewrite target ECU 19.

When the center device 3 determines that the application stored in the rewrite target ECU19 needs to be updated, it notifies the mobile terminal 6 that the update is necessary. When notified that the update is necessary, the mobile terminal 6 displays a distribution availability screen (a 1). The distribution availability screen is equivalent to a motion notification screen described later. The user can confirm that updating is necessary through the distribution availability screen displayed on the mobile terminal 6, and can select whether or not updating is necessary.

When the user selects the update instruction from the mobile terminal 6 (a2), the mobile terminal 6 notifies the center apparatus 3 of a download request for the distribution package. When the slave terminal 6 is notified of a download request for the distribution packet, the center device 3 transmits the distribution packet to the host device 11.

When the host apparatus 11 downloads the distribution packet from the center apparatus 3, the packet authentication process is started for the downloaded distribution packet (B1). The host apparatus 11 authenticates the distribution packet, and when the packet authentication process is completed, the write data extraction process is started (B2). The host device 11 extracts write data from the distribution packet, and transmits a download completion notification signal to the center device 3 when the write data extraction process is completed.

Upon receiving the download completion notification signal from the host device 11, the center device 3 notifies the mobile terminal 6 of the completion of the download. When notified of the completion of the download from the center apparatus 3, the portable terminal 6 displays a download completion notification screen (a 3). The user can confirm the completion of the download through the download completion notification screen displayed on the mobile terminal 6, and can set the rewrite start time of the application on the vehicle side.

When the user sets the rewrite start time of the application on the vehicle side in the portable terminal 6 (a4), the portable terminal 6 notifies the center device 3 of the rewrite start time. When the mobile terminal 6 notifies the rewrite start time, the center apparatus 3 stores the rewrite start time set by the user as the setting start time. When the current time reaches the setting start time (a5), the center device 3 transmits a rewrite instruction signal to the host device 11.

Upon receiving the rewrite instruction signal from the center device 3, the host device 11 transmits a power activation request to the power management ECU20, and causes the rewrite target ECU (ID1), the rewrite target ECU (ID2), and the other ECUs to transition from the stopped state or the sleep state to the activated state (X1).

The host apparatus 11 starts to distribute write data to the ECU to be rewritten (ID1), and instructs the ECU to be rewritten (ID1) to write the write data. The ECU (ID1) to be rewritten starts receiving the write data from the host apparatus 11, and when the writing of the write data is instructed, starts the writing of the write data and starts the program rewriting process (C1). When the writing of the write data is completed by receiving the write data from the host apparatus 11, and the program rewriting process is completed, the ECU (ID1) to be rewritten transmits a rewriting completion notification signal to the host apparatus 11.

Upon receiving the rewriting completion notification signal from the ECU to be rewritten (ID1), the host apparatus 11 starts to distribute the write data to the ECU to be rewritten (ID2), and instructs the ECU to be rewritten (ID2) to write the write data. The ECU (ID2) to be rewritten starts receiving the write data from the host apparatus 11, and when the writing of the write data is instructed, starts the writing of the write data and starts the program rewriting process (D1). When the writing of the write data is completed by receiving the write data from the host apparatus 11, and the program rewriting process is completed, the ECU (ID2) to be rewritten transmits a rewriting completion notification signal to the host apparatus 11. When receiving the rewriting completion notification signal from the ECU to be rewritten (ID2), the host apparatus 11 transmits the rewriting completion notification signal to the center apparatus 3.

Upon receiving the rewriting completion notification signal from the host apparatus 11, the center apparatus 3 notifies the mobile terminal 6 of completion of rewriting of the application program. When the rewriting completion of the application is notified from the center device 3, the portable terminal 6 displays a rewriting completion notification screen (a 6). The user can confirm that the rewriting of the application is completed through the rewriting completion notification screen displayed on the mobile terminal 6, and can set the synchronization implementation as activation.

When the user sets the synchronization implementation in the mobile terminal 6 (a7), that is, the user sets the approval for activation of the new program, the mobile terminal 6 notifies the center apparatus 3 of the synchronization implementation. When notified of the synchronization execution by the slave terminal 6, the center device 3 transmits a synchronization switching instruction signal to the master device 11. Upon receiving the synchronization switching instruction signal from the center device 3, the host device 11 distributes the received synchronization switching instruction signal to the ECU to be rewritten (ID1) and the ECU to be rewritten (ID 2).

When receiving the synchronization switching instruction signal from the host apparatus 11, each of the ECU to be rewritten (ID1) and the ECU to be rewritten (ID2) starts a program switching process for switching the application to be started next from the old application to the new application (C2, D2). When the program switching process is completed, the rewrite target ECU (ID1) and the rewrite target ECU (ID2) transmit a switching completion notification signal to the host apparatus 11.

Upon receiving the switching completion notification signal from the ECU to be rewritten (ID1) and the ECU to be rewritten (ID2), the host apparatus 11 distributes the version read signal to the ECU to be rewritten (ID1) and the ECU to be rewritten (ID 2). When the ECU to be rewritten (ID1) and the ECU to be rewritten (ID2) each receive a version read signal from the host apparatus 11, they read the versions of the application programs (C3 and D3) to be subsequently operated, and transmit the latest version notification signal including the read version to the host apparatus 11. The host apparatus 11 checks the version of the software or performs rollback as necessary by receiving the version notification signal from the ECU to be rewritten (ID1) and the ECU to be rewritten (ID 2).

Upon receiving the version notification signal from the rewrite target ECU (ID1) and the rewrite target ECU (ID2), the host apparatus 11 transmits a power supply stop request to the power supply management ECU20, and causes the rewrite target ECU (ID1), the rewrite target ECU (ID2), and the other ECUs to transition from the activated state to the deactivated state or the sleep state (X2).

The master device 11 transmits the latest version notification signal to the center device 3. Upon receiving the latest version notification signal from the host apparatus 11, the center apparatus 3 specifies the latest version of the application program of the rewriting target ECU (ID1) and the rewriting target ECU (ID2) based on the received latest version notification signal, and notifies the specified latest version to the mobile terminal 6. When the mobile terminal 6 is notified of the latest version from the center apparatus 3, a latest version notification screen indicating the notified latest version is displayed on the mobile terminal 6 (A8). The user can confirm the latest version through the latest version notification screen displayed on the mobile terminal 6, and can confirm that activation is completed.

Next, a timing chart of operations of the DCM12, the CGW13, and the rewrite target ECU19 when rewriting the application program will be described with reference to fig. 26 to 29. Here, a case will be described where the application program of the dual-sided memory ECU is rewritten while the IG switch 42 is turned on by a user operation, that is, while the vehicle is capable of traveling, and the application programs of the single-sided suspended memory ECU and the single-sided individual memory ECU are rewritten while the vehicle is stopped after the IG switch 42 is turned off by a user operation. In addition, a case where the application program is rewritten by power control and a case where the application program is rewritten by power self-holding will be described.

(one) case of rewriting application program by power supply control

The case of rewriting the application program by power control will be described with reference to fig. 26 and 27. The rewriting of the application program by the power supply control is a configuration in which the rewriting operation is controlled by switching the power supply without using the power supply self-holding circuit. When the vehicle electric power source is switched from the + B electric power source to the IG electric power source by the user switching the IG switch from off to on, the DCM12, the CGW13, the dual-sided memory ECU, the one-sided suspend memory ECU, and the one-sided individual memory ECU start normal operations, respectively (t 1).

When the start of downloading is notified from the center apparatus 3, the DCM12 shifts from the normal operation to the downloading operation, and starts downloading the distribution packet from the center apparatus 3 (t 2). DCM12 may download the distribution packets in the background while doing normal actions. When the DCM12 completes downloading the distribution packet from the center apparatus 3, the operation returns from the downloading operation to the normal operation (t 3).

When the rewriting instruction signal (installation instruction signal) is notified from the center apparatus 3 or the CGW13, the DCM12 shifts from the normal operation to the data transfer/center communication operation, and starts the data transfer/center communication operation (t 4). That is, the DCM12 extracts the write data from the distribution packet, starts transferring the write data to the CGW13, acquires the progress status of rewriting from the CGW13, and starts notifying the center device 3 of the progress status of rewriting.

When the CGW13 starts acquiring write data from the DCM12, the normal operation is shifted to the re-main operation, the re-main operation is started, the write data is distributed to the dual-sided memory ECU, and the write of the write data is instructed. When the dual-sided memory ECU starts receiving write data from CGW13, the programming phase (hereinafter also referred to as the mount phase) is started in the normal operation. That is, the dual-sided memory ECU performs normal operation and installation of an application in the background. The dual-sided memory ECU starts writing the received write data to the flash memory and starts rewriting the application program.

While the application is being rewritten in the dual-sided memory ECU, when the IG switch is switched from on to off by the user and the vehicle power supply is switched from the IG power supply to the + B power supply, the DCM12 interrupts the data transmission/center communication operation, the CGW13 interrupts the reprogramming main operation, and the dual-sided memory ECU interrupts the installation phase and interrupts rewriting of the application (t 5).

When the IG switch is switched from off to on by the user and the vehicle power supply is switched from + B power supply to IG power supply, DCM12 restarts the data transfer/center communication operation, CGW13 restarts the reprogramming main operation, and the dual-sided memory ECU restarts the installation phase and restarts rewriting of the application (t 6). That is, the dual-sided memory ECU repeats interruption and resumption of rewriting of the application every time the user switches the IG switch from on to off and the vehicle electric power source from the IG electric power source to the + B electric power source, and then switches the IG switch from off to on and the vehicle electric power source from the + B electric power source to the IG electric power source (t7, t 8).

When the writing of the write data is completed and the rewriting of the application is completed, the dual-sided memory ECU ends the installation stage and shifts from the normal operation to the standby operation. That is, the dual-sided memory ECU does not start on the new side (side B) on which the application program is rewritten at the time when the activation stage is not performed, and keeps starting on the old side (side a) (t 9).

After the IG switch is switched from on to off by the user and the vehicle electric power source is switched from the IG electric power source to the + B electric power source (t10), when the dual-sided memory ECU completes rewriting the application program at this point of time, the CGW13 transmits the electric power source start request to the electric power source management ECU 20. When the vehicle electric power source is switched from the + B electric power source to the IG electric power source by the CGW13 transmitting the electric power source start request to the electric power source management ECU20, the DCM12 restarts the data transfer/center communication operation, the CGW13 restarts the reprogramming main operation, and the distribution of the write data to the one-side suspended memory ECU and the one-side individual memory ECU starts. When the single-sided suspended memory ECU and the single-sided individual memory ECU start receiving the write data from CGW13, the normal operation is shifted to the boot process, and the mounting stage is started in the boot process (t 11). That is, the single-sided suspend memory ECU and the single-sided individual memory ECU are not installed in parallel with the normal operation, but installed in the boot process in which the application does not operate.

When the single-sided suspend memory ECU starts rewriting the application program, the rewriting of the application program is interrupted when the IG switch 42 is switched from off to on by a user operation before the rewriting of the application program is completed. The single-sided suspend memory ECU restores the operating side (side a) as the boot side without using the non-operating side (side B) in which the rewriting of the application program is interrupted. When the single-sided individual memory ECU starts rewriting the application program, the rewriting of the application program is continued even if the IG switch 42 is switched from off to on by a user operation before the rewriting of the application program is completed. This is because the single-sided individual memory ECU cannot return to the normal operation if it is interrupted during the rewriting of the application program. It is preferable that the IG switch 42 operation by the user is disabled after the rewriting of the application program by the single-sided individual memory ECU is started and before the rewriting of the application program is completed.

When the write data is written and the application is rewritten, the one-sided suspend memory ECU ends the installation process and shifts from the boot process to standby for activation. That is, the one-side suspend memory ECU does not start on the new side (side B) on which the application is rewritten at the time when the activation phase is not performed, and keeps the old side (side a) starting. When the write data is written and the application is rewritten, the single-sided individual memory ECU waits for activation at the end of the boot process in the install stage (t 12).

When the electric power source management ECU20 switches the vehicle electric power source from the IG electric power source to the + B electric power source in response to the activation instruction from the CGW13, the dual-sided memory ECU and the single-sided suspend memory ECU each switch from the old side to the new side, start the new side start, and start the post-programming phase (hereinafter also referred to as the activation phase) during the new side start. The single-sided individual memory ECU starts the restart, and starts the activation phase in the restart after the completion of the installation (t13, t 14). During activation, confirmation of correct activation by a new program, notification of version information to CGW13, and the like are performed.

When the activation is completed, and the vehicle electric power source is switched from the IG electric power source to the + B electric power source by the electric power source management ECU20 in accordance with the activation completion instruction from the CGW13, the DCM12 shifts from the data transfer/center communication operation to the sleep/stop operation, and starts the sleep/stop operation. CGW13 transitions from the reprogramming action to the sleep/stop action, and starts the sleep/stop action. The dual-sided memory ECU, the single-sided suspend memory ECU, and the single-sided individual memory ECU respectively shift from the new-sided start to the sleep/stop operation (t 15).

Then, when the vehicle electric power source is switched from the + B electric power source to the IG electric power source by switching the IG switch from off to on by the user, the dual-sided memory ECU and the single-sided suspended memory ECU start the new application program with the new side (side B) as the start side, and the single-sided individual memory ECU starts the new application program (t 16).

(II) case of rewriting application program by power supply self-holding

The case of rewriting the application program by power supply self-holding will be described with reference to fig. 28 and 29. The rewriting of the application program by the power supply self-hold is a configuration in which the rewriting operation is controlled by using a power supply self-hold circuit. When the vehicle electric power source is switched from the + B electric power source to the IG electric power source by the user switching the IG switch from off to on, the DCM12, the CGW13, the dual-sided memory ECU, the one-sided suspend memory ECU, and the one-sided individual memory ECU start normal operations, respectively (t 21).

When the start of downloading is notified from the center apparatus 3, that is, when an update by a new program is notified, the DCM12 shifts from the normal operation to the downloading operation, and starts downloading the distribution packet from the center apparatus 3 (t 22). When the DCM12 completes downloading the distribution packet from the center apparatus 3, the operation returns from the downloading operation to the normal operation (t 23).

When the rewrite instruction signal (mount instruction signal) is notified from the center apparatus 3 or the CGW13, the DCM12 transitions from the normal operation to the data transfer/center communication operation, and starts the data transfer/center communication operation (t 24). That is, the DCM12 extracts the write data from the distribution packet, starts transferring the write data to the CGW13, acquires the progress status of rewriting from the CGW13, and starts notifying the center apparatus 3 of the progress status of rewriting.

When the CGW13 starts acquiring the write data from the DCM12, the normal operation is switched to the main reprogramming operation, the main reprogramming operation is started, the write data is distributed to the dual-sided memory ECU, and the write of the write data is instructed. When the dual-sided memory ECU starts receiving write data from CGW13, the dual-sided memory ECU starts a programming phase (hereinafter, also referred to as a mounting phase) in a normal operation. That is, the dual-sided memory ECU performs the installation of the application program in the background while performing the normal operation. The dual-sided memory ECU starts writing the received write data to the flash memory and starts rewriting the application program.

When the IG switch is switched from on to off by the user and the vehicle power supply is switched from the IG power supply to the + B power supply (t25) while the application is rewritten in the dual-sided memory ECU, immediately after the vehicle power supply is switched from the IG power supply to the + B power supply, the DCM12 continues the data transfer/center communication operation, the CGW13 continues the reprogramming operation, and the dual-sided memory ECU continues the installation stage and continues rewriting of the application. When a self-hold period, which is a preset time period, elapses after the vehicle power supply is switched from the IG power supply to the + B power supply, the DCM12 interrupts the data transmission/center communication operation, the CGW13 interrupts the reprogramming operation, the dual-sided memory ECU interrupts the installation phase, and the rewriting of the application program is interrupted (t 26). That is, the installation is continued by the supply of electric power from the vehicle battery 40 until a predetermined time has elapsed from the IG switch 42 being turned off.

When the IG switch is switched from off to on by the user and the vehicle power supply is switched from + B power supply to IG power supply, DCM12 restarts the data transfer/center communication operation, CGW13 restarts the reprogramming main operation, and the dual-sided memory ECU restarts the installation phase and restarts rewriting of the application (t 27). That is, the user switches the IG switch from on to off to switch the vehicle electric power source from the IG electric power source to the + B electric power source, and then switches the IG switch from off to on to switch the vehicle electric power source from the + B electric power source to the IG electric power source, and the dual-sided memory ECU repeats interruption and restart of rewriting of the application program every time the disconnection occurs (t28 to t 30). However, before the self-hold period elapses after the vehicle electric power source is switched from the IG electric power source to the + B electric power source, the DCM12 continues the data transfer/center communication operation, the CGW13 continues the reprogramming operation, the dual-sided memory ECU continues the installation phase, and the rewriting of the application program continues.

When the writing of the write data is completed and the rewriting of the application program is completed, the dual-sided memory ECU ends the installation stage and shifts from the normal operation to the standby operation. That is, the dual-sided memory ECU does not start on the new side (side B) on which the application program is rewritten at the time when the activation stage is not performed, and keeps starting on the old side (side a) (t 31).

When the user switches the IG switch from on to off and the vehicle power supply is switched from the IG power supply to the + B power supply, and the double-sided memory ECU completes rewriting of the application program at that time, the single-sided suspend memory ECU and the single-sided individual memory ECU each transition from the normal operation to the boot processing, and the boot processing is started, and the installation stage is started in the boot processing (t 32).

When the write data is written and the application is rewritten, the single-sided suspend memory ECU and the individual memory ECU end the boot process in the installation stage (t 33). When the vehicle electric power source is switched from the + B electric power source to the IG electric power source by the CGW13 sending the electric power source start request to the electric power source management ECU20, the DCM12 starts the data transmission/center communication operation again (t 34).

When the write data is written and the application is rewritten, the one-sided suspend memory ECU transitions from the boot process to the standby process. That is, the one-sided suspend memory ECU does not start on the new side (side B) on which the application is rewritten, and keeps starting on the old side (side a) at the time when the activation stage is not performed. When the write data is written and the application is rewritten, the single-sided individual memory ECU waits for activation at the end of the boot process in the install stage (t 35).

When the electric power source management ECU20 switches the vehicle electric power source from the IG electric power source to the + B electric power source in response to the activation instruction from the CGW13, the dual-sided memory ECU and the single-sided suspend memory ECU switch from the old side to the new side, start the vehicle on the new side, and start the activation phase on the new side. The single-sided individual memory ECU starts the restart, and starts the activation phase in the restart after the completion of the installation (t36, t 37).

When the activation is completed, the electrical power source management ECU20 switches the vehicle electrical power source from the IG electrical power source to the + B electrical power source in response to the activation completion instruction from the CGW13, and the DCM12 shifts from the data transfer/center communication operation to the sleep/stop operation, and starts the sleep/stop operation. CGW13 transitions from the reprogramming operation to the sleep/stop operation, and starts the sleep/stop operation. The dual-sided memory ECU, the single-sided suspend memory ECU, and the single-sided individual memory ECU each start from a new side to shift to a sleep/stop operation (t 38).

After that, when the vehicle electric power source is switched from the + B electric power source to the IG electric power source by switching the IG switch from off to on by the user, the double-sided memory ECU and the single-sided suspend memory ECU start the new application program with the new side (side B) as the start side, and the single-sided individual memory ECU starts the new application program (t 39).

The CGW13 performs the following check before downloading the distribution packet from the center apparatus 3 and before distributing the packet to the ECU19 to which data is written. Before downloading the distribution packet from the center device 3, the CGW13 checks the radio wave environment, the remaining battery level of the vehicle battery 40, and the memory capacity of the DCM12 so that the download can be performed normally. Before being distributed to the ECU19 to be rewritten, the CGW13 performs detection of an intrusion sensor, detection of a vehicle lock, detection of a curtain, and detection of an IG off as a check for preventing a human environment from making an installation environment unstable, and performs checks of generation of a version and an abnormality as a check for checking whether the ECU19 to be rewritten can write, so that the written data can be normally distributed. In addition, as a check of write data distributed to the ECU19 to be rewritten, the CGW13 performs a tamper check, an access authentication, a version check, and the like before starting the installation, performs a communication interruption check, a check of an abnormality occurrence, and the like while executing the installation, and performs a version check, an integrity check, a DTC (Diagnostic reliable Code) check, and the like after completing the installation.

Next, a screen displayed by the display terminal 5 will be described with reference to fig. 30 to 46. As shown in fig. 30, the configuration in which the application program of the ECU19 to be rewritten is rewritten OTA includes stages of activity notification, download, installation, and activation. Active notifications refer to notifications of program updates. For example, it is an active notification that the central apparatus 3 determines that there is an update of the application and the host apparatus 11 downloads the distribution specification data. The display terminal 5 displays a screen at each stage as rewriting of the application progresses. Here, a screen displayed on the in-vehicle display 7 will be described.

As shown in fig. 31, in a normal state before the activity notification, CGW13 displays a navigation screen 501 such as a known route guidance screen, which is one of navigation functions, on in-vehicle display 7. When the activity notification is generated from this state, CGW13 displays an activity notification icon 501a indicating that the activity notification is generated on the lower right of navigation screen 501, as shown in fig. 32. The user can grasp the generation of the activity notification related to the update of the application by confirming the display of the activity notification icon 501 a.

When the user operates activity notification icon 501a from this state, CGW13 causes activity notification screen 502 to pop up on navigation screen 501 as shown in fig. 33. CGW13 is not limited to pop-up display of motion notification screen 502, and may be displayed in another manner. CGW13 displays guidance such as "available software update" on activity notification screen 502 to notify the user of the generation of an activity notification, and displays "ok" button 502a and "later" button 502b to wait for the user's operation. In this case, the user can enter the next screen for starting rewriting of the application by operating the "ok" button 502 a. When the user operates the "later" button 502b, CGW13 cancels the pop-up display of the activity notification screen 502 and returns to the screen shown in fig. 32 on which the activity notification icon 501a is displayed.

When the user operates the "ok" button 502a from this state, CGW13 switches the display from the navigation screen 501 to the download approval screen 503, and causes the in-vehicle display 7 to display the download approval screen 503, as shown in fig. 34. CGW13 notifies the user of the campaign ID and the update name on download approval screen 503, and displays "download start" button 503a, "detailed confirmation" button 503b, and "return" button 503c to wait for the user to operate. In this case, the user can start downloading by operating the "download start" button 503a, can display details of downloading by operating the "detailed confirmation" button 503b, and can reject downloading and return to the previous screen by displaying the "return" button 503 c. In a case where the "back" button 503c is operated, and the user can enter a screen for starting downloading by operating the activity notification icon 501 a.

When the user operates the "detailed confirmation" button 503b from the state in which the download approval screen 503 is displayed, the CGW13 switches the display content of the download approval screen 503 to display the details of the download on the in-vehicle display 7, as shown in fig. 35. As details of the download, CGW13 displays the contents of the update, the time required for the update, the restriction of the vehicle function accompanying the update, and the like, using the received distribution specification data. In addition, when the user operates the "download start" button 503a, the CGW13 starts downloading of the distribution package via the DCM 12. In parallel with the start of the download of the distribution package, as shown in fig. 36, the CGW13 switches the display from the download approval screen 503 to the navigation screen 501, displays the navigation screen 501 again on the in-vehicle display 7, and displays the download execution icon 501b indicating that the download is being executed on the lower right of the navigation screen 501. The user can grasp that the download of the distribution packet is being executed by confirming the display of the download execution icon 501 b.

When the user operates the in-download execution icon 501b from this state, as shown in fig. 37, CGW13 switches the display from the navigation screen 501 to the in-download execution screen 504, and causes the in-download execution screen 504 to be displayed on the in-vehicle display 7. CGW13 notifies the user of the downloading progress on downloading progress screen 504, and displays "confirm details" button 504a, "return" button 504b, and "cancel" button 504c to wait for the user's operation. In this case, the user can display details during the execution of the download by operating the "detailed confirmation" button 504a, and can interrupt the download by operating the "cancel" button 504 c.

Upon completion of the download, CGW13 causes a download completion notification screen 505 to pop up and display on navigation screen 501 as shown in fig. 38. CGW13 displays, for example, "download completed" on download completion notification screen 505. The guidance of software update enabled "notifies the user of the completion of the download, and causes a" confirm "button 505a, a" later "button 505b to be displayed, waiting for the user's operation. In this case, the user can enter a screen for starting installation by operating the "ok" button 505 a.

When the user operates "ok" button 505a from this state, CGW13 switches the display from navigation screen 501 to installation approval screen 506 and causes installation approval screen 506 to be displayed on in-vehicle display 7, as shown in fig. 39. CGW13 notifies the user of the setting of the required time, the limitation items, and the schedule concerning the installation on installation approval screen 506, and displays "immediate update" button 506a, "offer update" button 506b, and "return" button 506c to wait for the user's operation. In this case, the user can cause the installation to start immediately by operating the "update immediately" button 506 a. Further, the user can start installation in a reserved manner by setting a time at which the user desires to execute installation and operating the "offer update" button 506 b. Further, the user can reject the installation and return to the previous screen by operating the "return" button 506 c. When the "back" button 506c is operated, and the user can enter a screen for starting installation by operating the download execution icon 501 b.

When the user operates "update immediately" button 506a from this state, CGW13 switches the display content of installation approval screen 506 and displays the installation details on in-vehicle display 7 as shown in fig. 40. CGW13 notifies the user of the acceptance of the installation request and the start of installation on installation approval screen 506.

When the mounting is started, CGW13 switches the display from mounting approval screen 506 to navigation screen 501, displays navigation screen 501 again on in-vehicle display 7, and displays mounting execution icon 501c indicating that the mounting is being executed on the lower right of navigation screen 501, as shown in fig. 41. The user can recognize that the installation is being performed by confirming the display of the icon 501c during the installation.

When the user operates installation-in-progress icon 501c from this state, CGW13 switches the display from navigation screen 501 to installation-in-progress screen 507, and displays installation-in-progress screen 507 on in-vehicle display 7, as shown in fig. 42. CGW13 notifies the user of the execution of the installation on installation execution screen 507. CGW13 may also display the remaining time required for installation, the percentage of progress, for example, on installation in progress screen 507.

When the CGW13 completes the installation, as shown in fig. 43, the display is switched from the navigation screen 501 to the activation approval screen 508, and the activation approval screen 508 is displayed on the in-vehicle display 7. CGW13 notifies the user of the activated content on activation approval screen 508, and displays "back" button 508a and "OK" button 508b to wait for the user's operation. In this case, the user can refuse activation and return to the previous screen by operating the "return" button 508 a. In addition, the user can agree to activation by operating the "OK" button 508 b. Further, in a case where the "back" button 508a is operated, and the user can enter the screen for executing activation by operating the installation-executing icon 501 c. Note that these displays and consents may be omitted depending on the setting of the user or the scene of the program.

When the IG power supply is turned on from the state in which the user has operated the "OK" button 508b, as shown in fig. 44, CGW13 causes an activation completion notification screen 509 to pop up on the navigation screen 501. CGW13 displays, on activation completion notification screen 509, a guidance of "software update completion" to notify the user of the completion of activation, for example, and displays "OK" button 509a and "confirmation detail" button 509b to wait for the user's operation. In this case, the user can cancel the pop-up display on the activation completion notification screen 509 by operating the "OK" button 509a, and can display the details of the completion of activation by operating the "detail confirmation" button 509 b.

When the user operates the "OK" button 509a from this state, CGW13 switches the display from the navigation screen 501 to the confirmation operation screen 510, and displays the confirmation operation screen 510 on the in-vehicle display 7, as shown in fig. 45. CGW13 notifies the user of completion of activation on confirmation operation screen 510, and displays "detailed confirmation" button 510a and "OK" button 510b to wait for the user's operation. In this case, the user can display the details of the completion of the activation by operating the "detail confirmation" button 510 a.

When the user operates the "detail confirmation" button 510a from this state, as shown in fig. 46, CGW13 switches the display contents of the confirmation operation screen image 510 and displays the activation-completed details on the in-vehicle display 7. CGW13 displays the function added by the update, the changed function, and the like as update details, and also displays an "OK" button 510 b. CGW13 determines that the user has confirmed completion of the software update when the user operates "OK"

buttons

509a and 510 b.

As described above, the vehicle-side system 4 controls the operation stages such as activity notification, download, installation, activation, and update completion, and presents a display matching the operation stages to the user. In the above description, the CGW13 is configured to control the display, but the in-vehicle display 7 may be configured to receive the operation phase and the distribution specification data from the CGW13 and display them.

Next, characteristic processing performed by the vehicle program rewriting system 1 will be described with reference to fig. 47 to 233. The vehicle program rewriting system 1 performs characteristic processing described below.

(1) Distribution packet transmission determination processing

(2) Download determination processing for distribution packet

(3) Transfer decision processing of write data

(4) Acquisition determination processing of write data

(5) Installation instruction determination process

(6) Management processing of secure access keys

(7) Verification processing of write data

(8) Transmission control processing of data storage plane information

(9) Power management processing for non-rewritten object

(10) Transmission control processing of files

(11) Distribution control processing of write data

(12) Indication handling of activation requests

(13) Active execution control processing

(14) Group management processing of rewritten objects

(15) Execution control processing of rollback

(16) Display control processing for rewriting progress status

(17) Processing for determining matching of differential data

(18) Execution control processing of rewriting

(19) Session establishment processing

(20) Retry point determination process

(21) Synchronous control processing of progress states

(22) Transmission control processing of display control information

(23) Reception control processing of display control information

(24) Screen display control processing of progress display

(25) Report control processing of program update

(26) Execution control processing of power supply self-hold

(27) Overwrite indication processing based on overrides of configuration information

(28) Rewrite indication processing based on write back of configuration information

(29) Rewrite instruction processing based on specific mode

The center device 3, the DCM12, the CGW13, the ECU19, and the in-vehicle display 7 each have the following functional blocks as a configuration for performing the characteristic processes of the above-described (1) to (26).

As shown in fig. 47, the center apparatus 3 includes a distribution packet transmitting unit 51. Upon receiving a download request of the distribution packet from the DCM12, the distribution packet transmitter 51 transmits the distribution packet to the DCM 12. As a configuration for performing the characteristic processing, the center device 3 includes, in addition to the above-described configuration, a transmission determination unit 52 for distributing a packet, a synchronization control unit 53 for controlling the progress state, a transmission control unit 54 for displaying control information, and a write data selection unit 55 (corresponding to an update data selection unit). Upon receiving the data storage surface information from the host device 11, the write data selection unit 55 (corresponding to an update data selection unit) selects write data suitable for the non-operating surface based on the software version and the operating surface specified from the received data storage surface information. That is, the distribution packet transmitting unit 51 transmits the distribution packet including the write data selected by the write data selecting unit 55 to the DCM 12. The functional blocks that perform characteristic processing will be described later.

As shown in fig. 48, DCM12 includes a download request transmitting unit 61, a distribution packet downloading unit 62, a write data extracting unit 63, a write data transferring unit 64, a rewriting specification data extracting unit 65, and a rewriting specification data transferring unit 66. The download request transmitting unit 61 transmits a download request for distributing the package to the center apparatus 3. The distribution packet download section 62 downloads the distribution packet from the center device 3. When the distribution packet is downloaded from the center apparatus 3 by the distribution packet download section 62, the write data extraction section 63 extracts write data from the downloaded distribution packet.

When the write data extraction unit 63 extracts write data from the distribution packet, the write data transfer unit 64 transfers the extracted write data to CGW 13. When the distribution packet is downloaded from the center device 3 by the distribution packet download section 62, the rewriting specification data extraction section 65 extracts rewriting specification data from the downloaded distribution packet. When rewriting specification data is extracted from the distribution packet by rewriting specification data extraction unit 56, rewriting specification data transmission unit 66 transmits the extracted rewriting specification data to CGW 13. As a configuration for performing the characteristic processing, in addition to the above configuration, the DCM12 includes a download determination unit 67 for distributing a packet and a transfer determination unit 68 for writing data. The functional blocks that perform characteristic processing will be described later.

As shown in fig. 49 and 50, the CGW13 includes an acquisition request transmitting unit 71, a write data acquiring unit 72 (corresponding to an update data storage unit), a write data distributing unit 73 (corresponding to an update data distributing unit), a rewriting specification data acquiring unit 74, and a rewriting specification data analyzing unit 75. The write data acquisition section 72 acquires write data from the DCM12 by the write data being transferred from the DCM 12. When the write data acquisition unit 72 acquires the write data and the write data distribution unit 73 becomes the distribution timing of the write data, the write data distribution unit distributes the acquired write data to the rewrite target ECU 19. The rewriting specification data acquisition unit 74 acquires rewriting specification data from the DCM12 by transferring the rewriting specification data from the DCM 12. When the rewriting specification data is acquired by the rewriting specification data acquisition unit 74, the rewriting specification data analysis unit 75 analyzes the acquired rewriting specification data.

The CGW13 includes, as a configuration for performing the characteristic processing, in addition to the above-described configuration, a write data acquisition determination unit 76, an installation instruction determination unit 77, a security access key management unit 78, a write data verification unit 79, a data storage surface information transmission control unit 80, a non-rewriting power supply management unit 81, a file transfer control unit 82, a write data distribution control unit 83, an activation request instruction unit 84, a rewriting target group management unit 85, a rollback execution control unit 86, a rewriting progress status display control unit 87, a progress state synchronization control unit 88, a display control information reception control unit 89, a progress display screen display control unit 90, a program update report control unit 91, a power supply self-holding execution control unit 92, a rewriting instruction unit 93 based on the override of the configuration information, a rewriting instruction unit 94 based on the write back of the configuration information, a program update control unit 90, a program update control unit, And a rewrite instruction unit 95 based on the specific mode. The functional blocks that perform the characteristic processing will be described later.

As shown in fig. 51, the ECU19 has a write data receiving unit 101 and a program rewriting unit 102. The write data reception unit 101 receives write data from the CGW 13. When the write data is received from CGW13 by write data reception unit 101, program rewriting unit 102 writes the received write data in the flash memory to rewrite the application program. As a configuration for performing the characteristic processing, the ECU19 includes, in addition to the above-described configuration, a matching determination unit 103 for difference data, a rewrite execution control unit 104, a session establishment unit 105, a retry point determination unit 106, an active execution control unit 107, and a power supply self-holding execution control unit 108. The functional blocks that perform the characteristic processing will be described later.

As shown in fig. 52, the in-vehicle display 7 includes a reception control unit 111 that distributes specification data. The distribution specification data reception control unit 111 controls reception of the distribution specification data.

The respective processes (1) to (29) described above will be described in order below.

(1) Distribution packet transmission determination processing, (2) distribution packet download determination processing

The transmission determination process of the distribution packet in the center apparatus 3 will be described with reference to fig. 53 and 54, and the download determination process of the distribution packet in the host apparatus 11 will be described with reference to fig. 55 and 56.

As shown in fig. 53, the center device 3 includes a software information acquisition unit 52a, an update presence/absence determination unit 52b, an update suitability determination unit 52c, and a motion information transmission unit 52d in the transmission determination unit 52 for distributing packets. The software information acquisition unit 52a acquires the software information of each ECU19 from the vehicle side. Specifically, the software information acquisition unit 52a acquires ECU configuration information including software information such as a version and a write surface and hardware information from the vehicle side. The software information acquiring unit 52a may acquire vehicle state information such as a trouble code, a setting of an burglar alarm function, and license agreement information together with the ECU configuration information from the vehicle side.

When the software information is acquired by the software information acquiring unit 52a, the update presence/absence determining unit 52b determines the presence or absence of update data for the vehicle based on the acquired software information. That is, the update presence/absence determination unit 52b compares the version of the acquired software information with the version of the latest software information managed by itself, determines whether or not both versions match, and determines whether or not there is update data for the vehicle. The update presence/absence determination unit 52b determines that there is no update data for the vehicle if both are determined to be identical, and determines that there is update data for the vehicle if both are determined to be not identical.

When the update presence/absence determination unit 52b determines that there is update data for the vehicle, the update suitability determination unit 52c determines whether or not the vehicle state is a state suitable for updating using a program or the like that distributes packets. Specifically, the update suitability determination unit 52c determines whether or not the license agreement is established, whether or not the vehicle position is within a predetermined range registered in advance by the user, whether or not the setting of the warning function of the vehicle is validated, whether or not the failure information of the ECU19 is generated, and whether or not the vehicle state is a state suitable for downloading the distribution packet. That is, the update suitability determination unit 52c determines whether or not the vehicle is a vehicle that may be subjected to update against the user's intention, or a vehicle that may have failed in installation after download even if the download is successful.

The update suitability determination unit 52c determines that the vehicle state is a state suitable for updating a program or the like using a distribution packet if it is determined that the license agreement is established, the vehicle position is within a predetermined range registered in advance by the user, the setting of the warning function of the vehicle is validated, and the failure information of the ECU19 is not generated. If the update suitability determination unit 52c determines that the license agreement is not established, the vehicle position is not within the predetermined range registered in advance by the user, the setting of the warning function of the vehicle is not validated, and at least any one of the failure information of the ECU19 is generated, it determines that the vehicle state is not a state suitable for updating of the program using the distribution packet and the like.

When the update suitability determination unit 52c determines that the vehicle state is a state suitable for updating using a program or the like of a distribution packet, the activity information transmission unit 52d transmits the activity information to the host device 11. When the update suitability determination unit 52c determines that the vehicle state is not a state suitable for updating of a program or the like using a distribution packet, the activity information transmission unit 52d does not transmit the activity information to the host device 11. By performing the above determination, the activity information transmitting unit 52d stores in advance information relating to a vehicle for which activity information is not transmitted to the host apparatus 11. Further, information about a vehicle that does not transmit activity information to the host apparatus 11 may also be displayed in the center apparatus 3.

Next, the operation of the transmission determination unit 52 for distributing packets in the center device 3 will be described with reference to fig. 54. The center device 3 executes a distribution packet transmission determination program and performs a distribution packet transmission determination process.

When the transmission determination process of the distribution packet is started, the center device 3 acquires the software information from the vehicle side (S101, which corresponds to a software information acquisition step). That is, the center device 3 determines whether or not there is a software update for the vehicle. The center device 3 determines the presence or absence of update data for the vehicle based on the acquired software information (S102, corresponding to an update presence determination step). When the center device 3 determines that there is update data for the vehicle (yes in S102), it determines whether or not the vehicle state is a state suitable for updating by a program or the like that distributes packets (S103, corresponding to an update suitability determination step). When the center device 3 determines that the vehicle state is a state suitable for updating a program or the like using the distribution packet (yes in S103), it transmits the activity information to the host device 11(S104, corresponding to the activity information transmission step), and ends the transmission determination process of the distribution packet.

When the center device 3 determines that there is no update data for the vehicle (no in S102), it transmits a message that the distribution packet is not to be transmitted, that is, that there is no update of the application, to the host device 11(S105), and ends the transmission determination process of the distribution packet. When the center device 3 determines that the vehicle state is not a state suitable for updating the program or the like using the distribution packet (no in S103), it transmits the message that the program or the like is not suitable for updating to the host device 11 and the reason for the message (S106), and ends the transmission determination process of the distribution packet. In this case, the host device 11 displays the message indicating that the update of the program or the like is not appropriate and the reason for the update on the in-vehicle display 7. For example, if the license agreement is not established, the master device 11 makes "the program cannot be updated because the license is invalidated, for example. Please consult with the dealer. "etc. are displayed on the in-vehicle display 7. This makes it possible to present the user with a reason why the update of the program or the like is not appropriate, and to present appropriate information to the user.

As described above, the center device 3 can determine whether or not the updated state of the program or the like is suitable for use of the distribution packet by performing the transmission determination process of the distribution packet before the transmission of the activity information and before the transmission of the distribution packet to the host device 11. The center device 3 can transmit the activity information to the host device 11 to transmit the distribution packet to the host device 11 only when it is determined that the updated state of the program or the like using the distribution packet is appropriate.

When the license agreement is established, the vehicle position is within a predetermined range registered by the user in advance, the setting of the warning function of the vehicle is validated, and the failure information of the ECU19 is not generated, the center device 3 can transmit the activity information to the host device 11 as the update of the program or the like suitable for using the distribution packet. That is, the center device 3 can avoid a situation in which the activity information is transmitted to the host device 11 when the license agreement is not established, the vehicle location is outside a predetermined range such as a location away from the home, the setting of the warning function of the vehicle is invalidated, or failure information of the ECU19 is generated. In this way, the center device 3 can prevent the activity information from being transmitted to the host device 11 for a vehicle that may be updated against the user's intention, or a vehicle that may fail in installation even if the download is successful.

The center device 3 may perform the transmission determination process of the distribution packet during transmission of the distribution packet. In this case, the center device 3 continues the transmission of the distribution packet if it is determined that the vehicle state is a state suitable for updating the program or the like using the distribution packet during the transmission of the distribution packet, but interrupts the transmission of the distribution packet if it is determined that the vehicle state is not a state suitable for updating the program or the like using the distribution packet during the transmission of the distribution packet. That is, if failure information of the ECU19 occurs while the distribution packet is being transmitted, for example, the center device 3 interrupts the transmission of the distribution packet.

Next, a process of the master device 11 receiving the activity information transmitted from the center device 3 will be described. The download determination process of the distribution packet in the host apparatus 11 will be described with reference to fig. 55 and 56. The vehicle program rewriting system 1 performs a download determination process of the distribution packet in the host device 11. The above-described (1) transmission determination process of the distribution packet is a determination process performed by the center device 3 in the activity notification phase before the download phase, but the download determination process of the distribution packet is a determination process performed by the host device 11 in the download phase. In the present embodiment, the case where DCM12 performs the download determination process of the distribution packet in host apparatus 11 is described, but CGW13 may have the function of DCM12, and CGW13 may perform the download determination process of the distribution packet.

As shown in fig. 55, the DCM12 includes a motion information receiving unit 67a, a downloadable determination unit 67b, and a download execution unit 67c in the download determination unit 67 that distributes packets. The activity information receiving section 67a receives activity information from the center apparatus 3. Further, when the activity information is received from the center apparatus 3, the activity notification icon 501a shown in fig. 32 is displayed. When the event information is received by the event information receiving unit 67a, the downloadable determination unit 67b determines whether or not the vehicle state is a state in which the distribution packet can be downloaded. That is, the downloadable determination unit 67b determines whether the radio wave environment for communicating with the center device 3 is good, whether the remaining battery capacity of the vehicle battery 40 is equal to or greater than the predetermined capacity, and whether the memory free capacity of the DCM12 is equal to or greater than the predetermined capacity, and determines whether the vehicle state is a state in which the distribution packet can be downloaded.

The downloadable determination unit 67b determines that the vehicle state is a state in which the distribution packet can be downloaded when it is determined that the radio spectrum environment is good, the remaining battery capacity of the vehicle battery 40 is equal to or greater than the predetermined capacity, and the free memory capacity of the DCM12 is equal to or greater than the predetermined capacity. The downloadable determination unit 67b determines that the vehicle state is not a state in which the distribution packet can be downloaded, if at least one of the radio spectrum environment is not good, the remaining battery capacity of the vehicle battery 40 is not equal to or greater than the predetermined capacity, and the memory free capacity of the DCM12 is not equal to or greater than the predetermined capacity.

In this way, the download possibility determining unit 67b determines whether or not there is a possibility that the download cannot be completed normally. The determination by the downloadable determination unit 67b is performed on the condition that the "download start" button 503a is operated by the user on the download approval screen 503 shown in fig. 34 and 35. The downloadable determination unit 67b may be configured to determine the determination items in the center device 3. That is, the downloadable determination unit 67b determines that the downloadable state is available when, for example, the setting of the warning function of the vehicle is validated or when the failure information of the ECU19 is not generated.

When the downloadable determination unit 67b determines that the vehicle state is a state in which the distribution package can be downloaded, the download execution unit 67c downloads the distribution package from the center apparatus 3. That is, the download execution unit 67c executes the download of the distribution package after confirming that the download can be completed normally.

If the downloadable determination unit 67b determines that the vehicle state is not the state in which the distribution package can be downloaded, the download execution unit 67c does not download the distribution package from the center device 3. That is, the download execution unit 67c does not execute the download of the distribution packet when the download may not be completed normally. In this case, the download execution unit 67c instructs the in-vehicle display 7 to display a pop-up screen indicating that the download cannot be started and the reason for the same on the navigation screen 501.

Next, the operation of the download determination unit 67 for distributing packets in the host apparatus 11 will be described with reference to fig. 56. The host device 11 executes a download determination program for the distribution packet, and performs download determination processing for the distribution packet.

When the host apparatus 11 starts the download determination process for distributing the packet, it receives the activity information from the center apparatus 3 (S201, which corresponds to an activity information receiving step). The host apparatus 11 determines whether or not the vehicle state is a state in which the distribution packet can be downloaded (S202, which corresponds to a downloadable determination step). When the host apparatus 11 determines that the vehicle state is a state in which the distribution packet can be downloaded (yes in S202), it downloads the distribution packet corresponding to the event from the center apparatus 3 (S203, corresponding to a download execution step), and ends the download determination process of the distribution packet. If the host apparatus 11 determines that the vehicle state is not a state in which the distribution packet can be downloaded (S202: no), the distribution packet is not downloaded from the center apparatus 3, and the distribution packet download determination process ends.

As described above, the host device 11 can determine whether or not the vehicle state is a state in which the distribution packet can be downloaded by performing the download determination process of the distribution packet before downloading the distribution packet from the center device 3. Further, the host apparatus 11 is capable of downloading the distribution package only when the vehicle state is a state in which the distribution package can be downloaded.

As a case suitable for downloading the distribution packet, the host device 11 can download the distribution packet from the center device 3 when the radio wave environment is good, the remaining battery capacity of the vehicle battery 40 is equal to or more than the predetermined capacity, and the memory free capacity of the DCM12 is equal to or more than the predetermined capacity. That is, it is possible to avoid a situation in which the distribution packet is downloaded from the center device 3 when the radio wave environment is poor, the remaining battery capacity of the vehicle battery 40 is smaller than the predetermined capacity, or the free memory capacity of the DCM12 is smaller than the predetermined capacity.

The host apparatus 11 may perform download determination processing of the distribution packet during download of the distribution packet. In this case, if it is determined that the vehicle state is the state in which the distribution packet can be downloaded during the downloading of the distribution packet, the host apparatus 11 continues the downloading of the distribution packet from the center apparatus 3, but if it is determined that the vehicle state is not the state in which the distribution packet can be downloaded during the downloading of the distribution packet, the downloading of the distribution packet from the center apparatus 3 is interrupted. That is, if the radio wave environment is not good, the remaining battery level of the vehicle battery 40 is less than the predetermined capacity, or the memory free capacity of the DCM12 is less than the predetermined capacity during the download of the distribution packet, for example, the host apparatus 11 interrupts the download of the distribution packet.

In this way, by determining whether or not the center device 3 is a vehicle that may be an update that violates the user's intention, or a vehicle that may have a failure in installation, and determining whether or not the host device 11 has a failure in download, it is possible to suppress transmission of useless activity information or distribution packets from the center device 3 to the host device 11.

The center device 3 has the following configuration. The disclosed device is provided with: a software information acquisition unit 52a that acquires software information of the electronic control device from the vehicle side; an update presence/absence determination unit 52b that determines the presence or absence of update data for the vehicle based on the software information acquired by the software information acquisition unit; an update suitability determination unit 52c that determines whether or not the vehicle state is a state suitable for updating when the update presence determination unit determines that the update data is present; and an activity information transmitting unit 52d that transmits activity information related to the update to the vehicle host device when the update suitability determination unit determines that the vehicle state is a state suitable for update.

The host device 11 has the following configuration. The disclosed device is provided with: an activity information receiving unit 67a that receives activity information from the center device; a downloadable determination unit 67b that determines whether or not the vehicle state is a state in which the distribution packet can be downloaded, when the event information is received by the event information receiving unit; and a download execution unit 67c that downloads the distribution package from the center device when the downloadable determination unit determines that the vehicle state is a state in which the distribution package can be downloaded.

(3) Transfer determination processing of write data, (4) acquisition determination processing of write data, and (5) instruction determination processing of mounting

The transfer determination process of the write data is described with reference to fig. 57 and 58, the acquisition determination process of the write data is described with reference to fig. 59 and 60, and the mounting instruction determination process is described with reference to fig. 61 to 64. The vehicle program rewriting system 1 performs a transfer determination process of write data in the DCM 12. Here, the distribution packet transmitted from the center apparatus 3 to the DCM12 is unpacked, and the write data is extracted from the distribution packet.

As shown in fig. 57, the DCM12 includes an acquisition request receiving unit 68a and a communication state determining unit 68b in the transfer determining unit 68 for write data. The acquisition request receiving unit 68a receives an acquisition request of write data from the CGW 13. When the acquisition request receiving unit 68a receives the acquisition request of the write data, the communication state determining unit 68b determines the state of the data communication between the center device 3 and the DCM12, for example, when the transfer availability determination flag set in advance by the user is a first predetermined value. The transmission availability determination flag is, for example, 1 (first predetermined value) when the predetermined condition is checked at the time of mounting, and 0 (second predetermined value) when the check is omitted. The write data transfer section 64 transfers the write data to the CGW13 on condition that the communication state determination section 68b determines that the data communication between the center device 3 and the DCM12 is in the connected state.

Next, the operation of the transfer determination unit 68 for write data in DCM12 will be described with reference to fig. 58. DCM12 executes a transfer determination program of write data, and performs a transfer determination process of the write data. Here, a description will be given of a process in which the CGW13 requests the DCM12 to acquire write data in response to an installation instruction from the center apparatus 3.

When the DCM12 determines that the request for acquiring the write data is received from the CGW13, the DCM starts transfer determination processing of the write data. When the DCM12 starts the transfer determination process of the write data, it determines the transfer permission determination flag (S301 and S302). When the DCM12 determines that the transmission permission determination flag is the first predetermined value (S301: yes), it determines the state of data communication between the center apparatus 3 and itself (S303). When the DCM12 determines that the data communication between the center apparatus 3 and itself is in the connected state (yes in S303), the DCM transfers the write data to the CGW13(S304), and the write data transfer determination process is ended. When the DCM12 determines that the data communication between the center apparatus 3 and itself is not in the connected state but in the interrupted state (S303: no), the DCM ends the write data transfer determination process without transferring the write data to the CGW 13.

When the DCM12 determines that the transfer permission determination flag is the second predetermined value (yes in S302), the write data is transferred to the CGW13 without determining the state of data communication between the center apparatus 3 and the DCM, and the transfer determination process of the write data is ended.

As described above, the DCM12 performs the transfer determination process of the write data before transferring the write data to the CGW13, thereby determining the state of data communication between the center apparatus 3 and itself when the transfer availability determination flag is the first predetermined value. DCM12 starts transfer of write data when it is determined that data communication is in a connected state, and waits without starting transfer of write data when it is determined that data communication is in an interrupted state. In a situation where data communication with the center apparatus 3 is possible, the write data can be transmitted to the CGW13, and the ECU19 to be rewritten can be installed.

For example, when a plurality of the rewrite target ECUs 19 are provided and it takes time to install them, the progress of installation can be notified from the vehicle-mounted system 4 to the center apparatus 3, and the progress can be displayed on the mobile terminal 6 one by one. Further, the DCM12 may perform the transfer determination process of the write data during the transfer of the write data. In this case, the DCM12 continues the transfer of the write data when it is determined that the data communication is in the connected state during the transfer of the write data, but interrupts the transfer of the write data when it is determined that the data communication is in the interrupted state during the transfer of the write data.

Next, acquisition determination processing of write data will be described. The vehicle program rewriting system 1 performs acquisition determination processing of write data in the CGW 13. The above-described (3) transfer determination process of the write data is a determination process performed by the DCM12 in the mounting stage, and the acquisition determination process of the write data is a determination process performed by the CGW13 in the same mounting stage.

As shown in fig. 59, CGW13 includes an event occurrence determination unit 76a and a communication state determination unit 76b in the acquisition determination unit 76 for write data. The event occurrence determination unit 76a determines occurrence of an event of a request (installation instruction) for acquiring write data from the center apparatus 3. When the event occurrence determination unit 76a determines that the event of the acquisition request of the write data has occurred, the communication state determination unit 76b determines the state of data communication between the center device 3 and the DCM12, for example, when the acquisition availability determination flag set in advance by the user is a first predetermined value. The acquisition availability determination flag is, for example, 1 (first predetermined value) when the predetermined condition is checked at the time of mounting, and 0 (second predetermined value) when the check is omitted. Here, the event occurrence determination unit 76a may determine that an event occurs based on the user's instruction for installation, and for example, upon receiving a notification of an instruction operation (see fig. 39) by the user for installation via the in-vehicle display 7, determine that an event for requesting acquisition of write data has occurred.

Next, the operation of the write data acquisition determination unit 76 in CGW13 will be described with reference to fig. 60. CGW13 executes a write data acquisition determination program and performs write data acquisition determination processing.

Upon determining that an event for acquiring write data is generated, CGW13 starts write data acquisition determination processing. When CGW13 starts the write data acquisition determination process, it determines whether or not the acquisition permission determination flag is set (S401, S402). If the CGW13 determines that the acquisition availability determination flag is the first predetermined value (yes in S401), it determines the state of data communication between the center device 3 and the DCM12 (S403). When the CGW13 determines that the data communication between the center apparatus 3 and the DCM12 is connected (yes in S403), it transmits a write data acquisition request to the DCM12(S404), and ends the write data acquisition determination process. After that, when the CGW13 transfers the write data from the DCM12, the transferred write data is distributed to the rewrite target ECU 19. When the CGW13 determines that the data communication between the center apparatus 3 and the DCM12 is not connected but interrupted (S403: no), the CGW13 does not transmit the write data acquisition request to the DCM12, and ends the write data acquisition determination process.

When the CGW13 determines that the acquisition permission determination flag is the second predetermined value (yes in S402), the CGW13 transmits the request for acquiring write data to the DCM12 without determining the state of data communication between the center apparatus 3 and the DCM12, and ends the process of determining acquisition of write data.

As described above, the CGW13 performs the acquisition determination process of the write data before acquiring the write data from the DCM12, thereby determining the state of data communication between the center apparatus 3 and the DCM12 when the acquisition availability determination flag is the first predetermined value. CGW13 starts acquisition of write data when it is determined that data communication is in a connected state, and waits without starting acquisition of write data when it is determined that data communication is in an interrupted state. In a situation where communication with the center apparatus 3 is possible, the write data can be acquired from the DCM12, and the rewriting ECU19 can be installed.

For example, when a plurality of the rewrite target ECUs 19 are provided and it takes time to install them, the progress of installation can be notified from the in-vehicle system 4 to the center device 3, and the progress can be displayed one by one on the portable terminal 6. CGW13 may perform write data acquisition determination processing during acquisition of write data. In this case, if it is determined that the data communication is in the connected state during the acquisition of the write data, the CGW13 continues the acquisition of the write data, but if it is determined that the data communication is in the interrupted state during the acquisition of the write data, the CGW13 interrupts the acquisition of the write data.

Next, the acquisition determination of the write data will be described in more detail. Acquisition of write data is one of processes related to mounting, and here, a mounting instruction determination process is described with reference to fig. 61 to 64. The vehicle program rewriting system 1 performs an instruction determination process of mounting in the CGW 13. The above-described (1) transmission determination processing of the distribution packet, (2) download determination processing of the distribution packet is determination processing performed at the download stage, (3) transmission determination processing of the write data, (4) acquisition determination processing of the write data is processing performed at the installation stage after the download is completed, and (5) instruction determination processing of the installation is processing performed at the installation stage and the activation stage. Here, the distribution packet is downloaded to the DCM12, and the write data (update data, difference data) to the write target ECU19 is unpacked as shown in fig. 10.

As shown in fig. 61, the CGW13 includes an attachment condition determination unit 77a, an attachment instruction unit 77b, a vehicle state information acquisition unit 77c, an activation condition determination unit 77d, and an activation instruction unit 77e in the attachment instruction determination unit 77. The mounting condition determination unit 77a determines whether or not the first condition, the second condition, the third condition, the fourth condition, and the fifth condition are satisfied. The first condition is that user consent relating to installation is obtained. The user consent related to the installation indicates, for example, a consent operation of the user to the installation (for example, pressing the "update immediately" button 506a) in the screen shown in fig. 39. Alternatively, the operation from downloading to activation may be regarded as an update as the user's approval operation for the update.

The second condition is a condition that CGW13 can perform data communication with the center apparatus 3. The third condition is a condition that the vehicle state is installable. The fourth condition is that the rewrite target ECU19 can be mounted. Here, the fourth condition includes not only that the rewrite target ECU19 to be mounted can be mounted, but also that the rewrite target ECU19 cooperates with the rewrite target ECU19 to be mounted. The fifth condition is a condition that the write data is normal data. Here, the normal data includes data suitable for rewriting the ECU19, data that has not been tampered with, and the like.

When the installation condition determination unit 77a determines that all of the first condition, the second condition, the third condition, the fourth condition, and the fifth condition are satisfied, the installation instruction unit 77b instructs the rewrite target ECU19 to install the application. That is, if the installation condition determination unit 77a determines that the user approval about installation is obtained, the CGW13 can perform data communication with the center apparatus 3, the vehicle state is the installable state, the rewrite target ECU19 is the installable state, and the write data is the normal data, the installation instruction unit 77b instructs the rewrite target ECU19 to install the application. Specifically, mounting instruction unit 77b acquires write data from DCM12, and transmits the acquired write data to rewrite target ECU 19. When the installation condition determination unit 77a determines that at least one of the first condition, the second condition, the third condition, the fourth condition, and the fifth condition is not satisfied, the installation instruction unit 77b waits for the rewriting ECU19 without instructing installation of the application, or presents the user with a notice that installation cannot be started and a reason for the notice.

The vehicle state information acquisition portion 77c acquires the vehicle state information from the center device 3. When all the rewrite target ECUs 19 have completed installing the application, the activation condition determination unit 77d determines whether or not the sixth condition, the seventh condition, and the eighth condition are satisfied. The sixth condition is that the user's consent related to the activation is obtained. The user consent related to the activation indicates, for example, a consent operation of the user to the activation (e.g., pressing the "OK" button 508b) in the screen shown in fig. 43. Alternatively, the operation from downloading to activation may be regarded as an update as the user's approval operation for the update. The seventh condition is a condition that the vehicle state is an activatable state. The eighth condition is a condition that the rewrite target ECU19 is in an activatable state.

When the activation condition determination unit 77d determines that all of the sixth condition, the seventh condition, and the eighth condition are satisfied, the activation instruction unit 77e instructs the rewrite target ECU19 to activate the application. The details will be described in the process of instructing the activation request (12) described later. That is, when the activation condition determination unit 77d determines that the user consent on activation is obtained, the vehicle state is the state in which activation is possible, and the rewrite target ECU19 is the state in which activation is possible, the activation instruction unit 77e instructs the rewrite target ECU19 to activate the application. By the activation, the update program written in the rewrite target ECU19 is validated. When the activation condition determination unit 77d determines that at least one of the sixth condition, the seventh condition, and the eighth condition is not satisfied, the activation instruction unit 77e waits without instructing the rewrite target ECU19 to activate an application, or presents to the user a message indicating that activation cannot be started and the reason for the message.

Next, the operation of the mounting instruction determining unit 77 in CGW13 will be described with reference to fig. 62 to 64. CGW13 executes an installation instruction determination program and performs installation instruction determination processing.

When the instruction determination processing for mounting is started, CGW13 determines whether or not the first condition is satisfied, and determines whether or not the user' S consent on mounting is obtained (S501, which corresponds to a part of the mounting condition determination step). When the CGW13 determines that the user approval about the installation is obtained (yes in S501), it determines whether or not the second condition is satisfied, and determines whether or not data communication with the center apparatus 3 is possible (S502, which corresponds to a part of the installation condition determination step). The CGW13 determines whether or not data communication with the center apparatus 3 is possible based on the communication radio wave state in the DCM 12.

When the CGW13 determines that data communication with the center device 3 is possible (yes in S502), it determines whether or not a third condition is satisfied, and determines whether or not the vehicle state is installable (S503, corresponding to a part of the installation condition determination step). As the vehicle state, CGW13 determines whether or not the vehicle state is installable, for example, whether or not the remaining battery level of vehicle battery 40 is equal to or greater than a predetermined capacity, whether or not the vehicle is in a parked state (IG off state) when the memory configuration of rewrite target ECU19 is a one-sided memory, or the like. These vehicle state conditions may be configured to refer to the received rewriting specification data (see fig. 8). For example, when the remaining battery level of the vehicle battery 40 is equal to or greater than the predetermined capacity specified by the rewritten specification data, and matches the vehicle state (only the stopped state, only the traveling state, or both the stopped state and the traveling state) specified by the rewritten specification data, the CGW13 determines that the vehicle state is installable.

If the CGW13 determines that the vehicle state is installable (yes in S503), it determines whether or not the fourth condition is satisfied, and determines whether or not the rewrite target ECU19 is installable (S504, corresponding to a part of the installation condition determination step). The CGW13 determines that the rewrite target ECU19 is installable when, for example, a trouble code is not generated in the rewrite target ECU19 or a secure access to the rewrite target ECU19 is successful. Here, the presence or absence of the generation of the fault code is confirmed not only with respect to the ECU19 to be rewritten to which the write data is written but also with respect to the ECU19 that performs cooperative control with the ECU19 to be rewritten. That is, the CGW13 determines whether or not a failure code has occurred not only in the ECU19 to be rewritten but also in the ECU19 that performs cooperative control with the ECU19 to be rewritten.

If CGW13 determines that it is possible to install rewrite-target ECU19 (S504: yes), it determines whether or not the fifth condition is satisfied, and determines whether or not the write data is normal data (S505, which corresponds to a part of the installation condition determination step). The CGW13 determines that the write data is normal data when the write data matches the write surface (non-operating surface) of the ECU19 to be rewritten and when the verification result of the integrity of the write data is normal. When the CGW13 determines that the write data is normal data (yes in S505), it instructs the rewrite target ECU19 to install an application (S506, corresponding to the installation instruction step), and thus CGW13 makes a determination of the second condition and thereafter, on condition that the first condition is satisfied. CGW13 finally determines the fifth condition. When the CGW13 determines that all of the first to fifth conditions are satisfied, it instructs the rewrite target ECU19 to install an application.

On the other hand, if the CGW13 determines that the user consent relating to the installation is not obtained (S501: no), determines that data communication with the center apparatus 3 is not possible (S502: no), determines that the vehicle state is not installable (S503: no), determines that the rewriting ECU19 is not installable (S504: no), and determines that the written data is not normal data (S505: no), it does not instruct the rewriting ECU19 to install the application. In the above-described processing, the configuration in which the condition that the user's approval about the installation is obtained is determined before the other conditions is described, but the configuration may be determined after the other conditions.

When the CGW13 instructs the rewrite target ECU19 to install the application, the write data is distributed to the rewrite target ECU19(S507), and it is determined whether or not the installation is completed (S508). If CGW13 determines that the installation has been completed (yes in S508), it determines whether or not the sixth condition is satisfied, and determines whether or not user approval for activation is obtained (S509). If CGW13 determines that the user' S approval for activation is obtained (yes in S509), it determines whether or not the seventh condition is satisfied, and determines whether or not the vehicle state is an activatable state (S510).

When the CGW13 determines that the vehicle state is the activatable state (yes in S510), it determines whether or not the eighth condition is satisfied, and determines whether or not the rewrite target ECU19 is the activatable state (S511). If the CGW13 determines that the rewrite target ECU19 is in an activatable state (yes in S511), activation is instructed to the rewrite target ECU19 (S512), and if the CGW13 determines that all of the sixth to eighth conditions are satisfied, activation is instructed to the rewrite target ECU 19.

When there are a plurality of rewrite target ECUs 19, CGW13 may be instructed to be attached independently or collectively. In the case where the rewrite target ECU19 is the ECU (ID1) and the ECU (ID2), in the mode of independently instructing the mounting, as shown in fig. 63, the CGW13 determines whether or not the mounting conditions are satisfied for the ECU (ID 1). When the mounting condition is determined to be satisfied for the ECU (ID1), the CGW13 instructs the ECU (ID1) to mount. Next, CGW13 determines whether or not the mounting conditions are established for the ECU (ID 2). Here, as the mounting condition, the CGW13 may determine whether or not the fourth condition and the fifth condition are established for the ECU (ID 2). When the CGW13 determines that the mounting condition is satisfied for the ECU (ID2), mounting is instructed to the ECU (ID 2).

In the case where the rewrite target ECU19 is the ECU (ID1) or the ECU (ID2), when the ECU is instructed to be mounted together, the CGW13 determines whether or not the mounting condition is satisfied for the ECU (ID1), as shown in fig. 64. That is, CGW13 determines the first to third conditions, and the fourth and fifth conditions with respect to the ECU (ID 1). When the CGW13 determines that the mounting condition is established for the ECU (ID1), it determines whether the mounting condition is established for the ECU (ID 2). That is, CGW13 determines the fourth condition and the fifth condition for the ECU (ID 2). When the mounting condition is established for the ECU (ID2), the CGW13 instructs the ECU (ID1) and the ECU (ID2) to mount. The CGW13 performs, for example, transmission of the rewriting data to the ECU (ID1) and transmission of the rewriting data to the ECU (ID2) simultaneously and in parallel. In this way, in the mode in which CGW13 collectively instructs mounting, the first to third conditions, and the fourth and fifth conditions for all the rewrite target ECUs are determined. Also, CGW13 indicates installation after all of these conditions are met.

As described above, by performing the installation instruction determination process before instructing the rewrite target ECU19 to install, the CGW13 instructs the rewrite target ECU19 to install the application if it is determined that all of the first condition that the user who is related to installation agrees, the second condition that data communication can be performed with the center device 3, the third condition that the vehicle state is the installable state, the fourth condition that the rewrite target ECU19 is the installable state, and the fifth condition that the write data is normal data are satisfied. The rewrite target ECU19 can be instructed to install the application program as appropriate.

(6) Management processing of secure access keys

The management processing of the secure access key will be described with reference to fig. 65 to 69. The secure access key is a key for device authentication when CGW13 accesses rewriting target ECU19 before the installation of write data. The vehicle program rewriting system 1 performs a process of managing a security access key in the CGW 13. Here, the description is made on the premise that the CGW13 can acquire write data from the DCM12 by the above-described (3) transfer determination process of write data or (4) acquisition determination process of write data. The device authentication using the secure access key corresponds to the fourth condition in the instruction determination processing of the above (5) mounting (step S505).

When the CGW13 distributes write data to the rewrite target ECU19, it is necessary to perform secure access (device authentication) between the CGW13 and the rewrite target ECU19 using a secure access key. In this case, a method may be considered in which the CGW13 requests the rewrite target ECU19 to generate a random value, acquires the random value generated by the rewrite target ECU19 from the rewrite target ECU19, and calculates the acquired random value to generate the security access key. However, in such a method, if a random value is acquired from the rewrite target ECU19 even when the application is not rewritten, the secure access key can be held, and therefore there is a risk of the secure access key being leaked.

Further, if the CGW13 is configured to transmit the random value acquired from the rewrite target ECU19 to the center apparatus 3, and the center apparatus 3 calculates the random value and generates the security access key, the security access key does not have to be held, and therefore the risk of leakage of the security access key can be reduced. However, in the configuration in which the center device 3 calculates the random value, the waiting time until the rewrite target ECU19 acquires the random value from the center device 3 is long, and it is difficult to satisfy the time specification for the diagnostic communication. In this case, the present embodiment adopts the following configuration.

As shown in fig. 65, the vendor encrypts the secure access key of each rewriting target ECU19 using the encryption/decryption key of the secure access key to generate a random value. The random value here includes either a value different from a value used in the past or a value identical to the value used in the past, and means a random value. The random value is an encrypted secure access key. The supplier provides the generated random values along with the reprogramming data. The secure access key, the encryption/decryption key of the secure access key, and the random value are keys unique to each ECU 19.

If the random value is supplied from the supplier together with the rebuilt data, the OEM stores the supplied random value in correspondence with the ECU (id) of the recognition ECU19 in the rewriting specification data for CGW shown in fig. 8. The OEM also stores a key pattern and a decryption operation pattern required for decrypting the random value in the rewriting specification data for CGW. The key pattern includes a scheme such as a shared key and a public key, a key length, and the like, and the decryption operation pattern includes a type of algorithm used for the decryption operation. When the random value, the key pattern, and the decryption operation pattern are stored in the rewriting specification data for CGW, the OEM supplies the rewriting specification data for CGW, in which the random value is stored, to the center device 3 together with the rebuilt data. These pieces of information supplied from the vendor are stored in an ECU reprogramming data DB and an ECU metadata DB, which will be described later.

When rewriting specification data (rewriting specification data for DCM and rewriting specification data for CGW) is supplied from the OEM together with the reprogramming data, the center device 3 transmits a distribution packet including the supplied rewriting specification data and reprogramming data to the host device 11. In the host apparatus 11, when the DCM12 downloads the distribution packet from the center apparatus 3, the rewriting specification data and the write data are transmitted to the CGW 13.

As shown in fig. 66, the CGW13 includes a secure area 78a (corresponding to a decryption key storage unit), a random value extraction unit 78b (corresponding to a key derived value extraction unit), a key pattern extraction unit 78c, a decryption operation pattern extraction unit 78d, a key generation unit 78e, a secure access execution unit 78f, a session transfer request unit 78g, and a key erasure unit 78h in the secure access key management unit 78. The secure area 78a cannot read information from outside the ECU19, and is configured with an encryption/decryption key of the secure access key and a decryption operation algorithm. The random value extracting unit 78b extracts a random value (key derived value) included in the rewriting specification data for CGW from the analysis result of the rewriting specification data. The random value is a value that is encrypted in correspondence with the ECU (id) of the rewriting target ECU 19.

The key pattern extraction unit 78c extracts the key pattern included in the rewriting specification data for CGW from the analysis result of the rewriting specification data. The decryption operation pattern extraction unit 78d extracts the decryption operation pattern included in the rewriting specification data for CGW from the analysis result of the rewriting specification data.

When the random value is extracted by the random value extraction unit 78b, the key generation unit 78e searches the secure area 78a, decrypts the extracted random value using a decryption key corresponding to the ecu (id) from a decryption key bundle of the secure access key placed in the secure area 78a, and generates the secure access key. In this case, the key generation unit 78e decrypts the key derived value in accordance with the decryption operation method specified by the decryption operation pattern extracted by the decryption operation pattern extraction unit 78d, using the decryption key specified by the key pattern extracted by the key pattern extraction unit 78 c. That is, a plurality of key patterns and a plurality of decryption operation patterns are prepared, and the key pattern and the decryption operation pattern are specified by the rewriting specification data for CGW, and the key generation unit 78e generates the secure access key using the key patterns and the decryption operation patterns.

When the key generation unit 78e generates the secure access key, the secure access execution unit 78f executes secure access to the rewrite target ECU19 using the generated secure access key. Specifically, the secure access execution unit 78f transmits, for example, encrypted data obtained by encrypting the ECU (id) with the secure access key, and requests the rewrite target ECU19 for access. When receiving the encrypted data, the rewrite target ECU19 decrypts the received encrypted data using the secure access key held by itself. The rewrite target ECU19 compares the decrypted data generated by the decryption with its own ECU (id), and permits access to itself if both are identical, and does not permit access to itself if both are not identical.

The session transfer request unit 78g requests transfer to a rewrite session. After the default session is transferred to the rewrite session, the secure access execution unit 78f executes the secure access. Alternatively, the secure access may be performed after the session other than the default session (for example, the diagnostic session) is transferred, and then the session may be transferred to the rewrite session. The key erasing unit 78h erases the secure access key generated by the key generating unit 78e after the secure access to the rewriting ECU19 is executed by the secure access executing unit 78f and the rewriting of the application program of the rewriting ECU19 is completed.

Next, the operation of the security access key management unit 78 in CGW13 will be described with reference to fig. 67 to 69. CGW13 executes a security access key management program and performs security access key management processing. CGW13 performs a process of generating a security access key and a process of removing the security access key as a process of managing the security access key. Hereinafter, each process will be described in turn.

(6-1) Generation Process of secure Access Key

When the process of generating the security access key is started, the CGW13 analyzes the rewriting specification data acquired from the DCM12 (S601, corresponding to the rewriting specification data analysis step), and extracts a random value, a key pattern, and a decryption operation pattern from the rewriting specification data for the CGW (S602, corresponding to the key derived value extraction step).

The CGW13 searches the secure area 78a, decrypts the random value extracted from the CGW rewriting specification data using the decryption key corresponding to the ecu (id) from the decryption key bundle of the secure access key placed in the secure area 78a, and generates the secure access key (S603, corresponding to a key generation step).

As shown in fig. 68, CGW13 generates a security access key from the rewriting specification data for CGW. The CGW13 makes a session transfer request to a rewrite session in which write data can be written (S604), executes a secure access to the rewrite target ECU19 using a secure access key (S605), and when the CGW13 completes the execution of the secure access, distributes the write data to the rewrite target ECU19(S606), and makes a session maintenance request (S607). If CGW13 determines that the installation has been completed (yes in S608), the process of generating the secure access key ends.

(6-2) secure access key removal processing

When the security access key removal process is started, CGW13 determines whether rewriting of the application of rewrite target ECU19 is completed (S611). When CGW13 determines that rewriting of the application of rewrite target ECU19 is completed (S611: yes), it erases the security access key generated by executing the security access key generation process (S612), and ends the security access key erasure process.

As described above, by performing the management processing of the security access key, the CGW13 extracts the random value corresponding to the rewrite target ECU19 from the analysis result of the rewrite specification data, decrypts the random value using the decryption key corresponding to the rewrite target ECU19 stored in the secure area 78a, and generates the security access key. The secure access key is generated in CGW13 without acquiring the secure access key from the outside, so that the risk of leakage of the secure access key can be reduced, and secure access to the rewriting target ECU19 can be appropriately performed.

In addition, when there are a plurality of rewrite target ECUs 19, the CGW13 preferably performs the process of generating the security access key before the installation of each write data. Namely, it is preferable that: if the ECU19 to be rewritten is the ECU (ID1), the ECU (ID2), or the ECU (ID3), the CGW13 performs the process of generating the security access key of the ECU (ID1), the process of installing the write data to the ECU (ID1), the process of generating the security access key of the ECU (ID2), the process of installing the write data to the ECU (ID2), the process of generating the security access key of the ECU (ID3), and the process of installing the write data to the ECU (ID3) in this order. For example, as shown in fig. 63, the CGW13 performs a security access process as one of whether or not the mounting condition for the ECU (ID1) is satisfied, and when access is normally permitted, mounting is instructed to the ECU (ID 1). Then, the CGW13 performs a security access process as one process of whether or not the mounting condition for the ECU (ID2) is established, and when the access is normally permitted, instructs the ECU (ID2) to mount.

When the CGW13 performs secure access to the ECU19 and grants access to the ECU, the ECU receives a session transfer request from the CGW13 and releases the secure access, thereby writing data into the flash memory. The session transfer request refers to, for example, "rewrite session transfer request" in the second state as shown in fig. 155. If the rewrite target ECU19 does not receive the session transfer request from CGW13 within a predetermined time (for example, 5 seconds) from the time when access to itself is permitted, it times out, locks the secure access, and does not receive the session transfer request. When the session relocation request is not transmitted to the rewrite target ECU19 within a predetermined time after the permission of the access to the rewrite target ECU19 is determined, the CGW13 needs to transmit the session maintenance request to the rewrite target ECU19, and transmit the session relocation request to the rewrite target ECU19 while keeping the rewrite target ECU19 from timing out.

For example, if an operation is cancelled during rewriting, an application of version 1.0 is written on the operating surface, an application of version 2.0 is written on the non-operating surface, and an activity notification to version 2.0 is generated from this state, only activation may be performed without installation, and therefore, the secure access processing may be omitted.

(7) Verification processing of write data

The verification process of the write data will be described with reference to fig. 70 to 78. The vehicle program rewriting system 1 performs verification processing of the write data in the CGW 13. CGW13 may perform the write data verification process described in the present embodiment before the access permission in the above-described (6) secure access key management process is acquired, or after the access permission is acquired.

As shown in fig. 70, when a supplier or OEM generates write data, a data verification value calculation algorithm is applied to the generated write data to generate a data verification value. Here, the write data may be a new program to be updated or may be differential data from an old program to the new program. The supplier or OEM applies encryption using a predetermined key (key value) to the data verification value to generate an authenticator, and registers the write data and the authenticator in the center apparatus 3 in a corresponding relationship. Specifically, each ECU19 stores these data in the reprogramming data DB described later. The center device 3 generates a distribution packet including the write data and the authenticator, and stores the distribution packet in the packet DB.

When a download request for a distribution packet is generated from the host device 11, the center device 3 transmits the distribution packet including the write data and the authentication code to the host device 11 in accordance with the download request. In this case, the write data transmitted from the center device 3 to the host device 11 is a ciphertext, and the authentication code transmitted from the center device 3 to the host device 11 is also a ciphertext. The authenticator transmitted from the center device 3 to the host device 11 may be plaintext. When the authenticator transmitted from the center device 3 to the host device 11 is in the clear text, the decryption process described later is not necessary.

When the host apparatus 11 downloads the distribution packet from the center apparatus 3, the write data of the rewrite target ECU19 is extracted from the downloaded distribution packet, and the validity of the write data is verified before the write data is distributed to the rewrite target ECU 19. That is, the host device 11 sequentially executes decryption processing, first verification value calculation processing, second verification value calculation processing, comparison processing, and determination processing to verify write data. The decryption process is a process of decrypting the authenticator transmitted in the ciphertext. The first verification value calculation process is a process of calculating a first data verification value as an expected value using a key (key value) from the decrypted authenticator. The second verification value calculation process is a process of calculating a second data verification value from the write data using a data verification value calculation algorithm. The comparison processing is processing of comparing the first data verification value and the second data verification value. The determination process is a process of determining the validity of the write data based on the comparison result of the comparison process.

As shown in fig. 71, CGW13 includes a write-enabled determination unit 79a, a process execution request unit 79b, a process result acquisition unit 79c, and a verification unit 79d in a verification unit 79 for write data. The writable determination unit 79a determines whether or not the writing of the write data is possible in the rewrite target ECU 19. When the writable determination unit 69a determines that the writing of the write data is possible in the rewrite target ECU19, the process execution request unit 79b notifies the DCM12 of the process execution request and requests the DCM12 to execute the process. The process execution request unit 68b notifies the DCM12 of a process execution request for at least one of the decryption process, the first verification value calculation process, the second verification value calculation process, the comparison process, and the determination process. The processing result acquisition unit 68c acquires the processing result from the DCM12 by being notified of the processing result from the DCM 12. When the processing result is acquired by the processing result acquiring unit 68c, the verifying unit 79d verifies the write data using the processing result. That is, in the above configuration, CGW13 corresponds to the first device and the first functional unit, and DCM12 corresponds to the second device and the second functional unit.

Next, the operation of the verification unit 79 for writing data in CGW13 will be described with reference to fig. 72 to 77. CGW13 executes a verification program for write data and performs verification processing for write data.

When the CGW13 starts the verification process of the write data, it notifies the DCM12 of the process execution request and requests the DCM12 to execute the process (S701, corresponding to the process execution request step). The CGW13 notifies the DCM12 of a process execution request for at least one of the decryption process, the first verification value calculation process, the second verification value calculation process, the comparison process, and the determination process. When the CGW13 acquires the processing result from the DCM12 (S702, corresponding to the processing result acquisition step), the write data is verified using the acquired processing result (S703, corresponding to the verification step).

Hereinafter, several cases in which CGW13 notifies DCM12 of a process execution request are exemplified. In the example of fig. 73, the CGW13 notifies the DCM12 of a process execution request of the decryption process, the first verification value calculation process, and the second verification value calculation process. When a process execution request for the decryption process, the first verification value calculation process, and the second verification value calculation process is notified from the CGW13, the DCM12 executes the decryption process, the first verification value calculation process, and the second verification value calculation process in this order. DCM12 executes processing result notification processing to notify CGW13 of the first data verification value calculated by the first verification value calculation processing and the second data verification value calculated by the second verification value calculation processing as processing results. When the CGW13 executes the processing result acquisition processing to acquire the first data verification value and the second data verification value from the DCM12, the CGW13 executes the comparison processing and the determination processing in this order using the first data verification value and the second data verification value. CGW13 verifies the write data based on whether the determination result of the determination process is positive. In this example, DCM12 holds the key used to calculate the first data verification value.

In the example of fig. 74, the CGW13 notifies the DCM12 of a process execution request of the decryption process and the second verification value calculation process. When the process execution request of the decryption process and the second verification value calculation process is notified from CGW13, DCM12 sequentially executes the decryption process and the second verification value calculation process, and notifies CGW13 of the second data verification value calculated by the second verification value calculation process. When the CGW13 executes the processing result acquisition processing to acquire the second data verification value from the DCM12, the CGW13 executes the first verification value calculation processing, and executes the comparison processing and the determination processing in order using the first data verification value calculated by the first verification value calculation processing and the second data verification value. CGW13 verifies the write data based on whether or not the determination result of the determination process is positive. In this example, CGW13 holds the key used to calculate the first data verification value.

In the example of fig. 75, the CGW13 notifies the DCM12 of a process execution request of decryption process, first verification value calculation process, second verification value calculation process, and comparison process. When a process execution request of the decryption process, the first verification value calculation process, the second verification value calculation process, and the comparison process is notified from the CGW13, the DCM12 executes the decryption process, the first verification value calculation process, the second verification value calculation process, and the comparison process in this order. DCM12 executes processing result notification processing, and notifies the comparison result of the comparison processing as a processing result to CGW 13. When the CGW13 executes the processing result acquisition processing and acquires the comparison result from the DCM12, the CGW13 executes the determination processing using the comparison result. CGW13 verifies the write data based on whether the determination result of the determination process is positive. In this example, DCM12 holds the key used to calculate the first data verification value.

In the example of fig. 76, the CGW13 notifies the DCM12 of a process execution request of the decryption process, the first verification value calculation process, the second verification value calculation process, the comparison process, and the determination process. When a process execution request for the decryption process, the first verification value calculation process, the second verification value calculation process, the comparison process, and the determination process is notified from the CGW13, the DCM12 executes the decryption process, the first verification value calculation process, the second verification value calculation process, the comparison process, and the determination process in this order. DCM12 executes processing result notification processing to notify the determination result of the determination processing as a processing result to CGW 13. When the CGW13 executes the processing result acquisition processing and acquires the processing result from the DCM12, it verifies that the write data is being verified according to the determination result indicated by the processing result. In this example, DCM12 holds the key used to calculate the first data verification value.

When there are a plurality of rewrite target ECUs 19, the CGW13 performs verification processing of write data to the plurality of rewrite target ECUs 19 as follows. When there are a plurality of the rewrite target ECUs 19, the CGW13 may verify the write data for the plurality of rewrite target ECUs 19 collectively or may verify the write data independently.

In the method of collectively verifying the write data with respect to the plurality of rewrite target ECUs 19, for example, as shown in fig. 77, CGW13 collectively verifies the write data of the ECU (ID1), the write data of the ECU (ID2), the write data of the ECU (ID3), the write target ECU (ID1) of the write data distributed to the ECU (ID1), the write target ECU (ID2) of the write data distributed to the ECU (ID2), and the write target ECU (ID3) of the write data distributed to the ECU (ID 3). In this case, by performing verification of the written data to the plurality of rewrite target ECUs 19 at once, the time required from the start of verification of the written data to the plurality of rewrite target ECUs 19 to the completion of rewriting of the program can be shortened. That is, compared to a configuration in which written data is independently verified for each of the plurality of rewrite target ECUs 19, it is possible to shorten the time required from the verification of written data for the plurality of rewrite target ECUs 19 to the completion of rewriting of the program.

In the method of verifying the write data independently for each of the plurality of ECU19 to be rewritten, for example, as shown in fig. 78, CGW13 verifies the write data of the ECU (ID1), the write target ECU (ID1) of the write data distributed to the ECU (ID1), the write data of the verification ECU (ID2), the write target ECU (ID2) of the write data distributed to the ECU (ID2), and the write data of the verification ECU (ID3) are distributed to the write target ECU (ID2) of the write data distributed to the ECU (ID 3). In this case, by verifying the write data before distributing the write data, it is possible to avoid unauthorized access and improve reliability. That is, in the configuration in which the written data is verified at once for the plurality of rewrite target ECUs 19, the time from completion of verification to distribution of the written data differs depending on the rewriting order, and if the time from completion of verification to distribution of the written data becomes long, there is a fear that falsification by unauthorized access may occur therebetween.

As described above, the CGW13 causes the DCM12, which downloads the distribution packet from the center apparatus 3, to execute at least part of the process for verifying the write data by performing the verification process of the write data. In the CGW13 and the ECU19 to be rewritten, even if an area for storing the write data cannot be secured or an arithmetic program for verification cannot be installed, the write data can be properly verified before the write data is written into the ECU19 to be rewritten.

In the configuration in which CGW13 performs the first verification value calculation process illustrated in fig. 74, CGW13 holds a key (key value) and performs the verification process without transmitting the key to DCM12, so that it is possible to improve security as compared with the configuration in which DCM12 performs the first verification value calculation process. In the case where there are a plurality of rewrite target ECUs 19, the first verification value calculation process may be performed using a shared key (key value) shared by the plurality of rewrite target ECUs 19, or may be performed using individual keys (key values) different for each of the plurality of rewrite target ECUs 19.

In addition, although the configuration in which CGW13 notifies DCM12 of a process execution request has been described above, for example, in the case where the processing load increases in DCM12 and the original processing is hindered, an ECU other than the navigation device and rewrite target ECU19 may be used instead of DCM12 to notify the navigation device and an ECU other than rewrite target ECU19 of the process execution request. In the case where DCM12 and CGW13 are integrated, the process execution request may be requested from the own process execution unit when the processing can be handled without interfering with the original process. For example, it may be performed between different soft components in the same ECU. The above disclosure may be applied to the host apparatus 11 configured as one integrated ECU having the functions of DCM12 and CGW 13. For example, in fig. 73 to 76, the processing function in CGW13 is set as the first functional block, the processing function in DCM12 is set as the second functional block, the processing execution request is notified from the first functional block to the second functional block, and the execution result is returned from the second functional block to the first functional block. In the case where the processing load increases and the communication processing or the relay processing is hindered in the host apparatus 11 configured as the integrated ECU, the processing execution request may be notified to an ECU other than the navigation apparatus and the rewrite target ECU19 instead of the second functional unit.

The data verification value may be a single value for the entire application program, or may be a plurality of values for each module of the application program. If the write data is full data, the write data can be used in integrity verification after the write data is completed.

The verification of the write data includes the concepts that the center device 3 as a distribution destination of the write data is normal (connection by TLS communication, mutual authentication), that the communication path for downloading the write data from the center device 3 is normal (communication path hiding, encryption), that the write data downloaded from the center device 3 is not falsified (falsification detection), and that the write data downloaded from the center device 3 cannot be falsified (encryption), as opposed to the method in which the secure access verifies whether or not the CGW13 and the rewrite target ECU19 can be connected.

In addition, although the write data when the new program is rewritten is described, the same applies to the write data when the program is rolled back when written back to the old program. In this case, the CGW13 may verify the write data at the time of rollback download from the center apparatus 3, but may verify the write data immediately before the rollback write data is distributed to the rewrite target ECU19 by the generation of a cancel request for writing.

(8) Transmission control processing of data storage plane information

The transmission control processing of the data storage plane information will be described with reference to fig. 79 to 81. The vehicle program rewriting system 1 performs a transmission control process of the data storage plane information in the CGW 13.

As shown in fig. 79, the CGW13 includes a data storage surface information acquisition unit 80a, a data storage surface information transmission unit 80b, a rewriting method determination unit 80c, and a rewriting method instruction unit 80d in the data storage surface information transmission control unit 80. The data storage surface information acquisition unit 80a acquires information on hardware and software from each ECU19 as ECU configuration information. More specifically, in the case of a double-sided memory ECU and a single-sided suspend memory ECU each having a plurality of sides with data storage sides, a software ID including version information of each data storage side and information that can specify an operating side are acquired as double-sided rewrite information (hereinafter referred to as side information).

When the ECU configuration information including the plane information is acquired by the data storage plane information acquisition unit 80a, the data storage plane information transmission unit 80b transmits the acquired plane information as one of the ECU configuration information from the DCM12 to the center device 3. The data storage surface information transmitting unit 80b may transmit the ECU configuration information to the center device 3 every time the IG switch 42 is turned on or off, or may transmit the ECU configuration information to the center device 3 in response to a request from the center device 3. In addition to the dual-sided memory ECU and the single-sided suspend memory ECU, the data storage plane information transmitting unit 80b may be configured to transmit an ECU including plane information together with the single-sided individual memory ECU.

The rewriting method determination unit 80c determines a rewriting method based on the analysis result of the rewriting specification data for CGW 13. The rewriting method indicates a power supply switching method at the time of mounting in the rewrite target ECU 19. When the rewriting method is specified by the rewriting method specifying unit 80c, the rewriting method instructing unit 80d instructs the rewriting target ECU19 to rewrite the application program based on the specified rewriting method. That is, when the rewriting method determination unit 80c determines the rewriting method by power self-holding, the rewriting method instruction unit 80d instructs the rewriting target ECU19 to rewrite the application program by power self-holding. When the rewriting method determination unit 80c determines the rewriting method by power control, the rewriting method instruction unit 80d instructs the rewrite target ECU19 to rewrite the application program by power control without using power self-holding.

Next, an operation of the data storage plane information transmission control unit 80 in the CGW13 will be described with reference to fig. 80 and 81. CGW13 executes a data storage plane information transmission control program and performs data storage plane information transmission control processing.

When the CGW13 starts the transmission control process of the data storage plane information, it transmits an ECU configuration information request including the plane information to all ECUs 19(S801), and acquires the ECU configuration information including the plane information from all ECUs 19 (S802, corresponding to the data storage plane information acquisition step). When the CGW13 acquires the ECU configuration information from each rewrite target ECU19, it transmits the acquired ECU configuration information to the DCM12(S803, corresponding to the data storage surface information transmission step), and waits for the acquisition of the write data and the rewrite specification data from the DCM12 (S804). Here, when the rewrite target ECU19 is specified in advance, the CGW13 may acquire the plane information and the like only from the specified rewrite target ECU 19.

Upon receiving the ECU configuration information from CGW13, DCM12 temporarily accumulates the received ECU configuration information, and transmits the ECU configuration information to center device 3 when it is a timing to transmit (upload) the ECU configuration information to center device 3. Upon receiving the ECU configuration information from the DCM12, the center apparatus 3 stores and analyzes the received ECU configuration information.

The center apparatus 3 identifies the version of the application program for each plane and which plane is the operation plane of each ECU19 that is the transmission source of the plane information, and identifies the version of the application program suitable for the identified 2 planes and the write data of the operation plane (corresponding to the update data selection step). For example, when the a-plane is an operation plane, the application stored in the operation plane is version 2.0, the B-plane is a non-operation plane, and the application stored in the non-operation plane is version 1.0, the center device 3 determines write data of version 3.0 for the B-plane as write data. The center device 3 determines the differential data updated from version 1.0 to version 3.0 when the write data is the differential data. When the center device 3 specifies the write data, it transmits a distribution packet including the specified write data and the rewriting specification data to the DCM12 (corresponding to a distribution packet transmission step).

The center apparatus 3 may statically select the distribution packet to be transmitted to the DCM12, or may dynamically generate the distribution packet. When statically selecting a distribution packet to be transmitted to the DCM12, the center device 3 manages a plurality of distribution packets storing write data, selects write data suitable for the non-operation surface, selects a distribution packet storing the selected write data from the plurality of distribution packets, and transmits the selected distribution packet to the DCM 12. When the center device 3 dynamically generates the distribution packet to be transmitted to the DCM12, if the write data suitable for the non-operation surface is identified, the center device generates the distribution packet in which the identified write data is stored, and transmits the distribution packet to the DCM 12.

When the DCM12 downloads the distribution packet from the center apparatus 3, the write data and the rewriting specification data are extracted from the downloaded distribution packet, and the extracted write data and rewriting specification data are transferred to the CGW 13.

When the CGW13 determines that the write data and the rewrite specification data are acquired from the DCM12 (S804: yes), the acquired rewrite specification data are analyzed (S805), and a rewrite method for the rewrite target ECU19 is determined based on the analysis result of the rewrite specification data (S806, S807).

When the CGW13 determines that the rewriting method is rewriting by power self-holding (S806: yes), it transmits a write data acquisition request to the DCM12, acquires write data from the DCM12, distributes the acquired write data to the rewriting target ECU19, and ends the transmission control processing of the data storage surface information by the power self-holding rewriting application (S808), on condition that the vehicle is in an installable vehicle state. The method of rewriting the application program by power supply self-holding is as described in the case of (ii) rewriting the application program by power supply self-holding using fig. 28 and fig. 29 described above.

When the CGW13 determines that the rewriting method is rewriting by power control (S807: yes), it transmits a write data acquisition request to the DCM12, acquires write data from the DCM12, distributes the acquired write data to the rewriting target ECU19, and ends the transmission control process of the data storage surface information by the power control rewriting application (S809). The method of rewriting the application program by power supply control is as described in the case of (a) rewriting the application program by power supply control using fig. 26 and fig. 27 described above.

As described above, the CGW13 performs the transmission control process of the data storage plane information, thereby notifying the center device 3 of the ECU configuration information including the plane information, and causing the center device 3 to download the distribution packet including the write data suitable for the ECU configuration information to the DCM 12. The CGW13 acquires write data suitable for the surface information from the DCM12, and distributes the write data to the rewrite target ECU 19. When the ECU19 having a flash memory with a data storage surface on the 2-side is to be rewritten, the application program can be rewritten appropriately.

Further, as methods for distributing the distribution packet by the center apparatus 3, there are a first distribution method to a third distribution method described below. In the first distribution method, the center apparatus 3 distributes, for example, one distribution packet in which the write data of version 2.0 for the a-plane and the write data of version 2.0 for the B-plane are stored. The DCM12 extracts the write data of version 2.0 for the a-plane and the write data of version 2.0 for the B-plane from the distribution packet downloaded from the center apparatus 3, and transfers the extracted write data to the CGW 13. When the write data of version 2.0 for the a-plane and the write data of version 2.0 for the B-plane are transferred from the DCM12, the CGW13 selects either one of them and distributes it to the rewrite target ECU 19. That is, the write data corresponding to each data storage surface is included in the distribution packet, and the host apparatus 11 selects the rewrite data suitable for the rewrite target ECU 19.

In the second distribution method, the center apparatus 3 selects and distributes either a distribution package in which the write data of version 2.0 for the a-plane is stored or a distribution package in which the write data of version 2.0 for the B-plane is stored, for example. The DCM12 extracts write data from the distribution packet downloaded from the center apparatus 3, and transfers the extracted write data to the CGW 13. The CGW13 distributes the write data transmitted from the DCM12 to the rewrite target ECU 19. That is, the center device 3 selects a distribution packet including write data for a non-operational plane based on plane information uploaded from the DCM 12.

In the third distribution method, the hub device 3 distributes a distribution packet storing write data of version 2.0 shared for the a-plane and the B-plane, for example. The DCM12 extracts write data of the shared version 2.0 for the a-plane and the B-plane from the distribution packet downloaded from the center apparatus 3, and transfers the extracted write data to the CGW 13. The CGW13 distributes the write data of the shared version 2.0 for the a-plane and the B-plane transmitted from the DCM12 to the rewrite target ECU 19. When receiving the write data of version 2.0 shared for the a-plane and the B-plane from the CGW13, the rewrite target ECU19 writes the received write data to either the a-plane or the B-plane. In this case, when the application is executed in the rewrite target ECU19, the address resolution function of the microcomputer functions so that the microcomputer operates appropriately regardless of whether the write data is written on the a-side or the B-side. That is, the microcomputer of the write target ECU19 solves the difference in the execution addresses due to the difference in the plane, and the center device 3 and the host device 11 can operate without knowing the plane.

The ECU configuration information including the plane information transmitted from the CGW13 to the center device 3 via the DCM12 may include vehicle identification information, system identification information, ECU identification information, usage environment information, and the like, in addition to the version of the 2-plane application program and information that can identify the operation plane.

The Vehicle Identification information is unique information for identifying a Vehicle to which the packet is to be distributed, and is, for example, a VIN (Vehicle Identification Number). In a vehicle that conforms to the On-board diagnostics (OBD) regulation, the VIN can be used according to the OBD regulation, but if the vehicle does not conform to the OBD regulation, such as an EV vehicle, the VIN cannot be used.

The system determination information is unique information for determining which type of the rebuilt system is. CGW13 can wirelessly rewrite a system capable of wired rewriting diagnostic communication by self-management, but cannot wirelessly rewrite a system of an original system other than the above. That is, this is because the system is a system that updates a program acquired via radio by using a mechanism of program update acquired via cable. Therefore, the center device 3 needs to determine which distribution packet is distributed to which system, and can manage what system is mounted in the vehicle by using the system identification information. The center device 3 can determine the rewriting method for each system, the rewriting order when a plurality of systems are to be rewritten, and the like by the determination system specifying information.

The ECU specification information is unique information for specifying the rewrite target ECU19, and is information including a software version and a hardware version for uniquely specifying the rewrite ECU and an application program written in the rewrite target ECU 19. The ECU determination information also corresponds to an ECU product number. In the case of writing the latest software with all data, only the hardware version may be used. Further, information that can specify an application, such as a specification version and a configuration version, may be defined, and a microcomputer ID, a slave microcomputer ID, a flash memory ID, a software child version, a software grandchild version, and the like may be defined.

The usage environment information is unique information for determining the environment in which the user uses the vehicle. By transmitting the usage environment information from the CGW13 to the center apparatus 3 via the DCM12, the center apparatus 3 can distribute an application suitable for the environment where the user uses the vehicle. For example, an application program for enhancing acceleration is distributed to a user who prefers rapid acceleration driving from a stop time, an application program for enhancing eco-driving although acceleration performance is poor is distributed to a user who prefers eco-driving, and the like, and an application program suitable for an environment where a user uses a vehicle can be distributed.

In addition, although the case where the flash memory is mounted on the microcomputer of the ECU19 to be rewritten has been described above, when the external memory is connected to the microcomputer of the ECU19 to be rewritten, the external memory is handled in the same manner as the dual-sided memory, and the write area of the external memory is divided into 2 areas to write the write data. When the microcomputer of the rewrite target ECU19 has a flash memory mounted thereon and an external memory is connected thereto, a process of temporarily copying (copying) a program stored in the external memory to the memory of the microcomputer may be performed. Since the external memory is generally used as a storage area for the operation log of the ECU, it is preferable that the storage of the operation log is interrupted when the writing of the write data into the external memory is started, and the storage of the operation log is restarted when the writing of the write data into the external memory is completed.

The concept of double-sided and version is applicable to data having a property of being updated one by one, such as map data, and the same applies to the case of rewriting map data.

(9) Power management processing for non-rewritable object

The power management processing of the non-rewrite target ECU19 will be described with reference to fig. 82 to 87. The vehicle program rewriting system 1 performs power management processing of the non-rewriting ECU19 in the CGW 13. In the present embodiment, the download of the distribution packet is completed by DCM12, and CGW13 acquires rewriting specification data, and CGW13 distributes the write data to ECU19 to be rewritten in the vehicle stopped state. When the CGW13 distributes the write data to the rewrite target ECU19, it requests the power management ECU20 to turn on the IG power source, and sets all ECUs 19 to the activated state.

As shown in fig. 82, the CGW13 includes a rewriting target specifying unit 81a, an installability determining unit 81b, a state transition control unit 81c, and a rewriting order specifying unit 81d in the power supply management unit 81 of the non-rewriting target ECU 19. The rewritten object specifying unit 81a specifies the rewritten object ECU19 and the non-rewritten object ECU19 based on the analysis result of the rewritten specification data. The installability determination unit 81b determines whether or not the ECU19 to be rewritten can be installed.

The state transition controller 81c can transition the state of the ECU19, transition the ECU19 in the stopped state or the sleep state to the activated state (awake state), or transition the ECU19 in the activated state to the stopped state or the sleep state. The state transition controller 81c also causes the ECU19 in the normal operation state to transition to the power saving operation state, or causes the ECU19 in the power saving operation state to transition to the normal operation state. When the installability determination unit 81b determines that installation is possible, the state transition control unit 81c controls at least one or more of the non-rewrite target ECUs 19 to be in a stopped state, a sleep state, or a power saving operation state. The rewriting order determination unit 81d determines the rewriting order of the rewriting ECU19 based on the analysis result of the rewriting specification data.

Next, the operation of the power supply management unit 81 of the ECU19 to be unwritten in CGW13 will be described with reference to fig. 83 to 87. CGW13 executes a power management program for the non-rewritable object, and performs power management processing for the non-rewritable object. Here, a case where CGW13 sets all ECUs 19 to be managed to an activated state will be described.

When the CGW13 starts the power management processing of the ECU19 to be rewritten, the ECU19 to be rewritten and the ECU19 to be non-rewritten are specified based on the analysis result of the rewritten specification data for CGW (S901), and the rewriting order of one or more ECUs 19 to be rewritten is specified based on the analysis result of the rewritten specification data (S902). The CGW13 determines whether or not write data can be written (S903, corresponding to a writable determination step), and if it is determined that write data can be written (S903: yes), transmits a power-off request (stop request) to the non-rewritable ECU19 of the ACC system and the non-rewritable ECU19 of the IG system, and causes the non-rewritable ECU19 of the ACC system and the non-rewritable ECU19 of the IG system to transition from the on state to the off state (S904, corresponding to a state transition control step).

The CGW13 determines whether or not transmission of the power-off request to all of the conforming ECUs 19 is complete (S905), and when it is determined that transmission of the power-off request to all of the conforming ECUs 19 is complete (S905: yes), transmits a sleep request to the non-rewriting ECU19 of the + B power supply system, and shifts the non-rewriting ECU19 of the + B power supply system from the activated state to the sleep state (S906, corresponding to a state shift control step).

The CGW13 determines whether or not transmission of the sleep request to all of the conforming ECUs 19 is completed (S907), and if it is determined that transmission of the sleep request to all of the conforming ECUs 19 is completed (S907: yes), determines whether or not rewriting of the application to all of the rewriting target ECUs 19 is completed (S908). When the CGW13 determines that the rewriting of the application is completed for all the rewriting ECU19 (S908: yes), the power management process of the non-rewriting ECU19 is terminated. When CGW13 determines that rewriting of the application has not been completed for all of the rewriters ECU19 (S908: no), the process returns to step S904, and the steps at and after step S904 are repeated.

When there are a plurality of the rewrite target ECUs 19, the CGW13 may shift the states of the plurality of rewrite target ECUs 19 independently, or may shift the states of the plurality of rewrite target ECUs 19 together. That is, fig. 83 shows a process in which CGW13 transmits a power-off request or a sleep request to non-rewriting ECU 19. Next, in fig. 84 and 85, a case will be described in which power management processing is performed for the rewrite target ECU19 in addition to power management processing for the non-rewrite target ECU 19.

First, a case where CGW13 makes the states of plural rewriting ECU19 transition independently will be described with reference to fig. 84. As shown in fig. 84, a case will be described where, for example, the rewrite target ECU19 is an ECU (ID1), an ECU (ID2), and an ECU (ID3), and the rewrite target ECU19 designated by the ECU (ID1), the ECU (ID2), and the ECU (ID3) in the order of rewriting from the morning to the evening during parking is rewritten.

CGW13 shifts all of ECU (ID1), ECU (ID2), and ECU (ID3) from the stopped state or the sleep state to the activated state. The CGW13 changes the ECU (ID2) and the ECU (ID3) from the activated state to the deactivated state or the sleep state with the activated state of the first rewritten ECU (ID1) maintained, and distributes the write data to the ECU (ID 1). When the CGW13 completes distribution of the write data to the ECU (ID1), the ECU (ID1) is caused to transition from the activated state to the deactivated state or the sleep state, the second rewritten ECU (ID2) is caused to transition from the deactivated state or the sleep state to the activated state, the ECU (ID3) is caused to remain in the deactivated state or the sleep state, and the write data is distributed to the ECU (ID 2).

When the CGW13 completes distribution of the write data to the ECU (ID2), the ECU (ID1) is kept in the stopped state or the sleep state, the ECU (ID2) is shifted from the activated state to the stopped state or the sleep state, the third rewritten ECU (ID3) is shifted from the stopped state or the sleep state to the activated state, and the write data is distributed to the ECU (ID 3). When the CGW13 completes distribution of the write data to the ECU (ID3), the ECU (ID1) and the ECU (ID2) are kept in the stopped state or the sleep state, and the ECU (ID3) is shifted from the activated state to the stopped state or the sleep state. In this way, CGW13 is controlled so that only ECU19 currently being rewritten among plural rewrite target ECUs 19 is in an activated state.

Next, a case where CGW13 collectively changes the states of plural rewrite target ECUs 19 will be described with reference to fig. 85. As shown in fig. 85, a case will be described where, for example, the rewrite target ECU19 is an ECU (ID1), an ECU (ID2), and an ECU (ID3), and the rewrite target ECU19 designated by the ECU (ID1), the ECU (ID2), and the ECU (ID3) in the order of rewriting from the morning to the evening during parking is rewritten.

CGW13 shifts all of ECU (ID1), ECU (ID2), and ECU (ID3) from the stopped state or the sleep state to the activated state. CGW13 distributes the write data to ECU (ID1) while keeping all of ECU (ID1), ECU (ID2), and ECU (ID3) in the activated state. Upon completion of the distribution of the write data to the ECU (ID1), the CGW13 distributes the write data to the ECU (ID 2). Upon completion of the distribution of the write data to the ECU (ID2), the CGW13 distributes the write data to the ECU (ID 3). Upon completion of distribution of the write data to the ECU (ID3), the CGW13 causes all of the ECU (ID1), the ECU (ID2), and the ECU (ID3) to transition from the activated state to the deactivated state or the sleep state. In this way, CGW13 controls all of plural rewrite target ECUs 19 to be in the activated state until all of the mounting operations are completed. Here, CGW13 may simultaneously and concurrently distribute the write data to ECU (ID1), ECU (ID2), and ECU (ID 3).

When the rewrite-target ECU19 rewrites an application during a stop, the environment in which the voltage supplied to the rewrite-target ECU19 is stable is not always necessary, and therefore there is a concern that the battery capacity of the vehicle battery 40 will run out during rewriting of the application. In particular, if there are a plurality of the rewrite target ECUs 19, the time required to rewrite the application program increases, and therefore the possibility of the battery level of the vehicle battery 40 running low during the rewriting of the application program increases. In this regard, by setting the non-rewriting ECU19 to the stopped state or the sleep state as described above, it is possible to prevent a situation in which the remaining battery capacity of the vehicle battery 40 is insufficient during rewriting of the program. Furthermore, by setting the ECU19, which is not currently being rewritten, of the rewrite-target ECUs 19 to the stopped state or the sleep state, power consumption can be further suppressed.

While the above description has been made of the case where the application program of the ECU19 to be rewritten is rewritten during parking, the description has been made of the case where the application program of the ECU19 to be rewritten is rewritten during traveling of the vehicle. When the rewrite target ECU19 rewrites an application while the vehicle is traveling, the supply voltage to the rewrite target ECU19 is stable, and therefore there is no fear that the vehicle battery 40 runs out of battery charge during rewriting of the application, but there may be a case where the remaining battery level of the vehicle battery 40 is small. In this case, it is preferable that the ECU19 which does not need to be operated is shifted to a stop state or a sleep state while the vehicle is running. As shown in fig. 86, in the case of a configuration in which ECU44, which does not need to operate while the vehicle is traveling, is connected to + B power line 37, but is not connected to ACC power line 38 and IG power line 39, CGW13 causes ECU44, which does not need to operate while the vehicle is traveling, to transition from the on state to the off state or the sleep state. The ECU44 is, for example, an ECU having a theft prevention function. Specifically, while all ECUs 19 are in the activated state during vehicle traveling, CGW13 causes ECUs 44 that do not need to be operated and are not to be rewritten to transition to the stopped state or the sleep state. This can suppress an increase in power consumption associated with installation while the vehicle is traveling.

CGW13 monitors the remaining battery level of vehicle battery 40, and performs the power management processing described above for non-rewriting objects. Here, the process of monitoring the remaining battery level will be described with reference to fig. 87. When the CGW13 starts the remaining battery level monitoring process, the remaining battery level is monitored while the write data is being distributed to the ECU19 to be rewritten (S911), and it is determined whether the remaining battery level is equal to or higher than a first predetermined capacity, whether the remaining battery level is lower than the first predetermined capacity and equal to or higher than a second predetermined capacity, or whether the remaining battery level is lower than the second predetermined capacity (S912 to S914).

When the CGW13 determines that the remaining battery capacity is equal to or greater than the first predetermined capacity (yes in S912), the non-rewrite target ECU19 is kept activated, and distribution of the write data to the rewrite target ECU19 is continued (S915). When the CGW13 determines that the remaining battery level is less than the first predetermined capacity and equal to or greater than the second predetermined capacity (S913: yes), the ECU that does not need to operate during traveling among the non-rewrite target ECUs 19 is shifted to the stopped state or the sleep state, and distribution of the write data to the rewrite target ECU19 is continued (S916). When CGW13 determines that the remaining battery capacity is less than the second predetermined capacity (yes in S914), it determines whether rewriting can be interrupted (S917).

If CGW13 determines that rewriting can be interrupted (S917: yes), distribution of write data is interrupted (S918). If CGW13 determines that rewriting cannot be interrupted (S917: no), all of non-rewriting target ECUs 19 that can transition to the stopped state or the sleep state are transitioned to the stopped state or the sleep state (S919).

CGW13 determines whether rewriting is completed (S920), and if rewriting is determined not to be completed (S920: No), returns to step S911, and repeats step S911 and subsequent steps. If it is determined that rewriting is complete (yes in S920), CGW13 transitions ECU19 to be rewritten, which is in a stopped state or a sleep state, to an activated state (S921), and ends the remaining battery level monitoring process. Here, the values of the first predetermined capacity and the second predetermined capacity may be previously provided by CGW13, or values specified by rewriting the specification data may be used.

In step S919, CGW13 may exclude ECU19 having a specific function such as a warning function from the transition to the stopped state or the sleep state, and cause non-rewritten ECU19 other than ECU19 having the specific function to transition from the activated state to the stopped state or the sleep state. When the application control can be executed while the rewriting ECU19 rewrites the application program, the CGW13 may set the non-rewriting ECU19 other than the ECU19 that can communicate with the rewriting ECU19 to a stopped state or a sleep state. When all the ECUs 19 are in the stopped state or the sleep state, and when the rewriting condition is satisfied, for example, when the vehicle position becomes a predetermined position or the current time becomes a predetermined time, the CGW13 may shift the ECU19 to be rewritten from the stopped state or the sleep state to the activated state.

The CGW13 may group the writing target ECU19 or the non-writing target ECU19 based on any one of the startup power supply (+ B power supply system ECU, ACC system ECU, IG system ECU), the field group (vehicle body system, traveling system, multimedia system), and the synchronization timing, and set the writing target ECU19 to the startup state in units of groups, or set the non-writing target ECU19 to the stop state or the sleep state in units of groups.

CGW13 may be configured to control power supply in units of a bus. That is, if it is determined that all of the ECUs 19 connected to the specific bus are the non-rewrite target ECU19, the CGW13 may turn off the power supply to the specific bus, thereby causing all of the non-rewrite target ECUs 19 connected to the specific bus to transition to the stop state or the sleep state.

As described above, the CGW13 performs the power management processing for the non-rewritable object, and when it is determined that the non-rewritable object ECU19 can be mounted, causes at least one or more of the non-rewritable object ECUs 19 to be in the stopped state, the sleep state, or the power saving operation state. It is possible to prevent a situation in which the remaining battery level of the vehicle battery 40 becomes insufficient during the rewriting of the application program. Further, by setting the non-rewrite target ECU19 to a stop state, a sleep state, or a power saving operation state, it is possible to suppress an increase in communication load.

(10) Transmission control processing of files

The file transfer control processing will be described with reference to fig. 88 to 97. The vehicle program rewriting system 1 performs file transfer control processing in the CGW 13. The present embodiment is a process when rewriting data held in DCM12 (corresponding to a first device) is transmitted to rewrite target ECU19 (corresponding to a third device) via CGW13 (corresponding to a second device).

As shown in fig. 88, the CGW13 includes a file transfer control unit 82 including a transfer target file specifying unit 82a, a first data size specifying unit 82b, an acquired information specifying unit 82c, a second data size specifying unit 82d, and a divided file transfer requesting unit 82 e. The transmission target file specifying unit 82a specifies a file including the write data written in the rewrite target ECU19 as a transmission target file using the analysis result of the rewrite specification data. For example, when the ECU19 to be rewritten is the ECU (ID1), the ECU (ID2), or the ECU (ID3), the file-to-be-transferred specifying unit 82a acquires the ECU information of the ECU (ID1), the ECU (ID2), and the ECU (ID3) from the rewriting specification data for CGW shown in fig. 8, and specifies a file including the write data as the file-to-be-transferred based on the acquired ECU information. As the file to be transferred, the address and index at the time of acquiring the file may be specified, or the file name of the file may be specified.

When the transfer target file is specified by the transfer target file specifying unit 82a, the first data size specifying unit 82b specifies the first data size for acquiring the transfer target file. When the transmission target file is determined by the transmission target file determining section 82a, the acquisition information determining section 82c determines an address as the acquisition information for acquiring the transmission target file. In the present embodiment, the address is specified as acquisition information for acquiring the file to be transferred, but if the address is acquisition information for acquiring the file to be transferred, the address is not limited to the address, and a file name, ecu (id), or the like may be used. The second data size determination unit 82d determines a second data size for distributing the write data to the rewrite target ECU 19. That is, the first data size is the data transfer size from the DCM12 to the CGW13, and the second data size is the data transfer size from the CGW13 to the rewrite target ECU 19.

If the address is determined by the acquisition information determining section 82c and the first data size is determined by the first data size determining section 82b, the divided file transfer requesting section 82e specifies the address and the first data size to the DCM12 and requests the DCM12 for transfer of the divided file. For example, when the data amount of the write file to be distributed to the ECU (ID1) is 1 mbyte, the divided file transfer request unit 82e requests the write data to be transferred from the address 0x10000000 by 1 kbyte.

Next, the operation of the file transfer control unit 82 in CGW13 will be described with reference to fig. 89 to 97. CGW13 executes a file transfer control program and performs a file transfer control process.

When the CGW13 determines that the depacketization completion notification signal is received from the DCM12, it starts the file transfer control process. Unpacking is processing for dividing a distribution packet file into data for each ECU and rewriting specification data as shown in fig. 10. When the file transfer control process is started, the CGW13 transmits the predetermined address to the DCM12 (S1001). When DCM12 receives the predetermined address from CGW13, it transfers the rewriting specification data for CGW to CGW13 as a trigger to receive the predetermined address. The CGW13 acquires the rewriting specification data for CGW by transmitting the rewriting specification data for CGW from the DCM12 (S1002).

When the CGW13 acquires the rewriting specification data for CGW from the DCM12, the acquired rewriting specification data for CGW is analyzed (S1003), and the file to be transferred is identified based on the analysis result of the rewriting specification data (S1004, which corresponds to a file to be transferred identification step). The CGW13 specifies the address corresponding to the file to be transferred (S1005, corresponding to the acquisition information specifying step), and specifies the first data size corresponding to the file to be transferred (S1006, corresponding to the first data size specifying step). The CGW13 sends the determined address and data size to the DCM12 as specified by sid (service identifier)35, specifies the address and data size for the memory area, and requests the DCM12 to transmit the split file (S1007).

Upon receiving the address and the data size from CGW13, DCM12 analyzes the rewriting specification data for DCM, and transfers a file corresponding to the address and the data size to CGW13 as a divided file. The CGW13 acquires the split file by being transmitted from the DCM12 (S1008). In this case, CGW13 may store the acquired file in the RAM and then in the flash memory.

CGW13 determines whether or not acquisition of all the divided files to be acquired is completed (S1009). For example, when the data amount of the write file to be distributed to the ECU (ID1) is 1 mbyte, the CGW13 acquires the divided files every 1 kbyte, repeats the acquisition of the divided files every 1 kbyte, and determines whether or not the acquisition of the data amount of 1 mbyte is completed. If the CGW13 determines that the acquisition of all the divided files to be acquired has not been completed (S1009: no), the process returns to step S1004, and the steps after step S1004 are repeated. When CGW13 determines that the acquisition of all files to be acquired is completed (S1009: yes), it ends the file transfer control process. When there are a plurality of the ECU to be rewritten 19, the CGW13 repeats the file transfer control process described above for each ECU to be rewritten 19.

That is, for example, in the case where the ECU19 to be rewritten is the ECU (ID1), the ECU (ID2), or the ECU (ID3), the CGW13 performs the file transfer control processing for the ECU (ID2) when the distribution of the write data to the ECU (ID1) is completed, and performs the file transfer control processing for the ECU (ID3) when the distribution of the write data to the ECU (ID2) is completed. CGW13 may perform transfer control processing for a plurality of rewrite target ECUs 19 in sequence, or may perform the transfer control processing in parallel.

Fig. 90 shows a case where, in the memory of DCM12, for example, the write data files of ECU (ID1) are stored at addresses "1000" to "3999", the write data files of ECU (ID2) are stored at addresses "4000" to "6999", and the write data files of ECU (ID3) are stored at addresses "7000".

In this case, as shown in fig. 91, upon receiving the depacketization completion notification signal from DCM12, CGW13 transmits address "0000" to DCM12, and acquires the rewriting specification data from DCM 12. That is, when determining that the reception of the address "0000" is the request for acquiring the CGW rewriting data, the DCM12 transmits the CGW rewriting specification data to the CGW 13. The CGW13 specifies the ECU (ID1) as the transfer destination of the write data, specifies the address "1000" and the data size "1 kbyte", and acquires the split file including the write data stored in the ECUs (ID1) of the addresses "1000" to "1999" from the DCM 12. When the CGW13 acquires the split file from the DCM12, the write data included in the split file is distributed to the ECU (ID 1).

The CGW13 then similarly designates the ECU (ID1) as the transfer destination of the write data, designates the address "2000" and the data size "1 kbyte", and acquires the split file including the write data stored in the ECUs (ID1) at the addresses "2000" to "2999" from the DCM 12. When the CGW13 acquires a split file from the DCM12, the write data included in the split file is distributed to the ECU (ID 1). Until all the write data is written to the ECU (ID1), the CGW13 repeatedly acquires the split file of 1 kbyte from the DCM12 and repeatedly distributes the write data contained in the split file to the ECU (ID 1). That is, the CGW13 transmits the 1 k-byte write data to the rewrite target ECU19 when the 1 k-byte write data is acquired from the DCM12, and acquires the next 1 k-byte write data from the DCM12 when the transmission to the rewrite target ECU19 is completed. CGW13 repeats these processes until the write is fully completed.

When the ECU (ID1) completes writing of write data normally, the CGW13 specifies the ECU (ID2) as the transfer destination of the write data, specifies the address "4000" and the data size "1 kbyte", and acquires the split file including the write data stored in the ECUs (ID2) at the addresses "4000" to "4999" from the DCM 12. When the CGW13 acquires the split file from the DCM12, the write data included in the split file is distributed to the ECU (ID 2).

When the ECU (ID2) completes writing of write data normally, the CGW13 specifies the ECU (ID3) as the transfer target of the write data, specifies the address "7000" and the data size "1 kbyte", and acquires the split file including the write data stored in the ECUs (ID2) at the addresses "7000" to "7999" from the DCM 12. When the CGW13 acquires a split file from the DCM12, the write data included in the split file is distributed to the ECU (ID 2).

As described above, CGW13 specifies a file to be transferred from the analysis result of the rewriting specification data by performing file transfer control processing, and specifies an address and a data size corresponding to the file to be transferred. The CGW13 specifies the address and the data size to the DCM12, requests the DCM12 to transfer the split file in which the transfer object file is split, and acquires the split file from the DCM 12. Thus, the write data can be distributed to ECU19 in a state where the write data having a large memory capacity is stored in DCM 12. That is, CGW13 does not need to prepare a memory for storing files with a large capacity, and the memory capacity of CGW13 can be reduced.

Here, the relationship between the data amount of the divided file transferred from the DCM12 to the CGW13 and the data amount of the write file distributed from the CGW13 to the rewrite target ECU19 will be described. In the above example, as shown in fig. 92, the description has been given of the case where the data amount of the divided file transferred from DCM12 to CGW13 is 1 kbyte, but the relationship between the data amount of the divided file transferred from DCM12 to CGW13 and the data amount of the write file distributed from CGW13 to rewrite target ECU19 may be arbitrary.

That is, for example, if the specification for receiving the write data in 4 kbytes is adopted by the rewrite target ECU19 for CAN communication reasons, the CGW13 distributes the data amount of the write file to the rewrite target ECU19 in 4 kbytes. In this case, if the data amount of the divided files transferred from the DCM12 to the CGW13 is 1 kbyte, the CGW13 acquires four divided files from the DCM12 and then distributes 4 kbytes to the rewrite target ECU 19. That is, the data amount of the divided file transferred from the DCM12 to the CGW13 is smaller than the data amount of the written file distributed from the CGW13 to the rewrite target ECU 19. In such a relation, in CGW13, while suppressing an increase in memory capacity, the divided files are acquired from the DCM12 in parallel, and the write data is distributed to the rewrite target ECU 19.

That is, if the data amount of the divided file transferred from DCM12 to CGW13 is 4 kbytes, the memory capacity of CGW13 needs to be 8 kbytes in order to acquire the divided file from DCM12 and distribute the write data to rewrite target ECU19 in parallel. By setting the data size of the divided file transferred from DCM12 to CGW13 to 1 kbyte, the divided file can be acquired from DCM12 in parallel without setting the memory capacity of CGW13 to 8 kbytes, and the write data can be distributed to rewrite target ECU 19. For example, the memory capacity of the CGW13 is secured to 5 kbytes in advance, and the CGW13 distributes 4 kbytes acquired from the DCM12 to the rewrite target ECU19, and acquires the next 1 kbyte from the DCM 12. After the completion of the 4k bytes distribution to the rewrite target ECU19, the CGW13 acquires the next 1k bytes from the DCM 12.

On the other hand, if the specification of receiving the write data in 128 bytes is adopted by the rewrite target ECU19 for CAN communication reasons, for example, the CGW13 distributes the write data in 128 bytes to the rewrite target ECU 19. In this case, if the data amount of the divided file transferred from the DCM12 to the CGW13 is 1 kbyte, the CGW13 acquires one divided file from the DCM12 and then distributes the acquired divided file to the rewrite target ECU19 by 128 bytes. That is, the data amount of the divided file transferred from the DCM12 to the CGW13 is larger than the data amount of the write file distributed from the CGW13 to the rewrite target ECU 19. For example, the memory capacity of CGW13 is secured to 2 kbytes in advance, CGW13 distributes 1 kbyte acquired from DCM12 to rewrite target ECU19 in units of 128 bytes, and acquires the next 1 kbyte from DCM 12. Then, after the CGW13 completes the distribution of 128 bytes × 8 times to the rewrite target ECU19, the next 1 kbyte is further acquired from the DCM 12.

In this way, the data amount of the divided file transferred from DCM12 to CGW13 may be a fixed value (for example, 1 kbyte), and the data amount of the write file distributed from CGW13 to rewrite target ECU19 may be a variable value according to the specification of rewrite target ECU 19. CGW13 may determine the amount of data to be distributed to ECU19 to be rewritten, using the data transfer size of each ECU specified by the rewriting specification data, for example.

The CGW13 transmits a transfer request to the DCM12 and requests the DCM12 to transfer the divided file, but there are a first request method and a second request method as methods of requesting the DCM12 to transfer the divided file. The rewrite target ECU19 transmits a reception completion notification indicating that the reception of the write data is completed to the CGW13 when the reception of the write data is completed, and transmits a write completion notification indicating that the writing of the write data is completed to the CGW13 when the writing of the write data is completed.

The first distribution method will be described with reference to fig. 93. When the CGW13 acquires a split file from the DCM12, the acquired split file is distributed as write data to the rewrite target ECU 19. When the rewrite target ECU19 completes reception of the write data, it transmits a reception completion notification to the CGW13 to start the write processing of the write data. Upon receiving the write data reception completion notification from the rewrite target ECU19, the CGW13 transmits a transfer request to the DCM12 and requests the DCM12 to transfer the next divided file. When the CGW13 acquires the next divided file from the DCM12, the acquired next divided file is distributed as write data to the rewrite target ECU 19.

In this way, in the first distribution method, the CGW13 acquires the next write data from the DCM12 and distributes the next write data to the ECU19 to be rewritten without waiting for completion of writing of the write data in the ECU19 to be rewritten. Therefore, in the first distribution method, if the rewrite target ECU19 does not complete the writing of the write data in the CGW13, the rewrite target ECU19 may not be able to receive the next write data even if the next divided file is acquired from the DCM12 and the next write data is distributed to the rewrite target ECU 19. However, if the rewrite target ECU19 completes writing of the write data, it is possible to quickly acquire the next divided file from the DCM12 and quickly distribute the next write data to the rewrite target ECU 19.

The second distribution method will be described with reference to fig. 94. When the CGW13 acquires a split file from the DCM12, the acquired split file is distributed as write data to the rewrite target ECU 19. When the rewrite target ECU19 completes reception of the write data, it transmits a reception completion notification to the CGW13 to start the write processing of the write data. When the writing is completed, the rewrite target ECU19 transmits a writing completion notification to the CGW 13. Upon receiving the write completion notification from the rewrite target ECU19, the CGW13 transmits a transfer request to the DCM12 and requests the DCM12 to transfer the next divided file. When the CGW13 acquires the next divided file from the DCM12, the acquired next divided file is distributed as write data to the rewrite target ECU 19.

In this way, in the second distribution method, the CGW13 acquires the next write data from the DCM12 and distributes the next write data to the ECU19 to be rewritten after waiting for completion of writing of the write data to the ECU19 to be rewritten. Therefore, in the second distribution method, in CGW13, it takes time until the next divided file is acquired from DCM12, and the divided files can be requested to be transferred to DCM12 in a state where the rewrite target ECU19 completes writing of the write data. Therefore, when the next divided file is acquired from the DCM12 and the next write data is distributed to the rewrite target ECU19, the next write data can be reliably distributed to the rewrite target ECU 19.

The CGW13 distributes the write data to the ECU19 to be rewritten by the SID34, 36, 37, and there are a first distribution method and a second distribution method as methods for distributing the write data to the ECU19 to be rewritten. In the first distribution scheme, as shown in fig. 95, CGW13 is divided into a predetermined data amount (for example, 1 kbyte) and distributed in accordance with the distributed write data. In the second distribution method, as shown in fig. 96, CGW13 is distributed uniformly without dividing write data to be distributed. The CGW13 selects either the first distribution method or the second distribution method from the SID34 first distributed to the rewrite target ECU 19. As shown in fig. 97, the CGW13 determines reception of write data by the rewrite target ECU19 by receiving ACK (SID74) for the SID37 which is distributed to the rewrite target ECU19 last. The ACK to SID37 corresponds to the reception completion notification of the write data described above with reference to fig. 93 and 94. That is, in the first distribution method, upon receiving ACK for SID37 distributed to the rewriting target ECU19, the CGW13 adds 1 to the address of the next write data, thereby acquiring the next write data from the DCM12 simultaneously with the distribution of the next write data to the rewriting target ECU 19.

Further, although addresses and files are associated with each other in the rewriting specification data for DCM, as a method of associating addresses and files, for example, a folder structure may be designed, and specification data may be stored in the folder 1, the file 1 may be stored in the folder 2, and the file 2 may be stored in the folder 3 for management, or management may be performed in order of file names. For example, in the unpacking shown in fig. 10, the folder 1 stores the rewriting specification data for DCM and the rewriting specification data for CGW, the folder 2 stores the identifier and the difference data for ECU (ID1), and the folder 3 stores and manages the identifier and the difference data for ECU (ID 2).

When the distribution of the write data to the rewrite target ECU19 is interrupted due to some reason such as an interruption of communication, the CGW13 acquires information that can specify an address at which the write of the write data is completed from the rewrite target ECU19, and requests the DCM12 to transfer the split file including the write data from the time at which the write is not completed. Alternatively, CGW13 may also request the DCM12 for the transmission of a split file containing write data from the beginning.

As described above, the CGW13 performs the file transfer control process to determine the file including the write data written in the rewrite target ECU19 as the transfer target file, determines the address and the first data size for acquiring the transfer target file, requests the DCM12 to transfer the divided file, and transfers the divided file from the DCM12, thereby distributing the write data to the rewrite target ECU. The transfer of the write data from the DCM12 to the CGW13 and the distribution of the write data from the CGW13 to the rewrite target ECU19 can be performed efficiently.

(11) Distribution control processing of write data

Distribution control processing of write data is explained with reference to fig. 98 to 108. The vehicle program rewriting system 1 performs distribution control processing of write data in the CGW 13. Since CGW13 transmits the write data to ECU19 via the bus in the vehicle, the distribution control process of the write data is performed so that the bus load during the distribution of the write data does not become excessively high.

As shown in fig. 98, assume a case where the + B electric power source system ECU, the ACC system ECU, and the IG system ECU are connected to the same bus. In this case, in the + B electric power source state, only the + B electric power source system ECU is started, and the ACC system ECU and the IG system ECU are stopped, so vehicle control data of only the + B electric power source system ECU is transmitted to the bus. When in the ACC electric power source state, the + B electric power source system ECU and the ACC system ECU are started, and the IG system ECU is stopped, so vehicle control data of the + B electric power source system ECU and the ACC system ECU are transmitted to the bus. When in the IG electric power source state, the + B electric power source system ECU, the ACC system ECU, and the IG system ECU are activated, and therefore vehicle control data of the + B electric power source system ECU, the ACC system ECU, and the IG system ECU are transmitted to the bus. That is, the amount of transmission of the vehicle control data is the IG power supply state, the ACC power supply state, and the + B power supply state in a large order.

As shown in fig. 99, CGW13 includes a first correspondence relation determination unit 83a, a second correspondence relation determination unit 83b, a transfer allowance determination unit 83c, a distribution frequency determination unit 83d, a bus load measurement unit 83e, and a distribution control unit 83f in the distribution control unit 83 of write data.

The first correspondence relation determining unit 83a determines a first correspondence relation indicating a relation between the power supply state and the bus transfer allowance amount based on the analysis result of the rewriting specification data, and determines the bus load table shown in fig. 100. The transmission permission amount is a value of a transmission load with which data can be transmitted and received without causing data collision or delay. The bus load table is a table showing a correspondence relationship between the power supply state and the bus transfer allowance, and is defined for each bus. The transfer allowance is a sum of transfer amounts of the vehicle control data and the write data that can be transferred with respect to the maximum transfer allowance.

In the example of fig. 100, the transfer allowance amount of the first bus is "80%" with respect to the maximum transfer allowance amount, and therefore, "50%" with respect to the maximum transfer allowance amount is allowed as the transfer allowance amount of the vehicle control data and "30%" with respect to the maximum transfer allowance amount is allowed as the transfer allowance amount of the write data in the IG power source state by the CGW 13. In addition, with respect to the first bus, "30%" with respect to the maximum allowable amount of transfer is allowed as the allowable amount of transfer of the vehicle control data and "50%" with respect to the maximum allowable amount of transfer is allowed as the allowable amount of transfer of the write data in the ACC power state by the CGW 13. In addition, regarding the first bus, "20%" with respect to the maximum allowable amount of transfer is allowed as the allowable amount of transfer of the vehicle control data and "60%" with respect to the maximum allowable amount of transfer is allowed as the allowable amount of transfer of the write data in the + B power state by the CGW 13. As shown in fig. 100, the second bus and the third bus are also defined similarly.

The second correspondence relation determining unit 83b determines a second correspondence relation indicating a relation between the bus to which the rewrite target ECU19 belongs and the power supply system based on the analysis result of the rewrite specification data, and determines the rewrite target ECU belonging table shown in fig. 101. The rewrite target ECU belongs table is a table showing the bus and power supply system to which the rewrite target ECU19 belongs.

In the example of fig. 101, the CGW13 identifies the first rewriting ECU19 as a + B electric power source system ECU, because the first rewriting ECU19 is connected to the first bus and activated in any of the + B electric power source state, the ACC electric power source state, and the IG electric power source state. The CGW13 identifies the second rewrite target ECU19 as an ACC system ECU because the second rewrite target ECU19 is connected to the second bus and is stopped in the + B power supply state, but is activated in the ACC power supply state or IG power supply state. The CGW13 identifies the third rewrite-target ECU19 as an IG-based ECU because the third rewrite-target ECU19 is connected to the third bus and is stopped in the + B power supply state and the ACC power supply state, but is activated in the IG power supply state.

CGW13 uses the data of "connection bus" and "connection power" in the rewriting specification data shown in fig. 8 to determine which bus and which power system the rewriting ECU19 is connected to. In addition, if such information can be specified, it is not necessarily required to be stored in the form of a table.

The transfer permission amount determination unit 83c determines the transfer permission amount of the bus to which the rewriting target ECU19 belongs, that is, the transfer permission amount corresponding to the power state of the vehicle when the program is updated, based on the determination result of the first correspondence relationship and the determination result of the second correspondence relationship. Specifically, the transfer allowance determination unit 83c determines the bus to which the ECU19 belongs by using the table to which the ECU to be rewritten belongs, which is the second correspondence relationship, and determines the transfer allowance for each power source state for the determined bus by using the bus load table, which is the first correspondence relationship.

The distribution frequency determining unit 83d determines the distribution frequency of the write data corresponding to the power supply state at the time of mounting, using the correspondence relationship between the power supply state and the distribution frequency of the write data determined in advance. Specifically, the distribution frequency determining unit 83d determines the transfer allowance allocated for distributing the write data among the transfer allowances determined by the transfer allowance determining unit 83c, using the bus load table, and determines the distribution frequency of the write data. The distribution frequency determining unit 83d determines the distribution frequency of the write data by, for example, determining that the bus to which the rewriting ECU19 belongs is the first bus, determining that the power supply state at the time of installation is the IG power supply state, determining the transfer allowance as "80%", and determining the transfer allowance allocated for distributing the write data among these as "30%". The transfer allowance allocated for distributing the write data corresponds to the transfer restriction information.

The bus load measuring unit 83e measures the bus load of the bus to which the rewrite target ECU19 belongs. The bus load measuring unit 83e measures the bus load by, for example, counting the number of frames or bits received per unit time. The distribution control unit 83f controls the distribution of the write data according to the distribution frequency determined by the distribution frequency determination unit 83 d.

Next, the operation of the write data distribution control unit 83 in CGW13 will be described with reference to fig. 102 to 108. CGW13 executes a write data distribution control program and performs write data distribution control processing.

Upon receiving the unpacking completion notification signal from the DCM12, the CGW13 starts the distribution control process of the write data. The CGW13 acquires rewriting specification data for CGW from the DCM12 (S1101), and specifies a bus load table and a table to which the ECU to be rewritten belongs based on the rewriting specification data for CGW (S1102). The CGW13 determines the bus to which the rewrite target ECU19 belongs from the table to which the rewrite target ECU belongs (S1103). CGW13 specifies the transfer allowance amount corresponding to the bus to which ECU19 belongs, that is, the power state of the vehicle at the time of update, from the bus load table. CGW13 then determines the distribution frequency of the write data in consideration of the determined transfer allowance (S1104, corresponding to a distribution frequency determining step). For example, when the first rewrite target ECU19, i.e., the ECU (ID1), distributes the write data while the vehicle is traveling, the CGW13 refers to the transmission allowable amount of the first bus in the IG power state. In the example of fig. 100, the transfer allowance amount of the first bus in the IG power source state is "80%", in which transfer of "50%" is allowed in the vehicle control data, and transfer of "30%" is allowed in the write data. The transmission allowance is a value indicating an instance, and the numerical value is set within an allowable range according to the applicable communication standard.

Since the specification of CAN at 500 kbps is about 1 frame 250 μ s, if 4 breaks occur within 1 second, four frames are generated, and the bus load is 100%. CGW13 determines the distribution frequency of write data by determining a break that occurs in the bus. CGW13 starts measurement of the number of frames received per unit time, starts measurement of the bus load (S1105), determines whether or not the measured bus load exceeds the transfer allowance (S1106), and sets the delivery interval. The distribution interval is a time interval between when the CGW13 distributes the write data to the rewrite target ECU19 and when the rewrite target ECU19 receives a write completion notification (ACK) until the next write data is transmitted to the rewrite target ECU 19.

When the CGW13 determines that the measured bus load does not exceed the transfer allowance (S1106: no), the distribution interval of the write data is set to the preset shortest interval, and as shown in fig. 103, the distribution of the write data to the rewrite target ECU19 is started (S1107, corresponding to a distribution control step). That is, CGW13 sets the distribution interval of 1 frame on the CAN to the preset shortest interval, and starts distributing the write data to rewrite target ECU 19. In addition, 1 frame on CAN contains write data with a data amount of 8 bytes. In addition, 1 frame on the CAN FD (CAN with Flexible Data-Rate) contains write Data with a Data amount of 64 bytes.

On the other hand, when CGW13 determines that the measured bus load exceeds the transfer allowance (S1106: yes), the bus load is calculated at an interval not exceeding the transfer allowance (S1108), the distribution interval of the write data is set to the calculated interval, and the distribution of the write data to ECU19 to be rewritten is started as shown in fig. 104 (S1109, corresponding to a distribution control step).

For example, in the IG power supply state, the CGW13 determines whether or not the bus load exceeds the transfer allowance amount, i.e., "80%", for the first bus, and if it determines that the bus load does not exceed the transfer allowance amount, sets the distribution interval T1 at which the transfer allowance amount of the write data is "30%". That is, as shown in the bus load table of fig. 100, CGW13 sets distribution interval T1 using "30%" which is the transfer allowance of write data in the first bus in the IG power state. CGW13 sets the distribution interval T1 to be the maximum transmission amount allowed. CGW13 may measure the bus load by converging the measurement target on the frame of the write data, and determine whether the bus load based on the write data exceeds the write data transfer allowable amount "30%". When CGW13 determines that the bus load exceeds the transfer allowance, it changes the bus load to a distribution interval T2 (> T1) in which the bus load does not exceed the transfer allowance, according to the amount by which the bus load exceeds the transfer allowance. In this way, after acquiring the write data from the DCM12, the CGW13 waits until the set distribution interval is reached, and then distributes the write data to the rewrite target ECU 19.

When the CGW13 starts to distribute the write data to the ECU19, it is determined whether or not the distribution of the write data to the ECU19 is completed, and it is continuously determined whether or not the measured bus load exceeds the transfer allowance (S1110, S1011). When the CGW13 determines that the measured bus load does not exceed the transfer allowance (S1111: no), it sets the distribution interval of the write data to the preset shortest interval and changes the distribution interval of the write data to the rewrite target ECU19 (S1112). On the other hand, when CGW13 determines that the measured bus load exceeds the transfer allowance (S1111: "yes"), it calculates an interval at which the bus load does not exceed the transfer allowance (S1113), sets the distribution interval of the write data to the calculated interval, and changes the distribution interval of the write data to rewrite target ECU19 (S1114).

When CGW13 determines that the distribution of the write data to ECU19 has been completed (S1110: yes), the measurement of the number of frames received per unit time is stopped, the measurement of the bus load is stopped (S1115), and the write data distribution control process is terminated. Here, when there are a plurality of the rewrite target ECUs 19, the CGW13 performs a distribution control process of write data for the installation to all the rewrite target ECUs 19.

As described above, CGW13 performs write data distribution control processing to determine the distribution frequency of write data to rewrite target ECU19 using a predetermined correspondence between the power supply state and the distribution frequency of write data, and controls the distribution of write data according to the distribution frequency. Data collision, delay, and the like can be suppressed when the device is mounted. In addition, distribution of write data can be made to coexist without hindering distribution of vehicle control data on the same bus.

In addition, CGW13 has been described above as an example of a configuration in which the bus load table is specified from the analysis result of the rewriting specification data, but may be a configuration in which the bus load table is stored in advance. In addition, CGW13 illustrates a configuration in which the table to which the ECU to be rewritten belongs is specified from the analysis result of the rewriting specification data, but a configuration in which the table to which the ECU to be rewritten belongs is stored in advance may be employed.

The distribution amount of the write data may be relatively small in the power supply state in which the vehicle is running, and may be relatively large in the power supply state in which the vehicle is stopped. That is, as shown in fig. 105, when the IG power source is turned on while the vehicle is traveling, CGW13 transmits the CAN frame via the IG-system ECU, ACC system ECU, and + B power source ECU, and the amount of transmission of application data such as vehicle control and diagnosis is relatively large, and therefore the amount of distribution of write data is relatively small. As shown in fig. 106, when the IG power supply is off during parking, CGW13 transmits the CAN frame only by the + B power supply system ECU, so that the amount of transmission of application data such as vehicle control and diagnosis is relatively small, and the amount of distribution of write data is relatively large. That is, CGW13 adjusts the distribution amount of write data in a free capacity that does not hinder the transfer of application data such as vehicle control and diagnosis.

In addition, as shown in fig. 107, in the CGW13, when an event frame is transmitted from the rewrite target ECU19, the distribution amount of write data may be relatively small because the frequency of interruption becomes high by receiving the event frame and the bus load becomes high, and when an event frame is not transmitted from the rewrite target ECU19, the distribution amount of write data may be relatively large.

As shown in fig. 108, in the vehicle system, when it is determined that CGW13 is distributing write data, the bus load may be reduced by increasing the transmission interval of application data such as vehicle control and diagnosis to the maximum allowable interval. In CGW13, the bus load can be reduced by extending the transmission interval of the application data by the vehicle system, and the distribution amount of the write data can be made relatively large.

The bus load table embedded in the rewriting specification data is commonly set, for example, uniformly regardless of the model, grade, and the like of the vehicle manufacturer. This is because the bus loads are greatly different when the equipment of the ECU greatly differs depending on, for example, the vehicle type, the class, and the like, and when an optimal bus load table is set independently in accordance with the vehicle type, the class, and the like, a troublesome work such as man-hour is required for the verification, and such a troublesome work is avoided.

As in the case of mounting the vehicle while the vehicle is traveling as described above, the distribution control process of the write data is performed also in the case of mounting the vehicle while the vehicle is stopped. In this case, if the rewrite target ECU19 is the + B power supply system ECU, the update may be performed in the + B power supply state, and therefore, the transmission permission amount of the + B power supply state in the bus load table is referred to. On the other hand, when the rewrite target ECU19 is an IG system ECU, it is installed in the IG electric power source state, and therefore the transmission allowable amount of the IG electric power source state in the bus load table is referred to. Here, for example, when the rewrite target ECU19 is an ACC system ECU, the ECU may be mounted in the IG electric power source state. In this case, the transfer allowance of the IG power source state in the bus load table is referred to. Further, although the configuration of storing the bus load table and the table to which the ECU to be rewritten belongs has been described, any table may be stored as long as the distribution frequency of the write data for each power supply state can be determined.

(12) Indication handling of activation requests

The processing of the instruction of the activation request will be described with reference to fig. 109 to 111. The vehicle program rewriting system 1 performs an instruction process of an activation request in the CGW 13. CGW13 makes an activation request to validate the rewritten program for a plurality of rewrite target ECUs 19 for which rewriting of the application program has been completed. In the present embodiment, CGW13 obtains the state of the group of ECU19 to be rewritten by analyzing the rewriting specification data for CGW. CGW13 makes an activation request only during parking and does not make an activation request during vehicle running.

As shown in fig. 109, CGW13 includes a rewrite target specification unit 84a, a rewrite completion determination unit 84b, an activation executable determination unit 84c, and an activation request instruction unit 84d in the activation request instruction unit 84. The rewriting target specification unit 84a specifies the plurality of rewriting target ECUs 19 for the plurality of rewriting target ECUs 19 for cooperative control. When the rewrite target specification unit 84a specifies the plurality of rewrite target ECUs 19, the rewrite completion determination unit 84b determines whether or not the rewrite of the program has been completed in all of the specified plurality of rewrite target ECUs 19.

When the rewrite completion determining unit 84b determines that rewriting of the program has been completed in all of the plurality of rewrite target ECUs 19, the activation executable determining unit 84c determines whether or not activation can be executed. The activation executable determination section 84c determines that activation can be executed when activation approval by the user is performed and when the vehicle is in a stopped state.

When the activation executable determination unit 84c determines that activation is executable, the activation request instruction unit 84d instructs an activation request. Specifically, the activation request instructing unit 84d instructs a reset request after instructing a switching request to a new surface, and instructs an activation request by monitoring a session transition timeout or monitoring an internal reset of the rewrite target ECU 19. In the dual-sided memory ECU or the single-sided suspended memory ECU, the application is activated by starting on a new side (non-operating side) on which the application is written. On the other hand, in the single-sided individual memory ECU, the application program is activated by restart. The rewrite target ECU19 may be configured to perform a reset by itself, independently of the activation request, after the switching request is instructed to the new surface.

Next, the operation of the activation request instructing unit in CGW13 will be described with reference to fig. 110 and 111. CGW13 executes an activation request instruction program and performs activation request instruction processing.

Upon starting the process of instructing the activation request, CGW13 identifies a plurality of rewriteable object ECUs 19(S1201, corresponding to a rewriteable object identifying step). Specifically, CGW13 refers to the ECU (id) described in the rewriting specification data, thereby specifying the ECU19 to be rewritten. CGW13 determines whether or not rewriting of the application is completed in all of the plurality of specified rewriting target ECUs 19 (S1202, corresponding to a rewriting completion determination step). For example, the CGW13 sequentially mounts the ECUs 19 to be rewritten in the order of the ECUs (ids) described in the rewriting specification data, and determines that writing is completed in all the ECUs 19 to be rewritten when the mounting to the ECU (id) described last is completed.

When CGW13 determines that rewriting of the application has been completed in all of the identified plurality of rewriting target ECUs 19 (S1202: yes), it determines whether activation is executable or not (S1203, corresponding to an activation executable determination step). Specifically, CGW13 determines whether or not user approval for updating has been obtained before, whether or not the vehicle is in a stopped state, or the like, and if these conditions are satisfied, determines that activation is executable. The user consent may be consent to the update process as a whole, or consent to activation. When the CGW13 determines that activation can be executed (S1203: yes), it then simultaneously instructs activation requests to the plurality of rewrite target ECUs 19 (corresponding to the activation request instructing step). Here, the ECU (ID1), the ECU (ID2), and the ECU (ID3) are assumed to be the same group of the rewrite target ECU 19.

When the CGW13 determines that activation can be performed for the ECU (ID1), the ECU (ID2), and the ECU (ID3), the instruction processing of the activation request is started. When the CGW13 starts the activation request instructing process, it instructs the rewrite target ECU19 to request switching to a new plane (S1204). The CGW13 requests the electric power source management ECU20 to switch the IG electric power source from off to on (S1205). Although the vehicle is parked and the IG switch 42 is off, the CGW13 switches the IG power supply from off to on for activation. When CGW13 is activated after installation, the IG power supply is turned on, and therefore S1205 is not performed and an activation request (wake-up request) is made to ECU19 to be rewritten in the sleep state.

The CGW13 transmits a software reset request to the rewrite target ECU19, and instructs the rewrite target ECU19 to reset the software (S1206). If the specification corresponding to the software reset request is adopted, the rewrite target ECU19 resets the software and restarts the software upon receiving the software reset request from the CGW13, thereby activating the application. When the ECU19 to be rewritten is a single-sided individual memory ECU, the ECU19 to be rewritten switches from the old application to the new application by restarting the new application. When the ECU19 to be rewritten is a single-sided hook memory ECU or a dual-sided memory ECU, the ECU19 to be rewritten updates the operating plane information (a-plane or B-plane) stored in the flash memory and switches the plane in which the new application is written to the operating plane, thereby switching from the old application to the new application.

The CGW13 requests the electric power source management ECU20 to switch the IG electric power source from on to off and from off to on, instructs the rewrite target ECU19 to request a reset of the electric power source, and instructs the rewrite target ECU19 to restart the electric power source (S1207). Even if the specification not corresponding to the reset request of the software is adopted, the rewrite target ECU19 resets itself to restart it and activates the application when the IG power supply is switched from on to off and from off to on. In this case as well, when the ECU19 to be rewritten is a single-sided individual memory ECU, the ECU19 to be rewritten switches from the old application to the new application by restarting with the new application. When the ECU19 to be rewritten is a single-sided suspension memory ECU or a dual-sided memory ECU, the ECU19 to be rewritten updates the operating plane information (a-plane or B-plane) stored in the flash memory and switches the plane in which the new application is written to the operating plane, thereby switching from the old application to the new application. In addition, the CGW13 monitors the session transition timeout (S1208), and monitors the internal reset of the rewriting target ECU19 (S1209).

That is, if the specification not corresponding to the software reset request is adopted for the rewrite target ECU19, the CGW13 cannot instruct activation even if the software reset request is transmitted to the rewrite target ECU19, and therefore, the rewrite target ECU19 of the specification not corresponding to the software reset request is activated by instructing the rewrite target ECU19 to instruct the power reset request. For example, in an IG system ECU such as an engine ECU, since it is configured to be reset constantly by turning on and off the power supply, it is often not in response to a software reset request. In view of rewriting the ECU19, the activation (start-up in a new program) is performed in response to any one of a software reset request from the CGW13, a power supply reset request from the CGW13, a session transfer timeout, and an internal reset.

When a software reset request is instructed from the CGW13, the rewrite target ECU19 that corresponds to the software reset request forcibly resets itself and activates it. When a reset request of the power supply is instructed from the CGW13, the ECU19 to be rewritten of the ACC system or IG system ECU does not forcibly supply the power supply, and is reset and activated at the next power supply. Unlike the ECU19 of the ACC system or IG system ECU, the ECU19 to be rewritten of the + B electric power source system ECU always supplies electric power, and is activated by a session transition timeout or an internal reset. The method of activation of the ECU19 to be rewritten is specified by rewriting specification data.

When notified from all of the rewrite target ECUs 19 that the new application is normally started, the CGW13 transmits a switch completion notification to the DCM12 (S1210). The DCM12 notifies the center apparatus 3 that activation of the update program is completed. The CGW13 requests the electric power source management ECU20 to switch the IG electric power source from on to off, and completes the activation synchronization instruction processing. When the IG power supply is switched from off to on by a user operation, the CGW13 transmits the program version, the start-up status, and the like of each ECU to the DCM 12. The DCM12 notifies the center device 3 of information of each ECU19 received from the CGW 13. Here, when DCM12 notifies center device 3 of completion of activation, ECU configuration information including the program version and surface information of each ECU may be transmitted to center device 3. Fig. 111 shows a case where the ECU19 to be rewritten is a dual-sided memory ECU or a single-sided suspend memory ECU.

As described above, the CGW13 prevents the plurality of rewrite target ECUs 19 that have completed rewriting the application from switching from the old program to the new program at their own timings by performing the process of instructing the activation request, and appropriately makes the timings of switching from the old program to the new program coincide with each other in the plurality of rewrite target ECUs 19. That is, the program versions of the plurality of rewriting ECU19 cooperating with each other are not matched, and thus, a problem in the cooperation process is avoided.

(13) Active execution control processing

The activated execution control processing is explained with reference to fig. 112 to 114. The active execution control process is a process performed by the rewrite target ECU19 to which the activation request is instructed from the CGW13 as the CGW13 performs the above-described (12) activation request instructing process. The vehicle program rewriting system 1 performs an execution control process of activation in the rewriting target ECU 19. Here, the rewrite target ECU19 has a plurality of data storage surfaces such as a single-sided pause memory and a double-sided memory. The rewrite target ECU19 has a first data storage surface and a second data storage surface, and is in a state where the mounting of the rewrite data is completed on the non-operation surface (new surface).

As shown in fig. 112, the ECU19 includes an operation plane information updating unit 107a, an execution condition determining unit 107b, an execution control unit 107c, and a notification unit 107d in the active execution control unit 107. When an activation request is instructed from CGW13, the operating plane information update unit 107a updates the flash memory start-up plane determination information (operating plane information) for the next restart. For example, when the current a plane is started and a new program is written on the B plane, the operation plane information update unit 107a updates the operation plane information from the a plane to the B plane.

As the active execution conditions, the execution condition determination unit 107b determines whether or not a software reset request is instructed from the CGW13, whether or not a power supply reset request is instructed from the CGW13 to the power supply management ECU20, and whether or not the communication interruption with the CGW13 has continued for a predetermined time. When any one of the conditions is satisfied, the execution condition determination unit 107b determines that the activated execution condition is satisfied. Instead of the instruction from CGW13, power supply detection circuit 36 may detect whether a reset request of the power supply is instructed. When the execution condition determination unit 107b determines that the activated execution condition is satisfied, the execution control unit 107c performs new surface switching (activation) for switching the start surface from the old surface (the currently operated surface) to the new surface (the currently non-operated surface) based on the operation surface information. The notification unit 107d notifies CGW13 of notification information such as operation plane information and version information.

Next, the operation of the execution control unit 107 for activating the rewrite target ECU19 will be described with reference to fig. 113 and 114. The rewrite target ECU19 executes the activated execution control program and performs the activated execution control process.

(13-1) overwrite Process

When the rewrite processing is started, the rewrite target ECU19 performs processing before memory erasure such as product number reading and authentication as the rewrite processing (S1301). The rewrite target ECU19 determines whether or not rewrite surface information has been received from the center apparatus 3 (S1302). The rewrite target ECU19 determines whether rewrite face information is received, for example, based on whether rewrite face information described in rewrite specification data included in the distribution packet is acquired from the CGW 13. When the rewrite target ECU19 determines that the rewrite surface information has been received from the center device 3 (S1302: yes), it checks the rewrite surface information against the rewrite surface information (operating surface information) managed by itself and determines whether or not both of the rewrite surface information and the operating surface information match (S1303). Here, the rewriting plane information is described in, for example, rewriting specification data transmitted from the center device 3. For example, when the managed rewriting surface information is the a surface and the non-operating surface is the B surface, it is determined that the rewriting surface information described in the rewriting specification data indicates the non-operating surface (B surface), and it is determined that the rewriting surface information described in the specification data indicates the operating surface (a surface).

When the ECU19 to be rewritten determines that both match (S1303: yes), it performs memory erase, write of write data, and verification as rewriting processing (S1304), and ends the rewriting processing. The verification is, for example, an integrity verification of the data written to the flash memory. When the rewriting ECU19 determines that the two do not match each other (S1303: NO), it transmits a negative response to the CGW13 (S1305) and ends the rewriting process.

(13-2) activated execution control processing

When the execution control processing to be activated is started, the rewrite target ECU19 determines whether or not the rewriting of the application program onto the rewrite surface is completed, with the non-operating surface as the rewrite surface (S1311). When the rewrite target ECU19 determines that rewriting of the application program onto the rewrite surface is completed (S1311: yes), it verifies the integrity of the application program written in the flash memory and determines whether the verification of the rewritten data is positive (S1312). When the rewrite target ECU19 determines that the rewritten data is verified to be positive (S1312: "yes"), it sets the new surface rewrite completion flag to "OK" and stores it (S1313).

Then, the rewrite target ECU19 determines whether an activation request is instructed from the CGW13 (S1314). When the rewrite target ECU19 determines that the activation request is instructed (S1314: "yes"), it determines whether or not the rewrite completion flag for the new surface is "OK" (S1315), and when the rewrite completion flag for the new surface is determined to be "OK" (S1315: "yes"), it updates the operating surface information (S1316, corresponding to an operating surface information updating step). That is, for example, when the rewriting target ECU19 completes rewriting the application program onto the rewriting surface by using the B surface as the rewriting surface when the operating surface is the a surface and the non-operating surface is the B surface, the operating surface information indicating that the operating surface is the a surface and the non-operating surface is the B surface is updated to the operating surface information indicating that the operating surface is the B surface and the non-operating surface is the a surface.

When the rewriting ECU19 is updated to the operation plane information, it determines whether or not a software reset request is received from the CGW13, whether or not a power supply reset request is instructed from the CGW13 to the power supply management ECU20, whether or not communication interruption with the CGW13 continues for a predetermined time after the software reset request is instructed, and whether or not the activated execution condition is satisfied (S1317, corresponding to an execution condition determination step). Here, when any of these active execution conditions is satisfied, the rewrite target ECU19 restarts or the ECU determines the restart conditions.

The rewrite target ECU19 determines that the execution condition for activation is satisfied when any one of a software reset request is instructed from the CGW13, a power supply reset request is instructed from the CGW13 to the power supply management ECU20, and a predetermined time elapses after the software reset request is instructed (S1317: yes), and executes restart (reset). The rewrite target ECU19 starts the new surface (B surface) as the start surface based on the updated operating surface information by executing restart (S1318, corresponding to a start control step), and ends the active execution control process. That is, the rewrite target ECU19 is restarted and then started on the B-side on which the application is installed.

If the rewrite-target ECU19 determines that rewriting of the application program onto a new surface has not been completed (S1311: no) or if verification of the rewritten data is no (S1312: no), it determines whether an activation request has been instructed (S1319), and if it determines that an activation request has been instructed (S1319: yes), it transmits a negative response to the CGW13 (S1320), and the process returns to step S1311. In addition, when it is determined that the data after rewriting is verified to be no, the rewrite target ECU19 may end the active execution control process and perform a process such as rollback. When the ECU19 determines that the flag indicating completion of rewriting of the new surface is not "OK" (S1315: no), it transmits a negative response to the CGW13 (S1321) and returns to step S1311.

As described above, the rewrite target ECU19 performs the execution control processing of activation, and when an activation request is instructed from the CGW13, restarts the next plane and updates the operating plane information, and when the execution condition of activation is satisfied, performs new plane switching for switching the start plane from the old plane to the new plane based on the operating plane information after the restart. That is, even when the installation of the update program is completed, the rewrite target ECU19 is not started by the update program unless activation is instructed from the CGW 13. For example, even if the rewrite target ECU19 restarts when the IG switch 42 is turned on from off by the user, the rewrite target ECU19 starts on the same operation surface if activation is not instructed from the CGW 13. The CGW13 can simultaneously validate the update programs of the plurality of rewrite target ECUs 19 by simultaneously instructing the plurality of rewrite target ECUs 19 to activate and then restarting the ECUs by software reset, power reset, or session timeout. In the above description, the case where the data storage surface is 2 surfaces has been described, but the same applies to the case where the data storage surface is 3 surfaces or more.

In the above-described (12) CGW13 activation request instructing process, the CGW13 instructs the plurality of rewriting target ECUs 19 that have completed rewriting of the application to request activation, so that switching from the old program to the new program is performed at the unique timing by the plurality of rewriting target ECUs 19 that have completed rewriting of the application, and the timing of switching from the old program to the new program can be appropriately matched among the plurality of rewriting target ECUs 19.

(14) Group management processing of rewritten objects

Group management processing of the rewriting target is described with reference to fig. 115 to 118. The vehicle program rewriting system 1 performs group management processing of a rewriting target in the CGW 13. CGW13 instructs activation of an application program simultaneously to one or more rewrite target ECUs 19 belonging to the same group. CGW13 controls the activation of the cells in units of groups. Here, the description will be given assuming that the ECU (ID1) and the ECU (ID2) are the first group of the ECU19 to be rewritten, and the ECU (ID11), the ECU (ID12) and the ECU (ID13) are the second group of the ECU19 to be rewritten.

As shown in fig. 115, the CGW13 includes a group generation unit 85a and an instruction execution unit 85b in the group management unit 85 to be rewritten. The group generation unit 85a generates groups by grouping the rewriting ECUs 19 to be rewritten that perform version up simultaneously, based on the analysis result of the rewriting specification data for CGW. When a group is generated by the group generator 85a, the instruction execution unit 85b instructs to install the groups in a predetermined order, and when the installation is completed, instructs to activate the groups in units.

Next, the operation of group management unit 85 to be rewritten in CGW13 will be described with reference to fig. 116 to 118. CGW13 executes a group program for rewriting objects, and performs group management processing for rewriting objects. When the CGW13 starts the group management processing for the rewrite target, rewrite specification data for CGW is acquired from the DCM12 (S1401, corresponding to the rewrite specification data acquisition step), the acquired rewrite specification data is analyzed (S1402, corresponding to the rewrite specification data analysis step), and the group to which the rewrite target ECU19 belongs is determined. The CGW13 may determine which group the ECU belongs to by referring to information on the ECU whose specification data is rewritten, or may determine which ECU belongs to the group by referring to information on the group whose specification data is rewritten, for example. The CGW13 determines whether or not the rewriting of the ECU19 is the first rewriting target for one group (S1403), whether or not the rewriting target ECU19 belonging to the same group as the previous rewriting target ECU19 is rewritten (S1404), and whether or not the rewriting target ECU19 belonging to a different group from the previous rewriting target ECU19 is rewritten (S1405, corresponding to a group creation step).

When the CGW13 determines that the rewriting of the ECU19 is the first rewriting target (S1403: "yes") or that the rewriting of the ECU19 belonging to the same group as the previous rewriting target ECU19 is the target (S1404: "yes"), the rewriting target ECU19 is instructed to rewrite the application program, and the rewriting of the application program of the rewriting target ECU19 is performed (S1406). Then, CGW13 determines whether or not there is the next rewrite target ECU19 (S1407). If the CGW13 determines that there is the next-to-be-rewritten ECU19 in the same group (S1407: yes), the process returns to steps S1403 to S1405 described above, and steps S1403 to S1405 are repeated.

When the CGW13 determines that the rewrite of the rewrite target ECU19 belonging to a different group from the previous rewrite target ECU19 (S1405: yes), the process proceeds to an instruction processing for an activation request (S1408, corresponding to an instruction execution step).

When the CGW13 starts the process of instructing the activation request, it is determined whether or not there is the next rewrite target ECU19 (S1411). That is, CGW13 determines whether there is a group that has not completed installation. If the CGW13 determines that there is the next-rewriting-object ECU19 (S1411: yes), it instructs an activation request to the rewriting-object ECU19 belonging to the group for which rewriting has been completed (S1412). That is, when the rewrite target ECU19 belonging to the second group is not mounted, the CGW13 instructs activation of the rewrite target ECU (ID1) and the ECU (ID2) of the first group for which rewriting has been completed.

The CGW13 instructs the rewrite target ECU19 to request a software reset, and instructs the rewrite target ECU19 to simultaneously start the applications of the rewrite target ECU (ID1) and ECU (ID2) based on a restart of switching the power supply from on to off and from off to on via the power supply management ECU 20.

CGW13 determines the rewrite timing of next rewrite target ECU19 (S1413, S1314). That is, CGW13 determines the rewrite timing of rewrite target ECU19 belonging to the second group. When the CGW13 determines that the rewrite timing of the next rewrite target ECU19 is the next switch from the user to the user for boarding and alighting (S1413: "yes"), it switches the IG power supply from on to off (S1415), ends the instruction processing of the activation request, and returns to the group management processing of the rewrite target. For example, a time zone for allowing the execution of the update of the application is set in advance by the user, and when it is predicted that the installation of the rewriting target ECU19 belonging to the second group is not completed in this time zone, the CGW13 is installed in the next parking state. In this case, returning to the original parked state, CGW13 instructs electric power source management ECU20 to turn off the IG electric power source.

When the CGW13 determines that the rewriting timing of the next rewrite target ECU19 is currently alighting (stopped) (S1414: "yes"), it determines whether or not the remaining battery level of the vehicle battery 40 is equal to or higher than a threshold (S1417). Here, the threshold may be a preset value or a value obtained from rewriting specification data for CGW. When the CGW13 determines that the remaining battery level of the vehicle battery 40 is not equal to or greater than the threshold (no in S1416), it instructs the power supply management ECU20 to switch the IG power supply from on to off (S1415), ends the instruction processing of the activation request, and returns to the group management processing of the rewriting target. When the CGW13 determines that the remaining battery level of the vehicle battery 40 is equal to or greater than the threshold (S1416: yes), the IG power supply continues to be turned on (S1417), the activation request instruction processing is terminated, and the processing returns to the group management processing for rewriting. CGW13 rewrites the application program of ECU19 belonging to the second group as shown in fig. 116.

When the CGW13 determines that the next rewrite target ECU19 does not exist (S1411: no), it instructs an activation request to the rewrite target ECU19 belonging to the group in which rewriting has been completed (S1418), switches the IG power supply from on to off (S1419), ends the instruction processing of the activation request, and returns to the group management processing of the rewrite target. For example, when rewriting of the ECU (ID11), ECU (ID12), and ECU (ID13) to be rewritten belonging to the second group is completed, the ECU19 to be rewritten next, that is, the next group does not exist. In this case, the CGW13 instructs activation of the update program to the ECU (ID11), the ECU (ID12), and the ECU (ID12), and after completion of the activation, instructs the power supply management ECU20 to turn off the IG power supply.

As shown in fig. 154, in the case of rewriting the applications of the ECUs (ID1) to ECU (ID2) and ECU (ID11) to ECU (ID13), if the ECUs (ID1) and ECU (ID2) are in a cooperative control relationship and the ECUs (ID11), ECU (ID12) and ECU (ID13) are in a cooperative control relationship, in the distribution packet, the ECUs (ID1) and ECU (ID2) belong to the rewrite target ECU19 as the first group and the ECUs (ID11), ECU (ID12) and ECU (ID13) belong to the rewrite target ECU19 as the second group. When the CGW13 completes rewriting the application program in the ECU (ID1) and the ECU (ID2) belonging to the first group, the ECU (ID2) instructs the ECU (ID1) to request activation. When all of the applications are rewritten in the ECU (ID11), the ECU (ID12), and the ECU (ID13) belonging to the second group, the CGW13 instructs the ECU (ID11), the ECU (ID12), and the ECU (ID13) to request activation. Further, the single-sided individual memory, i.e., the rewrite target ECU19 is instructed to restart, and becomes an activation instruction.

As described above, the CGW13 instructs an activation request on a group-by-group basis through the group management process of the rewrite target ECU19 that performs the activation request. Version-up of a plurality of ECUs in a cooperative control relationship can be performed simultaneously. That is, it is possible to avoid the occurrence of a problem in the cooperative control process due to the fact that the versions of the application programs of the plurality of rewriting target ECUs 19 that are in the relationship of the cooperative control do not match. CGW13 is mounted in a predetermined order in units of the group. That is, CGW13 is controlled to perform slave-to-slave activation in group units.

In the present embodiment, the rewrite target ECU19 belonging to the first group is activated after the completion of the mounting of the rewrite target ECU19 belonging to the first group, and the rewrite target ECU19 belonging to the second group is activated after the completion of the mounting of the rewrite target ECU19 belonging to the second group. However, the activation of the rewrite target ECU19 belonging to the first group and the activation of the rewrite target ECU19 belonging to the second group may be continued. That is, after the completion of the mounting of the rewrite target ECU19 belonging to the first group and the mounting of the rewrite target ECU19 belonging to the second group, the activation of the rewrite target ECU19 belonging to the first group and the activation of the rewrite target ECU19 belonging to the second group may be performed. In this case, the activation of the rewrite target ECU19 belonging to the first group and the second group may be performed simultaneously.

When the rewrite target ECU19 includes the single-sided individual memory ECU, an instruction to attach the single-sided individual memory ECU may be the last in the group. When mounting is instructed to the rewrite target ECU19 which is in a cooperative operation relationship, the mounting may be instructed to the rewrite target ECU19 which operates as the data transmission side, and then the mounting may be instructed to the rewrite target ECU which operates as the data reception side.

CGW13 refers to the memory type of the rewriting specification data, and determines the mounting order according to the memory type of ECU19 to be rewritten. Such as a double-sided memory, a single-sided suspend memory, a single-sided single memory, in that order. The CGW13 stores information of the ECU19 that is in the cooperative operation relationship, in advance, on either the data transmission side or the data reception side, and determines the mounting order of the rewrite target ECU19 based on the information.

In addition, when there are a plurality of groups, the order of installation may be determined based on, for example, the degree of urgency, the degree of safety, the function, the time, and the like. The urgency level is an index indicating whether or not immediate installation is required, and is high when the possibility of a human disaster, an accident, or the like is relatively high when the device is left without installation, and is low when the possibility of a human disaster, an accident, or the like is relatively low when the device is not left without installation, and a group with a high urgency level is installed with priority. The security level is an index based on the restriction of the type of microcomputer at the time of mounting, and is mounted in the order of less restriction, that is, in the order of the double-sided memory, the single-sided suspend memory, and the single-sided individual memory. The function is an index of convenience for the user, and a group having high convenience for the user is preferentially installed. The time is an index of time required for mounting, and a group requiring a shorter time for mounting is preferentially mounted.

In addition, when the CGW13 instructs the first and second

rewrite target ECUs

19 and 19 belonging to the same group to install, when the first rewrite target ECU19 has successfully installed and the second rewrite target ECU19 has failed to install, it instructs the second rewrite target ECU19 to rollback and the first rewrite target ECU19 to rollback.

In addition, the CGW13 instructs the rewrite target ECU19 belonging to the second group to mount the rewrite target ECU19 belonging to the first group and the rewrite target ECU19 belonging to the second group when the first group has failed to mount the rewrite target ECU 19. For example, in fig. 116, when the rewriting target ECU19 belonging to the first group is rewritten to the second group in a state of failed installation (S1405; "yes"), the CGW13 skips the process of instructing the activation request for the first group (S1408), and proceeds to step S1407. Then, CGW13 returns to step S1403, starts the installation of the second group, and when the installation is completed, instructs the second group to perform an activation request (S1408). That is, CGW13 performs an update for the second group even if the update for the first group fails.

In addition, when 2 groups exist in one event (in one distribution packet), the approval operation for the user of the event and the approval operation for the user of the download are set to be one time, and the approval operation for the user of the installation and the approval operation for the user of the activation are performed twice for each group. That is, when the function changed by the update differs for each group, it is preferable to perform the approval operation for the installed user and the approval operation for the activated user for each function. Further, since it is assumed that the user feels troublesome to perform the approval operation for the installation user and the approval operation for the active user for each group, the approval operation for the installation user and the approval operation for the active user may be set once for the entire group.

While the configuration in which the group to which the ECU19 to be rewritten belongs is determined using the rewriting specification data is exemplified, the configuration in which the group to which the ECU19 to be rewritten belongs is stored in advance in the CGW13 may be adopted.

(15) Execution control processing of rollback

The execution control processing of rollback will be described with reference to fig. 119 to 130. The vehicle program rewriting system 1 performs the execution control processing of rollback in the CGW 13. The rollback refers to writing or write-back for restoring the memory of the ECU19 to be rewritten to a predetermined state, such as an original version, when rewriting of the application is interrupted, and returns the state of the ECU19 to be rewritten to a state before writing of the write data is started, as viewed from the user.

As shown in fig. 155, CGW13 includes a cancel request determining unit 86a, a rollback method determining unit 86b, and a rollback executing unit 86c in the rollback execution control unit 86. The cancel request determination unit 86a determines whether or not a cancel request for rewriting has occurred during rewriting of the application. For example, when the user operates the mobile terminal 6 to select cancellation of program rewriting, a cancellation request for program rewriting is notified from the center apparatus 3 that has acquired the information of the cancellation to the CGW13 via the DCM 12.

When an abnormality occurs in the system, if the center apparatus 3 is notified of the abnormality in the system, the center apparatus 3 notifies the CGW13 of a request to cancel rewriting of the program via the DCM 12. The system abnormality is, for example, a case where the writing to one rewriting target ECU19 is successful, but the writing to the other rewriting target ECU19 that performs cooperative control with the one rewriting target ECU19 is failed. When one of the plurality of rewriting ECU19 cooperatively controlled in this manner fails to write, it is determined that the system is abnormal, and a request to cancel the rewriting of the program is notified to the CGW13 from the center apparatus 3 via the DCM12 with respect to the rewriting ECU19 to which the writing has succeeded. That is, the user-based operation and the system-based abnormality generation are included in the important factors for generating the cancel request.

The rollback method determination unit 86b determines a rollback method for returning the state of the ECU19 to the state before the start of writing of the write data, based on the memory type of the flash memory mounted on the ECU19 to be rewritten and the data type of the write data of the new program or the old program. That is, the rollback method determination unit 86b determines which of the single-sided individual memory, the single-sided suspended memory, and the double-sided memory the flash memory is of as the memory type of the ECU19 to be rewritten, and the rollback method determination unit 86b determines which of the entire data or the difference data the write data is of as the data type of the write data.

The rollback method determination unit 86b determines the first rollback processing, the second rollback processing, or the third rollback processing based on these memory types and data types. When the rollback method is determined by the rollback method determining unit 86b, the rollback executing unit 86c instructs the rewrite target ECU19 to rollback corresponding to the rollback method, and causes the rewrite target ECU19 to operate as the old program. That is, the rollback execution unit 86c performs rollback to restore the operation state of the rewrite target ECU19 to the state before the start of rewriting of the application.

Next, the operation of the rollback execution control unit 86 of the CGW13 will be described with reference to fig. 120 to 130. CGW13 executes a rollback execution control program and performs rollback execution control processing. CGW13 performs a rollback method determination process and a cancel request determination process as the execution control process of rollback. Hereinafter, each process will be described.

(15-1) determination processing of rollback method

When the CGW13 starts the rollback method determination process, the rewriting specification data for CGW acquired from DCM12 is analyzed (S1501), the rollback method is determined from the analysis result (S1502), and the rollback method determination process is terminated. CGW13 acquires the memory type and the data type of the rollback program from the rewrite specification data shown in fig. 8, and determines the rollback method. If the same operation is performed regardless of whether the data type is a new program or an old program (rollback program), the rollback method may also be determined using the data type of the new program.

That is, if the flash memory of the ECU19 to be rewritten is a single-sided individual memory and the write data is all data, the CGW13 specifies a method (first rollback processing) of immediately interrupting distribution of all data and writing data of the old application in the rewrite area and rewriting the data to the old application in the ECU19 to be rewritten as a rollback method when the cancel request is generated. The old application (rewriting data for rollback) used in the single-sided individual memory is included in the delivery packet together with the update program, and the CGW13 delivers the old application to the rewrite target ECU19 by the same method as the new application.

If the flash memory of the ECU19 to be rewritten is a single-sided individual memory and the write data is differential data, the CGW13 specifies a method (second rollback processing) of continuing the distribution of the differential data, writing the differential data in the rewrite area and rewriting it into a new application in the ECU19 to be rewritten, then distributing the differential data of an old application, and writing the old data in the rewrite area and rewriting it into the old application in the ECU19 to be rewritten, as a rollback method when a cancel request is generated.

When the write data is the difference data, the rewrite target ECU19 restores the new application using the current application written in the flash memory and the difference data acquired from the CGW13, and writes the new application. In a state where a different application program is written to the flash memory, the write-target ECU19 cannot restore the new application program from the differential data. Therefore, the single-sided individual memory needs to be temporarily rewritten to a new application program. Here, for example, if the current application is version 1.0 and the new application is version 2.0, the rewrite program (rewrite data) is difference data for updating version 1.0 to version 2.0, and the rollback rewrite data is difference data for updating version 2.0 to version 1.0.

If the flash memory of the ECU19 to be rewritten is a single-sided suspended memory or a double-sided memory, the CGW13 specifies a method (third rollback processing) of continuing the distribution of the write data, and if the operating surface is the a surface and the non-operating surface is the B surface in the ECU19 to be rewritten, the CGW13 writes the write data in the non-operating surface, that is, the B surface, and installs a new application program, but suppresses the switching of the operating surface from the a surface to the B surface.

(15-2) cancellation request determination processing

When the CGW13 determines that rewriting of the application has been started in the rewrite target ECU19, it starts a cancel request determination process, determines whether rewriting of the application has been completed (S1511), and determines whether a cancel request has been generated (S1512). That is, CGW13 determines whether or not a cancel request has been generated by a user operation, system abnormality, or the like, as described above.

When the CGW13 determines that a cancel request has been made before the rewriting of the application is completed, that is, a cancel request has been made during installation (S1512: yes), the rewrite target ECU19 that is the rollback target is identified (S1513). Assuming that the rewrite target ECUs 19 belonging to the same group are the ECU (ID1), the ECU (ID2) and the ECU (ID3), the ECU (ID1) is a single-sided individual memory, and the ECU (ID2) and the ECU (ID3) are double-sided memories, the mounting to the ECU (ID1) is completed, and a cancel request is generated during the mounting to the ECU (ID 2). In this case, in S1413, the CGW13 determines whether or not all of the rewrite target ECUs 19 belonging to the first group need to be rolled back.

CGW13 specifies that the ECU (ID1) that has completely rewritten the application and the ECU (ID2) that has partially rewritten the application are rollback targets. CGW13 determines the memory type of the flash memory of the identified rollback target rewrite target ECU19, and determines which of the single-sided individual memory, the single-sided suspended memory, and the double-sided memory the flash memory is (S1514, S1515). If CGW13 determines that the flash memory is a single-sided individual memory (S1514: yes), it determines the type of data in the rollback program and determines whether the rollback write data is all data or differential data (S1516, S1517).

When CGW13 determines that the rollback write data is all data (S1516: yes), the process proceeds to the first rollback processing (S1518, corresponding to a rollback execution step). When CGW13 starts the first rollback processing, distribution of the write data, which is a new program, is immediately interrupted (S1531). The CGW13 acquires all data, i.e., rollback write data (old program) from the DCM12, and distributes the data to the rewrite target ECU 19. The rewrite-target ECU19 writes the data of the old application acquired from the CGW13 in the flash memory and rewrites the data into the old application (S1532), ends the first rollback processing, and returns to the cancellation request determination processing.

When the CGW13 determines that the rollback write data is differential data (S1517: yes), the process proceeds to the second rollback processing (S1519, corresponding to the rollback execution step). When the CGW13 starts the second rollback processing, the distribution of the write data as the new program continues (S1541), and the difference data is restored in the rewrite target ECU19, written in the flash memory, and rewritten into the new application (S1542). After the rewriting of the new application is completed, the CGW13 distributes the write data of the old application acquired from the DCM12 to the rewrite target ECU19 (S1543). The ECU19 to be rewritten restores the difference data as the data written by the old application, writes the data in the flash memory to rewrite the data into the old application (S1544), ends the second rollback processing, and returns the determination processing of the cancel request.

If the CGW13 determines that the ECU19 to be rewritten is the one-sided suspend memory ECU or the two-sided memory ECU (S1515: yes), the process proceeds to the third rollback processing (S1520, corresponding to the rollback execution step). In this case, CGW13 shifts to the third rollback process regardless of the type of rewriting data. When the CGW13 starts the third rollback process, the distribution of the write data is continued (S1551), and the rewrite target ECU19 writes the write data on the non-operating surface (B surface) and rewrites the write data into a new application (S1552). CGW13 suppresses switching from the old plane (operating plane: plane a) to the new plane (non-operating plane: plane B) (S1553), ends the third rollback processing, and returns the cancellation request determination processing. In addition to suppressing the switching of the operating plane, CGW13 may write back the non-operating plane written in version 2.0 to the state before rewriting to the new application (for example, version 1.0) as shown in fig. 126.

Upon returning to the cancel request determination process, CGW13 determines whether or not the rewrite target ECU19 has performed the rollback process for all the rollback targets (S1521). For example, in the case where the ECU19 to be rewritten is the ECU (ID1), the ECU (ID2), or the ECU (ID3), first, the CGW13 performs the first rollback processing or the second rollback processing on the ECU (ID1) in which the single-sided individual memory is mounted, in accordance with the type of the rollback data. Then, CGW13 performs a third rollback process on the ECU (ID2) of the double-sided memory to which the mounting is completed.

The CGW13 performs the first rollback processing or the second rollback processing on the ECU (ID1) that is the single-sided individual memory, depending on the type of the rewriting data. If CGW13 determines that rollback processing is not performed on all rewriting target ECU19 that are rollback targets (S1521: no), the process returns to step S1513, and the steps after step S1513 are repeated. When CGW13 determines that rollback processing is to be performed by ECU19 for all rollback targets (S1521: yes), the determination processing of the cancel request is terminated. CGW13 simultaneously instructs activation of the old application to the ECU (ID1), ECU (ID2), and ECU (ID3) belonging to the first group to which the rollback processing has been performed. The single-sided separate memory, i.e., the ECU (ID1), restarts, thereby switching to the old application. The ECU (ID2) and the ECU (ID3) serving as the dual-sided memory are not activated on the non-operation side (side B) on which the update program is written, but are activated on the same operation side (side a) as before. When the intention of the user changes and the program update is still executed, a new application is written in the ECU (ID1) and the ECU (ID3), but the new application is already installed in the non-operation surface in the ECU (ID2), and therefore the writing is omitted.

If CGW13 determines that rewriting of the application has been completed without generating a cancel request (S1511: yes), it determines whether activation has been completed (S1522), and determines whether a cancel request has been generated (S1523).

When the CGW13 determines that a cancel request has been made before the activation is completed, that is, that a cancel request has been made during the activation (S1523: yes), it determines whether or not the instruction for activation has reached the rewrite target ECU19, and it determines whether or not the switching of the operation plane has been completed (S1524).

If CGW13 determines that the active command has not reached rewrite target ECU19 and that the switching of the operation plane has not been completed (S1524: no), it performs a fourth rollback processing (S1525). As the fourth rollback processing, CGW13 does not switch the operation plane. Alternatively, CGW13 may return the non-operating surface to the state before rewriting to the new application without switching the operating surface. When the operating plane is not switched, CGW13 saves the plane written with version 1.0 as the operating plane and the plane written with version 2.0 as the non-operating plane, as shown in fig. 127. When the non-operating surface is returned to the state before being rewritten to the new application without switching the operating surface, CGW13 saves the surface written with version 1.0 as the operating surface and writes back the non-operating surface written with version 2.0 to the state before being rewritten to the new application (version 1.0) as shown in fig. 128.

When it is determined that the active command has reached rewriting ECU19 and it is determined that the operation surface has been switched (S1524: yes), CGW13 performs the fifth rollback processing. As shown in fig. 129, the completion of switching of the operating plane indicates a state in which the plane written with version 2.0 is switched from the non-operating plane to the operating plane and the plane written with version 1.0 is switched from the operating plane to the non-operating plane. As the fifth rollback process, CGW13 switches the active plane, or switches the active plane after the non-active plane is returned to the state before being rewritten to the new application. When switching the operating plane, CGW13 switches the plane to which version 2.0 is written from the operating plane to the non-operating plane and switches the plane to which version 1.0 is written from the non-operating plane to the operating plane, as shown in fig. 129. When the operating plane is switched after the non-operating plane is returned to the state before being rewritten to the new application, as shown in fig. 130, the CGW13 writes back the operating plane, which is the plane written with version 2.0, to the state before being rewritten to the new application (for example, version 1.0), switches the plane returned to the state before being rewritten to the new application from the operating plane to the non-operating plane, and switches the plane written with version 1.0 from the non-operating plane to the operating plane.

As described above, CGW13 performs the execution control processing of the rollback, and when a request to cancel rewriting occurs during rewriting of an application, returns the operating state of rewrite target ECU19 to the state before the rewriting of the application is started as viewed by the user. This makes it possible to return all of the rewrite target ECUs 19 belonging to the same group to the original program version at the same time. In addition, even when the difference data is used for the next program update, the write data can be restored correctly.

(16) Display control processing for rewriting progress status

The display control processing of the rewriting progress state will be described with reference to fig. 131 to 143. The vehicle program rewriting system 1 performs display control processing of rewriting progress status in the CGW 13. In order to communicate the progress of rewriting of the application to the user, the mobile terminal 6, which is the display terminal 5, and the in-vehicle display 7 display the progress. The progress of the display includes not only the case of updating the program but also the case of rolling back due to, for example, a cancel operation by the user, a failure in updating, or the like.

As shown in fig. 131, CGW13 includes a cancellation detector 87a, a write indicator 87b, and a report indicator 87c in the display controller 87 for rewriting the progress status. The cancellation detection unit 87a detects cancellation of rewriting of a program for rewriting the first write data stored in the ECU19 to the second write data acquired from the center device 3. The cancel detection unit 87a detects an abnormality such as a cancel operation by the user or a write failure to the rewrite target ECU 19. Since the rollback process is performed when the cancel detection unit 87a detects a predetermined abnormality, such as when the written data is not suitable for the rewrite target ECU19, when falsification is detected for the written data, or when a write error occurs in the rewrite target ECU19, the detection of such an abnormality is also regarded as the detection of the cancellation.

The write instruction unit 87b issues the second write data to the rewrite target ECU19, and instructs writing of the second write data. The report instruction unit 87c instructs reporting of the progress status related to rewriting of the application program. While the second write data is being distributed by the write instructing unit 87b, the report instructing unit 87c instructs the first mode to report the progress status regarding rewriting of the application program, and when the cancellation detecting unit 87a detects cancellation, instructs the second mode to report the progress status regarding rewriting of the application program. When the cancellation detection unit 87a detects cancellation during distribution of the second write data, the write instruction unit 87b continues distribution of the second write data.

The CGW13 specifies rewriting of the application program in the ECU19 to be rewritten, based on either one of the internal state of the ECU19 to be rewritten, the instruction from the center device 3, and the user operation. When the CGW13 specifies rewriting of an application, it is determined whether rewriting (installation) is performed in a normal state or rewriting (removal) is performed in a rollback state. When the CGW13 determines whether rewriting is to be performed in normal time or in rollback time based on any one of the internal state of the ECU19 for which rewriting is to be determined, the instruction from the center device 3, and the user operation, the progress of rewriting in normal time or in rollback time is calculated based on the determination result, and display of the calculated progress is instructed to the display terminal 5.

CGW13 instructs display terminal 5 to display the normal progress state or the rollback progress state, based on the rewrite determination result indicating whether the rewrite is normal or rollback. CGW13 instructs display to distinguish between progress display indicating the progress of rewriting during normal operation and progress display indicating the progress of rewriting during rollback operation. That is, CGW13 displays the progress status in a first mode in the case of normal rewrite, and displays the progress status in a second mode different from the first mode in the case of rewrite at rollback. As a method related to display at the time of displaying the progress status, CGW13 distinguishes characters, items, colors, numerical values, flickers, and the like on the display screen between normal time and rollback time, and distinguishes normal progress display from progress display at the time of rollback. In addition, CGW13 distinguishes between normal progress display and rollback progress display by distinguishing sound, vibration, and the like between normal time and rollback time as a method relating to display other than display when progress display is displayed.

Next, the operation of CGW13 will be described with reference to fig. 132 to 143. CGW13 executes a display control program for the rewriting progress status, and performs display control processing for the rewriting progress status.

Upon receiving a rewrite start signal indicating that rewriting of the program is started in the rewrite target ECU19 (e.g., when installation to the rewrite target ECU19 is started), the CGW13 starts display control processing of the progress status of rewriting. When the CGW13 starts the display control processing of the rewriting progress, the rewriting specification data for the CGW is analyzed, the memory type and the write data type of the flash memory of the ECU19 to be rewritten are determined, and the ECU19 to be rewritten in a normal state is determined (S1601). When the CGW13 specifies the memory type, the write data type, and the size of the update program of the flash memory of the ECU19 to be rewritten (S1602), it calculates the rewriting progress at the normal time based on the specified result and instructs display of the calculated rewriting progress at the normal time (S1603). The display terminal 5 displays the information in a rewriting display mode in a normal state in accordance with an instruction from CGW 13.

CGW13 determines whether rewriting of the application is completed (S1604) and whether a cancel request is generated (S1605, which corresponds to a cancel detection step). For example, when the CGW13 is mounted on the ECU to be rewritten (ID1), the progress status is updated and displayed as needed by repeating S1604 and S1605.

When the CGW13 receives the rewrite completion signal indicating that the rewrite of the application has been completed in the rewrite target ECU19, and determines that the rewrite of the application has been completed without a cancel request (S1604: yes), the display of the progress of the rewrite in the normal state is terminated (S1606), and whether or not the rewrite has been completed for all the rewrite target ECUs 19 is determined (S1607). For example, when the mounting of the rewrite target ECU (ID1) is completed, the CGW13 displays the progress status of the ECU (ID1) as 100%. If the CGW13 determines that rewriting has not been completed for all of the rewrite target ECUs 19 (S1607: no), the flow returns to step S1601 and the steps after step S1601 are repeated. For example, in a step subsequent to S1601, the CGW13 displays progress of the ECU to be rewritten (ID2) to be mounted next.

When CGW13 determines that a cancel request has been made before the rewriting of the application is completed (yes in S1605), the display of the rewriting progress status in the normal state is terminated (S1608), and the process proceeds to the display control processing at the time of rollback (S1609, corresponding to the report instruction step). Here, the cancel request includes a cancel request by a user and a cancel request by a system in which writing to rewrite target ECU19 has failed, and the like.

When the CGW13 starts the display control processing at the time of rollback, the ECU19 to be rewritten at the time of rollback is identified (S1611), and the memory type of the flash memory of the ECU19 to be rewritten at the time of rollback, the data type and the size of the rollback program are identified (S1612). For example, the CGW13 makes the rewrite target ECU19 belonging to the same group as the ECU (ID1), the ECU (ID2), and the ECU (ID3), and completes the installation of the ECU (ID1) and the ECU (ID2), and generates a cancel request during the installation of the ECU (ID 3). In this case, CGW13 determines whether or not rollback is necessary and the rollback method according to the memory type and the write data type of each rewrite target ECU 19.

The CGW13 specifies the memory type and the write data type of the flash memory of the rewrite target ECU19 to be subjected to rollback, and specifies the need or non-need of rollback and the rollback method (the first rollback processing in S1518, the second rollback processing in S1519, and the third rollback processing in S1520). CGW13 calculates the progress status based on the determination result, displays the progress status, and instructs display of the rewriting progress status during rollback (S1613). CGW13 has different amounts of data to be written in accordance with the first to third rollback processes. Therefore, CGW13 determines the total amount of data to be written based on the first to third rollback processes, and calculates the progress (several% written) based on the ratio to the amount of data to be written. CGW13 determines whether rewriting of the application program as the rollback processing is completed (S1614).

The CGW13 distributes the write data to the rewrite target ECU19 until the completion of the rewrite as the rollback processing, and repeats the above-described calculation and display instruction. CGW13 displays the calculated progress in the display mode during rollback at S1613. In S1614, CGW13 determines whether or not rollback of the ECU (ID3) in the middle of rewriting has been completed normally, for example.

When CGW13 determines that rollback of rewrite target ECU19 to be a rollback target is complete (S1614: yes), it ends the display of the progress of rewriting at the time of rollback (S1615). CGW13, for example, continues to complete 100% display for ECU (ID3) rollback.

CGW13 determines whether or not rewriting at the time of rollback is completed for all rollback target ECUs 19 (S1616). When the CGW13 determines that rewriting at the time of rollback is not completed for all of the rollback targets ECU19 (S1616: no), the process returns to step S1611, and the steps after step S1611 are repeated.

For example, when the ECU (ID1) to which the mounting has been completed is a single-sided individual memory, the CGW13 displays the progress of rewriting during rollback (S1613). On the other hand, for example, when the mounted ECU (ID2) is a dual-sided memory and rollback is not necessary, the ECU (ID2) is removed from the rewriting target at the time of rollback. When the rollback of the ECU (ID3) and the ECU (ID1) is completed, the CGW13 completes the rewriting of all the rewrites of the ECU19 to be rewound (S1616: yes), and ends the display control processing at the time of the rollback.

In the above description, the CGW13 performs the display control process during rollback, but may be configured to acquire necessary information from the CGW13 and perform the display control process during rollback by the in-vehicle display ECU7 or the center apparatus 3. Note that rewriting, progress calculation, and the like at the time of rollback may be performed by CGW13, and display control at the time of rollback may be performed by in-vehicle display ECU7 and center device 3. That is, the configuration is not limited to the configuration in which only the CGW13 has the function of the display control device, and the configuration may be such that the CGW13 and the in-vehicle display ECU7 dispersedly have the function of the display control device, or the configuration may be such that the CGW13 and the center device 3 dispersedly have the function of the display control device.

Hereinafter, the display of the rewriting progress will be described with reference to fig. 134 to 142. As shown in fig. 134, the display terminal 5 displays the entire progress status as "normal rewriting" in the display of the rewriting progress status at normal time, and allows the user to grasp the display of the rewriting progress status at normal time. The "normal rewrite" may also be displayed as "install". As a first mode, the display terminal 5 displays the progress of rewriting at normal times.

The display terminal 5 displays the progress state as "waiting for synchronization instruction" for the rewrite target ECU19 that has completed rewriting of the application and is in a state of waiting for synchronization instruction for activating the update program, and displays the progress state as "normal rewriting" for the rewrite target ECU19 that is in a state of being rewritten. The "wait for synchronization indication" may also be displayed as "wait for activation". The "normal rewriting" may be indicated as "installation". Fig. 134 illustrates a case where the ECU (ID0001) and the ECU (ID0002) have completed rewriting the application program and are in a state of waiting for a synchronization instruction, and the ECU (ID0003) is in a state of being normally rewritten.

When the cancel request is generated from this state, the display terminal 5 accepts, for example, a pop-up display "as shown in fig. 135. The state before rewriting is restored. Please wait a bit. "such a message makes the user grasp that cancellation is accepted. As a second mode, the display terminal 5 displays the accepted cancellation.

When preparation for rewriting at the time of rollback is completed by CGW13, display terminal 5 displays the entire progress as "rollback rewrite" as shown in fig. 136, and allows the user to grasp the display of the progress of rewriting at the time of rollback. The "rollback rewrite" may also be displayed as "unload". The display terminal 5 displays the progress state as "waiting for rollback" and displays the numerical value of the progress chart indicating the progress of the rewriting situation as "0%" for all the rewriting target ECUs 19. The "waiting to rollback" may also be displayed as "waiting to unload". Here, in the case where the ECU (ID0001) and the ECU (ID0002) are single-sided single-memory ECUs and the ECU (ID0003) is a double-sided memory ECU, the ECU (ID0001) and the ECU (ID0002) that have completed the installation need to be rolled back in addition to the ECU (ID0003) that is in the middle of rewriting. In fig. 136, a mode is adopted in which the progress status of the entire ECU19 is shown and the progress status of each ECU19 to be rewritten is displayed.

When the CGW13 starts the rewrite at the time of rollback, the progress state is displayed as "rollback rewrite-in (or unload)" to the rewrite target ECU19 in the state being rewritten as shown in fig. 137. As a third aspect, the display terminal 5 displays the progress of rewriting at the time of rollback. Fig. 137 illustrates a case where the ECU (ID0003) is in the rollback rewrite. When the display terminal 5 completes the rollback in the ECU19 to be rewritten, the display terminal displays the progress status of the ECU19 to be rewritten as "rollback completed" at 100% as shown in fig. 138.

When the rollback target ECU19 is a single-sided individual memory ECU and all data is rewritten, the display terminal 5 causes the progress chart to be displayed in transition as shown in fig. 139. That is, when the ECU19 to be rolled back is a single-sided individual memory ECU and all data is rewritten, distribution of all data is immediately interrupted, and the data of the old application is written into the flash memory and rewritten into the old application in the ECU19 to be rewritten (first rolling back processing).

For example, when a cancel request is generated at a stage when normal rewriting is completed to "50%" (fig. 139(a)), the display terminal 5 displays the numerical value of the progress chart as "0%" (fig. 139(b)), and increases the numerical value of the progress chart in accordance with the progress of data written in the old application program to rewrite the program to the old application program (fig. 139(c), (d), and (e)). When the rewriting of the old application is completed by 100%, the display terminal 5 displays that the ECU19 to be rewritten is "rollback completed". Fig. 139 and fig. 140 to 142 described later show a progress display of each ECU.

When the rollback target ECU19 is the single-sided individual memory ECU and the difference data is rewritten, the display terminal 5 causes the progress chart to be displayed in transition as shown in fig. 140 or 141. That is, when the ECU19 to be rolled back is a single-sided individual memory and the differential data is rewritten, the CGW13 continues the distribution of the differential data, and the ECU19 to be rewritten writes the differential data in the flash memory and rewrites the differential data into a new application. The CGW13 distributes the data of the old application to the ECU19 to be rewritten, and writes the old data in the flash memory in the ECU19 to be rewritten to the old application (second rollback processing).

For example, when a cancel request is generated at a stage when normal rewriting (installation) is completed to "50%" (fig. 140(a) and 141(a)), the display terminal 5 displays the numerical value of the progress chart as "0%" (fig. 140(b) and 141 (b)). The ECU19 to be rewritten validates the difference data written up to that time, and writes the difference data distributed from the CGW13 continuously. That is, the display of "0%" is switched to the progressive display corresponding to the mounting completion of the effective "50%" (fig. 140(c), 141 (c)). The display terminal 5 increases the numerical values of the progression chart in accordance with the progression of the difference data written in the new program distributed from the CGW13 by the ECU19 to be rewritten (fig. 140(d), (e), and fig. 141(d), (e)). After the rewrite target ECU19 completes the rewriting of the new application, the display terminal 5 increases the numerical values of the progress chart in accordance with the progress of the difference data of the old application distributed from the CGW13 written by the rewrite target ECU19 (fig. 140(f), (g), and fig. 141(f), (g)). That is, as the rollback processing, the display terminal 5 displays the progress status of the new program writing and the progress status of the old program writing so that the progress status of the new program writing and the progress status of the old program writing can be known in association with the continuous installation of the new program and the installation of the old program.

In this case, as shown in fig. 140, the display terminal 5 may display the left progressive graph as "100%" as the rewrite amount of the new application and the right progressive graph as "100%" as the rewrite amount of the old application, thereby setting the entire width of the progressive graph to "200%". In this case, the display terminal 5 calculates the percentage of progress of the new application based on the file size of the new application and the size of the accumulated data of the new application written, calculates the percentage of progress of the old application based on the file size of the old application and the size of the accumulated data of the old application written, and displays the progress status.

As shown in fig. 141, the display terminal 5 may set the rewriting amount of the new application to "50%" and the rewriting amount of the old application to "50%" so that the entire width of the progress chart is "100%". In this case, the display terminal 5 calculates and displays the progress percentage based on the sum of the file size of the new application and the file size of the old application, and the sum of the written cumulative data size of the new application and the written cumulative data size of the old application.

When the rollback target ECU19 is the one-sided suspend memory ECU or the double-sided suspend memory ECU for rewriting, the display terminal 5 shifts the display of the progress chart as shown in fig. 142. That is, when the rollback target ECU19 is the single-sided suspend memory ECU or the double-sided memory ECU, the CGW13 continuously distributes the write data to the rewrite target ECU19, and writes the write data to the non-operating surface and rewrites the write data to a new application in the rewrite target ECU19 (third rollback processing).

For example, when a cancel request is generated at a stage when normal rewriting (installation) is completed to "50%" (fig. 178(a)), the display terminal 5 displays the numerical value of the progress chart as "0%" (fig. 142 (b)). The ECU19 to be rewritten validates the difference data written up to that time, and continues writing of the difference data distributed from the CGW 13. That is, the display of "0%" is switched to the progressive display of the mounting completion corresponding to the ratio of "50%" (fig. 142 (c)). The display terminal 5 increases the numerical value of the progression diagram according to the progression of writing of the write data distributed from the CGW13 by the rewrite target ECU19 (fig. 142(d), (e)). In the present embodiment, the display control processing for the CGW13 to perform the progress of rewriting has been described, but the display terminal 5 may be configured to perform the display control processing for the progress of rewriting.

As described above, the display terminal 5 performs the display control processing of rewriting progress status, and displays the progress status in a display mode of distinguishing whether rewriting of the application program is normal rewriting (installation) or rewriting (uninstallation) in rollback, in addition to the rollback processing. The user accepts cancellation of the update program and can grasp progress of rollback. In addition, although the above description has been made of the configuration in which the progress state is displayed for each of the rewriting ECU19, as shown in fig. 143, the progress state of the rewriting ECU19 may be displayed together. In this case, the display terminal 5 displays progress displays for the three rewriting target ECUs 19 as one progress state instead of individually displaying the progress displays. As the rollback processing, CGW13 calculates the progress based on the ratio of the written data amount to the total written data amount generated in three rewrite target ECUs 19.

(17) Processing for determining matching of differential data

The processing for determining the matching of the difference data will be described with reference to fig. 144 to 147. The vehicle program rewriting system 1 performs the matching determination process of the difference data before installation of the rewriting target ECU19 is started.

As shown in fig. 144, the ECU19 includes a difference data acquisition unit 103a, a matching determination unit 103b, a written data restoration unit 103c, a data writing unit 103d, a data verification value calculation unit 103e, a rewriting specification data acquisition unit 103f, a data identification information acquisition unit 103g, and a rewriting surface information acquisition unit 103h in the difference data matching determination unit 103.

The difference data acquisition unit 103a acquires data for rewriting the data storage area of the electronic control device of the ECU19 to be rewritten, that is, difference data indicating the difference between the old data and the new data. The matching determination unit 103b determines whether or not the difference data matches the data storage area or the storage data based on first determination information relating to the storage data stored in the data storage area of the flash memory and second determination information acquired in association with the difference data. For example, the first determination information is a data verification value for stored data, and the second determination information is a data verification value for old data or a data verification value for new data. When the matching determination unit 103b determines that the matching of the differential data is positive, the write data restoration unit 103c restores the write data using the differential data and the stored data, and when the matching determination unit 103b determines that the matching of the differential data is negative, the write data restoration unit 103c restores the write data. When the write data is restored by the write data restoring unit 103c, the data writing unit 103d stores the restored write data in the data storage area. The data verification value calculation unit 103e calculates a data verification value for each block obtained by dividing the stored data into one or more blocks. The data verification value calculation unit 103e acquires the data verification value for each block received together with the difference data.

The rewriting specification data acquisition unit 103f acquires rewriting specification data corresponding to itself from among the rewriting specification data for CGW 13. The data identification information acquisition unit 103g acquires the data identification information stored in the difference data and the data identification information of the old application program, which is the old data. The data identification information is information that can identify whether or not the difference data is data for itself, and is, for example, data calculated by applying a predetermined algorithm to old data.

The rewriting plane information acquiring unit 103h acquires the rewriting plane information stored in the rewriting specification data acquired from the CGW13, and the rewriting plane information of the old application, which is the old data. The rewrite-target ECU19 specifies the a-side or the B-side when the double-sided memory or the single-sided suspend memory is used as the rewrite target ECU 19. When the rewrite target ECU19 is a single-sided individual memory, the rewrite surface information is not used. When the write data receiving unit 101 receives the differential data distributed from the CGW13, the matching determination unit 103b determines the matching of the differential data using at least one of the data identification information, the data verification value, and the overwrite surface information.

Next, the operation of the matching degree determination unit 103 for difference data of the rewrite target ECU19 will be described with reference to fig. 145 to 147. The rewrite target ECU19 executes a program for determining the matching of the difference data, and performs a process for determining the matching of the difference data. When the rewrite target ECU19 starts the process of determining the compatibility of the difference data, it acquires the data identification information, the data verification value, and the rewrite surface information relating to the difference data as the first determination information for determining the compatibility of the difference data (S1701). As the second determination information, the rewrite target ECU19 acquires the data identification information, the data verification value of the old data, the data verification value of the new data, and the rewrite plane information (S1702).

The rewrite target ECU19 determines whether or not the data identification information of the first determination information matches the data identification information of the second determination information, and whether or not the rewrite surface information of the first determination information matches the rewrite surface information of the second determination information (S1703). When the rewrite target ECU19 determines that the data identification information of the first determination information does not match the data identification information of the second determination information or the rewrite plane information of the first determination information does not match the rewrite plane information of the second determination information (S1703: no), it determines that the written data is inappropriate, and notifies the CGW13 of error information to end the difference data matching determination process.

When it is determined that the data identification information of the first determination information matches the data identification information of the second determination information and the rewrite plane information of the first determination information matches the rewrite plane information of the second determination information (S1703: yes), the rewrite target ECU19 compares the data verification value of the first determination information with the data verification value of the new data of the second determination information and determines whether or not both of the two match (S1704, corresponding to a matching determination step). When the rewrite target ECU19 determines that the two are not matched (S1704: no), it checks the data verification value of the first determination information with the data verification value of the old data of the second determination information to determine whether or not the two are matched (S1705, corresponding to a matching performance determination step).

When the rewrite target ECU19 determines that both are identical (S1705: YES), it restores the write data (S1706, which corresponds to a step of restoring the write data), writes the restored write data to the flash memory (S1707, which corresponds to a data writing step), and determines whether or not all the writes have been completed (S1708). If the rewrite target ECU19 determines that all writes have not been completed (S1708: no), it returns to step S1703 to repeat the steps after step S1703. When the rewrite target ECU19 determines that all writes have been completed (S1708: yes), it ends the matching judgment processing for the difference data.

When the rewrite target ECU19 determines that the data verification value of the first determination information does not match the data verification value of the new data of the second determination information (S1704: no) and that the data verification value of the first determination information does not match the data verification value of the old data of the second determination information (S1705: no), it determines whether or not the writing is to the first block (S1709).

When the rewrite target ECU19 determines that the writing is to be performed to the first block (S1709: yes), it determines whether or not all the writing is performed because the writing to the first block is not completed (S1708). When the rewrite target ECU19 determines that the write is not to be made to the first block, that is, to be made to the blocks subsequent to the second block (S1709: no), the write is retried (S1710), and whether or not all the writes have been completed is determined (S1708).

A case where the rewrite target ECU19 is a single-sided individual memory ECU will be described with reference to fig. 146. To the differential data distributed from CGW13, data identification information (old) and a CRC value (data verification value) calculated for each block of old data are added. The data identification information (old) is data calculated by applying a predetermined algorithm to old data (old application). When the data identification information is used as the determination information, the rewrite target ECU19 compares the data identification information (old) added to the difference data with the data identification information (old) of the program (old data) stored in the flash memory, and determines the matching of the difference data. The data identification information (old) stored in the flash memory is information stored in the flash memory of the rewrite target ECU19 when the program is written in the flash memory. Alternatively, the predetermined number of bits from the start address of the program written in the flash memory may be regarded as the data identification information (old).

When the verification value of data is used as the determination information, the rewrite target ECU19 calculates the CRC value for each block of the program stored in the flash memory, compares the CRC value for the old data (CRC (B1-Bn)) and the CRC value for the new data (CRC (B1 ' -Bn ') added to the received differential data with the calculated CRC values, and determines the consistency of the differential data, and when the new program is not written in the flash memory, the CRC values received in all the blocks match the calculated CRC values, the rewrite target ECU19, when the writing is interrupted and restarted in a state where the new program is written up to m (< n) blocks of the flash memory, matches the CRC values for the new data (CRC (B1 ' -Bn '), and thus the writing process is skipped (S1706, S7) and the rewrite target ECU19, observes the block m +1 and the CRC values for the old data (B1-Bn)), and performs the writing process (S1706) on the block m +1, B3538, B38 ', B) and the CRC value for the old data, S1707).

In addition, the differential data may be added with data identification information (new) of a new program (new data) and a CRC value (CRC (B1 'to Bn')) for each block. When the difference data is written in the flash memory and the new program is installed, the rewrite target ECU19 also stores the data identification information (new) in a lump for use in the consistency determination in the next program update. When the new program is installed, the rewrite target ECU19 reads the new program written in the flash memory for each block, calculates a CRC value, compares the CRC value with the CRC value added to the difference data, and verifies whether or not the program is correctly written.

A case where the rewrite target ECU19 is a dual-sided memory ECU will be described with reference to fig. 147. In this case as well, when the data verification value is used as the determination information, the rewrite target ECU19 calculates the CRC value for each block of the program stored in the flash memory, compares the CRC value for the old data (CRC (B1 to Bn)) added to the received differential data and the CRC value for the new data (CRC (B1 ' to Bn)) with the calculated CRC value, and determines the consistency of the differential data, in a state where the new program is not written in the flash memory, the CRC values received in all blocks match the calculated CRC value, the rewrite target ECU19, when the writing is interrupted and restarted in a state where the new program is written up to the m (< n) block of the flash memory, matches the CRC values for the new data (CRC (B1 ' to Bn ') up to the blocks 1 to m, skips the writing processing (S1706, S7), and the rewrite target ECU19, from the block m +1, observes the CRC value for the old data (B17032 to 1)) and writes the CRC value for the old data to match the CRC value for the block m +1 Then (S1706, S1707).

Assuming that the a-plane of the flash memory is an operating plane and is version 2.0, and the B-plane is a non-operating plane and is version 1.0, the differential data is differential data (differential data of version 1.0 and version 3.0) for updating the B-plane to version 3.0. To the differential data distributed from CGW13, data identification information (information indicating old (version 1.0)), a CRC value calculated for each block of old data (old program (version 1.0)), and a CRC value calculated for each block of new data (new program (version 3.0)) are added.

The rewrite specification data includes rewrite plane information indicating which plane of the flash memory the difference data for the ECU19 to be rewritten is written to. When the rewrite-target ECU19 uses the rewrite-surface information as the determination information, the rewrite-target ECU19 compares the rewrite-surface information acquired from the rewrite specification data with the non-operating-surface information (B-surface) of the rewrite-target ECU19 to determine the compatibility of the difference data. When the data identification information is used as the determination information, the rewrite target ECU19 compares the data identification information (old (version 1.0)) added to the differential data with the data identification information (old) of the old program (version 1.0) stored on the non-operating surface (B-surface) of the flash memory, and determines the matching of the differential data. When the data verification value is used as the determination information, the rewrite target ECU19 calculates the CRC value for each block of the old program (version 1.0) stored on the non-operating surface (B-surface) of the flash memory, compares the CRC value (CRC (B1 to Bn)) added to the differential data with the calculated CRC value, and determines the matching of the differential data.

In the above examples of fig. 143 and 144, the data identification information and the data verification value are added to the differential data and distributed from CGW13 together with the differential data. However, the data identification information and the data verification value may be added as header information of the differential data, and the CGW13 may distribute the header information to the rewrite target ECU19 before distributing the differential data to the rewrite target ECU 19. When the header information is received from the CGW13, the rewrite target ECU19 determines the matching of the differential data using the data identification information and the data verification value.

In fig. 179 and 180, the case where the rewriting data is the difference data has been described as an example, but the same applies to the case where the rewriting data is all the data. In the case where the rewrite target ECU19 is a single-sided individual memory, the same consistency determination is performed even when the original version is returned using the rollback difference data.

As described above, the rewrite target ECU19 performs the processing for determining the matching property of the difference data, and executes the writing of the write data generated based on the difference data only when the matching property of the difference data is positive, and prevents the case where the write data generated based on the difference data is written when the matching property of the difference data is negative. For example, in the case where the differential data for writing to the a-side is included in the distribution packet, the rewrite target ECU19 having the B-side of the flash memory as the non-operating side can detect a mismatch before writing the differential data in the flash memory. In addition, when differential data for another ECU and differential data whose version is not matched are included in the distribution packet as differential data for itself, the mismatch can be detected before the differential data are written into the flash memory.

When the writing of the write data is interrupted and the writing is resumed, the rewrite target ECU19 determines the matching of the differential data based on the data verification value of the stored data in the flash memory, the data verification value of the old data and the data verification value of the new data attached to the received differential data. The rewrite target ECU19 may determine the matching of the difference data based on the data verification value for the stored data and the verification value for the received new data, and from the final block determined as no, determine the matching of the difference data based on the data verification value for the stored data and the data verification value for the received old data.

The rewrite target ECU19 skips writing of write data until at least the block preceding the final block determined as no matching of the difference data, and restarts writing of write data from the final block or the block succeeding the final block. When the block size is equal to the data size of the write area in which data is written, writing of write data is completed up to the final block, and therefore, writing up to the final block is skipped and writing is started again from the subsequent block of the final block. On the other hand, when the block size is not equal to the data size of the write area in which data is written, the writing of write data may be interrupted in the final block, and therefore, it is necessary to restart writing from the final block.

(18) Execution control processing of rewriting

The execution control processing of rewriting will be described with reference to fig. 148 to 155. The vehicle program rewriting system 1 performs execution control processing for rewriting in the ECU 19.

As shown in fig. 148, the ECU19 includes the program execution unit 104a, the switching request reception unit 104b, the data acquisition unit 104c, the plane information notification unit 104d, the firmware acquisition unit 104e, the installation execution unit 104f, and the activation execution unit 104g in the rewritten execution control unit 104. The program execution unit 104a executes the rewriting program of the operating plane and rewrites the non-operating plane while executing the application program and the parameter data of the operating plane. The handover request receiver 104b receives an activation request from the CGW 13. The data acquisition unit 104c acquires, from the outside, write data in an area of the non-operating surface that needs to be rewritten. The surface information notification unit 104d notifies the outside of double-sided rewriting information (hereinafter referred to as surface information). The firmware acquisition unit 104e acquires firmware of the rewriting program from the outside. When the mounting is instructed from CGW13, the mounting execution unit 104f writes the write data into the flash memory and executes the mounting. When the activation is instructed from CGW13, the activation execution unit 104g executes activation of the switching operation surface at the time of restart.

Next, the operation of the execution control unit 104 for rewriting the ECU19 will be described with reference to fig. 149 to 155. The rewrite target ECU19 executes the rewritten execution control program to perform the rewritten execution control process. As the rewrite execution control process, the rewrite target ECU19 performs a normal operation process, a rewrite operation process, an information notification process, and an application program verification process. Hereinafter, each process will be described. In the present embodiment, a case where the ECU19 to be rewritten is a double-sided memory ECU or a single-sided suspend memory ECU will be described.

(18-1) Normal action processing

The rewrite target ECU19 starts the normal operation processing when it shifts from the stopped state or the sleep state to the activated state with the IG power source turned on or the like. When the rewriting ECU19 starts the normal operation process, it specifies the start surface based on the start surface determination information of the a surface and the B surface (S1801), and starts on the start surface (S1802). The rewrite target ECU19 verifies the integrity of the program stored on the activation surface (operating surface) and determines whether the activation surface is positive (S1803).

If the rewrite target ECU19 determines that the verification result of the integrity of the activation surface is negative and determines that the activation surface is negative (S1803: no), it transmits error information indicating that the verification result of the integrity of the activation surface is negative to the CGW13 (S1804) and ends the normal operation processing. Upon receiving the error information from the rewrite target ECU19, the CGW13 transmits the error information to the DCM 12. When receiving the error information from CGW13, DCM12 uploads the received error information to center apparatus 3. That is, if the result of verifying the integrity of the start surface is determined to be no in the rewrite target ECU19, the contents are notified to the CGW13, the DCM12, and the center device 3.

When the rewrite target ECU19 determines that the verification result of the integrity of the activation surface is positive and determines that the activation surface is positive (S1803: yes), it verifies the integrity of the program stored on the rewrite surface (non-operating surface) and determines whether the rewrite surface is positive (S1805).

When the rewrite target ECU19 determines that the verification result of the integrity of the rewritten surface is negative and determines that the rewritten surface is negative (S1805: no), it transmits error information indicating that the verification result of the integrity of the rewritten surface is negative to the CGW13 (S1806). Upon receiving the error information from the rewrite target ECU19, the CGW13 transmits the error information to the DCM 12. When receiving the error information from CGW13, DCM12 uploads the received error information to center apparatus 3. That is, if the rewrite target ECU19 determines that the verification result of the integrity of the rewritten surface is no, it notifies the CGW13, DCM12, and the center device 3 of the result.

The above-described process of integrity verification is performed by the boot program before the application program is executed. When the rewrite target ECU19 ends the integrity verification, it specifies the arrangement address of the boot vector table (S1807), specifies the arrangement address of the normal-time vector table (S1808), specifies the start address of the application program (S1809), executes the application program, and ends the normal operation processing.

(18-2) rewrite operation processing

When receiving a rewrite request from the CGW13, the rewrite target ECU19 starts the rewrite operation processing. When the rewrite operation process is started, the rewrite target ECU19 performs authentication with the CGW13 using the secure access key (S1811). When the rewrite target ECU19 determines that the authentication result is positive (S1812: yes), it waits for reception of write data (S1813). When the ECU19 to be rewritten determines that the write data has been received from the CGW13 (S1813: yes), it rewrites an application disposed on the rewriting surface (non-operating surface) while executing the application disposed on the startup surface (operating surface) (S1814).

The rewrite target ECU19 determines whether or not the rewriting of the application is completed (S1815), and if it is determined that the rewriting of the application is completed (S1815: yes), determines whether or not the check is positive (S1816). If the determination is that the check is positive (S1816: yes), the ECU19 sets the rewrite completion flag to "OK" (S1817). Verification refers to integrity verification of the application written to the non-application side.

The rewrite target ECU19 determines whether an activation request is received from the CGW13 (S1818). When the rewrite target ECU19 determines that an activation request has been received from the CGW13 (S1818: yes), it updates the startup surface information of the rewritten surface by, for example, adding 1 to the numerical value of the startup surface information of the rewritten surface (S1819). That is, after that, the information is updated to the information indicating the startup on the rewritable surface. The ECU19 to be rewritten determines whether or not the version read signal is received from the CGW13 (S1820), and if it determines that the version read signal is received (S1820: yes), transmits the version information of the operating surface, the version information of the non-operating surface, and the identification information that can identify which surface is the operating surface to the CGW13 (S1821), and ends the rewriting operation processing. Here, in the rewrite target ECU19, all the processes from S1811 to S1821 may be executed by the application of the operating surface (old surface) before switching. Note that, in the rewrite target ECU19, the processing from S1811 to S1819 may be executed by the application of the operation surface (old surface) before switching, and the processing from S1820 to S1821 may be executed by the application of the operation surface (new surface) after switching by restarting the application after S1819.

(18-3) information Notification processing

The rewrite target ECU19 starts the information notification process when it transitions from the stopped state or the sleep state to the activated state, or when the IG power is turned on or when it receives a notification request from the CGW13, for example. When the rewrite target ECU19 starts the information notification process, it notifies the CGW13 of identification information capable of uniquely identifying the application and parameter data related to the operating plane and the non-operating plane, and identification information capable of uniquely identifying the location of the operating plane and the non-operating plane on the memory. That is, the rewrite target ECU19 acquires startup plane information on the startup plane (S1831), and transmits the startup plane information to the CGW13 (S1832). The rewrite target ECU19 transmits information on which of the a-surface and the B-surface is the activation surface and version information of the activation surface to the CGW13 as activation surface information.

When the transmission of the startup surface information to the CGW13 is completed, the ECU19 acquires rewriting surface information (hereinafter also referred to as surface information) relating to the rewriting surface (S1833), and transmits the acquired rewriting surface information to the CGW13 (S1834). The rewrite target ECU19 transmits, as rewrite surface information, information on which of the a-surface and the B-surface is the rewrite surface, version information of the rewrite surface, and the like to the CGW 13. When the rewrite target ECU19 finishes transmitting the rewrite surface information to the CGW13, it transmits identification information capable of specifying the arrangement addresses of the rewrite surface and the start surface on the memory to the CGW13 (S1835), and ends the information notification processing. The rewrite target ECU19 transmits, for example, the start address and the end address of the a-plane and the start address and the end address of the B-plane in the flash memory to the CGW13 as the identification information from which the addresses can be specified.

(18-4) verification processing of rewriting program

When the rewrite target ECU19 starts the rewrite program verification process, it determines whether or not identification information capable of specifying an address for executing the rewrite program is acquired (S1841). When the rewrite target ECU19 determines that identification information for specifying an address for executing the rewrite program has been acquired (S1841: yes), it determines whether or not the identification information matches the startup plane information of the rewrite target ECU19 (S1842). Specifically, the rewrite target ECU19 determines whether or not the surface information indicating the start surface in the start surface information matches the identification information.

When the ECU19 to be rewritten determines that the identification information matches the startup plane information of the ECU19 to be rewritten (S1842: yes), the program to be rewritten is acquired (S1843), and it is determined whether or not the identification information that can specify the address for rewriting the application program is acquired (S1844). Here, if the rewrite target ECU19 is of an embedded type structure in which the rewrite program is embedded in the flash memory in advance, in S1843, the write program of the start surface is acquired from the flash memory and executed on the RAM. If the rewrite target ECU19 has a download-type configuration in which the rewrite program is downloaded from the outside without embedding the rewrite program in the flash memory in advance, the rewrite program is downloaded to the RAM and executed in S1843.

When the rewrite target ECU19 determines that identification information for specifying an address for rewriting an application is acquired (S1844: yes), it determines whether the identification information matches the startup plane information of the rewrite target ECU19 (S1845). Specifically, the rewrite target ECU19 determines whether or not the surface information indicating the non-start surface in the start surface information matches the identification information. When the rewrite target ECU19 determines that the identification information matches the startup plane information of ECU19 (S1845: yes), the application is rewritten (S1846), and the verification process of the rewritten program is ended.

If the rewrite target ECU19 determines that the identification information does not match the startup plane information of the ECU19 (S1842: no) or that the identification information does not match the startup plane information of the rewrite target ECU19 (S1845: no), it determines that the application or parameter data that can be executed on the operating plane or the non-operating plane is not present, and transmits a negative response to the CGW13 (S1847), thereby ending the verification process of the rewrite program. For example, in the case of a dual-sided memory ECU using a flash memory in which the a-side is an operating side and the B-side is a non-operating side, the address for executing the rewrite program is the address of the a-side, which is the operating side, and the address for rewriting the application program is the address of the B-side, which is the non-operating side.

As shown in fig. 150, the ECU19 to be rewritten may acquire identification information capable of specifying an address from the CGW13 before acquiring the write data from the CGW 13. As shown in fig. 151, the ECU19 to be rewritten may acquire identification information capable of specifying an address when acquiring the write data from the CGW 13. The rewrite target ECU19 receives rewrite specification data from the CGW13 and acquires rewrite surface information, for example, before acquiring write data. Since the rewritable surface information includes data that can identify which surface is the start surface and which surface is the rewritable surface, the identifiable data is used as identification information that can identify an address.

In response to the mounting instruction processing performed by CGW13, rewrite-target ECU19 performs the above-described (18-2) rewrite operation processing. Here, the mounting instruction processing by CGW13 will be described.

When the mounting instruction processing is started, the CGW13 recognizes the rewriting specification data (S1851), and specifies the mounting during parking for all the rewriting ECU19, but determines whether the mounting during vehicle traveling is specified for all the rewriting ECU19, and whether the mounting is specified for each memory type of the rewriting ECU19 (S1852 to S1854).

If the CGW13 determines that the mounting in the parking is specified for all the rewrite target ECUs 19 (S1852: yes), the mounting is instructed to the rewrite target ECU19 on the condition that the mounting is approved and the vehicle is parked (S1855). If the CGW13 determines that the mounting during the traveling of the vehicle is specified for all the rewrite-target ECUs 19 (S1853: yes), the mounting is instructed to the rewrite-target ECU19 on the condition that the mounting is approved and the vehicle is traveling (S1856).

When the CGW13 determines that the mounting is designated for each memory type of the ECU19 to be rewritten (S1854: "yes"), it determines whether the memory type is a dual-sided memory, a single-sided suspend memory, or a single-sided individual memory based on the rewriting specification data (S1857, S1858).

If the CGW13 determines that the memory type of the ECU19 to be rewritten is the dual-sided memory and the first predetermined condition is satisfied (S1857: yes), the mounting is instructed to the ECU19 to be rewritten on condition that the mounting is approved and the vehicle is traveling (S1859). When the CGW13 determines that the memory type of the ECU19 to be rewritten is the single-sided suspended memory or the single-sided individual memory and the second predetermined condition is satisfied (S1858: yes), the mounting is instructed to the ECU19 to be rewritten (S1860) on condition that the mounting is granted and the vehicle is stopped.

The CGW13 determines whether or not the mounting has been completed on all of the rewrite target ECUs 19 (S1861), and when it is determined that the mounting has not been completed on all of the rewrite target ECUs 19 (S1861: no), returns to step S1851, and repeats step S1851.

That is, if the rewrite target ECU19 is a dual-sided memory ECU, the CGW13 instructs installation while the vehicle is able to travel. The dual-sided memory ECU is instructed to be mounted from CGW13 while the vehicle is able to travel, and is mounted while the vehicle is able to travel (corresponding to the mounting execution step). If the rewrite target ECU19 is a single-sided suspended memory ECU or a single-sided individual memory ECU, the CGW13 instructs installation during parking. The single-sided suspend memory ECU and the single-sided individual memory ECU are instructed to be mounted from CGW13 during parking, and are mounted during parking (corresponding to mounting execution steps).

When the CGW13 determines that the mounting has been completed on all of the rewrite target ECUs 19 (S1861: yes), it determines whether or not the vehicle is parked (S1862), and when it determines that the vehicle is parked (S1862: yes), it instructs the rewrite target ECU19 to activate the vehicle during parking (S1863), and the mounting instruction processing is ended. The rewrite target ECU19 is instructed to activate from the CGW13 during parking, and thereby activated (corresponding to an activation execution step).

As described above, in the configuration in which the plurality of surfaces have the data storage surfaces by performing the execution control processing of rewriting, the ECU19 to be rewritten executes the rewriting program of the operating surface and rewrites the non-operating surface while executing the application program of the operating surface. The period in which the application program can be rewritten is not limited to the parking state, and the application program can be rewritten while the vehicle is traveling. The rewrite target ECU19, if it is a dual-sided memory ECU, can be mounted while the vehicle is able to travel by being instructed to be mounted from the CGW13 while the vehicle is able to travel. If the ECU19 to be rewritten is a single-sided suspended memory ECU or a single-sided individual memory ECU, the mounting is instructed from the CGW13 during the parking, and the mounting can be performed during the parking.

(19) Session establishment processing

The session establishment process will be described with reference to fig. 156 to 169. The vehicle program rewriting system 1 performs a session establishment process in the rewriting target ECU 19.

As shown in fig. 156, the ECU19 includes an application execution unit 105a, a wireless rewrite request specification unit 105b, and a wired rewrite request specification unit 105c in the session specification unit 105. The application execution unit 105a has a function of mediating the execution of each program. The wireless rewriting request specification unit 105b has a function of specifying a program rewriting request via wireless. The wired rewrite request specification unit 105c has a function of specifying a program rewrite request via a wired line.

Fig. 157 shows the configuration of each program stored in the flash memory. The vehicle control program is a program for realizing a vehicle control function (for example, a steering control function) mounted on the ECU19 itself. The wired diagnosis program is a program for performing diagnosis of the ECU19 itself from outside the vehicle via a wired line. The wireless diagnostic program is a program for diagnosing the ECU19 itself from outside the vehicle via wireless. The wireless rewriting program is a program for rewriting a program acquired from outside the vehicle via wireless. The wired rewrite program is a program for rewriting a program acquired from outside the vehicle via a wired line. The vehicle control program is configured in the application area as a first program. The wired diagnostic program and the wired rewrite program are disposed in the application area as a second program. The wireless diagnostic program and the wireless rewrite program are disposed in the application area as a third program. In other words, the second program is a program for performing special processing via wire other than vehicle control, and the third program is a program for performing special processing via wireless other than vehicle control. The wired rewrite program may be disposed in the boot area as a fourth program, instead of being disposed in the application area.

The application execution unit 105a performs control so that the first program, the second program, and the third program can be executed at the same time (non-exclusive control is performed). The application execution unit 105a can execute, for example, a vehicle control program, a wired diagnostic program, and a wireless diagnostic program at the same time. That is, the application execution unit 105a can simultaneously execute the vehicle control, the diagnosis by the wired ECU19, and the diagnosis by the wireless ECU 19. Similarly, the application execution unit 105a performs control so that the vehicle control program, the wired diagnostic program, and the wireless rewrite program can be executed at the same time, the vehicle control program, the wired rewrite program, and the wireless diagnostic program can be executed at the same time, and the vehicle control program, the wired rewrite program, and the wireless rewrite program can be executed at the same time.

On the other hand, the application execution unit 105a performs exclusive control so that the programs in the second program cannot be executed simultaneously. Also, exclusive control is performed so that the programs in the third program cannot be executed simultaneously. The application execution unit 105a exclusively controls the wired diagnostic program and the wired rewrite program, and exclusively controls the wireless diagnostic program and the wireless rewrite program, for example. That is, the application execution unit 105a executes only one program in special processing via a wire. Similarly, the application execution unit 105a executes only one program in the special processing via wireless.

In other words, the wireless rewrite program may be disposed inside the wireless diagnostic program and embedded as a part of the wireless diagnostic program. That is, with the configuration in which the wireless rewrite program is disposed inside the wireless diagnostic program, when the state is shifted from the default session or the wireless diagnostic session to the wireless rewrite session as described later during execution of the vehicle control program and the wired diagnostic program, the application execution unit 105a controls to execute the wireless rewrite program in a state in which execution of the vehicle control program and the wired diagnostic program is continued. The application execution unit 105a can simultaneously execute the vehicle control program, the wired diagnostic program, and the wireless rewrite program by starting the execution of the wireless rewrite program while continuing the execution of the vehicle control program and the wired diagnostic program. That is, the application execution unit 105a performs control so that vehicle control, diagnosis by the wired ECU19, and rewriting of an application program by wireless can be performed at the same time.

Here, depending on the specific contents of the diagnosis process and the rewriting process, there is a situation where the diagnosis using wired and wireless and the rewriting using wired and wireless cannot be performed simultaneously. For example, when the same area is rewritten by wired rewriting and by wireless rewriting, the two processes conflict with each other. Therefore, the application execution unit 105a exclusively controls the wired diagnostic program and the wireless diagnostic program, and exclusively controls the wired rewrite program and the wireless rewrite program, based on the specific contents of the processing and the request. Further, depending on the contents of the diagnostic process, there may be a case where the normal vehicle control cannot be continued. For example, when a diagnostic process is performed in which an ECU is operated to read the result, the diagnostic process cannot be executed simultaneously with the normal vehicle control. In this case, the application execution unit 105a performs the following mediation control to wait for the vehicle control program and execute the wired or wireless diagnostic program.

On the other hand, when the wired rewrite program is not arranged in the application area but arranged in the boot area as the fourth program, the application execution unit 105a performs a locally different mediation control from the above. As shown by the dotted line in fig. 157, the wired rewrite program is disposed outside the wired diagnostic program as a fourth program and is not embedded as a part of the wired diagnostic program. In this case, the application execution unit 105a performs exclusive control to end the first to third programs when executing the fourth program. That is, the application execution unit 105a switches from the mode for executing the first to third programs to the dedicated mode for executing the fourth program. In other words, when the wired rewrite program is disposed outside the wired diagnostic program, and the state is shifted from the wired diagnostic session to the wired rewrite session as described later during execution of the vehicle control program and the wireless diagnostic program, the wired rewrite program stops execution of the vehicle control program and the wireless diagnostic program, and starts execution of the wired rewrite program. The application execution unit 105a stops the execution of the vehicle control program and the wireless diagnostic program and starts the execution of the wired rewrite program, and thus the vehicle control program, the wireless diagnostic program, and the wired rewrite program cannot be executed at the same time, and only the wired rewrite program can be executed. That is, the application execution unit 105a controls so that the vehicle control, the diagnosis of the ECU19 using wireless communication, and the rewriting of the application program using wired communication cannot be executed at the same time, and the rewriting of the application program using wired communication can be executed only.

As shown in fig. 158, the application execution unit 105a manages a default state (default session), a wired diagnosis state (wired diagnosis session), and a wired rewrite state (wired rewrite session) as a first state related to special processing using a wired. As a second state relating to special processing using radio, a default state (default session) and a state of radio rewriting (radio rewriting session) are managed, and an internal state of an operation is managed.

As the state transition of the first state, the application execution unit 105a exclusively makes the state transition to a default session in which the vehicle control can be performed in accordance with the diagnostic communication standard, a wired diagnostic session in which the diagnosis of the ECU19 can be performed from outside the vehicle via a wired line, and a wired rewrite session in which the rewriting of the application program acquired from outside the vehicle via a wired line is possible. Making a session state transition exclusively means that a session cannot be established at the same time, and making a session state transition non-exclusively means that a session can be established at the same time.

The default session in the first state is a mode indicating a state where special processing using a wired line is not performed, and is a state where vehicle control can be executed. The default session may be a mode in which a process that does not affect the vehicle control at all, for example, a diagnostic program that is not related to the vehicle control may be executed. The diagnostic program not related to the vehicle control is a program for reading information such as a trouble code. The wired diagnostic session is a mode of executing a diagnostic program related to the diagnosis of the ECU 19. At least when the vehicle control can be affected by execution of the diagnostic program, the session is transferred from the default session to the wired diagnostic session. The diagnostic program related to the diagnosis of the ECU19 is a program for performing communication stop, examination masking, actuator driving, and the like. The wired rewrite session is a mode for executing rewrite of an application acquired from outside the vehicle via a wired line.

The application execution unit 105a performs state transition of a session in the first state as follows. When a diagnosis request for using the wire is generated in the state of the first default session, the application execution unit 105a transfers from the first default session to the wired diagnosis session in accordance with the diagnosis session transfer request, and executes a diagnosis process using the wire. When a session restoration request is generated, a timeout is generated, the power is disconnected, or a regulatory service is received in the wired diagnostic session, the application execution unit 105a transfers from the wired diagnostic session to the first default session. When a wired rewrite request is generated in the state of the first default session, the application execution unit 105a transfers the wired rewrite process from the wired diagnostic session to the wired diagnostic session in response to a diagnostic session transfer request, and then transfers the wired diagnostic session to the wired rewrite session in response to a rewrite session transfer request. When a session restoration request is generated, a timeout is generated, the power is turned off, or a regulation service is received while the wired rewrite session is in progress, the application execution unit 105a transfers the wired rewrite session to the first default session. The application execution unit 105a maintains the current session without transferring the session in response to the session maintenance request.

As the state transition of the second state, the application execution unit 105a exclusively transitions the state of a default session in which the vehicle control is possible in accordance with the diagnostic communication standard, and a wireless rewriting session relating to rewriting of an application program acquired from the outside of the vehicle via wireless. The wireless rewrite session is a mode for executing rewrite of an application acquired from outside the vehicle via wireless.

In the second state, the application execution unit 105a performs the state transition of the session as follows. When a wireless rewrite request is generated in the state of the second default session, the application execution unit 105a transfers the second default session to the wireless rewrite session in response to the rewrite session transfer request, and executes a wireless rewrite process. When a session restoration request is generated, a timeout is generated, or power is turned off in the state of the wireless rewrite session, the application execution unit 105a transfers from the wireless rewrite session to the second default session. The application execution unit 105a maintains the current session without transferring the session in response to the session maintenance request.

The application execution unit 105a executes a vehicle control program as a first program, and manages a first state relating to special processing using a wire and a second state relating to special processing using a wireless. For example, when the wired diagnostic request is generated in the default session in both the first state and the second state, the application execution unit 105a shifts the first state to the wired diagnostic session and starts the execution of the wired diagnostic program while the vehicle control program is being continued. In this state, when a wireless rewrite request is generated, the application execution unit 105a shifts the second state to a wireless rewrite session to start execution of the wireless rewrite program while continuing execution of the vehicle control program and the wired diagnostic program. In this state, when a wired rewrite request is generated, the application execution unit 105a ends the execution of the wireless rewrite program, shifts the second state to the default session, ends the execution of the wired diagnostic program, shifts the first state to the wired rewrite session, and starts the execution of the wired rewrite program, for example. In order to prevent a write process conflict to the same memory area, the application execution unit 105a performs exclusive state transition (performs exclusive control) so that a wired rewrite session in the first state and a wireless rewrite session in the second state are not established simultaneously.

The wireless rewrite request specification unit 105b determines the identification information of the rewrite request received from the outside and specifies the wireless rewrite request. That is, when the reprogramming data is downloaded from the center apparatus 3 to the DCM12 and the CGW13 distributes the reprogramming data transmitted from the DCM12 to the rewriting target ECU19, the wireless rewriting request determination unit 105b determines the wireless rewriting request by receiving the identification information indicating the wireless rewriting request together with the reprogramming data from the CGW 13.

The wired rewrite request specification unit 105c determines identification information of a rewrite request received from the outside, and specifies the wired rewrite request. That is, when the tool 23 is connected to the DLC connector 22 and the CGW13 distributes the rewrite data transmitted from the tool 23 to the rewrite target ECU19, the wired rewrite request specifying unit 105c receives identification information indicating a wired rewrite request together with the rewrite data from the CGW13, and specifies the wired rewrite request.

The identification information may be information corresponding to different identification IDs in the wired rewrite request and the wireless rewrite request, or may be information corresponding to different data even though the identification ID is the same in the wired rewrite request and the wireless rewrite request. That is, any information may be used as long as the wired rewrite request and the wireless rewrite request can be recognized.

The application execution unit 105a has been described with reference to fig. 158 as a configuration for managing two states of the default session and the wireless rewrite session as the second state relating to the special processing using wireless, but may be configured to manage three states of the default session, the wireless diagnostic session, and the wireless rewrite session as the second state as shown in fig. 159 and 160. The wireless diagnostic session is a mode of executing a wireless diagnostic program for performing diagnosis of the ECU19 from outside the vehicle via wireless. At least when a wireless diagnostic program that affects vehicle control is executed, a transition is made to a wireless diagnostic session.

In the case of the configuration shown in fig. 159, the application execution unit 105a performs the state transition of the second state as follows. When a diagnosis request using wireless is generated in the state of the second default session, the application execution unit 105a transfers from the second default session to the wireless diagnosis session in accordance with the diagnosis session transfer request, and executes wireless diagnosis processing. When a session restoration request is generated, a timeout is generated, and the power is turned off in the wireless diagnostic session state, the application execution unit 105a transfers from the wireless diagnostic session to a second default session. When the wireless rewrite request is generated in the state of the second default session, the application execution unit 105a transfers the second default session to the wireless diagnostic session in response to the diagnostic session transfer request, and then transfers the second default session to the wireless rewrite session in response to the rewrite session transfer request, thereby executing the wireless rewrite processing. When a session restoration request is generated, a timeout is generated, and the power is turned off in the wireless rewrite session, the application execution unit 105a transfers the wireless rewrite session to a second default session.

In the case of the configuration shown in fig. 160, the application execution unit 105a performs state transition of the second state as follows. When a diagnosis request using wireless is generated in the state of the second default session, the application execution unit 105a transfers from the second default session to the wireless diagnosis session in accordance with the diagnosis session transfer request, and executes wireless diagnosis processing. When a session restoration request is generated, a timeout is generated, and the power is turned off in the wireless diagnostic session state, the application execution unit 105a transfers from the wireless diagnostic session to a second default session. When a wireless rewrite request is generated in the state of the second default session, the application execution unit 105a transfers the wireless rewrite session from the second default session to the wireless diagnostic session in response to the diagnostic session transfer request, and then transfers the wireless rewrite session from the wireless diagnostic session to the wireless diagnostic session in response to the rewrite session transfer request, or transfers the wireless rewrite session from the second default session to the wireless rewrite session in response to the rewrite session transfer request, and executes wireless rewrite processing. When a session restoration request is generated, a timeout is generated, and the power is turned off in the wireless rewrite session, the application execution unit 105a transfers the wireless rewrite session to a second default session.

The wired diagnostic session in the first state and the wireless diagnostic session in the second state may execute the same diagnostic procedure or different diagnostic procedures. The wired rewrite session in the first state and the wireless rewrite session in the second state may execute the same rewrite program or different rewrite programs. For example, a common rewriting program such as erasing and writing of the memory may be executed.

In the configurations shown in fig. 159 and 160, the mediation of each session in the first state and each session in the second state will be described. As described in fig. 157, the wired diagnostic program is disposed in the application area as the second program, the wireless diagnostic program and the wireless rewrite program are disposed in the third program application area, and the wired diagnostic program is disposed in the boot area as the fourth program. In other words, the description will be made of a configuration in which the wireless rewrite program is embedded as a part of the wireless diagnostic program, and the wired rewrite program is not embedded as a part of the wired diagnostic program. In this case, the mediation of program execution in each session of the first state and the second state is as shown in fig. 161.

When the second state is the wireless rewriting session and the first state is the default session, the application execution unit 105a executes the vehicle control program and also executes the wireless rewriting program. When the second state is the wireless rewriting session and the first state is the wired diagnosis session, the application execution unit 105a executes the vehicle control program and simultaneously executes the wireless rewriting program and the wired diagnosis program.

On the other hand, when the first state is the wired rewrite session and the second state is the default session, the application execution unit 105a ends the vehicle control program and executes only the wired rewrite program. When the first state is the wired rewrite session and the second state is the wireless diagnosis session, the application execution unit 105a ends the wireless diagnosis program and the vehicle control program and executes only the wired rewrite program. That is, the application execution unit 105a exclusively controls the first to third programs as a dedicated mode for executing only the wired rewrite program, which is the fourth program.

In the configuration in which the wired diagnostic program and the wired rewrite program are disposed in the application area as the second program, the mediation of each program is partially different from that in fig. 161. That is, in the configuration in which the wireless rewriting program is embedded as a part of the wireless diagnostic program and the wired rewriting program is embedded as a part of the wired diagnostic program, the mediation of the program execution in each session of the first state and the second state is as shown in fig. 162. In this case, when the first state is the wired rewrite session and the second state is the default session, the application execution unit 105a executes the vehicle control program and also executes the wired rewrite program. When the first state is the wired rewriting session and the second state is the wireless diagnosis session, the application execution unit 105a executes the vehicle control program and simultaneously executes the wired rewriting program and the wireless diagnosis program.

Next, the operation of the above-described configuration will be described with reference to fig. 163 to 167. In the ECU19, the microcomputer 33 executes a session establishment program to perform a session establishment process.

When the microcomputer 33 detects that the power is turned on and starts up, it executes a session establishment program to perform a state transition management process for managing a state transition of the first state and a state transition management process for managing a state transition of the second state. Hereinafter, each state transition management process will be described. Here, a case where the application execution unit 105a manages the second state with the configuration shown in fig. 158, that is, the configuration without the wireless diagnosis session will be described.

(19-1) State transition management processing of the first State

When the microcomputer 33 detects that the power is turned on and starts the state transition management processing in the first state, it determines the rewrite completion flag and determines whether or not the rewrite of the previous application program has been normally completed (S1901). If the microcomputer 33 determines that the rewrite completion flag is positive, it determines that the previous rewrite of the application has been completed normally (S1901: yes), and then shifts the first state to the default session (S1902). That is, the microcomputer 33 starts the vehicle control process by making the first state transition to the default session.

When the vehicle control program is executed to start the vehicle control process, the microcomputer 33 determines whether or not a wired diagnosis request is generated during the execution of the vehicle control process (S1903), determines whether or not a wired rewrite request is generated (S1904), and determines that a completion condition for the state transition management is satisfied (S1905). If the microcomputer 33 determines that the wired diagnosis request is generated during the execution of the vehicle control process (yes in S1903), the first state is transferred from the default session to the wired diagnosis session (S1906), and the wired diagnosis program is executed to start the wired diagnosis process (S1907). The microcomputer 33 determines that the conditions for completing the wired diagnostic process are satisfied (S1908), and if it is determined that the conditions for completing the wired diagnostic process are satisfied (S1908: "yes"), the wired diagnostic program is terminated to terminate the wired diagnostic process (S1909), and the first state is transferred from the wired diagnostic session to the default session (S1910).

When the microcomputer 33 determines that a wired rewrite request is generated during execution of the vehicle control processing (yes in S1904), it starts a rewrite exclusive processing at the time of generation of the wired rewrite request (S1911). That is, the process is for exclusive control so that the wired rewrite process does not conflict with the wireless rewrite process. When the microcomputer 33 starts the rewriting exclusive process at the time of generation of the wired rewrite request, it determines whether or not the transition to the wireless rewrite session is in progress in the second state, that is, whether or not the second state is the wireless rewrite session (S1921). If the microcomputer 33 determines that the transition to the wireless rewrite session is not in the process in the second state (S1921: no), it determines that the transition to the wired rewrite session is possible in the first state (S1922). The microcomputer 33 terminates the rewriting exclusion process at the time of generation of the wired rewriting request, and returns to the state transition management process in the first state.

When the microcomputer 33 determines that the transition to the wireless rewrite session is in the process in the second state (S1921: yes), it determines which of the wired rewrite session and the wireless rewrite session is to be prioritized to perform the exclusive control. Specifically, the microcomputer 33 determines whether or not any of the wired rewrite session priority condition, the wireless rewrite session priority condition, and the during-transfer rewrite session priority condition is satisfied (S1923 to S1925). The wired rewrite session priority condition is a condition for giving priority to the wired rewrite session over the wireless rewrite session. The wireless rewrite session priority condition is a condition for giving priority to a wireless rewrite session over a wired rewrite session. The overwrite session priority condition during transfer is a condition for giving priority to an overwrite session during transfer, i.e., a session transferred first. Which of these priority conditions is adopted is set in advance, and for example, a priority condition flag may be set for the vehicle, or a priority condition flag may be set for each rewriting ECU.

If the microcomputer 33 determines that the wired rewrite session priority condition is satisfied (yes in step S1923), it shifts the wireless rewrite session to the default session in response to the session restoration request in the second state to interrupt the wireless rewrite (step S1926), and determines that the first state is transferable to the wired rewrite session (step S1922). The microcomputer 33 ends the wireless rewrite program with the default session transfer. The microcomputer 33 terminates the rewriting exclusion process at the time of generation of the wired rewriting request, and returns to the state transition management process in the first state.

When the microcomputer 33 determines that the wireless rewrite session priority condition is satisfied (S1924: "YES"), it discards the wired rewrite request and continues the wireless rewrite (S1927). That is, the microcomputer 33 maintains the second state in the wireless rewrite session, continues execution of the wireless rewrite program, and determines that the first state cannot be transferred to the wired rewrite session (S1928). The microcomputer 33 terminates the rewriting exclusion processing at the time of generation of the wired rewriting request, and restores the state transition management processing to the first state.

When the microcomputer 33 determines that the rewriting session priority condition is satisfied during the transition (S1925: "yes"), the wired rewrite request is discarded and the wireless rewrite is continued (S1927). That is, the microcomputer 33 maintains the second state in the wireless rewrite session, continues execution of the wireless rewrite program, and determines that the first state cannot be transferred to the wired rewrite session (S1928). The microcomputer 33 terminates the rewriting exclusion process at the time of generation of the wired rewriting request, and returns to the state transition management process in the first state. The microcomputer 33 executes the rewriting exclusion processing at the time of generation of the wired rewriting request in this manner, thereby exclusively controlling the wired rewriting session and the wireless rewriting session so that the sessions are not established at the same time.

When the microcomputer 33 returns to the state transition management processing in the first state, it determines whether or not the transfer to the wired rewrite session is possible as a result of the rewrite exclusive processing at the time of generation of the wired rewrite request (S1912). When the microcomputer 33 determines that the wired rewrite session is transferable by determining that the rewrite exclusive processing at the time of generation of the wired rewrite request is transferable (S1912: YES), the microcomputer shifts the first state from the default session to the wired rewrite session via the wired diagnosis session (S1913), interrupts the vehicle control processing, and starts the wired rewrite processing (S1914). The microcomputer 33 ends the vehicle control program in association with the wired rewrite session transfer.

The microcomputer 33 determines that the completion condition of the wired rewrite processing is satisfied (S1915), and if it is determined that the completion condition of the wired rewrite processing is satisfied (S1915: YES), the wired rewrite processing is completed (S1916), and the first state is transferred from the wired rewrite session to the default session (S1917). Here, the conditions for completing the wired rewrite processing include, for example, a case where all the writing of the application program is completed and integrity verification is performed.

When the microcomputer 33 determines that the wired rewrite session cannot be transferred by the rewrite exclusive process at the time of generation of the wired rewrite request and determines that the transfer cannot be performed (S1912: NO), it does not transfer the first state from the default session to the wired rewrite session via the wired diagnostic session. That is, the microcomputer 33 maintains the first state in the default session. When the microcomputer 33 determines that the condition for completing the state transition management is satisfied (yes in S1905), it completes the state transition management processing of the first state.

In the above description, the case has been described in which the microcomputer 33 interrupts the wireless rewrite in the second state if it is determined that the wired rewrite session priority condition is satisfied while the wireless rewrite session is being transferred in the second state in the rewrite exclusion processing at the time of generation of the wired rewrite request, but it may be determined whether or not to interrupt the wireless rewrite session based on the non-rewrite margin of the wireless rewrite.

If the microcomputer 33 determines that the wired rewrite session priority condition is satisfied (S1923: "yes") while the transition to the wireless rewrite session is being performed in the second state (S1921: "yes"), it determines whether or not the unwritten margin for the wireless rewrite is a predetermined amount or more (for example, 20% or more) in the wireless rewrite session during the transition (S1931). When the microcomputer 33 determines that the non-rewriting margin of the wireless rewriting is equal to or greater than the predetermined amount (S1931: "YES"), the second state is transferred from the wireless rewriting session to the default session, and the wireless rewriting is interrupted (S1926). The microcomputer 33 ends the wireless rewrite program as it transitions to the default session. When the microcomputer 33 determines that the amount of non-rewriting margin for wireless rewriting is not equal to or greater than the predetermined amount (S1931: NO), the wired rewriting request is discarded and wireless rewriting is continued (S1927). That is, if the remaining time until the wireless rewriting is completed is relatively long, the microcomputer 33 interrupts the wireless rewriting session, but if the remaining time until the wireless rewriting is completed is relatively short, the microcomputer 33 continues the wireless rewriting session without interruption.

(19-2) State transition management processing of the second State

When the microcomputer 33 detects that the power is turned on and starts the state transition management processing in the second state, it determines the rewrite completion flag and determines whether or not the previous rewrite of the application has been completed normally (S1941). If the microcomputer 33 determines that the rewrite completion flag is positive, it determines that the previous rewrite of the application program has been completed normally (S1941: "YES"), and then shifts the second state to the default session (S1942). That is, the microcomputer 33 shifts the second state to the default session to execute the vehicle control program, thereby starting the vehicle control process.

When the vehicle control processing is started, the microcomputer 33 determines whether or not a wireless rewrite request is generated (S1943), and determines that the completion condition of the state transition management is satisfied (S1944). If the microcomputer 33 determines that a wireless rewrite request is generated during execution of the vehicle control processing (S1943: yes), it starts a rewrite exclusive processing at the time of generation of the wireless rewrite request (S1944). When the microcomputer 33 starts the rewriting exclusive process at the time of generation of the wireless rewriting request, it is determined whether or not the transition to the wired rewriting session is in progress in the first state, that is, whether or not the first state is the wired rewriting session (S1961). If the microcomputer 33 determines that the transition to the wired rewrite session is not in the process in the first state (S1961: no), it determines that the transition to the wireless rewrite session is possible (S1962). The microcomputer 33 ends the rewriting exclusion processing at the time of generation of the wireless rewriting request, and returns to the state transition management processing in the second state.

When the microcomputer 33 determines that the transition to the wired rewrite session is in the first state (S1961: yes), it determines which of the wired rewrite session and the wireless rewrite session is to be prioritized and performs the exclusive control. Specifically, the microcomputer 33 determines whether any of the wireless rewriting session priority condition, the wired rewriting session priority condition, and the in-transit rewriting session priority condition is satisfied (S1963 to S1965).

When the microcomputer 33 determines that the wireless rewrite session priority condition is satisfied (S1963: "YES"), it shifts the wired rewrite session to the default session in response to the session restoration request in the first state to interrupt the wired rewrite (S1966), and determines that the second state can be shifted to the wireless rewrite session (S1962). The microcomputer 33 ends the wired rewrite program with the transition to the default session. The microcomputer 33 ends the rewriting exclusion processing at the time of generation of the wireless rewriting request, and returns to the state transition management processing in the second state.

When the microcomputer 33 determines that the wired rewrite session priority condition is satisfied (S1964: "YES"), it discards the wireless rewrite request and continues the wired rewrite (S1967). That is, the microcomputer 33 maintains the first state in the wired rewrite session, continues execution of the wired rewrite program, and determines that the second state cannot be transferred to the wireless rewrite session (S1968). The microcomputer 33 ends the rewriting exclusion processing at the time of generation of the wireless rewriting request, and returns to the state transition management processing in the second state.

When the microcomputer 33 determines that the rewriting session priority condition is satisfied during the transfer (S1965: "yes"), the wireless rewriting request is discarded and the wired rewriting is continued in this case as well (S1967). That is, the microcomputer 33 maintains the first state in the wired rewrite session, continues the execution of the wired rewrite program, and determines that the second state cannot be transferred to the wireless rewrite session (S1968). The microcomputer 33 ends the rewriting exclusion processing at the time of generation of the wireless rewriting request, and returns to the state transition management processing in the second state. By executing the rewriting exclusion process at the time of generation of the wireless rewriting request in this manner, the microcomputer 33 exclusively controls the wired rewriting session and the wireless rewriting session, and does not establish the sessions at the same time.

When the microcomputer 33 returns to the state transition management processing in the second state, it determines whether or not the transition to the wireless rewrite session is possible as a result of the rewrite exclusive processing at the time of generation of the wireless rewrite request (S1945). When the microcomputer 33 determines that the transfer to the wireless rewrite session is possible by determining that the rewrite exclusive processing at the time of the wireless rewrite request generation is possible (yes in S1945), the microcomputer shifts the second state from the default session to the wireless rewrite session (S1946), executes the wireless rewrite program, and starts the wireless rewrite processing (S1847). The microcomputer 33 judges that the completion condition of the wireless rewrite processing is satisfied (S1948), and if it is judged that the completion condition of the wireless rewrite processing is satisfied (S1948: "YES"), the wireless rewrite processing is terminated (S1949), and the second state is shifted from the wireless rewrite session to the default session (S1950). The microcomputer 33 ends the wireless rewrite program with the transition to the default session. Here, the completion condition of the wireless rewrite processing means, for example, a case where the writing of the application is completed and the integrity verification is performed.

If the microcomputer 33 determines that the transfer to the wireless rewrite session is impossible by determining that the rewrite exclusive processing at the time of the generation of the wireless rewrite request cannot be performed and determines that the transfer is impossible (S1945: "no"), the microcomputer does not transfer the second state from the default session to the wireless rewrite session. That is, the microcomputer 33 maintains the second state in the default session. If the microcomputer 33 determines that the condition for completing the state transition management is satisfied (S1951: yes), it ends the state transition management processing of the second state.

As described above, the case where the application execution unit 105a can independently (simultaneously) execute the program related to the special processing using wired and the program related to the special processing using wireless has been described, but a configuration in which the wired diagnostic program and the wireless diagnostic program are shared may be adopted as shown in fig. 165. The vehicle control program is configured to be disposed in the application area as a first program, and the diagnostic programs (the wired diagnostic program and the wireless diagnostic program) and the wireless rewrite program are configured to be disposed in the application area as a second program. The wired rewrite program may be disposed in the application area as the second program or disposed in the boot area as the third program. The application execution unit 105a executes the first program and the second program at the same time. That is, the application execution unit 105a controls the vehicle control program and the shared diagnostic program to be executable at the same time. On the other hand, the application execution unit 105a exclusively controls execution of each program constituting the second program. That is, the control is performed by any one of the wired diagnostic program, the wireless rewrite program, and the wired rewrite program.

As shown in fig. 166, the application execution unit 105a manages a default state (default session), a diagnostic state (diagnostic session), a wired rewrite state (wired rewrite session), and a wireless rewrite state (wireless rewrite session), and manages internal states of operations as states. The state managed here is not independently managed by wire and wireless, but is managed as one state in a mixed manner.

In this configuration, the application execution unit 105a executes the vehicle control program and starts execution of the diagnostic program. The application execution unit 105a executes the vehicle control program and starts execution of the wireless rewriting program and the wired rewriting program. On the other hand, the application execution unit 105a exclusively controls the execution of the wireless diagnostic program and the wired diagnostic program. The application execution unit 105a also exclusively controls the execution of the wired diagnostic program and the wireless diagnostic program, and the wired rewriting program and the wireless rewriting program. That is, the application execution unit 105a exclusively controls execution of each program constituting the second program.

Here, when the wired rewrite program is arranged in the boot area as the third program, the application execution unit 105a exclusively executes and controls the third program and the first and second programs. That is, when the wired rewrite program is executed, the first program and the second program are terminated and the program operates in the exclusive mode.

As shown in fig. 166, when the application execution unit 105a generates a diagnosis request, the execution of the vehicle control program is continued, and the process shifts to a diagnosis session to start the execution of the diagnosis program. In this state, when a wireless rewrite request is generated, the application execution unit 105a terminates the diagnostic program, shifts to a wireless rewrite session, and starts execution of the wireless rewrite program. Execution of the vehicle control program continues. On the other hand, when the wired rewrite request is generated, the application execution unit 105a ends the diagnostic program and the vehicle control program, transitions to the wired rewrite session, and starts the execution of the wired rewrite program.

Even if the wireless rewrite program is disposed inside the diagnostic program, if the state is shifted from the diagnostic session to the wireless rewrite session during execution of the vehicle control program and the diagnostic program, the application execution unit 105a interrupts execution of the vehicle control program and the diagnostic program and then starts execution of the wireless rewrite program. In addition, processing can be continued without accompanying a session.

If the wired rewrite program is disposed outside the diagnostic program, the application execution unit 105a stops execution of the vehicle control program and the wireless diagnostic program and starts execution of the wired rewrite program when the state transitions from the diagnostic session to the wired rewrite session during execution of the vehicle control program and the diagnostic program. That is, the application execution unit 105a cannot execute the vehicle control, the diagnosis by the ECU19 wired or wireless, and the rewriting of the application program by the wired line at the same time, and can execute the rewriting of only the application program by the wired line.

As described above, the ECU19 executes the state transition management process in the first state and the state transition management process in the second state by performing the session establishment process, manages the state transition of each of the first state and the second state, and establishes a default session in the first state or a wired diagnosis session and a wireless rewrite session in the second state non-exclusively. The vehicle control or the diagnosis of ECU19 and the request for rewriting of the program by wireless are controlled to execute the vehicle control program or the diagnosis program and the wireless rewriting program of ECU19 non-exclusively, and can appropriately mediate various requests from the outside.

In addition, the ECU19 exclusively establishes the wired rewrite session and the wireless rewrite session. The wired rewrite program and the wireless rewrite program can be controlled to be exclusively executed, and the rewrite of the program by the wired and the rewrite of the program by the wireless can be appropriately mediated.

In addition, when the wired rewrite session priority condition is satisfied, the ECU19 gives priority to the wired rewrite session over the wireless rewrite session. By setting wired rewrite session priority conditions in advance, it is possible to execute rewriting of a program by wired in priority over rewriting of a program by wireless. For example, rewriting of a program using a wire instructed by an installer such as a dealer can be performed with priority over rewriting of a program using a wireless instruction instructed by a user of a vehicle.

Further, when the wireless rewrite session priority condition is satisfied, the ECU19 gives priority to the wireless rewrite session over the wired rewrite session. By setting the wireless rewriting session priority condition in advance, it is possible to execute rewriting of a program by wireless preferentially to rewriting of a program by wired. For example, rewriting of a program instructed by a user of a vehicle using wireless can be performed with priority over rewriting of a program instructed by a setter such as a dealer using wired.

Further, when the rewrite session priority condition during the transfer is satisfied, the ECU19 gives priority to the rewrite session during the transfer. By setting the rewriting session priority condition during migration in advance, rewriting during migration can be executed with priority. That is, the first one of the wired rewrite and the wireless rewrite can be continued without interruption.

In the configuration having the application area on the 2-plane, the vehicle control program, the diagnostic program, and the wireless rewrite program are arranged in each application area, and the vehicle control program or the diagnostic program, and the wireless rewrite program are executed in parallel (simultaneously). By designing the memory structure of the flash memory 30d, the vehicle control program, the diagnostic program, and the wireless rewrite program can be executed in parallel.

When the wireless rewrite request is determined during execution of the vehicle control program or the wired diagnostic program, the execution of the vehicle control program or the wired diagnostic program is continued, and the wireless rewrite program is executed. When a wireless rewrite request is generated while the vehicle control program or the wired diagnostic program is being executed, the vehicle control program or the wired diagnostic program and the wireless rewrite program can be executed in parallel (simultaneously).

When the vehicle control request or the wired diagnosis request is determined during execution of the wireless rewriting program, the execution of the wireless rewriting program is continued, and the vehicle control program or the wired diagnosis program is executed. When a vehicle control request or a wired diagnosis request occurs during execution of the wireless rewriting program, the wireless rewriting program and the vehicle control program or the wired diagnosis program can be executed in parallel (simultaneously).

When the wired rewrite request is determined while the vehicle control program or the wireless diagnostic program is being executed, the execution of the vehicle control program or the wireless diagnostic program is stopped, and the wired rewrite program is executed. When a wired rewrite request is generated during execution of a vehicle control program or a wireless diagnostic program, only the wired rewrite program can be exclusively executed.

In the case of a reprogramming firmware embedded type in which reprogramming firmware is embedded, a rewriting program is executed using firmware disposed in an application area. The rewriting process of the application program on the non-operating surface can be executed without downloading the re-programmed firmware from the outside.

In the case of a firmware re-installation download type in which re-installation is downloaded from the outside, the rewriting program is executed using the firmware downloaded from the outside. The capacity of the rewriting program in the application area is reduced, and the rewriting process of the application program on the non-operating surface can be executed.

The description has been given of the double-sided memory having the application area on the substantial 2-side, but the single-sided suspend system memory and the external memory having the application area on the dummy 2-side can also be applied.

The differential overwrite is described in which new data is generated from old data and differential re-encoded data, but the present invention can also be applied to a case of all overwrite in which old data is deleted and new data is written.

The case where the application program of the ECU19 is rewritten was described, but the case where the application program of the CGW13 is rewritten can also be applied. That is, the flash memory 26d of the CGW13 may be configured on both sides and have the same configuration as the flash memory 30d of the ECU19, and the microcomputer 26 may have the same function as the microcomputer 33 of the ECU 19.

(20) Retry point determination process

The process of determining the retry point will be described with reference to fig. 170 to 174. The vehicle program rewriting system 1 performs a process of specifying a retry point in the rewriting target ECU 19. The retry point is information indicating where the processing is completed in order to restart the interrupted write data from the middle of writing when the write data is written in a plurality of times and the write data is interrupted. As the case of interrupting the writing of the written data, there are a case where cancellation by a user operation occurs, a case where an abnormality such as communication interruption occurs, and a case where the ignition is switched from off to on in a stopped state, for example.

In the ECU19, the program rewriting unit 102 shares a series of processes associated with the rewriting of the application program with a plurality of rewritten programs. The program rewriting unit 102 includes a first rewriting program for performing the first processing and a second rewriting program for performing the second processing, and sequentially executes the respective rewriting programs. The first processing performed by the first rewrite program is, for example, memory erase processing for erasing data of the flash memory, data write processing for writing write data, or the like. The second processing performed by the second rewrite program is, for example, verification processing, falsification check processing, or the like.

As shown in fig. 170, the ECU19 includes a first processing flag setting unit 106a, a second processing flag setting unit 106b, and a retry point specifying unit 106c in the retry point specifying unit 106. When the program rewriting unit 102 executes the first rewrite program, the first process flag setting unit 106a determines whether or not the program rewriting unit 102 has completed the first process by the first rewrite program, and sets a first process flag indicating the determination result. When the first process flag setting unit 106a determines that the program rewriting unit 102 has completed the first process, it sets the first process flag to "OK".

When the program rewriting unit 102 executes the second rewriting program, the second processing flag setting unit 106b determines whether or not the program rewriting unit 102 has completed the second processing by the second rewriting program, and sets a second processing flag indicating the determination result. When the second process flag setting unit 106b determines that the program rewriting unit 102 has completed the second process, it sets the second process flag to "OK".

When a part of the processing associated with the rewriting of the program is interrupted, the retry point specification unit 106c specifies the retry point at which the program rewriting unit 102 retries the rewriting of the application program, based on the first processing flag and the second processing flag. Further, the retry point specifying unit 106c stores the write amount of the update data until the interruption in advance, and when the processing related to rewriting the program is restarted, requests the CGW13 to transmit the update data based on the write amount of the stored update data. As shown in fig. 207, the first processing flag and the second processing flag are stored in the same block of the flash memory of the rewrite target ECU 19.

Next, the operation of the retry point determination unit 106 of the rewrite target ECU19 will be described with reference to fig. 172 to 174. The rewrite target ECU19 executes a retry point determination program and performs a retry point determination process. As the retry point determination process, rewrite target ECU19 performs a process flag setting process and a process flag determination process. Hereinafter, each process will be described.

(20-1) setting Process of Process flag

When the rewrite target ECU19 starts the process of setting the process flag, it determines whether or not the preliminary process before rewriting the application program is completed (S2001). When the rewrite target ECU19 determines that the preprocessing before the rewrite of the application is completed (S2001: yes), it sets the first processing flag to "NG" and the second processing flag to "NG" and stores them (S2002, corresponding to the first processing flag setting step and the second processing flag setting step).

When receiving the write data from the CGW13, the ECU19 to be rewritten starts the first process (S2003) and determines whether or not the first process is completed (S2004). When the rewrite target ECU19 determines that the first process is completed (S2004: yes), it sets the first process flag to "OK" and stores it while maintaining the second process flag to "NG" (S2005, corresponding to the first process flag setting step and the second process flag setting step). The rewrite target ECU19 also stores a write completion address indicating where the flash memory has been written.

When the rewrite target ECU19 starts the second process such as the notification of completion of writing to the CGW13 (S2006), it determines whether or not the second process is completed (S2007). When the rewrite target ECU19 determines that the second process is completed (S2007: yes), it sets and stores the second process flag to "OK" while maintaining the first process flag to "OK" (S2008, corresponding to the first process flag setting step and the second process flag setting step), and ends the process of setting the process flag.

(20-2) Process flag determination processing

When the processing flag determination process is started from the sleep or stop state, the rewrite target ECU19 is started by the boot program (S2011), and reads the first processing flag and the second processing flag from the flash memory to perform the determination (S2012 to S2015).

When the rewrite target ECU19 determines that the first process flag is "NG" and the second process flag is "NG" (S2012: "yes"), it specifies the retry point as the start of the first process, notifies the CGW13 of a retry request from the start of the first process (S2016, corresponding to a retry point specifying step), and ends the process of specifying the retry point. That is, the rewrite target ECU19 requests the CGW13 to distribute write data. At this time, the rewrite target ECU19 also notifies the CGW13 of the write completion address read from the flash memory, and thereby the CGW13 determines which of the divisionally distributed write data can be distributed. When the rewrite target ECU19 determines that the first process flag is "NG" and the second process flag is "OK" (S2013: yes), it also determines the retry point as the start of the first process in this case (S2016, corresponding to the retry point determination step), notifies the CGW13 of a retry request from the start of the first process (S2017), and ends the process of determining the process flag.

When the rewrite target ECU19 determines that the first processing flag is "OK" and the second processing flag is "NG" (S2014: "yes"), it specifies the retry point as the start of the second processing (S2018, corresponding to the retry point specifying step), notifies the CGW13 of a retry request from the start of the second processing (S2019), and ends the processing flag determination processing. As the second process, the ECU19 notifies, for example, the CGW13 of an address to which writing is completed.

When the rewrite target ECU19 determines that the first processing flag is "OK" and the second processing flag is "OK" (S2015: "yes"), it notifies the CGW13 of the completion of the processing related to the rewriting of the application (S2020), and ends the processing for determining the processing flag. When the CGW13 distributes the write data in divided manner, the rewrite target ECU19 sets the retry point in each divided write data unit.

As described above, the rewriting ECU19 sets the first processing flag indicating whether or not the first processing is completed, sets the second processing flag indicating whether or not the second processing is completed by performing the retry point specification processing, and specifies the retry point based on the first processing flag and the second processing flag. For example, when the rewrite target ECU19 is restarted in a state where the first process is completed and the second process is not completed, rewriting of the same write data can be suppressed.

When the data amount of the write data for which writing is completed, i.e., which byte the writing of the write data is completed is stored in advance and the writing of the write data is to be restarted, the rewrite target ECU19 requests the CGW13 to transmit the write data of the second byte. When the rewriting ECU19 stores in advance which byte the write data has been written to and restarts the writing, it requests the CGW13 to transmit the write data from the several bytes, so that the CGW13 can avoid retransmitting the transmitted write data when the restarting is performed, and the rewriting ECU19 can write the write data from the next write area in which the write data has been written. When the write of the write data is restarted, the rewrite target ECU19, which does not have the function of storing the byte to which the write of the write data is completed, requests the CGW13 to transmit the write data from the beginning.

(21) Synchronous control processing of progress states

The synchronization control processing of the progress state is explained with reference to fig. 175 to 180. The vehicle program rewriting system 1 performs a process of controlling the progress state synchronously with the CGW13 and the center device 3. The vehicle program rewriting system 1 includes a portable terminal 6 and an in-vehicle display 7 as a display terminal 5 that can be operated by a user. The in-vehicle display 7 displays a progress screen indicating the progress of rewriting in cooperation with the CGW 13. The portable terminal 6 is connected to the center apparatus 3, and displays a progress screen indicating the progress of rewriting provided by the center apparatus 3. The CGW13 and the center device 3 perform a process of controlling the progress state in synchronization with each other in order to synchronize the information displayed on the mobile terminal 6 and the in-vehicle display 7.

As shown in fig. 30, for example, if the ECU19 to be rewritten is the ECU19 equipped with a dual-sided memory, the steps related to rewriting of the application are performed based on an activity notification phase in which the user agrees to rewrite the application, a download phase in which the write data is downloaded from the center device 3 to the DCM12, an installation phase in which the write data is distributed from the CGW13 to the ECU19 to be rewritten, and an activation phase in which the boot plane at the next boot is switched from the old plane to the new plane. That is, the user operates the mobile terminal 6 and the in-vehicle display 7 to advance a series of steps related to rewriting of the application, such as granting execution of each stage.

As shown in fig. 175, CGW13 includes a first progress state determination unit 88a, a first progress state transmission unit 88b, a second progress state acquisition unit 88c, and a first display instruction unit 88d in the progress state synchronization control unit 88. The first progress state determination unit 88a determines a first progress state relating to rewriting of the program, for example, a progress state such as an activity notification stage, a download stage, an installation stage, and an activation stage. The activity notification phase is a phase until the user agrees to receive an activity, display the screens shown in fig. 32 to 33, and the like. The download stage is a stage in which the screens shown in fig. 34 to 37 are displayed and the download is executed with the user's approval. The installation stage is a stage in which the downloading is completed, and the screens shown in fig. 38 to 42 are displayed, and the installation is executed with the user's approval. The activation phase is a phase in which the screen shown in fig. 43 is displayed, and activation is performed with the approval of the user.

When the user selects "approve execution of the program update" on the in-vehicle display 7 and performs an operation to advance the step further, while the user is in the vehicle, the first progress state determination unit 88a determines the operation performed by the user on the in-vehicle display 7 by transmitting a user operation signal from the in-vehicle display 7 to the CGW13, and determines the first progress state. In this case, selection of "approval of execution of program update" corresponds to operation of any of "download start" button 503a shown in fig. 70, "immediate update" button 506a shown in fig. 75, "reservation update" button 506b, and "OK" button 508b shown in fig. 79. When the first progress state determination unit 88a determines the first progress state, it manages the determined first progress state as the current progress state.

When the first progress state is determined by the first progress state determining unit 88a, the first progress state transmitting unit 88b transmits the determined first progress state to the center device 3 and to each in-vehicle display device such as the in-vehicle display 7. The second progress state acquiring unit 88c acquires the second progress state relating to rewriting of the program from the center apparatus 3. When the first progress state is determined by the first progress state determination unit 88a and the second progress state is acquired by the second progress state acquisition unit, the first display instruction unit 88d instructs to create a content that can be displayed on the in-vehicle display 7 based on the determined first progress state and the acquired second progress state.

Here, in the case where the second progress state acquisition unit 88c acquires the second progress state from the center apparatus 3, if the second progress state is at a stage earlier than the current progress state, the first progress state determination unit 88a manages the second progress state as the current progress state. I.e. the first state of progress is updated with the value of the second state of progress. Then, the first progress state transmitting unit 88b transmits the current progress state, i.e., the first progress state, to the center apparatus 3. For example, when the first progress state is "waiting for a download phase" and the user approval operation in the mobile terminal 6 is performed, the second progress state acquiring unit 88c acquires "download execution phase" as the second progress state from the center apparatus 3. Since the "download execution intermediate stage" acquired from the center apparatus 3 is a stage before the current progress state, the first progress state determination unit 88a updates the current progress state, that is, the first progress state, with the value of the second progress state, and transmits the updated first progress state to the center apparatus 3 and to various in-vehicle display devices such as the in-vehicle display 7. As the first progress state, "download completion X%" indicating the progress degree of the download may be transmitted in addition to "download execution middle stage".

When the user operation signal is generated in the in-vehicle display 7, the first display instructing section 88d instructs the content creation based on the first progress state determined by the first progress state determining section 88 a. When the user operation signal is generated in the mobile terminal 6, the first display instruction unit 88d instructs the content creation based on the second progress state acquired by the second progress state acquisition unit 88 c. In addition, if a configuration is adopted in which the first progress state determined by the first progress state determining unit 88a is always the current progress state, that is, a configuration is adopted in which the host apparatus 11 manages the current progress state, the first display instructing unit 88d may instruct the content creation based on the first progress state.

As shown in fig. 176, the center device 3 includes a second progress state determination unit 53a, a second progress state transmission unit 53b, a first progress state acquisition unit 53c, and a second display instruction unit 53d in the synchronization control unit 53 for the progress state. The second progress state determination unit 53a determines the second progress state relating to rewriting of the program, for example, determines a progress state such as an activity notification stage, a download stage, an installation stage, and an activation stage. When the user selects "approve execution of the program update" in the portable terminal 6 during the alighting (parking), the user performs an operation to advance the stage to the next step, and if the portable terminal 6 is in an environment where the data communication with the center apparatus 3 is possible, the second progress state determination unit 53a receives the user operation signal transmitted from the portable terminal 6.

The second progress state determination section 53a determines the second progress state based on the current progress state, which is the first progress state, received by the first progress state acquisition section 53c from the host apparatus 11 up to that point and the user operation signal. For example, when the current progress state is "waiting for installation stage", the second progress state determination unit 53a receives a user operation signal indicating "approval", and determines that the current progress state is "installation execution stage". The second progress state determination unit 53a may determine that "there is user approval in the installation waiting stage". If the center apparatus 3 and the DCM12 are in an environment where data communication is possible, a user operation signal of the mobile terminal 6 is transmitted from the center apparatus 3 to the DCM 12. Further, by transmitting a user operation signal from DCM12 to CGW13, CGW13 can determine an operation performed by the user in mobile terminal 6, and determine the progress state.

When the second progress state determination unit 53a determines the second progress state, the second progress state transmission unit 53b transmits the determined second progress state to the host device 11. The first progress state acquiring unit 53c acquires the first progress state relating to rewriting of the program from the host apparatus 11, and manages the first progress state as the current progress state. As the current progress state, the second progress state may also be updated with the value of the first progress state. When the second progress state determination unit 53a determines the second progress state and the first progress state acquisition unit 53d acquires the first progress state, the second display instruction unit 53d instructs the mobile terminal 6 to create a content that can be displayed based on the determined second progress state and the acquired first progress state.

For example, if only the user operation signal of the mobile terminal 6 is received, the second progress state determined by the second progress state determining section 53a and the first progress state acquired by the first progress state acquiring section 53d indicate the same progress state. Therefore, the second display instruction unit 53d may instruct the content creation based on the second progress state. Then, when the user operation signal of the in-vehicle display 7 is generated, the second display instruction unit 53d instructs the creation of the content based on the acquired first progress state.

For example, when the mobile terminal 6 receives the SMS as the progress status signal from the center apparatus 3, the user selects the URL recorded in the SMS, connects to the center apparatus 3, and displays a screen of a predetermined stage provided by the center apparatus 3.

Next, the operations of the synchronization control unit 88 for the progress state in CGW13 and the synchronization control unit 53 for the progress state in the center device 3 will be described with reference to fig. 177 to 180.

As shown in fig. 177, the master device 11 and the center device 3 synchronize the display of the progress status of the stages in the mobile terminal 6 and the in-vehicle display 7 by transmitting and receiving the first progress status signal and the second progress status signal. That is, when the first progress state, which is the current progress state, is updated, the host apparatus 11 transmits a first progress state signal to the center apparatus 3 and also transmits the first progress state signal to various in-vehicle display devices such as the in-vehicle display 7. The center apparatus 3 transmits the first progress status signal as the current progress status to the mobile terminal 6. Thereby, if the mobile terminal 6 is able to access the center apparatus 3, the display of the progress state of the stages in the mobile terminal 6 and the in-vehicle display 7 is synchronized. The center device 3 transmits a second progress state signal to the main device 11 based on the user approval operation of the mobile terminal 6, thereby synchronizing the display of the progress states of the stages in the mobile terminal 6 and the in-vehicle display 7 if the mobile terminal 6 can access the center device 3.

The master device 11 that has acquired the second progress state signal may transmit the first progress state to each of the in-vehicle display devices such as the center device 3 and the in-vehicle display 7 after updating the first progress state that is the current progress state. That is, the master device 11 transmits the current progress state to each of the in-vehicle display devices such as the center device 3 and the in-vehicle display 7, thereby realizing the function as a stage management device. Here, the second progress state signal transmitted from the mobile terminal 6, the in-vehicle display 7, and the center apparatus 3 may be a notification indicating a certain stage, but may be a notification indicating that there is a notification indicating that the user approves the operation or a notification indicating that a button is operated.

When the synchronization control processing of the progress state is started, CGW13 transmits the distribution specification data to in-vehicle display 7 (S2101). The distribution specification data includes text and content to be displayed to the user on the in-vehicle display 7. The CGW13 determines whether the user has performed an operation on the in-vehicle display 7 or the mobile terminal 6 based on the notification from the in-vehicle display 7 or the center apparatus 3 (S2102). When CGW13 determines that the user has operated the in-vehicle display 7 or the mobile terminal 6 (S2102: "yes"), it determines which stage the operation was based on the first progress state (S2103 to S2106, corresponding to a first progress state determination step).

If the CGW13 determines that the process is the activity notification stage (S2103: yes), the process of the activity notification stage is performed (S2107), and a first progress state signal indicating the progress state of the process of the activity notification stage is transmitted to the in-vehicle display 7 and the center device 3 (S2111). The process of the activity notification phase is to acquire an input operation or the like by the user with respect to the in-vehicle display 7 or the mobile terminal 6.

The CGW13 acquires conditions such as the date and time and the place of execution permission, etc., in addition to the approval or disapproval of the update of the program, from the in-vehicle display 7 or the mobile terminal 6 via the center device 3, for example. When the CGW13 acquires an input operation by the user of the content agreed to the mobile terminal 6 from the center apparatus 3 via the DCM12, the CGW13 notifies the in-vehicle display 7 of the progress of the content agreed to the mobile terminal. On the other hand, when the CGW13 acquires from the in-vehicle display 7 an input operation by the user that the content agreed on the in-vehicle display 7, it notifies the center apparatus 3 of the progress of the content for which agreement has been completed.

If the CGW13 determines that the download stage is the download stage (S2104: yes), the process of the download stage is performed (S2108), and a first progress state signal indicating the progress state of the process of the download stage is transmitted to the in-vehicle display 7 and the center device (S2111). The processing in the download phase refers to, for example, calculating that the download of the distribution package is completed by several%.

CGW13 decides that the download is completed by several% based on the notification from center apparatus 3. The CGW13 notifies the in-vehicle display 7 and the center apparatus 3 of the progress indicating that the download is completed by several%. CGW13 repeats these processes until the download of the distribution package is complete. Upon completion of the download, the CGW13 notifies the in-vehicle display 7 and the center device 3 of the progress of the content for which the download phase is completed.

If the CGW13 determines that the mounting stage is the mounting stage (S2104: yes), the mounting stage is processed (S2108), and a progress state signal indicating the progress state of the mounting stage is transmitted to the in-vehicle display 7 and the DCM12 (S2111). The process at the mounting stage is, for example, calculation of how many% of the mounting to the rewrite target ECU19 is completed.

CGW13 determines that the mounting is completed by several% based on the notification from ECU19 to be rewritten. The CGW13 notifies the in-vehicle display 7 and the center device 3 of progress indicating that the installation is completed by several%. The CGW13 repeats these processes until the mounting of the ECU19 to all the rewriting targets is completed. When the mounting is completed, the CGW13 notifies the in-vehicle display 7 and the center device 3 of the progress of the content of the completion of the mounting stage.

If the CGW13 determines that the activation phase is established (S2104: yes), the activation phase processing is performed (S2108), and a progress state signal indicating the progress state of the activation phase processing is transmitted to the in-vehicle display 7 and the DCM12 (S2111, corresponding to the first progress state transmission step). The process in the activation phase is, for example, a calculation of the completion of activation of one or more rewrite target ECUs 19 belonging to the same group by several%. CGW13 determines that activation is completed by several% based on the notification from rewrite target ECU 19. CGW13 informs the in-vehicle display 7 and the central device of the progress indicating that activation was completed by a few%.

CGW13 determines whether or not the activation phase is completed (S2112), and if it is determined that the activation phase is completed (S2112: yes), ends the synchronization control processing for the progress state. If CGW13 determines that the activation phase has not been completed (S2112: no), the flow returns to S2102. The CGW13 advances the processing of each stage, and the calculation processing is completed by several percent (S2107 to S2110). The CGW13 periodically transmits the phase and the content of which X% is completed as the first progress status to the center apparatus 3 (S2111).

When the center apparatus 3 transmits the distribution specification data and starts the synchronization control process of the progress state, it monitors the reception of the first progress state signal transmitted from the DCM12 (S2121). When the center device 3 determines that the first progress status signal is received from the DCM12 (S2121: yes), it permits access from the mobile terminal 6 (S2122), and determines which stage the stage identified from the first progress status signal is (S2123 to S2126).

When the center device 3 determines that the process is the activity notification stage (S2123: YES), the process of the activity notification stage is performed (S2127). That is, the center apparatus 3 creates a screen of the event notification phase, and transmits a display instruction signal instructing display of the screen of the event notification phase to the mobile terminal 6, and the mobile terminal 6 displays the screen of the event notification phase by connecting to the center apparatus 3.

If the center device 3 determines that the download stage is the present (yes in S2124), the center device performs a process of the download stage (S2128). That is, the center apparatus 3 creates a screen at the download stage, transmits a display instruction signal for instructing display of the screen at the download stage to the portable terminal 6, and causes the portable terminal 6 to display the screen at the download stage by connection to the center apparatus 3. When the DCM12 notifies the center apparatus 3 of the progress indicating that the download is completed by several%, the screen of the download stage is updated.

If the center device 3 determines that the mounting stage is the mounting stage (S2125: yes), the mounting stage processing is performed (S2129). That is, the center device 3 creates a screen at the installation stage, and transmits a display instruction signal instructing display of the screen at the installation stage to the portable terminal 6, and the portable terminal 6 displays the screen at the installation stage by connection with the center device 3. When the DCM12 notifies the center apparatus 3 of the progress indicating that the installation is completed by several%, the screen at the installation stage is updated.

When the center device 3 determines that the activation phase is present (S2126: YES), the activation phase processing is performed (S2130). That is, the center apparatus 3 creates a screen for the active phase, and transmits a display instruction signal instructing display of the screen for the active phase to the mobile terminal 6, and the mobile terminal 6 displays the screen for the active phase by connection with the center apparatus 3. When the DCM12 notifies the center device 3 of the progress indicating that the activation is completed by several%, the screen of the activation stage is updated. When the user approves or the like the screens displayed in S2127 to S2130, the center device 3 transmits a second progress state signal to the host device 11 (S2131), and ends the synchronization control process of the progress state.

When the vehicle-mounted display 7 receives the distribution specification data from the CGW13, it starts the progress display process and monitors the reception of the progress state signal transmitted from the CGW13 (S2141). When the in-vehicle display 7 determines that the progress state signal is received from the CGW13 (S2141: yes), the user operation of the in-vehicle display 7 is permitted (S2142), and it is determined which stage the stage identified from the progress state signal is (S2143 to S2146).

When the in-vehicle display 7 determines that the event notification stage is present (yes in S2143), it displays a screen for the event notification stage using the text, content, and the like included in the distribution specification data (S2147). If the in-vehicle display 7 determines that the download stage is performed (S2144: YES), it displays a screen for the download stage (S2148). When the vehicle-mounted display 7 is notified of the progress indicating that the download is completed by several% from the CGW13, the screen at the download stage is updated.

If the in-vehicle display 7 is determined to be in the installation stage (S2145: YES), a screen of the installation stage is displayed (S2149). When the vehicle-mounted display 7 is notified of a progress indicating that the mounting is completed by several% from the CGW13, the screen at the mounting stage is updated. If the in-vehicle display 7 determines that the activation stage is present (S2146: YES), it displays an activation stage screen (S2150). When the vehicle-mounted display 7 is notified of a progress indicating that activation is completed by several% from the CGW13, the screen of the activation stage is updated.

As described above, the first progress state and the second progress state are transmitted and received between the master device 11 and the center device 3. For example, even if the mobile terminal 6 can access the center device 3, the in-vehicle display 7 cannot access the center device 3, and the first progress state and the second progress state are transmitted and received between the host device 11 and the center device 3, whereby the progress state of rewriting of the application program and the like can be appropriately synchronized among the plurality of display terminals.

(22) Transmission control processing of display control information, and (23) reception control processing of display control information

The transmission control processing of the display control information in the center apparatus 3 will be described with reference to fig. 181 and 182, and the reception control processing of the display control information in the host apparatus 11 will be described with reference to fig. 183 to 185.

As shown in fig. 181, the center device 3 includes a write data storage unit 54a (corresponding to an update data storage unit), a display control information storage unit 54b, and an information transmission unit 54c in the transmission control unit 54 for displaying control information. The write data storage unit 54a stores write data for the plurality of rewrite target ECUs 19 as one activity of rewriting the application program for the plurality of rewrite target ECUs 19. The display control information storage unit 54b stores distribution start data including display control information. The display control information is information necessary for displaying, on the in-vehicle display 7, display information related to rewriting of the application program in the rewriting target ECU19, and is a display control program and attribute information.

The display information is data constituting various screens (a moving notification screen, an installation screen, and the like) associated with rewriting of the application program. The display control program is a program for realizing a function equivalent to that of a web browser. The attribute information is information specifying display characters, display positions, colors, and the like. The information transmitting unit 54c transmits the write data stored in the write data storage unit 54a and the display control information stored in the display control information storage unit 54b to the host apparatus 11. The information transmitting unit 54c transmits the write data to the plurality of rewriting ECUs 19 to the host apparatus 11 as one packet. Here, the display control information may include stage identification information indicating at which stage the display is performed. For example, phase identification information indicating information which is displayed in which phase among the activity notification phase, the download phase, the installation phase, and the activation phase.

Next, the operation of the transmission control unit 54 for display control information in the center device 3 will be described with reference to fig. 182. The center device 3 executes a transmission control program of the display control information and performs a transmission control process of the display control information.

When the center apparatus 3 starts the transmission control processing of the display control information, it transmits the distribution start data to the CGW13 via the DCM12 (S2201, corresponding to the control information transmission step), and transmits the write data to the CGW13 via the DCM12 (S2202). The center apparatus 3 transmits the display information to the CGW13 via the DCM12 (S2203, corresponding to the display information transmission step), and ends the transmission control process of the display control information. In addition, when the center device 3 transmits the display control information corresponding to each of the activity notification stage, the download stage, the installation stage, and the activation stage, the display control information corresponding to each stage may be transmitted to the in-vehicle display 7 as a single file, or the display control information corresponding to the next stage may be transmitted to the in-vehicle display 7 every time the stage is completed. Here, the timing at which the center device 3 transmits the distribution start data may be configured to be transmitted in response to a request from the host device 11.

As shown in fig. 183, CGW13 includes an information receiving unit 89a, a rewriting instruction unit 89b, and a display instruction unit 89c in the reception control unit 89 for displaying control information. The information receiving unit 89a receives the write data and the display control information from the center device 3. When the information receiving unit 89a receives the write data from the center device 3, the rewrite instructing unit 89b instructs the rewrite target ECU19 to write the received write data. Before the rewrite instructing unit 89b instructs the rewrite target ECU19 to write the write data, the display instructing unit 89c instructs the in-vehicle display 7 to display the information related to the event using the display control information. The display instruction unit 89c may instruct the display of the information on the event as the history information after all the writing of the write data is completed.

Next, the operation of the display control information reception control unit 89 in the CGW13 will be described with reference to fig. 184. CGW13 executes a reception control program for the display control information, and performs reception control processing for the display control information. Thus, when the mobile terminal 6 and the in-vehicle display 7 are provided as the display terminal, these display modes can be brought close to each other, and convenience for the user can be improved.

When the CGW13 starts the reception control process of the display control information, the distribution specification data is received from the center apparatus 3 via the DCM12 (S2301, corresponding to a control information reception step). The write data is received from the center apparatus 3 via the DCM12 (S2302). The CGW13 receives the display information from the center apparatus 3 via the DCM12 (S2303, corresponding to a display information receiving step). CGW13 determines whether or not the display control information included in the distribution specification data from the center apparatus 3 is used (S2304). If the CGW13 determines to use the display control information (S2304: yes), it instructs the in-vehicle display 7 to display the display information using the display control information (S2305). That is, CGW13 instructs in-vehicle display 7 to display a screen related to rewriting of the application program using the display control information. The in-vehicle display 7 displays the display information using the display control information in accordance with an instruction from the CGW 13.

If the CGW13 determines that the display control information is not to be used (S2304: no), it instructs the in-vehicle display 7 to display the display information using the content stored in advance (S2306). That is, CGW13 instructs in-vehicle display 7 to display a screen related to rewriting of an application program using a content stored in advance. The in-vehicle display 7 displays the display information using the content stored in advance in accordance with the instruction from the CGW 13. In addition, when displaying the display information corresponding to each of the activity notification stage, the download stage, the installation stage, and the activation stage, the in-vehicle display 7 may receive the display control information corresponding to each stage from the center apparatus 3 as a whole, or may receive the display control information corresponding to the next stage from the center apparatus 3 every time the stage is ended.

As shown in fig. 185, if the in-vehicle display 7 does not have the function of a web browser and does not include the display control program but includes the attribute information in the specification data transmitted from the center apparatus 3 to the in-vehicle display 7 via the DCM12 and the CGW13, the in-vehicle display 7 uses the content and the frame stored in advance as the display information and displays the attribute information on the simple screen. The attribute information is data such as text, and a display position, a size, and the like thereof, and is the same as the attribute information used for the screen created by the center device 3. That is, the screen image displayed on the in-vehicle display 7 is different from the screen image created by the center apparatus 3 in the background, the bitmap, and the like, but the display content is the same as that of the center apparatus 3.

If the in-vehicle display 7 does not have the function of a web browser and the distribution specification data transmitted from the center apparatus 3 to the in-vehicle display 7 via the DCM12 and the CGW13 includes the display control program and the attribute information, the in-vehicle display 7 displays the display information on a screen equivalent to that of the center apparatus 3. Here, the display control program and the attribute information included in the distribution specification data are the same as those used in the screen created by the center apparatus 3.

If the in-vehicle display 7 does not have the function of a web browser but stores a display control program and the distribution specification data transmitted from the center apparatus 3 to the in-vehicle display 7 includes attribute information, the in-vehicle display 7 displays display information on a screen equivalent to that of the center apparatus 3. Here, the display control program stored in the in-vehicle display 7 is different from the display control program used in the screen created by the center apparatus 3, for example, in version.

If the in-vehicle display 7 has a web browser function, the in-vehicle display 7 displays display information on the same screen as the center apparatus 3 by connecting to the center apparatus.

As described above, the center device 3 transmits the display control information to the in-vehicle display 7 by performing the transmission control process of the display control information, and displays the display information on the in-vehicle display 7 based on the display control information. Thus, when the mobile terminal 6 and the in-vehicle display 7 are provided as the display terminal, these display modes can be brought close to each other, and convenience for the user can be improved. The CGW13 receives the display control information from the center apparatus 3 by performing the reception control processing of the display control information, receives the display information from the center apparatus 3, and displays the display information based on the display control information.

(24) Screen display control processing of progress display

Screen display control processing for progress display will be described with reference to fig. 186 to 210. The vehicle program rewriting system 1 performs screen display control processing for progress display in the CGW 13.

As shown in fig. 186, CGW13 includes a mode determination unit 90a and a screen display instruction unit 90b in a screen display control unit 90 for progress display.

The mode determination unit 90a determines whether or not the customization mode is set by a customization operation by the user. The mode determination unit 90a determines whether or not to set an external mode from the outside based on scene information included in the rewriting specification data. That is, the mode determination unit 90a refers to the scene information included in the rewriting specification data shown in fig. 8. As shown in fig. 8 and 187, the rewriting specification data stores scene information, expiration date information, and position information. The scene information indicates the scene (type, scene, etc.) of the present update and specifies the screen display of the present update. Specifically, there are a call flag, a dealer flag, a factory flag, a function update notification flag, and a forced execution flag.

The call flag is a flag for specifying a screen display in a case where the application is rewritten in response to a call. The call is a measure for performing, when it is found that there is a defect in the product due to a mistake in design or manufacture, a gratuitous repair, replacement, or recovery according to the regulations of the statute or the judgment of the manufacturer or seller.

The dealer logo is a logo that specifies a screen display in a case where the dealer rewrites an application. The factory flag is a flag for specifying a screen display when rewriting of an application is performed at a factory. The function update notification flag is a flag that specifies a screen display in a case where the application is rewritten in accordance with the function update notification. The function update notification refers to updating the determined function. For example, the function update notification flag is a flag for specifying a screen display for use in program update for adding a new function for compensation (or compensation).

The forced execution flag is a flag for specifying a screen display in a case where the rewriting of the application program is performed by forced execution. The forced execution means that the application is forcibly rewritten without rewriting the application although the activity notification is repeated a predetermined number of times. For example, the forced execution flag is a flag for specifying a screen display in the case where the program update is forcibly performed.

Flags indicating these pieces of scene information are set to all 0 (flag false) in the case of no correspondence, and to 1 (flag true) in the case of correspondence. The mode determination unit 90a determines that the call mode is set when the call flag is set, determines that the dealer mode is set when the dealer flag is set, determines that the factory mode is set when the factory flag is set, determines that the function update mode is set when the function update notification flag is set, and determines that the forced execution mode is set when the forced execution flag is set, for example.

The expiration date information is information indicating an expiration date and is information to be a criterion for determining whether or not to execute rewriting of the application. The CGW13 executes rewriting of the application if the current time is within the valid period indicated by the valid period information, and the CGW13 does not execute rewriting of the application if the current time is outside the valid period indicated by the valid period information. That is, after downloading the distribution packet, CGW13 refers to the expiration date information when installing the program, and if the current time is out of the expiration date, the program is not installed and the distribution packet is discarded.

The position information is information indicating a position, which is a criterion for determining whether or not to execute rewriting of the application program, and includes an allowed area and a prohibited area. In the case where the permission area is designated as the position information, the CGW13 performs rewriting of the application if the current position of the vehicle is within the permission area indicated by the position information, and the CGW13 does not perform rewriting of the application if the current position of the vehicle is outside the permission area indicated by the position information. In the case where the prohibited area is designated as the position information, the CGW13 performs rewriting of the application if the current position of the vehicle is outside the prohibited area indicated by the position information, and the CGW13 does not perform rewriting of the application if the current position of the vehicle is within the prohibited area indicated by the position information. That is, after downloading the distribution packet, CGW13 refers to the location information when installing the program, and if the current location is outside the permitted area, waits until the installation is within the permitted area without executing the installation of the program.

The screen display instruction unit 90b instructs the display terminal 5 to display a screen corresponding to rewriting of the application program. The screen display instruction unit 90b instructs the display terminal 5 to display the screen by instructing the presence or absence of display of the screen corresponding to the stage of rewriting the application program, instructing the presence or absence of display of the item on the screen, and instructing the change of the display content of the item on the screen.

The customization operation by the user is explained. Note that, although the screen displayed on the in-vehicle display 7 is described here, the same applies to the screen displayed on the portable terminal 6. In the screen described later, the layout such as the number and arrangement of the buttons may be a layout other than the illustrated one. When the user performs a display operation of the menu screen image on in-vehicle display 7, CGW13 causes in-vehicle display 7 to display menu selection screen image 511 as shown in fig. 188. CGW13 displays a "software update" button 511a, an "update result confirmation" button 511b, a "software version list" button 511c, an "update history" button 511d, and a "user information registration" button 511e on menu selection screen 511, and waits for the user to operate.

When the user operates "user information registration" button 511e from this state, CGW13 causes in-vehicle display 7 to display user selection screen 512 as shown in fig. 189. CGW13 displays "user" buttons 512a to 512c on user selection screen 512, and waits for a user operation.

When the user operates "user" button 512a from this state, CGW13 causes in-vehicle display 7 to display user registration screen 513 as shown in fig. 190. CGW13 displays fields for inputting mail addresses and VIN information (bicycle identification information) as personal information registration, fields for inputting credit card numbers and expiration dates as charging information registration, on/off buttons 513a to 513d for activity notification, download, installation, and activation as rewriting settings of the application, and a detailed information button 513e for user operation on the user registration screen 513.

The "on/off" buttons 513a to 513d for activity notification, download, installation, and activation are buttons for selecting whether or not to display a screen for activity notification, download, installation, and activation. Specifically, the button is used to allow the user to select in advance whether or not to perform content display requesting user approval when the activity notification is received, when the download is started, when the installation is started, or when the activation is started. The "detailed information" button 513e is a button for registering the expiration date information and the position information described above. These pieces of information set by the user are transmitted to the center apparatus 3 via the DCM 12. When the user sets the information using the mobile terminal 6, the CGW13 acquires the information from the center apparatus 3 via the DCM 12.

If the user is annoyed by the action notification, download, install, or activation of the screen, the "on/off" buttons 513a to 513d may be turned off. By setting to disconnect, the display of the content of which the user's consent is requested is omitted. For example, if the user does not feel a sense of annoyance in the screen display for the activity notification and activation, but feels a sense of annoyance in the screen display for the download and installation, the user may set the activity notification to on by the "on/off" button 513a, the download to off by the "on/off" button 513b, the installation to off by the "on/off" button 513c, and the activation to on by the "on/off" button 513 d.

In this case, for example, if the activity notification is set to on, the download is set to off, the install is set to off, and the activation is set to on, the display terminal 5 displays the activity notification screen, does not display the download approval screen and the download execution screen, does not display the install approval screen and the install execution screen, and displays the activation screen according to the rewriting stage of the application program. That is, if the user sets on in the stages of the activity notification, the download, the installation, and the activation, the screen display set to the on stage is performed, and if the user sets off, the screen display set to the off stage is not performed, and the screen display can be customized. The on/off setting of the screen display may be set independently for each stage, or may be set once for all stages.

When the user desires to register the valid period, the permitted area, and the prohibited area, the user may simply operate the "detailed information" button 513e to set the valid period, the permitted area, and the prohibited area. The user can customize the valid period for permitting rewriting of the application as valid period information, and can customize the permitted area for permitting rewriting of the application and the prohibited area for prohibiting rewriting of the application as position information.

Next, the operation of the above-described configuration will be described with reference to fig. 191 to 214. CGW13 executes a screen display control program for progress display, and performs screen display control processing for progress display.

When the screen display control processing for the progress display is started, CGW13 determines whether or not the expiration date information is stored in the rewriting specification data and whether or not the expiration date information is set in the customization information (S2401). If CGW13 determines that the expiration date information is stored in the rewriting specification data (S2401: yes), it determines whether or not the current time satisfies the expiration date information (S2402). When the expiration date information stored in the rewriting specification data and the expiration date information set as the customization information are present, CGW13 determines whether both the expiration date information and the expiration date information are satisfied. When CGW13 determines that the current time is outside the expiration date indicated by the expiration date information and the current time does not satisfy the expiration date information (S2402: no), screen display control processing for progress display is terminated.

If CGW13 determines that the current time is within the expiration date indicated by the expiration date information and that the current time satisfies the expiration date information (S2402: yes), it determines whether or not scene information is stored in the rewriting specification data (S2403). If the CGW13 determines that the scene information is stored in the rewriting specification data (S2403: yes), it determines that the external mode is set, and proceeds to the display instruction processing according to the setting content of the scene information (S2404), and instructs the in-vehicle display 7 to perform the screen display corresponding to the rewriting of the application program in accordance with the established mode of the flag. For example, if the call flag is established, the CGW13 instructs the in-vehicle display 7 to display a screen corresponding to rewriting of the application program in accordance with the call mode. For example, if the dealer flag is established, the CGW13 instructs the in-vehicle display 7 to perform screen display corresponding to rewriting of the application program in accordance with the dealer mode.

When CGW13 determines that no scene information is stored in the rewriting specification data (S2403: no), it determines whether or not the custom mode is set by a user' S custom operation (S2405 corresponds to a custom mode determination step). When the CGW13 determines that the custom mode is set (S2405: yes), the process proceeds to a display instruction process according to the setting content of the custom operation (S2406, corresponding to a screen display instruction step), and instructs the in-vehicle display 7 to perform screen display corresponding to rewriting of the application program in accordance with the custom mode.

When the CGW13 determines that the custom mode is not set (S2405: no), the process proceeds to a display instruction process according to the setting content of the initial setting (S2407, corresponding to a screen display instruction step), and instructs the in-vehicle display 7 to perform screen display corresponding to rewriting of the application program in accordance with the custom mode. That is, CGW13 preferentially applies the scene information stored in the rewriting specification data, and when the scene information is not stored, the customized mode is applied. In the case where neither scene information nor customization mode exists, the initial setting is applied. Here, the initial setting refers to a value set in advance, and for example, a setting in which any one of the settings of the activity notification, the download, the installation, and the activation is set to on is set as the initial setting.

Next, screen display instruction processing in S2404, S2406, and S2407 will be described with reference to fig. 192. Here, the screen display instruction processing in the installation stage is exemplified, but the same is true in other stages. When the process shifts to the display instruction process, CGW13 determines whether or not the screen is displayed (S2411), determines whether or not the item on the screen is displayed (S2412), and instructs to change the display content of the item on the screen (S2413). The CGW13 transmits a screen display request notification to the DCM12, transmits a screen display request from the DCM12 to the in-vehicle display 7 (S2414), and waits for reception of operation result information from the DCM12 (S2415). The operation result information is information indicating which button the user has operated. CGW13 may transmit a screen display request notification directly to in-vehicle display 7 and receive operation result information.

When the CGW13 determines that the operation result information is received from the DCM12 by transmitting the operation result from the in-vehicle display 7 to the DCM12 (S2415: "yes"), it determines whether the user approves rewriting of the application based on approval confirmation performed by the operation result information (S2416).

When CGW13 determines that the user has approved rewriting the application (S2416: yes), it determines whether or not position information is stored in the rewriting specification data (S2417). If the CGW13 determines that the position information is stored in the rewritten specification data (S2417: yes), it determines whether or not the current position of the vehicle satisfies the position information (S2418). In addition, S2417 and S2418 may be omitted in a stage other than the mounting stage. If the position information is within the allowable area, the CGW13 determines that the current position of the vehicle satisfies the position information if the current position of the vehicle is within the allowable area (S2418: yes), and continues rewriting the application (S2419).

On the other hand, if the current position of the vehicle is outside the allowable area, CGW13 determines that the current position of the vehicle does not satisfy the position information, stops rewriting of the application program without continuing, and ends the screen display instruction processing. If the position information is the prohibited area, if the current position of the vehicle is outside the prohibited area, the CGW13 determines that the current position of the vehicle satisfies the position information (S2418: yes), continues the rewriting of the application (S2419), and ends the screen display instruction processing. If the current position of the vehicle is within the prohibited area, CGW13 determines that the current position of the vehicle does not satisfy the position information, suspends the rewriting of the application program without continuing, and ends the display instruction processing.

The screen display request notification transmitted from the CGW13 to the DCM12 and the operation result information transmitted from the DCM12 to the CGW13 will be described. As shown in fig. 193, the screen display request notification transmitted from CGW13 to DCM12 includes the phase ID, the scene ID, and the screen configuration information. The phase ID is an ID for identifying each phase such as activity notification, download, installation, and activation. The scene ID is an ID for identifying the scene information shown in fig. 187. The operation result information transmitted from DCM12 to CGW13 includes transmission source information, a phase ID, a scene ID, an operation result, and additional information. CGW13 checks the phase ID and scene ID stored in the screen display request notification against the phase ID and scene ID stored in the operation result information, and confirms the deviation and mediation.

That is, if the phase ID and scene ID stored in the screen display request notification transmitted to DCM12 match the phase ID and scene ID stored in the operation result information received from DCM12, CGW13 determines that the screen display request notification matches the operation result information, and the screen display request notification does not deviate from the operation result information, and does not require mediation. On the other hand, if the phase ID and scene ID stored in the screen display request notification transmitted to the DCM12 do not match the phase ID and scene ID stored in the operation result information received from the DCM12, the CGW13 determines that the screen display request notification does not match the operation result information, and the screen display request notification deviates from the operation result information, and mediation is necessary. The CGW13 performs mediation as to whether or not to perform processing according to the operation result information received from the DCM 12.

The screen configuration information is information indicating the configuration elements of the screen, and as shown in fig. 194, for example, 6 items of a "activity ID …" button 514a, an "update name a …" button 514B, an "update name B …" button 514c, a "detail confirmation" button 514d, a "return" button 514e, and an "OK" button 514f exist on the activation approval screen 514. In this case, as shown in fig. 195, if all of the 6 items of the screen configuration information are set to "display", all of the 6 items are displayed on the activation approval screen 514 as shown in fig. 194. That is, the user can operate any of the "activity ID …" button 514a, the "update name a …" button 514B, the "update name B …" button 514c, the "detail confirmation" button 514d, the "return" button 514e, and the "OK" button 514 f.

On the other hand, as shown in fig. 196, if the "activity ID …" button 514a, the "update name a …" button 514B, the "update name B …" button 514c, the "detailed information" button 514d, the "OK" button 514f, and the "return" button 514e are set to "display" and "non-display", among the 6 items of the screen configuration information, the "activity ID …" button 514a, the "update name a …" button 514B, the "update name B …" button 514c, the "detailed information" button 514d, the "OK" button 514f, and the "return" button 514e are displayed on the activation approval screen 514 as shown in fig. 197. That is, the user can operate any of the "activity ID …" button 514a, the "update name a …" button 514B, the "update name B …" button 514c, the "detail confirmation" button 514d, and the "OK" button 514f, and the "back" button 514e is not displayed, and therefore the "back" button 514e cannot be operated. For example, since it is not desirable to reject the activation for rewriting of an application having a relatively high degree of importance or urgency due to a call or the like, it is possible to set the activation not to be rejected by disabling the operation of the "back" button 514e as described above. In this case, activation is granted by the user operating the "OK" button 514 f.

The screen display transmitted and received between the CGW13, the DCM12, the in-vehicle display 7, the center apparatus 3, and the meter apparatus 45, and the message frame operation related to the user operation will be described. As shown in fig. 198, CGW13 and DCM12 are connected by CAN and ethernet, and DCM12 and in-vehicle display 7 are connected by USB.

The CGW13 performs data communication with the center apparatus 3 via the DCM 12. Data transmitted from the CGW13 by the examination communication is subjected to protocol conversion by the DCM12, and is received from the DCM12 by the center apparatus 3 by the HTTP communication. For example, the CGW13 transmits data indicating the current progress state of the current stage, progress ratio, and the like to the center apparatus 3 via the DCM 12. Data transmitted from the center apparatus 3 by HTTP communication is subjected to protocol conversion by the DCM12, and received from the DCM12 by the CGW13 by examination communication.

The CGW13 communicates data with the in-vehicle display 7 via the DCM 12. Data transmitted from CGW13 by the diagnostic communication is subjected to protocol conversion by DCM12, and received from DCM12 by the in-vehicle display 7 by the USB communication. Data transmitted from the on-vehicle display 7 by USB communication is subjected to protocol conversion by the DCM12, and received by the CGW13 by examination communication from the DCM 12. For example, the CGW13 acquires information related to user operations in the in-vehicle display 7 via the DCM 12. In this way, in the vehicle program rewriting system 1, the DCM12 is configured to have a protocol conversion function, and the CGW13 similarly handles the mobile terminal 6 and the in-vehicle display 7. Further, by aggregating information on user operations to CGW13, CGW13 can mediate the results of user operations in a plurality of operation terminals, and manage the current progress state.

The order of transmitting and receiving message frames to and from the CGW13, DCM12, and in-vehicle display 7 will be described. As shown in fig. 199 to 206, in the screen display request notification transmitted from CGW13 to DCM12 and the operation result information transmitted from DCM12 to CGW13, the phase ID is set to "03" in the activity notification, the phase ID is set to "04" in the download, the phase ID is set to "05" in the installation, and the phase ID is set to "06" in the activation. In each of the stages of activity notification, download, installation, and activation, the order of transmission and reception of message frames is made the same, and the stages are distinguished by making the stage IDs different.

The activity notification phase is illustrated in fig. 199. The CGW13 manages a current progress state, specifies a phase ID, a scene ID, and picture structure information, and transmits a picture display request notification to the DCM 12. Upon receiving the screen display request notification from CGW13, DCM12 transmits a screen display request to in-vehicle display 7. When receiving the screen display request from DCM12, in-vehicle display 7 displays the screen at the time of the activity notification, and when the user performs the confirmation operation of the activity notification, transmits the operation result to DCM 12. Upon receiving the operation result from the in-vehicle display 7, the DCM12 transmits operation result information to the CGW 13. The source information, the phase ID, the scene ID, the operation result, and the additional information are specified in the operation result information received by CGW 13. CGW13 updates the current progress state based on the operation result information received from DCM 12. Here, in the case where there is an approval operation in the activity notification phase, CGW13 updates the current progress state to the download phase.

In diagram 200, a download phase is illustrated. The CGW13 manages a current progress state, specifies a phase ID, a scene ID, and picture structure information, and transmits a picture display request notification to the DCM 12. Upon receiving the screen display request notification from CGW13, DCM12 transmits a screen display request to in-vehicle display 7. When receiving the screen display request from DCM12, the in-vehicle display 7 displays a screen at the time of download approval, and when the user performs a download approval operation, transmits the operation result to DCM 12. Upon receiving the operation result from the in-vehicle display 7, the DCM12 transmits operation result information to the CGW 13. The source information, the phase ID, the scene ID, the operation result, and the additional information are specified in the operation result information received by CGW 13. CGW13 updates the current progress state based on the operation result information received from DCM 12. Here, in the case where there is an approval operation in the download phase, CGW13 updates the current progress state to the install phase.

In fig. 201, the installation phase is illustrated. The CGW13 manages a current progress state, specifies a phase ID, a scene ID, and picture structure information, and transmits a picture display request notification to the DCM 12. Upon receiving the screen display request notification from CGW13, DCM12 transmits a screen display request to in-vehicle display 7. When receiving the screen display request from DCM12, in-vehicle display 7 displays a screen at the time of installation approval, and when the user performs an installation approval operation, transmits the operation result to DCM 12. Upon receiving the operation result from the in-vehicle display 7, the DCM12 transmits operation result information to the CGW 13. The source information, the phase ID, the scene ID, the operation result, and the additional information are specified in the operation result information received by CGW 13. CGW13 updates the current progress state based on the operation result information received from DCM 12. Here, in the case where there is an approval operation in the installation phase, CGW13 updates the current progress state to the active phase.

In diagram 202, the activation phase is illustrated. The CGW13 manages a current progress state, specifies a phase ID, a scene ID, and picture structure information, and transmits a picture display request notification to the DCM 12. Upon receiving the screen display request notification from the CGW13, the DCM12 transmits a screen display request to the in-vehicle display 7. When receiving the screen display request from DCM12, the in-vehicle display 7 displays a screen at the time of activation approval, and when the user performs an activation approval operation, transmits the operation result to DCM 12. Upon receiving the operation result from the in-vehicle display 7, the DCM12 transmits operation result information to the CGW 13. The source information, the phase ID, the scene ID, the operation result, and the additional information are specified in the operation result information received by CGW 13. CGW13 updates the current progress state based on the operation result information received from DCM 12.

The screen display is explained with reference to fig. 203 to 210. When the custom mode is not set and any flag is not set in the scene information of the rewriting specification data, CGW13 instructs display terminal 5 to display a screen corresponding to rewriting of the application program in accordance with the contents of the initial setting (S2407). If the initial setting is a setting in which all of the activity notification, download, installation, and activation are turned on, CGW13 instructs display of a screen to display navigation screen 501, activity notification screen 502, download approval screen 503, download execution screen 504, download completion notification screen 505, installation approval screen 506, installation execution screen 507, activation approval screen 508, activation completion notification screen 509, and confirmation operation screen 510 in this order on display terminal 5, as shown in fig. 31 to 46. At this time, the contents for obtaining the user's approval (OK) are displayed on the activity notification screen 502, the download approval screen 503, the installation approval screen 506, the activation approval screen 508, and the confirmation operation screen 510.

When the user' S custom mode is set, CGW13 instructs display terminal 5 to display a screen corresponding to rewriting of the application program in accordance with the contents of the custom mode (S2406). However, it is limited to the case where the scene information is not specified. For example, if the activity notification is set to on, the download is set to off, the installation is set to off, and the activation is set to on in the customization mode, CGW13 instructs screen display to display terminal 5 so that, after activity notification screen 502 is displayed, download approval screen 503, download execution-in-progress screen 504, download completion notification screen 505, installation approval screen 506, and installation execution-in-progress screen 507 are not displayed, and activation approval screen 508 is displayed.

When the call flag is set in the scene information for rewriting the specification data, CGW13 instructs display terminal 5 to display a screen corresponding to rewriting of the application program in accordance with the content of the call mode (S2404). In this case, as shown in fig. 204, CGW13 causes "back" button 502a to be not displayed on active notification screen 502. As shown in fig. 205 and 206, CGW13 does not display return button 503c on download approval screen 503. As shown in fig. 207, CGW13 causes "back" button 504b to be not displayed on download execution screen 504. As shown in fig. 208 and 209, CGW13 does not display "back" button 505b on installation approval screen 505. As shown in fig. 210, CGW13 causes the "back" button to be not displayed on activation approval screen 518.

That is, when the call flag is set in the scene information in which the specification data is rewritten, the "after" button and the "back" button are set so as not to be displayed as described above, and thus the "after" button and the "back" button may be set so as not to be displayed. Alternatively, the activity notification screen 502 may be displayed, and after the user's approval is obtained on the download approval screen 503, the display of the installation approval screen 505 and the activation approval screen 518 may be omitted. In the above, although the case where the call flag is set in the scene information for rewriting the specification data has been described, the case where the dealer flag, the factory flag, the function update notification flag, and the compulsory execution flag are set in the scene information for rewriting the specification data may be similarly configured to instruct, depending on the state of rewriting the application program, whether to display the screen corresponding to the stage, whether to display the items of the screen, and change the display content of the items of the screen.

Specifically, when the dealer logo is set in the scene information in which the specification data is rewritten, a dedicated screen display in the repair process is required in the dealer environment, and the dedicated screen for the dealer may be displayed without displaying the screen for the user. That is, the dealer operator performs an operation related to rewriting of the application program, not an operation related to rewriting of the application program by the user, and therefore, it is sufficient to set the "after" button and the "back" button to be displayed and display the "after" button and the "back" button for the dealer job. Further, for example, a prompt such as "please rewrite the dealer" may be displayed to urge the dealer to put the vehicle in storage.

When the factory flag is set in the scene information in which the specification data is rewritten, the screen display is not necessary in the manufacturing process in the factory environment, and therefore the screen may not be displayed.

When the function update notification flag is set in the scene information in which the specification data is rewritten, even if the user performs setting that does not require display by customization, a screen display for reliably notifying the user of the changed content is required, and therefore the user's screen may be displayed regardless of the customized setting. That is, since it is sufficient to forcibly perform the approval even when it is determined that the user does not need the approval and forcibly display the approval screen, it is sufficient to display the "after" button and the "back" button by setting the "after" button and the "back" button to be displayed as described above.

In the case where the compulsory execution flag is set in the scene information in which the specification data is rewritten, the user needs to perform setting of display by customization, and even if the user does not agree, compulsory execution for reliably performing software update of the vehicle is necessary. That is, since the application is rewritten even if the user does not need to approve while determining that the user needs to approve, the "after" button and the "back" button may be set so as not to be displayed, and the "after" button and the "back" button may not be displayed, as described above. Further, since the function is assumed to be the approval, rewriting may be performed as an approved screen without displaying the screen itself.

As described above, CGW13 performs screen display control processing for progress display, and instructs display terminal 5 to display a screen corresponding to the setting content of the custom mode when the custom mode is set. The user can customize the screen display according to the progress of rewriting.

(25) Report control processing of program update

Report control processing of program update is explained with reference to fig. 211 to 217. The vehicle program rewriting system 1 performs a report control process of updating a program in the CGW 13.

As shown in fig. 211, CGW13 includes a phase specifying unit 91a, a display instructing unit 91b, an indicator display control unit 91c, an icon display control unit 91d, a detailed information display control unit 91e, and a nullifying instructing unit 91f in a program update report control unit 91. The phase determination section 91a determines the phase as the progress status of the program update. As the stage of the program update, the stage determination section 91a determines the activity notification, the download approval, the download execution in progress, the installation approval, the installation execution in progress, the activation approval, the activation execution in progress, and the update completion.

When the stage specification unit 91a specifies the stage of the program update, the display instruction unit 91b instructs to display an indicator so as to correspond to the specified stage of the program update. When the display instruction unit 91 instructs the display of the pointer, the pointer display control unit 91c controls the display of the pointer in accordance with the instruction. Specifically, the indicator display control unit 91c controls the indicator 46 to be turned on in the meter device 45.

The indicator display control unit 91c controls the display of the indicator, and the icon display control unit 91d controls the display of the icon on the in-vehicle display 7. The display control of the indicator is performed following the indicator display control unit 91c, and the detailed information display control unit 91e performs display control of the icon and the detailed information related to the program update on the in-vehicle display 7 or the mobile terminal 6. The icon is an activity notification icon 501a shown in fig. 32, and the detailed information is, for example, an activity notification screen 502 of the pop-up display shown in fig. 33, a download approval screen shown in fig. 34 and 35, or the like. The detailed information display control unit 91e instructs to display icons corresponding to the stages of the program update specified by the stage specifying unit 91a, or instructs to display detailed information screens corresponding to the stages and the user operation.

Even when the power supply management ECU20 performs power supply control by updating the program during parking, the invalidation instructing unit 91f instructs the power supply management ECU20 and each ECU19 related to the user operation to invalidate the reception of the user operation. For example, when the memory of the rewrite target ECU19 is configured as a one-sided memory and is mounted while the vehicle is stopped, the invalidation of the reception of the user operation is instructed to the engine ECU47 (see fig. 217), and the reception is suppressed so as not to be invalidated and the engine is not started even if the user performs an operation to start the engine. Further, by instructing the power supply management ECU20 to invalidate the user operation, when the memory of the rewrite target ECU19 is configured as a one-sided memory and the IG power supply is turned on and attached during parking, even if the user performs an operation to turn off the IG power supply, the reception is suppressed so as not to be invalidated and the IG power supply is not turned off. At this time, the invalidation instructing unit 91f may instruct the in-vehicle display 7 to report the content of the invalidation of the reception of the user operation.

Next, the operation of the above-described structure will be described with reference to fig. 212 to 217. CGW13 executes a program update report control program and executes a program update report control process.

When the report control processing of the program update is started, CGW13 determines whether or not an activity of the program update has occurred (S2501). When CGW13 determines that an activity of a program update has occurred (S2501: yes), it specifies the stage and memory structure of the program update (S2502, corresponding to the stage specifying step). The CGW13 instructs the meter device 45 to display the indicator 46 in a manner corresponding to the determined stage of the program update (S2503, corresponding to the display instruction step). The in-vehicle display 7 is instructed to display an icon corresponding to the determined stage of the program update (S2504).

The CGW13 determines whether or not the detail display request is present (S2505), and if it is determined that the detail display request is present (S2505: yes), it is determined whether or not data communication with the in-vehicle display 7 is possible (S2506). For example, when the user presses the activity notification icon 501a shown in fig. 32, the "confirm" button 502a shown in fig. 33, the "detail confirm" button 503b shown in fig. 34, or the like, the CGW13 determines that there is a detail display request. When the CGW13 determines that data communication with the in-vehicle display 7 is possible (S2506: yes), it acquires detailed information (S2507), instructs the in-vehicle display 7 to display the detailed information (S2508), and instructs the center device 3 to display the detailed information (S2509).

CGW13 acquires the report content received together with the event notification and the report content of the distribution specification data, and notifies in-vehicle display 7 of the report content and instructs detailed information display. The CGW13 notifies the center device 3 of the phase and the operation content of the user as an instruction to display detailed information so that the same content as that of the in-vehicle display 7 is also displayed on the mobile terminal 6.

CGW13 determines whether or not the event of program update is ended (S2510).

For example, if the user confirms that activation is completed and the program update is completed, CGW13 determines that the event is completed. If CGW13 determines that the event of the program update has not ended (S2510: no), it returns to step S2502 and repeats the steps after step S2502. CGW13 repeats the steps following step S2502 in each stage of activity notification, download approval, download execution, installation approval, installation execution, activation approval, activation execution, and update completion. When CGW13 determines that the event of the program update has ended (S2510: yes), it ends the report control process of the program update.

The meter device 45 has the indicator 46 disposed at a predetermined position that can be confirmed by the user, and when a report request notification is received from the CGW13, the indicator 46 is turned on or blinked as a report during rewriting of the application program. Here, instead of the blinking, the lighting display may be a lighting display in which the color, brightness, or the like of the indicator 46 is changed to be more emphasized than the normal lighting display. That is, the display may be a display in which the emphasis is placed on the normal display. In addition, the indicator 46 associated with the program update is one and is made of one design.

As shown in fig. 213, when the rewrite target of the application program is a double-sided memory, a single-sided suspend memory, or a single-sided single memory, the meter device 45 causes the indicators at the respective stages to report differently. Specifically, the meter device 45 determines the reporting mode of the indicator 46 based on the stage and the memory configuration specified from the CGW13, and reports based on the determined reporting mode. Instead of the meter device 45, the indicator display control unit 91c may control the manner of notification of the indicator 46, or the indicator display control unit 91c may specify the manner of notification of the indicator 46 and instruct the meter device 45 to control the indicator 46 to turn on in this manner of notification.

As shown in fig. 213, the indicator display control unit 91c blinks the indicator 46, for example, in green at a stage where the travel of the vehicle is restricted, such as during installation or activation. When the rewrite target ECU19 is a dual-sided memory, the indicator display control unit 91c blinks only at the stage during execution of activation. When the rewrite target ECU19 is the one-sided suspend memory, the indicator display control unit 91c blinks to display the mounting execution phase during IG off, the activation approval phase, and the activation execution phase. When the rewrite target ECU19 is a one-sided memory, the indicator display control unit 91c blinks and displays the mounting execution phase, the activation approval phase, and the activation execution phase. That is, the display of the indicator 46 in the activity notification phase, the download phase, and the phases after completion of activation (IG off, IG on, confirmation operation) is not common depending on the memory configuration, but the display of the indicator 46 in the installation phase and the activation phase is different depending on the memory configuration. Here, the IG off time shown in fig. 213 is a display mode in which activation is performed during parking, and the IG power supply is turned off along with completion of activation, and the indicator 46 is turned off along with the IG power supply off. When the IG power supply is turned on by a user operation, the indicator 46 is turned on. This is to report to the user that the program update is fully completed. In confirmation operation screen 510 shown in fig. 45, when the user presses OK button 510b, it is determined that the confirmation operation is performed, and indicator 46 is turned off.

Hereinafter, a case where the meter device 45 controls the reporting method of the indicator 46 will be described, but the indicator display control unit 91c may control the reporting method of the indicator 46 as described above. Fig. 214 shows a manner of reporting an indicator when the memory type of the rewrite target ECU19 is a dual-sided memory. Based on the instruction from CGW13, meter device 45 lights indicator 46 during the period from the notification of activity to the approval of activation, and blinks indicator 46 during the period during execution of activation. Then, the meter device 45 turns off the indicator 46 when the IG is off, turns on the indicator 46 when the IG is on, and turns off the indicator 46 when the user performs a confirmation operation for the update completion. That is, in the case of the dual-sided memory, there is a possibility that a restriction is generated during the traveling of the vehicle and only the activation execution is performed. Since only the active execution is performed when the vehicle is in a stopped state, the vehicle cannot be driven. Therefore, the meter device 45 blinks the indicator 46 in a stage in the execution of activation. The indicator here is of a predetermined design and is displayed in green in the case of normal progress.

Fig. 215 shows a manner of reporting the indicator when the memory type of the rewrite target ECU19 is a one-sided suspend memory. When the rewriting target of the application is the one-sided suspend memory, the meter device 45 lights the indicator 46 in a stage from the activity notification to the installation approval based on the instruction from the CGW13, lights the indicator 46 when the IG is on during the execution of the installation, and blinks the indicator 46 when the IG is off. That is, the meter device 45 turns on the indicator 46 because writing to the flash memory of the single-sided suspend memory ECU is not performed in the IG on state, but blinks the indicator 46 because writing to the flash memory is performed in the IG off state. The meter device 45 blinks the indicator 46 in the phase from the approval of activation until the execution of activation. Then, the indicator 46 is turned off when the IG is off, the indicator 46 is turned on when the IG is on, and the indicator 46 is turned off when the user performs a confirmation operation for the update completion. That is, in the case of the one-sided suspend memory, there is a possibility that a restriction is imposed during traveling of the vehicle from the time of the IG off during the installation execution until the activation execution. Thus, the meter device 45 blinks the indicator 46 in these stages. Here, in the case of the one-sided suspend memory, even during installation on the non-operation surface, the operation surface can be activated to perform the travel control on the vehicle by interrupting the installation. Therefore, as in the case of the dual-sided memory, the blinking display may be used only for the activation execution that does not allow the vehicle to run.

Fig. 216 shows a manner of reporting the indicator when the memory type of the rewrite target ECU19 is a single-sided memory. When the rewriting target of the application is the single-sided individual memory, the meter device 45 lights the indicator 46 in a period from the activity notification to the installation approval and blinks the indicator 46 in a period from the installation execution to the activation execution based on the instruction from the CGW 13. Then, the indicator 46 is turned off when the IG is off, the indicator 46 is turned on when the IG is on, and the indicator 46 is turned off when the user performs a confirmation operation for the update completion. That is, in the case of the one-sided memory, there is a possibility that a restriction is imposed during traveling of the vehicle from the installation execution to the activation execution. Thus, the meter device 45 blinks the indicator 46 in these stages.

When the ECU19 to be rewritten is the ECU19 including the dual-sided memory, the single-sided suspended memory, and the single-sided individual memory in one activity notification, the meter device 45 rewrites the application program of the ECU19 in the order of the dual-sided memory, the single-sided suspended memory, and the single-sided individual memory. After the notification of the activity, the CGW13 is performed from the approval of the download to the dual-sided memory ECU19 until the installation is being performed, and the meter device 45 lights the indicator 46 during this period. When the CGW13 ends the stage during the mounting execution of the ECU19 with respect to the dual-sided memory, the meter device 45 lights the indicator 46 during the period from the download approval of the ECU19 with respect to the single-sided suspend memory to the mounting execution. When the CGW13 ends the stage in which the ECU19 is being mounted to the single-sided suspended memory, the meter device 45 lights the indicator 46 during the period from the download approval to the mounting approval of the ECU19 to the single-sided individual memory.

The meter device 45 blinks the indicator 46 from the time of the installation of the single-sided individual memory to the time of the activation of the 3 types of ECUs 19 different in kind from these memories. The meter device 45 turns off the indicator 46 when the IG is turned off, turns on the indicator 46 when the IG is turned on, and turns off the indicator 46 when the user performs a confirmation operation for the completion of the update.

When the ECU19 to be rewritten as a program in one activity notification includes the ECU19 having a dual-sided memory, a single-sided suspend memory, and a single-sided individual memory, the meter device 45 may be controlled as follows. The meter device 45 rewrites the application program of the ECU19 in the order of the double-sided memory, the single-sided suspend memory, and the single-sided individual memory. After the notification of the activity, CGW13 instructs the predetermined green design to light up as the download approval and the indicator 46 during the download execution of the distribution packet including the update data of the rewrite target ECU 19. CGW13 then indicates that the green, defined design is illuminated as an installation approved indicator 46. In addition, in the case of the ECU19 including a single-sided individual memory, the installation consent here doubles as the activation consent. If approval is obtained for the user of the installation, CGW13 first performs the installation as a dual-sided memory to ECU 19. While the mounting of the dual-sided memory to the ECU19 is being performed, the meter device 45 lights the indicator 46. When the CGW13 ends the stage of the mounting of the ECU19 to the dual-sided memory, the mounting of the single-sided suspended memory to the ECU19 is performed. While the single-sided suspend memory is being mounted to the ECU19, the meter device 45 lights the indicator 46. When the CGW13 ends the stage in which the single-sided suspend memory is mounted to the ECU19, the single-sided individual memory is mounted to the ECU 19. While the single-sided suspend memory is being mounted to the ECU19, the meter device 45 blinks the indicator 46. When all of these rewriting ECU19 are mounted, CGW13 is activated while the indicator 46 is kept blinking. The CGW13 instructs the meter device 45 to turn off the indicator 46 when the IG is turned off, instructs the meter device 45 to turn on the indicator 46 when the IG is turned on, and instructs the meter device 46 to turn off the indicator 46 when the user performs a confirmation operation for the completion of the update.

In each stage shown in fig. 214 to 216, CGW13 also indicates icon display to in-vehicle display 7. CGW13 instructs display of activity notification icon 501a shown in fig. 32 in the activity notification phase. CGW13 also continues the display of the activity notification icon 501a during the download approval phase. CGW13 instructs display of download execution icon 501b shown in fig. 36 in the download execution phase. CGW13 may continue to display the icon 501b during the download execution or may indicate to display the activity notification icon 501a again during the installation approval phase. CGW13 instructs display of the installation in-execution icon 501c shown in fig. 41 in the installation in-execution phase. CGW13 may continue to display icon 501c during the installation execution or may indicate that activity notification icon 501a is displayed again during the activation approval phase. CGW13 does not display an icon when the IG is turned off during and after the active execution. CGW13 may instruct the active notification icon 501a to be displayed again when IG is turned on, or may cause the activation completion notification screen 509 shown in fig. 44 to pop up. If the user performs a confirmation operation for the completion of the update, CGW13 does not display an icon. Further, the icon display related to the program update is one, and is configured by a design corresponding to each stage.

When the CGW13 instructs the indicator 46 to report the rewriting of the application as described above, if an abnormality occurs in the rewriting of the application, the report mode is different from that in the normal state. The CGW13 may instruct, for example, green to light up and blink when rewriting the application program normally, and the CGW13 may instruct, for example, yellow or red to light up and blink when an abnormality occurs. CGW13 may be different in color depending on the degree of abnormality, and for example, when the degree of abnormality is relatively large, the indication may be displayed in red or blinking, and when the degree of abnormality is relatively small, the indication may be displayed in yellow or blinking. The abnormality here includes a state in which the distribution packet cannot be downloaded, a state in which the write data cannot be attached, a state in which the write data cannot be written in the rewrite target ECU19, a state in which the write data is not legitimate, and the like.

As the detailed display, the in-vehicle display 7 sequentially displays the above-described activity notification screen 502, download approval screen 503, download execution in-progress screen 504, download completion notification screen 505, installation approval 506, installation execution in-progress screen 507, activation approval screen 508, IG on-time screen 509, and update completion confirmation operation time screen 510 based on the operation of the user. The same details as those of the in-vehicle display 7 can be displayed also in the mobile terminal 6 connected to be able to communicate with the center apparatus 3. For example, in a vehicle not equipped with the in-vehicle display 7, when the user requests the detail display by operating a handle switch or the like, the CGW13 requests the center device 3 to display the detail display via the DCM 12. The center apparatus 3 creates the content of the detailed display and displays the content on the mobile terminal 6, so that the user can confirm the detailed information on the mobile terminal 6.

As shown in fig. 217, when rewriting the application programs of the single-sided suspended memory and the single-sided individual memory of the IG system ECU and the ACC system ECU during parking, the CGW13 forcibly activates the electric power source management ECU20 to turn on the vehicle electric power source. In this case, when the power supply management ECU20 is forcibly activated, the meter device 45 and the in-vehicle display 7 are activated by the operation of the power supply management ECU 20. Therefore, CGW13 indicates suppression of the report related to the program update to meter device 45 and in-vehicle display 7. When the inhibition of the report of the program update is instructed from the CGW13, the meter device 45 does not turn on or blink the indicator 46. When the vehicle-mounted display 7 is instructed from the CGW13 to suppress the report of the program update, the above-described detailed display is not performed. That is, in the installation and activation during parking, when the user is not riding in the vehicle, the report related to the program update is not necessary, and therefore, the control is performed so as not to perform the report.

Further, although the power supply management ECU20 can receive an operation from a user's button switch to perform engine control when the vehicle power supply is forcibly activated to turn on the vehicle power supply, the CGW13 instructs the power supply management ECU20 to invalidate the reception of the user operation and instructs the meter device 45, the in-vehicle display 7, and the ECU19 related to the user operation to notify the user of invalidation of the reception of the user operation. When the validation of the reception of the user operation is instructed from the CGW13, the meter device 45 validates the reception of the operation even if the user operates the meter device 45. Similarly, when the onboard display 7 is instructed from the CGW13 to invalidate the reception of the user operation, even if the user operates the onboard display 7, the reception of the operation is invalidated. When the CGW13 instructs the engine ECU47 to invalidate the reception of the user operation, the reception of the operation is suppressed so as to invalidate the operation even if the user operates the engine to start by the push switch, and the engine is not started.

As described above, the CGW13 instructs the meter device 45 to rewrite the report of the application program by the report control process of performing the program update. Even in a situation where the user cannot be notified of the rewriting of the application by the mobile terminal 6 or the in-vehicle display 7, the user is notified of the rewriting of the application by the meter device 45, and the user can be appropriately notified of the rewriting of the application. CGW13 may change the reporting method according to the progress of rewriting of the application.

(26) Execution control processing of power supply self-hold

The execution control processing of the power supply self-holding will be described with reference to fig. 218 to 222. The vehicle program rewriting system 1 performs execution control processing for self-holding the power supply in the CGW13, the ECU19, the in-vehicle display 7, and the power supply management ECU 20. In this case, the CGW13 instructs the ECU19, the in-vehicle display 7, and the power management ECU20 to perform power supply self-holding. Specifically, CGW13 corresponds to a vehicle master device, and ECU19, in-vehicle display 7, and power supply management ECU20 correspond to a vehicle slave device. The CGW13 has a second power supply self-holding circuit, and the vehicle slave device has a first power supply self-holding circuit.

As shown in fig. 218, CGW13 includes a vehicle power supply determination unit 92a, a rewriting determination unit 92b, a first power supply self-holding determination unit 92c, a power supply self-holding instruction unit 92d, a second power supply self-holding determination unit 92e, a second power supply self-holding validation unit 92f, a second stop condition establishment determination unit 92g, and a second power supply self-holding stop unit 92h in the execution control unit 92 for power supply self-holding.

The vehicle power supply determination unit 92a determines on/off of the vehicle power supply. The rewriting determination unit 92b determines whether or not rewriting of the application is underway. The rewriting determination unit 95b determines which of the rewriting target ECUs 19 is being rewritten. When the vehicle power supply determination unit 92a determines that the vehicle power supply is off and the rewriting determination unit 92b determines that the rewriting of the program is underway, the first power supply self-holding validation unit 92c determines the necessity of self-holding the power supply in the vehicle slave device. That is, the first power supply self-sustaining enabling unit 92c refers to the rewriting specification data shown in fig. 8, and determines that there is a need for the self-sustaining power supply if the method of rewriting the ECU information of the rewrite target ECU19 is designated as power supply self-sustaining, and determines that there is no need for the self-sustaining power supply if designated as power supply control.

When the first power supply self-holding determination unit 92c determines that the self-holding power supply is required for the vehicle slave device, the power supply self-holding instruction unit 92d instructs the vehicle slave device to activate the first power supply self-holding circuit. The power supply self-hold instruction unit 92d is configured to instruct the first power supply self-hold circuit to be activated, and includes a mode for specifying a completion time of the power supply self-hold, a mode for instructing an extension time of the power supply self-hold, and a mode for periodically and continuously outputting a self-hold request to the vehicle slave device. The power supply self-hold instruction unit 92d refers to the rewriting specification data shown in fig. 8, and instructs the vehicle slave device to validate the first power supply self-hold circuit based on the time specified by the power supply self-hold time of the ECU information of the rewriting ECU 19.

That is, if the method of designating the completion time of power supply self-holding is adopted, the power supply self-holding instruction unit 92d designates the completion time as the time obtained by adding the time designated by the rewriting specification data from the current time. If the extended time of the power supply self-hold is designated, the power supply self-hold instruction unit 92d designates the time designated by the rewriting specification data as the extended time. If the system is adopted in which the self-hold request is continuously output to the vehicle slave device at regular intervals, the power supply self-hold instruction unit 92d continuously outputs the self-hold request to the vehicle slave device at regular intervals until the time specified by the rewriting specification data elapses.

When the vehicle power supply determining unit 92a determines that the vehicle power supply is off and the rewriting determining unit 92b determines that the program is being rewritten, the second power supply self-holding determining unit 92e determines the necessity of self-holding the power supply. In other words, the necessity of self-sustaining power supply is determined in consideration of the configuration of CGW13 as an IG power supply system or an ACC power supply system. When the second power supply self-hold determination unit 92e determines that it needs self-hold power supply, the second power supply self-hold validation unit 92f validates the second power supply self-hold circuit.

In this case, when the second power supply self-holding circuit is stopped, the second power supply self-holding enabling unit 92f enables the second power supply self-holding circuit by activating the second power supply self-holding circuit. When the second power supply self-holding circuit is activated, the second power supply self-holding validation unit 92f validates the power supply self-holding circuit by extending the operation period of the second power supply self-holding circuit.

The second stop condition satisfaction determination unit 92g determines whether or not the stop condition for the power supply self-holding of the second power supply self-holding circuit is satisfied. Specifically, the second stop condition satisfaction determination unit 92g monitors the remaining battery level of the vehicle battery 40, occurrence of a timeout, and completion of rewriting by the rewriting ECU19, and determines that the stop condition for power supply self-holding by the second power supply self-holding circuit is satisfied when it is determined that the remaining battery level of the vehicle battery 40 is smaller than a predetermined capacity, or a timeout occurs, or rewriting by the rewriting ECU19 is completed. The second power supply self-holding stop unit 92h stops the second power supply self-holding circuit when the second stop condition satisfaction determination unit 92g determines that the stop condition for the power supply self-holding of the second power supply self-holding circuit is satisfied.

As shown in fig. 219, the ECU19 includes an instruction determination unit 108a, a first power supply self-hold enabling unit 108b, a first stop condition satisfaction determination unit 108c, and a first power supply self-hold stop unit 108d in the execution control unit 108 for power supply self-hold. The instruction determination unit 108a determines whether or not the activation of the first power supply self-holding circuit is instructed from the CGW 13.

When the instruction determination unit 108a determines that the first power supply self-holding circuit is instructed to be activated, the first power supply self-holding activation unit 108b activates the first power supply self-holding circuit. When the completion time of the power supply self-holding is designated, the first power supply self-holding enabling unit 108b enables the first power supply self-holding circuit until the designated completion time. When the extension time of the power supply self-holding is designated, the first power supply self-holding validation unit 108b validates the first power supply self-holding circuit until the designated extension time elapses from the present time. When a self-hold request is input from the CGW13, the first power supply self-hold enabling unit 108b enables the first power supply self-hold circuit as long as the self-hold request is continuously input.

In this case, when the first power supply self-holding circuit is stopped, the first power supply self-holding validation unit 108b activates the first power supply self-holding circuit, thereby validating the first power supply self-holding circuit. When the first power supply self-holding circuit is activated, the first power supply self-holding activation unit 108b activates the first power supply self-holding circuit by extending the operation period of the first power supply self-holding circuit. The first power supply self-hold enabling unit 108b stores a default power supply self-hold time, and enables the first power supply self-hold circuit for the default power supply self-hold time even if the validation of the first power supply self-hold circuit is not instructed. That is, when the first power self-holding validation unit 108b is instructed to validate the first power self-holding circuit, the longer one of the default power self-holding time and the power self-holding time instructed by the CGW13 is prioritized to validate the first power self-holding circuit.

The first stop condition establishment determination unit 108c determines whether or not the stop condition for the power supply self-holding by the first power supply self-holding circuit is established. Specifically, if the object of the power self-holding is the ECU19 to be rewritten, the first stop condition satisfaction determination unit 108c monitors the occurrence of a timeout and the stop instruction from the CGW13, and determines that the stop condition of the power self-holding of the first power self-holding circuit is satisfied if it is determined that a timeout occurs or a stop instruction from the CGW13 is received. The first stop condition establishment determination unit 108c monitors occurrence of a timeout, getting-off of the user, and a stop instruction from the CGW13 if the object of the power self-holding is the in-vehicle display 7, and determines that the stop condition for the power self-holding of the first power self-holding circuit is established if it is determined that the timeout, the getting-off of the user, or the stop instruction from the CGW13 is generated. If the power supply self-holding target is the power supply management ECU20, the first stop condition satisfaction determination unit 108c monitors the stop instruction from the CGW13, and determines that the stop condition for power supply self-holding of the first power supply self-holding circuit is satisfied when it is determined that the stop instruction from the CGW13 is received. When the second stop condition satisfaction determination unit 108c determines that the stop condition for the power self-holding of the first power self-holding circuit is satisfied, the first power self-holding stop unit 108d stops the first power self-holding circuit.

Next, the operation of the above-described structure will be described with reference to fig. 220 to 222. Here, a case where the vehicle slave device is the rewrite target ECU19 will be described. The CGW13 and the ECU19 to be rewritten execute a power-supply-self-holding execution control program and perform power-supply-self-holding execution control processing.

When the execution control process of the power self-holding is started, CGW13 determines whether or not the vehicle power is off (S2601, corresponding to a vehicle power determination step). When the CGW13 determines that the vehicle power is off (S2601: yes), it determines whether rewriting of the application is underway (S2602, corresponding to an underwriting determination step). If the CGW13 determines that the application is being rewritten (yes in S2602), the second power supply self-holding circuit is activated (S2603, corresponding to the second power supply self-holding validation step), and the necessity of self-holding the power supply in the rewrite target ECU19 is determined (S2604, corresponding to the power supply self-holding determination step).

When the CGW13 determines that the power supply itself needs to be held in the ECU19 to be rewritten (S2604: yes), it instructs the ECU19 to activate the first power supply self-holding circuit (S2605, corresponding to a power supply self-holding instruction step). The CGW13 determines whether or not the stop condition for power supply self-holding is satisfied (S2606), and if it is determined that the stop condition for power supply self-holding is satisfied (yes at S2606), stops the second power supply self-holding circuit (S2607), and ends the execution control processing for power supply self-holding.

While CGW13 is configured to activate the power supply self-holding circuit when it is determined that the application is being rewritten, it may be configured to activate the power supply self-holding circuit when it is determined that the vehicle power is turned off, and to prolong the operation time of the power supply self-holding circuit during activation when it is determined that the application is being rewritten.

When the execution control processing of the power supply self-holding is started, the rewrite target ECU19 determines whether the vehicle power supply is off (S2611). When the rewrite-target ECU19 determines that the vehicle power supply is off (S2611: yes), it activates the self-holding circuit (S2612), determines whether a stop condition for power supply self-holding is satisfied (S2613), and determines whether or not validation of the self-holding circuit is instructed from the CGW13 (S2614). When the rewrite-target ECU19 determines that the CGW13 instructs the power supply self-holding circuit to be activated (S2614: yes), it extends the operation period of the power supply self-holding circuit during the activation (S2615). When the rewrite-target ECU19 determines that the stop condition for power supply self-holding is satisfied (yes in S2613), it stops the power supply self-holding circuit (S2616) and ends the execution control process for power supply self-holding.

While the rewrite-target ECU19 has been described above as having a configuration to activate the power self-holding circuit when it is determined that the vehicle power is off, it may be configured to deactivate the power self-holding circuit when it is determined that the vehicle power is off, and to activate the power self-holding circuit while it is being deactivated when it is determined that the vehicle power is off and it is determined that activation of the power self-holding circuit has been instructed from the CGW 13.

Although the description has been given above of the case where the vehicle slave device is the rewrite target ECU19, the same applies to the case where the vehicle slave device is the in-vehicle display 7 or the power management ECU 20. As shown in fig. 222, the rewrite-target ECU19 requires the operation of the power supply self-holding circuit during the period from the installation preparation to the rewrite post-processing, and the in-vehicle display 7 requires the operation of the power supply self-holding circuit during the periods of waiting for the update approval, waiting for the download approval, waiting for the installation approval, and waiting for the activation approval.

As described above, the CGW13 performs execution control processing for power self-holding, and determines that the power is necessary to be self-held in the rewrite target ECU19 when it is determined that the vehicle power is off and the application is being rewritten, and instructs the rewrite target ECU19 to activate the power self-holding circuit when it is determined that the self-holding power is necessary. When it is determined that the CGW13 instructs the power supply self-holding circuit to be activated, the ECU19 to be rewritten activates the power supply self-holding circuit. By activating the power supply self-holding circuit, the operating power supply for rewriting the application program can be secured, and the rewriting of the application program can be appropriately completed.

(27) Overwrite indication processing based on override of configuration information

Rewriting instruction processing based on overwriting by the arrangement information will be described with reference to fig. 223 to 227. The vehicle program rewriting system 1 performs a rewriting instruction process based on the override of the arrangement information in the CGW 13. The configuration information is a set value and includes various parameters for control. In the present embodiment, a description will be given of a configuration in which program update such as the execution control processing (fig. 148 to 155) of the above-described (18) rewrite is used to update the arrangement information. CGW13 determines which of overwriting and write-back is used for rewriting of the configuration information, based on the rewriting specification data (fig. 8). Here, since the type of rewriting of the configuration information is specified as the override, CGW13 instructs rewriting of the override based on the configuration information. The overwriting of configuration information means that updating is performed using new configuration information regardless of the content of old configuration information.

As shown in fig. 223, the CGW13 includes an arrangement information override instruction unit 93a, a specific information acquisition unit 93b, a specific information transmission unit 93c, and a new arrangement information reception unit 93d in an override instruction unit 93 based on the arrangement information. The arrangement information override instruction unit 93a instructs the rewrite target ECU19 to override the new arrangement information used in response to execution of the rewrite target program during or after rewriting of the application program, and instructs the rewrite target ECU19 to rewrite the arrangement information. The specifying information acquiring unit 93b acquires specifying information capable of specifying the old configuration information stored in the flash memory from each ECU 19. In this case, when the SID and DID are specified by the rewriting specification data, the specifying information acquiring unit 93b acquires the specifying information from each ECU19 using the SID and DID specified by the rewriting specification data. The identification information acquiring unit 93b acquires, as the identification information, the software version indicating the version of the program and the arrangement information version indicating the version of the arrangement information as the configuration information of the ECU19, in accordance with the procedure specified by the rewriting specification data.

When the specific information acquiring unit 93b acquires the specific information from the rewrite target ECU19, the specific information transmitting unit 93c transmits the acquired specific information from the DCM12 to the center apparatus 3. When receiving the new configuration information corresponding to the identification information from the center apparatus 3 in the DCM12, the new configuration information receiving unit 93d acquires the new configuration information from the DCM 12. Specifically, the new configuration information receiving unit 93d acquires, from the DCM12, new configuration information included in the distribution packet received by the DCM 12. In the distribution packet generation process shown in fig. 6, the center device 3 includes new configuration information in the reprogramming data instead of the difference data corresponding to the ECU19, and generates a distribution packet. Alternatively, the center device 3 includes the difference data and the new configuration information corresponding to the ECU19 in the reprogramming data to generate the distribution packet. The type of "configuration data" is given to the rewriting specification data (see fig. 8) included in the distribution packet as the write data type.

Alternatively, the new configuration information receiver 93d transmits the new configuration information from the center device 3 and acquires the new configuration information from the DCM12 that received the new configuration information, in response to the determination information transmitter 93c transmitting the determination information of the rewriting target ECU 19. For example, after the installation using the difference data is completed, the new configuration information receiving unit 93d transmits the old configuration information to the center device 3, and acquires the new configuration information transmitted from the center device 3.

Next, the operation of the above-described configuration will be described with reference to fig. 224 to 227. CGW13 executes a rewrite instruction program based on the overwriting of the configuration information, and executes rewrite instruction processing based on the overwriting of the configuration information. Here, a case where the configuration information is updated together with the update of the program will be described.

CGW13 starts rewriting instruction processing based on the overwriting of the placement information at a predetermined timing such as when IG is turned on. First, the CGW13 collects vehicle information, and acquires a software version and a configuration information version as configuration information of each ECU19 (S2701). The CGW13 causes the collected vehicle information to be transmitted from the DCM12 to the center apparatus 3 (S2702). The CGW13 determines the presence or absence of an activity notification related to a program update based on the notification from the center apparatus 3 acquired via the DCM12 (S2703). If the CGW13 determines that there is an activity notification (yes in S2703), the distribution packet is downloaded from the center device 3 to the DCM12(S2704), and the rewriting specification data is confirmed (S2705).

The CGW13 determines whether or not the application is rewritten or the configuration information is rewritten, based on the type of the written data of the rewriting specification data for the ECU19 to be rewritten (S2706, S2707). Specifically, CGW13 determines that the configuration information is rewritten if the update program data type is "configuration data", and determines that the application is rewritten if the update program data type is other than the "configuration data".

If the CGW13 determines that the application is rewritten (yes in S2706), it instructs the rewrite target ECU19 to rewrite the application (S2708). When rewriting of the application program is instructed from the CGW13, the ECU19 to be rewritten writes the write data distributed from the CGW13 to the flash memory, and rewrites the application program. The rewriting of the application program is described in the execution control processing (fig. 148 to 155) of the above-described (18) rewriting and the like, and therefore, the detailed description thereof is omitted.

If CGW13 determines that the configuration information is rewritten (yes in S2707), it determines the method of overwriting the configuration information (S2709). That is, CGW13 determines whether to instruct overwriting of the configuration information during rewriting of the application or to instruct overwriting of the configuration information after rewriting of the application, as the method of overwriting of the configuration information. CGW13 determines, for example, a method of overwriting rewriting specification data, and instructs overwriting of the placement information during rewriting of the application program if the program is designated for rewriting, and instructs overwriting of the placement information after rewriting of the application program if the program is designated for rewriting. Before the above-described determination of the overwriting method, CGW13 may refer to the type of overwriting of the arrangement data described in the overwriting specification data, and determine which of the overwriting and the write-back is to be used for overwriting of the arrangement information. When rewriting the configuration information using the overwrite, as described in the present embodiment, the configuration for rewriting the configuration information using the write-back is described in (28) a rewrite instruction process based on the write-back of the configuration information.

When CGW13 specifies the method of overlaying the configuration information, the configuration information is temporarily stored (S2710). The CGW13 distributes the arrangement information included in the distribution packet to the rewrite target ECU19, and instructs the rewrite target ECU19 to overwrite the arrangement information according to the determined overwrite method (S2711, corresponding to the arrangement information overwrite instruction step). When the rewriting ECU19 instructs the CGW13 to overwrite the layout information, the layout information is overwritten.

After the rewrite of the application program is instructed to the rewrite target ECU19 or after the overwriting of the configuration information is instructed to the rewrite target ECU19, the CGW13 determines whether or not the configuration information is normally overwritten and whether or not the rollback is necessary (S2712). Here, if it is determined that the normal overwriting of the configuration information is normally completed and the configuration information is normally overwritten, and it is determined that the rollback is not necessary (S2712: no), CGW13 ends the rewriting instruction processing based on the overwriting of the configuration information.

On the other hand, if it is determined that the normal overlay of the configuration information is not normally completed or the abnormal overlay of the configuration information is completed, and it is determined that the rollback is necessary (yes in S2712), the CGW13 instructs the rewrite target ECU19 to rollback, instructs the rewrite target ECU19 to restore the stored configuration information (S2713), and ends the rewrite instruction processing based on the overlay of the configuration information. In this case, CGW13 may notify the center apparatus 3 that the configuration information is not normally covered.

When write back of the arrangement information is instructed from CGW13, the rewrite target ECU19 writes back the temporarily stored arrangement information in S2710. Thereafter, when there are a plurality of pieces of information on the rewrite target ECU19, the processing from S2705 to S2713 is repeated for each rewrite target ECU 19. When the CGW13 determines that rewriting of the application program is performed (yes in S2706), and instructs the ECU19 to rewrite the application program (S2708), the process of S2712 may not be performed.

Next, a case will be described in which a program update and a configuration information update are instructed to one rewriting target ECU 19. CGW13 includes a case where overwriting of configuration information is instructed during rewriting of an application program and a case where overwriting of configuration information is instructed after rewriting of an application program as a method of instructing overwriting of configuration information. When the CGW13 instructs overwriting of the configuration information during rewriting of the application, as shown in fig. 225, rewriting of the application is started (S2721), overwriting of the configuration information is instructed before the rewriting of the application is completed (S2722), and the rewriting of the application is completed (S2733). That is, CGW13 completes the installation of the program and further completes the overwriting of configuration information, after which the activation of the new program is performed.

When the CGW13 rewrites the configuration information after rewriting the application, as shown in fig. 226, rewriting of the application is started (S2731), and after rewriting of the application is completed (S2732), overwriting of the configuration information is instructed (S2723). That is, CGW13 completes the installation of the program and performs the activation of the new program, followed by indicating the override of the configuration information.

Fig. 227 shows the sequence in the case of receiving the configuration information from the center apparatus 3, unlike the distribution packet. When receiving the configuration information from the center apparatus 3 after the activity notification, the DCM12 stores the received configuration information. DCM12 sends a configuration information reception notification to CGW13, and when receiving a configuration information acquisition request from CGW13, sends the stored configuration information to CGW 13. For example, in the case of the flowchart shown in fig. 225, the CGW13 transmits a configuration information acquisition request to the DCM12 to acquire configuration information during installation of a program. In the case of the flowchart shown in fig. 226, CGW13 transmits a configuration information acquisition request to DCM12 to acquire configuration information after activation of a new program.

Upon receiving the arrangement information from the DCM12, the CGW13 transmits an information write request to the rewrite target ECU19, and instructs the rewrite target ECU19 to overwrite the arrangement information. The rewrite target ECU19 overwrites the configuration information when receiving the information write request from the CGW13, and transmits a write response to the CGW13 when overwriting the configuration information is completed.

As described above, the CGW13 performs the rewriting instruction processing based on the overwriting of the configuration information, and instructs the rewriting ECU19 to overwrite the new configuration information during or after the rewriting of the application by the rewriting ECU 19. Even when the structure of the flash memory is changed at the time of rewriting the application program in the rewrite target ECU19, the arrangement information can be used appropriately.

The rewrite instruction processing based on write back of the configuration information will be described with reference to fig. 228 to 239. The vehicle program rewriting system 1 performs rewriting instruction processing based on write back of the configuration information in the CGW 13. In the above (27) rewriting instruction processing based on the overwriting of the configuration information, the description has been given of a configuration in which the overwriting is performed by the new configuration information acquired from the center device 3 or by the old configuration information stored in the flash memory. In the present embodiment, a configuration will be described in which new configuration information is generated based on old configuration information stored in a flash memory, and the configuration information is updated. CGW13 determines which of overwriting and write-back is used for rewriting of the configuration information, based on the rewriting specification data (fig. 8). Here, the kind of rewriting of the configuration information is specified as write-back, so CGW13 indicates rewriting based on the write-back of the configuration information. The write-back of the configuration information means that the configuration information is updated by new configuration information processed using the content of the old configuration information.

As shown in fig. 228, CGW13 includes an old configuration information acquisition unit 94a, a configuration information write-back instruction unit 94b, a new configuration information generation unit 94c, an old configuration information transmission unit 94d, a new configuration information reception unit 94e, and a specific information acquisition unit 94f in the rewrite instruction unit 94 based on write-back of configuration information. The old arrangement information acquisition unit 94a acquires the old arrangement information from the rewrite target ECU 19. The arrangement information write-back instruction unit 94b instructs the rewrite target ECU19 to write back new arrangement information in which the old arrangement information is processed, during or after rewriting of the application program, thereby rewriting the arrangement information.

When the old arrangement information is acquired by the old arrangement information acquiring unit 94a, the new arrangement information generating unit 94c processes the acquired old arrangement information to generate new arrangement information. The new-configuration-information generating unit 94c generates new configuration information by processing the old configuration information by a processing method specified by the rewriting specification data, for example. The new configuration information generation unit 94 processes the old configuration information, for example, by converting the data format from 16 bits to 32 bits, which is a relatively simple process.

When the old configuration information is acquired by the old configuration information acquiring unit 94a, the old configuration information transmitting unit 94d transmits the acquired old configuration information from the DCM12 to the center apparatus 3. The new configuration information receiving unit 94e receives new configuration information generated by processing the old configuration information by the center device 3 from the center device 3 via the DCM 12. The center device 3 generates new configuration information by processing the old configuration information by a processing method specified in advance. The processing performed by the center device 3 on the old configuration information is, for example, processing that is relatively complicated, such as using the old configuration information as an input value and converting the input value into a value suitable for an operation in a new program.

The specifying information acquiring unit 94f acquires specifying information capable of specifying the old configuration information stored in the flash memory from each ECU 19. In this case, when the SID and DID are specified by the rewriting specification data, the specifying information acquiring unit 94f acquires the specifying information from each ECU19 using the SID and DID specified by the rewriting specification data. The specifying information acquiring unit 93b acquires, as specifying information, a software version indicating a version of a program and a layout information version indicating a version of layout information, as configuration information of the ECU 19.

Next, the operation of the above-described structure will be described with reference to fig. 229 to 239. CGW13 executes a rewrite instruction program based on the write back of the configuration information, and performs a rewrite instruction process based on the write back of the configuration information. Here, a case where the configuration information is updated together with the update of the program will also be described.

CGW13 starts the rewrite instruction processing based on the write back of the configuration information at a predetermined timing such as when IG is turned on. First, the CGW13 collects vehicle information as configuration information of each ECU19, and acquires a software version and a configuration information version (S2801). The CGW13 causes the collected vehicle information to be transmitted from the DCM12 to the center apparatus 3 (S2802). The CGW13 determines the presence or absence of an activity notification related to a program update based on the notification from the center apparatus 3 acquired via the DCM12 (S2803). If the CGW13 determines that there is an activity notification (yes in S2803), the distribution packet is downloaded from the center device 3 to the DCM12(S2804), and rewriting of the specification data is confirmed (S2805).

The CGW13 determines whether or not the application is rewritten or the configuration information is rewritten, based on the type of data written to the rewriting specification data of the ECU19 to be rewritten (S2806, S2807). Specifically, CGW13 determines that the placement information is rewritten if the write data type is "placement data", and determines that the application is rewritten if the write data type is other than the "placement data".

When the CGW13 determines that the application is rewritten (yes in S2806), the process proceeds to rewrite instruction processing of the application (S2808). When the rewriting instruction processing of the application is started, CGW13 analyzes the rewriting specification data and determines whether or not it is necessary to acquire the arrangement information of ECU19 to be rewritten (S2821). CGW13 determines that the acquisition of the configuration information is necessary if the acquisition necessity of the configuration data in which the specification data is rewritten is specified as necessary, and determines that the acquisition of the configuration information is unnecessary if the acquisition necessity of the configuration data is specified as unnecessary.

If the CGW13 determines that it is necessary to acquire the arrangement information (S2821: yes), it acquires the arrangement information stored in the flash memory from the ECU19 to be rewritten (S2822), analyzes the rewriting specification data, and determines whether the processing method and the write-back method of the acquired old arrangement information require processing of the determined arrangement information in the center apparatus 3 (S2823). The CGW13 determines that the arrangement information needs to be processed by the center device 3 if the type of processing of the arrangement data in which the specification data is rewritten is designated as the center device, and determines that the arrangement information does not need to be processed by the center device 3 if the type of processing is designated as the CGW.

If the CGW13 determines that the configuration information needs to be processed by the center apparatus 3 (S2823: yes), the obtained configuration information is transmitted from the DCM12 to the center apparatus 3 (S2824). The CGW13 receives the configuration information distributed from the center apparatus 3 (S2825), temporarily stores the received configuration information as new configuration information (S2827), instructs rewriting of the application (S2828), and ends the rewriting instruction processing of the application.

When the CGW13 determines that the arrangement information does not need to be processed in the center device 3 (S2823: no), the arrangement information on which the processing has been performed is temporarily stored as new arrangement information (S2827) based on the rewriting specification data processing arrangement information (S2826), rewriting of the application is instructed (S2828), and the processing of instructing rewriting of the application is terminated.

If the configuration information is rewritten (yes in S2807), CGW13 proceeds to the rewriting process of the configuration information (S2809). When the CGW13 starts the rewriting process of the arrangement information, the rewriting specification data is analyzed to determine whether or not the arrangement information needs to be acquired (S2831). CGW13 determines that the acquisition of the configuration information is necessary if the acquisition necessity of the configuration data in which the specification data is rewritten is specified as necessary, and determines that the acquisition of the configuration information is unnecessary if the acquisition necessity of the configuration data is specified as unnecessary.

If the CGW13 determines that the arrangement information needs to be acquired (S2831: yes), it acquires the arrangement information stored in the flash memory from the ECU19 to be rewritten (S2832), analyzes the rewriting specification data, specifies the processing method and the write-back method of the acquired old arrangement information, and determines whether the arrangement information needs to be processed in the center apparatus 3 (S2833). The CGW13 determines that the arrangement information needs to be processed in the center device 3 if the type of processing of the arrangement data in which the specification data is rewritten is specified as the center device, and determines that the arrangement information does not need to be processed in the center device 3 if the type of processing is specified as the CGW.

If the CGW13 determines that the arrangement information needs to be processed in the center apparatus 3 (S2833: yes), the obtained arrangement information is transmitted from the DCM12 to the center apparatus 3 (S2834). The CGW13 receives the configuration information distributed from the center apparatus 3 (S2835), temporarily stores the received configuration information as new configuration information (S2837), and ends the rewriting process of the configuration information.

When the CGW13 determines that it is not necessary to process the placement information in the center apparatus 3 (S2833: no), the placement information is processed based on the rewriting specification data (S2836), the placement information that has been processed is temporarily stored as new placement information (S2837), and the rewriting instruction processing of the application is terminated.

After the rewrite instruction processing of the application or the write back instruction processing of the configuration information is finished, CGW13 determines whether or not the configuration information is normally written back, thereby determining whether or not rollback is necessary (S2810). Here, if it is determined that the normal configuration information is normally written back because the normal write back of the configuration information is normally completed, and it is determined that the rollback is not necessary (S2810: no), CGW13 ends the rewrite instruction processing based on the write back of the configuration information.

On the other hand, if it is determined that the configuration information is not normally written back because the write-back of the normal configuration information is not normally completed or the write-back of the abnormal configuration information is completed, and it is determined that the rollback is necessary (yes in S2810), CGW13 instructs the rewrite target ECU19 to rollback, instructs the rewrite target ECU19 to restore the stored configuration information (S2811), and ends the rewrite instruction processing based on the overwriting of the configuration information. In this case, CGW13 may notify center device 3 that the configuration information is not normally written back.

When write back of the arrangement information is instructed from the CGW13, the ECU19 to be rewritten writes back the arrangement information temporarily stored in S2827 or S2837. Hereinafter, when there are a plurality of pieces of information of the ECU19 to be rewritten, the processing from S2805 to S2811 is repeated for each ECU19 to be rewritten. When the CGW13 determines that the application is rewritten (yes in S2706), and instructs the ECU19 to rewrite the application (S2708), the process of S2712 may not be performed.

Next, a case where one rewrite target ECU19 instructs a program update and a layout information update will be described.

CGW13 is a method of instructing write back of configuration information, and includes a case of instructing write back of configuration information during rewriting of an application program and a case of instructing write back of configuration information after rewriting of an application program. CGW13 also includes a case of acquiring the placement information stored in the distribution packet, a case of acquiring the distribution packet after acquiring the placement information, and a case of acquiring the placement information after acquiring the distribution packet.

When the CGW13 acquires the configuration information stored in the distribution packet and instructs the write-back of the configuration information during the rewriting of the application, as shown in fig. 232, the CGW13 starts the rewriting of the application when receiving the distribution packet storing the configuration information (S2841), instructs the write-back of the configuration information before the completion of the rewriting of the application (S2842), and completes the rewriting of the application (S2843). That is, CGW13 completes the installation of the program and further completes the write back of the configuration information, after which the activation of the new program is performed.

When the CGW13 acquires the configuration information stored in the distribution packet and instructs the write-back of the configuration information after the rewriting of the application, as shown in fig. 233, when the distribution packet storing the configuration information is received, the rewriting of the application is started (S2851), the rewriting of the application is completed (S2852), and the write-back of the configuration information is instructed (S2853). That is, CGW13 instructs write back of configuration information after completion of installation of a program and activation of a new program.

When the CGW13 acquires the distribution packet after acquiring the configuration information and instructs the write back of the configuration information during the rewriting of the application, as shown in fig. 234, when the configuration information is received and the distribution packet is received, the rewriting of the application is started (S2861), and the write back of the configuration information is instructed before the rewriting of the application is completed (S2862), and the rewriting of the application is completed (S2863). That is, CGW13 completes the installation of the program and further completes the write back of the configuration information, after which the activation of the new program is performed.

When the CGW13 acquires the distribution packet after acquiring the configuration information and instructs write-back of the configuration information after rewriting the application, as shown in fig. 235, when the configuration information is received and the distribution packet is received, the application starts to be rewritten (S2871), and after the application completes to be rewritten (S2872), the write-back of the configuration information is instructed (S2873). That is, CGW13 instructs write back of configuration information after completion of installation of a program and activation of a new program.

When the CGW13 acquires the configuration information after acquiring the distribution packet and instructs the write back of the configuration information during the rewriting of the application, as shown in fig. 236, the application starts the rewriting of the application when the distribution packet is received (S2881), and instructs the write back of the configuration information before the application completes the rewriting of the application (S2882) and completes the rewriting of the application when the configuration information is received (S2883). That is, CGW13 completes the installation of the program and further completes the write back of the configuration information, after which the activation of the new program is performed.

When the CGW13 acquires the distribution packet and then the configuration information, and instructs the write back of the configuration information after the rewriting of the application, as shown in fig. 237, the rewriting of the application is started when the distribution packet is received (S2891), and the write back of the configuration information is instructed when the rewriting of the application is completed when the configuration information is received (S2892). That is, CGW13 instructs write back of configuration information after completion of installation of a program and activation of a new program.

When the CGW13 holds the arrangement information, it transmits an information acquisition request to the rewrite target ECU19 as shown in fig. 238, and when receiving the arrangement information from the rewrite target ECU19, it saves the received arrangement information. Thereafter, the CGW13 transmits an information write request to the rewrite target ECU19, and receives a write response from the rewrite target ECU19 when the rewrite of the arrangement information is completed in the rewrite target ECU 19.

In the case where the configuration information is held by the DCM12, as shown in fig. 239, the CGW13 transmits an information acquisition request to the rewrite target ECU19, and upon receiving the configuration information from the rewrite target ECU19, transmits an information storage request to the DCM12, and transmits the received configuration information to the DCM 12. Upon receiving the configuration information acquisition from CGW13, DCM12 transmits a save response to CGW13 and saves the received configuration information. The CGW13 transmits an information acquisition request to the DCM12, receives the arrangement information from the DCM12, transmits an information write request to the rewrite target ECU19, and receives a write response from the rewrite target ECU19 when the write-back of the arrangement information is completed in the rewrite target ECU 19.

As described above, the CGW13 performs the rewrite instruction processing based on the write-back of the configuration information, and instructs the rewrite target ECU19 to write back the new configuration information while or after the rewrite target ECU19 rewrites or rewrites the application. Even when the structure of the flash memory is changed when the application program is rewritten in the rewrite target ECU19, the arrangement information can be used appropriately.

(29) Rewrite instruction processing based on specific mode

The rewriting instruction processing in the specific mode will be described with reference to fig. 240 to 246. The vehicle program rewriting system 1 performs a rewriting instruction process in the CGW13 in accordance with a specific mode. A program executed in an environment used by a user of a vehicle is updated to a normal mode, whereas a program executed in a factory, a dealer, or the like is updated to a specific mode. Hereinafter, as the specific mode, a plant mode, which is a program update performed at a plant, and a dealer mode, which is a program update performed at a dealer, will be described.

As shown in fig. 240, the flash memory of the ECU19, which is stored as a stock in the factory environment of the manufactured vehicle, stores a factory software product number and a factory flag, and the initial software is written in the write area of the application as incomplete temporary software. The incomplete temporary software is software that includes only software for executing the program update, in addition to the activation process and the communication process of the ECU 19. For example, in the case of an engine ECU, the initial software does not include a program for engine control.

As shown in fig. 241, CGW13 includes a specific mode determination unit 95a and a rewrite instruction unit 95b in a rewrite instruction unit 95 based on a specific mode. The specific mode determination unit 95a determines whether or not the specific mode is set using the analysis result of the rewriting specification data. That is, the specific mode determination unit 95a determines the mode information from the rewriting specification data for CGW shown in fig. 8, determines the program update based on the normal mode if the mode information is "normal", determines the program update based on the factory mode if the mode information is "factory", and determines the program update based on the dealer mode if the mode information is "dealer".

When the specific mode determination unit 95a determines that the specific mode is set, the rewrite instruction unit 95b instructs the rewrite target ECU19 to write data based on the specific mode and controls the update process of the program based on the specific mode. That is, when the specific mode determination unit 95a determines that the factory mode is set, the rewrite instruction unit 95b instructs the rewrite target ECU19 to write data based on the factory mode, and controls the update process of the program based on the factory mode. When the specific mode determination unit 95a determines that the dealer mode is set, the rewrite instruction unit 95b instructs the rewrite target ECU19 to write data based on the dealer mode, and controls the update process of the program based on the dealer mode. When the rewrite instruction unit 95b instructs writing of write data in the factory mode or the dealer mode, it instructs the rewrite target ECU19 or the like to write the write data in which the processing for approving rewriting of the update of the program, the processing for displaying progress, and the processing for performing the security function such as integrity verification of the write data are omitted. The writing of the write data in which the process of performing the security function is omitted refers to, for example, the writing of the encryption process by the center apparatus 3 and the decryption process by the rewrite target ECU19 and the writing of the plaintext data (unencrypted data), the writing of the management process in which the above-described (6) security access key is omitted, and the writing of the verification process in which the data written in (7) is omitted.

As shown in fig. 242, the plant device 1001 is configured by, for example, a computer terminal functioning as a server in a plant, and is configured by one computer terminal or a plurality of computer terminals that cooperate with each other. The plant device 1001 has a function of performing data communication with the DCM12 wirelessly, a function of receiving operation input from a plant operator, and the like, and can perform data communication with the CGW13 via the DCM12 in a plant environment. The CGW13 instructs the writing of the writing data in the factory mode to the ECU19 to be rewritten in a state of being wirelessly connected to the factory device 1001 via the DCM12, and controls the update processing of the program in the factory mode.

As shown in fig. 243, the dealer device 1002 is configured by, for example, a computer terminal that functions as a server in the dealer, and is configured by one computer terminal or a plurality of computer terminals that cooperate with each other. The dealer device 1002 has a function of performing data communication with the DCM12 wirelessly, a function of receiving an operation input from an operator of the dealer, and the like, and can perform data communication with the CGW13 via the DCM12 in the dealer environment. The CGW13 instructs the rewrite target ECU19 to write data in accordance with the dealer mode while being wirelessly connected to the dealer apparatus 1002 via the DCM12, and controls the update process of the program in accordance with the dealer mode.

The factory equipment 1001 and the dealer equipment 1002 have the same functions as the center device 3. That is, in the same manner as the case where the program update is performed in the normal mode in the state where the center apparatus 3 and the CGW13 are connected, the program update is performed in the factory mode in the state where the factory devices 1001 and the CGW13 are connected, and the program update is performed in the dealer mode in the state where the dealer devices 1002 and the CGW13 are connected. The factory device 1001 and the dealer device 1002 have functions equivalent to those of the package management unit 3A, the configuration information management unit 3B, the individual vehicle information management unit 3C, and the activity management unit 3D of the center apparatus 3 shown in fig. 264, which will be described later, and perform program update in the factory mode or the dealer mode by performing processing equivalent to that of program update performed on the CGW13 by the center apparatus 3. That is, the plant device 1001 and the dealer device 1002 can easily have a configuration having a function related to program update of the center apparatus 3, and can perform program update in the plant mode or the dealer mode. The factory device 1001 functions as the center apparatus 3 for program update in the factory mode, and the dealer device 1002 functions as the center apparatus 3 for program update in the dealer mode.

In the present embodiment, the configuration in which the plant device 1001 and the dealer device 1002 perform data communication with the CGW13 via the DCM12 is exemplified, but the plant device 1001 and the dealer device 1002 may not be provided with a function of performing data communication with the DCM 12. For example, by transmitting an update instruction of a program based on the factory mode from the factory device 1001 to the center apparatus 3, the center apparatus 3 and the CGW13 may perform data communication via the DCM12 to update the program in the factory mode. Similarly, by transmitting an update instruction of the program based on the dealer mode from the dealer apparatus 1002 to the center apparatus 3, the center apparatus 3 can perform data communication with the CGW13 via the DCM12 and perform program update in the dealer mode.

Further, since the factory equipment 1001 is wirelessly connected to the CGW13 as described above, the program update process can be performed even when the vehicle incorporating the CGW13 is moving on a production line in a factory. That is, in the configuration in which the plant 1001 and the CGW13 are connected by wire, for example, the moving range of the vehicle is limited in the process of updating the program according to the length of the communication line, and the vehicle is not easily moved, and there is a fear that the moving range may affect the progress of the vehicle manufacturing process. Similarly, in the dealer apparatus 1002, the dealer apparatus 1002 and the CGW13 are wirelessly connected, and the influence on the progress of the maintenance process and the inspection process of the vehicle can be suppressed.

Next, the operation of the above-described structure will be described with reference to fig. 244 to 246. Here, a case where writing of data is instructed by the rewrite target ECU19 in a factory environment will be described. CGW13 executes a rewrite instruction program based on the specific pattern, and performs rewrite instruction processing based on the specific pattern.

First, a rewriting instruction process by CGW13 in a specific pattern will be described. When the rewrite instruction processing by the specific mode is started, CGW13 determines whether or not the plant is connected after power-on (S2901). When the CGW13 determines that the factory device is connected after the power is turned on (S2901: yes), the activity notification is confirmed, the rewriting specification data is acquired (S2902), and rewriting processing is prepared (S2903). CGW13 determines the mode information of the rewritten specification data, and determines whether or not any of the factory mode and the normal mode is set (S2904, S2905, corresponding to the specific mode determination step).

When the CGW13 determines that the mode information is "normal" in the rewriting specification data and the normal mode is set (S2905: yes), rewriting in the normal mode is instructed to the ECU19 to be rewritten (S2906). That is, CGW13 indicates that program update is performed in the normal mode, although it is an environment connected to plant 1001. Thereafter, CGW13 performs data communication with center device 3, performs program update in the normal mode, and ends the rewrite instruction processing in the specific mode.

When the CGW13 determines that the mode information is "factory" in the rewriting specification data and the factory mode is set (S2904: yes), rewriting by the factory mode is instructed to the rewriting ECU19 or the like (S2907, corresponding to the specific mode write instruction step). That is, CGW13 is an environment connected to plant 1001, and instructs ECU19 to be rewritten or the like to perform program update in the plant mode. Thereafter, CGW13 communicates data with the plant equipment, performs program update in the plant mode, and ends the rewrite instruction processing based on the specific mode.

In the factory mode, the CGW13 does not perform a display instruction to the in-vehicle display 7 in order to omit a process of obtaining user's approval about the update of the program and a process of displaying the progress of the program update. CGW13 facilitates the process by treating it as having consent from the user. CGW13 does not perform secure access to rewrite target ECU19 using the key as described in (6) management processing of the secure access key. CGW13 does not perform the verification process of the write data using the key as described in the verification process of the write data of (7).

Next, a rewriting process by the specific mode performed by the rewriting ECU19 will be described. The ECU19 to be rewritten performs the rewriting instruction processing in accordance with the specific mode by the CGW13, instructs the rewriting of the specific mode, and performs the rewriting processing in accordance with the specific mode. When the rewrite processing by the specific mode is started, the rewrite target ECU19 determines whether or not the completion of normal rewrite is confirmed after power-on (S2911). When the rewrite target ECU19 determines that normal rewrite completion has not been confirmed after power-ON (S2911: no), it determines whether or not the factory flag is set to ON (ON) (S2912). When the rewrite target ECU19 determines that the factory flag is not set to on (S2912: no), it performs rewrite in the normal mode (S2913), and ends the rewrite processing in the specific mode.

When the ECU19 to be rewritten determines that the factory flag is set to on (S2912: yes), it performs rewriting by the factory mode (S2914). The rewrite target ECU19 determines that access to the ECU19 is permitted even if secure access using a key is not available in the factory mode. Since the written data is in the clear text, the ECU19 to be rewritten omits the decryption process and performs the rewriting process. Next, the rewrite target ECU19 determines whether or not writing of the write data is completed (S2915). When the ECU19 to be rewritten determines that writing of the write data is completed (yes in S2915), it turns OFF the factory flag (S2916) and ends the rewriting process in the specific mode. The ECU19 to be rewritten sets the factory flag to off, and thus, even if writing of write data is instructed after writing of the write data, the write data is not written as the factory mode, that is, second writing of the write data in the factory mode is prohibited. Since the process of performing the security function is omitted in the factory mode, the write process is permitted only once in consideration of the security aspect.

Although the above description has been made of the case where writing of write data is instructed to the ECU19 to be rewritten in a factory environment, the same is also true of the case where writing of write data is instructed to the ECU19 to be rewritten in a dealer environment. That is, CGW13 determines the mode information of the rewriting specification data, instructs rewriting in the dealer mode if it is determined that the dealer mode is set, and rewrites in the dealer mode if it is determined that the dealer mode is set to on by rewrite target ECU 19.

The contents of the rewriting by the factory mode and the dealer mode will be described below with reference to fig. 246. First, the need for display of progress of rewriting will be described. In the rewriting in the factory mode and the dealer mode, CGW13 does not display the progress of the instruction of rewriting on in-vehicle display 7 and the like from the activity notification to the next IG on time. That is, in the factory mode, there is a possibility that the display device such as the in-vehicle display 7 is not mounted in the middle of the vehicle manufacturing, and even if the display device such as the in-vehicle display 7 is mounted, the progress of rewriting is not displayed for the reason that the operator sufficiently grasps the procedure of updating the program. In addition, in the dealer mode, even if the display device such as the in-vehicle display 7 is mounted, the CGW13 does not instruct the in-vehicle display 7 or the like to display the progress of rewriting until the next IG on time from the event notification because the operator sufficiently grasps the procedure of updating the program.

Next, rewriting based on the factory mode will be described. In the factory mode, as the number of objects to be rewritten, there are a case where all the ECUs mounted on the vehicle are rewritten together (hereinafter, referred to as rewriting step 1) and a case where the ECUs are rewritten every time they are mounted (hereinafter, referred to as rewriting step 2). In the case of rewriting all the ECUs mounted on the vehicle at once, the order of mounting on the vehicle is assumed, and the order is specified by rewriting specification data. That is, the factory device 1001 generates rewriting specification data in advance in which the order is designated, generates a package file including update data and rewriting specification data in advance, and distributes the package file to the host apparatus 11. In the case of rewriting each time an ECU is installed, after the connection of the ECU is completed, the connected ECU is specified by rewriting specification data. That is, the plant 1001 generates rewriting specification data for each ECU in advance, generates a packet file for each ECU including update data and rewriting specification data in advance, and distributes the packet file for the connected ECU to the host apparatus 11.

In factory mode, no activity notification is needed during the activity notification phase. In the downloading phase, the downloading is performed without the consent of the downloading. That is, CGW13 does not instruct on-vehicle display 7 to display the download approval screen (fig. 34 and 35). In this case, since all the ECUs mounted on the vehicle are rewritten at once in rewriting step 1, downloading is performed once, and since rewriting is performed every time an ECU is mounted in rewriting step 2, downloading is performed for each connected ECU. At the stage of installation, the installation is performed without approval of the installation. That is, CGW13 does not display an approval screen (see fig. 39) for instructing the in-vehicle display 7 to install. In the activation stage, activation is appropriately performed for each group in which the mounting is completed in rewriting step 1, or after the mounting of all ECUs is completed, and activation is appropriately performed for each ECU in which the mounting is completed in rewriting step 2. The next time the IG is turned on, no operator confirmation is required. That is, CGW13 does not instruct the in-vehicle display 7 to display a confirmation screen (see fig. 44) indicating completion of updating.

Next, the dealer-based rewrite will be described. In the dealer mode, only the ECU to be replaced is the number of objects to be rewritten. That is, since the ECU to be replaced cannot be identified according to the repair contents, rewriting is performed one by one (rewriting step 2). In the same manner as in the factory mode, incomplete temporary software is written in the write area of the write data of the replaced ECU, and the program of the replaced ECU is updated in the communication environment between the dealer device 1002 and the host apparatus 11. At this time, the dealer apparatus 1002 acquires the configuration information of each ECU from the vehicle, and distributes a data packet containing a program that matches the vehicle.

In the dealer mode, at the stage of the activity notification, the dealer flag explained in the screen display control processing of the above-described (24) progress display is followed. That is, if the execution is specified by the dealer logo, the activity notification is performed, and if the execution is not specified by the dealer logo, the activity notification is not required. In the stage of downloading, according to the dealer mark described in the screen display control processing of the progress display of (24), if it is specified that approval is required, approval for downloading is required, and if it is specified that approval is not required, approval for downloading is not required, and downloading is performed for each ECU to which connection has been completed. At the stage of installation, according to the dealer mark explained in the screen display control processing of the progress display of (24), if it is specified that approval is required, approval for installation is required, and if it is specified that approval is not required, approval for installation is not required, and installation is performed for each ECU that has completed downloading. In the stage of activation, activation is appropriately performed for each ECU whose installation is completed. Even at the next IG on, confirmation of activation completion is required if confirmation is designated as necessary, and confirmation of activation completion is not required if confirmation is designated as unnecessary, according to the dealer flag described in the screen display control processing of the progress display of (24) above.

As described above, when the specific mode is set by performing the rewriting instruction processing in the specific mode, CGW13 instructs the writing of the write data in the specific mode to ECU19 to be rewritten. As in the case of writing the write data downloaded from the center device 3 to the rewrite target ECU19, the write data can be written to the rewrite target ECU19 even in a factory environment, a dealer environment, or the like. In other words, the function of program update in the market by the normal mode can be appropriated, and program update in the factory environment and the dealer environment can be realized. It is not necessary to prepare many ECUs depending on the program such as the grade of each vehicle, and it is possible to reduce the stock of electronic control devices to be managed in a predetermined environment such as a factory environment or a dealer environment and to write data appropriately.

The overall procedure of program update including the above-described characteristic processes (1) to (29) will be described with reference to fig. 247 to 257. Here, an example will be described in which the application programs of the ECU (ID1), the ECU (ID2), and the ECU (ID3) connected to the first bus are rewritten, and the application programs of the ECU (ID4), the ECU (ID5), and the ECU (ID6) connected to the second bus are not rewritten. The ECU (ID1) and the ECU (ID4) are single-sided single memories, the ECU (ID5) is a single-sided suspend memory, and the ECUs (ID2), the ECU (ID3) and the ECU (ID6) are double-sided memories. The ECU (ID1), the ECU (ID4), the ECU (ID5), and the ECU (ID6) are IG electric power source system ECUs, the ECU (ID2) is an ACC electric power source system ECU, and the ECU (ID3) is a + B electric power source system ECU.

First, as a preparation in advance, the user operates the mobile terminal 6 or the like, inputs personal information such as a vehicle number (vehicle identification number) and a mobile phone number, and registers an account in the center apparatus 3 (S5001). Further, the user operates the mobile terminal 6 or the like to input an execution condition, and specifies a vehicle position, a time period, and the like as a condition for allowing execution of the program update. The center apparatus 3 stores the personal information and the like received via the mobile terminal 6 in the database (S5002).

In addition, the CGW13 of the vehicle-side system 4 collects information about the vehicle (S5011), and uploads the information to the center apparatus 3 via the DCM12 (S5012). Specifically, the information includes a program version, a memory configuration of each ECU19, operation surface information, electric components mounted on the vehicle, a vehicle position, and a power supply state of the vehicle. The center device 3 stores the information received from the vehicle-side system 4 in the database (S5013).

When the necessity of the program update occurs, the center device 3 generates rewriting specification data shown in fig. 7 and 8 based on the written data provided from the supplier, which is the provider of the application, and the information stored in the database. The center device 3 generates rebuilt data based on the write data, the authentication code thereof, and the rewriting specification data. The center device 3 packages the generated rebuilt data, the separately generated distribution specification data (fig. 45), and the packet identifier into one file, generates a distribution packet, and registers the distribution packet (S5021).

After completing preparation of the distribution packet, the center apparatus 3 notifies the user of the program update. The center apparatus 3 refers to the personal information stored in the database, and transmits a Short Message Service (SMS) to the mobile terminal 6 (S5031). By the user operation, the mobile terminal 6 connects to a URL (Uniform Resource Locator) recorded in the SMS, and displays the notification content (S5032). The mobile terminal 6 notifies the center apparatus 3 of the content approved to be updated based on the program operated by the user or the content disapproved (S5033). The center device 3 registers the intention information (approval or disapproval) of the user in the database (S5034). Here, the user may be notified using the in-vehicle display 7 instead of the mobile terminal 6.

The CGW13 receives the distribution specification data transmitted from the center apparatus 3 via the DCM12, and transmits it to the in-vehicle display 7 (S5035). The in-vehicle display 7 analyzes the distribution specification data and displays a display sentence or the like as the notification content (S5036). The in-vehicle display 7 displays image data such as icons, and accepts input as to whether or not the user has approved program update. The CGW13 receives the user intention information from the in-vehicle display 7 and notifies the center apparatus 3 via the DCM12 (S5037).

When the user has received approval for the program update, the vehicle-side system 4 downloads the distribution packet from the center device 3. First, the center apparatus 3 checks whether or not an execution condition specified in advance by the user is satisfied (S5041). When none of the execution conditions is satisfied, the center device 3 does not transmit the distribution packet to the DCM 12. When all the execution conditions are satisfied, the center device 3 transmits the distribution packet to the DCM12 (S5042). When the DCM12 downloads the distribution package from the center apparatus 3, the downloaded distribution package is stored in the flash memory. Further, the DCM12 extracts the distribution packet authenticator from the distribution packet, and verifies the integrity of the rebuilt data and the distribution specification data (S5043).

The DCM12 calculates the certifier for the recomposed data and the distribution specification data using the key information stored in the CGW13, for example. DCM12 compares the calculated authenticator with the delivery packet authenticator extracted from the delivery packet, and determines that the verification is successful if the authenticators match each other, and determines that the verification is failed if the authenticators do not match each other. When the DCM12 determines that the verification has failed, the DCM deletes the distribution packet and notifies the CGW13 and the center apparatus 3 of the failure of the verification.

When determining that the verification of the distribution packet is successful, the DCM12 unpacks the rewriting data included in the distribution packet as shown in fig. 10, and divides the repackaged data into the writing data and the rewriting specification data for each of the rewriting target ECUs 19 (S5044). The rewriting specification data is divided into the rewriting specification data for DCM and the rewriting specification data for CGW in advance.

DCM12 transmits the rewriting specification data for CGW to CGW13 (S5045). The CGW13 analyzes rewriting specification data for CGW received from the DCM12, extracts necessary information, and authenticates the data written to each ECU19 with the DCM12 (S5046). The CGW13 calculates the authenticator of the write data (differential data) of the ECU (ID1) using the key information of the ECU (ID1) itself, for example. CGW13 compares the calculated authenticator with the authenticator extracted from the rebuilt data, and determines that the verification is successful if the authenticators match each other, and determines that the verification is failed if the authenticators do not match each other. If the CGW13 determines that the verification failed, it deletes the distribution packet and notifies the DCM12 and the center apparatus 3 of the content of the verification failure. Here, when it is determined that the verification has failed for any one of the written data, the CGW13 does not perform the program update for all the ECUs 19.

If the CGW13 determines that verification has succeeded for all the write data, it receives the distribution specification data from the DCM12 and transmits the received distribution start data to the in-vehicle display 7 (S5047). The in-vehicle display 7 stores the distribution specification data transmitted from the CGW 13. When the above download process is completed, the CGW13 notifies the center apparatus 3 of the content whose download is completed via the DCM12 (S5048).

When notified of the completion of the download from the vehicle-side system 4, the center apparatus 3 transmits an SMS to the portable terminal 6 (S5049). The mobile terminal 6 connects to the URL described in the SMS by a user operation, and displays an installation reservation screen (S5050). The mobile terminal 6 notifies the installation date and time input by the user operation to the center apparatus 3 (S5051). The center apparatus 3 stores the date and time of installation in the database in association with the personal information (S5052). Here, the user may reserve the installation date and time using the in-vehicle display 7 instead of the portable terminal 6. When the in-vehicle display 7 is notified of the completion of the download from the CGW13 (S5053), the installation reservation screen is displayed (S5054). The CGW13 notifies the center apparatus 3 of the installation date and time received from the in-vehicle display 7 via the DCM12 (S5055).

If the current date and time is the installation date and time registered in the database, the center device 3 instructs the vehicle-side system 4 to start installation (S5071). When the DCM12 instructs mounting from the center apparatus 3, the mounting execution condition is checked (S5072). The DCM12 checks, for example, the vehicle position, the communication condition with the center apparatus 3, and the like. The DCM12 authenticates the distribution packet using the packet authenticator when all the execution conditions are satisfied (S5073). If the authentication is successful, DCM12 unpacks the distribution packet (S5074), extracts the rewriting specification data for DCM and the rewriting specification data for CGW, and notifies CGW13 of the start of installation after dividing the distribution packet into the write data for each ECU19 (S5075).

When the start of mounting is notified from the DCM12, the CGW13 analyzes the rewriting specification data for CGW acquired from the DCM12, and determines which ECU19 is rewritten in which order (S5076). Here, the order of the first modified ECU (ID1), the second modified ECU (ID2), and the third modified ECU (ID3) is set. The CGW13 verifies all the write data for each rewrite target ECU19 stored in the DCM12 using the respective certifiers (S5077). Here, not only the write data for version upgrade but also the write data for rollback can be verified.

If the verification of the write data is successful, the CGW13 requests the electric power source management ECU20 to turn on the IG electric power source (S5078). When the rewriting-target ECU19 is an IG system ECU or an ACC system ECU when the vehicle is parked (the IG switch 42 is off and the ACC switch 41 is off), it is necessary to supply power to start the rewriting-target ECU 19. The electric power source management ECU20 requests the electric power source control circuit 43 to supply electric power in the same manner as the IG electric power source is turned on (S5079). When electric power is supplied to the IG power supply line 39 by the electric power supply control circuit 43, the IG system ECU and the ACC system ECU start (wake up).

Then, the CGW13 requests the non-rewritten ECU19, that is, the ECU (ID5), the ECU (ID5), and the ECU (ID6), and the second and subsequent rewritten ECUs (ID2) and the ECU (ID3) to sleep (S5080). Here, although the first ECU to be rewritten 19 is rewritten and then the second ECU to be rewritten 19 is rewritten, a plurality of ECUs to be rewritten 19 may be rewritten simultaneously in parallel. In this case, only the non-rewritten object ECU19 requests sleep.

In parallel with the mounting of each of the rewrite target ECUs 19, the CGW13 monitors the remaining battery level (S5081) and the communication load on the bus (S5082). CGW13 refers to the battery load value and the bus load value (bus load table) extracted from the CGW rewriting specification data, and controls the mounting within a range not exceeding the allowable value. CGW13 interrupts the installation at the time when the battery load reaches a permissible value, for example, in a stopped state.

For example, when the bus load of the first bus to which the ECU to be rewritten (ID1) is connected reaches the allowable value, the frequency of transmitting the write data to the ECU (ID1) is delayed in CGW 14. When the mounting to all of the rewrite target ECUs 19 is completed, the monitoring is terminated. In addition, in the case of a single-sided individual memory, the mounting cannot be completed in the middle of the mounting, and therefore, it is necessary to confirm that a sufficient battery remaining amount exists before the mounting is started.

The CGW13 notifies the first rewritten ECU (ID1) of the start of mounting (S5101). When the start of installation is notified from the CGW13, the ECU (ID1) changes the state to the wireless program update mode (S5102). Since the ECU (ID1) is a single-sided individual memory ECU, execution of an application program and diagnostic processing using a tool cannot be performed in parallel, and a program update dedicated mode by wireless is provided.

When the ECU (ID1) to be first rewritten is mounted, the CGW13 performs access authentication using the security access key (S5103). If the access authentication to the ECU (ID1) is successful, the CGW13 transmits the write data, that is, all data information to the ECU (ID 1). The ECU (ID1) determines whether the written data matches the ECU itself, using the information of all the received data (S5104). When the ECU (ID1) determines that the data matches, the ECU performs a write process.

The CGW13 obtains a divided file of a predetermined size (for example, 1 kbyte) in the write data to the ECU (ID1) from the DCM12, and distributes the divided file to the ECU (ID1) (S5105). The ECU (ID1) writes the split file received from the CGW13 to the flash memory 33d (S5106). When the writing is completed, the ECU (ID1) stores a retry point indicating where the flash address is written so that the writing can be restarted from the middle (S5107). As the retry point, a flag indicating where to perform erasing, writing, and subsequent processing to the flash memory may be stored. When storing the retry point, the ECU (ID1) notifies CGW13 of the completion of writing (S5108).

Upon receiving the notification of completion of writing from the ECU (ID1), the CGW13 notifies the center apparatus 3 of progress information of rewriting status via the DCM12 (S5109). The progress information is data such as the stage of installation and how many bytes of writing of the write data of the ECU (ID1) is completed. The center apparatus 3 updates the web page screen connectable from the mobile terminal 6 based on the progress information transmitted from the DCM12 (S5110). The mobile terminal 6 is connected to the center apparatus 3, and displays, for example, that the current installation has progressed to several% as the updated progress status (S5111). Thus, even when the vehicle is parked and the user is outside the vehicle, the progress of the mounting can be grasped by the mobile terminal 6. Here, instead of the mobile terminal 6, the progress may be displayed on the in-vehicle display 7. Upon receiving the notification of completion of rewriting from the ECU (ID1), the CGW13 notifies the in-vehicle display 7 of progress information of the rewriting status (S5112). The in-vehicle display 7 updates and displays the screen of the progress status (S5113). In the case of a two-sided memory structure such as an ECU (ID2) or an ECU (ID3), the vehicle can be mounted even when the vehicle is in a traveling state. Therefore, for example, in the case where the vehicle is in the IG switch on state, the in-vehicle display 7 may display the progress status.

Upon receiving the notification of the completion of writing from the ECU (ID1), the CGW13 acquires the second divided file as the next write data and distributes it to the ECU (ID 1). Thereafter, until the nth divided file as the last write data, the processes of S5105 to S5113 are repeated. When the writing is completed up to the nth divided file, the ECU (ID1) verifies the integrity of the flash memory update program and confirms whether the writing is correct (S5114). Upon receiving the notification from the ECU (ID1) that all the split files have been written and the integrity verification has succeeded, the CGW13 requests the ECU (ID1) to sleep (S5115). The ECU (ID1) does not start by the update program after installation, but temporarily sleeps.

The CGW13 requests wake-up to the second rewritten ECU (ID2) (S5201). The CGW13 notifies the ECU (ID2) of the content of the wireless-based program update, that is, the start of installation (S5202). As the internal state, the ECU (ID2) shifts the state to the program update mode by wireless (S5203). An ECU (ID2) serving as a dual-sided memory can execute an application program and perform tool-based diagnosis during the wireless program update mode. The CGW13 performs access authentication for the ECU (ID2) (S5204). The ECU (ID2) determines whether or not the difference data as the write data matches the ECU (S5205). Since the ECU (ID2) is a dual-sided memory, it is determined whether write data matching the non-operating surface of the flash memory is included. For example, if the surface a of the ECU (ID2) is an operating surface and the surface B is a non-operating surface, if the write data is an address that does not match the surface B, the CGW13 notifies the center device 3 of the content of the write data error via the DCM12 without proceeding to the subsequent processing. CGW13 performs rollback processing described later. When it is determined that the write data matches the ECU itself, a write process is performed on the ECU (ID 2). Thereafter, the processing of S5206 to S5216 by the ECU (ID2) is the same as S5105 to S5115. In S5207, when the differential data is written to the ECU (ID2) which is a dual-sided memory, the differential data is restored from the old data and the differential data to generate new data, as shown in fig. 18, and the new data is written to the flash memory 33 d.

When the ECU (ID2) is put to sleep after all the ECUs (ID2) are mounted, the CGW13 requests a wake-up from the third rewritten ECU (ID3) (S5301). The CGW13 notifies the ECU (ID3) of the wireless-based program update, that is, the start of installation of the content (S5302). As the internal state, the ECU (ID3) shifts the state to the program update mode by wireless (S5303). The CGW13 performs access authentication on the ECU (ID3) (S5304). The ECU (ID3) determines whether or not the difference data as the write data matches the ECU (S5305). When it is determined that the write data matches the ECU itself, a write process is performed on the ECU (ID 3). Thereafter, the processing of S5306 to S5315 related to the ECU (ID3) is the same as that of S5105 to S5114.

When the ECU (ID3) is completely mounted, the CGW13 terminates the monitoring of the remaining battery level and the monitoring of the communication load on the bus (S5316, S5317). Also, CGW13 requests wake-up to ECU (ID1) and ECU (ID2) (S5401).

In order for the ECU (ID1), the ECU (ID2), and the ECU (ID3) to start simultaneously with the updated program, the CGW13 requests the respective ECUs to activate the updated program (S5402). In the case of an ECU that does not respond to the request for activation, the ECU may be restarted by notifying power-off and power-on instead of the request for activation.

When receiving the activation request from the CGW13, the ECU (ID1) restarts itself (S5403). Since the ECU (ID1) is a single-sided separate memory, the ECU (ID1) is restarted by the updated program. If the restart after the installation is completed, the ECU (ID1) notifies the CGW13 of the updated program version in the same direction as the activation is completed (S5404).

Upon receiving the activation request from the CGW13, the ECU (ID2) updates the stored operation plane information from plane a to plane B (S5405), and restarts itself (S5406). When the ECU (ID2) is normally activated on the B-plane, the activation completion is notified to the CGW13 together with the updated program version and operation plane information (S5407).

Upon receiving the activation request from the CGW13, the ECU (ID3) updates the stored operation plane information from plane a to plane B (S5408), and restarts itself (S5409). When the ECU (ID3) normally starts on the B-plane, the activation completion is notified to the CGW13 together with the updated program version and operation plane information (S5410).

Upon receiving the activation completion notification from the ECU (ID1), the ECU (ID2), and the ECU (ID3), the CGW13 notifies the center apparatus 3 of the completion of the update of the program, the updated program version related to the rewrite target ECU (ID1), the ECU (ID2), and the ECU (ID3), and the operation surface information via the DCM12 (S5411). The center apparatus 3 registers the information notified from the DCM12 in the database (S5412), and updates the web page screen to the display indicating completion of the progress status (S5413). The portable terminal 6 is connected to the center apparatus 3, and displays a web page screen of the content for which the program update is completed (S5414). Further, upon receiving the activation completion notification from the ECU (ID1), the ECU (ID2), and the ECU (ID3), the CGW13 notifies the in-vehicle display 7 of the completion of the program update as the progress status (S5415). The in-vehicle display 7 displays the content of which the program update is completed (S5416). In addition, in a case where the progress display is not required such as when the vehicle is in a stopped state, the CGW13 does not notify the in-vehicle display 7 of the progress.

Finally, the CGW13 requests the electric power source management ECU20 to turn off the IG electric power source (S5418). The electric power source management ECU20 requests the electric power source control circuit 43 to cut off the electric power supply to return to the electric power source state in which the IG switch is off before the start of installation. When the electric power supply to the IG power supply line 39 and the ACC power supply line 38 is cut off by the electric power supply control circuit 43, the ECU (ID1), the ECU (ID2), the ECU (ID4), the ECU (ID5) and the ECU (ID6) are brought into a stopped state.

In the above example, since the program update including the ECU (ID1) which is a single-sided individual memory is performed, the program update is performed continuously from the time of installation to the time of activation when the vehicle is in the stopped state. However, for example, when all of the rewrite target ECUs 19 are the duplex memories, they may be mounted in the background during traveling. Further, the mobile terminal 6 may be configured to receive an approval for activation from the user at the time when the mounting of the rewrite target ECU19 is completed.

Next, with reference to fig. 254 to 257, a rollback sequence in a case where cancellation of a program update is selected by the user during installation of an application program will be described. Specifically, the following description will be made with respect to the case where the installation of the ECU (ID1) is completed and the ECU (ID2) is selected to be cancelled by the user at a point in time during the installation.

When the mobile terminal 6 notifies the cancellation of the program update, the center apparatus 3 instructs the vehicle-side system 4 to cancel the program update (S6001). Then, the center device 3 changes the web page screen to the display mode in the rollback as the progress status (S6002). The mobile terminal 6 displays a web page screen indicating the progress status in the rollback (S6003).

When cancellation of the program update is instructed from the center apparatus 3 via the DCM12, the CGW13 determines which ECU needs to be subjected to what rollback processing based on the memory configurations and the installation statuses of the rewrite target ECU (ID1), ECU (ID2), and ECU (ID3) (S6004). In this example, it is determined that the installation to the ECU (ID2) is completed and the contents of the rollback process of returning the ECU (ID1) to the original version are necessary.

Further, CGW13 notifies the in-vehicle display 7 of the progress for rollback (S6005). When the vehicle-mounted display 7 is notified of the progress for rollback from the CGW13, the display mode is changed to the display mode for rollback and the progress is displayed (S6006). The in-vehicle display 7 displays, for example, "in rollback", and displays the progress of the ECU (ID1) requiring rollback as 0%, and the progress of the ECU (ID2) as 0%.

As the rollback process for the ECU (ID2), CGW13 continues the installation of write data. Since the ECU (ID2) is a dual-sided memory, the mounting to the B-side, which is a non-operating side, may be interrupted halfway, and the operation may be continued with the a-side as an operating side. However, when the B-plane is in an incomplete state during mounting, the difference cannot be restored correctly when the next mounting using the difference data is performed. Therefore, the installation continues to be last for the ECU (ID 2).

Specifically, the CGW13 acquires a split file (for example, 1 kbyte in size) of write data for the ECU (ID2) from the DCM12, and distributes the split file to the ECU (ID2) (S6007). The ECU (ID2) writes the split file received from the CGW13 to the flash memory 33d (S6008). When the writing is completed, the ECU (ID2) stores the retry point so that the writing can be restarted from the middle (S6009), and notifies the CGW13 of the completion of the writing (S6010).

Upon receiving the notification of the completion of writing from the ECU (ID2), the CGW13 notifies the center apparatus 3 of progress information of the rollback state via the DCM12 (S6011). The progress information of the rollback condition refers to, for example, how many bytes of writing are required as rollback by the ECU (ID2), and how many bytes of data such as writing are accumulated. The center apparatus 3 can update the web screen connected from the mobile terminal 6 based on the progress information transmitted from the DCM12 (S6012). As the updated progress status, the mobile terminal 6 displays, for example, a web page screen for scrolling back up to several% or the like (S6013). Here, instead of the mobile terminal 6, the progress may be displayed on the in-vehicle display 7. Upon receiving the notification of the completion of rewriting from the ECU (ID2), the CGW13 notifies the in-vehicle display 7 of the progress information of the rollback state (S6014). The in-vehicle display 7 updates and displays the screen of the progress status (S6015). Thereafter, until the nth divided file as the last write data, the processes of S6007 to S6015 are repeated.

When the ECU (ID2) writes the file up to the nth divided file, the integrity of the update program of the flash memory 33d is verified (S6016). Upon receiving the installation completion notification from the ECU (ID2), the CGW13 requests the ECU (ID2) to sleep (S6017). The ECU (ID2) sleeps without being started by an update program installed on the non-operating side, i.e., the B-side.

Next, CGW13 requests wake-up from ECU (ID1) to perform rollback processing for ECU (ID1) (S6101). The CGW13 notifies the ECU (ID1) of the content of starting the installation for rollback (S6102). When the start of installation is notified from the CGW13, the ECU (ID1) shifts the state to the program update mode by wireless (S6103). The CGW13 performs access authentication with the ECU (ID1) (S6104). If the access authentication is successful, the ECU (ID1) determines whether the write data for rollback matches the ECU itself (S6105). When it is determined that the write data for rollback matches the ECU itself, the write process is performed on the ECU (ID 1).

The CGW13 obtains a split file of a predetermined size (for example, 1 kbyte) in the write data for rollback to the ECU (ID1) from the DCM12, and distributes the split file to the ECU (ID1) (S6016). The ECU (ID1) writes the split file received from the CGW13 to the flash memory 33d (S6107). When the writing is completed, the ECU (ID1) stores a retry point indicating where the flash address is written so that the writing can be restarted from the middle (S6108). When the retry point is stored, the ECU (ID1) notifies the CGW13 of the completion of writing (S6109).

Upon receiving the notification of the completion of writing from the ECU (ID1), the CGW13 notifies the center apparatus 3 of progress information of the rewriting status via the DCM12 (S6110). The center apparatus 3 updates the web page screen connectable from the mobile terminal 6 based on the progress information transmitted from the DCM12 (S6111). The mobile terminal 6 connects to the center apparatus 3, and displays, for example, that the rollback is currently progressing to several%, as an updated progress status (S6112). Here, instead of the portable terminal 6, the progress may be displayed on the in-vehicle display 7. Upon receiving the notification of the completion of writing from the ECU (ID1), the CGW13 notifies the in-vehicle display 7 of progress information of the rewriting status (S6113). The in-vehicle display 7 updates and displays the screen of the progress status of the rollback (S6114). Upon receiving the notification of completion of writing from the ECU (ID1), the CGW13 acquires the second divided file as the next write data and distributes the second divided file to the ECU (ID 1). Thereafter, the processes of S6106 to S6114 are repeated until the nth divided file as the last write data.

When the writing is completed up to the nth divided file, the ECU (ID1) verifies the integrity of the rollback program of the flash memory and confirms whether the writing is correct (S6115). Upon receiving the notification from the ECU (ID1) that the writing of all the divided files and the integrity verification have been completed, the CGW13 ends the monitoring of the remaining battery level and the monitoring of the communication load on the bus (S6116, S6117).

Next, CGW13 requests wake-up to ECU (ID2) and ECU (ID3) (S6201). In order to start up with the old version before installation, the CGW13 requests the ECU (ID1), the ECU (ID2), and the ECU (ID3) to activate rollback (S6202). The ECU (ID1) which is a single-sided individual memory starts the program of the old version by restarting, as in the case of normal rewriting. Unlike the normal rewriting, the ECUs (ID2) and ECU (ID3) serving as the dual-sided memory start the program on the current operating side, i.e., the a-side, without switching the operating side.

Upon receiving the request for activation for rollback from the CGW13, the ECU (ID1) restarts itself (S6203). When the restart is completed, the ECU (ID1) notifies the CGW13 of the program version in the same direction as the activation completion for rollback (S6204).

When receiving the rollback activation request from the CGW13, the ECU (ID2) restarts itself without updating the stored operation surface information (S6205). When the ECU (ID2) starts up normally on the continuous operation plane, i.e., the a plane, the ECU notifies the CGW13 of the program version and the operation plane information together with the completion of activation for rollback (S6206).

When receiving the rollback activation request from the CGW13, the ECU (ID3) restarts itself without updating the stored operation surface information (S6207). If the ECU (ID3) starts up normally on the continuous operation plane, i.e., the a plane, the ECU notifies the CGW13 of the program version and the operation plane information together with the completion of activation for rollback (S6208).

Upon receiving the rollback activation completion notification from the ECU (ID1), the ECU (ID2), and the ECU (ID3), the CGW13 notifies the center apparatus 3 of the completion of rollback via the DCM12 (S6209). Here, CGW13 also notifies the program version and operation face information about the ECU (ID1), the ECU (ID2), and the ECU (ID3) together. The center device 3 registers the information notified from the DCM12 in the database (S6210), and updates the web page screen to the display indicating the cancellation completion as the progress status (S6211). The mobile terminal 6 is connected to the center device 3, and displays a web page screen of the content whose cancellation is completed (S6212).

When receiving the activation completion notification for rollback from the ECU (ID1), the ECU (ID2), and the ECU (ID3), the CGW13 notifies the in-vehicle display 7 that rollback is completed as the progress status (S6213). The in-vehicle display 7 displays that the rollback is completed (S6214).

Finally, the CGW13 requests the IG electric power source disconnection to the electric power source management ECU20 (S6215). The electric power source management ECU20 requests the electric power source control circuit 43 to cut off the supply of electric power to return to the state where the IG switch was off before the start of installation. When the electric power supply to the IG power line 39 and the ACC power line 38 is cut off by the electric power supply control circuit 43, the ECU (ID1), the ECU (ID2), the ECU (ID4), the ECU (ID5), and the ECU (ID6) are in a stopped state.

As described above, the programs of the plurality of rewrite target ECUs 19 can be updated using CGW13 as a reprogramming master. In the present embodiment, the application is rewritten with the ECU (ID1), the ECU (ID2), and the ECU (ID3) as one group, but the same is true when the application is rewritten with the ECU (ID4), the ECU (ID5), and the ECU (ID6) as the second group. In this case, after the first group of ECUs 19 are installed and activated, the second group of ECUs 19 are installed and activated.

Similarly, the applications such as the DCM12, the CGW13, the in-vehicle display device 7, and the power management ECU20 can be rewritten. However, these ECUs are preferably configured with a dual-sided memory because they require an application program to be able to operate during program update.

Next, the structure of the center device 3 will be described with reference to fig. 258 to 294. The first to fifth embodiments will be described.

(first embodiment)

The first embodiment will be described below with reference to fig. 258 to 277. The vehicle program rewriting system is a system capable of rewriting, by OTA, application programs such as vehicle control and diagnosis of an ECU mounted in a vehicle. As shown in fig. 258, the vehicle program rewriting system 1 includes a center device 3 on the communication network 2 side, a vehicle-side system 4 on the vehicle side, and a display terminal 5. The communication network 2 includes, for example, a mobile communication network based on a 4G line or the like, the internet, wifi (wireless fidelity) (registered trademark), and the like.

The display terminal 5 is a terminal having a function of receiving an operation input from a user and a function of displaying various screens, and is, for example, a mobile terminal 6 such as a smartphone or a tablet that can be carried by the user, a display equipped with a navigation function in a vehicle, an in-vehicle display 7 such as a meter display, and the like. The mobile terminal 6 can be connected to the communication network 2 if it is within the communication range of the mobile communication network. The in-vehicle display 7 is connected to the vehicle-side system 4.

When the user is outside the vehicle and within the communication range of the mobile communication network, the user can perform operation input while checking various screens related to rewriting of the application program at the mobile terminal 6, thereby realizing the procedure related to rewriting of the application program. The user can perform operation input while checking various screens related to rewriting of the application program on the in-vehicle display 7 in the vehicle interior, and thereby realize procedures related to rewriting of the application program. That is, the user can use the mobile terminal 6 and the in-vehicle display 7 separately outside and inside the vehicle compartment, and realize the procedure for rewriting the application program.

The center device 3 incorporates the function of the OTA on the communication network 2 side in the vehicle program rewriting system 1, and functions as an OTA center. The center device 3 includes a file server 8, a web server 9, and a management server 10, and the servers 8 to 10 are configured to be capable of data communication with each other.

The file server 8 is a server that has a function of managing application programs transmitted from the center device 3 to the vehicle-side system 4, and manages ECU programs provided by suppliers and the like as providers of the application programs and accompanying information thereof, distribution specification data provided by an oem (original Equipment manager), vehicle states acquired from the vehicle-side system 4, and the like. The file server 8 can perform data communication with the vehicle-side system 4 via the communication network 2, and when a download request of a distribution packet is generated, transmits the distribution packet in which the reconstruction data and the distribution specification data are packaged to the vehicle-side system 4. The web server 9 is a server for managing web information, and provides various screens related to rewriting of an application program to the mobile terminal 6. The management server 10 manages personal information and the like of a user registered to a service for rewriting an application program, and manages a history of rewriting an application program and the like for each vehicle.

The vehicle-side system 4 has a main apparatus 11. The host apparatus 11 has a DCM12 and a CGW13, and the DCM12 and the CGW13 are connected to be capable of data communication via the first bus 14. The DCM12 is a vehicle-mounted communication device that performs data communication with the center apparatus 3 via the communication network 2, and when a distribution packet is downloaded from the file server 8, write data is extracted from the distribution packet and transmitted to the CGW 13.

The CGW13 is a gateway device for a vehicle having a data relay function, and when acquiring write data from the DCM12, distributes the write data to a rewrite target ECU of a rewrite application. The host device 11 incorporates the function of the OTA on the vehicle side in the vehicle program rewriting system 1, and functions as an OTA master. In addition, although fig. 258 illustrates a configuration in which DCM12 and in-vehicle display 7 are connected to the same first bus 14, DCM12 and in-vehicle display 7 may be connected to separate buses.

The second bus 15 is, for example, a bus of a vehicle body system network. The ECU19 connected to the second bus 15 is an ECU that controls the vehicle body system, such as a door ECU that controls locking/unlocking of a door, a meter ECU that controls a meter display, an air conditioner ECU that controls driving of an air conditioner, and a window ECU that controls opening/closing of a window. The third bus 16 is, for example, a bus of a travel system network. The ECU19 connected to the third bus 16 is an ECU that controls the running System, such as an engine ECU that controls driving of the engine, a brake ECU that controls driving of the brake, an ECT (Electronic Toll Collection System) ECU that controls driving of the automatic transmission, and a power steering ECU that controls driving of the power steering.

The fourth bus 17 is for example a bus of a multimedia system network. The ECU19 connected to the fourth bus 17 is an ECU that controls a multimedia system, such as a navigation ECU for controlling a navigation system, and an etc ECU for controlling an electronic toll collection system (ECT system). The buses 15 to 17 may be buses of systems other than the vehicle body system network, the traveling system network, and the multimedia system network. The number of buses and the number of ECUs 19 are not limited to the illustrated configurations.

The power supply management ECU20 is an ECU having a function of performing power supply management of the DCM12, the CGW13, the various ECUs 19, and the like.

The sixth bus 21 is connected to the CGW13 as a bus on the vehicle outer side. A dlc (data Link coupler) connector 22 to which a tool 23 is detachably connected is connected to the sixth bus 21. The vehicle-interior buses 14 to 18 and the vehicle-exterior bus 21 are each constituted by a CAN (Controller Area Network, registered trademark) bus, for example, and the CGW13 performs data communication with the DCM12, the various ECUs 19, and the tool 23 in accordance with the data communication standard and the diagnostic communication standard (UDS: ISO14229) of the CAN. Further, DCM12 and CGW13 may be connected via ethernet, or DLC connector 22 and CGW13 may be connected via ethernet.

When the writing target ECU19 receives the write data from the CGW13, the write data is written to the flash rewriting application. In the above configuration, upon receiving a write data acquisition request from the rewrite target ECU19, the CGW13 functions as a rewrite host that distributes write data to the rewrite target ECU 19. The ECU19 to be rewritten functions as a reprogramming device that writes write data into the flash rewriting application upon receiving the write data from the CGW 13.

The method of rewriting the application program includes a wired rewriting method and a wireless rewriting method. In the wired rewrite application, when the tool 23 is connected to the DLC connector 22, the tool 23 transfers the write data to the CGW 13. The CGW13 relays or distributes the write data transmitted from the tool 23 to the rewrite target ECU 19. In the method of rewriting an application by wireless, as described above, when the DCM12 downloads the distribution packet from the file server 8, the DCM extracts write data from the distribution packet and transfers the write data to the CGW 13.

As shown in fig. 259, the CGW13 includes a microcomputer (hereinafter referred to as a "microcomputer") 24, a data transmission circuit 25, a power supply circuit 26, and a power supply detection circuit 27 as electrical functional blocks. The microcomputer 24 includes a cpu (central Processing unit)24a, a ROM (Read Only Memory)24b, a RAM (Random Access Memory)24c, and a flash Memory 24 d. The microcomputer 24 executes various control programs stored in the non-transitory tangible storage medium to perform various processes, thereby controlling the operation of the CGW 13.

As shown in fig. 260, the ECU19 includes a microcomputer 28, a data transmission circuit 29, a power supply circuit 30, and a power supply detection circuit 31 as electrical function blocks. The microcomputer 28 has a CPU28a, a ROM28b, a RAM28c, and a flash memory 28 d. The microcomputer 28 executes various control programs stored in the non-transitory tangible storage medium to perform various processes, thereby controlling the operation of the ECU 19.

The data transmission circuit 29 controls data communication with the buses 15 to 17 according to the data communication standard of the CAN. The power supply circuit 30 inputs + B power supply, ACC power supply, and IG power supply. The power supply detection circuit 31 detects the voltage value of the + B power supply, the voltage value of the ACC power supply, and the voltage value of the IG power supply input from the power supply circuit 30, compares these detected voltage values with a predetermined voltage threshold, and outputs the comparison result to the microcomputer 28. The microcomputer 28 determines whether the + B power supply, the ACC power supply, and the IG power supply supplied from the outside to the ECU19 are normal or abnormal, based on the comparison result input from the power supply detection circuit 27. The ECU19 has basically the same configuration except for the connected loads such as sensors and actuators. The basic configuration of DCM12, in-vehicle display 7, and power supply management ECU is also the same as ECU19 shown in fig. 260.

As shown in fig. 261, the electric power source management ECU20, CGW13, and ECU19 are connected to the + B power source line 32, ACC power source line 33, and IG power source line 34. The + B power supply line 32 is connected to the positive electrode of the vehicle battery 35. The ACC power supply line 33 is connected to the positive electrode of the vehicle battery 35 via an ACC switch 36. When the user performs the ACC operation, the ACC switch 36 is switched from off to on, and the output voltage of the vehicle battery 35 is applied to the ACC power supply line 33. For example, if the vehicle is of a type in which a key is inserted into an insertion opening, the ACC operation is an operation in which the key is inserted into the insertion opening and turned from the "OFF" position to the "ACC" position, and if the vehicle is of a type in which a start button is pressed, the ACC operation is an operation in which the start button is pressed once.

The IG power supply line 34 is connected to the positive electrode of the vehicle battery 35 via an IG switch 37. When the user performs an IG operation, the IG switch 37 is switched from off to on, and the output voltage of the vehicle battery 35 is applied to the IG power supply line 34. For example, if the vehicle is of a type in which a key is inserted into the insertion opening, the IG operation is an operation of inserting the key into the insertion opening and turning the key from the "OFF" position to the "ON" position, and if the vehicle is of a type in which the start button is pressed, the IG operation is an operation of pressing the start button 2 times. The negative electrode of the vehicle battery 35 is grounded.

When both the ACC switch 36 and the IG switch 37 are turned off, only the + B electric power is supplied to the vehicle-side system 4. The state in which only + B power is supplied to the vehicle-side system 4 is referred to as a + B power state. When the ACC switch 36 is turned on and the IG switch 37 is turned off, the ACC electric power source and the + B electric power source are supplied to the vehicle-side system 4. A state in which the ACC electric power and the + B electric power are supplied to the vehicle-side system 4 is referred to as an ACC electric power state. When both the ACC switch 36 and the IG switch 37 are turned on, the + B electric power source, the ACC electric power source, and the IG electric power source are supplied to the vehicle-side system 4. A state in which the + B electric power source, the ACC electric power source, and the IG electric power source are supplied to the vehicle-side system 4 is referred to as an IG electric power source state.

The ECU19 is classified into a + B system ECU activated in the + B electric power source state, an ACC system ECU activated in the ACC electric power source state, and an IG system ECU activated in the IG electric power source state, depending on the electric power source state. The ECU19 driven for use in, for example, vehicle theft prevention is a + B system ECU. The ECU19 driven for use in a non-driving system such as an audio system is an ACC system ECU. The ECU19 driven for use in a traveling system such as engine control is an IG system ECU.

The CGW13 transmits the activation request to the ECU19 in the sleep state, and thereby the ECU19 to which the activation request is transmitted shifts from the sleep state to the activation state. In addition, CGW13 transmits a sleep request to ECU19 in the active state, and thereby makes ECU19 as a transmission destination of the sleep request shift from the active state to the sleep state. The CGW13 selects the ECU19 to which the start request and the sleep request are transmitted from the plurality of ECUs by, for example, differentiating the waveforms of the transmission signals transmitted to the buses 15 to 17.

The electric power source control circuit 38 is connected in parallel to the ACC switch 36 and the IG switch 37. The CGW13 transmits a power supply control request to the power supply management ECU20, and causes the power supply management ECU20 to control the power supply control circuit 38. That is, the CGW13 transmits the electric power source activation request to the electric power source management ECU20 as the electric power source control request, and connects the ACC power source line 33 and the IG power source line 34 to the positive electrode of the vehicle battery 35 inside the electric power source control circuit 38. In this state, even if the ACC switch 36 and the IG switch 37 are off, the ACC electric power source and the IG electric power source are supplied to the vehicle-side system 4. The CGW13 transmits the electric power source stop request to the electric power source management ECU20 as an electric power source control request to interrupt the ACC power source line 33, the IG power source line 34 and the positive electrode of the vehicle battery 35 inside the electric power source control circuit 38.

The DCM12, the CGW13 and the ECU19 have the function of self-holding the power supply. That is, when the vehicle electric power source is switched from the ACC electric power source or the IG electric power source to the + B electric power source while the DCM12, the CGW13, and the ECU19 are in the on state, the vehicle electric power source does not shift from the on state to the sleep state or the stop state immediately after the switching, and the on state is continued for a predetermined time even after the switching, and the drive electric power source is self-held. The DCM12, CGW13, and ECU19 transition from the on state to the sleep state or the off state after a prescribed time (for example, several seconds) has elapsed after the vehicle electric power source is switched from the ACC electric power source or the IG electric power source to the + B electric power source.

Next, a distribution packet distributed from the center device 3 to the host device 11 will be described with reference to fig. 262 to 263. In the vehicle program rewriting system 1, rewriting data is generated based on written data provided by a supplier of a providing company as an application program and rewriting specification data mainly provided by an OEM. The write data provided by the vendor includes differential data corresponding to a difference between the old application and the new application, and all data corresponding to the entire new application. The differential data and the entire data may be compressed by a known data compression technique. In fig. 262, a case is illustrated in which differential data is supplied as write data from suppliers a to C, and reassembled data is generated from the encrypted differential data and the authenticator of the ECU (ID1) supplied from the supplier a, the encrypted differential data and the authenticator of the ECU (ID2) supplied from the supplier B, the encrypted differential data and the authenticator of the ECU (ID3) supplied from the supplier C, and the rewriting specification data supplied from the OEM. The authenticator is assigned to each write data.

Note that, although fig. 262 shows the difference data when the old application is updated to the new application, the difference data for rollback to be rewritten from the new application to the old application may be included in the rebuilt data. For example, when the rewrite target ECU19 is a single-sided memory, the rewrite data includes rollback difference data.

The overwrite specification data provided from the OEM is the following data: the operations related to rewriting in the DCM12, the CGW13, and the rewrite target ECU19 are defined by including information that can specify the rewrite target ECU19, information that can specify the rewrite order when there are a plurality of rewrite target ECUs 19, information that can specify the rollback method described later, and the like as information related to rewriting of the application program. The rewriting specification data is classified into the rewriting specification data for DCM used in DCM12 and the rewriting specification data for CGW used in CGW 13. The rewriting specification data for DCM describes information necessary for reading a file corresponding to the ECU19 to be rewritten. As described above, the CGW describes information necessary to control rewriting in the ECU19 to be rewritten, with the rewriting specification data.

When the DCM12 acquires the DCM rewriting specification data, it analyzes the DCM rewriting specification data, and controls operations related to rewriting such as transfer of write data to the CGW13 based on the analysis result. When CGW13 acquires the rewriting specification data for CGW, it analyzes the rewriting specification data for CGW, and controls operations related to rewriting such as acquisition of write data from DCM12 and distribution of write data to ECU19 to be rewritten, based on the analysis result.

The file server 8 has the above-described rebuilt data registered therein, and has distribution specification data provided from the OEM registered therein. The distribution specification data supplied from the OEM is data defining operations related to the display of various screens in the display terminal 5.

When the rebuilt data and the distribution specification data are registered, the file server 8 encrypts the rebuilt data to generate a distribution packet in which a packet authentication character for authenticating the packet, the encrypted rebuilt data, and the distribution specification data are packaged into one file. When receiving a download request of the distribution packet from the outside, the file server 8 transmits the distribution packet to the DCM 12. In addition, although fig. 262 illustrates a case where the file server 8 generates a distribution package in which the reprogramming data and the distribution specification data are stored, and transmits the reprogramming data and the distribution specification data to the DCM12 at the same time, the reprogramming data and the distribution specification data may be transmitted to the DCM12 separately. That is, the file server 8 may first transmit the distribution specification data to the DCM12 and then transmit the reassembled data to the DCM 12. The file server 8 transmits the distribution packet and the packet identifier to the DCM12, with the reprogramming data and the distribution specification data as one file, i.e., the distribution packet.

The DCM12 verifies the packet identifier and the encrypted dubbing data stored in the distribution packet when the distribution packet is downloaded from the file server 8, and decrypts the encrypted dubbing data when the verification result is positive. When the DCM12 decrypts the encrypted reprogramming data, it unpacks the reprogramming data obtained by decryption, and generates encrypted differential data and an authentication code for each ECU, rewriting specification data for DCM, and rewriting specification data for CGW. Fig. 263 illustrates a case where the encrypted differential data and the authenticator of the ECU (ID1) are generated, the encrypted differential data and the authenticator of the ECU (ID2), the encrypted differential data and the authenticator of the ECU (ID3), and the rewriting specification data.

Fig. 264 is a block diagram showing the main functions of the servers 8 to 10 in the center device 3. Fig. 265 shows an outline of processing performed by the center device 3 for program update of the ECU. Hereinafter, the "database" may be referred to as "DB". As shown in fig. 264, the center device 3 includes a packet management unit 3A, a configuration information management unit 3B, an individual vehicle information management unit 3C, and an activity management unit 3D. The packet management unit 3A includes a specification data generation unit 201, a packet generation unit 202, and a packet distribution unit 203, and an ECU reprogramming data DB204, an ECU metadata DB205, and a packet DB 206. The configuration information management unit 3B includes a configuration information registration unit 207 and a configuration information DB 208.

The supplier registers data of each ECU using an input unit 218 and a display unit 219 that are User Interface (UI) functions of the management server 10. The data of each ECU includes a new program, a program file such as differential data, program file related information such as authentication data, size, and encryption method of the program file, and data related to ECU attribute information such as a memory structure of the ECU 19. The program file is stored in the ECU reprogramming data DB 204. The ECU attribute information is stored in the ECU metadata DB 205. The program file-related information may be stored in the ECU reprogramming data DB204 or the ECU metadata DB 205. The ECU reprogramming data DB204 is an example of an update data storage section. In addition, the ECU metadata DB205 is an example of the device-related information storage unit.

The OEM registers the regular configuration information to the configuration information DB208 by vehicle model via the configuration information registration section 207. The regular configuration information is configuration information of a vehicle approved by a public institution. The configuration is identification information relating to hardware and software of ECU19 mounted on the vehicle, and is an example of vehicle-related information. The configuration information also includes identification information of a system constituted by a plurality of ECUs 19 and identification information of a vehicle constituted by a plurality of systems. Further, as the configuration information, restriction information of the vehicle related to update of the program may be registered. For example, group information, a bus load table, information on a battery load, and the like, which are described in the ECU whose specification data is rewritten, may be registered. The ECU metadata DB205 is an example of the device-related information storage unit. The configuration information DB208 is an example of a vehicle information storage unit.

The specification data generation unit 201 generates rewriting specification data by referring to each DB. The packet generation unit 202 generates a distribution packet including rewriting specification data and reprogramming data, and registers the distribution packet in the packet DB 206. The packet generation unit 202 may include distribution specification data to generate a distribution packet. The packet distribution section 203 distributes the registered distribution packet to the vehicle-side system 4. The distribution package corresponds to a file.

The individual vehicle information management unit 3C includes an individual vehicle information registration unit 209, a configuration information confirmation unit 210, an update presence/absence confirmation unit 211, an SMS transmission control unit 212, and an individual vehicle information DB 213. The individual vehicle information registration unit 209 registers the individual vehicle information uploaded by each vehicle to the individual vehicle information DB 213. The individual vehicle information registration unit 209 may also register the individual vehicle information at the time of vehicle production or sale as an initial value to the individual vehicle information DB 213. The configuration information confirming unit 210 compares the individual vehicle information with the configuration information of the vehicle of the same model registered in the configuration information DB208 when registering the uploaded individual vehicle information. The update presence/absence confirmation unit 211 confirms the presence/absence of update of the individual vehicle information by the new program, that is, the presence/absence of activity. When the individual vehicle information is updated, the SMS transmission control unit 212 transmits a Message related to the update to the corresponding vehicle by SMS (Short Message Service).

The activity management unit 3D includes an activity generation unit 214, an activity distribution unit 215, an instruction notification unit 216, and an activity DB 217. The OEM generates activity information, which is information related to program update, by the activity generation section 214, and registers the information in the activity DB 217. Note that the event information here corresponds to the "distribution specification data" described above, and is mainly information related to the update content displayed on the vehicle-side system 4. The activity distribution section 215 distributes the activity information to the vehicle. The instruction notifying unit 216 notifies the vehicle of a necessary instruction related to the program update. In the vehicle-side system 4, for example, the user determines whether or not to download the update program based on the event information transmitted from the center apparatus 3, and downloads the update program if necessary. Note that the portions of the management units 3A to 3D other than the databases are functions realized by hardware and software of a computer. The vehicle communication unit 222 is a functional module for performing data communication between the center device 3 and the vehicle-side system 4 mutually by wireless.

The above-described processing will be described in more detail below, and first, the contents of data registered in each database will be described. As shown in fig. 266, the following data is registered in the configuration information DB208 as an example. The "vehicle model" indicates the vehicle type. "Vehicle SW ID" is a software ID for the entire Vehicle, and corresponds to a Vehicle software ID. The "Vehicle SW ID" is assigned to only one Vehicle, and is updated as the version of the application of any one or more ECUs is updated. When a group of the plurality of ECUs 19 mounted on each vehicle is set as "system," Sys ID "is the ID of the system.

For example, in fig. 258, the group of vehicle body system ECUs 19 are vehicle body system systems, and the group of travel system ECUs 19 are travel systems. The "Sys ID" is updated as the version of the application program of any one or more ECUs constituting the system is updated. The "ECU ID" is an ID for device identification indicating the type of each ECU. The "ECU SW ID" is a software ID for each ECU, and corresponds to the ECU software ID. Here, for convenience, the information is represented by information in which the "ECU ID" is denoted by the version of software. The "ECU SW ID" is updated as the version of the application of the ECU is updated. In addition, even if the same "ECU ID" and the same program version are used, different "ECU SW ID" is used when the hardware configuration is different. That is, "ECU SW ID" is information indicating the product number of the ECU.

In fig. 266, the structural information about the vehicle of which "vehicle model" is "aaa" is shown. The ECU19 mounted on the vehicle includes an automatic drive ECU (ads), an engine ECU (eng), a brake ECU (brk), and an electric power steering ECU (eps). For example, the "ECU SW ID" for "Vehicle SW ID" 0001 "is" ads _001 "," eng _010 "," brk _001 "," eps _010 ", and" ECU SW ID "for" Vehicle SW ID "0002" is "ads _ 002", "eng _ 010", "brk _ 005", and "eps _ 011", and 3 software versions are updated. Accordingly, "Sys ID" is updated to "SA 02" from "SA 01", and "Sys ID" is updated to "SA 03" from "SA 02". In this way, the configuration information DB208 has an initial value registered at the time of production or sale of the vehicle, and is updated as the version of the application program of any one or more ECUs is updated. That is, the configuration information DB208 indicates the configuration information of each vehicle model and the configuration information that is present in the market in a regular manner.

As shown in fig. 267, the following programs and data are registered in the ECU reprogramming data DB204 as an example. In fig. 267, an automatic drive ECU (ads), a brake ECU (brk), and an electric power steering ECU (eps) are exemplified as an ECU19 in which an application installed in an ECU19 of a certain vehicle model is updated. The latest "ECU SW ID" of the update target ECU19 includes an old program and a new program file of the ECU, integrity verification data of the new program, an update data file which is difference data between the new program and the old program, integrity verification data of the update data, a rollback data file which is similarly difference data, integrity verification data of the rollback data, and the like. The integrity verification data is a hash value resulting from applying a hash function to the data value. Further, when the update data is regarded as all data of the new program in place of the differential data, the integrity verification data of the update data is equal to the data of the new program.

Note that, although fig. 267 shows the data structure of the latest "ECU SW ID", when the data of the old "ECU SW ID" is stored, the old program file may be a new program file that refers to one old "ECU SW ID". Each integrity verification data may be in a form of registering a value calculated by a supplier, or in a form of calculating and registering by the center apparatus 3.

As shown in fig. 268, as an example, specification data of each ECU shown below is registered in the ECU metadata DB 205. The latest "ECU SW ID" is the area information, the transfer size, the address for reading the program file, and the like of the program for which the area is the a-side, the B-side, or the C-side in the case where the size of the update data file and the size of the rollback data file are the same, and the flash memory 28d included in the ECU19 has a configuration of 2 or more. These are one example of updating data-related information.

Attribute information indicating the attribute of the ECU19 is also registered in the ECU metadata DB 205. The attribute information indicates hardware attributes and software attributes related to the ECU. The "transfer size" is a transfer size when rewriting data is transferred from CGW13 to ECU19 in a divided manner, and the "key" is a key used when CGW13 securely accesses ECU 19. These are one example of software attribute information. The "vehicle model" and the "ECU ID" also include the memory configuration of the flash memory 28d included in the ECU19, the type of bus to which the ECU19 is connected, the type of power supply connected to the ECU19, and the like. These are one example of hardware attribute information.

Here, the memory configuration "single-sided" is a single-sided single-mode memory having a flash memory side on the 1 side, "double-sided" is a double-sided memory having a flash memory side on the 2 side, and "suspend" is a single-sided suspend-mode memory having a flash memory side on the dummy 2 side. The hardware attribute information and the software attribute information are information used for rewriting control of each ECU19 in the vehicle-side system 4. The hardware attribute information may be stored in advance in the CGW13, and in the present embodiment, the hardware attribute information is managed by the center device 3 in order to reduce the management load on the vehicle-side system 4. The software attribute information is data directly specifying the rewrite operation of each ECU 19. Managed by the center apparatus 3 so as to enable flexible control in the vehicle-side system 4.

As shown in fig. 269, data of each individual vehicle shown below is registered in the individual vehicle information DB213 as an example. The configuration information of each individual vehicle, the state information of the individual vehicle updated for the program are mainly registered. Specifically, the "VIN" is the ID of each Vehicle, "Vehicle SW ID", "Sys ID", "ECU SW ID", and the like are configuration information. The "Digest" value, which is the hash value of the configuration information, is also calculated and stored by the center apparatus 3. When the memory configuration is double-sided, the "operating surface" is a surface to which a program currently operated by the ECU19 is written, and a value uploaded together with the configuration information is registered.

The "access log" is the date, year, and time when the vehicle uploaded the individual vehicle information to the center apparatus 3. The "reprogramming state" indicates a reprogramming state in the vehicle, and includes, for example, "completion of issuance of an event", "completion of activation", "completion of download", and the like. In other words, it is known from the state of progress to which phase reprogramming in the vehicle has proceeded and at which phase the reprogramming has stagnated. When the vehicle-side system 4 uploads configuration information or the like to the center device 3, the "VIN" of each vehicle is given to the information or the like.

As shown in fig. 270, the packet DB206 registers the ID of the distribution packet, the distribution packet file, and data for integrity verification of the distribution packet. As shown in fig. 271, the following data is registered in the activity DB 217. The ID of the event information, the distribution packet ID, message information such as text indicating the specific update content as the event content, a list of "VIN" as the ID of the Vehicle to be subjected to the event, a list of "Vehicle SW ID" before and after the update, a list of "ECU SW ID" before and after the update, and the like. The "object VIN" list can be collated and registered with the individual vehicle information DB213 and the activity DB 217. In addition, these pieces of activity information may be registered together in the packet DB 206.

Next, the operation of the present embodiment will be explained. In fig. 272, a registration process for the ECU reprogramming data DB204 in the packet management unit 3A will be described. As shown in fig. 272, the display unit 219 and the input unit 218 activate a screen for registering reprogramming data of the management server 10, and receive an input of a new and old program file from the ECU19 from a supplier worker (a 1). For example, a UI or the like may be used that registers a file marked with structure information in the CSV format or the like as a file. Next, the package manager 3A generates integrity verification data of the new program (a2), and generates difference data files when the old program is updated to the new program as a base and integrity verification data of the difference data for updating as difference data for updating (A3, a 4).

Next, the differential data file when the new program is updated to the old program as a base and the integrity verification data of the data are generated as differential data for rollback (a5, a 6). These program files and the verification data are registered to the ECU reprogramming data DB204, and a new "ECU SW ID" is generated based on one old "ECU SW ID" and registered (a 7). Here, when all the data is distributed without distributing the difference, the procedure related to the difference data can be omitted.

The integrity verification data is, for example, a hash value generated by applying a hash function. For example, using SHA-256 (Secure Hash Algorithm 256-bit) as the Hash function, the data values are divided into message blocks by 64 bytes. Then, when the data value of the first message block is applied to the initial hash value to obtain a hash value of 32 bytes in length, the data value of the next message block is applied to the hash value to obtain a hash value of 32 bytes in length in the same manner.

In fig. 273, a description is given of a generation process of rewriting specification data in the specification data generation unit 201. Here, the generation process of the rewriting specification data for the vehicle having the "vehicle model" as "aaa" will be described, and the same applies to other vehicles.

The center device 3 starts a specification data generation program of the specification data generation unit 201, and receives an input from an OEM operator via the display unit 219 and the input unit 218. First, the specification data generation unit 201 determines the ECU19 to be updated. As shown in fig. 273, the specification data generating unit 201 accesses the ECU reprogramming data DB204, and outputs a display screen capable of selecting the "ECU SW ID" to be updated among the registered "ECU SW IDs" to the display unit 219. The specification data generation unit 201 holds 1 or more "ECU SW IDs" selected by the OEM worker via the input unit 218 in a specific ECU order (B1). Here, the ECU sequence indicates a rewriting sequence of the ECU19 in the vehicle-side system 4. The specification data generation unit 201 sets the order designated by the OEM worker as a specific ECU order.

The specification data generation unit 201 may receive an input from an OEM operator without accessing the configuration information DB208, and determine the ECU19 to be updated. The specification data generation unit 201 extracts the ECU19 that has been updated by referring to the "ECU SW ID" for the latest "Vehicle SW ID" and the "ECU SW ID" for one of the old "Vehicle SW IDs". For example, in fig. 266, "ADS", "BRK", and "EPS" are update target ECU 19. The specification data generation unit 201 sets the order of registration to the configuration information DB208 as a specific ECU order.

Then, the specification data generation unit 201 generates ECU group information including a plurality of "ECU SW IDs" to be updated (B2). Here, referring to the configuration information DB208, the "Sys ID" is used, and for example, group 1 is constituted by the "ECU ID" whose Sys ID is "SA 01_ 02", and group 2 is constituted by the "ECU ID" whose Sys ID is "SA 02_ 02". For example, in fig. 266, group 1 is "ADS", group 2 is "BRK" as the first, and "EPS" as the second. In this way, the specification data generating unit 201 determines the ECU to be updated, the group to which the ECU belongs, and the order of the ECUs in the group.

Next, the specification data generator 201 accesses the ECU metadata DB205 to acquire the update data-related information, the hardware attribute information, and the software attribute information as specification data on the ECU19 to be updated (B3). For example, as shown in fig. 274, the update data-related information includes "update program version", "update program acquisition address", "update program size", "rollback program version", "rollback program acquisition address", "rollback program size", "write data type", and "write surface". The hardware attribute information is "connection bus", "connection power supply", and "memory type". The software attribute information is 'rewrite surface information', 'secure access key information', 'rewrite method' and 'transmission size'. The "rewriting method" is data indicating whether rewriting is performed by activating the power supply self-holding circuit when switching from IG on to IG off (power supply self-holding) or rewriting is performed by switching from IG on and IG off (power supply control). The "security access key information" may include information other than a key.

Hereinafter, each information will be explained.

"write data type" indicates whether the program is differential data or full data type. The write data type for the update program and the write data type for the rollback program may be described separately.

"write side" is information indicating which side of the program the ECU19 for the dual-sided memory writes.

"connection bus" is information identifying the bus to which the ECU19 is connected.

"connected power supply" is information indicating the state of the power supply to which the ECU19 is connected, and describes values indicating any of the battery power supply (+ B power supply), the accessory power supply (ACC power supply), and the ignition power supply (IG power supply).

"memory type" is information for identifying the memory configuration of the ECU19, and describes values indicating a double-sided memory, a single-sided suspend memory (pseudo double-sided memory), a single-sided memory, and the like.

"rewritten surface information" is information indicating which surface of the ECU19 is the starting surface (operating surface) and which surface is the rewritten surface (non-operating surface).

"secure access key information" is information for performing access authentication to the ECU19 using a key, and includes information of a key derivation key, a key pattern, and a decryption operation pattern.

"transfer size" is a data size when the transfer program is divided to the ECU 19.

For example, as shown in fig. 274, these pieces of information are held as the above-described specific ECU sequence with "ECU ID" as a key. When the specification data generating unit 201 acquires information for all ECUs (B4; yes), the "rewriting environment information" is designated for the vehicle to be updated (B5). The "rewriting environment information" is information used for rewriting control in the vehicle-side system 4 that targets the group of ECUs or the entire vehicle, and is data that directly specifies a rewriting operation. For example, the rewriting environment information regarding the entire vehicle is "vehicle state" indicating whether the program in the vehicle-side system 4 is updated while the vehicle is traveling (while the IG switch is on) or while the vehicle is parked (while the IG switch is off), "battery load (remaining battery level)" indicating the limit of the remaining battery level at which the program update can be executed in the vehicle-side system 4, and bus load table information indicating the limit of the bus load at which the write data can be transmitted in the vehicle-side system 4.

The rewriting environment information for a group includes the ECU19 belonging to the group, the order of the ECUs in the group, and the like. In the vehicle-side system 4, control is performed such that program updates are synchronized on a group-by-group basis, and writing to the ECU19 is performed in the designated ECU order. The specification data generation unit 201 starts a screen for rewriting the environmental information registration, and receives an input from an OEM worker. Alternatively, the format may be an Excel (registered trademark) into which rewriting environment information is input. Alternatively, the restriction information registered in the configuration information DB208 may be extracted. The specification data generation unit 201 uses the generation result of step B2 as rewriting environment information for the group.

The bus load table is a table showing a correspondence relationship between a power supply state and a bus transfer allowance. As shown in fig. 275, the transfer allowance is the sum of the transfer amounts of the vehicle control data and the written data that can be transferred with respect to the maximum transfer allowance. In this example, since the allowable transfer amount of the first bus is "80%" with respect to the maximum allowable transfer amount, CGW13 allows "50%" with respect to the maximum allowable transfer amount to be the allowable transfer amount of the vehicle control data and "30%" with respect to the maximum allowable transfer amount to be the allowable transfer amount of the write data in the IG power source state. In the ACC power state, CGW13 allows "30% of the maximum allowable amount of transmission as the allowable amount of transmission of the vehicle control data, and" 50% of the maximum allowable amount of transmission as the allowable amount of transmission of the write data. In addition, CGW13 allows "20% of the maximum allowable amount of transmission as the allowable amount of transmission of the vehicle control data and" 60% of the maximum allowable amount of transmission as the allowable amount of transmission of the write data in the + B power supply state. The second bus and the third bus are also the same.

Finally, the specification data generation unit 201 arranges the generated or acquired data in accordance with a predetermined data structure determined in advance, and generates the rewriting specification data as shown in fig. 274 (B6). That is, the specification data generation unit 201 generates rewriting specification data in a data structure that can be interpreted by the vehicle-side system 4. Further, for each ECU information, the rewriting specification data may be written in the order of the group from the small to the large and in the order of the ECUs within the group. For example, in fig. 266, when group 1 is "ADS", the first of group 2 is "BRK", and the second is "EPS", the ECU information of "ADS" is arranged first, the ECU information of "BRK" is arranged next, and the ECU information of "EPS" is arranged last in the ECU information column of the specification data.

In the specification data shown in fig. 274, "ECU ID" to "transmission size" of the ECU information are examples of the target device-related information including the type of the target ECU19, and correspond to the above-described hardware attribute information and software attribute information. The "update program version" to the "write side" are examples of the update data-related information. The "rewriting environment" for the group of ECUs or the entire vehicle is an example of update process information for specifying an update process in the vehicle.

In fig. 276, a packet generation process in the packet generation section 202 will be described. As described above, the packet generation processing for a vehicle having "aaa" as the vehicle model is explained here. As shown in fig. 276, the center device 3 activates the packet generation unit 202 of the packet management unit 3A when an instruction from a worker is received. The packet generator 202 determines the "ECU SW ID" to be updated in the same manner as in step B1 (C1). The packet generation unit 202 acquires each data corresponding to the "ECU SW ID" to be updated from the ECU re-encoding data DB204 and generates one piece of re-encoding data (C2). For example, in fig. 267, the packet generation unit 201 acquires integrity verification data of a new program, update data as difference data, integrity verification data of update data, integrity verification data of an old program, rollback data as difference data, and integrity verification data of rollback data, and generates rebuilt data. Then, the generated rebuilt data and the corresponding rewrite specification data described in steps B1 to B6 are merged to generate one distribution package file (C3). Next, integrity verification data of the generated package file is generated (C4), and registered with the package file in the package DB206 (C5).

Fig. 277 graphically shows the contents of the packet file generated as described above. The image showing a distribution packet file is generated by combining update data and integrity verification data corresponding to "ADS", "BRK", and "EPS" to be updated into one piece of rebuilt data in the ECU order, and further combining the rebuilt data with rewriting specification data. Here, the rollback data may be included in the rebuilt data only when the memory configuration of the ECU19 to be updated is single-sided. When the memory structure is double-sided or suspended, since rewriting of the operating surface is not performed, the rollback data as the old program can be omitted.

As described above, according to the present embodiment, the ECU reprogramming data DB204 of the center device 3 stores data of the update program of the ECU19 to be the target of updating the application program among the plurality of ECUs 19 mounted in the vehicle. In configuration information DB208, vehicle-related information such as "ECU ID" for each of a plurality of ECUs 19 mounted on the vehicle and "ECU SW ID" of an application stored in ECU19 is stored together with the type of the vehicle. The ECU metadata DB205 stores attributes of the rewrite target ECU19 and update data-related information related to the update data.

The specification data generator 201 generates specification data to be transmitted to the vehicle together with the update data written in the subject ECU19, based on the information stored in the configuration information DB208 and the ECU metadata DB205, so as to include the type, attribute, update data-related information, and information indicating the rewriting environment related to the data update of the subject ECU 19. The packet generation unit 202 generates a distribution packet including the specification data and the reprogramming data, and registers the distribution packet in the packet DB 206. Further, the packet distribution section 203 distributes the registered distribution packet to the vehicle-side system 4. Thus, the vehicle-side system 4 can receive the specification data transmitted together with the update data, appropriately select the target ECU19 based on the specification data, and appropriately control the write processing using the update data.

Further, since the specification data generating unit 201 generates the specification data for the plurality of ECUs 19 as one file, and the package generating unit 202 packages the specification data and the reprogramming data for the plurality of ECUs 19 as one file, the vehicle-side system 4 can write the update data into the plurality of ECUs 19 upon receiving one distribution package.

Since the vehicle-related information as the specification data includes group information in which some of the plurality of ECUs 19 are grouped, the vehicle-side system 4 can select the target ECU19 in accordance with the order specified by the group information and write the update data. For example, when there are many ECUs 19 to be improved in some function, the group 1 is set as the vehicle body system ECU19, the group 2 is set as the traveling system ECU19, and the group 3 is set as the MM system ECU19, so that the program update in the vehicle-side system 4 can be executed 3 times. Therefore, the waiting time of the user can be shortened in each case, as compared with the case where all ECUs execute program update together.

The rewriting environment information includes "vehicle state (IG on state)" and "battery load" relating to the vehicle and "bus load table" relating to the ECU19, so the vehicle-side system 4 can determine the timing of writing the update data and the like based on these pieces of information. In other words, a service company using the OEM or the center device 3 can apply flexible program updating by specifying the execution restriction conditions for the vehicle as the rewriting environment information.

Further, since the specification data generation unit 201 sequentially generates the specification data from the information on the ECU19 having an earlier rewriting order set in advance, based on the predetermined data structure, the vehicle-side system 4 can write the update data in accordance with the arrangement order of the ECU IDs in the specification data. In other words, the ECUs 19 having the processes of mutual cooperation are grouped into one group, and the ECU order is specified in consideration of the contents of the processes of mutual cooperation, so that in the vehicle-side system 4, even in the case where the update timing to a new program is completely out of synchronization, the program update can be completed without inconvenience. For example, when the new program of the ECU (ID1) has a process of transmitting a predetermined message to the ECU (ID2) and the new program of the ECU (ID2) has a process of causing a timeout error when the predetermined message transmitted from the ECU (ID1) cannot be received, the ECU sequence may be defined such that the ECU (ID1) is updated and then the ECU (ID2) is updated.

(second embodiment)

As shown in fig. 278, the second embodiment relates to "vehicle configuration information synchronization" in which the vehicle-side system 4 first transmits to the center device 3 in fig. 265. When the vehicle-side IG switch 37 is turned on, the CGW13 transmits a "synchronization start request" to the DCM 12. DCM12 accepts the request and returns a "structure information collection request" to CGW 13. Thus, the CGW13 makes a consultation of the program version for each ECU 19. Each ECU19 returns "ECU SW ID" to CGW 13. The ECU19, which has a double-sided or suspended memory structure, also returns surface information indicating which surface of the plurality of surfaces is the operating surface and which surface is the non-operating surface to the CGW 13. Further, each ECU19 may transmit calibration information of an actuator or the like to be controlled, permission information for receiving a program update service, and a fault code generated in the ECU19 to the CGW 13.

Upon completion of receiving the "ECU SW ID" from each ECU19, CGW13 transmits all of these information together with the "VIN" to DCM 12. At this time, "Vehicle SW ID" and "Sys ID" managed by CGW13 may be transmitted to DCM 12. The DCM12 receives this information, and generates a hash value as a digest value by using a hash function, for example, for all the "ECU SW IDs". As described above, when SHA-256 is used as a hash function, data values obtained by successively connecting all values of "ECU SW ID" are divided into message blocks every 64 bytes, a hash value of 32 bytes in length is obtained by applying the data value of the first message block to the initial hash value, and data values of subsequent message blocks are sequentially applied to the hash value, thereby finally obtaining a hash value of 32 bytes in length. Here, the DCM12 may generate one hash value for a value including not only all of the "ECU SW ID" but also the "Vehicle SW ID", "Sys ID", the surface information, and the calibration information.

The DCM12 transmits the digest value of the "ECU SW ID" obtained as described above to the center device 3 together with the "VIN". In addition, DCM12 may also send the fault code and the license information together with the digest value. Hereinafter, the above-described digest value may be referred to as a "digest of configuration information", and all data values of the "ECU SW ID" from which the digest value is derived may be referred to as "all configuration information". The "overall configuration information" may also include "Vehicle SW ID", "Sys ID", plane information, and calibration information.

As will be described later, the center device 3 compares the digest values and updates the individual vehicle information DB 213. The center device 3 that synchronizes the configuration information confirms the presence or absence of the program update, and notifies the vehicle-side system 4 of the event information when the update is present. Then, the vehicle-side system 4 downloads the distribution packet, installs the packet in the target ECU19, and activates a new program. Upon completion of these update processes, CGW13 transmits a "synchronization start request" to DCM12, and thereafter performs the same processes as described above until a synchronization completion notification. After the update of the program, the above-described processing may be performed when the IG switch 37 is turned on.

As shown in fig. 279, when the individual vehicle information management unit 3C of the center device 3 receives the "configuration information digest" by the vehicle-side system 4 (D1), it checks with the "configuration information digest" of the corresponding vehicle registered in the individual vehicle information DB213 at that time, and determines whether or not both of them match (D2). The "individual vehicle information digest" may be a value calculated in advance and registered in the individual vehicle information DB213, or may be a digest value calculated using the configuration information registered in the individual vehicle information DB213 at the time of reception from the vehicle-side system 4. If both are matched (yes), it is determined whether or not the individual vehicle information of the vehicle is suitable for the authorized combination registered in the configuration information DB208 (D6). Since the configuration information DB208 may be updated at a predetermined timing, the determination at step D6 is performed both when both are matched (yes) and when both are not matched (no) at step D2.

Here, as shown in fig. 280, for example, the above-described suitability determination checks whether or not the combination of the "Vehicle SW ID" and the "ECU SW ID" of the configuration information uploaded from the Vehicle-side system 4 is valid. In the list shown in the figure, "ECU SW ID" of "ECU ID: ADS" corresponding to "Vehicle SW ID: 0001" registered in the configuration information DB208, "ECU SW ID" of "ECU ID: BRK" is "ADS _001," ECU SW ID "of" ECU ID: EPS "is" EPS _ 010.

In contrast, the Vehicle C with VIN equal to 300 is similarly "Vehicle SW ID equal to 0001", but the "ECU SW ID" with "ECU ID equal to ADS" is "ADS _ 002", the "ECU SW ID" with "ECU ID equal to BRK" is "BRK _ 003", and these 2 ECUs 19 are different from the configuration information registered in the configuration information DB 208. Therefore, the result of step D6 is "no", in other words, the result is "NG", and the configuration information confirming unit 210 notifies the management device 220 shown in fig. 265, which is a device for managing information of vehicles produced by the vehicle-side system 4, OEMs, and the like, of an abnormality (D12). The notification of the abnormality is performed by the SMS transmission control section 212 using SMS, for example. The SMS transmission control section 212 is an example of a communication section. Even if these 2 ECUs 19 are not the subject ECU to be updated based on the new program, the center device 3 determines that the vehicle is not authorized, and does not perform the processing after step D7.

On the other hand, the Vehicle a with VIN equal to 100 is "Vehicle SW ID equal to 0001", "ECU SW ID equal to ADS" is "ADS _ 001", and "ECU SW ID" equal to BRK "is" BRK _001 ", and all of the pieces of configuration information registered in the configuration information DB208 match. Therefore, the answer in step D6 is yes, in other words, normal, and the answer is OK, and the routine proceeds to step D7. Here, the configuration information confirmation unit 210 may determine whether the combination of the "ECU SW ID" of the vehicle C is normal or not, depending on whether the combination is present in the configuration information DB 208. In addition, in addition to "Vehicle SW ID", a "Sys ID" may be added to the judgment material.

Next, the update presence/absence confirmation unit 211 accesses the campaign DB217 via the campaign management unit 3D, and confirms the presence/absence of an update by the new program (D7). The presence or absence of update is determined by comparing the "Vehicle SW ID" uploaded from the Vehicle-side system 4 with the "pre-update Vehicle SW ID" of the activity DB 217. For example, as shown in fig. 271, the Vehicle a having VIN equal to 100 is "Vehicle SW ID equal to 0001" before update, and therefore, it is determined that there is an update (yes). In this case, the update presence/absence confirmation unit 211 notifies the vehicle-side system 4 of the vehicle a of the corresponding event ID "Cpn _ 001" (D8). The activity information corresponds to update notification information, and the activity DB217 is an example of an update notification information storage unit.

Note that if the active DB217 has the "Sys ID" before and after the update, the presence or absence of the update can be confirmed by the "Sys ID". Instead of the "Vehicle SW ID", the uploaded "ECU SW ID" list and the "ECU SW ID before update list" of the activity DB217 may be compared to determine whether or not the update is performed.

The vehicle-side system 4 acquires the event file corresponding to the notified event ID from the center apparatus 3 as a key (D9). The activity file contains text describing the content of the activity, a limitation when updating the program, and the like. The limitation item is a condition for executing download and installation, for example, a remaining battery level, a free capacity of a RAM required for download of a distribution package, a current position of a vehicle, and the like. The vehicle-side system 4 parses the event file, displays event contents, and the like using the in-vehicle display 7. The user refers to the message displayed on the in-vehicle display 7 according to the content of the event, and determines whether or not to update the application program of the ECU 19. Upon receiving the approval operation from the user via the in-vehicle display 7, the CGW13 notifies the center apparatus 3 of approval update via the DCM 12. Then, the center device 3 transmits the distribution packet file of the packet ID corresponding to the above-described event ID and the integrity verification data to the vehicle-side system 4 (D10).

If the update is not performed in step D7 (no), the vehicle-side system 4 is notified of "no update" (D11). For example, as shown in fig. 280, the Vehicle a with VIN of 200 is "Vehicle SW ID of 0002" after update, and is determined as not updated because it does not match any of the "Vehicle SW ID before update" of the activity DB 217.

On the other hand, if the comparison result of the "summary of configuration information" does not match at step D2 (no), the center device 3 requests the vehicle-side system 4 to transmit "all configuration information" (D3). This transmission corresponds to "notification of entire data transmission request". In response to this, the vehicle-side system 4 transmits "all configuration information", and the center device 3 receives the information (D4). Then, the individual vehicle information management unit 3C of the center device 3 updates the information of the vehicle registered in the individual vehicle information DB213 (D4). Thereafter, the process proceeds to step D6. The individual vehicle information DB213 is an example of a vehicle-side configuration information storage unit. The "synchronization start request" transmitted by CGW13 may be transmitted at a timing when IG switch 37 is turned off.

As described above, according to the second embodiment, when the vehicle-side system 4 receives the configuration information on the configuration of each ECU19 from the plurality of ECUs 19, it generates a hash value based on the data values of the plurality of configuration information and transmits the hash value to the center device 3. The center device 3 has an individual vehicle information DB213, and compares the hash value transmitted from the vehicle-side system 4 with the hash value of the vehicle configuration information stored in the individual vehicle information DB 213. If the two are not matched, the vehicle-side system 4 is requested to transmit "all configuration information". Then, the vehicle-side system 4 receives the transmission, transmits "all configuration information" to the center device 3, and when the center device 3 receives "all configuration information", the configuration information stored in the individual vehicle information DB213 is updated based on the data value.

With this configuration, the vehicle-side system 4 first transmits the hash value of the configuration information to the center device 3, and transmits all the data values of the configuration information to the center device 3 only when the comparison results of the hash values in the center device 3 do not match. This can reduce the size of data transmitted by the vehicle-side system 4, and therefore, even if the vehicle-side system 4 is mounted on a plurality of vehicles, the communication volume can be reduced as a whole. In particular, in the vehicle-side system 4, when the configuration information is uploaded at a predetermined timing such as when the IG is turned on, a time zone in which the communication is concentrated may occur. Therefore, the communication load can be reduced by reducing the amount of transmission data using the hash value.

The CGW13 receives the configuration information from all the ECUs 19 to which the update data is to be rewritten, generates a hash value based on all the data values, and the DCM12 transmits the hash value at the timing when the ignition switch 37 of the vehicle is turned on or off, so that the hash value can be transmitted to the center device 3 at the timing when the traveling of the vehicle is started or ended. Therefore, the center device 3 can appropriately synchronize the configuration information of the individual vehicle information DB213 with the vehicle.

When the Vehicle-side system 4 receives the "ECU SW ID" of each ECU19 from the plurality of ECUs 19, it transmits a configuration information list in which the "Vehicle SW ID" is combined with the information to the center device 3. The center device 3 compares the "ECU SW ID" list transmitted from the vehicle-side system 4 with the authorized "ECU SW ID" list of the corresponding vehicle stored in the configuration information DB208, and if it is determined that the combination of the transmitted lists is not authorized, transmits the abnormality detection to the vehicle-side system 4 and the management device 220.

With this configuration, the center device 3 can detect as an abnormality a state where a plurality of ECUs 19 cannot cooperate with each other to hinder the traveling of the vehicle, and can notify the vehicle-side system 4 of the combination of the vehicle configuration information. This enables the vehicle-side system 4 to respond to prohibition of vehicle travel or the like.

The center device 3 does not perform the process of confirming whether or not the update is performed for the vehicle whose combination of the configuration information of the vehicle is unauthorized (D7). Therefore, it is possible to prevent the program update from being performed in the non-compliant vehicle. Even if the non-compliant ECU19 is not the update subject ECU based on the new program, the center device 3 does not perform the process of confirming the presence or absence of the update (D7). When the program update is executed in the vehicle-side system 4, control is also performed for the ECU19 that is not the object of the update. Therefore, in a vehicle having an irregular ECU19, there is a possibility that the program update cannot be completed normally, so the center device 3 does not execute the program update for the vehicle.

The center device 3 includes a campaign DB217 that stores campaign information used to notify the vehicle side of the occurrence of an update by a new program, and confirms the presence or absence of the campaign information of the corresponding vehicle for a vehicle determined to be legitimate. If there is an update, the activity information is transmitted to the vehicle-side system 4. This can prompt the user with activity information to prompt the application to be updated. When uploading the configuration information of the vehicle, the center device 3 executes synchronization of the configuration information, determination of whether the configuration information is valid, and confirmation of whether or not the update is performed as a series of processes, and can promptly notify the appropriate vehicle of the update of the program.

Further, the second embodiment may be modified as follows.

The transmission of the "synchronization start request" may be performed by the center apparatus 3 to the vehicle-side system 4, or the DCM12 may transmit the "configuration information collection request" to the CGW13 when the "synchronization start request" is received. For example, when the configuration information DB208 of "aaa", which is the vehicle model ", is updated, the center device 3 transmits a" synchronization start request "to the vehicle of the vehicle model.

In addition, the ECU19 to be rewritten of the update data may transmit the hash value to the center apparatus 3 at the timing of completion of rewriting. That is, the flowcharts of steps D1 to D12 shown in fig. 279 are also executed at the timing when the program update of all ECUs 19 to be rewritten is completed.

When the comparison results of the hash values of both sides match, the center device 3 requests the vehicle-side system 4 to transmit a combination list of the configuration information of each ECU 16. Further, when the combination list is received, the processing of steps D6 to D12 may be performed.

The center device 3 may check the presence or absence of the event information of the corresponding vehicle by referring to the event DB217 even when the comparison results of the hash values of both the vehicles match.

As shown in fig. 280, the hash value may be transmitted from the vehicle-side system 4 to the center apparatus 3. Fig. 280 is a flowchart showing the processing of CGW 13. For example, when the IG switch 37 is turned on, the CGW13 collects configuration information from each ECU19 (D21), and generates a hash value for a data value of the collected configuration information (D22). Then, the generated hash value is compared with the hash value stored in the flash memory 24D (the last generated value), and it is determined whether there is a difference (D23). If there is a difference (yes), the hash value generated this time is stored in the flash memory 24D (D24), and the hash value is transmitted to the center device 3. In step D23, if there is no difference in the hash values between the two (no), the process ends. In addition, the flash memory 24d stores in advance a hash value of an initial value of the configuration information. This can reduce the number of times the vehicle-side system 4 uploads the configuration information to the center device 3.

(third embodiment)

The third embodiment relates to a function to be executed by the activity management unit 3D of the center device 3 in order to increase the update rate of the application program in the vehicle-side system 4. As shown in fig. 282, for example, in the vehicle-side system 4, the user sets the interval of HTTP polling to about 3 days by using the Config file, and the vehicle-side system 4 periodically checks whether or not the application is updated with respect to the center device 3. Thus, the center device 3 notifies the vehicle-side system 4 of "update available" at the time when the update confirmation is performed after the event information of the VIN is set for the vehicle corresponding to the event DB 217. That is, as described in the second embodiment, when the vehicle-side system 4 uploads the configuration information using HTTP, the center device 3 performs the update confirmation process at the timing when the IG is turned on after 3 days have elapsed.

If the configuration is such that the presence or absence of the update is triggered by the notification from the vehicle, the center device 3 does not need to transmit the event information from the center device 3 to all vehicles to be subjected to the event at the time when the event information is set. However, when the user does not use the vehicle for a long period of time, the presence or absence of the update using HTTP is not confirmed during the period. Therefore, it is also assumed that the user does not know that a new activity is issued, and a vehicle in which an update of the application is not performed is generated.

Therefore, as shown in fig. 283, the SMS transmission control unit 212 of the center device 3 checks the access log of each vehicle with reference to the individual vehicle information DB213 periodically or at a predetermined timing (E1). Then, it is determined whether or not the vehicle has transmitted the configuration information for which the access to the center device 3, in other words, the update confirmation of the application program, has not been performed for a predetermined period (E2). The predetermined period is, for example, about 7 days from the date when the new event is set in the event DB 217. In other words, the SMS transmission control portion 212 specifies a Vehicle for which update confirmation has not been performed for 7 days, with the Vehicle whose "Vehicle SW ID" of the individual Vehicle information DB213 matches the "Vehicle SW ID before update" of the event DB217 as the target. Note that the SMS transmission control unit 212 may specify a vehicle for which update confirmation has not been performed for a predetermined period of time, with respect to all vehicles.

Further, in the individual vehicle information DB213, initial data is registered by the OEM at the time of production of the vehicle by the factory, and then, an initial access log is entered, for example, by a notification from the OEM that the vehicle is sold along with. This access log substantially corresponds to a notification for validating the update of the following program. The vehicle for which the access log is not input is not the object of the determination in step E2.

If there is a vehicle that has not been updated for a predetermined period (yes), the SMS transmission control unit 212 determines the characteristics of the vehicle from the model number, equipment information, and the like of the individual vehicle information DB213 (E3). As a characteristic here, the SMS transmission control section 212 determines that it is an electric vehicle; EV capable of SMS (short Message service) reception, or an existing gasoline engine vehicle capable of SMS reception, in other words, a regular engine vehicle; a conventional vehicle, or a vehicle that is difficult to receive SMS. For example, the DCM12 mounted on the vehicle determines that the vehicle is a vehicle that has difficulty in receiving the SMS when the DCM does not have a function of receiving the SMS or does not make a contract to receive the SMS.

If EV is the case, an SMS is transmitted to start the ECU19 of the vehicle to start the configuration information transmission sequence (E5, see fig. 284). When the DCM12 receives the SMS and returns the command described in the SMS, the IG is turned on, and the activated CGW13 transmits configuration information to the center apparatus 3 via the DCM 12. Then, as shown in steps D1 to D12 of fig. 279, update confirmation is performed, and download of the distribution package is executed. In the case of EV, since the capacity of the battery is large, it is considered that the program can be downloaded while maintaining the parked state as the IG on-state. Thus, using SMS causes the ECU19 to initiate a sequence after automatically starting the update confirmation and download.

If the remaining battery capacity of the EV is small, the vehicle-side system 4 refers to the rewritten specification data shown in fig. 274, and is controlled not to start the mounting operation if the remaining battery capacity is lower than the specified remaining battery capacity. Alternatively, when the remaining battery level of the active file described as the limitation item in the center device 3 and transmitted in step D9 is lower than the specified remaining battery level, the vehicle-side system 4 is controlled not to start downloading the distribution packet.

In the conventional vehicle, while the DCM12 is intermittently activated, the SMS transmission control unit 212 transmits the SMS that can be displayed on the in-vehicle display 7 to the vehicle that is in the state capable of receiving the SMS (E4, see fig. 284). For example, CGW13 displays a text message described in the received SMS to on-vehicle display 7 at the timing when the next IG is turned on. In addition, when the information of the mobile terminal 6 of the user is registered in the individual vehicle information DB213, the SMS may be transmitted to the mobile terminal 6. For example, let "have activity information. Please turn IG on. "such text message display. The individual vehicle information DB213 is an example of a user information storage unit. On the other hand, the vehicle in a state where it is difficult to receive the SMS is dealt with by mailing or the like to another user without any processing (E6).

As described above, according to the third embodiment, the vehicle-side system 4 transmits the configuration information of the plurality of ECUs 19 to the center device 3, and the configuration information transmitted by each vehicle is stored together with the transmission date in the individual vehicle information DB 213. In addition, the event DB217 stores therein event IDs and a list of object VINs capable of identifying the object vehicles whose data is updated as event information. Then, the center device 3 refers to the individual vehicle configuration DB213, and if there is no transmission of the configuration information within a predetermined period from the transmission date associated with the subject vehicle, transmits a message for prompting the update of the data to the vehicle-side system 4 of the subject vehicle by SMS.

With this configuration, the user does not have a chance to board the vehicle, and therefore, when the predetermined period from the transmission date stored in the individual vehicle information DB213 elapses while the situation where the configuration information is not transmitted to the center device 3 is continued, the center device 3 also transmits a message for prompting the data update to the vehicle-side system 4 of the subject vehicle. Therefore, the user can recognize that data update is required by referring to the message.

Then, the center device 3 determines the target vehicle for program update by referring to the individual vehicle information DB213 and the activity DB 217. That is, the individual vehicle information DB213 stores the date on which the configuration information is transmitted from each vehicle, and the event DB217 stores the list of the object VINs. Therefore, the center device 3 can determine the target vehicle to be updated by the program based on the transmission date of the configuration information from each vehicle and the target VIN list.

When the vehicle-side system 4 receives the respective pieces of configuration information from the respective ECUs 19 when the ignition switch 37 of the vehicle is turned on, the pieces of configuration information are transmitted to the center device 3. Therefore, when the user gets on the vehicle, the configuration information can be reliably transmitted to the center device 3.

When the target vehicle is an electric vehicle, the center device 3 transmits a command for activating the ECU of the target vehicle, including the message, and the vehicle-side system 4 that receives the message activates the ECU19 to execute the processing related to the data update. That is, since the capacity of the battery of the electric vehicle is relatively sufficient, the ECU19 can execute the processing related to the data update without waiting for the user's operation. Therefore, data update can be performed efficiently.

In addition, if the subject vehicle is a conventional vehicle, the center device 3 transmits at least character information that can be displayed on the in-vehicle display 7 of the subject vehicle as a message. Therefore, the user of the conventional vehicle can recognize that data update is required by referring to the character information displayed on the in-vehicle display 7.

When the individual vehicle information DB213 stores the destination of the mobile terminal 6 of the user, the center device 3 transmits the character information that can be displayed on the mobile terminal 6 as a message. Thus, even if the user does not have a chance to board the vehicle, the user can recognize that data update is necessary by referring to the character information displayed on the mobile terminal 6.

Further, when the user transmits the active transmission date and the transmission destination to the center apparatus 3 in advance via the mobile terminal 6, the center apparatus 3 stores the transmission date and the transmission destination in the individual vehicle information DB 213. For example, the user designates the next day of activity issue as a transmission day, and designates the mobile terminal 6 as a transmission destination without designating the in-vehicle display 7. The user designates a predetermined time when the vehicle is not driven as a transmission day, designates the vehicle as a transmission destination, and performs an agreement operation to automatically update the program. As a result, the center apparatus 3 transmits the event information to the transmission destination on the transmission day regardless of the presence or absence of the transmission of the configuration information. Therefore, when it is previously known that there is no chance that the user gets on the vehicle, it can be set that the activity information is received on the transmission day set by the user.

The third embodiment may be modified as described below.

The user information storage unit may be provided separately from the individual vehicle information DB 213.

The transmission of the activity information may use SMS.

Instead of storing the transmission date in the individual vehicle information DB213, the center device 3 may store a date on which transmission from the vehicle side is not performed, and transmit a message prompting data update when 7 consecutive days are present on the date.

(fourth embodiment)

The fourth embodiment shows a case where the user designates a method of notifying activity information or a message. For example, assume a case where the user specifies in advance that the vehicle is not in a car for about 1 month, and the IG switch 37 is not turned on. As shown in fig. 285, the user transmits the setting of the notification destination and the notification date and time at the time of the event generation to the center apparatus 3 via the mobile terminal 6. For example, the mobile terminal 6 is set to notify the activity information after 1 month. Thus, the individual vehicle information management unit 3C stores the information of the notification destination and the notification date and time in the individual vehicle information DB213, and notifies the user of the information according to the setting. For example, if 2 events (1, 2) are set during the 1 month period, the SMS transmission control unit 212 notifies the user's mobile terminal 6 of the event (1, 2) information after 1 month, and prompts the program update.

As described above, according to the fourth embodiment, when the user transmits the transmission date and the transmission destination of the event information to the center device 3 via the mobile terminal 6, the center device 3 stores the transmission date and the transmission destination in the individual vehicle information DB 213. Then, the center apparatus 3 transmits the event information to the transmission destination on the stored transmission day. Thus, when it is confirmed that the user does not board the vehicle for a predetermined period, the transmission of unnecessary activity information from the center apparatus 3 can be stopped.

(fifth embodiment)

The fifth embodiment shows a function of the vehicle-side system 4 to give the verification data used for verifying the integrity of the data when the center device 3 transmits the data of the update program to the vehicle-side system 4. As shown in fig. 286 and 287, the supplier uses the packet manager 3A to create data registered in the ECU reprogramming data DB 204. Specifically, the packet manager 3A creates new difference data for rewriting the old program into the new program as update data (Y1), creates a hash value as integrity verification data for the new program in the ECU19, and creates a hash value for the new difference data (Y2). Here, when the ECU is a one-sided memory, old difference data for rewriting the new program into the old program may be created as rollback data, and the hash value for the old program and the hash value for the old difference data may be created for the ECU 19.

The packet management unit 3A applies an encryption generation authenticator using a key value as a predetermined key to each hash value (Y3). Then, the packet management unit 3A transmits the update data and the integrity verification data with the certifier, and stores the update data and the integrity verification data in the ECU reprogramming data DB204 (Y4). The packet management unit 3A generates a packet as described above, generates integrity verification data for the packet, and transmits the integrity verification data to the vehicle-side system 4 (Y5).

The master device (OTA host) 11 calculates integrity verification data for the packet, compares the calculated value with the integrity verification data of the received packet, and performs integrity verification of the packet (Y6). If the integrity verification of the packet is successful, the host apparatus 11 transmits the update data and the integrity verification data of the ECU to the rewrite target ECU (target ECU)19 (Y7).

The rewrite target ECU19 calculates integrity verification data for the update data, compares the calculated value with the received integrity verification data for the update data, and performs integrity verification of the update data (Y8). If the integrity verification of the update data is successful, the rewrite target ECU19 restores the difference data as the update data and writes the difference data to the flash memory 28d (Y9). When the writing is completed, the rewrite target ECU19 calculates integrity verification data for the data written in the flash memory 28d, compares the calculated value with the received integrity verification data of the new program, and performs integrity verification of the flash memory 28d (Y10). The rewrite target ECU19 transmits the verification result to the host device 11 (Y11), and the host device 11 transmits the received verification result to the center device 3 as the installation result notification (Y12).

For example, as shown in fig. 267, the packet management unit 3A generates the following integrity verification data for the latest "ECU SW ID". When the memory structure of the ECU is a dual-sided memory or a suspend, the following (3) (4) can be omitted.

(1) A hash value is generated as integrity verification data of a new program for the ECU. The functional portion for performing this processing is an example of the first verification value generation unit (step a 1).

(2) Update data as difference data for updating to a new program based on an old program of an ECU and a hash value as integrity verification data of the update data are generated. The functional portion for performing this processing is an example of the second verification value generation unit (step a 4).

(3) A hash value is generated as integrity verification data of an old program for the ECU. The functional portion for performing this processing is an example of the fourth verification value generation unit (step a 5).

(4) Update data as difference data for updating to an old program based on a new program of an ECU and a hash value as integrity verification data of the update data are generated. The functional portion for performing this processing is an example of the fifth verification value generation unit (step a 7).

Further, "program" also includes constant data and the like used in the program. If "ECU SW ID is ads _ 002", the hash value x1 is generated for the update data "Adsfile 001-002". As described above, the hash function uses SHA-256, for example. The hash value corresponds to the verification value. Here, the packet management unit 3A may be configured to apply encryption using a key value as a predetermined key to the hash value to generate an authenticator and generate integrity verification data with the authenticator.

Next, the vendor generates integrity verification data with an authenticator by applying an encryption generation authenticator using a key value as a prescribed key to the integrity verification data, and provides the update data and the integrity verification data with the authenticator to the OEM in a corresponding relationship. In other words, each program and the integrity verification data with an authenticator therefor are provided to the OEM by the packet management section 3A as being registered in the ECU reprogramming data DB 204. By the instruction of the OEM, the packet management unit 3A generates rewriting specification data as described above using the ECU reprogramming data DB204 and the like, generates a distribution packet, and registers the distribution packet in the packet DB 206. When a download request of the update data is generated from the vehicle-side system 4, the center device 3 distributes a distribution packet including the update data and the integrity verification data with the authenticator to the vehicle-side system 4 in accordance with the download request. Further, the "integrity verification data" in the claims includes any one of data including only a hash value and integrity verification data with an authenticator including encryption based on a key.

When the host apparatus 11 of the vehicle-side system 4 receives the distribution packet, the integrity verification data (third verification value) given to the distribution packet is used to verify the validity of the distribution packet. Specifically, the integrity verification data calculated using the distribution packet is compared with the received integrity verification data, and if they match, it is determined to be normal. If the verification result indicates that the data is normal, the host device 11 unpacks the distribution packet into data for each ECU (see fig. 263). Then, the host apparatus 11 transmits the update data and the integrity verification data with the authenticator to the ECU19 of the write destination.

The ECU19 verifies the validity of the update data using the integrity verification data (second verification value) with the authenticator. Specifically, the integrity verification data calculated using the received update data is compared with the received integrity verification data, and if they match, it is determined to be normal. If it is determined as normal as a result of the verification, the CPU28a of the ECU19 performs a write process to the flash memory 28 d. When the write process is completed, the ECU19 reads data written in the flash memory 28d using the integrity verification data (first verification value) with the authenticator, and verifies the validity thereof. Specifically, the integrity verification data calculated using the read data is compared with the received integrity verification data, and if they match, it is determined to be normal. Since the integrity verification data is also used at the time of activation of the ECU19, it is stored in a predetermined area of the flash memory 28 d. If these processes are completed, the ECU19 includes the verification result and transmits a write response to the host apparatus 11. The master device 11 notifies the installation result to the center device 3. In the figure, "target ECU" and "target ECU" have the same meaning, and "OTA host" and "DCM" have the same meaning. The CPU28a is an example of a write processing section.

Here, when cancellation of the program update occurs in the middle of installation, the ECU19 performs the rollback processing. The ECU19 writes the update data and verifies the validity of the rollback differential data using the integrity verification data with the authenticator (fifth verification value). Specifically, the integrity verification data calculated using the rollback difference data is compared with the received integrity verification data, and if they match, it is determined that the data is normal. If it is determined as normal as a result of the verification, the ECU19 starts writing using the rollback differential data after the update data writing is completed. After the completion of the writing, the ECU19 reads the data written in the flash memory 28d using the integrity verification data (fourth verification value) with the authenticator, and verifies the validity thereof. The integrity verification of the received differential data (update data, rollback differential data) may be performed by the host apparatus 11 instead of the ECU 19.

As shown in fig. 288, when the IG switch 37 of the vehicle is turned on, the ECU19 verifies the data at the time of startup. The ECU19 verifies the integrity of the started program or the like using the integrity verification data (the first verification value or the fourth verification value) with the authenticator. First, the flash memory 28d applies a hash function to the data value of the evaluation target area in which the updated program and the constant data are written, and acquires a hash value. Next, the integrity verification data with the authentication code is decrypted, and the hash value (expected value) included in the decryption result is compared with the acquired hash value (calculated value), and it is determined whether or not the program or the like written in the flash memory 28d has been tampered with. If the hash values of both sides match "OK", the ECU19 performs the activation processing as usual. The same process is performed for each ECU19, and if all the evaluation target ECUs 19 result in "OK", the process ends.

On the other hand, if the result of verification by any of ECUs 19 is abnormal and "NG", ECU19 stores a log of processing and notifies host apparatus 11 of an error. The master device 11 similarly saves the log and notifies the center device 3 of an error. The center device 3 similarly stores a log to notify the management device 220 of the OEM or the like of an error. The notification to the management apparatus 220 is performed by, for example, the SMS transmission control unit 212 using SMS, or by transmission of an email via an internet line.

In the above-described embodiment, the integrity of the vehicle-side system 4 is verified. In fig. 289, a case where the center apparatus 3 verifies integrity (compares with an expected value) will be described. In fig. 289, for example, when the version information of the updated application is transmitted to the host apparatus 11 at a timing such as IG on, the ECU19 generates and transmits integrity verification data with an authenticator in the same manner as described above together with the version information (X1). The ECU19 calculates integrity verification data for the data in the flash memory 28d and transmits the calculated value to the host device 11. The master device 11 includes integrity verification data with an authenticator as structural information and transmits to the center device 3 (X2).

The center device 3 accesses the ECU reprogramming data DB204, acquires the integrity verification data with an authenticator (X3, X4) that matches the "ECU SW ID" of the target ECU19, and collates it with the integrity verification data uploaded from the vehicle side (X5). Specifically, integrity verification data of the new program corresponding to the "ECU SW ID" is acquired from the ECU reprogramming data DB and collated. If the result of the collation is NG (X6; NG), an abnormality is notified to the OEM management apparatus 220 (X7). The processing section functions as an abnormality reporting section.

The center device 3 transmits the collation result to the host device 11 (X8), and the host device 11 transmits the received collation result to the rewrite target ECU19 (X9). The rewrite target ECU19 operates the application as usual when the comparison result is OK, and does not operate the application when the comparison result is NG. In the present embodiment, the packet manager 3A can omit the generation of the integrity verification data of the new program (step a1) and the generation of the integrity verification data of the old ECU program (step a 5).

In the above description, the ECU19 verifies the integrity of the update data at the timing when the IG switch 37 of the vehicle is turned on after the update data is written, but instead, the integrity may be verified after the update data is written.

In the above-described embodiment, only the integrity verification data with the authenticator may be given to the update data as follows.

The new program and the corresponding update data are acquired from the ECU reprogramming data DB204 (data acquisition step; step a 1).

The first verification value generation unit generates a first hash value for the new program (first verification value generation step; step a 2).

The second verification value generation unit generates a second hash value for the update data (second verification value generation step; step a 4). The packet generation unit 202 causes the distribution packet to include the update data, the specification data, and the first and second hash values (distribution packet generation step). The update data corresponds to the new difference data.

The third verification value generation unit generates a third hash value for the distribution packet (third verification value generation step; step C4).

The packet distribution unit 203 transmits the distribution packet and the third hash value to the vehicle-side system 4 (transmission step).

The authenticator may be given only to the distribution packet and the third hash value, or may be given at each stage of generating each hash value. The packet distribution unit 203 corresponds to a transmission unit.

In this case, in the vehicle-side system 4,

DCM12 serving as a reception processing unit receives the distribution packet and the third hash value.

The third verification processing unit verifies the integrity of the distribution packet data by comparing the hash value generated based on the distribution packet data with the received third hash value.

The second verification processing unit verifies the integrity of the update data by comparing the hash value generated from the update data with the received second hash value.

The CPU28a, which is an example of the write processing unit, writes the update data to the flash memory 28 d.

The first verification processing unit generates a hash value of the data value in the flash memory 28d, which is the new program, by writing the update data, and verifies the integrity of the new program by comparing the generated hash value with the received first hash value.

If the verification result of the update data is NG, the writing to the flash memory 28d is suspended. If the result of the verification of the new program written in the flash memory 28d is NG, the new program is invalidated and the rollback processing is performed as necessary. The first to third verification processing units may be realized by the CPU28 a. When any one of the first to third verification processing units verifies NG, the DCM12 serving as the transmission processing unit notifies the center device 3 of an abnormality.

Further, in addition to the above, as shown in fig. 267, when there is rollback data for returning the state of the old program before rewriting the update data, it may be implemented as follows.

The fourth verification value generation unit generates a fourth hash value for the old program (fourth verification value generation step; step a 5).

The fifth verification value generation unit generates a fifth hash value for the rollback data for returning the new program to the old program (fifth verification value generation step; step a 7). The rollback data represents the difference data for rollback, and corresponds to the old difference data.

The packet generation unit 202 causes the distribution packet to include the update data, the rollback difference data, the rewrite specification data, and the first, second, third, and fourth hash values (distribution packet generation step).

In this case, while the update data is being rewritten in the flash memory 28d in the vehicle-side system 4, if a user instructs, for example, that rewriting be suspended, rewriting is canceled, and restoration to the old program, in other words, rollback is performed. This is only the case where the memory structure of the ECU19 is a single-sided memory.

The second verification processing unit calculates a hash value for the rollback data included in the distribution packet, and verifies the integrity of the rollback data by comparing the calculated hash value with the fifth hash value.

The CPU28a performs writing to the flash memory 28d using the rollback data.

The first verification processing unit calculates a hash value for the old program restored by writing to the flash memory 28d, and verifies the integrity of the old program by comparing the calculated hash value with the fourth hash value.

As described above, according to the fifth embodiment, the ECU reprogramming data DB204 stores the new program and the old program of the target ECU19 to be rewritten, and the update data as the new difference data for updating the old program to the new program. The first verification value generation unit generates a first hash value using the new program, and the second verification value generation unit generates a second hash value using the update data. The packet generation unit 202 generates a packet including the update data for the target ECUs 19 and the first and second verification values and specification data. The third verification value generation section generates a third hash value using the distribution packet, and the packet distribution section 203 transmits the distribution packet to the vehicle-side system 4 together with the third hash value.

When the vehicle-side system 4 receives the distribution packet and the third hash value, the third verification processing unit calculates a hash value for the distribution packet and verifies the integrity of the distribution packet by comparing the calculated hash value with the third hash value. The second verification processing unit calculates an update data hash value corresponding to the target ECU19 included in the distribution packet, and verifies the integrity of the update data by comparing the calculated update data hash value with the second hash value included in the distribution packet.

The CPU28a writes the updated data in the flash memory 28d, and the first verification processing unit calculates a hash value of the updated data of the new program for the flash memory 28d, compares the hash value with the first hash value, and verifies the integrity of the data of the new program. In this way, the integrity of each data value can be verified in multiple stages using each hash value. Moreover, the integrity of the new program 3 can be verified again, and the vehicle-side system 4 can be prevented from writing an incomplete new program and operating with an incorrect new program.

When the ECU reprogramming data DB204 has the rollback data, the fourth verification value generation unit generates a fourth hash value for the old program, and the fifth verification value generation unit generates a fifth hash value for the rollback data. The packet generation unit 202 causes the distribution packet to include the update data, the first and second hash values, the rollback data, and the fourth and fifth hash values.

When rollback is performed in the vehicle-side system 4, the second verification processing unit calculates a hash value for the rollback data included in the distribution packet, and verifies the integrity of the rollback data by comparing the hash value with the fifth hash value. The CPU28a uses the rollback data to perform writes to the flash memory 28 d. The first verification processing unit calculates a hash value for the old program restored by writing to the flash memory 28d, and verifies the integrity of the old program by comparing the hash value with the fourth hash value. Thereby, integrity can also be verified for the old program that was written back. In the above, the first to fifth verification value generation units are functional modules in the packet management unit 3A of the center device 3. The first, second, fourth, and fifth verification processing sections are functional blocks within the target ECU19 of the vehicle-side system 4. The third authentication processing unit is a functional block in the main device 11(OTA host 11) of the vehicle-side system 4.

(modification of the first embodiment 1)

As shown in fig. 290 and 291, one activity "cpn _ 001" may be associated with a plurality of packets "pkg _001_ 1" and "pkg _001_ 2". In addition, a plurality of packets may be grouped into a plurality of groups. In the above-described embodiment, a plurality of groups are included in one packet. In the present modification, one packet is generated in one group, and a plurality of packets are distributed for one event. For example, the packet "pkg _001_ 1" includes "ADS" and "BRK" which are the ECUs belonging to group 1, and the packet "pkg _001_ 2" includes "EPS" which is the ECU belonging to group 2.

In this case, as shown in fig. 292 and fig. 293, the specification data and the distribution packet are generated independently for each group. In fig. 292, the specification data generation unit 201 generates, as the specification data of group 1, the first specification data in which, for example, ECU information of "ADS" and "BRK" is described. The specification data generation unit 201 generates second specification data in which ECU information of "EPS" is described, for example, as the specification data of group 2. In fig. 293, the packet generation unit 202 generates the rebuilt data in which the update data of "ADS" and "BRK" belonging to the group 1, for example, are sequentially merged according to the ECU, and merges the rebuilt data with the first specification data to generate the packet file "pkg 001_1. dat". The packet generation unit 202 generates the rebuilt data using the update data of the "EPS" belonging to the group 2, and generates the packet file "pkg 001_2. dat" by merging the rebuilt data with the second specification data.

(modification of the first embodiment 2)

Fig. 294 shows the processing contents in the case where the functions of the specification data generation unit 201 and the packet generation unit 202 are combined to form one packet generation tool 221. Hereinafter, each process will be described again.

In the specification data generation processing, a value input by an operator is output as specification data information in a data structure in which the number of bits and the arrangement order are previously defined, and specification data is generated. As the specification data information, for example, information in units of ECUs such as the ECU (ID1), the ECU (ID2), and the ECU (ID3), which are values illustrated in fig. 274, and information in units of vehicles or units of systems (groups) are input. The information on a vehicle basis is, for example, rewriting environment information shown in fig. 274, and the information on a system basis is, for example, group information and ECU order information shown in fig. 274. The input information of the vehicle unit and the system unit may be provided as separate files. The specification data generation process may have a function of automatically calculating a partial value such as a file size of the update data and reflecting the specification data.

In the packet generation process, the generated specification data, the update data of each ECU, the value input as the integrity verification data of each ECU, and the file are output in a data structure in which the number of bits and the order of arrangement are predetermined, and a file for distributing the packet is generated. The update data and the integrity verification data of each ECU are arranged in the order of the group from small to large and in the order of the ECUs from small to large. Here, in addition to the update data (new differential data), data for rollback (old differential data) may be added to the input. As the integrity verification data, "integrity verification data of the ECU program (new)" and "integrity verification data of the update data" are input. In the case where the rollback data is also added, "integrity verification data of the ECU old program" and "integrity verification data of the old differential data" are also added to the input.

In the integrity verification data generation process, integrity verification data is generated for the generated package file as described for step C4 of fig. 276.

The generated package file, the integrity verification data generated for the package file are registered to the package DB206 by the worker.

The functions performed by the center apparatus 3 may be implemented by hardware or software. Alternatively, the present invention may be realized by hardware or software.

The data to be rewritten is not limited to the application program, and may be data such as a map or data such as control parameters.

The content of the configuration information is not limited to the illustrated content, and may be appropriately selected according to the respective designs.

The content of the specification data is not limited to the exemplified content.

The event information and the distribution specification data may be included in the distribution packet and transmitted to the vehicle side, or may be transmitted to the vehicle side separately from the distribution packet.

In the fifth embodiment, the distribution packet and the third verification value may be stored in the packet storage unit in advance, and the packet transmission unit 213 may transmit the distribution packet and the third verification value associated with the request to the vehicle-mounted system 4 in response to the request from the vehicle-mounted system 4.

According to the present embodiment, the following operational advantages can be obtained by performing the rewriting instruction processing of the above-described (29) specific mode. In ECU19, writing of write data can be performed by writing incomplete temporary software in the write area of write data in the nonvolatile memory. In CGW13, when a specific mode such as factory mode or dealer mode is set in the rewriting specification data, writing of write data based on the specific mode is instructed to rewrite target ECU 19. In a predetermined environment such as a factory environment or a dealer environment, by preparing in advance an ECU19 in which incomplete temporary software is written in a write area in which data is written, it is possible to reduce the inventory of ECUs 19 to be managed and write data appropriately.

That is, since the product number of the ECU is determined by a combination of the hardware version and the software version of the ECU, even in the ECU having the same hardware version, if the software version differs, it is necessary to manage the stock of the ECUs having the product number corresponding to the version number of the software. In contrast, if one type of ECU is prepared in which incomplete temporary software is written as initial software in the application program writing area as in the present embodiment, software of any version can be written, so that the stock of the ECU19 to be managed can be reduced in a factory environment or a dealer environment.

Further, by providing the factory device 1001 and the dealer device 1002 with the same functions as the center apparatus 3, the program update function in the market is used, and the program update is also possible in a factory environment during the manufacture of the vehicle and a dealer environment after the shipment of the vehicle.

In CGW13, the writing target ECU is instructed to write the write data in which the process of obtaining approval for rewriting is omitted. In the environment where the permission to rewrite is obtained, the write data can be written appropriately without the permission to rewrite.

In CGW13, the writing of write data in which processing for the security function is omitted is instructed to the ECU to be rewritten. In a secure environment, write data can be appropriately written without requiring a security function.

The present disclosure has been described in terms of embodiments, but is understood not to be limited to the embodiments, configurations. The present disclosure also includes various modifications and modifications within an equivalent range. In addition, various combinations and modes, and even other combinations and modes including only one element, more elements or less elements, are also included in the scope and idea of the present disclosure.

The control unit and the method thereof described in the present disclosure may be implemented by a dedicated computer provided by configuring a processor and a memory programmed to execute one or more functions embodied by a computer program. Alternatively, the control unit and the method described in the present disclosure may be implemented by a dedicated computer provided by configuring a processor with one or more dedicated hardware logic circuits. Alternatively, the control unit and the method thereof described in the present disclosure may be implemented by one or more special purpose computers configured by a combination of a processor and a memory programmed to execute one or more functions and a processor configured by one or more hardware logic circuits. In addition, the computer program may also be stored in a computer-readable non-transitory tangible recording medium as instructions executed by a computer.

Claims

1. An electronic control system (1) for a vehicle, comprising a host device (11) for a vehicle and an electronic control device (19), wherein the host device for a vehicle instructs an electronic control device to be rewritten to write update data and distributes the update data to the electronic control device to be rewritten, and the electronic control device writes the update data received from the host device for a vehicle into a nonvolatile memory to rewrite a program,

the electronic control unit writes incomplete temporary software in a write area of the non-volatile memory in which the data is updated,

the vehicle main device includes:

a specific mode determination unit (95a) that determines whether or not a specific mode is set; and

and a rewrite instructing unit (95b) that instructs the electronic control device to be rewritten to write the update data in accordance with the specific mode when the specific mode determining unit determines that the specific mode is set.

2. The vehicular electronic control system according to claim 1, wherein,

the vehicle main device includes:

a rewriting specification data acquisition unit (74) for acquiring rewriting specification data from the outside; and

a rewriting specification data analysis unit (75) for analyzing the rewriting specification data acquired by the rewriting specification data acquisition unit,

The specific mode determination unit determines whether or not a specific mode is set based on the analysis result of the rewriting specification data analysis unit.

3. The vehicular electronic control system according to claim 1 or 2, wherein,

the rewrite instruction unit instructs the electronic control device to be rewritten to write the update data, in which the process of obtaining approval of rewriting is omitted, as the write of the update data by the specific mode.

4. The vehicular electronic control system according to claim 1 or 2, wherein,

the rewrite instruction unit instructs the electronic control device to be rewritten to write the update data, which is not subjected to the process of performing the security function, as the update data based on the specific pattern.

5. The vehicular electronic control system according to any one of claims 1 to 4, wherein,

the electronic control unit writes the update data in the write area after the write of the update data is instructed, and does not write the update data in the write area even if the write of the update data is instructed.

6. An electronic control system (1) for a vehicle, comprising a host device (11) for a vehicle, an electronic control device (19) and a center device (3, 1001, 1002), wherein the host device for a vehicle instructs an electronic control device to be rewritten to write update data and distributes the update data to the electronic control device to be rewritten, the electronic control device writes the update data received from the host device for a vehicle into a nonvolatile memory to rewrite a program, and the center device transmits the update data and specification data to the host device for a vehicle,

the vehicle main device includes:

a specific mode determination unit (95a) that determines, based on the specification data received from the center device, whether or not a specific mode different from a normal mode in which a user performs an operation related to data update is set; and

and a rewrite instructing unit (95b) that controls, when the specific mode determining unit determines that the specific mode is set, the update process in the specific mode, which is an update process in which a part of the update process in the normal mode is omitted.

7. A host device (11) for a vehicle, which distributes update data to an electronic control device to be rewritten, and instructs the electronic control device to be rewritten to write the update data, is provided with:

and a rewrite instruction unit (95b) that, when the specific mode determination unit determines that the specific mode is set, instructs the electronic control device, in which incomplete temporary software has been written in the write area of the update data in the nonvolatile memory, to write the update data in the specific mode.

8. A host device for a vehicle (11) that instructs an electronic control device to be rewritten to write update data and distributes the update data to the electronic control device to be rewritten, the host device comprising:

a specific mode determination unit (95a) that determines whether or not a specific mode different from a normal mode in which a user performs an operation related to data update is set, based on the specification data received from the center device; and

and a rewrite instructing unit (95b) that controls, when the specific mode determining unit determines that the specific mode is set, the update process based on the specific mode, which is an update process omitting a part of the update process based on the normal mode.

9. A rewriting indication method based on a specific mode, wherein,

in a vehicle host device (11) that distributes update data to an electronic control device to be rewritten and instructs the electronic control device to be rewritten to write the update data, the following are performed:

a specific mode determining step of determining whether or not a specific mode is set; and

and a specific pattern write instruction step of, when it is determined by the specific pattern determination step that the specific pattern is set, instructing an electronic control device, in which incomplete temporary software is written in a write area of the update data in the nonvolatile memory, to write the update data in the specific pattern.

10. A rewriting indication method based on a specific mode, wherein,

in a vehicle host device (11) that instructs an electronic control device to be rewritten to write update data and distributes the update data to the electronic control device to be rewritten, the following is performed:

a specific mode determination step of determining whether or not a specific mode different from a normal mode in which a user performs an operation related to data update is set, based on specification data received from the center device; and

and a rewriting instruction step of controlling the update processing in the specific mode as an update processing omitting a part of the update processing in the normal mode when it is determined in the specific mode determination step that the specific mode is set.

11. A rewrite instruction program based on a specific mode, wherein,

a host device (11) for a vehicle, which distributes update data to an electronic control device to be rewritten and instructs the electronic control device to be rewritten to write the update data, executes:

12. A rewriting instruction program based on a specific mode, wherein,

a vehicle host device (11) that instructs an electronic control device to be rewritten to write update data and distributes the update data to the electronic control device to be rewritten executes: