Vehicle information communication system

Abstract

The present application provides a vehicle information communication system, if the vehicle side system (4) receives the "ECU SW ID" of each ECU (19) from a plurality of ECUs (19), it sends a list combined with "Vehicle SW ID" to the center device (3). The center device (3) compares the list sent from the vehicle side system (4) with the corresponding vehicle's normal list stored in the structure information DB108, and if it is judged that the combination of the sent list is not normal, it sends an abnormal detection to the vehicle side system (4) and the management device (220).

Description

[0001] Cross-reference to related applications

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

[0003] This disclosure relates to a vehicle information communication system having a central device for managing data written to multiple electronic control devices mounted on a vehicle, and an on-board unit mounted on the vehicle. Background Technology

[0004] In recent years, with the diversification of vehicle control functions such as driver assistance and autonomous driving, the scale of applications for vehicle control and diagnostics using electronic control units (hereinafter referred to as ECUs) has increased. Furthermore, with version upgrades based on functional improvements, the opportunity to rewrite (reprogram) ECU applications has also increased. On the other hand, with the development of communication networks, vehicle-to-everything (V2X) technology has become widespread. Due to this situation, for example, Patent Document 1 discloses a technology that distributes ECU update programs from a central location to the vehicle's onboard unit via OTA (Over-The-Air) and rewrites the update programs on the vehicle side.

[0005] Patent Document 1: Japanese Patent Application Publication No. 2017-157004

[0006] In this case, if, for example, a portion of multiple ECUs on the vehicle side is replaced and its structural information, such as the application version, is updated, it may fail to function properly depending on the combination of its application version with that of the other ECUs. Summary of the Invention

[0007] This disclosure was made in view of the above circumstances, and its purpose is to provide a vehicle information communication system in which the central device can confirm the appropriateness of the combination of structural information of various electronic control devices mounted on the vehicle.

[0008] According to the vehicle information communication system disclosed herein, if an on-board unit receives structural information related to the structure of each electronic control device from multiple devices, it sends a list of structural information containing the multiple structural information items to a central unit. The central unit has a structural information storage unit that stores regular lists of structural information for each vehicle type. It compares the list of structural information received from the on-board unit with the list stored in the structural information storage unit. If it determines that the list of structural information received from the on-board unit is irregular, it sends abnormal content to the on-board unit. With this structure, the central unit can detect an anomaly caused by a combination of vehicle structural information where multiple electronic control devices cannot cooperate, thus hindering vehicle operation, and notify the on-board unit. Therefore, the on-board unit can take measures such as prohibiting the vehicle from driving. Attached Figure Description

[0009] While referring to the appendix Figure 1 The above-mentioned and other objects, features, and advantages of the present invention will become clearer from the following detailed description. The accompanying drawings are as follows.

[0010] Figure 1 This is a diagram showing the overall structure of the vehicle information communication system in the first embodiment.

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

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

[0013] Figure 4 This is a diagram showing the connection method of the power cord.

[0014] Figure 5 This is a diagram representing the way recompiled data and distribution specification data are packaged.

[0015] Figure 6 This is a diagram representing the way distribution packets are broken down.

[0016] Figure 7 It is a diagram that represents the main functions of the central device that involve the server in a block diagram format.

[0017] Figure 8 This is a schematic diagram illustrating the processing flow in the central device.

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

[0019] Figure 10 This is a diagram representing an example of the programs and data registered in the ECU reconfiguration data database.

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

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

[0022] Figure 13 This is a diagram representing an example of distribution packet data registered in the packet database.

[0023] Figure 14 This is a diagram representing an example of active data registered in the active database.

[0024] Figure 15 It is a flowchart representing the process of generating the program and data registered in the ECU reconfiguration data DB.

[0025] Figure 16 This is a flowchart illustrating a process for generating specification data registered in the ECU metadata DB.

[0026] Figure 17 This is a diagram representing an example of specification data.

[0027] Figure 18 This is a diagram representing an example of a bus load table.

[0028] Figure 19 This is a flowchart illustrating the process of generating distribution packages registered in the package database.

[0029] Figure 20 It is a diagram that schematically represents the contents of a package file.

[0030] Figure 21 This is a timing diagram showing the processing steps performed between the central device and the vehicle-side system in the second embodiment.

[0031] Figure 22 This is a flowchart representing the processing performed by the central device.

[0032] Figure 23 It is an illustrative representation. Figure 22 The flowchart shown illustrates the processing steps D6 and D7.

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

[0034] Figure 24 This is a timing diagram showing the processing steps performed between the central device and the vehicle-side system in the third embodiment.

[0035] Figure 25This is a flowchart representing the processing performed by the central device.

[0036] Figure 26 This is a timing diagram showing the status of the central device notifying the EV vehicle and the delivery vehicle respectively via SMS.

[0037] Figure 27 This is a timing diagram showing the processing steps performed between the central device and the vehicle-side system in the fourth embodiment.

[0038] Figure 28 This diagram schematically illustrates the processing performed between the supplier, the central device, and the vehicle-side system in the fifth embodiment.

[0039] Figure 29 This is a timing diagram (one of the three) showing the processing steps performed between the supplier, the central unit, and the vehicle-side system.

[0040] Figure 30 This is a timing diagram (Part Two) showing the processing steps performed between the supplier, the central unit, and the vehicle-side system.

[0041] Figure 31 This is a timing diagram (Part 3) showing the processing steps performed between the supplier, the central unit, and the vehicle-side system.

[0042] Figure 32 It is a variation of the first embodiment (one of them), and is a diagram showing the data format of the package DB when multiple packages correspond to one activity.

[0043] Figure 33 It is a diagram representing the data format of the activity database when multiple packages correspond to one activity.

[0044] Figure 34 This is equivalent to generating specification data for each group. Figure 16 The picture

[0045] Figure 35 This is equivalent to generating a distribution package for each group. Figure 19 The picture

[0046] Figure 36 This is a variation of the first embodiment (second one), and is a diagram showing the processing content of the package generation tool.

[0047] Figure 37 This is a diagram showing the overall structure of the sixth embodiment.

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

[0049] Figure 39 This is a diagram showing the electrical structure of a DCM.

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

[0051] Figure 41 This is a diagram showing the connection method of the power cord.

[0052] Figure 42 This is a diagram representing the way recompiled data and distribution specification data are packaged.

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

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

[0055] Figure 45 This is a diagram representing the distribution specification data.

[0056] Figure 46 This is a diagram representing the way distribution packets are broken down.

[0057] Figure 47 This is a diagram showing the typical operation of an embedded, single-sided independent memory.

[0058] Figure 48 This is a diagram showing the form of a rewrite operation in an embedded, single-sided independent memory.

[0059] Figure 49 This is a diagram showing the normal operation of a downloadable, single-sided independent memory.

[0060] Figure 50 This is a diagram illustrating the rewrite operation of a download-type single-sided independent memory.

[0061] Figure 51 This is a diagram showing the typical operation of an embedded 1-sided suspended memory.

[0062] Figure 52 This is a diagram representing the form of a rewrite operation when an embedded 1-sided suspended memory is suspended.

[0063] Figure 53 This is a diagram showing the normal operation of a download-type 1-sided suspended memory.

[0064] Figure 54 This is a diagram illustrating the form of a download-type 1-sided suspended memory rewrite operation.

[0065] Figure 55 This is a diagram showing the typical operation of an embedded two-sided memory.

[0066] Figure 56 This is a diagram illustrating the form of a rewrite operation in an embedded two-sided memory.

[0067] Figure 57 This is a diagram showing the normal operation of a downloadable two-sided memory.

[0068] Figure 58 This is a diagram illustrating the rewrite operation of a download-type two-sided memory.

[0069] Figure 59 It is a diagram representing the form of a rewritten application.

[0070] Figure 60 It is a diagram representing the form of a rewritten application.

[0071] Figure 61 It is a diagram representing the form of a rewritten application.

[0072] Figure 62 It is a timing diagram that represents the form of rewriting the application through power control.

[0073] Figure 63 It is a timing diagram that represents the form of rewriting the application through power control.

[0074] Figure 64 It is a timing diagram representing the form of rewriting the application through power self-holding.

[0075] Figure 65 It is a timing diagram representing the form of rewriting the application through power self-holding.

[0076] Figure 66 It is a diagram representing stages.

[0077] Figure 67 It is a picture representing the scene in its normal state.

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

[0079] Figure 69 This is an image representing the screen displayed when an event is announced.

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

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

[0082] Figure 72 This is an image showing the download process in progress.

[0083] Figure 73 This is an image showing the download process in progress.

[0084] Figure 74 This is an image showing the screen when the download is complete.

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

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

[0087] Figure 77 This is a screenshot showing the installation process.

[0088] Figure 78 This is a screenshot showing the installation process.

[0089] Figure 79 This is an image representing the screen displayed when activating consent.

[0090] Figure 80 This is an image showing the screen when an IG connection is established.

[0091] Figure 81 This is an image showing the screen when confirming the operation.

[0092] Figure 82 This is an image showing the screen when confirming the operation.

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

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

[0095] Figure 85 This is the functional block diagram of CGW.

[0096] Figure 86 This is the functional block diagram of CGW.

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

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

[0099] Figure 89 This is a functional block diagram of the packet distribution decision unit.

[0100] Figure 90 This is a flowchart representing the sending decision process for the distribution packet.

[0101] Figure 91 This is a functional block diagram of the download determination section for the distribution package.

[0102] Figure 92 This is a flowchart representing the download determination process for the distribution package.

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

[0104] Figure 94 This is a flowchart illustrating the data transmission decision process.

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

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

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

[0108] Figure 98 This is a flowchart indicating the instruction determination process for installation.

[0109] Figure 99 This is a diagram indicating the form of installation.

[0110] Figure 100 This is a diagram indicating the form of installation.

[0111] Figure 101 It is a graph representing the form of generating random numerical values.

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

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

[0114] Figure 104 It is a diagram representing the form in which secure access keys are generated.

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

[0116] Figure 106 It is a diagram showing the flow of processing associated with the verification of written data.

[0117] Figure 107 This is a functional block diagram of the data verification section.

[0118] Figure 108 This is a flowchart representing the verification process for writing data.

[0119] Figure 109 It is a diagram that represents the distributed form of the processing associated with the verification of written data.

[0120] Figure 110It is a diagram that represents the distributed form of the processing associated with the verification of written data.

[0121] Figure 111 It is a diagram that represents the distributed form of the processing associated with the verification of written data.

[0122] Figure 112 It is a diagram that represents the distributed form of the processing associated with the verification of written data.

[0123] Figure 113 It is a diagram representing the process of verifying written data and rewriting the application.

[0124] Figure 114 It is a diagram representing the process of verifying written data and rewriting the application.

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

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

[0127] Figure 117 This is a sequence diagram representing the form in which information is rewritten on both sides of a notification.

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

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

[0130] Figure 120 It is a diagram that represents the transition between start-up, stop-up, and hibernation states.

[0131] Figure 121 It is a diagram that represents the transition between start-up, stop-up, and hibernation states.

[0132] Figure 122 This is a diagram showing the connection method of the power cord.

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

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

[0135] Figure 125 It is a flowchart representing the file transfer control process.

[0136] Figure 126 It is a diagram representing the format of sending and receiving files.

[0137] Figure 127 It is a diagram representing the format of sending and receiving files.

[0138] Figure 128 It is a diagram representing the splitting and writing of files.

[0139] Figure 129 This is a diagram representing the form in which the CGW sends a transmission request to the DCM.

[0140] Figure 130 This is a diagram representing the form in which the CGW sends a transmission request to the DCM.

[0141] Figure 131 This is a diagram representing the format in which the CGW distributes write data to the ECU being rewritten.

[0142] Figure 132 This is a diagram representing the format in which the CGW distributes write data to the ECU being rewritten.

[0143] Figure 133 This is a diagram representing the format in which the CGW distributes write data to the ECU being rewritten.

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

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

[0146] Figure 136 This is a diagram representing the bus load table.

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

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

[0149] Figure 139 It is a diagram representing the form of distributing and writing data.

[0150] Figure 140 It is a diagram representing the form of distributing and writing data.

[0151] Figure 141 This is a diagram representing the distribution of written data to a vehicle while it is in motion.

[0152] Figure 142 This is a diagram representing the form of written data distributed during parking.

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

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

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

[0156] Figure 146 This is a flowchart indicating the processing of activation request instructions.

[0157] Figure 147 This is a diagram representing the form of an activation request.

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

[0159] Figure 149 This is a flowchart representing the rewrite process.

[0160] Figure 150 This is a flowchart representing the activated execution control process.

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

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

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

[0164] Figure 154 This is a diagram representing the grouping of objects to be rewritten.

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

[0166] Figure 156 This is a flowchart illustrating the process of determining the rollback method.

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

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

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

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

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

[0172] Figure 162This is a diagram representing the form of executing a rollback.

[0173] Figure 163 This is a diagram representing the form of executing a rollback.

[0174] Figure 164 This is a diagram representing the form of executing a rollback.

[0175] Figure 165 This is a diagram representing the form of executing a rollback.

[0176] Figure 166 This is a diagram representing the form of executing a rollback.

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

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

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

[0180] Figure 170 It is an image showing the progress of the rewriting process.

[0181] Figure 171 It is an image showing the progress of the rewriting process.

[0182] Figure 172 It is an image showing the progress of the rewriting process.

[0183] Figure 173 It is an image showing the progress of the rewriting process.

[0184] Figure 174 It is an image showing the progress of the rewriting process.

[0185] Figure 175 It is a graph that represents the changes shown in the progress chart.

[0186] Figure 176 It is a graph that represents the changes shown in the progress chart.

[0187] Figure 177 It is a graph that represents the changes shown in the progress chart.

[0188] Figure 178 It is a graph that represents the changes shown in the progress chart.

[0189] Figure 179 It is an image showing the progress of the rewriting process.

[0190] Figure 180 This is a functional block diagram of the integration and determination unit for differential data.

[0191] Figure 181 This is a flowchart representing the integration determination process for differential data.

[0192] Figure 182 It is a diagram representing the integration of differential data.

[0193] Figure 183 It is a diagram representing the integration of differential data.

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

[0195] Figure 185 It is a flowchart representing the typical action processing.

[0196] Figure 186 This is a flowchart representing the rewrite action processing.

[0197] Figure 187 This is a flowchart representing the information notification process.

[0198] Figure 188 This is a flowchart representing the verification process of the rewritten program.

[0199] Figure 189 It is a diagram representing the form of sending identification information and writing data.

[0200] Figure 190 It is a diagram representing the form of sending identification information and writing data.

[0201] Figure 191 This is a flowchart illustrating the installation instruction process.

[0202] Figure 192 This is a functional block diagram of the conversation initiation section.

[0203] Figure 193 It is a diagram representing the structure of the program.

[0204] Figure 194 It is a diagram representing state transitions.

[0205] Figure 195 It is a diagram representing state transitions.

[0206] Figure 196 It is a diagram representing state transitions.

[0207] Figure 197 This is a diagram representing the mediation of a conversation.

[0208] Figure 198 This is a diagram representing the mediation of a conversation.

[0209] Figure 199This is a flowchart representing the state transition management process for the first state.

[0210] Figure 200 This is a flowchart representing the state transition management process for the first state.

[0211] Figure 201 This is a flowchart representing the state transition management process for the first state.

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

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

[0214] Figure 204 It is a diagram representing the structure of the program.

[0215] Figure 205 It is a diagram representing state transitions.

[0216] Figure 206 This is a functional block diagram of the pilot test unit.

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

[0218] Figure 208 This is a flowchart representing the setting of processing flags.

[0219] Figure 209 This is a flowchart representing the determination and processing of processing flags.

[0220] Figure 210 This is a flowchart representing the determination and processing of processing flags.

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

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

[0223] Figure 213 This is a diagram representing the form of the transmission and reception progress status signal.

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

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

[0226] Figure 216 This is a flowchart showing the progress status.

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

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

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

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

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

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

[0233] Figure 223 This is a diagram representing the rewritten specification data.

[0234] Figure 224 This is an image showing the screen when selecting from the menu.

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

[0236] Figure 226 This is an image showing the screen during user registration.

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

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

[0239] Figure 229 This is a diagram representing a message frame.

[0240] Figure 230 This is an image representing the screen displayed when activating consent.

[0241] Figure 231 This is a diagram indicating whether an item is displayed or not.

[0242] Figure 232 This is a diagram indicating whether an item is displayed or not.

[0243] Figure 233 This is an image representing the screen displayed when activating consent.

[0244] Figure 234 It is a diagram representing the form of data communication.

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

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

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

[0248] Figure 238 This is a diagram representing the message frame when consent is activated.

[0249] Figure 239 It is a diagram that shows a change in the scene.

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

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

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

[0253] Figure 243 This is an image showing the download process in progress.

[0254] Figure 244 This is an image showing the screen when the download is complete.

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

[0256] Figure 246 This is an image representing the screen displayed when activating consent.

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

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

[0259] Figure 249 It is a diagram representing the report format of the indicator.

[0260] Figure 250 This is a diagram showing the change in report format when the object being rewritten is a two-sided memory.

[0261] Figure 251 This is a diagram showing the change in report format when the object being rewritten is suspended from memory.

[0262] Figure 252 This is a diagram showing the change in report format when the object being rewritten is a single-sided independent memory.

[0263] Figure 253 It is a diagram representing the connection form.

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

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

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

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

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

[0269] Figure 259 It is a sequence diagram representing the overall form of rewriting the application.

[0270] Figure 260 It is a sequence diagram representing the overall form of rewriting the application.

[0271] Figure 261 It is a sequence diagram representing the overall form of rewriting the application.

[0272] Figure 262 It is a sequence diagram representing the overall form of rewriting the application.

[0273] Figure 263 It is a sequence diagram representing the overall form of rewriting the application.

[0274] Figure 264 It is a sequence diagram representing the overall form of rewriting the application.

[0275] Figure 265 It is a sequence diagram representing the overall form of rewriting the application.

[0276] Figure 266 It is a sequence diagram representing the overall form of rewriting the application.

[0277] Figure 267 It is a sequence diagram representing the overall form of rewriting the application.

[0278] Figure 268 It is a sequence diagram representing the overall form of rewriting the application.

[0279] Figure 269 It is a sequence diagram representing the overall form of rewriting the application. Detailed Implementation

[0280] (First Implementation)

[0281] The following is for reference Figure 1 to Figure 20 The first embodiment of the present invention will be described. The vehicle program rewriting system is a system capable of rewriting vehicle control, diagnostic, and other applications installed on the vehicle's ECU via over-the-air (OTA) updates. For example... Figure 1 As shown, the vehicle program rewriting system 1 includes a central device 3 on the communication network 2 side, a vehicle-side system 4 on the vehicle side, and a display terminal 5. The communication network 2 is configured to include, for example, mobile communication networks based on 4G lines, the Internet, WiFi (Wireless Fidelity) (registered trademark), etc.

[0282] Display terminal 5 is a terminal that can accept user input and display various screens, such as a portable terminal 6 (e.g., a smartphone or tablet computer that the user can carry), or an in-vehicle display 7 (e.g., a display that also functions as a navigation system or instrument panel) installed in the vehicle interior. Portable terminal 6 can connect to communication network 2 as long as it is within the communication range of the mobile communication network. In-vehicle display 7 is connected to vehicle-side system 4.

[0283] If the user is outside the vehicle but within the communication range of the mobile communication network, they can use the portable terminal 6 to view various screens related to application rewriting while performing operation input, and can complete procedures related to application rewriting. The user can also use the in-vehicle display 7 inside the vehicle to view various screens related to application rewriting while performing operation input, and can complete procedures related to application rewriting. In other words, the user can use the portable terminal 6 and the in-vehicle display 7 separately, both outside and inside the vehicle, to perform procedures related to application rewriting.

[0284] The central device 3 integrates the OTA (Over-The-Air) functionality on the communication network 2 side of the vehicle program rewriting system 1, and functions as the OTA center. The central device 3 has a file server 8, a network server 9, and a management server 10, and each of the servers 8 to 10 is configured to communicate with each other.

[0285] File server 8 manages applications sent from central device 3 to vehicle-side system 4. It manages ECU programs and associated information provided by application providers (suppliers), distribution specification data from OEMs (Original Equipment Manufacturers), and vehicle status data obtained from vehicle-side system 4. File server 8 can communicate with vehicle-side system 4 via communication network 2. If a download request for a distribution package is generated, it sends a distribution package containing recompiled data and distribution specification data to vehicle-side system 4. Network server 9 manages network information and provides various screens related to application rewriting to portable terminal 6. Management server 10 manages the personal information of users registered in the application rewriting service and manages the application rewriting history for each vehicle.

[0286] The vehicle-side system 4 has a main unit 11. The main unit 11 has a DCM 12 and a CGW 13, which are connected via a first bus 14 to enable data communication. The DCM 12 is an on-board communication unit that communicates with the central unit 3 via the communication network 2. If a distribution package is downloaded from the file server 8, the DCM 12 extracts the write data from the distribution package and transmits it to the CGW 13.

[0287] CGW13 is a vehicle gateway device with data relay function. If write data is obtained from DCM12, it distributes the write data to the ECU targeted by the rewritten application. The main device 11, within the vehicle program rewriting system 1, encompasses the vehicle-side OTA functions and acts as the OTA host. Furthermore, in... Figure 1 The example shown illustrates a structure where the DCM12 and the vehicle display 7 are connected to the same first bus 14, but it could also be a structure where the DCM12 and the vehicle display 7 are connected to different buses.

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

