Central device, vehicle information communication system, and distribution package sending method

Abstract

The present invention provides a central device, a vehicle information communication system, a distribution package sending method, and a distribution package sending program. ECU reconfiguration data (204) stores a new program, an old program, and new differential data for updating the old program to the new program, i.e., update data, for a target ECU (19). A first verification value generating unit generates a first hash value using the new program, and a second verification value generating unit generates a second hash value using the update data. A package generating unit (202) generates a package containing update data, a first verification value, a second verification value, and specification data for a plurality of target ECUs (19). A third verification value generating unit generates a third hash value using the distribution package, and a package distributing unit (203) sends the distribution package together with the third hash value to a vehicle-side system (4).

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

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

[0003] The present invention relates to a central device for managing data written to a plurality of electronic control devices mounted on a vehicle, a vehicle information communication system including the central device and an onboard device mounted on the vehicle, a distribution package sending method, and a distribution package sending program. Background Art

[0004] In recent years, with the diversification of vehicle control such as driving assistance functions and automatic driving functions, the scale of vehicle control or diagnosis applications such as electronic control devices (hereinafter referred to as ECUs (Electronic Control Units)) installed in vehicles has increased. In addition, with version upgrades based on functional improvements, the chances of rewriting (reprogramming) ECU applications have also increased. On the other hand, with the advancement of communication networks, vehicle networking technology has also become popular. Based on such circumstances, for example, the following technology is disclosed in Patent Document 1, which distributes ECU update programs from a center to on-board devices via OTA (Over The Air) and rewrites the update programs on the vehicle side.

[0005] Furthermore, Patent Document 1 discloses a technique for preventing inappropriate rewriting of a control program by allowing rewriting based on information such as the current position of the vehicle, the current time, and the signal level of wireless communication.

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

[0007] As described above, when rewriting an update program distributed OTA on the vehicle side, it is necessary to confirm that the correct update program has been distributed and correctly written into the electronic control device. Summary of the Invention

[0008] The present invention has been completed in view of the above situation, and its purpose is to provide a central device, a vehicle information communication system, a distribution package sending method and a distribution package sending program that can confirm that the data of an application distributed from a central device is correctly distributed and correctly written into an electronic control device.

[0009] According to the center device of the present invention, an update data storage unit stores new data, old data, and new differential data for updating the old data from the new data for target devices among multiple electronic control devices installed in a vehicle. A first verification value generation unit uses the new data to generate a first verification value for verifying integrity in the vehicle, and a second verification value generation unit uses the new differential data to similarly generate a second verification value for verifying the integrity of the new differential data. A distribution package generation unit generates a package containing the new differential data for the multiple target devices, as well as the first and second verification values.

[0010] The third verification value generation unit generates a third verification value for verifying the integrity of the distribution package in the vehicle using the distribution package, and the distribution package transmission unit transmits the distribution package together with the third verification value to the in-vehicle device.

[0011] With this configuration, an on-board device that receives a distribution package can use the third verification value to verify the integrity of the distribution package, namely, the new differential data, the specification data, and the first and second verification values. Furthermore, after confirming their integrity, the second verification value can be used to verify the integrity of the new differential data. Furthermore, the first verification value can be used to verify the integrity of the new data, which is the addition of the new differential data to the old data. Thus, the integrity of the new data can be verified three times, preventing the on-board device from writing incomplete new data.

[0012] Furthermore, according to the vehicle information communication system of the present invention, when the onboard device receives a distribution package and a third verification value transmitted from a center device having the same structure as described above, the third verification processing unit calculates a verification value for the distribution package and compares the calculated verification value with the third verification value to verify the integrity of the distribution package. The second verification processing unit calculates a verification value for new differential data corresponding to the target device and included in the distribution package and compares the calculated verification value with the second verification value included in the distribution package to verify the integrity of the new differential data.

[0013] The write processing unit writes the new differential data included in the distribution package to the non-volatile memory of the target device. The first verification processing unit calculates a verification value for the data in the non-volatile memory and compares the calculated verification value with the first verification value to verify the integrity of the data in the non-volatile memory. In this way, the in-vehicle device can verify the integrity of each data value at multiple stages using each verification value.

[0014] In addition, according to the vehicle information communication system of the present invention, the vehicle-mounted device is the same as described above. If the write processing unit uses the new differential data included in the distribution package to write to the non-volatile memory of the target device, the first verification processing unit calculates the verification value of the data in the non-volatile memory and sends it to the central device.

[0015] The central device compares a first verification value used to verify the integrity of new data stored in the update data storage unit with the verification value received from the first verification processing unit and transmits the result as a verification result to the onboard device. The first verification processing unit of the onboard device receives the verification result transmitted from the central device. With this configuration, the central device can verify the integrity of data written to the non-volatile memory of the target device, while the onboard device can recognize the verification result. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Refer to the attached Figure 1 The above-mentioned object and other objects, features and advantages of the present invention will become more apparent from the following detailed description.

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

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

[0019] Figure 3 This is a diagram showing the electrical structure of the ECU.

[0020] Figure 4 This diagram shows how to connect the power cord.

[0021] Figure 5 This diagram shows a format in which reorganization data and distribution specification data are packaged.

[0022] Figure 6 This figure shows the form of unpacking the distribution package.

[0023] Figure 7 This diagram shows a portion of the center device that mainly relates to each function of the server in the form of a block diagram.

[0024] Figure 8 This is a schematic diagram showing the flow of processing in the central device.

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

[0026] Figure 10 This is a diagram showing an example of programs and data registered in the ECU reconfiguration data DB.

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

[0028] Figure 121 is a diagram showing an example of the structural information of a vehicle registered in the vehicle information DB.

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

[0030] Figure 14 This is a diagram showing an example of activity data registered in the activity DB.

[0031] Figure 15 This is a flowchart showing a process of generating a program and data to be registered in the ECU reconfiguration data DB.

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

[0033] Figure 17 This is a diagram showing an example of specification data.

[0034] Figure 18 This is a diagram showing an example of a bus load table.

[0035] Figure 19 This is a flowchart showing a process of generating a distribution package to be registered in the package DB.

[0036] Figure 20 A diagram schematically showing the contents of a package file.

[0037] Figure 21 This is a sequence diagram showing a processing procedure executed between the central device and the vehicle-side system in the second embodiment.

[0038] Figure 22 This is a flowchart showing the processing performed by the center device.

[0039] Figure 23 It is schematically represented in Figure 22 FIG. 1 is a diagram showing the contents of processing performed in steps D6 and D7 of the flowchart shown.

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

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

[0042] Figure 25 This is a flowchart showing the processing performed by the center device.

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

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

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

[0046] Figure 29 This is a sequence diagram (part 1) showing the processing steps performed between the supplier, the central device, and the vehicle-side system.

[0047] Figure 30 This is a sequence diagram (part 2) showing the processing steps performed between the supplier, the central device, and the vehicle-side system.

[0048] Figure 31 This is a sequence diagram (part 3) showing the processing steps performed between the supplier, the central device, and the vehicle-side system.

[0049] Figure 32 This is a modification (Part 1) of the first embodiment, and is a diagram showing the data format of a package DB in a case where a plurality of packages are associated with one activity.

[0050] Figure 33 This is a diagram showing the data format of the activity DB when multiple packages are associated with one activity.

[0051] Figure 34 This is equivalent to generating specification data for each group. Figure 16 Image

[0052] Figure 35 This is equivalent to generating a distribution package for each group. Figure 19 Image

[0053] Figure 36 This is a modification (Part 2) of the first embodiment, and is a diagram showing the processing contents of the package generation tool.

[0054] Figure 37 It is a diagram showing the overall structure of the sixth embodiment.

[0055] Figure 38 This is a diagram showing the electrical structure of CGW.

[0056] Figure 39 It is a diagram showing the electrical structure of DCM.

[0057] Figure 40 This is a diagram showing the electrical structure of the ECU.

[0058] Figure 41 This diagram shows how to connect the power cord.

[0059] Figure 42 This diagram shows a format in which reorganization data and distribution specification data are packaged.

[0060] Figure 43 This is a diagram showing rewritten specification data for DCM.

[0061] Figure 44 This is a diagram showing rewriting specification data for CGW.

[0062] Figure 45 This is a diagram showing distribution specification data.

[0063] Figure 46 This figure shows the form of unpacking the distribution package.

[0064] Figure 47 This is a diagram showing the normal operation of an embedded-type single-sided independent memory.

[0065] Figure 48 This is a diagram showing the state of an embedded-type single-side independent memory during rewriting operation.

[0066] Figure 49 This is a diagram showing the normal operation of a download-type single-sided independent storage.

[0067] Figure 50 This is a diagram showing a format during rewriting operation of a download-type single-side independent memory.

[0068] Figure 51 This is a diagram showing a normal operation of an embedded single-side suspend memory.

[0069] Figure 52 This is a diagram showing a state during a rewrite operation of an embedded-type single-side suspend memory.

[0070] Figure 53 This is a diagram showing a normal operation of a download-type single-side suspend memory.

[0071] Figure 54 This is a diagram showing a form of a download-type single-side suspend memory rewrite operation.

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

[0073] Figure 56 This is a diagram showing the state of an embedded-type double-sided memory during rewriting operation.

[0074] Figure 57 This is a diagram showing the normal operation of a download-type two-sided memory.

[0075] Figure 58 This is a diagram showing the format of a download-type double-sided memory during rewriting operation.

[0076] Figure 59 This figure shows the format of rewriting the application.

[0077] Figure 60 This figure shows the format of rewriting the application.

[0078] Figure 61 This figure shows the format of rewriting the application.

[0079] Figure 62 This is a sequence diagram showing how the application program is rewritten using power control.

[0080] Figure 63 This is a sequence diagram showing how the application program is rewritten using power control.

[0081] Figure 64 This is a timing diagram showing how the application program is rewritten while the power supply is maintained.

[0082] Figure 65 This is a timing diagram showing how the application program is rewritten while the power supply is maintained.

[0083] Figure 66 It is a diagram showing the stages.

[0084] Figure 67 This figure shows a normal screen.

[0085] Figure 68 This figure shows a screen when an event notification is generated.

[0086] Figure 69 This figure shows a screen when an event is notified.

[0087] Figure 70 This is a diagram showing a screen that appears when downloading is approved.

[0088] Figure 71 This is a diagram showing a screen that appears when downloading is approved.

[0089] Figure 72 This is a diagram showing a screen during download execution.

[0090] Figure 73 This figure shows a screen showing downloading in progress.

[0091] Figure 74 This figure shows the screen when downloading is completed.

[0092] Figure 75 This figure shows the screen when the installation is approved.

[0093] Figure 76 This figure shows the screen when the installation is approved.

[0094] Figure 77 This figure shows the screen during installation.

[0095] Figure 78 This figure shows the screen during installation.

[0096] Figure 79 This figure shows a screen when activating consent.

[0097] Figure 80 This figure shows the screen when the IG is turned on.

[0098] Figure 81 This figure shows a screen for confirming an operation.

[0099] Figure 82 This figure shows a screen for confirming an operation.

[0100] Figure 83 This is a functional block diagram of the central device.

[0101] Figure 84 This is the functional block diagram of DCM.

[0102] Figure 85 This is a functional block diagram of CGW.

[0103] Figure 86 This is a functional block diagram of CGW.

[0104] Figure 87 This is the functional block diagram of the ECU.

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

[0106] Figure 89 This is a functional block diagram of a distribution packet transmission determination unit.

[0107] Figure 90 This is a flowchart showing the distribution package transmission determination process.

[0108] Figure 91 This is a functional block diagram of a distribution package download determination unit.

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

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

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

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

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

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

[0115] Figure 98 This is a flowchart showing the installation instruction determination process.

[0116] Figure 99 This is a diagram showing the form of instruction installation.

[0117] Figure 100 This is a diagram showing the form of instruction installation.

[0118] Figure 101 This is a diagram showing the format of generating random values.

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

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

[0121] Figure 104 This is a diagram showing the format for generating a secure access key.

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

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

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

[0125] Figure 108 This is a flowchart showing the verification process of written data.

[0126] Figure 109 This figure shows a form in which the processing related to verification of written data is distributed.

[0127] Figure 110 This figure shows a form in which the processing related to verification of written data is distributed.

[0128] Figure 111 This figure shows a form in which the processing related to verification of written data is distributed.

[0129] Figure 112 This figure shows a form in which the processing related to verification of written data is distributed.

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

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

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

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

[0134] Figure 117 This is a sequence diagram showing a format for notifying 2-side rewriting information.

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

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

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

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

[0139] Figure 122 This diagram shows how to connect the power cord.

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

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

[0142] Figure 125 This is a flowchart showing the file transfer control process.

[0143] Figure 126 This is a diagram showing the format of sending and receiving files.

[0144] Figure 127 This is a diagram showing the format of sending and receiving files.

[0145] Figure 128 This is a diagram showing the split files and written files.

[0146] Figure 129 This is a diagram showing the format in which CGW sends a transmission request to DCM.

[0147] Figure 130 This is a diagram showing the format in which CGW sends a transmission request to DCM.

[0148] Figure 131 This diagram shows the format in which the CGW distributes write data to the rewriting target ECU.

[0149] Figure 132 This diagram shows the format in which the CGW distributes write data to the rewriting target ECU.

[0150] Figure 133 This diagram shows the format in which the CGW distributes write data to the rewriting target ECU.

[0151] Figure 134 This is a diagram showing the connection configuration of the ECU.

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

[0153] Figure 136 It is a diagram showing a bus load table.

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

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

[0156] Figure 139 This is a diagram showing the format of distributing write data.

[0157] Figure 140 This is a diagram showing the format of distributing write data.

[0158] Figure 141 This figure shows a format for distributing write data while a vehicle is traveling.

[0159] Figure 142 This is a diagram showing a format for distributing written data during parking.

[0160] Figure 143 This is a graph showing the distribution amount of write data.

[0161] Figure 144 This is a graph showing the distribution amount of write data.

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

[0163] Figure 146 This is a flowchart showing the instruction processing of the activation request.

[0164] Figure 147 This is a diagram showing a format for instructing an activation request.

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

[0166] Figure 149 This is a flowchart showing the rewriting process.

[0167] Figure 150 is a flowchart showing the execution control process of activation.

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

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

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

[0171] Figure 154 This is a diagram showing a format in which rewrite objects are grouped.

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

[0173] Figure 156 This is a flowchart showing the process of determining the rollback method.

[0174] Figure 157 This is a flowchart showing the cancellation request determination process.

[0175] Figure 158 This is a flowchart showing the cancellation request determination process.

[0176] Figure 159 This is a flowchart showing the cancellation request determination process.

[0177] Figure 160 This is a flowchart showing the cancellation request determination process.

[0178] Figure 161 This is a flowchart showing the cancellation request determination process.

[0179] Figure 162 This is a diagram showing the form of executing rollback.

[0180] Figure 163This is a diagram showing the form of executing rollback.

[0181] Figure 164 This is a diagram showing the form of executing rollback.

[0182] Figure 165 This is a diagram showing the form of executing rollback.

[0183] Figure 166 This is a diagram showing the form of executing rollback.

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

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

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

[0187] Figure 170 This is a diagram showing a screen showing the progress of rewriting.

[0188] Figure 171 This is a diagram showing a screen showing the progress of rewriting.

[0189] Figure 172 This is a diagram showing a screen showing the progress of rewriting.

[0190] Figure 173 This is a diagram showing a screen showing the progress of rewriting.

[0191] Figure 174 This is a diagram showing a screen showing the progress of rewriting.

[0192] Figure 175 This is a diagram showing the transition displayed by the progress chart.

[0193] Figure 176 This is a diagram showing the transition displayed by the progress chart.

[0194] Figure 177 This is a diagram showing the transition displayed by the progress chart.

[0195] Figure 178 This is a diagram showing the transition displayed by the progress chart.

[0196] Figure 179 This is a diagram showing a screen showing the progress of rewriting.

[0197] Figure 180 This is a functional block diagram of a differential data integrity determination unit.

[0198] Figure 181This is a flowchart showing the consistency determination process of differential data.

[0199] Figure 182 This is a diagram showing a format for determining the integrity of differential data.

[0200] Figure 183 This is a diagram showing a format for determining the integrity of differential data.

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

[0202] Figure 185 This is a flowchart showing normal operation processing.

[0203] Figure 186 This is a flowchart showing the rewriting operation process.

[0204] Figure 187 This is a flowchart showing information notification processing.

[0205] Figure 188 This is a flowchart showing the verification process of the rewritten program.

[0206] Figure 189 This is a diagram showing the format of sending identification information and write data.

[0207] Figure 190 This is a diagram showing the format of sending identification information and write data.

[0208] Figure 191 This is a flowchart showing the installation instruction processing.

[0209] Figure 192 This is a functional block diagram of the session establishment unit.

[0210] Figure 193 It is a diagram that shows the structure of a program.

[0211] Figure 194 It is a diagram showing state transitions.

[0212] Figure 195 It is a diagram showing state transitions.

[0213] Figure 196 It is a diagram showing state transitions.

[0214] Figure 197 This is a diagram showing the mediation of a conversation.

[0215] Figure 198 This is a diagram showing the mediation of a conversation.

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

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

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

[0219] Figure 202 4 is a flowchart showing the state transition management process in the second state.

[0220] Figure 203 4 is a flowchart showing the state transition management process in the second state.

[0221] Figure 204 It is a diagram that shows the structure of a program.

[0222] Figure 205 It is a diagram showing state transitions.

[0223] Figure 206 This is a functional block diagram of a retry point determination unit.

[0224] Figure 207 This is a diagram showing the structure of a flash memory.

[0225] Figure 208 This is a flowchart showing the process of setting the processing flag.

[0226] Figure 209 This is a flowchart showing the process of determining the processing flag.

[0227] Figure 210 This is a flowchart showing the process of determining the processing flag.

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

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

[0230] Figure 213 This is a diagram showing the format of a transmission / reception progress status signal.

[0231] Figure 214 This is a flowchart showing the progress of the synchronous control process.

[0232] Figure 215 This is a flowchart showing the progress of the synchronous control process.

[0233] Figure 216 This is a flowchart showing the progress status display process.

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

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

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

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

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

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

[0240] Figure 223 This is a diagram showing rewritten specification data.

[0241] Figure 224 This figure shows the screen when a menu is selected.

[0242] Figure 225 This figure shows the screen when the user makes a selection.

[0243] Figure 226 This figure shows a screen when a user registers.

[0244] Figure 227 This is a flowchart showing screen display control processing for progress display.

[0245] Figure 228 This is a flowchart showing screen display control processing for progress display.

[0246] Figure 229 is a diagram showing a message frame.

[0247] Figure 230 This figure shows a screen when activating consent.

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

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

[0250] Figure 233 This figure shows a screen when activating consent.

[0251] Figure 234 This is a diagram showing the format of data communication.

[0252] Figure 235 This diagram shows the message frame for activity notification.

[0253] Figure 236 This is a diagram showing a message frame when downloading is approved.

[0254] Figure 237 This is a diagram showing a message frame when installation is approved.

[0255] Figure 238 This is a diagram showing a message frame when activating consent.

[0256] Figure 239 This is a diagram showing screen transitions.

[0257] Figure 240 This figure shows a screen when an event notification is generated.

[0258] Figure 241 This is a diagram showing a screen that appears when downloading is approved.

[0259] Figure 242 This is a diagram showing a screen that appears when downloading is approved.

[0260] Figure 243 This is a diagram showing a screen during download execution.

[0261] Figure 244 This figure shows the screen when downloading is completed.

[0262] Figure 245 This figure shows the screen when the installation is approved.

[0263] Figure 246 This figure shows a screen when activating consent.

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

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

[0266] Figure 249 This is a diagram showing the report format of the indicator.

[0267] Figure 250 This is a diagram showing the transition of the report format when the rewriting target is a two-sided memory.

[0268] Figure 251 This is a diagram showing the transition of the report format when the rewriting target is a single-side suspended memory.

[0269] Figure 252 This is a diagram showing the transition of the report format when the rewriting target is a single-side independent memory.

[0270] Figure 253It is a diagram showing the connection form.

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

[0272] Figure 255 This is a functional module that controls the execution of the self-power-sustaining control unit in the ECU.

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

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

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

[0276] Figure 259 This is an overall sequence diagram showing the form of rewriting the application.

[0277] Figure 260 This is an overall sequence diagram showing the form of rewriting the application.

[0278] Figure 261 This is an overall sequence diagram showing the form of rewriting the application.

[0279] Figure 262 This is an overall sequence diagram showing the form of rewriting the application.

[0280] Figure 263 This is an overall sequence diagram showing the form of rewriting the application.

[0281] Figure 264 This is an overall sequence diagram showing the form of rewriting the application.

[0282] Figure 265 This is an overall sequence diagram showing the form of rewriting the application.

[0283] Figure 266 This is an overall sequence diagram showing the form of rewriting the application.

[0284] Figure 267 This is an overall sequence diagram showing the form of rewriting the application.

[0285] Figure 268 This is an overall sequence diagram showing the form of rewriting the application.

[0286] Figure 269 This is an overall sequence diagram showing the form of rewriting the application. DETAILED DESCRIPTION

[0287] (First embodiment)

[0288] Below, refer to Figures 1 to 20 The first embodiment of the present invention will be described. A vehicle program rewriting system is a system that can rewrite vehicle control, diagnosis, and other application programs of the ECU mounted on the vehicle via OTA. Figure 1 As shown, a vehicle program rewriting system 1 includes a central device 3 on the communication network 2 side, a vehicle-side system 4 on the vehicle side, and a display terminal 5. The communication network 2 is composed of, for example, a mobile communication network such as a 4G line, the Internet, or WiFi (Wireless Fidelity) (registered trademark).

