Vehicle electronic control system, power supply self-maintenance execution control method, and power supply self-maintenance execution control program

Abstract

In a vehicle electronic control system (1), a vehicle master device (11) includes: a vehicle power supply determination unit (92a) for determining whether the vehicle power supply is on or off; a rewriting determination unit (92b) for determining whether a program is being rewritten; a first power supply self-holding determination unit (92c) for determining whether the vehicle power supply is off and the program is being rewritten, and for determining whether the vehicle slave device needs to self-hold the power supply; and a power supply self-holding instruction unit (92d) for instructing the vehicle slave device to activate the first power supply self-holding circuit when it is determined that the power supply needs to be self-held. When the vehicle master device instructs the vehicle slave device to activate the first power supply self-holding circuit, the vehicle slave device activates the first power supply self-holding circuit.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is based on Japanese Application No. 2018-151414 filed on August 10, 2018 and Japanese Application No. 2019-129973 filed on July 12, 2019, and the contents thereof are incorporated herein by reference. Technical Field

[0003] The present disclosure relates to a vehicle electronic control system, a method for executing and controlling a self-power-supply system, and a program for executing and controlling a self-power-supply system. Background Art

[0004] In recent years, with the diversification of vehicle control such as driving assistance functions and automatic driving functions, the scale of programs for vehicle control, diagnosis, etc. of the electronic control unit (hereinafter referred to as ECU (Electronic Control Unit)) installed in the vehicle has become increasingly larger. In addition, with version upgrades based on functional improvements, etc., there are more and more opportunities to rewrite (recompile) ECU programs. On the other hand, with the development of communication networks, etc., the technology of connected cars is also becoming increasingly popular. Based on such a situation, for example, the following technology is proposed in Patent Document 1: A vehicle main device is provided on the vehicle side as a relay device, and the vehicle main device distributes the update data received from the central device via wireless to the rewriting object ECU, thereby rewriting the program of the rewriting object ECU using OTA (Over The Air).

[0005] Patent Document 1: Japanese Patent Application Laid-Open No. 2016-224898

[0006] Types of nonvolatile memory (e.g., flash memory) used to write update data in ECUs include single-sided standalone memory (with a data storage surface on one side for storing programs), single-sided suspend memory (with a pseudo-second side for data storage), and double-sided memory (with actual data storage surfaces on two sides). ECUs equipped with single-sided suspend or double-sided memory have data storage surfaces on both sides, allowing one side to be used as the operating side and the other as the non-operating side, allowing update data to be written to the non-operating side.

[0007] When rewriting an ECU equipped with such a double-sided memory, for example, the vehicle master device distributes update data to the target ECU while the vehicle is running with the ignition on, allowing the target ECU to be reprogrammed. If the vehicle is parked with the ignition off, the vehicle master device interrupts the distribution of update data to the target ECU. This situation presents a problem in that the program cannot be rewritten if the vehicle's drivable period is short. Summary of the Invention

[0008] The present disclosure has been made in view of the above circumstances, and an object thereof is to provide a vehicle electronic control system, a method for controlling execution of a self-powered system, and a program for controlling execution of a self-powered system, which are capable of appropriately performing program rewriting.

[0009] According to one embodiment of the present disclosure, a vehicle master distributes update data to an electronic control device to be rewritten. A vehicle slave has a first power self-holding circuit. In the vehicle master, a vehicle power determination unit determines whether the vehicle power is on or off. A rewriting determination unit determines whether a program is being rewritten. If the vehicle power determination unit determines that the vehicle power is disconnected and the rewriting determination unit determines that a program is being rewritten, the first power self-holding determination unit determines the necessity of self-holding the power in the vehicle slave. If the first power self-holding determination unit determines that the vehicle slave needs to self-hold the power, the power self-holding instruction unit instructs the vehicle slave to activate the first power self-holding circuit.

[0010] In the vehicle slave device, the instruction determination unit determines whether the vehicle master device has instructed to activate the first power self-holding circuit. If the instruction determination unit determines to activate the first power self-holding circuit, the first power self-holding activation unit activates the first power self-holding circuit.

[0011] If the vehicle master device determines that the vehicle power is disconnected and the program is being rewritten, it determines whether the vehicle slave device must self-hold power. If self-hold power is determined to be necessary, the vehicle slave device is instructed to activate a first self-holding circuit. If the vehicle slave device determines that activation of the first self-holding circuit has been instructed by the vehicle master device, the first self-holding circuit is activated. Even when the vehicle power is disconnected, activating the first self-holding circuit ensures operating power for rewriting the application program, allowing the application program to be rewritten appropriately. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The above-mentioned objects and other objects, features and advantages of the present disclosure will become more apparent through the following detailed description with reference to the accompanying drawings.

[0013] Figure 1 It is a diagram showing the overall structure of one embodiment.

[0014] Figure 2 This is a diagram showing the electrical structure of the CGW.

[0015] Figure 3 This is a diagram showing the electrical structure of a DCM.

[0016] Figure 4This is a diagram showing the electrical structure of the ECU.

[0017] Figure 5 This diagram shows how to connect the power cord.

[0018] Figure 6 This diagram shows how to package reorganization data and distribution specification data.

[0019] Figure 7 This is a diagram showing rewritten specification data for DCM.

[0020] Figure 8 This is a diagram showing rewriting specification data for CGW.

[0021] Figure 9 This is a diagram showing distribution specification data.

[0022] Figure 10 This diagram shows how to unpack a distribution packet.

[0023] Figure 11 This is a diagram showing a normal operation of the embedded single-sided independent memory.

[0024] Figure 12 This is a diagram showing how an embedded single-sided independent memory performs a rewriting operation.

[0025] Figure 13 This is a diagram showing a normal operation mode in a download-type single-sided independent memory.

[0026] Figure 14 This is a diagram showing the manner of rewriting operation in a download-type single-sided independent memory.

[0027] Figure 15 This is a diagram showing a normal operation of the embedded single-sided suspend memory.

[0028] Figure 16 This is a diagram showing how an overwrite operation is performed in an embedded single-sided suspend memory.

[0029] Figure 17 This is a diagram showing a normal operation mode in a download-type single-sided suspend memory.

[0030] Figure 18 This is a diagram showing the manner of rewriting operation in a download-type single-sided suspend memory.

[0031] Figure 19 This is a diagram showing a normal operation of the embedded double-sided memory.

[0032] Figure 20 This is a diagram showing how the embedded double-sided memory performs a rewriting operation.

[0033] Figure 21 This is a diagram showing a normal operation mode in a download-type double-sided memory.

[0034] Figure 22 This is a diagram showing the manner of rewriting operation in a download-type double-sided memory.

[0035] Figure 23 This diagram shows how to rewrite an application.

[0036] Figure 24 This diagram shows how to rewrite an application.

[0037] Figure 25 This diagram shows how to rewrite an application.

[0038] Figure 26 This is a timing diagram showing how to rewrite an application program through power control.

[0039] Figure 27 This is a timing diagram showing how to rewrite an application program through power control.

[0040] Figure 28 This is a timing diagram showing how to rewrite the application program by self-holding the power supply.

[0041] Figure 29 This is a timing diagram showing how to rewrite the application program by self-holding the power supply.

[0042] Figure 30 It is a diagram showing the stages.

[0043] Figure 31 This figure shows a normal screen.

[0044] Figure 32 This figure shows a screen when an event notification is generated.

[0045] Figure 33 This figure shows a screen when an event is notified.

[0046] Figure 34 This is a diagram showing a screen that appears when downloading is approved.

[0047] Figure 35 This is a diagram showing a screen that appears when downloading is approved.

[0048] Figure 36 This figure shows a screen showing downloading in progress.

[0049] Figure 37 This figure shows a screen showing downloading in progress.

[0050] Figure 38This figure shows the screen when downloading is completed.

[0051] Figure 39 This figure shows the screen when the installation is approved.

[0052] Figure 40 This figure shows the screen when the installation is approved.

[0053] Figure 41 This figure shows the screen during installation.

[0054] Figure 42 This figure shows the screen during installation.

[0055] Figure 43 This figure shows a screen when activating consent.

[0056] Figure 44 This figure shows the screen when the IG is turned on.

[0057] Figure 45 This figure shows a screen for confirming an operation.

[0058] Figure 46 This figure shows a screen for confirming an operation.

[0059] Figure 47 This is a functional block diagram of the central device.

[0060] Figure 48 This is the functional block diagram of DCM.

[0061] Figure 49 This is a functional block diagram of CGW.

[0062] Figure 50 This is a functional block diagram of CGW.

[0063] Figure 51 This is the functional block diagram of the ECU.

[0064] Figure 52 This is a functional block diagram of an in-vehicle display.

[0065] Figure 53 This is a functional block diagram of a transmission determination unit for a distribution packet.

[0066] Figure 54 This is a flowchart showing the transmission determination process of a distribution packet.

[0067] Figure 55 This is a functional block diagram of a download determination unit for a distribution data package.

[0068] Figure 56 This is a flowchart showing the download determination process of the distribution package.

[0069] Figure 57 This is a functional block diagram of the transfer determination unit for write data.

[0070] Figure 58 4 is a flowchart showing the transfer determination process of write data.

[0071] Figure 59 This is a functional block diagram of the write data acquisition determination unit.

[0072] Figure 60 This is a flowchart showing the acquisition and determination processing of write data.

[0073] Figure 61 This is a functional block diagram of the installed instruction determination unit.

[0074] Figure 62 This is a flowchart showing the installation instruction determination process.

[0075] Figure 63 This is a diagram showing how to install the instructions.

[0076] Figure 64 This is a diagram showing how to install the instructions.

[0077] Figure 65 It is a diagram showing how random values ​​are generated.

[0078] Figure 66 This is a functional block diagram of the secure access key management unit.

[0079] Figure 67 This is a flowchart showing the process of generating a secure access key.

[0080] Figure 68 It is a diagram showing how to generate a secure access key.

[0081] Figure 69 This is a flowchart showing the process of deleting a secure access key.

[0082] Figure 70 This is a diagram showing the flow of processing related to verification of written data.

[0083] Figure 71 This is a functional block diagram of the verification unit for written data.

[0084] Figure 72 This is a flowchart showing the verification process of written data.

[0085] Figure 73 This is a diagram showing a method of distributing the processing related to verification of written data.

[0086] Figure 74 This is a diagram showing a method of distributing the processing related to verification of written data.

[0087] Figure 75 This is a diagram showing a method of distributing the processing related to verification of written data.

[0088] Figure 76 This is a diagram showing a method of distributing the processing related to verification of written data.

[0089] Figure 77 This is a diagram showing the flow of verification of written data and rewriting of an application program.

[0090] Figure 78 This is a diagram showing the flow of verification of written data and rewriting of an application program.

[0091] Figure 79 This is a functional block diagram of the data storage surface information transmission control unit.

[0092] Figure 80 This is a flowchart showing the transmission control process of data storage surface information.

[0093] Figure 81 This is a sequence diagram showing a method of notifying double-sided rewriting information.

[0094] Figure 82 This is a functional block diagram of the power management unit that is not subject to rewriting.

[0095] Figure 83 This is a flowchart showing the power management process for non-rewrite targets.

[0096] Figure 84 This diagram shows the transition between the start state, stop state, and sleep state.

[0097] Figure 85 This diagram shows the transition between the start state, stop state, and sleep state.

[0098] Figure 86 This diagram shows how to connect the power cord.

[0099] Figure 87 This is a flowchart showing the process of monitoring the remaining battery level.

[0100] Figure 88 This is a functional block diagram of the file transfer control unit.

[0101] Figure 89 This is a flowchart showing the file transfer control process.

[0102] Figure 90 This diagram shows how to transfer documents.

[0103] Figure 91 This diagram shows how to transfer documents.

[0104] Figure 92 This is a diagram showing the split files and written files.

[0105] Figure 93 This is a diagram showing how the CGW sends a transfer request to the DCM.

[0106] Figure 94 This is a diagram showing how the CGW sends a transfer request to the DCM.

[0107] Figure 95 This is a diagram showing how the CGW distributes write data to the rewriting target ECU.

[0108] Figure 96 This is a diagram showing how the CGW distributes write data to the rewriting target ECU.

[0109] Figure 97 This is a diagram showing how the CGW distributes write data to the rewriting target ECU.

[0110] Figure 98 This is a diagram showing how the ECU is connected.

[0111] Figure 99 This is a functional block diagram of the distribution control unit for write data.

[0112] Figure 100 is a diagram showing a bus load table.

[0113] Figure 101 This is a diagram showing a table to which ECUs to be rewritten belong.

[0114] Figure 102 This is a flowchart showing the distribution control process of write data.

[0115] Figure 103 This diagram shows how write data is distributed.

[0116] Figure 104 This diagram shows how write data is distributed.

[0117] Figure 105 This is a diagram showing a method of distributing and writing data while a vehicle is traveling.

[0118] Figure 106 This is a diagram showing a method of distributing and writing data while the vehicle is parked.

[0119] Figure 107 This is a graph showing the distribution amount of write data.

[0120] Figure 108 This is a graph showing the distribution amount of write data.

[0121] Figure 109 This is a functional block diagram of an activation request instruction unit.

[0122] Figure 110 This is a flowchart showing the instruction processing of the activation request.

[0123] Figure 111 This is a diagram showing a method of instructing an activation request.

[0124] Figure 112 This is a functional block diagram of the activated execution control unit.

[0125] Figure 113 This is a flowchart showing the rewriting process.

[0126] Figure 114 is a flowchart showing the execution control process of activation.

[0127] Figure 115 This is a functional block diagram of the grouping unit for rewriting objects.

[0128] Figure 116 This is a flowchart showing the group management process of the rewriting object.

[0129] Figure 117 This is a flowchart showing the group management process of the rewriting object.

[0130] Figure 118 This is a diagram showing how to group rewrite objects.

[0131] Figure 119 This is a functional block diagram of the rollback execution control unit.

[0132] Figure 120 This is a flowchart showing the process of determining the rollback method.

[0133] Figure 121 This is a flowchart showing the cancellation request determination process.

[0134] Figure 122 This is a flowchart showing the cancellation request determination process.

[0135] Figure 123 This is a flowchart showing the cancellation request determination process.

[0136] Figure 124 This is a flowchart showing the cancellation request determination process.

[0137] Figure 125 This is a flowchart showing the cancellation request determination process.

[0138] Figure 126 This is a diagram showing how a rollback is performed.

[0139] Figure 127 This is a diagram showing how a rollback is performed.

[0140] Figure 128 This is a diagram showing how a rollback is performed.

[0141] Figure 129 This is a diagram showing how a rollback is performed.

[0142] Figure 130 This is a diagram showing how a rollback is performed.

[0143] Figure 131 This is a functional block diagram of the display control unit that rewrites the progress status.

[0144] Figure 132 This is a flowchart of a display control process showing a rewriting progress status.

[0145] Figure 133 This is a flowchart of a display control process showing a rewriting progress status.

[0146] Figure 134 This is a diagram showing a screen showing the progress of rewriting.

[0147] Figure 135 This is a diagram showing a screen showing the progress of rewriting.

[0148] Figure 136 This is a diagram showing a screen showing the progress of rewriting.

[0149] Figure 137 This is a diagram showing a screen showing the progress of rewriting.

[0150] Figure 138 This is a diagram showing a screen showing the progress of rewriting.

[0151] Figure 139 This is a diagram showing the transition displayed on the progress graph.

[0152] Figure 140 This is a diagram showing the transition displayed on the progress graph.

[0153] Figure 141 This is a diagram showing the transition displayed on the progress graph.

[0154] Figure 142 This is a diagram showing the transition displayed on the progress graph.

[0155] Figure 143 This is a diagram showing a screen showing the progress of rewriting.

[0156] Figure 144 This is a functional block of the difference data consistency determination unit.

[0157] Figure 145This is a flowchart showing the matching determination process of difference data.

[0158] Figure 146 This is a diagram showing a method for determining the consistency of differential data.

[0159] Figure 147 This is a diagram showing a method for determining the consistency of differential data.

[0160] Figure 148 This is a functional block diagram of the rewritten execution control unit.

[0161] Figure 149 This is a flowchart showing normal operation processing.

[0162] Figure 150 This is a flowchart showing the rewriting operation process.

[0163] Figure 151 This is a flowchart showing information notification processing.

[0164] Figure 152 This is a flowchart showing the verification process of the rewritten program.

[0165] Figure 153 This diagram shows how identification information is transmitted and data is written.

[0166] Figure 154 This diagram shows how identification information is transmitted and data is written.

[0167] Figure 155 This is a flowchart showing the installation instruction processing.

[0168] Figure 156 This is a functional block diagram of the session establishment unit.

[0169] Figure 157 A diagram showing the structure of a program.

[0170] Figure 158 It is a diagram that represents state transition.

[0171] Figure 159 It is a diagram that represents state transition.

[0172] Figure 160 It is a diagram that represents state transition.

[0173] Figure 161 This is a diagram showing the mediation of a conversation.

[0174] Figure 162 This is a diagram showing the mediation of a conversation.

[0175] Figure 163 This is a flowchart showing the state transition management process in the first state.

[0176] Figure 164 This is a flowchart showing the state transition management process in the first state.

[0177] Figure 165 This is a flowchart showing the state transition management process in the first state.

[0178] Figure 166 This is a flowchart showing the state transition management process in the second state.

[0179] Figure 167 This is a flowchart showing the state transition management process in the second state.

[0180] Figure 168 A diagram showing the structure of a program.

[0181] Figure 169 It is a diagram that represents state transition.

[0182] Figure 170 This is a functional block diagram of a retry point determination unit.

[0183] Figure 171 This is a diagram showing the structure of a flash memory.

[0184] Figure 172 This is a flowchart showing the process of setting the processing flag.

[0185] Figure 173 This is a flowchart showing the process of determining the processing flag.

[0186] Figure 174 This is a flowchart showing the process of determining the processing flag.

[0187] Figure 175 This is a functional block diagram of the synchronization control unit in the progress state.

[0188] Figure 176 This is a functional block diagram of the synchronization control unit in the progress state.

[0189] Figure 177 This is a diagram showing a method of transmitting and receiving progress status signals.

[0190] Figure 178 This is a flowchart showing the progress of the synchronous control process.

[0191] Figure 179 This is a flowchart showing the progress of the synchronous control process.

[0192] Figure 180 This is a flowchart showing the progress status display process.

[0193] Figure 181 This is a functional block diagram of a transmission control unit for display control information.

[0194] Figure 182 This is a flowchart showing the transmission control processing of display control information.

[0195] Figure 183 This is a functional block diagram of a reception control unit for display control information.

[0196] Figure 184 This is a flowchart showing the reception control process of display control information.

[0197] Figure 185 This is a diagram showing information included in the distribution specification data.

[0198] Figure 186 This is a functional block diagram of the screen display control unit for progress display.

[0199] Figure 187 This is a diagram showing rewritten specification data.

[0200] Figure 188 This figure shows the screen when a menu is selected.

[0201] Figure 189 This figure shows the screen when the user makes a selection.

[0202] Figure 190 This figure shows a screen when a user registers.

[0203] Figure 191 This is a flowchart showing screen display control processing for progress display.

[0204] Figure 192 This is a flowchart showing screen display control processing for progress display.

[0205] Figure 193 is a diagram showing a message frame.

[0206] Figure 194 This figure shows a screen when activating consent.

[0207] Figure 195 This is a diagram showing the setting of whether or not to display an item.

[0208] Figure 196 This is a diagram showing the setting of whether or not to display an item.

[0209] Figure 197 This figure shows a screen when activating consent.

[0210] Figure 198 This is a diagram showing a data communication method.

[0211] Figure 199 This diagram shows the message frame for activity notification.

[0212] Figure 200 This is a diagram showing a message frame when downloading is approved.

[0213] Figure 201 This is a diagram showing a message frame when installation is approved.

[0214] Figure 202 This is a diagram showing a message frame when activating consent.

[0215] Figure 203 This is a diagram showing the transition of the screen.

[0216] Figure 204 This figure shows a screen when an event notification is generated.

[0217] Figure 205 This is a diagram showing a screen that appears when downloading is approved.

[0218] Figure 206 This is a diagram showing a screen that appears when downloading is approved.

[0219] Figure 207 This figure shows a screen showing downloading in progress.

[0220] Figure 208 This figure shows the screen when downloading is completed.

[0221] Figure 209 This figure shows the screen when the installation is approved.

[0222] Figure 210 This figure shows a screen when activating consent.

[0223] Figure 211 This is a functional block diagram of the report control unit for program updates.

[0224] Figure 212 This is a flowchart showing the report control process for program update.

[0225] Figure 213 This is a diagram showing how indicators are reported.

[0226] Figure 214 This is a diagram showing the transition of the reporting method when the rewriting target is a double-sided memory.

[0227] Figure 215 This is a diagram showing the transition of the reporting method when the rewriting target is a single-sided suspend memory.

[0228] Figure 216 This is a diagram showing the transition of the reporting method when the rewriting target is a single-sided dedicated memory.

[0229] Figure 217This is a diagram showing the connection method.

[0230] Figure 218 This is a functional module of the execution control unit for power self-maintenance in the CGW.

[0231] Figure 219 This is a functional module that controls the execution of the self-powered ECU.

[0232] Figure 220 This is a flowchart showing the execution control process of self-power-supply in the CGW.

[0233] Figure 221 This is a flowchart showing the execution control process of the power supply self-holding in the ECU.

[0234] Figure 222 This is a diagram showing the period during which the power supply must be self-maintained.

[0235] Figure 223 This is an overall sequence diagram showing how to rewrite an application.

[0236] Figure 224 This is an overall sequence diagram showing how to rewrite an application.

[0237] Figure 225 This is an overall sequence diagram showing how to rewrite an application.

[0238] Figure 226 This is an overall sequence diagram showing how to rewrite an application.

[0239] Figure 227 This is an overall sequence diagram showing how to rewrite an application.

[0240] Figure 228 This is an overall sequence diagram showing how to rewrite an application.

[0241] Figure 229 This is an overall sequence diagram showing how to rewrite an application.

[0242] Figure 230 This is an overall sequence diagram showing how to rewrite an application.

[0243] Figure 231 This is an overall sequence diagram showing how to rewrite an application.

[0244] Figure 232 This is an overall sequence diagram showing how to rewrite an application.

[0245] Figure 233 This is an overall sequence diagram showing how to rewrite an application.

[0246] Figure 234It is a diagram showing the overall configuration of the vehicle information communication system in the first embodiment.

[0247] Figure 235 This is a diagram showing the electrical structure of the CGW.

[0248] Figure 236 This is a diagram showing the electrical structure of the ECU.

[0249] Figure 237 This diagram shows how to connect the power cord.

[0250] Figure 238 This diagram shows how to package reorganization data and distribution specification data.

[0251] Figure 239 This diagram shows how to unpack a distribution packet.

[0252] Figure 240 This diagram shows, in the form of a block diagram, a portion of the center device mainly related to each function of the server.

[0253] Figure 241 This is a graphic diagram showing the flow of processing in the center device.

[0254] Figure 242 FIG. 1 is a diagram showing an example of vehicle configuration information registered in the configuration information DB.

[0255] Figure 243 This is a diagram showing an example of programs and data registered in the ECU reprogramming data DB.

[0256] Figure 244 This is a diagram showing an example of specification data registered in the ECU metadata DB.

[0257] Figure 245 FIG. 1 is a diagram showing an example of the structural information of a vehicle registered in the individual vehicle information DB.

[0258] Figure 246 This is a diagram showing an example of distribution package data registered in the package DB.

[0259] Figure 247 FIG. 1 is a diagram showing an example of activity data registered in the activity DB.

[0260] Figure 248 This is a flowchart showing a process of generating a program and data to be registered in the ECU reprogramming data DB.

[0261] Figure 249 This is a flowchart showing an example of a process for generating specification data to be registered in the ECU metadata DB.

[0262] Figure 250 This is a diagram showing an example of specification data.

[0263] Figure 251 This is a diagram showing an example of a bus load table.

[0264] Figure 252 This is a flowchart showing the process of generating a distribution package registered in the package DB.

[0265] Figure 253 A diagram that graphically represents the contents of a packet file.

[0266] Figure 254 This is a sequence diagram showing the flow of processing executed between the center device and the vehicle-side system in the second embodiment.

[0267] Figure 255 This is a flowchart showing the processing performed by the center device.

[0268] Figure 256 It is represented in a graphical form Figure 248 FIG. 1 is a diagram showing the contents of processing performed in steps D6 and D7 of the flowchart shown.

[0269] Figure 257 This is a flowchart showing the process when a hash value is transmitted from the vehicle-side system to the center device.

[0270] Figure 258 This is a sequence diagram showing the flow of processing executed between the central device and the vehicle-side system in the third embodiment.

[0271] Figure 259 This is a flowchart showing the processing performed by the center device.

[0272] Figure 260 This is a sequence diagram showing a state in which the center device notifies each of the EV vehicle and the combination vehicle via SMS.

[0273] Figure 261 This is a sequence diagram showing the flow of processing executed between the center device and the vehicle-side system in the fourth embodiment.

[0274] Figure 262 This is a diagram graphically showing the processing performed among the supplier, the center device, and the vehicle-side system in the fifth embodiment.

[0275] Figure 263 This is a sequence diagram (part 1) showing the flow of processing performed between the supplier, the center device, and the vehicle-side system.

[0276] Figure 264This is a sequence diagram (part 2) showing the flow of processing performed between the supplier, the central device, and the vehicle-side system.

[0277] Figure 265 This is a sequence diagram (part 3) showing the flow of processing performed between the supplier, the central device, and the vehicle-side system.

[0278] Figure 266 This is a modification (No. 1) of the first embodiment, and is a diagram showing the data format of a packet DB in a case where a plurality of packets are associated with one activity.

[0279] Figure 267 This is a diagram showing the data format of the activity DB when a plurality of data packets are associated with one activity.

[0280] Figure 268 When generating specification data by group Figure 242 Quite a picture.

[0281] Figure 269 Is the case of generating and distributing data packets by group Figure 245 Quite a picture.

[0282] Figure 270 This is a modification (Part 2) of the first embodiment, and is a diagram showing the processing contents of the packet generation tool. DETAILED DESCRIPTION

[0283] An embodiment is described below with reference to the accompanying drawings. A vehicle program rewriting system (equivalent to a vehicle electronic control system) is capable of rewriting vehicle control and diagnostic applications installed in an electronic control unit (hereinafter referred to as an ECU) via OTA (Over the Air). While this embodiment describes rewriting applications via wired or wireless communication, it is also applicable to rewriting map data used in map applications, control parameters used in ECUs, and other data used in various applications, for example, via wired or wireless communication.

[0284] Rewriting applications via wired connections involves not only acquiring and rewriting applications from outside the vehicle via wired connections, but also acquiring and rewriting various data used when executing applications from outside the vehicle via wired connections. Rewriting applications via wireless connections involves not only acquiring and rewriting applications from outside the vehicle via wireless connections, but also acquiring and rewriting various data used when executing applications from outside the vehicle via wireless connections.

[0285] like Figure 1As shown, the vehicle program rewriting system 1 includes a central 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 is composed of a mobile communication network such as a 4G line, the Internet, WiFi (Wireless Fidelity) (registered trademark), etc. In addition, in this embodiment, the configuration on the vehicle side is mainly described. Regarding the configuration of the central device 3, Figures 234 to 270 Described in detail in.

[0286] The display terminal 5 is a terminal that accepts user input and displays various screens. Examples include a mobile terminal 6 such as a smartphone or tablet that the user can carry, and an onboard display 7 located within the vehicle. Within the communication range of the mobile communication network, the mobile terminal 6 can communicate data with the center device 3 via the communication network 2. The onboard display 7 is connected to the vehicle-side system 4 and may also include navigation functions. Alternatively, the onboard display 7 may be an onboard display ECU that functions as an ECU, or may have the function of controlling the display on a center display, instrument panel, or the like.

[0287] If the user is outside the vehicle and within the communication range of the mobile communication network, they can confirm the various screens related to the application rewrite through the mobile terminal 6 while performing operational inputs and completing the application rewrite procedures. Inside the vehicle, the user can confirm the various screens related to the application rewrite through the onboard display 7 while performing operational inputs and completing the application rewrite procedures. In other words, the user can use the mobile terminal 6 and onboard display 7 separately outside and inside the vehicle to complete the application rewrite procedures.

[0288] In the vehicle program rewriting system 1, the center device 3 oversees program update functions on the communication network 2 side, functioning as an OTA center. The center device 3 includes a file server 8, a web server 9, and a management server 10. Each server 8-10 is configured to communicate data with one another. Specifically, the center device 3 includes multiple servers, each with its own function.

[0289] The file server 8 manages files for applications distributed from the center device 3 to the vehicle-side system 4. The file server 8 manages update data (hereinafter also referred to as reprogram data or write data) provided by suppliers, or other companies providing applications distributed from the center device 3 to the vehicle-side system 4, distribution specification data provided by OEMs (Original Equipment Manufacturers), and vehicle status data acquired from the vehicle-side system 4. The file server 8 is capable of communicating with the vehicle-side system 4 via the communication network 2. In response to a download request for a distribution package, the file server 8 transmits a distribution package containing the reprogram data and distribution specification data packaged into a single file to the vehicle-side system 4.