[0289] The second bus 15 is, for example, the bus of the vehicle body system network. The ECUs 19 connected to the second bus 15 are, for example, door ECUs that control the locking / unlocking of doors, instrument panel ECUs that control the instrument display, air conditioning ECUs that control the air conditioning drive, and window ECUs that control the opening and closing of windows, etc., which control the vehicle body system. The third bus 16 is, for example, the bus of the driving system network. The ECUs 19 connected to the third bus 16 are, for example, engine ECUs that control the engine drive, brake ECUs that control the brake drive, ECT (Electronic Toll Collection System) ECUs that control the automatic transmission drive, and power steering ECUs that control the power steering drive, etc., which control the driving system.

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

[0291] The power management ECU20 is an ECU that has the function of power management for DCM12, CGW13, and various ECU19.

[0292] The sixth bus 21 connects to the CGW13 as an external bus. The DLC (DataLink Coupler) connector 22, detachably connected to the tool 23, connects to the sixth bus 21. The internal buses 14-18 and the external bus 21 are, for example, composed of a CAN (Controller Area Network) bus. The CGW13 communicates with the DCM12, various ECUs 19, and the tool 23 according to the CAN data communication standard and diagnostic communication standard (UDS: ISO14229). Alternatively, the DCM12 and CGW13 can also be connected via Ethernet, as can the DLC connector 22 and CGW13 via Ethernet.

[0293] If the target ECU 19 receives write data from CGW 13, it writes the write data to flash memory to rewrite the application. In the above structure, CGW 13 functions as a reprogramming master, distributing write data to the target ECU 19 if it receives a write data acquisition request from the target ECU 19. The target ECU 19 functions as a reprogramming slave, writing the write data to flash memory to rewrite the application if it receives write data from CGW 13.

[0294] As for the rewriting application, there are wired rewriting and wireless rewriting methods. In the wired rewriting application method, tool 23 is connected to DLC connector 22, and tool 23 transmits write data to CGW13. CGW13 relays or distributes the write data transmitted from tool 23 to the rewritten object ECU19. In the wireless rewriting application method, as described above, if DCM12 downloads a distribution package from file server 8, it extracts the write data from the distribution package and transmits the write data to CGW13.

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

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

[0297] like Figure 3As shown, the ECU19, as an electrical function module, includes a microcomputer 28, a data transmission circuit 29, a power supply circuit 30, and a power detection circuit 31. 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-transferable physical storage medium to perform various processes and control the operation of the ECU19.

[0298] Data transmission circuit 29 controls data communication with buses 15-17 according to the CAN data communication standard. Power supply circuit 30 inputs +B power, ACC power, and IG power. Power detection circuit 31 detects the voltage values ​​of +B power, ACC power, and IG power input from power supply circuit 30, compares these detected voltage values ​​with specified voltage thresholds, and outputs the comparison result to microcomputer 28. Microcomputer 28 determines whether the +B power, ACC power, and IG power supplied to ECU 19 from the outside is normal or abnormal based on the comparison result input from power detection circuit 27. Furthermore, although the loads connected to ECU 19, such as sensors and actuators, are different, their basic structures are essentially the same. Additionally, the basic structures of DCM 12, vehicle display 7, and power management ECU are also similar. Figure 3 The ECU19 shown is the same.

[0299] like Figure 4 As shown, power management ECU 20, CGW13, and ECU 19 are connected to +B power line 32, ACC power line 33, and IG power line 34. +B power line 32 is connected to the positive terminal of the vehicle battery 35. ACC power line 33 is connected to the positive terminal of the vehicle battery 35 via ACC switch 36. When the user performs ACC operation, ACC switch 36 switches from off to on, and the output voltage of the vehicle battery 35 is applied to ACC power line 33. ACC operation, for example, in a vehicle that uses a key to insert a ignition key, involves inserting the key and turning it from the "OFF" position to the "ACC" position; in a vehicle that uses a start button, it involves pressing the start button once.

[0300] 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. An IG operation, for example, in a vehicle that uses a key to insert a ignition key, involves inserting the key and turning it from the "OFF" position to the "ON" position; in a vehicle that uses a start button, it involves pressing the start button twice. The negative terminal of the vehicle battery 35 is grounded.

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

[0302] The activation conditions of ECU19 vary depending on the power supply status, and are categorized as +B system ECUs activated under +B power supply, ACC system ECUs activated under ACC power supply, and IG system ECUs activated under IG power supply. For example, ECU19 driven in applications such as vehicle theft is a +B system ECU. For example, ECU19 driven in non-driving system applications such as audio systems is an ACC system ECU. For example, ECU19 driven in driving system applications such as engine control is an IG system ECU.

[0303] CGW13 sends a start request to an ECU 19 that is in a sleep state, thereby causing the ECU 19 destined for the start request to transition from a sleep state to a start state. Conversely, CGW13 sends a sleep request to an ECU 19 that is in a start state, thereby causing the ECU 19 destined for the sleep request to transition from a start state to a sleep state. CGW13 can select the ECU 19 destined for the start request or sleep request from among multiple ECUs, for example, by making the waveforms of the transmission signals sent to buses 15-17 different.

[0304] The power control circuit 38 is connected in parallel with the ACC switch 36 and the IG switch 37. The CGW13 sends a power control request to the power management ECU 20, causing the power management ECU 20 to control the power control circuit 38. Specifically, the CGW13 sends a power-on request as a power control request to the power management ECU 20, connecting the ACC power line 33 and the IG power line 34 to the positive terminal of the vehicle battery 35 within the power control circuit 38. In this state, even if the ACC switch 36 and the IG switch 37 are open, ACC power and IG power are still supplied to the vehicle-side system 4. The CGW13 sends a power-off request as a power control request to the power management ECU 20, isolating the ACC power line 33 and the IG power line 34 from the positive terminal of the vehicle battery 35 within the power control circuit 38.

[0305] DCM12, CGW13, and ECU19 have a power self-holding function. That is, if the vehicle power supply switches from ACC or IG power to +B power while the vehicle is in the starting state, DCM12, CGW13, and ECU19 do not immediately transition from the starting state to a sleep or stop state after the switch. Instead, they maintain the driving power supply by remaining in the starting state for a specified time after the switch. After a specified time (e.g., a few seconds) has elapsed following the vehicle power switch from ACC or IG power to +B power, DCM12, CGW13, and ECU19 transition from the starting state to a sleep or stop state.

[0306] Next, refer to Figures 5 to 6 The distribution package sent from the central device 3 to the main device 11 is described. In the vehicle program rewriting system 1, recompiled data is generated based on write data provided by the application provider (i.e., the supplier) and rewrite specification data primarily provided by the OEM. The write data provided by the supplier includes differential data, which is equivalent to the difference between the old and new applications, and overall data, which is equivalent to the entire new application. Both the differential data and the overall data can be compressed using known data compression techniques. Figure 5 The example illustrates the use of differential data from suppliers A through C as write data. Recompiled data is generated based on encrypted differential data and authentication codes from ECU (ID1) provided by supplier A, ECU (ID2) provided by supplier B, ECU (ID3) provided by supplier C, and rewritten specification data provided by the OEM. An authentication code is assigned to each write data item.

[0307] In addition, Figure 5 The data in the rewrite data represents the differential data used when updating from an old application to a new application. However, it can also be configured to include rollback differential data used for writing back from the new application to the old application within the rewrite data. For example, if the object being rewritten, ECU19, is a single-sided memory, rollback differential data can be included in the rewrite data.

[0308] The rewrite specification data provided by the OEM, as information associated with the application rewrite, includes information that can identify the ECU19 to be rewritten, information that can determine the rewrite order when there are multiple ECUs19 to be rewritten, and information that can determine the rollback method described later. It defines the action data associated with the rewrite in DCM12, CGW13, and the ECU19 to be rewritten. The rewrite specification data is divided into DCM-specific rewrite specification data used by DCM12 and CGW-specific rewrite specification data used by CGW13. The DCM-specific rewrite specification data contains information required to read the file corresponding to the ECU19 to be rewritten. As described above, the CGW-specific rewrite specification data contains information required to control the rewrite of the ECU19 to be rewritten.

[0309] If DCM12 obtains the rewrite specification data used by DCM, it parses the rewrite specification data used by DCM and controls the transmission of write data to CGW13 and other rewrite-related actions based on the parsing result. If CGW13 obtains the rewrite specification data used by CGW, it parses the rewrite specification data used by CGW and controls the acquisition of write data from DCM12, the distribution of write data to the rewrite target ECU19, and other rewrite-related actions based on the parsing result.

[0310] The aforementioned re-edited data is registered in file server 8, as well as the distribution specification data provided by the OEM. The distribution specification data provided by the OEM defines the actions associated with the display of various screens in display terminal 5.

[0311] If file server 8 has registered recompiled data and distribution specification data, it encrypts the recompiled data and generates a distribution package that combines the packet authentication token used for the authentication package, the encrypted recompiled data, and the distribution specification data into a single file. If file server 8 receives a download request for the distribution package from an external source, it sends the distribution package to DCM12. Additionally, in Figure 5 The example illustrates a scenario where file server 8 generates a distribution packet containing recompiled data and distribution specification data, and sends both data to DCM 12 simultaneously. However, it can also send the recompiled data and distribution specification data to DCM 12 separately. That is, file server 8 can send the distribution specification data to DCM 12 first, and then send the recompiled data to DCM 12. Alternatively, file server 8 can combine the recompiled data and distribution specification data into a single distribution packet containing a file, and send the distribution packet and packet authentication code to DCM 12.

[0312] If DCM12 downloads a distribution package from file server 8, it verifies the packet authentication code and encrypted reprogrammed data stored in the distribution package. If the verification result is positive, it decodes the encrypted reprogrammed data. If DCM12 decodes the encrypted reprogrammed data, it unpacks the decoded reprogrammed data and generates encrypted differential data and authentication codes for each ECU, reprogrammed specification data for DCM, and reprogrammed specification data for CGW. Figure 6 The example illustrates the generation of encrypted differential data and authentication tokens for ECU (ID1), ECU (ID2), ECU (ID3), and the rewriting of specification data.

[0313] Figure 7 The main functional components of the central device 3 involving servers 8-10 are represented by block diagrams. Additionally, Figure 8 This section provides a summary of the processing performed by the central unit 3 regarding ECU program updates. Additionally, "database" will sometimes be referred to as "DB" below. Figure 7 As shown, the central device 3 includes a package management unit 3A, a structural 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, ECU reconfiguration data DB 204, ECU metadata DB 205, and a package DB 206. The structural information management unit 3B includes a structural information registration unit 207 and a structural information DB 208.

[0314] The supplier uses the user interface (UI) functions of the management server 10, namely the input unit 218 and the display unit 219, to register individual data for the ECU. This individual ECU data includes program files such as new programs and differential data, program file verification data, size, encryption methods, and other program file association information, as well as data related to ECU attribute information such as the memory structure of the ECU 19. The program files are stored in the ECU reconfiguration data DB204. ECU attribute information is stored in the ECU metadata DB205. Program file association information can also be stored in either the ECU reconfiguration data DB204 or the ECU metadata DB205. The ECU reconfiguration data DB204 is an example of an update data storage unit. Furthermore, the ECU metadata DB205 is an example of a device association information storage unit.

[0315] The OEM registers formal structural information in the structural information DB208 for each vehicle model via the structural information registration department 207. Formal structural information refers to vehicle structural information approved by a public authority. 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 for the system structure consisting of multiple ECUs 19, and identification information for the vehicle structure consisting of multiple systems. Additionally, as structural information, vehicle constraint information related to program updates can also be registered. For example, it can also register ECU group information recorded in the rewrite specification data, bus load tables, and information related to battery load. The ECU metadata DB205 is an example of a device-related information storage unit. Furthermore, the structural information DB208 is an example of a vehicle information storage unit.

[0316] Specification data generation unit 201 generates rewritten specification data by referring to each database. Package generation unit 202 generates a distribution package containing the rewritten specification data and recompiled data, and registers it in package database 206. Package generation unit 202 can also generate a distribution package containing distribution specification data. Package distribution unit 203 distributes the registered distribution package to vehicle-side system 4. The distribution package is equivalent to a file.

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

[0318] The Activity Management Department 3D comprises an Activity Generation Department 214, an Activity Distribution Department 215, an Instruction and Notification Department 216, and an Activity Database 217. The OEM generates activity information related to program updates, i.e., activity information, through the Activity Generation Department 214, and registers it in the Activity Database 217. Furthermore, this activity information is equivalent to the aforementioned "distribution specification data," primarily information related to the update content displayed in the vehicle-side system 4. The Activity Distribution Department 215 distributes the activity information to the vehicle. The Instruction and Notification Department 216 notifies the vehicle of the necessary instructions related to the program update. In the vehicle-side system 4, for example, a user determines whether to download the update program based on the activity information sent from the central device 3, and downloads it if necessary.

[0319] In addition, the functions of each management department (3A-3D), apart from the databases, are implemented through computer hardware and software.

[0320] The vehicle communication unit 222 is a functional module used for wireless data communication between the central device 3 and the vehicle-side system 4.

[0321] The following section explains the above processing in more detail. First, it describes the content of the data registered in each database. For example... Figure 9 As shown, in the structure information DB208, the following data is registered as an example. "Vehicle Model" indicates the vehicle model. "Vehicle SW ID" is a software ID specific to the entire vehicle, equivalent to a vehicle software ID. Only one "Vehicle SW ID" is assigned to each vehicle, and the "Vehicle SW ID" is updated whenever the application version of any one or more ECUs is updated. If the group of multiple ECUs 19 installed in each vehicle is designated as a "system," then "Sys ID" is the ID of that system.

[0322] For example, in Figure 1 In this diagram, the group containing the body system ECU19 is the body system, and the group containing the driving system ECU19 is the driving system. When the application version of any one or more ECUs constituting the system is updated, the "Sys ID" is updated. The "ECUID" is a device identification ID representing the type of each ECU. The "ECU SW ID" is a software ID specific to each ECU, equivalent to the ECU software ID. Here, for convenience, the software version is appended to the "ECU ID". When the application version of that ECU is updated, the "ECU SW ID" is updated. Furthermore, even if the same "ECU ID" represents the same program version, different "ECU SW IDs" are used depending on the hardware architecture. That is, the "ECU SW ID" also represents the ECU's product number.

[0323] exist Figure 9 The section represents structural information related to the vehicle with "Vehicle Model" = "aaa". Examples include the Autopilot ECU (ADS), Engine ECU (ENG), Brake ECU (BRK), and Electric Power Steering ECU (EPS) installed in the vehicle's ECU19.

[0324] For example, compared to "Vehicle SW ID" = "0001" with "ECU SW ID" as "ads_001", "eng_010", "brk_001", "eps_010", and "Vehicle SW ID" = "0002" with "ECU SW ID" as "ads_002", "eng_010", "brk_005", "eps_011", three software versions have been updated. Along with this, "Sys ID" = "SA01" was updated to "SA02", and "Sys ID" = "SA02" was updated to "SA03". Thus, in the structural information DB208, initial values ​​are registered at the time of vehicle production or sale, and then updated as the application versions of any one or more ECUs are updated. In other words, the structural information DB208 represents the structural information that is officially available in the market for each vehicle model.

[0325] like Figure 10 As shown, in ECU reconfiguration data DB204, the following procedures and data are registered as an example. Figure 10 In this context, examples of ECUs 19 whose applications are updated, which are installed in a specific vehicle model, include the Autopilot ECU (ADS), Brake ECU (BRK), and Electric Power Steering ECU (EPS). For the latest "ECUSW ID" of these updated ECUs 19, the following are registered: the old and new program files of the ECU, the integrity verification data of the new program, the difference between the new and old programs (i.e., the update data file), the integrity verification data of the update data, the rollback data file (also serving as the difference data), and the integrity verification data of the rollback data. The integrity verification data is a hash value obtained by applying a hash function to the data value. Furthermore, when the updated data is replaced with the difference data and set as the overall data of the new program, the integrity verification data of the updated data is equal to the same data in the new program.

[0326] In addition, Figure 10The text indicates the data structure for the latest "ECU SW ID," but it can also be configured such that, while retaining data for the older "ECU SW ID," a new program file for the older "ECU SW ID" is referenced. Furthermore, the integrity verification data can be in the form of registered values ​​calculated by the supplier, or it can be calculated and registered by the central device 3.

[0327] like Figure 11 As shown, in the ECU metadata DB205, as an example, the following individual ECU specification data is registered. Regarding the latest "ECU SW ID," the updated data file size and the rollback data file size are used. In the case of the ECU19's flash memory 28d having a structure with two or more sides, information such as which side (A, B, C, etc.) is used for the program, the transfer size, and the address used to read the program file are used. These are examples of updated data association information.

[0328] In addition, attribute information representing the properties of ECU19 is registered in ECU metadata DB205. Attribute information refers to information representing hardware and software attributes related to the ECU. "Transfer Size" is the transfer size when the rewritten data is segmented from CGW13 and transferred to ECU19, and "Key" is the key used by CGW13 to securely access ECU19. These are examples of software attribute information. Furthermore, regarding "Vehicle Model" and "ECU ID," information includes the memory structure of the ECU19's 28d flash memory, the type of bus connected to ECU19, and the type of power supply connected to ECU19. These are examples of hardware attribute information.

[0329] Here, the memory structure "1-sided" refers to a single-sided independent memory with a flash memory side, "2-sided" refers to a two-sided memory with flash memory sides, and "suspended" refers to a single-sided suspended memory with pseudo-two flash memory sides. Hardware attribute information and software attribute information are used in the vehicle-side system 4 for rewriting control of each ECU 19. Hardware attribute information can also be pre-stored by the CGW 13; in this embodiment, to reduce the management load in the vehicle-side system 4, it is managed by the central device 3. Additionally, software attribute information is data that directly specifies the rewriting actions of each ECU 19. To achieve flexible control in the vehicle-side system 4, it is managed by the central device 3.

[0330] like Figure 12As shown, in the vehicle information DB213, as an example, the data for each vehicle shown below is registered. This mainly registers the structural information of each vehicle and the vehicle's status information for program updates. Specifically, the ID of each vehicle, i.e., "VIN," is structural information such as "Vehicle SW ID," "Sys ID," "ECU ID," and "ECU SW ID." The hash value of this structural information, i.e., the "Digest" value, is also calculated and stored by the central device 3. In the case of a two-sided memory structure, the "application side" is where the program currently used by ECU19 is written, and the uploaded values ​​are registered together with the structural information.

[0331] The "Access Log" records the date and time when the vehicle uploaded its information to the central device 3. The "Reconfiguration Status" indicates the reconfiguration status within the vehicle, such as "Activity Release Completed," "Activation Completed," or "Download Completed." This status indicates the stage at which the reconfiguration process within the vehicle has progressed and where it has stalled. Additionally, when uploading structural information from the vehicle-side system 4 to the central device 3, each vehicle is assigned a "VIN" to this information.

[0332] like Figure 13 As shown, package DB206 registers the distribution package ID, distribution package file, and data used for distribution package integrity verification.

[0333] like Figure 14 As shown, the following data is registered in activity DB217: Activity information ID, distribution package ID, text statements representing the specific update content, a list of vehicle IDs (VINs) of the vehicles targeted by the activity, lists of "Vehicle SW IDs" before and after the update, and lists of "ECU SW IDs" before and after the update. The "Target VIN" list allows for comparison and registration between individual vehicle information DB213 and activity DB217. Additionally, this activity information can also be registered in package DB206.

[0334] Next, the function of this embodiment will be explained. Figure 15 The section explains the registration process for ECU reconfiguration data DB204 in Package Management Department 3A. For example... Figure 15As shown, the display unit 219 and the input unit 218 activate the screen for registering reconfiguration data of the management server 10, and accept the input of the old and new program files of the ECU 19 from the supplier's operator (A1). For example, a UI or similar interface can be used to register files with structure information marked in CSV format, etc. Next, the package management unit 3A generates integrity verification data for the new program (A2), and generates differential data files for updating from the old program to the new program, as differential data for updating (A3, A4), and integrity verification data for the differential data for updating (A3, A4).

[0335] Next, as differential data for rollback, differential data files are generated when updating from the old program to the new program, along with integrity verification data for this data (A5, A6). These program files and verification data are registered in the ECU reconfiguration data DB204, and a new "ECU SW ID" is generated based on an old "ECU SW ID" and registered (A7). Here, if the overall data is distributed instead of differential data, the steps related to differential data can be omitted.

[0336] Integrity verification data can be, for example, a hash value generated by applying a hash function. For instance, when using SHA-256 (Secure Hash Algorithm 256-bit) as the hash function, the data value is divided into message blocks of 64 bytes each. Furthermore, if applying the initial message block's data value to the initial hash value results in a 32-byte hash value, this process is repeated sequentially, applying the next message block's data value to that hash value, also resulting in a 32-byte hash value.

[0337] exist Figure 16 The generation process of rewritten specification data in specification data generation unit 201 will be explained here. Here, the generation process of rewritten specification data for vehicles with "Vehicle Model" = "aaa" will be explained, but the same applies to other vehicles.

[0338] The central device 3 initiates the specification data generation program of the specification data generation unit 201, and accepts input from the operator of the OEM via the display unit 219 and the input unit 218. First, the specification data generation unit 201 determines the ECU 19 that is to be updated. For example... Figure 16As shown, the specification data generation unit 201 accesses the ECU reconfiguration data DB204 and outputs a display screen to the display unit 219, allowing selection of the data from the registered "ECU SW IDs" that will be updated. 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 refers to the rewriting order of the ECUs 19 in the vehicle-side system 4. The specification data generation unit 201 uses the order specified by the OEM operator as the defined ECU order.

