Vehicle main device, vehicle electronic control system, configuration information rewriting instruction method, and recording medium recording configuration information rewriting instruction program

Abstract

The master device (11) provided by the present application distributes update data received from the center device (3) to the electronic control device (19) to be rewritten, and instructs the electronic control device (19) to write the update data. The master device (11) transmits the software version and the configuration information version as the structure information of the electronic control device (19) to be rewritten to the center device, downloads the rewriting specification data from the center device (3) if it is determined that there is an activity notification related to program update based on the notification from the center device (3), and instructs the electronic control device (19) to be rewritten to perform rewriting based on the overlay of the configuration information using the new configuration information downloaded from the center device (3) if it is determined that the configuration information is rewritten based on the rewriting specification data.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to Japanese Application No. 2019-155687, filed on August 28, 2019, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to electronic control systems for vehicles, main devices for vehicles, rewrite instruction methods based on write-back of configuration information, and rewrite instruction procedures based on write-back of configuration information. Background Technology

[0004] In recent years, with the diversification of vehicle control functions such as driver assistance and autonomous driving, the scale of vehicle control and diagnostic programs in electronic control units (hereinafter referred to as ECUs) has been increasing. Furthermore, with version upgrades based on functional improvements, the opportunities to rewrite (reprogram) ECU programs are also increasing. On the other hand, with the development of communication networks, connected car technology is becoming increasingly widespread. In this context, for example, Patent Document 1 proposes a technology where a vehicle master device is installed on the vehicle side as a relay device. This vehicle master device wirelessly distributes update data received from a central device to the ECU to be rewritten, thereby rewriting the program of the target ECU using OTA (Over-The-Air).

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

[0006] In an ECU being modified, if the structure of the non-volatile memory is changed when writing update data to modify the program, there is a concern that configuration information stored in the non-volatile memory, such as learning values, may not be properly used. Therefore, it is preferable to have a structure that allows for the proper use of configuration information even if the structure of the non-volatile memory is changed when modifying the program of the ECU being modified. Summary of the Invention

[0007] The purpose of this disclosure is to enable the proper use of configuration information after program rewriting, even when the construction of non-volatile memory is changed during program rewriting in the electronic control device of the object being rewritten.

[0008] According to one aspect of this disclosure, the vehicle master device distributes updated data received from the central device to the electronic control unit to be rewritten, and instructs the electronic control unit to write the updated data. If the electronic control unit receives updated data from the vehicle master device, it uses the received updated data to rewrite the program in the non-volatile memory. The electronic control unit stores configuration information in the non-volatile memory. In the vehicle master device, the old configuration information acquisition unit acquires old configuration information from the electronic control unit to be rewritten. The configuration information write-back instruction unit, during or after the electronic control unit to be rewritten is instructing the electronic control unit to write back new configuration information processed from the old configuration information acquired by the old configuration information acquisition unit.

[0009] During or after the electronic control device of the target device is rewriting the program, it is instructed to write back the new configuration information, which has been processed from the old configuration information acquired by the old configuration information acquisition unit. By instructing the electronic control device of the target device to write back the new configuration information, which has been processed from the old configuration information acquired by the old configuration information acquisition unit, during or after the program is being rewritten, the old configuration information can be rewritten into the new configuration information in the electronic control device of the target device. Even if the structure of the non-volatile memory is changed when the program is rewritten in the electronic control device of the target device, the configuration information can still be appropriately used after the application program is rewritten. Attached Figure Description

[0010] The above-mentioned objects, as well as other objects, features, and advantages of this disclosure, will become more apparent from the accompanying drawings and the following detailed description. The accompanying drawings are as follows:

[0011] Figure 1 This is a diagram showing the overall configuration of one implementation method.

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

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

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

[0015] Figure 5 This is a diagram showing how the power cord is connected.

[0016] Figure 6 This diagram illustrates how recompiled data and distribution specification data are packaged.

[0017] Figure 7 This is a diagram representing the rewritten specification data used in DCM.

[0018] Figure 8 This is a diagram representing the rewritten specification data used by CGW.

[0019] Figure 9 This is a diagram representing the distribution specification data.

[0020] Figure 10 This is a diagram illustrating how data packets are unpacked and distributed.

[0021] Figure 11 This is a diagram illustrating the typical operation of an embedded single-sided individual memory.

[0022] Figure 12 This is a diagram illustrating how rewrite operations occur in an embedded single-sided, standalone memory.

[0023] Figure 13 This is a diagram illustrating the typical operation of a downloadable single-sided, standalone memory.

[0024] Figure 14 This is a diagram illustrating the method of rewriting operations in a downloadable single-sided separate memory.

[0025] Figure 15 This is a diagram illustrating the typical operation in an embedded single-sided suspended memory.

[0026] Figure 16 This is a diagram illustrating how rewrite operations occur in an embedded single-sided suspended memory.

[0027] Figure 17 This is a diagram illustrating the typical operation in a download-type single-sided suspended memory.

[0028] Figure 18 This is a diagram illustrating the method of overwrite operations in a download-type single-sided suspended memory.

[0029] Figure 19 This is a diagram illustrating the typical operation of an embedded double-sided memory.

[0030] Figure 20 This is a diagram illustrating how rewrite operations occur in an embedded double-sided memory.

[0031] Figure 21 This is a diagram illustrating the typical operation of a downloadable double-sided memory.

[0032] Figure 22 This is a diagram illustrating the rewrite operation in a downloadable double-sided memory.

[0033] Figure 23 This is a diagram illustrating how to rewrite an application.

[0034] Figure 24 This is a diagram illustrating how to rewrite an application.

[0035] Figure 25 This is a diagram illustrating how to rewrite an application.

[0036] Figure 26 This is a timing diagram illustrating how the application is rewritten via power control.

[0037] Figure 27 This is a timing diagram illustrating how the application is rewritten via power control.

[0038] Figure 28 This is a timing diagram representing how the application is rewritten via power self-holding.

[0039] Figure 29 This is a timing diagram representing how the application is rewritten via power self-holding.

[0040] Figure 30 It is a diagram representing stages.

[0041] Figure 31 It is a picture representing the scene in its normal state.

[0042] Figure 32 This is an image representing the screen displayed when an event notification is generated.

[0043] Figure 33 This is an image representing the screen displayed when an event is announced.

[0044] Figure 34 This is an image showing the screen when you agree to the download.

[0045] Figure 35 This is an image showing the screen when you agree to the download.

[0046] Figure 36 This is an image showing the download process in progress.

[0047] Figure 37 This is an image showing the download process in progress.

[0048] Figure 38 This is an image showing the screen when the download is complete.

[0049] Figure 39 This is an image showing the screen when you agree to the installation.

[0050] Figure 40 This is an image showing the screen when you agree to the installation.

[0051] Figure 41 This is a screenshot showing the installation process.

[0052] Figure 42 This is a screenshot showing the installation process.

[0053] Figure 43 This is an image representing the screen displayed when activating consent.

[0054] Figure 44 This is an image showing the screen when an IG connection is established.

[0055] Figure 45 This is an image showing the screen when confirming the operation.

[0056] Figure 46 This is an image showing the screen when confirming the operation.

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

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

[0059] Figure 49 This is the functional block diagram of CGW.

[0060] Figure 50 This is the functional block diagram of CGW.

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

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

[0063] Figure 53 This is a functional block diagram of the data packet sending decision unit.

[0064] Figure 54 This is a flowchart illustrating the sending decision process for distributing data packets.

[0065] Figure 55 This is a functional block diagram of the download determination unit for distributing data packets.

[0066] Figure 56 This is a flowchart illustrating the download determination process for distributing data packets.

[0067] Figure 57 This is a functional block diagram of the data transmission determination unit.

[0068] Figure 58 This is a flowchart illustrating the data transmission decision process.

[0069] Figure 59 This is a functional block diagram of the data acquisition and determination section.

[0070] Figure 60 This is a flowchart representing the process of determining and handling the data to be written.

[0071] Figure 61 This is a functional block diagram of the installation indication and determination unit.

[0072] Figure 62 This is a flowchart indicating the instruction determination process for installation.

[0073] Figure 63 This is a diagram indicating the method of installation.

[0074] Figure 64 This is a diagram indicating the method of installation.

[0075] Figure 65 It is a graph representing the way random values ​​are generated.

[0076] Figure 66 This is a functional block diagram of the security access key management department.

[0077] Figure 67 This is a flowchart illustrating the process of generating secure access keys.

[0078] Figure 68 This is a diagram illustrating how secure access keys are generated.

[0079] Figure 69 This is a flowchart illustrating the process of eliminating secure access keys.

[0080] Figure 70 It is a diagram showing the process flow involved in verifying written data.

[0081] Figure 71 This is a functional block diagram of the data verification section.

[0082] Figure 72 This is a flowchart representing the verification process for writing data.

[0083] Figure 73 This is a diagram illustrating the distributed processing involved in verifying the data to be written.

[0084] Figure 74 This is a diagram illustrating the distributed processing involved in verifying the data to be written.

[0085] Figure 75 This is a diagram illustrating the distributed processing involved in verifying the data to be written.

[0086] Figure 76 This is a diagram illustrating the distributed processing involved in verifying the data to be written.

[0087] Figure 77 It is a diagram illustrating the process of verifying written data and rewriting the application.

[0088] Figure 78 It is a diagram illustrating the process of verifying written data and rewriting the application.

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

[0090] Figure 80 This is a flowchart representing the data storage plane information transmission control process.

[0091] Figure 81 This is a sequence diagram representing the way information is rewritten on both sides of a notification.

[0092] Figure 82 This is a functional block diagram of the power management unit for non-rewriteable objects.

[0093] Figure 83 This is a flowchart representing the power management process for non-rewriting objects.

[0094] Figure 84 It is a diagram representing the transition between start-up, stop-up, and sleep states.

[0095] Figure 85 It is a diagram representing the transition between start-up, stop-up, and sleep states.

[0096] Figure 86 This is a diagram showing how the power cord is connected.

[0097] Figure 87 This is a flowchart representing the monitoring and processing of remaining battery capacity.

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

[0099] Figure 89 It is a flowchart representing the file transfer control process.

[0100] Figure 90 This is a diagram representing the way documents are given and received.

[0101] Figure 91 This is a diagram representing the way documents are given and received.

[0102] Figure 92 It is a diagram representing the splitting of a file and writing to a file.

[0103] Figure 93 This diagram illustrates how the CGW sends transmission requests to the DCM.

[0104] Figure 94 This diagram illustrates how the CGW sends transmission requests to the DCM.

[0105] Figure 95 This is a diagram illustrating how the CGW distributes write data to the ECU being rewritten.

[0106] Figure 96 This is a diagram illustrating how the CGW distributes write data to the ECU being rewritten.

[0107] Figure 97 This is a diagram illustrating how the CGW distributes write data to the ECU being rewritten.

[0108] Figure 98 This is a diagram showing the connection method of the ECU.

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

[0110] Figure 100 This is a diagram representing the bus load table.

[0111] Figure 101 This is a diagram representing the table to which the object ECU belongs.

[0112] Figure 102 This is a flowchart representing the distribution control process for written data.

[0113] Figure 103 This is a diagram representing how data is distributed and written.

[0114] Figure 104 This is a diagram representing how data is distributed and written.

[0115] Figure 105 This is a diagram illustrating how data is distributed and written while the vehicle is in motion.

[0116] Figure 106 This is a diagram illustrating how data is distributed and written during parking.

[0117] Figure 107 It is a graph representing the amount of data distributed during writing.

[0118] Figure 108 It is a graph representing the amount of data distributed during writing.

[0119] Figure 109 This is a function block diagram of the instruction section for activating the request.

[0120] Figure 110 This is a flowchart indicating the processing of activation requests.

[0121] Figure 111 This is a diagram illustrating how to indicate an activation request.

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

[0123] Figure 113 This is a flowchart representing the rewrite process.

[0124] Figure 114 This is a flowchart representing the activated execution control process.

[0125] Figure 115 This is a function block diagram of the grouping section for rewriting objects.

[0126] Figure 116 This is a flowchart representing the group management process for rewriting objects.

[0127] Figure 117 This is a flowchart representing the group management process for rewriting objects.

[0128] Figure 118 This is a diagram illustrating how the objects will be grouped for rewriting.

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

[0130] Figure 120 This is a flowchart illustrating the process of determining the rollback method.

[0131] Figure 121 This is a flowchart illustrating the process of determining and handling cancellation requests.

[0132] Figure 122 This is a flowchart illustrating the process of determining and handling cancellation requests.

[0133] Figure 123 This is a flowchart illustrating the process of determining and handling cancellation requests.

[0134] Figure 124 This is a flowchart illustrating the process of determining and handling cancellation requests.

[0135] Figure 125 This is a flowchart illustrating the process of determining and handling cancellation requests.

[0136] Figure 126 This is a diagram illustrating how a rollback is performed.

[0137] Figure 127 This is a diagram illustrating how a rollback is performed.

[0138] Figure 128 This is a diagram illustrating how a rollback is performed.

[0139] Figure 129 This is a diagram illustrating how a rollback is performed.

[0140] Figure 130 This is a diagram illustrating how a rollback is performed.

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

[0142] Figure 132 This is a flowchart showing the display control process for the rewriting progress.

[0143] Figure 133 This is a flowchart showing the display control process for rewriting progress.

[0144] Figure 134 It is an image showing the progress of the rewriting process.

[0145] Figure 135 It is an image showing the progress of the rewriting process.

[0146] Figure 136 It is an image showing the progress of the rewriting process.

[0147] Figure 137 It is an image showing the progress of the rewriting process.

[0148] Figure 138 It is an image showing the progress of the rewriting process.

[0149] Figure 139 It is a graph that represents the migration shown in the progress graph.

[0150] Figure 140 It is a graph that represents the migration shown in the progress graph.

[0151] Figure 141 It is a graph that represents the migration shown in the progress graph.

[0152] Figure 142 It is a graph that represents the migration shown in the progress graph.

[0153] Figure 143 It is an image showing the progress of the rewriting process.

[0154] Figure 144 This is the function block for the matching determination of differential data.

[0155] Figure 145 This is a flowchart representing the matching determination process for differential data.

[0156] Figure 146 This is a diagram illustrating how the matching of differencing data is determined.

[0157] Figure 147 This is a diagram illustrating how the matching of differencing data is determined.

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

[0159] Figure 149 It is a flowchart representing the typical action processing.

[0160] Figure 150 This is a flowchart representing the rewrite action processing.

[0161] Figure 151 This is a flowchart representing the information notification process.

[0162] Figure 152 This is a flowchart representing the verification process of the rewritten program.

[0163] Figure 153 This is a diagram illustrating the methods of sending identification information and writing data.

[0164] Figure 154 This is a diagram illustrating the methods of sending identification information and writing data.

[0165] Figure 155 This is a flowchart illustrating the installation instruction process.

[0166] Figure 156 This is a functional block diagram of the conversation initiation section.

[0167] Figure 157 It is a diagram representing the structure of a program.

[0168] Figure 158 It is a graph representing state transitions.

[0169] Figure 159 It is a graph representing state transitions.

[0170] Figure 160 It is a graph representing state transitions.

[0171] Figure 161 This is a diagram representing the mediation of a conversation.

[0172] Figure 162 This is a diagram representing the mediation of a conversation.

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

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

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

[0176] Figure 166 This is a flowchart representing the state transition management process for the second state.

[0177] Figure 167This is a flowchart representing the state transition management process for the second state.

[0178] Figure 168 It is a diagram representing the structure of a program.

[0179] Figure 169 It is a graph representing state transitions.

[0180] Figure 170 This is a functional block diagram of the pilot test unit.

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

[0182] Figure 172 This is a flowchart representing the setting of processing flags.

[0183] Figure 173 This is a flowchart representing the determination and processing of processing flags.

[0184] Figure 174 This is a flowchart representing the determination and processing of processing flags.

[0185] Figure 175 This is a functional block diagram of the synchronization control unit for the progress status.

[0186] Figure 176 This is a functional block diagram of the synchronization control unit for the progress status.

[0187] Figure 177 This is a diagram showing how the sending and receiving progress status signals are displayed.

[0188] Figure 178 This is a flowchart representing the synchronization control process of the progress status.

[0189] Figure 179 This is a flowchart representing the synchronization control process of the progress status.

[0190] Figure 180 This is a flowchart showing the progress status.

[0191] Figure 181 This is a functional block diagram of the control unit that displays control information.

[0192] Figure 182 This is a flowchart representing the sending control processing of display control information.

[0193] Figure 183 This is a functional block diagram of the receiving control unit that displays control information.

[0194] Figure 184 This is a flowchart representing the receiving and control processing of display control information.

[0195] Figure 185 It is a diagram representing the information contained in the distribution specification data.

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

[0197] Figure 187 This is a diagram representing the rewritten specification data.

[0198] Figure 188 This is an image showing the screen when selecting from the menu.

[0199] Figure 189 It is an image representing the screen when the user makes a selection.

[0200] Figure 190 This is an image showing the screen during user registration.

[0201] Figure 191 This is a flowchart representing the screen display control process for progress tracking.

[0202] Figure 192 This is a flowchart representing the screen display control process for progress tracking.

[0203] Figure 193 This is a diagram representing a message frame.

[0204] Figure 194 This is an image representing the screen displayed when activating consent.

[0205] Figure 195 This is a diagram indicating whether an item is displayed or not.

[0206] Figure 196 This is a diagram indicating whether an item is displayed or not.

[0207] Figure 197 This is an image representing the screen displayed when activating consent.

[0208] Figure 198 This is a diagram representing the methods of data communication.

[0209] Figure 199 This is a diagram representing the message frame when an activity notification is sent.

[0210] Figure 200 This is a diagram representing the message frame indicating that the download agreement has been granted.

[0211] Figure 201 This is a diagram representing the message frame indicating that installation is agreed upon.

[0212] Figure 202 This is a diagram representing the message frame when consent is activated.

[0213] Figure 203 It is a diagram that represents the movement of the screen.

[0214] Figure 204 This is an image representing the screen displayed when an event notification is generated.

[0215] Figure 205 This is an image showing the screen when you agree to the download.

[0216] Figure 206 This is an image showing the screen when you agree to the download.

[0217] Figure 207 This is an image showing the download process in progress.

[0218] Figure 208 This is an image showing the screen when the download is complete.

[0219] Figure 209 This is an image showing the screen when you agree to the installation.

[0220] Figure 210 This is an image representing the screen displayed when activating consent.

[0221] Figure 211 This is a functional block diagram of the program update report control department.

[0222] Figure 212 This is a flowchart representing the report control process for program updates.

[0223] Figure 213 This is a diagram showing how the indicator reports.

[0224] Figure 214 This is a diagram illustrating the migration of the reporting method when the object being rewritten is a double-sided memory.

[0225] Figure 215 This is a diagram illustrating the migration of reporting methods when the object being rewritten is a single-sided suspended memory.

[0226] Figure 216 This is a diagram illustrating the migration of the reporting method when the object being rewritten is a single-sided, separate memory.

[0227] Figure 217 This is a diagram representing the connection method.

[0228] Figure 218 It is a functional module of the power self-holding execution control unit in CGW.

[0229] Figure 219 It is a functional module of the power self-holding execution control unit in the ECU.

[0230] Figure 220 This is a flowchart illustrating the execution control process of power self-holding in CGW.

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

[0232] Figure 222 This is a diagram showing the period during which the power supply needs to be self-sustaining.

[0233] Figure 223 This is a functional block diagram of the overwrite instruction section based on configuration information.

[0234] Figure 224 This is a flowchart representing the rewrite instruction processing based on configuration information overriding.

[0235] Figure 225 This is a diagram illustrating a mixed approach of application rewriting and configuration information overriding.

[0236] Figure 226 This is a diagram illustrating a mixed approach of application rewriting and configuration information overriding.

[0237] Figure 227 This is a diagram illustrating the methods for sending and receiving configuration information.

[0238] Figure 228 It is a functional module of the rewrite instruction section based on the write-back of configuration information.

[0239] Figure 229 This is a flowchart representing the rewrite instruction processing based on configuration information.

[0240] Figure 230 This is a flowchart representing the rewrite instruction processing based on configuration information.

[0241] Figure 231 This is a flowchart representing the rewrite instruction processing based on configuration information.

[0242] Figure 232 This is a diagram illustrating a hybrid approach of application rewriting and configuration information write-back.

[0243] Figure 233 This is a diagram illustrating a hybrid approach of application rewriting and configuration information write-back.

[0244] Figure 234 This is a diagram illustrating a hybrid approach of application rewriting and configuration information write-back.

[0245] Figure 235 This is a diagram illustrating a hybrid approach of application rewriting and configuration information write-back.

[0246] Figure 236 This is a diagram illustrating a hybrid approach of application rewriting and configuration information write-back.

[0247] Figure 237 This is a diagram illustrating a hybrid approach of application rewriting and configuration information write-back.

[0248] Figure 238 This is a diagram illustrating the methods for sending and receiving configuration information.

[0249] Figure 239 This is a diagram illustrating the methods for sending and receiving configuration information.

[0250] Figure 240 This is a diagram showing the structure of flash memory.

[0251] Figure 241 This is a functional block diagram of the rewriting instruction section based on a specific pattern.

[0252] Figure 242 This is a diagram showing how the equipment is connected to the factory.

[0253] Figure 243 This is a diagram showing how to connect to the dealer's equipment.

[0254] Figure 244 It is a flowchart representing the rewrite instruction processing based on a specific pattern.

[0255] Figure 245 It is a flowchart representing the rewrite process based on a specific pattern.

[0256] Figure 246 This diagram represents the rewrites based on the factory pattern and the rewrites based on the distributor pattern.

[0257] Figure 247 It is a sequence diagram representing the overall way to rewrite the application.

[0258] Figure 248 It is a sequence diagram representing the overall way to rewrite the application.

[0259] Figure 249 It is a sequence diagram representing the overall way to rewrite the application.

[0260] Figure 250 It is a sequence diagram representing the overall way to rewrite the application.

[0261] Figure 251 It is a sequence diagram representing the overall way to rewrite the application.

[0262] Figure 252 It is a sequence diagram representing the overall way to rewrite the application.

[0263] Figure 253 It is a sequence diagram representing the overall way to rewrite the application.

[0264] Figure 254 It is a sequence diagram representing the overall way to rewrite the application.

[0265] Figure 255 It is a sequence diagram representing the overall way to rewrite the application.

[0266] Figure 256 It is a sequence diagram representing the overall way to rewrite the application.

[0267] Figure 257 It is a sequence diagram representing the overall way to rewrite the application.

[0268] Figure 258 This is a diagram showing the overall configuration of the vehicle information communication system in the first embodiment.

[0269] Figure 259 This is a diagram showing the electrical structure of the CGW.

[0270] Figure 260 This is a diagram showing the electrical structure of the ECU.

[0271] Figure 261 This is a diagram showing how the power cord is connected.

[0272] Figure 262 This diagram illustrates how recompiled data and distribution specification data are packaged.

[0273] Figure 263 This is a diagram illustrating how data packets are unpacked and distributed.

[0274] Figure 264 It is a block diagram representing the main functional parts of the central device related to the server.

[0275] Figure 265 It is a diagram illustrating the processing flow in the central device.

[0276] Figure 266 This is a diagram representing an example of the structural information of a vehicle registered in the structural information database.

[0277] Figure 267 This is a diagram representing an example of the programs and data registered in the ECU rewrite data database.

[0278] Figure 268 This is a diagram representing an example of specification data registered in the ECU metadata database.

[0279] Figure 269 This is a diagram representing an example of the structural information of a vehicle registered in the Individual Vehicle Information Database.

[0280] Figure 270This is a diagram representing an example of distributed packet data registered in the packet database.

[0281] Figure 271 This is a diagram representing an example of activity data registered in the activity database.

[0282] Figure 272 It is a flowchart representing the processing of programs and data registered in the ECU rewrite data DB.

[0283] Figure 273 This is a flowchart illustrating an example of the process for generating specification data registered in the ECU metadata database.

[0284] Figure 274 This is a diagram representing an example of specification data.

[0285] Figure 275 This is a diagram representing an example of a bus load table.

[0286] Figure 276 This is a flowchart illustrating the process of generating distribution data packets registered in the data packet database.

[0287] Figure 277 It is a diagram that represents the contents of a data packet file in an image format.

[0288] Figure 278 This is a sequence diagram illustrating the processing flow executed between the central device and the vehicle-side system in the second embodiment.

[0289] Figure 279 This is a flowchart representing the processing performed by the central device.

[0290] Figure 280 It is represented in the form of images Figure 279 The flowchart shown illustrates the processing steps D6 and D7.

[0291] Figure 281 This is a flowchart illustrating the process of sending hash values ​​from the vehicle-side system to the central device.

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

[0293] Figure 283 This is a flowchart representing the processing performed by the central device.

[0294] Figure 284 This is a sequence diagram showing the state of the central device notifying both EV vehicles and traditional vehicles via SMS.

[0295] Figure 285This is a sequence diagram showing the processing flow executed between the central device and the vehicle-side system in the fourth embodiment.

[0296] Figure 286 This is a diagram illustrating the processing performed between the supplier, the central device, and the vehicle-side system in the fifth embodiment.

[0297] Figure 287 It is a sequence diagram (1) showing the processing flow between the supplier, the central unit, and the vehicle-side system.

[0298] Figure 288 It is a sequence diagram (2) showing the processing flow between the supplier, the central unit, and the vehicle-side system.

[0299] Figure 289 It is a sequence diagram (3) showing the processing flow between the supplier, the central unit, and the vehicle-side system.

[0300] Figure 290 It is a variation of the first embodiment (1), and is a diagram showing the data format of the data packet DB in the case where multiple data packets correspond to one activity.

[0301] Figure 291 This is a diagram illustrating the data format of an active DB when multiple data packets correspond to one active event.

[0302] Figure 292 This refers to the situation where specification data is generated in groups. Figure 273 Equivalent diagram.

[0303] Figure 293 This is in the case of generating and distributing data packets in groups. Figure 276 Equivalent diagram.

[0304] Figure 294 This is a variation of the first embodiment (2), and is a diagram showing the processing content of the data packet generation tool. Detailed Implementation

[0305] Hereinafter, one embodiment will be described with reference to the accompanying drawings. The vehicle program rewriting system (equivalent to a vehicle electronic control system) is a system capable of rewriting vehicle control, diagnostic, and other applications mounted on an electronic control unit (hereinafter referred to as an ECU) via OTA (Over-The-Air). In this embodiment, the case of rewriting applications via wired or wireless means is described, but it can also be applied, for example, to rewriting map data used in map applications, control parameters used in the ECU, and other data used in various applications via wired or wireless means.

[0306] Wired application rewriting includes not only acquiring and rewriting the application from outside the vehicle via a wired connection, but also acquiring and rewriting various data used during application execution from outside the vehicle via a wired connection. Wireless application rewriting includes not only acquiring and rewriting the application from outside the vehicle via a wireless connection, but also acquiring and rewriting various data used during application execution from outside the vehicle via a wireless connection.