[0290] Web server 9 manages web page information. Web server 9 distributes its managed web page data in response to requests from a web browser on a mobile terminal 6 or the like. Management server 10 manages the personal information of users registered with the application rewriting service, the application rewriting history for each vehicle, and other information.

[0291] The vehicle-side system 4 includes a master device 11 (equivalent to a vehicle master device). The master device 11 includes a DCM (Data Communication Module) 12 (equivalent to an onboard communication device) and a CGW (Central GateWay) 13 (equivalent to a vehicle gateway device). The DCM 12 and CGW 13 are connected via a first bus 14 for data communication. The DCM 12 communicates data with the central device 3 via the communication network 2. When the DCM 12 downloads a distribution package from the file server 8, it extracts the written data from the downloaded distribution package and transmits the extracted written data to the CGW 13.

[0292] The CGW 13 has a data relay function. Upon receiving write data from the DCM 12, it instructs the target ECU (the target of the application program) to write the received write data and distributes the write data to the target ECU. Furthermore, once the write data is written to the target ECU, completing the application program rewrite, the CGW 13 instructs the target ECU to activate the completed application program.

[0293] The main device 11 manages the program update function on the vehicle side in the vehicle program rewriting system 1 and functions as an OTA host. Figure 1In the example, the DCM 12 and the onboard display 7 are connected to the same first bus 14. However, the DCM 12 and the onboard display 7 may be connected to different buses. Furthermore, the CGW 13 may have some or all of the functions of the DCM 12, or the DCM 12 may have some or all of the functions of the CGW 13. In other words, the functions of the DCM 12 and CGW 13 in the master device 11 can be divided in any manner. The master device 11 may be composed of two ECUs, the DCM 12 and the CGW 13, or a single integrated ECU that has the functions of both the DCM 12 and the CGW 13.

[0294] In addition to the first bus 14 , the CGW 13 is also connected to a second bus 15 , a third bus 16 , a fourth bus 17 , and a fifth bus 18 as in-vehicle buses. Various ECUs 19 are connected via the buses 15 to 17 , and a power management ECU 20 is connected via the bus 18 .

[0295] The second bus 15 is, for example, a bus of a vehicle body system network. The ECU 19 connected to the second bus 15 is an ECU that controls the vehicle body systems. Examples of ECUs that control the vehicle body systems include a door ECU that controls door locking and unlocking, an instrument ECU that controls the display on the instrument panel, an air conditioning ECU that controls air conditioning operation, a window ECU that controls window opening and closing, and a security ECU that operates for vehicle theft prevention.

[0296] The third bus 16 is, for example, a bus of a travel system network. The ECU 19 connected to the third bus 16 is an ECU that controls the travel system. Examples of ECUs that control the travel system include an engine ECU that controls engine operation, a brake ECU that controls brake operation, an ECT (Electronic Controlled Transmission) ECU that controls automatic transmission operation, and a power steering ECU that controls power steering operation.

[0297] The fourth bus 17 is, for example, a bus of a multimedia system network. The ECU 19 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 for controlling the navigation system, an ETC ECU that controls the electronic toll collection system (ETC (Electronic Toll Collection System, registered trademark)), etc. Buses 15 to 17 may also be buses of systems other than the bus of the body system network, the bus of the driving system network, and the bus of the multimedia system network. In addition, the number of buses and the number of ECUs 19 are not limited to the illustrated configuration. The power management ECU 20 is an ECU that manages the power supplied to the DCM 12, CGW 13, various ECUs 19, etc.

[0298] The CGW 13 is connected to a sixth bus 21, serving as an exterior vehicle bus. A DLC (Data Link Coupler) connector 22, which allows for detachable connection to a tool 23 (equivalent to a service tool), is connected to the sixth bus 21. The interior vehicle buses 14-18 and the exterior vehicle bus 21 are comprised of, for example, a CAN (Controller Area Network) bus. The CGW 13 communicates data with the DCM 12, various ECUs 19, and the tool 23 in accordance with the CAN data communication standard and the diagnostic communication standard (UDS (Unified Diagnosis Services): ISO 14229). Alternatively, the DCM 12 and CGW 13 may be connected via Ethernet, or the DLC connector 22 and CGW 13 may be connected via Ethernet.

[0299] Upon receiving write data from the CGW 13, the target ECU 19 writes the received write data to a flash memory (equivalent to a non-volatile memory) to rewrite the application program. In the above configuration, the CGW 13 functions as a reprogramming master, which, upon receiving a write data acquisition request from the target ECU 19, distributes the write data to the target ECU 19. The target ECU 19, upon receiving write data from the CGW 13, functions as a reprogramming slave, which, upon receiving write data from the CGW 13, writes the received write data to the flash memory to rewrite the application program.

[0300] There are two methods for rewriting applications: wired and wireless. The wired method involves rewriting the target ECU 19 using an application acquired from outside the vehicle via a wired connection. Specifically, when the tool 23 is connected to the DLC connector 22, the tool 23 transmits the write data to the CGW 13. The CGW 13 acts as a gateway, sending a wired rewrite request to the target ECU 19, instructing the target ECU 19 to write (install) the write data, and distributing the write data transmitted from the tool 23 to the target ECU 19. Distributing the write data to the target ECU 19 means relaying the write data.

[0301] The so-called wireless application rewriting method refers to a method of rewriting the target ECU 19 using an application program wirelessly acquired from outside the vehicle. Specifically, when the DCM 12 downloads a distribution package from the file server 8, it extracts the write data from the downloaded distribution package and transmits the write data to the CGW 13. The CGW 13 functions as a rewriting tool, instructing the target ECU 19 to write (install) the write data and distributing the write data transmitted from the DCM 12 to the target ECU 19.

[0302] Diagnosing the ECU 19 can be done via wired or wireless methods. Wired diagnosis involves diagnosing the ECU 19 from outside the vehicle via a wired connection. Specifically, when the tool 23 is connected to the DLC connector 22, the tool 23 transmits a diagnostic request to the CGW 13. The CGW 13 acts as a gateway, sending the diagnostic request to the ECU 19 being diagnosed and distributing the diagnostic instructions transmitted from the tool 23 to the ECU 19 being diagnosed. The ECU 19 then performs diagnostic processing in accordance with the diagnostic instructions received from the CGW 13.

[0303] Wireless diagnostics involve diagnosing the ECU 19 wirelessly from outside the vehicle. Specifically, when a diagnostic command is sent from the center device 3 to the DCM 12 as a diagnostic request, the DCM 12 transmits the command to the CGW 13. The CGW 13, acting as a gateway, distributes the command as a diagnostic request to the ECU 19 being diagnosed. The ECU 19 then performs diagnostic processing in accordance with the command received from the CGW 13.

[0304] like Figure 2As shown, the CGW 13 includes a microcomputer (hereinafter referred to as microcomputer) 24, a data transmission circuit 25, a power supply circuit 26, and a power detection circuit 27 as electrical functional modules. 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 24d. The flash memory 24d contains a secure area where information cannot be read from outside the CGW 13. The microcomputer 24 executes various control programs stored on a non-transitory physical storage medium to perform various processes and control the operation of the CGW 13.

[0305] The data transmission circuit 25 controls data communication with buses 14 to 18 and 21 in accordance with the CAN data communication standard and the diagnostic communication standard. The power supply circuit 26 receives inputs from the battery power supply (hereinafter referred to as the +B power supply), the accessory power supply (hereinafter referred to as the ACC power supply), and the ignition power supply (hereinafter referred to as the IG power supply). The power supply detection circuit 27 detects the voltage values ​​of the +B power supply, the ACC power supply, and the IG power supply inputted by the power supply circuit 26, compares these detected voltage values ​​with predetermined voltage thresholds, and outputs the comparison results to the microcomputer 24. Based on the comparison results inputted from the power supply detection circuit 27, the microcomputer 24 determines whether the +B power supply, the ACC power supply, and the IG power supply supplied externally to the CGW 13 are normal or abnormal.

[0306] like Figure 3 As shown, the DCM 12 includes a microcomputer 28, a wireless circuit 29, a data transmission circuit 30, a power supply circuit 31, and a power detection circuit 32 as electrical functional modules. The microcomputer 28 includes a CPU 28a, a ROM 28b, a RAM 28c, and a flash memory 28d. The flash memory 28d contains a secure area where information cannot be read from outside the DCM 12. The microcomputer 28 executes various control programs stored on a non-transitory physical storage medium to perform various processes and control the operation of the DCM 12. Flash memory for storing data downloaded from the center device 3 may also be provided in the CGW 13.

[0307] The wireless circuit 29 controls data communication with the center device 3 via the communication network 2. The data transmission circuit 30 controls data communication with the bus 14 in accordance with the CAN data communication standard. The power supply circuit 31 receives inputs of the +B power supply, the ACC power supply, and the IG power supply. The power supply detection circuit 32 detects the voltage values ​​of the +B power supply, the ACC power supply, and the IG power supply inputted by the power supply circuit 31, compares these detected voltage values ​​with predetermined voltage thresholds, and outputs the comparison results to the microcomputer 28. Based on the comparison results inputted from the power supply detection circuit 32, the microcomputer 28 determines whether the +B power supply, the ACC power supply, and the IG power supply supplied externally to the DCM 12 are normal or abnormal.

[0308] The DCM 12 also has a vehicle position detection function that uses, for example, GPS (Global Positioning System) to detect the vehicle's position. The DCM 12's flash memory 28d has sufficient memory capacity to store distribution data packages downloaded from the center device 3 and has a larger memory capacity than the CGW 13's flash memory 24d. Specifically, because the DCM 12's flash memory 28d has sufficient memory capacity, the host device 11 can download distribution data packages from the center device 3 and store them in the DCM 12, even if the CGW 13's flash memory 24d does not have sufficient memory capacity.

[0309] like Figure 4 As shown, the ECU 19 includes a microcomputer 33, a data transmission circuit 34, a power supply circuit 35, and a power detection circuit 36 ​​as electrical functional modules. The microcomputer 33 includes a CPU 28a, a ROM 28b, a RAM 33c, and a flash memory 28d. The flash memory 28d contains a secure area where information cannot be read from outside the ECU 19. The microcomputer 33 executes various control programs stored in a non-transitory physical storage medium to perform various processes and control the operation of the ECU 19.

[0310] The data transmission circuit 34 controls data communication with buses 15-17 in accordance with the CAN data communication standard. The power supply circuit 35 receives inputs for the +B power supply, ACC power supply, and IG power supply. The power supply detection circuit 36 ​​detects the voltage values ​​of the +B power supply, ACC power supply, and IG power supply inputted by the power supply circuit 35, compares these detected voltage values ​​with predetermined voltage thresholds, and outputs the comparison results to the microcomputer 33. Based on the comparison results inputted from the power supply detection circuit 27, the microcomputer 33 determines whether the +B power supply, ACC power supply, and IG power supply supplied externally to the ECU 19 are normal or abnormal. The ECU 19 has a fundamentally identical configuration, except for differences in connected loads such as sensors and actuators.

[0311] The vehicle-mounted display 7 has Figure 4 The power management ECU 20 has the same structure as the ECU 19 shown in FIG. Figure 4 The power management ECU 20 has the same configuration as the ECU 19 shown. The power management ECU 20 is connected to enable data communication with a power control circuit 43 described later.

[0312] like Figure 5 As shown, the power management ECU 20, CGW 13, and ECU 19 are connected to a +B power line 37, an ACC power line 38, and an IG power line 39, which serve as power supply lines. The +B power line 37 is connected to the positive terminal of the vehicle battery 40. The ACC power line 38 is connected to the positive terminal of the vehicle battery 40 via an ACC switch 41. When the user performs an ACC operation, the ACC switch 41 switches from off to on, and the output voltage of the vehicle battery 40 is applied to the ACC power line 38. For example, in a vehicle that requires a key to be inserted into the key slot, ACC operation involves inserting the key into the key slot and turning it from the "OFF" position to the "ACC" position. In a vehicle that requires a push-start button, ACC operation involves pressing the start button once.

[0313] The IG power supply line 39 is connected to the positive terminal of the vehicle battery 40 via the IG switch 42. When the user performs an IG operation, the IG switch 42 switches 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 that requires a key to be inserted into the key slot, the IG operation involves inserting the key into the key slot and turning it from the "off" position to the "on" position. In a vehicle that requires a push-start button, the IG operation involves pressing the start button twice. The negative terminal of the vehicle battery 40 is grounded.

[0314] When both the ACC switch 41 and the IG switch 42 are off, only +B 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 the +B power state. When the ACC switch 41 is on and the IG switch 42 is off, ACC power and +B power are supplied to the vehicle-side system 4. The state in which ACC power and +B power are supplied to the vehicle-side system 4 is referred to as the ACC power state. When both the ACC switch 41 and the IG switch 42 are on, +B power, ACC power, and IG power are supplied to the vehicle-side system 4. The state in which +B power, ACC power, and IG power are supplied to the vehicle-side system 4 is referred to as the IG power state. In addition to the power supply states described above, power supply states that provide power suitable for wireless program updates are also conceivable.

[0315] The activation conditions for the ECU 19 vary depending on the power supply state. ECUs are categorized as +B power system ECUs (activated in the +B power state), ACC system ECUs (activated in the ACC power state), and IG system ECUs (activated in the IG power state). For example, an ECU 19 activated for applications such as vehicle anti-theft is categorized as a +B power system ECU. An ECU 19 activated for non-driving system applications, such as audio, is categorized as an ACC system ECU. An ECU 19 activated for driving system applications, such as engine control, is categorized as an IG system ECU.

[0316] The +B power system ECU is connected to +B power line 37, ACC power line 38, and IG power line 39. In the +B power state, it selects +B power line 37; in the ACC power state, it selects ACC power line 38; and in the IG power state, it selects IG power line 39. The ACC system ECU is connected to ACC power line 38 and IG power line 39. In the ACC power state, it selects ACC power line 38; and in the IG power state, it selects IG power line 39. The IG system ECU is connected to IG power line 39.

[0317] CGW13 causes ECU19, the destination of the start request, to transition from the sleep state to the start state by sending a start request to ECU19 in the sleep state. Furthermore, CGW13 causes ECU19, the destination of the sleep request, to transition from the start state to the sleep state by sending a sleep request to ECU19 in the start state. CGW13 can cause a specific ECU19 to transition to the start state or the sleep state by, for example, varying the waveform of the signal sent to buses 15 to 17. That is, a start request waveform and a sleep request waveform are predetermined for each ECU19. An ECU19 transitions from the sleep state to the start state if it receives a start request waveform that suits it, and from the start state to the sleep state if it receives a sleep request waveform that suits it from CGW13.

[0318] For example, when ECU (ID1) and ECU (ID2) are in the active state, CGW 13 transmits a first waveform to cause ECU (ID1) to transition from the active state to the sleep state, while maintaining ECU (ID2) in the active state. Alternatively, when ECU (ID1) and ECU (ID2) are in the active state, CGW 13 transmits a second waveform to maintain ECU (ID1) in the active state, while causing ECU (ID2) to transition from the active state to the sleep state.

[0319] The power supply control circuit 43 is connected in parallel with the ACC switch 41 and the IG switch 42. The CGW 13 transmits a power supply control request to the power management ECU 20, causing the power management ECU 20 to control the power supply control circuit 43. Specifically, by transmitting a power supply start request to the power management ECU 20 as a power supply control request, the CGW 13 connects the ACC power supply line 38, the IG power supply line 39, and the positive terminal of the vehicle battery 40 within the power supply control circuit 43. In this state, even when the ACC switch 41 and the IG switch 42 are turned off, ACC power and IG power are supplied to the vehicle-side system 4. Furthermore, by transmitting a power supply stop request to the power management ECU 20 as a power supply control request, the CGW 13 disconnects the ACC power supply line 38, the IG power supply line 39, and the positive terminal of the vehicle battery 40 within the power supply control circuit 43.

[0320] The DCM12, CGW13, ECU19, and power management ECU20 each include a power self-holding circuit, providing a power self-holding function for maintaining power from the vehicle battery 40. Specifically, if the vehicle power source switches from ACC power or IG power to +B power while the DCM12, CGW13, ECU19, and power management ECU20 are in the active state, they do not immediately transition from the active state to the stopped state or sleep state following the switch. Instead, they maintain the active state for a predetermined period (e.g., several minutes) using the power source from the vehicle battery 40 to maintain the driving power source. The DCM12, CGW13, ECU19, and power management ECU20 transition from the active state to the stopped state or sleep state after a predetermined period of time has passed since the vehicle power source switched from ACC power or IG power to +B power. For example, in the case of the engine control system ECU19, the power self-holding function activates after the vehicle power source switches from ACC power or IG power to +B power, allowing various engine control-related data acquired during vehicle driving to be stored as a log.

[0321] Next, the distribution data packet distributed from the center device 3 to the main device 11 will be described. Figure 6 As shown, in the vehicle program rewriting system 1, rewriting data is generated based on the write data provided by the supplier as the application provider and the rewriting specification data (equivalent to the specification data) provided by the OEM. The rewriting specification data can also be generated in the center device 3. As the write data provided by the supplier, there are differential data equivalent to the difference between the old application and the new application and all data equivalent to the entire new application. The differential data and the all data can also be compressed using a well-known data compression technology. Figure 6In the example, differential data is provided from suppliers A to C as write data, and recoded data is generated based on the encrypted differential data and authenticator of ECU (ID1) provided by supplier A, the encrypted differential data and authenticator of ECU (ID2) provided by supplier B, the encrypted differential data and authenticator of ECU (ID3) provided by supplier C, and the rewrite specification data provided by the OEM.

[0322] The authenticator is data assigned to each written data to verify the integrity of the differential data. For example, it is generated based on the ECU (ID), the key information associated with the ECU (ID), and the differential data. Here, if the application rewrite is canceled midway, the write data used to write back (roll back) to the old version can also be included in the recompilation data.

[0323] The rewrite specification data provided by the OEM includes information related to application rewrite, such as information that identifies the ECU 19 to be rewritten, information that specifies the rewrite order when there are multiple ECUs 19 to be rewritten, and information that specifies the rollback method (described later). The rewrite specification data defines the rewrite operations performed by the DCM 12, CGW 13, and the ECU 19 to be rewritten. The rewrite specification data is divided into DCM rewrite specification data used by the DCM 12 and CGW rewrite specification data used by the CGW 13.

[0324] like Figure 7 As shown, the rewrite specification data used by DCM includes specification data information and ECU information. The specification data information includes address information and file name. The ECU information includes address information corresponding to the number of rewrite object ECUs 19, which is referenced when sending the update program (write data) of each rewrite object ECU 19 to the CGW 13. Specifically, the ECU information includes at least the ID for identifying the ECU (ECU (ID)), the reference address when obtaining the update program (update program acquisition address), the update program size, the reference address when obtaining the rollback program (rollback program acquisition address), and the rollback program size. The rollback program is a program (write data) used to return the application to the original version when the rewrite of the application is canceled midway.

[0325] like Figure 8As shown, the rewrite specification data used by CGW includes group information, bus load table, battery load, vehicle status during rewriting, and ECU information. In addition to these, the rewrite specification data used by CGW may also include rewrite step information, display scene information, etc. Group information is information indicating the group to which the rewrite object ECU19 belongs and the rewrite order. For example, as the first group of information, it is stipulated that the content of the application program is rewritten in the order of ECU (ID1), ECU (ID2), and ECU (ID3). As the second group of information, it is stipulated that the content of the application program is rewritten in the order of ECU (ID4), ECU (ID5), and ECU (ID6). The bus load table is described later. Figure 100 The table shown will be described in detail later. The battery load is information indicating the lower limit of the remaining battery capacity of the vehicle battery 40 that can be allowed in the vehicle. The vehicle state at the time of rewriting is information indicating the state of the vehicle under which rewriting is performed.

[0326] ECU information is information related to the rewrite object ECU19, and includes at least ECU_ID (equivalent to device identification information), connection bus (equivalent to bus identification information), connection power supply, security access key information, memory type, rewrite method, power self-holding time, rewrite surface information, update program version, update program acquisition address, update program size, rollback program version, rollback program acquisition address, rollback program size, and write data type.

[0327] The connection bus indicates the bus to which ECU19 is connected. The connection power indicates the power line to which ECU19 is connected. The security access key information indicates the key information used for authentication of CGW13 accessing the rewrite object ECU19, including a random value or unique information, a key mode, and a decryption operation mode. The memory type indicates whether the memory mounted on the rewrite object ECU19 is a single-sided separate memory, a single-sided suspended memory (also called a pseudo-double-sided memory), or a double-sided memory. The rewrite method indicates whether it is a rewrite based on power self-retention or a rewrite based on power control. The power self-retention time indicates the time for which the power self-retention continues when the rewrite method is a rewrite based on power self-retention. The rewrite surface information indicates which surface is the operating surface and which surface is the non-operating surface. The operating surface is also called the startup surface, and the non-operating surface is also called the rewrite surface.

[0328] The update program version indicates the update program version. The update program acquisition address indicates the address of the update program. The update program size indicates the data size of the update program. The rollback program version indicates the version of the rollback program. The rollback program acquisition address indicates the address of the rollback program. The rollback program size indicates the data size of the rollback program. The write data type indicates whether the written data is differential data or full data. In addition to this information, the rewrite specification data can also include information uniquely defined by the system.

[0329] Upon receiving the DCM rewrite specification data, the DCM 12 analyzes the data. Once the data is analyzed, the DCM 12 controls the rewrite operations, such as acquiring write data from an address storing an update program for the rewrite target ECU 19 and transmitting the acquired write data to the CGW 13.

[0330] Upon receiving the CGW rewrite specification data, the CGW 13 analyzes the data. Based on the analysis results, the CGW 13 controls rewrite-related operations, such as requesting the DCM 12 to transfer a predetermined amount of an update program to the rewrite target ECU 19 or distributing write data to the rewrite target ECU 19 in a specified order.

[0331] The above-mentioned re-edited data is registered in the file server 8, and the distribution specification data provided by the OEM is also registered. The distribution specification data provided by the OEM is data that defines the actions involved in the display of various screens in the display terminal 5. Figure 9 As shown, the distribution specification data includes language information, display sentences, data package information, image data, display mode, display control program, etc.

[0332] Upon receiving the distribution specification data from the CGW 13, the display terminal 5 analyzes the data and controls the display of various screens based on the analysis results. For example, the display terminal 5 overlays the display text obtained from the distribution specification data on a pre-stored display frame, or executes a display control program obtained from the distribution specification data. Furthermore, the distribution specification data may include other information unique to the system.

[0333] If the file server 8 has registered the re-edited data and the distribution specification data, it encrypts the registered re-edited data and generates a distribution data packet that stores a data packet authenticator for authenticating the data packet, the encrypted re-edited data, and the distribution specification data. The authenticator is data assigned to verify the integrity of the re-edited data and the distribution specification data, and is generated, for example, based on the key information associated with the CGW 13, the re-edited data, and the distribution specification data. If the file server 8 receives a download request for the distribution data packet from the outside, it sends the distribution data packet to the DCM 12. In addition, Figure 6 In the example, the file server 8 generates a distribution data packet storing the renumbered data and the distribution specification data, and sends the renumbered data and the distribution specification data to the DCM 12 simultaneously as a single file. However, the renumbered data and the distribution specification data may be sent to the DCM 12 as separate files. In other words, the file server 8 may first send the distribution specification data to the DCM 12, and then send the renumbered data to the DCM 12. In this case, an authentication code may be assigned to each of the distribution specification data and the renumbered data.

[0334] like Figure 10 As shown, if DCM12 downloads a distribution data package from the file server 8, it uses the data package authenticator stored in the downloaded distribution data package to verify the integrity of the encrypted re-encoded data. If the verification result is positive, DCM12 decrypts the encrypted re-encoded data. If DCM12 decrypts the encrypted re-encoded data, it unpacks the decrypted re-encoded data and extracts it into the encrypted differential data and authenticator, the re-encoded specification data for DCM, and the re-encoded specification data for CGW. Figure 10 In the example, the encrypted differential data and authenticator of ECU (ID1), the encrypted differential data and authenticator of ECU (ID2), the encrypted differential data and authenticator of ECU (ID3), the rewrite specification data for DCM, and the rewrite specification data for CGW are divided and extracted.

[0335] Next, refer to Figures 11 to 22 The flash memory 33d of the ECU 19 will be described. Based on the memory structure, the flash memory 33d of the ECU 19 is categorized into single-sided independent memory (with flash memory on one side), single-sided suspended memory (with flash memory on two pseudo sides), and double-sided memory (with flash memory on two actual sides). Hereinafter, an ECU 19 equipped with a single-sided independent memory will be referred to as a single-sided independent memory ECU, an ECU 19 equipped with a single-sided suspended memory will be referred to as a single-sided suspended memory ECU, and an ECU 19 equipped with a double-sided memory will be referred to as a double-sided memory ECU.

[0336] Single-sided standalone memory has a flash memory surface on one side, so there are no concepts of active and non-active surfaces, and the application cannot be rewritten while it is being executed. On the other hand, single-sided suspend memory and double-sided memory have flash memory surfaces on both sides, so there are concepts of active and non-active surfaces, and the application can be rewritten on the non-active side while the application is being executed. Double-sided memory has flash memory surfaces on two completely separate sides, so the application can be rewritten at any time, such as while the vehicle is in motion. Single-sided suspend memory is a pseudo-partition of single-sided standalone memory, with limited timings for normal reading and writing. Applications cannot be rewritten while the vehicle is in motion, but can be rewritten while the IG power is disconnected.

[0337] In addition, the single-sided standalone memory, single-sided suspend memory, and double-sided memory are available in two types: 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. Reprogramming firmware is firmware used to rewrite application programs.

[0338] The following describes the configuration of each flash memory in sequence.

[0339] (A) Single-sided independent memory

[0340] (A-1) Embedded single-sided memory

[0341] Reference Figure 11 as well as Figure 12 The embedded single-sided independent memory is described below. It includes a differential engine work area, an application area, and a boot program area. The application area contains version information, parameter data, applications, firmware, and a normal vector table. The boot program, progress status point 2, progress status point 1, startup determination information, wireless reprogramming firmware, wired reprogramming firmware, a startup determination program, and a boot vector table are located in the boot program area.

[0342] like Figure 11 As shown, when executing normal operation of application processing such as vehicle control processing and diagnosis processing, the microcomputer 33 executes the startup determination program, searches for the start address by referring to the boot vector table and the normal vector table, and executes the specified address of the application program.

[0343] When executing the rewriting operation of the application program rewriting process, the microcomputer 33 reprograms the firmware wirelessly or wiredly without executing the application program. Figure 12 Indicates the action of rewriting the application using differential data as an update program. Figure 12As shown, microcomputer 33 temporarily stores the application as old data in the difference engine work area. Microcomputer 33 reads the old data temporarily stored in the difference engine work area and, using the difference engine included in the embedded recompiled firmware, restores new data based on the read-out old data and the difference data stored in RAM 33c. Once microcomputer 33 generates new data based on the old data and the difference data, it writes the new data to a specified address in memory, thereby overwriting the application.

[0344] (A-2) Downloadable single-sided storage

[0345] Reference Figure 13 as well as Figure 14 The download type single-sided independent storage is explained. The download type is different from the above embedded type in that wireless reprogramming firmware or wired reprogramming firmware is downloaded from the outside and deleted after the application is rewritten. When updating the application wirelessly, the wireless reprogramming firmware or wired reprogramming firmware is previously stored in the memory. Figure 6 The reprogramming data shown includes wireless reprogramming firmware executed by each ECU 19. The ECU 19 receives the wireless reprogramming firmware for its own ECU from the CGW 13, and stores the received wireless reprogramming firmware for its own ECU in the RAM.

[0346] like Figure 13 As shown, when executing normal operation of application processing such as vehicle control processing and diagnosis processing, the microcomputer 33 executes the startup determination program in the same way as the embedded type, searches for the start address by referring to the boot-time vector table and the normal-time vector table, and executes the specified address of the application program.

[0347] like Figure 14 As shown, when executing the rewrite operation of the application program rewrite process, the microcomputer 33 temporarily stores the application program as old data in the difference engine work area. The microcomputer 33 reads the old data temporarily stored in the difference engine work area and, using the difference engine included in the recompiled firmware downloaded from the outside, restores new data based on the read-out old data and the difference data stored in RAM 33c. Once the microcomputer 33 generates new data based on the old data and the difference data, it writes the new data to rewrite the application program.

[0348] (B) Single-sided suspend memory

[0349] (B-1) Embedded Single-Sided Suspended Memory

[0350] Reference Figure 15 as well as Figure 16The embedded single-sided suspend memory is described. The embedded single-sided suspend memory has a differential engine work area, an application area, and a boot program area. The reprogramming firmware for program updates is configured in the boot program area in the same manner as the single-sided independent memory and is not the target of program updates. The application area, which is the target of program updates, has an A side and a B side in a pseudo manner, and version information, an application, and a normal vector table are configured on the A side and the B side, respectively. The boot program, the reprogramming firmware, the reprogramming vector table, the startup side determination function, the startup side determination information, and the boot vector table are configured in the boot area.