[0339] Additionally, the specification data generation unit 201 can also access the structural information DB208, rejecting input from the OEM operator, and determining which ECU1 is the target for updating. The specification data generation unit 201 refers to the "ECU SW ID" relative to the latest "Vehicle SWID" and the "ECU SW ID" relative to an older "Vehicle SW ID" to extract the ECU19 that is eligible for updating. For example, in... Figure 9 In the diagram, "ADS", "BRK", and "EPS" are the updated target ECU19. The specification data generation unit 201 uses the order registered in the structural information DB208 as the determined ECU order.

[0340] Furthermore, the specification data generation unit 201 generates group information (B2) for ECUs with multiple "ECU SW IDs" that are to be updated. Here, referring to the structure information DB208, "Sys ID" is used; for example, group 1 is summarized into "ECU IDs" with "Sys ID" as "SA01_02", and group 2 is summarized into "ECU IDs" with "Sys ID" as "SA02_02". For example, in Figure 9 In this process, group 1 is set to "ADS", and group 2 is set with the first ECU as "BRK" and the second ECU as "EPS". In this way, the specification data generation unit 201 determines the ECU to be updated, the group to which the ECU belongs, and the order of the ECUs in the group.

[0341] Next, the specification data generation unit 201 accesses the ECU metadata DB205 to obtain update data association information, hardware attribute information, and software attribute information (B3) as specification data related to the ECU19 to be updated. For example, Figure 17As shown, the update data association information includes "Updater Version," "Updater Acquisition Address," "Updater Size," "Rollback Version," "Rollback Acquisition Address," "Rollback Size," "Data Type to be Written," and "Write Surface." Hardware attribute information includes "Connection Bus," "Connection Power Supply," and "Memory Type." Software attribute information includes "Rewrite Surface Information," "Security Access Key Information," "Rewrite Method," and "Transfer Size." "Rewrite Method" indicates whether the rewrite is performed by activating the power self-holding circuit (power self-holding) or based on whether the rewrite is performed based on IG on / off (power control). "Security Access Key Information" may also include information other than the key.

[0342] The following is an explanation of each piece of information.

[0343] • "Write Data Type" indicates whether the program uses differential or global data. It can also separately record the write data types for update programs and the write data types for rollback programs.

[0344] • "Write Side" indicates which side of the program is written to for the ECU19, which is a two-sided memory.

[0345] • “Connection Bus” is information that identifies the bus connected to ECU19.

[0346] • "Power Connection" indicates the power status of the ECU19, and records the value of any one of the following: battery power (+B power), auxiliary power (ACC power), and ignition power (IG power).

[0347] • "Memory type" is information that identifies the memory structure of ECU19, and records values ​​indicating 2-sided memory, 1-sided suspended memory (simulating 2-sided memory), and 1-sided memory, etc.

[0348] • "Rewrite face information" indicates which face of ECU19 is the start face (operation face) and which face is the rewrite face (non-operation face).

[0349] • "Secure Access Key Information" is information used to authenticate access to ECU19 using a key, including information on the key derived from the key, the key mode, and the decoding operation mode.

[0350] • "Transfer size" is the data size when the program is divided and transferred to ECU19.

[0351] For example, Figure 17As shown, the "ECU ID" is used as the key, and this information is stored in the form of the determined ECU order mentioned above. If the specification data generation unit 201 acquires information for all ECUs (B4; "Yes"), then for the vehicle that is the object of the update, it specifies "rewrite environment information" (B5). "Rewrite environment information" refers to information used for rewrite control in the vehicle-side system 4 that targets the ECU group or the entire vehicle, and is data that directly specifies the rewrite action. For example, as rewrite environment information targeting the entire vehicle, it includes "vehicle status" indicating whether the program update in the vehicle-side system 4 is performed while the vehicle is in motion (IG switch is on) or while parked (IG switch is off), "battery load (battery balance)" indicating the battery balance constraint that allows the program update to be performed in the vehicle-side system 4, and bus load table information indicating the bus load constraint that allows the written data to be transmitted in the vehicle-side system 4, etc.

[0352] Furthermore, the rewrite environment information, which is group-based, includes the ECUs 19 belonging to that group and the ECU order within the group. In the vehicle-side system 4, the control synchronizes program updates on a group-by-group basis, performing the writing of ECUs 19 in the specified ECU order. The specification data generation unit 201 activates the screen for registering rewrite environment information, accepting input from the OEM operator. Alternatively, it can be in the form of an Excel spreadsheet (registered trademark) containing the rewrite environment information. Alternatively, it can be in the form of extracting the constraint information registered in the structure information DB208. In addition, the specification data generation unit 201 uses the generation result of step B2 above as the group-based rewrite environment information.

[0353] A bus load table is a table that shows the correspondence between power states and the allowable transmission amounts on the bus. For example... Figure 18 As shown, the transmission allowance is the sum of the amount of vehicle control data and write data that can be transmitted relative to the maximum transmission allowance. In this example, for the first bus, the transmission allowance is "80%" of the maximum transmission allowance. Therefore, in the IG power state, the CGW13 allows the transmission allowance of vehicle control data to be "50%" of the maximum transmission allowance, and the transmission allowance of write data to be "30%" of the maximum transmission allowance. Furthermore, in the ACC power state, the CGW13 allows the transmission allowance of vehicle control data to be "30%" of the maximum transmission allowance, and the transmission allowance of write data to be "50%" of the maximum transmission allowance. Additionally, in the +B power state, the CGW13 allows the transmission allowance of vehicle control data to be "20%" of the maximum transmission allowance, and the transmission allowance of write data to be "60%" of the maximum transmission allowance. The same applies to the second and third buses.

[0354] Finally, the specification data generation unit 201 configures the generated or acquired data according to the predetermined data structure to generate the specification data. Figure 17 The rewritten specification data (B6) is shown. That is, the specification data generation unit 201 generates the rewritten specification data using data that the vehicle-side system 4 can interpret. Furthermore, information for each ECU can be recorded in the rewritten specification data in ascending order of the group and in the order of the ECUs within the group. For example, in... Figure 9 In the case where Group 1 is set to "ADS" and Group 2 is set with "BRK" as the first and "EPS" as the second, the ECU information column of the specification data initially displays the ECU information of "ADS", then the ECU information of "BRK" is arranged, and finally the ECU information of "EPS" is arranged.

[0355] exist Figure 17 In the specification data shown, the "ECU ID" to "Transfer Size" fields for the ECU information are examples of object device association information that includes the type of the object ECU19, corresponding to the aforementioned hardware and software attribute information. Additionally, "Update Program Version" to "Write Surface" are examples of update data association information. Furthermore, "Rewrite Environment," which applies to either the ECU group or the entire vehicle, is an example of update processing information specifying the update process within the vehicle.

[0356] exist Figure 19 The packet generation process in packet generation unit 202 will be explained here. Similarly, the packet generation process for vehicles with "Vehicle Model" = "aaa" will be explained here. Figure 19 As shown, triggered by the operator's instruction, the central device 3 activates the package generation unit 202 of the package management unit 3A. The package generation unit 202, similar to step B1, determines the "ECU SW ID" (C1) that is to be updated. The package generation unit 202 retrieves the data corresponding to the "ECU SW ID" that is to be updated from the ECU reconfiguration data DB204 and generates reconfiguration data (C2). For example, in... Figure 10 In this process, the package generation unit 201 acquires integrity verification data for the new program, update data as differential data, integrity verification data for the update data, integrity verification data for the old program, rollback data as differential data, and integrity verification data for the rollback data, and generates recompiled data. Furthermore, the generated recompiled data is merged with the corresponding rewrite specification data described in steps B1 to B6 to generate a distribution package file (C3). Next, integrity verification data (C4) for the generated package file is generated and registered in package DB206 (C5) along with the package file.

[0357] Figure 20This illustration shows the contents of the package file generated as described above. It illustrates how, according to the ECU sequence, the update data and integrity verification data corresponding to the "ADS," "BRK," and "EPS" targets being updated are merged into a single recompiled data file, and then combined with the rewritten specification data to generate a single distribution package file. Here, rollback data can also be included in the recompiled data only if the memory structure of the ECU19 target being updated is on a single side. If the memory structure is on a two-side or suspended side, since no rewriting is performed on the application side, the rollback data as the old program can be omitted.

[0358] As described above, according to this embodiment, the ECU reconfiguration data DB204 of the central device 3 stores update program data for the ECUs 19 that are the objects of the update applications among the multiple ECUs 19 installed in the vehicle. The structure information DB208 stores vehicle-related information, such as the "ECU ID" corresponding to each of the multiple ECUs 19 installed in the vehicle and the "ECU SW ID" of the application stored in the ECU 19, along with the vehicle type. The ECU metadata DB205 stores the attributes of the ECUs 19 to be modified and update data association information associated with the update data.

[0359] Furthermore, the specification data generation unit 201 generates specification data that is sent to the vehicle along with the updated data written to the target ECU 19, based on information stored in the structure information DB 208 and ECU metadata DB 205. This specification data includes information about the type and attributes of the target ECU 19, update data association information, and information indicating the rewriting environment related to the data update. The package generation unit 202 generates a distribution package containing the specification data and recompiled data and registers it in the package DB 206. 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 and appropriately control the write process using the update data.

[0360] Furthermore, the specification data generation unit 201 generates specification data for multiple ECUs 19 into a single file, and the package generation unit 202 packages the recompiled data for multiple ECUs 19 together into a single file. Therefore, if the vehicle-side system 4 receives a distribution package, it can write updated data to multiple ECUs 19.

[0361] Furthermore, the vehicle association information, which serves as specification data, includes group information that groups a subset of multiple ECUs 19. Therefore, the vehicle-side system 4 can select the target ECUs 19 according to the order specified by the group information and write update data. For example, if multiple ECUs 19 are targeted for a certain function improvement, group 1 can be designated as the body system ECUs 19, group 2 as the driving system ECUs 19, and group 3 as the MM system ECUs 19. This allows the program update in the vehicle-side system 4 to be performed in three separate steps. Therefore, compared to performing program updates on all ECUs at once, the user's waiting time for each update can be reduced.

[0362] Furthermore, the rewrite environment information includes vehicle-related "vehicle status (IG on status)" and "battery load," as well as a "bus load table" related to ECU19. Therefore, the vehicle-side system 4 can determine the timing of writing update data based on this information. In other words, by specifying execution constraints for the vehicle as the rewrite environment information, the OEM or service provider of the central device 3 can use flexible procedures for updates.

[0363] Furthermore, the specification data generation unit 201 generates specification data sequentially based on information related to the ECU 19 with the earliest pre-set rewrite order, according to a predetermined data structure. Therefore, the vehicle-side system 4 can write update data according to the configuration order of the ECU IDs in the specification data. That is, ECUs 19 with mutually cooperating processes are grouped together, and the ECU order is determined considering the content of these cooperative processes. Thus, even if the timing of updating the new program is not fully synchronized, the program update can be completed without adverse effects in the vehicle-side system 4. For example, if the new program for ECU (ID1) has a process for sending a specified message to ECU (ID2), and the new program for ECU (ID2) has a process for timeout errors if the specified message sent from ECU (ID1) cannot be received, the ECU order can be determined by updating ECU (ID1) first, and then updating ECU (ID2).

[0364] (Second Implementation)

[0365] like Figure 21 As shown, the second embodiment relates to... Figure 8The vehicle-side system 4 initially sends a "vehicle structure information synchronization" request to the central unit 3. If the vehicle-side IG switch 37 is turned on, CGW13 sends a "synchronization start request" to DCM12. DCM12 accepts the "synchronization start request" and replies with a "structure information collection request" to CGW13. CGW13 then queries the program version of each ECU 19. Each ECU 19 replies with its "ECU SW ID" to CGW13. In addition, ECUs with a two-sided or suspended memory structure also reply to CGW13 with information indicating which of the multiple sides is active and which is not. Furthermore, each ECU 19 may also send calibration information of actuators, etc., which are controlled objects, permission information for receiving program update services, and fault codes generated in the ECU 19 to CGW13.

[0366] If CGW13 has finished receiving the "ECU SW IDs" from each ECU19, it sends them all along with the "VIN" to DCM12. At this time, the "Vehicle SW ID" and "Sys ID" managed by CGW13 can also be sent to DCM12. DCM12 accepts them and, for example, uses a hash function to generate a hash value as a digest value, targeting all "ECU SW IDs". As described above, when using SHA-256 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 initial hash value is applied to the data value of the first message block, resulting in a 32-byte hash value. This hash value is then applied sequentially to the data values ​​of subsequent message blocks, ultimately yielding a 32-byte hash value. Here, DCM12 can generate a hash value not only targeting all "ECU SW IDs" but also targeting values ​​containing "Vehicle SW ID", "Sys ID", surface information, and calibration information.

[0367] The DCM12 sends the summary value of the "ECU SW ID" obtained as described above, along with the "VIN," to the central device 3. Alternatively, the DCM12 may also send fault codes, clearance information, and the summary value together. Hereinafter, the summary value will sometimes be referred to as the "structural information summary," and all the data values ​​of the "ECU SW ID" upon which it is based will be referred to as "complete structural information." The "complete structural information" may also include the "Vehicle SW ID," "Sys ID," surface information, and calibration information.

[0368] As described later, the central device 3 compares the summary values ​​and updates the vehicle information DB213. The central device 3, which synchronizes the structural information, checks for program updates and, if an update is found, notifies the vehicle-side system 4 of the activity information. Then, the vehicle-side system 4 downloads the distribution package, installs it on the targeted 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, and continues with the same process until a synchronization completion notification is received. Alternatively, the aforementioned process, triggered by the IG switch 37 being turned on, can also be performed after a program update.

[0369] like Figure 22 As shown, if the vehicle information management unit 3C of the central device 3 receives a "structure information summary" (D1) from the vehicle-side system 4, it compares it with the "structure information summary" of the corresponding vehicle registered in the vehicle information DB213 at that time, and determines whether the two are consistent (D2). The "vehicle information summary" can also be a calculated value pre-registered in the vehicle information DB213, or it can be calculated using the structure information registered in the vehicle information DB213 at the time of receipt from the vehicle-side system 4. If the two are consistent ("Yes"), it determines whether the vehicle's vehicle information is suitable for a regular combination registered in the structure information DB208 (D6). In addition, the structure information DB208 may be updated at a specified time, so the determination in step D6 is performed both if the two are consistent ("Yes") and if they are inconsistent ("No") in step D2.

[0370] Here, for example, Figure 23 As shown, in the above judgment of suitability, the combination of "Vehicle SW ID" and "ECU SW ID" of the structural information uploaded from the vehicle-side system 4 is checked to see if it is normal. In the list shown in the figure, the "ECU SW ID" of "ECU ID=ADS" corresponding to "Vehicle SW ID=0001" registered in structural information DB208 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".

[0371] In contrast, vehicle C with VIN=300 also has "Vehicle SW ID=0001", but the "ECU SW ID" for "ECU ID=ADS" is "ads_002" and the "ECU SW ID" for "ECU ID=BRK" is "brk_003". These two ECUs are different from the structural information registered in structural information DB208. Therefore, in step D6, it is determined to be "No", that is, non-standard "NG". The structural information verification unit 210 sends the information to the vehicle-side system 4 and the device that manages information on vehicles produced by OEMs, etc. Figure 8 The management device 220 shown notifies of an anomaly (D12). For example, the SMS sending control unit 212 uses SMS to notify of the anomaly. The SMS sending control unit 212 is an example of a communication unit. Assuming that these two ECUs 19 are not ECUs updated based on the new program, the central device 3 also determines that the vehicle is irregular and does not perform the processing after step D7.

[0372] On the other hand, vehicle A with VIN=100 has "Vehicle SW ID=0001", "ECU ID=ADS" has "ECU SW ID" as "ads_001", and "ECU ID=BRK" has "ECU SW ID" as "brk_001", which are completely consistent with the structural information registered in structural information DB208. Therefore, in step D6, it is determined to be "yes", that is, it is normal, "OK", and proceeds to step D7. Here, the structural information confirmation unit 210 can also determine whether it is normal or non-normal based on whether the combination of "ECU SW ID" of vehicle C exists in structural information DB208. In addition, in addition to "Vehicle SW ID", "Sys ID" can also be added to the determination material.

[0373] Next, the update confirmation unit 211 accesses the activity DB217 via the activity management unit 3D to confirm the existence of an update based on the new program (D7). The existence of 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 DB217. For example... Figure 23 As shown, since vehicle A with VIN=100 has the previous "Vehicle SW ID=0001", it is determined that an update has occurred ("Yes"). In this case, the update confirmation unit 211 notifies the corresponding activity ID "Cpn_001" to the vehicle-side system 4 of vehicle A (D8). The activity information is equivalent to the update notification information, and the activity DB217 is an example of the update notification information storage unit.

[0374] Alternatively, if the active DB217 has both pre- and post-update "Sys IDs," the presence or absence of an update can also be confirmed using the "Sys ID." Alternatively, instead of the "Vehicle SW ID," the uploaded list of "ECU SW IDs" can be compared with the active DB217's "pre-update ECU SW ID list" to determine if an update has occurred.

[0375] The vehicle-side system 4 uses the notified activity ID as a key to obtain the activity file (D9) corresponding to the aforementioned ID from the central device 3. The activity file contains text statements describing the activity content, constraints for executing the program update, etc. Constraints refer to the conditions for performing the download and installation, such as battery level, available RAM 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 using the in-vehicle display 7. Based on the activity content and referring to the message displayed on the in-vehicle display 7, the user decides whether to update the ECU19 application. If the in-vehicle display 7 accepts the user's consent, the CGW13 notifies the central device 3 of the agreed update content via the DCM12. Then, the central device 3 sends the distribution package file with the package ID corresponding to the aforementioned activity ID and integrity verification data (D10) to the vehicle-side system 4.

[0376] Additionally, if no update is made in step D7 (“No”), then “No update” (D11) is sent to the vehicle-side system 4. For example, Figure 23 As shown, vehicle A with VIN=200 has the updated "Vehicle SW ID=0002", which is inconsistent with the "Vehicle SW ID before update" of activity DB217. Therefore, it is determined that there is no update.

[0377] On the other hand, if the comparison result of the "structural information summary" in step D2 is inconsistent ("No"), the central device 3 requests the transmission of "all structural information" to the vehicle-side system 4 (D3). This transmission corresponds to the "notification of overall data transmission request". Correspondingly, if the vehicle-side system 4 sends "all structural information", the central device 3 receives the information (D4). Moreover, the vehicle information management unit 3C of the central device 3 updates the information of the vehicle registered in the vehicle information DB213 (D4). Then, the process proceeds to step D6. The vehicle information DB213 is an example of a vehicle-side structural information storage unit.

[0378] Alternatively, a "synchronization start request" based on CGW13 can be sent when the IG switch 37 is turned off.

[0379] As described above, according to the second embodiment, if the vehicle-side system 4 receives structural information related to the structure of each ECU 19 from multiple ECUs 19, it generates a hash value based on the data values ​​of the multiple structural information and sends the hash value to the central device 3. The central device 3 has a single-vehicle information DB 213 and compares the hash value sent from the vehicle-side system 4 with the hash value of the vehicle's structural information stored in the single-vehicle information DB 213. Moreover, if the two are inconsistent, it requests the transmission of "all structural information" from the vehicle-side system 4. The vehicle-side system 4 then accepts the transmission and sends the "all structural information" to the central device 3. If the central device 3 receives the "all structural information," it updates the structural information stored in the single-vehicle information DB 213 based on the data value.

[0380] If configured in this way, the vehicle-side system 4 initially sends the hash value of the structural information to the central device 3, and only sends the full data value of the structural information to the central device 3 if the comparison results of the hash values ​​in the central device 3 are inconsistent. This reduces the amount of data sent by the vehicle-side system 4, thus reducing the overall communication load even when the vehicle-side system 4 is installed in multiple vehicles. In particular, in the vehicle-side system 4, when structural information is uploaded at predetermined times such as when IG is activated, there are concentrated periods of communication. Therefore, by using hash values ​​to reduce the amount of data sent, the communication load can be reduced.

[0381] Furthermore, CGW13 receives structural information from all ECUs19 that are the targets of the updated data rewriting, generates a hash value based on all these data values, and DCM12 sends the hash value when the vehicle's ignition switch 37 is turned on or off. Therefore, it can send the hash value to the central device 3 at the start or end of vehicle operation. Thus, the central device 3 can properly synchronize the structural information of the single-vehicle information DB213 with the vehicle.

[0382] Furthermore, if the vehicle-side system 4 receives "ECU SW IDs" from multiple ECUs 19, it will send a list of structured information combining "Vehicle SW IDs" from these ECUs to the central device 3. The central device 3 compares the list of "ECU SW IDs" sent from the vehicle-side system 4 with the corresponding list of regular "ECU SW IDs" for the vehicle stored in the structured information DB208. If it determines that the combination of the sent list is irregular, it will send an anomaly detection to the vehicle-side system 4 and the management device 220.

[0383] If configured in this way, the central device 3 can detect an anomaly where the combination of vehicle structural information is such that multiple ECUs 19 cannot coordinate, thus hindering the vehicle's operation, and notify the vehicle-side system 4. As a result, the vehicle-side system 4 can take measures such as prohibiting the vehicle from driving.

[0384] For vehicles with non-standard combinations of vehicle structure information, the central unit 3 does not perform the update confirmation process (D7). Therefore, it is possible to prevent program updates from being performed in non-standard vehicles. Even if the non-standard ECU 19 is not the ECU to be updated based on the new program, the central unit 3 does not perform the update confirmation process (D7). In the vehicle-side system 4, during program updates, control is also generated for ECU 19 that is not the update target. Therefore, in vehicles with non-standard ECU 19s, the program update may not complete properly, and thus the central unit 3 does not perform a program update for that vehicle.