[0289] The display terminal 5 is a terminal that has the function of accepting user input and displaying various screens. Examples include a portable terminal 6 such as a smartphone or tablet computer that the user can carry, and an in-vehicle display 7 such as a display that also functions as a navigation system or an instrument display. The portable terminal 6 can connect to the communication network 2 as long as it is within the communication range of the mobile communication network. The in-vehicle display 7 is connected to the vehicle-side system 4.

[0290] If the user is outside the vehicle and within the communication range of the mobile communication network, they can use the portable terminal 6 to confirm various screens related to application rewriting while performing operations and inputting, and can perform procedures related to application rewriting. Inside the vehicle, the user can use the in-vehicle display 7 to confirm various screens related to application rewriting while performing operations and inputting, and can perform procedures related to application rewriting. In other words, the user can use the portable terminal 6 and in-vehicle display 7 separately outside and inside the vehicle to perform procedures related to application rewriting.

[0291] The center device 3 coordinates the OTA functions on the communication network 2 side and functions as an OTA center in the vehicle program rewriting system 1. The center device 3 includes a file server 8, a network server 9, and a management server 10. The servers 8 to 10 are configured to communicate data with each other.

[0292] The file server 8 manages applications sent from the center device 3 to the vehicle-side system 4. It manages ECU programs and accompanying information provided by application providers (e.g., suppliers), distribution specification data provided by OEMs (Original Equipment Manufacturers), and vehicle status information received from the vehicle-side system 4. The file server 8 is capable of data communication with the vehicle-side system 4 via the communication network 2. Upon receiving a download request for a distribution package, the file server 8 transmits a distribution package containing reprogramming data and distribution specification data to the vehicle-side system 4. The network server 9 manages network information and provides various screens related to application rewriting to the mobile terminal 6. The management server 10 manages the personal information of users registered for the application rewriting service and manages the application rewriting history for each vehicle.

[0293] The vehicle-side system 4 includes a host device 11. The host device 11 includes a DCM 12 and a CGW 13, which are connected via a first bus 14 for data communication. The DCM 12 is an on-vehicle communication device that communicates data with the center device 3 via the communication network 2. When a distribution package is downloaded from the file server 8, the DCM 12 extracts the write data from the distribution package and transfers it to the CGW 13.

[0294] CGW13 is a vehicle gateway device with data relay function. When receiving write data from DCM12, it distributes the write data to the rewriting target ECU of the rewriting application. The main device 11 manages the OTA function of the vehicle side in the vehicle program rewriting system 1 and functions as an OTA host. Figure 1 In the embodiment, the DCM 12 and the onboard display 7 are connected to the same first bus 14 , but the DCM 12 and the onboard display 7 may be connected to different bus lines.

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

[0296] The second bus 15 is, for example, a bus of the vehicle body system network. The ECUs 19 connected to the second bus 15 are, for example, ECUs that control the vehicle body systems, such as the door ECU that controls door locking / unlocking, the instrument ECU that controls the instrument display, the air conditioning ECU that controls air conditioning operation, and the window ECU that controls window opening and closing. The third bus 16 is, for example, a bus of the vehicle travel system network. The ECUs 19 connected to the third bus 16 are, for example, ECUs that control the vehicle travel systems, such as the engine ECU that controls engine operation, the brake ECU that controls brake operation, the ECT (ETC (Electronic Toll Collection System: registered trademark)) ECU that controls automatic transmission operation, and the power steering ECU that controls power steering operation.

[0297] The fourth bus 17 is, for example, a bus for a multimedia system network. The ECU 19 connected to the fourth bus 17 is, for example, an ECU for controlling the multimedia system, such as a navigation ECU for controlling the navigation system or an ETC ECU for controlling the electronic toll collection system (ECT). Buses 15-17 may also be buses for systems other than the body system network, the driving system network, or the multimedia system network. The number of buses and ECUs 19 is not limited to the illustrated configuration.

[0298] The power management ECU 20 is an ECU having a function of managing power supplies of the DCM 12 , the CGW 13 , the various ECUs 19 , and the like.

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

[0300] Upon receiving write data from the CGW 13, the target ECU 19 writes the write data to the flash memory, thereby rewriting the application program. In the above configuration, the CGW 13 functions as a reprogramming master. Upon receiving a write data acquisition request from the target ECU 19, the CGW 13 distributes the write data to the target ECU 19. The target ECU 19 functions as a reprogramming slave. Upon receiving write data from the CGW 13, the CGW 13 writes the write data to the flash memory, thereby rewriting the application program.

[0301] Application rewriting methods include wired and wireless rewriting. In the wired rewriting method, the tool 23 is connected to the DLC connector 22, and the tool 23 transmits write data to the CGW 13. The CGW 13 relays or distributes the write data transmitted from the tool 23 to the rewriting target ECU 19. In the wireless rewriting method, as described above, the DCM 12 downloads a distribution package from the file server 8, extracts the write data from the distribution package, and transmits the write data to the CGW 13.

[0302] like Figure 2 As shown, the CGW 13 includes a microcomputer (hereinafter referred to as microcomputer) 24, a data transmission circuit 25, a power supply circuit 26, and a power detection circuit 27 as electrical functional modules. The microcomputer 24 includes a CPU (Central Processing Unit) 24a, a ROM (Read Only Memory) 24b, a RAM (Random Access Memory) 24c, and a flash memory 24d. The microcomputer 24 executes various control programs stored in a non-migratable physical storage medium to perform various processes and control the operation of the CGW 13.

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

[0304] like Figure 3As shown, the ECU 19 includes a microcomputer 28, a data transmission circuit 29, a power supply circuit 30, and a power supply detection circuit 31 as electrical function modules. The microcomputer 28 includes a CPU 28a, a ROM 28b, a RAM 28c, and a flash memory 28d. The microcomputer 28 executes various control programs stored in a non-migratable physical storage medium to perform various processes and control the operation of the ECU 19.

[0305] The data transmission circuit 29 controls the data communication with the buses 15 to 17 in accordance with the CAN data communication standard. The power supply circuit 30 inputs the +B power supply, the ACC power supply, and the IG power supply. The power supply detection circuit 31 detects the voltage value of the +B power supply, the ACC power supply, and the IG power supply input by the power supply circuit 30, compares these detected voltage values with the specified voltage threshold, and outputs the comparison result to the microcomputer 28. The microcomputer 28 determines whether the +B power supply, the ACC power supply, and the IG power supply supplied from the outside to the ECU19 are normal or abnormal based on the comparison result input from the power supply detection circuit 27. In addition, the loads connected to the ECU19, such as sensors and actuators, are different and basically have the same structure. In addition, the basic structure of the DCM12, the on-board display 7, and the power management ECU is also the same. Figure 3 The ECU 19 shown is the same.

[0306] like Figure 4 As shown, the power management ECU 20, CGW 13, and ECU 19 are connected to a +B power line 32, an ACC power line 33, and an IG power line 34. The +B power line 32 is connected to the positive terminal of the vehicle battery 35. The ACC power line 33 is connected to the positive terminal of the vehicle battery 35 via an ACC switch 36. When the user performs an ACC operation, the ACC switch 36 switches from off to on, and the output voltage of the vehicle battery 35 is applied to the ACC power line 33. The so-called ACC operation, for example, is the operation of inserting the key into the key slot and turning the key from the "OFF" position to the "ACC" position in the case of a vehicle that requires a key to be inserted into the key slot, or the operation of pressing the start button once in the case of a vehicle that requires a key to be pressed.

[0307] The IG power line 34 is connected to the positive terminal of the vehicle battery 35 via the IG switch 37. When the user performs an IG operation, the IG switch 37 switches from off to on, and the output voltage of the vehicle battery 35 is applied to the IG power line 34. For example, in a vehicle with a key-operated key slot, this involves inserting the key into the slot and turning it from the "off" position to the "on" position. In a vehicle with a push-button start, this involves pressing the start button twice. The negative terminal of the vehicle battery 35 is grounded.

[0308] When both the ACC switch 36 and the IG switch 37 are off, only the +B power supply is supplied to the vehicle-side system 4. This state in which only the +B power supply is supplied to the vehicle-side system 4 is referred to as the +B power supply state. When the ACC switch 36 is on and the IG switch 37 is off, both the ACC power supply and the +B power supply are supplied to the vehicle-side system 4. This state in which both the ACC power supply and the +B power supply are supplied to the vehicle-side system 4 is referred to as the ACC power supply state. When both the ACC switch 36 and the IG switch 37 are on, the +B power supply, the ACC power supply, and the IG power supply are supplied to the vehicle-side system 4. This state in which the +B power supply, the ACC power supply, and the IG power supply are supplied to the vehicle-side system 4 is referred to as the IG power supply state.

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

[0310] The CGW 13 transmits a start request to an ECU 19 in a sleep state, causing the ECU 19 to transition from the sleep state to the sleep state. Furthermore, the CGW 13 transmits a sleep request to an ECU 19 in an active state, causing the ECU 19 to transition from the active state to the sleep state. For example, the CGW 13 selects the ECU 19 to which the start request or sleep request is to be sent from among multiple ECUs by varying the waveforms of the signals transmitted to buses 15 to 17.

[0311] The power control circuit 38 is connected in parallel with the ACC switch 36 and the IG switch 37. The CGW 13 transmits a power control request to the power management ECU 20, causing the power management ECU 20 to control the power control circuit 38. Specifically, the CGW 13 transmits a power start request to the power management ECU 20 as a power control request, connecting the ACC power line 33, the IG power line 34, and the positive terminal of the vehicle battery 35 within the power control circuit 38. In this state, even when the ACC switch 36 and the IG switch 37 are off, ACC power and IG power are supplied to the vehicle-side system 4. The CGW 13 transmits a power stop request to the power management ECU 20 as a power control request, disconnecting the ACC power line 33, the IG power line 34 from the positive terminal of the vehicle battery 35 within the power control circuit 38.

[0312] The DCM12, CGW13, and ECU19 have a self-powered maintenance function. Specifically, if the vehicle power source switches from ACC or IG power to +B power while the DCM12, CGW13, and ECU19 are in the active state, they do not immediately transition from the active state to the sleep state or the stopped state. Instead, they maintain the active state for a predetermined period of time even after the switch, self-maintaining the driving power source. The DCM12, CGW13, and ECU19 transition from the active state to the sleep state or the stopped state after a predetermined period of time (e.g., several seconds) has passed since the vehicle power source switched from ACC or IG power to +B power.

[0313] Next, refer to Figures 5 and 6 The distribution package distributed from the center device 3 to the main device 11 is described. In the vehicle program rewriting system 1, rewriting data is generated based on the write data provided by the application provider, that is, the supplier, and the rewriting specification data mainly provided by the OEM. The write data provided by the supplier includes differential data corresponding to the difference between the old application and the new application, and overall data corresponding to the entire new application. The differential data and overall data can also be compressed using a well-known data compression technology. Figure 5 In the example, differential data from suppliers A to C is provided as write data. Rewritten data is generated based on the encrypted differential data and authenticator from ECU (ID1) provided by supplier A, the encrypted differential data and authenticator from ECU (ID2) provided by supplier B, the encrypted differential data and authenticator from ECU (ID3) provided by supplier C, and rewrite specification data provided by the OEM. An authenticator is assigned to each piece of write data.

[0314] In addition, Figure 5 In the example, the difference data when updating from the old application to the new application is shown, but the reprogramming data may also include the rollback difference data for writing back from the new application to the old application. For example, when the rewrite target ECU 19 is a single-sided memory, the reprogramming data includes the rollback difference data.

[0315] The rewrite specification data provided by the OEM is information related to application rewriting. It includes information that identifies the ECU 19 to be rewritten, information that determines the rewrite order when there are multiple ECUs to be rewritten, and information that determines the rollback method (described later). These data define rewrite-related operations in the DCM 12, CGW 13, and the ECU 19 to be rewritten. The rewrite specification data is divided into DCM rewrite specification data used by the DCM 12 and CGW rewrite specification data used by the CGW 13. The DCM rewrite specification data contains information necessary for reading files corresponding to the ECU 19 to be rewritten. As mentioned above, the CGW rewrite specification data contains information necessary for controlling the rewrite of the ECU 19 to be rewritten.

[0316] Upon receiving the DCM rewrite specification data, the DCM 12 analyzes the DCM rewrite specification data and, based on the analysis results, controls rewrite-related operations such as transmission of write data to the CGW 13. Upon receiving the CGW rewrite specification data, the CGW 13 analyzes the CGW rewrite specification data and, based on the analysis results, controls rewrite-related operations such as acquisition of write data from the DCM 12 and distribution of the write data to the rewrite target ECU 19.

[0317] The above-mentioned re-edited data is registered in the file server 8 , and the distribution specification data provided by the OEM is also registered. The distribution specification data provided by the OEM is data that defines actions associated with the display of various screens on the display terminal 5 .

[0318] If the file server 8 has registered the re-edited data and the distribution specification data, it will encrypt the re-edited data and generate a distribution package that packages the package authentication code, the encrypted re-edited data, and the distribution specification data into one file. If the file server 8 receives a download request for the distribution package from the outside, it will send the distribution package to the DCM 12. Figure 5 In the example, the file server 8 generates a distribution package storing the recompiled data and the distribution specification data, and sends the recompiled data and the distribution specification data to the DCM 12 simultaneously. However, the recompiled data and the distribution specification data may be sent separately to the DCM 12. That is, the file server 8 may first send the distribution specification data to the DCM 12 and then send the recompiled data to the DCM 12. Alternatively, the file server 8 may combine the recompiled data and the distribution specification data into a distribution package as a single file and send the distribution package and the package authenticator to the DCM 12.

[0319] When the DCM12 downloads the distribution package from the file server 8, it verifies the package authentication code and the encrypted recoded data stored in the distribution package. If the verification result is positive, it decodes the encrypted recoded data. When the DCM12 decodes the encrypted recoded data, it unpacks the decoded recoded data and generates encrypted differential data and authentication codes for each ECU, rewrite specification data for the DCM, and rewrite specification data for the CGW. Figure 6 , there is illustrated an example of generating encrypted differential data and an authenticator of ECU (ID1), encrypted differential data and an authenticator of ECU (ID2), encrypted differential data and an authenticator of ECU (ID3), and rewriting specification data.

[0320] Figure 7 The portion of the center device 3 that mainly relates to the functions of the servers 8 to 10 is shown in a block diagram. Figure 8 The following is an overview of the processing performed by the center device 3 regarding the program update of the ECU. In addition, "database" may be expressed as "DB" in some cases. Figure 7 As shown, the center device 3 includes a package management unit 3A, a configuration information management unit 3B, a vehicle information management unit 3C, and an activity management unit 3D. The package management unit 3A includes a specification data generation unit 201, a package generation unit 202, a package distribution unit 203, an ECU reconfiguration data database 204, an ECU metadata database 205, and a package database 206. The configuration information management unit 3B includes a configuration information registration unit 207 and a configuration information database 208.

[0321] The supplier uses the user interface (UI) function of the management server 10, namely the input unit 218 and the display unit 219, to register ECU individual data. ECU individual data includes program files such as new programs and differential data, program file-related information such as verification data, size, and encryption method of program files, and data related to ECU attribute information such as the memory structure of ECU19. Program files are stored in ECU reconfiguration data DB204. ECU attribute information is stored in ECU metadata DB205. Program file-related information can also be stored in ECU reconfiguration data DB204 or in ECU metadata DB205. ECU reconfiguration data DB204 is an example of an update data storage unit. In addition, ECU metadata DB205 is an example of a device-related information storage unit.

[0322] The OEM registers the formal structural information in the structural information DB 208 according to each vehicle model through the structural information registration unit 207. Formal structural information refers to the structural information of the vehicle approved by a public agency. Structural information is identification information related to the hardware and software of the ECU 19 installed in the vehicle, and is an example of vehicle-related information. The structural information also includes identification information of the system structure composed of multiple ECUs 19 and identification information of the vehicle structure composed of multiple systems. In addition, as structural information, vehicle restriction information related to program updates can also be registered. For example, the ECU group information recorded in the rewrite specification data, the bus load table, information related to the battery load, etc. can also be registered. The ECU metadata DB 205 is an example of a device-related information storage unit. In addition, the structural information DB 208 is an example of a vehicle information storage unit.

[0323] The specification data generation unit 201 generates rewrite specification data by referring to various databases. The package generation unit 202 generates a distribution package containing the rewrite specification data and the recompiled data, and registers it in the package DB 206. The package generation unit 202 may also generate a distribution package containing the distribution specification data. The package distribution unit 203 distributes the registered distribution package to the vehicle-side system 4. The distribution package is equivalent to a file.

[0324] The bicycle information management unit 3C includes a bicycle information registration unit 209, a structure information confirmation unit 210, an update confirmation unit 211, an SMS sending control unit 212, and a bicycle information DB 213. The bicycle information registration unit 209 registers the bicycle information uploaded by each vehicle in the bicycle information DB 213. As an initial value, the bicycle information registration unit 209 may also register the bicycle information at the time of vehicle production or sale in the bicycle information DB 213. When registering the uploaded bicycle information, the structure information confirmation unit 210 compares the bicycle information with the structure information of the same model vehicle registered in the structure information DB 208. The update confirmation unit 211 confirms whether the bicycle information has been updated based on the new program, that is, whether it is active. When the bicycle information is updated, the SMS sending control unit 212 sends a message related to the update to the corresponding vehicle via SMS (Short Message Service).

[0325] The activity management unit 3D includes an activity generation unit 214, an activity distribution unit 215, an instruction notification unit 216, and an activity database 217. The OEM generates activity information related to program updates through the activity generation unit 214 and registers it in the activity database 217. The activity information here corresponds to the "distribution specification data" described above and primarily relates to the updated content displayed on the vehicle-side system 4. The activity distribution unit 215 distributes the activity information to the vehicle. The instruction notification unit 216 notifies the vehicle of instructions required for program updates. In the vehicle-side system 4, for example, a user determines whether to download the updated program based on the activity information transmitted from the center device 3 and, if necessary, proceeds with the download.

[0326] Note that the parts of each management unit 3A to 3D other than the databases are functions realized by computer hardware and software.

[0327] The vehicle communication unit 222 is a functional module for wirelessly communicating data between the center device 3 and the vehicle-side system 4 .

[0328] The above-mentioned processing will be described in more detail below. First, the contents of the data registered in each database will be described. Figure 9 As shown, the following data is registered in the configuration information DB 208, as an example. "Vehicle Model" indicates the vehicle model. "Vehicle SW ID" is the software ID for the entire vehicle and corresponds to the vehicle software ID. Each vehicle is assigned only one "Vehicle SW ID," and the "Vehicle SW ID" is updated whenever the application version of one or more ECUs is updated. If the group of multiple ECUs 19 installed in each vehicle is referred to as a "system," the "Sys ID" is the ID of that system.

[0329] For example, in Figure 1 In the figure, the group of body system ECU19 is the body system, and the group of travel system ECU19 is the travel system. As the version of the application of any one or more ECUs constituting the system is updated, the "Sys ID" is updated. "ECUID" is an ID for device identification that indicates the type of each ECU. "ECU SW ID" is the software ID for each ECU, which is equivalent to the ECU software ID. Here, for convenience, the software version is appended to the "ECU ID" to indicate it. As the version of the application of the ECU is updated, the "ECU SW ID" is updated. In addition, even if the same "ECU ID" is the same program version, different "ECU SW IDs" are used when the hardware structure is different. That is, "ECU SW ID" is also information indicating the product number of the ECU.

[0330] exist Figure 9 , shows configuration information related to a vehicle with "vehicle model" = "aaa." Examples of the ECUs 19 mounted on the vehicle include the automatic driving ECU (ADS), the engine ECU (ENG), the brake ECU (BRK), and the electric power steering ECU (EPS).

[0331] For example, for "Vehicle SW ID" = "0001," the "ECU SW IDs" are "ads_001," "eng_010," "brk_001," and "eps_010." For "Vehicle SW ID" = "0002," the "ECU SW IDs" are "ads_002," "eng_010," "brk_005," and "eps_011," indicating that three software versions have been updated. Consequently, "Sys ID" = "SA01" is updated to "SA02," and "Sys ID" = "SA02" is updated to "SA03." Thus, initial values are registered in configuration information DB 208 at the time of vehicle production or sale, and are subsequently updated as the application versions of one or more ECUs are updated. In other words, configuration information DB 208 represents the officially available configuration information for each vehicle model.

[0332] like Figure 10 As shown in FIG. 2 , the following programs and data are registered in the ECU reconfiguration data DB 204 as an example. Figure 10 In this example, the automated driving ECU (ADS), brake ECU (BRK), and electric power steering ECU (EPS) are shown as examples of ECUs 19 installed in a certain vehicle model whose applications are being updated. For the latest "ECUSW ID" of these update-target ECUs 19, the ECU's old and new program files, integrity verification data for the new program, an update data file (differential data between the new and old programs), integrity verification data for the update data, a rollback data file (also differential data), and integrity verification data for the rollback data are registered. The integrity verification data is a hash value obtained by applying a hash function to the data value. Furthermore, when the update data is replaced with the differential data to create the entire new program data, the integrity verification data for the updated data is identical to the same data for the new program.

[0333] In addition, Figure 10, the data structure for the latest "ECU SW ID" is shown. However, if data for an older "ECU SW ID" is stored, a new program file for the older "ECU SW ID" may be referenced for the older program file. Furthermore, each integrity verification data may be registered as a value calculated by the vendor or calculated and registered by the center device 3.

[0334] like Figure 11 As shown, the ECU metadata DB 205 registers the following ECU-specific specification data, as an example. Regarding the latest "ECU SW ID," the update data file size and rollback data file size are used. If the flash memory 28d included in the ECU 19 has two or more sides, side information indicating whether the program is used on side A, B, or C, transfer size, and program file readout addresses are used. These are examples of update data-related information.