[0351] like Figure 15 As shown, when the microcomputer 33 performs normal actions of application processing such as vehicle control processing and diagnostic processing, it executes the boot program and determines which of the A and B sides is the application side based on the startup side judgment information of each side A and B through the startup side judgment function. If the microcomputer 33 determines that side A is set as the application side, it searches for the starting address with reference to the normal time vector table of side A and executes the application program of side A. Similarly, if the microcomputer 33 determines that side B is set as the application side, it searches for the starting address with reference to the normal time vector table of side B and executes the application program of side B. In addition, Figure 15 In the embodiment, the reprogrammed firmware is arranged in the boot program area, but the reprogrammed firmware may also be an object of program update and arranged in respective areas of the A side or the B side.

[0352] like Figure 16 As shown, when the microcomputer 33 performs the rewriting operation of the application program on the non-operating surface, the application program on the non-operating surface is temporarily saved as old data in the differential engine working area. The microcomputer 33 reads the old data temporarily saved in the differential engine working area, and restores the new data based on the read old data and the differential data stored in the RAM 33c through the differential engine in the embedded recompiled firmware. If the microcomputer 33 generates new data based on the old data and the differential data, it writes the new data to the non-operating surface to rewrite the application program on the non-operating surface. Figure 16 In FIG, a case where surface A is an operating surface and surface B is a non-operating surface is illustrated.

[0353] (B-2) Download type single-sided suspend memory

[0354] Reference Figure 17 as well as Figure 18 The downloadable single-sided suspend memory is described below. The downloadable type differs from the embedded type described above in that the reprogramming firmware and reprogramming vector table are downloaded from the outside and then deleted after the application is rewritten.

[0355] like Figure 17As shown, during normal operation of application processing such as vehicle control and diagnostics, the microcomputer 33 executes a boot program, similar to the embedded type. The startup surface determination function uses the startup surface determination information for each of surfaces A and B to determine which surface is the operational surface. If the microcomputer 33 determines that surface A is the operational surface, it searches for the start address by referring to the normal-time vector table for surface A and executes the application program for surface A. Similarly, if the microcomputer 33 determines that surface B is the operational surface, it searches for the start address by referring to the normal-time vector table for surface B and executes the application program for surface B.

[0356] like Figure 18 As shown, when the microcomputer 33 performs the rewriting operation of the application rewriting process, the non-operating application is temporarily saved as old data in the differential engine working area. The microcomputer 33 reads the old data temporarily saved in the differential engine working area, and restores the new data based on the read old data and the differential data stored in the RAM 33c through the differential engine in the recompiled firmware downloaded from the outside. When the microcomputer 33 generates new data based on the old data and the differential data, it writes the new data to rewrite the application. Figure 18 In the example, the case where side A is the operating side and side B is the non-operating side is shown. In this way, in a single-sided suspend memory, the application program on side A can be executed while the application program on side B is rewritten in the background.

[0357] (C) Double-sided memory

[0358] (C-1) Embedded double-sided memory

[0359] Reference Figure 19 as well as Figure 20 The embedded double-sided memory is described. The embedded single-sided independent memory has an application area and a rewrite program area on side A, an application area and a rewrite program area on side B, and a boot program area. In the boot area, the boot program is configured to be non-rewritable. The boot program includes a boot swap function and a boot-time vector table. Version information, parameter data, application programs, firmware, and a normal-time vector table are configured in each application area. A program for controlling rewrites, reprogramming progress management information 2, reprogramming progress management information 1, startup side determination information, wireless reprogramming firmware, wired reprogramming firmware, and a boot-time vector table are configured in each rewrite program area. The boot area is configured with a boot program, a boot swap function, and a boot-time vector table.

[0360] like Figure 19As shown, the microcomputer 33 executes the boot program both during normal operation of application processing such as vehicle control and diagnostic processing, and during rewriting of non-operational applications. The boot swap function determines the newness and oldness of each side based on the startup side determination information of sides A and B, and determines which side is the operational side. If the microcomputer 33 determines that side A is the operational side, it searches for the starting address by referring to the boot-time vector table and the normal-time vector table of side A, and executes the side A application. Similarly, if the microcomputer 33 determines that side B is the operational side, it searches for the starting address by referring to the boot-time vector table and the normal-time vector table of side B, and executes the side B application.

[0361] like Figure 20 As shown, when the microcomputer 33 performs the rewriting action of the rewriting processing of the application program on the non-operating side, the application program on the non-operating side is temporarily saved as old data in the differential engine working area. The microcomputer 33 reads the old data temporarily saved in the differential engine working area, and restores the new data based on the read old data and the differential data stored in the RAM 33c through the differential engine in the embedded recompilation firmware. If the microcomputer 33 generates new data based on the old data and the differential data, the new data is written to the non-operating side to rewrite the application program on the non-operating side. In addition, the old data temporarily saved in the differential engine working area can take either the application program on the operating side or the application program on the non-operating side as the object. At this time, when the application program on the operating side is taken as the object, the data on the non-operating side is eliminated before the new data is written. Here, when the recompiled data obtained from outside the vehicle is not differential data but all data (full data), the obtained recompiled data is written to the non-operating side as new data. In Figure 20 In the example, side A is the active side and side B is the non-active side. Furthermore, the old data temporarily saved in the Difference Engine work area can target both active and non-active applications. If it is necessary to match the execution addresses of applications, the non-active application can be saved as old data.

[0362] (C-2) Downloadable double-sided memory

[0363] Reference Figure 21 as well as Figure 22 The downloadable double-sided memory is described below. The downloadable type differs from the embedded type in that wireless reprogramming firmware and wired reprogramming firmware are downloaded from the outside, and after the application is rewritten, the wireless reprogramming firmware and wired reprogramming firmware are deleted.

[0364] like Figure 21As shown, when the microcomputer 33 performs normal operations such as vehicle control processing and diagnostic processing, and when performing rewriting operations of rewriting processing of applications on non-operating surfaces, it executes the boot program in the same manner as the embedded type, determines the new and old sides based on the information of each startup surface of surface A and surface B through the boot exchange function, and determines which surface of surface A and surface B is the operating surface, and executes the application on the operating surface to perform application processing.

[0365] like Figure 22 As shown, when the microcomputer 33 performs the rewriting action of the application rewriting process, the application on the non-operating side is temporarily saved as old data in the differential engine working area. The microcomputer 33 reads the old data temporarily saved in the differential engine working area, and restores the new data based on the read old data and the differential data stored in RAM33c through the recompilation firmware downloaded from the outside. If the microcomputer 33 generates new data based on the old data and the differential data, it writes the new data to the non-operating side to rewrite the application on the non-operating side. In addition, the old data temporarily saved in the differential engine working area can take either the application on the operating side or the application on the non-operating side as the object. At this time, when the application on the operating side is taken as the object, the data on the non-operating side is eliminated before the new data is written. Here, when the recompiled data obtained from the outside of the vehicle is not differential data but all data (full data), the obtained recompiled data is written to the non-operating side as new data. In Figure 22 In the example, side A is the active side and side B is the non-active side. Furthermore, the old data temporarily saved in the Difference Engine work area can target both active and non-active applications. This allows applications on side A to be executed in the background while rewriting side B in the dual-sided memory.

[0366] As described above, in either the embedded type or the download type, an application program and a rewriting program for rewriting the application program are arranged in each application area. Figure 20 as well as Figure 22 , an application program is shown as the target for reprogramming, but a rewrite program can also be used as the target for reprogramming. Furthermore, if it is desired that the rewrite program cannot be rewritten, the rewrite program can be placed in the boot area. A program for wired rewriting can also be placed in the boot area so that, for example, rewrite can be reliably performed by wire using the tool 23 at a dealership.

[0367] Next, refer to Figures 23 to 25The overall sequence for rewriting an application will be explained. While this description will focus on the case where a user operates a mobile terminal 6, serving as a display terminal 5, to rewrite an application while the vehicle is parked, the same procedure applies to the case where the user operates the onboard display 7 to rewrite the application while the vehicle is parked. The distribution data packet sent from the center device 3 to the DCM 12 stores write data for one or more rewrite target ECUs 19. Specifically, if there is one rewrite target ECU 19, the distribution data packet stores a single write data item for that single rewrite target ECU 19. If there are multiple rewrite target ECUs 19, the distribution data packet stores multiple write data items for each of the multiple rewrite target ECUs 19. Here, there are two rewrite target ECUs 19, and these two rewrite target ECUs 19 are referred to as rewrite target ECU (ID1) and rewrite target ECU (ID2). ECUs 19 other than rewrite target ECU (ID1) and rewrite target ECU (ID2) are referred to as "other ECUs."

[0368] If each of the rewrite target ECU (ID1) and the rewrite target ECU (ID2) determines that it has received a request to transmit a version notification signal, for example, from the host device 11, it determines that the conditions for transmitting the version notification signal have been met. If the conditions for transmitting the version notification signal have been met, the rewrite target ECU (ID1) transmits a version notification signal containing the version information of its stored application and identifying its own ECU (ID) to the host device 11. If the host device 11 receives the version notification signal from the rewrite target ECU (ID1), it transmits the received version notification signal to the center device 3. Similarly, if the conditions for transmitting the version notification signal have been met, the rewrite target ECU (ID2) transmits a version notification signal containing the version of its stored application and identifying its own ECU (ID) to the host device 11. If the host device 11 receives the version notification signal from the rewrite target ECU (ID2), it transmits the received version notification signal to the center device 3.

[0369] Upon receiving version notification signals from the target ECU (ID 1) and the target ECU (ID 2), the center device 3 identifies the application version and ECU (ID) included in the received version notification signals and determines whether there is write data that should be distributed to the target ECU 19, which was the source of the version notification signal. Based on the version notification signal received from the target ECU, the center device 3 determines the current application version of the target ECU 19 and compares the current application version with the latest version currently being managed.

[0370] If the version determined by the version notification signal is the same as the latest version currently being managed, the center device 3 determines that there is no write data to be distributed to the rewriting target ECU 19, which is the source of the version notification signal, and that there is no need to update the application program stored in the rewriting target ECU 19. On the other hand, if the version determined by the version notification signal is lower than the latest version currently being managed, the center device 3 determines that there is write data to be distributed to the rewriting target ECU 19, which is the source of the version notification signal, and that there is a need to update the application program stored in the rewriting target ECU 19.

[0371] If the center device 3 determines that an application stored in the rewrite target ECU 19 needs to be updated, it notifies the mobile terminal 6 that the update is required. Upon receiving the notification of the update requirement, the mobile terminal 6 displays a distribution permission screen (A1). The distribution permission screen is equivalent to the event notification screen described later. The user can confirm the need for an update on the distribution permission screen displayed on the mobile terminal 6 and choose whether to update.

[0372] When the user selects update (A2) in mobile terminal 6, mobile terminal 6 notifies center device 3 of a distribution package download request.

[0373] When the master device 11 downloads a distribution package from the central device 3, it begins a package authentication process (B1) for the downloaded distribution package. The master device 11 authenticates the distribution package, and upon completion of the package authentication process, it begins a write data extraction process (B2). The master device 11 extracts the write data from the distribution package, and upon completion of the write data extraction process, it transmits a download completion notification signal to the central device 3.

[0374] Upon receiving the download completion notification signal from the host device 11, the center device 3 notifies the mobile terminal 6 of the download completion. Upon receiving the download completion notification from the center device 3, the mobile terminal 6 displays a download completion notification screen (A3). The user can confirm the download completion on the download completion notification screen displayed on the mobile terminal 6 and set the start time for rewriting the vehicle-side application.

[0375] When a user sets a rewrite start time for a vehicle-side application on mobile terminal 6 (A4), mobile terminal 6 notifies center device 3 of the rewrite start time. Upon receiving notification of the rewrite start time from mobile terminal 6, center device 3 stores the user-set rewrite start time as the set start time. When the current time reaches the set start time (A5), center device 3 transmits a rewrite instruction signal to host device 11.

[0376] When the master device 11 receives the rewrite instruction signal from the center device 3, it sends a power start request to the power management ECU 20, causing the rewrite target ECU (ID1), rewrite target ECU (ID2), and other ECUs to transition from the stopped state or sleep state to the started state (X1).

[0377] The master device 11 begins distributing write data to the target ECU (ID1) and instructs the target ECU (ID1) to write the write data. The target ECU (ID1) begins receiving write data from the master device 11. Upon receiving the instruction to write the write data, the target ECU (ID1) begins writing the write data, thereby beginning the program rewrite process (C1). Upon completing the reception of the write data from the master device 11, writing the write data, and completing the program rewrite process, the target ECU (ID1) transmits a rewrite completion notification signal to the master device 11.

[0378] When the master device 11 receives a rewrite completion notification signal from the rewrite target ECU (ID1), it begins distributing write data to the rewrite target ECU (ID2) and instructs the rewrite target ECU (ID2) to write the write data. The rewrite target ECU (ID2) begins receiving write data from the master device 11 and, upon being instructed to write the write data, begins writing the write data, thus beginning the program rewrite process (D1). When the rewrite target ECU (ID2) completes receiving the write data from the master device 11, writing the write data, and completing the program rewrite process, it transmits a rewrite completion notification signal to the master device 11. When the master device 11 receives a rewrite completion notification signal from the rewrite target ECU (ID2), it transmits the rewrite completion notification signal to the center device 3.

[0379] Upon receiving the rewrite completion notification signal from the host device 11, the center device 3 notifies the mobile terminal 6 of the completion of the application rewrite. Upon receiving notification of the application rewrite completion from the center device 3, the mobile terminal 6 displays a rewrite completion notification screen (A6). The user can confirm the completion of the application rewrite on the rewrite completion notification screen displayed on the mobile terminal 6 and can set synchronization execution to active.

[0380] When the user sets synchronization execution (A7) on the mobile terminal 6, that is, when the user agrees to activate the new program, the mobile terminal 6 notifies the center device 3 of the synchronization execution. Upon receiving the synchronization execution notification from the mobile terminal 6, the center device 3 transmits a synchronization switching instruction signal to the main device 11. Upon receiving the synchronization switching instruction signal from the center device 3, the main device 11 distributes the received synchronization switching instruction signal to the rewriting target ECU (ID1) and the rewriting target ECU (ID2).

[0381] Upon receiving a synchronous switching instruction signal from the host device 11, each of the rewriting target ECUs (ID1) and (ID2) begins a program switching process (C2, D2) to switch the next application to be started from the old application to the new application. Upon completing the program switching process, each of the rewriting target ECUs (ID1) and (ID2) transmits a switching completion notification signal to the host device 11.

[0382] Upon receiving a switching completion notification signal from the target ECU (ID1) and the target ECU (ID2), the host device 11 transmits a version readout signal to the target ECU (ID1) and the target ECU (ID2). Upon receiving the version readout signal from the host device 11, the target ECU (ID1) and the target ECU (ID2) read out the version (C3, D3) of the application program to be subsequently used and transmit a latest version notification signal containing the readout version to the host device 11. By receiving the version notification signal from the target ECU (ID1) and the target ECU (ID2), the host device 11 checks the software version and performs a rollback as needed.

[0383] If the main unit 11 receives a version notification signal from the rewrite target ECU (ID1) and the rewrite target ECU (ID2), it sends a power stop request to the power management ECU 20, causing the rewrite target ECU (ID1), the rewrite target ECU (ID2), and other ECUs to move from the start state to the stop state or the sleep state (X2).

[0384] The main device 11 transmits a latest version notification signal to the center device 3. Upon receiving the latest version notification signal from the main device 11, the center device 3 determines the latest version of the application program for the rewrite target ECU (ID1) and the rewrite target ECU (ID2) based on the received latest version notification signal, and notifies the mobile terminal 6 of the determined latest version. Upon receiving the latest version notification from the center device 3, the mobile terminal 6 displays a latest version notification screen (A8) indicating the notified latest version. The user can confirm the latest version on the latest version notification screen displayed on the mobile terminal 6 and confirm that activation has been completed.

[0385] Next, refer to Figures 26 to 29The timing diagrams of the DCM 12, CGW 13, and rewrite target ECU 19 during application rewriting are described. Furthermore, this section describes the cases where an application is rewritten in a dual-side memory ECU while the IG switch 42 is on by a user, that is, while the vehicle is driving, and where an application is rewritten in a single-side suspended memory ECU or a single-side independent memory ECU while the vehicle is parked after the IG switch 42 is turned off by a user. Furthermore, the cases of rewriting an application using power supply control and rewriting an application using power supply self-holding are described.

[0386] (1) Rewriting applications through power control

[0387] Reference Figure 26 as well as Figure 27 The following describes the case of rewriting an application program using power control. Rewriting an application program using power control does not use a self-holding circuit, but rather controls the rewriting operation based on power switching. When the user switches the IG switch from off to on, switching the vehicle power supply from +B power to IG power, the DCM 12, CGW 13, dual-side memory ECU, single-side suspended memory ECU, and single-side dedicated memory ECU each begin normal operation (t1).

[0388] Upon receiving notification of the download start from the center device 3, the DCM 12 shifts from normal operation to download operation and begins downloading the distribution package from the center device 3 (t2). The DCM 12 can download the distribution package in the background while performing normal operation. When the DCM 12 completes downloading the distribution package from the center device 3, it returns to normal operation from the download operation (t3).

[0389] Upon receiving a rewrite instruction signal (installation instruction signal) from the center device 3 or CGW 13, the DCM 12 shifts from normal operation to data transmission / center communication operation and begins data transmission / center communication operation (t4). Specifically, the DCM 12 extracts the write data from the distribution packet, begins transmitting the write data to the CGW 13, obtains the rewrite progress status from the CGW 13, and begins notifying the center device 3 of the rewrite progress status.

[0390] When the CGW 13 begins receiving write data from the DCM 12, it transitions from normal operation to reprogramming master operation, begins distributing write data to the double-sided memory ECU, and instructs it to write the write data. When the double-sided memory ECU begins receiving write data from the CGW 13, the programming phase (hereinafter also referred to as the installation phase) begins during normal operation. Specifically, the double-sided memory ECU installs the application in the background while performing normal operations. The double-sided memory ECU begins writing the received write data to the flash memory, initiating the rewrite of the application.

[0391] During the rewriting of the application in the double-sided memory ECU, if the user switches the IG switch from on to off and the vehicle power is switched from IG power to +B power, DCM12 interrupts the data transmission / center communication action, CGW13 interrupts the reprogramming main action, the double-sided memory ECU interrupts the installation phase, and the rewriting of the application is interrupted (t5).

[0392] Then, when the user switches the IG switch from OFF to ON, switching the vehicle power from +B power to IG power, the DCM 12 resumes data transmission / center communication operations, the CGW 13 resumes the main reprogramming operation, and the dual-side memory ECU resumes the installation phase, restarting application rewriting (t6). Specifically, when the user switches the IG switch from ON to OFF, switching the vehicle power from IG power to +B power, and then when the user switches the IG switch from OFF to ON, switching the vehicle power from +B power to IG power, the dual-side memory ECU repeats interrupting and resuming application rewriting (t7, t8) each time a trip occurs.

[0393] Once the dual-sided memory ECU has completed writing data and rewriting the application, the installation phase ends and the system transitions from normal operation to waiting for activation. Specifically, before the activation phase begins, the dual-sided memory ECU no longer starts the new side (Side B) to which the application has been rewritten, but instead keeps the old side (Side A) running (t9).

[0394] After the user switches the IG switch from on to off, switching the vehicle's power supply from IG to +B (t10), the CGW 13 sends a power-on request to the power management ECU 20 if the dual-side memory ECU completes rewriting the application. Once the CGW 13 sends the power-on request to the power management ECU 20, switching the vehicle's power supply from +B to IG, the DCM 12 resumes data transmission / center communication operations, and the CGW 13 resumes the reprogramming master operation, beginning to distribute write data to the single-side mounted memory ECU and the single-side independent memory ECU. Once the single-side mounted memory ECU and the single-side independent memory ECU each begin receiving write data from the CGW 13, the process transitions from normal operation to the boot process, where the installation phase begins (t11). Specifically, the single-side mounted memory ECU and the single-side independent memory ECU perform installation during the boot process, rather than concurrently with normal operation.

[0395] If a single-sided suspended memory ECU starts rewriting of an application, the rewriting of the application is interrupted if the IG switch 42 is switched from off to on by a user operation before the rewriting of the application is completed. The single-sided suspended memory ECU does not restore the non-operating side (side B) where the rewriting of the application was interrupted, but restores the operating side (side A) as the startup side. If a single-sided independent memory ECU starts rewriting of an application, the rewriting of the application is continued even if the IG switch 42 is switched from off to on by a user operation before the rewriting of the application is completed. This is because for a single-sided independent memory ECU, if the rewriting of the application is interrupted in the middle, it cannot be restored to normal operation. It is preferable to invalidate the IG switch 42 operation performed by the user after the rewriting of the application of the single-sided independent memory ECU is started and before the rewriting of the application is completed.

[0396] When a single-sided suspended memory ECU completes writing data and rewriting the application, the installation phase ends during the boot process and the boot process transitions to the waiting state for activation. Specifically, before the activation phase begins, a single-sided suspended memory ECU no longer boots from the new side (Side B) to which the application has been rewritten, but instead maintains the old side (Side A) for startup. When a single-sided dedicated memory ECU completes writing data and rewriting the application, the installation phase ends during the boot process and the boot process transitions to the waiting state for activation (t12).

[0397] When the power management ECU 20 switches the vehicle's power supply from IG power to +B power in response to an activation instruction from the CGW 13, the dual-side memory ECU and the single-side suspended memory ECU each switch from the old side to the new side, booting up on the new side. The post-programming phase (hereinafter also referred to as the activation phase) begins during the boot-up of the new side. The single-side dedicated memory ECU begins rebooting, and upon rebooting after installation completes, the activation phase begins (t13, t14). During activation, the correct boot-up of the new program is confirmed, and version information is notified to the CGW 13.

[0398] Once activation is complete, the power management ECU 20 switches the vehicle power supply from IG power to +B power in response to an activation completion instruction from the CGW 13. The DCM 12 then transitions from data transmission / center communication mode to sleep / stop mode, initiating sleep / stop mode. The CGW 13 transitions from reprogramming mode to sleep / stop mode, initiating sleep / stop mode. The dual-side memory ECU, single-side suspended memory ECU, and single-side independent memory ECU each transition from new-side activation to sleep / stop mode (t15).

[0399] Afterwards, if the user switches the IG switch from off to on and the vehicle power is switched from +B power to IG power, the double-sided memory ECU and the single-sided suspended memory ECU each use the new side (B side) as the startup side and start a new application, and the single-sided independent memory ECU starts the new application (t16).

[0400] (2) Rewriting the application program by self-holding the power supply

[0401] Reference Figure 28 as well as Figure 29 The following describes the case of rewriting an application program using power self-holding. Rewriting an application program using power self-holding refers to a configuration in which the rewriting operation is controlled by a power self-holding circuit. When the user switches the IG switch from off to on, switching the vehicle power supply from +B power to IG power, the DCM 12, CGW 13, dual-side memory ECU, single-side suspended memory ECU, and single-side dedicated memory ECU each begin normal operation (t21).

[0402] When the DCM 12 receives a notification from the center device 3 that a download has started, that is, when it receives a notification that an update based on a new program has been made, it switches from normal operation to downloading operation and starts downloading the distribution package from the center device 3 (t22). When the DCM 12 completes downloading the distribution package from the center device 3, it returns from downloading operation to normal operation (t23).

[0403] When the DCM 12 receives a rewrite instruction signal (installation instruction signal) from the center device 3 or CGW 13, it switches from normal operation to data transmission / center communication operation and starts the data transmission / center communication operation (t24). Specifically, the DCM 12 extracts the write data from the distribution packet, starts transmitting the write data to the CGW 13, obtains the rewrite progress status from the CGW 13, and starts notifying the center device 3 of the rewrite progress status.

[0404] When the CGW 13 begins receiving write data from the DCM 12, it transitions from normal operation to reprogramming master operation, begins distributing write data to the double-sided memory ECU, and instructs it to write the write data. When the double-sided memory ECU begins receiving write data from the CGW 13, the programming phase (hereinafter also referred to as the installation phase) begins during normal operation. Specifically, the double-sided memory ECU installs the application in the background while performing normal operations. The double-sided memory ECU begins writing the received write data to the flash memory, initiating the rewrite of the application.

[0405] While the dual-side memory ECU is rewriting the application, if the user switches the IG switch from on to off, causing the vehicle power to switch from IG power to +B power (t25), then immediately after the vehicle power switches from IG power to +B power, the DCM 12 continues data transmission and center communication operations, the CGW 13 continues the reprogramming main operation, and the dual-side memory ECU continues the installation phase, continuing the application rewriting. After a predetermined time, or self-holding period, has passed since the vehicle power switched from IG power to +B power, the DCM 12 suspends data transmission and center communication operations, the CGW 13 suspends the reprogramming main operation, and the dual-side memory ECU suspends the installation phase, suspending the application rewriting (t26). Specifically, installation continues using power from the vehicle battery 40 until a predetermined time has passed since the IG switch 42 was turned off.

[0406] Afterward, if the user switches the IG switch from off to on, switching the vehicle power from +B power to IG power, the DCM 12 resumes data transmission / center communication operations, the CGW 13 resumes the reprogramming main operation, and the dual-side memory ECU resumes the installation phase, resuming application rewriting (t27). Specifically, whenever the user switches the IG switch from on to off, switching the vehicle power from IG power to +B power, and then switches the vehicle power from +B power to IG power by switching the IG switch from off to on, the dual-side memory ECU repeatedly interrupts and resumes application rewriting (t28-t30). However, until the self-holding period elapses after the vehicle power switches from IG power to +B power, the DCM 12 continues data transmission / center communication operations, the CGW 13 continues the reprogramming main operation, and the dual-side memory ECU continues the installation phase, continuing application rewriting.

[0407] Once the dual-side memory ECU has completed writing data and rewriting the application, the installation phase ends and the system transitions from normal operation to waiting for activation. Specifically, before the activation phase begins, the dual-side memory ECU no longer activates the new side (Side B) to which the application has been rewritten, but instead maintains the old side (Side A) (t31).

[0408] If the user switches the IG switch from on to off and the vehicle power is switched from IG power to +B power, the application is rewritten in the double-sided memory ECU at this moment, and the single-sided suspended memory ECU and the single-sided independent memory ECU are respectively transferred from normal operation to boot processing, and the boot processing is started, and the installation phase (t32) is started in the boot processing.

[0409] Once the single-side suspended memory ECU and the independent memory ECU have completed writing data and rewriting the application, the installation phase of the boot process ends (t33). When the CGW 13 transmits a power on request to the power management ECU 20 and the vehicle power is switched from +B power to IG power, the DCM 12 resumes data transmission and center communication operations (t34).

[0410] When a single-sided suspended memory ECU completes writing data and rewriting the application, it transitions from the boot process to the waiting phase for activation. Specifically, before the activation phase begins, the single-sided suspended memory ECU no longer boots from the new side (Side B) to which the application has been rewritten, but instead maintains the old side (Side A) for startup. When a single-sided dedicated memory ECU completes writing data and rewriting the application, it ends the installation phase in the boot process and enters the waiting phase for activation (t35).

[0411] When the power management ECU 20 switches the vehicle power supply from IG power to +B power in response to an activation instruction from the CGW 13, the dual-side memory ECU and the single-side suspended memory ECU each switch from the old side to the new side, booting up on the new side, and starting the activation phase during the bootup of the new side. The single-side dedicated memory ECU begins rebooting, and during the reboot after installation is complete, the activation phase begins (t36, t37).

[0412] If activation is complete, the power management ECU 20 switches the vehicle power supply from IG power to +B power in response to an activation completion instruction from the CGW 13. The DCM 12 then transitions from data transmission / center communication mode to sleep / stop mode, initiating sleep / stop mode. The CGW 13 transitions from reprogramming mode to sleep / stop mode, initiating sleep / stop mode. The dual-side memory ECU, single-side suspended memory ECU, and single-side independent memory ECU each transition from new-side activation to sleep / stop mode (t38).

[0413] After this, if the user switches the IG switch from off to on and the vehicle power is switched from +B power to IG power, the double-sided memory ECU and the single-sided suspended memory ECU respectively use the new side (B side) as the startup side and start the new application, and the single-sided independent memory ECU starts the new application (t39).

[0414] Before downloading a distribution package from the center device 3 and distributing it to the target ECU 19 for data writing, the CGW 13 performs the following checks. Before downloading the distribution package from the center device 3, the CGW 13 checks the radio wave environment, the remaining battery level of the vehicle battery 40, and the memory capacity of the DCM 12 to ensure proper downloading. Before distributing the data to the target ECU 19 for data writing, the CGW 13 performs checks for intrusion sensors, vehicle locks, curtains, and disconnected IG (internal galvanic isolation) to prevent instability in the installation environment. Furthermore, to verify that the target ECU 19 is capable of writing, the CGW 13 performs version checks and error detection to ensure proper data distribution. Furthermore, before starting installation, the CGW 13 performs checks for tampering, access authentication, and version checks. During installation, it also performs checks for communication interruptions and error detection. After installation, it performs checks for version, integrity, and DTC (Diagnostic Trouble Code) status.

[0415] Next, refer to Figures 30 to 46 The screen displayed by the display terminal 5 is described. Figure 30 As shown, the configuration for rewriting the application of the target ECU 19 via OTA involves the following stages: activity notification, download, installation, and activation. Activity notification refers to notification of a program update. For example, an activity notification occurs when the center device 3 determines that an application update has occurred and the main device 11 downloads and distributes specification data. The display terminal 5 displays screens at each stage as the application update progresses. Furthermore, the screens displayed on the in-vehicle display 7 are described here.