[0385] Additionally, the central device 3 includes an activity DB217 that stores activity information. This activity information is used to notify the vehicle side of updates based on new programs. For vehicles deemed legitimate, the presence or absence of corresponding activity information is checked. If an update exists, the activity information is sent to the vehicle-side system 4. This allows the user to be notified of activity information and urged to update the application. Taking the upload of structural information from the vehicle as an opportunity, the central device 3 performs a series of processes, including synchronizing this structural information, determining whether it is legitimate, and confirming the presence or absence of updates. This enables the appropriate vehicles to be quickly notified of program updates.

[0386] Alternatively, the second implementation method can be modified as follows.

[0387] • The central device 3 can also send a "synchronization start request" to the vehicle-side system 4. If the "synchronization start request" is received, the DCM12 sends a "structural information collection request" to the CGW13. For example, when the structural information DB208 of "vehicle model = aaa" is updated, the central device 3 sends a "synchronization start request" to vehicles of that vehicle model.

[0388] Additionally, in the ECU 19 that is the target of the data update, a hash value can be sent to the central device 3 upon completion of the update. That is, the update is executed when all programs of the ECU 19 that is the target of the update are completed. Figure 22 The flowcharts for steps D1 to D12 are shown.

[0389] • When the hash values ​​of both sides match, the central device 3 requests the vehicle-side system 4 to send a list of combinations of structural information for each ECU 16. Furthermore, if the aforementioned list of combinations is received, steps D6 to D12 can be performed.

[0390] • The central device 3 can also refer to activity DB217 to confirm the presence or absence of activity information for the corresponding vehicle when the comparison results of the hash values ​​of both parties are consistent.

[0391] It can also be like Figure 23A As shown, the hash value is sent from the vehicle-side system 4 to the central device 3. Figure 23A This is a flowchart illustrating the processing of CGW13. For example, when IG switch 37 is turned on, CGW13 collects structural information from each ECU 19 (D21) and generates a hash value for the collected structural information data values ​​(D22). Furthermore, it compares the generated hash value with the hash value (the previously generated value) stored in flash memory 24d to determine if there is a difference (D23). If there is a difference ("Yes"), the generated hash value is stored in flash memory 24d (D24) and sent to the central device 3. In step D23, if the hash values ​​of both sides are not different ("No"), the processing ends. Additionally, the initial hash value for the structural information is pre-stored in flash memory 24d. Therefore, the vehicle-side system 4 can reduce the number of times it uploads structural information to the central device 3.

[0392] (Third Implementation)

[0393] The third embodiment relates to a function performed by the activity management unit 3D of the central device 3 to improve the update rate of applications in the vehicle-side system 4. For example... Figure 24 As shown, for example, in vehicle-side system 4, the user pre-sets the HTTP polling interval to approximately 3 days via a Config file. Thus, vehicle-side system 4 periodically checks with central device 3 to confirm whether the application has been updated. Therefore, for the vehicle corresponding to activity DB217, when the activity information of the VIN is set and an update confirmation is made, central device 3 notifies vehicle-side system 4 that "an update has been made." That is, as described in the second embodiment, taking the opportunity of uploading structural information from vehicle-side system 4 via HTTP, the process of update confirmation by central device 3 is performed when IG connection is established 3 days later.

[0394] If the update is configured to be triggered by notifications from vehicles, then the central device 3 does not need to send activity information from the central device 3 to all vehicles that are the subjects of the activity at the moment the activity information is set. However, if the user does not use the vehicle for an extended period, no confirmation of the update status via HTTP is performed during that time. Therefore, it is also conceivable that the user is unaware of the issuance of a new activity, resulting in vehicles not updating their applications.

[0395] Therefore, as Figure 25 As shown, the SMS sending control unit 212 of the central device 3 periodically or at predetermined times checks the access logs (E1) of each vehicle by referring to the vehicle information DB213. Furthermore, it determines whether there are any vehicles that have not accessed the central device 3 within a predetermined period, i.e., have sent structure information for application update confirmation (E2). The predetermined period is calculated from the date a new activity is set in the activity DB217, for example, approximately 7 days. That is, the SMS sending control unit 212 identifies vehicles that have not received update confirmation within 7 days, targeting vehicles whose "Vehicle SW ID" in the vehicle information DB213 corresponds to the "Pre-update Vehicle SW ID" in the activity DB217. Alternatively, the SMS sending control unit 212 can identify vehicles that have not received update confirmation within the predetermined period, targeting all vehicles.

[0396] Additionally, in the vehicle information DB213, initial data is registered with the OEM during vehicle production at the factory. Then, for example, an initial access log is entered via a notification from the OEM accompanying the sale of the vehicle. This access log essentially serves as a notification to enable subsequent program updates. Vehicles for which no access log is entered are not included in the decision criteria of step E2.

[0397] If a vehicle has not been updated and confirmed within the specified period (“Yes”), the SMS transmission control unit 212 determines the characteristics of the vehicle (E3) based on the model, equipment information, etc., of the vehicle information DB213. These characteristics include whether the vehicle is an electric vehicle; whether it is an EV capable of receiving SMS (Short Message Service); whether it is an existing gasoline engine vehicle capable of receiving SMS (i.e., a conventional engine vehicle); and whether it is a delivery vehicle or a vehicle that is difficult to receive SMS. For example, if the DCM12 installed in the vehicle does not have the function of receiving SMS or if there is no protocol for receiving SMS, it is determined to be a vehicle that is difficult to receive SMS.

[0398] If it is an EV, then send an SMS (E5, refer to) to start the structural information transmission step, which will activate the ECU19 of that vehicle. Figure 26If DCM12 receives an SMS and executes the instructions recorded in the SMS, it enters the IG power-on state, and the activated CGW13 sends structural information to the central device 3 via DCM12. Then, like... Figure 22 As shown in steps D1 to D12, update confirmation and download of the distribution package are performed. In the case of an EV, due to the larger battery capacity, it is assumed that keeping the vehicle parked with the IG powered on will allow for sufficient program download. Therefore, ECU19 is started using SMS to automatically begin the update confirmation and subsequent download steps.

[0399] Assuming the EV vehicle has limited battery capacity, in vehicle-side system 4, refer to... Figure 17 The rewritten specification data shown prevents installation from starting if the battery level is below the specified level. Alternatively, the central device 3, referring to the battery level recorded in the activity file as a constraint sent in step D9, prevents the packet download from starting in the vehicle-side system 4 if the battery level is below the specified level.

[0400] In the transport vehicle, the SMS sending control unit 212 sends SMS messages (see E4) that can be displayed on the vehicle display 7 to vehicles that are in a state where they can receive SMS messages during each intermittent start of the DCM12. Figure 26 For example, CGW13 instructs the onboard display 7 to show the text message recorded in the received SMS when the IG connection is next established. Additionally, if the user's portable terminal 6 information is registered in the bicycle information DB213, an SMS can also be sent to that portable terminal 6. For example, a text message such as "Activity information exists. Please turn IG-ON." is displayed. The bicycle information DB213 is an example of a user information storage unit. On the other hand, no action is taken for vehicles that are difficult to receive SMS messages; instead, the user is contacted via mail (E6).

[0401] As described above, according to the third embodiment, the vehicle-side system 4 sends structural information of multiple ECUs 19 to the central device 3, and stores the structural information sent from each vehicle along with the sending date in the vehicle information DB 213. Furthermore, the activity DB 217 stores an activity ID and a list of target VINs that can identify the target vehicle for data updates, as activity information. Moreover, referring to the vehicle structure DB 213, if the central device 3 has not sent structural information within a specified period from the sending date associated with the target vehicle, it sends a message via SMS to the vehicle-side system 4 of the target vehicle urging a data update.

[0402] If configured in this way, even if the user does not have the opportunity to ride the vehicle and therefore does not send structural information to the central device 3, if a predetermined period has elapsed since the date of transmission stored in the vehicle information DB213, the central device 3 will send a message urging data updates to the vehicle-side system 4 of the target vehicle. Therefore, the user can identify the need for data updates by referring to this message.

[0403] Furthermore, the central device 3 determines the target vehicle for program updates by referring to the vehicle information DB213 and the activity DB217. Specifically, the vehicle information DB213 stores the date from which structural information is sent from each vehicle, and the activity DB217 stores a list of target VINs. Therefore, the central device 3 can determine the target vehicle for program updates based on the date of structural information transmission from each vehicle and the list of target VINs.

[0404] Furthermore, when the vehicle's ignition switch 37 is turned on, the vehicle-side system 4 receives its respective structural information from each ECU 19 and then sends the structural information to the central device 3. Therefore, structural information can be reliably sent to the central device 3 when a user is riding in the vehicle.

[0405] Furthermore, if the target vehicle is an electric vehicle, the central device 3 sends a message containing an instruction to start the ECU of the target vehicle. Upon receiving the message, the vehicle-side system 4 starts the ECU 19 to perform data update-related processing. That is, because the battery capacity of an electric vehicle is relatively ample, the ECU 19 can perform data update-related processing without waiting for user input. Therefore, data updates can be performed efficiently.

[0406] Furthermore, if the target vehicle is a transport vehicle, the central device 3 will send at least one text message that can be displayed on the vehicle's onboard display 7 as a message. Therefore, the user of the transport vehicle can identify the need for a data update by referring to the text message displayed on the onboard display 7.

[0407] Furthermore, when the destination of the user's portable terminal 6 is stored in the bicycle information DB213, the message center device 3 sends text information that can be displayed on the portable terminal 6. Thus, even if the user does not have the opportunity to ride a bicycle, they can identify the need for data updates by referring to the text information displayed on the portable terminal 6.

[0408] Furthermore, if a user sends the activity's launch date and destination to the central device 3 in advance via portable terminal 6, the central device 3 stores these dates and destinations in the vehicle information DB213. For example, the user may specify the day after the activity's launch as the launch date, and specify portable terminal 6 as the destination instead of vehicle display 7. Alternatively, the user may specify a scheduled time when they will not be using the vehicle as the launch date, and specify the vehicle as the destination, automatically performing an agreement operation for program updates. Thus, regardless of whether structured information is sent, the central device 3 sends activity information to the specified destination on the designated launch date. Therefore, when it is known in advance that the user will not have the opportunity to use the vehicle temporarily, it is possible to set the launch date to receive activity information on the user-defined launch date.

[0409] Alternatively, the third implementation method can be modified as follows.

[0410] • The user information storage unit can also be set up independently from the bicycle information DB213.

[0411] • Event information can also be sent using methods other than SMS.

[0412] • It can also replace storing the sending date in the bicycle information DB213. For example, the central device 3 stores the dates on which no sending has been made from the vehicle side, and sends a message urging data updates when the date has been continuous for 7 days.

[0413] (Fourth Implementation)

[0414] The fourth implementation describes a scenario where the user specifies a method for notifying activity information and messages. For example, it is assumed that it is predetermined that the user has not taken a ride for approximately one month, thus eliminating the opportunity to turn on the IG switch 37. Figure 27 As shown, the user sends a notification to the central device 3 via the portable terminal 6, specifying the destination and time of the event. For example, a setting might be made to notify the portable terminal 6 of the event information one month later. The bicycle information management unit 3C then stores the notification destination and 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 that one-month period, the SMS sending control unit 212 notifies the user's portable terminal 6 of the events (1 and 2) one month later, prompting a program update.

[0415] As described above, according to the fourth embodiment, if a user sends the sending date and destination of activity information to the central device 3 via the portable terminal 6, the central device 3 stores the sending date and destination in the bicycle information DB213. Furthermore, the central device 3 sends the activity information to the destination on the stored sending date. Thus, if it is determined that the user will not ride the vehicle within a certain period, the central device 3 can stop sending unnecessary activity information.

[0416] (Fifth Implementation)

[0417] The fifth embodiment indicates that when the central device 3 sends update program data to the vehicle-side system 4, the vehicle-side system 4 provides a function for verifying the integrity of the data. For example... Figure 28 and Figure 29 As shown, the supplier uses Package Management Department 3A to create data registered in ECU reconfiguration data DB204. Specifically, as update data, Package Management Department 3A creates new differential data (Y1) for rewriting the old program into a new program, creates integrity verification data (hash value) for the new program for ECU19, and creates a hash value for the new differential data (Y2). Here, if the ECU is a single-sided memory, it can also be used as rollback data to create old differential data for rewriting the new program into the old program, create a hash value for the old program for ECU19, and create a hash value for the old differential data.

[0418] The Packet Management Unit 3A generates an authentication token (Y3) by encrypting each hash value using a prescribed key. Furthermore, the Packet Management Unit 3A sends update data and integrity verification data containing each authentication token, and stores them in the ECU reconfiguration data DB204 (Y4). The Packet Management Unit 3A generates a packet as described above, generates integrity verification data for the packet, and sends it to the vehicle-side system 4 (Y5).

[0419] The master device (OTA host) 11 performs calculations on the integrity verification data for the packet, compares the calculated value with the received integrity verification data for the packet, and performs packet integrity verification (Y6). If the packet integrity verification is successful, the master device 11 sends the ECU update data and integrity verification data to the ECU to be modified (target ECU) 19 (Y7).

[0420] The rewrite target ECU 19 performs calculations on the integrity verification data for the updated data, compares the calculated value with the received integrity verification data for the updated data, and performs integrity verification of the updated data (Y8). If the integrity verification of the updated data is successful, the rewrite 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 rewrite target ECU 19 performs calculations on the integrity verification data for the data written to the flash memory 28d, compares the calculated value with the integrity verification data of the received new program, and performs integrity verification of the flash memory 28d (Y10). The rewrite target ECU 19 sends the verification result to the master device 11 (Y11), and the master device 11 sends the received verification result to the central device 3 as an installation result notification (Y12).

[0421] For example, Figure 10 As shown, Package Management Department 3A generates the following integrity verification data for the latest "ECU SW ID". If the ECU's memory structure is a two-sided memory or suspended, the following (3) and (4) can be omitted.

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

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

[0424] (3) Generate integrity verification data, i.e., hash values, for the old program of the ECU. The functional part that performs this process is an example of the fourth verification value generation unit (step A5).

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

[0426] Additionally, "program" also includes constant data used within the program. For example, if "ECU SW ID = ads_002", then for the updated data "Adsfile001-002", this hash value x1 is generated. The hash function is, for example, SHA-256, as described above. The hash value is equivalent to a verification value. Here, the packet management unit 3A can also be configured to generate an authentication token by applying encryption of the hash value using a specified key, i.e., the key value, and thus generate integrity verification data with the authentication token.

[0427] Next, the supplier generates an authentication token by encrypting the integrity verification data using a specified key, i.e., the key value. Integrity verification data with the authentication token is then generated, and the updated data is provided to the OEM by mapping the updated data to the authentication token-containing integrity verification data. Specifically, the package management unit 3A registers each program and the authentication token-containing integrity verification data for that program in the ECU reconfiguration data DB204, thereby providing it to the OEM. According to the OEM's instructions, the package management unit 3A uses the ECU reconfiguration data DB204, etc., to generate rewritten specification data as described above, generates a distribution package, and registers it in package DB206. If a download request for updated data is generated from the vehicle-side system 4, the central device 3 distributes a distribution package containing the updated data and the authentication token-containing integrity verification data to the vehicle-side system 4 based on the download request.

[0428] In addition, the "integrity verification data" in the technical solution includes data with only hash values ​​and integrity verification data with authentication tokens that are encrypted based on keys.

[0429] If the main unit 11 of the vehicle-side system 4 receives a distribution package, it uses the integrity verification data (third verification value) assigned to the distribution package to verify the appropriateness of the distribution package. Specifically, it compares the integrity verification data calculated using the distribution package with the received integrity verification data; if they match, it is considered normal. If the verification result confirms that it is normal, the main unit 11 unpacks the distribution package into data for each ECU (refer to...). Figure 6 Furthermore, the master device 11 transmits update data and integrity verification data with authentication tokens to the ECU 19, which is written to the destination.

[0430] ECU19 uses integrity verification data (second verification value) with an authentication token to verify the appropriateness of the updated data. Specifically, it compares the integrity verification data calculated using the received updated data with the received integrity verification data; if they match, it is considered normal. If the verification result confirms normality, the CPU28a of ECU19 performs a write operation to flash memory 28d. If the write operation is complete, ECU19 reads the data written to flash memory 28d using integrity verification data with an authentication token (first verification value) and verifies its appropriateness. Specifically, it compares the integrity verification data calculated using the read data with the received integrity verification data; if they match, it is considered normal. Furthermore, this integrity verification data is also used during ECU19 startup and is therefore pre-stored in a designated area of ​​flash memory 28d. If these processes are complete, ECU19 sends a write response containing the verification result to the master device 11. The master device 11 notifies the central device 3 of the installation result. Additionally, in the figure, "target ECU" and "object ECU" are synonymous, and "OTA host" and "DCM" are synonymous. CPU28a is an example of a write processing unit.

[0431] Here, in the event of a program update cancellation during installation, ECU19 performs a rollback. ECU19 writes the update data and verifies the appropriateness of the rollback differential data using integrity verification data with an authentication token (fifth verification value). Specifically, the integrity verification data calculated using the rollback differential data is compared with the received integrity verification data; if they match, it is considered normal. If the verification result confirms normality, ECU19 begins writing the rollback differential data after completing the update data writing. Furthermore, after completing the writing, ECU19 reads the data written to flash memory 28d using the integrity verification data with an authentication token (fourth verification value) to verify its appropriateness.

[0432] Alternatively, the integrity verification of the received differential data (update data, rollback differential data) can be performed by the main device 11 instead of the ECU19.

[0433] like Figure 30As shown, if the IG switch 37 of the aforementioned vehicle is turned on, the ECU 19 performs data verification during startup. The ECU 19 uses integrity verification data (first verification value or fourth verification value) with an authentication token to verify the integrity of the started program, etc. First, in the flash memory 28d, a hash function is applied to the data values ​​of the evaluation object area where updated program and constant data are written to obtain a hash value. Next, the integrity verification data with the authentication token is decoded, and the hash value (expected value) contained in the decoding result is compared with the obtained hash value (operated value) to determine whether the program, etc., written to the flash memory 28d has been tampered with. If the hash values ​​of both are consistent and "OK", the ECU 19 performs startup processing as usual. The same process is performed for each ECU 19, and if the result of all the evaluated object ECUs is "OK", the processing ends.

[0434] On the other hand, if the verification result for any ECU 19 is abnormal, i.e., "NG", then ECU 19 saves the processing log and notifies the master device 11 of the error. The master device 11 also saves the log and notifies the central device 3 of the error. The central device 3 also saves the log and notifies the management device 220, such as the OEM, of the error. The notification to the management device 220 is made, for example, by sending SMS to the control unit 212 using SMS, or by sending email via the Internet line.

[0435] In the above embodiments, the vehicle-side system 4 employs a structure for integrity verification. Figure 31 The section explains the process of integrity verification (comparison with expected values) performed by the central device 3. Figure 31 For example, when the IG is connected, the ECU19 sends the updated application version information to the host device 11, and generates and sends integrity verification data with an authentication token along with the version information in the same manner as described above (X1). The ECU19 performs a calculation on the integrity verification data for the data in the flash memory 28d and sends the calculated value to the host device 11. The host device 11 sends the integrity verification data with the authentication token, which includes structure information, to the central device 3 (X2).

[0436] The central device 3 accesses the ECU reconfiguration data DB204 to obtain integrity verification data (X3, X4) with an authentication token for the "ECU SW ID" that matches the target ECU 19, and compares it with the integrity verification data uploaded from the vehicle side (X5). Specifically, it obtains the integrity verification data of the new procedure corresponding to the "ECU SW ID" from the ECU reconfiguration data DB and compares it. If the comparison result is inconsistent and NG (X6; NG), an anomaly is notified to the OEM's management device 220 (X7). This processing unit functions as an anomaly reporting unit.

[0437] The central device 3 sends the comparison result (X8) to the main device 11, and the main device 11 sends the received comparison result (X9) to the ECU 19 to be modified. If the comparison result is OK, the ECU 19 to be modified will operate the application as usual; if the comparison result is NG, the application will not operate. 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).

[0438] In addition, as described above, after the ECU19 writes the updated data, it verifies the integrity of the updated data when the vehicle's IG switch 37 is turned on. However, it is also possible to verify the integrity after the updated data has been written.

[0439] In addition, in the above implementation, only the updated data is given integrity verification data with an authentication token, but it can also be implemented as follows.

[0440] • Obtain the new program and corresponding update data from the ECU reconfiguration data DB204 (data acquisition step; step A1).

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

[0442] • The second verification value generation unit generates a second hash value for the updated data (second verification value generation step; step A4). The packet generation unit 202 causes the distribution packet to include the updated data, specification data, and the first and second hash values ​​(distribution packet generation step). The updated data corresponds to the new differential data.

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

[0444] • The packet distribution unit 203 sends the distribution packet and the third hash value to the vehicle-side system 4 (sending step).

[0445] Additionally, the authentication token can be assigned only to the distribution packet and the third hash value, or it can be assigned at each stage of generating each hash value. The packet distribution unit 203 is equivalent to the sending unit.

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

[0447] • The receiving and processing unit, namely DCM12, receives and distributes packets and third hash values.

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

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

[0450] • One example of the write processing unit is that CPU 28a writes updated data to flash memory 28d.

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

[0452] If the verification result of the updated data is NG, the writing to flash memory 28d is aborted. Furthermore, if the verification result of the new program written to flash memory 28d is NG, the new program is invalidated, and a rollback is performed as needed. Alternatively, the first to third verification processing units can also be implemented by CPU 28a. Additionally, if the verification result of any of the first to third verification processing units is NG, DCM12, acting as a transmission processing unit, notifies the central device 3 of an anomaly.