[0335] In addition, attribute information representing the attributes of ECU 19 is also registered in ECU metadata DB 205. Attribute information refers to information representing the hardware attributes and software attributes related to the ECU. "Transfer size" is the transfer size when the rewrite data is divided and transferred from CGW 13 to ECU 19, and "key" is the key used by CGW 13 to securely access ECU 19. This is an example of software attribute information. In addition, "Vehicle Model" and "ECU ID" also include the memory structure of the flash memory 28d equipped by ECU 19, the type of bus to which ECU 19 is connected, the type of power supply connected to ECU 19, etc. This is an example of hardware attribute information.

[0336] Here, the memory structure "1-side" refers to a single-side independent memory with a flash memory surface on one side, "2-side" refers to a dual-side memory with flash memory surfaces on both sides, and "suspend" refers to a single-side suspended memory with pseudo dual-side flash memory surfaces. Hardware attribute information and software attribute information are used to control the rewrite of each ECU 19 in the vehicle-side system 4. While hardware attribute information can be pre-stored by the CGW 13, in this embodiment, it is managed by the central device 3 to reduce the management load on the vehicle-side system 4. Software attribute information is data that directly specifies the rewrite actions for each ECU 19. It is managed by the central device 3 to enable flexible control within the vehicle-side system 4.

[0337] like Figure 12As shown, in the vehicle information DB 213, as an example, the following data for each vehicle is registered. Primarily, the data is registered for each vehicle's configuration information and vehicle status information for program updates. Specifically, the "VIN," or "Vehicle SW ID," "Sys ID," "ECU ID," and "ECU SW ID" are configuration information related to each vehicle. The center device 3 also calculates and stores hash values, or "Digest" values, for this configuration information. In the case of a two-sided memory structure, the "operation side" is the side where the program currently being operated by the ECU 19 is written, and the uploaded values are registered along with the configuration information.

[0338] The "Access Log" records the year, month, day, and time when a vehicle uploads its individual vehicle information to the center device 3. The "Reconfiguration Status" indicates the status of the vehicle's reconfiguration, including statuses such as "Activation Completed," "Activation Completed," and "Download Completed." This progress status indicates the current stage of the vehicle's reconfiguration and where it has stalled. Furthermore, when configuration information and other information are uploaded from the vehicle-side system 4 to the center device 3, the information is assigned the "VIN" of each vehicle.

[0339] like Figure 13 As shown, the distribution package ID, distribution package file, and data for integrity verification of the distribution package are registered in the package DB 206.

[0340] like Figure 14 As shown, the following data is registered in the activity DB 217: the activity information ID, the distribution package ID, message information such as text indicating the specific update content of the activity, a list of "VINs" (vehicle IDs) for the vehicles targeted by the activity, the "Vehicle SW IDs" before and after the update, and a list of "ECU SW IDs" before and after the update. The "target VIN" list can be registered by comparing it with the vehicle information DB 213 and the activity DB 217. Furthermore, this activity information can also be registered in the package DB 206.

[0341] Next, the effects of this embodiment will be described. Figure 15 In the following, the registration process of the package management unit 3A to the ECU reconfiguration data DB 204 is described. Figure 15As shown, the display unit 219 and input unit 218 activate the management server 10's reconfiguration data registration screen, accepting input of the old and new program files for the ECU 19 from the supplier's operator (A1). For example, a UI for registering files containing configuration information in CSV format or the like may also be used. Next, the package management unit 3A generates integrity verification data for the new program (A2), and as differential data for updating, generates a differential data file for updating the old program to the new program, and integrity verification data for the updated differential data (A3, A4).

[0342] Next, as differential data for rollback, a differential data file is generated for updating the old program from the new program, along with integrity verification data for that data (A5, A6). These program files and verification data are registered in the ECU reconfiguration data DB 204. A new "ECU SW ID" is generated based on the old "ECU SW ID" and registered (A7). If the entire data is distributed instead of differential data, the steps related to differential data can be omitted.

[0343] The integrity verification data is, for example, a hash value generated by applying a hash function. For example, when SHA-256 (Secure Hash Algorithm 256-bit) is used as the hash function, the data value is divided into message blocks of 64 bytes each. Furthermore, if the data value of the first message block is applied to the initial hash value, resulting in a 32-byte hash value, the following process is repeated, applying the data value of the next message block to this hash value, resulting in a similar 32-byte hash value.

[0344] exist Figure 16 , the generation process of the rewritten specification data in the specification data generation unit 201 will be described. Here, the generation process of the rewritten specification data for the vehicle with "vehicle model" = "aaa" will be described, but the same applies to other vehicles.

[0345] The center device 3 starts the specification data generation program of the specification data generation unit 201 and receives input from the OEM operator via the display unit 219 and the input unit 218. First, the specification data generation unit 201 determines the ECU 19 to be updated. Figure 16As shown, the specification data generation unit 201 accesses the ECU reconfiguration data DB 204 and outputs a display screen to the display unit 219, allowing users to select data to be updated from the registered "ECU SW IDs." The specification data generation unit 201 stores one or more "ECU SW IDs" (B1) selected by the OEM operator via the input unit 218 in a defined ECU order. Here, the ECU order indicates the order in which the ECUs 19 in the vehicle-side system 4 are to be rewritten. The specification data generation unit 201 uses the order specified by the OEM operator as the defined ECU order.

[0346] Alternatively, the specification data generating unit 201 may access the configuration information DB 208 and determine the ECU 1 to be updated without receiving input from the OEM operator. The specification data generating unit 201 refers to the "ECU SW ID" corresponding to the latest "Vehicle SW ID" and the "ECU SW ID" corresponding to an older "Vehicle SW ID" to extract the ECU 19 to be updated. For example, Figure 9 In the example, "ADS", "BRK" and "EPS" are update target ECUs 19. The specification data generating unit 201 uses the order registered in the configuration information DB 208 as the determined ECU order.

[0347] Furthermore, the specification data generating unit 201 generates group information (B2) for ECUs having multiple "ECU SW IDs" to be updated. Here, referring to the configuration information DB 208, using "Sys ID", for example, group 1 is aggregated into "ECU IDs" with "Sys ID" "SA01_02", and group 2 is aggregated into "ECU IDs" with "Sys ID" "SA02_02". For example, Figure 9 In the example, group 1 is set to "ADS", and group 2 is set to have "BRK" as the first and "EPS" as the second. In this way, the specification data generating unit 201 determines the ECUs to be updated, the groups to which the ECUs belong, and the order of the ECUs within the groups.

[0348] Next, the specification data generating unit 201 accesses the ECU metadata DB 205 and acquires update data related information, hardware attribute information, and software attribute information as specification data related to the ECU 19 to be updated (B3). Figure 17As shown, the update data associated information is "update program version", "update program acquisition address", "update program size", "rollback program version", "rollback program acquisition address", "rollback program size", "write data type", and "write surface". The hardware attribute information is "connection bus", "connection power supply", and "memory type". The software attribute information is "overwrite surface information", "security access key information", "overwrite method", and "transmission size". "Overwrite method" is data indicating whether the power self-holding circuit is enabled for rewriting (power self-holding) when the IG switches from on to off, or whether rewriting is performed according to the IG being on and the IG being off (power control). As "security access key information", information other than the key may also be included.

[0349] Hereinafter, each information will be described.

[0350] "Written data type" indicates whether the program is differential data or full data. The written data type for the update program and the written data type for the rollback program may be separately described.

[0351] The “writing surface” is information indicating to which surface the program is to be written in the ECU 19 of the two-surface memory.

[0352] The “connected bus” is information for identifying the bus to which the ECU 19 is connected.

[0353] The “connected power source” is information indicating the power source state to which the ECU 19 is connected, and describes a value indicating any one of the battery power source (+B power source), the auxiliary power source (ACC power source), and the ignition power source (IG power source).

[0354] The “memory type” is information for identifying the memory configuration of the ECU 19 , and describes values indicating dual-side memory, single-side suspend mode memory (simulated dual-side memory), and single-side memory.

[0355] The “rewriting surface information” is information indicating which surface of the ECU 19 is the activation surface (operation surface) and which surface is the rewriting surface (non-operation surface).

[0356] The “security access key information” is information for authenticating access to the ECU 19 using a key, and includes information on a key derivation key, a key mode, and a decryption operation mode.

[0357] The “transfer size” is the data size when the program is divided and transferred to the ECU 19 .

[0358] For example, Figure 17As shown, "ECU ID" is used as a key, and this information is saved in the form of the above-mentioned determined ECU order. If the specification data generation unit 201 obtains information for all ECUs (B4; "Yes"), it specifies "rewrite environment information" (B5) for the vehicle that is the update object. "Rewrite environment information" refers to information used for rewrite control in the vehicle-side system 4 with the ECU group or the entire vehicle as the object, and is data that directly specifies the rewrite action. For example, as the rewrite environment information with the entire vehicle as the object, there are "vehicle status" indicating whether the program update in the vehicle-side system 4 is carried out while the vehicle is driving (IG switch is turned on) or while parked (IG switch is turned off), "battery load (battery remaining amount)" indicating the restriction of the battery remaining amount that can execute the program update in the vehicle-side system 4, and bus load table information indicating the restriction of the bus load that can transmit write data in the vehicle-side system 4, etc.

[0359] In addition, as the rewrite environment information for the group, there are the ECUs 19 belonging to the group and the order of the ECUs in the group. In the vehicle-side system 4, the program update is controlled to be synchronized in groups, and the writing to the ECUs 19 is performed in the specified ECU order. The specification data generation unit 201 starts the screen for registering the rewrite environment information and accepts input from the OEM operator. Alternatively, it can be in the form of inputting a spreadsheet (Excel) (registered trademark) into which the rewrite environment information is input. Alternatively, it can be in the form of extracting the constraint information registered in the structure information DB 208. In addition, the specification data generation unit 201 uses the generation result of the above-mentioned step B2 as the rewrite environment information for the group.

[0360] The bus load table is a table showing the correspondence between the power supply status and the transfer allowance of the bus. Figure 18 As shown, the transmission allowance is the sum of the transmission amounts of vehicle control data and write data that can be transmitted relative to the maximum transmission allowance. In this example, for the first bus, the transmission allowance is "80%" relative to the maximum transmission allowance. Therefore, when CGW13 is in the IG power state, the transmission allowance of vehicle control data allowed is "50%" relative to the maximum transmission allowance, and the transmission allowance of write data allowed is "30%" relative to the maximum transmission allowance. In addition, when CGW13 is in the ACC power state, the transmission allowance of vehicle control data allowed is "30%" relative to the maximum transmission allowance, and the transmission allowance of write data allowed is "50%" relative to the maximum transmission allowance. In addition, when CGW13 is in the +B power state, the transmission allowance of vehicle control data allowed is "20%" relative to the maximum transmission allowance, and the transmission allowance of write data allowed is "60%" relative to the maximum transmission allowance. The same applies to the second and third buses.

[0361] Finally, the specification data generating unit 201 arranges the generated or acquired data in accordance with a predetermined data structure to generate Figure 17 The rewriting specification data (B6) shown in FIG. That is, the specification data generating unit 201 generates the rewriting specification data using a data structure that can be interpreted by the vehicle side system 4. In addition, the information of each ECU can be recorded in the rewriting specification data in the order of the group from small to large and in the order of the ECUs in the group. For example, Figure 9 In the example, when group 1 is set to "ADS", group 2 is set to "BRK" first and "EPS" second, the ECU information column of the specification data is initially the ECU information of "ADS", followed by the ECU information of "BRK", and finally the ECU information of "EPS".

[0362] exist Figure 17 In the specification data shown, the "ECU ID" to "Transfer Size" fields of the ECU information are examples of target device-related information, including the type of the target ECU 19, corresponding to the hardware attribute information and software attribute information described above. Furthermore, the "Update Program Version" to "Writing Target" fields are examples of update data-related information. Furthermore, the "Rewrite Environment" field, which targets a group of ECUs or the entire vehicle, is an example of update processing information that specifies the update process within the vehicle.

[0363] exist Figure 19 In the following, the packet generation process in the packet generation unit 202 is described. As described above, here, the packet generation process for the vehicle with "vehicle model" = "aaa" is described. Figure 19 As shown in FIG. 1 , the center device 3 activates the package generation unit 202 of the package management unit 3A in response to the operator's instruction. The package generation unit 202 determines the "ECU SW ID" (C1) to be updated in the same manner as in step B1. The package generation unit 202 obtains each data corresponding to the "ECU SW ID" to be updated from the ECU reconfiguration data DB 204 and generates a reconfiguration data (C2). For example, Figure 10 In the process, the package generation unit 201 obtains the integrity verification data of the new program, the update data as differential data, the integrity verification data of the update data, the integrity verification data of the old program, the rollback data as differential data, and the integrity verification data of the rollback data, and generates recompilation data. Furthermore, the generated recompilation data is combined with the corresponding rewrite specification data described in steps B1 to B6 to generate a single distribution package file (C3). Next, integrity verification data for the generated package file is generated (C4) and registered with the package file in the package DB 206 (C5).

[0364] Figure 20The contents of the package file generated as described above are schematically shown. The schematic shows that the update data and integrity verification data corresponding to the "ADS," "BRK," and "EPS" targets for update are combined into a single recompiled data file, and then combined with the rewrite specification data to generate a single distribution package file. Here, the rollback data may be included in the recompiled data file only if the memory structure of the ECU 19 being updated is a single-layer structure. If the memory structure is a dual-layer or suspended structure, the rollback data, representing the old program, can be omitted because the operating layer is not rewritten.

[0365] As described above, according to this embodiment, the ECU reconfiguration data DB 204 of the center device 3 stores update program data for ECUs 19 targeted for application program update among the multiple ECUs 19 installed in the vehicle. The configuration information DB 208 stores vehicle-related information, including the "ECU ID" corresponding to each of the multiple ECUs 19 installed in the vehicle and the "ECU SW ID" of the application program stored in that ECU 19, along with the vehicle type. The ECU metadata DB 205 stores attributes of the target ECU 19 and update data-related information associated with the update data.

[0366] Furthermore, the specification data generation unit 201 generates specification data, based on information stored in the configuration information database 208 and the ECU metadata database 205, to be sent to the vehicle along with the update data to be written to the target ECU 19. The specification data includes the type and attributes of the target ECU 19, information related to the update data, and information indicating the rewriting environment related to the data update. Furthermore, the package generation unit 202 generates a distribution package containing the specification data and the rewritten data, and registers it in the package database 206. Furthermore, the package distribution unit 203 distributes the registered distribution package to the vehicle-side system 4. Thus, by receiving the specification data sent along with the update data, the vehicle-side system 4 can appropriately select the target ECU 19 based on the specification data and appropriately control the writing process using the update data.

[0367] The specification data generator 201 generates specification data for multiple ECUs 19 into one file, and the package generator 202 packages the specification data for multiple ECUs 19 together with the re-edited data into one file. Therefore, the vehicle-side system 4 can write update data to multiple ECUs 19 by receiving one distribution package.

[0368] Furthermore, the vehicle-related information, which serves as specification data, includes group information that groups some of the multiple ECUs 19. This allows the vehicle-side system 4 to select the target ECUs 19 according to the order specified by the group information and write the update data. For example, if there are multiple ECUs 19 targeted for a particular function improvement, group 1 can be assigned to the body system ECUs 19, group 2 to the driving system ECUs 19, and group 3 to the mobile system ECUs 19. This allows the program update in the vehicle-side system 4 to be performed in three steps. This reduces the user's waiting time each time compared to performing program updates on all ECUs collectively.

[0369] Furthermore, the rewrite environment information includes the vehicle's "vehicle status (IG on state)" and "battery load," as well as the "bus load table" associated with the ECU 19. Therefore, the vehicle-side system 4 can determine the timing of writing update data based on this information. Specifically, OEMs or service providers using the center device 3 can utilize flexible program updates by specifying vehicle-specific execution constraints as rewrite environment information.

[0370] Furthermore, the specification data generation unit 201 sequentially generates specification data based on information related to ECUs 19 with earlier updates in a pre-set update order, according to a predetermined data structure. This allows the vehicle-side system 4 to write update data according to the order in which the ECU IDs are arranged in the specification data. Specifically, ECUs 19 with mutually cooperating processes are grouped together, and the ECU order is determined based on the content of the cooperating processes. This allows the vehicle-side system 4 to complete program updates without problems even if the timing of the new program updates is not completely synchronized. For example, if the new program for ECU (ID1) includes processing for sending a specified message to ECU (ID2), and the new program for ECU (ID2) includes processing for causing a timeout error if it cannot receive the specified message from ECU (ID1), the ECU order can be determined so that ECU (ID1) is updated first, followed by ECU (ID2).

[0371] (Second embodiment)

[0372] like Figure 21 As shown, the second embodiment involves Figure 8The vehicle-side system 4 initially sends "Vehicle Configuration Information Synchronization" to the center device 3. When the vehicle-side IG switch 37 is turned on, the CGW 13 sends a "Synchronization Start Request" to the DCM 12. The DCM 12 accepts this "Synchronization Start Request" and responds with a "Configuration Information Collection Request" to the CGW 13. The CGW 13 then inquires about the program version of each ECU 19. Each ECU 19 responds with its "ECU SW ID" to the CGW 13. ECUs 19 with a dual-layer or suspended memory structure also respond to the CGW 13 with layer information indicating which of the multiple layers is operational and which is non-operational. Furthermore, each ECU 19 may also send calibration information for actuators under control, permission information for receiving program update services, and fault codes generated within the ECU 19 to the CGW 13.

[0373] Once the CGW 13 has received the "ECU SW IDs" from each ECU 19, it transmits them all along with the "VIN" to the DCM 12. At this point, the "Vehicle SW ID" and "Sys ID" managed by the CGW 13 may also be transmitted to the DCM 12. The DCM 12 receives these and generates a single hash value, serving as a digest value, for all "ECU SW IDs" using, for example, a hash function. As described above, when SHA-256 is used as the hash function, the data value obtained by serially concatenating all "ECU SW ID" values is divided into message blocks of 64 bytes each. The data value of the first message block is applied to the initial hash value to obtain a 32-byte hash value. The data values of subsequent message blocks are then applied to this hash value to obtain a final 32-byte hash value. Here, the DCM 12 may generate a single hash value not only for all "ECU SW IDs" but also for values including the "Vehicle SW ID," "Sys ID," surface information, and calibration information.

[0374] The DCM 12 transmits the digest value of the "ECU SW ID" obtained as described above, along with the "VIN," to the center unit 3. Alternatively, the DCM 12 may also transmit a fault code and permission information along with the digest value. Hereinafter, the digest value may be referred to as the "structural information digest," and the entire data value of the "ECU SW ID" underlying it may be referred to as "total structural information." "Total structural information" may also include the "Vehicle SW ID," "Sys ID," surface information, and calibration information.

[0375] As described below, the center device 3 compares digest values and updates the vehicle information DB 213. The center device 3, which synchronizes the configuration information, confirms whether a program update has occurred and, if so, notifies the vehicle-side system 4 of the update. The vehicle-side system 4 then downloads the distribution package, installs it in the target ECU 19, and activates the new program. Upon completion of these update processes, the CGW 13 sends a "synchronization start request" to the DCM 12. The same process as described above is then performed until the synchronization completion notification is received. Furthermore, the above-described process, triggered by the IG switch 37 being turned on, can also be performed after the program has been updated.

[0376] like Figure 22 As shown, upon receiving the "Structure Information Digest" (D1) from the vehicle-side system 4, the vehicle information management unit 3C of the center device 3 compares it with the "Structure Information Digest" of the corresponding vehicle registered in the vehicle information DB 213 at that time to determine whether the two match (D2). The "Structure Information Digest" may be a pre-calculated value registered in the vehicle information DB 213, or the digest value may be calculated using the structure information registered in the vehicle information DB 213 upon receipt from the vehicle-side system 4. If the two match ("Yes"), the center device 3C determines whether the vehicle information matches the standard combination registered in the structure information DB 208 (D6). Since the structure information DB 208 may be updated at a predetermined timing, the determination in step D6 is performed regardless of whether the two match ("Yes") or disagree ("No").

[0377] Here, for example Figure 23 As shown in the figure, in the above-mentioned determination of compatibility, the combination of the "Vehicle SW ID" and the "ECU SW ID" in the configuration information uploaded from the vehicle-side system 4 is checked to see if it is valid. In the list shown in the figure, the "ECU SW ID" of "ECU ID = ADS" corresponding to "Vehicle SW ID = 0001" registered in the configuration information DB 208 is "ads_001", the "ECU SW ID" of "ECU ID = BRK" is "brk_001", and the "ECU SW ID" of "ECU ID = EPS" is "eps_010".

[0378] On the other hand, the vehicle C with VIN=300 also has "Vehicle SW ID=0001", but the "ECU SW ID" of "ECU ID=ADS" is "ads_002", and the "ECU SW ID" of "ECU ID=BRK" is "brk_003". These two ECUs 19 have different configuration information from that registered in the configuration information DB 208. Therefore, the judgment in step D6 is "No", that is, it is not normal "NG", and the configuration information confirmation unit 210 sends a message to the vehicle-side system 4 and the device that manages the information of the vehicles produced by the OEM, that is, Figure 8 The management device 220 shown in FIG. 1 notifies the user of the abnormality (D12). For example, the abnormality notification is performed by SMS via the SMS transmission control unit 212. The SMS transmission control unit 212 is an example of a communication unit. Assuming that these two ECUs 19 are not ECUs subject to update based on the new program, the center device 3 also determines that the vehicle is non-compliant and does not proceed to step D7 and beyond.