[0416] like Figure 31 As shown, the CGW 13 displays a navigation screen 501 such as a well-known route guidance screen as one of the navigation functions on the vehicle-mounted display 7 in a normal state before the event notification. Figure 32 As shown, the CGW 13 displays an event notification icon 501a indicating the occurrence of an event notification at the lower right of the navigation screen 501. The user can recognize the occurrence of an event notification related to an application update by confirming the display of the event notification icon 501a.

[0417] If the user operates the activity notification icon 501a from this state, Figure 33As shown, CGW13 causes the activity notification screen 502 to pop up and be displayed on the navigation screen 501. In addition, CGW13 is not limited to causing the activity notification screen 502 to pop up and be displayed, and other display methods may also be used. In the activity notification screen 502, CGW13 notifies the user of the generation of the activity notification by, for example, displaying a guide of "There is a software update that can be used", and displays a "Confirm" button 502a and a "Later" button 502b, waiting for the user's operation. In this case, the user can enter the next screen for starting the rewriting of the application by operating the "Confirm" button 502a. In addition, when the user operates the "Later" button 502b, CGW13 eliminates the pop-up display of the activity notification screen 502 and returns to Figure 32 The screen shown displays the event notification icon 501a.

[0418] If the user operates the "Confirm" button 502a from this state, Figure 34 As shown, the CGW 13 switches the display from the navigation screen 501 to the download consent screen 503, and displays the download consent screen 503 on the in-vehicle display 7. In the download consent screen 503, the CGW 13 notifies the user of the activity ID and update name, and displays a "Start Download" button 503a, a "Confirm Details" button 503b, and a "Back" button 503c, awaiting user input. In this case, the user can start the download by pressing the "Start Download" button 503a, display the download details by pressing the "Confirm Details" button 503b, and reject the download and return to the previous screen by displaying the "Back" button 503c. If the "Back" button 503c is pressed, and the user presses the activity notification icon 501a, the download start screen is displayed.

[0419] If the user operates the "Details Confirmation" button 503b from the state where the download consent screen 503 is displayed, Figure 35 As shown, the CGW 13 switches the display content of the download consent screen 503 so that the download details are displayed on the vehicle-mounted display 7. As the download details, the CGW 13 uses the received distribution specification data to display the update content, the time required for the update, the restrictions on the vehicle functions accompanying the update, etc. In addition, when the user presses the "download start" button 503a, the CGW 13 starts downloading the distribution data package via the DCM 12. In parallel with the start of the download of the distribution data package, as shown in FIG. Figure 36 As shown, the CGW 13 switches the display from the download consent screen 503 to the navigation screen 501, displays the navigation screen 501 again on the in-vehicle display 7, and displays a download-in-progress icon 501b indicating that the download is in progress at the lower right of the navigation screen 501. By confirming the display of the download-in-progress icon 501b, the user can understand that the download of the distribution data package is in progress.

[0420] If the user operates the download execution icon 501b from this state, Figure 37 As shown, the CGW 13 switches the display from the navigation screen 501 to the downloading screen 504, and displays the downloading screen 504 on the in-vehicle display 7. In the downloading screen 504, the CGW 13 notifies the user that the download is in progress and displays a "Confirm Details" button 504a, a "Return" button 504b, and a "Cancel" button 504c, waiting for the user's operation. In this case, the user can display the details of the downloading process by pressing the "Confirm Details" button 504a, and can cancel the download by pressing the "Cancel" button 504c.

[0421] If CGW13 completes the download, Figure 38 As shown, a download completion notification screen 505 is popped up and displayed on the navigation screen 501. On the download completion notification screen 505, the CGW 13 displays a message such as "Download completed. Software update available." to notify the user of the download completion. The CGW 13 also displays a "Confirm" button 505a and a "Later" button 505b, awaiting user input. In this case, the user can access the screen for starting the installation by pressing the "Confirm" button 505a.

[0422] If the user operates the "Confirm" button 505a from this state, Figure 39 As shown, the CGW 13 switches the display from the navigation screen 501 to the installation consent screen 506, which is then displayed on the in-vehicle display 7. In the installation consent screen 506, the CGW 13 notifies the user of the required time, restrictions, and schedule settings for the installation. It also displays an "Update Now" button 506a, a "Schedule Update" button 506b, and a "Back" button 506c, awaiting user input. In this case, the user can start the installation immediately by pressing the "Update Now" button 506a. Alternatively, the user can schedule the installation by setting a desired installation time and pressing the "Schedule Update" button 506b. Furthermore, the user can decline the installation and return to the previous screen by pressing the "Back" button 506c. If the "Back" button 506c is pressed and the user then presses the download-in-progress icon 501b, the user can proceed to the screen for starting the installation.

[0423] If the user operates the "Update Now" button 506a from this state, Figure 40 As shown, the CGW 13 switches the display content of the installation approval screen 506 and displays the details of the installation on the vehicle-mounted display 7. In the installation approval screen 506, the CGW 13 notifies the user that the installation request has been accepted and the installation has started.

[0424] If CGW13 starts to be installed, Figure 41 As shown, the display is switched from the installation consent screen 506 to the navigation screen 501, and the navigation screen 501 is displayed again on the vehicle-mounted display 7, and an installation-in-progress icon 501c indicating that the installation is in progress is displayed at the lower right of the navigation screen 501. The user can recognize that the installation is in progress by confirming the display of the installation-in-progress icon 501c.

[0425] If the user operates the installation execution icon 501c from this state, Figure 42 As shown, the CGW 13 switches the display from the navigation screen 501 to the installation execution screen 507, and displays the installation execution screen 507 on the vehicle-mounted display 7. The CGW 13 notifies the user that the installation is in progress on the installation execution screen 507. The CGW 13 may also display, for example, the remaining time required for installation and the progress percentage on the installation execution screen 507.

[0426] If CGW13 is installed, Figure 43 As shown, the display is switched from the navigation screen 501 to the activation consent screen 508, and the activation consent screen 508 is displayed on the vehicle-mounted display 7. In the activation consent screen 508, the CGW 13 notifies the user of the details of the activation, and displays a "Back" button 508a and an "OK" button 508b, waiting for the user's operation. In this case, the user can refuse the activation and return to the previous screen by operating the "Back" button 508a. Alternatively, the user can agree to the activation by operating the "OK" button 508b. In addition, if the "Back" button 508a is operated, the user can enter the screen for executing the activation by operating the installation execution icon 501c. In addition, these displays and consents can also be omitted according to the user's settings or the program scenario.

[0427] If the user turns on the IG power supply after the user operates the "OK" button 508b, Figure 44 As shown, the CGW 13 displays an activation completion notification screen 509 as a pop-up on the navigation screen 501. On the activation completion notification screen 509, the CGW 13 displays, for example, a message stating "Software Update Completed" to notify the user of the activation completion. The CGW 13 also displays an "OK" button 509a and a "Details Confirmation" button 509b, awaiting user input. In this case, the user can dismiss the pop-up display of the activation completion notification screen 509 by pressing the "OK" button 509a, and display the details of the activation completion by pressing the "Details Confirmation" button 509b.

[0428] If the user operates the "OK" button 509a from this state, Figure 45As shown, the CGW 13 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. On the confirmation operation screen 510, the CGW 13 notifies the user of the completion of activation and displays a "Details Confirmation" button 510a and an "OK" button 510b, waiting for the user's operation. In this case, the user can display the details of the activation completion by pressing the "Details Confirmation" button 510a.

[0429] If the user operates the "Details Confirmation" button 510a from this state, Figure 46 As shown, the CGW 13 switches the display content of the confirmation operation screen 510, displaying the details of activation completion on the in-vehicle display 7. The CGW 13 displays the functions added and changed by the update as update details, and displays an "OK" button 510b. The CGW 13 determines that the user has confirmed the completion of the software update based on the user pressing the "OK" buttons 509a and 510b.

[0430] As described above, the vehicle-side system 4 controls each operational phase, such as event notification, download, installation, activation, and update completion, and presents the user with a display corresponding to each operational phase. Furthermore, while the CGW 13 controls the display in the above description, the onboard display 7 may also receive the operational phase from the CGW 13, distribute the specification data, and display it.

[0431] Next, refer to Figures 47 to 233 The characteristic processing performed by the vehicle program rewriting system 1 will be described. The vehicle program rewriting system 1 performs the characteristic processing described below.

[0432] (1) Distribution packet transmission decision processing

[0433] (2) Download determination process for distribution data packages

[0434] (3) Transfer determination processing of write data

[0435] (4) Write data acquisition and determination processing

[0436] (5) Installation instruction determination process

[0437] (6) Management of secure access keys

[0438] (7) Verification of written data

[0439] (8) Data storage information transmission control processing

[0440] (9) Power management processing for non-rewrite objects

[0441] (10) File transfer control processing

[0442] (11) Distribution control processing of write data

[0443] (12) Activation request instruction processing

[0444] (13) Activated execution control processing

[0445] (14) Group management processing of rewriting objects

[0446] (15) Rollback execution control processing

[0447] (16) Rewriting progress status display control processing

[0448] (17) Matching determination of differential data

[0449] (18) Rewritten execution control processing

[0450] (19) Session establishment process

[0451] (20) Determination and processing of retesting

[0452] (21) Synchronous control processing of progress status

[0453] (22) Display control information transmission control processing

[0454] (23) Receiving and controlling the display control information

[0455] (24) Screen display control processing for progress display

[0456] (25) Report control processing for program updates

[0457] (26) Execution control processing of power supply self-holding

[0458] The center device 3 , DCM 12 , CGW 13 , ECU 19 , and on-vehicle display 7 each include the following functional blocks as a configuration for performing the characteristic processing ( 1 ) to ( 26 ) described above.

[0459] like Figure 47As shown, the center device 3 includes a distribution packet transmitter 51. Upon receiving a distribution packet download request from the DCM 12, the distribution packet transmitter 51 transmits the distribution packet to the DCM 12. In addition to the aforementioned components, the center device 3 also includes a distribution packet transmission determination unit 52, a progress status synchronization control unit 53, a display control information transmission control unit 54, and a write data selection unit 55 (equivalent to an update data selection unit) as components that perform characteristic processing. Upon receiving data storage surface information from the host device 11, the write data selection unit 55 (equivalent to an update data selection unit) selects write data suitable for the non-operational surface based on the software version and operation surface determined from the received data storage surface information. Specifically, the distribution packet transmitter 51 transmits a distribution packet containing the write data selected by the write data selection unit 55 to the DCM 12. The functional modules that perform characteristic processing will be described later.

[0460] like Figure 48 As shown, the DCM 12 includes a download request transmitter 61, a distribution package downloader 62, a write data extractor 63, a write data transmitter 64, a rewrite specification data extractor 65, and a rewrite specification data transmitter 66. The download request transmitter 61 transmits a download request for a distribution package to the center device 3. The distribution package downloader 62 downloads the distribution package from the center device 3. Once the distribution package is downloaded from the center device 3 by the distribution package downloader 62, the write data extractor 63 extracts the write data from the downloaded distribution package.

[0461] When the write data extraction unit 63 extracts write data from the distribution packet, the write data transmission unit 64 transmits the extracted write data to the CGW 13. When the distribution packet download unit 62 downloads the distribution packet from the center device 3, the rewrite specification data extraction unit 65 extracts rewrite specification data from the downloaded distribution packet. When the rewrite specification data extraction unit 56 extracts rewrite specification data from the distribution packet, the rewrite specification data transmission unit 66 transmits the extracted rewrite specification data to the CGW 13. In addition to the above-mentioned components, the DCM 12 further includes a distribution packet download determination unit 67 and a write data transmission determination unit 68 as components that perform characteristic processing. The functional modules that perform characteristic processing will be described later.

[0462] like Figure 49 as well as Figure 50As shown, the CGW 13 includes an acquisition request sending unit 71, a write data acquisition unit 72 (equivalent to an update data storage unit), a write data distribution unit 73 (equivalent to an update data distribution unit), a rewrite specification data acquisition unit 74, and a rewrite specification data analysis unit 75. The write data acquisition unit 72 acquires the write data from the DCM 12 when the write data is transmitted from the DCM 12. Once the write data is acquired by the write data acquisition unit 72, the write data distribution unit 73 distributes the acquired write data to the rewrite target ECU 19 when the distribution timing of the write data arrives. The rewrite specification data acquisition unit 74 acquires the rewrite specification data from the DCM 12 when the rewrite specification data is transmitted from the DCM 12. Once the rewrite specification data is acquired by the rewrite specification data acquisition unit 74, the rewrite specification data analysis unit 75 analyzes the acquired rewrite specification data.

[0463] In addition to the above-mentioned components, the CGW 13 also includes a write data acquisition determination unit 76, an installation instruction determination unit 77, a secure access key management unit 78, a write data verification unit 79, a data storage surface information transmission control unit 80, a non-rewrite target power management unit 81, a file transfer control unit 82, a write data distribution control unit 83, an activation request instruction unit 84, a rewrite target group management unit 85, a rollback execution control unit 86, a rewrite progress status display control unit 87, a progress status 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, and a power self-sustaining execution control unit 92 as components performing characteristic processing. The functional modules performing characteristic processing will be described later.

[0464] like Figure 51 As shown, the ECU 19 includes a write data receiving unit 101 and a program rewriting unit 102. The write data receiving unit 101 receives write data from the CGW 13. If the write data receiving unit 101 receives write data from the CGW 13, the program rewriting unit 102 writes the received write data into the flash memory to rewrite the application program. In addition to the above-mentioned components, as a structure for performing characteristic processing, the ECU 19 further includes a differential data matching determination unit 103, a rewriting execution control unit 104, a session establishment unit 105, a retry point determination unit 106, an activation execution control unit 107, and a power self-maintaining execution control unit 108. The functional modules for performing characteristic processing will be described later.

[0465] like Figure 52 As shown, the in-vehicle display 7 includes a distribution specification data reception control unit 111. The distribution specification data reception control unit 111 controls reception of the distribution specification data.

[0466] Hereinafter, each of the above-mentioned processes (1) to (26) will be described in sequence.

[0467] (1) Distribution package transmission determination processing, (2) Distribution package download determination processing

[0468] Reference Figure 53 as well as Figure 54 The following describes the distribution packet transmission determination processing in the center device 3. Figure 55 as well as Figure 56 The download determination process of the distribution package in the host device 11 will be described.

[0469] like Figure 53 As shown, the center device 3 includes a software information acquisition unit 52a, an update presence determination unit 52b, an update suitability determination unit 52c, and an activity information transmission unit 52d within the distribution data packet transmission determination unit 52. The software information acquisition unit 52a acquires software information for each ECU 19 from the vehicle. Specifically, the software information acquisition unit 52a acquires ECU configuration information from the vehicle, including software information such as the version and write surface, and hardware information. The software information acquisition unit 52a may also acquire vehicle status information such as fault codes, anti-theft alarm function settings, and license agreement information, along with this ECU configuration information.

[0470] After the software information acquisition unit 52a acquires the software information, the update determination unit 52b determines whether updated data for the vehicle exists based on the acquired software information. Specifically, the update determination unit 52b compares the acquired software information version with the latest software information version managed by the unit to determine whether the two match, thereby determining whether updated data for the vehicle exists. If the update determination unit 52b determines that the two match, it determines that updated data for the vehicle does not exist. If the two do not match, it determines that updated data for the vehicle exists.

[0471] If the update presence determination unit 52b determines that update data for the vehicle is available, the update suitability determination unit 52c determines whether the vehicle is in a state suitable for an update such as a program using the distribution package. Specifically, the update suitability determination unit 52c determines whether a license agreement has been established, whether the vehicle's location is within a specified range pre-registered by the user, whether the vehicle's alarm function settings are enabled, and whether ECU 19 has generated fault information, thereby determining whether the vehicle is in a state suitable for downloading the distribution package. In other words, the update suitability determination unit 52c determines whether the vehicle is likely to be updated against the user's intent, or whether the vehicle is likely to fail during installation after downloading, even if the download is successful.

[0472] If the update suitability determination unit 52c determines that the license agreement is established, the vehicle position is within the specified range pre-registered by the user, the vehicle alarm function setting is enabled, and no ECU 19 failure information has occurred, the vehicle state is determined to be suitable for updating the program, etc. using the distribution package. If the update suitability determination unit 52c determines that at least one of the following is not established, the vehicle position is not within the specified range pre-registered by the user, the vehicle alarm function setting is not enabled, and ECU 19 failure information has occurred, the vehicle state is determined to be not suitable for updating the program, etc. using the distribution package.

[0473] If the update suitability determination unit 52c determines that the vehicle state is suitable for updating the program, etc., using the distribution package, the event information transmission unit 52d transmits the event information to the host device 11. If the update suitability determination unit 52c determines that the vehicle state is not suitable for updating the program, etc., using the distribution package, the event information transmission unit 52d does not transmit the event information to the host device 11. By making the above determination, the event information transmission unit 52d pre-stores information related to vehicles for which event information has not been transmitted to the host device 11. Furthermore, information related to vehicles for which event information has not been transmitted to the host device 11 may be displayed on the center device 3.

[0474] Next, refer to Figure 54 The following describes the role of the distribution packet transmission determination unit 52 in the center device 3. The center device 3 executes a distribution packet transmission determination program to perform distribution packet transmission determination processing.

[0475] When the center device 3 begins the distribution packet transmission determination process, it acquires software information from the vehicle (S101, equivalent to a software information acquisition step). Specifically, the center device 3 determines whether a software update for the vehicle is available. Based on the acquired software information, the center device 3 determines whether update data for the vehicle is available (S102, equivalent to an update availability determination step). If the center device 3 determines that update data for the vehicle is available (S102: Yes), it determines whether the vehicle is in a state suitable for updating the program, etc., using the distribution packet (S103, equivalent to an update availability determination step). If the center device 3 determines that the vehicle is in a state suitable for updating the program, etc., using the distribution packet (S103: Yes), it transmits activity information to the host device 11 (S104, equivalent to an activity information transmission step), thereby terminating the distribution packet transmission determination process.

[0476] If the center device 3 determines that there is no update data for the vehicle (S102: No), it transmits to the main device 11 a notice that the distribution package is not intended for distribution, that is, that no application program has been updated (S105), terminating the distribution package transmission determination process. If the center device 3 determines that the vehicle is not in a state suitable for updating the program, etc., using the distribution package (S103: No), it transmits to the main device 11 a notice that the program, etc. is not suitable for updating and the reason for this to the main device 11 (S106), terminating the distribution package transmission determination process. In this case, the main device 11 displays the notice that the program, etc. is not suitable for updating and the reason for this on the in-vehicle display 7. For example, if the license agreement is not established, the main device 11 displays a message such as "Unable to update the program due to invalid license. Please consult your dealer." This allows the user to be informed of the reason why the program, etc. is not suitable for updating, allowing for appropriate information to be provided.

[0477] As described above, the center device 3 performs a distribution packet transmission determination process before transmitting the distribution packet to the host device 11 and before transmitting the activity information. This allows the center device 3 to determine whether the state is suitable for updating the program, etc., which uses the distribution packet. Furthermore, the center device 3 can transmit the activity information to the host device 11 in order to transmit the distribution packet to the host device 11 only when it is determined that the state is suitable for updating the program, etc., which uses the distribution packet.

[0478] In the case of an update for a program or the like suitable for use with a distribution package, the center device 3 can transmit action information to the host device 11 if a license agreement is established, the vehicle's location is within a specified range pre-registered by the user, the vehicle's alarm function is enabled, and no ECU 19 failure information has been generated. Specifically, the center device 3 can avoid transmitting action information to the host device 11 if a license agreement is not established, the vehicle's location is outside a specified range, such as far from home, the vehicle's alarm function is disabled, or ECU 19 failure information has been generated. This prevents the center device 3 from transmitting action information to the host device 11 for vehicles where an update might be unintended by the user, or where even if the download is successful, the installation might fail.

[0479] Furthermore, the center device 3 may also perform a distribution packet transmission determination process during the transmission of the distribution packet. In this case, if the center device 3 determines that the vehicle state is suitable for updating the program, etc., using the distribution packet, during the transmission of the distribution packet, the distribution packet will continue to be transmitted. However, if the center device 3 determines that the vehicle state is not suitable for updating the program, etc., using the distribution packet, the distribution packet will be interrupted. In other words, if, for example, failure information of the ECU 19 is generated during the transmission of the distribution packet, the center device 3 will interrupt the transmission of the distribution packet.

[0480] Next, the processing of the host device 11 that receives the event information transmitted from the center device 3 will be described. Figure 55 as well as Figure 56 The following describes the download determination process for the distribution packet in the master device 11. The vehicle program rewriting system 1 performs the download determination process for the distribution packet in the master device 11. While the aforementioned (1) distribution packet transmission determination process is performed by the center device 3 during the activity notification phase prior to the download phase, the download determination process for the distribution packet is performed by the master device 11 during the download phase. While this embodiment describes the case where the DCM 12 in the master device 11 performs the download determination process for the distribution packet, the CGW 13 may also have the functionality of the DCM 12, thereby performing the download determination process for the distribution packet.

[0481] like Figure 55 As shown in FIG. 1 , the DCM 12 includes an event information receiving unit 67a, a downloadable determination unit 67b, and a download execution unit 67c in the download determination unit 67 of the distribution data package. The event information receiving unit 67a receives event information from the center device 3. In addition, if event information is received from the center device 3, the event information is displayed. Figure 32 Event notification icon 501a is shown. When event information receiving unit 67a receives event information, downloadability determination unit 67b determines whether the vehicle is in a state where the distribution data package can be downloaded. Specifically, downloadability determination unit 67b determines whether the radio wave environment for communication with center device 3 is good, whether the remaining battery level of vehicle battery 40 is at least a predetermined capacity, and whether the available memory capacity of DCM 12 is at least a predetermined capacity, thereby determining whether the vehicle is in a state where the distribution data package can be downloaded.

[0482] If the downloadability determination unit 67b determines that the radio wave environment is good, the remaining battery level of the vehicle battery 40 is at least a predetermined capacity, and the available memory capacity of the DCM 12 is at least a predetermined capacity, the vehicle is determined to be in a state where the distribution data package can be downloaded. If the downloadability determination unit 67b determines that at least one of the following is not true, the remaining battery level of the vehicle battery 40 is not at least a predetermined capacity, and the available memory capacity of the DCM 12 is not at least a predetermined capacity, the vehicle is determined to be in a state where the distribution data package cannot be downloaded.

[0483] In this way, the downloadable determination unit 67b determines whether there is a possibility that the download cannot be completed normally. Figure 34 as well as Figure 35 The downloadability determination unit 67b makes a determination based on the user pressing the "Start Download" button 503a on the download consent screen 503 shown. Alternatively, the downloadability determination unit 67b may also determine a determination item in the center device 3. Specifically, the downloadability determination unit 67b determines that the download is possible if, for example, the vehicle alarm function is enabled or if no ECU 19 failure information is generated.

[0484] If 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 device 3. That is, the download execution unit 67c executes the download of the distribution package after confirming that the download can be completed normally.

[0485] If the downloadability determination unit 67b determines that the vehicle is not in a state where the distribution package can be downloaded, the download execution unit 67c does not download the distribution package from the center device 3. Specifically, the download execution unit 67c does not download the distribution package if there is a possibility that the download will not be completed normally. In this case, the download execution unit 67c instructs the onboard display 7 to display a pop-up screen on the navigation screen 501 indicating that the download cannot be started and the reason for the failure.

[0486] Next, refer to Figure 56 The following describes the operation of the distribution package download determination unit 67 in the host device 11. The host device 11 executes a distribution package download determination program to perform a distribution package download determination process.

[0487] When the master device 11 begins the distribution package download determination process, it receives event information from the center device 3 (S201, equivalent to an event information receiving step). The master device 11 determines whether the vehicle state is a state in which the distribution package can be downloaded (S202, equivalent to a downloadable determination step). If the master device 11 determines that the vehicle state is a state in which the distribution package can be downloaded (S202: Yes), the master device 11 downloads the distribution package corresponding to the event from the center device 3 (S203, equivalent to a download execution step), terminating the distribution package download determination process. If the master device 11 determines that the vehicle state is not a state in which the distribution package can be downloaded (S202: No), the master device 11 does not download the distribution package from the center device 3, terminating the distribution package download determination process.

[0488] As described above, the host device 11 can determine whether the vehicle is in a state where the distribution package can be downloaded by performing a distribution package download determination process before downloading the distribution package from the center device 3. Furthermore, the host device 11 can download the distribution package only when the vehicle is in a state where the distribution package can be downloaded.

[0489] In a case suitable for downloading a distribution package, the host device 11 can download the distribution package from the center device 3 when the radio wave environment is good, the remaining battery level of the vehicle battery 40 is at least a predetermined level, and the available memory capacity of the DCM 12 is at least a predetermined level. In other words, it is possible to avoid a situation where the distribution package is downloaded from the center device 3 when the radio wave environment is poor, the remaining battery level of the vehicle battery 40 is less than a predetermined level, or the available memory capacity of the DCM 12 is less than a predetermined level.

[0490] Furthermore, the host device 11 may also perform a distribution package download determination process during the distribution package download. In this case, if the host device 11 determines that the vehicle is in a state capable of downloading the distribution package, it will continue downloading the distribution package from the center device 3. However, if the host device 11 determines that the vehicle is not in a state capable of downloading the distribution package, it will interrupt the download of the distribution package from the center device 3. Specifically, if, for example, the radio wave environment is poor, the remaining battery capacity of the vehicle battery 40 is less than a specified capacity, or the available memory capacity of the DCM 12 is less than a specified capacity during the distribution package download, the host device 11 will interrupt the download of the distribution package.

[0491] In this way, by determining in the center device 3 whether a vehicle may receive an update that is not intended by the user or a vehicle in which installation may fail, and determining in the main device 11 whether a download may fail, it is possible to suppress the transmission of useless activity information or distribution data packets from the center device 3 to the main device 11.

[0492] The center device 3 has the following configuration: a software information acquisition unit 52a for acquiring software information of an electronic control unit from the vehicle; an update availability determination unit 52b for determining the presence of update data for the vehicle based on the software information acquired by the software information acquisition unit; an update suitability determination unit 52c for determining whether the vehicle is suitable for an update if the update availability determination unit determines that update data is available; and an activity information transmission unit 52d for transmitting activity information related to the update to the vehicle master device if the update suitability determination unit determines that the vehicle is suitable for an update.

[0493] The main device 11 has the following configuration: an event information receiving unit 67a for receiving event information from a central device; a downloadability determination unit 67b for determining whether the vehicle is in a state where the distribution package can be downloaded, upon receipt of the event information by the event information receiving unit; and a download execution unit 67c for downloading the distribution package from the central device, upon determination by the downloadability determination unit that the vehicle is in a state where the distribution package can be downloaded.

[0494] (3) Write data transmission determination process, (4) Write data acquisition determination process, (5) Installation instruction determination process

[0495] Reference Figure 57 as well as Figure 58 For an explanation of the write data transfer determination process, refer to Figure 59 as well as Figure 60 For an explanation of the write data acquisition and determination process, refer to Figures 61 to 64 The vehicle program rewriting system 1 performs a write data transmission determination process in the DCM 12. Here, it is assumed that the distribution packet sent from the center device 3 to the DCM 12 is depacketized and the write data is extracted from the distribution packet.

[0496] like Figure 57As shown, the DCM 12 includes an acquisition request receiving unit 68a and a communication status determining unit 68b in the write data transmission determination unit 68. The acquisition request receiving unit 68a receives a write data acquisition request from the CGW 13. Upon receiving the write data acquisition request by the acquisition request receiving unit 68a, the communication status determining unit 68b determines the status of data communication between the center device 3 and the DCM 12, for example, if a user-preset transmission availability determination flag is at a first predetermined value. The transmission availability determination flag is 1 (first predetermined value) when a predetermined condition is checked during installation, and is 0 (second predetermined value) when the check is omitted. The write data transmission unit 64 transmits the write data to the CGW 13 based on a determination by the communication status determining unit 68b that data communication between the center device 3 and the DCM 12 is connected.

[0497] Next, refer to Figure 58 The function of the write data transmission determination unit 68 in the DCM 12 will be described. The DCM 12 executes a write data transmission determination program to perform write data transmission determination processing. Here, the processing when the CGW 13 requests the DCM 12 to obtain write data in response to an installation instruction from the center device 3 will be described.

[0498] If the DCM 12 determines that it has received a write data acquisition request from the CGW 13, it begins a write data transmission determination process. If the DCM 12 begins the write data transmission determination process, it determines the transmission availability determination flag (S301, S302). If the DCM 12 determines that the transmission availability determination flag is a first predetermined value (S301: Yes), it determines the state of data communication between the central device 3 and itself (S303). If the DCM 12 determines that data communication between the central device 3 and itself is connected (S303: Yes), it transmits the write data to the CGW 13 (S304), terminating the write data transmission determination process. If the DCM 12 determines that data communication between the central device 3 and itself is not connected but is interrupted (S303: No), it does not transmit the write data to the CGW 13, terminating the write data transmission determination process.

[0499] If the DCM 12 determines that the transfer determination flag is the second predetermined value ( S302 : YES), it transfers the write data to the CGW 13 without determining the state of data communication between the center device 3 and itself, and ends the write data transfer determination process.