[0453] Furthermore, based on the above, such as Figure 10 As shown, when rollback data exists to revert to the state of the old program before the updated data was written, it can also be implemented as follows.

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

[0455] The fifth verification value generation unit generates a fifth hash value for the rollback data used to revert the new program to the old program (fifth verification value generation step; step A7). The rollback data represents the rollback differential data, which corresponds to the old differential data.

[0456] • The package generation unit 202 makes the distribution package include update data, rollback differential data, rewritten specification data, and first, second, third, and fourth hash values ​​(distribution package generation step).

[0457] In this case, during the rewriting and updating of data in the flash memory 28d in the vehicle-side system 4, if the rewriting is aborted by the user, it becomes a rewrite cancellation, and a restoration to the old program, i.e., a rollback, is performed. This only applies when the memory structure of ECU19 is a single-sided memory.

[0458] 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.

[0459] The CPU28a uses rollback data to write to the flash memory 28d.

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

[0461] As described above, according to the fifth embodiment, the ECU reconfiguration data DB204 stores the new program, the old program, and new differential data (update data) used to update from the old program to the new program for the target ECU 19. The first verification value generation unit generates a first hash value using the new program, and the second verification value generation unit generates a second hash value using the update data. The packet generation unit 202 generates a packet containing update data for multiple target ECUs 19, the first and second verification values, and specification data. The third verification value generation unit generates a third hash value using the distribution packet, and the packet distribution unit 203 sends the distribution packet and the third hash value together to the vehicle-side system 4.

[0462] If the vehicle-side system 4 receives a distribution packet and a third hash value, the third verification processing unit calculates a hash value for the distribution packet and compares it with the third hash value to verify the integrity of the distribution packet. The second verification processing unit calculates a hash value for the updated data corresponding to the target ECU 19 included in the distribution packet and compares it with the second hash value included in the distribution packet to verify the integrity of the updated data.

[0463] CPU 28a writes updated data to flash memory 28d. The first verification processing unit calculates the hash value of the updated new program data for flash memory 28d and compares it with the first hash value to verify the integrity of the new program data. In this way, the integrity of each data value can be verified at multiple stages using each hash value. Moreover, for a new program, integrity can be verified three times, which can prevent the vehicle-side system 4 from writing an incomplete new program or operating with an improper new program.

[0464] Furthermore, when rollback data exists in the ECU reconfiguration data DB204, the fourth verification value generation unit generates a fourth hash value for the old program, and the fifth verification value generation unit generates a fifth hash value for the rollback data. The packet generation unit 202 causes the distribution packet to include update data, the first and second hash values, the rollback data, and the fourth and fifth hash values.

[0465] Furthermore, during rollback 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 a fifth hash value to verify the integrity of the rollback data. The 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 recovered by writing to the flash memory 28d and compares it with a fourth hash value to verify the integrity of the old program. Thus, the integrity of the old program that has been written back can also be verified. In the above, 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. Additionally, the third verification processing unit is a functional module within the main device 11 (OTA host 11) of the vehicle-side system 4.

[0466] (A variation of the first embodiment)

[0467] It can also be like Figure 32 and Figure 33 As shown, one activity "cpn_001" corresponds to multiple packages "pkg_001_1" and "pkg_001_2". Alternatively, multiple packages can be grouped together. In the above embodiment, a structure is used where one package contains multiple groups. In this variation, one package is generated using one group, and multiple packages are distributed for one activity. For example, package "pkg_001_1" contains ECUs belonging to group 1, namely "ADS" and "BRK", and package "pkg_001_2" contains ECUs belonging to group 2, namely "EPS".

[0468] In this case, such as Figure 34 and Figure 35 As shown, specification data and distribution packages are generated independently for each group. Figure 34 In this context, as specification data for Group 1, the specification data generation unit 201 generates, for example, first specification data containing ECU information of "ADS" and "BRK". As specification data for Group 2, the specification data generation unit 201 generates, for example, second specification data containing ECU information of "EPS". Furthermore, in... Figure 35In this process, the package generation unit 202 generates, for example, recompiled data obtained by merging updated data of "ADS" and "BRK" belonging to group 1 according to the ECU sequence, and merges it with the first specification data to generate the package file "pkg001_1.dat". The package generation unit 202 uses updated data of "EPS" belonging to group 2 to generate recompiled data, and merges it with the second specification data to generate the package file "pkg001_2.dat".

[0469] (A second variation of the first embodiment)

[0470] Figure 36 This describes the processing steps when the functions of the specification data generation unit 201 and the package generation unit 202 are combined to form a package generation tool 221. The processing steps will be explained again below.

[0471] In the specification data generation process, the values ​​input by the operator as specification data information are pre-determined in terms of bit count and arrangement order to generate specification data. For example, specification data information includes... Figure 17 The values ​​shown in the examples, in addition to information for ECU units such as ECU(ID1), ECU(ID2), and ECU(ID3), also include information for vehicle units or system (group) units. Vehicle unit information, for example, refers to... Figure 17 The rewrite environment information shown, such as system unit information, refers to... Figure 17 The information shown includes group information and ECU sequence information. Input information for vehicle units and system units can also be stored in separate files. The specification data generation process can also automatically calculate and reflect values ​​such as file size of updated data in the specification data.

[0472] 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 pre-determined in terms of bit count and arrangement order, and an output file for the distribution package is generated. The update data and integrity verification data for each ECU are arranged in ascending order of group size and ascending order of ECU size. 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 for ECU program (new)" and "Integrity verification data for updated data" are input. If rollback data is also added, "Integrity verification data for old ECU program" and "Integrity verification data for old differential data" are also added to the input.

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

[0474] The generated package file and the integrity verification data generated for the package file are registered by the operator in package DB206.

[0475] (Other implementation methods)

[0476] The functions performed by the central device 3 can be implemented by hardware or software. Alternatively, they can be implemented through a combination of hardware and software.

[0477] The data that is rewritten can be not only application data, but also data such as maps and control parameters.

[0478] The content of structural information is not limited to the examples shown; it can be selected appropriately based on the individual design.

[0479] The specifications are not limited to the examples shown.

[0480] Activity information and distribution specification data can be included in the distribution package and sent to the vehicle side, or they can be sent to the vehicle side independently of the distribution package.

[0481] In the fifth embodiment, the distribution packet and the third verification value may be stored in the packet storage unit in advance, and the packet sending unit 213 sends the distribution packet and the third verification value associated with the request to the vehicle-side system 4 according to the request from the vehicle-side system 4.

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

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

[0484] like Figure 37As shown, the vehicle program rewriting system 1 includes a central device 3 on the communication network 2 side, a vehicle-side system 4 on the vehicle side, and a display terminal 5. The communication network 2 is configured to include, for example, mobile communication networks based on 4G lines, the Internet, WiFi (Wireless Fidelity) (registered trademark), etc.

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

[0486] If a user is outside the vehicle but within the communication range of the mobile communication network, they can simultaneously view various screens related to application rewriting on the portable terminal 6 and perform operation input, thus completing the procedures related to application rewriting. Alternatively, a user can be inside the vehicle and simultaneously view various screens related to application rewriting on the in-vehicle display 7 and perform operation input, thus completing the procedures related to application rewriting. In other words, the user can use the portable terminal 6 and the in-vehicle display 7 separately, both outside and inside the vehicle, to complete the procedures related to application rewriting.

[0487] The central device 3 integrates the program update functions on the communication network 2 side of the vehicle program rewriting system 1, functioning as an OTA center. The central device 3 has a file server 8, a network server 9, and a management server 10, and each server 8 to 10 is configured to communicate with each other. That is, the central device 3 is composed of multiple servers with different functions.

[0488] File server 8 is a server that manages the files of applications distributed from central device 3 to vehicle-side system 4. File server 8 manages updated data (hereinafter also referred to as recompiled data or write data) provided by suppliers such as the original equipment manufacturer (OEM), and vehicle status data obtained from vehicle-side system 4. The supplier is the company that provides the applications distributed from central device 3 to vehicle-side system 4. File server 8 can communicate with vehicle-side system 4 via communication network 2. If a download request for a distribution package is generated, it packages the recompiled data and distribution specification data into a single file and sends it to vehicle-side system 4.

[0489] Network server 9 is a server that manages network information. Network server 9 sends network data it manages based on requests from web browsers on devices such as portable terminals 6. Management server 10 is a server that manages the personal information of users registered in the application rewriting service, the application rewriting history of each vehicle, and so on.

[0490] The vehicle-side system 4 has a main unit 11 (equivalent to a vehicle main unit). The main unit 11 has a DCM (Data Communication Module) 12 (equivalent to an onboard communicator) and a CGW (Central Gateway) 13 (equivalent to a vehicle gateway device). The DCM 12 and CGW 13 are connected via a first bus 14 to enable data communication. The DCM 12 communicates with the central unit 3 via a communication network 2. If the DCM 12 downloads a distribution package from the file server 8, it extracts write data from the downloaded distribution package and transmits the extracted write data to the CGW 13.

[0491] CGW13 has a data relay function. If write data is obtained from DCM12, it instructs the target ECU of the application to write the obtained write data and distributes the write data to the target ECU. In addition, if the writing of data in the target ECU is completed and the application is rewritten, CGW13 instructs the target ECU to make the rewritten application valid and active.

[0492] The main device 11, within the vehicle-side program update system 1, encompasses the vehicle-side program update functions and functions as an OTA (Over-The-Air) host. Furthermore, in Figure 37 In this example, the DCM12 and the vehicle display 7 are connected to the same first bus 14. However, the DCM12 and the vehicle display 7 can also be connected to different buses. Alternatively, the CGW13 can have part or all of the functions of the DCM12, or the DCM12 can have part or all of the functions of the CGW13. That is, the functional distribution of the DCM12 and CGW13 in the main unit 11 can be arbitrarily configured. The main unit 11 can also be composed of two separate ECUs, DCM12 and CGW13, or it can be composed of a single ECU that combines the functions of both DCM12 and CGW13.

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

[0494] The second bus 15 is, for example, the bus of the vehicle body system network. The ECU 19 connected to the second bus 15 is an ECU that controls the vehicle body system. The ECU that controls the vehicle body system is, for example, a door ECU that controls the locking / unlocking of the doors, an instrument ECU that controls the display on the instrument display, an air conditioning ECU that controls the operation of the air conditioning, a window ECU that controls the opening and closing of the windows, a security ECU that is activated to prevent the vehicle from being stolen, etc.

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

[0496] The fourth bus 17 is, for example, a bus for a multimedia system network. The ECU 19 connected to the fourth bus 17 is an ECU that controls the multimedia system. Examples of ECUs controlling the multimedia system include navigation ECUs for controlling navigation systems and ETC ECUs for controlling electronic toll collection systems (ETC). Buses 15-17 can also be buses for systems other than the vehicle body system network, the driving system network, and the multimedia system network. Furthermore, the number of buses and the number of ECUs 19 are not limited to the illustrated structure.

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

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

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

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

[0501] The method of using a wireless rewriting application refers to rewriting the target ECU 19 using an application obtained wirelessly from outside the vehicle. Specifically, if DCM 12 downloads a distribution package from file server 8, it extracts write data from the downloaded distribution package and transmits the write data to CGW 13. 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 DCM 12 to the target ECU 19.

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

[0503] Wireless diagnostics refers to diagnosing the ECU 19 from outside the vehicle via wireless means. Specifically, if the central device 3 sends a diagnostic command to the DCM 12 as a diagnostic request, the DCM 12 transmits the diagnostic command to the CGW 13. The CGW 13 acts as a gateway, distributing the diagnostic command as a diagnostic request to the target ECU 19. The target ECU performs diagnostic processing corresponding to the diagnostic command received from the CGW 13.

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

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

[0506] like Figure 39 As shown, the DCM12, as an electrical function module, includes a microcomputer 28, a wireless circuit 29, a data transmission circuit 30, a power supply circuit 31, and a power detection circuit 32. 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 from which information cannot be read from outside the DCM12. The microcomputer 28 executes various control programs stored in a non-transferable physical storage medium to perform various processes and control the operation of the DCM12. Flash memory for storing data downloaded from the central device 3 can also be configured in the CGW13.

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

[0508] Furthermore, the DCM12, for example, has a vehicle position detection function that detects the vehicle's position via GPS (Global Positioning System). The flash memory 28d of the DCM12 has sufficient memory capacity to store distribution packets downloaded from the central device 3, and has a larger memory capacity than the flash memory 24d of the CGW13. That is, because the DCM12's flash memory 28d has sufficient memory capacity, even without using the CGW13's flash memory 24d, the main device 11 can download distribution packets from the central device 3 and store these downloaded distribution packets in the DCM12.

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

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

[0511] The in-vehicle display 7 has the same features as Figure 40 The ECU19 shown has the same structure. The power management ECU20 has the same... Figure 40 The ECU 19 shown has the same structure. The power management ECU 20 is connected to the power control circuit 43, which will be described later, to enable data communication.

[0512] like Figure 41As shown, the power management ECU 20, CGW13, and ECU 19 are connected to the power supply lines, namely +B power line 37, ACC power line 38, and IG power line 39. +B power line 37 is connected to the positive terminal of the vehicle battery 40. ACC power line 38 is connected to the positive terminal of the vehicle battery 40 via ACC switch 41. When the user performs ACC operation, ACC switch 41 switches from off to on, applying the output voltage of the vehicle battery 40 to ACC power line 38. ACC operation, for example, in a vehicle that uses a key to insert a ignition key, involves inserting the key and turning it from the "OFF" position to the "ACC" position; in a vehicle that uses a start button, it involves pressing the start button once.

[0513] The IG power line 39 is connected to the positive terminal of the vehicle battery 40 via the IG switch 42. When the user performs an IG operation, the IG switch 42 switches from off to on, applying the output voltage of the vehicle battery 40 to the IG power line 39. An IG operation, for example, in a vehicle that uses a key to insert a ignition key, involves inserting the key and turning it from the "OFF" position to the "ON" position; in a vehicle that uses a start button, it involves pressing the start button twice. The negative terminal of the vehicle battery 40 is grounded.

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

[0515] The activation conditions of ECU19 vary depending on the power supply state. ECU19 is classified into +B power system ECUs that activate under +B power conditions, ACC system ECUs that activate under ACC power conditions, and IG system ECUs that activate under IG power conditions. For example, ECU19s used for purposes such as vehicle theft are classified as +B power system ECUs. ECU19s used for non-driving system purposes such as audio systems are classified as ACC system ECUs. ECU19s used for driving system purposes such as engine control are classified as IG system ECUs.

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

[0517] CGW13 causes the ECU 19 destined for a start request to transition from a sleep state to a start state by sending a start request to the ECU 19 in a sleep state. Conversely, CGW13 causes the ECU 19 destined for a sleep request to transition from a start state to a sleep state by sending a sleep request to the ECU 19 in a start state. CGW13 can, for example, transition a specific ECU 19 to a start state or a sleep state by using different waveforms of the transmission signals sent to buses 15-17. That is, the start request waveform and sleep request waveform are predetermined for each ECU 19. If an ECU 19 receives a start request waveform suitable for itself, it transitions from a sleep state to a start state; if it receives a sleep request waveform suitable for itself from CGW13, it transitions from a start state to a sleep state.

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

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

[0520] DCM12, CGW13, ECU19, and power management ECU20 each have a power self-holding circuit, which maintains the power supply from the vehicle battery 40. That is, if the vehicle power supply switches from ACC or IG to +B power during startup, DCM12, CGW13, ECU19, and power management ECU20 do not immediately transition from startup to shutdown or sleep mode after the switch. Instead, they maintain the startup state for a specified time (e.g., several minutes) by maintaining the drive power supply through the power supply from the vehicle battery 40. After the specified time has elapsed since the vehicle power switch from ACC or IG to +B power, DCM12, CGW13, ECU19, and power management ECU20 transition from startup to shutdown or sleep mode. For example, if it is ECU19 of the engine control system, the power self-holding function activates after the vehicle power switch from ACC or IG to +B power, thereby storing various engine control-related data acquired during vehicle operation as a log.

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

[0522] An authentication token is assigned to each piece of 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 that ECU(ID), and the differential data. Here, in the case of canceling the application rewrite midway, the write data used for writing back (rolling back) to the old version can also be included in the recompiled data.

[0523] As information associated with application rewriting, the rewrite specification data provided by the OEM includes information that can identify the target ECU 19, information that can determine the rewrite order when there are multiple target ECUs 19, and information that can determine the rollback method described later. The rewrite specification data defines the actions associated with rewriting in DCM 12, CGW 13, and the target ECU 19. The rewrite specification data is divided into DCM-specific rewrite specification data used by DCM 12 and CGW-specific rewrite specification data used by CGW 13.

[0524] 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 filename. The ECU information includes the address information referenced when sending the update program (write data) for each ECU 19 to CGW 13, corresponding to the number of ECUs 19 to be rewritten. Specifically, the ECU information includes at least: the ECU ID (ECU(ID)), the reference address for obtaining the update program (update program retrieval address), the update program size, the reference address for obtaining the rollback program (rollback program retrieval address), and the rollback program size. The rollback program is used to revert the application to the original version of the program (write data) when the application rewrite is canceled midway.

[0525] 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 rewrite, and ECU information. In addition, the rewrite specification data used by CGW may also include rewrite order information and display scene information. Group information indicates the group to which the rewrite target ECU19 belongs and the rewrite order. For example, the first group specifies that the application content should be rewritten in the order of ECU(ID1), ECU(ID2), and ECU(ID3), while the second group specifies that the application content should be rewritten in the order of ECU(ID4), ECU(ID5), and ECU(ID6). The bus load table will be discussed later. Figure 136 The table shown will be explained in detail later. Battery load indicates the lower limit of the battery capacity that can be allowed in the vehicle's battery 40. Vehicle status at the time of rewrite indicates the conditions under which the rewrite was performed.

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

[0527] The connection bus indicates the bus connected to ECU19. The power connection indicates the power line connected to ECU19. The security access key information indicates the key information used for authentication by CGW13 to access the target ECU19, including random values ​​or unique information, key mode, and decoding operation mode. The memory type indicates whether the memory installed on the target ECU19 is a single-sided independent memory, a single-sided suspended memory (also known as an analog two-sided memory), or a two-sided memory. The rewriting method indicates whether it is a power-based self-holding rewriting or a power-controlled rewriting. The power self-holding time indicates the duration of power self-holding when the rewriting method is power-based self-holding. The rewriting face information indicates which face is the active face and which face is the inactive face. The active face is also called the startup face, and the inactive face is also called the rewriting face.

[0528] The updater version indicates the version of the updater. The updater retrieval address indicates the address of the updater. The updater size indicates the data size of the updater. The rollback version indicates the version of the rollback program. The rollback retrieval address indicates the address of the rollback program. The rollback size indicates the data size of the rollback program. The data type to be written indicates whether the written data is differential data or all data. In addition, the rewrite specification data may contain system-specific information besides these information.

[0529] If DCM12 obtains rewrite specification data for DCM, it parses the obtained rewrite specification data for DCM. If DCM12 parses the rewrite specification data for DCM, it obtains write data from the address where the update program of the rewrite target ECU19 is stored, and controls the transmission of the obtained write data to CGW13 and other rewrite-related actions.

[0530] If CGW13 obtains the rewrite specification data for CGW, it parses the obtained rewrite specification data for CGW. If CGW13 parses the rewrite specification data for CGW, it controls the following rewrite-related actions based on the parsing result, such as requesting the DCM12 to transmit a specified amount of the update program for the target ECU19, or distributing the write data to the target ECU19 in a specified order.

[0531] The aforementioned re-edited data is registered in file server 8, along with distribution specification data provided by the OEM. The distribution specification data provided by the OEM defines the actions associated with the display of various screens on display terminal 5. For example... Figure 45 As shown, the distribution specification data includes language information, display statements, package information, image data, display modes, and display control programs.

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

[0533] If file server 8 registers recompiled data and distribution specification data, it encrypts the registered recompiled data and generates a distribution packet storing a packet authentication token for the authentication packet, the encrypted recompiled data, and the distribution specification data. The authentication token is data assigned to verify the integrity of the recompiled data and distribution specification data, and is generated, for example, based on key information associated with CGW13, the recompiled data, and the distribution specification data. If file server 8 receives a download request for the distribution packet from an external source, it sends the distribution packet to DCM12. Additionally, in... Figure 42 The example illustrates a scenario where file server 8 generates a distribution package containing recompiled data and distribution specification data, and sends both the recompiled data and distribution specification data to DCM 12 as a single file. However, it is also possible to send the recompiled data and distribution specification data to DCM 12 as separate files. That is, file server 8 can first send the distribution specification data to DCM 12, and then send the recompiled data to DCM 12. In this case, authentication characters can be assigned to the distribution specification data and the recompiled data separately.

[0534] like Figure 46 As shown, if DCM12 downloads a distribution package from file server 8, it uses the packet authentication token stored in the downloaded distribution package to verify the integrity of the encrypted recompiled data. If the verification result is positive, DCM12 decodes the encrypted recompiled data. If DCM12 decodes the encrypted recompiled data, it decapsulates (hereinafter also referred to as unpacking) the decoded recompiled data, dividing it into encrypted differential data and authentication token, rewritten specification data used by DCM, and rewritten specification data used by CGW, and extracts them. Figure 46The example illustrates the segmentation of encrypted differential data and authentication tokens for ECU (ID1), ECU (ID2), ECU (ID3), rewritten specification data for DCM, and rewritten specification data for CGW, and the extraction of these data.