[0379] On the other hand, vehicle A with VIN = 100 has "Vehicle SW ID = 0001," "ECU SW ID = ADS" is "ads_001," and "ECU SW ID = BRK" is "brk_001," all of which match the configuration information registered in configuration information DB 208. Therefore, the judgment in step D6 is "Yes," indicating that the vehicle is legitimate, or "OK," and the process proceeds to step D7. Configuration information confirmation unit 210 can also determine whether vehicle C is legitimate or not based on whether the combination of "ECU SW IDs" exists in configuration information DB 208. Furthermore, in addition to "Vehicle SW ID," "System ID" can also be added to the judgment criteria.

[0380] Next, the update confirmation unit 211 accesses the activity DB 217 via the activity management unit 3D to confirm whether there is an update based on the new program (D7). The update is determined by comparing the "Vehicle SW ID" uploaded from the vehicle-side system 4 with the "Vehicle SW ID before update" in the activity DB 217. Figure 23 As shown, since vehicle A with VIN = 100 is "Vehicle SW ID = 0001" before the update, it is determined that an update has occurred ("Yes"). In this case, the update confirmation unit 211 notifies the vehicle-side system 4 of vehicle A of the corresponding activity ID "Cpn_001" (D8). Activity information corresponds to update notification information, and the activity DB 217 is an example of an update notification information storage unit.

[0381] Furthermore, if the activity DB 217 has the "Sys ID" before and after the update, the "Sys ID" can also be used to confirm whether an update has occurred. Alternatively, instead of using the "Vehicle SW ID," the uploaded "ECU SW ID" list can be compared with the "pre-update ECU SW ID list" in the activity DB 217 to determine whether an update has occurred.

[0382] The vehicle-side system 4 uses the notified activity ID as a key to retrieve the activity file corresponding to the ID from the center device 3 (D9). The activity file contains text describing the activity content and constraints for executing program updates. Constraints refer to conditions for downloading and installing, such as the remaining battery life, the amount of free RAM required for downloading the distribution package, and the vehicle's current location. The vehicle-side system 4 parses the activity file and displays the activity content on the onboard display 7. Based on the activity content, the user refers to the message displayed on the onboard display 7 and decides whether to update the application program in the ECU 19. If the user's consent is accepted via the onboard display 7, the CGW 13 notifies the center device 3 of the consent to the update via the DCM 12. The center device 3 then sends the distribution package file and integrity verification data with the package ID corresponding to the activity ID to the vehicle-side system 4 (D10).

[0383] If there is no update in step D7 ("No"), the vehicle-side system 4 is notified of "no update" (D11). Figure 23 As shown, the vehicle A with VIN=200 has the updated “Vehicle SW ID=0002”, which does not match the “Vehicle SW ID before update” in the activity DB 217 , and therefore it is determined that there is no update.

[0384] On the other hand, if the comparison of the "structural information summary" in step D2 does not match ("No"), the center device 3 requests the vehicle-side system 4 to transmit "all structural information" (D3). This transmission corresponds to a "notification of a request to transmit overall data." In response, if the vehicle-side system 4 transmits "all structural information," the center device 3 receives it (D4). Furthermore, the single-vehicle information management unit 3C of the center device 3 updates the vehicle information registered in the single-vehicle information DB 213 (D4). The process then proceeds to step D6. The single-vehicle information DB 213 is an example of a storage unit for vehicle-side structural information.

[0385] Alternatively, the CGW 13 may transmit the “synchronization start request” at a timing when the IG switch 37 is turned off.

[0386] As described above, according to the second embodiment, upon receiving configuration information related to the configuration of each ECU 19 from multiple ECUs 19, the vehicle-side system 4 generates a hash value based on the data values of the multiple configuration information and transmits this hash value to the center device 3. The center device 3, which has a vehicle information database 213, compares the hash value transmitted from the vehicle-side system 4 with the hash value of the vehicle's configuration information stored in the vehicle information database 213. If the two do not match, the center device 3 requests the vehicle-side system 4 to transmit "all configuration information." The vehicle-side system 4 then accepts this transmission and transmits the "all configuration information" to the center device 3. Upon receiving the "all configuration information," the center device 3 updates the configuration information stored in the vehicle information database 213 based on the data value.

[0387] With this configuration, the vehicle-side system 4 initially transmits a hash value of the configuration information to the center device 3. Only when the comparison result of the hash values in the center device 3 indicates a mismatch is the full data value of the configuration information transmitted to the center device 3. This reduces the amount of data transmitted by the vehicle-side system 4, thereby reducing overall communication traffic even when the vehicle-side system 4 is installed in multiple vehicles. In particular, when the vehicle-side system 4 uploads configuration information at predetermined times, such as when the IG is turned on, there are periods of time when this communication is concentrated. Therefore, by using hash values to reduce the amount of transmitted data, the communication load can be reduced.

[0388] Furthermore, the CGW 13 receives configuration information from all ECUs 19 whose data is to be updated and generates a hash value based on all of this data. The DCM 12 transmits the hash value when the vehicle's ignition switch 37 is turned on or off. This allows the hash value to be transmitted to the center device 3 at the start or end of the vehicle's travel. Consequently, the center device 3 can appropriately synchronize the configuration information in the vehicle's single-vehicle information DB 213 with that of the vehicle.

[0389] Furthermore, upon receiving the "ECU SW ID" of each ECU 19 from multiple ECUs 19, the vehicle-side system 4 transmits a configuration information list combining the "Vehicle SW ID" with the ECU SW ID to the center device 3. The center device 3 compares the "ECU SW ID" list transmitted from the vehicle-side system 4 with the list of authorized "ECU SW IDs" for the corresponding vehicle stored in the configuration information DB 208. If the center device 3 determines that the combination of the transmitted lists is not authorized, it transmits an abnormality detection message to the vehicle-side system 4 and the management device 220.

[0390] With this configuration, the center device 3 can detect as abnormal a situation where the combination of vehicle configuration information is such that the multiple ECUs 19 cannot cooperate and thus hinder vehicle travel, and notify the vehicle-side system 4. The vehicle-side system 4 can then take measures such as prohibiting vehicle travel.

[0391] For vehicles whose vehicle configuration information combination indicates non-compliant, the center device 3 does not perform the update confirmation process (D7). This prevents program updates from being performed on non-compliant vehicles. Even if a non-compliant ECU 19 is not an ECU targeted for update based on the new program, the center device 3 does not perform the update confirmation process (D7). In the vehicle-side system 4, control is also generated for ECUs 19 that are not the target of the update during program updates. Therefore, in vehicles with non-compliant ECUs 19, there is a possibility that the program update may not be completed properly, and therefore the center device 3 does not perform the program update on such vehicles.

[0392] The center device 3 also includes an activity DB 217, which stores activity information used to notify vehicles of updates based on new programs. For vehicles deemed legitimate, the center device 3 checks whether activity information exists for the corresponding vehicle. If an update is available, the center device 3 transmits the activity information to the vehicle-side system 4. This allows users to be notified of the activity information and urges them to update their applications. Triggered by the upload of structural information from a vehicle, the center device 3 performs a series of processes, including synchronizing this structural information, determining whether it is legitimate, and confirming whether an update has occurred. This allows appropriate vehicles to be promptly notified of program updates.

[0393] Furthermore, the second embodiment may be implemented in the following modified forms.

[0394] Alternatively, the center device 3 may transmit a "synchronization start request" to the vehicle-side system 4. Upon receiving the "synchronization start request," the DCM 12 may transmit a "configuration information collection request" to the CGW 13. For example, when the configuration information DB 208 for "vehicle model = aaa" is updated, the center device 3 may transmit a "synchronization start request" to the vehicle of that model.

[0395] · In addition, in the ECU 19 that is the target of rewriting the update data, the hash value may be sent to the center device 3 when the rewriting is completed. That is, when the program update of all the ECUs 19 that are the target of rewriting is completed, the hash value may be sent to the center device 3. Figure 22 Flowchart of steps D1 to D12 shown.

[0396] When the comparison result of both hash values matches, the center device 3 requests the vehicle-side system 4 to transmit a combination list of configuration information of each ECU 16. Then, upon receiving the combination list, the processing of steps D6 to D12 may be performed.

[0397] When the comparison results of both hash values match, the center device 3 may also refer to the activity DB 217 to confirm the presence or absence of activity information of the corresponding vehicle.

[0398] You can also Figure 23A As shown, the hash value is transmitted from the vehicle-side system 4 to the central device 3 . Figure 23A This is a flowchart showing the processing performed by the CGW 13. For example, when the IG switch 37 is turned on, the CGW 13 collects configuration information from each ECU 19 (D21) and generates a hash value for the data value of the collected configuration information (D22). The generated hash value is then compared with the hash value stored in the flash memory 24d (the previously generated value) to determine whether there is a difference (D23). If there is a difference ("Yes"), the newly generated hash value is stored in the flash memory 24d (D24) and transmitted to the center device 3. If there is no difference between the hash values in step D23 ("No"), the process ends. Furthermore, the flash memory 24d pre-stores a hash value for the initial value of the configuration information. This allows the vehicle-side system 4 to reduce the number of times the configuration information is uploaded to the center device 3.

[0399] (Third embodiment)

[0400] The third embodiment relates to a function executed by the activity management unit 3D of the center device 3 in order to improve the update rate of the application in the vehicle-side system 4. Figure 24 As shown, for example, in vehicle-side system 4, the user pre-sets the HTTP polling interval to approximately three days via a configuration file. This allows vehicle-side system 4 to periodically check with center device 3 for application updates. Consequently, when update confirmation is performed after setting activity information for the VIN of a vehicle corresponding to activity DB 217, center device 3 notifies vehicle-side system 4 of the availability of an update. Specifically, as described in the second embodiment, upon the upload of configuration information from vehicle-side system 4 via HTTP, update confirmation by center device 3 is executed upon IG connection three days later.

[0401] If the update status is determined based on notifications from vehicles, the center device 3 does not need to transmit event information to all vehicles targeted by the event at the time the event information is set. However, if a user does not use a vehicle for an extended period, HTTP confirmation of the update status may not be performed during that period. Therefore, it is conceivable that a user may be unaware of the release of a new event, resulting in a vehicle not having its application updated.

[0402] Therefore, if Figure 25 As shown, the SMS transmission control unit 212 of the center device 3 periodically or at specified times refers to the vehicle information DB 213 to check the access logs of each vehicle (E1). Furthermore, it determines whether any vehicle has not accessed the center device 3, i.e., has not transmitted configuration information for confirming an application update, within a specified period (E2). The specified period is calculated from the date a new activity is set in the activity DB 217 and is, for example, set to approximately seven days. Specifically, the SMS transmission control unit 212 identifies vehicles whose "Vehicle SW ID" in the vehicle information DB 213 corresponds to the "Vehicle SW ID before update" in the activity DB 217 and identifies those vehicles that have not confirmed an update within seven days. Alternatively, the SMS transmission control unit 212 may identify all vehicles that have not confirmed an update within the specified period.

[0403] In addition, initial data is registered in the vehicle information DB 213 by the OEM when the vehicle is manufactured at the factory. Subsequently, an initial access log is entered, for example, upon notification from the OEM accompanying the sale of the vehicle. This access log essentially serves as a notification for validating subsequent program updates. Vehicles for which no access log has been entered are not subject to the determination in step E2.

[0404] If there is a vehicle that has not been updated within the specified period ("Yes"), the SMS transmission control unit 212 determines the characteristics of the vehicle based on the model and equipment information in the vehicle information DB 213 (E3). The characteristics here include whether the vehicle is an electric vehicle; an EV capable of receiving SMS (Short Message Service) or a conventional gasoline engine vehicle capable of receiving SMS; a delivery vehicle; or a vehicle with difficulty receiving SMS. For example, if the vehicle's DCM 12 does not have SMS reception capabilities or has not been configured for SMS reception, the vehicle is determined to be difficult to receive SMS.

[0405] If it is an EV, an SMS is sent to start the ECU 19 of the vehicle and start the configuration information transmission step (E5, see Figure 26). If DCM12 receives SMS and executes the instruction written in SMS, it will become IG power-on state, and the activated CGW13 will send the configuration information to the center device 3 via DCM12. Figure 22 The update is confirmed and the distribution package is downloaded, as shown in steps D1 to D12. In the case of an EV, the battery capacity is large, so it is believed that the program can be downloaded sufficiently while the vehicle is parked and powered on. Therefore, the ECU 19 is activated using SMS, automatically starting the update confirmation and download steps.

[0406] If the remaining amount of the battery of the EV vehicle is low, the vehicle-side system 4 refers to Figure 17 If the battery level is below a specified level, the center device 3 controls the vehicle-side system 4 so that the installation is not started. Alternatively, the center device 3 refers to the battery level recorded as a constraint in the activity file sent in step D9 and controls the vehicle-side system 4 so that the download of the distribution package is not started if the battery level is below a specified level.

[0407] In the transport vehicle, the SMS transmission control unit 212 transmits an SMS that can be displayed on the vehicle-mounted display 7 to the vehicle in a state where the SMS can be received every time the DCM 12 is intermittently activated (see E4, Figure 26 ). For example, CGW13 instructs the vehicle-mounted display 7 to display the text sentence recorded in the received SMS when the IG is turned on next time. In addition, when the information of the user's portable terminal 6 is registered in the bicycle information DB213, an SMS can also be sent to the portable terminal 6. For example, a text message such as "There is activity information. Please turn IG-ON." is displayed. The bicycle information DB213 is an example of a user information storage unit. On the other hand, no processing is performed on a vehicle that is in a state where it is difficult to receive SMS, and the user is dealt with by mailing, etc. (E6).

[0408] As described above, according to the third embodiment, the vehicle-side system 4 transmits configuration information for multiple ECUs 19 to the center device 3. The configuration information transmitted from each vehicle is stored in the vehicle-specific information DB 213, along with the date of transmission. Furthermore, the activity DB 217 stores, as activity information, an activity ID and a list of target VINs that can identify the target vehicles for data updates. Furthermore, the center device 3 references the vehicle-specific configuration DB 213 and, if configuration information has not been transmitted within a specified period from the date of transmission associated with the target vehicle, sends a message urging the vehicle-side system 4 of the target vehicle via SMS to urge a data update.

[0409] With this configuration, even if the user has not had the opportunity to ride the vehicle and therefore has not yet transmitted the configuration information to the center device 3, the center device 3 will transmit a message urging the vehicle-side system 4 of the target vehicle to update the data after a predetermined period has passed since the transmission date stored in the bicycle information DB 213. Therefore, the user can recognize that a data update is necessary by referring to this message.

[0410] The center device 3 then determines the target vehicles for the program update by referring to the vehicle information DB 213 and the activity DB 217. Specifically, the vehicle information DB 213 stores the date on which each vehicle's configuration information was transmitted, while the activity DB 217 stores a list of target VINs. Therefore, the center device 3 can determine the target vehicles for the program update based on the date on which each vehicle's configuration information was transmitted and the list of target VINs.

[0411] Furthermore, when the vehicle ignition switch 37 is turned on, the vehicle-side system 4 receives configuration information from each ECU 19 and transmits the configuration information to the center device 3. Therefore, the configuration information can be reliably transmitted to the center device 3 while the user is in the vehicle.

[0412] Furthermore, if the target vehicle is an electric vehicle, the center device 3 transmits a message containing a command to activate the target vehicle's ECU. Upon receiving this message, the vehicle-side system 4 activates the ECU 19 and executes data update-related processing. In other words, because the electric vehicle's battery has ample capacity, the ECU 19 can execute data update-related processing without waiting for user input. This allows for efficient data updates.

[0413] If the target vehicle is a transport vehicle, the center device 3 transmits at least text information that can be displayed on the target vehicle's onboard display 7 as a message. Therefore, the user of the transport vehicle can recognize that data update is required by referring to the text information displayed on the onboard display 7.

[0414] Furthermore, if the destination of the user's mobile terminal 6 is stored in the bicycle information DB 213, the message center device 3 transmits a text message that can be displayed on the mobile terminal 6. This allows the user to recognize the need for data update by referring to the text message displayed on the mobile terminal 6 even if the user does not have the opportunity to ride the bicycle.

[0415] Furthermore, if the user sends the event's delivery date and destination in advance to the center device 3 via the portable terminal 6, the center device 3 stores these delivery dates and destinations in the bicycle information DB 213. For example, the user may specify the day after the event's release as the delivery date, and the portable terminal 6 as the delivery destination, rather than the on-board display 7. Alternatively, the user may specify a specified time of day when they will not be riding as the delivery date, and the vehicle as the delivery destination, automatically performing the consent operation for the program update. Thus, regardless of whether or not the configuration information is sent, the center device 3 sends the event information to the destination on the specified delivery date. Therefore, if it is known that the user will not be riding a vehicle for a while, the user can be configured to receive the event information on the delivery date specified by the user.

[0416] Furthermore, the third embodiment may be implemented in a modified manner as follows.

[0417] A user information storage unit may be provided independently of the bicycle information DB 213 .

[0418] ・Event information can be sent using methods other than SMS.

[0419] Instead of storing the transmission date in the bicycle information DB 213 , the center device 3 may store, for example, a date on which no transmission from the vehicle was performed, and transmit a message urging data update when the date continues for seven days.

[0420] (Fourth embodiment)

[0421] The fourth embodiment shows a case where the user specifies a notification method for event information or a message. For example, it is assumed that it is predetermined that the user has not ridden a vehicle for about a month and has no chance to turn on the IG switch 37. Figure 27 As shown, the user sends settings for the notification destination and notification time when an event occurs to the center device 3 via the mobile terminal 6. For example, a setting is made to notify the mobile terminal 6 of the event information one month later. The bicycle information management unit 3C then stores the notification destination and notification time information in the bicycle information DB 213 and notifies the user according to the settings. For example, if two events (1 and 2) are set within the one-month period, the SMS transmission control unit 212 notifies the user's mobile terminal 6 of the information about events (1 and 2) one month later, prompting the user to update the program.

[0422] As described above, according to the fourth embodiment, when a user transmits a date and destination for event information to the center device 3 via the mobile terminal 6, the center device 3 stores the date and destination in the bicycle information DB 213. The center device 3 then transmits the event information to the destination on the stored date. This allows the center device 3 to stop transmitting unnecessary event information if it is determined that the user will not be riding a bicycle for a certain period of time.

[0423] (Fifth embodiment)

[0424] The fifth embodiment shows that when the center device 3 sends data for updating the program to the vehicle-side system 4, the vehicle-side system 4 provides a function for verifying the integrity of the data. Figure 28 and Figure 29 As shown, the supplier uses the package management unit 3A to create data to be registered in the ECU reconfiguration data DB 204. Specifically, as update data, the package management unit 3A creates new differential data (Y1) for rewriting the old program to the new program, creates a hash value (Y2) for the integrity verification data of the new program for the ECU 19, and creates a hash value for the new differential data. If the ECU has a single-side memory, the supplier can also create old differential data for rewriting the new program to the old program as rollback data, create a hash value for the old program for the ECU 19, and create a hash value for the old differential data.

[0425] The package management unit 3A encrypts each hash value using a predetermined key, i.e., a key value, to generate an authenticator (Y3). The package management unit 3A then transmits the update data and integrity verification data along with each authenticator to the ECU reconfiguration data DB 204 (Y4). The package management unit 3A generates a package as described above, generates integrity verification data for the package, and transmits it to the vehicle-side system 4 (Y5).

[0426] The master device (OTA host) 11 calculates the integrity verification data for the packet and compares the calculated value with the integrity verification data of the received packet to verify the integrity of the packet (Y6). If the integrity verification of the packet is successful, the master device 11 sends the ECU update data and the integrity verification data to the target ECU 19 (Y7).

[0427] The target ECU 19 calculates the integrity verification data for the updated data and compares the calculated value with the received integrity verification data for the updated data to verify the integrity of the updated data (Y8). If the integrity verification of the updated data succeeds, the target ECU 19 restores the updated data, i.e., the differential data, and writes it to the flash memory 28d (Y9). If the writing is complete, the target ECU 19 calculates the integrity verification data for the data written to the flash memory 28d and compares the calculated value with the received integrity verification data for the new program to verify the integrity of the flash memory 28d (Y10). The target ECU 19 transmits the verification result to the host device 11 (Y11), which transmits the received verification result to the center device 3 as an installation result notification (Y12).

[0428] For example, Figure 10 As shown, the package management unit 3A generates the following integrity verification data for the latest "ECU SW ID". If the memory structure of the ECU is a dual-side memory or a suspended memory, the following (3) (4) can be omitted.

[0429] (1) Generate a hash value, which is integrity verification data for a new program for the ECU. The functional unit that performs this process is an example of a first verification value generation unit (step A1).

[0430] (2) Generate update data (differential data for updating the old ECU program to the new program) and a hash value (integrity verification data for the update data). The functional unit that performs this process is an example of a second verification value generation unit (step A4).

[0431] (3) Generate a hash value, which is integrity verification data for the old program of the ECU. The functional portion that performs this process is an example of a fourth verification value generation unit (step A5).

[0432] (4) Generate update data (differential data for updating the old ECU program based on the new ECU program) and a hash value (integrity verification data for the update data). The functional unit that performs this process is an example of a fifth verification value generation unit (step A7).

[0433] Furthermore, "program" also includes constant data used within the program. For example, if "ECU SW ID = ads_002," a hash value x1 is generated for the update data "Adsfile001-002." As mentioned above, the hash function used is, for example, SHA-256. The hash value corresponds to the verification value. The package management unit 3A may also be configured to generate an authenticator by encrypting the hash value using a predetermined key, i.e., a key value, and generate integrity verification data with the authenticator.