[0500] As described above, the DCM 12 performs a write data transmission determination process before transmitting write data to the CGW 13. This determines the status of data communication between the center device 3 and itself when the transmission availability determination flag is at the first predetermined value. If the DCM 12 determines that data communication is connected, it begins transmitting write data. If it determines that data communication is interrupted, it waits without starting write data transmission. If data communication with the center device 3 is established, the write data can be transmitted to the CGW 13 and installed in the target ECU 19.

[0501] For example, if there are multiple ECUs 19 to be rewritten and installation takes time, the progress of the installation can be notified from the vehicle-mounted system 4 to the center device 3, and the progress can be displayed one by one on the mobile terminal 6. Furthermore, the DCM 12 can also perform a write data transmission determination process during write data transmission. In this case, if the DCM 12 determines that data communication is connected during write data transmission, the write data transmission continues. However, if the DCM 12 determines that data communication is interrupted during write data transmission, the write data transmission is interrupted.

[0502] Next, the write data acquisition and determination process will be described. Vehicle program rewriting system 1 performs the write data acquisition and determination process in CGW 13. The write data transmission determination process (3) described above is performed by DCM 12 during the installation phase, while the write data acquisition and determination process is performed by CGW 13 during the same installation phase.

[0503] like Figure 59 As shown, CGW13 has an event generation determination unit 76a and a communication status determination unit 76b in the acquisition determination unit 76 for write data. The event generation determination unit 76a determines the generation of an event of an acquisition request for write data (installation instruction) from the center device 3. If the event generation determination unit 76a determines that an event of an acquisition request for write data has occurred, the communication status determination unit 76b determines the state of data communication between the center device 3 and the DCM12, for example, when the acquisition feasibility determination flag pre-set by the user is a first specified value. The acquisition feasibility determination flag is, for example, 1 (first specified value) when the specified conditions are checked during installation, and 0 (second specified value) when the check is omitted. Here, the event generation determination unit 76a can also determine the generation of an event based on the user's indication of installation, for example, if the user's indication operation for installation is accepted through the vehicle-mounted display 7 (refer to Figure 39 ) is notified, it is determined to be an event that generates a request to obtain write data.

[0504] Next, refer to Figure 60The following describes the role of the write data acquisition determination unit 76 in the CGW 13. The CGW 13 executes a write data acquisition determination program to perform write data acquisition determination processing.

[0505] If the CGW 13 determines that an event for a write data acquisition request has occurred, it begins a write data acquisition determination process. Once the write data acquisition determination process begins, the CGW 13 determines the acquisition permission determination flag (S401, S402). If the CGW 13 determines that the acquisition permission determination flag is at the first predetermined value (S401: Yes), it determines the state of data communication between the center device 3 and the DCM 12 (S403). If the CGW 13 determines that data communication between the center device 3 and the DCM 12 is connected (S403: Yes), it transmits a write data acquisition request to the DCM 12 (S404), terminating the write data acquisition determination process. Thereafter, if write data is transmitted from the DCM 12, the CGW 13 distributes the transmitted write data to the rewrite target ECU 19. If the CGW 13 determines that data communication between the center device 3 and the DCM 12 is disconnected rather than connected (S403: No), it does not transmit a write data acquisition request to the DCM 12, terminating the write data acquisition determination process.

[0506] If the CGW 13 determines that the acquisition possibility determination flag is the second predetermined value ( S402 : YES), it transmits a write data acquisition request to the DCM 12 without determining the state of data communication between the center device 3 and the DCM 12 , and ends the write data acquisition determination process.

[0507] As described above, the CGW 13 performs write data acquisition determination processing before acquiring write data from the DCM 12. This determines the data communication status between the center device 3 and the DCM 12 when the acquisition determination flag is at the first predetermined value. If the CGW 13 determines that data communication is connected, it begins acquiring write data. If it determines that data communication is disconnected, it waits without starting write data acquisition. If communication with the center device 3 is established, write data can be acquired from the DCM 12 and installed in the target ECU 19.

[0508] For example, if there are multiple ECUs 19 to be rewritten and installation takes time, the progress of the installation can be notified from the vehicle-mounted system 4 to the center device 3, and the progress can be displayed one by one on the mobile terminal 6. Furthermore, the CGW 13 can also perform a write data acquisition determination process during write data acquisition. In this case, if data communication is determined to be connected during write data acquisition, the CGW 13 continues to acquire the write data. However, if data communication is determined to be interrupted during write data acquisition, the CGW 13 interrupts the write data acquisition.

[0509] Next, the acquisition and determination of the above-mentioned write data will be described in more detail. The acquisition of write data is one of the processes related to installation. Figures 61 to 64 The following describes the installation instruction determination process. The vehicle program rewriting system 1 performs the installation instruction determination process in the CGW 13. The above-mentioned (1) distribution data packet transmission determination process and (2) distribution data packet download determination process are determination processes performed in the download phase, (3) write data transmission determination process and (4) write data acquisition determination process are processes performed in the installation phase after the download is completed, and (5) installation instruction determination process is a process performed in the installation phase and the activation phase. Here, it is assumed that the distribution data packet is downloaded to the DCM 12, and as Figure 10 As shown, the write data (update data, difference data) to the write target ECU 19 is in an unpacked state.

[0510] like Figure 61 As shown, the CGW 13 includes an installation condition determination unit 77a, an installation instruction unit 77b, a vehicle state information acquisition unit 77c, an activation condition determination unit 77d, and an activation instruction unit 77e in the installation instruction determination unit 77. The installation condition determination unit 77a determines whether the first condition, the second condition, the third condition, the fourth condition, and the fifth condition are satisfied. The first condition is a condition that the user consent related to the installation is obtained. The user consent related to the installation is indicated, for example, in Figure 39 The user's consent operation for installation in the screen shown (for example, pressing the "Update Now" button 506a) is shown. Alternatively, the process from downloading to activation can be considered as one update, which is the user's consent operation for the update.

[0511] The second condition is that the CGW 13 can communicate data with the center device 3. The third condition is that the vehicle is in a state suitable for installation. The fourth condition is that the target ECU 19 is suitable for installation. This fourth condition includes not only the ability to install the target ECU 19, but also the ability to install any target ECU 19 that collaborates with the target ECU 19. The fifth condition is that the data to be written is normal data. Normal data includes data suitable for the target ECU 19 and data that has not been tampered with.

[0512] If the installation condition determination unit 77a determines that all of the first, second, third, fourth, and fifth conditions are met, the installation instructing unit 77b instructs the target ECU 19 to install the application. Specifically, if the installation condition determination unit 77a determines that user consent for installation has been obtained, data communication between the CGW 13 and the center device 3 is possible, the vehicle is in a state where installation is possible, the target ECU 19 is in a state where installation is possible, and the written data is normal, the installation instructing unit 77b instructs the target ECU 19 to install the application. Specifically, the installation instructing unit 77b obtains the write data from the DCM 12 and transmits the obtained write data to the target ECU 19. If the installation condition determination unit 77a determines that at least one of the first, second, third, fourth, and fifth conditions is not met, the installation instructing unit 77b waits without instructing the target ECU 19 to install the application, or notifies the user that installation cannot begin and the reason for the inability to start the installation.

[0513] The vehicle state information acquisition unit 77c acquires the vehicle state information from the center device 3. When the application is installed in all the rewriting target ECUs 19, the activation condition determination unit 77d determines whether the sixth condition, the seventh condition, and the eighth condition are satisfied. The sixth condition is a condition that the user consent related to activation is obtained. The user consent related to activation is indicated, for example, in the following example: Figure 43 The user consents to the activation (e.g., pressing the "OK" button 508b) on the screen shown. Alternatively, the process from download to activation can be considered a single update, with the user consenting to the update. The seventh condition is that the vehicle is in a state where activation is possible. The eighth condition is that the rewrite target ECU 19 is in a state where activation is possible.

[0514] If the activation condition determination unit 77d determines that the sixth condition, the seventh condition, and the eighth condition are all met, the activation instruction unit 77e instructs the rewrite target ECU 19 to activate the application. The specific details will be described in the instruction processing of the activation request (12) described later. That is, if the activation condition determination unit 77d determines that the user consent related to the activation has been obtained, the vehicle status is in an activation-capable state, and the rewrite target ECU 19 is in an activation-capable state, the activation instruction unit 77e instructs the rewrite target ECU 19 to activate the application. By performing the activation, the update program written to the rewrite target ECU 19 is validated. If the activation condition determination unit 77d determines that at least any one of the sixth condition, the seventh condition, and the eighth condition is not met, the activation instruction unit 77e does not instruct the rewrite target ECU 19 to activate the application and waits, or prompts the user with the fact that the activation cannot be started and the reason why it is not started.

[0515] Next, refer to Figures 62 to 64 The following describes the role of the installation instruction determination unit 77 in the CGW 13. The CGW 13 executes an installation instruction determination program to perform an installation instruction determination process.

[0516] When the CGW 13 begins the installation instruction determination process, it determines whether the first condition is met and whether the user's consent for installation has been obtained (S501, equivalent to a portion of the installation condition determination step). If the CGW 13 determines that the user's consent for installation has been obtained (S501: Yes), it then determines whether the second condition is met and whether data communication with the center device 3 is possible (S502, equivalent to a portion of the installation condition determination step). The CGW 13 determines whether data communication with the center device 3 is possible based on the communication radio wave conditions in the DCM 12.