[0535] Next, refer to Figures 47 to 58 The flash memory 33d of ECU19 will be explained. Based on the memory structure, the flash memory 33d of ECU19 is divided into a single-sided independent memory with one flash memory side, a single-sided suspended memory with two simulated flash memory sides, and a two-sided memory with two actual flash memory sides. Hereinafter, ECU19 equipped with a single-sided independent memory will be referred to as a single-sided independent memory ECU, ECU19 equipped with a single-sided suspended memory will be referred to as a single-sided suspended memory ECU, and ECU19 equipped with two-sided memory will be referred to as a two-sided memory ECU.

[0536] A single-sided independent memory has a structure with flash memory on one side, therefore there is no concept of an "application side" and a "non-application side," and the application cannot be rewritten during application execution. On the other hand, a single-sided suspended memory and a two-sided memory have a structure with flash memory on two sides, therefore there is a concept of an "application side" and a "non-application side," and the application on the non-application side can be rewritten during the execution of the application on the application side. A two-sided memory has a structure with flash memory on two completely separate sides, therefore the application can be rewritten at any time, such as when the vehicle is in motion. A single-sided suspended memory is a pseudo-two-sided partitioned single-sided independent memory structure, therefore the timing of normal read and write operations is restricted; the application cannot be rewritten while the vehicle is in motion, but it can be rewritten while the IG power is disconnected and the vehicle is parked.

[0537] In addition, the single-sided independent memory, the single-sided suspended memory, and the dual-sided memory each contain embedded reprogrammed firmware (hereinafter referred to as embedded type) and downloadable reprogrammed firmware (hereinafter referred to as downloadable type), respectively. Reprogrammed firmware is firmware used to rewrite application programs.

[0538] The structure of each flash memory is described below.

[0539] (A) 1-sided independent memory

[0540] (A-1) Embedded, single-sided independent memory

[0541] Reference Figure 47 and Figure 48The embedded single-sided independent memory is described below. The embedded single-sided independent memory has a differential engine operating area, an application area, and a startup program area. The application area contains version information, parameter data, the application program, firmware, and a normal time vector table. The startup area contains the startup program, progress status point 2, progress status point 1, startup determination information, wireless reprogramming firmware, wired reprogramming firmware, startup determination program, and a startup time vector table.

[0542] like Figure 47 As shown, when the microcomputer 33 performs routine operations such as vehicle control processing and diagnostic processing, it executes a startup determination program, refers to the startup vector table and the normal time vector table to explore the starting address, and executes the specified address of the application program.

[0543] When microcomputer 33 performs the rewriting action of the application rewriting process, it performs wireless or wired firmware recompilation instead of executing the application. Figure 48 This indicates that the application's actions are rewritten using differential data as an updater. For example... Figure 48 As shown, the microcomputer 33 temporarily stores the application program as old data in the differential engine's operating area. The microcomputer 33 reads the old data temporarily stored in the differential engine's operating area and, through the differential engine included in the embedded reprogrammed firmware, restores the new data based on the read old data and the differential data stored in RAM 33c. If the microcomputer 33 generates new data based on the old data and the differential data, it writes the new data to a predetermined address in memory, thus rewriting the application program.

[0544] (A-2) Downloadable 1-sided independent memory

[0545] Reference Figure 49 and Figure 50 The downloadable type with a single independent memory will be described. Compared to the embedded type described above, the downloadable type differs in the following aspects: wireless re-editing firmware and wired re-editing firmware are downloaded from an external source, and after the application is rewritten, the wireless re-editing firmware and wired re-editing firmware are deleted. In the case of updating the application wirelessly, for example... Figure 42 The reprogramming data shown includes the wireless reprogramming firmware executed by each ECU 19. ECU 19 receives the wireless reprogramming firmware for its own ECU from CGW 13 and saves the received wireless reprogramming firmware for its own ECU in RAM.

[0546] like Figure 49 As shown, when the microcomputer 33 performs normal operations such as vehicle control processing and diagnostic processing, it executes a startup determination program in the same way as the embedded type, refers to the startup vector table and the normal time vector table to explore the starting address, and executes the address specified by the application program.

[0547] like Figure 50 As shown, when the microcomputer 33 performs the rewrite operation of the application rewrite process, it temporarily stores the application 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 RAM 33c through the differential engine included in the recompiled firmware downloaded from the outside. If the microcomputer 33 generates new data based on the old data and the differential data, it writes the new data to rewrite the application.

[0548] (B) 1-sided suspended memory

[0549] (B-1) Embedded 1-sided suspended memory

[0550] Reference Figure 51 and Figure 52 The embedded single-sided suspended memory is described below. The embedded single-sided suspended memory has a differential engine operating area, an application program area, and a boot program area. The reprogrammed firmware, which is updated, is configured in the boot program area, similar to the single-sided independent memory, and is an object other than the target of the program update. The application program area, the target of the program update, appears to have an A side and a B side, with version information, the application program, and a normal time vector table configured on the A side and B side, respectively. The boot program area contains the boot program, reprogrammed firmware, reprogrammed time vector table, boot face determination function, boot face determination information, and boot time vector table.

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

[0552] like Figure 52As shown, when microcomputer 33 performs the rewrite operation of the non-application application, it temporarily stores the non-application application as old data in the differential engine working area. 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 RAM 33c through the differential engine in the embedded rewrite firmware. If microcomputer 33 generates new data based on the old data and the differential data, it writes the new data to the non-application application and rewrites the non-application application. Figure 52 The example shown illustrates the case where surface A is the application surface and surface B is the non-application surface.

[0553] (B-2) Download-type 1-sided suspended memory

[0554] Reference Figure 53 and Figure 54 The downloadable type with one-sided suspended memory will be explained. Compared with the embedded type described above, the downloadable type differs in the following aspects: the recompiled firmware and recompilation time vector table are downloaded from an external source, and after the application is rewritten, the recompiled firmware and recompilation time vector table are deleted.

[0555] like Figure 53 As shown, when the microcomputer 33 performs routine operations such as vehicle control processing and diagnostic processing, it executes a startup program similar to the embedded type. Through the startup surface determination function, it determines the age of the startup surface based on the determination information of surfaces A and B, identifying which surface is the application surface. If the microcomputer 33 determines surface A as the application 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 the microcomputer 33 determines surface B as the application 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.

[0556] like Figure 54 As shown, when microcomputer 33 performs the rewrite operation of the application rewrite process, it temporarily stores the non-application-side application data as old data in the differential engine working area. 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 RAM 33c through the differential engine in the recompiled firmware downloaded from the outside. If microcomputer 33 generates new data based on the old data and the differential data, it writes the new data to rewrite the application. Figure 54 The example illustrates a scenario where side A is the application side and side B is the non-application side. In this way, the application program on side A can be executed in the suspended memory on side 1, while the application program on side B can be rewritten in the background.

[0557] (C) 2-sided memory

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

[0559] Reference Figure 55 and Figure 56 The embedded two-sided memory is described below. The embedded single-sided independent memory has an application program area and a rewrite program area on side A, an application program area and a rewrite program area on side B, and a boot program area. The boot program is configured in a non-rewriteable manner in the boot area. The boot program includes boot switching functionality and a boot time vector table. Version information, parameter data, application programs, firmware, and a normal time vector table are configured in each application program area. Each rewrite program area contains a program for controlling rewriting, rewrite progress management information 2, rewrite progress management information 1, boot face determination information, wireless rewrite firmware, wired rewrite firmware, and a boot time vector table. The boot area contains the boot program, boot switching functionality, and a boot time vector table.

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

[0561] like Figure 56 As shown, when the microcomputer 33 performs the rewrite operation of the non-application application rewriting process, it temporarily stores the non-application application 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 RAM 33c through the differential engine in the embedded rewrite 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-application area to rewrite the non-application application. In addition, the old data temporarily stored in the differential engine working area can be either the application in the application area or the non-application application. In this case, if the application in the application area is the target, the non-application data is eliminated before writing the new data. Here, if the rewrite data obtained from outside the vehicle is not differential data but overall data (all data), the obtained rewrite data is written to the non-application area as new data. Figure 56The example illustrates the case where side A is the application side and side B is the non-application side. Furthermore, old data temporarily stored in the differential engine's operating area can be either application data from the application side or application data from the non-application side. When it's necessary to ensure consistent execution addresses for the application data, the application data from the non-application side is stored as old data.

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

[0563] Reference Figure 57 and Figure 58 The downloadable two-sided memory will be described. Compared with the embedded type described above, the downloadable type differs in the following aspects: wireless reprogramming firmware and wired reprogramming firmware are downloaded from an external source, and after the application is rewritten, the wireless reprogramming firmware and wired reprogramming firmware are deleted.

[0564] like Figure 57 As shown, when the microcomputer 33 performs normal operations such as vehicle control processing and diagnostic processing, as well as when it performs rewriting operations of non-application surface application rewriting processing, it is the same as the embedded type. It executes the startup program, determines the old and new based on the startup surface determination information of surface A and surface B, determines which of surface A and surface B is the application surface, and executes the application of the application surface to perform application processing.

[0565] like Figure 58 As shown, when the microcomputer 33 performs the rewrite operation of the application rewrite process, it temporarily stores the non-application-side application 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 RAM 33c by the re-compiled firmware downloaded from the outside. If the microcomputer 33 generates new data based on the old data and the differential data, it writes the new data to the non-application-side application and rewrites the non-application-side application. In addition, the old data temporarily stored in the differential engine working area can be either the application-side application or the non-application-side application. In the case where the application-side application is the target, the non-application-side data is eliminated before the new data is written. Here, if the re-compiled data obtained from outside the vehicle is not differential data but overall data (all data), the obtained re-compiled data is written to the non-application-side as new data. Figure 58 The example illustrates a scenario where side A is the application side and side B is the non-application side. Furthermore, old data temporarily stored in the differential engine's operating area can be applied to either the application side or the non-application side. Thus, in the two-sided memory, the application side A can be executed, while the application side B can be rewritten in the background.

[0566] As described above, in any structure, whether embedded or downloadable, the application and a rewrite program for rewriting the application are configured in each application area. Additionally, in Figure 56 and Figure 58 In this example, the application is shown as the refactoring object, but the rewriting program can also be shown as the refactoring object. Additionally, if it is desired that the rewriting program cannot be rewritten, it can be configured in the startup area. For example, a program for wired rewriting can also be configured in the startup area, enabling distributors and others to reliably perform wired rewriting via tool 23.

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

[0568] If both the modified ECU (ID1) and the modified ECU (ID2) are determined to have received a version notification signal transmission request from the master device 11, the transmission condition for the version notification signal is deemed met. If the transmission condition for the version notification signal is met, the modified ECU (ID1) sends a version notification signal to the master device 11 containing version information of its stored application and its own ECU (ID). If the master device 11 receives the version notification signal from the modified ECU (ID1), it sends the received version notification signal to the central device 3. Similarly, if the transmission condition for the version notification signal is met, the modified ECU (ID2) sends a version notification signal to the master device 11 containing the version of its stored application and its own ECU (ID). If the master device 11 receives the version notification signal from the modified ECU (ID2), it sends the received version notification signal to the central device 3.

[0569] If the central device 3 receives version notification signals from the ECUs (ID1) and (ID2) to be rewritten, it determines the application version and ECU (ID) contained in the received version notification signal, and determines whether write data should be distributed to the ECU 19 to which the version notification signal originated. The central device 3 determines the current application version of the ECU 19 based on the version notification signals received from the ECUs, and compares this current application version with the latest version managed.

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

[0571] If the central device 3 determines that the application stored in the rewrite target ECU 19 needs to be updated, it notifies the portable terminal 6 of the content that needs to be updated. If the portable terminal 6 notifies that the content needs to be updated, it displays a distribution screen (A1). The distribution screen is the same as the activity notification screen described later. The user can confirm the content that needs to be updated by viewing the distribution screen displayed on the portable terminal 6 and can choose whether to update.

[0572] If the user selects updated content (A2) on the portable terminal 6, the portable terminal 6 notifies the central device 3 of the download request for the distribution package. If the central device 3 is notified of the download request for the distribution package from the portable terminal 6, it sends the distribution package to the main device 11.

[0573] If the master device 11 downloads a distribution package from the central device 3, it begins packet authentication processing (B1) for the downloaded distribution package. After authenticating the distribution package, the master device 11 begins write data extraction processing (B2). The master device 11 extracts write data from the distribution package; if the write data extraction processing is complete, it sends a download completion notification signal to the central device 3.

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

[0575] If the user sets the rewrite start time (A4) of the vehicle-side application in the portable terminal 6, the portable terminal 6 notifies the central device 3 of the rewrite start time. If the central device 3 is notified of the rewrite start time from the portable terminal 6, it stores the user-set rewrite start time as the set start time. If the current time reaches the set start time (A5), the central device 3 sends a rewrite instruction signal to the main device 11.

[0576] If the main device 11 receives a rewrite instruction signal from the central device 3, it sends a power start request to the power management ECU 20, causing the ECU to be rewritten (ID1), the ECU to be rewritten (ID2), and other ECUs to switch from the stop state or the dormant state to the start state (X1).

[0577] The master device 11 begins distributing write data to the target ECU (ID1) and instructs the target ECU (ID1) to write the data. If the target ECU (ID1) begins receiving write data from the master device 11 and is instructed to write the data, it begins writing the data and starts the program rewriting process (C1). If the target ECU (ID1) finishes receiving write data from the master device 11, finishes writing the data, and finishes the program rewriting process, it sends a rewriting completion notification signal to the master device 11.

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

[0579] If the central device 3 receives a rewrite completion notification signal from the main device 11, it notifies the portable terminal 6 that the application rewrite is complete. If the portable terminal 6 is notified from the central device 3 that the application rewrite is complete, it displays a rewrite completion notification screen (A6). The user can confirm the completion of the application rewrite by viewing the rewrite completion notification screen on the portable terminal 6, thus activating the synchronization settings.

[0580] If the user sets up synchronization implementation (A7) in the portable terminal 6, that is, the user agrees to the activation of the new program, the portable terminal 6 notifies the central device 3 of the synchronization implementation. If the central device 3 is notified of the synchronization implementation from the portable terminal 6, it sends a synchronization switching instruction signal to the master device 11. If the master device 11 receives the synchronization switching instruction signal from the central device 3, it distributes the received synchronization switching instruction signal to the ECU to be rewritten (ID1) and the ECU to be rewritten (ID2).

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

[0582] If the master device 11 receives a switchover completion notification signal from both the target ECU (ID1) and the target ECU (ID2), it distributes a version readout signal to both. If the target ECU (ID1) and the target ECU (ID2) receive the version readout signal from the master device 11, they read the version (C3, D3) of the application to be used later and send a latest version notification signal containing the readout version to the master device 11. By receiving the version notification signals from the target ECU (ID1) and the target ECU (ID2), the master device 11 checks the software version or performs a rollback as needed.

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

[0584] The master device 11 sends a latest version notification signal to the central device 3. If the central device 3 receives the latest version notification signal from the master device 11, it determines the latest version of the application for both the target ECU (ID1) and the target ECU (ID2) based on the received signal and notifies the portable terminal 6 of this determined latest version. If the portable terminal 6 is notified of the latest version from the central device 3, it displays a latest version notification screen (A8) indicating the latest version. The user can confirm the latest version and the activation completion by viewing the latest version notification screen on the portable terminal 6.

[0585] Next, refer to Figures 62 to 65 Timing diagrams illustrating the operations of DCM12, CGW13, and the target ECU19 during application rewriting are provided. Furthermore, the following scenarios are explained: rewriting the application programs of two memory ECUs while the vehicle is in motion, i.e., when the IG switch 42 is turned on by the user; and rewriting the application programs of one suspended memory ECU and one independent memory ECU while the vehicle is parked after the IG switch 42 is turned off by the user. Additionally, the scenarios of rewriting the application programs via power control and via power self-holding are also explained.

[0586] (A) In the case of rewriting the application via power control

[0587] Reference Figure 62 and Figure 63 The following explains the case of rewriting the application program via power control. Power control-based application rewriting refers to a structure that controls the rewriting action based on power switching without using a power self-holding circuit. If the vehicle power supply is switched from +B power to IG power by the user switching the IG switch from off to on, then DCM12, CGW13, the 2-sided memory ECU, the 1-sided suspended memory ECU, and the 1-sided independent memory ECU will each begin their normal operation (t1).

[0588] If DCM12 is notified by central device 3 to start downloading, it transitions from normal operation to downloading, beginning the download of the distribution package from central device 3 (t2). DCM12 can perform normal operations and download the distribution package in the background. Once DCM12 has completed downloading the distribution package from central device 3, it reverts to normal operation (t3).

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

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

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

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

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

[0594] If, after the vehicle power supply is switched from IG power to +B power by the user switching the IG switch from ON to OFF (t10), and at that moment the two-sided memory ECU completes the application rewriting, then CGW13 sends a power-on request to the power management ECU20. If the vehicle power supply is switched from +B power to IG power by sending the power-on request to the power management ECU20 via CGW13, then DCM12 restarts the data transmission / central communication operation, and CGW13 restarts the main reprogramming operation, starting to distribute write data to the one-sided suspended memory ECU and the one-sided independent memory ECU. If the one-sided suspended memory ECU and the one-sided independent memory ECU start receiving write data from CGW13 respectively, then the operation transitions from normal operation to boot processing, and the installation phase begins in the boot process (t11). That is, the one-sided suspended memory ECU and the one-sided independent memory ECU do not perform installation in parallel with the normal operation, but rather during the boot process when the application has not yet been activated.

[0595] If a single-sided suspended memory ECU starts rewriting an application, the rewriting process is interrupted if the IG switch 42 is switched from off to on by user operation before the rewriting is completed. Instead of restoring the non-use side (side B) where the application rewriting was interrupted to the start side, the single-sided suspended memory ECU restores the use side (side A) to the start side. If a single-sided independent memory ECU starts rewriting an application, the rewriting process continues even if the IG switch 42 is switched from off to on by user operation before the rewriting is completed. This is because if the single-sided independent memory ECU is interrupted during the application rewriting process, it cannot return to normal operation. Preferably, after the application rewriting of the single-sided independent memory ECU begins, user operation on the IG switch 42 is disabled until the application rewriting is completed.

[0596] If a 1-sided suspended memory ECU completes the writing of data and the rewriting of the application, it ends the installation phase during startup and transitions to the activation waiting phase. That is, a 1-sided suspended memory ECU will not start on the new side (side B) with the rewritten application while not in the activation phase; it will remain on the old side (side A). If a 1-sided independent memory ECU completes the writing of data and the rewriting of the application, it ends the installation phase during startup and becomes an activation waiting phase (t12).

[0597] If the power management ECU 20 switches the vehicle power supply from IG power to +B power according to the activation instruction from CGW13, the two-sided memory ECU and the one-sided suspended memory ECU switch from the old side to the new side respectively, start on the new side, and begin the subsequent phase (hereinafter also referred to as the activation phase) during the new side startup. The one-sided independent memory ECU starts to restart, and the activation phase (t13, t14) begins during the restart after installation is completed. During activation, it is confirmed that the new program is started correctly, and version information is notified to CGW13, etc.

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

[0599] Subsequently, if the vehicle power supply is switched from +B power to IG power by the user switching the IG switch from off to on, the two-sided memory ECU and the one-sided suspended memory ECU will start the new application with the new side (side B) as the starting side, and the one-sided independent memory ECU will start the new application (t16).

[0600] (i) In the case of rewriting the application via power self-holding

[0601] Reference Figure 64 and Figure 65 The case of rewriting the application via power self-holding is explained. Rewriting the application based on power self-holding refers to a structure that uses a power self-holding circuit to control the rewriting action. If the vehicle power supply is switched from +B power to IG power by the user switching the IG switch from off to on, then DCM12, CGW13, 2-sided memory ECU, 1-sided suspended memory ECU, and 1-sided independent memory ECU will start their normal operation (t21).

[0602] If DCM12 is notified from central device 3 that a download has begun (i.e., an update based on a new program exists), it transitions from normal operation to download operation and begins downloading the distribution package from central device 3 (t22). Once DCM12 has completed downloading the distribution package from central device 3, it reverts to normal operation (t23).

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

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

[0605] In the 2-sided memory ECU, during application rewriting, if the vehicle power supply is switched from IG power to +B power by the user switching the IG switch from ON to OFF (t25), then after switching the vehicle power supply from IG power to +B power, DCM12 continues data transmission / central communication operation, CGW13 continues main reprogramming operation, the 2-sided memory ECU continues the installation phase, and application rewriting continues. If a preset time, i.e., a self-holding period, has elapsed after the vehicle power supply has switched from IG power to +B power, then DCM12 interrupts data transmission / central communication operation, CGW13 interrupts main reprogramming operation, the 2-sided memory ECU interrupts the installation phase, and application rewriting is interrupted (t26). That is, after the IG switch 42 is turned off, installation continues until the specified time has elapsed, powered by the vehicle battery 40.

[0606] Then, if the vehicle power supply is switched from +B power to IG power by the user switching the IG switch from off to on, the DCM12 restarts the data transmission / central communication operation, the CGW13 restarts the main operation reprogramming, the two-sided memory ECU restarts the installation phase, and the application rewriting restarts (t27). That is, when the vehicle power supply is switched from IG power to +B power by the user switching the IG switch from on to off, and then switched from +B power to IG power by the user switching the IG switch from off to on, the two-sided memory ECU repeats the interruption and restart of the application rewriting every time a trip occurs (t28~t30). However, after the vehicle power supply is switched from IG power to +B power until the self-hold period has elapsed, the DCM12 continues the data transmission / central communication operation, the CGW13 continues the main operation reprogramming, the two-sided memory ECU continues the installation phase, and the application rewriting continues.

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