[0434] Next, the vendor encrypts the integrity verification data using a predetermined key, or key value, to generate an authenticator. This generates integrity verification data with the authenticator, associates the update data with the integrity verification data with the authenticator, and provides it to the OEM. Specifically, the package management unit 3A registers each program and its corresponding integrity verification data with the authenticator in the ECU reconfiguration data DB 204, thereby providing it to the OEM. Based on the OEM's instructions, the package management unit 3A uses the ECU reconfiguration data DB 204 and other means to generate the rewrite specification data as described above, creates a distribution package, and registers it in the package DB 206. When a download request for update data is received from the vehicle-side system 4, the center device 3 distributes the distribution package containing the update data and the integrity verification data with the authenticator to the vehicle-side system 4 in response to the download request.

[0435] In addition, the "integrity verification data" in the technical solution includes both data consisting of only hash values and data containing an authenticator encrypted using a key.

[0436] When the main device 11 of the vehicle-side system 4 receives the distribution package, it verifies the validity of the distribution package using the integrity verification data (third verification value) assigned to the distribution package. Specifically, the integrity verification data calculated using the distribution package is compared with the received integrity verification data. If they are consistent, it is determined to be normal. If the verification result confirms that it is normal, the main device 11 decompresses the distribution package into data for each ECU (refer to Figure 6 ) Furthermore, the host device 11 transmits the update data and the integrity verification data with the authenticator to the ECU 19 of the write destination.

[0437] The ECU 19 uses the integrity verification data (second verification value) with the authenticator to verify the validity of the update data. Specifically, the integrity verification data calculated using the received update data is compared with the received integrity verification data. If they match, the update data is deemed normal. If the verification confirms normality, the CPU 28a of the ECU 19 writes the data to the flash memory 28d. Once the write process is complete, the ECU 19 reads the data written to the flash memory 28d using the integrity verification data (first verification value) with the authenticator to verify its validity. Specifically, the integrity verification data calculated using the read data is compared with the received integrity verification data. If they match, the update data is deemed normal. This integrity verification data is also used when the ECU 19 is started up and is therefore pre-stored in a designated area of the flash memory 28d. Once these processes are complete, the ECU 19 sends a write response containing the verification results to the host device 11. The host device 11 notifies the center device 3 of the installation results. In the figure, "target ECU" is synonymous with "subject ECU," and "OTA host" is synonymous with "DCM." The CPU 28a is an example of a write processing unit.

[0438] Here, in the event that the program update is canceled during the installation, ECU19 performs a rollback process. ECU19 writes the update data and uses the integrity verification data (fifth verification value) with the authenticator to verify the appropriateness of the differential data for rollback. Specifically, the integrity verification data calculated using the differential data for rollback is compared with the received integrity verification data, and if they are consistent, it is judged to be normal. If the verification result confirms that it is normal, ECU19 starts writing using the differential data for rollback after completing the writing of the update data. Moreover, after completing the writing, ECU19 uses the integrity verification data (fourth verification value) with the authenticator to read the data written to the flash memory 28d and verify its appropriateness.

[0439] Alternatively, a configuration may be employed in which the integrity verification of received differential data (update data, rollback differential data) is performed not by the ECU 19 but by the host device 11 .

[0440] like Figure 30As shown, then, if the IG switch 37 of the above-mentioned vehicle is turned on, ECU19 uses this as an opportunity to perform data verification at the time of startup. ECU19 uses integrity verification data (first verification value or fourth verification value) with an authenticator to verify the integrity of the program being started, etc. First, in the flash memory 28d, a hash function is applied to the data value of the evaluation object area where the updated program and constant data are written to obtain a hash value. Next, the integrity verification data with an authenticator is decoded, and the hash value (expected value) contained in the decoding result is compared with the obtained hash value (calculated value) to determine whether the program written to the flash memory 28d has been tampered with. If the hash values of both parties are consistent and are "OK", ECU19 performs the startup process as usual. The same process is performed on each ECU19, and if the results of all the evaluation object ECU19 are "OK", the process ends.

[0441] On the other hand, if the verification result for any ECU 19 is abnormal, i.e., "NG," the ECU 19 saves the processing log and notifies the host device 11 of the error. The host device 11 similarly saves the log and notifies the center device 3 of the error. The center device 3 similarly saves the log and notifies the management device 220, such as an OEM, of the error. Notification to the management device 220 is performed, for example, by the SMS transmission control unit 212 using SMS or by sending an email via the Internet.

[0442] In the above-mentioned embodiment, the vehicle-side system 4 adopts a structure for verifying the integrity. Figure 31 In the following, the case where the central device 3 performs integrity verification (comparison with expected values) is described. Figure 31 When the ECU 19 transmits the updated application version information to the host device 11, for example, at a timing such as when the IG is turned on, it generates and transmits integrity verification data with an authenticator along with the version information (X1). The ECU 19 calculates the integrity verification data for the data in the flash memory 28d and transmits the calculated value to the host device 11. The host device 11 transmits the integrity verification data with an authenticator as structural information to the center device 3 (X2).

[0443] The center device 3 accesses the ECU reconfiguration data DB 204 and obtains the integrity verification data with the authenticator corresponding to the "ECU SW ID" of the target ECU 19 (X3, X4). This data is then compared with the integrity verification data uploaded from the vehicle (X5). Specifically, the center device 3 obtains the integrity verification data of the new program corresponding to the "ECU SW ID" from the ECU reconfiguration data DB and compares the data. If the comparison result is inconsistent ("NG" or "FAIL"), the center device 3 notifies the OEM's management device 220 of the abnormality (X7). This processing section functions as an abnormality reporting unit.

[0444] The central device 3 transmits the comparison result to the master device 11 (X8), and the master device 11 transmits the received comparison result to the target ECU 19 (X9). If the comparison result is OK, the target ECU 19 operates the application program as usual. If the comparison result is NG, the application program is not operated. Furthermore, in this embodiment, the package management unit 3A can omit the generation of integrity verification data for the new program (step A1) and the generation of integrity verification data for the old ECU program (step A5).

[0445] In the above description, the ECU 19 verifies the integrity of the update data after writing the update data when the IG switch 37 of the vehicle is turned on. Alternatively, the integrity may be verified after writing the update data.

[0446] In the above-mentioned embodiment, only the integrity verification data with the authenticator is added to the update data, but this can also be implemented as follows.

[0447] Acquire the new program and corresponding update data from the ECU reconfiguration data DB 204 (data acquisition step; step A1 ).

[0448] The first verification value generation unit generates a first hash value for the new program (first verification value generation step; step A2).

[0449] The second verification value generation unit generates a second hash value for the update data (second verification value generation step; step A4). The package generation unit 202 includes the update data, specification data, and the first and second hash values in the distribution package (distribution package generation step). The update data corresponds to the new differential data.

[0450] The third verification value generation unit generates a third hash value for the distribution package (third verification value generation step; step C4 ).

[0451] The packet distribution unit 203 transmits the distribution packet and the third hash value to the vehicle-side system 4 (transmission step).

[0452] Furthermore, the authenticator may be assigned only to the distribution package and the third hash value, or may be assigned at each stage of generating each hash value. The packet distribution unit 203 corresponds to a transmission unit.

[0453] In this case, in the vehicle-side system 4,

[0454] The reception processing unit, namely the DCM 12, receives the distribution package and the third hash value.

[0455] The third verification processing unit compares the hash value generated based on the distribution package data with the received third hash value to verify the integrity of the distribution package data.

[0456] The second verification processing unit compares the hash value generated based on the update data with the received second hash value to verify the integrity of the update data.

[0457] The CPU 28a, which is an example of a write processing unit, writes the update data into the flash memory 28d.

[0458] The first verification processing unit generates a hash value for the data value in the flash memory 28d that becomes a new program by writing the update data, and compares it with the received first hash value to verify the integrity of the new program.

[0459] If the updated data verification result is NG, writing to the flash memory 28d is aborted. Furthermore, if the verification result of the new program written to the flash memory 28d is NG, the new program is invalidated and rolled back as needed. Alternatively, the first through third verification processing units may be implemented by the CPU 28a. Furthermore, if any of the first through third verification processing units returns NG, the DCM 12, acting as the transmission processing unit, notifies the center device 3 of the abnormality.

[0460] In addition, based on the above, Figure 10 As shown, when there is rollback data for returning to the state of the old program before writing the update data, it can also be implemented as follows.

[0461] The fourth verification value generation unit generates a fourth hash value for the old program (fourth verification value generation step; step A5 ).

[0462] The fifth verification value generation unit generates a fifth hash value for rollback data for returning the new program to the old program (fifth verification value generation step; step A7). The rollback data represents differential data for rollback and corresponds to the old differential data.

[0463] The package generation unit 202 causes the distribution package to include the update data, rollback differential data, rewrite specification data, and the first, second, third, and fourth hash values (distribution package generation step).

[0464] In this case, if the user instructs to stop rewriting while the updated data is being rewritten in the flash memory 28d in the vehicle-side system 4, for example, the rewriting is canceled and the old program is restored, i.e., rolled back. This is only the case when the memory structure of the ECU 19 is a single-side memory.

[0465] The second verification processing unit calculates a hash value for the rollback data included in the distribution package, and compares the calculated hash value with the fifth hash value to verify the integrity of the rollback data.

[0466] The CPU 28a writes to the flash memory 28d using the rollback data.

[0467] The first verification processing unit calculates a hash value for the old program restored by writing to the flash memory 28 d , and compares the calculated hash value with the fourth hash value to verify the integrity of the old program.

[0468] As described above, according to the fifth embodiment, the ECU reconfiguration data DB 204 stores the new program for the target ECU 19 (to be rewritten), the old program, and the update data (new differential data used to update the old program to the new program). The first verification value generation unit generates a first hash value using the new program, and the second verification value generation unit generates a second hash value using the update data. The package generation unit 202 generates a package containing the update data, first and second verification values, and specification data for multiple target ECUs 19. The third verification value generation unit generates a third hash value using a distribution package, and the package distribution unit 203 transmits the distribution package along with the third hash value to the vehicle-side system 4.

[0469] Upon receiving the distribution package and the third hash value, the vehicle-side system 4 calculates a hash value for the distribution package and compares it with the third hash value to verify the integrity of the distribution package. The second verification processing unit calculates a hash value for the update data corresponding to the target ECU 19 included in the distribution package and compares it with the second hash value included in the distribution package to verify the integrity of the update data.

[0470] CPU 28a writes the updated data to flash memory 28d. The first verification processing unit calculates a hash value for the updated new program data in flash memory 28d and compares it with the first hash value to verify the integrity of the new program data. This allows the integrity of each data value to be verified at multiple stages using each hash value. Furthermore, the integrity of the new program can be verified three times, preventing the vehicle-side system 4 from writing an incomplete new program and operating with an improper new program.

[0471] Furthermore, when rollback data exists in the ECU reconfiguration data DB 204, the fourth verification value generation unit generates a fourth hash value for the old program, and the fifth verification value generation unit generates a fifth hash value for the rollback data. The package generation unit 202 creates a distribution package containing the update data, the first and second hash values, the rollback data, and the fourth and fifth hash values.

[0472] Furthermore, when a rollback is performed in the vehicle-side system 4, the second verification processing unit calculates a hash value for the rollback data included in the distribution package and compares it with the fifth hash value to verify the integrity of the rollback data. CPU 28a uses the rollback data to write to the flash memory 28d. The first verification processing unit calculates a hash value for the old program restored by writing to the flash memory 28d and compares it with the fourth hash value to verify the integrity of the old program. In this way, the integrity of the old program that is written back can also be verified. In the above description, the first to fifth verification value generation units are functional modules within the package management unit 3A of the central device 3. The first, second, fourth, and fifth verification processing units are functional modules within the target ECU 19 of the vehicle-side system 4. In addition, the third verification processing unit is a functional module within the main device 11 (OTA host 11) of the vehicle-side system 4.

[0473] (Variation 1 of the First Embodiment)

[0474] You can also Figure 32 and Figure 33 As shown, one activity "cpn_001" is associated with multiple packages "pkg_001_1" and "pkg_001_2." Alternatively, multiple packages can be grouped together. In the above embodiment, a structure was adopted in which multiple groups were contained within one package. In this variation, one package is generated for each group, and multiple packages are distributed to one activity. For example, package "pkg_001_1" contains the ECUs "ADS" and "BRK" belonging to group 1, while package "pkg_001_2" contains the ECU "EPS" belonging to group 2.

[0475] In this case, if Figure 34 and Figure 35 As shown in , specification data and distribution packages are generated independently for each group. Figure 34 In the example, as the specification data of group 1, the specification data generating unit 201 generates the first specification data including the ECU information of "ADS" and "BRK". As the specification data of group 2, the specification data generating unit 201 generates the second specification data including the ECU information of "EPS". Figure 35In the example, the package generation unit 202 generates recompiled data by combining the updated data of "ADS" and "BRK" belonging to group 1 according to the ECU order, and combines this data with the first specification data to generate the package file "pkg001_1.dat." The package generation unit 202 generates recompiled data using the updated data of "EPS" belonging to group 2, and combines this data with the second specification data to generate the package file "pkg001_2.dat."

[0476] (Second modification of the first embodiment)

[0477] Figure 36 The following shows the processing contents when the functions of the specification data generating unit 201 and the package generating unit 202 are integrated to form a single package generating tool 221. Hereinafter, each process will be described again.

[0478] In the specification data generation process, the value input by the operator as specification data information is output in a data structure with a predetermined number of bits and arrangement order, thereby generating specification data. Figure 17 The values exemplified in ECU (ID1), ECU (ID2), and ECU (ID3) may include information on a vehicle unit or a system (group) unit. Vehicle unit information, for example, refers to Figure 17 The rewriting environment information shown is the system unit information, for example Figure 17 The group information and ECU sequence information shown are also included. Vehicle- and system-level input information can also be stored in separate files. The specification data generation process can also include a function that automatically calculates certain values, such as the file size of the updated data, and reflects them in the specification data.

[0479] In the package generation process, the values and files input as the generated specification data, update data for each ECU, and integrity verification data for each ECU are output in a data structure with a predetermined number of bits and arrangement order, and a distribution package file is generated. The update data and integrity verification data for each ECU are arranged in order from small to large for the group and from small to large for the ECU. Here, in addition to the update data (new differential data), rollback data (old differential data) can also be added to the input. As integrity verification data, "integrity verification data of the ECU program (new)" and "integrity verification data of the update data" are input. When rollback data is also added, "integrity verification data of the ECU old program" and "integrity verification data of the old differential data" are also added to the input.

[0480] In the integrity verification data generation process, such as Figure 19 As described in step C4, integrity verification data is generated for the generated package file.

[0481] The generated package file and the integrity verification data generated for the package file are registered in the package DB 206 by the operator.

[0482] (Other Embodiments)

[0483] The functions performed by the central device 3 can be realized by hardware or software. In addition, they can also be realized by the cooperation of hardware and software.

[0484] The data that is rewritten is not limited to application programs, but can also include map data, control parameters, and other data.

[0485] The content of the structural information is not limited to the exemplified content, and may be appropriately selected according to individual design.

[0486] The contents of the specification data are not limited to those exemplified.

[0487] The campaign information and distribution specification data may be included in the distribution package and sent to the vehicle side, or may be sent to the vehicle side independently of the distribution package.

[0488] In the fifth embodiment, the distribution package and the third verification value may be stored in advance in the package storage unit, and the packet transmission unit 213 may transmit the distribution package and the third verification value associated with the request to the in-vehicle system 4 in response to a request from the in-vehicle system 4 .

[0489] The following describes a sixth embodiment, focusing on the operation of a vehicle program rewriting system 1, with reference to the accompanying drawings. The vehicle program rewriting system (equivalent to a vehicle electronic control system) is capable of rewriting vehicle control, diagnostic, and other applications installed in an electronic control unit (hereinafter referred to as an ECU) via OTA (Over the Air). While this embodiment describes rewriting applications via wired or wireless communication, it is also applicable to rewriting data used in various applications, such as map data used in map applications and control parameters used in ECUs, via wired or wireless communication.

[0490] Rewriting an application using a wired connection includes not only acquiring the application from outside the vehicle via a wired connection and rewriting it, but also acquiring various data used when executing the application from outside the vehicle via a wired connection and rewriting it. Rewriting an application using a wireless connection includes not only acquiring the application from outside the vehicle via a wireless connection and rewriting it, but also acquiring various data used when executing the application from outside the vehicle via a wireless connection and rewriting it.

[0491] like Figure 37As shown, a vehicle program rewriting system 1 includes a central device 3 on the communication network 2 side, a vehicle-side system 4 on the vehicle side, and a display terminal 5. The communication network 2 is composed of, for example, a mobile communication network such as a 4G line, the Internet, or WiFi (Wireless Fidelity) (registered trademark).

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

[0493] If the user is outside the vehicle and within the communication range of the mobile communication network, they can confirm various screens related to application rewriting on the portable terminal 6 while performing operations and inputting, and can perform procedures related to application rewriting. Inside the vehicle, the user can confirm various screens related to application rewriting on the vehicle-mounted display 7 while performing operations and inputting, and can perform procedures related to application rewriting. In other words, the user can use the portable terminal 6 and the vehicle-mounted display 7 separately outside and inside the vehicle to perform procedures related to application rewriting.

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

[0495] The file server 8 manages files for applications distributed from the center device 3 to the vehicle-side system 4. It manages update data (hereinafter also referred to as recompilation data or write data) provided by suppliers, such as those that provide applications distributed from the center device 3 to the vehicle-side system 4; distribution specification data provided by OEMs (Original Equipment Manufacturers); and vehicle status acquired from the vehicle-side system 4. The file server 8 is capable of data communication with the vehicle-side system 4 via the communication network 2. Upon receiving a download request for a distribution package, the file server 8 packages the recompilation data and distribution specification data into a single file and transmits it to the vehicle-side system 4.

[0496] The network server 9 manages network information. In response to requests from a web browser on a portable terminal 6 or the like, the network server 9 transmits the network data it manages. The management server 10 manages the personal information of users registered with the application rewriting service, the application rewriting history for each vehicle, and other information.

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

[0498] The CGW 13 has a data relay function. Upon receiving write data from the DCM 12, it instructs the target ECU (the target ECU) to write the received write data and distributes the write data to the target ECU. Furthermore, once the write data is completed in the target ECU, and the application is rewritten, the CGW 13 instructs the target ECU to activate the rewritten application.

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

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

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

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

[0503] 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 a navigation ECU that controls the navigation system and an ETC ECU that controls the Electronic Toll Collection System (ETC (registered trademark)). Buses 15 to 17 may also be buses for systems other than the bus of the vehicle body system network, the bus of the driving system network, and the bus of the multimedia system network. The number of buses and the number of ECUs 19 are not limited to the illustrated configuration.

[0504] The power management ECU 20 is an ECU that manages power supplied to the DCM 12 , the CGW 13 , the various ECUs 19 , and the like.

[0505] The sixth bus 21 is connected to the CGW 13 as a bus on the vehicle's exterior. A DLC (Data Link Coupler) connector 22 is connected to the sixth bus 21, and this DLC (Data Link Coupler) connector 22 is detachably connected to a tool 23 (equivalent to a service tool). The in-vehicle buses 14-18 and the out-vehicle bus 21 are composed of, for example, a CAN (Controller Area Network, registered trademark) bus. The CGW 13 communicates data between the DCM 12, various ECUs 19, and the tool 23 based on the CAN data communication standard and the diagnostic communication standard (UDS (Unified Diagnosis Services): ISO 14229). Alternatively, the DCM 12 and CGW 13 can be connected via Ethernet, and the DLC connector 22 and CGW 13 can also be connected via Ethernet.

[0506] Upon receiving write data from the CGW 13, the target ECU 19 writes the received write data to a flash memory (equivalent to nonvolatile memory), thereby rewriting the application program. In the above configuration, the CGW 13 functions as a reprogramming master. Upon receiving a write data acquisition request from the target ECU 19, the CGW 13 distributes the write data to the target ECU 19. The target ECU 19 functions as a reprogramming slave. Upon receiving write data from the CGW 13, the CGW 13 writes the received write data to the flash memory, thereby rewriting the application program.

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

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

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

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

[0511] like Figure 38 As shown, the CGW 13 includes a microcomputer (hereinafter referred to as microcomputer) 24, a data transmission circuit 25, a power supply circuit 26, and a power detection circuit 27 as electrical functional modules. The microcomputer 24 includes a CPU (Central Processing Unit) 24a, a ROM (Read Only Memory) 24b, a RAM (Random Access Memory) 24c, and a flash memory 24d. The flash memory 24d contains a secure area where information cannot be read from outside the CGW 13. The microcomputer 24 executes various control programs stored on a non-migratable physical storage medium to perform various processes and control the operation of the CGW 13.

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

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

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

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

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

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

[0518] The vehicle-mounted display 7 has Figure 40 The power management ECU 20 has the same structure as the ECU 19 shown in FIG. Figure 40 The power management ECU 20 has the same structure as the ECU 19 shown in FIG. The power management ECU 20 is connected to a power control circuit 43 described later so as to be capable of data communication.

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

[0520] The IG power supply line 39 is connected to the positive terminal of the vehicle battery 40 via the IG switch 42. When the user performs an IG operation, the IG switch 42 switches from off to on, applying the output voltage of the vehicle battery 40 to the IG power supply line 39. For example, in a vehicle with a key-operated key slot, this involves inserting the key into the slot and turning it from the "off" position to the "on" position; in a vehicle with a push-button start, this involves pressing the start button twice. The negative terminal of the vehicle battery 40 is grounded.