[0517] If the CGW 13 determines that data communication with the center device 3 is possible (S502: Yes), it determines whether the third condition is met and determines whether the vehicle state is ready for installation (S503, which corresponds to a part of the installation condition determination step). As the vehicle state, the CGW 13 determines whether the battery remaining capacity of the vehicle battery 40 is above the specified capacity, whether the vehicle is in a parked state (IG disconnected state) when the memory structure of the rewriting target ECU 19 is a single-sided memory, etc., to determine whether the vehicle state is ready for installation. These vehicle state conditions can also be constructed by referring to the received rewriting specification data (refer to Figure 8 The CGW 13 determines that the vehicle state is ready for installation when, for example, the remaining battery level of the vehicle battery 40 is greater than the specified capacity specified by the rewriting specification data and matches the vehicle state specified by the rewriting specification data (only the parking state is possible, only the driving state is possible, or both the parking state and the driving state are possible).

[0518] If the CGW 13 determines that the vehicle is ready for installation (S503: Yes), it then determines whether the fourth condition is met and determines whether the rewrite target ECU 19 is ready for installation (S504, which corresponds to part of the installation condition determination step). The CGW 13 determines that the rewrite target ECU 19 is ready for installation, for example, if no fault code is generated by the rewrite target ECU 19 or if secure access to the rewrite target ECU 19 is successful. Here, the presence of a fault code is not only confirmed for the rewrite target ECU 19 that writes the write data, but also for the ECUs 19 that cooperate with the rewrite target ECU 19. In other words, the CGW 13 determines whether a fault code is generated not only for the rewrite target ECU 19 but also for the ECUs 19 that cooperate with the rewrite target ECU 19.

[0519] If the CGW13 determines that the rewrite target ECU19 is installable (S504: Yes), it then determines whether the fifth condition is met and whether the written data is normal data (S505, equivalent to part of the installation condition determination step). The CGW13 determines that the written data is normal data if the written data matches the write surface (non-operation surface) of the rewrite target ECU19 and the verification result of the written data integrity is normal. If the CGW13 determines that the written data is normal data (S505: Yes), it instructs the rewrite target ECU19 to install the application (S506, equivalent to the installation instruction step). In this way, the CGW13 uses the satisfaction of the first condition as a condition and performs determinations on the second condition and subsequent conditions. In addition, the CGW13 finally determines the fifth condition. If the CGW13 determines that all the first to fifth conditions are met, it instructs the rewrite target ECU19 to install the application.

[0520] On the other hand, if the CGW 13 determines that user consent for installation has not been obtained (S501: No), that data communication with the center device 3 is impossible (S502: No), that the vehicle status is not suitable for installation (S503: No), that the target ECU 19 is not suitable for installation (S504: No), or that the written data is not normal data (S505: No), then the CGW 13 does not instruct the target ECU 19 to install the application. Furthermore, in the above-described process, the condition for obtaining user consent for installation is determined before the other conditions. However, the condition may be determined after the other conditions.

[0521] When the CGW 13 instructs the target ECU 19 to install the application, it distributes the write data to the target ECU 19 (S507) and determines whether the installation is complete (S508). If the CGW 13 determines that the installation is complete (S508: Yes), it determines whether the sixth condition is met and whether the user's consent for activation has been obtained (S509). If the CGW 13 determines that the user's consent for activation has been obtained (S509: Yes), it determines whether the seventh condition is met and whether the vehicle is in a state where activation is possible (S510).

[0522] If the CGW 13 determines that the vehicle state is in an activation-capable state (S510: YES), it determines whether the eighth condition is satisfied and determines whether the rewriting target ECU 19 is in an activation-capable state (S511). If the CGW 13 determines that the rewriting target ECU 19 is in an activation-capable state (S511: YES), it instructs the rewriting target ECU 19 to activate (S512). In this way, if the CGW 13 determines that all of the sixth to eighth conditions are satisfied, it instructs the rewriting target ECU 19 to activate.

[0523] In addition, when there are multiple ECUs 19 to be rewritten, CGW 13 can instruct installation separately or together. In the case where the ECUs 19 to be rewritten are ECU (ID1) and ECU (ID2), in the case where the installation is instructed separately, as shown in FIG. Figure 63 As shown, CGW 13 determines whether the installation conditions for ECU (ID1) are met. If CGW 13 determines that the installation conditions for ECU (ID1) are met, it instructs ECU (ID1) to install. Next, CGW 13 determines whether the installation conditions for ECU (ID2) are met. Here, as installation conditions, CGW 13 can simply determine whether the fourth and fifth conditions for ECU (ID2) are met. If CGW 13 determines that the installation conditions for ECU (ID2) are met, it instructs ECU (ID2) to install.

[0524] In the case where the rewriting target ECU 19 is ECU (ID1) and ECU (ID2), in the method of instructing installation at the same time, as shown in FIG. Figure 64 As shown, CGW13 determines whether the installation conditions for ECU (ID1) are met. That is, CGW13 determines the first to third conditions, and the fourth and fifth conditions for ECU (ID1). If CGW13 determines that the installation conditions for ECU (ID1) are met, it determines whether the installation conditions for ECU (ID2) are met. That is, CGW13 determines the fourth and fifth conditions for ECU (ID2). If the installation conditions for ECU (ID2) are met, CGW13 instructs ECU (ID1) and ECU (ID2) to install. For example, CGW13 transmits rewrite data to ECU (ID1) and transmits rewrite data to ECU (ID2) simultaneously and in parallel. In this way, CGW13 determines the first to third conditions, and the fourth and fifth conditions for all rewrite target ECUs in a manner that instructs installation together. Moreover, CGW13 instructs installation after all these conditions are met.

[0525] As described above, the CGW 13 performs installation instruction determination processing before instructing the target ECU 19 to install the application. If it is determined that all of the following conditions are met: the first condition that the user's consent regarding installation has been obtained, the second condition that data communication with the center device 3 is possible, the third condition that the vehicle is in an installation-capable state, the fourth condition that the target ECU 19 is in an installation-capable state, and the fifth condition that the written data is normal data, the CGW 13 instructs the target ECU 19 to install the application. This allows the target ECU 19 to be appropriately instructed to install the application.

[0526] (6) Management of secure access keys

[0527] Reference Figures 65 to 69The management process of the security access key is explained. The security access key refers to the key used by CGW13 to authenticate the device when accessing the rewriting target ECU19 before installing the write data. The vehicle program rewriting system 1 performs the management process of the security access key in CGW13. Here, the explanation is based on the premise that CGW13 is in a state where it can obtain the write data from DCM12 through the above-mentioned (3) write data transmission determination process or (4) write data acquisition determination process. Device authentication using the security access key is equivalent to the fourth condition (step S505) in the above-mentioned (5) installation instruction determination process.

[0528] When the CGW 13 distributes write data to the target ECU 19, secure access (device authentication) between the CGW 13 and the target ECU 19 is required using a secure access key. In this case, a method is considered in which the CGW 13 requests the target ECU 19 to generate a random value, obtains the random value generated by the target ECU 19, and calculates the secure access key using the obtained random value. However, in this method, if the random value is obtained from the target ECU 19 even when the application is not being rewritten, the secure access key can be retained, which may lead to the risk of security access key leakage.

[0529] Alternatively, if the CGW 13 transmits the random value received from the rewrite target ECU 19 to the center device 3, where the center device 3 calculates the random value and generates a secure access key, the secure access key need not be stored, thereby reducing the risk of security access key leakage. However, in a configuration where the center device 3 calculates the random value, the waiting time until the rewrite target ECU 19 receives the random value from the center device 3 is long, making it difficult to meet the time requirements for diagnostic communication. In response to this situation, the following configuration is adopted in this embodiment.

[0530] like Figure 65 As shown, the vendor uses the security access key encryption / decryption key to encrypt the security access key for each rewrite target ECU 19 to generate a random value. The random value here can be either different from or the same as the previously used value. The random value is the encrypted security access key. The vendor provides the generated random value along with the reprogramming data. The security access key, the security access key encryption / decryption key, and the random value are unique to each ECU 19.

[0531] If the random value is provided together with the reprogramming data from the supplier, the OEM will establish a correspondence between the provided random value and the ECU (ID) that identifies the ECU 19 and store it in Figure 8The CGW rewrite specification data is shown. The OEM also stores the key mode and decryption operation mode required to decrypt the random value in the CGW rewrite specification data. The key mode stores information such as the shared key / public key method and key length, while the decryption operation mode stores information such as the type of algorithm used for the decryption operation. Once the random value, key mode, and decryption operation mode are stored in the CGW rewrite specification data, the OEM provides the CGW rewrite specification data containing the random value along with the reprogramming data to the center device 3. This information provided by the supplier is stored in the ECU reprogramming data DB and ECU metadata DB, described later.

[0532] When rewrite specification data (rewrite specification data for the DCM and rewrite specification data for the CGW) is provided by the OEM along with the reprogramming data, the center device 3 transmits a distribution package including the provided rewrite specification data and the reprogramming data to the host device 11. In the host device 11, the DCM 12 downloads the distribution package from the center device 3 and transmits the rewrite specification data and the write data to the CGW 13.

[0533] like Figure 66 As shown, the CGW 13 includes a secure area 78a (equivalent to a decryption key storage unit), a random value extraction unit 78b (equivalent 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 within its secure access key management unit 78. The secure area 78a prevents information from being read from outside the ECU 19 and contains encryption / decryption keys and decryption algorithms for the secure access key. The random value extraction unit 78b extracts the random value (key-derived value) contained in the CGW rewrite specification data from the results of its analysis. The random value is encrypted and associated with the ECU (ID) of the rewrite target ECU 19.

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

[0535] After the random value extraction unit 78b extracts the random value, the key generation unit 78e searches the secure area 78a and decrypts the extracted random value using the decryption key corresponding to the ECU (ID) from the decryption key bundle of the secure access key allocated in the secure area 78a, thereby generating a secure access key. In this case, the key generation unit 78e uses the decryption key determined by the key pattern extracted by the key pattern extraction unit 78c and the decryption operation method determined by the decryption operation mode extracted by the decryption operation mode extraction unit 78d to decrypt the key-derived value. Specifically, multiple key patterns and multiple decryption operation modes are prepared, and the key pattern and decryption operation mode are specified by the rewrite specification data for the CGW. The key generation unit 78e uses these key patterns and decryption operation modes to generate the secure access key.

[0536] Once the key generation unit 78e generates a secure access key, the secure access execution unit 78f uses the generated secure access key to execute secure access to the target ECU 19. Specifically, the secure access execution unit 78f transmits encrypted data, for example, obtained by encrypting the ECU (ID) using the secure access key, to the target ECU 19, requesting access. Upon receiving the encrypted data, the target ECU 19 decrypts it using its own secure access key. The target ECU 19 then compares the decrypted data generated by the decryption process with its own ECU (ID). If the two match, access is permitted; if they do not, access is denied.

[0537] The session transfer request unit 78g requests a transfer to the rewrite session. After transferring from the default session to the rewrite session, the secure access execution unit 78f executes secure access. Alternatively, secure access may be performed after transferring to a session other than the default session (e.g., a diagnostic session) before transferring to the rewrite session. The key erasure unit 78h erases the secure access key generated by the key generation unit 78e after the secure access execution unit 78f executes secure access to the rewrite target ECU 19 and the rewrite of the application program in the rewrite target ECU 19 is completed.

[0538] Next, refer to Figures 67 to 69 The role of the secure access key management unit 78 in the CGW 13 will be described. The CGW 13 executes a secure access key management program and performs secure access key management. As part of the secure access key management process, the CGW 13 generates and deletes secure access keys. Each of these processes will be described below.

[0539] (6-1) Generation of secure access keys

[0540] If CGW13 starts the process of generating a secure access key, it parses the rewrite specification data obtained from DCM12 (S601, equivalent to the rewrite specification data parsing step), and extracts the random value, key mode, and decryption operation mode from the rewrite specification data used by CGW (S602, equivalent to the key derivation value extraction step).

[0541] CGW13 retrieves the secure area 78a, and uses the decryption key corresponding to the ECU (ID) from the decryption key bundle of the secure access key configured in the secure area 78a to decrypt the random value extracted from the rewrite specification data used by the CGW, thereby generating a secure access key (S603, equivalent to the key generation step).

[0542] like Figure 68 As shown, the CGW 13 generates a secure access key based on the CGW rewrite specification data. The CGW 13 issues a session transfer request to a rewrite session where write data can be written (S604). Using the secure access key, the CGW 13 performs secure access to the rewrite target ECU 19 (S605). Once the secure access is complete, the CGW 13 distributes the write data to the rewrite target ECU 19 (S606) and issues a session maintenance request (S607). If the CGW 13 determines that the installation is complete (S608: Yes), the secure access key generation process ends.

[0543] (6-2) Deletion of secure access keys

[0544] When the CGW 13 starts the secure access key erasure process, it determines whether the rewriting of the application program of the rewriting target ECU 19 is complete (S611). If the CGW 13 determines that the rewriting of the application program of the rewriting target ECU 19 is complete (S611: Yes), it erases the secure access key generated by executing the secure access key generation process (S612), and ends the secure access key erasure process.

[0545] As described above, the CGW 13 manages the secure access key, extracting a random value corresponding to the target ECU 19 from the analysis results of the rewrite specification data. This random value is then decrypted using the decryption key corresponding to the target ECU 19 stored in the secure area 78a to generate the secure access key. By generating the secure access key within the CGW 13 without externally acquiring the secure access key, the risk of security access key leakage is reduced, allowing for appropriate secure access to the target ECU 19.

[0546] In addition, it is preferred that CGW13 generates a security access key before installing each write data when there are multiple ECUs19 to be rewritten. That is, it is preferred that: if the ECUs19 to be rewritten are ECU (ID1), ECU (ID2), and ECU (ID3), CGW13 performs the following steps in the order of generating a security access key for ECU (ID1), installing write data to ECU (ID1), generating a security access key for ECU (ID2), installing write data to ECU (ID2), generating a security access key for ECU (ID3), and installing write data to ECU (ID3). For example, Figure 63 As shown, CGW 13 performs secure access processing as a process to determine whether installation conditions are met for ECU (ID1). If access is permitted, ECU (ID1) is instructed to install. Then, CGW 13 performs secure access processing as a process to determine whether installation conditions are met for ECU (ID2). If access is permitted, ECU (ID2) is instructed to install.

[0547] In addition, if the rewrite target ECU 19 is allowed to access itself through the CGW 13 through security access, it will release the security access by receiving the session transfer request from the CGW 13, and the write data will be able to be written to the flash memory. Figure 155 The second state shown is "Rewrite Session Transfer Request." If the target ECU 19 does not receive a session transfer request from the CGW 13 within a specified time (e.g., 5 seconds) from the time access to itself is granted, it times out, locks security access, and refuses to accept further session transfer requests. If the CGW 13 does not send a session transfer request to the target ECU 19 within the specified time from the time access to the target ECU 19 is granted, it is necessary to send a session maintain request to the target ECU 19 to ensure that the target ECU 19 does not time out and send the session transfer request to the target ECU 19.

[0548] In addition, for example, in the middle of rewriting, the version 1.0 application is written to the operating surface and the version 2.0 application is written to the non-operating surface by canceling the operation. If an activity notification to version 2.0 is generated from this state, it is only necessary to activate it without installation, so the security access processing can also be omitted.

[0549] (7) Verification of written data

[0550] Reference Figures 70 to 78The written data verification process is described below. The vehicle program rewriting system 1 performs the written data verification process in the CGW 13. The CGW 13 can perform the written data verification process described in this embodiment either before obtaining access permission in the above-mentioned (6) secure access key management process or after obtaining access permission.

[0551] like Figure 70 As shown, when a supplier or OEM generates write data, a data verification value calculation algorithm is applied to the written data to generate a data verification value. The written data can be either a new program to be updated or differential data from an old program to a new one. The supplier or OEM encrypts the data verification value using a specified key (key value) to generate an authenticator. The written data and authenticator are then registered in a corresponding relationship with the central device 3. Specifically, this data is stored in the reprogramming data database (described later) for each ECU 19. Furthermore, the central device 3 generates a distribution data packet containing the written data and authenticator and stores it in the data packet database.

[0552] When a download request for a distribution data packet is generated from the host device 11, the central device 3 transmits the distribution data packet, including the write data and the authenticator, to the host device 11 in response to the download request. In this case, the write data sent from the central device 3 to the host device 11 is encrypted, and the authenticator sent from the central device 3 to the host device 11 is also encrypted. Alternatively, the authenticator sent from the central device 3 to the host device 11 may be plaintext. If the authenticator sent from the central device 3 to the host device 11 is plaintext, the decryption process described below is unnecessary.

[0553] If the main device 11 downloads a distribution data package from the central device 3, it extracts the write data of the rewrite target ECU 19 from the downloaded distribution data package and verifies the validity of the write data before distributing the write data to the rewrite target ECU 19. That is, the main device 11 performs decryption processing, first verification value calculation processing, second verification value calculation processing, comparison processing, and judgment processing in sequence to verify the write data. The decryption processing is the process of decrypting the authentication code sent in ciphertext. The first verification value calculation processing is the process of calculating the first data verification value as the expected value based on the decrypted authentication code using a key (key value). The second verification value calculation processing is the process of calculating the second data verification value based on the write data using a data verification value calculation algorithm. The comparison processing is the process of comparing the first data verification value and the second data verification value. The judgment processing is the process of determining the validity of the write data based on the comparison result of the comparison processing.

[0554] like Figure 71As shown, the CGW 13 includes a write data verification unit 79 including a write-enable determination unit 79a, a process execution request unit 79b, a process result acquisition unit 79c, and a verification unit 79d. The write-enable determination unit 79a determines whether the write data can be written to the rewrite target ECU 19. If the write-enable determination unit 69a determines that the write data can be written to the rewrite target ECU 19, the process execution request unit 79b notifies the DCM 12 of a process execution request, requesting the DCM 12 to execute a process. The process execution request unit 68b notifies the DCM 12 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 process result acquisition unit 68c, upon receiving notification of the process result from the DCM 12, acquires the process result from the DCM 12. If the process result acquisition unit 68c acquires the process result, the verification unit 79d uses the process result to verify the write data. That is, in the above-described configuration, the CGW 13 corresponds to a first device and a first functional unit, and the DCM 12 corresponds to a second device and a second functional unit.

[0555] Next, refer to Figures 72 to 77 The following describes the role of the write data verification unit 79 in the CGW 13. The CGW 13 executes a write data verification program to perform a write data verification process.

[0556] When the CGW 13 begins verification of the written data, it notifies the DCM 12 of a request to execute the process, requesting DCM 12 to execute the process (S701, equivalent to a process execution request step). The CGW 13 notifies the DCM 12 of a request to execute at least one of the aforementioned decryption process, first verification value calculation process, second verification value calculation process, comparison process, and determination process. When the CGW 13 obtains the process result from the DCM 12 (S702, equivalent to a process result acquisition step), it uses the obtained process result to verify the written data (S703, equivalent to a verification step).

[0557] The following examples illustrate several cases where CGW 13 notifies DCM 12 of a processing execution request. Figure 73In the example, CGW13 notifies DCM12 of the processing execution request for decryption processing, first verification value calculation processing, and second verification value calculation processing. If DCM12 is notified of the processing execution request for decryption processing, first verification value calculation processing, and second verification value calculation processing from CGW13, it will sequentially perform decryption processing, first verification value calculation processing, and second verification value calculation processing. DCM12 performs processing result notification processing and notifies 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. If CGW13 performs processing result acquisition processing and obtains the first data verification value and the second data verification value from DCM12, it will sequentially perform comparison processing and determination processing 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 processing is positive. In this example, DCM12 holds the key used to calculate the first data verification value.

[0558] exist Figure 74 In the example, CGW13 notifies DCM12 of the request to execute the decryption process and the second verification value calculation process. If DCM12 is notified of the request to execute the decryption process and the second verification value calculation process by CGW13, it will sequentially execute the decryption process and the second verification value calculation process, and notify CGW13 of the second data verification value calculated by the second verification value calculation process. If CGW13 executes the processing result acquisition process and obtains the second data verification value from DCM12, it will execute the first verification value calculation process, and use the first data verification value calculated by the first verification value calculation process and the second data verification value to sequentially execute the comparison process and the determination process. CGW13 verifies the write data based on whether the determination result of the determination process is positive. In this example, CGW13 maintains the key used to calculate the first data verification value.

[0559] exist Figure 75 In the example, CGW13 notifies DCM12 of a request to execute the decryption process, the first verification value calculation process, the second verification value calculation process, and the comparison process. Upon receiving notification of the decryption process, the first verification value calculation process, the second verification value calculation process, and the comparison process from CGW13, DCM12 sequentially executes the decryption process, the first verification value calculation process, the second verification value calculation process, and the comparison process. DCM12 executes a processing result notification process and notifies CGW13 of the comparison result of the comparison process as the processing result. When CGW13 executes a processing result acquisition process and obtains the comparison result from DCM12, it executes a determination process using the comparison result. CGW13 verifies the written data based on whether the determination result of the determination process indicates a positive result. In this example, DCM12 holds a key for calculating the first data verification value.

[0560] exist Figure 76 In the example shown, CGW 13 notifies DCM 12 of a request to execute decryption, first verification value calculation, second verification value calculation, comparison, and determination. Upon receiving notification of these requests from CGW 13, DCM 12 sequentially executes decryption, first verification value calculation, second verification value calculation, comparison, and determination. DCM 12 performs processing result notification and notifies CGW 13 of the result of the determination as a processing result. CGW 13 then verifies the write data based on whether the determination result indicated by the processing result indicates a positive result. In this example, DCM 12 holds the key used to calculate the first data verification value.

[0561] When there are multiple ECUs 19 to be rewritten, the CGW 13 performs the following verification process for the written data of the multiple ECUs 19 . When there are multiple ECUs 19 to be rewritten, the CGW 13 can verify the written data of the multiple ECUs 19 together or independently.

[0562] In a method of verifying written data for a plurality of rewriting target ECUs 19 at once, for example, Figure 77 As shown, CGW 13 simultaneously verifies the write data of ECU (ID1), the write data of ECU (ID2), and the write data of ECU (ID3), and distributes the write data of ECU (ID1) to ECU (ID1) as the writing target, distributes the write data of ECU (ID2) to ECU (ID2) as the writing target, and distributes the write data of ECU (ID3) to ECU (ID3) as the writing target. In this case, by verifying the write data of multiple rewrite target ECUs 19 at the same time, the time required from the start of verification of the write data of multiple rewrite target ECUs 19 to the completion of program rewrite can be shortened. In other words, compared with a configuration in which the write data of multiple rewrite target ECUs 19 is independently verified, the time required from the start of verification of the write data of multiple rewrite target ECUs 19 to the completion of program rewrite can be shortened.

[0563] In a method of independently verifying the written data for a plurality of rewriting target ECUs 19, for example, Figure 78As shown, CGW 13 verifies the write data of ECU (ID1), distributes the write data of ECU (ID1) to ECU (ID1) as the write target ECU (ID1), verifies the write data of ECU (ID2), distributes the write data of ECU (ID2) to ECU (ID2) as the write target ECU (ID2), and verifies the write data of ECU (ID3), distributes the write data of ECU (ID3) to ECU (ID2) as the write target ECU. In this case, by verifying the write data before distributing the write data, illegal access can be avoided and reliability can be improved. That is, in a configuration in which write data is verified for multiple rewrite target ECUs 19 at the same time, the time from completing the verification according to the rewrite order to distributing the write data varies according to the rewrite order. If the time from completing the verification to distributing the write data becomes longer, there is a concern that tampering due to illegal access may occur during this period. However, by verifying the write data immediately before distributing the write data, such a situation can be avoided.

[0564] As described above, the CGW 13 performs written data verification processing, causing the DCM 12, which downloads the distribution data package from the center device 3, to execute at least a portion of the processing related to written data verification. Even if the CGW 13 or the target ECU 19 cannot secure an area for storing written data or cannot install a verification program, it is still possible to appropriately verify the written data before writing it to the target ECU 19.

[0565] exist Figure 74 In the illustrated configuration in which the CGW 13 performs the first verification value calculation process, the CGW 13 retains the key (key value) and performs the verification process without transmitting the key to the DCM 12. This improves security compared to a configuration in which the DCM 12 performs the first verification value calculation process. Furthermore, if there are multiple target ECUs 19, the first verification value calculation process can be performed using either a shared key (key value) shared by the multiple target ECUs 19 or a unique key (key value) that differs for each of the multiple target ECUs 19.

[0566] In addition, the above example illustrates a configuration in which CGW13 notifies DCM12 of a processing execution request. However, in a case where, for example, the processing load in DCM12 increases and interferes with the original processing, an ECU other than a navigation device or rewriting target ECU19 may be used instead of DCM12 to notify the processing execution request to the ECU other than the navigation device or rewriting target ECU19. In addition, in a case where DCM12 and CGW13 are integrated, a processing execution request may be requested to its own processing execution unit when it is possible to respond without interfering with the original processing. For example, it may be performed between different software components within the same ECU. In addition, the above configuration may be applied to the main unit 11 configured as an integrated ECU having the functions of DCM12 and CGW13. For example, in Figures 73 to 76 In this example, the processing function in the CGW 13 is defined as the first functional unit, and the processing function in the DCM 12 is defined as the second functional unit. A processing execution request is notified from the first functional unit to the second functional unit, and the execution result is returned from the second functional unit to the first functional unit. In the case where the processing load in the master device 11, which is configured as an integrated ECU, increases, hindering communication processing and relay processing, the processing execution request can be notified to ECUs other than the navigation system and the rewrite target ECU 19, instead of the second functional unit.

[0567] In addition, the data verification value can be calculated as a single value for the entire application or multiple values ​​can be calculated for each module of the application. If the written data is complete, it can be used for integrity verification after the data is written.

[0568] In addition, with respect to secure access, which is a method of verifying whether CGW13 and the rewrite object ECU19 can also be connected, the verification of written data includes the concepts of the central device 3 as the distribution destination of the written data being regular (connection based on TLS communication, mutual authentication), the communication path for downloading the written data from the central device 3 being regular (communication path hiding, encryption), the written data downloaded from the central device 3 not being tampered with (tampering detection), and the written data downloaded from the central device 3 being unable to be tampered with (encryption).

[0569] While the description above focuses on data written when rewriting a new program, the same applies to data written during a rollback when rewriting an old program. In this case, the CGW 13 may verify the data written during the rollback when downloading it from the center device 3, or it may verify the data immediately before distributing the rollback data to the target ECU 19 by issuing a write cancellation request.

[0570] (8) Data storage information transmission control processing

[0571] Reference Figures 79 to 81The transmission control process of the data storage surface information will be described. The vehicle program rewriting system 1 performs the transmission control process of the data storage surface information in the CGW 13 .

[0572] like Figure 79 As shown, the CGW 13 includes a data storage surface information acquisition unit 80a, a data storage surface information transmission unit 80b, a rewrite method determination unit 80c, and a rewrite method instruction unit 80d within its data storage surface information transmission control unit 80. The data storage surface information acquisition unit 80a acquires information related to hardware and software from each ECU 19 as ECU configuration information. Specifically, in the case of dual-sided memory ECUs with multiple data storage surfaces and single-sided memory ECUs, the unit acquires software IDs containing version information for each data storage surface and information identifying the operating surface as dual-sided rewrite information (hereinafter referred to as surface information).

[0573] When the data storage surface information acquiring unit 80a acquires ECU configuration information including surface information, the data storage surface information transmitting unit 80b transmits the acquired surface information from the DCM 12 to the center device 3 as part of the ECU configuration information. The data storage surface information transmitting unit 80b may transmit the ECU configuration information to the center device 3 each time the IG switch 42 is switched 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. Furthermore, the data storage surface information transmitting unit 80b may also transmit the ECU configuration including surface information not only to dual-side memory ECUs and single-side suspended memory ECUs, but also to single-side independent memory ECUs.

[0574] The rewriting method determination unit 80c determines the rewriting method based on the analysis results of the rewriting specification data used by the CGW 13. The rewriting method indicates the power switching method during installation in the rewriting target ECU 19. If the rewriting method determination unit 80c determines the rewriting method, the rewriting method instruction unit 80d instructs the rewriting target ECU 19 to rewrite the application based on the determined rewriting method. In other words, if the rewriting method determination unit 80c determines the rewriting method based on power self-maintenance, the rewriting method instruction unit 80d instructs the rewriting target ECU 19 to rewrite the application based on power self-maintenance. If the rewriting method determination unit 80c determines the rewriting method based on power control, the rewriting method instruction unit 80d instructs the rewriting target ECU 19 to rewrite the application based on power control without using power self-maintenance.

[0575] Next, refer to Figure 80 as well as Figure 81 The following describes the role of the data storage plane information transmission control unit 80 in the CGW 13. The CGW 13 executes a data storage plane information transmission control program to perform data storage plane information transmission control processing.

[0576] When the CGW 13 begins the data storage surface information transmission control process, it sends an ECU configuration information request including the surface information to all ECUs 19 (S801), and then obtains the ECU configuration information including the surface information from all ECUs 19 (S802, equivalent to the data storage surface information acquisition step). After obtaining the ECU configuration information from each rewrite target ECU 19, the CGW 13 transmits the obtained ECU configuration information to the DCM 12 (S803, equivalent to the data storage surface information transmission step), and then waits to receive the write data and rewrite specification data from the DCM 12 (S804). Alternatively, if the CGW 13 has previously determined the rewrite target ECU 19, it may obtain surface information, etc., only from the specified ECU 19.

[0577] Upon receiving ECU configuration information from the CGW 13, the DCM 12 temporarily stores the received ECU configuration information. When the time comes to transmit (upload) the ECU configuration information to the center device 3, the DCM 12 transmits the ECU configuration information to the center device 3. Upon receiving ECU configuration information from the DCM 12, the center device 3 stores and analyzes the received ECU configuration information.

[0578] The center device 3 identifies the application version of each surface of each ECU 19, which is the source of the surface information, and which surface is the operational surface. It then determines the application version and write data appropriate for the two identified surfaces (this corresponds to the update data selection step). For example, if surface A is the operational surface and the application stored on the operational surface is version 2.0, and surface B is the non-operating surface and the application stored on the non-operating surface is version 1.0, the center device 3 determines that version 3.0 write data for surface B is the write data. If the write data is differential data, the center device 3 determines that the differential data represents the update from version 1.0 to version 3.0. Once the write data is determined, the center device 3 transmits a distribution packet containing the determined write data and rewrite specification data to the DCM 12 (this corresponds to the distribution packet transmission step).

[0579] The central device 3 can either statically select the distribution data packets to be sent to the DCM 12 or dynamically generate them. When statically selecting the distribution data packets to be sent to the DCM 12, the central device 3 manages multiple distribution data packets storing write data, selects write data suitable for the non-operational side, selects a distribution data packet storing the selected write data from the multiple distribution data packets, and transmits the selected distribution data packet to the DCM 12. When dynamically generating the distribution data packets to be sent to the DCM 12, if the central device 3 determines that write data suitable for the non-operational side is present, it generates a distribution data packet storing the determined write data and transmits the generated distribution data packet to the DCM 12.

[0580] When the DCM 12 downloads the distribution package from the center device 3 , it extracts the write data and the rewrite specification data from the downloaded distribution package, and transmits the extracted write data and rewrite specification data to the CGW 13 .

[0581] When the CGW 13 determines that the write data and the rewrite specification data have been acquired from the DCM 12 ( S804 : YES), it analyzes the acquired rewrite specification data ( S805 ) and determines the rewrite method for the rewrite target ECU 19 based on the analysis result of the rewrite specification data ( S806 , S807 ).

[0582] If the CGW 13 determines that the rewriting method is based on power self-maintenance rewriting (S806: Yes), it will send a write data acquisition request to the DCM 12 based on the vehicle state that can be installed, obtain the write data from the DCM 12, and distribute the acquired write data to the rewriting target ECU 19, and end the data storage surface information transmission control processing through the power self-maintenance rewriting application (S808). The method of using the power self-maintenance rewriting application is as follows: Figure 28 as well as Figure 29 This is described in (ii) the case of rewriting the application program by self-maintaining the power supply.

[0583] If the CGW 13 determines that the rewriting method is rewriting based on power control (S807: Yes), it sends a write data acquisition request to the DCM 12 under the condition that the vehicle is parked, acquires the write data from the DCM 12, distributes the acquired write data to the rewriting target ECU 19, and rewrites the application program through power control (S809), thereby ending the data storage surface information transmission control process. Figure 26 as well as Figure 27 This is described in (1) the case of rewriting the application program through power control.

[0584] As described above, the CGW 13 performs data storage surface information transmission control processing to notify the center device 3 of the ECU configuration information, including the surface information, and downloads a distribution packet containing write data that matches the ECU configuration information from the center device 3 to the DCM 12. The CGW 13 obtains the write data that matches the surface information from the DCM 12 and distributes it to the rewrite target ECU 19. When the rewrite target ECU 19 is equipped with a flash memory having data storage surfaces on both sides, the application program can be appropriately rewritten.

[0585] Furthermore, the central device 3 can distribute distribution packages in the following ways: first, second, and third distribution methods. In the first distribution method, the central device 3 distributes a single distribution package containing, for example, version 2.0 write data for Side A and version 2.0 write data for Side B. The DCM 12 extracts the version 2.0 write data for Side A and version 2.0 write data for Side B from the distribution package downloaded from the central device 3 and transmits the extracted write data to the CGW 13. Upon receiving the version 2.0 write data for Side A and version 2.0 write data from the DCM 12, the CGW 13 selects one of the two and distributes it to the rewrite target ECU 19. Specifically, the write data corresponding to each data storage surface is included in the distribution package, and the host device 11 selects the rewrite data appropriate for the rewrite target ECU 19.

[0586] In the second distribution method, the center device 3 selects and distributes either a distribution package containing version 2.0 write data for side A or a distribution package containing version 2.0 write data for side B. The DCM 12 extracts the write data from the distribution package downloaded from the center device 3 and transmits the extracted write data to the CGW 13. The CGW 13 distributes the write data transmitted from the DCM 12 to the rewrite target ECU 19. Specifically, based on the surface information uploaded from the DCM 12, the center device 3 selects the configuration of the distribution package that includes the write data for the non-operational surface.

[0587] In the third distribution method, the central device 3 distributes a distribution package containing, for example, version 2.0 write data shared by Sides A and B. The DCM 12 extracts the version 2.0 write data shared by Sides A and B from the distribution package downloaded from the central device 3 and transmits the extracted write data to the CGW 13. The CGW 13 distributes the version 2.0 write data shared by Sides A and B, transmitted from the DCM 12, to the target ECU 19. Upon receiving the version 2.0 write data shared by Sides A and B from the CGW 13, the target ECU 19 writes the received write data to either Side A or Side B. In this case, when the application program is executed in the target ECU 19, the address resolution function of the microcomputer comes into play, ensuring proper operation regardless of whether the write data is written to Side A or Side B. Specifically, the microcomputer in the target ECU 19 resolves the difference in execution address associated with the difference in side, allowing the central device 3 and the host device 11 to operate without knowing the side.

[0588] The ECU configuration information including the surface information sent from the CGW 13 to the center device 3 via the DCM 12 may include vehicle identification information, system identification information, ECU identification information, usage environment information, etc. in addition to the versions of the two surface applications and information that can identify the application surface.

[0589] Vehicle identification information is unique information used to identify the vehicle to which the distribution data packet is being delivered, such as a VIN (Vehicle Identification Number). In vehicles that comply with OBD (On-Board Diagnostics) regulations, the VIN can be used due to OBD regulations. However, in vehicles that do not comply with OBD regulations, such as EVs, the VIN cannot be used, so individual vehicle identification information can be used instead of the VIN.

[0590] System identification information is unique information used to identify the type of reprogramming system. The CGW 13 can wirelessly reprogram systems that can perform wired reprogramming using its own managed diagnostic communication, but cannot wirelessly reprogram other independent systems. This is because the system uses a wired program update mechanism to update programs acquired wirelessly. Therefore, the center device 3 must determine which distribution packet is delivered to which system. Using this system identification information, the center device 3 can manage which systems are installed in the vehicle. By determining the system identification information, the center device 3 can determine the reprogramming method for each system and the reprogramming order when multiple systems are targeted for reprogramming.

[0591] ECU identification information uniquely identifies the target ECU 19. It includes information used to uniquely identify the target ECU and the software and hardware versions of the application program written to the target ECU 19. ECU identification information also corresponds to the ECU product number. If the latest software is written using all data, it can also include only the hardware version. Information that identifies the application program, such as the specification version and configuration version, can also be defined. Furthermore, the microcomputer ID, sub-microcomputer ID, flash memory ID, software sub-version, and software sub-version can also be defined.

[0592] Usage environment information is unique information used to identify the environment in which a user uses their vehicle. By transmitting this usage environment information from the CGW 13 to the center device 3 via the DCM 12, the center device 3 can distribute applications tailored to the user's vehicle usage environment. For example, a user who prefers rapid acceleration from a stop can be provided with an application that enhances acceleration, while a user who prefers eco-driving can be provided with an application that enhances eco-driving despite poor acceleration performance. These applications can be distributed in a manner tailored to the user's vehicle usage environment.

[0593] The above description describes the case where the microcomputer of the rewrite target ECU 19 is equipped with flash memory. However, if the microcomputer of the rewrite target ECU 19 is connected to external memory, the external memory is treated identically to the double-sided memory, with the write area of ​​the external memory divided into two areas for writing data. In cases where the microcomputer of the rewrite target ECU 19 is equipped with flash memory and connected to external memory, programs stored in the external memory may be temporarily copied (copied) to the microcomputer's memory. Because external memory is often used as a storage area for the ECU's action log, it is preferable to interrupt action log storage when writing data to the external memory begins and resume action log storage when writing data to the external memory is completed.

[0594] This is not limited to the case of rewriting an application. For example, data that is updated one by one, such as map data, also has concepts such as double-sided and version, so the same applies to the case of rewriting map data.

[0595] (9) Power management processing for non-rewrite objects

[0596] Reference Figures 82 to 87 The power management process for the non-rewrite target ECUs 19 will be described. The vehicle program rewriting system 1 performs power management for the non-rewrite target ECUs 19 in the CGW 13. In this embodiment, the DCM 12 completes downloading of the distribution data package, the CGW 13 obtains the rewrite specification data, and then distributes the write data to the rewrite target ECUs 19 while the vehicle is parked. After distributing the write data to the rewrite target ECUs 19, the CGW 13 requests the power management ECU 20 to turn on the IG power supply, thereby activating all ECUs 19.

[0597] like Figure 82 As shown, the CGW 13 includes a rewrite target determination unit 81a, an installability determination unit 81b, a state transition control unit 81c, and a rewrite order determination unit 81d in the power supply management unit 81 of the non-rewrite target ECU 19. The rewrite target determination unit 81a determines the rewrite target ECU 19 and the non-rewrite target ECU 19 based on the analysis results of the rewrite specification data. The installability determination unit 81b determines whether the rewrite target ECU 19 can be installed.

[0598] The state transition control unit 81c can transition the state of the ECU 19, causing the ECU 19 in the stopped or sleep state to transition to the activated state (awake state), or the activated ECU 19 to transition to the stopped or sleep state. Furthermore, the state transition control unit 81c can transition the ECU 19 in the normal operating state to the power-saving operating state, or vice versa. If the installability determination unit 81b determines that the device can be installed, the state transition control unit 81c controls at least one non-rewrite target ECU 19 to transition to the stopped state, sleep state, or power-saving operating state. The rewrite order determination unit 81d determines the rewrite order of the rewrite target ECU 19 based on the analysis results of the rewrite specification data.

[0599] Next, refer to Figures 83 to 87 The function of the power management unit 81 of the non-rewrite target ECU 19 in the CGW 13 will be described. The CGW 13 executes the non-rewrite target power management program and performs non-rewrite target power management processing. Here, the case where the CGW 13 activates all the ECUs 19 to be managed will be described.

[0600] When the CGW 13 begins power management processing for the non-rewrite target ECUs 19, it determines the rewrite target ECUs 19 and non-rewrite target ECUs 19 based on the analysis results of the rewrite specification data for the CGW (S901). It also determines the rewrite order of one or more rewrite target ECUs 19 based on the analysis results of the rewrite specification data (S902). The CGW 13 determines whether write data can be written (S903, equivalent to a write-enable determination step). If it determines that write data can be written (S903: Yes), it transmits a power-off request (stop request) to the non-rewrite target ECUs 19 of the ACC system and the non-rewrite target ECUs 19 of the IG system, causing the non-rewrite target ECUs 19 of the ACC system and the non-rewrite target ECUs 19 of the IG system to transition from an active state to a stopped state (S904, equivalent to a state transition control step).

[0601] CGW13 determines whether the power disconnection request has been sent to all compliant ECU19 (S905). If it is determined that the power disconnection request has been sent to all compliant ECU19 (S905: Yes), a sleep request is sent to the non-rewrite object ECU19 of the +B power system, so that the non-rewrite object ECU19 of the +B power system is transferred from the startup state to the sleep state (S906, equivalent to the state transfer control step).

[0602] The CGW 13 determines whether the sleep request has been sent to all eligible ECUs 19 (S907). If the sleep request has been sent to all eligible ECUs 19 (S907: Yes), the CGW 13 determines whether the application program has been rewritten to all rewrite-target ECUs 19 (S908). If the CGW 13 determines that the application program has been rewritten to all rewrite-target ECUs 19 (S908: Yes), the CGW 13 terminates the power management process for the non-rewrite-target ECUs 19. If the CGW 13 determines that the application program has not been rewritten to all rewrite-target ECUs 19 (S908: No), the process returns to step S904 and repeats step S904 and subsequent steps.

[0603] When there are multiple ECUs 19 to be rewritten, the CGW 13 can either independently transfer the states of the multiple ECUs 19 to be rewritten, or transfer the states of the multiple ECUs 19 to be rewritten together. Figure 83 In FIG. 1 , the processing of the CGW 13 sending a power off request or a sleep request to the non-rewriting target ECU 19 is shown. Figure 84 as well as Figure 85 In the following, a case where the power supply management process for the rewriting target ECU 19 is performed in addition to the power supply management process for the non-rewriting target ECU 19 will be described.

[0604] First, use Figure 84 The following describes a case where the CGW 13 independently transfers the states of a plurality of rewrite target ECUs 19. Figure 84 As shown, the case where the rewrite object ECU19 is, for example, ECU (ID1), ECU (ID2), and ECU (ID3), and the rewrite object ECU19 specified by ECU (ID1), ECU (ID2), and ECU (ID3) is rewritten in the order of rewriting from early to late during parking is described.

[0605] CGW13 causes ECU (ID1), ECU (ID2), and ECU (ID3) to transition from a stopped or sleep state to a started state. CGW13 maintains the first rewritten ECU (ID1) in its started state, transitions ECU (ID2) and ECU (ID3) from their started states to a stopped or sleep state, and distributes the written data to ECU (ID1). Once CGW13 has completed distributing the written data to ECU (ID1), it transitions ECU (ID1) from its started state to a stopped or sleep state, transitions the second rewritten ECU (ID2) from its stopped or sleep state to its started state, maintains ECU (ID3) in its stopped or sleep state, and distributes the written data to ECU (ID2).

[0606] Once CGW13 has completed distributing the write data to ECU (ID2), it maintains ECU (ID1) in a stopped or sleep state, shifts ECU (ID2) from an active state to a stopped or sleep state, and shifts the third ECU (ID3) being rewritten from a stopped or sleep state to an active state, distributing the write data to ECU (ID3). Once CGW13 has completed distributing the write data to ECU (ID3), it maintains ECU (ID1) and ECU (ID2) in a stopped or sleep state, shifting ECU (ID3) from an active state to a stopped or sleep state. In this way, CGW13 controls so that only the ECU 19 currently being rewritten among the multiple rewrite target ECUs 19 is in an active state.

[0607] Next, use Figure 85 The following describes a case where the CGW 13 transfers the states of a plurality of rewriting target ECUs 19 at once. Figure 85 As shown, the case where the rewrite object ECU19 is, for example, ECU (ID1), ECU (ID2), and ECU (ID3), and the rewrite object ECU19 specified by ECU (ID1), ECU (ID2), and ECU (ID3) is rewritten in the order of rewriting from early to late during parking is described.

[0608] CGW13 transfers all ECU (ID1), ECU (ID2), and ECU (ID3) from the stopped state or the sleep state to the started state. CGW13 keeps all ECU (ID1), ECU (ID2), and ECU (ID3) in the started state and distributes the write data to ECU (ID1). If CGW13 completes the distribution of the write data to ECU (ID1), it distributes the write data to ECU (ID2). If CGW13 completes the distribution of the write data to ECU (ID2), it distributes the write data to ECU (ID3). If CGW13 completes the distribution of the write data to ECU (ID3), it transfers all ECU (ID1), ECU (ID2), and ECU (ID3) from the started state to the stopped state or the sleep state. In this way, CGW13 controls all multiple rewrite object ECUs 19 to the started state until the installation is completed. Here, CGW13 can also distribute the write data to ECU (ID1), ECU (ID2), and ECU (ID3) simultaneously and in parallel.

[0609] When the rewriting target ECU 19 rewrites an application while the vehicle is parked, the supply voltage to the rewriting target ECU 19 is not necessarily stable, leading to a risk of the vehicle battery 40 running out of charge while the application is being rewritten. In particular, if there are multiple rewriting target ECUs 19, the time required to rewrite the application increases, increasing the likelihood of the vehicle battery 40 running out of charge during the application rewriting process. To address this issue, by placing the non-rewriting target ECUs 19 in a stopped or dormant state as described above, it is possible to prevent the vehicle battery 40 from running low during program rewriting. Furthermore, by placing the ECUs 19 not currently being rewritten in the rewriting target ECUs 19 in a stopped or dormant state, power consumption can be further reduced.

[0610] The above describes the case where the application program of the rewriting target ECU 19 is rewritten while the vehicle is parked, but the following describes the case where the application program of the rewriting target ECU 19 is rewritten while the vehicle is running. When the application program of the rewriting target ECU 19 is rewritten while the vehicle is running, the supply voltage to the rewriting target ECU 19 is stable, so there is no need to worry about the vehicle battery 40 being exhausted during the rewriting of the application program. However, there may be a case where the battery remaining in the vehicle battery 40 is low. In such a case, it is preferable to transfer the ECU 19 that does not need to be operated to a stopped state or a sleep state while the vehicle is running. Figure 86 As shown, in a configuration where an ECU 44 not required to operate while the vehicle is running is connected to the +B power line 37 but not to the ACC power line 38 or the IG power line 39, the CGW 13 shifts the ECU 44 not required to operate while the vehicle is running from an active state to a stopped state or a sleep state. For example, the ECU 44 may include an anti-theft function. Specifically, while all ECUs 19 are active while the vehicle is running, the CGW 13 shifts the ECU 44 not required to operate and not subject to rewriting to a stopped state or a sleep state. This can suppress the increase in power consumption associated with the installation while the vehicle is running.

[0611] In addition, the CGW 13 monitors the remaining battery level of the vehicle battery 40 and performs the above-mentioned power management process for the non-rewriting target. Figure 87 The following describes the remaining battery capacity monitoring process. Once the CGW 13 begins the remaining battery capacity monitoring process, it monitors the remaining battery capacity while distributing write data to the rewrite target ECU 19 ( S911 ), and determines whether the remaining battery capacity is greater than or equal to a first predetermined capacity, less than or equal to a second predetermined capacity, or less than or equal to the second predetermined capacity ( S912 to S914 ).

[0612] If the CGW 13 determines that the remaining battery level is greater than the first predetermined capacity (S912: Yes), the non-rewrite target ECU 19 remains in the activated state and continues to distribute write data to the rewrite target ECU 19 (S915). If the CGW 13 determines that the remaining battery level is less than the first predetermined capacity and greater than the second predetermined capacity (S913: Yes), the CGW 13 shifts any ECUs in the non-rewrite target ECU 19 that are not required to operate during driving to a stopped state or a sleep state, and continues to distribute write data to the rewrite target ECU 19 (S916). If the CGW 13 determines that the remaining battery level is less than the second predetermined capacity (S914: Yes), the CGW 13 determines whether rewriting can be interrupted (S917).

[0613] If the CGW 13 determines that the rewrite operation can be interrupted (S917: Yes), the CGW 13 interrupts the distribution of the write data (S918). If the CGW 13 determines that the rewrite operation cannot be interrupted (S917: No), the CGW 13 causes all ECUs that can be switched to the stop state or sleep state among the non-rewrite target ECUs 19 to be switched to the stop state or sleep state (S919).

[0614] The CGW 13 determines whether the rewrite is complete (S920). If it determines that the rewrite is not complete (S920: No), the process returns to step S911 and repeats step S911 and subsequent steps. If it determines that the rewrite is complete (S920: Yes), the CGW 13 shifts the rewrite target ECU 19, which is in a stopped or sleep state, to an activated state (S921), terminating the battery remaining capacity monitoring process. The values ​​for the first and second predetermined capacities may be pre-set by the CGW 13 or specified in the rewrite specification data.

[0615] Furthermore, in step S919, the CGW 13 may exclude ECUs 19 with specific functions, such as alarms, from transitioning to a stopped or sleep state, and may instead transition non-rewrite target ECUs 19, excluding those with specific functions, from an active state to a stopped or sleep state. The CGW 13 may also place non-rewrite target ECUs 19, excluding ECUs 19 capable of communicating with the rewrite target ECU 19, in a situation where the rewrite target ECU 19 can execute application control by rewriting an application program. If all ECUs 19 are in a stopped or sleep state, and if a rewrite condition is met, such as when the vehicle reaches a predetermined location or the current time reaches a predetermined time, the CGW 13 may transition the rewrite target ECUs 19 from a stopped or sleep state to an active state.

[0616] CGW13 can also group the rewrite object ECU19 or non-rewrite object ECU19 based on any one of the starting power supply (+B power supply system ECU, ACC system ECU, IG system ECU), domain group (body system, driving system, multimedia system), and synchronization timing, and make the rewrite object ECU19 start up in groups, or make the non-rewrite object ECU19 stop or sleep in groups.

[0617] Alternatively, the CGW 13 may be configured to perform power control on a bus-by-bus basis. Specifically, if all ECUs 19 connected to a specific bus are determined to be non-rewrite target ECUs 19, the CGW 13 may power off the specific bus, thereby causing all non-rewrite target ECUs 19 connected to the specific bus to transition to a stopped state or a sleep state.

[0618] As described above, the CGW 13 performs power management processing on non-rewriteable ECUs. If the CGW 13 determines that the application can be installed on a rewriteable ECU 19, it places at least one non-rewriteable ECU 19 in a stopped state, a sleep state, or a power-saving mode. This prevents the vehicle battery 40 from running low on battery power during application rewriting. Furthermore, placing the non-rewriteable ECU 19 in a stopped state, a sleep state, or a power-saving mode can suppress increases in communication load.

[0619] (10) File transfer control processing

[0620] Reference Figures 88 to 97 The file transfer control process will be described. The vehicle program rewriting system 1 performs file transfer control processing in the CGW 13. This embodiment describes the process of transmitting rewriting data held by the DCM 12 (equivalent to the first device) to the rewriting target ECU 19 (equivalent to the third device) via the CGW 13 (equivalent to the second device).

[0621] like Figure 88 As shown, the CGW 13 includes a transfer target file determination unit 82a, a first data size determination unit 82b, an acquisition information determination unit 82c, a second data size determination unit 82d, and a split file transfer request unit 82e in the file transfer control unit 82. The transfer target file determination unit 82a uses the analysis result of the rewrite specification data to determine the file including the write data written to the rewrite target ECU 19 as the transfer target file. For example, when the rewrite target ECU 19 is ECU (ID1), ECU (ID2), and ECU (ID3), the transfer target file determination unit 82a determines the file including the write data written to the rewrite target ECU 19 as the transfer target file. Figure 8The CGW rewrite specification data shown acquires ECU information for ECU (ID1), ECU (ID2), and ECU (ID3). Based on the acquired ECU information, a file containing write data is identified as a transfer target file. The transfer target file can specify the address and index at which the file was acquired, as well as the file name.

[0622] If the transmission target file determination unit 82a determines the transmission target file, the first data size determination unit 82b determines the first data size for acquiring the transmission target file. If the transmission target file determination unit 82a determines the transmission target file, the acquisition information determination unit 82c determines the address as the acquisition information for acquiring the transmission target file. In addition, in this embodiment, the address is determined as the acquisition information for acquiring the transmission target file. However, if it is the acquisition information for acquiring the transmission target file, it is not limited to the address and can also be a file name, ECU (ID), etc. The second data size determination unit 82d determines the second data size for distributing the write data to the rewrite target ECU 19. That is, the first data size is the data transmission size from the DCM 12 to the CGW 13, and the second data size is the data transmission size from the CGW 13 to the rewrite target ECU 19.

[0623] When the acquired information determination unit 82c determines the address and the first data size determination unit 82b determines the first data size, the divided file transfer request unit 82e specifies the address and the first data size to the DCM 12 and requests the DCM 12 to transfer the divided files. For example, if the write file to be distributed to the ECU (ID1) has a data size of 1M bytes, the divided file transfer request unit 82e requests that the write data be transferred in 1K-byte increments from address 0x10000000.

[0624] Next, refer to Figures 89 to 97 The following describes the role of the file transfer control unit 82 in the CGW 13. The CGW 13 executes a file transfer control program to perform file transfer control processing.

[0625] If CGW13 determines that it has received the depacketization completion notification signal from DCM12, it will start the file transmission control process. Figure 10 The distribution data package file is divided into data for each ECU and rewrite specification data. When the CGW 13 starts file transfer control, it sends a specified address to the DCM 12 (S1001). Upon receiving the specified address from the CGW 13, the DCM 12 uses the receipt of the specified address as a trigger to transmit the CGW rewrite specification data to the CGW 13. The CGW 13 receives the CGW rewrite specification data from the DCM 12, thereby acquiring the CGW rewrite specification data (S1002).

[0626] When CGW13 obtains the rewrite specification data for the CGW from DCM12, it parses the rewrite specification data for the CGW (S1003) and determines the transfer target file based on the parsed rewrite specification data (S1004, equivalent to the transfer target file determination step). CGW13 determines the address corresponding to the transfer target file (S1005, equivalent to the acquisition information determination step) and determines the first data size corresponding to the transfer target file (S1006, equivalent to the first data size determination step). CGW13 sends the determined address and data size to DCM12 according to the SID (Service Identifier) ​​35, specifies the address and data size for the memory area, and requests DCM12 to transfer the split file (S1007).

[0627] Upon receiving the address and data size from the CGW 13, the DCM 12 analyzes the DCM rewrite specification data and transfers the file corresponding to the address and data size as a separate file to the CGW 13. The CGW 13 receives the separate files from the DCM 12 (S1008). In this case, the CGW 13 may store the received files in the RAM and then in the flash memory.

[0628] CGW13 determines whether the acquisition of all the split files that should be acquired has been completed (S1009). For example, when the data volume of the write file to be distributed to ECU (ID1) is 1M bytes, CGW13 acquires split files of each 1k byte, repeats the acquisition of split files of each 1k byte, and determines whether the acquisition of 1M bytes of data has been completed. If CGW13 determines that the acquisition of all the split files that should be acquired has not been completed (S1009: "No"), it returns to step S1004 and repeats the steps after step S1004. If CGW13 determines that the acquisition of all the files that should be acquired has been completed (S1009: "Yes"), the file transmission control processing ends. In addition, when there are multiple rewrite object ECUs 19, CGW13 repeats the above-mentioned file transmission control processing for each rewrite object ECU 19.

[0629] Specifically, for example, if the target ECUs 19 to be rewritten are ECU (ID1), ECU (ID2), and ECU (ID3), once the CGW 13 has completed the write data distribution to ECU (ID1), it will then perform file transfer control processing on ECU (ID2). Once the CGW 13 has completed the write data distribution to ECU (ID2), it will then perform file transfer control processing on ECU (ID3). Furthermore, the CGW 13 may perform transfer control processing on multiple target ECUs 19 sequentially or in parallel.

[0630] exist Figure 90 In the figure, it indicates that in the memory of DCM12, for example, the write data file of ECU (ID1) is stored at addresses "1000" to "3999", the write data file of ECU (ID2) is stored at addresses "4000" to "6999", and the write data file of ECU (ID3) is stored at addresses "7000" to "7999".

[0631] In this case, if Figure 91 As shown, upon receiving the unpacking completion notification signal from DCM12, CGW13 sends address "0000" to DCM12 and retrieves the rewrite specification data from DCM12. Specifically, upon determining that the reception of address "0000" is a request to retrieve rewrite data for the CGW, DCM12 transmits the rewrite specification data for the CGW to CGW13. CGW13 specifies ECU (ID1) as the destination for write data transmission, address "1000" and data size "1k bytes," and retrieves from DCM12 a split file containing the write data for ECU (ID1) stored at addresses "1000" to "1999." Upon receiving the split file from DCM12, CGW13 distributes the write data contained in the split file to ECU (ID1).

[0632] CGW13 then similarly designates ECU (ID1) as the target for write data transfer, specifying address "2000" and data size "1k byte." It then retrieves from DCM12 a split file containing the write data for ECU (ID1) stored at addresses "2000" to "2999." Upon receiving the split file from DCM12, CGW13 distributes the write data contained in the split file to ECU (ID1). CGW13 repeatedly retrieves split files from DCM12 in 1k-byte increments and distributes the write data contained in the split files to ECU (ID1) until writing of the write data to ECU (ID1) is complete. Specifically, upon receiving a 1k-byte chunk of write data from DCM12, CGW13 sends that 1k-byte chunk to ECU19, the target ECU. Once transmission to ECU19 is complete, CGW13 retrieves the next 1k-byte chunk of write data from DCM12. CGW13 repeats this process until writing is complete.

[0633] If the write data is successfully written to ECU (ID1), CGW 13 designates ECU (ID2) as the destination for the write data, specifies address "4000" and data size "1 kilobyte," and retrieves from DCM 12 the split files containing the write data for ECU (ID2) stored at addresses "4000" to "4999." Upon receiving the split files from DCM 12, CGW 13 distributes the write data contained in the split files to ECU (ID2).

[0634] If the write data is successfully written to ECU (ID2), CGW 13 designates ECU (ID3) as the destination for the write data, specifies address "7000" and data size "1 kilobyte," and retrieves from DCM 12 the split files containing the write data for ECU (ID2) stored at addresses "7000" to "7999." Upon receiving the split files from DCM 12, CGW 13 distributes the write data contained in the split files to ECU (ID2).

[0635] As described above, the CGW 13 performs file transfer control processing, identifies the transfer target file based on the results of analyzing the rewrite specification data, and determines the address and data size corresponding to the transfer target file. The CGW 13 specifies this address and data size to the DCM 12, requests the DCM 12 to transfer the split files obtained by dividing the transfer target file, and then receives the split files from the DCM 12. This allows the write data to be distributed to the ECU 19 while the DCM 12's memory is storing the large amount of write data. This eliminates the need for the CGW 13 to prepare memory for storing large files, reducing the CGW 13's memory capacity.

[0636] Here, the relationship between the data volume of the split file transmitted from the DCM 12 to the CGW 13 and the data volume of the write file distributed from the CGW 13 to the rewrite target ECU 19 will be described. Figure 92 As shown, the case where the data size of the split file transmitted from DCM12 to CGW13 is 1k bytes is described, but the relationship between the data size of the split file transmitted from DCM12 to CGW13 and the data size of the write file distributed from CGW13 to the rewrite target ECU19 can also be arbitrary.

[0637] For example, if the target ECU 19 receives write data in 4kbyte increments due to CAN communication requirements, the CGW 13 distributes the write file data size to the target ECU 19 in 4kbyte increments. In this case, if the data size of the split files transferred from the DCM 12 to the CGW 13 is 1kbyte, the CGW 13 will receive four split files from the DCM 12 and then distribute 4kbyte files to the target ECU 19. In other words, the data size of the split files transferred from the DCM 12 to the CGW 13 is smaller than the data size of the write file distributed from the CGW 13 to the target ECU 19. This relationship allows the CGW 13 to minimize the increase in memory capacity while simultaneously acquiring split files from the DCM 12 and distributing write data to the target ECU 19.

[0638] Specifically, if the data size of the split files transferred from the DCM 12 to the CGW 13 is 4 kilobytes, then in order to concurrently retrieve the split files from the DCM 12 and distribute the write data to the target ECU 19, the CGW 13's memory capacity must be 8 kilobytes. By limiting the data size of the split files transferred from the DCM 12 to the CGW 13 to 1 kilobyte, it is possible to concurrently retrieve the split files from the DCM 12 and distribute the write data to the target ECU 19 without requiring the CGW 13's memory capacity to 8 kilobytes. For example, by pre-assigning 5 kilobytes of memory to the CGW 13, the CGW 13 distributes the 4 kilobytes retrieved from the DCM 12 to the target ECU 19 and then retrieves the next kilobyte from the DCM 12. Furthermore, after the CGW 13 has completed distributing the 4 kilobytes to the target ECU 19, it retrieves the next kilobyte from the DCM 12.

[0639] On the other hand, for example, if the target ECU 19 adopts a specification for receiving write data in 128-byte increments due to CAN communication issues, the CGW 13 distributes the write data to the target ECU 19 in 128-byte increments. In this case, if the data size of the split files transferred from the DCM 12 to the CGW 13 is 1kbyte, the CGW 13 will receive one split file from the DCM 12 and then distribute it to the target ECU 19 in 128-byte increments. In other words, the data size of the split files transferred from the DCM 12 to the CGW 13 is larger than the data size of the write file distributed from the CGW 13 to the target ECU 19. For example, if the CGW 13 has a pre-reserved memory capacity of 2kbytes, the CGW 13 distributes the 1kbyte received from the DCM 12 to the target ECU 19 in 128-byte increments and then receives the next 1kbyte from the DCM 12. Furthermore, after the CGW 13 completes eight 128-byte distributions to the target ECU 19, it receives the next 1kbyte from the DCM 12.

[0640] In this manner, the data size of the divided files transferred from the DCM 12 to the CGW 13 can be fixed (e.g., 1 kilobyte), while the data size of the write files distributed from the CGW 13 to the target ECU 19 can be made variable based on the specifications of the target ECU 19. Alternatively, the CGW 13 can determine the data size to be distributed to the target ECU 19 using, for example, the data transfer size for each ECU specified in the rewrite specification data.

[0641] The CGW 13 sends a transfer request to the DCM 12, requesting the DCM 12 to transfer the divided files. There are two methods for requesting the DCM 12 to transfer the divided files: a first request method and a second request method. Upon completing reception of the write data, the rewrite target ECU 19 sends a reception completion notification to the CGW 13 indicating completion of reception of the write data. Upon completing writing of the write data, the rewrite target ECU 19 sends a write completion notification to the CGW 13 indicating completion of writing the write data.

[0642] use Figure 93 The first distribution method will be described. Upon receiving a split file from the DCM 12, the CGW 13 distributes the received split file as write data to the rewrite target ECU 19. Upon receiving the write data, the rewrite target ECU 19 sends a reception completion notification to the CGW 13 and begins writing the write data. Upon receiving the write data reception completion notification from the rewrite target ECU 19, the CGW 13 sends a transfer request to the DCM 12, requesting the DCM 12 to transfer the next split file. Upon receiving the next split file from the DCM 12, the CGW 13 distributes the received next split file as write data to the rewrite target ECU 19.

[0643] Thus, in the first distribution method, the CGW 13 receives the next write data from the DCM 12 and distributes it to the target ECU 19, without waiting for the target ECU 19 to complete writing the write data. Therefore, in the first distribution method, if the target ECU 19 has not completed writing the write data, even if the CGW 13 receives the next split file from the DCM 12 and distributes the next write data to the target ECU 19, the target ECU 19 may not receive the next write data. However, if the target ECU 19 completes writing the write data, it can quickly receive the next split file from the DCM 12 and distribute the next write data to the target ECU 19.

[0644] use Figure 94The second distribution method will be described. When CGW13 receives a split file from DCM12, it distributes the received split file as write data to the rewrite target ECU19. When the rewrite target ECU19 completes receiving the write data, it sends a reception completion notification to CGW13 and begins writing the write data. When the rewrite target ECU19 completes writing, it sends a write completion notification to CGW13. When CGW13 receives the write completion notification from the rewrite target ECU19, it sends a transfer request to DCM12, requesting the transfer of the next split file. When CGW13 receives the next split file from DCM12, it distributes the received next split file as write data to the rewrite target ECU19.

[0645] Thus, in the second distribution method, the CGW 13 waits for the target ECU 19 to complete writing the write data before receiving the next write data from the DCM 12 and distributing it to the target ECU 19. Therefore, in the second distribution method, while it takes time for the CGW 13 to receive the next split file from the DCM 12, it can request the DCM 12 to transfer the split file after the target ECU 19 has completed writing the write data. Therefore, by receiving the next split file from the DCM 12 and distributing the next write data to the target ECU 19, the next write data can be reliably delivered to the target ECU 19.

[0646] In addition, CGW13 distributes the write data to the rewrite target ECU19 through SID34, 36, 37. As a method of distributing the write data to the rewrite target ECU19, there are a first distribution method and a second distribution method. In the first distribution method, if Figure 95 As shown in FIG, CGW13 divides the write data to be distributed into sections according to the specified data amount (for example, 1k bytes) and distributes them. Figure 96 As shown, CGW13 does not divide the write data to be distributed but distributes it uniformly. CGW13 selects either the first distribution method or the second distribution method based on the SID34 initially distributed to the rewrite target ECU19. Figure 97 As shown, the CGW 13 confirms the reception of the write data of the rewrite target ECU 19 by receiving the ACK (SID74) for the SID37 last distributed to the rewrite target ECU 19. The ACK for the SID37 is equivalent to the Figure 93 and Figure 94The above-mentioned notification of completion of receiving write data. That is, in the first distribution method, when the CGW 13 receives the ACK for the last distribution of SID 37 to the rewrite target ECU 19, it increments the address of the next write data by 1, and simultaneously with the distribution of the next write data to the rewrite target ECU 19, further obtains the next write data from the DCM 12.

[0647] In addition, the address and the file are associated in the rewriting specification data for DCM. However, as a method of associating the address and the file, for example, a folder structure can be designed to store the specification data in folder 1, store file 1 in folder 2, and store file 2 in folder 3 for management. Alternatively, the files can be managed in the order of the file names. Figure 10 In the unpacking shown, the rewriting specification data for DCM and CGW are stored in folder 1, the authenticator and differential data of ECU (ID1) are stored in folder 2, and the authenticator and differential data of ECU (ID2) are stored in folder 3 for management.

[0648] Furthermore, if the CGW 13 interrupts the distribution of write data to the target ECU 19 due to a communication interruption or other reason, the CGW 13 obtains information from the target ECU 19 that can identify the address where the write data was completed, and requests the DCM 12 to transfer a split file containing the write data from the time when the write was not completed. Alternatively, the CGW 13 may request the DCM 12 to transfer a split file containing the write data from the start.

[0649] As described above, the CGW 13 performs file transfer control processing, identifies a file containing write data to be written to the rewrite target ECU 19 as a transfer target file, determines the address and first data size for acquiring the transfer target file, requests the DCM 12 to transfer the divided files, and then transmits the divided files from the DCM 12. The write data is then distributed to the rewrite target ECU. This allows efficient transmission of write data from the DCM 12 to the CGW 13 and distribution of write data from the CGW 13 to the rewrite target ECU 19.

[0650] (11) Distribution control processing of write data

[0651] Reference Figures 98 to 108 The write data distribution control process will be described. Vehicle program rewriting system 1 performs write data distribution control in CGW 13. CGW 13 sends write data to ECU 19 via a bus within the vehicle, and therefore performs write data distribution control to prevent excessive bus load during write data distribution.

[0652] like Figure 98As shown, it is assumed that the +B power system ECU, the ACC system ECU, and the IG system ECU are connected to the same bus. In this case, in the +B power state, only the +B power system ECU is active, while the ACC system ECU and the IG system ECU are deactivated. Therefore, only vehicle control data from the +B power system ECU is transmitted on the bus. In the ACC power state, the +B power system ECU and the ACC system ECU are active, while the IG system ECU is deactivated. Therefore, vehicle control data from the +B power system ECU and the ACC system ECU is transmitted on the bus. In the IG power state, the +B power system ECU, the ACC system ECU, and the IG system ECU are active, so vehicle control data from the +B power system ECU, the ACC system ECU, and the IG system ECU are transmitted on the bus. In other words, the amount of vehicle control data transmitted increases in the order of IG power state, ACC power state, and +B power state.

[0653] like Figure 99 As shown, the CGW 13 includes a first correspondence determination unit 83a, a second correspondence 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 for writing data.

[0654] The first correspondence determination unit 83a determines a first correspondence indicating the relationship between the power supply state and the transfer allowance of the bus based on the analysis result of the rewriting specification data. Figure 100 The bus load table is shown. The transmission capacity is the value of the transmission load that can be used to send and receive data without causing data conflicts or delays. The bus load table is a table that shows the correspondence between power supply status and bus transmission capacity, and is defined for each bus. The transmission capacity is the total amount of vehicle control data and write data that can be transmitted relative to the maximum transmission capacity.

[0655] exist Figure 100 In the example, the transmission allowance of the first bus is "80%" relative to the maximum transmission allowance, so CGW13 allows "50%" relative to the maximum transmission allowance as the transmission allowance of vehicle control data in the IG power state, and allows "30%" relative to the maximum transmission allowance as the transmission allowance of write data. In addition, for the first bus, CGW13 allows "30%" relative to the maximum transmission allowance as the transmission allowance of vehicle control data in the ACC power state, and allows "50%" relative to the maximum transmission allowance as the transmission allowance of write data. In addition, for the first bus, CGW13 allows "20%" relative to the maximum transmission allowance as the transmission allowance of vehicle control data in the +B power state, and allows "60%" relative to the maximum transmission allowance as the transmission allowance of write data. As Figure 100 As shown, the second bus and the third bus are also defined in the same manner.

[0656] The second correspondence determination unit 83b determines a second correspondence indicating the relationship between the bus to which the rewriting target ECU 19 belongs and the power supply system based on the analysis result of the rewriting specification data, and determines Figure 101 The rewriting target ECU affiliation table is a table showing the buses and power supply systems to which the rewriting target ECU 19 belongs.

[0657] exist Figure 101 In the example shown, the CGW 13 connects the first rewrite target ECU 19 to the first bus and activates it in any of the +B, ACC, and IG power states. Therefore, the first rewrite target ECU 19 is identified as the +B power system ECU. Furthermore, the CGW 13 connects the second rewrite target ECU 19 to the second bus and deactivates it in the +B power state but activates it in the ACC and IG power states. Therefore, the second rewrite target ECU 19 is identified as the ACC system ECU. Furthermore, the CGW 13 connects the third rewrite target ECU 19 to the third bus and deactivates it in the +B and ACC power states but activates it in the IG power state. Therefore, the third rewrite target ECU 19 is identified as the IG system ECU.

[0658] CGW13 use Figure 8 The data of "connection bus" and "connection power supply" in the rewriting specification data shown above can be used to determine which bus and power supply system the rewriting target ECU 19 is connected to. In addition, if this information can be determined, it is not necessarily necessary to store it in the form of a table.

[0659] Based on the results of the first and second correspondence determinations, the transmission allowance determination unit 83c determines the transmission allowance for the bus to which the rewriting target ECU 19 belongs, i.e., the transmission allowance corresponding to the vehicle power state at the time of the program update. Specifically, the transmission allowance determination unit 83c uses the second correspondence, i.e., the rewriting target ECU affiliation table, to determine the bus to which the rewriting target ECU 19 belongs, and uses the first correspondence, i.e., the bus load table, to determine the transmission allowance for each power state for the determined bus.

[0660] The distribution frequency determination unit 83d uses a predetermined correspondence between power state and write data distribution frequency to determine the write data distribution frequency corresponding to the power state at installation. Specifically, the distribution frequency determination unit 83d uses the bus load table to determine the transmission allowance allocated for write data distribution within the transmission allowance determined by the transmission allowance determination unit 83c, thereby determining the write data distribution frequency. For example, the distribution frequency determination unit 83d determines that the bus to be rewritten ECU 19 belongs to the first bus, that the power state at installation is the IG power state, and that the transmission allowance is set to "80%." Within this allowance, the transmission allowance allocated for write data distribution is set to "30%." This determines the write data distribution frequency. The transmission allowance allocated for write data distribution corresponds to the transmission restriction information.

[0661] The bus load measurement unit 83e measures the bus load of the bus to which the rewrite target ECU 19 belongs. The bus load measurement 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 write data based on the distribution frequency determined by the distribution frequency determination unit 83d.

[0662] Next, refer to Figures 102 to 108 The following describes the role of the write data distribution control unit 83 in the CGW 13. The CGW 13 executes a write data distribution control program to perform write data distribution control processing.

[0663] If CGW13 receives the unpacking completion notification signal from DCM12, it starts the distribution control process of the write data. CGW13 obtains the rewrite specification data for CGW from DCM12 (S1101), and determines the bus load table and the rewrite object ECU belonging table (S1102) based on the rewrite specification data for CGW. CGW13 determines the bus to which the rewrite object ECU19 belongs based on the rewrite object ECU belonging table (S1103). CGW13 determines the transmission allowance corresponding to the bus to which the rewrite object ECU19 belongs, that is, the power state of the vehicle when the update is performed, based on the bus load table. Moreover, CGW13 determines the distribution frequency of the write data in consideration of the determined transmission allowance (S1104, equivalent to the distribution frequency determination step). For example, when distributing write data to the first rewrite object ECU19, i.e., ECU (ID1), while the vehicle is driving, CGW13 refers to the transmission allowance of the first bus under the IG power state. In Figure 100In the example shown, the transmission allowance for the first bus in the IG power state is 80%, of which 50% is allowed for vehicle control data and 30% is allowed for write data. The transmission allowances are ultimately values ​​for example purposes only; numerical values ​​should be set within the allowable range of the applicable communication standards.

[0664] Since the CAN specification of 500 [kbps] is about 250 [μs] per frame, if four interruptions occur within one second, four frames are generated, and the bus load is 100%. CGW13 determines the distribution frequency of write data by determining the interruptions generated on the bus. CGW13 starts measuring the number of frames received per unit time, starts measuring the bus load (S1105), determines whether the measured bus load exceeds the transmission allowable amount (S1106), and sets the distribution interval. The distribution interval refers to the time interval from the distribution of write data to the rewrite target ECU19 in CGW13, receiving the write completion notification (ACK) from the rewrite target ECU19, to sending the next write data to the rewrite target ECU19.

[0665] If the CGW 13 determines that the measured bus load does not exceed the transmission allowance (S1106: No), it sets the distribution interval of the write data to the preset minimum interval, such as Figure 103 As shown, the distribution of write data to the rewrite target ECU 19 begins (S1107, corresponding to the distribution control step). Specifically, the CGW 13 sets the distribution interval of one frame on the CAN to the preset minimum interval and begins distributing write data to the rewrite target ECU 19. Note that one frame on the CAN contains 8 bytes of write data. Furthermore, one frame on the CAN FD (CAN with Flexible Data-Rate) contains 64 bytes of write data.

[0666] On the other hand, if CGW13 determines that the measured bus load exceeds the transmission allowance (S1106: "Yes"), it calculates the interval in which the bus load does not exceed the transmission allowance (S1108) and sets the distribution interval of the write data to the calculated interval. Figure 104 As shown, distribution of write data to the rewriting target ECU 19 is started (S1109, corresponding to a distribution control step).

[0667] For example, in the IG power state, the CGW 13 determines whether the bus load exceeds the transfer allowance, i.e., "80%", for the first bus. If it is determined that the bus load does not exceed the transfer allowance, the CGW 13 sets the distribution interval T1 in which the transfer allowance of the write data is "30%". Figure 100As shown in the bus load table, CGW13 uses the transmission allowance of write data in the first bus, i.e., "30%", in the IG power state to set the distribution interval T1. CGW13 sets the distribution interval T1 to be the maximum transmission allowance allowed. In addition, CGW13 can also measure the bus load by converging the measurement object on the frame of write data, and determine whether the bus load based on the write data exceeds the transmission allowance of "30%". If CGW13 determines that the bus load exceeds the transmission allowance, it changes the distribution interval T2 (>T1) to a value where the bus load does not exceed the transmission allowance based on the amount by which the bus load exceeds the transmission allowance. In this way, after obtaining the write data from DCM12, CGW13 waits until the set distribution interval is reached, and then distributes the write data to the rewrite object ECU19.

[0668] When the CGW 13 begins distributing write data to the rewrite target ECU 19, it determines whether the distribution of write data to the rewrite target ECU 19 is complete, and continuously determines whether the measured bus load exceeds the transmission allowance (S1110, S1011). If the CGW 13 determines that the measured bus load does not exceed the transmission allowance (S1111: "No"), the distribution interval of the write data is set to the pre-set minimum interval, and the distribution interval of the write data to the rewrite target ECU 19 is changed (S1112). On the other hand, if the CGW 13 determines that the measured bus load exceeds the transmission allowance (S1111: "Yes"), the interval during which the bus load does not exceed the transmission allowance is calculated (S1113), the distribution interval of the write data is set to the calculated interval, and the distribution interval of the write data to the rewrite target ECU 19 is changed (S1114).

[0669] If the CGW 13 determines that the write data has been distributed to the target ECU 19 (S1110: YES), it stops measuring the number of frames received per unit time, stops measuring the bus load (S1115), and ends the write data distribution control process. If there are multiple target ECUs 19, the CGW 13 performs the write data distribution control process for installation to all target ECUs 19.

[0670] As described above, the CGW 13 performs write data distribution control processing, using a predetermined correspondence between power supply status and write data distribution frequency to determine the frequency of write data distribution to the target ECU 19. This frequency is then used to control the distribution of write data. This reduces data conflicts and delays during installation. Furthermore, write data distribution can coexist without interfering with vehicle control data distribution on the same bus.

[0671] In the above, the CGW 13 is described as determining a bus load table based on the analysis results of the rewrite specification data. However, a pre-stored bus load table is also possible. Furthermore, the CGW 13 is described as determining a table of rewrite target ECUs based on the analysis results of the rewrite specification data. However, a pre-stored table of rewrite target ECUs is also possible.

[0672] It is also possible to make the amount of data written to be distributed relatively small when the vehicle is in a running state, and to make the amount of data written to be distributed relatively large when the vehicle is in a parked state. Figure 105 As shown, when the IG power is on while the vehicle is running, CGW13 sends CAN frames through the IG system ECU, ACC system ECU, and +B power system ECU, making the transmission volume of application data such as vehicle control and diagnosis relatively large, and thus making the distribution volume of write data relatively small. Figure 106 As shown, when the IG power supply is disconnected during parking, the CGW 13 transmits CAN frames only to the +B power system ECU. This reduces the amount of application data transmitted for vehicle control and diagnostics, and increases the amount of write data distributed. Specifically, the CGW 13 adjusts the amount of write data distributed within the available capacity that does not hinder the transmission of application data for vehicle control and diagnostics.

[0673] In addition, you can also Figure 107 As shown, in CGW13, when an event frame is sent from the rewrite object ECU19, the frequency of interruptions increases by receiving the event frame, and the bus load increases, so the distribution amount of write data is relatively small. When an event frame is not sent from the rewrite object ECU19, the distribution amount of write data is relatively large.

[0674] In addition, you can also Figure 108 As shown, in the vehicle system, when it is determined that the CGW 13 is distributing write data, the bus load is reduced by extending the transmission interval of application data such as vehicle control and diagnosis to the maximum allowed interval. In the CGW 13, the vehicle system can also extend the transmission interval of application data to reduce the bus load, thereby distributing a relatively large amount of write data.

[0675] The bus load table embedded in the rewrite specification data is uniformly set regardless of the vehicle manufacturer's model, grade, etc. This is because if ECU configurations vary significantly depending on the vehicle model, grade, etc., the bus load will also vary significantly. Setting an optimal bus load table for each vehicle model, grade, etc. would require time and effort for verification, which is cumbersome and laborious. Therefore, such cumbersomeness is avoided.

[0676] Similar to the case where the vehicle is installed while it is moving, as described above, distribution control processing for write data is also performed when the vehicle is installed while it is parked. In this case, if the ECU 19 to be rewritten is a +B power system ECU, the update can also be performed in the +B power state, so the transmission allowance for the +B power state in the bus load table is referenced. On the other hand, if the ECU 19 to be rewritten is an IG system ECU, the installation is performed in the IG power state, so the transmission allowance for the IG power state in the bus load table is referenced. Here, for example, if the ECU 19 to be rewritten is an ACC system ECU, the installation can also be performed in the IG power state. In this case, the transmission allowance for the IG power state in the bus load table is referenced. In addition, the structure of the bus load table and the table to which the rewrite target ECU belongs has been described, but as long as the distribution frequency of write data for each power state can be determined, any table can be stored.

[0677] (12) Activation request instruction processing

[0678] Reference Figures 109 to 111 The activation request instruction process will be described. The vehicle program rewriting system 1 performs activation request instruction processing within the CGW 13. The CGW 13 issues activation requests to multiple rewriting target ECUs 19 that have completed application program rewriting, validating the rewritten programs. In this embodiment, the CGW 13 analyzes CGW rewriting specification data to understand the status of the group of rewriting target ECUs 19. The CGW 13 only issues activation requests when the vehicle is parked and does not issue activation requests while the vehicle is moving.

[0679] like Figure 109 As shown, the CGW 13 includes a rewrite target determination unit 84a, a rewrite completion determination unit 84b, an activation executable determination unit 84c, and an activation request instructing unit 84d in its activation request instruction unit 84. The rewrite target determination unit 84a identifies multiple rewrite target ECUs 19 that are cooperatively controlled. Once the rewrite target determination unit 84a identifies multiple rewrite target ECUs 19, the rewrite completion determination unit 84b determines whether program rewrite has been completed for all of the identified multiple rewrite target ECUs 19.

[0680] If the rewrite completion determination unit 84b determines that program rewriting is complete in all of the multiple rewrite target ECUs 19, the activation executable determination unit 84c determines whether activation can be executed. If the user has consented to the activation and the vehicle is parked, the activation executable determination unit 84c determines that activation can be executed.

[0681] If the activation executable determination unit 84c determines that activation can be performed, the activation request indication unit 84d indicates an activation request. Specifically, after indicating a switch request for the new side, the activation request indication unit 84d indicates a reset request, monitors the session transfer timeout, or monitors the internal reset of the rewrite object ECU 19, thereby indicating an activation request. In a double-sided memory ECU or a single-sided suspended memory ECU, the application is activated by starting it on the new side (non-operation side) where the application is written. On the other hand, in a single-sided independent memory ECU, the application is activated by restarting. In addition, the rewrite object ECU 19 can also be configured to reset itself after indicating a switch request for the new side, regardless of the activation request.

[0682] Next, refer to Figure 110 and Figure 111 The following describes the role of the activation request instruction unit in the CGW 13. The CGW 13 executes an activation request instruction program and performs activation request instruction processing.

[0683] If CGW13 starts the instruction processing of the activation request, it determines multiple rewrite target ECUs 19 (S1201, equivalent to the rewrite target determination step). Specifically, CGW13 determines the rewrite target ECU 19 by referring to the ECU (ID) recorded in the rewrite specification data. CGW13 determines whether the rewrite of the application is completed in all of the multiple rewrite target ECUs 19 that have been determined (S1202, equivalent to the rewrite completion determination step). CGW13, for example, installs the rewrite target ECUs 19 in sequence according to the order of the ECUs (IDs) recorded in the rewrite specification data. If the installation of the last recorded ECU (ID) is completed, it is determined that the writing is completed in all of the rewrite target ECUs 19.

[0684] If CGW13 determines that the rewriting of the application has been completed in all of the multiple rewriting object ECUs 19 identified (S1202: "Yes"), it determines whether activation can be performed (S1203, equivalent to the activation executable determination step). Specifically, CGW13 determines whether the user's consent to the update has been obtained before, whether the vehicle is in a parked state, etc. If these conditions are met, it determines that activation can be performed. User consent can also be consent for the entire update process, or consent for activation. If CGW13 determines that activation can be performed (S1203: "Yes"), it then indicates an activation request to multiple rewriting object ECUs 19 at the same time (equivalent to the activation request indication step). Here, it is assumed that ECU (ID1), ECU (ID2) and ECU (ID3) are the rewriting object ECUs 19 of the same group for explanation.

[0685] If CGW13 determines that activation can be performed for ECU (ID1), ECU (ID2) and ECU (ID3), it starts the instruction processing of the activation request. If CGW13 starts the instruction processing of the activation request, it instructs the rewrite object ECU19 to request the switch to the new surface (S1204). CGW13 requests the power management ECU20 to switch the IG power from off to on (S1205). Although the vehicle is in a parked state and the IG switch 42 is in an off state, CGW13 switches the IG power from off to on in order to perform activation. In addition, when CGW13 performs activation after installation, since the IG power is in an on state, S1205 is not performed, and a start request (wake-up request) is made to the rewrite object ECU19 in a sleep state.

[0686] CGW13 sends a software reset request to the rewrite target ECU19, instructing the rewrite target ECU19 to make the software reset request (S1206). If the rewrite target ECU19 adopts a specification corresponding to the software reset request, upon receiving the software reset request from CGW13, it resets the software and restarts, activating the application. In the case where the rewrite target ECU19 is a single-sided independent memory ECU, the rewrite target ECU19 restarts using the new application, switching from the old application to the new application. In the case where the rewrite target ECU19 is a single-sided suspended memory ECU or a double-sided memory ECU, the rewrite target ECU19 updates the operating side information (side A or side B) stored in the flash memory, switches the side where the new application is written to the operating side, and thereby switches from the old application to the new application.

[0687] The CGW 13 requests the power management ECU 20 to switch the IG power supply from on to off and back again, instructs the target ECU 19 to reset the power supply, and instructs the target ECU 19 to restart (S1207). Even if the target ECU 19 uses specifications that do not support software reset requests, if the IG power supply is switched from on to off and back again, it will reset itself and restart, activating the application. In this case, if the target ECU 19 is a single-sided independent memory ECU, the target ECU 19 restarts using the new application, switching from the old application to the new application. If the target ECU 19 is a single-sided suspended memory ECU or a dual-sided memory ECU, the target ECU 19 updates the operating side information (side A or side B) stored in the flash memory, switching the side with the new application to the operating side, thereby switching from the old application to the new application. Furthermore, the CGW 13 monitors the session transfer timeout ( S1208 ), and monitors the internal reset of the rewrite target ECU 19 ( S1209 ).

[0688] Specifically, if the target ECU 19 uses specifications that do not support software reset requests, the CGW 13 cannot instruct activation even if it sends a software reset request to the target ECU 19. Therefore, the target ECU 19, which does not support software reset requests, is activated by instructing the target ECU 19 to request a power reset. For example, IG system ECUs, such as the engine ECU, are designed to reset upon power on / off, and therefore often do not support software reset requests. From the perspective of the target ECU 19, activation (starting a new program) occurs in response to any of the following: a software reset request from the CGW 13, a power reset request from the CGW 13, a session transfer timeout, or an internal reset.

[0689] When the CGW 13 instructs the ECU 19 to be rewritten, responding to a software reset request, it forcibly resets itself and activates. However, when the CGW 13 instructs the ECU 19 to be rewritten, responding to a power reset request, the ACC and IG system ECUs are not forcibly powered. Instead, they are reset and activated the next time power is supplied. Unlike the ACC and IG system ECUs, the +B power system ECU 19 is always powered, so it is activated by a session transfer timeout or internal reset. The activation method for each ECU 19 is specified in the rewrite specification data.

[0690] When the CGW13 receives notification from all the ECUs 19 to be rewritten that the new application has been successfully started, it sends a switching completion notification to the DCM12 (S1210). The DCM12 notifies the central unit 3 that activation of the updated program has been completed. The CGW13 requests the power management ECU 20 to switch the IG power from on to off, completing the activation synchronization instruction process. When the CGW13 switches the IG power from off to on through user operation, the program version, startup interface, etc. of each ECU are sent to the DCM12. The DCM12 notifies the central unit 3 of the information on each ECU 19 received from the CGW13. Here, when the DCM12 notifies the central unit 3 of the completion of activation, it may also send ECU configuration information including the program version and interface information of each ECU to the central unit 3. Figure 111 This shows a case where the rewriting target ECU 19 is a double-sided memory ECU or a single-sided suspended memory ECU.

[0691] As described above, the CGW 13 prevents multiple rewrite target ECUs 19 that have completed application program rewrite from switching from the old program to the new program at their own unique timing by performing activation request instruction processing. This ensures that the timing of switching from the old program to the new program in these multiple rewrite target ECUs 19 is appropriately aligned. In other words, the program versions of the multiple cooperating rewrite target ECUs 19 become mismatched, preventing problems from occurring during the coordinated processing.

[0692] (13) Activated execution control processing

[0693] Reference Figures 112 to 114 The activation execution control process is described. The activation execution control process is a process performed by the rewriting target ECU 19 that has received an activation request from the CGW 13, accompanied by the CGW 13 performing the aforementioned (12) activation request instruction process. The vehicle program rewriting system 1 performs the activation execution control process in the rewriting target ECU 19. Here, the rewriting target ECU 19 has multiple data storage surfaces such as a single-sided pause-type memory and a double-sided memory. The rewriting target ECU 19 has a first data storage surface and a second data storage surface, and is in a state where the installation of the rewriting data is completed on the non-operating surface (new surface).

[0694] like Figure 112As shown, the ECU 19 includes an operating surface information update unit 107a, an execution condition determination unit 107b, an execution control unit 107c, and a notification unit 107d in the activated execution control unit 107. Upon receiving an activation request from the CGW 13, the operating surface information update unit 107a updates the startup surface determination information (operation surface information) in the flash memory for the next reboot. For example, if side A is currently being booted and a new program is written to side B, the operating surface information update unit 107a updates the operating surface information from side A to side B.

[0695] As execution conditions for activation, the execution condition determination unit 107b determines whether a software reset request has been issued from the CGW 13, whether a power reset request has been issued from the CGW 13 to the power management ECU 20, or whether the interruption of communication with the CGW 13 has lasted for a predetermined time. If any one of these conditions is met, the execution condition determination unit 107b determines that the execution condition for activation has been met. Alternatively, the power detection circuit 36 ​​may detect whether a power reset request has been issued, rather than an instruction from the CGW 13. If the execution condition determination unit 107b determines that the execution condition for activation has been met, the execution control unit 107c switches the startup surface from the old surface (the surface currently in use) to the new surface (the surface not currently in use) based on the application surface information (new surface switching (activation)). The notification unit 107d notifies the CGW 13 of notification information such as the application surface information and version information.

[0696] Next, refer to Figure 113 and Figure 114 The following describes the function of the active execution control unit 107 of the rewrite target ECU 19. The rewrite target ECU 19 executes the active execution control program to perform the active execution control process.

[0697] (13-1) Rewrite Processing

[0698] When the rewrite target ECU 19 begins the rewrite process, it performs pre-rewrite processing such as reading the product number and authentication, which precedes memory erasure (S1301). The rewrite target ECU 19 determines whether it has received rewrite surface information from the center device 3 (S1302). The rewrite target ECU 19 determines whether it has received rewrite surface information based on, for example, whether it has obtained rewrite surface information described in the rewrite specification data included in the distribution data packet from the CGW 13. If the rewrite target ECU 19 determines that it has received rewrite surface information from the center device 3 (S1302: "Yes"), it compares the rewrite surface information with the rewrite surface information (operation surface information) managed by itself to determine whether the two are consistent (S1303). Here, the rewrite surface information is described, for example, in the rewrite specification data sent from the center device 3. For example, when the rewrite surface information managed by itself is that the operating surface is side A and the non-operating surface is side B, if the rewrite surface information recorded in the rewrite specification data indicates the non-operating surface (side B), it is judged that the two are consistent; if the rewrite surface information recorded in the specification data indicates the operating surface (side A), it is judged that the two are inconsistent.

[0699] If the target ECU 19 determines that the two are consistent (S1303: Yes), it performs a memory erase, writes the written data, and verifies (S1304) as a rewrite process, terminating the rewrite process. Verification may include, for example, verifying the integrity of the data written to the flash memory. If the target ECU 19 determines that the two are inconsistent (S1303: No), it sends a negative response to the CGW 13 (S1305), terminating the rewrite process.

[0700] (13-2) Activated execution control processing

[0701] When the target ECU 19 begins active execution control processing, it uses the non-operating surface as the rewriting surface and determines whether rewriting the application program to the rewriting surface has been completed (S1311). If the target ECU 19 determines that rewriting the application program to the rewriting surface has been completed (S1311: "Yes"), it verifies the integrity of the application program written to the flash memory and determines whether the rewritten data is verified to be positive (S1312). If the target ECU 19 determines that the rewritten data is verified to be positive (S1312: "Yes"), it sets the rewrite completion flag of the new surface to "OK" and stores it (S1313).

[0702] The rewrite target ECU 19 then determines whether an activation request has been issued from the CGW 13 (S1314). If the rewrite target ECU 19 determines that an activation request has been issued (S1314: "Yes"), it then determines whether the rewrite completion flag for the new surface is "OK" (S1315). If it determines that the rewrite completion flag for the new surface is "OK" (S1315: "Yes"), it updates the operating surface information (S1316, corresponding to the operating surface information updating step). Specifically, for example, if the operating surface is surface A and the non-operating surface is surface B, and the application program is rewritten to the rewrite surface using surface B as the rewrite surface, the rewrite target ECU 19 updates the operating surface information indicating that the operating surface is surface A and the non-operating surface is surface B to operating surface information indicating that the operating surface is surface B and the non-operating surface is surface A.

[0703] Once the operational information is updated, the target ECU 19 determines whether a software reset request has been received from the CGW 13, whether a power reset request has been issued from the CGW 13 to the power management ECU 20, whether communication with the CGW 13 has been interrupted for a predetermined period of time after the software reset request was issued, and whether activation execution conditions have been met (S1317, corresponding to ...

Claims

1. A vehicle electronic control system comprising: a vehicle master device that distributes update data to an electronic control device to be rewritten; and a vehicle slave device that is the electronic control device to be rewritten and has a first power supply self-holding circuit, wherein: When the vehicle power source is turned off and the first power source self-holding circuit is enabled, the vehicle slave device is supplied with power from the vehicle battery and maintains the activated state. When the vehicle power supply is turned off and the first power supply self-holding circuit is not activated, the vehicle slave device is in a sleep state or a stopped state. The vehicle main device includes: A vehicle power supply determination unit, which determines whether the vehicle power supply is on or off; A rewriting determination unit determines whether the program is being rewritten; a first power self-holding determination unit for determining the necessity of self-holding power in the vehicle slave device when the vehicle power determination unit determines that the vehicle power is off and the rewriting determination unit determines that the program is being rewritten; as well as a power self-holding instruction unit for instructing the vehicle slave device to activate the first power self-holding circuit when the first power self-holding determination unit determines that the vehicle slave device needs to self-hold power; The vehicle slave device includes: an instruction determination unit that determines whether activation of the first power supply self-holding circuit has been instructed from the vehicle master device; and The first power self-holding activating unit activates the first power self-holding circuit when the instruction determining unit determines that the first power self-holding circuit is to be activated. A plurality of the above-mentioned vehicle slave devices are provided, Each of the plurality of vehicle slave devices includes the first power self-holding circuit, and the first power self-holding circuit has a power self-holding function for holding power supplied from the vehicle battery. The vehicle master device instructs each of the plurality of vehicle slave devices to activate the first power supply self-holding circuit.

2. The vehicle electronic control system according to claim 1, wherein: The first power supply self-holding activating unit activates the first power supply self-holding circuit by activating the first power supply self-holding circuit when the first power supply self-holding circuit is stopped.

3. The electronic control system for a vehicle according to claim 1, wherein: The first power supply self-holding activating unit activates the first power supply self-holding circuit by extending an operating period of the first power supply self-holding circuit when the first power supply self-holding circuit is activated.

4. The electronic control system for a vehicle according to claim 1, wherein: The vehicle slave device includes: a first stop condition satisfaction determination unit for determining whether a stop condition for self-holding of power supply is satisfied; and The first power supply self-holding stopping unit stops the first power supply self-holding circuit when the first stop condition satisfaction determination unit determines that the stop condition for power supply self-holding is satisfied.

5. The electronic control system for a vehicle according to claim 4, wherein: The vehicle master device includes an update data distribution unit that distributes update data to an electronic control device to be rewritten. The vehicle slave device includes a program rewriting unit that rewrites the application program by writing update data received from the vehicle master device into the nonvolatile memory. The update data distribution unit distributes the update data to the electronic control device to be rewritten while the first power supply self-holding circuit is enabled by the first power supply self-holding enabling unit. The program rewriting unit rewrites the application program while the first power supply self-holding circuit is enabled by the first power supply self-holding enabling unit.

6. The electronic control system for a vehicle according to claim 5, wherein: The first stop condition satisfaction determination unit determines whether a stop condition for self-maintaining power supply is satisfied based on at least one of occurrence of a timeout and a stop instruction from the vehicle master device.

7. The electronic control system for a vehicle according to claim 4, wherein: The vehicle slave device is a display terminal having a function of accepting a consent operation for rewriting a program. The first stop condition satisfaction determination unit determines whether a stop condition for self-maintaining power supply is satisfied based on at least one of occurrence of a timeout, a user getting off the vehicle, and a stop instruction from the vehicle master device.

8. The electronic control system for a vehicle according to claim 4, wherein: The vehicle slave device is a power supply control device that performs power supply control. The first stop condition satisfaction determination unit determines whether a stop condition for self-maintaining power supply is satisfied based on a stop instruction from the vehicle master device.

9. The vehicle electronic control system according to any one of claims 1 to 8, wherein: The vehicle main device has a second power supply self-holding circuit. The vehicle main device includes: a second power self-holding determination unit for determining the necessity of self-holding power in the vehicle main device when the vehicle power determination unit determines that the vehicle power is off and the rewriting determination unit determines that the program is being rewritten; and The second power supply self-holding activation unit activates the second power supply self-holding circuit when the second power supply self-holding determination unit determines that the vehicle main device needs to self-hold the power supply.

10. The electronic control system for a vehicle according to claim 9, wherein: The second power supply self-holding activation unit activates 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 stopped.

11. The electronic control system for a vehicle according to claim 9, wherein: The second power supply self-holding activating unit activates the second power supply self-holding circuit by extending an operating period of the second power supply self-holding circuit when the second power supply self-holding circuit is activated.

12. The electronic control system for a vehicle according to claim 9, wherein: The vehicle main device includes: a second stop condition satisfaction determination unit for determining whether a stop condition for self-holding of power supply is satisfied; and The second power supply self-holding stopping unit stops the second power supply self-holding circuit when the second stop condition satisfaction determination unit determines that the stop condition for power supply self-holding is satisfied.

13. The electronic control system for a vehicle according to claim 12, wherein: The second stop condition satisfaction determination unit determines whether a stop condition for power self-holding is satisfied based on at least one of a remaining battery level of a vehicle battery, occurrence of a timeout, and completion of rewriting in the electronic control device to be rewritten.

14. A method for controlling a power self-holding operation in a vehicle electronic control system comprising a vehicle master device for distributing update data to an electronic control device to be rewritten and a vehicle slave device which is the electronic control device to be rewritten and has a first power self-holding circuit. When the vehicle power source is turned off and the first power source self-holding circuit is enabled, the vehicle slave device is supplied with power from the vehicle battery and maintains the activated state. When the vehicle power supply is turned off and the first power supply self-holding circuit is not activated, the vehicle slave device is in a sleep state or a stopped state. The above-mentioned power supply self-holding execution control method performs the following steps in the above-mentioned vehicle electronic control system: A vehicle power supply determination step, determining whether the vehicle power supply is on or off; A rewriting determination step is used to determine whether the program is being rewritten; a first power self-holding determination step for determining the necessity of self-holding power in the vehicle slave device when the vehicle power determination step determines that the vehicle power is disconnected and the rewriting determination step determines that the program is being rewritten; a power self-holding instruction step of instructing the vehicle slave device to activate the first power self-holding circuit when it is determined in the first power self-holding determination step that the vehicle slave device needs to self-hold the power; an instruction determination step of determining whether activation of the first power supply self-holding circuit has been instructed from the vehicle master device; and A first power self-holding activation step of activating the first power self-holding circuit when the first power self-holding circuit is determined to be activated in the instruction determination step, A plurality of the above-mentioned vehicle slave devices are provided, Each of the plurality of vehicle slave devices includes the first power self-holding circuit, and the first power self-holding circuit has a power self-holding function for holding power supplied from the vehicle battery. The vehicle master device instructs each of the plurality of vehicle slave devices to activate the first power supply self-holding circuit.

15. A recording medium having a power self-holding execution control program recorded thereon, wherein in a vehicle electronic control system comprising a vehicle master device for distributing update data to an electronic control device to be rewritten and a vehicle slave device which is the electronic control device to be rewritten and has a first power self-holding circuit, When the vehicle power source is turned off and the first power source self-holding circuit is enabled, the vehicle slave device is supplied with power from the vehicle battery and maintains the activated state. When the vehicle power supply is turned off and the first power supply self-holding circuit is not activated, the vehicle slave device is in a sleep state or a stopped state. The execution control program for self-maintaining the power supply causes the vehicle electronic control system to execute the following steps: A vehicle power supply determination step, determining whether the vehicle power supply is on or off; A rewriting determination step is used to determine whether the program is being rewritten; a first power self-holding determination step for determining the necessity of self-holding power in the vehicle slave device when the vehicle power determination step determines that the vehicle power is disconnected and the rewriting determination step determines that the program is being rewritten; a power self-holding instruction step of instructing the vehicle slave device to activate the first power self-holding circuit when it is determined in the first power self-holding determination step that the vehicle slave device needs to self-hold the power; an instruction determination step of determining whether activation of the first power supply self-holding circuit has been instructed from the vehicle master device; and A first power self-holding activation step of activating the first power self-holding circuit when the first power self-holding circuit is determined to be activated in the instruction determination step, A plurality of the above-mentioned vehicle slave devices are provided, Each of the plurality of vehicle slave devices includes the first power self-holding circuit, and the first power self-holding circuit has a power self-holding function for holding power supplied from the vehicle battery. The vehicle master device instructs each of the plurality of vehicle slave devices to activate the first power supply self-holding circuit.

16. A vehicle master device that distributes update data to a vehicle slave device, wherein the vehicle slave device is an electronic control device to be rewritten and has a first power supply self-holding circuit, wherein: When the vehicle power source is turned off and the first power source self-holding circuit is enabled, the vehicle slave device is supplied with power from the vehicle battery and maintains the activated state. When the vehicle power supply is turned off and the first power supply self-holding circuit is not activated, the vehicle slave device is in a sleep state or a stopped state. The vehicle main device includes: A vehicle power supply determination unit, which determines whether the vehicle power supply is on or off; A rewriting determination unit determines whether the program is being rewritten; a first power self-holding determination unit for determining the necessity of self-holding power in the vehicle slave device when the vehicle power determination unit determines that the vehicle power is off and the rewriting determination unit determines that the program is being rewritten; as well as a power self-holding instruction unit for instructing the vehicle slave device to activate the first power self-holding circuit when the first power self-holding determination unit determines that the vehicle slave device needs to self-hold power; A plurality of the above-mentioned vehicle slave devices are provided, Each of the plurality of vehicle slave devices includes the first power self-holding circuit, and the first power self-holding circuit has a power self-holding function for holding power supplied from the vehicle battery. The vehicle master device instructs each of the plurality of vehicle slave devices to activate the first power supply self-holding circuit.

17. A method for controlling power self-holding, wherein a vehicle master device distributes update data to a vehicle slave device, the vehicle slave device being an electronic control device to be rewritten and having a first power self-holding circuit, wherein: When the vehicle power source is turned off and the first power source self-holding circuit is enabled, the vehicle slave device is supplied with power from the vehicle battery and maintains the activated state. When the vehicle power supply is turned off and the first power supply self-holding circuit is not activated, the vehicle slave device is in a sleep state or a stopped state. The above-mentioned power supply self-holding execution control method performs the following steps in the above-mentioned vehicle main device: A vehicle power supply determination step, determining whether the vehicle power supply is on or off; A rewriting determination step is used to determine whether the program is being rewritten; a first power self-holding determination step for determining the necessity of self-holding power in the vehicle slave device when the vehicle power determination step determines that the vehicle power is disconnected and the rewriting determination step determines that the program is being rewritten; as well as a power self-holding instruction step of instructing the vehicle slave device to activate the first power self-holding circuit when it is determined in the first power self-holding determination step that the vehicle slave device needs to self-hold the power; A plurality of the above-mentioned vehicle slave devices are provided, Each of the plurality of vehicle slave devices includes the first power self-holding circuit, and the first power self-holding circuit has a power self-holding function for holding power supplied from the vehicle battery. The vehicle master device instructs each of the plurality of vehicle slave devices to activate the first power supply self-holding circuit.

18. A vehicle master device that distributes update data to a vehicle slave device, wherein the vehicle slave device is an electronic control device to be rewritten and has a first power supply self-holding circuit, wherein: When the vehicle power source is turned off and the first power source self-holding circuit is enabled, the vehicle slave device is supplied with power from the vehicle battery and maintains the activated state. When the vehicle power supply is turned off and the first power supply self-holding circuit is not activated, the vehicle slave device is in a sleep state or a stopped state. The vehicle main device includes: a write data distribution unit for distributing the update data to the vehicle slave device; a rewrite determination unit that determines a rewrite state of the program; and The power self-holding instruction unit instructs the vehicle slave device to activate the first power self-holding circuit before the program rewriting is completed. A plurality of the above-mentioned vehicle slave devices are provided, Each of the plurality of vehicle slave devices includes the first power self-holding circuit, and the first power self-holding circuit has a power self-holding function for holding power supplied from the vehicle battery. The vehicle master device instructs each of the plurality of vehicle slave devices to activate the first power supply self-holding circuit.

19. A recording medium having a power self-holding execution control program recorded thereon, wherein a vehicle master device distributes update data to a vehicle slave device, the vehicle slave device being an electronic control device to be rewritten and having a first power self-holding circuit, wherein: When the vehicle power source is turned off and the first power source self-holding circuit is enabled, the vehicle slave device is supplied with power from the vehicle battery and maintains the activated state. When the vehicle power supply is turned off and the first power supply self-holding circuit is not activated, the vehicle slave device is in a sleep state or a stopped state. The execution control program for self-maintaining the power supply causes the vehicle main device to execute the following steps: a data distribution step of distributing the update data to the vehicle slave device; a rewrite determination step of determining a rewrite status of the program; and a power self-holding instruction step of instructing the vehicle slave device to activate the first power self-holding circuit before the program rewriting is completed; A plurality of the above-mentioned vehicle slave devices are provided, Each of the plurality of vehicle slave devices includes the first power self-holding circuit, and the first power self-holding circuit has a power self-holding function for holding power supplied from the vehicle battery. The vehicle master device instructs each of the plurality of vehicle slave devices to activate the first power supply self-holding circuit.

Images