[0608] If the vehicle power supply is switched from IG power to +B power by the user switching the IG switch from on to off, and the application is rewritten in the two-sided memory ECU at that moment, then the one-sided suspended memory ECU and the one-sided independent memory ECU will switch from normal operation to startup processing, and the installation phase (t32) will begin in the startup processing.

[0609] If the suspended memory ECU and the independent memory ECU have completed writing the data and rewriting the application program, the installation phase ends during the startup process (t33). If the vehicle power is switched from +B power to IG power by sending a power start request to the power management ECU 20 via CGW13, the DCM12 restarts the data transmission / central communication operation (t34).

[0610] If a 1-sided suspended memory ECU completes the writing of data and the rewriting of the application program, it transitions from the boot process to the waiting-to-activation phase. That is, while not in the activation phase, a 1-sided suspended memory ECU will not boot from the newly rewritten application side (side B), but will remain on the old side (side A). If a 1-sided independent memory ECU completes the writing of data and the rewriting of the application program, it ends the installation phase during the boot process and becomes waiting to activate (t35).

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

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

[0613] Subsequently, if the vehicle power supply is switched from +B power supply to IG power supply by the user switching the IG switch from off to on, the 2-sided memory ECU and the 1-sided suspended memory ECU will start the new application with the new side (side B) as the starting side, and the 1-sided independent memory ECU will start the new application (t39).

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

[0615] Next, refer to Figures 66 to 82 The screen displayed on display terminal 5 will be described. For example... Figure 66As shown, in the structure of rewriting the application of the target ECU19 via OTA, there are stages of activity notification, download, installation, and activation. Activity notification refers to notification of program updates. For example, if the central device 3 determines that an application update is needed, the main device 11 downloads and distributes specification data, etc., as part of the activity notification. The display terminal 5 displays screens at each stage as the application rewriting progresses. Furthermore, the screen displayed on the in-vehicle display 7 will be explained here.

[0616] like Figure 67 As shown, in the normal state before an event notification, CGW13 displays, for example, a navigation screen 501, such as a known route launch screen, on the in-vehicle display 7. If an event notification is generated from this state, then... Figure 32 As shown, CGW13 displays an activity notification icon 501a in the lower right corner of the navigation screen 501, indicating the generation of activity notifications. Users can be aware of the generation of activity notifications related to application updates by confirming the display of the activity notification icon 501a.

[0617] If the user interacts with the activity notification icon 501a from this state, then as follows: Figure 69 As shown, CGW13 displays an activity notification screen 502 on the navigation screen 501. However, CGW13 is not limited to displaying the activity notification screen 502; other display formats can also be used. For example, CGW13 may display a message stating "A usable software update exists" on the activity notification screen 502 to notify the user of the activity notification, and display a "Confirm" button 502a and a "Later" button 502b, awaiting user action. In this case, by pressing the "Confirm" button 502a, the user can proceed to the next screen for starting the application rewriting. Furthermore, if the user presses the "Later" button 502b, CGW13 will clear the activity notification screen 502 and return to the previous screen. Figure 32 The screen shown displays the activity notification icon 501a.

[0618] If the user clicks the "Confirm" button 502a from this state, then as follows Figure 70As shown, CGW13 switches the display from navigation screen 501 to download agreement screen 503, and displays download agreement screen 503 on the in-vehicle display 7. On download agreement screen 503, CGW13 notifies the user of the activity ID and update name, and displays 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, view the download details by pressing the "Confirm Details" button 503b, and refuse the download and return to the previous screen by pressing the "Back" button 503c. After pressing the "Back" button 503c, the user can access the screen for starting the download by pressing the activity notification icon 501a.

[0619] If the user clicks the "Confirm Details" button 503b from the state where the download agreement screen 503 is displayed, then as follows Figure 71 As shown, CGW13 switches the display content of the download agreement screen 503, causing the in-vehicle display 7 to show download details. As download details, CGW13 uses the received distribution specification data to display the update content, the time spent on the update, and the limitations of the vehicle functions accompanying the update. Additionally, if the user operates the "Download Start" button 503a, CGW13 begins downloading the distribution package via DCM12. Parallel to the start of the download, as... Figure 72 As shown, CGW13 will switch the display from the download agreement screen 503 to the navigation screen 501, causing the in-vehicle display 7 to re-show the navigation screen 501. A download in progress icon 501b will be displayed in the lower right corner of the navigation screen 501. Users can monitor the download progress of the distribution package by confirming the display of the download in progress icon 501b.

[0620] If the user downloads the running icon 501b from this state, then as follows: Figure 73 As shown, CGW13 will switch the download progress screen from navigation screen 501 to download progress screen 504, causing the in-vehicle display 7 to show download progress screen 504. In download progress screen 504, CGW13 notifies the user that the download is in progress and displays a "Confirm Details" button 504a, a "Back" button 504b, and a "Cancel" button 504c, awaiting user input. In this situation, the user can access download progress details by pressing the "Confirm Details" button 504a and interrupt the download by pressing the "Cancel" button 504c.

[0621] If the download is complete, then as follows Figure 74As shown, CGW13 displays a download completion notification screen 505 on navigation screen 501. In the download completion notification screen 505, CGW13 notifies the user of the download completion, for example, by displaying a message such as "Download complete, software update is now possible," and displays a "Confirm" button 505a and a "Later" button 505b, awaiting user input. In this case, the user can enter the screen for starting the installation by pressing the "Confirm" button 505a.

[0622] If the user clicks the "Confirm" button 505a from this state, then as follows: Figure 75 As shown, the CGW13 will switch from the navigation screen 501 to the installation agreement screen 506, displaying the installation agreement screen 506 on the in-vehicle display 7. On the installation agreement screen 506, the CGW13 informs the user of the required time, constraints, and schedule settings related to the installation, and displays the "Update Now" button 506a, the "Schedule Update" button 506b, and the "Back" button 506c, awaiting user input. In this case, the user can start the installation immediately by pressing the "Update Now" button 506a. Alternatively, the user can schedule the installation by pressing the "Schedule Update" button 506b, setting the desired installation time. Furthermore, the user can reject the installation and return to the previous screen by pressing the "Back" button 506c. After pressing the "Back" button 506c, the user can access the screen for starting the installation by pressing the download in progress icon 501b.

[0623] If the user clicks the "Update Now" button 506a from this state, then as follows: Figure 76 As shown, CGW13 switches the display content of the installation agreement screen 506, causing the vehicle display 7 to show the installation details. In this installation agreement screen 506, CGW13 accepts the installation request and notifies the user to begin the installation process.

[0624] If CGW13 installation begins, then as follows: Figure 77 As shown, the display will switch from the installation agreement screen 506 to the navigation screen 501, causing the vehicle display 7 to re-show the navigation screen 501. An installation progress icon 501c will be displayed in the lower right corner of the navigation screen 501, indicating that the installation is in progress. Users can monitor the installation process by confirming the display of the installation progress icon 501c.

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

[0626] If CGW13 is installed successfully, then... Figure 79 As shown, the display will switch from navigation screen 501 to activation agreement screen 508, causing the in-vehicle display 7 to show activation agreement screen 508. In activation agreement screen 508, CGW13 notifies the user of the activation content and displays a "back" button 508a and an "OK" button 508b, awaiting user action. In this case, the user can refuse activation and return to the previous screen by pressing the "back" button 508a. Alternatively, the user can agree to activation by pressing the "OK" button 508b. Furthermore, after pressing the "back" button 508a, the user can enter the activation screen by pressing the installation in progress icon 501c. Additionally, these displays and agreement confirmations may be omitted depending on user settings and program context.

[0627] If the user connects the IG power supply after pressing the "OK" button 508b, then as follows: Figure 80 As shown, CGW13 displays an activation completion notification screen 509 on navigation screen 501. In the activation completion notification screen 509, CGW13 notifies the user of the activation completion, for example, by displaying a "Software update complete" message, and displays an "OK" button 509a and a "Confirm Details" button 509b, awaiting user action. In this case, the user can close the activation completion notification screen 509 by pressing the "OK" button 509a, and can view the activation completion details by pressing the "Confirm Details" button 509b.

[0628] If the user clicks the "OK" button 509a from this state, then as follows: Figure 81 As shown, the CGW13 will switch from the navigation screen 501 to the confirmation operation screen 510, causing the in-vehicle display 7 to show the confirmation operation screen 510. On the confirmation operation screen 510, the CGW13 notifies the user that activation is complete and displays a "Details Confirmation" button 510a and an "OK" button 510b, awaiting user input. In this case, the user can display activation completion details by pressing the "Details Confirmation" button 510a.

[0629] If the user clicks the "Confirm Details" button 510a from this state, then as follows Figure 82As shown, CGW13 switches the display content of the confirmation operation screen 510, causing the vehicle display 7 to show the activation completion details. CGW13 displays the added functions and changed functions as update details, and displays the "OK" button 510b. CGW13 determines that the user has confirmed the software update is complete based on the user's operation of the "OK" buttons 509a and 510b.

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

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

[0632] (1) Processing for determining the sending of the distribution packet

[0633] (2) Download determination and processing of the distribution package

[0634] (3) Data transmission determination process

[0635] (4) Data Acquisition and Determination Processing

[0636] (5) Installation instruction determination processing

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

[0638] (7) Validation processing of written data

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

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

[0641] (10) File transfer control processing

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

[0643] (12) Instruction processing for activation request

[0644] (13) Activated execution control processing

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

[0646] (15) Rollback execution control processing

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

[0648] (17) Integration determination of difference data

[0649] (18) Rewritten execution control processing

[0650] (19) Session establishment process

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

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

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

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

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

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

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

[0658] The central device 3, DCM12, CGW13, ECU19, and vehicle display 7 are structures that perform the characteristic processes described above (1) to (26) respectively, and have the following functional modules.

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

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

[0661] If the write data transmission unit 64 extracts write data from the distribution packet via the write data extraction unit 63, it transmits the extracted write data to the CGW13. If the rewrite specification data extraction unit 65 downloads a distribution packet from the central device 3 via the distribution packet download unit 62, it extracts rewrite specification data from the downloaded distribution packet. If the rewrite specification data transmission unit 66 extracts rewrite specification data from the distribution packet via the rewrite specification data extraction unit 56, it transmits the extracted rewrite specification data to the CGW13. In addition to the above structure, the DCM12, as a structure for performing characteristic processing, includes a distribution packet download determination unit 67 and a write data transmission determination unit 68. The functional modules for performing characteristic processing will be described later.

[0662] like Figure 85 and Figure 86 As shown, CGW13 includes an acquisition request sending unit 71, a write data acquisition unit 72 (equivalent to an update data storage unit), a write data distribution unit 73 (equivalent to an update data distribution unit), a rewrite specification data acquisition unit 74, and a rewrite specification data parsing unit 75. The write data acquisition unit 72 acquires write data from the DCM12 by transmitting write data from the DCM12. If the write data is acquired by the write data acquisition unit 72, the write data distribution unit 73 distributes the acquired write data to the rewrite target ECU19 when it is a distribution opportunity for the write data. The rewrite specification data acquisition unit 74 acquires rewrite specification data from the DCM12 by transmitting rewrite specification data from the DCM12. If the rewrite specification data is acquired by the rewrite specification data acquisition unit 74, the rewrite specification data parsing unit 75 parses the acquired rewrite specification data.

[0663] In addition to the structure described above, the CGW13 includes, as a structure for performing characteristic processing, a write data acquisition determination unit 76, an installation instruction determination unit 77, a security access key management unit 78, a write data verification unit 79, a data storage surface information transmission control unit 80, a non-rewriteable power management unit 81, a file transfer control unit 82, a write data distribution control unit 83, an activation request instruction unit 84, a rewriteable object group management unit 85, a rollback execution control unit 86, a rewrite progress status display control unit 87, a progress status synchronization control unit 88, a display control information receiving control unit 89, a progress display screen display control unit 90, a program update reporting control unit 91, and a power self-holding execution control unit 92. The functional modules for performing characteristic processing will be described later.

[0664] like Figure 87 As shown, ECU 19 includes a write data receiving unit 101 and a program rewriting unit 102. The write data receiving unit 101 receives write data from CGW 13. If the program rewriting unit 102 receives write data from CGW 13 through the write data receiving unit 101, it writes the received write data to flash memory to rewrite the application program. In addition to the above-described structure, ECU 19 also includes a differential data integration determination unit 103, a rewriting execution control unit 104, a session establishment unit 105, a re-pilot determination unit 106, an activation execution control unit 107, and a power self-holding execution control unit 108 as the structure for performing characteristic processing. The functional modules for performing characteristic processing will be described later.

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

[0666] The following will explain each of the above-mentioned treatments (1) to (26) in turn.

[0667] (1) Processing for determining whether to send the distribution packet; (2) Processing for determining whether to download the distribution packet.

[0668] Reference Figure 89 and Figure 90 The sending determination process of the distribution packets of the central device 3 is explained below, referring to... Figure 91 and Figure 92 The download determination process for the distribution packets of the main device 11 is explained.

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

[0670] If the update presence / absence determination unit 52b obtains software information through the software information acquisition unit 52a, it determines whether update data for the vehicle exists based on the obtained software information. Specifically, the update presence / absence determination unit 52b compares the version of the obtained software information with the latest version of the software information it manages, determines whether the two are consistent, and thus determines whether update data for the vehicle exists. If the update presence / absence determination unit 52b determines that the two are consistent, it determines that update data for the vehicle does not exist; if it determines that the two are inconsistent, it determines that update data for the vehicle exists.

[0671] If the update suitability determination unit 52c determines, through the update availability determination unit 52b, that update data for the vehicle exists, it then determines whether the vehicle's status is suitable for updating the program or other components in the distribution package. Specifically, the update suitability determination unit 52c determines whether the license agreement is valid, whether the vehicle's location is within the range pre-registered by the user, whether the vehicle's alarm function settings are valid, and whether fault information has been generated in the ECU 19, thereby determining whether the vehicle's status is suitable for downloading the distribution package. In other words, the update suitability determination unit 52c determines whether the vehicle is a vehicle for which an update might violate the user's intentions, or a vehicle for which even if the download is successful, the installation might fail.

[0672] If the update suitability determination unit 52c determines that the license agreement is established, the vehicle location is within the range pre-registered by the user, the vehicle's alarm function settings are enabled, and the vehicle is in a state where no fault information is generated for ECU 19, then the vehicle status 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 true: the license agreement is not established, the vehicle location is not within the range pre-registered by the user, the vehicle's alarm function settings are not enabled, or a fault information is generated for ECU 19, then the vehicle status is determined to be unsuitable for updating the program, etc., using the distribution package.

[0673] If the activity information sending unit 52d determines, through the update suitability determination unit 52c, that the vehicle status is suitable for updating the program, etc., using the distribution package, then it sends activity information to the main device 11. If the activity information sending unit 52d determines, through the update suitability determination unit 52c, that the vehicle status is not suitable for updating the program, etc., using the distribution package, then it does not send activity information to the main device 11. By performing the above determinations, the activity information sending unit 52d pre-stores information related to vehicles for which activity information has not been sent to the main device 11. Furthermore, the central device 3 can also display information related to vehicles for which activity information has not been sent to the main device 11.

[0674] Next, refer to Figure 90 The function of the packet transmission determination unit 52 of the central device 3 will be explained. The central device 3 executes the packet transmission determination procedure and performs packet transmission determination processing.

[0675] If the central device 3 initiates the packet delivery determination process, it acquires software information from the vehicle side (S101, equivalent to the software information acquisition step). That is, the central device 3 determines whether there is a software update for the vehicle. Based on the acquired software information, the central device 3 determines whether update data for the vehicle exists (S102, equivalent to the update existence determination step). If the central device 3 determines that update data for the vehicle exists (S102: "Yes"), it determines whether the vehicle status is suitable for updating the program, etc., using the packet delivery (S103, equivalent to the update suitability determination step). If the central device 3 determines that the vehicle status is suitable for updating the program, etc., using the packet delivery (S103: "Yes"), it sends activity information to the main device 11 (S104, equivalent to the activity information sending step), and ends the packet delivery determination process.

[0676] If the central device 3 determines that there is no update data for the vehicle (S102: "No"), it sends content that is not the recipient of the distribution package, i.e., content indicating that there is no application update (S105), and ends the distribution package sending determination process. If the central device 3 determines that the vehicle state is not suitable for updating the program, etc., using the distribution package (S103: "No"), it sends content that is not suitable for updating the program, etc., and the reason therefor to it to the main device 11 (S106), and ends the distribution package sending determination process. In this case, the main device 11 causes the vehicle display 7 to display content suitable for updating the program, etc., and the reason therefor. For example, if the license agreement is invalid, the main device 11 causes the vehicle display 7 to display, for example, "Due to the invalid license, the program update cannot be performed. Please contact your dealer." Thus, it is possible to inform the user of the reason why the content is not suitable for updating the program, etc., and to provide the user with appropriate information.

[0677] As explained above, the central device 3 performs a distribution packet sending determination process before sending the distribution packet to the main device 11 and before sending the activity information, thereby determining whether the state is suitable for updating programs, etc., to use the distribution packet. Furthermore, the central device 3 only sends the distribution packet to the main device 11 and sends the activity information to the main device 11 if it determines that the state is suitable for updating programs, etc., to use the distribution packet.

[0678] In the case of updates such as those for programs suitable for distribution packages, if the license agreement is established, the vehicle location is within the pre-registered range by the user, the vehicle's alarm function is enabled, and no fault information is generated in the ECU 19, the central device 3 can send activity information to the main device 11. That is, if the license agreement is not established, the vehicle location is outside the pre-registered range (e.g., far from the user's home), the vehicle's alarm function is disabled, or a fault information is generated in the ECU 19, the central device 3 can avoid sending activity information to the main device 11. Thus, the central device 3 can refrain from sending activity information to the main device 11 for vehicles where the update might violate the user's intentions, or for vehicles where installation might fail even if the download is successful.

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

[0680] Next, the processing of the main device 11 that receives activity information sent from the central device 3 will be explained. (Refer to...) Figure 91 and Figure 92 The download determination process for the distribution package in the main device 11 will be explained. The vehicle program rewriting system 1 performs the download determination process for the distribution package in the main device 11. The above-mentioned (1) distribution package sending determination process is the determination process performed by the central device 3 in the activity notification stage before the download stage, but the distribution package download determination process is the determination process performed by the main device 11 in the download stage. In addition, in this embodiment, the case where the download determination process for the distribution package is performed by the DCM12 in the main device 11 is described, but it is also possible that the CGW13 has the function of the DCM12 and the download determination process for the distribution package is performed by the CGW13.

[0681] like Figure 91As shown, the DCM12's download determination unit 67 for the distribution package includes an activity information receiving unit 67a, a downloadability determination unit 67b, and a download execution unit 67c. The activity information receiving unit 67a receives activity information from the central device 3. Furthermore, if activity information is received from the central device 3, it displays... Figure 68 The activity notification icon 501a is shown. If the downloadability determination unit 67b receives activity information through the activity information receiving unit 67a, it determines whether the vehicle status is suitable for downloading the distribution package. That is, the downloadability determination unit 67b determines whether the radio wave environment for communication with the central device 3 is good, whether the remaining battery capacity of the vehicle battery 40 is above a specified capacity, and whether the free memory capacity of the DCM 12 is above a specified capacity, and thus determines whether the vehicle status is suitable for downloading the distribution package.

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

[0683] Thus, the downloadability determination unit 67b determines whether the download may fail to complete normally. Additionally, in Figure 70 and Figure 71 In the download consent screen 503 shown, a downloadability determination is performed based on the downloadability determination unit 67b, assuming the user has operated the "Download Start" button 503a. Furthermore, the downloadability determination unit 67b can also be configured to determine the criteria for the central device 3. That is, for example, if the vehicle's alarm function setting is enabled, or if no fault information is generated in the ECU 19, the downloadability determination unit 67b determines that the device is in a downloadable state.

[0684] If the downloadability determination unit 67b determines that the vehicle status is capable of downloading the distribution package, the download execution unit 67c downloads the distribution package from the central 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.

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

[0686] Next, refer to Figure 92 The function of the packet download determination unit 67 in the main device 11 will be explained. The main device 11 executes the packet download determination procedure and performs packet download determination processing.

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

[0688] As explained above, before downloading the distribution package from the central device 3, the main device 11 performs a distribution package download determination process to determine whether the vehicle status is suitable for downloading the distribution package. Furthermore, the main device 11 can download the distribution package only if the vehicle status is suitable for downloading the distribution package.

[0689] When the radio wave environment is favorable, the remaining battery capacity of the vehicle battery 40 is greater than or equal to a specified capacity, and the free memory capacity of the DCM 12 is greater than or equal to a specified capacity, the main device 11 can download the distribution packet from the central device 3. That is, when the radio wave environment is favorable, or the remaining battery capacity of the vehicle battery 40 is less than a specified capacity, or the free memory capacity of the DCM 12 is less than a specified capacity, downloading the distribution packet from the central device 3 can be avoided.

[0690] Alternatively, the main device 11 can also perform packet download determination processing during packet download. In this case, if the main device 11 determines during packet download that the vehicle status is capable of downloading the packet, it continues to download the packet from the central device 3; however, if it determines during packet download that the vehicle status is not capable of downloading the packet, it interrupts the download from the central device 3. That is, if, for example, the radio wave environment is poor, or the remaining battery capacity of the vehicle battery 40 is less than a specified capacity, or the free memory capacity of the DCM 12 is less than a specified capacity, the main device 11 interrupts the packet download.

[0691] In this way, the central device 3 determines whether the vehicle is likely to be an update that violates the user's intentions or whether the installation may fail, and the main device 11 determines whether the download may fail, thereby suppressing the sending of useless activity information and distribution packets from the central device 3 to the main device 11.

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