[0521] When both the ACC switch 41 and the IG switch 42 are off, only +B power is supplied to the vehicle-side system 4. The state in which only +B power is supplied to the vehicle-side system 4 is referred to as the +B power state. When the ACC switch 41 is on and the IG switch 42 is off, both ACC power and +B power are supplied to the vehicle-side system 4. The state in which both ACC power and +B power are supplied to the vehicle-side system 4 is referred to as the ACC power state. When both the ACC switch 41 and the IG switch 42 are on, +B power, ACC power, and IG power are supplied to the vehicle-side system 4. The state in which +B power, ACC power, and IG power are supplied to the vehicle-side system 4 is referred to as the IG power state. In addition to the power supply states described above, power supply states in which a power supply suitable for wireless program updates is applied are also conceivable.

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

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

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

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

[0526] The power control circuit 43 is connected in parallel with the ACC switch 41 and the IG switch 42. The CGW 13 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 CGW 13 sends a power start request to the power management ECU 20 as a power control request, 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 when the ACC switch 41 and the IG switch 42 are turned off, ACC power and IG power are supplied to the vehicle-side system 4. Furthermore, the CGW 13 sends a power stop request to the power management ECU 20 as a power control request, thereby disconnecting the ACC power line 38, the IG power line 39 from the positive terminal of the vehicle battery 40 within the power control circuit 43.

[0527] The DCM12, CGW13, ECU19, and power management ECU20 each include a power self-holding circuit, which has a power self-holding function for maintaining power from the vehicle battery 40. Specifically, if the vehicle power source switches from ACC power or IG power to +B power while the DCM12, CGW13, ECU19, or power management ECU20 is in the startup state, the DCM12, CGW13, ECU19, or power management ECU20 does not immediately transition from the startup state to the shutdown state or sleep state after the switch. Instead, the DCM12, CGW13, ECU19, or power management ECU20 maintains the driving power source by maintaining the startup state for a predetermined period (e.g., several minutes) after the vehicle power source switches from ACC power or IG power to +B power. For example, in the case of the engine control system ECU19, the power self-holding function activates after the vehicle power source switches from ACC power or IG power to +B power, allowing various engine control-related data acquired during vehicle driving to be stored as a log.

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

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

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

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

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

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

[0534] The connection bus indicates the bus to which ECU19 is connected. The connection power supply indicates the power supply line to which ECU19 is connected. The security access key information indicates the key information used for authentication by CGW13 to access the rewrite object ECU19, including a random value or unique information, a key mode, and a decoding operation mode. The memory type indicates whether the memory mounted on the rewrite object ECU19 is a 1-side independent memory, a 1-side suspended memory (also called an analog 2-side memory), or a 2-side memory. The rewrite method indicates whether it is a rewrite based on power self-retention or a rewrite based on power control. The power self-retention time indicates the time during which the power self-retention continues when the rewrite method is a rewrite based on power self-retention. The rewrite surface information indicates which surface is the operating surface and which surface is the non-operating surface. The operating surface is also called the startup surface, and the non-operating surface is also called the rewrite surface.

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

[0536] Upon receiving the DCM rewrite specification data, the DCM 12 analyzes the data. The DCM 12 then retrieves write data from the address where the update program for the target ECU 19 is stored and controls rewrite-related operations such as transferring the retrieved write data to the CGW 13.

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

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

[0539] Upon receiving distribution specification data from the CGW 13, the display terminal 5 analyzes the data and controls the display of various screens based on the analysis results. For example, the display terminal 5 overlays the display text obtained from the distribution specification data on a pre-stored display frame or executes a display control program obtained from the distribution specification data. Furthermore, the distribution specification data may include not only this information but also information uniquely defined by the system.

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

[0541] like Figure 46 As shown, if DCM12 downloads a distribution package from the file server 8, it uses the package authenticator stored in the downloaded distribution package to verify the integrity of the encrypted recoded data. If the verification result is positive, DCM12 decodes the encrypted recoded data. If DCM12 decodes the encrypted recoded data, it decrypts (hereinafter also referred to as depacketizing) the decoded recoded data, splits it into encrypted differential data and authenticator, rewritten specification data for DCM, and rewritten specification data for CGW, and extracts them. Figure 46In the figure, an example is given of the case where the encrypted differential data and authenticator of ECU (ID1), the encrypted differential data and authenticator of ECU (ID2), the encrypted differential data and authenticator of ECU (ID3), the rewrite specification data for DCM, and the rewrite specification data for CGW are divided and extracted.

[0542] Next, refer to Figures 47 to 58 The flash memory 33d of the ECU 19 will be described. Based on the memory structure, the flash memory 33d of the ECU 19 is categorized into single-sided independent memory (with a flash memory surface on one side), single-sided suspended memory (with flash memory surfaces on two simulated sides), and dual-sided memory (with flash memory surfaces on two actual sides). Hereinafter, an ECU 19 equipped with a single-sided independent memory will be referred to as a single-sided independent memory ECU, an ECU 19 equipped with a single-sided suspended memory will be referred to as a single-sided suspended memory ECU, and an ECU 19 equipped with dual-sided memories will be referred to as a dual-sided memory ECU.

[0543] Single-sided independent memory has a flash memory surface on one side, so there are no concepts of an active and non-active surface, and the application cannot be rewritten while it is running. On the other hand, single-sided suspend memory and dual-sided memory have flash memory surfaces on both sides, so there are concepts of an active and non-active surface, and the application on the non-active surface can be rewritten while the application on the active side is running. Dual-sided memory has flash memory surfaces on two completely separate sides, so the application can be rewritten at any time, such as when the vehicle is moving. Single-sided suspend memory is a pseudo-two-sided structure that divides one side into independent memories. Therefore, there are restrictions on the timing of normal reading and writing. The application cannot be rewritten while the vehicle is moving, but it can be rewritten when the IG power is disconnected.

[0544] In addition, there are two types of memory: single-sided independent memory, single-sided suspended memory, and dual-sided memory, each of which has reprogrammed firmware embedded in it (hereinafter referred to as embedded type) and reprogrammed firmware download type (hereinafter referred to as download type) in which reprogrammed firmware is downloaded from the outside. Reprogrammed firmware is firmware used to rewrite application programs.

[0545] The following describes the structure of each flash memory in sequence.

[0546] (A) 1-side independent memory

[0547] (A-1) Embedded 1-sided independent memory

[0548] Reference Figure 47 and Figure 48This section describes the embedded, single-sided independent memory. It includes a differential engine operating area, an application area, and a boot program area. The application area contains version information, parameter data, applications, firmware, and a normal vector table. The boot program, progress status point 2, progress status point 1, boot determination information, wireless reprogramming firmware, wired reprogramming firmware, a boot determination program, and a boot vector table are located in the boot area.

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

[0550] When executing the rewriting operation of the application program rewriting process, the microcomputer 33 performs wireless or wired reprogramming of the firmware without executing the application program. Figure 48 Indicates the action of rewriting the application using differential data as an update program. Figure 48 As shown, the microcomputer 33 temporarily stores the application program as old data in the difference engine operating area. The microcomputer 33 reads the old data temporarily stored in the difference engine operating area and, using the difference engine included in the embedded recompiled firmware, restores new data based on the read-out old data and the difference data stored in RAM 33c. Once the microcomputer 33 generates new data based on the old data and the difference data, it writes the new data to a specified address in the memory, thereby rewriting the application program.

[0551] (A-2) Downloadable 1-sided independent storage

[0552] Reference Figure 49 and Figure 50 The download type is described as a single independent memory. The download type differs from the above embedded type in that wireless reprogramming firmware and wired reprogramming firmware are downloaded from the outside, and after rewriting the application, the wireless reprogramming firmware and wired reprogramming firmware are deleted. When using wireless update application, for example, Figure 42 The reprogramming data shown includes wireless reprogramming firmware executed by each ECU 19. The ECU 19 receives the wireless reprogramming firmware for its own ECU from the CGW 13 and stores the received wireless reprogramming firmware for its own ECU in the RAM.

[0553] like Figure 49 As shown, when executing normal operations such as vehicle control processing and diagnostic processing, the microcomputer 33 executes the startup determination program in the same manner as the embedded type, searches for the start address by referring to the startup vector table and the normal vector table, and executes the specified address of the application program.

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

[0555] (B) 1-side suspend memory

[0556] (B-1) Embedded 1-sided suspend memory

[0557] Reference Figure 51 and Figure 52 The embedded single-sided suspend memory is described. The embedded single-sided suspend memory has a differential engine working area, an application area, and a boot program area. The reprogramming firmware for program updates is configured in the boot program area, similar to the single-sided independent memory, and is an object other than the object of program update. The object of program update, that is, the application area, is suspected to have an A side and a B side, and version information, an application, and a normal time vector table are configured on the A side and the B side, respectively. The boot program, reprogramming firmware, a reprogramming time vector table, a boot side judgment function, boot side judgment information, and a boot time vector table are configured in the boot area.

[0558] like Figure 51 As shown, when the microcomputer 33 performs normal actions such as vehicle control processing, diagnostic processing, and other application processing, it executes the startup program and uses the startup surface judgment function to determine which of the A and B surfaces is the application surface based on the startup surface judgment information of the A and B surfaces. If the microcomputer 33 determines that the A surface is the application surface, it will refer to the normal time vector table of the A surface to search for the starting address and execute the application of the A surface. Similarly, if the microcomputer 33 determines that the B surface is the application surface, it will refer to the normal time vector table of the B surface to search for the starting address and execute the application of the B surface. In addition, Figure 51 In the embodiment, the reprogrammed firmware is arranged in the boot program area, but the reprogrammed firmware may be configured as the target of program update and arranged in respective areas of the A side or the B side.

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

[0560] (B-2) Downloadable 1-side suspend memory

[0561] Reference Figure 53 and Figure 54 The downloadable single-side suspend memory is described below. The downloadable type differs from the embedded type described above in that the reprogramming firmware and reprogramming vector table are downloaded from the outside and then deleted after the application is rewritten.

[0562] like Figure 53 As shown, when microcomputer 33 performs normal operations such as vehicle control and diagnostic processing, it executes a startup program similar to the embedded type. Using the startup surface determination function, it determines the newness or oldness of each startup surface determination information on surfaces A and B, thereby determining which of the two surfaces is the operational surface. If microcomputer 33 determines that surface A is the operational surface, it searches for the starting address by referring to the normal-time vector table of surface A and executes the application program on surface A. Similarly, if microcomputer 33 determines that surface B is the operational surface, it searches for the starting address by referring to the normal-time vector table of surface B and executes the application program on surface B.

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

[0564] (C) 2-sided memory

[0565] (C-1) Embedded 2-sided memory

[0566] Reference Figure 55 and Figure 56 The embedded two-sided memory is described. The embedded one-sided independent memory has an application area and a rewrite program area on side A, an application area and a rewrite program area on side B, and a boot program area. The boot program is configured in the boot area in a manner that cannot be rewritten. The boot program includes a boot exchange function and a boot vector table. Version information, parameter data, application, firmware, and a normal vector table are configured in each application area. A program for controlling rewrites, reprogramming progress management information 2, reprogramming progress management information 1, boot side determination information, wireless reprogramming firmware, wired reprogramming firmware, and a boot vector table are configured in each rewrite program area. The boot area contains a boot program, a boot exchange function, and a boot vector table.

[0567] like Figure 55 As shown, the microcomputer 33 executes a startup program both during normal operations for application processing such as vehicle control and diagnostic processing, and during rewriting operations for non-operational applications. Based on the startup face determination information for each side A and side B, the startup swap function determines which side is the operational side. If the microcomputer 33 determines that side A is the operational side, it searches for a starting address by referring to the startup-time vector table and the normal-time vector table for side A, and executes the application for side A. Similarly, if the microcomputer 33 determines that side B is the operational side, it searches for a starting address by referring to the startup-time vector table and the normal-time vector table for side B, and executes the application for side B.

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

[0569] (C-2) Downloadable 2-sided memory

[0570] Reference Figure 57 and Figure 58 The downloadable two-sided memory is described below. The downloadable type differs from the embedded type described above in that wireless reprogramming firmware and wired reprogramming firmware are downloaded externally, and after the application is rewritten, the wireless reprogramming firmware and wired reprogramming firmware are deleted.

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

[0572] like Figure 58 As shown, when the microcomputer 33 performs the rewriting action of the application rewriting process, the application of the non-operating surface is temporarily stored in the differential engine working area as old data. The microcomputer 33 reads the old data temporarily stored in the differential engine working area, and restores the new data based on the read old data and the differential data stored in the RAM33c by the recompiled firmware downloaded from the outside. If the microcomputer 33 generates new data based on the old data and the differential data, the new data is written to the non-operating surface to rewrite the application of the non-operating surface. In addition, the old data temporarily stored in the differential engine working area can also be the application of the operating surface as the target, or the application of the non-operating surface as the target. At this time, when the application of the operating surface is the target, the data of the non-operating surface is eliminated before the new data is written. Here, when the recompiled data obtained from the outside of the vehicle is not differential data but overall data (all data), the obtained recompiled data is written as new data to the non-operating surface. In Figure 58 In the example, side A is the active side and side B is the non-active side. Furthermore, the old data temporarily stored in the differential engine operating area can be targeted at either active or non-active applications. This allows applications on side A to be executed in both memories while side B is being rewritten in the background.

[0573] As described above, in either the embedded type or the download type, an application program and a rewriting program for rewriting the application program are arranged in each application area. Figure 56 and Figure 58 In the example, the application program is shown as the target for reprogramming, but the rewriting program can also be the target for reprogramming. Furthermore, if it is desired to prevent the rewriting program from being rewritten, the rewriting program can be placed in the startup area. For example, a program for wired rewriting can be placed in the startup area, allowing dealers and others to reliably perform wired rewriting via the tool 23.

[0574] Next, refer to Figures 59 to 61 The overall sequence for rewriting an application will be explained. Here, the user will be described as rewriting an application while the vehicle is parked by operating the portable terminal 6, which serves as the display terminal 5. The same applies to rewriting an application while the vehicle is parked by operating the onboard display 7. The distribution packet sent from the center device 3 to the DCM 12 stores write data for one or more target ECUs 19. Specifically, if there is one target ECU 19, the distribution packet stores a single write data item for that single target ECU 19. If there are multiple target ECUs 19, the distribution packet stores multiple write data items for each of the multiple target ECUs 19. Here, there are two target ECUs 19, and these two target ECUs 19 are referred to as target ECU (ID1) and target ECU (ID2). ECUs 19 other than target ECU (ID1) and target ECU (ID2) are referred to as "other ECUs."

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

[0576] Upon receiving version notification signals from the target ECU (ID1) and the target ECU (ID2), the center device 3 identifies the application version and ECU (ID) contained in the received version notification signals and determines whether there is write data to be distributed to the target ECU 19, which was the source of the version notification signal. Based on the version notification signal received from the target ECU, the center device 3 determines the current application version of the target ECU 19 and compares the current application version with the latest version managed by the center device.

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

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

[0579] When the user selects updated content in the portable terminal 6 (A2), the portable terminal 6 notifies the center device 3 of a distribution package download request.

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

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

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

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

[0584] The master device 11 begins distributing write data to the target ECU (ID1) and instructs the target ECU (ID1) to write the write data. When the target ECU (ID1) begins receiving write data from the master device 11 and is instructed to write the write data, it begins writing the write data and begins the program rewrite process (C1). When the target ECU (ID1) completes receiving the write data from the master device 11, writing the write data, and completing the program rewrite process, it transmits a rewrite completion notification signal to the master device 11.

[0585] When the master device 11 receives a rewrite 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 write data. When the target ECU (ID2) begins receiving write data from the master device 11 and is instructed to write the write data, it begins writing the write data and begins the program rewrite process (D1). When the target ECU (ID2) completes receiving the write data from the master device 11, writing the write data, and completing the program rewrite process, it transmits a rewrite completion notification signal to the master device 11. When the master device 11 receives the rewrite completion notification signal from the target ECU (ID2), it transmits the rewrite completion notification signal to the center device 3.

[0586] Upon receiving the rewrite completion notification signal from the host device 11, the center device 3 notifies the portable terminal 6 of the completion of the application rewrite. Upon receiving the notification of the application rewrite completion from the center device 3, the portable terminal 6 displays a rewrite completion notification screen (A6). The user can confirm the completion of the application rewrite on the rewrite completion notification screen displayed on the portable terminal 6, thereby activating the synchronization setting.

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

[0588] When the rewriting target ECU (ID1) and the rewriting target ECU (ID2) each receive a synchronous switching instruction signal from the host device 11, they begin a program switching process (C2, D2) to switch the application to be started next from the old application to the new application. When the rewriting target ECU (ID1) and the rewriting target ECU (ID2) each complete the program switching process, they transmit a switching completion notification signal to the host device 11.

[0589] Upon receiving a switching completion notification signal from the target ECU (ID1) and the target ECU (ID2), the master device 11 issues a version readout signal to each target ECU (ID1) and the target ECU (ID2). Upon receiving the version readout signal from the master device 11, each target ECU (ID1) and the target ECU (ID2) reads the version (C3, D3) of the application program to be subsequently used and transmits a latest version notification signal containing the readout version to the master device 11. Receiving the version notification signal from the target ECU (ID1) and the target ECU (ID2) allows the master device 11 to check the software version or perform a rollback as needed.

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

[0591] The host device 11 transmits a latest version notification signal to the center device 3. Upon receiving the latest version notification signal from the host device 11, the center device 3 determines the latest version of the application program for the rewrite target ECU (ID1) and the rewrite target ECU (ID2) based on the received latest version notification signal, and notifies the portable terminal 6 of the determined latest version. Upon receiving the latest version notification from the center device 3, the portable terminal 6 displays a latest version notification screen (A8) indicating the notified latest version. The user can confirm the latest version and the completion of activation by viewing the latest version notification screen displayed on the portable terminal 6.

[0592] Next, refer to Figures 62 to 65 The timing diagram of the DCM 12, CGW 13, and target ECU 19 for rewriting applications will be described. Furthermore, this section describes the case where applications are rewritten to two memory ECUs while the IG switch 42 is on by user operation, that is, while the vehicle is drivable, and the case where applications are rewritten to one suspended memory ECU and one independent memory ECU while the vehicle is parked after the IG switch 42 is turned off by user operation. Furthermore, the case where applications are rewritten using power supply control and the case where applications are rewritten using self-powered maintenance will be described.

[0593] (A) When rewriting the application program through power control

[0594] Reference Figure 62 and Figure 63 The following describes the case of rewriting applications using power control. Rewriting applications using power control does not use a self-holding circuit, but rather controls the rewriting operation based on power switching. When the user switches the IG switch from off to on, switching the vehicle power supply from +B power to IG power, the DCM 12, CGW 13, two-side memory ECU, one-side suspended memory ECU, and one-side independent memory ECU each begin normal operation (t1).

[0595] When the DCM 12 receives a notification from the center device 3 that the download has started, it switches from normal operation to downloading operation and begins downloading the distribution package from the center device 3 (t2). The DCM 12 can continue normal operation while downloading the distribution package in the background. When the DCM 12 completes downloading the distribution package from the center device 3, it returns from downloading operation to normal operation (t3).

[0596] When the DCM 12 receives a rewrite instruction signal (installation instruction signal) from the center device 3 or CGW 13, it shifts from normal operation to data transfer / center communication operation and begins data transfer / center communication operation (t4). Specifically, the DCM 12 extracts the write data from the distribution package, begins transmitting the write data to the CGW 13, obtains the rewrite progress status from the CGW 13, and begins notifying the center device 3 of the rewrite progress status.

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

[0598] In the 2-side memory ECU, during the rewriting of the application, if the user switches the IG switch from on to off and switches the vehicle power supply from IG power supply to +B power supply, DCM12 interrupts the data transmission / center communication action, CGW13 interrupts the reprogramming main action, the 2-side memory ECU interrupts the installation phase, and the rewriting of the application is interrupted (t5).

[0599] Then, when the user switches the IG switch from OFF to ON, switching the vehicle power source from +B power source to IG power source, the DCM 12 resumes data transmission / center communication operations, the CGW 13 resumes the main reprogramming operation, and the two-side memory ECUs resume the installation phase, resuming application program rewriting (t6). Specifically, when the user switches the IG switch from ON to OFF, switching the vehicle power source from IG power source to +B power source, and then switches the vehicle power source from +B power source to IG power source, switching the IG switch from OFF to ON, each time a trip occurs, the two-side memory ECUs repeatedly interrupt and resume application program rewriting (t7, t8).

[0600] Once the dual-side memory ECU has completed writing the write data and rewriting the application, the installation phase ends and the system transitions from normal operation to waiting for activation. Specifically, when the dual-side memory ECU is not in the activation phase, it will not start on the new side (side B) to which the application has been rewritten, but will continue to start on the old side (side A) (t9).

[0601] After the user switches the IG switch from on to off, switching the vehicle's power supply from IG to +B (t10), the two-side memory ECUs complete rewriting the application program, and the CGW 13 sends a power startup request to the power management ECU 20. Once the CGW 13 sends the power startup request to the power management ECU 20, switching the vehicle's power supply from +B to IG, the DCM 12 resumes data transmission / center communication operations, and the CGW 13 resumes the reprogramming main operation, beginning to distribute write data to the single-side suspended memory ECU and the single-side independent memory ECU. Once the single-side suspended memory ECU and the single-side independent memory ECU each begin receiving write data from the CGW 13, they transition from normal operation to the boot process, where the installation phase begins (t11). Specifically, the single-side suspended memory ECU and the single-side independent memory ECU perform installation not in parallel with normal operation but during the boot process, when the application program is not running.

[0602] If the 1-side suspended memory ECU starts rewriting of the application, the rewriting of the application is interrupted when the IG switch 42 is switched from off to on by the user operation before the rewriting of the application is completed. The 1-side suspended memory ECU does not restore the non-operating side (B side) where the rewriting of the application is interrupted to the startup side, but restores the operating side (A side) to the startup side. If the 1-side independent memory ECU starts rewriting of the application, the rewriting of the application continues even if the IG switch 42 is switched from off to on by the user operation before the rewriting of the application is completed. This is because if the 1-side independent memory ECU is interrupted in the middle of rewriting the application, it cannot be restored to normal operation. It is preferred that after starting rewriting of the application of the 1-side independent memory ECU, the user's operation on the IG switch 42 is invalid until the rewriting of the application is completed.