[0307] like Figure 1 As 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 includes, for example, mobile communication networks utilizing 4G lines, the Internet, WiFi (Wireless Fidelity) (registered trademark), etc. Furthermore, in this embodiment, the configuration on the vehicle side will be mainly described; regarding the configuration of the central device 3, ... Figures 234 to 270 Detailed description is provided.

[0308] Display terminal 5 is a terminal that can accept user input and display various screens, such as a mobile terminal 6 (e.g., a smartphone, tablet, etc.) or an in-vehicle display 7 installed in the vehicle compartment. If the mobile terminal 6 is within the communication range of the mobile communication network, it can communicate with the central device 3 via the communication network 2. The in-vehicle display 7 is connected to the vehicle-side system 4 and may also have navigation functionality. Furthermore, the in-vehicle display 7 can be an in-vehicle display ECU with ECU functionality, or it can control displays to the central display, instrument panel, etc.

[0309] If the user is outside the carriage but within the communication range of the mobile communication network, they can simultaneously view the various screens involved in rewriting the application via the mobile terminal 6 and perform the necessary inputs to complete the application rewriting procedures. If the user is inside the carriage, they can simultaneously view the various screens involved in rewriting the application via the in-vehicle display 7 and perform the necessary inputs to complete the application rewriting procedures. In other words, the user can use the mobile terminal 6 and the in-vehicle display 7 separately, both outside and inside the carriage, to complete the application rewriting procedures.

[0310] The central device 3, within the vehicle program rewriting system 1, integrates the program update functions on the communication network 2 side, functioning as an OTA (Over-The-Air) center. The central device 3 includes a file server 8, a web server 9, and a management server 10, with servers 8-10 configured to communicate with each other. In other words, the central device 3 is composed of multiple servers for different functions.

[0311] File server 8 is a server that manages the files of applications distributed from central device 3 to vehicle-side system 4. File server 8 manages updated data (hereinafter also referred to as reprogram-data or write data) provided by the application providers (i.e., suppliers) distributed from central device 3 to vehicle-side system 4, distribution specification data provided by OEMs (Original Equipment Manufacturers), vehicle status data obtained from vehicle-side system 4, etc. File server 8 can communicate with vehicle-side system 4 via communication network 2. If a download request for a distribution data packet is generated, it will package the reprogram-data and distribution specification data into a single file and send the distribution data packet to vehicle-side system 4.

[0312] Web server 9 is a server that manages web page information. Web server 9 sends the web page data it manages based on requests from web browsers on mobile terminals such as mobile terminals 6. Management server 10 is a server that manages the personal information of users registered to the application rewriting service, the application rewriting history of each individual vehicle, and so on.