[0693] The main device 11 has the following structure: It includes: an activity information receiving unit 67a that receives activity information from a central device; a downloadability determination unit 67b that, upon receiving activity information through the activity information receiving unit, determines whether the vehicle status is such that a distribution package can be downloaded; and a download execution unit 67c that, if the downloadability determination unit determines that the vehicle status is such that a distribution package can be downloaded, downloads the distribution package from the central device.

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

[0695] Reference Figure 93 and Figure 94 The process for determining the transmission of written data is explained, please refer to... Figure 95 and Figure 96 The process for determining and retrieving written data is explained below, refer to... Figures 97 to 100 The instruction determination process for installation is explained. The vehicle program rewriting system 1 performs the data transmission determination process in the DCM 12. Here, the distribution packet sent from the central device 3 to the DCM 12 is unpacked, resulting in a state where the data to be written has been extracted from the distribution packet.

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

[0697] Next, refer to Figure 94 The function of the write data transfer determination unit 68 of DCM12 will be explained. DCM12 executes the write data transfer determination program to perform write data transfer determination processing. Here, the processing when CGW13 requests write data acquisition from DCM12 according to the installation instructions from central device 3 will be explained.

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

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

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

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

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

[0703] like Figure 95 As shown, the CGW13 has an event generation determination unit 76a and a communication status determination unit 76b in its write data acquisition determination unit 76. The event generation determination unit 76a determines the occurrence of an event indicating a write data acquisition request (installation instruction) from the central device 3. If the event generation determination unit 76a determines that a write data acquisition request has occurred, then, for example, if the acquisition availability determination flag preset by the user is a first predetermined value, the communication status determination unit 76b determines the status of data communication between the central device 3 and the DCM12. For example, if the installation checks the specified conditions, the acquisition availability determination flag is 1 (first predetermined value); if the check is omitted, the acquisition availability determination flag is 0 (second predetermined value). Here, the event generation determination unit 76a can also determine the occurrence of the event based on the user instructing installation, for example, if it receives an instruction from the user to perform installation on the vehicle display 7 (see reference). Figure 75 If a notification of the content of a data entry is received, it is determined that an event has generated a request to write data.

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

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

[0706] In addition, if CGW13 determines that the acquisition approval flag is the second specified value (S402: "Yes"), it does not determine the status of data communication between the central device 3 and DCM12, but sends an acquisition request for writing data to DCM12 and ends the acquisition approval process for writing data.

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

[0708] For example, if there are multiple ECUs 19 to be modified and installation takes time, the on-board system 4 can notify the central device 3 of the installation progress, and the progress can be displayed one by one on the portable terminal 6. Additionally, the CGW13 can perform write data acquisition determination processing during the write data acquisition process. In this case, if the CGW13 determines that data communication is in a connected state during write data acquisition, it continues to acquire write data; however, if it determines that data communication is in a disconnected state, it interrupts the write data acquisition.

[0709] Next, we will explain the determination of the write data acquisition process in more detail. The acquisition of write data is one of the installation-related processes; here, refer to... Figures 97 to 100 The installation instruction determination process is explained. The vehicle program rewriting system 1 performs the installation instruction determination process in CGW13. The aforementioned (1) distribution package sending determination process, (2) distribution package download determination process are determination processes performed during the download phase; (3) write data transmission determination process, (4) write data acquisition determination process are processes performed during the installation phase after download completion; and (5) installation instruction determination process is processes performed during both the installation and activation phases. Here, the distribution package is downloaded to DCM12, as... Figure 46 As shown, the write data (update data, differential data) written to the write object ECU19 has been unpacked.

[0710] like Figure 97 As shown, the CGW13, in its installation instruction determination unit 77, includes an installation condition determination unit 77a, an installation instruction unit 77b, a vehicle status information acquisition unit 77c, an activation condition determination unit 77d, and an activation instruction unit 77e. The installation condition determination unit 77a determines whether a first condition, a second condition, a third condition, a fourth condition, and a fifth condition are met. The first condition is obtaining user consent related to the installation. User consent related to the installation, for example, means... Figure 75 The screen shown represents the consent action for the user who is installing (e.g., pressing the "Update Now" button 506a). Alternatively, the entire process from download to activation can be considered an update, and this can be considered the consent action for the user who is updating.

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

[0712] If the installation condition determination unit 77a determines that all five conditions—first, second, third, fourth, and fifth—are met, the installation instruction unit 77b instructs the target ECU 19 to install the application. That is, if the installation condition determination unit 77a determines that user consent related to the installation has been obtained, CGW13 can communicate with the central device 3, the vehicle is in an installable state, the target ECU 19 is in an installable state, and the written data is normal, then the installation instruction unit 77b instructs the target ECU 19 to install the application. Specifically, the installation instruction unit 77b obtains the written data from DCM12 and transmits the obtained written data to the target ECU 19. If the installation condition determination unit 77a determines that at least one of the first, second, third, fourth, and fifth conditions is not met, then the installation instruction unit 77b does not instruct the target ECU 19 to install the application, and instead prompts the user with a message indicating standby or that the installation cannot begin, along with the reason.

[0713] The vehicle status information acquisition unit 77c acquires vehicle status information from the central device 3. After the application installation is completed in all the modified target ECUs 19, the activation condition determination unit 77d determines whether the sixth, seventh, and eighth conditions are met. The sixth condition is obtaining user consent related to activation. User consent related to activation, for example, means... Figure 79 The screen shown represents the consent action for the activated user (e.g., pressing the "OK" button 508b). Alternatively, the period from download to activation can be considered an update, and the consent action can be for the updated user. The seventh condition is that the vehicle is in an activated state. The eighth condition is that the modified object ECU 19 is in an activated state.

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

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

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

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

[0718] If CGW13 determines that the vehicle status is suitable for installation (S503: "Yes"), it then determines whether the fourth condition is met and whether the target ECU 19 can be installed (S504, equivalent to part of the installation condition determination step). For example, if the target ECU 19 does not generate a fault code and secure access to the target ECU 19 is successful, CGW13 determines that the target ECU 19 can be installed. Here, in addition to the target ECU 19 to which the write data is written, the presence or absence of fault codes can also be checked for ECUs 19 that cooperate with the target ECU 19 for control. That is, CGW13 not only determines whether a fault code is generated for the target ECU 19, but also for ECUs 19 that cooperate with the target ECU 19 for control.

[0719] If CGW13 determines that the target ECU19 can be installed (S504: "Yes"), it then determines whether the fifth condition is met and whether the written data is normal data (S505, equivalent to part of the installation condition determination step). If the written data does not meet the write surface (non-application surface) of the target ECU19, and the verification result for the integrity of the written data is normal, CGW13 determines that the written data is normal data. If CGW13 determines that the written data is normal data (S505: "Yes"), it instructs the target ECU19 to install the application (S506, equivalent to the installation instruction step). In this way, CGW13 performs the determination of the second condition and subsequent conditions based on the first condition being met. In addition, CGW13 finally performs the determination of the fifth condition. If CGW13 determines that all conditions from the first to the fifth condition are met, it instructs the target ECU19 to install the application.

[0720] On the other hand, if CGW13 determines that user consent related to installation has not been obtained (S501: "No"), that data communication with the central device 3 cannot be performed (S502: "No"), that the vehicle status is unsuitable for installation (S503: "No"), that the target ECU 19 cannot be installed (S504: "No"), or that the written data is not normal data (S505: "No"), then it will not instruct the target ECU 19 to install the application. Furthermore, the above process describes a structure where user consent related to installation is determined before other conditions, but it could also be a structure where the determination is made after other conditions.

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

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

[0723] Furthermore, when there are multiple ECUs 19 to be modified, CGW13 can instruct installation individually or uniformly. When the ECUs 19 to be modified are ECU(ID1) and ECU(ID2), in the form of independent installation instruction, such as... Figure 99 As shown, CGW13 determines whether the installation conditions are met for ECU (ID1). If CGW13 determines that the installation conditions are met for ECU (ID1), it instructs ECU (ID1) to install. Next, CGW13 determines whether the installation conditions are met for ECU (ID2). Here, as installation conditions, CGW13 only needs to determine whether the fourth and fifth conditions are met for ECU (ID2). If CGW13 determines that the installation conditions are met for ECU (ID2), it instructs ECU (ID2) to install.

[0724] When rewriting the target ECU19 as ECU(ID1) or ECU(ID2), in the form of unified instruction installation, such as Figure 100 As shown, CGW13 determines whether the installation conditions are met for ECU (ID1). 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 are met for ECU (ID1), then it determines whether the installation conditions are met for ECU (ID2). That is, CGW13 determines the fourth and fifth conditions for ECU (ID2). If the installation conditions are met for ECU (ID2), then CGW13 instructs installation to both ECU (ID1) and ECU (ID2). For example, CGW13 transmits rewrite data to ECU (ID1) and ECU (ID2) simultaneously and in parallel. Thus, in the form of unified installation instruction, CGW13 determines the first to third conditions, as well as the fourth and fifth conditions for all ECUs to be rewritten. Moreover, CGW13 instructs installation based on the satisfaction of all these conditions.

[0725] As explained above, CGW13 performs an installation instruction determination process before instructing the ECU 19 to install the application. If all five conditions are met—first, obtaining user consent related to the installation; second, being able to communicate data with the central device 3; third, the vehicle being in an installable state; fourth, the ECU 19 being in an installable state; and fifth, the data being written being normal—then the application is instructed to be installed on the ECU 19. This allows for the appropriate instruction to the ECU 19 to install the application.

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

[0727] Reference Figures 101 to 105 The management and processing of the secure access key will be explained. The secure access key is a key used for device authentication when accessing the ECU19 to be rewritten before the installation of write data in CGW13. The vehicle program rewriting system 1 manages the secure access key in CGW13. Here, the explanation is based on the premise that CGW13 is in a state where it can obtain write data from DCM12 through the above-described (3) write data transmission determination process or (4) write data acquisition determination process. Device authentication using the secure access key is equivalent to the fourth condition (step S505) of the above-described (5) installation instruction determination process.

[0728] When CGW13 distributes write data to the target ECU19, CGW13 needs to use a secure access key for secure access (device authentication) with the target ECU19. In this case, consider the following method: CGW13 requests the generation of a random value from the target ECU19, obtains the random value generated by the target ECU19, and calculates the obtained random value to generate the secure access key. However, in this method, if the random value is obtained from the target ECU19 even when the application is not being rewritten, the secure access key can be saved, thus creating a risk of secure access key leakage.

[0729] Furthermore, in CGW13, if the configuration involves sending a random value obtained 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, then it is not necessary to store the secure access key, thus reducing the risk of leakage of the secure access key. However, in the structure where the central device 3 calculates the random value, the standby time until the target ECU 19 obtains the random value from the central device 3 becomes longer, making it difficult to meet the time requirements for diagnostic communication. Based on this situation, the following structure is adopted in this embodiment.

[0730] like Figure 101 As shown, the supplier uses the encryption and decoding keys of the secure access key to encrypt the secure access key for each ECU19 to generate a random value. This random value includes both values ​​different from and the same as previously used values; it refers to a random value. The random value is the encrypted secure access key. The supplier provides the generated random value along with the re-encoded data. The secure access key, the encryption and decoding keys of the secure access key, and the random value are unique to each ECU19.

[0731] If the OEM receives reprogrammed data and random values ​​from the supplier, it will establish a correspondence between the provided random values ​​and the ECU(ID) that identifies ECU19, and store them in [the relevant database / system]. Figure 44 The CGW rewrite specification data shown is further divided into two parts. The OEM stores the key pattern and decoding operation pattern required for decoding the random value in the CGW rewrite specification data. The key pattern stores information such as the shared key / public key method and key length; the decoding operation pattern stores information such as the type of algorithm used for decoding. If the OEM stores the random value, key pattern, and decoding operation pattern in the CGW rewrite specification data, it provides the CGW rewrite specification data containing the random value along with the re-encoding data to the central device 3. This information from the suppliers is stored in the ECU reconfiguration data DB and ECU metadata DB, described later.

[0732] If the central device 3 receives recompiled data and rewritten specification data (rewritten specification data for DCM and rewritten specification data for CGW) from the OEM, it sends a distribution package containing the provided rewritten specification data and recompiled data to the main device 11. In the main device 11, if the DCM 12 downloads the distribution package from the central device 3, it transmits the rewritten specification data and write data to the CGW 13.

[0733] like Figure 102 As shown, the CGW13 has a secure area 78a (equivalent to a decoding key storage unit), a random value extraction unit 78b (equivalent to a key derived value extraction unit), a key pattern extraction unit 78c, a decoding operation pattern extraction unit 78d, a key generation unit 78e, a secure access execution unit 78f, a session transfer request unit 78g, and a key elimination unit 78h in its secure access key management unit 78. The secure area 78a cannot be read from outside the ECU19 and is configured with encryption and decoding keys for the secure access key, as well as a decoding operation algorithm. The random value extraction unit 78b extracts the random value (key derived value) contained in the rewritten specification data from the parsing results of the rewritten specification data used by the CGW. The random value is an encrypted value that establishes a correspondence with the ECU(ID) of the rewritten object ECU19.

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

[0735] If the key generation unit 78e extracts a random value through the random value extraction unit 78b, it searches the security region 78a and decodes the extracted random value using the decoding key corresponding to the ECU(ID) from the decoding key group of the security access key configured in the security region 78a, thereby generating a security access key. In this case, the key generation unit 78e uses the decoding key determined by the key pattern extracted by the key pattern extraction unit 78c and decodes the key-derived value according to the decoding operation method determined by the decoding operation mode extracted by the decoding operation mode extraction unit 78d. That is, multiple key patterns and multiple decoding operation modes are prepared, the key patterns and decoding operation modes are specified by the rewrite specification data used by the CGW, and the key generation unit 78e uses the key patterns and decoding operation modes to generate a security access key.

[0736] If a secure access key is generated by the key generation unit 78e, the secure access execution unit 78f uses the generated secure access key to perform secure access to the ECU 19 to be modified. Specifically, the secure access execution unit 78f, for example, uses the secure access key to send encrypted data obtained by encrypting the ECU(ID) to the ECU 19 to request access. If the ECU 19 receives the encrypted data, it uses its own stored secure access key to decode the received encrypted data. Furthermore, the ECU 19 compares the decoded data generated by the decoding with its own ECU(ID). If they match, access to itself is allowed; if they do not match, access to itself is not allowed.

[0737] The session transfer request unit 78g requests a transfer to the rewrite session. After the transfer from the default session to the rewrite session, the security access execution unit 78f performs security access. Alternatively, security access can be performed based on a transfer to a session other than the default session (e.g., a diagnostic session), followed by a transfer to the rewrite session. After the security access execution unit 78f performs security access for the rewrite target ECU19 and completes the rewrite of the application for the rewrite target ECU19, the key removal unit 78h removes the security access key generated by the key generation unit 78e.

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

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

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

[0741] CGW13 retrieves security zone 78a, uses the decoding key corresponding to the ECU(ID) in the decoding key group of the security access key configured in security zone 78a, decodes the random value extracted from the rewritten specification data used by CGW, and generates a security access key (S603, equivalent to the key generation step).

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

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

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

[0745] As explained above, CGW13 manages the secure access key by extracting a random value corresponding to the target ECU19 from the parsing results of the rewritten specification data. This random value is then decoded using the decoding key corresponding to the target ECU19 stored in secure area 78a to generate a secure access key. By generating the secure access key within CGW13 instead of obtaining it from an external source, the risk of secure access key leakage is reduced, and secure access to the target ECU19 is appropriately enforced.

[0746] Furthermore, when there are multiple ECUs 19 to be modified, it is preferable that CGW13 generates a security access key before installing each piece of data. That is, if the ECUs 19 to be modified are ECU(ID1), ECU(ID2), and ECU(ID3), it is preferable that CGW13 performs the following steps in the order of generating the security access key for ECU(ID1), installing data to ECU(ID1), generating the security access key for ECU(ID2), installing data to ECU(ID2), generating the security access key for ECU(ID3), and installing data to ECU(ID3). For example... Figure 99 As shown, CGW13 performs a security access process to determine whether the installation conditions for ECU (ID1) are met. If normal access is permitted, CGW13 instructs ECU (ID1) to be installed. Then, as another condition to determine whether the installation conditions for ECU (ID2) are met, CGW13 performs a security access process. If normal access is permitted, CGW13 instructs ECU (ID2) to be installed.

[0747] Furthermore, if the object to be modified, ECU19, is granted access to itself through a secure access granted by CGW13, then the secure access is released upon receiving a session transfer request from CGW13, thus enabling data to be written to the flash memory. A session transfer request is, for example,... Figure 191 The second state shown is "Rewrite Session Transfer Request". If the rewritten object ECU19 does not receive a session transfer request from CGW13 within a specified time (e.g., 5 seconds) after allowing access to itself, it times out, secures access, and does not accept the reception of session transfer requests. If, after determining that access to the rewritten object ECU19 has been granted, no session transfer request is sent to the rewritten object ECU19 within the specified time, CGW13 needs to send a session maintenance request to the rewritten object ECU19 to prevent the rewritten object ECU19 from timing out and sending a session transfer request to the rewritten object ECU19.

[0748] Additionally, if the rewriting process is canceled midway, and version 1.0 of the application is written on the application side while version 2.0 of the application is written on the non-application side, if an activity notification for version 2.0 is generated from this state, it is possible to activate the application without installation, thus omitting the security access process.

[0749] (7) Validation processing of written data

[0750] Reference Figures 106 to 114The verification process for written data is explained. The vehicle program rewriting system 1 performs the verification process for written data in CGW13. CGW13 may perform the verification process for written data as described in this embodiment before obtaining access permission from the management process of the security access key described above (6), or it may perform it after obtaining access permission.

[0751] like Figure 106 As shown, if a supplier or OEM generates write data, they apply a data verification value calculation algorithm to the generated write data to generate a data verification value. Here, the write data can be an updated new program or differential data from an old program to a new program. The supplier or OEM uses a specified key (key value) to encrypt the data verification value to generate an authentication t...

Claims

1. A vehicle information communication system that has a center device and a vehicle-mounted device mounted on a vehicle, wherein The above-described center device manages data written to a plurality of electronic control devices mounted on a vehicle, and the above-described in-vehicle device has: an in-vehicle communication section that communicates with the plurality of electronic control devices; and an out-of-vehicle communication section that wirelessly communicates with the above-described center device, wherein The above-described in-vehicle device, if it receives structure information related to the structure of each device from the plurality of electronic control devices, transmits a structure information list including a plurality of the above-described structure information to the above-described center device, The above-described center device has a structure information storage section that stores a normal above-described structure information list for each type of vehicle, the above-described structure information list including a plurality of structure information of vehicles that are certified by a common authority, Before the above-described center device distributes an update program to the above-described in-vehicle device, the above-described center device compares the above-described structure information list received from the above-described in-vehicle device with the normal above-described structure information list for each type of vehicle stored in the above-described structure information storage section, and determines whether the combination of the plurality of electronic control devices mounted on the vehicle is appropriate, If it is determined that the above-described structure information list received from the above-described in-vehicle device is not normal, it transmits the content of the abnormality to the above-described in-vehicle device, It has a vehicle-side structure information storage section that stores data for each vehicle, and if it receives the above-described structure information list from the above-described in-vehicle device, it stores the above-described structure information list in the above-described vehicle-side structure information storage section regardless of whether it is normal or not, If it is determined that the above-described structure information list received from the above-described in-vehicle device is normal, it determines whether there is a program update for the corresponding vehicle, and in the case where there is, it transmits activity information including a restriction matter of the vehicle related to the program update to the above-described in-vehicle device, the above-described activity information including information about the update content displayed in the in-vehicle device and a restriction matter of the vehicle related to the program update, The above-described in-vehicle device determines whether it is in a state where it can download or install an update program in accordance with the above-described restriction matter included in the above-described activity information received, and in the case where it is in a state where it can download or install, it requests the above-described center device to distribute an update program, The above-described center device distributes an update program to the vehicle in response to the request from the above-described in-vehicle device, The above-described restriction matter included in the above-described activity information includes any one or more of information related to the remaining capacity of a battery, information related to the free capacity of a memory, and information related to the position of the vehicle, and a prescribed threshold value is set for each of the above-described restriction matters.

2. The vehicle information communication system according to claim 1, wherein The above-described center device has a communication section that communicates with a management device that manages information of vehicles produced, and transmits the detection of the abnormality to the above-described management device.

3. The vehicle information communication system according to claim 1, wherein The above-described structure information list includes an ECU software ID including information related to the version of an application program of each electronic control device, The above-described center device determines whether it is not normal using the above-described ECU software ID.

4. The vehicle information communication system according to claim 1, wherein The structure information list contains a vehicle software ID, and each vehicle is assigned only one vehicle software ID, which is updated when any one or more of the applications are updated, The center device determines whether the vehicle software ID is irregular.

5. The vehicle information communication system according to claim 1, wherein The center device determines that the vehicle is irregular if the structure information of any one of the electronic control devices does not match the value stored in the structure information storage section.

6. The vehicle information communication system according to claim 5, wherein The center device determines that the vehicle is irregular even if the electronic control device whose structure information does not match the value stored in the structure information storage section is not an update target of the application.

7. The vehicle information communication system according to any one of claims 1 to 6, wherein The center device has an update notification information storage section that stores notification information related to program updates of vehicles, If it is determined that the structure information list received from the in-vehicle device is regular, the update notification information storage section is referred to, and if there is a program update of the corresponding vehicle, the notification information is transmitted to the in-vehicle device.

Images