[0603] When the 1-side suspended memory ECU completes writing data and rewriting the application, it ends the installation phase during the startup process and transitions from the startup process to the waiting phase for activation. Specifically, when the 1-side suspended memory ECU is not in the activation phase, it will not start on the new side (side B) with the rewritten application, but will continue to start on the old side (side A). When the 1-side independent memory ECU completes writing data and rewriting the application, it ends the installation phase during the startup process and transitions to the waiting phase for activation (t12).

[0604] When the power management ECU 20 switches the vehicle's power supply from IG power to +B power in response to an activation instruction from the CGW 13, the two-side memory ECU and the one-side suspended memory ECU each switch from the old side to the new side and start up on the new side. The subsequent phase (hereinafter referred to as the activation phase) begins during the new-side startup. The one-side independent memory ECU begins restarting, and the activation phase begins during the restart after installation is complete (t13, t14). During the activation phase, the new program is confirmed to have been correctly started up, and version information is notified to the CGW 13.

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

[0606] Thereafter, if the user switches the IG switch from off to on and switches the vehicle power supply from +B power supply to IG power supply, the 2-side memory ECU and the 1-side suspended memory ECU each start a new application using the new side (B side) as the startup side, and the 1-side independent memory ECU starts the new application (t16).

[0607] (i) When rewriting the application program by self-maintaining the power supply

[0608] Reference Figure 64 and Figure 65 The following describes the case of rewriting an application program using power self-sustaining. Rewriting an application program using power self-sustaining refers to a configuration in which the rewriting operation is controlled using a power self-sustaining circuit. When the user switches the IG switch from off to on, switching the vehicle power supply from +B power to IG power, the DCM 12, CGW 13, two-side memory ECU, one-side suspended memory ECU, and one-side independent memory ECU each begin normal operation (t21).

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

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

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

[0612] In the dual-side memory ECU, while the application is being rewritten, if the user switches the IG switch from on to off, switching the vehicle power source from IG power to +B power (t25), the DCM 12 continues data transmission / center communication operations, the CGW 13 continues reprogramming operations, and the dual-side memory ECU continues the installation phase, continuing the application rewrite. After a predetermined time, or self-holding period, has elapsed since the vehicle power source was switched from IG power to +B power, the DCM 12 suspends data transmission / center communication operations, the CGW 13 suspends reprogramming operations, and the dual-side memory ECU suspends the installation phase, terminating the application rewrite (t26). Specifically, installation continues with power supplied from the vehicle battery 40 until the predetermined time has elapsed after the IG switch 42 is turned off.

[0613] Then, when the user switches the IG switch from OFF to ON, switching the vehicle power source from +B to IG, the DCM 12 resumes data transmission / center communication operations, the CGW 13 resumes the reprogramming master operation, and the two-side memory ECUs resume the installation phase, resuming application rewriting (t27). Specifically, when the user switches the IG switch from ON to OFF, switching the vehicle power source from IG to +B, and then switches the vehicle power source from +B to IG, switching the IG switch from OFF to ON, the two-side memory ECUs repeatedly interrupt and resume application rewriting each time a trip occurs (t28-t30). However, after the vehicle power source switches from IG to +B, and until the self-holding period has expired, the DCM 12 continues data transmission / center communication operations, the CGW 13 continues the reprogramming master operation, and the two-side memory ECUs continue the installation phase, continuing application rewriting.

[0614] Once the 2-side memory ECU has completed writing the write data and rewriting the application, the installation phase ends and the system transitions from normal operation to waiting for activation. Specifically, when the 2-side memory ECU is not in the activation phase, it will not start on the new side (Side B) to which the application has been rewritten, but will continue to start on the old side (Side A) (t31).

[0615] If the user switches the IG switch from on to off to switch the vehicle power supply from IG power supply to +B power supply, at this moment the rewriting of the application is completed in the 2-sided memory ECU, then the 1-sided suspended memory ECU and the 1-sided independent memory ECU are respectively transferred from normal operation to the startup processing, the startup processing is started, and the installation phase (t32) is started in the startup processing.

[0616] Once the suspended memory ECU and independent memory ECU have completed writing data and rewriting the application, the installation phase of the startup process ends (t33). When the CGW 13 sends a power startup request to the power management ECU 20, switching the vehicle power supply from +B power to IG power, the DCM 12 resumes data transmission / center communication operations (t34).

[0617] When the 1-side suspended memory ECU completes writing data and rewriting the application, it transitions from the startup process to the waiting stage for activation. Specifically, the 1-side suspended memory ECU will not start on the new side (Side B) with the rewritten application until the activation phase is complete, but will continue to start on the old side (Side A). When the 1-side independent memory ECU completes writing data and rewriting the application, it ends the installation phase during the startup process and enters the waiting stage for activation (t35).

[0618] When the power management ECU 20 switches the vehicle power supply from IG power to +B power in response to an activation instruction from the CGW 13, the two-side memory ECU and the one-side suspended memory ECU each switch from the old side to the new side, restarting on the new side. The activation phase begins during the new-side startup. The one-side independent memory ECU begins restarting, and the activation phase begins during the restart after installation is complete (t36, t37).

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

[0620] Thereafter, if the user switches the IG switch from off to on and switches the vehicle power supply from +B power supply to IG power supply, the 2-side memory ECU and the 1-side suspended memory ECU each start a new application using the new side (B side) as the startup side, and the 1-side independent memory ECU starts the new application (t39).

[0621] Before downloading the distribution package from the center device 3 and distributing it to the target ECU 19 for data writing, the CGW 13 performs the following checks. Before downloading the distribution package from the center device 3, the CGW 13 checks the radio wave environment, the remaining battery level of the vehicle battery 40, and the memory capacity of the DCM 12 to ensure normal downloading. Before distributing the distribution package to the target ECU 19 for data writing, the CGW 13 performs checks for intrusion sensors, door locks, curtains, and disconnected IG (internal galvanic isolation) to ensure stable distribution of the written data, ensuring the installation environment remains stable. Furthermore, the CGW 13 performs version checks and error detection checks to verify that the target ECU 19 is capable of writing data. Furthermore, before starting installation, the CGW 13 performs tampering checks, access authentication, and version checks. During installation, it performs checks for communication interruption and error occurrences. After installation is complete, it performs version checks, integrity checks, and DTC (Diagnostic Trouble Code) checks.

[0622] Next, refer to Figures 66 to 82 The screen displayed by the display terminal 5 is described. Figure 66As shown, the structure for rewriting the application of the rewrite target ECU 19 via OTA involves the following stages: activity notification, download, installation, and activation. Activity notification refers to notification of a program update. For example, when the center device 3 determines that an application update is available, the host device 11 downloads and distributes specification data. The display terminal 5 displays screens at each stage as the application rewrite progresses. The screens displayed on the in-vehicle display 7 will be described below.

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

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

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

[0626] If the user operates the "Details Confirmation" button 503b from the state where the download consent screen 503 is displayed, Figure 71 As shown, CGW13 switches the display content of the download consent screen 503 and displays the download details on the vehicle display 7. As the download details, CGW13 uses the received distribution specification data to display the update content, the time required for the update, the restrictions on the vehicle functions associated with the update, etc. In addition, if the user presses the "download start" button 503a, CGW13 starts downloading the distribution package via DCM12. In parallel with the start of the download of the distribution package, Figure 72 As shown, the CGW 13 switches the display from the download approval screen 503 to the navigation screen 501, causes the in-vehicle display 7 to display the navigation screen 501 again, and displays a download-in-progress icon 501b indicating that the download is in progress at the lower right corner of the navigation screen 501. The user can confirm that the download of the distribution package is in progress by confirming the display of the download-in-progress icon 501b.

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

[0628] If the download is complete, Figure 74As shown, the CGW 13 displays a pop-up download completion notification screen 505 on the navigation screen 501. In the download completion notification screen 505, the CGW 13 displays, for example, a message stating "Download completed, software update available," notifying the user of the download completion. It also displays a "Confirm" button 505a and a "Next" button 505b, awaiting user input. In this case, the user can press the "Confirm" button 505a to access the screen for starting the installation.

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

[0630] If the user operates the "Update Now" button 506a from this state, Figure 76 As shown, the CGW 13 switches the display content of the installation consent screen 506 and displays the details of the installation on the vehicle-mounted display 7. The CGW 13 accepts the installation request on the installation consent screen 506 and notifies the user of the start of the installation.

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

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

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

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

[0635] If the user operates the "OK" button 509a from this state, Figure 81 As shown, the CGW 13 switches the display from the navigation screen 501 to the confirmation operation screen 510, and displays the confirmation operation screen 510 on the vehicle-mounted display 7. In the confirmation operation screen 510, the CGW 13 notifies the user of the completion of activation and displays a "Confirm Details" button 510a and an "OK" button 510b, waiting for the user's operation. In this case, the user can display the details of the activation completion by pressing the "Confirm Details" button 510a.

[0636] If the user operates the "Details Confirmation" button 510a from this state, Figure 82As shown, the CGW 13 switches the display content of the confirmation operation screen 510, causing the onboard display 7 to display details indicating the activation completion. The CGW 13 displays the functions added and changed by the update as update details, and also displays an "OK" button 510b. Based on the user's operation of the "OK" buttons 509a and 510b, the CGW 13 determines that the user has confirmed the completion of the software update.

[0637] As described above, the vehicle-side system 4 controls each operational phase, such as event notification, download, installation, activation, and update completion, and presents the user with a display appropriate to each operational phase. Furthermore, while the above description employs a configuration in which the CGW 13 controls the display, the in-vehicle display 7 may alternatively receive the operational phase and distributed specification data from the CGW 13 and display the information.

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

[0639] (1) Distribution package delivery determination process

[0640] (2) Distribution package download determination process

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

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

[0643] (5) Installation instruction determination process

[0644] (6) Management of secure access keys

[0645] (7) Verification of written data

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

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

[0648] (10) File transfer control processing

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

[0650] (12) Activation request instruction processing

[0651] (13) Activated execution control processing

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

[0653] (15) Rollback execution control processing

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

[0655] (17) Integrity determination processing of differential data

[0656] (18) Rewritten execution control processing

[0657] (19) Session establishment process

[0658] (20) Determination and processing of retesting

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

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

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

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

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

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

[0665] The center device 3 , DCM 12 , CGW 13 , ECU 19 , and on-vehicle display 7 are structures for performing the characteristic processes (1) to (26) described above, and have the following functional blocks.

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

[0667] like Figure 84As shown, the DCM 12 includes a download request transmitter 61, a distribution package downloader 62, a write data extractor 63, a write data transmitter 64, a rewrite specification data extractor 65, and a rewrite specification data transmitter 66. The download request transmitter 61 transmits a distribution package download request to the center device 3. The distribution package downloader 62 downloads the distribution package from the center device 3. Upon downloading the distribution package from the center device 3 via the distribution package downloader 62, the write data extractor 63 extracts the write data from the downloaded distribution package.

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

[0669] like Figure 85 and Figure 86 As shown, the CGW 13 includes an acquisition request sending unit 71, a write data acquisition unit 72 (equivalent to an update data storage unit), a write data distribution unit 73 (equivalent to an update data distribution unit), a rewrite specification data acquisition unit 74, and a rewrite specification data analysis unit 75. The write data acquisition unit 72 receives the write data from the DCM 12, thereby acquiring the write data. Upon receiving the write data from the write data acquisition unit 72, the write data distribution unit 73 distributes the acquired write data to the rewrite target ECU 19 when the distribution timing of the write data arrives. The rewrite specification data acquisition unit 74 receives the rewrite specification data from the DCM 12, thereby acquiring the rewrite specification data. Upon receiving the rewrite specification data from the rewrite specification data acquisition unit 74, the rewrite specification data analysis unit 75 analyzes the acquired rewrite specification data.

[0670] In addition to the above-mentioned components, the CGW 13 includes, as components that perform characteristic processing, a write data acquisition determination unit 76, an installation instruction determination unit 77, a secure access key management unit 78, a write data verification unit 79, a data storage surface information transmission control unit 80, a non-rewrite target power management unit 81, a file transfer control unit 82, a write data distribution control unit 83, an activation request instruction unit 84, a rewrite target group management unit 85, a rollback execution control unit 86, a rewrite progress status display control unit 87, a progress status synchronization control unit 88, a display control information reception control unit 89, a progress display screen display control unit 90, a program update report control unit 91, and a power self-maintaining execution control unit 92. The functional blocks that perform characteristic processing will be described later.

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

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

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

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

[0675] Reference Figure 89 and Figure 90 The following describes the distribution packet transmission determination process of the center device 3. Figure 91 and Figure 92 The distribution package download determination process performed by the host device 11 will be described.

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

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

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

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

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

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

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

[0683] If the center device 3 determines that there is no update data for the vehicle (S102: No), it transmits content that is not intended for distribution of the distribution package, namely, content that does not include an application update, to the main device 11 (S105), terminating the distribution package transmission determination process. If the center device 3 determines that the vehicle is not in a state suitable for updating the program, etc., using the distribution package (S103: No), it transmits the content and reasons why the program, etc. is not suitable for updating to the main device 11 (S106), terminating the distribution package transmission determination process. In this case, the main device 11 causes the in-vehicle display 7 to display the content and reasons why the program, etc. is suitable for updating. For example, if the license agreement is not established, the main device 11 causes the in-vehicle display 7 to display a message such as "The license is invalid, so the program cannot be updated. Please inquire with the dealer." This allows the user to be informed of the reasons why the content is not suitable for updating the program, etc., and to be presented with appropriate information.

[0684] As described above, the center device 3 performs a distribution package transmission determination process before sending the distribution package to the host device 11 and before sending the event information. This process allows the center device 3 to determine whether the state is suitable for updating the program, etc., that uses the distribution package. Furthermore, the center device 3 sends the distribution package to the host device 11 and sends the event information to the host device 11 only when it determines that the state is suitable for updating the program, etc. that uses the distribution package.

[0685] In the case of an update for a program or the like suitable for use with a distribution package, the center device 3 can transmit action information to the host device 11 if a license agreement is established, the vehicle's location is within a specified range pre-registered by the user, the vehicle's alarm function is enabled, and no ECU 19 failure information has been generated. Specifically, the center device 3 can avoid transmitting action information to the host device 11 if a license agreement is not established, the vehicle's location is outside a specified range (e.g., far from the home), the vehicle's alarm function is disabled, or ECU 19 failure information has been generated. This allows the center device 3 to refrain from transmitting action information to the host device 11 for vehicles that may be subject to an update that is not intended by the user, or for vehicles that may fail during installation even if the download is successful.

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

[0687] Next, the processing of the host device 11 which receives the event information transmitted from the center device 3 will be described. Figure 91 and Figure 92 The following describes the distribution package download determination process in the main device 11. The vehicle program rewriting system 1 performs the distribution package download determination process in the main device 11. While the distribution package transmission determination process (1) described above is performed by the center device 3 during the activity notification phase prior to the download phase, the distribution package download determination process is performed by the main device 11 during the download phase. While this embodiment describes the case where the DCM 12 in the main device 11 performs the distribution package download determination process, it is also possible that the CGW 13 performs the distribution package download determination process by providing the functionality of the DCM 12.

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

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

[0690] In this way, the downloadable determination unit 67b determines whether the downloading may not be completed normally. Figure 70 and Figure 71 In the download consent screen 503 shown, the download availability determination unit 67b makes a determination based on the user's operation of the "Start Download" button 503a. Alternatively, the download availability determination unit 67b may also be configured to determine the status of the vehicle based on the determination items of the center device 3. Specifically, for example, if the vehicle alarm function is enabled or if no ECU 19 failure information is generated, the download availability determination unit 67b determines that the vehicle is in a downloadable state.

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

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

[0693] Next, refer to Figure 92 The following describes the role of the distribution package download determination unit 67 in the host device 11. The host device 11 executes a distribution package download determination program to perform distribution package download determination processing.

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

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

[0696] In the case where the radio wave environment is good, the remaining battery level of the vehicle battery 40 is at least a predetermined level, and the available memory capacity of the DCM 12 is at least a predetermined level, which is a suitable condition for downloading the distribution package, the host device 11 can download the distribution package from the center device 3. In other words, when the radio wave environment is good, the remaining battery level of the vehicle battery 40 is less than a predetermined level, or the available memory capacity of the DCM 12 is less than a predetermined level, downloading the distribution package from the center device 3 can be avoided.

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

[0698] In this way, the center device 3 determines whether the vehicle is likely to receive an update that is not intended by the user or is likely to fail in installation, and the host device 11 determines whether the download is likely to fail. This can prevent unnecessary activity information and distribution packages from being sent from the center device 3 to the host device 11.

[0699] The center device 3 has the following configuration: a software information acquisition unit 52a that acquires software information about the electronic control unit from the vehicle; an update presence / absence determination unit 52b that determines the presence or absence of update data for the vehicle based on the software information acquired by the software information acquisition unit; an update suitability determination unit 52c that, if the update presence / absence determination unit determines that update data exists, determines whether the vehicle state is suitable for an update; and an activity information transmission unit 52d that, if the update suitability determination unit determines that the vehicle state is suitable for an update, transmits activity information related to the update to the vehicle master device.

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

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

[0702] Reference Figure 93 and Figure 94 For an explanation of the write data transfer determination process, refer to Figure 95 and Figure 96 For an explanation of the write data acquisition and determination process, refer to Figures 97 to 100 The installation instruction determination process will be described. The vehicle program rewriting system 1 performs a write data transmission determination process in the DCM 12. Here, the distribution package sent from the center device 3 to the DCM 12 is decompressed, and the write data is extracted from the distribution package.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0719] If the installation condition determination unit 77a determines that all of the first, second, third, fourth, and fifth conditions are met, the installation instructing unit 77b instructs the target ECU 19 to install the application. Specifically, if the installation condition determination unit 77a determines that the user has consented to the installation, the CGW 13 can communicate data with the center unit 3, the vehicle is in a state that allows installation, the target ECU 19 is in a state that allows installation, and the written data is normal, the installation instructing unit 77b instructs the target ECU 19 to install the application. Specifically, the installation instructing unit 77b acquires the written data from the DCM 12 and transmits the acquired 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 instructing unit 77b does not instruct the target ECU 19 to install the application, and instead notifies the user of a waiting state or a failure to start installation, along with the reason.

[0720] The vehicle state information acquisition unit 77c acquires the vehicle state information from the center device 3. When the installation of the application program is completed in all the rewriting target ECUs 19, the activation condition determination unit 77d determines whether the sixth condition, the seventh condition, and the eighth condition are satisfied. The sixth condition is to obtain the user's consent related to the activation. The user's consent related to the activation is, for example, Figure 79 The screen shown shows the user's consent to activation (e.g., pressing the "OK" button 508b). Alternatively, the process from download to activation can be considered a single update, with the user's consent to the update being performed. The seventh condition is that the vehicle is in a state where activation is possible. The eighth condition is that the target ECU 19 is in a state where activation is possible.

[0721] If the activation condition determination unit 77d determines that the sixth condition, the seventh condition, and the eighth condition are all met, the activation instruction unit 77e instructs the rewrite target ECU 19 to activate the application. Specifically, this will be described in the instruction processing of the activation request (12) described later. That is, if the activation condition determination unit 77d determines that the user consent related to the activation is obtained, the vehicle state is in an activation-capable state, and the rewrite target ECU 19 is in an activation-capable state, the activation instruction unit 77e instructs the rewrite target ECU 19 to activate the application. By performing the activation, the update program written to the rewrite target ECU 19 is validated. If the activation condition determination unit 77d determines that at least one of the sixth condition, the seventh condition, and the eighth condition is not met, the activation instruction unit 77e does not instruct the rewrite target ECU 19 to activate the application, and prompts the user to the content and reason of standby or inability to start activation.

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

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

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

[0725] If the CGW13 determines that the vehicle status is installable (S503: "Yes"), it determines whether the fourth condition is met and determines whether the rewrite target ECU19 can be installed (S504, equivalent to a part of the installation condition determination step). For example, when the rewrite target ECU19 does not generate a fault code and the security access to the rewrite target ECU19 is successful, the CGW13 determines that the rewrite target ECU19 can be installed. Here, in addition to the rewrite target ECU19 to which the write data is written, the generation of a fault code can also be confirmed for the ECU19 that cooperates with the rewrite target ECU19. That is, the CGW13 not only determines whether a fault code is generated for the rewrite target ECU19, but also determines whether a fault code is generated for the ECU19 that cooperates with the rewrite target ECU19.

[0726] If CGW13 determines that the rewrite target ECU19 can be installed (S504: "Yes"), it determines whether the fifth condition is met and determines whether the written data is normal data (S505, equivalent to a part of the installation condition determination step). If the written data is in accordance with the write surface (non-operation surface) of the rewrite target ECU19 and the verification result of 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 rewrite target ECU19 to install the application (S506, equivalent to the installation instruction step). In this way, CGW13 makes judgments on the second and subsequent conditions based on the satisfaction of the first condition. In addition, CGW13 finally makes a judgment on the fifth condition. If CGW13 determines that all the first to fifth conditions are met, it instructs the rewrite target ECU19 to install the application.

[0727] On the other hand, if the CGW 13 determines that user consent for installation has not been obtained (S501: No), that data communication with the center unit 3 is impossible (S502: No), that the vehicle status is such that installation is not possible (S503: No), that the target ECU 19 is not capable of installation (S504: No), or that the written data is not normal data (S505: No), then the CGW 13 does not instruct the target ECU 19 to install the application. While the above process describes a configuration in which the condition of obtaining user consent for installation is determined before other conditions, a configuration in which the condition is determined after other conditions may also be used.

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

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