[0313] The vehicle-side system 4 has a main unit 11 (equivalent to a vehicle main unit). The main unit 11 has a DCM (Data Communication Module) 12 (equivalent to an in-vehicle 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 to enable data communication. The DCM 12 communicates with the central unit 3 via a communication network 2. If the DCM 12 downloads a distribution data packet from the file server 8, it extracts write data from the downloaded distribution data packet and transmits the extracted write data to the CGW 13.

[0314] CGW13 has a data relay function. If write data is obtained from DCM12, it instructs the target ECU (ECU to be rewritten as an application) to write the obtained write data and distributes the write data to the target ECU. Furthermore, if the write data is completed in the target ECU and the application rewriting is complete, CGW13 instructs the target ECU to effectively activate the rewritten application.

[0315] The main device 11, within the vehicle-side program update system 1, encompasses all program update functions on the vehicle side and functions as an OTA (Over-The-Air) host. Furthermore, in... Figure 1The example shown illustrates a configuration where the DCM12 and the vehicle display 7 are connected to the same first bus 14, but the DCM12 and the vehicle display 7 could also be connected to different buses. Furthermore, the CGW13 could be configured to have part or all of the functions of the DCM12, or the DCM12 could have part or all of the functions of the CGW13. That is, the functional distribution of the DCM12 and CGW13 in the main unit 11 can be arbitrarily configured. The main unit 11 could be composed of two separate ECUs, one for the DCM12 and one for the CGW13, or it could be composed of a single integrated ECU having the functions of both the DCM12 and the CGW13.

[0316] In addition to the first bus 14, the CGW13 is also connected to the second bus 15, the third bus 16, the fourth bus 17, and the fifth bus 18 as buses inside the vehicle. Various ECUs 19 are connected via buses 15 to 17, and the power management ECU 20 is connected via bus 18.

[0317] The second bus 15 is, for example, the bus of the vehicle body system network. The ECU 19 connected to the second bus 15 is an ECU that controls the vehicle body system. ECUs that control the vehicle body system include, for example, door ECUs that control the locking / unlocking of doors, instrument ECUs that control the display on the instrument panel, air conditioning ECUs that control the operation of the air conditioning, window ECUs that control the opening and closing of windows, and safety ECUs that operate for vehicle anti-theft purposes.

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

[0319] 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. Examples of ECUs that control the multimedia system include navigation ECUs for controlling navigation systems and ETC ECUs for controlling electronic toll collection systems (ETC). Buses 15-17 can also be buses of systems other than the vehicle body system network, the driving system network, or the multimedia system network. Furthermore, the number of buses and the number of ECUs 19 are not limited to the illustrated configuration.

[0320] The power management ECU20 is an ECU that manages the power supplied to DCM12, CGW13, various ECUs19, etc.

[0321] The CGW13 is connected to a sixth bus 21 as an external bus. A DLC (Data Link Coupler) connector 22, capable of detachably connecting a tool 23 (equivalent to a service tool), is connected to the sixth bus 21. The internal buses 14-18 and the external bus 21 are, for example, composed of a CAN (Controller Area Network) bus. The CGW13 communicates with the DCM12, various ECUs 19, and the tool 23 according to the CAN data communication standard and the diagnostic communication standard (UDS (Unified Diagnosis Services): ISO 14229). Alternatively, the DCM12 and CGW13 can be connected via Ethernet, or the DLC connector 22 and CGW13 can be connected via Ethernet.

[0322] If the target ECU 19 receives write data from CGW 13, it writes the received write data to flash memory (equivalent to non-volatile memory) to rewrite the application. In the above configuration, CGW 13 functions as a reprogramming master that distributes write data to the target ECU 19 when it receives a write data acquisition request. The target ECU 19 functions as a reprogramming slave that writes the received write data to flash memory to rewrite the application when it receives write data from CGW 13.

[0323] There are two methods for rewriting applications: wired and wireless. Wired application rewriting refers to rewriting the target ECU 19 using an application obtained from outside the vehicle via a wired connection. Specifically, if tool 23 is connected to DLC connector 22, tool 23 transmits the write data to CGW 13. CGW 13 acts as a gateway, sending the wired rewriting request to the target ECU 19, instructing the target ECU 19 to write (install) the write data, and distributing the write data transmitted from tool 23 to the target ECU 19. Distributing the write data to the target ECU 19 is a relaying of the write data.

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

[0325] There are two methods for diagnosing ECU 19: wired and wireless. Wired diagnosis refers to diagnosing ECU 19 from outside the vehicle via a wired connection. Specifically, if tool 23 is connected to DLC connector 22, tool 23 transmits a diagnostic request to CGW 13. CGW 13 acts as a gateway, sending the diagnostic request to the target ECU 19 and distributing the diagnostic commands transmitted from tool 23 to the target ECU 19. The target ECU 19 then performs diagnostic processing corresponding to the diagnostic commands received from CGW 13.

[0326] The so-called wireless diagnostic method refers to diagnosing the ECU 19 wirelessly from outside the vehicle. Specifically, if a diagnostic command is sent as a diagnostic request from the central device 3 to the DCM 12, the DCM 12 transmits the diagnostic command to the CGW 13. The CGW 13 acts as a gateway, distributing the diagnostic command as a diagnostic request to the target ECU 19. The target ECU then performs diagnostic processing corresponding to the diagnostic command received from the CGW 13.

[0327] like Figure 2 As shown, CGW13 has a microcomputer (hereinafter referred to as a 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 has a CPU (Central Processing Unit) 24a, a ROM (Read Only Memory) 24b, a RAM (Random Access Memory) 24c, and flash memory 24d. The flash memory 24d contains a secure area from which information cannot be read from outside the CGW13. The microcomputer 24 executes various control programs stored in a non-transferable physical storage medium to perform various processes and control the operation of the CGW13.

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

[0329] like Figure 3 As shown, the DCM12 has 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 has 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 DCM12. The microcomputer 28 executes various control programs stored in a non-transferable physical storage medium to perform various processes and control the operation of the DCM12. Flash memory for storing data downloaded from the central device 3 can also be configured in the CGW13.

[0330] Wireless circuit 29 controls data communication between the central device 3 and the communication network 2. Data transmission circuit 30 controls data communication between the central device 3 and the bus 14 according to the CAN data communication standard. Power supply circuit 31 inputs +B power, ACC power, and IG power. Power detection circuit 32 detects the voltage values ​​of +B power, ACC power, and IG power input to power supply circuit 31, compares these detected voltage values ​​with specified voltage thresholds, and outputs the comparison result to microcomputer 28. Microcomputer 28 determines whether the +B power, ACC power, and IG power supplied to DCM 12 from the outside is normal or abnormal based on the comparison result input from power detection circuit 32.

[0331] In addition, DCM12 has a vehicle location detection function, for example, detecting the vehicle's location via GPS (Global Positioning System). The flash memory 28d of DCM12 has sufficient memory capacity to store distribution data packets downloaded from the central device 3, and has a larger memory capacity than the flash memory 24d of CGW13. That is, because the flash memory 28d of DCM12 has sufficient memory capacity, even if the flash memory 24d of CGW13 does not have sufficient memory capacity, the main device 11 can still download distribution data packets from the central device 3 and store the downloaded distribution data packets in DCM12.

[0332] like Figure 4 As shown, ECU 19 has 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 has 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-transient physical storage medium to perform various processes and control the actions of the ECU 19.

[0333] The data transmission circuit 34 controls data communication with buses 15-17 according to the CAN data communication standard. The power supply circuit 35 inputs +B power, ACC power, and IG power. The power detection circuit 36 ​​detects the voltage values ​​of the +B power, ACC power, and IG power input to the power supply circuit 35, compares these detected voltage values ​​with specified voltage thresholds, and outputs the comparison result to the microcomputer 33. Based on the comparison result input from the power detection circuit 27, the microcomputer 33 determines whether the +B power, ACC power, and IG power supplied to the ECU 19 from the outside is normal or abnormal. Furthermore, the ECU 19 has essentially the same configuration, except for the different loads connected to it, such as sensors and actuators.

[0334] The in-vehicle display 7 has the same features as Figure 4 The ECU19 shown has the same configuration. The power management ECU20 has the same... Figure 4 The configuration is the same as that of ECU19 shown. The power management ECU20 is connected to enable data communication with the power control circuit 43, which will be described later.

[0335] like Figure 5As shown, the power management ECU 20, CGW13, and ECU 19 are connected to the +B power line 37, ACC power line 38, and 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 the ACC switch 41. When the user performs 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. In vehicles that, for example, involve inserting a key into a slot, the ACC operation is performed by inserting the key into the slot and turning it from the "OFF" position to the "ACC" position. In vehicles that involve pressing a start button, the ACC operation is performed by pressing the start button once.

[0336] The IG power 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 line 39. For vehicles that, for example, involve inserting a key into a slot, the IG operation is the act of inserting the key into the slot and turning it from the "OFF" position to the "ON" position. For vehicles that involve pressing a start button, the IG operation is the act of pressing the start button twice. The negative terminal of the vehicle battery 40 is grounded.

[0337] When both ACC switch 41 and IG switch 42 are open, only +B power is supplied to the vehicle-side system 4. This state, where only +B power is supplied to the vehicle-side system 4, is called the +B power state. When ACC switch 41 is on and IG switch 42 is off, both ACC power and +B power are supplied to the vehicle-side system 4. This state, where both ACC power and +B power are supplied to the vehicle-side system 4, is called the ACC power state. When both ACC switch 41 and IG switch 42 are on, +B power, ACC power, and IG power are supplied to the vehicle-side system 4. This state, where +B power, ACC power, and IG power are supplied to the vehicle-side system 4, is called the IG power state. In addition to the power states described above, a power state suitable for wireless program updates is also considered.

[0338] For ECU19, the starting conditions differ depending on the power supply state, and it is classified as a +B power system ECU that starts under +B power supply state, an ACC system ECU that starts under ACC power supply state, and an IG system ECU that starts under IG power supply state. For example, ECU19 driven for applications such as vehicle anti-theft is classified as a +B power system ECU. For example, ECU19 driven for non-driving system applications such as audio is classified as an ACC system ECU. For example, ECU19 driven for driving system applications such as engine control is classified as an IG system ECU.

[0339] The +B power system ECU is configured to connect to +B power line 37, ACC power line 38, and IG power line 39. In +B power mode, +B power line 37 is selected; in ACC power mode, ACC power line 38 is selected; and in IG power mode, IG power line 39 is selected. The ACC system ECU is configured to connect to ACC power line 38 and IG power line 39. In ACC power mode, ACC power line 38 is selected; and in IG power mode, IG power line 39 is selected. The IG system ECU is connected to IG power line 39.

[0340] CGW13 initiates a start request to an ECU 19 that is in a sleep state, thereby transitioning the ECU 19 from sleep to start. Conversely, CGW13 initiates a sleep request to an ECU 19 that is in a start state, thereby transitioning the ECU 19 from start to sleep. CGW13 can transition a specific ECU 19 to either start or sleep state by, for example, using different waveforms of the transmission signals sent to buses 15-17. Specifically, based on pre-determined start and sleep request waveforms for each ECU 19, if an ECU 19 receives a start request waveform suitable for itself, it transitions from sleep to start; if it receives a sleep request waveform suitable for itself from CGW13, it transitions from start to sleep.

[0341] For example, when both ECU(ID1) and ECU(ID2) are in the active state, CGW13 sends a first waveform, thereby causing ECU(ID1) to transition from the active state to the sleep state while keeping ECU(ID2) in the active state. Additionally, when both ECU(ID1) and ECU(ID2) are in the active state, CGW13 sends a second waveform, thereby keeping ECU(ID1) in the active state while causing ECU(ID2) to transition from the active state to the sleep state.

[0342] The power control circuit 43 is connected in parallel with the ACC switch 41 and the IG switch 42. The CGW13 sends a power control request to the power management ECU 20, causing the power management ECU 20 to control the power control circuit 43. Specifically, the CGW13 sends a power-on request as a power control request to the power management ECU 20, thereby connecting the ACC power line 38, the IG power line 39, and the positive terminal of the vehicle battery 40 within the power control circuit 43. In this state, even if the ACC switch 41 and the IG switch 42 are open, ACC power and IG power are still supplied to the vehicle-side system 4. Conversely, the CGW13 sends a power-off request as a power control request to the power management ECU 20, thereby disconnecting the ACC power line 38, the IG power line 39, and the positive terminal of the vehicle battery 40 within the power control circuit 43.

[0343] DCM12, CGW13, ECU19, and power management ECU20 each have a power self-holding circuit, which has a power self-holding function to maintain the power supply from the vehicle battery 40. That is, regarding DCM12, CGW13, ECU19, and power management ECU20, if the vehicle power supply switches from ACC power or IG power to +B power during the start-up state, they do not immediately transition from the start-up state to the stop state or sleep state after the switch. Instead, they maintain the drive power by utilizing the power supply from the vehicle battery 40 to continue the start-up state for a specified time (e.g., a few minutes). DCM12, CGW13, ECU19, and power management ECU20 transition from the start-up state to the stop state or sleep state after a specified time has elapsed after the vehicle power supply switches from ACC power or IG power to +B power. For example, in the engine control system ECU19, the power self-holding function operates after the vehicle power supply switches from ACC power or IG power to +B power, thereby storing various data related to engine control acquired during vehicle operation as a log.

[0344] Next, the distribution data packets from the central device 3 to the main device 11 will be described. For example... Figure 6 As shown, in the vehicle program rewriting system 1, recompiled data is generated based on write data provided by the supplier (the application provider) and rewrite specification data (equivalent to specification data) provided by the OEM. The rewrite specification data can also be generated in the central device 3. The write data provided by the supplier includes differential data, representing the difference between the old and new applications, and total data, representing the entire new application. Both the differential data and the total data can be compressed using known data compression techniques. Figure 6 The example illustrates the scenario where differential data is provided from suppliers A through C as write data, and recompiled data is generated based on the encrypted differential data and authentication token of ECU (ID1) provided by supplier A, the encrypted differential data and authentication token of ECU (ID2) provided by supplier B, the encrypted differential data and authentication token of ECU (ID3) provided by supplier C, and the rewritten specification data provided by the OEM.

[0345] An authentication token is assigned to each write operation to verify the integrity of the differential data; it may be generated based on the ECU(ID), the key information associated with that ECU(ID), and the differential data. Here, in the event that the application rewrite is canceled midway, the write data used to write back (rollback) to the old version can also be included in the recompiled data.

[0346] The rewrite specification data provided by the OEM includes information that identifies the target ECU 19, the rewrite order if there are multiple target ECUs 19, and the rollback method (described later), among other information related to the application rewrite. The rewrite specification data defines the actions involved in the rewrite of DCM 12, CGW 13, and the target ECU 19. The rewrite specification data is divided into DCM-specific rewrite specification data used by DCM 12 and CGW-specific rewrite specification data used by CGW 13.

[0347] like Figure 7 As shown, the rewrite specification data used by DCM includes specification data information and ECU information. Specification data information includes address information and filename. ECU information includes address information corresponding to the number of ECUs 19 to be rewritten, and address information referenced when sending the update program (write data) for each ECU 19 to CGW13. Specifically, ECU information includes at least the ECU ID (ECU(ID)), the reference address for obtaining the update program (update program retrieval address), the update program size, the reference address for obtaining the rollback program (rollback program retrieval address), and the rollback program size. The rollback program is used to revert the application to its original version (write data) if the application rewrite is canceled midway.

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

[0349] ECU information is information related to the ECU19 being modified, including at least ECU_ID (equivalent to device identification information), connection bus (equivalent to bus identification information), connection power, security access key information, memory type, modification method, power self-hold time, modification surface information, update program version, update program retrieval address, update program size, rollback program version, rollback program retrieval address, rollback program size, and type of data to be written.

[0350] The connection bus indicates the bus to which ECU19 is connected. The power supply connection indicates the power line to which ECU19 is connected. The security access key information indicates the key information used by CGW13 to authenticate accessing the target ECU19, including random values ​​or unique information, key mode, and decryption operation mode. The memory type indicates whether the memory installed in the target ECU19 is a single-sided separate memory, a single-sided suspended memory (also known as pseudo-double-sided memory), or a double-sided memory. The rewriting method indicates whether it is a power-based self-holding rewriting or a power-controlled rewriting. The power self-holding time indicates the duration of power self-holding when the rewriting method is based on power self-holding. The rewriting surface information indicates which surface is the active surface and which is the inactive surface. The active surface is also called the startup surface, and the inactive surface is also called the rewriting surface.

[0351] The updater version indicates the updater version. The updater fetch address indicates the updater address. The updater size indicates the updater's data size. The rollback version indicates the rollback version. The rollback fetch address indicates the rollback's address. The rollback size indicates the rollback's data size. The data type to write indicates whether the written data is differential data or all data. In addition to these information, the rewrite specification data can also include system-defined information.

[0352] If DCM12 obtains the rewrite specification data used by DCM, it parses the obtained rewrite specification data used by DCM. If DCM12 parses the rewrite specification data used by DCM, it controls the acquisition of write data from the address where the update program of the rewrite target ECU19 is stored, and transmits the acquired write data to the rewrite-related actions such as CGW13.

[0353] If CGW13 obtains the rewrite specification data for CGW, it parses the obtained rewrite specification data for CGW. If CGW13 parses the rewrite specification data for CGW, it controls the actions involved in rewriting, such as requesting the DCM12 to transmit a specified amount of the update program for the target ECU19, or distributing the write data to the target ECU19 in a specified order, according to the parsing result.

[0354] The file server 8 contains the aforementioned re-edited data, as well as distribution specification data provided by the OEM. The distribution specification data provided by the OEM defines the actions involved in displaying various screens on the display terminal 5. For example... Figure 9 As shown, the distribution specification data includes language information, display statements, data packet information, image data, display mode, display control program, etc.

[0355] If display terminal 5 obtains distribution specification data from CGW13, it parses the obtained distribution specification data and controls the display of various screens based on the parsing result. For example, display terminal 5 may overlay display statements obtained from the distribution specification data onto pre-stored display frames, or execute display control programs obtained from the distribution specification data. In addition to this information, the distribution specification data may also include system-defined information.

[0356] If file server 8 registers recompiled data and distribution specification data, it encrypts the registered recompiled data to generate a distribution data packet that stores a data packet authentication token for authenticating the data packet, the encrypted recompiled data, and the distribution specification data. The authentication token is data assigned to verify the integrity of the recompiled data and distribution specification data, for example, based on key information associated with CGW13, the recompiled data, and the distribution specification data. If file server 8 receives a download request for the distribution data packet from an external source, it sends the distribution data packet to DCM12. Furthermore, in... Figure 6 The example illustrates a scenario where file server 8 generates a distribution data packet storing recompiled data and distribution specification data, and sends both the recompiled data and distribution specification data to DCM12 simultaneously as a single file. However, it can also send the recompiled data and distribution specification data to DCM12 as separate files. That is, file server 8 can first send the distribution specification data to DCM12, and then send the recompiled data to DCM12. In this case, authentication tokens can be assigned to the distribution specification data and the recompiled data separately.

[0357] like Figure 10 As shown, if DCM12 downloads a distribution data packet from file server 8, it uses the data packet authentication token stored in the downloaded distribution data packet to verify the integrity of the encrypted recompiled data. If the verification result is positive, DCM12 decrypts the encrypted recompiled data. If DCM12 decrypts the encrypted recompiled data, it unpacks the decrypted recompiled data, dividing it into encrypted differential data and authentication token, rewritten specification data used by DCM, and rewritten specification data used by CGW for extraction. Figure 10The example illustrates the extraction of encrypted differential data and authentication tokens for ECU (ID1), ECU (ID2), ECU (ID3), rewritten specification data for DCM, and rewritten specification data for CGW.

[0358] Next, refer to Figures 11 to 22 The flash memory 33d of ECU19 will be explained. Based on its memory structure, the flash memory 33d of ECU19 is classified into three types: a single-sided independent memory with a flash memory surface on one side, a single-sided suspended memory with a flash memory surface on a pseudo-second side, and a double-sided memory with a flash memory surface on two actual sides. From this point forward, ECU19 equipped with a single-sided independent memory will be referred to as a single-sided independent memory ECU, ECU19 equipped with a single-sided suspended memory will be referred to as a single-sided suspended memory ECU, and ECU19 equipped with a double-sided memory will be referred to as a double-sided memory ECU.

[0359] Single-sided standalone memory has a flash memory side on only one side, so there is no concept of an active side and a non-active side, and applications cannot be rewritten while the application is running. On the other hand, single-sided suspended memory and double-sided memory have flash memory sides on both sides, so there is a concept of an active side and a non-active side, and applications on the active side can be rewritten while the application on the active side is running. Double-sided memory has flash memory sides on two completely separate sides, so applications can be rewritten at any time, such as when the vehicle is in motion. Single-sided suspended memory is a pseudo-division of single-sided standalone memory into two sides, and the times when normal read and write operations can be performed are limited. Applications cannot be rewritten while the vehicle is in motion, but applications can be rewritten when the vehicle is parked with the IG power off.

[0360] In addition, single-sided standby memory, single-sided suspended memory, and double-sided memory each have embedded reprogrammed firmware (hereinafter referred to as embedded type) and downloadable reprogrammed firmware (hereinafter referred to as downloadable type) types, respectively. Reprogrammed firmware is firmware used to rewrite application programs.

[0361] The following sections will describe the composition of each flash memory module in turn.

[0362] (A) Single-sided separate memory

[0363] (A-1) Embedded single-sided standalone memory

[0364] Reference Figure 11 as well as Figure 12The embedded single-sided independent memory is described below. The embedded single-sided independent memory has a differential engine working area, an application area, and a bootloader area. The application area contains version information, parameter data, the application program, firmware, and a typical time vector table. The bootloader area contains the bootloader, progress state point 2, progress state point 1, startup determination information, wireless re-editing firmware, wired re-editing firmware, startup determination program, and a boot time vector table.

[0365] like Figure 11 As shown, when the microcomputer 33 performs routine operations such as vehicle control processing and diagnostic processing, it executes the startup determination program, searches for the starting address by referring to the boot time vector table and the normal time vector table, and executes the specified address of the application program.

[0366] When microcomputer 33 performs the rewriting action of the application rewriting process, it does not execute the application but instead performs wireless or wired firmware recompilation. Figure 12 This indicates that the application's actions are rewritten using differential data as an updater. For example... Figure 12 As shown, the microcomputer 33 temporarily saves the application as old data to the differential engine's working area. The microcomputer 33 reads the old data temporarily saved to the differential engine's working area and, through the differential engine included in the embedded reprogramming firmware, reconstructs the new data based on the read old data and the differential data stored in RAM 33c. If the microcomputer 33 generates new data based on the old data and the differential data, it writes the new data to a specified address in memory to rewrite the application.

[0367] (A-2) Download-type single-sided independent memory

[0368] Reference Figure 13 as well as Figure 14 The downloadable single-sided independent memory will be described. Compared to the embedded type described above, the downloadable type differs in that it downloads wireless or wired reprogrammed firmware from an external source, and then deletes the wireless or wired reprogrammed firmware after rewriting the application. In the case of updating the application wirelessly, for example, in advance... Figure 6 The reprogramming data shown includes wireless reprogramming firmware executed by each ECU 19. ECU 19 receives the wireless reprogramming firmware for its own ECU from CGW13 and saves the received wireless reprogramming firmware for its own ECU to RAM.

[0369] like Figure 13 As shown, when the microcomputer 33 performs routine operations such as vehicle control processing and diagnostic processing, it executes the startup determination program in the same way as the embedded type, searches for the starting address by referring to the boot vector table and the normal time vector table, and executes the specified address of the application program.

[0370] like Figure 14As shown, when the microcomputer 33 performs the rewrite operation of the application rewriting process, it temporarily saves the application as old data to the differential engine working area. The microcomputer 33 reads the old data temporarily saved to the differential engine working area, and restores the new data based on the old data and the differential data stored in RAM 33c using the differential engine included in the recompiled 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 rewrite the application.

[0371] (B) Single-sided suspended memory

[0372] (B-1) Embedded single-sided suspended memory

[0373] Reference Figure 15 as well as Figure 16 The embedded single-sided suspended memory is described below. The embedded single-sided suspended memory has a differential engine working area, an application area, and a bootloader area. The reprogrammed firmware, which is updated, is configured in the bootloader area in the same way as the single-sided separate memory and is not the object of the update. The application area, which is the object of the update, has pseudo-A and B sides, with version information, the application, and a normal time vector table configured on sides A and B, respectively. The bootloader area contains the bootloader, reprogrammed firmware, reprogrammed time vector table, boot plane determination function, boot plane determination information, and boot time vector table.

[0374] like Figure 15 As shown, when the microcomputer 33 performs routine operations such as vehicle control processing and diagnostic processing, it executes a boot program. Using the startup surface determination function, it determines which of the A and B surfaces is the application surface based on the startup surface determination information for both A and B surfaces. If the microcomputer 33 determines that A surface is the application surface, it searches for the starting address in the normal time vector table of A surface and executes the application program for A surface. Similarly, if the microcomputer 33 determines that B surface is the application surface, it searches for the starting address in the normal time vector table of B surface and executes the application program for B surface. Furthermore, in... Figure 15 In this case, the recompiled firmware is configured in the bootloader area, but it can also be configured in the A-side or B-side area as the object of program updates.

[0375] like Figure 16As shown, when the microcomputer 33 performs the rewrite operation of the non-application application, it temporarily saves the non-application application as old data to the differential engine working area. The microcomputer 33 reads the old data temporarily saved to the differential engine working area and, through the differential engine in the embedded rewrite firmware, restores the new data based on the read old data and the differential data stored in RAM 33c. If the microcomputer 33 generates new data based on the old data and the differential data, it writes the new data to the non-application area to rewrite the non-application application. Figure 16 The example shows the case where surface A is the active surface and surface B is the non-active surface.

[0376] (B-2) Download-type single-sided suspended memory

[0377] Reference Figure 17 as well as Figure 18 The downloadable single-sided suspended memory will be described. Compared with the embedded type described above, the downloadable type differs in that it downloads the recompiled firmware and recompilation time vector table from an external source, and deletes the recompiled firmware and recompilation time vector table after rewriting the application.

[0378] like Figure 17 As shown, when the microcomputer 33 performs routine operations such as vehicle control processing and diagnostic processing, similarly to an embedded system, it executes a boot program. Using a startup surface determination function, it determines the age of the startup surface based on the startup surface determination information of surface A and surface B, and identifies which surface (A or B) is the application surface. If the microcomputer 33 determines that surface A is the application surface, it searches for the starting address in the normal time vector table of surface A and executes the application program for surface A. Similarly, if the microcomputer 33 determines that surface B is the application surface, it searches for the starting address in the normal time vector table of surface B and executes the application program for surface B.

[0379] like Figure 18 As shown, when the microcomputer 33 performs the rewrite operation of the application rewriting process, it temporarily saves the non-application-side application data as old data to the differential engine working area. The microcomputer 33 reads the old data temporarily saved to the differential engine working area, and restores the new data based on the read old data and the differential data stored in RAM 33c through the differential engine in the recompiled 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 rewrite the application. Figure 18 The example illustrates the case where side A is the active side and side B is the inactive side. In this way, in a single-side suspended memory, it is possible to rewrite the application on side B in the background while the application on side A is being executed.

[0380] (C) Double-sided memory

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

[0382] Reference Figure 19 as well as Figure 20 An embedded double-sided memory is described. An embedded single-sided memory has an application program area and a rewrite program area on side A, an application program area and a rewrite program area on side B, and a boot program area. In the boot program area, the boot program is configured to be unwritable. The boot program includes a boot switching function and a boot time vector table. Each application program area contains version information, parameter data, the application program, firmware, and a normal time vector table. Each rewrite program area contains a program to control rewriting, rewrite progress management information 2, rewrite progress management information 1, boot face determination information, wireless rewrite firmware, wired rewrite firmware, and a boot time vector table. The boot program area contains a boot program, a boot switching function, and a boot time vector table.

[0383] like Figure 19 As shown, when the microcomputer 33 performs routine operations such as vehicle control processing and diagnostic processing, as well as when performing rewriting operations for non-application application programs, it executes a boot program. Based on the startup information of surfaces A and B, the boot exchange function determines the old or new surface and identifies which surface (A or B) is the application surface. If the microcomputer 33 determines that surface A is the application surface, it searches for the starting address by referring to the boot time vector table and the normal time vector table of surface A, and executes the application program for surface A. Similarly, if the microcomputer 33 determines that surface B is the application surface, it searches for the starting address by referring to the boot time vector table and the normal time vector table of surface B, and executes the application program for surface B.

[0384] like Figure 20 As shown, when the microcomputer 33 performs the rewrite operation of the non-application application rewriting process, it temporarily saves the non-application application as old data to the differential engine working area. The microcomputer 33 reads the old data temporarily saved to the differential engine working area and, through the differential engine within the embedded rewrite firmware, restores the new data based on the read old data and the differential data stored in RAM 33c. If the microcomputer 33 generates new data based on the old data and the differential data, it writes the new data to the non-application area to rewrite the non-application application. Furthermore, the old data temporarily saved to the differential engine working area can be either the application in the application area or the non-application application. In this case, when the application in the application area is used as the object, the non-application data is eliminated before writing the new data. Here, if the rewrite data obtained from outside the vehicle is not differential data but all data (full data), the obtained rewrite data is written to the non-application area as new data. Figure 20The example illustrates the case where surface A is the application surface and surface B is the non-application surface. Furthermore, the old data temporarily saved to the differential engine's working area can be either the application from the application surface or the application from the non-application surface. When it's necessary to match the application's execution address, the application from the non-application surface is saved as old data.

[0385] (C-2) Downloadable Double-sided Memory

[0386] Reference Figure 21 as well as Figure 22 The downloadable double-sided memory will be described. Compared with the embedded type described above, the downloadable type differs in that it downloads wireless and wired reprogrammed firmware from an external source, and deletes the wireless and wired reprogrammed firmware after rewriting the application.

[0387] like Figure 21 As shown, when the microcomputer 33 performs normal operations such as vehicle control processing and diagnostic processing, as well as when it performs rewriting operations of non-application surface application rewriting processing, it executes the boot program in the same way as the embedded type. Based on the start surface determination information of surface A and surface B, it determines the old and new through the boot exchange function and determines which surface of surface A and surface B is the application surface, and executes the application of the application surface to perform application processing.

[0388] like Figure 22 As shown, when the microcomputer 33 performs the rewrite operation of the application rewrite process, it temporarily saves the non-application-side application as old data to the differential engine working area. The microcomputer 33 reads the old data temporarily saved to the differential engine working area and restores the new data based on the read old data and the differential data stored in RAM 33c using the re-compilation 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-application-side to rewrite the non-application-side application. Furthermore, the old data temporarily saved to the differential engine working area can be either the application-side application or the non-application-side application. In this case, if the application-side application is used as the object, the non-application-side data is eliminated before writing the new data. Here, if the re-compilation data obtained from outside the vehicle is not differential data but all data (full data), the obtained re-compilation data is written to the non-application-side as new data. Figure 22 The example illustrates the case where side A is the application side and side B is the non-application side. Furthermore, the old data temporarily stored in the differential engine's working area can be either the application from the application side or the application from the non-application side. In this way, in dual-sided memory, it is possible to rewrite the application from side B in the background while the application from side A is being executed.

[0389] As mentioned above, in both embedded and downloadable configurations, an application and a rewriting program for rewriting the application are configured in each application area. Furthermore, in Figure 20 as well as Figure 22 The diagram shows an application as the refactoring object, but a rewrite program can also be used as the refactoring object. Additionally, if it is desired that the rewrite program cannot be rewritten, the rewrite program can be configured in the boot area. The program for wired rewriting can also be configured in the boot area so that wired rewriting via tool 23 can be reliably implemented, for example, in a distributor's facility.

[0390] Next, refer to Figures 23 to 25 The overall order of rewriting the application will be explained. Furthermore, the case where the user rewrites the application while parking by operating the mobile terminal 6, which is the display terminal 5, will be explained here; however, the same applies to the case where the user operates the in-vehicle display 7 to rewrite the application while parking. The distribution data packet sent from the central device 3 to the DCM 12 stores write data for one or more rewrite target ECUs 19. That is, in the distribution data packet, if there is only one rewrite target ECU 19, one write data is stored for that single rewrite target ECU 19; if there are multiple rewrite target ECUs 19, multiple write data are stored for each of the multiple rewrite target ECUs 19. Here, there are two rewrite target ECUs 19, referred to as rewrite target ECU (ID1) and rewrite target ECU (ID2). Additionally, ECUs 19 other than rewrite target ECU (ID1) and rewrite target ECU (ID2) are referred to as other ECUs.

[0391] If both the modified ECU (ID1) and the modified ECU (ID2) determine that they have received a request to send, for example, a version notification signal from the master device 11, then the condition for sending the version notification signal is deemed met. If the condition for sending the version notification signal is met, the modified ECU (ID1) sends a version notification signal to the master device 11, including the version information of its stored application and the ECU (ID) that identifies itself. If the master device 11 receives the version notification signal from the modified ECU (ID1), it sends the received version notification signal to the central device 3. Similarly, if the condition for sending the version notification signal is met, the modified ECU (ID2) sends a version notification signal to the master device 11, including the version of its stored application and the ECU (ID) that identifies itself. If the master device 11 receives the version notification signal from the modified ECU (ID2), it sends the received version notification signal to the central device 3.

[0392] If the central device 3 receives version notification signals from both the target ECU (ID1) and the target ECU (ID2), it determines the application version and ECU (ID) included in the received version notification signal, and determines whether there is write data that should be distributed to the source of the version notification signal for the target ECU 19. The central device 3 determines the current application version of the target ECU 19 based on the version notification signal received from the target, and compares this current application version with the latest version currently being managed.

[0393] If the version determined based on the version notification signal is the same as the latest version currently being managed, the central device 3 determines that there is no write data for the rewrite target ECU 19 that should be distributed to the source of the version notification signal, and the application stored in the rewrite target ECU 19 does not need to be updated. On the other hand, if the version determined based on the version notification signal is less than the latest version currently being managed, the central device 3 determines that there is write data for the rewrite target ECU 19 that should be distributed to the source of the version notification signal, and the application stored in the rewrite target ECU 19 needs to be updated.

[0394] If the central device 3 determines that an application stored in the rewrite target ECU 19 needs to be updated, it notifies the mobile terminal 6 of the update requirement. If the update requirement is confirmed, the mobile terminal 6 displays a distribution screen (A1). This distribution screen is identical to the activity notification screen described later. The user can confirm the update requirement through the distribution screen displayed on the mobile terminal 6 and choose whether to update.

[0395] If the user selects the update subject (A2) on mobile terminal 6, mobile terminal 6 will notify central device 3 of the data packet download request. If the user is notified of the data packet download request from mobile terminal 6, central device 3 will send the data packet to master device 11.

[0396] If the master device 11 downloads a distribution data packet from the central device 3, it begins data packet authentication processing (B1) for the downloaded distribution data packet. The master device 11 authenticates the distribution data packet, and if the data packet authentication processing is completed, it begins data write extraction processing (B2). The master device 11 extracts the write data from the distribution data packet, and if the data write extraction processing is completed, it sends a download completion notification signal to the central device 3.

[0397] If the central device 3 receives a download completion notification signal from the main device 11, it will notify the mobile terminal 6 of the download completion. If the download is notified of completion from the central device 3, the mobile terminal 6 will display a download completion notification screen (A3). The user can confirm the download completion by viewing the download completion notification screen on the mobile terminal 6 and can set the start time for rewriting the application on the vehicle side.

[0398] If the user sets the rewrite start time (A4) of the vehicle-side application in the mobile terminal 6, the mobile terminal 6 will notify the central device 3 of the rewrite start time. If the rewrite start time is notified from the mobile terminal 6, the central device 3 will store the rewrite start time set by the user as the set start time. If the current time reaches the set start time (A5), the central device 3 will send a rewrite instruction signal to the main device 11.

[0399] If the main device 11 receives a rewrite instruction signal from the central device 3, it sends a power-on request to the power management ECU 20, causing the ECU to be rewritten (ID1), the ECU to be rewritten (ID2), and other ECUs to transition from the stopped or sleep state to the start state (X1).

[0400] The master device 11 begins distributing write data to the target ECU (ID1) and instructs the target ECU (ID1) to write the data. The target ECU (ID1) begins receiving write data from the master device 11. If instructed to write data, it begins writing the data and initiates the program rewriting process (C1). Once the target ECU (ID1) has finished receiving write data from the master device 11, completed writing the data, and completed the program rewriting process, it sends a rewriting completion notification signal to the master device 11.

[0401] If the master device 11 receives a write completion notification signal from the target ECU (ID1), it begins distributing write data to the target ECU (ID2) and instructs the target ECU (ID2) to write the data. The target ECU (ID2) begins receiving write data from the master device 11. If instructed to write data, it begins writing the data and initiates the program rewrite process (D1). If the target ECU (ID2) completes receiving write data from the master device 11, completes writing the data, and completes the program rewrite process, it sends a write completion notification signal to the master device 11. If the master device 11 receives a write completion notification signal from the target ECU (ID2), it sends the write completion notification signal to the central device 3.

[0402] If the central device 3 receives a rewrite completion notification signal from the main device 11, it notifies the mobile terminal 6 that the application rewrite is complete. If the central device 3 notifies the mobile terminal 6 that the application rewrite is complete, the mobile terminal 6 displays a rewrite completion notification screen (A6). The user can confirm the completion of the application rewrite by viewing the rewrite completion notification screen on the mobile terminal 6 and can set synchronous implementation as active.

[0403] If the user sets up synchronization implementation (A7) in mobile terminal 6, that is, the user agrees to the activation of a new program, mobile terminal 6 will notify central device 3 of synchronization implementation. If notified of synchronization implementation from mobile terminal 6, central device 3 will send a synchronization switching indication signal to master device 11. If master device 11 receives the synchronization switching indication signal from central device 3, it will distribute the received synchronization switching indication signal to the ECU to be rewritten (ID1) and the ECU to be rewritten (ID2).

[0404] If the target ECU (ID1) and the target ECU (ID2) receive a synchronization switching instruction signal from the master device 11, they will begin the program switching process (C2, D2) to switch the application to be launched from the old application to the new application. If the target ECU (ID1) and the target ECU (ID2) complete the program switching process, they will send a switching completion notification signal to the master device 11.

[0405] If the master device 11 receives a switchover completion notification signal from both the target ECU (ID1) and the target ECU (ID2), it distributes a version read signal to both target ECUs (ID1 and ID2). If each target ECU (ID1) and target ECU (ID2) receives a version read signal from the master device 11, it reads the version (C3, D3) of the application to be used, and sends a latest version notification signal, including the read version, to the master device 11. By receiving version notification signals from the target ECUs (ID1 and ID2), the master device 11 checks the software version or performs a rollback as needed.

[0406] If the main device 11 receives a version notification signal from the ECU(ID1) and the ECU(ID2) to be rewritten, it sends a power stop request to the power management ECU20, causing the ECU(ID1), the ECU(ID2), and other ECUs to switch from the start state to the stop state or the sleep state (X2).

[0407] The main device 11 sends a latest version notification signal to the central device 3. If the central device 3 receives the latest version notification signal from the main device 11, it determines the latest version of the application for both the target ECU (ID1) and the target ECU (ID2) based on the received signal, and then notifies the mobile terminal 6 of the determined latest version. If the mobile terminal 6 is notified of the latest version from the central device 3, it displays a latest version notification screen (A8) indicating the notified latest version. The user can confirm the latest version by viewing the latest version notification screen on the mobile terminal 6, thus confirming that the activation process has been completed.

[0408] Next, refer to Figures 26 to 29 Timing diagrams illustrating the operations of DCM12, CGW13, and the target ECU19 during application rewriting are provided. Furthermore, the following scenarios are described: rewriting the application for the double-sided memory ECU while the vehicle is in motion (i.e., when the IG switch 42 is turned on by user operation); rewriting the application for the single-sided suspended memory ECU and the single-sided individual memory ECU while the vehicle is stationary (after the IG switch 42 is turned off by user operation); and rewriting the application for the application via power control and power self-holding.

[0409] (a) Cases of rewriting application programs via power control

[0410] Reference Figure 26 as well as Figure 27 The following explains the case of rewriting the application program via power control. Rewriting the application program via power control refers to a configuration where the rewriting action is controlled based on power switching without using a power self-holding circuit. If the user switches the IG switch from off to on, and the vehicle power supply switches from +B power to IG power, then DCM12, CGW13, the dual-sided memory ECU, the single-sided suspended memory ECU, and the single-sided individual memory ECU each begin their normal operation (t1).

[0411] If notified by central device 3 that a download has begun, DCM12 transitions from its normal operation to the download operation and begins downloading and distributing data packets from central device 3 (t2). DCM12 can perform the download of distribution data packets in the background while performing its normal operation. Once DCM12 has completed downloading and distributing data packets from central device 3, it reverts to its normal operation (t3).

[0412] If a rewrite instruction signal (installation instruction signal) is received from the central device 3 or CGW13, DCM12 transitions from normal operation to data transmission / central communication operation and begins data transmission / central communication operation (t4). That is, DCM12 extracts write data from the distribution data packet, begins transmitting write data to CGW13, obtains the rewrite progress status from CGW13, and begins notifying the central device 3 of the rewrite progress status.

[0413] If CGW13 begins receiving write data from DCM12, it transitions from normal operation to main reprogramming operation, initiating the main reprogramming process and distributing write data to the dual-sided memory ECU, indicating the writing of the write data. If the dual-sided memory ECU begins receiving write data from CGW13, it begins the programming phase (hereinafter also referred to as the installation phase) during normal operation. That is, the dual-sided memory ECU installs the application in the background while performing normal operation. The dual-sided memory ECU begins writing the received write data to the flash memory, initiating the rewriting of the application.

[0414] During the rewriting of the application program in the dual-sided memory ECU, if the vehicle power supply is switched from IG power to +B power by the user switching the IG switch from on to off, then DCM12 interrupts the data transmission / central communication action, CGW13 interrupts the main reprogramming action, the dual-sided memory ECU interrupts the installation stage, and the rewriting of the application program is interrupted (t5).

[0415] Then, if the user switches the IG switch from off to on and the vehicle power supply switches from +B to IG, the DCM12 restarts the data transmission / central communication operation, the CGW13 restarts the main operation reprogramming, the dual-sided memory ECU restarts the installation phase, and the application rewriting restarts (t6). That is, whenever a trip occurs, the dual-sided memory ECU repeats the interruption and restart of the application rewriting (t7, t8).

[0416] Once the dual-sided memory ECU has completed writing the data and rewriting the application, the installation phase ends, and it transitions from normal operation to waiting for activation. That is, while the dual-sided memory ECU is not in the activation phase, it will not start on the new side (side B) where the application has been rewritten, but will keep the old side (side A) starting (t9).

[0417] After the user switches the IG switch from ON to OFF and the vehicle power supply switches from IG power to +B power (t10), if the dual-sided memory ECU completes the application rewriting at this time, CGW13 sends a power-on request to the power management ECU20. If the CGW13 sends a power-on request to the power management ECU20 and the vehicle power supply switches from +B power to IG power, DCM12 restarts the data transmission / central communication operation, and CGW13 restarts the main operation reprogramming, starting to distribute write data to the single-sided suspended memory ECU and the single-sided individual memory ECU. If the single-sided suspended memory ECU and the single-sided individual memory ECU start receiving write data from CGW13, the process transitions from normal operation to boot processing, where the installation phase begins (t11). That is, the single-sided suspended memory ECU and the single-sided individual memory ECU do not perform installation in parallel with the normal operation, but rather during the boot processing when the application is not active.

[0418] If a single-sided suspended memory ECU starts rewriting an application, the rewriting process is interrupted if the IG switch 42 is switched from off to on by user operation before the rewriting is completed. The single-sided suspended memory ECU does not restore the non-operational side (side B) where the application rewriting was interrupted, but instead uses the operational side (side A) as the starting side. If a single-sided standalone memory ECU starts rewriting an application, the rewriting process continues even if the IG switch 42 is switched from off to on by user operation before the rewriting is completed. This is because, for a single-sided standalone memory ECU, if the application rewriting is interrupted, it cannot be restored to normal operation. Preferably, after the application rewriting of a single-sided standalone memory ECU starts, the user-performed operation of the IG switch 42 is invalidated until the application rewriting is completed.

[0419] If a single-sided suspended memory ECU completes the writing of data and the rewriting of the application, it ends the installation phase during boot processing and transitions to the activation waiting phase. That is, while the activation phase is not underway, the single-sided suspended memory ECU will not boot from the newly rewritten application side (side B), but will continue booting from the old side (side A). If a single-sided standalone memory ECU completes the writing of data and the rewriting of the application, it ends the installation phase during boot processing and becomes an activation waiting phase (t12).

[0420] If the power management ECU 20 switches the vehicle power supply from IG power to +B power according to the activation instruction from CGW13, the dual-sided memory ECU and the single-sided suspended memory ECU switch from the old side to the new side respectively, start on the new side, and begin the post-programming phase (hereinafter also referred to as the activation phase) during the new side startup. The single-sided standalone memory ECU starts restarting, and the activation phase (t13, t14) begins during the restart after installation is completed. During activation, confirmation of correct startup through the new program and notification of version information to CGW13 are performed.

[0421] If activation is complete, the power management ECU 20 switches the vehicle power from IG power to +B power according to the activation completion indication from CGW13. Then, DCM12 transitions from data transmission / central communication to sleep / stop operation and begins the sleep / stop process. CGW13 transitions from reprogramming main operation to sleep / stop operation and begins the sleep / stop process. The dual-sided memory ECU, single-sided suspended memory ECU, and single-sided individual memory ECU transition from new-side startup to sleep / stop operation (t15).

[0422] Subsequently, if the user switches the IG switch from off to on and the vehicle power supply is switched from +B power to IG power, the dual-sided memory ECU and the single-sided suspended memory ECU will use the new side (side B) as the start side and start the new application, and the single-sided separate memory ECU will start the new application (t16).

[0423] (ii) Cases of rewriting applications via power self-holding

[0424] Reference Figure 28 as well as Figure 29 The following explains the case of rewriting the application via power self-holding. Rewriting the application via power self-holding refers to the configuration where the rewriting action is controlled by a power self-holding circuit. If the user switches the IG switch from off to on, and the vehicle power supply switches from +B power to IG power, then DCM12, CGW13, the dual-sided memory ECU, the single-sided suspended memory ECU, and the single-sided individual memory ECU each begin their normal operation (t21).

[0425] If DCM12 is notified from central device 3 that a download has begun, i.e., that there is an update based on a new program, then DCM12 transitions from normal operation to download operation and begins downloading and distributing data packets from central device 3 (t22). If DCM12 completes downloading and distributing data packets from central device 3, it reverts to normal operation (t23).

[0426] If a rewrite instruction signal (installation instruction signal) is received from the central device 3 or CGW13, DCM12 transitions from normal operation to data transmission / central communication operation and begins data transmission / central communication operation (t24). That is, DCM12 extracts write data from the distribution data packet, begins transmitting write data to CGW13, obtains the rewrite progress status from CGW13, and begins notifying the central device 3 of the rewrite progress status.

[0427] If CGW13 begins receiving write data from DCM12, it transitions from normal operation to main reprogramming operation, initiating the main reprogramming process and distributing write data to the dual-sided memory ECU, indicating the writing of the write data. If the dual-sided memory ECU begins receiving write data from CGW13, it begins the programming phase (hereinafter also referred to as the installation phase) during normal operation. That is, the dual-sided memory ECU installs the application in the background while performing normal operation. The dual-sided memory ECU begins writing the received write data to the flash memory, initiating the rewriting of the application.

[0428] During the rewriting of the application program in the dual-sided memory ECU, if the vehicle power supply switches from IG power to +B power by the user switching the IG switch from on to off (t25), then immediately after the vehicle power supply switches from IG power to +B power, DCM12 continues data transmission / central communication operation, CGW13 continues master reprogramming operation, and the dual-sided memory ECU continues the installation phase, continuing the application program rewriting. If a preset time, i.e., a self-holding period, elapses after the vehicle power supply switches from IG power to +B power, then DCM12 interrupts data transmission / central communication operation, CGW13 interrupts master reprogramming operation, the dual-sided memory ECU interrupts the installation phase, and the application program rewriting is interrupted (t26). That is, installation continues by power supply from the vehicle battery 40 until a predetermined time has elapsed since the IG switch 42 was turned off.

[0429] Subsequently, if the user switches the IG switch from off to on and the vehicle power supply switches from +B to IG, the DCM12 restarts data transmission / central communication, the CGW13 restarts master operation reprogramming, the dual-sided memory ECU restarts the installation phase, and the application rewriting restarts (t27). That is, whenever the user switches the IG switch from on to off and the vehicle power supply switches from IG to +B, and then switches the IG switch from off to on and the vehicle power supply switches from +B to IG, the dual-sided memory ECU repeats the interruption and restart of application rewriting (t28~t30) whenever an open circuit occurs. However, before the self-hold period elapses after the vehicle power supply switches from IG to +B, the DCM12 continues data transmission / central communication, the CGW13 continues master operation reprogramming, the dual-sided memory ECU continues the installation phase, and the application rewriting continues.

[0430] Once the dual-sided memory ECU has completed writing the data and rewriting the application, the installation phase ends, and it transitions from normal operation to waiting for activation. That is, while the dual-sided memory ECU is not in the activation phase, it will not start on the new side (side B) where the application has been rewritten, but will keep the old side (side A) running (t31).

[0431] If the user switches the IG switch from ON to OFF and the vehicle power supply switches from IG power to +B power, the application program is rewritten in the dual-sided memory ECU at that moment. Then, the single-sided suspended memory ECU and the single-sided individual memory ECU switch from normal operation to boot processing, and the boot processing begins. The installation phase (t32) begins in the boot processing.

[0432] If the single-sided suspended memory ECU and the individual memory ECU have completed writing the data and rewriting the application, the installation phase ends during the boot process (t33). If the vehicle power switches from +B power to IG power by sending a power start request to the power management ECU 20 via CGW13, the DCM12 will start the data transmission / central communication operation again (t34).

[0433] If a single-sided suspended memory ECU completes the writing of data and the rewriting of the application, it transitions from boot processing to waiting for activation. That is, while not in the activation phase, the single-sided suspended memory ECU will not boot from the new side (side B) where the application has been rewritten, but will continue booting from the old side (side A). If a single-sided standalone memory ECU completes the writing of data and the rewriting of the application, it ends the installation phase in the boot process and becomes waiting for activation (t35).

[0434] If the power management ECU 20 switches the vehicle power from IG power to +B power according to the activation instruction from CGW13, the dual-sided memory ECU and the single-sided suspended memory ECU switch from the old side to the new side respectively, start on the new side, and begin the activation phase during the new side startup. The single-sided standalone memory ECU starts to restart, and begins the activation phase (t36, t37) during the restart after installation is completed.

[0435] If activation is complete, the power management ECU 20 switches the vehicle power from IG power to +B power according to the activation completion indication from CGW13. Then, DCM12 transitions from data transmission / central communication to sleep / stop operation and begins the sleep / stop process. CGW13 transitions from reprogramming main operation to sleep / stop operation and begins the sleep / stop process. The dual-sided memory ECU, single-sided suspended memory ECU, and single-sided individual memory ECU transition from new-sided startup to sleep / stop operation (t38).

[0436] After this, if the user switches the IG switch from off to on and the vehicle power supply is switched from +B power to IG power, the dual-sided memory ECU and the single-sided suspended memory ECU will use the new side (side B) as the start side and start the new application, and the single-sided separate memory ECU will start the new application (t39).

[0437] Before downloading and distributing data packets from the central device 3 and before distributing them to the ECU 19 to which data is to be written, CGW13 performs the following checks: Before downloading and distributing data packets from the central device 3, CGW13 checks the radio wave environment, the remaining battery level of the vehicle battery 40, and the memory capacity of the DCM 12 to ensure normal downloading. Before distributing the data to the ECU 19 to which data is to be written, CGW13 performs checks for intrusion sensors, vehicle locks, curtains, and IG disconnection to prevent instability in the installation environment. It also checks the version and anomaly occurrences to ensure the data can be distributed correctly. Furthermore, as checks for the data to be written to the ECU 19, CGW13 performs tampering checks, access authentication, and version checks before installation begins; communication interruption checks and anomaly checks during installation; and version checks, integrity checks, and DTC (Diagnostic Trouble Code) checks after installation is complete.

[0438] Next, refer to Figures 30 to 46 The screen displayed on display terminal 5 will be described. For example... Figure 30As shown, the process of rewriting the application of the target ECU19 via OTA includes stages of activity notification, download, installation, and activation. Activity notification refers to notification of program updates. For example, receiving a notification that an application update has been detected in the central device 3, and the main device 11 downloading and distributing specification data, is an activity notification. The display terminal 5 displays screens at each stage as the application rewriting progresses. Furthermore, the screens displayed on the in-vehicle display 7 will be explained here.

[0439] like Figure 31 As shown, in the normal state before an event notification, CGW13 displays a navigation screen 501, such as a known route guidance screen (which is part of the navigation function), on the in-vehicle display 7. If an event notification is generated from this state, then... Figure 32 As shown, CGW13 displays an activity notification icon 501a, indicating the generation of activity notifications, in the lower right corner of the navigation screen 501. By confirming the display of the activity notification icon 501a, the user can be aware of the generation of activity notifications related to application updates.

[0440] If the user interacts with the activity notification icon 501a from this state, then as follows: Figure 33 As shown, CGW13 causes the activity notification screen 502 to pop up on the navigation screen 501. However, CGW13 is not limited to simply displaying the activity notification screen 502; other display methods can also be used. For example, CGW13 may display a prompt in the activity notification screen 502 indicating that a software update is available, thus notifying the user of the activity notification, and display the "Confirm" button 502a and the "Later" button 502b, awaiting user action. In this case, by pressing the "Confirm" button 502a, the user can proceed to the next screen to begin rewriting the application. Furthermore, if the user presses the "Later" button 502b, CGW13 will remove the pop-up display of the activity notification screen 502 and return to the previous screen. Figure 32 The screen shown displays the activity notification icon 501a.

[0441] If the user clicks the "Confirm" button 502a from this state, then as follows Figure 34As shown, CGW13 will switch the display from navigation screen 501 to download agreement screen 503, displaying download agreement screen 503 on the in-vehicle display 7. On download agreement screen 503, CGW13 notifies the user of the activity ID and update name, and displays the "Start Download" button 503a, "Detailed Confirmation" button 503b, and "Back" button 503c, awaiting user input. In this situation, the user can start the download by pressing the "Start Download" button 503a, view the download details by pressing the "Detailed Confirmation" button 503b, and reject the download and return to the previous screen by displaying the "Back" button 503c. After pressing the "Back" button 503c, and by pressing the activity notification icon 501a, the user can access the screen for starting the download.

[0442] If the user clicks the "Detailed Confirmation" button 503b from the state where the download agreement screen 503 is displayed, then as follows Figure 35 As shown, CGW13 switches the display content of the download agreement screen 503, displaying the download details on the in-vehicle display 7. As download details, CGW13 uses the received distribution specification data to display the update content, update time, and limitations of vehicle functions accompanying the update. Additionally, if the user operates the "Download Start" button 503a, CGW13 begins distributing the data package via DCM12. Parallel to the start of the data package distribution download, as... Figure 36 As shown, CGW13 will switch the display from the download agreement screen 503 to the navigation screen 501, making the navigation screen 501 reappear on the in-vehicle display 7, and displaying the download in progress icon 501b in the lower right corner of the navigation screen 501. By confirming the display of the download in progress icon 501b, the user can understand the progress of the data packet download.

[0443] If the user downloads the running icon 501b from this state, then as follows: Figure 37 As shown, CGW13 will switch the display from navigation screen 501 to download in progress screen 504, displaying download in progress screen 504 on the in-vehicle display 7. In download in progress screen 504, CGW13 notifies the user that the download is in progress and displays the "Detailed Confirmation" button 504a, the "Back" button 504b, and the "Cancel" button 504c, awaiting user input. In this situation, the user can activate the detailed download progress display by pressing the "Detailed Confirmation" button 504a, and interrupt the download by pressing the "Cancel" button 504c.

[0444] If CGW13 completes the download, then... Figure 38As shown, a download completion notification screen 505 pops up on the navigation screen 501. In the download completion notification screen 505, CGW13 displays, for example, a prompt stating "Download complete. Software update is now possible" to notify the user of the download completion, and displays the "Confirm" button 505a and the "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.

[0445] If the user clicks the "Confirm" button 505a from this state, then as follows: Figure 39 As shown, the CGW13 will switch from the navigation screen 501 to the installation agreement screen 506, displaying the installation agreement screen 506 on the in-vehicle display 7. On the installation agreement screen 506, the CGW13 informs the user of the required time, limitations, and schedule settings related to the installation, and displays the "Update Now" button 506a, the "Schedule Update" button 506b, and the "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 the desired time and pressing the "Schedule Update" button 506b. Furthermore, the user can reject the installation and return to the previous screen by pressing the "Back" button 506c. After pressing the "Back" button 506c, and by pressing the download progress icon 501b, the user can access the screen for starting the installation.

[0446] If the user clicks the "Update Now" button 506a from this state, then as follows: Figure 40 As shown, the CGW13 switches the display content of the installation agreement screen 506, displaying the installation details on the vehicle display screen 7. In this installation agreement screen 506, the CGW13 notifies the user that the installation request has been accepted and the installation has begun.

[0447] If CGW13 installation begins, then as follows: Figure 41 As shown, the display will switch from the installation agreement screen 506 to the navigation screen 501, which will then reappear on the vehicle display 7. An installation in progress icon 501c will be displayed in the lower right corner of the navigation screen 501. By confirming the display of the installation in progress icon 501c, the user can ensure that the installation is in progress.

[0448] If the user performs the installation from this state, the process is as follows: Figure 42As shown, CGW13 will switch the display from navigation screen 501 to installation in progress screen 507, displaying installation in progress screen 507 on the in-vehicle display 7. CGW13 notifies the user of the installation progress in installation in installation in progress screen 507. CGW13 may also display, for example, the remaining installation time and progress percentage on installation in progress screen 507.

[0449] If CGW13 is installed successfully, then... Figure 43 As shown, the display will switch from navigation screen 501 to activation and agreement screen 508, which will then be displayed on the in-vehicle display 7. In activation and agreement screen 508, CGW13 notifies the user of the activation details and displays the "Back" button 508a and the "OK" button 508b, awaiting user input. In this case, the user can refuse activation and return to the previous screen by pressing the "Back" button 508a. Alternatively, the user can agree to activation by pressing the "OK" button 508b. Furthermore, if the "Back" button 508a has been pressed, the user can access the activation screen by pressing the installation in progress icon 501c. These displays and agreements can also be omitted depending on user settings and the specific program scenario.

[0450] If the user connects the IG power supply after pressing the "OK" button 508b, then as follows: Figure 44 As shown, CGW13 displays an activation completion notification screen 509 on the navigation screen 501. In the activation completion notification screen 509, CGW13 displays a prompt such as "Software update complete" to notify the user of the activation completion, and displays the "OK" button 509a and the "Detailed Confirmation" button 509b, awaiting user action. In this case, the user can close the pop-up display of the activation completion notification screen 509 by pressing the "OK" button 509a, and can display the detailed activation completion information by pressing the "Detailed Confirmation" button 509b.

[0451] If the user clicks the "OK" button 509a from this state, then as follows: Figure 45 As shown, the CGW13 will switch the display from the navigation screen 501 to the confirmation operation screen 510, which will then be displayed on the in-vehicle display 7. On the confirmation operation screen 510, the CGW13 will notify the user of the activation completion and display the "Detailed Confirmation" button 510a and the "OK" button 510b, awaiting user input. In this case, the user can activate the detailed display of the activation completion by pressing the "Detailed Confirmation" button 510a.

[0452] If the user clicks the "Detailed Confirmation" button 510a from this state, then as follows Figure 46As shown, the CGW13 switches the display content of the confirmation operation screen 510, displaying the activation completion details on the in-vehicle display 7. The CGW13 displays the added and changed functions as update details and shows the "OK" button 510b. Based on the user's operation of the "OK" buttons 509a and 510b, the CGW13 determines that the user has confirmed the software update is complete.

[0453] As explained above, the vehicle-side system 4 controls the various stages of the operation, such as notification, download, installation, activation, and update completion, and provides the user with a display corresponding to each stage. Furthermore, while the above description specifies control for display on the CGW13, it could also be configured so that the vehicle-mounted display 7 receives the operation stages from the CGW13, distributes specification data, and displays it.

[0454] 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 shown below.

[0455] (1) Data packet sending determination process

[0456] (2) Download determination processing of distributed data packets

[0457] (3) Data transmission determination process

[0458] (4) Data Acquisition and Determination Processing

[0459] (5) Installation instruction determination processing

[0460] (6) Management and processing of secure access keys

[0461] (7) Validation processing of written data

[0462] (8) Data storage plane information transmission control processing

[0463] (9) Power management processing for non-overwrite objects

[0464] (10) File transfer control processing

[0465] (11) Distribution control processing of written data

[0466] (12) Instruction processing for activation request

[0467] (13) Activated execution control processing

[0468] (14) Rewrite the group management process of the object

[0469] (15) Rollback execution control processing

[0470] (16) Rewrite the display control process of progress status

[0471] (17) Matching determination of difference data

[0472] (18) Rewritten execution control processing

[0473] (19) Session establishment process

[0474] (20) Determination and handling of re-pilot projects

[0475] (21) Synchronization control processing of progress status

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

[0477] (23) Display control information reception and control processing

[0478] (24) Progress display screen display control processing

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

[0480] (26) Power self-holding execution control processing

[0481] (27) Overwrite instruction processing based on configuration information

[0482] (28) Rewrite instruction processing based on configuration information

[0483] (29) Pattern-specific rewrite instruction processing

[0484] The central device 3, DCM12, CGW13, ECU19, and vehicle display 7 each have the following functional modules as the configuration for performing the characteristic processing of (1) to (26) described above.

[0485] like Figure 47As shown, the central device 3 has a data packet sending unit 51. If the data packet sending unit 51 receives a download request for a data packet from the DCM 12, it sends the data packet to the DCM 12. In addition to the above-described configuration, the central device 3 also includes a data packet sending determination unit 52, a progress status synchronization control unit 53, a sending control unit 54 for displaying control information, and a write data selection unit 55 (equivalent to an update data selection unit) for performing characteristic processing. If the write data selection unit 55 (equivalent to an update data selection unit) receives data storage information from the main device 11, it selects write data suitable for a non-application space based on the software version and application space determined according to the received data storage information. That is, the data packet sending unit 51 sends a data packet including the write data selected by the write data selection unit 55 to the DCM 12. The functional modules for performing characteristic processing will be described later.

[0486] like Figure 48 As shown, the DCM12 includes a download request sending unit 61, a distribution data packet downloading unit 62, a write data extraction unit 63, a write data transmission unit 64, a rewrite specification data extraction unit 65, and a rewrite specification data transmission unit 66. The download request sending unit 61 sends a download request for a distribution data packet to the central device 3. The distribution data packet downloading unit 62 downloads the distribution data packet from the central device 3. If the distribution data packet is downloaded from the central device 3 by the distribution data packet downloading unit 62, the write data extraction unit 63 extracts the write data from the downloaded distribution data packet.

[0487] If write data is extracted from the distribution data packet by the write data extraction unit 63, the write data transmission unit 64 transmits the extracted write data to the CGW13. If a distribution data packet is downloaded from the central device 3 by the distribution data packet download unit 62, the rewrite specification data extraction unit 65 extracts rewrite specification data from the downloaded distribution data packet. If rewrite specification data is extracted from the distribution data packet by the rewrite specification data extraction unit 56, the rewrite specification data transmission unit 66 transmits the extracted rewrite specification data to the CGW13. As a configuration for performing feature processing, in addition to the above configuration, the DCM12 also has a distribution data packet download determination unit 67 and a write data transmission determination unit 68. The functional modules for performing feature processing will be described later.

[0488] like Figure 49 as well as Figure 50As shown, CGW13 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 parsing unit 75. The write data acquisition unit 72 acquires write data from the DCM12 by transmitting write data from the DCM12. If 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 ECU19 when it is time to distribute the write data. The rewrite specification data acquisition unit 74 acquires rewrite specification data from the DCM12 by transmitting rewrite specification data from the DCM12. If rewrite specification data is acquired by the rewrite specification data acquisition unit 74, the rewrite specification data parsing unit 75 parses the acquired rewrite specification data.

[0489] In addition to the above-described components, the CGW13 also includes a write data acquisition determination unit 76, an installation instruction determination unit 77, a security access key management unit 78, a write data verification unit 79, a data storage surface information transmission control unit 80, a non-rewriteable power management unit 81, a file transfer control unit 82, a write data distribution control unit 83, an activation request instruction unit 84, a rewriteable object 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 receiving control unit 89, a progress display screen display control unit 90, a program update report control unit 91, a power self-holding execution control unit 92, a configuration information-based overwrite instruction unit 93, a configuration information-based writeback instruction unit 94, and a specific mode-based rewrite instruction unit 95. The functional modules for performing characteristic processing will be described later.

[0490] like Figure 51 As shown, 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 CGW 13. If write data is received from CGW 13 via the write data receiving unit 101, the program rewriting unit 102 writes the received write data to flash memory to rewrite the application program. In addition to the above-described configuration, ECU 19 also includes a differential data matching determination unit 103, a rewriting execution control unit 104, a session establishment unit 105, a re-pilot determination unit 106, an activation execution control unit 107, and a power self-holding execution control unit 108 for performing characteristic processing. The functional modules for performing characteristic processing will be described later.

[0491] like Figure 52As shown, the vehicle-mounted display 7 has a data receiving and control unit 111 for distributing specification data. The data receiving and control unit 111 controls the reception of the data distributing specification data.

[0492] The following will explain each of the above processes (1) to (29) in turn.

[0493] (1) Processing for determining whether to send distributed data packets; (2) Processing for determining whether to download distributed data packets.

[0494] Reference Figure 53 as well as Figure 54 The sending and receiving parameters of the data packets in the central device 3 are explained below, refer to Figure 55 as well as Figure 56 The download determination process for the distributed data packets in the main device 11 is explained.

[0495] like Figure 53 As shown, the central device 3 includes a software information acquisition unit 52a, an update availability determination unit 52b, an update suitability determination unit 52c, and an activity information transmission unit 52d in its data packet distribution and transmission determination unit 522. The software information acquisition unit 52a acquires software information from each ECU 19 on the vehicle side. Specifically, the software information acquisition unit 52a acquires ECU structure information from the vehicle side, including software information such as version and write path, as well as hardware information. The software information acquisition unit 52a can also acquire vehicle status information from the vehicle side along with this ECU structure information, such as fault codes, anti-theft alarm function settings, and license agreement information.

[0496] If software information is acquired through the software information acquisition unit 52a, the update availability determination unit 52b determines whether there is update data for the vehicle based on the acquired software information. That is, the update availability determination unit 52b compares the version of the acquired software information with the latest version of the software information it manages, determines whether the two are consistent, and thus determines whether there is update data for the vehicle. If the update availability determination unit 52b determines that the two are consistent, it determines that there is no update data for the vehicle; if it determines that the two are inconsistent, it determines that there is update data for the vehicle.

[0497] If the update availability determination unit 52b determines that there is update data for the vehicle, the update suitability determination unit 52c determines whether the vehicle status is suitable for an update using a program that distributes data packets. Specifically, the update suitability determination unit 52c determines whether a license agreement is established, whether the vehicle location is within the range pre-registered by the user, whether the vehicle's alarm function settings are enabled, and whether fault information from the ECU 19 has been generated, to determine whether the vehicle status is suitable for downloading the data packet. In other words, the update suitability determination unit 52c determines whether the vehicle is a vehicle that could potentially be an update that violates the user's intentions, or a vehicle that could fail during installation even if the download is successful.

[0498] If the update suitability determination unit 52c determines that the following conditions are met: the license agreement is established, the vehicle location is within the range pre-registered by the user, the vehicle's alarm function settings are enabled, and no fault information is generated in the ECU 19, then the vehicle status is determined to be suitable for updating using the data packet distribution program, etc. If the update suitability determination unit 52c determines that at least one of the following conditions is met: the license agreement is not established, the vehicle location is not within the range pre-registered by the user, the vehicle's alarm function settings are not enabled, or a fault information is generated in the ECU 19, then the vehicle status is determined to be unsuitable for updating using the data packet distribution program, etc.

[0499] If the update suitability determination unit 52c determines that the vehicle status is suitable for updating using a program that distributes data packets, the activity information sending unit 52d sends activity information to the host device 11. If the update suitability determination unit 52c determines that the vehicle status is not suitable for updating using a program that distributes data packets, the activity information sending unit 52d does not send activity information to the host device 11. By performing the above determination, the activity information sending unit 52d pre-stores information related to vehicles for which activity information has not been sent to the host device 11. Furthermore, information related to vehicles for which activity information has not been sent to the host device 11 can also be displayed on the central device 3.

[0500] Next, refer to Figure 54 The function of the data packet distribution sending determination unit 52 in the central device 3 will be explained. The central device 3 executes the data packet distribution sending determination procedure to perform data packet distribution sending determination processing.

[0501] If the central device 3 begins the data packet distribution sending determination process, it obtains software information from the vehicle side (S101, equivalent to the software information acquisition step). That is, the central device 3 determines whether there is a software update for the vehicle. Based on the obtained software information, the central device 3 determines whether there is update data for the vehicle (S102, equivalent to the update availability determination step). If the central device 3 determines that there is update data for the vehicle (S102: Yes), it determines whether the vehicle status is suitable for updating the program, etc., that distributes the data packet (S103, equivalent to the update suitability determination step). If the central device 3 determines that the vehicle status is suitable for updating the program, etc., that distributes the data packet (S103: Yes), it sends activity information to the main device 11 (S104, equivalent to the activity information sending step), and ends the data packet distribution sending determination process.

[0502] If the central device 3 determines that there is no update data for the vehicle (S102: No), it sends the subject line that is not the recipient of the distribution data packet, i.e., the subject line that there is no application update, to the main device 11 (S105), and ends the distribution data packet sending determination process. If the central device 3 determines that the vehicle state is not suitable for updating the program, etc., using the distribution data packet (S103: No), it sends the subject line that the program, etc., is not suitable for updating and the reason to the main device 11 (S106), and ends the distribution data packet sending determination process. In this case, the main device 11 displays the subject line that the program, etc., is not suitable for updating and the reason to the main device 11 on the vehicle display 7. For example, if the license agreement is not valid, the main device 11 displays, for example, "The program cannot be updated due to invalid license. Please consult your dealer." on the vehicle display 7. Thus, the reason for the subject line that the program, etc., is not suitable for updating can be provided to the user, and appropriate information can be provided to the user.

[0503] As explained above, the central device 3 performs a distribution data packet transmission determination process before sending the distribution data packet to the main device 11 and before sending the activity information, thereby determining whether the program or other device is in an update state suitable for using the distribution data packet. Furthermore, the central device 3 can send the activity information to the main device 11 only when it is determined that the program or other device is in an update state suitable for using the distribution data packet.

[0504] In cases where updates are suitable for using programs that distribute data packets, and where a license agreement is established, the vehicle location is within the range pre-registered by the user, the vehicle's alarm function settings are enabled, and no fault information is generated in the ECU 19, the central device 3 can send activity information to the main device 11. That is, the central device 3 can avoid sending activity information to the main device 11 in situations where a license agreement is not established, the vehicle location is outside the specified range far from its own location, the vehicle's alarm function settings are disabled, or a fault information is generated in the ECU 19. Thus, for vehicles where there is a possibility that the update violates the user's intentions, or vehicles where there is a possibility that the installation will fail even if the download is successful, the central device 3 can prevent the activity information from being sent to the main device 11.

[0505] Furthermore, the central device 3 can also perform data packet transmission determination processing during data packet transmission. In this case, if the central device 3 determines during data packet transmission that the vehicle state is suitable for updating the program, etc., using the data packet, then it continues transmitting the data packet; however, if it determines during data packet transmission that the vehicle state is not suitable for updating the program, etc., using the data packet, then it interrupts the transmission of the data packet. That is, if, for example, fault information of ECU 19 is generated during data packet transmission, the central device 3 interrupts the transmission of the data packet.

[0506] Next, the processing of the main device 11 that receives activity information sent from the central device 3 will be explained. (Refer to...) Figure 55 as well as Figure 56 The download determination process for the distribution data packets in the main device 11 will be explained. The vehicle program rewriting system 1 performs the download determination process for the distribution data packets in the main device 11. The above-mentioned (1) distribution data packet sending determination process is the determination process performed by the central device 3 in the activity notification stage before the download stage, but the distribution data packet download determination process is the determination process performed by the main device 11 in the download stage. In addition, in this embodiment, the case where the download determination process for the distribution data packets is performed by the DCM12 in the main device 11 will be explained, but the CGW13 may also have the function of the DCM12, so that the CGW13 performs the download determination process for the distribution data packets.

[0507] like Figure 55 As shown, the DCM12 includes an activity information receiving unit 67a, a downloadability determination unit 67b, and a download execution unit 67c in its data packet distribution download determination unit 67. The activity information receiving unit 67a receives activity information from the central device 3. Furthermore, if activity information is received from the central device 3, it displays... Figure 32The activity notification icon 501a is shown. If the activity information receiving unit 67a receives activity information, the downloadability determination unit 67b determines whether the vehicle status is capable of downloading and distributing data packets. That is, the downloadability determination unit 67b determines whether the radio wave environment for communication with the central device 3 is good, whether the remaining battery capacity of the vehicle battery 40 is above the specified capacity, and whether the free memory capacity of the DCM 12 is above the specified capacity, and determines whether the vehicle status is capable of downloading and distributing data packets.

[0508] If the downloadability determination unit 67b determines that the radio wave environment is good, the remaining battery capacity of the vehicle battery 40 is above a specified capacity, and the free memory capacity of the DCM 12 is above a specified capacity, then the vehicle is determined to be in a state where it can download and distribute data packets. If the downloadability determination unit 67b determines that at least one of the following is true: the radio wave environment is bad, the remaining battery capacity of the vehicle battery 40 is not above a specified capacity, and the free memory capacity of the DCM 12 is not above a specified capacity, then the vehicle is determined to be in a state where it cannot download and distribute data packets.

[0509] Thus, the downloadability determination unit 67b determines whether there is a possibility that the download cannot be completed normally. Furthermore, in... Figure 34 as well as Figure 35 In the download consent screen 503 shown, the downloadability determination unit 67b determines the downloadability based on the condition that the user operates the "Download Start" button 503a. Alternatively, the downloadability determination unit 67b can also be configured as a determination item in the determination center device 3. That is, the downloadability determination unit 67b determines that the download is possible if, for example, the vehicle's alarm function settings are enabled and no fault information is generated in the ECU 19.

[0510] If the downloadability determination unit 67b determines that the vehicle status is suitable for downloading and distributing data packets, the download execution unit 67c downloads and distributes the data packets from the central device 3. That is, the download execution unit 67c executes the download of the distribution data packets after confirming that the download can be completed normally.

[0511] If the downloadability determination unit 67b determines that the vehicle status is not suitable for downloading and distributing data packets, the download execution unit 67c will not download and distribute data packets from the central device 3. That is, the download execution unit 67c will not perform the download of the data packets if there is a possibility that the download cannot be completed normally. In this case, the download execution unit 67c instructs the vehicle display 7 to display a pop-up screen on the navigation screen 501 indicating the reason why the download cannot begin.

[0512] Next, refer to Figure 56The function of the data packet distribution download determination unit 67 in the main device 11 will be explained. The main device 11 executes the data packet distribution download determination program to perform data packet distribution download determination processing.

[0513] If the master device 11 initiates the download determination process for the data packet distribution, it receives activity information from the central device 3 (S201, equivalent to the activity information receiving step). The master device 11 determines whether the vehicle status is such that the data packet distribution can be downloaded (S202, equivalent to the downloadability determination step). If the master device 11 determines that the vehicle status is such that the data packet distribution can be downloaded (S202: Yes), it downloads the data packet distribution corresponding to the activity from the central device 3 (S203, equivalent to the download execution step), and ends the data packet download determination process. If the master device 11 determines that the vehicle status is not such that the data packet distribution can be downloaded (S202: No), it does not download the data packet distribution from the central device 3, and ends the data packet download determination process.

[0514] As explained above, the master device 11 can determine whether the vehicle state is in a state where the distribution data packet can be downloaded by performing a distribution data packet download determination process before downloading the distribution data packet from the central device 3. Moreover, the master device 11 can download the distribution data packet only if the vehicle state is in a state where the distribution data packet can be downloaded.

[0515] As a suitable case for downloading and distributing data packets, when the radio wave environment is good, the remaining battery capacity of the vehicle battery 40 is greater than or equal to a specified capacity, and the free memory capacity of the DCM 12 is greater than or equal to a specified capacity, the main device 11 can download and distribute data packets from the central device 3. That is, it can avoid situations where data packets are downloaded and distributed from the central device 3 when the radio wave environment is poor, or the remaining battery capacity of the vehicle battery 40 is less than a specified capacity, or the free memory capacity of the DCM 12 is less than a specified capacity.

[0516] Furthermore, the master device 11 can also perform download determination processing for the distribution data packets during the download process. In this case, if the master device 11 determines during the download of the distribution data packets that the vehicle status is suitable for downloading the distribution data packets, it continues to download the distribution data packets from the central device 3. However, if it determines during the download of the distribution data packets that the vehicle status is not suitable for downloading the distribution data packets, it interrupts the download of the distribution data packets from the central device 3. That is, 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 free memory capacity of the DCM 12 is less than a specified capacity, the master device 11 interrupts the download of the distribution data packets.

[0517] In this way, by determining in the central device 3 whether there is a possibility of an update that violates the user's intentions or a possibility of installation failure, and by determining in the main device 11 whether there is a possibility of download failure, it is possible to suppress the transmission of useless activity information or distribution data packets from the central device 3 to the main device 11.

[0518] The central device 3 has the following configuration: a software information acquisition unit 52a, which acquires software information of the electronic control device from the vehicle side; an update availability determination unit 52b, which determines whether there is update data for the vehicle based on the software information acquired by the software information acquisition unit; an update suitability determination unit 52c, which determines whether the vehicle status is suitable for updating if the update availability determination unit determines that update data is available; and an activity information transmission unit 52d, which sends activity information related to the update to the vehicle's main device if the update suitability determination unit determines that the vehicle status is suitable for updating.

[0519] The main device 11 has the following configuration: an activity information receiving unit 67a that receives activity information from a central device; a downloadability determination unit 67b that, upon receiving activity information from the activity information receiving unit, determines whether the vehicle status is such that data packets can be downloaded and distributed; and a download execution unit 67c that, if the downloadability determination unit determines that the vehicle status is such that data packets can be downloaded and distributed, downloads and distributes data packets from the central device.

[0520] (3) Data transmission determination process, (4) Data acquisition determination process, (5) Installation instruction determination process

[0521] Reference Figure 57 as well as Figure 58 The process for determining the transmission of written data is explained, please refer to... Figure 59 as well as Figure 60 The process for determining and retrieving written data is explained below, refer to... Figures 61 to 64 The instruction determination process for installation is explained. The vehicle program rewriting system 1 performs the data transmission determination process in the DCM12. Here, it is assumed that the distribution data packet sent from the central device 3 to the DCM12 is unpacked, and the state of the written data is extracted from the distribution data packet.

[0522] like Figure 57As shown, the DCM12 has an acquisition request receiving unit 68a and a communication status determination unit 68b in its write data transmission determination unit 68. The acquisition request receiving unit 68a receives an acquisition request for write data from the CGW13. If the acquisition request receiving unit 68a receives an acquisition request for write data, the communication status determination unit 68b determines the status of data communication between the central device 3 and the DCM12, for example, if the user-preset transmission availability determination flag is a first predetermined value. The transmission availability determination flag is, for example, 1 (first predetermined value) if the installation condition is checked, and 0 (second predetermined value) if the check is omitted. The write data transmission unit 64 transmits the write data to the CGW13 based on the condition that the communication status determination unit 68b determines that the data communication between the central device 3 and the DCM12 is in a connected state.

[0523] Next, refer to Figure 58 The function of the write data transfer determination unit 68 in DCM12 will be explained. DCM12 executes the write data transfer determination program to perform write data transfer determination processing. Here, the processing of the case where CGW13 requests DCM12 to obtain write data according to the installation instructions from central device 3 will be explained.

[0524] If DCM12 determines that it has received a write data acquisition request from CGW13, it begins the write data transmission determination process. If DCM12 begins the write data transmission determination process, it checks the transmission availability flag (S301, S302). If DCM12 determines that the transmission availability flag is the first predetermined value (S301: Yes), it determines the data communication status between the central device 3 and itself (S303). If DCM12 determines that the data communication between the central device 3 and itself is in a connected state (S303: Yes), it transmits the write data to CGW13 (S304) and ends the write data transmission determination process. If DCM12 determines that the data communication between the central device 3 and itself is not in a connected state but in an interrupted state (S303: No), it does not transmit the write data to CGW13 and ends the write data transmission determination process.

[0525] In addition, if DCM12 determines that the transmission permission determination flag is the second specified value (S302: Yes), it will not determine the data communication status between the central device 3 and itself, but will transmit the write data to CGW13 and end the write data transmission determination process.

[0526] As explained above, DCM12 determines the data communication status between itself and the central device 3 by performing a data transmission determination process before transmitting the write data to CGW13, based on a first predetermined value for the transmission capability determination flag. If DCM12 determines that the data communication is in a connected state, it begins the transmission of write data; if it determines that the data communication is interrupted, it does not begin the transmission of write data and remains in standby mode. When data communication with the central device 3 is possible, the write data can be transmitted to CGW13, and installation can be performed in the target ECU 19.

[0527] For example, if there are multiple ECUs 19 to be modified and installation takes time, the installation progress can be notified from the vehicle-side system 4 to the central device 3, and the progress can be displayed one by one on the mobile terminal 6. Furthermore, the DCM 12 can also perform write data transmission determination processing during the write data transmission. In this case, if the DCM 12 determines that the data communication is in a connected state during write data transmission, it continues the write data transmission; however, if it determines that the data communication is interrupted during write data transmission, it interrupts the write data transmission.

[0528] Next, the process for determining the acquisition of write data will be explained. The vehicle program rewriting system 1 performs the process for determining the acquisition of write data in CGW13. The above-mentioned (3) process for determining the transmission of write data is performed by DCM12 during the installation phase, and the process for determining the acquisition of write data is performed by CGW13 during the same installation phase.

[0529] like Figure 59 As shown, the CGW13 has an event generation determination unit 76a and a communication status determination unit 76b in its write data acquisition determination unit 76. The event generation determination unit 76a determines the occurrence of an event indicating a write data acquisition request (installation instruction) from the central device 3. If the event generation determination unit 76a determines that a write data acquisition request has occurred, the communication status determination unit 76b determines the status of data communication between the central device 3 and the DCM12, for example, if the user-preset acquisition availability determination flag is a first predetermined value. The acquisition availability determination flag is, for example, 1 (first predetermined value) if specified conditions are checked during installation, and 0 (second predetermined value) if the check is omitted. Here, the event generation determination unit 76a can also determine the event occurrence based on the user instructing installation, for example, if the user has given an installation instruction via the vehicle display 7 (see [reference]). Figure 39 If a notification is received, it is determined to be an event that generates a request to write data.

[0530] Next, refer to Figure 60The function of the write data acquisition determination unit 76 in CGW13 will be explained. CGW13 executes the write data acquisition determination program to perform write data acquisition determination processing.

[0531] If CGW13 determines that an event requesting the acquisition of write data has occurred, it begins the write data acquisition determination process. If CGW13 begins the write data acquisition determination process, it determines the acquisition feasibility determination flag (S401, S402). If CGW13 determines that the acquisition feasibility determination flag is a first predetermined value (S401: Yes), it determines the status of data communication between the central device 3 and DCM12 (S403). If CGW13 determines that the data communication between the central device 3 and DCM12 is connected (S403: Yes), it sends the write data acquisition request to DCM12 (S404) and ends the write data acquisition determination process. After this, if write data is transmitted from DCM12, CGW13 distributes the transmitted write data to the rewrite target ECU19. If CGW13 determines that the data communication between the central device 3 and DCM12 is not connected but interrupted (S403: No), it does not send the write data acquisition request to DCM12 and ends the write data acquisition determination process.

[0532] In addition, if CGW13 determines that the acquisition approval flag is the second specified value (S402: Yes), it will not determine the status of the data communication between the central device 3 and DCM12, but will send the data writing acquisition request to DCM12 and end the data writing acquisition approval process.

[0533] As explained above, CGW13 performs a write data acquisition determination process before acquiring write data from DCM12, and determines the data communication status between the central device 3 and DCM12 when the acquisition permission determination flag is a first predetermined value. If CGW13 determines that the data communication is in a connected state, it begins acquiring write data; if it determines that the data communication is in an interrupted state, it does not begin acquiring write data and remains in standby mode. When communication with the central device 3 is possible, write data can be acquired from DCM12, and installation can be performed in the target ECU19.

[0534] For example, if there are multiple ECUs 19 to be modified and installation takes time, the installation progress can be notified from the vehicle-side system 4 to the central device 3, and the progress can be displayed one by one on the mobile terminal 6. Furthermore, CGW13 can also perform write data acquisition determination processing during the write data acquisition process. In this case, if it is determined that data communication is in a connected state during write data acquisition, CGW13 continues to acquire write data; however, if it is determined that data communication is interrupted during write data acquisition, CGW13 interrupts write data acquisition.

[0535] Next, we will explain the determination of the write data acquisition process in more detail. The acquisition of write data is one of the installation-related processes; here, refer to... Figures 61 to 64 The installation instruction determination process is explained. The vehicle program rewriting system 1 performs the installation instruction determination process in CGW13. The above-mentioned (1) distribution data packet sending determination process and (2) distribution data packet download determination process are determination processes performed during the download phase. The (3) write data transmission determination process and (4) write data acquisition determination process are processes performed during the installation phase after the download is completed. The (5) installation instruction determination process is processes performed during the installation phase and the activation phase. Here, it is assumed that the distribution data packet is downloaded to DCM12, and as follows Figure 10 As shown, the write data (update data, differential data) to the write object ECU19 is unpacked.

[0536] like Figure 61 As shown, the CGW13 includes an installation condition determination unit 77a, an installation instruction unit 77b, a vehicle status information acquisition unit 77c, an activation condition determination unit 77d, and an activation instruction unit 77e in its installation instruction determination unit 77. The installation condition determination unit 77a determines whether a first condition, a second condition, a third condition, a fourth condition, and a fifth condition are met. The first condition is obtaining user consent related to the installation. User consent related to the installation is indicated, for example, in… Figure 39 The screen shown depicts the user's consent to the installation (e.g., pressing the "Update Now" button 506a). Alternatively, the process from download to activation can be considered an update, representing the user's consent to the update.

[0537] The second condition is that CGW13 can communicate with the central device 3 via data. The third condition is that the vehicle is in a state where installation is possible. The fourth condition is that the target ECU 19 can be installed. Here, the fourth condition includes not only that the target ECU 19 can be installed, but also that any ECUs that cooperate with it can be installed. The fifth condition is that the written data is normal data. Here, normal data includes data suitable for the target ECU 19, unaltered data, etc.

[0538] If the installation condition determination unit 77a determines that all of the first, second, third, fourth, and fifth conditions are met, the installation instruction unit 77b instructs the target ECU 19 to install the application program. That is, if the installation condition determination unit 77a determines that user consent related to the installation has been obtained, the CGW13 can communicate with the central device 3, the vehicle is in an installable state, the target ECU 19 is in an installable state, and the written data is normal data, then the installation instruction unit 77b instructs the target ECU 19 to install the application program. Specifically, the installation instruction unit 77b obtains the written data from the DCM12 and transmits the obtained written 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 instruction unit 77b does not instruct the target ECU 19 to install the application program and remains on standby, or informs the user that installation cannot begin and the reasons therefor.

[0539] The vehicle status information acquisition unit 77c acquires vehicle status information from the central device 3. The activation condition determination unit 77d, upon completion of application installation in all rewritten ECUs 19, determines whether the sixth, seventh, and eighth conditions are met. The sixth condition is obtaining user consent related to activation. User consent related to activation is indicated, for example, in... Figure 43 The screen shown represents the user's consent to activation (e.g., pressing the "OK" button 508b). Alternatively, the process from download to activation can be considered an update, and the user's consent to the update can be considered as such. The seventh condition is that the vehicle is in a state where it can be activated. The eighth condition is that the object ECU 19 has been modified to a state where it can be activated.

[0540] If the activation condition determination unit 77d determines that all of the sixth, seventh, and eighth conditions are met, the activation instruction unit 77e instructs the ECU 19 to activate the application. The specifics will be explained in the activation request instruction processing section (12) described later. That is, if the activation condition determination unit 77d determines that user consent related to activation has been obtained, the vehicle is in an activatable state, and the ECU 19 is in an activatable state, the activation instruction unit 77e instructs the ECU 19 to activate the application. Activation is performed, and the update program written to the ECU 19 is validated. If the activation condition determination unit 77d determines that at least one of the sixth, seventh, and eighth conditions is not met, the activation instruction unit 77e either does not instruct the ECU 19 to activate the application and remains in standby mode, or informs the user that activation cannot begin and the reasons why.

[0541] Next, refer to Figures 62 to 64 The function of the installation instruction determination unit 77 in CGW13 will be explained. CGW13 executes the installation instruction determination procedure and performs installation instruction determination processing.

[0542] If the CGW13 initiates the installation instruction determination process, it determines whether the first condition is met and whether user consent related to the installation has been obtained (S501, equivalent to part of the installation condition determination step). If the CGW13 determines that user consent related to the installation has been obtained (S501: Yes), it determines whether the second condition is met and whether data communication with the central device 3 is possible (S502, equivalent to part of the installation condition determination step). The CGW13 determines whether data communication with the central device 3 is possible based on the communication wave status in the DCM12.

[0543] If CGW13 determines that it can communicate with the central device 3 (S502: Yes), it then determines whether the third condition is met and whether the vehicle status is suitable for installation (S503, which is part of the installation condition determination step). As for the vehicle status, CGW13 determines, for example, whether the remaining battery capacity of the vehicle battery 40 is above a specified capacity, or whether the vehicle is in a parked state (IG disconnected state) if the memory structure of the target ECU 19 is a single-sided memory, to determine whether the vehicle status is suitable for installation. These vehicle status conditions can also be configured based on the received rewrite specification data (refer to...). Figure 8 CGW13 determines that the vehicle status is suitable for installation if, for example, the remaining battery capacity of the vehicle battery 40 is greater than or equal to the specified capacity specified by the rewritten specification data, and the vehicle status is matched with the vehicle status specified by the rewritten specification data (parking status only, driving status only, or both parking and driving status).

[0544] If CGW13 determines that the vehicle status is suitable for installation (S503: Yes), it then determines whether the fourth condition is met and whether the target ECU 19 is suitable for installation (S504, which is part of the installation condition determination step). For example, CGW13 determines that the target ECU 19 is suitable for installation if no fault code is generated or if secure access to the target ECU 19 is successful. Here, regarding the presence or absence of fault codes, in addition to confirming the target ECU 19 for which data is written, it also confirms the ECU 19 that cooperates with the target ECU 19 for control. That is, CGW13 determines whether fault codes are generated not only for the target ECU 19 but also for the ECU 19 that cooperates with the target ECU 19 for control.

[0545] If CGW13 determines that the target ECU19 can be installed (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). If the written data matches the write surface (non-application surface) of the target ECU19 and the verification result for the integrity of the written data is normal, CGW13 determines that the written data is normal data. If CGW13 determines that the written data is normal data (S505: Yes), it instructs the target ECU19 to install the application program (S506, equivalent to the installation instruction step). Thus, CGW13 uses the satisfaction of the first condition as a condition to perform the determination of the second condition and subsequent conditions. Finally, CGW13 performs the determination of the fifth condition. If CGW13 determines that all conditions from the first to the fifth are met, it instructs the target ECU19 to install the application program.

[0546] On the other hand, if CGW13 determines that user consent related to installation has not been obtained (S501: No), that data communication with the central device 3 cannot be performed (S502: No), that the vehicle status is not suitable for installation (S503: No), that the target ECU 19 cannot be installed (S504: No), or that the written data is not normal data (S505: No), then it will not instruct the target ECU 19 to install the application. Furthermore, in the above processing, the condition of determining that user consent related to installation has been obtained first compared to other conditions has been explained, but it is also possible that the condition is determined after other conditions.

[0547] If CGW13 instructs the ECU19 to install the application, it distributes the write data to the ECU19 (S507) and determines whether the installation is complete (S508). If CGW13 determines that the installation is complete (S508: Yes), it determines whether the sixth condition is met and whether user consent related to activation has been obtained (S509). If CGW13 determines that user consent related to activation has been obtained (S509: Yes), it determines whether the seventh condition is met and whether the vehicle status is an activation-capable state (S510).

[0548] If CGW13 determines that the vehicle is in an activatable state (S510: Yes), it then determines whether the eighth condition is met and whether the ECU19 to be modified is in an activatable state (S511). If CGW13 determines that the ECU19 to be modified is in an activatable state (S511: Yes), it instructs the ECU19 to be modified to be activated (S512). Thus, if CGW13 determines that all conditions from the sixth to the eighth are met, it instructs the ECU19 to be modified to be activated.

[0549] Furthermore, when there are multiple ECUs 19 to be modified, CGW13 can instruct installation either individually or together. In the case of ECUs 19 to be modified being ECU(ID1) and ECU(ID2), the method of instructing installation individually is as follows: Figure 63 As shown, CGW13 determines whether the installation conditions are met for ECU (ID1). If CGW13 determines that the installation conditions are met for ECU (ID1), it instructs ECU (ID1) to install. Next, CGW13 determines whether the installation conditions are met for ECU (ID2). Here, as installation conditions, CGW13 only needs to determine whether the fourth and fifth conditions are met for ECU (ID2). If CGW13 determines that the installation conditions are met for ECU (ID2), it instructs ECU (ID2) to install.

[0550] In the case of rewriting ECU19 as ECU(ID1) and ECU(ID2) and in the method of simultaneous installation instruction, such as... Figure 64 As shown, CGW13 determines whether the installation conditions are met for ECU (ID1). That is, CGW13 determines the first to third conditions, and the fourth and fifth conditions regarding ECU (ID1). If CGW13 determines that the installation conditions are met for ECU (ID1), then it determines whether the installation conditions are met for ECU (ID2). That is, CGW13 determines the fourth and fifth conditions regarding ECU (ID2). If the installation conditions are met for ECU (ID2), then CGW13 instructs installation on both ECU (ID1) and ECU (ID2). For example, CGW13 simultaneously transmits rewrite data to ECU (ID1) and transmits rewrite data to ECU (ID2). In this way, CGW13 determines the first to third conditions, and the fourth and fifth conditions regarding all ECUs to be rewritten, while instructing installation together. Moreover, CGW13 instructs installation after all these conditions are met.

[0551] As explained above, CGW13 performs an installation instruction determination process before instructing the ECU19 to install the application. If all five conditions are met—a first condition of obtaining user consent related to installation, a second condition of being able to communicate data with the central device 3, a third condition that the vehicle is in an installation-ready state, a fourth condition that the ECU19 is in an installation-ready state, and a fifth condition that the written data is normal—then CGW13 instructs the ECU19 to install the application. This allows for the appropriate instruction of the application installation to the ECU19.

[0552] (6) Management and processing of secure access keys

[0553] Reference Figures 65 to 69The management and processing of the secure access key will be explained. The secure access key refers to the device authentication key used by CGW13 to access the ECU19 to be rewritten before the installation of the write data. The vehicle program rewriting system 1 manages and processes the secure 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-described (3) write data transmission determination process or (4) write data acquisition determination process. Device authentication using the secure access key is equivalent to the fourth condition (step S505) in the above-described (5) installation instruction determination process.

[0554] When CGW13 distributes write data to the target ECU19, secure access (device authentication) is required between CGW13 and the target ECU19 using a secure access key. In this case, a method could be considered where CGW13 requests the generation of a random value from the target ECU19, obtains the random value generated by the target ECU19, and calculates the secure access key from this random value. However, in such a method, if a random value is obtained from the target ECU19 even when no application rewriting is performed, the secure access key can still be maintained, potentially leading to a risk of leakage of the secure access key.

[0555] Furthermore, if the configuration involves sending the random value obtained from the target ECU 19 in CGW13 to the central device 3, and the central device 3 calculating the random value and generating a secure access key, then the secure access key does not need to be stored, thus reducing the risk of leakage of the secure access key. However, in the configuration where the central device 3 calculates the random value, the standby time until the target ECU 19 obtains the random value from the central device 3 is relatively long, making it difficult to meet the time requirements for diagnostic communication. Based on this, the following configuration is adopted in this embodiment.

[0556] like Figure 65 As shown, the supplier uses the encryption / decryption key of the secure access key to encrypt the secure access key for each ECU19 to generate a random value. This random value includes either a value different from or the same as a previously used value; it is a random value. The random value is the encrypted secure access key. The supplier provides the generated random value along with the re-edited data. The secure access key, the encryption / decryption key of the secure access key, and the random value are unique keys for each ECU19.

[0557] If the random value is provided from the supplier along with the reprogrammed data, the OEM will associate the provided random value with the ECU(ID) that identifies ECU19 and store it in [the relevant database / system]. Figure 8The CGW rewrite specification data shown is used in the diagram. Additionally, the OEM stores the key pattern and decryption operation mode required for decrypting the random value in the CGW rewrite specification data. The key pattern stores information such as the shared key / public key method and key length; the decryption operation mode stores information such as the type of algorithm used for decryption. If the random value, key pattern, 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 rewrite data, to the central device 3. This information provided by the supplier is stored in the ECU rewrite data DB and ECU metadata DB, described later.

[0558] If the rewrite specification data (rewrite specification data for DCM and rewrite specification data for CGW) is provided from the OEM along with the re-edit data, then the central device 3 sends a distribution data packet including the provided rewrite specification data and re-edit data to the master device 11. In the master device 11, if the DCM 12 downloads the distribution data packet from the central device 3, it transmits the rewrite specification data and write data to the CGW 13.

[0559] like Figure 66 As shown, the CGW13 has 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 elimination unit 78h in its secure access key management unit 78a. Regarding the secure area 78a, information cannot be read from outside the ECU19, and it is configured with the encryption / decryption key and decryption operation algorithm for the secure access key. The random value extraction unit 78b extracts the random value (key derived value) contained in the rewrite specification data from the parsing result of the rewrite specification data used by the CGW. The random value is an encrypted value that establishes a correspondence with the ECU(ID) of the rewrite target ECU19.

[0560] The key pattern extraction unit 78c extracts the key pattern contained in the rewritten specification data from the parsing result of the rewritten specification data used by the CGW. The decryption operation pattern extraction unit 78d extracts the decryption operation pattern contained in the rewritten specification data from the parsing result of the rewritten specification data used by the CGW.

[0561] If a random value is extracted by the random value extraction unit 78b, the key generation unit 78e searches the security region 78a and uses the decryption key corresponding to the ECU(ID) from the decryption key bundle of the security access key configured in the security region 78a to decrypt the extracted random value and generate a security 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 decrypts the key-derived value according to the decryption operation method determined by the decryption operation mode extracted by the decryption operation mode extraction unit 78d. That is, multiple key patterns and multiple decryption operation modes are prepared, the key patterns and decryption operation modes are specified by the rewrite specification data used by the CGW, and the key generation unit 78e uses the key patterns and decryption operation modes to generate a security access key.

[0562] If a secure access key is generated by the key generation unit 78e, the secure access execution unit 78f uses the generated secure access key to perform secure access to the ECU 19 to be modified. Specifically, the secure access execution unit 78f sends encrypted data, for example, data encrypted with the ECU(ID) using the secure access key, to request access to the ECU 19 to be modified. If the ECU 19 to be modified receives the encrypted data, it decrypts the received encrypted data using its own secure access key. Furthermore, the ECU 19 to be modified compares the decrypted data generated by the decryption with its own ECU(ID). If the two match, access to itself is granted; if they do not match, access to itself is denied.

[0563] The session transfer request unit 78g requests a transfer to the rewriting session. After the transfer from the default session to the rewriting session, the security access execution unit 78f performs security access. Alternatively, security access can be performed after transferring to a session other than the default session (e.g., a diagnostic session), and then the transfer to the rewriting session can proceed. After the security access to the rewriting target ECU19 is performed by the security access execution unit 78f and the rewriting of the application of the rewriting target ECU19 is completed, the key removal unit 78h removes the security access key generated by the key generation unit 78e.

[0564] Next, refer to Figures 67 to 69 The function of the security access key management unit 78 in CGW13 will be explained. CGW13 executes the security access key management procedure to perform security access key management processing. As part of the security access key management processing, CGW13 performs security access key generation processing and security access key deletion processing. Each process will be explained in turn below.

[0565] (6-1) Generation and processing of secure access keys

[0566] If CGW13 starts the secure access key generation process, it parses the rewritten specification data obtained from DCM12 (S601, equivalent to the rewritten specification data parsing step), and extracts random values, key modes, and decryption operation modes from the rewritten specification data used by CGW (S602, equivalent to the key derived value extraction step).

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

[0568] like Figure 68 As shown, CGW13 generates a secure access key based on the rewrite specification data used by CGW. CGW13 makes a session transfer request to the rewrite session capable of writing the write data (S604), and uses the secure access key to perform secure access to the rewrite target ECU19 (S605). If CGW13 completes the execution of the secure access, it distributes the write data to the rewrite target ECU19 (S606) and makes a session maintenance request (S607). If CGW13 determines that the installation is complete (S608: Yes), it ends the secure access key generation process.

[0569] (6-2) Elimination of secure access keys

[0570] If CGW13 starts the process of eliminating the security access key, it determines whether the rewriting of the application of the object ECU19 has been completed (S611). If CGW13 determines that the rewriting of the application of the object ECU19 has been completed (S611: Yes), it eliminates the security access key generated by performing the security access key generation process (S612) and ends the process of eliminating the security access key.

[0571] As explained above, CGW13 manages the secure access key, extracting a random value corresponding to the target ECU19 from the parsing results of the rewritten specification data. This random value is then decrypted using the decryption key stored in secure area 78a, which corresponds to the target ECU19, to generate a secure access key. By generating the secure access key within CGW13 instead of obtaining it from an external source, the risk of secure access key leakage is reduced, and secure access to the target ECU19 can be appropriately granted.

[0572] Furthermore, when there are multiple ECUs 19 to be modified, it is preferable that CGW13 performs a security access key generation process before installing each written data. That is, preferably, if the ECUs 19 to be modified are ECU(ID1), ECU(ID2), and ECU(ID3), then CGW13 performs the following sequence: generating the security access key for ECU(ID1), installing the written data to ECU(ID1), generating the security access key for ECU(ID2), installing the written data to ECU(ID2), generating the security access key for ECU(ID3), and installing the written data to ECU(ID3). For example... Figure 63 As shown, CGW13 performs a secure access process as a check to see if the installation conditions for ECU (ID1) are met. If the access is normally granted, installation is instructed for ECU (ID1). Then, CGW13 performs a secure access process as a check to see if the installation conditions for ECU (ID2) are met. If the access is normally granted, installation is instructed for ECU (ID2).

[0573] Furthermore, if the object to be modified, ECU19, grants itself secure access through CGW13, then by receiving a session transfer request from CGW13, the secure access is released, allowing data to be written to the flash memory. A session transfer request, for example, refers to... Figure 155 The second state shown is "Rewrite Session Transfer Request". If the rewrite object ECU19 does not receive a session transfer request from CGW13 within a specified time (e.g., 5 seconds) from the date access to itself is granted, it times out, locks secure access, and does not accept the reception of the session transfer request. If CGW13 does not send a session transfer request to the rewrite object ECU19 within the specified time from the date access to the rewrite object ECU19 is granted, it needs to send a session maintenance request to the rewrite object ECU19 to prevent the rewrite object ECU19 from timeout and send the session transfer request to the rewrite object ECU19.

[0574] Additionally, if, during the rewriting process, a cancellation operation is performed and the version 1.0 application is written to the application side while the version 2.0 application is written to the non-application side, and an activity notification for version 2.0 is generated from this state, then activation can be performed without installation, thus omitting the security access processing.

[0575] (7) Validation processing of written data

[0576] Reference Figures 70 to 78The verification process for written data is explained. The vehicle program rewriting system 1 performs the verification process for written data in CGW13. CGW13 can perform the verification process for written data as described in this embodiment either before or after obtaining access permission in the management process of the security access key described above (6).

[0577] like Figure 70 As shown, if the supplier or OEM generates write data, a data verification value calculation algorithm is applied to the generated write data to generate a data verification value. Here, the write data can be either a new program to be updated or differential data from an old program to a new program. The supplier or OEM uses a specified key (key value) to encrypt the data verification value to generate an authentication token, and registers the write data and authentication token in a corresponding relationship with the central device 3. Specifically, each ECU 19 stores these data in the recompiled data DB described later. Furthermore, the central device 3 generates a distribution data packet including the write data and authentication token, and stores it in the data packet DB.

[0578] If a download request for a distribution data packet is generated from the master device 11, the central device 3 sends a distribution data packet, including write data and an authentication token, to the master device 11 according to the download request. In this case, the write data sent from the central device 3 to the master device 11 is ciphertext, and the authentication token sent from the central device 3 to the master device 11 is also ciphertext. Alternatively, the authentication token sent from the central device 3 to the master device 11 can also be plaintext. If the authentication token sent from the central device 3 to the master device 11 is plaintext, the decryption process described later is not required.

[0579] If the master device 11 downloads a distribution data packet from the central device 3, it extracts the write data for the target ECU 19 from the downloaded distribution data packet. Before distributing the write data to the target ECU 19, it verifies the validity of the write data. That is, the master device 11 sequentially performs decryption processing, first verification value calculation processing, second verification value calculation processing, comparison processing, and determination processing to verify the write data. Decryption processing is the process of decrypting the authentication token sent in ciphertext. First verification value calculation processing is the process of calculating the first data verification value as the expected value using the key (key value) based on the decrypted authentication token. Second verification value calculation processing is the process of calculating the second data verification value based on the write data using the data verification value calculation algorithm. Comparison processing is the process of comparing the first data verification value and the second data verification value. Determination processing is the process of determining the validity of the write data based on the comparison result of the comparison processing.

[0580] like Figure 71As shown, the CGW13 includes a writable determination unit 79a, a processing execution request unit 79b, a processing result acquisition unit 79c, and a verification unit 79d in its data writing verification unit 79. The writable determination unit 79a determines whether data can be written to the target ECU 19. If the writable determination unit 79a determines that data can be written to the target ECU 19, the processing execution request unit 79b notifies the DCM 12 of a processing execution request, requesting the DCM 12 to execute the processing. The processing execution request unit 79b notifies the DCM 12 of at least one of the following processing execution requests: decryption processing, first verification value calculation processing, second verification value calculation processing, comparison processing, and determination processing. The processing result acquisition unit 79c obtains the processing result from the DCM 12 by receiving the processing result notification from the DCM 12. If the processing result is obtained by the processing result acquisition unit 79c, the verification unit 79d uses the processing result to verify the written data. That is, in the above configuration, CGW13 is equivalent to the first device and the first functional unit, and DCM12 is equivalent to the second device and the second functional unit.

[0581] Next, refer to Figures 72 to 77 The function of the write data verification unit 79 in CGW13 will be explained. CGW13 executes the write data verification program to perform write data verification processing.

[0582] If CGW13 begins the verification process for writing data, it notifies DCM12 of the processing execution request, and requests DCM12 to execute the processing (S701, equivalent to the processing execution request step). CGW13 notifies DCM12 of the processing execution request for at least one of the above-mentioned decryption processing, first verification value calculation processing, second verification value calculation processing, comparison processing, and determination processing. If CGW13 obtains the processing result from DCM12 (S702, equivalent to the processing result acquisition step), it uses the obtained processing result to verify the written data (S703, equivalent to the verification step).

[0583] The following examples illustrate several scenarios in which CGW13 will process execution request notifications to DCM12. Figure 73In this example, CGW13 notifies DCM12 of the execution requests for decryption processing, first verification value calculation processing, and second verification value calculation processing. If DCM12 receives these execution requests from CGW13, it executes the decryption, first verification value calculation, and second verification value calculation processing sequentially. DCM12 then performs a result notification process, sending the first data verification value calculated through the first verification value calculation and the second data verification value calculated through the second verification value calculation as the processing results to CGW13. If CGW13 performs a result retrieval process, obtaining the first and second data verification values ​​from DCM12, it uses these values ​​to perform a comparison process and a judgment process sequentially. CGW13 writes data based on whether the judgment result of the judgment process indicates a positive verification. In this example, DCM12 maintains the key used to calculate the first data verification value.

[0584] exist Figure 74 In this example, CGW13 notifies DCM12 of the execution request for decryption processing and second verification value calculation processing. If DCM12 receives the execution request from CGW13, it sequentially performs the decryption processing and the second verification value calculation processing, and then notifies CGW13 of the second data verification value calculated through the second verification value calculation processing. If CGW13 performs the result retrieval processing and obtains the second data verification value from DCM12, it then performs the first verification value calculation processing. Using the first data verification value calculated through the first verification value calculation processing and the second data verification value, it sequentially performs comparison processing and determination processing. CGW13 writes data based on whether the determination result of the determination processing is a positive verification. In this example, CGW13 maintains the key used to calculate the first data verification value.

[0585] exist Figure 75 In this example, CGW13 notifies DCM12 of the execution requests for decryption, first verification value calculation, second verification value calculation, and comparison. If DCM12 receives these execution requests from CGW13, it executes the decryption, first verification value calculation, second verification value calculation, and comparison processes sequentially. DCM12 then performs a result notification, sending the comparison result as the final result to CGW13. If CGW13 performs a result retrieval, obtains the comparison result from DCM12, and uses this result to perform a judgment process. CGW13 writes data based on whether the judgment result indicates a positive verification. In this example, DCM12 maintains the key used to calculate the first data verification value.

[0586] exist Figure 76 In this example, CGW13 notifies DCM12 of the execution requests for decryption processing, first verification value calculation processing, second verification value calculation processing, comparison processing, and determination processing. If DCM12 receives these execution requests from CGW13, it executes the following processes sequentially: decryption processing, first verification value calculation processing, second verification value calculation processing, comparison processing, and determination processing. DCM12 then performs a result notification process, sending the determination result of the determination process to CGW13. If CGW13 performs a result retrieval process and retrieves the result from DCM12, it writes data based on whether the determination result indicated by the processing result is a positive verification. In this example, DCM12 maintains the key used to calculate the first data verification value.

[0587] When there are multiple ECUs 19 to be modified, CGW13 performs verification processing on the written data for each of the multiple ECUs 19 as follows: CGW13 has two methods for verifying the written data for all ECUs 19 together and for verifying the written data independently for each ECU.

[0588] In methods for verifying written data for multiple modified ECU19 objects together, for example... Figure 77 As shown, CGW13 verifies the write data of ECU (ID1), ECU (ID2), and ECU (ID3) simultaneously, distributing the write data to the write target ECU (ID1) for ECU (ID1), the write data to the write target ECU (ID2) for ECU (ID2), and the write data to the write target ECU (ID3). In this case, by simultaneously verifying the write data of multiple rewrite target ECUs 19, the time required from the start of verification of the write data of multiple rewrite target ECUs 19 to the completion of program rewriting can be shortened. That is, compared to verifying the write data of multiple rewrite target ECUs 19 independently, the time required from the start of verification of the write data of multiple rewrite target ECUs 19 to the completion of program rewriting can be shortened.

[0589] In methods that independently verify the written data for multiple modified ECU19 objects, for example... Figure 78As shown, CGW13 verifies the write data of ECU (ID1), distributes the write data to the write object ECU (ID1) of ECU (ID1), verifies the write data of ECU (ID2), distributes the write data to the write object ECU (ID2) of ECU (ID2), verifies the write data of ECU (ID3), and distributes the write data to the write object ECU (ID2) of ECU (ID3). In this case, by verifying the write data before distributing the write data, unauthorized access can be avoided, and reliability can be improved. That is, in the configuration where the write data of multiple rewrite object ECUs 19 are verified together, the time from the completion of verification according to the rewrite order to the distribution of the write data varies depending on the rewrite order. If the time from the completion of verification to the distribution of the write data becomes longer, there is a risk of tampering caused by unauthorized access during this period. However, by verifying the write data immediately before distributing the write data, such a situation can be avoided.

[0590] As explained above, CGW13 performs write data verification processing, causing DCM12, which downloads and distributes data packets from central device 3, to perform at least a portion of the write data verification process. Even if the area for storing write data cannot be guaranteed in CGW13 or the target ECU19, or if a verification calculation program cannot be installed, write data verification can be appropriately performed before the write data is written to the target ECU19.

[0591] exist Figure 74 In the illustrated configuration where CGW13 performs the first verification value calculation, CGW13 retains the key (key value) and does not send the key to DCM12 for verification processing. Therefore, compared to the configuration where DCM12 performs the first verification value calculation, security is improved. Furthermore, when there are multiple ECUs 19 to be modified, either a shared key (key value) shared by all the modified ECUs 19 can be used for the first verification value calculation, or a separate key (key value) different for each of the multiple modified ECUs 19 can be used for the first verification value calculation.

[0592] Furthermore, the above example illustrates the configuration where CGW13 notifies DCM12 of the processing execution request. However, in cases where the processing load in DCM12 increases and hinders the original processing, a navigation device or an ECU other than the target ECU19 can be used instead of DCM12 to notify the processing execution request to the navigation device or the target ECU19. Additionally, when DCM12 and CGW13 are integrated, the processing execution request can be requested from its own processing execution unit without hindering the original processing. For example, this can be done between different software components within the same ECU. Furthermore, the above disclosure can be applied to the main device 11, which is configured as an integrated ECU having the functions of both DCM12 and CGW13. For example, in... Figures 73 to 76 In this configuration, the processing function in CGW13 is designated as the first functional unit, and the processing function in DCM12 is designated as the second functional unit. The first functional unit notifies the second functional unit of the processing execution request, and the second functional unit returns the execution result to the first functional unit. In the main device 11 configured as an integrated ECU, in cases where the processing load increases and hinders communication processing or relay processing, the second functional unit can be substituted to notify the ECU other than the navigation device or the target ECU 19 of the processing execution request.

[0593] Furthermore, data validation values ​​can be calculated as a single value for the entire application or as multiple values ​​for each module of the application. If the written data is all data, it can be used in integrity verification after the data writing is complete.

[0594] In addition, in contrast to secure access, which is a method for verifying whether CGW13 and the rewritten object ECU19 can also connect, the verification of written data includes concepts such as the proper functioning of the central device 3 as the destination of the written data distribution (connection based on TLS communication, mutual authentication), the proper functioning of the communication path from the central device 3 to download the written data (communication path hiding, encryption), the fact that the written data downloaded from the central device 3 has not been tampered with (tampering detection), and the fact that the written data downloaded from the central device 3 cannot be tampered with (encryption).

[0595] Furthermore, the write data during the rewriting of the new program is explained, but the write data during the rollback when writing back to the old program is also the same. In this case, CGW13 can also perform verification at the moment of downloading the rollback write data from the central device 3, but it can also perform verification immediately after the rollback write data is distributed to the rewritten target ECU19 by generating a write cancellation request.

[0596] (8) Data storage plane information transmission control processing

[0597] Reference Figures 79 to 81The transmission control processing of data storage surface information is explained. The vehicle program rewriting system 1 performs the transmission control processing of data storage surface information in CGW13.

[0598] like Figure 79 As shown, the CGW13 includes a data storage surface information acquisition unit 80a, a data storage surface information transmission unit 80b, a rewriting method determination unit 80c, and a rewriting method instruction unit 80d in the data storage surface information transmission control unit 80. The data storage surface information acquisition unit 80a acquires hardware and software related information from each ECU 19 as ECU structure information. Specifically, in the case of a double-sided memory ECU with multiple data storage surfaces and a single-sided suspended memory ECU, it acquires the software ID including version information of each data storage surface and information that can determine the application surface as double-sided rewriting information (hereinafter referred to as surface information).

[0599] If the data storage surface information acquisition unit 80a acquires ECU structure information including surface information, the data storage surface information transmission unit 80b transmits the acquired surface information as part of the ECU structure information from the DCM12 to the central device 3. The data storage surface information transmission unit 80b can transmit the ECU structure information to the central device 3 whenever the IG switch 42 is switched on or off, or it can transmit the ECU structure information to the central device 3 upon request from the central device 3. Furthermore, the data storage surface information transmission unit 80b can transmit the ECU configuration including surface information not only for dual-sided memory ECUs and single-sided suspended memory ECUs, but also for single-sided standalone memory ECUs.

[0600] The rewriting method determination unit 80c determines the rewriting method based on the analysis results of the rewriting specification data used in CGW13. The rewriting method represents the power switching method during installation in the target ECU 19. If the rewriting method determination unit 80c determines the rewriting method, the rewriting method instruction unit 80d instructs the target ECU 19 to rewrite the application program based on the determined rewriting method. That is, if the rewriting method determination unit 80c determines a rewriting method based on power self-holding, the rewriting method instruction unit 80d instructs the target ECU 19 to rewrite the application program based on power self-holding. If the rewriting method determination unit 80c determines a rewriting method based on power control, the rewriting method instruction unit 80d instructs the target ECU 19 to rewrite the application program based on power control without using power self-holding.

[0601] Next, refer to Figure 80 as well as Figure 81 The function of the data storage plane information transmission control unit 80 in CGW13 will be explained. CGW13 executes the data storage plane information transmission control program and performs data storage plane information transmission control processing.

[0602] If CGW13 initiates the data storage surface information transmission control process, it sends an ECU structure information request, including surface information, to all ECUs 19 (S801), and obtains the ECU structure information including surface information from all ECUs 19 (S802, equivalent to the data storage surface information acquisition step). If CGW13 obtains ECU structure information from each target ECU 19, it sends the obtained ECU structure information to DCM12 (S803, equivalent to the data storage surface information transmission step), and waits to obtain the write data and rewrite specification data from DCM12 (S804). Here, CGW13 can also obtain surface information, etc., only from the determined target ECU 19 if the target ECU 19 is predetermined.

[0603] If DCM12 receives ECU structure information from CGW13, it temporarily stores the received ECU structure information. If the opportunity arises to send (upload) the ECU structure information to the central device 3, it sends the ECU structure information to the central device 3. If the central device 3 receives ECU structure information from DCM12, it saves and parses the received ECU structure information.

[0604] The central device 3 determines the application version of each face of each ECU 19, which serves as the source of face information transmission, and which face is the application face. It then determines the appropriate application versions for the two determined faces and the write data for the application face (equivalent to the update data selection step). For example, if face A is the application face and the application stored on that application face is version 2.0, and face B is a non-application face and the application stored on that non-application face is version 1.0, the central device 3 determines the write data for version 3.0 used on face B as the write data. If the write data is differential data, the central device 3 determines the differential data that updates from version 1.0 to version 3.0. If the central device 3 determines the write data, it sends a distribution data packet including the determined write data and the rewritten specification data to the DCM 12 (equivalent to the distribution data packet sending step).

[0605] The central device 3 can either statically select the distribution data packets to be sent to the DCM12 or dynamically generate them. When statically selecting distribution data packets to be sent to the DCM12, the central device 3 manages multiple distribution data packets storing write data, selects write data suitable for non-application scenarios, selects a distribution data packet storing the selected write data from the multiple distribution data packets, and sends it to the DCM12. When dynamically generating distribution data packets to be sent to the DCM12, if write data suitable for non-application scenarios is determined, the central device 3 generates a distribution data packet storing the determined write data and sends it to the DCM12.

[0606] If DCM12 downloads a distribution data packet from the central device 3, it extracts write data and rewrite specification data from the downloaded distribution data packet and transmits the extracted write data and rewrite specification data to CGW13.

[0607] If CGW13 determines that it has obtained write data and rewrite specification data from DCM12 (S804: Yes), it parses the obtained rewrite specification data (S805) and determines the rewrite method for the rewrite target ECU19 based on the parsing result of the rewrite specification data (S806, S807).

[0608] If CGW13 determines that the rewriting method is based on power self-holding rewriting (S806: Yes), it will send a write data acquisition request to DCM12 based on the vehicle's installable status, acquire the write data from DCM12, distribute the acquired write data to the rewritten target ECU19, and terminate the data storage surface information transmission control processing through the power self-holding rewriting application (S808). The method using the power self-holding rewriting application is as described above. Figure 28 as well as Figure 29 As described in (ii) the case of rewriting the application via power self-holding.

[0609] If CGW13 determines that the rewriting method is based on power control (S807: Yes), it sends a write data acquisition request to DCM12 under the condition that the device is in a stopped state. It then acquires the write data from DCM12, distributes the acquired write data to the rewritten target ECU19, and terminates the data storage surface information transmission control processing via the power control rewriting application (S809). The method of rewriting via the power control application is as described above. Figure 26 as well as Figure 27 As described in (a) the case of rewriting the application via power control.

[0610] As explained above, CGW13 transmits ECU structure information, including the surface information, to the central device 3 by performing data storage surface information transmission control processing, causing a distribution data packet containing write data suitable for the ECU structure information to be downloaded from the central device 3 to DCM12. CGW13 obtains write data suitable for the surface information from DCM12 and distributes the write data to the ECU 19 to be rewritten. This allows for appropriate rewriting of the application program when the ECU 19, which is equipped with flash memory having data storage surfaces on two sides, is the rewriting target.

[0611] Furthermore, the central device 3 distributes the distribution data packet in three ways, as shown below: a first distribution method to a third distribution method. In the first distribution method, the central device 3 distributes, for example, a distribution data packet containing write data for version 2.0 of side A and write data for version 2.0 of side B. The DCM 12 extracts the write data for version 2.0 of side A and the write data for version 2.0 of side B from the distribution data packet downloaded from the central device 3, and transmits the extracted write data to the CGW 13. If the CGW 13 receives the write data for version 2.0 of side A and the write data for version 2.0 of side B from the DCM 12, it selects one of them and distributes it to the rewriting target ECU 19. That is, the write data corresponding to each data storage side is contained in the distribution data packet, and the main device 11 selects the appropriate configuration of the rewriting data for the rewriting target ECU 19.

[0612] In the second distribution method, the central device 3 selects, for example, either a distribution data packet storing write data for version 2.0 of side A or a distribution data packet storing write data for version 2.0 of side B, and distributes it. The DCM 12 extracts write data from the distribution data packet downloaded from the central 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 rewritten object ECU 19. That is, based on the side information uploaded from the DCM 12, the central device 3 selects the configuration of the distribution data packet including write data for non-application sides.

[0613] In the third distribution method, the central device 3, for example, distributes a distribution data packet storing write data of version 2.0 shared by both side A and side B. The DCM 12 extracts the write data of version 2.0 shared by both side A and side B from the distribution data packet downloaded from the central device 3 and transmits the extracted write data to the CGW 13. The CGW 13 distributes the write data of version 2.0 shared by both side A and side B transmitted from the DCM 12 to the rewrite target ECU 19. If the rewrite target ECU 19 receives the write data of version 2.0 shared by both side A and side B from the CGW 13, it writes the received write data to either side A or side B. In this case, when the application program is executed in the rewrite target ECU 19, the address resolution function of the microcomputer functions, so that it operates appropriately regardless of whether the write data is written to side A or side B. That is, by resolving the difference in execution addresses accompanying the difference in side A and side B through the microcomputer of the write target ECU 19, the central device 3 and the main device 11 can operate without knowing the side A.

[0614] The ECU structure information sent from CGW13 to central device 3 via DCM12, including surface information, may include vehicle identification information, system identification information, ECU identification information, and usage environment information, in addition to the application version of the two surfaces and information that can determine the application surface.

[0615] Vehicle identification information is unique information used to determine the vehicle to which a data packet is distributed, such as the VIN (Vehicle Identification Number). In vehicles compliant with OBD (On-board Diagnostics) regulations, the VIN can be used according to the regulations. However, for vehicles that do not comply with OBD regulations, such as EVs, the VIN cannot be used; therefore, individual vehicle identification information is used instead of the VIN.

[0616] System determination information is unique to identify which type of rewrite system is being used. CGW13 can wirelessly rewrite systems that can perform wired rewrites using its self-managed diagnostic communications, but it cannot wirelessly rewrite systems using other independent methods. That is, this is because it's a system that uses a wired program update mechanism but performs a wireless program update. Therefore, the central unit 3 needs to determine which distribution data packet to send to which system, and by using system determination information, it can manage which systems are installed in the vehicle. The central unit 3 can determine the rewrite method for each system, the rewrite order when multiple systems are being rewritten, etc., by determining the system determination information.

[0617] ECU identification information is unique to identify the target ECU 19 being modified. It includes the software and hardware versions of the application being written to the ECU and the ECU itself. ECU identification information is also equivalent to an ECU product number. In cases where all data is used to write the latest software, only the hardware version may be required. Additionally, information identifying the application, such as specification version and configuration version, can be defined. Furthermore, microprocessor ID, sub-microprocessor ID, flash memory ID, software sub-version, and software grandchild version can also be defined.

[0618] Environmental information is the only information used to determine the environment in which a user operates the vehicle. By using environmental information, it is sent from CGW13 to central device 3 via DCM12, allowing central device 3 to distribute applications suitable for the user's vehicle operating environment. For example, applications that enhance acceleration can be distributed to users who prefer rapid acceleration from a stop, while applications that enhance environmental driving performance, even if acceleration is poor, can be distributed to users who prefer eco-friendly driving. In short, applications suitable for the user's vehicle operating environment can be distributed.

[0619] Furthermore, while the above explanation addresses the case where the microcomputer in the ECU19 to be modified is equipped with flash memory, when the microcomputer in the ECU19 to be modified is connected to an external memory, the external memory is treated the same as the double-sided memory, and the write area of ​​the external memory is divided into two parts to write the data. When the microcomputer in the ECU19 to be modified is equipped with flash memory and is connected to an external memory, there is also a case where the program stored in the external memory is temporarily copied (copied) to the microcomputer's memory. Since the external memory is often used as a storage area for the ECU's operation log, it is preferable to interrupt the storage of the operation log when writing data to the external memory begins, and then resume the storage of the operation log after the writing of data to the external memory is completed.

[0620] This is not limited to the case of rewriting applications. For example, data such as map data, which has the nature of being updated one by one, also has concepts such as two-sided and version, so the same applies when rewriting map data.

[0621] (9) Power management processing for non-overwrite objects

[0622] Reference Figures 82 to 87 The power management processing for non-rewriteable ECU 19 is explained. The vehicle program rewriting system 1 performs power management processing for non-rewriteable ECU 19 in CGW 13. In this embodiment, it is assumed that the download of the distribution data packet is completed via DCM 12, CGW 13 obtains the rewrite specification data, and CGW 13 distributes the write data to the rewriteable ECU 19 while the vehicle is parked. When distributing the write data to the rewriteable ECU 19, CGW 13 requests IG power to be turned on from the power management ECU 20, causing all ECU 19 to be in an active state.

[0623] like Figure 82 As shown, the CGW13 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 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.

[0624] The state transition control unit 81c can transition the state of the ECU 19, causing the ECU 19 in a stopped or sleep state to transition to a start state (wake-up state), or causing the ECU 19 in a start state to transition to a stopped or sleep state. Additionally, the state transition control unit 81c can transition the ECU 19 in a normal operating state to a power-saving operating state, or cause the ECU 19 in a power-saving operating state to transition to a normal operating state. If the installability determination unit 81b determines that installation is possible, the state transition control unit 81c controls at least one non-rewriteable ECU 19 to a stopped state, a sleep state, or a power-saving operating state. The rewrite order determination unit 81d determines the rewrite order of the rewriteable ECU 19 based on the analysis results of the rewrite specification data.

[0625] Next, refer to Figures 83 to 87 The function of the power management unit 81 of the non-modified ECU 19 in CGW13 will be explained. CGW13 executes the power management program for the non-modified ECUs and performs power management processing for them. Here, the case where CGW13 puts all ECUs 19 that are being managed into the startup state will be explained.

[0626] If CGW13 starts power management processing for a non-rewriteable ECU19, it determines the rewriteable ECU19 and non-rewriteable ECU19 based on the parsing results of the rewrite specification data used by CGW (S901), and determines the rewrite order of one or more rewriteable ECU19s based on the parsing results of the rewrite specification data (S902). CGW13 determines whether data can be written (S903, equivalent to the writeability determination step). If it determines that data can be written (S903: Yes), it sends a power disconnection request (stop request) to the non-rewriteable ECU19 of the ACC system and the non-rewriteable ECU19 of the IG system, causing the non-rewriteable ECU19 of the ACC system and the non-rewriteable ECU19 of the IG system to transition from the start state to the stop state (S904, equivalent to the state transition control step).

[0627] CGW13 determines whether the power disconnection request has been sent to all eligible ECUs19 (S905). If it is determined that the power disconnection request has been sent to all eligible ECUs19 (S905: Yes), then a sleep request is sent to the non-rewriteable ECUs19 of the +B power system, causing the non-rewriteable ECUs19 of the +B power system to transition from the startup state to the sleep state (S906, equivalent to the state transition control step).

[0628] CGW13 determines whether the sleep request has been sent to all eligible ECUs 19 (S907). If it determines that the sleep request has been sent to all eligible ECUs 19 (S907: Yes), it then determines whether the application rewriting has been completed for all target ECUs 19 (S908). If CGW13 determines that the application rewriting has been completed for all target ECUs 19 (S908: Yes), it ends the power management processing for non-target ECUs 19. If CGW13 determines that the application rewriting has not been completed for all target ECUs 19 (S908: No), it returns to step S904 and repeats step S904 and subsequent steps.

[0629] When there are multiple ECUs 19 to be modified, CGW13 can either allow the states of each ECU 19 to transition independently or simultaneously. That is, in... Figure 83 The diagram shows how CGW13 processes power disconnect or sleep requests sent to the non-modified ECU19. The following diagram illustrates... Figure 84 as well as Figure 85 In this section, we will explain the power management processing for the ECU19 that is not being modified, as well as the power management processing for the ECU19 that is being modified.

[0630] First, use Figure 84 The case where CGW13 causes the states of multiple rewritten ECU19 objects to transition independently is explained. For example... Figure 84 As shown, the case where the ECU19 to be rewritten is, for example, ECU(ID1), ECU(ID2), ECU(ID3), and the ECU19 to be rewritten in the order of rewriting from morning to night during parking is explained.

[0631] CGW13 transitions all three ECUs (ID1, ID2, and ID3) from a stopped or sleep state to a started state. CGW13 keeps the first modified ECU (ID1) in the started state, transitions ECUs (ID2) and (ID3) from the started state 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 the started state to a stopped or sleep state, transitions the second modified ECU (ID2) from a stopped or sleep state to the started state, keeps ECU (ID3) in the stopped or sleep state, and distributes the written data to ECU (ID2).

[0632] If CGW13 completes the distribution of the written data to ECU (ID2), it keeps ECU (ID1) in a stopped or sleep state, transitions ECU (ID2) from the start state to a stopped or sleep state, and transitions the third ECU (ID3) to be written to a start state, distributing the written data to ECU (ID3). If CGW13 completes the distribution of the written data to ECU (ID3), it keeps ECU (ID1) and ECU (ID2) in a stopped or sleep state, and transitions ECU (ID3) from the start state to a stopped or sleep state. In this way, CGW13 controls the system to only make the currently being written ECU19 in the start state among the multiple ECUs to be written.

[0633] Next, use Figure 85 This section explains the scenario where CGW13 causes the states of multiple modified ECU19 objects to transfer simultaneously. For example... Figure 85 As shown, the case where the ECU19 to be rewritten is, for example, ECU(ID1), ECU(ID2), ECU(ID3), and the ECU19 to be rewritten in the order of rewriting from morning to night during parking is explained.

[0634] CGW13 transitions all ECUs (ID1), (ID2), and (ID3) from a stopped or sleep state to a running state. CGW13 keeps all ECUs (ID1), (ID2), and (ID3) running and distributes the write data to ECU (ID1). Once CGW13 has completed distributing the write data to ECU (ID1), it distributes it to ECU (ID2). Similarly, once CGW13 has completed distributing the write data to ECU (ID2), it distributes it to ECU (ID3). Finally, once CGW13 has completed distributing the write data to ECU (ID3), it transitions all ECUs (ID1), (ID2), and (ID3) from a running state to a stopped or sleep state. In this way, CGW13 keeps all the multiple target ECUs (ID19) running until the installation is complete. Alternatively, CGW13 can simultaneously and in parallel distribute the write data to ECUs (ID1), (ID2), and (ID3).

[0635] When rewriting the application for the target ECU 19 while the vehicle is parked, the supply voltage to the target ECU 19 may not be stable, raising concerns about the possibility of the vehicle battery 40 running out of power during the application rewriting process. In particular, if there are multiple target ECUs 19, the rewriting time increases, raising the likelihood of the vehicle battery 40 running out of power during the rewriting process. To address this, by putting the non-target ECUs 19 into a stopped or sleep state as described above, the possibility of insufficient battery power in the vehicle battery 40 during the rewriting process can be prevented. Furthermore, by putting the ECUs 19 that are not currently being rewritten into a stopped or sleep state, power consumption can be further suppressed.

[0636] The above describes the case of rewriting the application of the target ECU 19 while the vehicle is parked. However, the case of rewriting the application of the target ECU 19 while the vehicle is in motion will also be explained. When rewriting the application of the target ECU 19 while the vehicle is in motion, the supply voltage to the target ECU 19 is stable, so there is no concern that the vehicle battery 40 will be depleted during the application rewriting. However, there is a possibility that the remaining battery power of the vehicle battery 40 may be low. Therefore, it is preferable to transfer the ECU 19, which does not require operation, to a stopped or sleep state while the vehicle is in motion. Figure 86 As shown, in a configuration where the ECU 44, which does not need to operate while the vehicle is in motion, is connected to the +B power line 37 but not to the ACC power line 38 or the IG power line 39, the CGW13 transfers the ECU 44, which does not need to operate while the vehicle is in motion, from the start state to the stop state or the sleep state. The ECU 44 is, for example, an ECU with anti-theft functions. That is, while all ECUs 19 are in the start state while the vehicle is in motion, the CGW13 transfers the ECU 44, which does not need to operate and is not the target of modification, to the stop state or the sleep state. This suppresses the increase in power consumption associated with installations while the vehicle is in motion.

[0637] Additionally, CGW13 monitors the remaining battery level of the vehicle battery 40 and performs the aforementioned power management processing for non-rewriteable objects. Here, using Figure 87 The monitoring and processing of battery balance is explained. If the CGW13 starts the monitoring and processing of battery balance, it monitors the battery balance during the period when the write data is distributed to the ECU19 to be rewritten (S911), and determines whether the battery balance is above the first specified capacity, or the battery balance is below the first specified capacity but above the second specified capacity, or the battery balance is below the second specified capacity (S912 to S914).

[0638] If CGW13 determines that the remaining battery capacity is above the first specified capacity (S912: Yes), it keeps the non-rewriteable ECU19 in the active state and continues to distribute data to the rewriteable ECU19 (S915). If CGW13 determines that the remaining battery capacity is below the first specified capacity but above the second specified capacity (S913: Yes), it moves the ECUs in the non-rewriteable ECU19 that do not need to operate during driving to a stopped state or a sleep state, and continues to distribute data to the rewriteable ECU19 (S916). If CGW13 determines that the remaining battery capacity is below the second specified capacity (S914: Yes), it determines whether the rewriting can be interrupted (S917).

[0639] If CGW13 determines that the rewriting can be interrupted (S917: Yes), then the distribution of the written data is interrupted (S918). If CGW13 determines that the rewriting cannot be interrupted (S917: No), then all ECUs in the non-rewriting target ECU19 that can be transferred to the stop state or sleep state are transferred to the stop state or sleep state (S919).

[0640] CGW13 determines whether the rewriting is complete (S920). If the rewriting is not complete (S920: No), it returns to step S911 and repeats step S911 and subsequent steps. If the rewriting is complete (S920: Yes), CGW13 transfers the rewritten ECU19 from a stopped or sleep state to a start state (S921), ending the battery balance monitoring process. Here, the values ​​of the first and second specified capacities can be either pre-defined by CGW13 or used from the values ​​specified by the rewriting specification data.

[0641] Additionally, in step S919, CGW13 can exclude ECUs 19 with specific functions, such as alarm functions, from being transferred to a stopped or sleep state, and transfer non-rewriteable ECUs 19, excluding those with specific functions, from the start state to a stopped or sleep state. CGW13 can also set non-rewriteable ECUs 19, excluding those capable of communicating with the rewriteable ECU 19, to a stopped or sleep state when application control can be executed in the rewrite application of the rewriteable ECU 19. When all ECUs 19 are in a stopped or sleep state, and if the rewrite conditions are met, such as the vehicle position becoming a specified position or the current time becoming a specified time, CGW13 can also transfer the rewriteable ECU 19 from the stopped or sleep state to the start state.

[0642] CGW13 can also use any one of the following as a reference to group the target ECU19 or the non-target ECU19: starting power (+B power system ECU, ACC system ECU, IG system ECU), domain group (body system, driving system, multimedia system), or synchronization timing. It can then group the target ECU19 into a starting state or the non-target ECU19 into a stopped or sleep state.

[0643] Alternatively, CGW13 can also be configured to control power on a bus-by-bus basis. That is, if it is determined that all ECUs 19 connected to a specific bus are non-rewriteable ECUs 19, CGW13 can also switch all non-rewriteable ECUs 19 connected to that specific bus to a stop or sleep state by disconnecting the power supply to that specific bus.

[0644] As explained above, CGW13 performs power management processing on non-modified ECUs, and if it determines that the modification target ECU 19 can be installed, it puts at least one non-modified ECU 19 into a stopped state, a sleep state, or a power-saving operation state. This prevents the vehicle battery 40 from becoming insufficient during application modification. Furthermore, by putting the non-modified ECU 19 into a stopped state, a sleep state, or a power-saving operation state, it is possible to suppress the increase in communication load.

[0645] (10) File transfer control processing

[0646] Reference Figures 88 to 97 The file transfer control processing is described. The vehicle program rewriting system 1 performs file transfer control processing in CGW13. This embodiment describes the processing when the rewrite data held by DCM12 (equivalent to the first device) is sent to the rewrite target ECU19 (equivalent to the third device) via CGW13 (equivalent to the second device).

[0647] like Figure 88 As shown, the CGW13 includes a file transfer control unit 82 comprising a transfer target file determination unit 82a, a first data size determination unit 82b, an information acquisition determination unit 82c, a second data size determination unit 82d, and a file splitting transfer request unit 82e. The transfer target file determination unit 82a uses the parsing result of the rewrite specification data to determine a file containing write data to the rewrite target ECU 19 as the transfer target file. For example, if the rewrite target ECU 19 is ECU(ID1), ECU(ID2), or ECU(ID3), the transfer target file determination unit 82a determines the file from... Figure 8The CGW uses rewritten specification data to obtain ECU information for ECUs (ID1), (ID2), and (ID3). Based on this obtained ECU information, the file containing the written data is identified as the transfer target file. As the transfer target file, both the address and index at which the file was obtained, and the filename, can be determined.

[0648] If the transmission target file determination unit 82a determines a transmission target file, the first data size determination unit 82b determines a first data size for acquiring the transmission target file. If the transmission target file determination unit 82a determines a transmission target file, the acquisition information determination unit 82c determines an address as acquisition information for acquiring the transmission target file. Furthermore, in this embodiment, the address is determined as acquisition information for acquiring the transmission target file, but the acquisition information is not limited to an address; it could also be a filename, ECU(ID), etc. The second data size determination unit 82d determines a second data size for distributing write data to the rewrite target ECU 19. That is, the first data size is the data transfer size from DCM 12 to CGW 13, and the second data size is the data transfer size from CGW 13 to the rewrite target ECU 19.

[0649] If the address is determined by the information acquisition determination unit 82c and the first data size is determined by the first data size determination unit 82b, then the split file transfer request unit 82e specifies the address and the first data size to the DCM12 and requests the transfer of the split file to the DCM12. For example, if the amount of data to be written to the ECU (ID1) is 1M bytes, the split file transfer request unit 82e requests the transfer of the write data in 1KB increments from address 0x10000000.

[0650] Next, refer to Figures 89 to 97 The function of the file transfer control unit 82 in CGW13 will be explained. CGW13 executes the file transfer control program and performs file transfer control processing.

[0651] If CGW13 determines that it has received a depackaging completion notification signal from DCM12, it begins file transfer control processing. Depackaging refers to... Figure 10 The process shown involves dividing the data packet file into data for each ECU and rewritten specification data. If CGW13 initiates file transmission control processing, it sends a specified address to DCM12 (S1001). Upon receiving the specified address from CGW13, DCM12 uses this reception as a trigger to transmit the rewritten specification data for CGW to CGW13. CGW13 then obtains the rewritten specification data for CGW by receiving it from DCM12 (S1002).

[0652] If CGW13 obtains the rewritten specification data for CGW from DCM12, it parses the obtained rewritten specification data for CGW (S1003), and determines the transmission object file based on the parsing result of the rewritten specification data (S1004, equivalent to the transmission object file determination step). CGW13 determines the address corresponding to the transmission object file (S1005, equivalent to the information acquisition determination step), and determines the first data size corresponding to the transmission object 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 region, and requests DCM12 to transmit the segmented file (S1007).

[0653] If DCM12 receives the address and data size from CGW13, it parses the rewritten specification data used by DCM and transmits the file corresponding to the address and data size as a segmented file to CGW13. CGW13 obtains the segmented file by receiving the segmented file from DCM12 (S1008). In this case, CGW13 may also store the obtained file in RAM and then in flash memory.

[0654] CGW13 determines whether the acquisition of all the required segmented files has been completed (S1009). For example, if the amount of data in the write file to be distributed to ECU (ID1) is 1M bytes, CGW13 acquires each 1KB segmented file, repeats the acquisition of each 1KB segmented file, and determines whether the acquisition of 1M bytes of data has been completed. If CGW13 determines that the acquisition of all the required segmented files 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 required files has been completed (S1009: "Yes"), it ends the file transfer control process. In addition, if there are multiple ECUs 19 to be modified, CGW13 repeats the above file transfer control process for each ECU 19 to be modified.

[0655] That is, for example, if the ECU19 to be modified is ECU(ID1), ECU(ID2), and ECU(ID3), if CGW13 completes the data distribution to ECU(ID1), it performs file transfer control processing for ECU(ID2); if it completes the data distribution to ECU(ID2), it performs file transfer control processing for ECU(ID3). Alternatively, CGW13 can perform transfer control processing for multiple ECUs to be modified sequentially, or it can perform these processes in parallel.

[0656] exist Figure 90 In the DCM12 memory, 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 "6999".

[0657] In this case, such as Figure 91 As shown, if CGW13 receives an unpacking completion notification signal from DCM12, it sends address "0000" to DCM12 to retrieve rewrite specification data. That is, if DCM12 determines that the reception at address "0000" is a request to retrieve rewrite data for CGW, it sends rewrite specification data for CGW to CGW13. CGW13 designates ECU (ID1) as the target for writing data transmission, specifies address "1000" and data size "1KB", and retrieves a segmented file containing the write data for ECU (ID1) stored at addresses "1000" to "1999" from DCM12. If CGW13 retrieves the segmented file from DCM12, it distributes the write data contained in that segmented file to ECU (ID1).

[0658] CGW13 then similarly designates ECU (ID1) as the target for the write data transfer, specifying address "2000" and data size "1 kilobyte," and retrieves a segmented file from DCM12 containing the write data for ECU (ID1) stored at addresses "2000" to "2999." If CGW13 retrieves a segmented file from DCM12, it distributes the write data contained within that segmented file to ECU (ID1). This process continues until all write data to ECU (ID1) is complete. CGW13 repeatedly retrieves segmented files from DCM12 in 1 kilobyte increments and repeatedly distributes the write data contained within those segmented files to ECU (ID1). That is, if CGW13 retrieves 1 kilobyte of write data from DCM12, it sends that 1 kilobyte to the target ECU (ID1). Once the transmission to the target ECU (ID1) is complete, it retrieves the next 1 kilobyte from DCM12. CGW13 repeats this process until the entire write operation is complete.

[0659] If CGW13 successfully completes the write data writing in ECU(ID1), it designates ECU(ID2) as the target for the write data transfer, specifies address "4000" and data size "1 kilobyte", and retrieves a segmented file containing the write data of ECU(ID2) stored at addresses "4000" to "4999" from DCM12. If CGW13 retrieves the segmented file from DCM12, it distributes the write data contained in that segmented file to ECU(ID2).

[0660] If CGW13 successfully completes the write data writing in ECU(ID2), it designates ECU(ID3) as the target for the write data transfer, specifies address "7000" and data size "1 kilobyte", and retrieves a segmented file containing the write data of ECU(ID2) stored at addresses "7000" to "7999" from DCM12. If CGW13 retrieves the segmented file from DCM12, it distributes the write data contained in that segmented file to ECU(ID2).

[0661] As explained above, CGW13 determines the target file for transmission based on the parsing results of the rewritten specification data by performing file transfer control processing, and determines the address and data size corresponding to the target file. CGW13 specifies this address and data size to DCM12, requests the transmission of a segmented file containing the target file, and retrieves the segmented file from DCM12. Therefore, while using DCM12's memory to store large amounts of write data, write data can be distributed to ECU19. In other words, CGW13 does not require dedicated memory for storing large files, thus reducing its memory capacity.

[0662] Here, the relationship between the amount of data in the segmented file transferred from DCM12 to CGW13 and the amount of data in the write file distributed from CGW13 to the rewritten target ECU19 is explained. In the example above, as... Figure 92 As shown, the case where the data size of the segmented file transmitted from DCM12 to CGW13 is 1k bytes has been explained, but the relationship between the data size of the segmented file transmitted from DCM12 to CGW13 and the data size of the write file distributed from CGW13 to the rewritten object ECU19 can also be arbitrary.

[0663] That is, for example, if the target ECU 19 uses a 4KB data reception specification for write data due to CAN communication reasons, then CGW 13 distributes the write file data to the target ECU 19 in 4KB units. In this case, if the data size of the segmented file transmitted from DCM 12 to CGW 13 is 1KB, then CGW 13 distributes 4KB to the target ECU 19 after obtaining four segmented files from DCM 12. That is, the data size of the segmented files transmitted from DCM 12 to CGW 13 is smaller than the data size of the write file distributed from CGW 13 to the target ECU 19. In this relationship, CGW 13 can suppress the increase of memory capacity and obtain segmented files from DCM 12 and distribute write data to the target ECU 19 in parallel.

[0664] That is, if the amount of data in the segmented file transferred from DCM12 to CGW13 is 4KB, then to obtain the segmented file from DCM12 and distribute the write data to the target ECU19 in parallel, the memory capacity of CGW13 needs to be 8KB. By making the amount of data in the segmented file transferred from DCM12 to CGW13 1KB, the memory capacity of CGW13 does not need to be 8KB, and the segmented file can be obtained from DCM12 and the write data can be distributed to the target ECU19 in parallel. For example, if the memory capacity of CGW13 is pre-ensured to be 5KB, CGW13 distributes the 4KB obtained from DCM12 to the target ECU19 and obtains the next 1KB from DCM12. Moreover, after CGW13 has completed distributing 4KB to the target ECU19, it further obtains the next 1KB from DCM12.

[0665] On the other hand, for example, if the target ECU 19 uses a 128-byte write data reception specification due to CAN communication reasons, then CGW13 distributes the write data to the target ECU 19 in 128-byte increments. In this case, if the data volume of the segmented file transmitted from DCM12 to CGW13 is 1KB, then CGW13 distributes the data to the target ECU 19 in 128-byte increments after obtaining one segmented file from DCM12. That is, the data volume of the segmented file transmitted from DCM12 to CGW13 is larger than the data volume of the write file distributed from CGW13 to the target ECU 19. For example, if the memory capacity of CGW13 is pre-ensured to be 2KB, CGW13 distributes the 1KB obtained from DCM12 to the target ECU 19 in 128-byte increments, and then obtains the next 1KB from DCM12. Moreover, after CGW13 has distributed 128 bytes × 8 times to the target ECU 19, it further obtains the next 1KB from DCM12.

[0666] Thus, as long as the amount of data in the split file transmitted from DCM12 to CGW13 is a fixed value (e.g., 1 kilobyte), the amount of data in the write file distributed from CGW13 to the target ECU19 can be a variable value according to the specifications of the target ECU19. CGW13 can also, for example, use the data transfer size of each ECU specified by the rewrite specification data to determine the amount of data distributed to the target ECU19.

[0667] CGW13 sends a transmission request to DCM12, requesting the transmission of the segmented file. However, there are two methods for requesting the transmission of the segmented file to DCM12: a first request method and a second request method. If the object to be modified, ECU19, has completed receiving the written data, it sends a reception completion notification to CGW13 indicating that the reception of the written data has been completed. If it has completed writing the written data, it sends a write completion notification to CGW13 indicating that the writing of the written data has been completed.

[0668] use Figure 93 The first distribution method is described below. If CGW13 obtains a segmented file from DCM12, it distributes the obtained segmented file as write data to the rewrite target ECU19. If the rewrite target ECU19 completes the reception of the write data, it sends a reception completion notification to CGW13 and begins the write data processing. If CGW13 receives the write data reception completion notification from the rewrite target ECU19, it sends a transmission request to DCM12, requesting the transmission of the next segmented file. If CGW13 obtains the next segmented file from DCM12, it distributes the obtained next segmented file as write data to the rewrite target ECU19.

[0669] In this way, in the first distribution method, CGW13 does not need to wait for the write data of the target ECU19 to be completed, but instead obtains the next write data from DCM12 and distributes it to the target ECU19. Therefore, in the first distribution method, if the target ECU19 has not completed writing the write data, even if the next segment file is obtained from DCM12 and the next write data is distributed to the target ECU19, the target ECU19 may not be able to receive the next write data. However, if the target ECU19 has completed writing the write data, the next segment file can be quickly obtained from DCM12 and the next write data can be quickly distributed to the target ECU19.

[0670] use Figure 94The second distribution method is explained below. If CGW13 obtains a segmented file from DCM12, it distributes the obtained segmented file as write data to the rewrite target ECU19. If the rewrite target ECU19 completes the reception of the write data, it sends a reception completion notification to CGW13 and begins the write data writing process. If the rewrite target ECU19 completes the writing, it sends a write completion notification to CGW13. If CGW13 receives the write completion notification from the rewrite target ECU19, it sends a transmission request to DCM12, requesting the transmission of the next segmented file. If CGW13 obtains the next segmented file from DCM12, it distributes the obtained next segmented file as write data to the rewrite target ECU19.

[0671] Thus, in the second distribution method, after waiting for the write data of the target ECU 19 to be completed, CGW13 obtains the next write data from DCM12 and distributes it to the target ECU 19. Therefore, in the second distribution method, there is a time required in CGW13 until the next segment file is obtained from DCM12, allowing it to request the transmission of the segment file from DCM12 even after the target ECU 19 has completed writing the write data. Therefore, if the next segment file is obtained from DCM12 and the next write data is distributed to the target ECU 19, the next write data can be reliably distributed to the target ECU 19.

[0672] Additionally, CGW13 distributes write data to the target ECU19 via SIDs 34, 36, and 37. As a method of distributing write data to the target ECU19, there are two distribution methods: a first distribution method and a second distribution method. In the first distribution method, such as... Figure 95 As shown, the CGW13 divides the write data to be distributed into segments according to a specified data size (e.g., 1KB). In the second distribution method, as... Figure 96 As shown, CGW13 distributes the write data uniformly without segmenting it. CGW13 selects either a first or second distribution method based on the SID34 initially distributed to the rewritten object ECU19. For example... Figure 97 As shown, CGW13 determines the receipt of write data to the target ECU19 by receiving an ACK (SID74) for SID37, which was last distributed to the target ECU19. The ACK for SID37 is equivalent to... Figure 93 and Figure 94The above-mentioned notification of completion of receiving the write data. That is, in the first distribution method, if CGW13 receives an ACK for the last distribution of SID37 to the ECU19 to be rewritten, it further obtains the next write data from DCM12 at the same time as distributing the next write data to the ECU19 to be rewritten, by incrementing the address of the next write data by 1.

[0673] Additionally, in the DCM's rewritten specification data, addresses are mapped to files. However, as a method of mapping addresses to files, a folder structure can also be designed, such as storing specification data in folder 1, file 1 in folder 2, and file 2 in folder 3, or managing them according to the order of filenames. For example... Figure 10 The unpacking process shown involves storing the rewritten specification data for DCM and CGW in folder 1, the ECU (ID1) authentication code and differential data in folder 2, and the ECU (ID2) authentication code and differential data in folder 3 for management purposes.

[0674] Additionally, if the CGW13 interrupts the distribution of write data to the target ECU19 for some reason, such as a communication interruption, it obtains information from the target ECU19 indicating the address where the write data has been completed, and requests the DCM12 to transmit a segmented file containing the write data from the moment the write was never completed. Alternatively, the CGW13 may also request the DCM12 to transmit a segmented file containing the write data from the beginning.

[0675] As explained above, if CGW13 determines the file containing write data to be written to the target ECU19 as the transfer target file through file transfer control processing, determines the address and first data size of the transfer target file, requests the transfer of the segmented file from DCM12, transfers the segmented file from DCM12, and then distributes the write data to the target ECU for rewriting. This enables efficient transfer of write data from DCM12 to CGW13 and distribution of write data from CGW13 to the target ECU19 for rewriting.

[0676] (11) Distribution control processing of written data

[0677] Reference Figures 98 to 108 The data distribution control process is explained. The vehicle program rewriting system 1 performs data distribution control processing in the CGW13. The CGW13 sends the data to the ECU19 via the vehicle's bus, therefore data distribution control processing is performed to prevent the bus load from becoming too high during the data distribution process.

[0678] like Figure 98As shown, this assumes that the +B power system ECU, ACC system ECU, and IG system ECU are connected to the same bus. In this case, under +B power conditions, only the +B power system ECU is activated, while the ACC and IG system ECUs are deactivated. Therefore, only vehicle control data from the +B power system ECU is transmitted to the bus. Under ACC power conditions, both the +B and ACC system ECUs are activated, while the IG system ECU is deactivated. Therefore, vehicle control data from both the +B and ACC system ECUs is transmitted to the bus. Under IG power conditions, all three ECUs are activated, and vehicle control data from all three are transmitted to the bus. In other words, the amount of vehicle control data transmitted follows the order of IG power condition, ACC power condition, and +B power condition.

[0679] like Figure 99 As shown, the CGW13 has a first correspondence determination unit 83a, a second correspondence determination unit 83b, a transmission allowance determination unit 83c, a distribution frequency determination unit 83d, a bus load measurement unit 83e, and a distribution control unit 83f in the data distribution control unit 83.

[0680] The first correspondence determination unit 83a determines the first correspondence representing the relationship between the power state and the bus transmission allowance based on the parsing results of the rewritten specification data. Figure 100 The bus load table shown is used to illustrate this. The transmission allowance refers to the transmission load value that allows data to be sent and received without data collisions or delays. The bus load table is a table showing the correspondence between power states and bus transmission allowances, specified for each bus. The transmission allowance is the sum of the amount of vehicle control data and write data that can be transmitted relative to the maximum transmission allowance.

[0681] exist Figure 100 In the example, the transmission allowance of the first bus is "80%" of the maximum transmission allowance. Therefore, under IG power, CGW13 allows "50%" of the maximum transmission allowance as the transmission allowance for vehicle control data and "30%" of the maximum transmission allowance as the transmission allowance for write data. Additionally, for the first bus, under ACC power, CGW13 allows "30%" of the maximum transmission allowance as the transmission allowance for vehicle control data and "50%" of the maximum transmission allowance as the transmission allowance for write data. Furthermore, for the first bus, under +B power, CGW13 allows "20%" of the maximum transmission allowance as the transmission allowance for vehicle control data and "60%" of the maximum transmission allowance as the transmission allowance for write data. Figure 100 As shown, the second and third buses are also defined in the same way.

[0682] The second correspondence determination unit 83b determines the second correspondence between the bus and the power system to which the modified ECU19 belongs based on the parsing results of the modified specification data. Figure 101 The table shown represents the ECU to which the modified ECU belongs. This table indicates the bus and power system to which the modified ECU 19 belongs.

[0683] exist Figure 101 In the example, CGW13 connects the first modified ECU 19 to the first bus and starts in any of the +B power state, ACC power state, and IG power state, thus identifying the first modified ECU 19 as a +B power system ECU. Furthermore, CGW13 connects the second modified ECU 19 to the second bus, stops in the +B power state, but starts in the ACC power state and IG power state, thus identifying the second modified ECU 19 as an ACC system ECU. Finally, CGW13 connects the third modified ECU 19 to the third bus, stops in the +B power state and ACC power state, but starts in the IG power state, thus identifying the third modified ECU 19 as an IG system ECU.

[0684] CGW13 usage Figure 8 The data shown in the rewrite specification data, specifically the "Connection Bus" and "Connection Power Supply," determines which bus and power system the target ECU19 will be connected to. Furthermore, if this information can be determined, it may not be necessary to store it in a table.

[0685] The transmission allowance determination unit 83c determines the transmission allowance of the bus to which the target ECU 19 belongs, i.e., the transmission allowance corresponding to the power state of the vehicle when the program update is performed, based on the determination results of the first correspondence and the second correspondence. Specifically, the transmission allowance determination unit 83c uses the second correspondence, i.e., the target ECU to which the target ECU belongs, to determine the bus to which the target ECU 19 belongs, and uses the first correspondence, i.e., the bus load table, to determine the transmission allowance for each power state of the determined bus.

[0686] The distribution frequency determination unit 83d uses a predetermined correspondence between power states and write data distribution frequencies to determine the write data distribution frequency corresponding to the power state at the time of installation. Specifically, the distribution frequency determination unit 83d uses a bus load table to determine the transmission allowance allocated for write data distribution from the transmission allowance determined by the transmission allowance determination unit 83c, and thus determines the write data distribution frequency. For example, the distribution frequency determination unit 83d determines that the bus to which the ECU19 to be rewritten belongs is the first bus, and that the power state at the time of installation is the IG power state, determines the transmission allowance to be "80%", and determines that the transmission allowance allocated for write data distribution is "30%", thereby determining the write data distribution frequency. The transmission allowance allocated for write data distribution is equivalent to transmission restriction information.

[0687] The bus load measurement unit 83e measures the bus load of the bus belonging to the ECU 19 to which the data to be modified belongs. The bus load measurement unit 83e measures the bus load, for example, by counting the number of frames or bits received per unit time. The distribution control unit 83f controls the distribution of the written data based on the distribution frequency determined by the distribution frequency determination unit 83d.

[0688] Next, refer to Figures 102 to 108 The function of the write data distribution control unit 83 in CGW13 will be explained. CGW13 executes the write data distribution control program to perform write data distribution control processing.

[0689] If CGW13 receives an unpacking completion notification signal from DCM12, it begins the data distribution control process. CGW13 obtains the rewrite specification data for CGW from DCM12 (S1101), and determines the bus load table and the target ECU to which the data belongs based on this data (S1102). CGW13 determines the bus to which the target ECU19 belongs based on the target ECU to which the data belongs (S1103). CGW13 determines the transmission allowance corresponding to the bus to which the target ECU19 belongs, i.e., the vehicle's power state at the time of the update, based on the bus load table. Furthermore, CGW13 considers the determined transmission allowance and determines the data distribution frequency (S1104, equivalent to the distribution frequency determination step). For example, when distributing data to the first target ECU19, i.e., ECU (ID1), while the vehicle is in motion, CGW13 refers to the transmission allowance of the first bus under the IG power state. Figure 100In the example, the transmission allowance of the first bus under IG power state is "80%", which allows "50%" transmission in vehicle control data and "30%" transmission in write data. Furthermore, the transmission allowance is ultimately a value used to represent a specific instance, and the numerical value is set within the allowable range according to the applicable communication specifications.

[0690] Since one frame takes approximately 250 μs in the 500 kbps CAN specification, four interruptions within one second will generate four frames, resulting in a 100% bus load. CGW13 determines the data distribution frequency by detecting these interruptions on the bus. CGW13 begins measuring the number of frames received per unit time, starting bus load measurement (S1105), determining whether the measured bus load exceeds the transmission allowable amount (S1106), and setting the distribution interval. The distribution interval refers to the time interval between distributing write data to the target ECU 19 in CGW13, receiving a write completion notification (ACK) from the target ECU 19, and sending the next write data to the target ECU 19.

[0691] If CGW13 determines that the measured bus load does not exceed the transmission allowable amount (S1106: "No"), it sets the data distribution interval to the preset minimum interval. Figure 103 As shown, the process begins (S1107, equivalent to the distribution control step) of distributing write data to the target ECU 19. Specifically, CGW13 sets the distribution interval of one frame on the CAN bus to the preset minimum interval and begins distributing write data to the target ECU 19. Furthermore, one frame on the CAN bus contains 8 bytes of write data. Additionally, one frame on the CAN FD (CAN with Flexible Data-Rate) contains 64 bytes of write data.

[0692] On the other hand, if CGW13 determines that the measured bus load exceeds the transmission allowable amount (S1106: "Yes"), it calculates the interval at which the bus load does not exceed the transmission allowable amount (S1108) and sets the data distribution interval to the calculated interval, such as... Figure 104 As shown, the write data is distributed to the object to be rewritten, ECU19, starting from step S1109 (equivalent to the distribution control step).

[0693] For example, under IG power conditions, the CGW13 determines whether the bus load on the first bus exceeds the transmission allowance, i.e., "80%". If it determines that the bus load does not exceed the transmission allowance, it sets the data write transmission allowance to a distribution interval T1 of "30%". That is, as... Figure 100As shown in the bus load table, CGW13 uses the write data transfer allowance of "30%" in the first bus under IG power condition to set the distribution interval T1. CGW13 sets the distribution interval T1 to be the maximum allowable transfer amount. In addition, CGW13 can also measure the bus load by having the measurement object converge to the write data frame, and determine whether the bus load based on the write data exceeds the write data transfer allowance of "30%". If CGW13 determines that the bus load exceeds the transfer allowance, it changes the distribution interval T2 (> T1) to be such that the bus load does not exceed the transfer allowance. In this way, after CGW13 obtains the write data from DCM12, it waits until the set distribution interval is reached, and then distributes the write data to the object to be rewritten, ECU19.

[0694] If CGW13 starts distributing write data to the target ECU19, it determines whether the distribution of write data to the target ECU19 is complete, and continuously determines whether the measured bus load exceeds the transmission allowable amount (S1110, S1011). If CGW13 determines that the measured bus load does not exceed the transmission allowable amount (S1111: "No"), it sets the write data distribution interval to the preset minimum interval and changes the distribution interval for distributing write data to the target ECU19 (S1112). On the other hand, if CGW13 determines that the measured bus load exceeds the transmission allowable amount (S1111: "Yes"), it calculates the interval at which the bus load does not exceed the transmission allowable amount (S1113), sets the write data distribution interval to the calculated interval, and changes the distribution interval for distributing write data to the target ECU19 (S1114).

[0695] If CGW13 determines that the write data distribution to the target ECU19 has been completed (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. Here, when there are multiple target ECUs19, CGW13 performs write data distribution control processing for installation to all target ECUs19.

[0696] As explained above, CGW13 performs write data distribution control processing, using a pre-determined correspondence between power states and write data distribution frequency to determine the frequency at which write data is distributed to the target ECU19, and controls the distribution of write data accordingly. This suppresses data conflicts and delays during installation. Furthermore, write data distribution can coexist without interfering with the distribution of vehicle control data on the same bus.

[0697] Furthermore, in CGW13, the example above illustrates determining the structure of the bus load table based on the parsing results of the modified specification data; however, the structure of the bus load table can also be pre-saved. Additionally, in CGW13, the example illustrates determining the structure of the table to which the modified target ECU belongs based on the parsing results of the modified specification data; however, the structure of the table to which the modified target ECU belongs can also be pre-saved.

[0698] Alternatively, the amount of data distributed during writes can be relatively small when the vehicle is in motion and relatively large when the vehicle is parked. That is, as... Figure 105 As shown, when the IG power is on while the vehicle is in motion, the CGW13 sends CAN frames through the IG system ECU, ACC system ECU, and +B power system ECU, resulting in a relatively large amount of data transmission for vehicle control, diagnostics, and other applications, thus reducing the amount of data distributed for write operations. Additionally, as... Figure 106 As shown, when the IG power is disconnected while the vehicle is parked, the CGW13 sends CAN frames through the +B power system ECU only, resulting in a relatively small amount of data transmission for vehicle control, diagnostics, and other applications, and a relatively large amount of data distribution for write operations. In other words, the CGW13 adjusts the amount of write data distribution within its idle capacity without hindering the transmission of data for vehicle control, diagnostics, and other applications.

[0699] Alternatively, it can be like Figure 107 As shown, in CGW13, when an event frame is sent from the target ECU19, the frequency of interruptions increases and the bus load increases by receiving the event frame, thus resulting in a relatively small amount of write data being distributed. When no event frame is sent from the target ECU19, the amount of write data being distributed is relatively large.

[0700] Alternatively, it can be like Figure 108 As shown, in a vehicle system, when it is determined that CGW13 is distributing write data, the bus load is reduced by extending the transmission interval of application data such as vehicle control and diagnostics to the maximum allowable interval. In CGW13, the bus load can also be reduced by extending the transmission interval of application data by the vehicle system, thereby allowing for a relatively larger amount of write data to be distributed.

[0701] The bus load table embedded in the rewritten specification data is set uniformly, regardless of the vehicle manufacturer's model or class. This is because if the ECU's equipment differs significantly due to factors such as model or class, the bus load will also differ significantly. Setting the optimal bus load table independently based on model and class would be tedious and time-consuming during the verification process, thus avoiding such tediousness.

[0702] Similar to the case described above where installation is performed while the vehicle is in motion, data distribution control processing is also performed when installation is performed while the vehicle is parked. In this case, if the target ECU 19 is a +B power system ECU, the update can also be performed in the +B power state, therefore the transmission allowance for the +B power state in the bus load table is referenced. On the other hand, if the target ECU 19 is an IG system ECU, the installation is performed in the IG power state, therefore the transmission allowance for the IG power state in the bus load table is referenced. Here, for example, if the target ECU 19 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. Furthermore, the structure of storing the bus load table and the table to which the target ECU belongs has been explained, but as long as the frequency of data distribution for each power state can be determined, it can also be stored in any table format.

[0703] (12) Instruction processing for activation request

[0704] Reference Figures 109 to 111 The instruction processing for activation requests is explained. The vehicle program rewriting system 1 processes activation request instructions in the CGW13. The CGW13 issues activation requests to multiple rewritten ECUs 19 for which application programs have been rewritten, thus making the rewritten programs effective. In this embodiment, the CGW13 parses the rewriting specification data used by the CGW to obtain the status of the group of rewritten ECUs 19. Furthermore, the CGW13 only issues activation requests when the vehicle is stationary; it does not issue activation requests while the vehicle is in motion.

[0705] like Figure 109 As shown, the CGW13 includes a rewrite target determination unit 84a, a rewrite completion determination unit 84b, an activation executable determination unit 84c, and an activation request instruction unit 84d in the activation request instruction unit 84a. The rewrite target determination unit 84a identifies multiple rewrite target ECUs 19 under cooperative control as objects. If the rewrite completion determination unit 84b identifies multiple rewrite target ECUs 19 by the rewrite target determination unit 84a, it determines whether the program rewriting has been completed in all of the identified multiple rewrite target ECUs 19.

[0706] If the rewrite completion determination unit 84b determines that the program rewriting has been completed in all of the multiple rewrite target ECUs 19, the activation executable determination unit 84c determines whether activation can be performed. If activation is based on user consent and the vehicle is parked, the activation executable determination unit 84c determines that activation can be performed.

[0707] If the activation executable determination unit 84c determines that activation can be performed, the activation request instruction unit 84d instructs an activation request. Specifically, after instructing a switching request for a new side, the activation request instruction unit 84d instructs a reset request, monitors session transfer timeout, or monitors the internal reset of the rewritten target ECU 19, thereby instructing the activation request. In a dual-sided memory ECU or a single-sided suspended memory ECU, the application is activated by starting on a new side (non-application side) where the application has been written. On the other hand, in a single-sided separate memory ECU, the application is activated by restarting. In addition, the rewritten target ECU 19 may also be configured to reset itself after instructing a switching request for a new side, regardless of the activation request.

[0708] Next, refer to Figure 110 and Figure 111 The function of the activation request instruction unit in CGW13 will be explained. CGW13 executes the activation request instruction procedure and performs activation request instruction processing.

[0709] If CGW13 initiates the activation request instruction processing, it identifies multiple rewrite target ECUs 19 (S1201, equivalent to the rewrite target identification step). Specifically, CGW13 identifies the rewrite target ECUs 19 by referring to the ECU(ID) recorded in the rewrite specification data. CGW13 determines whether the application rewriting has been completed in all of the identified multiple rewrite target ECUs 19 (S1202, equivalent to the rewrite completion determination step). For example, CGW13 performs installation on the rewrite target ECUs 19 sequentially according to the order of the ECU(ID) recorded in the rewrite specification data. If the installation on the last recorded ECU(ID) is completed, it is determined that the writing has been completed in all the rewrite target ECUs 19.

[0710] If CGW13 determines that the application rewriting has been completed in all of the identified multiple rewriteable ECUs 19 (S1202: "Yes"), it then determines whether activation can be performed (S1203, equivalent to the activation execution determination step). Specifically, CGW13 determines whether user consent for the update has been obtained beforehand, whether the vehicle is in a parked state, etc. If these conditions are met, it determines that activation can be performed. User consent can be consent for the update process as a whole or consent for activation. If CGW13 determines that activation can be performed (S1203: "Yes"), then it subsequently instructs activation requests to multiple rewriteable ECUs 19 simultaneously (equivalent to the activation request instruction step). Here, it is assumed that ECU(ID1), ECU(ID2), and ECU(ID3) are the same group of rewriteable ECUs 19 for explanation.

[0711] If CGW13 determines that activation can be performed on ECUs (ID1), (ID2), and (ID3), it begins processing the activation request instruction. If CGW13 begins processing the activation request instruction, it instructs the target ECU 19 to switch to a new surface (S1204). CGW13 requests the power management ECU 20 to switch the IG power supply from off to on (S1205). Although the vehicle is parked and the IG switch 42 is off, CGW13 switches the IG power supply from off to on for activation. Furthermore, if CGW13 performs activation immediately after installation, since the IG power supply is on, S1205 is not executed, and a start request (wake-up request) is sent to the sleep target ECU 19.

[0712] CGW13 sends a software reset request to the target ECU 19, instructing it to perform the software reset request (S1206). If the target ECU 19 uses a specification corresponding to the software reset request, it resets and restarts the software upon receiving the reset request from CGW13, activating the application. If the target ECU 19 is a single-sided, separate memory ECU, it switches from the old application to the new application by restarting using the new application. If the target ECU 19 is a single-sided suspended memory ECU or a double-sided memory ECU, it updates the application plane information (side A or side B) stored in the flash memory, switches the side with the new application written to it as the application plane, and thus switches from the old application to the new application.

[0713] CGW13 requests the power management ECU20 to switch the IG power supply from on to off and from off to on, instructs the target ECU19 to reset the power supply, and instructs the target ECU19 to restart (S1207). Even if the target ECU19 uses a specification that does not correspond to the software reset request, if the IG power supply is switched from on to off and from off to on, it will reset itself and restart, activating the application. In this case, if the target ECU19 is a single-sided independent memory ECU, the target ECU19 will switch from the old application to the new application by restarting using the new application. If the target ECU19 is a single-sided suspended memory ECU or a double-sided memory ECU, the target ECU19 updates the application plane information (side A or side B) stored in the flash memory, switches the side with the new application written to it as the application plane, and thus switches from the old application to the new application. Additionally, CGW13 monitors session transfer timeout (S1208) and monitors the internal reset of the rewritten object ECU19 (S1209).

[0714] That is, if the target ECU 19 uses a specification that does not correspond to the software reset request, then even if CGW13 sends a software reset request to the target ECU 19, it cannot indicate activation. Therefore, by indicating a power reset request to the target ECU 19, activation is performed on the target ECU 19, even if the specification does not correspond to the software reset request. For example, in IG system ECUs such as engine ECUs, since they are configured to reset automatically upon power switching, the situation is often not related to the software reset request. From the perspective of the target ECU 19, activation (startup in the new program) is performed based on any one of the following: a software reset request is indicated from CGW13, a power reset request is indicated from CGW13, a session transfer timeout occurs, or an internal reset occurs.

[0715] If the rewritten ECU 19 corresponding to a software reset request is indicated by CGW13, it will forcibly reset itself and become active. If the rewritten ECU 19 of the ACC system and IG system ECUs is indicated by CGW13 for a power reset request, it will not be forcibly supplied with power, and will therefore reset and become active upon the next power supply. The rewritten ECU 19 of the +B power system ECU differs from the rewritten ECU 19 of the ACC system and IG system ECUs; since it is always supplied with power, it is activated through session transfer timeout and internal reset. Furthermore, the activation method for each rewritten ECU 19 is specified by the rewrite specification data.

[0716] If CGW13 is notified from all the modified ECUs 19 that it has successfully started using the new application, it sends a switchover completion notification to DCM12 (S1210). DCM12 notifies the central device 3 that the update program activation is complete. CGW13 requests the power management ECU 20 to switch the IG power supply from on to off, completing the activation synchronization instruction processing. If CGW13 switches the IG power supply from off to on through user operation, it sends the program version, startup plane, etc. of each ECU to DCM12. DCM12 notifies the central device 3 of the information received from CGW13 regarding each ECU 19. Here, it is also possible to send ECU structure information containing the program version and startup plane information of each ECU to the central device 3 when DCM12 notifies the central device 3 of activation completion. Figure 111 This indicates that the object to be rewritten, ECU19, is either a double-sided memory ECU or a single-sided suspended memory ECU.

[0717] As explained above, CGW13 prevents multiple rewritten ECUs 19 that have completed application rewriting from switching from the old program to the new program at their own times by processing activation request instructions, thus ensuring that the switching timing is consistent across the multiple rewritten ECUs 19. In other words, the program versions of the multiple cooperating rewritten ECUs 19 become mismatched, avoiding adverse situations during collaborative processing.

[0718] (13) Activated execution control processing

[0719] Reference Figures 112 to 114 The activation execution control process will be explained. The activation execution control process is the process performed by the ECU 19 that received the activation request from the CGW13, which is accompanied by the activation request instruction process described above (12) performed by the CGW13. The vehicle program rewriting system 1 performs the activation execution control process in the ECU 19. Here, the ECU 19 has multiple data storage surfaces such as a single-sided pause mode memory and a double-sided memory. The ECU 19 has a first data storage surface and a second data storage surface, and is in a state where the rewritten data has been installed on the non-use surface (new surface).

[0720] like Figure 112As shown, the ECU19, in its activated execution control unit 107, includes an application plane information update unit 107a, an execution condition determination unit 107b, an execution control unit 107c, and a notification unit 107d. If the application plane information update unit 107a is activated by the CGW13, it updates the boot plane determination information (application plane information) in the flash memory for the next reboot. For example, if the application plane information update unit 107a is currently booting from plane A and a new program is written to plane B, it updates the application plane information from plane A to plane B.

[0721] As activation execution conditions, the execution condition determination unit 107b determines whether a software reset request has been indicated from CGW13, whether a power reset request has been indicated from CGW13 to the power management ECU20, and whether the communication interruption with CGW13 has lasted for a specified time. If any one of these conditions is met, the execution condition determination unit 107b determines that the activation execution condition is met. Alternatively, the power reset request may not be indicated from CGW13, but rather detected by the power detection circuit 36. If the execution condition determination unit 107b determines that the activation execution condition is met, the execution control unit 107c performs a new face switch (activation) based on the application face information, switching the startup face from the old face (the currently used face) to the new face (the currently unused face). The notification unit 107d notifies CGW13 of application face information, version information, and other notification information.

[0722] Next, refer to Figure 113 and Figure 114 The function of the activation execution control unit 107 for the modified ECU 19 will be explained. The modified ECU 19 executes the activation execution control program and performs activation execution control processing.

[0723] (13-1) Rewriting Process

[0724] If the rewrite target ECU 19 initiates rewrite processing, it performs pre-rewrite processing, including product number reading and authentication, before memory erasure (S1301). The rewrite target ECU 19 determines whether it has received rewrite surface information from the central device 3 (S1302). The rewrite target ECU 19 determines whether it has received rewrite surface information, for example, based on whether it has obtained the rewrite surface information recorded in the rewrite specification data contained 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 central device 3 (S1302: "Yes"), it compares the rewrite surface information with the rewrite surface information (application surface information) managed by itself and determines whether the two are consistent (S1303). Here, the rewrite surface information is, for example, recorded in the rewrite specification data sent from the central device 3. For example, if the rewrite information managed by itself is application surface A and non-application surface B, it is determined that the two are consistent if the rewrite information recorded in the rewrite specification data represents non-application surface (surface B), and inconsistent if the rewrite information recorded in the specification data represents application surface (surface A).

[0725] If the target ECU19 determines that the two are consistent (S1303: "Yes"), then it proceeds with the rewrite process, including memory erasure, writing of the data, and verification (S1304), ending the rewrite process. Verification includes, for example, verifying the integrity of the data written to the flash memory. If the target ECU19 determines that the two are inconsistent (S1303: "No"), then it sends a negative response to CGW13 (S1305), ending the rewrite process.

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

[0727] If the ECU19 to be rewritten starts active execution control processing, it uses the non-application surface as the rewriting surface and determines whether the application program has been rewritten to the rewriting surface (S1311). If the ECU19 to be rewritten determines that the application program has been rewritten to the rewriting surface (S1311: "Yes"), it verifies the integrity of the application program written to the flash memory and determines whether the rewritten data verification is positive (S1312). If the ECU19 to be rewritten determines that the rewritten data verification is positive (S1312: "Yes"), it sets the rewriting completion flag of the new surface to "OK" and stores it (S1313).

[0728] Then, the rewriting object ECU19 determines whether an activation request has been indicated from CGW13 (S1314). If the rewriting object ECU19 determines that an activation request has been indicated (S1314: "Yes"), it determines whether the rewriting completion flag of the new face is "OK" (S1315). If it determines that the rewriting completion flag of the new face is "OK" (S1315: "Yes"), it updates the application face information (S1316, equivalent to the application face information update step). That is, for example, if the application face is A and the non-application face is B, and the application is rewritten to the rewriting face by using B as the rewriting face, the rewriting object ECU19 updates the application face information indicating that the application face is A and the non-application face is B to the application face information indicating that the application face is B and the non-application face is A.

[0729] If the target ECU 19 is updated with application information, it is determined whether a software reset request has been received from CGW 13, whether a power reset request has been indicated from CGW 13 to the power management ECU 20, whether the communication interruption with CGW 13 after the software reset request was indicated lasted for a specified time, and whether the activation execution conditions are met (S1317, equivalent to the execution condition determination step). Here, if any of these activation execution conditions are met, the target ECU 19 is restarted, or the restart conditions are determined separately by the ECU.

[0730] If the modified ECU 19 determines that any of the following conditions are met: a software reset request is indicated from CGW13, a power reset request is indicated from CGW13 to the power management ECU 20, or a specified time has elapsed since the software reset request was indicated, then the activation execution condition is deemed met (S1317: "Yes"), and a restart (reset) is performed. By performing the restart, the modified ECU 19 starts the new plane (plane B) as the startup plane based on the updated application plane information (S1318, equivalent to the startup control step), ending the activation execution control process. That is, after restarting, the modified ECU 19 starts on the plane B where the application is installed.

[0731] If the ECU19 determines that the application rewriting to the new face has not been completed (S1311: "No"), or if the rewritten data verification fails (S1312: "No"), it determines whether an activation request has been indicated (S1319). If it determines that an activation request has been indicated (S1319: "Yes"), it sends a negative response to CGW13 (S1320) and returns to step S1311. Alternatively, the ECU19 may also end ...

Claims

1. A master device for a vehicle that distributes update data received from a center device to an electronic control device that is a rewriting target, and instructs the electronic control device that is the rewriting target to write the update data, wherein the master device for the vehicle acquires a software version and information that enables determination of configuration information as configuration information of the electronic control device that is the rewriting target from the electronic control device that is the rewriting target, and transmits the information to the center device, downloads a distribution package that includes rewriting specification data and new configuration information from the center device if it is determined based on a notification from the center device that there is an active notification related to program updating, and instructs the electronic control device that is the rewriting target to perform rewriting based on an overwrite of the configuration information using the new configuration information if it is determined based on the rewriting specification data that it is rewriting of the configuration information.

2. The master device for the vehicle according to claim 1, wherein it is determined whether the configuration information is normally overwritten after instructing the electronic control device that is the rewriting target to perform rewriting based on an overwrite of the configuration information.

3. The master device for the vehicle according to claim 2, wherein the configuration information is temporarily saved before instructing the electronic control device that is the rewriting target to perform rewriting based on an overwrite of the configuration information, and if it is determined that the configuration information is not normally overwritten, and it is determined that rollback is necessary, the electronic control device that is the rewriting target is instructed to perform rollback, and the electronic control device that is the rewriting target is instructed to restore the saved configuration information.

4. An electronic control system for a vehicle that includes a master device for the vehicle and an electronic control device, the master device for the vehicle distributing update data received from a center device to the electronic control device that is a rewriting target, and instructing the electronic control device that is the rewriting target to write the update data, and the electronic control device rewriting a program of a nonvolatile memory using the update data received from the master device for the vehicle, wherein the master device for the vehicle acquires a software version and information that enables determination of configuration information as configuration information of the electronic control device that is the rewriting target from the electronic control device that is the rewriting target, and transmits the information to the center device, downloads a distribution package that includes rewriting specification data and new configuration information from the center device if it is determined based on a notification from the center device that there is an active notification related to program updating, and instructs the electronic control device that is the rewriting target to perform rewriting based on an overwrite of the configuration information using the new configuration information if it is determined based on the rewriting specification data that it is rewriting of the configuration information.

5. A method of instructing rewriting of configuration information, wherein in a master device for a vehicle that distributes update data received from a center device to an electronic control device that is a rewriting target, and instructs the electronic control device that is the rewriting target to write the update data, the following is performed. ​ ​ ​ ​ ​ The software version and information capable of determining the configuration information are acquired from the electronic control device of the rewriting target as structure information of the electronic control device of the rewriting target and transmitted to the center device, if it is determined based on the notification from the center device that there is an active notification relating to program update, a distribution package containing rewriting specification data and new configuration information is downloaded from the center device, if it is determined based on the rewriting specification data that it is rewriting of the configuration information, a step of instructing the electronic control device of the rewriting target to perform rewriting based on the covering of the configuration information using the new configuration information is performed.

6. A recording medium recording a rewriting instruction program of configuration information, wherein A vehicle main device that causes update data received from a center device to be distributed to electronic control devices of rewriting targets and instructs writing of the update data to the electronic control devices of the rewriting targets performs: The software version and information capable of determining the configuration information are acquired from the electronic control device of the rewriting target as structure information of the electronic control device of the rewriting target and transmitted to the center device, if it is determined based on the notification from the center device that there is an active notification relating to program update, a distribution package containing rewriting specification data and new configuration information is downloaded from the center device, if it is determined based on the rewriting specification data that it is rewriting of the configuration information, a step of instructing the electronic control device of the rewriting target to perform rewriting based on the covering of the configuration information using the new configuration information is performed.

Images