[0730] In addition, when there are multiple ECUs 19 to be rewritten, the CGW 13 may instruct the installation individually or collectively. When the ECUs 19 to be rewritten are ECU (ID1) and ECU (ID2), in the form of instructing the installation independently, such as Figure 99 As shown, CGW 13 determines whether the installation conditions for ECU (ID1) are met. If CGW 13 determines that the installation conditions for ECU (ID1) are met, it instructs ECU (ID1) to perform the installation. Next, CGW 13 determines whether the installation conditions for ECU (ID2) are met. Here, as the installation conditions, CGW 13 only needs to determine whether the fourth and fifth conditions for ECU (ID2) are met. If CGW 13 determines that the installation conditions for ECU (ID2) are met, it instructs ECU (ID2) to perform the installation.

[0731] When the rewriting target ECU 19 is ECU (ID1) or ECU (ID2), in the form of collectively instructing installation, as shown in FIG. Figure 100 As shown, CGW13 determines whether the installation conditions for ECU (ID1) are met. That is, CGW13 determines the first to third conditions, as well as the fourth and fifth conditions for ECU (ID1). If CGW13 determines that the installation conditions for ECU (ID1) are met, it determines whether the installation conditions for ECU (ID2) are met. That is, CGW13 determines the fourth and fifth conditions for ECU (ID2). If the installation conditions for ECU (ID2) are met, CGW13 instructs ECU (ID1) and ECU (ID2) to install. For example, CGW13 transmits rewrite data to ECU (ID1) and rewrite data to ECU (ID2) simultaneously and in parallel. In this way, in the form of unified installation instruction, CGW13 determines the first to third conditions, as well as the fourth and fifth conditions for all rewrite target ECUs. Moreover, CGW13 instructs installation based on the satisfaction of all these conditions.

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

[0733] (6) Management of secure access keys

[0734] Reference Figures 101 to 105 The management process of the security access key is described. The security access key is a key used to perform device authentication when accessing the rewrite target ECU 19 before the CGW 13 installs the write data. The vehicle program rewriting system 1 performs the management process of the security access key in the CGW 13. Here, the description is based on the premise that the CGW 13 is in a state where it can obtain the write data from the DCM 12 through the above-mentioned (3) write data transmission determination process or (4) write data acquisition determination process. Device authentication using the security access key is equivalent to the fourth condition (step S505) of the above-mentioned (5) installation instruction determination process.

[0735] When the CGW 13 distributes write data to the target ECU 19, it must use a secure access key to perform secure access (device authentication) with the target ECU 19. In this case, a possible approach is to request the CGW 13 to generate a random value from the target ECU 19, obtain the random value generated by the target ECU 19, and calculate the obtained random value to generate the secure access key. However, if this approach also obtains a random value from the target ECU 19 when the application is not being rewritten, the secure access key can be stored, thereby creating a risk of security access key leakage.

[0736] Alternatively, if the CGW 13 transmits a random value received from the target ECU 19 to the central device 3, and the central device 3 calculates the random value to generate a secure access key, it is no longer necessary to store the secure access key, thereby reducing the risk of security access key leakage. However, in a configuration where the central device 3 calculates the random value, the waiting time until the target ECU 19 receives the random value from the central device 3 becomes long, making it difficult to meet the time requirements for diagnostic communication. In response to this, the following configuration is adopted in this embodiment.

[0737] like Figure 101 As shown, the vendor uses the security access key encryption and decryption keys to encrypt the security access key for each rewrite target ECU 19 to generate a random value. The random value here includes both values that are different from and the same as previously used values, and is a random value. The random value is the encrypted security access key. The vendor provides the generated random value along with the reprogramming data. The security access key, the encryption and decryption keys for the security access key, and the random value are unique to each ECU 19.

[0738] If the OEM is provided with re-coding data and random value from the supplier, the provided random value is associated with the ECU (ID) that identifies the ECU 19 and stored in Figure 44 The CGW rewrite specification data is shown. The OEM also stores the key mode and decoding operation mode required to decrypt the random value in the CGW rewrite specification data. The key mode stores information such as the common key / public key method and key length, while the decoding operation mode stores information such as the type of algorithm used for the decoding operation. Once the OEM stores the random value, key mode, and decoding operation mode in the CGW rewrite specification data, the OEM provides the CGW rewrite specification data containing the random value along with the reprogramming data to the center device 3. This information provided by the vendor is stored in the ECU reconfiguration data DB and ECU metadata DB, described later.

[0739] When the center device 3 receives reprogramming data and rewrite specification data (rewrite specification data for the DCM and rewrite specification data for the CGW) from the OEM, it sends a distribution package containing the provided rewrite specification data and reprogramming data to the host device 11. In the host device 11, the DCM 12 downloads the distribution package from the center device 3 and transmits the rewrite specification data and write data to the CGW 13.

[0740] like Figure 102 As shown, the CGW 13 includes a secure area 78a (equivalent to a decryption key storage unit), a random value extraction unit 78b (equivalent to a key-derived value extraction unit), a key mode extraction unit 78c, a decryption operation mode extraction unit 78d, a key generation unit 78e, a secure access execution unit 78f, a session transfer request unit 78g, and a key erasure unit 78h within its secure access key management unit 78. The secure area 78a, which prevents access to information from outside the ECU 19, contains the encryption and decryption keys for the secure access key, as well as the decryption operation algorithm. The random value extraction unit 78b extracts the random value (key-derived value) contained in the CGW rewrite specification data from the analysis results of the rewrite specification data. The random value is encrypted and associated with the ECU (ID) of the rewrite target ECU 19.

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

[0742] After the random value extraction unit 78b extracts the random value, the key generation unit 78e searches the secure area 78a and decrypts the extracted random value using the decryption key corresponding to the ECU (ID) from the decryption key group of secure access keys allocated in the secure area 78a, thereby generating a secure access key. In this case, the key generation unit 78e uses the decryption key ...

Claims

1. A central device comprising: The update data storage unit stores new data and new differential data used to update the old data to the new data, wherein: The new data is data of a target device to be updated among a plurality of electronic control devices mounted on the vehicle; a first verification value generating unit configured to generate a first verification value for verifying integrity in the vehicle using the new data; a second verification value generating unit configured to generate a second verification value for verifying the integrity of the new differential data in the vehicle using the new differential data; a distribution package generating unit configured to generate a distribution package including the new differential data for the plurality of target devices, the first verification value, and the second verification value; a third verification value generating unit configured to generate a third verification value for verifying the integrity of the distribution package in the vehicle using the distribution package; a distribution package sending unit, configured to send the distribution package together with the third verification value to the in-vehicle device; as well as a specification data generating unit configured to generate specification data including target device association information, update data association information of the target device, and update processing information specifying an update processing of the vehicle, wherein the target device association information includes device types of the target devices belonging to the same system in a system composed of the plurality of electronic control devices; The distribution package generation unit generates the distribution package including the new differential data for the target device belonging to the same system, the first verification value, the second verification value, and the specification data. The first verification value, the second verification value, and the third verification value are hash values obtained by applying a hash function to data. The new data and the old data are data of different versions. If the old data is updated to the new data in the target device, the data is updated to the new version of the data.

2. The central device according to claim 1, wherein: The update data storage unit stores the old data and old differential data for writing back the new data to the old data. The central device has: a fourth verification value generating unit that generates a fourth verification value for verifying integrity in the vehicle using the old data; and a fifth verification value generating unit that uses the old differential data to generate a fifth verification value for verifying the integrity of the old differential data in the vehicle, The distribution package generation unit generates a distribution package including the new differential data, the first verification value, the second verification value, the old differential data, the fourth verification value, the fifth verification value, and the specification data for the plurality of target devices. The fourth verification value and the fifth verification value are hash values obtained by applying a hash function to data.

3. The central device according to claim 2, wherein: The center device includes an authenticator assigning unit that assigns an authenticator generated using a secret key to generate one or more of the first, second, third, fourth, and fifth verification values as authenticator-attached verification values.

4. The central device according to any one of claims 1 to 3, wherein: The center device includes a package storage unit that stores the distribution package and the third verification value. The distribution package transmitting unit transmits, in response to a request from the in-vehicle device, a distribution package associated with the request and a third verification value to the in-vehicle device.

5. A central device comprising: The update data storage unit stores new data and new differential data used to update the old data to the new data, wherein: The new data is data of a target device to be updated among a plurality of electronic control devices mounted on the vehicle; a first verification value generating unit configured to generate a first verification value for verifying integrity in the vehicle using the new data; a second verification value generating unit configured to generate a second verification value for verifying the integrity of the new differential data in the vehicle using the new differential data; a distribution package generating unit configured to generate a distribution package including the new differential data for the plurality of target devices, the first verification value, and the second verification value; a third verification value generating unit configured to generate a third verification value for verifying the integrity of the distribution package in the vehicle using the distribution package; a distribution package sending unit, configured to send the distribution package together with the third verification value to the vehicle-mounted device; as well as a specification data generating unit that generates specification data including target device related information, update data related information of the target device, and update processing information specifying an update process of the vehicle, wherein the target device related information includes a device type of the target device; The distribution package generating unit causes the distribution package to include the specification data. The update data storage unit stores the old data and rollback data for writing back the new data to the old data. The central unit also features: a fourth verification value generating unit that generates a fourth verification value for verifying integrity in the vehicle using the old data; and a fifth verification value generating unit for generating a fifth verification value for verifying the integrity of the rollback data in the vehicle using the rollback data; The distribution package generation unit generates a distribution package including the new differential data, the first verification value, the second verification value, the rollback data, the fourth verification value, the fifth verification value, and the specification data for the plurality of target devices. The first verification value, the second verification value, the third verification value, the fourth verification value, and the fifth verification value are hash values obtained by applying a hash function to data. The new data and the old data are data of different versions. If the old data is updated to the new data in the target device, the data is updated to the new version of the data.

6. A vehicle information communication system comprising a central device and an onboard device, the onboard device being an electronic control device mounted on a vehicle, wherein a nonvolatile memory is rewritten using data downloaded from the central device, wherein: The central device has: an update data storage unit for storing new data and new differential data for updating old data to the new data, wherein the new data is data of a target device to be updated among a plurality of electronic control devices mounted on a vehicle; a first verification value generating unit configured to generate a first verification value for verifying integrity in the vehicle using the new data; a second verification value generating unit configured to generate a second verification value for verifying the integrity of the new differential data in the vehicle using the new differential data; a distribution package generating unit configured to generate a distribution package including the new differential data for the plurality of target devices, the first verification value, and the second verification value; a third verification value generating unit configured to generate a third verification value for verifying the integrity of the distribution package in the vehicle using the distribution package; a distribution package sending unit that sends the distribution package together with the third verification value to the in-vehicle device; and a specification data generating unit configured to generate specification data including target device association information, update data association information of the target device, and update processing information specifying an update processing of the vehicle, wherein the target device association information includes device types of the target devices belonging to the same system in a system composed of the plurality of electronic control devices; The distribution package generation unit generates the distribution package including the new differential data for the target device belonging to the same system, the first verification value, the second verification value, and the specification data. The vehicle-mounted device comprises: a receiving processing unit, receiving the distribution package and the third verification value; a third verification processing unit that calculates a verification value for the distribution package and compares the calculated verification value with the third verification value to verify the integrity of the distribution package; a second verification processing unit that calculates a verification value for the new differential data corresponding to the target device and included in the distribution package, and compares the calculated verification value with the second verification value corresponding to the target device and included in the distribution package to verify the integrity of the new differential data; a write processing unit that writes the new differential data corresponding to the target device and included in the distribution package into the nonvolatile memory of the target device; and a first verification processing unit that calculates a verification value for the data in the nonvolatile memory and compares the calculated verification value with the first verification value corresponding to the target device and included in the distribution package to verify the integrity of the data in the nonvolatile memory; The first verification value, the second verification value, and the third verification value are hash values obtained by applying a hash function to data. The new data and the old data are data of different versions. If the old data is updated to the new data in the target device, the data is updated to the new version of the data.

7. A vehicle information communication system comprising a central device and an onboard device, the onboard device being an electronic control device mounted on a vehicle, wherein a nonvolatile memory is rewritten using data downloaded from the central device, wherein: The central device has: an update data storage unit for storing new data and new differential data for updating old data to the new data, wherein the new data is data of a target device to be updated among a plurality of electronic control devices mounted on a vehicle; a first verification value generating unit configured to generate a first verification value for verifying integrity in the vehicle using the new data; a second verification value generating unit configured to generate a second verification value for verifying the integrity of the new differential data in the vehicle using the new differential data; a distribution package generating unit configured to generate a distribution package including the new differential data for the plurality of target devices, the first verification value, and the second verification value; a third verification value generating unit that uses the distribution package to generate a third verification value for verifying the integrity of the distribution package in the vehicle; and a distribution package sending unit, which sends the distribution package together with the third verification value to the vehicle-mounted device; The vehicle-mounted device comprises: a receiving processing unit, receiving the distribution package and the third verification value; a third verification processing unit that calculates a verification value for the distribution package and compares the calculated verification value with the third verification value to verify the integrity of the distribution package; a second verification processing unit that calculates a verification value for the new differential data corresponding to the target device and included in the distribution package, and compares the calculated verification value with the second verification value corresponding to the target device and included in the distribution package to verify the integrity of the new differential data; a write processing unit that writes the new differential data corresponding to the target device and included in the distribution package into the nonvolatile memory of the target device; and a first verification processing unit that calculates a verification value for the data in the nonvolatile memory and compares the calculated verification value with the first verification value corresponding to the target device and included in the distribution package to verify the integrity of the data in the nonvolatile memory; If, in the vehicle-mounted device, cancellation of rewriting processing occurs during rewriting of the nonvolatile memory, The second verification processing unit calculates a verification value for the old differential data corresponding to the target device included in the distribution package, and compares the calculated verification value with a fifth verification value corresponding to the target device included in the distribution package to verify the integrity of the old differential data. The write processing unit writes the old differential data corresponding to the target device included in the distribution package to the nonvolatile memory of the target device. The first verification processing unit calculates a verification value for the data in the nonvolatile memory, and compares the calculated verification value with a fourth verification value corresponding to the target device included in the distribution package to verify the integrity of the data in the nonvolatile memory. The first verification value, the second verification value, the third verification value, the fourth verification value, and the fifth verification value are hash values obtained by applying a hash function to data. The new data and the old data are data of different versions. If the old data is updated to the new data in the target device, the data is updated to the new version of the data.

8. The vehicle information communication system according to claim 7, wherein: The in-vehicle device includes a transmission processing unit configured to notify the center device of an abnormality if any verification result of the first to third verification processing units is failure.

9. The vehicle information communication system according to claim 8, wherein: The center device includes an abnormality reporting unit that reports the abnormality upon receiving abnormality information from the vehicle-mounted device.

10. A vehicle information communication system comprising a central device and an onboard device, the onboard device being an electronic control device mounted on a vehicle, wherein a nonvolatile memory is rewritten using data downloaded from the central device, wherein: The central device has: an update data storage unit for storing new data and new differential data for updating old data to the new data, wherein the new data is data of a target device to be updated among a plurality of electronic control devices mounted on a vehicle; a first verification value generating unit, configured to generate a first verification value for verifying the integrity of the new data using the new data; a second verification value generating unit configured to generate a second verification value for verifying the integrity of the new differential data in the vehicle using the new differential data; a distribution package generating unit configured to generate a distribution package including the new differential data for the plurality of target devices, the first verification value, and the second verification value; a third verification value generating unit that uses the distribution package to generate a third verification value for verifying the integrity of the distribution package in the vehicle; and a distribution package sending unit that sends the distribution package together with the third verification value to the in-vehicle device; and a specification data generating unit configured to generate specification data including target device association information, update data association information of the target device, and update processing information specifying an update processing of the vehicle, wherein the target device association information includes device types of the target devices belonging to the same system in a system composed of the plurality of electronic control devices; The distribution package generation unit generates the distribution package including the new differential data for the target device belonging to the same system, the first verification value, the second verification value, and the specification data. The vehicle-mounted device comprises: a receiving processing unit, receiving the distribution package and the third verification value; a third verification processing unit that calculates a verification value for the distribution package and compares the calculated verification value with the third verification value to verify the integrity of the distribution package; a second verification processing unit that calculates a verification value for the new differential data corresponding to the target device and included in the distribution package, and compares the calculated verification value with the second verification value corresponding to the target device and included in the distribution package to verify the integrity of the new differential data; a write processing unit that writes the new differential data corresponding to the target device and included in the distribution package into the nonvolatile memory of the target device; and a first verification processing unit that calculates a verification value for the data in the nonvolatile memory and sends the value to the central device, and receives a verification result from the central device; The center device compares the first verification value with the verification value received from the first verification processing unit and transmits the result as a verification result to the onboard device. The first verification value, the second verification value, and the third verification value are hash values obtained by applying a hash function to data. The new data and the old data are data of different versions. If the old data is updated to the new data in the target device, the data is updated to the new version of the data.

11. A method for sending a distribution package, comprising: A data acquisition step of acquiring new data and new differential data for updating old data to the new data, wherein: The new data is data of a target device to be updated among a plurality of electronic control devices mounted on the vehicle; a first verification value generating step of generating a first verification value for verifying integrity in the vehicle using the new data; a second verification value generating step of using the new differential data to generate a second verification value for verifying the integrity of the new differential data in the vehicle; a specification data generating step of generating specification data including target device association information, update data association information of the target device, and update processing information specifying an update processing of the vehicle, wherein the target device association information includes device types of the target devices belonging to the same system in a system composed of the plurality of electronic control devices; a distribution package generating step of generating the distribution package including the new differential data for the target device belonging to the same system, the first verification value, the second verification value, and the specification data; a third verification value generating step of using the distribution package to generate a third verification value for verifying the integrity of the distribution package in the vehicle; and a distribution package sending step, sending the distribution package together with the third verification value to the vehicle-mounted device, The first verification value, the second verification value, and the third verification value are hash values obtained by applying a hash function to data. The new data and the old data are data of different versions. If the old data is updated to the new data in the target device, the data is updated to the new version of the data.

12. A storage medium storing a distribution package sending program, causing a central device that generates and sends a distribution package to an in-vehicle device to execute the following steps: A data acquisition step of acquiring new data and new differential data for updating old data to the new data, wherein: The new data is data of a target device to be updated among a plurality of electronic control devices mounted on the vehicle; a first verification value generating step of generating a first verification value for verifying integrity in the vehicle using the new data; a second verification value generating step of using the new differential data to generate a second verification value for verifying the integrity of the new differential data in the vehicle; a specification data generating step of generating specification data including target device association information, update data association information of the target device, and update processing information specifying an update processing of the vehicle, wherein the target device association information includes device types of the target devices belonging to the same system in a system composed of the plurality of electronic control devices; a distribution package generating step of generating a distribution package including the new differential data and the first and second verification values for the target devices belonging to the same system, and adding the specification data to the distribution package; a third verification value generating step of using the distribution package to generate a third verification value for verifying the integrity of the distribution package in the vehicle; and a distribution package sending step, sending the distribution package together with the third verification value to the vehicle-mounted device, The first verification value, the second verification value, and the third verification value are hash values obtained by applying a hash function to data. The new data and the old data are data of different versions. If the old data is updated to the new data in the target device, the data is updated to the new version of the data.

13. A central device comprising: The update data storage unit stores new data and new differential data used to update the old data to the new data, wherein: The new data is data of a target device to be updated among a plurality of electronic control devices mounted on the vehicle; a first verification value generating unit for generating a first verification value for verifying integrity in the vehicle using the new data; a second verification value generating unit for generating a second verification value for verifying the integrity of the new differential data in the vehicle using the new differential data; a distribution package generating unit that generates a distribution package including the new differential data for the plurality of target devices, the first verification value, and the second verification value, and distributes the distribution package to the vehicle; a third verification value generating unit configured to generate a third verification value for verifying the integrity of the distribution package in the vehicle using the distribution package; as well as a specification data generating unit configured to generate specification data including target device association information, update data association information of the target device, and update processing information specifying an update processing of the vehicle, wherein the target device association information includes device types of the target devices belonging to the same system in a system composed of the plurality of electronic control devices; The distribution package generating unit causes the distribution package to include the specification data. The first verification value, the second verification value, and the third verification value are hash values obtained by applying a hash function to data. The new data and the old data are data of different versions. If the old data is updated to the new data in the target device, the data is updated to the new version of the data.

14. A central device comprising: The update data storage unit stores new data and new differential data used to update the old data to the new data, wherein: The new data is data of a target device to be updated among a plurality of electronic control devices mounted on the vehicle; a first verification value generating unit for generating a first verification value for verifying integrity in the vehicle using the new data; a second verification value generating unit for generating a second verification value for verifying the integrity of the new differential data in the vehicle using the new differential data; a specification data generating unit configured to generate specification data including target device association information, update data association information of the target device, and update processing information specifying an update processing of the vehicle, wherein the target device association information includes device types of the target devices belonging to the same system as the plurality of electronic control devices; a third verification value generating unit for generating a third verification value for verifying the validity of the reprogrammed data and the specification data in the vehicle using a distribution package including the reprogrammed data and the specification data, wherein the reprogrammed data is a data set including the new differential data for the target device belonging to the same system, and the first verification value and the second verification value; and a sending unit, which sends the distribution package and the third verification value to the vehicle-mounted device, The first verification value, the second verification value, and the third verification value are hash values obtained by applying a hash function to data. The new data and the old data are data of different versions. If the old data is updated to the new data in the target device, the data is updated to the new version of the data.

Images