Vehicle Information Communication System

Abstract

The present invention provides a vehicle information communication system. A vehicle-side system (4) sends the structure information of a plurality of ECUs (19) to a central device (3), and in a single vehicle information DB (113), the structure information sent from each vehicle is stored together with the sending date. In addition, in an activity DB (217), as activity information, an activity ID and a list of target VINs that can identify target vehicles for data update are stored. Furthermore, the central device (3) refers to the single vehicle structure DB (213), and if no structure information is sent within a specified period from the sending date associated with the target vehicle, a message for reminding the vehicle-side system (4) of the target vehicle is sent via SMS to remind the vehicle-side system (4) of the target vehicle to update the data.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is based on Japanese application No. 2018-151414 filed on August 10, 2018 and Japanese application No. 2019-129954 filed on July 12, 2019, and the contents described therein are cited herein. Technical Field

[0003] The present disclosure relates to a vehicle information communication system including a central device that manages data written into a plurality of electronic control devices mounted on a vehicle, and an onboard device mounted on the vehicle. Background Art

[0004] In recent years, along with the diversification of vehicle control such as driving assistance functions and automatic driving functions, the scale of applications such as vehicle control and diagnosis installed in the electronic control unit (hereinafter referred to as ECU (Electronic Control Unit)) of the vehicle has increased. In addition, along with version upgrades based on functional improvements, etc., the chances of rewriting (recompiling) ECU applications are also increasing. On the other hand, along with the development of communication networks, etc., vehicle networking technology is also becoming increasingly popular. Based on this situation, for example, in Patent Document 1, a technology is disclosed for distributing ECU update programs from a center to vehicle-mounted devices via OTA (Over The Air) and rewriting the update programs on the vehicle side.

[0005] In order to realize such a system, the onboard device of each vehicle needs to access the center through communication to confirm whether there is a program update. Patent document 2 discloses a system in a vehicle, in which each ECU accesses a shared memory configured with an update program when the ignition switch is turned on, to confirm whether there is an update.

[0006] Patent Document 1: Japanese Patent No. 4221261

[0007] Patent Document 2: Japanese Patent Application Publication No. 2018-190223

[0008] Here, if the technology of Patent Document 2 is applied to the system of Patent Document 1, it is also considered that the ignition switch is not turned on continuously because the user has no chance to ride the vehicle. Therefore, even if the program is updated on the center side, the vehicle side cannot obtain the information and the program update will not be performed. Summary of the invention

[0009] The present disclosure has been made in view of the above circumstances, and an object of the present disclosure is to provide a vehicle information communication system capable of prompting an update of an application program on the vehicle side.

[0010] According to the vehicle information communication system disclosed in the present invention, the vehicle-mounted device transmits structural information related to the structures of multiple electronic control devices to the central device, and stores the structural information transmitted from multiple vehicles in a single-vehicle structural information storage unit of the central device in a form capable of determining the transmission period. In addition, in the activity information storage unit, as activity information related to data update for the vehicle, activity identification information and target vehicle identification information capable of identifying the target vehicle for data update are stored. Moreover, the central device refers to the activity information storage unit and the single-vehicle structural information storage unit, and if structural information is not transmitted from the target vehicle within a specified period, a message for prompting data update is transmitted to the vehicle-mounted device of the target vehicle.

[0011] With this configuration, even if the configuration information is not sent to the center device because the user has no chance to ride the vehicle, the center device sends a message to prompt the onboard device of the target vehicle to update the data. Therefore, the user can recognize the need for data update by referring to the message.

[0012] In addition, according to the vehicle information communication system disclosed in the present invention, the central device determines the target vehicle by referring to the single vehicle structure information storage unit and the activity information storage unit. That is, the single vehicle structure information storage unit stores the date when the structure information is sent from each vehicle, and the activity information storage unit stores the target vehicle identification information that can identify the target vehicle for data update. Therefore, the central device can determine the target vehicle based on the date when the structure information from each vehicle is sent and the target vehicle identification information. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Please refer to the attached Figure 1 The above and other objects, features and advantages of the present invention will become more apparent from the following detailed description.

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

[0015] Figure 2 It is a diagram showing the electrical structure of CGW.

[0016] Figure 3 It is a diagram showing the electrical structure of the ECU.

[0017] Figure 4 This is a diagram showing the connection form of the power cord.

[0018] Figure 5 This is a diagram showing a format in which re-editing data and distribution specification data are packaged.

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

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

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

[0022] Fig. 9 FIG. 2 is a diagram showing an example of the configuration information of a vehicle registered in the configuration information DB.

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

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

[0025] Fig.12 1 is a diagram showing an example of the structural information of a vehicle registered in the single vehicle information DB.

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

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

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

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

[0030] Fig.17 This is a diagram showing an example of specification data.

[0031] Fig.18 This is a diagram showing an example of a bus load table.

[0032] Fig.19 This is a flowchart showing the process of generating a distribution package registered in the package DB.

[0033] Fig. 20 This is a diagram schematically showing the contents of a package file.

[0034] Fig.21 This is a sequence diagram showing a process procedure executed between the center device and the vehicle-side system in the second embodiment.

[0035] Fig. 22This is a flowchart showing the processing performed by the center device.

[0036] Fig.23 It is schematically shown in Fig. 22 FIG. 2 is a diagram showing the contents of processing performed in steps D6 and D7 of the flowchart shown in FIG.

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

[0038] Fig.24 This is a sequence diagram showing a process procedure executed between the center device and the vehicle-side system in the third embodiment.

[0039] Fig.25 This is a flowchart showing the processing performed by the center device.

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

[0041] Fig. 27 This is a sequence diagram showing a process procedure executed between the center device and the vehicle-side system in the fourth embodiment.

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

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

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

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

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

[0047] Fig.33 This is a diagram showing the data format of the activity DB when a plurality of packages are associated with one activity.

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

[0049] Fig.35 This is equivalent to generating distribution packages for each group. Fig.19 The picture

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

[0051] Fig.37 It is a diagram showing the overall structure of the sixth embodiment.

[0052] Fig.38 It is a diagram showing the electrical structure of CGW.

[0053] Fig.39 It is a diagram showing the electrical structure of DCM.

[0054] Fig.40 It is a diagram showing the electrical structure of the ECU.

[0055] Fig.41 This is a diagram showing the connection form of the power cord.

[0056] Fig.42 This is a diagram showing a format in which re-editing data and distribution specification data are packaged.

[0057] Fig.43 This is a diagram showing rewriting specification data for DCM.

[0058] Fig.44 This is a diagram showing rewriting specification data for CGW.

[0059] Fig.45 This is a diagram showing distribution specification data.

[0060] Fig.46 This figure shows the form of unpacking the distribution package.

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

[0062] Fig.48 This is a diagram showing a form of a rewrite operation of an embedded type single-side independent memory.

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

[0064] Fig.50 This is a diagram showing a format during a rewriting operation of a download-type single-sided independent memory.

[0065] Fig.51 This is a diagram showing the normal operation of an embedded single-side suspend memory.

[0066] Fig.52 This is a diagram showing a form of an embedded type single-side suspend memory during a rewrite operation.

[0067] Fig.53 This is a diagram showing the normal operation of a download-type single-side suspend memory.

[0068] Fig.54 This is a diagram showing a format of a download type single-side suspend memory rewrite operation.

[0069] Fig.55 This is a diagram showing the normal operation of the embedded two-sided memory.

[0070] Fig.56 This is a diagram showing a form of an embedded type double-sided memory during a rewriting operation.

[0071] Fig.57 This is a diagram showing the normal operation of the download-type two-sided storage.

[0072] Fig.58 This is a diagram showing a format during rewriting operation of a download-type two-sided memory.

[0073] Fig.59 This is a diagram showing a format for rewriting an application.

[0074] Fig.60 This is a diagram showing a format for rewriting an application.

[0075] Fig.61 This is a diagram showing a format for rewriting an application.

[0076] Fig.62 This is a sequence diagram showing a format in which an application program is rewritten by power supply control.

[0077] Fig.63 This is a sequence diagram showing a format in which an application program is rewritten by power supply control.

[0078] Fig.64 This is a timing diagram showing a method of rewriting an application program by self-maintaining the power supply.

[0079] Fig.65 This is a timing diagram showing a method of rewriting an application program by self-maintaining the power supply.

[0080] Fig.66 It is a diagram showing the stages.

[0081] Fig.67 This is a diagram showing a normal screen.

[0082] Fig.68 This figure shows a screen when an event notification is generated.

[0083] Fig.69 This figure shows a screen when an event is notified.

[0084] Fig.70 This is a diagram showing a screen when downloading is approved.

[0085] Fig.71 This is a diagram showing a screen when downloading is approved.

[0086] Fig.72 This is a diagram showing a screen during download execution.

[0087] Fig.73 This is a diagram showing a screen during download execution.

[0088] Fig.74 This figure shows the screen when downloading is completed.

[0089] Fig.75 This is a diagram showing a screen when installation is approved.

[0090] Fig.76 This is a diagram showing a screen when installation is approved.

[0091] Fig.77 This figure shows the screen during installation execution.

[0092] Fig.78 This figure shows the screen during installation execution.

[0093] Fig.79 This figure shows a screen when activating consent.

[0094] Fig.80 This is a diagram showing a screen when IG is turned on.

[0095] Fig.81 This is a diagram showing a screen when confirming an operation.

[0096] Fig.82 This is a diagram showing a screen when confirming an operation.

[0097] Fig.83 This is a functional block diagram of the central device.

[0098] Fig.84 It is the functional block diagram of DCM.

[0099] Fig.85 This is a functional block diagram of CGW.

[0100] Fig.86 This is a functional block diagram of CGW.

[0101] Fig.87 It is the functional block diagram of ECU.

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

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

[0104] Fig.90 This is a flowchart showing the distribution package transmission determination process.

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

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

[0107] Fig.93 This is a functional block diagram of a transfer determination unit for write data.

[0108] Fig.94 Detailed description of the flowchart of the write data transfer determination process.

[0109] Fig.95 This is a functional block diagram of a write data acquisition determination unit.

[0110] Fig.96 Detailed description of the flowchart of the write data acquisition and determination process.

[0111] Fig.97 This is a functional block diagram of the instruction determination unit implemented.

[0112] Fig.98 This is a flowchart showing the installation instruction determination process.

[0113] Fig.99 This is a diagram showing the form of instruction installation.

[0114] Fig.100 This is a diagram showing the form of instruction installation.

[0115] Fig.101 This is a diagram showing the format of generating random values.

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

[0117] Fig.103 is a flowchart showing the process of generating a secure access key.

[0118] Fig.104 It is a diagram showing the format of generating a secure access key.

[0119] Fig.105Detailed description of the flowchart of the secure access key erasure process.

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

[0121] Fig.107 This is a functional block diagram of the verification unit for write data.

[0122] Fig.108 : is a flowchart showing the verification process of written data.

[0123] Fig.109 This is a diagram showing a form in which the processing associated with verification of write data is distributed.

[0124] Fig.110 This is a diagram showing a form in which the processing associated with verification of write data is distributed.

[0125] Fig.111 This is a diagram showing a form in which the processing associated with verification of write data is distributed.

[0126] Fig.112 This is a diagram showing a form in which the processing associated with verification of write data is distributed.

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

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

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

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

[0131] Fig.117 This is a sequence diagram showing the format of notifying the rewriting information of the two surfaces.

[0132] Fig.118 This is a functional block diagram of a power management unit that is not an object of rewriting.

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

[0134] Fig.120 This is a diagram showing the transition between the start state, the stop state, and the sleep state.

[0135] Fig.121This is a diagram showing the transition between the start state, the stop state, and the sleep state.

[0136] Fig.122 This is a diagram showing the connection form of the power cord.

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

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

[0139] Fig.125 This is a flowchart showing the file transfer control process.

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

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

[0142] Fig.128 This is a diagram showing the split files and written files.

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

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

[0145] Fig.131 This is a diagram showing the format in which the CGW distributes write data to the rewrite target ECU.

[0146] Fig.132 This is a diagram showing the format in which the CGW distributes write data to the rewrite target ECU.

[0147] Fig.133 This is a diagram showing the format in which the CGW distributes write data to the rewrite target ECU.

[0148] Fig.134 This is a diagram showing the connection configuration of the ECU.

[0149] Fig.135 This is a functional block diagram of a distribution control unit that writes data.

[0150] Fig.136 is a diagram showing a bus load table.

[0151] Fig.137 This is a diagram showing a table to which the rewriting target ECU belongs.

[0152] Fig.138 Detailed description of the flow chart showing the distribution control process of write data.

[0153] Fig.139 This is a diagram showing the format of distributing write data.

[0154] Fig.140 This is a diagram showing the format of distributing write data.

[0155] Fig.141 This is a diagram showing a format for distributing write data while a vehicle is traveling.

[0156] Fig.142 This is a diagram showing the format of distributing written data during parking.

[0157] Fig.143 It is a graph showing the distribution amount of write data.

[0158] Fig.144 It is a graph showing the distribution amount of write data.

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

[0160] Fig.146 Detailed description of the flowchart of the activation request instruction process.

[0161] Fig.147 This is a diagram showing a format for instructing an activation request.

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

[0163] Fig.149 It is a flowchart which shows the rewriting process.

[0164] Fig.150 is a flowchart showing an activated execution control process.

[0165] Fig.151 This is a functional block diagram of the grouping unit of the rewriting object.

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

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

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

[0169] Fig.155 This is a functional block diagram of a rollback execution control unit.

[0170] Fig.156 This is a flowchart showing the process of determining the rollback method.

[0171] Fig.157 : is a flowchart showing the determination process of the cancellation request.

[0172] Fig.158 : is a flowchart showing the determination process of the cancellation request.

[0173] Fig.159 : is a flowchart showing the determination process of the cancellation request.

[0174] Fig.160 : is a flowchart showing the determination process of the cancellation request.

[0175] Fig.161 : is a flowchart showing the determination process of the cancellation request.

[0176] Fig.162 This is a diagram showing the form of executing rollback.

[0177] Fig.163 This is a diagram showing the form of executing rollback.

[0178] Fig.164 This is a diagram showing the form of executing rollback.

[0179] Fig.165 This is a diagram showing the form of executing rollback.

[0180] Fig.166 This is a diagram showing the form of executing rollback.

[0181] Fig.167 This is a functional block diagram of a display control unit for rewriting the progress status.

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

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

[0184] Fig.170 This is a diagram showing a screen showing the progress of rewriting.

[0185] Fig.171 This is a diagram showing a screen showing the progress of rewriting.

[0186] Fig.172 This is a diagram showing a screen showing the progress of rewriting.

[0187] Fig.173 This is a diagram showing a screen showing the progress of rewriting.

[0188] Fig.174 This is a diagram showing a screen showing the progress of rewriting.

[0189] Fig.175 It is a diagram showing the transitions displayed by the progress chart.

[0190] Fig.176 It is a diagram showing the transitions displayed by the progress chart.

[0191] Fig.177 It is a diagram showing the transitions displayed by the progress chart.

[0192] Fig.178 It is a diagram showing the transitions displayed by the progress chart.

[0193] Fig.179 This is a diagram showing a screen showing the progress of rewriting.

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

[0195] Fig.181 This is a flowchart showing the integrity determination process of differential data.

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

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

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

[0199] Fig.185 This is a flowchart showing normal operation processing.

[0200] Fig.186 This is a flowchart showing the rewriting operation process.

[0201] Fig.187 This is a flowchart showing information notification processing.

[0202] Fig.188 This is a flowchart showing the verification process of the rewritten program.

[0203] Fig.189 This is a diagram showing the format of sending identification information and writing data.

[0204] Fig.190 This is a diagram showing the format of sending identification information and writing data.

[0205] Fig.191 This is a flowchart showing the installation instruction processing.

[0206] Fig.192 This is a functional block diagram of the session establishment unit.

[0207] Fig.193 It is a diagram that shows the structure of a program.

[0208] Fig.194 It is a diagram showing state transitions.

[0209] Fig.195 It is a diagram showing state transitions.

[0210] Fig.196 It is a diagram showing state transitions.

[0211] Fig.197 It is a diagram showing the mediation of a conversation.

[0212] Fig.198 It is a diagram showing the mediation of a conversation.

[0213] Fig.199 : is a flowchart showing the state transition management process of the first state.

[0214] Fig.200 : is a flowchart showing the state transition management process of the first state.

[0215] Fig.201 : is a flowchart showing the state transition management process of the first state.

[0216] Fig.202 : is a flowchart showing the state transition management process of the second state.

[0217] Fig.203 : is a flowchart showing the state transition management process of the second state.

[0218] Fig.204 It is a diagram that shows the structure of a program.

[0219] Fig.205 It is a diagram showing state transitions.

[0220] Fig.206 This is a functional block diagram of a determination unit for a retry point.

[0221] Fig.207 It is a diagram showing the structure of a flash memory.

[0222] Fig.208 This is a flowchart showing the process of setting the process flag.

[0223] Fig.209 This is a flowchart showing the determination process of the processing flag.

[0224] Fig.210 This is a flowchart showing the determination process of the processing flag.

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

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

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

[0228] Fig.214 : is a flowchart showing the progress status of the synchronous control process.

[0229] Fig.215 : is a flowchart showing the progress status of the synchronous control process.

[0230] Fig.216 This is a flowchart showing the display process of the progress status.

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

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

[0233] Fig.219 This is a functional block diagram of a receiving control unit for display control information.

[0234] Fig.220 This is a flowchart showing the reception control processing of display control information.

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

[0236] Fig.222 This is a functional block diagram of a screen display control unit for progress display.

[0237] Fig.223 This is a diagram showing rewriting specification data.

[0238] Fig.224 This figure shows a screen when a menu is selected.

[0239] Fig.225 This is a diagram showing a screen displayed when a user makes a selection.

[0240] Fig.226 This is a diagram showing a screen when a user registers.

[0241] Fig.227 This is a flowchart showing screen display control processing for progress display.

[0242] Fig.228 This is a flowchart showing screen display control processing for progress display.

[0243] Fig.229 is a diagram representing a message frame.

[0244] Fig.230 This figure shows a screen when activating consent.

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

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

[0247] Fig.233 This figure shows a screen when activating consent.

[0248] Fig.234 It is a diagram showing the format of data communication.

[0249] Fig.235 This is a diagram showing a message frame when an activity is notified.

[0250] Fig.236 This is a diagram showing a message frame when downloading is approved.

[0251] Fig.237 This is a diagram showing a message frame when installation is agreed.

[0252] Fig.238 This is a diagram showing a message frame when activating consent.

[0253] Fig.239 This is a diagram showing the transition of the screen.

[0254] Fig.240 This figure shows a screen when an event notification is generated.

[0255] Fig.241 This is a diagram showing a screen when downloading is approved.

[0256] Fig.242 This is a diagram showing a screen when downloading is approved.

[0257] Fig.243 This is a diagram showing a screen during download execution.

[0258] Fig.244 This figure shows the screen when downloading is completed.

[0259] Fig.245 This is a diagram showing a screen when installation is approved.

[0260] Fig.246 This figure shows a screen when activating consent.

[0261] Fig.247 This is a functional block diagram of the report control unit for program update.

[0262] Fig.248 Detailed description of the flowchart of the program update report control process.

[0263] Fig.249 This is a diagram showing the report format of the indicator.

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

[0265] Fig.251 This is a diagram showing the transition of the report format when the rewrite target is a single-side suspended memory.

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

[0267] Fig.253 It is a diagram showing the connection form.

[0268] Fig.254 This is a functional module of the execution control unit for self-power retention in the CGW.

[0269] Fig.255 This is a functional module of the execution control unit that maintains power supply in the ECU.

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

[0271] Fig.257 This is a flowchart showing the execution control process of the power supply self-maintaining in the ECU.

[0272] Fig.258 This is a diagram showing the period during which the power supply needs to be self-maintained.

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

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

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

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

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

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

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

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

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

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

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

[0284] (First Embodiment)

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

[0286] The display terminal 5 is a terminal having a function of accepting operation input from a user and a function of displaying various screens, and is, for example, a portable terminal 6 such as a smartphone or a tablet computer that a user can carry, and an in-vehicle display 7 such as a display that also serves as a navigation function and an instrument display that is arranged in the vehicle. The portable terminal 6 can be connected to the communication network 2 as long as it is within the communication range of the mobile communication network. The in-vehicle display 7 is connected to the vehicle-side system 4.

[0287] If the user is outside the vehicle and within the communication range of the mobile communication network, the user can confirm various screens related to the rewriting of the application using the portable terminal 6 while performing operation input, and can perform procedures related to the rewriting of the application. The user can confirm various screens related to the rewriting of the application using the vehicle display 7 inside the vehicle while performing operation input, and can perform procedures related to the rewriting of the application. That is, the user can use the portable terminal 6 and the vehicle display 7 separately outside the vehicle and inside the vehicle to perform procedures related to the rewriting of the application.

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

[0289] The file server 8 has a function of managing the application sent from the center device 3 to the vehicle-side system 4. It is a server that manages the ECU program and its accompanying information provided by the application provider, i.e., the supplier, etc., the distribution specification data provided by the OEM (Original Equipment Manufacturer), and the vehicle status obtained from the vehicle-side system 4. The file server 8 can communicate data with the vehicle-side system 4 via the communication network 2. If a download request for the distribution package is generated, the distribution package in which the re-editing data and the distribution specification data are packaged is sent to the vehicle-side system 4. The network server 9 is a server that manages network information and provides various screens related to the rewriting of the application to the portable terminal 6. The management server 10 manages the personal information of the users registered in the service of rewriting the application, and manages the rewriting history of the application for each vehicle.

[0290] The vehicle-side system 4 includes a main device 11. The main device 11 includes a DCM 12 and a CGW 13, and the DCM 12 and the CGW 13 are connected to each other via a first bus 14 so as to be able to perform data communication. The DCM 12 is an on-vehicle communication device that performs data communication with the center device 3 via a communication network 2. When a distribution package is downloaded from the file server 8, the DCM 12 extracts write data from the distribution package and transmits it to the CGW 13.

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

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

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

[0294] 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, an ECU for controlling a navigation system, an ETC ECU for controlling an electronic toll collection system, i.e., an ECU for controlling a multimedia system, such as an ETC ECU for controlling an ECT system. The buses 15 to 17 may also be buses of systems other than the bus of a vehicle body system network, a bus of a driving system network, and a bus of a multimedia system network. In addition, the number of buses and the number of ECUs 19 are not limited to the illustrated structure.

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

[0296] The sixth bus 21 is connected to the CGW 13 as a bus outside the vehicle. A DLC (Data Link Coupler) connector 22 to which a tool 23 is detachably connected is connected to the sixth bus 21. The buses 14 to 18 inside the vehicle and the bus 21 outside the vehicle are composed of, for example, a CAN (Controller Area Network, registered trademark) bus, and the CGW 13 performs data communication with the DCM 12, various ECUs 19, and the tool 23 according to the CAN data communication standard and the diagnostic communication standard (UDS: ISO14229). In addition, the DCM 12 and the CGW 13 may be connected via Ethernet, and the DLC connector 22 and the CGW 13 may be connected via Ethernet.

[0297] When the rewrite target ECU 19 receives the write data from the CGW 13, it writes the write data into the flash memory to rewrite the application program. In the above structure, the CGW 13 functions as the following reprogramming master, and when receiving a request to obtain the write data from the rewrite target ECU 19, it distributes the write data to the rewrite target ECU 19. The rewrite target ECU 19 functions as the following reprogramming slave, and when receiving the write data from the CGW 13, it writes the write data into the flash memory to rewrite the application program.

[0298] As a form of rewriting the application program, there are a form of rewriting by wire and a form of rewriting by wireless. In the form of rewriting the application program by wire, the tool 23 is connected to the DLC connector 22, and the tool 23 transmits the write data to the CGW 13. The CGW 13 relays or distributes the write data transmitted from the tool 23 to the rewriting target ECU 19. In the form of rewriting the application program by wireless, as described above, when the DCM 12 downloads the distribution package from the file server 8, it extracts the write data from the distribution package and transmits the write data to the CGW 13.

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

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

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

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

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

[0304] The IG power supply line 34 is connected to the positive electrode of the vehicle battery 35 via the IG switch 37. When the user performs the IG operation, the IG switch 37 is switched from off to on, and the output voltage of the vehicle battery 35 is applied to the IG power supply line 34. The so-called IG operation is, for example, an operation of inserting the key into the insertion port and turning the key from the "OFF" position to the "ON" position in the case of a vehicle of the type where the key is inserted into the insertion port, or an operation of pressing the start button twice in the case of a vehicle of the type where the start button is pressed. The negative electrode of the vehicle battery 35 is grounded.

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

[0306] The activation conditions of ECU19 vary depending on the power supply state, and are divided into +B system ECU activated in +B power supply state, ACC system ECU activated in ACC power supply state, and IG system ECU activated in IG power supply state. For example, the ECU19 driven in the use of stolen vehicles is +B system ECU. For example, the ECU19 driven in the use of non-driving systems such as audio is ACC system ECU. For example, the ECU19 driven in the use of driving systems such as engine control is IG system ECU.

[0307] The CGW 13 transmits a start request to the ECU 19 in the sleep state, thereby causing the ECU 19 to which the start request is sent to transition from the sleep state to the start state. In addition, the CGW 13 transmits a sleep request to the ECU 19 in the start state, thereby causing the ECU 19 to which the sleep request is sent to transition from the start state to the sleep state. The CGW 13 selects the ECU 19 to which the start request and the sleep request are sent from a plurality of ECUs, for example, by making the waveforms of the transmission signals transmitted to the buses 15 to 17 different.

[0308] The power control circuit 38 is connected in parallel with the ACC switch 36 and the IG switch 37. The CGW 13 sends a power control request to the power management ECU 20, so that the power management ECU 20 controls the power control circuit 38. That is, the CGW 13 sends a power start request to the power management ECU 20 as a power control request, so that the ACC power line 33, the IG power line 34 and the positive electrode of the vehicle battery 35 are connected inside the power control circuit 38. In this state, even if the ACC switch 36 and the IG switch 37 are turned off, the ACC power and the IG power are supplied to the vehicle-side system 4. The CGW 13 sends a power stop request to the power management ECU 20 as a power control request, so that the ACC power line 33, the IG power line 34 and the positive electrode of the vehicle battery 35 are disconnected inside the power control circuit 38.

[0309] DCM12, CGW13, ECU19 have a power self-holding function. That is, if the vehicle power is switched from the ACC power or the IG power to the +B power when DCM12, CGW13, ECU19 is in the start state, it does not immediately shift from the start state to the sleep state or the stop state after the switch, but continues the start state for a predetermined time even after the switch to self-hold the drive power. DCM12, CGW13, ECU19 shifts from the start state to the sleep state or the stop state after a predetermined time (for example, several seconds) has passed after the vehicle power is switched from the ACC power or the IG power to the +B power.

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

[0311] In addition, Figure 5 In the example, the differential data when updating from the old application to the new application is shown, but the differential data for rollback for writing back from the new application to the old application can also be included in the recompiled data. For example, when the rewriting target ECU 19 is a single-sided memory, the recompiled data includes the differential data for rollback.

[0312] The rewrite specification data provided by the OEM is information related to the rewrite of the application program, including information that can identify the rewrite target ECU 19, information that can identify the rewrite order when there are multiple rewrite target ECUs 19, information that can identify the rollback method described later, etc., and is action data related to the rewrite in the DCM 12, CGW 13, and rewrite target ECU 19. The rewrite specification data is divided into DCM rewrite specification data used by the DCM 12 and CGW rewrite specification data used by the CGW 13. The DCM rewrite specification data contains information required for reading files corresponding to the rewrite target ECU 19. As described above, the CGW rewrite specification data contains information required for controlling the rewrite of the rewrite target ECU 19.

[0313] When the DCM 12 acquires the rewrite specification data for DCM, it analyzes the rewrite specification data for DCM, and controls the rewrite-related operations such as the transmission of write data to the CGW 13 according to the analysis result. When the CGW 13 acquires the rewrite specification data for CGW, it analyzes the rewrite specification data for CGW, and controls the rewrite-related operations such as the acquisition of write data from the DCM 12 and the distribution of write data to the rewrite target ECU 19 according to the analysis result.

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

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

[0316] When DCM12 downloads a distribution package from the file server 8, it verifies the package authenticator and the encrypted recoded data stored in the distribution package. If the verification result is positive, it decodes the encrypted recoded data. When DCM12 decodes the encrypted recoded data, it unpacks the decoded recoded data to generate encrypted differential data and authenticator for each ECU, rewrite specification data for DCM, and rewrite specification data for CGW. Figure 6 , the case where the encrypted differential data and the authenticator of ECU (ID1), the encrypted differential data and the authenticator of ECU (ID2), the encrypted differential data and the authenticator of ECU (ID3), and the rewriting specification data are generated is exemplified.

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

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

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

[0320] The specification data generation unit 201 generates rewriting specification data by referring to each DB. The package generation unit 202 generates a distribution package including the rewriting specification data and the re-edited data, and registers it in the package DB 206. The package generation unit 202 may also generate a distribution package including the distribution specification data. The package distribution unit 203 distributes the registered distribution package to the vehicle-side system 4. The distribution package is equivalent to a file.

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

[0322] The activity management unit 3D includes an activity generation unit 214, an activity distribution unit 215, an instruction notification unit 216, and an activity DB 217. The OEM generates activity information, which is information related to program updates, through the activity generation unit 214 and registers it in the activity DB 217. The activity information here corresponds to the above-mentioned "distribution specification data", and is mainly information related to the update content displayed in the vehicle-side system 4. The activity distribution unit 215 distributes the activity information to the vehicle. The instruction notification unit 216 notifies the vehicle of the instructions required in connection with the program update. In the vehicle-side system 4, for example, the user determines whether to download the update program based on the activity information sent from the center device 3, and downloads it if necessary.

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

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

[0325] The above-mentioned processing will be described in more detail below. First, the contents of the data registered in each database will be described. Fig. 9 As shown, in the structure information DB 208, as an example, the following data is registered. "Vehicle model" indicates the vehicle model. "Vehicle SW ID" is the software ID for the entire vehicle, which is equivalent to the vehicle software ID. Only one "Vehicle SW ID" is assigned to each vehicle, and the "Vehicle SW ID" is updated when the version of the application program of any one or more ECUs is updated. If the group of multiple ECUs 19 installed in each vehicle is set as a "system", "Sys ID" is the ID of the system.

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

[0327] exist Fig. 9 , the configuration information related to the vehicle with "vehicle model"="aaa" is shown. The automatic driving ECU (ADS), the engine ECU (ENG), the brake ECU (BRK), and the electric power steering ECU (EPS) are exemplified in the ECU 19 mounted in the vehicle.

[0328] For example, for "Vehicle SW ID" = "0001", "ECU SW ID" is "ads_001", "eng_010", "brk_001", "eps_010", and for "Vehicle SW ID" = "0002", "ECU SW ID" is "ads_002", "eng_010", "brk_005", "eps_011", and three software versions are updated. Along with this, "Sys ID" = "SA01" is updated to "SA02", and "Sys ID" = "SA02" is updated to "SA03". In this way, in the structure information DB 208, the initial value is registered at the time of production or sale of the vehicle, and then it is updated along with the version of the application program of any one or more ECUs being updated. That is, the structure information DB 208 represents the structure information that is officially available in the market for each vehicle model.

[0329] like Fig.10 As shown, in the ECU reconfiguration data DB 204, as an example, the following programs and data are registered. Fig.10 In the example, as the ECU19 installed in a certain vehicle model and whose application program is updated, the automatic driving ECU (ADS), the brake ECU (BRK) and the electric power steering ECU (EPS) are exemplified. For the latest "ECUSW ID" of these update object ECU19, the old program and new program files of the ECU, the integrity verification data of the new program, the differential data between the new program and the old program, that is, the update data file, the integrity verification data of the update data, the rollback data file which is also the differential data, the integrity verification data of the rollback data, etc. are registered. The integrity verification data is a hash value obtained by applying a hash function to the data value. In addition, when the update data is replaced with the differential data and set as the overall data of the new program, the integrity verification data of the update data is equal to the same data of the new program.

[0330] In addition, Fig.10, the data structure about the latest "ECU SW ID" is shown, but it can also be configured so that when the data about the old "ECU SW ID" is stored, the new program file of the old "ECU SW ID" is referred to for the old program file. In addition, each integrity verification data can be in the form of registering a value calculated by the supplier, or in the form of calculating and registering by the center device 3.

[0331] like Fig.11 As shown, in the ECU metadata DB 205, as an example, the following ECU individual specification data is registered. Regarding the latest "ECU SW ID", the size of the update data file and the size of the rollback data file are used. When the flash memory 28d provided by the ECU 19 has a structure with more than two surfaces, the surface information indicating which surface the program is used for, such as surface A, surface B, surface C, etc., the transfer size, the address for reading the program file, etc. are used. These are examples of update data related information.

[0332] In addition, attribute information representing the attributes of ECU19 is also registered in ECU metadata DB205. Attribute information refers to information representing hardware attributes and software attributes related to ECU. "Transmission size" is the transmission size when rewriting data is divided and transmitted from CGW13 to ECU19, and "key" is the key used when CGW13 securely accesses ECU19. These are examples of software attribute information. In addition, regarding "vehicle model" and "ECU ID", it also includes the memory structure of the flash memory 28d possessed by ECU19, the type of bus connected to ECU19, the type of power supply connected to ECU19, etc. These are examples of hardware attribute information.

[0333] Here, the memory structure "1 side" is a 1-side independent type memory having a flash memory side on 1 side, "2 sides" is a 2-side memory having a flash memory side on 2 sides, and "suspended" is a 1-side suspended type memory having a pseudo 2-side flash memory side. The hardware attribute information and the software attribute information are information used for rewriting control of each ECU 19 in the vehicle side system 4. The hardware attribute information may also be stored in advance by the CGW 13. In this embodiment, in order to reduce the management load in the vehicle side system 4, it is managed by the central device 3. In addition, the software attribute information is data that directly specifies the rewriting action of each ECU 19. In order to achieve flexible control in the vehicle side system 4, it is managed by the central device 3.

[0334] like Fig.12As shown, in the vehicle information DB 213, as an example, the data of each vehicle shown below is registered. Mainly, the structural information of each vehicle and the status information of the vehicle for program updates are registered. Specifically, the ID of each vehicle, namely "VIN", is the structural information, namely "Vehicle SW ID", "Sys ID", "ECU ID", "ECU SW ID", etc. The hash value of these structural information, namely the "Digest" value, is also calculated and stored by the central device 3. In the case of a 2-sided memory structure, the "operation side" is the side where the program currently used by ECU19 is written, and the uploaded value is registered together with the structural information.

[0335] The "access log" is the year, month, day and time when the vehicle uploads the single vehicle information to the center device 3. The "reconfiguration status" indicates the status of the reconfiguration in the vehicle, such as "activity issuance completed", "activation completed", "download completed", etc. That is, according to the progress status, it is known at which stage the reconfiguration in the vehicle is progressing and at which stage it is stagnant. In addition, when the configuration information and the like are uploaded from the vehicle-side system 4 to the center device 3, the "VIN" of each vehicle is assigned to the information and the like.

[0336] like Fig.13 As shown, the distribution package ID, distribution package files, and data for integrity verification of the distribution package are registered in the package DB 206.

[0337] like Fig.14 As shown, the following data is registered in the activity DB 217. The ID of the activity information, the distribution package ID, the message information such as the text sentence indicating the specific update content as the activity content, the ID of the vehicle to be the target of the activity, that is, the list of "VIN", the "Vehicle SW ID" before and after the update, the list of "ECU SW ID" before and after the update, etc. The "target VIN" list can be compared and registered with the single vehicle information DB 213 and the activity DB 217. In addition, these activity information can also be registered in the package DB 206.

[0338] Next, the function of this embodiment is described. Fig.15 In the following, the registration process of the package management unit 3A to the ECU reconfiguration data DB 204 is described. Fig.15As shown, the display unit 219 and the input unit 218 start the screen for registering the reconfiguration data of the management server 10, and accept the input of the new and old program files of the ECU 19 from the operator of the supplier (A1). For example, a UI for registering a file in which the structure information is marked in a CSV format or the like may be used. Next, the package management unit 3A generates the integrity verification data of the new program (A2), and generates the differential data file when the old program is updated to the new program as the differential data for updating and the integrity verification data of the differential data for updating (A3, A4).

[0339] Next, as differential data for rollback, a differential data file when updating the old program based on the new program and integrity verification data of the data are generated (A5, A6). These program files and verification data are registered in the ECU reconfiguration data DB 204, and a new "ECU SW ID" is generated based on an old "ECU SW ID" and registered (A7). Here, in the case of distributing the entire data instead of the differential data, the steps related to the differential data can be omitted.

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

[0341] exist Fig.16 In the following, the generation process of the rewrite specification data in the specification data generation unit 201 is described. Here, the generation process of the rewrite specification data for the vehicle with "vehicle model"="aaa" is described, but the same is true for other vehicles.

[0342] The center device 3 starts the specification data generation program of the specification data generation unit 201, and receives 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 to be updated. Fig.16As shown, the specification data generation unit 201 accesses the ECU reconfiguration data DB 204 and outputs a display screen that allows selection of data to be updated from the registered "ECU SW ID" to the display unit 219. The specification data generation unit 201 stores one or more "ECU SW IDs" (B1) selected by the operator of the OEM via the input unit 218 in a determined ECU order. Here, the ECU order indicates the rewriting order of the ECU 19 in the vehicle-side system 4. The specification data generation unit 201 uses the order specified by the operator of the OEM as the determined ECU order.

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

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

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

[0346] Hereinafter, each information will be described.

[0347] The "write data type" indicates whether the program is differential data or whole data. The write data type for the update program and the write data type for the rollback program may be recorded separately.

[0348] The “writing surface” is information indicating on which surface a program is to be written for the ECU 19 of the two-surface memory.

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

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

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

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

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

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

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

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

[0357] The bus load table is a table showing the correspondence between the power supply status and the transmission allowance of the bus. Fig.18 As shown, the transmission allowance is the total transmission 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%" relative to the maximum transmission allowance, so CGW13 allows the transmission allowance of vehicle control data to be "50%" relative to the maximum transmission allowance, and allows the transmission allowance of write data to be "30%" relative to the maximum transmission allowance in the IG power state. In addition, when CGW13 is in the ACC power state, the transmission allowance of vehicle control data is "30%" relative to the maximum transmission allowance, and allows the transmission allowance of write data to be "50%" relative to the maximum transmission allowance. In addition, when CGW13 is in the +B power state, the transmission allowance of vehicle control data is "20%" relative to the maximum transmission allowance, and allows the transmission allowance of write data to be "60%" relative to the maximum transmission allowance. The same is true for the second and third buses.

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

[0359] exist Fig.17 In the specification data shown, "ECU ID" to "Transfer Size" of the ECU information is an example of object device related information including the type of the object ECU 19, and corresponds to the hardware attribute information and software attribute information described above. In addition, "Update Program Version" to "Writing Surface" are examples of update data related information. In addition, "Rewrite Environment" targeting the ECU group or the entire vehicle is an example of update processing information specifying the update processing in the vehicle.

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

[0361] Fig. 20The contents of the package file generated as described above are schematically shown. The schematic shows that the update data and integrity verification data corresponding to the "ADS", "BRK" and "EPS" to be updated are merged into one recompiled data according to the ECU order, and are merged with the rewrite specification data to generate one distribution package file. Here, the rollback data can also be included in the recompiled data only when the memory structure of the ECU 19 to be updated is 1-sided. In the case where the memory structure is 2-sided or suspended, since the rewrite to the operating side is not performed, the rollback data as the old program can be omitted.

[0362] As described above, according to the present embodiment, the update program data of the ECU 19 to be updated among the plurality of ECUs 19 mounted on the vehicle and to which the application program is to be updated is stored in the ECU reconfiguration data DB 204 of the center device 3. In the configuration information DB 208, vehicle-related information such as "ECU ID" corresponding to each of the plurality of ECUs 19 mounted on the vehicle and "ECU SW ID" of the application program stored in the ECU 19 is stored together with the type of the vehicle. In the ECU metadata DB 205, attributes of the ECU 19 to be rewritten and update data-related information associated with the update data are stored.

[0363] Furthermore, the specification data generating unit 201 generates specification data to be sent to the vehicle together with the update data written to the target ECU 19 based on the information stored in the structure information DB 208 and the ECU metadata DB 205, so that the specification data includes the type, attribute, update data related information about the target ECU 19, and information indicating the rewriting environment related to the data update. Furthermore, the package generating unit 202 generates a distribution package including the specification data and the rewritten data, and registers it in the package DB 206. Furthermore, the package distributing unit 203 distributes the registered distribution package to the vehicle-side system 4. Thus, by receiving the specification data sent together with the update data, the vehicle-side system 4 can appropriately select the target ECU 19 based on the specification data and appropriately control the writing process using the update data.

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

[0365] In addition, the vehicle-related information as specification data includes group information in which a part of the plurality of ECUs 19 are grouped, so that the vehicle-side system 4 can select the target ECU 19 according to the order specified by the group information and write the update data. For example, when there are a plurality of ECUs 19 that are targets for a certain function improvement, group 1 is set as the body system ECU 19, group 2 is set as the driving system ECU 19, and group 3 is set as the MM system ECU 19, thereby enabling the program update in the vehicle-side system 4 to be performed three times. Therefore, compared with the case where all ECUs are collectively executed to perform the program update, the waiting time of the user each time can be shortened.

[0366] In addition, the rewriting environment information includes "vehicle state (IG on state)" and "battery load" related to the vehicle, and "bus load table" related to the ECU 19, so the vehicle-side system 4 can determine the timing of writing the update data based on this information. That is, the OEM or the service company using the center device 3 can use flexible program updates by specifying the execution constraints for the vehicle as the rewriting environment information.

[0367] In addition, the specification data generating unit 201 generates specification data in sequence according to the predetermined data structure and the information related to the ECU 19 with an earlier rewrite order, so that the vehicle-side system 4 can write the update data according to the configuration order of the ECUID in the specification data. That is, the ECUs 19 with mutually cooperative processes are grouped into one group, and the ECU order is specified in consideration of the content of the cooperative process, thereby in the vehicle-side system 4, even if the update timing of the new program is not completely synchronized, the program update can be completed without any adverse situation. For example, when the new program of ECU (ID1) has a process of sending a specified message to ECU (ID2), and the new program of ECU (ID2) has a process of causing a timeout error when the specified message sent from ECU (ID1) cannot be received, the ECU order is specified in such a way that ECU (ID1) is updated first and then ECU (ID2) is updated.

[0368] (Second Embodiment)

[0369] like Fig.21 As shown, the second embodiment involves Figure 8The vehicle-side system 4 initially sends the "vehicle structure information synchronization" to the center device 3. If the vehicle-side IG switch 37 is turned on, CGW13 sends a "synchronization start request" to DCM12 as an opportunity. DCM12 receives the "synchronization start request" and replies with a "structure information collection request" to CGW13. Then, CGW13 inquires about the program version of each ECU19. Each ECU19 replies with the "ECU SW ID" to CGW13. In addition, the ECU19 with a memory structure of two sides or suspended will also reply to CGW13 with the surface information indicating which of the multiple sides is the operating side and which is the non-operating side. In addition, each ECU19 can also send calibration information of the actuator to be controlled, permission information for receiving the program update service, and fault codes generated in the ECU19 to CGW13.

[0370] When the CGW13 completes receiving the "ECU SW ID" from each ECU19, it sends all of them together with the "VIN" to the DCM12. At this time, the "Vehicle SW ID" and "Sys ID" managed by the CGW13 may also be sent to the DCM12. The DCM12 receives them and generates a hash value as a digest value using, for example, a hash function for all the "ECU SW IDs". As described above, when SHA-256 is used as the hash function, the data value obtained by serially connecting the values ​​of all the "ECU SW IDs" is divided into message blocks of 64 bytes each, and the data value of the first message block is applied to the initial hash value to obtain a hash value of 32 bytes in length, and the data values ​​of the subsequent message blocks are applied to the hash value in sequence to finally obtain a hash value of 32 bytes in length. Here, the DCM12 may generate a hash value not only for all the "ECU SW IDs" but also for values ​​including "Vehicle SW ID", "Sys ID", surface information, and calibration information.

[0371] The DCM 12 transmits the digest value of the "ECU SW ID" obtained as described above together with the "VIN" to the center device 3. In addition, the DCM 12 may transmit the fault code and the permission information together with the digest value. Hereinafter, the above-mentioned digest value may be referred to as "structural information digest", and all data values ​​of the "ECU SW ID" as the basis thereof may be referred to as "total structural information". The "total structural information" may also include "Vehicle SW ID", "Sys ID", surface information, and calibration information.

[0372] The center device 3 compares the summary value and updates the single vehicle information DB 213 as described later. The center device 3 that synchronizes the configuration information confirms whether the program is updated, and notifies the vehicle-side system 4 of the activity information if there is an update. Then, the vehicle-side system 4 downloads the distribution package, installs it to the target ECU 19, and activates the new program. With the completion of these update processes as an opportunity, the CGW 13 sends a "synchronization start request" to the DCM 12, and then performs the same processing as above until the synchronization completion notification. In addition, the above-mentioned processing performed when the IG switch 37 is turned on can also be performed after the program is updated.

[0373] like Fig. 22 As shown, when the single vehicle information management unit 3C of the center device 3 receives the "structural information summary" (D1) from the vehicle-side system 4, it compares it with the "structural information summary" of the corresponding vehicle registered in the single vehicle information DB213 at that time to determine whether the two are consistent (D2). The "single vehicle information summary" can also be a value calculated and registered in the single vehicle information DB213 in advance, or the summary value can be calculated using the structural information registered in the single vehicle information DB213 at the time of receiving it from the vehicle-side system 4. If the two are consistent ("yes"), it is determined whether the single vehicle information of the vehicle is suitable for the regular combination registered in the structural information DB208 (D6). In addition, it is also possible to update the structural information DB208 at a specified time, so in step D2, when the two are consistent ("yes"), and when the two are inconsistent ("no"), the judgment of step D6 is performed.

[0374] Here, for example Fig.23 As shown in the figure, in the above-mentioned judgment of suitability, it is checked whether the combination of "Vehicle SW ID" and "ECU SW ID" of the structural information uploaded from the vehicle-side system 4 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 the structural information DB 208 is "ads_001", the "ECU SW ID" of "ECU ID = BRK" is "brk_001", and the "ECU SW ID" of "ECU ID = EPS" is "eps_010".

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

[0376] On the other hand, the vehicle A with VIN=100 has "Vehicle SW ID=0001", "ECU SW ID" of "ECU ID=ADS" is "ads_001", and "ECU SW ID" of "ECU ID=BRK" is "brk_001", which are all consistent with the structure information registered in the structure information DB 208. Therefore, it is judged as "yes" in step D6, that is, it is legal, "OK", and the process proceeds to step D7. Here, the structure information confirmation unit 210 may also judge whether it is legal or not according to whether the combination of "ECU SW ID" of vehicle C exists in the structure information DB 208. In addition, in addition to "Vehicle SW ID", "Sys ID" may be added to the judgment material.

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

[0378] In addition, if the activity DB 217 has the "Sys ID" before and after the update, the "Sys ID" can also be used to confirm whether the update has been performed. In addition, instead of the "Vehicle SW ID", the uploaded "ECU SW ID" list can be compared with the "ECU SW ID list before update" of the activity DB 217 to determine whether the update has been performed.

[0379] The vehicle-side system 4 uses the notified activity ID as a key to obtain the activity file corresponding to the above ID from the center device 3 (D9). The activity file contains text statements that explain the activity content, constraints when executing program updates, etc. Constraints refer to conditions when downloading and installing, such as the remaining battery level, the free capacity of RAM required for downloading the distribution package, the current location of the vehicle, etc. The vehicle-side system 4 parses the activity file and displays the activity content on the vehicle-mounted display 7. The user refers to the message displayed on the vehicle-mounted display 7 based on the activity content and decides whether to update the application of the ECU 19. If the user's consent operation is accepted via the vehicle-mounted display 7, the CGW 13 notifies the center device 3 of the content of the consent to update via the DCM 12. Then, the center device 3 sends the distribution package file and integrity verification data of the package ID corresponding to the above activity ID to the vehicle-side system 4 (D10).

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

[0381] On the other hand, if the comparison result of the "structural information summary" in step D2 is inconsistent ("No"), the center device 3 requests the vehicle-side system 4 to send the "all structural information" (D3). This sending corresponds to the "notification of the overall data sending request". Correspondingly, if the vehicle-side system 4 sends the "all structural information", the center device 3 receives the information (D4). In addition, the single vehicle information management unit 3C of the center device 3 updates the information of the vehicle registered in the single vehicle information DB213 (D4). Then, it transfers to step D6. The single vehicle information DB213 is an example of a vehicle-side structural information storage unit.

[0382] In addition, the “synchronization start request” may be transmitted by the CGW 13 at a timing when the IG switch 37 is turned off.

[0383] As described above, according to the second embodiment, when the vehicle-side system 4 receives the structure information related to the structure of each ECU 19 from the plurality of ECUs 19, a hash value based on the data values ​​of the plurality of structure information is generated, and the hash value is sent to the center device 3. The center device 3 has the single vehicle information DB 213, and compares the hash value sent from the vehicle-side system 4 with the hash value of the structure information of the vehicle stored in the single vehicle information DB 213. And, if the two are inconsistent, the vehicle-side system 4 is requested to send "all structure information". Then, the vehicle-side system 4 receives the transmission and sends the "all structure information" to the center device 3. If the center device 3 receives the "all structure information", the structure information stored in the single vehicle information DB 213 is updated based on the data value.

[0384] According to this structure, the vehicle-side system 4 initially sends the hash value of the structure information to the center device 3, and only when the comparison result of the hash value in the center device 3 is inconsistent, the entire data value of the structure information is sent to the center device 3. In this way, the size of the data sent by the vehicle-side system 4 can be reduced, so even if the vehicle-side system 4 is installed in multiple vehicles, the overall communication volume can be reduced. In particular, in the vehicle-side system 4, when the structure information is uploaded at a predetermined timing such as when the IG is turned on, a time period in which the communication is concentrated occurs. Therefore, by using the hash value to reduce the amount of data to be sent, the communication load can be reduced.

[0385] In addition, the CGW 13 receives the structure information from all the ECUs 19 that are to be rewritten with the update data, generates a hash value based on all the data values, and the DCM 12 sends the hash value when the ignition switch 37 of the vehicle is turned on or off, so that the hash value can be sent to the center device 3 when the vehicle starts or ends traveling. Therefore, the center device 3 can synchronize the structure information of the single vehicle information DB 213 with the vehicle appropriately.

[0386] In addition, when the vehicle-side system 4 receives the "ECU SW ID" of each ECU 19 from a plurality of ECUs 19, it transmits a configuration information list in which the "Vehicle SW ID" is combined to the center device 3. The center device 3 compares the "ECU SW ID" list transmitted from the vehicle-side system 4 with the regular "ECU SW ID" list of the corresponding vehicle stored in the configuration information DB 208, and transmits an abnormality detection to the vehicle-side system 4 and the management device 220 if it is determined that the combination of the transmitted lists is irregular.

[0387] With this configuration, the center device 3 can detect as abnormal when the combination of vehicle configuration information is such that the plurality of ECUs 19 cannot cooperate and thus hinder the vehicle's travel, and notify the vehicle system 4. The vehicle system 4 can thus take measures such as prohibiting the vehicle from traveling.

[0388] For a vehicle whose combination of vehicle structure information is not regular, the center device 3 does not perform the update confirmation process (D7). Therefore, it is possible to prevent the program update from being performed in a non-regular vehicle. Even if the non-regular ECU 19 is not an update target ECU based on the new program, the center device 3 does not perform the update confirmation process (D7). In the vehicle-side system 4, when executing the program update, control is also generated for the ECU 19 that is not the update target. Therefore, in a vehicle with a non-regular ECU 19, there is a possibility that the program update is not completed normally, so the center device 3 does not perform the program update on the vehicle.

[0389] In addition, the center device 3 is provided with an activity DB 217, which stores activity information for notifying the vehicle side of the occurrence of an update based on the new program. For a vehicle determined to be compliant, the presence or absence of activity information of the corresponding vehicle is confirmed. If there is an update, the activity information is sent to the vehicle-side system 4. In this way, the user can be prompted with activity information to urge the application program to be updated. With the upload of structure information from the vehicle as an opportunity, the center device 3 performs a series of processing such as synchronization of the structure information, determination of whether it is compliant structure information, and confirmation of whether there is an update, thereby being able to quickly notify the appropriate vehicle of the program update.

[0390] In addition, the second embodiment may be implemented in a modified manner as follows.

[0391] The center device 3 may send a "synchronization start request" to the vehicle-side system 4, and upon receiving the "synchronization start request", the DCM 12 sends a "configuration information collection request" to the CGW 13. For example, when the configuration information DB 208 of "vehicle model = aaa" is updated, the center device 3 sends a "synchronization start request" to the vehicle of that vehicle model.

[0392] · In addition, in the ECU 19 that is the target of rewriting the update data, the hash value may be sent to the center device 3 when the rewriting is completed. That is, when the update of all programs of the ECU 19 that is the target of rewriting is completed, the hash value may also be executed. Fig. 22 Flowchart of steps D1 to D12 shown.

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

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

[0395] You can also Fig.23A As shown, the hash value is sent from the vehicle-side system 4 to the center device 3 . Fig.23A : is a flowchart showing the processing of CGW13. For example, when the IG switch 37 is turned on, CGW13 collects structural information from each ECU19 (D21), and generates a hash value (D22) for the data value of the collected structural information. In addition, the generated hash value is compared with the hash value (last generated value) stored in the flash memory 24d to determine whether there is a difference (D23). If there is a difference ("yes"), the hash value generated this time is stored in the flash memory 24d (D24), and the above hash value is sent to the center device 3. In step D23, if there is no difference between the hash values ​​of both parties ("no"), the processing is terminated. In addition, a hash value for the initial value of the structural information is pre-stored in the flash memory 24d. As a result, the vehicle-side system 4 can reduce the number of times the structural information is uploaded to the center device 3.

[0396] (Third Embodiment)

[0397] The third embodiment relates to a function executed by the activity management unit 3D of the center device 3 in order to improve the update rate of the application in the vehicle-side system 4. Fig.24 As shown, for example, in the vehicle-side system 4, the user sets the interval of HTTP polling to about 3 days in advance through the Config file, and the vehicle-side system 4 periodically confirms whether the application is updated with the center device 3. As a result, for the vehicle corresponding to the activity DB 217, when the activity information of the VIN is set and the update is confirmed, the center device 3 notifies the vehicle-side system 4 that "there is an update". That is, as described in the second embodiment, the update confirmation process is executed by the center device 3 at the time of IG connection after 3 days when the configuration information is uploaded from the vehicle-side system 4 using HTTP.

[0398] If the update is performed based on the notification from the vehicle, the center device 3 does not need to send the event information to all vehicles that are the target of the event at the time when the event information is set. However, if the user does not use the vehicle for a long time, the update is not confirmed using HTTP during that period. Therefore, it is also conceivable that the user does not know that a new event has been issued, and a vehicle that does not update the application is generated.

[0399] Therefore, if Fig.25 As shown, the SMS sending control unit 212 of the center device 3 checks the access log of each vehicle by referring to the single vehicle information DB 213 periodically or at a predetermined time (E1). In addition, it is determined whether there is a vehicle (E2) that has not accessed the center device 3, that is, has not sent the structural information for confirming the update of the application within a predetermined period. The predetermined period is calculated from the day when a new activity is set in the activity DB 217, for example, it is set to about 7 days. That is, the SMS sending control unit 212 targets the vehicles whose "Vehicle SW ID" of the single vehicle information DB 213 corresponds to the "Vehicle SW ID before update" of the activity DB 217, and identifies the vehicles that have not confirmed the update within 7 days. In addition, the SMS sending control unit 212 can also target all vehicles and identify the vehicles that have not confirmed the update within the predetermined period.

[0400] In addition, in the single vehicle information DB 213, initial data is registered by the OEM when the vehicle is produced in the factory, and then, for example, the initial access log is entered by a notification from the OEM accompanying the sale of the vehicle. This access log is substantially equivalent to a notification for validating the subsequent program update. Vehicles for which the access log is not entered are vehicles other than the judgment object of step E2.

[0401] If there is a vehicle that has not been updated and confirmed within the specified period ("Yes"), the SMS sending control unit 212 determines the characteristics of the vehicle based on the model and equipment information of the single vehicle information DB213 (E3). As the characteristics here, the SMS sending control unit 212 determines whether it is an electric vehicle; whether it is an EV that can receive SMS (Short Message Service) or an existing gasoline engine vehicle that can receive SMS, that is, a traditional engine vehicle; whether it is a transport vehicle or a vehicle that is difficult to receive SMS. For example, when the DCM 12 mounted on the vehicle does not have the function of receiving SMS or when there is no protocol for receiving SMS, it is determined that it is a vehicle that is difficult to receive SMS.

[0402] If it is an EV, an SMS is sent to start the ECU 19 of the vehicle and start the configuration information transmission step (E5, see Fig.26). If DCM12 receives the SMS and executes the command recorded in the SMS, the IG becomes powered on, and the activated CGW13 sends the configuration information to the center device 3 via DCM12. Fig. 22 As shown in steps D1 to D12, update confirmation is performed, and the distribution package is downloaded. In the case of EV, since the battery capacity is large, it is considered that the program can be fully downloaded while the IG is powered on while the vehicle is parked. Therefore, SMS is used to start the ECU 19 to automatically start the update confirmation and downloading steps.

[0403] Assume that when the remaining battery level of the EV vehicle is low, the vehicle-side system 4 refers to Fig.17 Alternatively, the center device 3 refers to the remaining battery level recorded in the activity file as a constraint sent in step D9, and controls the vehicle-side system 4 not to start downloading the distribution package when the remaining battery level is less than a specified level.

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

[0405] As described above, according to the third embodiment, the vehicle-side system 4 transmits the configuration information of the plurality of ECUs 19 to the center device 3, and stores the configuration information transmitted from each vehicle together with the transmission date in the single vehicle information DB 213. In addition, in the activity DB 217, as the activity information, the activity ID and the target VIN list capable of identifying the target vehicle for data update are stored. Furthermore, the center device 3 refers to the single vehicle configuration DB 213, and if the configuration information is not transmitted within a prescribed period from the transmission date associated with the target vehicle, the center device 3 transmits a message for urging data update to the vehicle-side system 4 of the target vehicle via SMS.

[0406] With such a configuration, even if the user has no opportunity to ride the vehicle and thus continues not to transmit the configuration information to the center device 3, the center device 3 transmits a message for urging data update to the vehicle-side system 4 of the target vehicle when a predetermined period has passed from the date of transmission stored in the single vehicle information DB 213. Therefore, the user can recognize that data update is necessary by referring to the message.

[0407] Furthermore, the center device 3 determines the target vehicle for program update by referring to the vehicle information DB 213 and the activity DB 217. That is, the vehicle information DB 213 stores the date on which the configuration information is transmitted from each vehicle, and the activity DB 217 stores the target VIN list. Therefore, the center device 3 can determine the target vehicle for program update based on the transmission date of the configuration information from each vehicle and the target VIN list.

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

[0409] Furthermore, if the target vehicle is an electric vehicle, the center device 3 sends a message including an instruction to start the ECU of the target vehicle, and the vehicle-side system 4 that receives the message starts the ECU 19 to execute the processing related to data update. That is, since the battery capacity of the electric vehicle is relatively sufficient, the ECU 19 can execute the processing related to data update without waiting for the user's operation. Therefore, data update can be performed efficiently.

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

[0411] When the destination of the user's portable terminal 6 is stored in the bicycle information DB 213, the message center device 3 transmits 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, he or she can recognize that data update is required by referring to the text information displayed on the portable terminal 6.

[0412] Furthermore, if the user transmits the event delivery date and delivery destination to the center device 3 in advance via the portable terminal 6, the center device 3 stores the delivery date and delivery destination in the bicycle information DB 213. For example, the user specifies the second day of the event release as the delivery date, and specifies the portable terminal 6 as the delivery destination without specifying the vehicle-mounted display 7. In addition, the user specifies a specified time when not riding a vehicle as the delivery date, and specifies a vehicle as the delivery destination, and automatically performs the consent operation for the program update. Thus, regardless of whether the configuration information is transmitted or not, the center device 3 transmits the event information to the delivery destination on the delivery date. Therefore, when it is known in advance that the user will not ride a vehicle for the time being, it can be set to receive the event information on the delivery date set by the user.

[0413] In addition, the third embodiment may be implemented in a modified manner as follows.

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

[0415] ·Event information can be sent by methods other than SMS.

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

[0417] (Fourth Embodiment)

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

[0419] As described above, according to the fourth embodiment, when the user transmits the transmission date and the transmission destination of the event information to the center device 3 via the portable terminal 6, the center device 3 stores the transmission date and the transmission destination in the bicycle information DB 213. Then, the center device 3 transmits the event information to the transmission destination on the stored transmission date. Thus, when it is determined that the user does not ride the vehicle within a certain period of time, the transmission of unnecessary event information from the center device 3 can be stopped.

[0420] (Fifth Embodiment)

[0421] The fifth embodiment shows that when the center device 3 sends data of the update program to the vehicle-side system 4, the vehicle-side system 4 provides a function of verifying data used to verify the integrity of the data. Fig.28 and Fig.29 As shown, the supplier uses the package management unit 3A to create data registered in the ECU reconfiguration data DB 204. Specifically, as update data, the package management unit 3A creates new differential data (Y1) for rewriting the old program into the new program, creates a hash value that is integrity verification data for the new program of the ECU 19, and a hash value (Y2) for the new differential data. Here, in the case where the ECU is a single-sided memory, it is also possible to create old differential data for rewriting the new program into the old program as rollback data, create a hash value for the old program of the ECU 19, and a hash value for the old differential data.

[0422] The package management unit 3A generates an authenticator by encrypting the hash value using a predetermined key, i.e., a key value (Y3). Furthermore, the package management unit 3A sends the update data and the integrity verification data with each authenticator, and stores them in the ECU reconfiguration data DB 204 (Y4). The package management unit 3A generates a package as described above, generates integrity verification data for the package, and sends it to the vehicle-side system 4 (Y5).

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

[0424] The rewrite target ECU 19 calculates the integrity verification data for the update data, compares the calculated value with the integrity verification data of the received update data, and performs integrity verification of the update data (Y8). If the integrity verification of the update data is successful, the rewrite target ECU 19 restores the update data, i.e., the differential data, and writes to the flash memory 28d (Y9). If the writing is completed, the rewrite target ECU 19 calculates 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 main device 11 (Y11), and the main device 11 sends the received verification result to the center device 3 as an installation result notification (Y12).

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

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

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

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

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

[0430] In addition, "program" also includes constant data used in the program. If it is "ECU SW ID = ads_002", the hash value x1 is generated for the update data "Adsfile001-002". The hash function uses, for example, SHA-256 as described above. The hash value is equivalent to the verification value. Here, the package management unit 3A can also be configured to generate an authenticator by applying encryption using a predetermined key, that is, a key value, to the hash value, and generate integrity verification data with the authenticator.

[0431] Next, the supplier generates an authenticator by encrypting the integrity verification data using a predetermined key, i.e., a key value, to generate integrity verification data with an authenticator, and provides the update data to the OEM by associating the integrity verification data with the authenticator. That is, each program and the integrity verification data with an authenticator for the program are registered in the ECU reconfiguration data DB 204 by the package management unit 3A, and are provided to the OEM. Based on the instruction of the OEM, the package management unit 3A generates the rewrite specification data as described above using the ECU reconfiguration data DB 204, generates a distribution package, and registers it in the package DB 206. If a download request for update data is generated from the vehicle-side system 4, the center device 3 distributes a distribution package including the update data and the integrity verification data with an authenticator to the vehicle-side system 4 based on the download request.

[0432] In addition, the "integrity verification data" in the technical solution includes both data of hash values ​​only and data of integrity verification with an authenticator encrypted based on a key.

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

[0434] ECU19 uses the integrity verification data (second verification value) with the authenticator to verify the validity of the update data. Specifically, the integrity verification data calculated using the received update data is compared with the received integrity verification data, and if they are consistent, it is judged to be normal. If the result of the verification is confirmed to be normal, the CPU28a of ECU19 performs a write process on the flash memory 28d. If the write process is completed, ECU19 uses the integrity verification data (first verification value) with the authenticator to read the data written to the flash memory 28d and verify its validity. Specifically, the integrity verification data calculated using the read data is compared with the received integrity verification data, and if they are consistent, it is judged to be normal. In addition, the integrity verification data here is also used when the ECU19 is started, so it is pre-stored in a specified area of ​​the flash memory 28d. If these processes are completed, ECU19 sends a write response containing the verification result to the main device 11. The main device 11 notifies the center device 3 of the installation result. In addition, "target ECU" in the figure is synonymous with "object ECU", and "OTA host" is synonymous with "DCM". The CPU 28a is an example of a write processing unit.

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

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

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

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

[0439] In the above-mentioned embodiment, the vehicle-side system 4 adopts a structure for verifying the integrity. Fig.31 In the following, the case where the central device 3 performs integrity verification (comparison with expected values) is described. Fig.31 When the ECU 19 sends the version information of the updated application to the main device 11, for example, at the time of IG turning on, the ECU 19 generates and sends the integrity verification data with the authenticator together with the version information in the same manner as described above (X1). The ECU 19 calculates the integrity verification data for the data in the flash memory 28d and sends the calculated value to the main device 11. The main device 11 sends the integrity verification data with the authenticator as the structure information to the center device 3 (X2).

[0440] The center device 3 accesses the ECU reconfiguration data DB 204, obtains the integrity verification data with the authenticator corresponding to the "ECU SW ID" of the target ECU 19 (X3, X4), and compares it with the integrity verification data uploaded from the vehicle side (X5). Specifically, the integrity verification data of the new program corresponding to the "ECU SW ID" is obtained from the ECU reconfiguration data DB and compared. If the comparison result is inconsistent, it is NG (X6; NG), then the abnormality is notified to the OEM management device 220 (X7). The function of this processing part is equivalent to the abnormality reporting unit.

[0441] The center device 3 sends the comparison result to the main device 11 (X8), and the main device 11 sends the received comparison result to the rewriting target ECU 19 (X9). If the comparison result is OK, the rewriting target ECU 19 operates the application program as usual, and if the comparison result is NG, the application program is not operated. In addition, 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).

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

[0443] In the above-mentioned embodiment, only the integrity verification data with the authenticator is added to the update data, but it is also possible to implement it as follows.

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

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

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

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

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

[0449] In addition, the authenticator may be given only to the distribution packet and the third hash value, or may be given at each stage of generating each hash value. The packet distribution unit 203 corresponds to a transmission unit.

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

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

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

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

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

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

[0456] If the verification result of the updated data is NG, the writing to the flash memory 28d is terminated. In addition, if the verification result of the new program written to the flash memory 28d is NG, the new program is invalidated and a rollback process is performed as needed. In addition, the first to third verification processing units can also be implemented by the CPU 28a. In addition, if the verification result of any of the first to third verification processing units is NG, the DCM 12 as a transmission processing unit notifies the center device 3 of the abnormality.

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

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

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

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

[0461] In this case, in the vehicle system 4, if the user instructs to stop rewriting while the update data is being rewritten in the flash memory 28d, for example, rewriting is canceled and restoration to the old program, that is, rollback, is performed. This is only the case when the memory structure of the ECU 19 is a single-sided memory.

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

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

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

[0465] As described above, according to the fifth embodiment, the ECU reconfiguration data DB 204 stores the new program, the old program, and the new differential data for updating the old program to the new program, i.e., the target ECU 19, which is the object of rewriting. The first verification value generating unit generates a first hash value using the new program, and the second verification value generating unit generates a second hash value using the update data. The package generating unit 202 generates a package including the update data, the first and second verification values, and the specification data for the plurality of target ECUs 19. The third verification value generating unit generates a third hash value using the distribution package, and the package distributing unit 203 sends the distribution package together with the third hash value to the vehicle-side system 4.

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

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

[0468] In addition, when the rollback data exists in the ECU reconfiguration data DB 204, the fourth verification value generation unit generates a fourth hash value for the old program, and the fifth verification value generation unit generates a fifth hash value for the rollback data. The package generation unit 202 causes the distribution package to include the update data, the first and second hash values, the rollback data, and the fourth and fifth hash values.

[0469] Moreover, when rolling back is performed in the vehicle-side system 4, the second verification processing unit calculates a hash value for the rollback data included in the distribution package, and compares it with the fifth hash value to verify the integrity of the rollback data. CPU28a uses the rollback data to write to the flash memory 28d. The first verification processing unit calculates a hash value for the old program restored by writing to the flash memory 28d, and compares it with the fourth hash value to verify the integrity of the old program. Thus, the integrity of the old program that is 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 ECU19 of the vehicle-side system 4. In addition, the third verification processing unit is a functional module within the main device 11 (OTA host 11) of the vehicle-side system 4.

[0470] (Variation 1 of the First Embodiment)

[0471] You can also Fig.32 and Fig.33 As shown, one activity "cpn_001" corresponds to multiple packages "pkg_001_1" and "pkg_001_2". In addition, multiple packages can also be used as multiple groups. In the above-mentioned embodiment, a structure in which multiple groups are included in one package is adopted. In this modified example, one package is generated using one group, and multiple packages are distributed to one activity. For example, the package "pkg_001_1" contains ECUs belonging to group 1, namely "ADS" and "BRK", and the package "pkg_001_2" contains ECUs belonging to group 2, namely "EPS".

[0472] In this case, if Fig.34 and Fig.35 As shown in , specification data and distribution packages are generated independently for each group. Fig.34 In the specification data of group 1, the specification data generating unit 201 generates, for example, first specification data recording ECU information of "ADS" and "BRK". As the specification data of group 2, the specification data generating unit 201 generates, for example, second specification data recording ECU information of "EPS". Fig.35In the example, the package generation unit 202 generates re-edited data by merging the update data of "ADS" and "BRK" belonging to group 1 according to the ECU order, and merges it with the first specification data to generate a package file "pkg001_1.dat". The package generation unit 202 generates re-edited data using the update data of "EPS" belonging to group 2, and merges it with the second specification data to generate a package file "pkg001_2.dat".

[0473] (Second modification of the first embodiment)

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

[0475] In the specification data generation process, the value input by the operator as specification data information is output in a data structure with a predetermined number of bits and arrangement order, thereby generating specification data. Fig.17 The values ​​exemplified in FIG. 1 include information of ECU units such as ECU (ID1), ECU (ID2), and ECU (ID3), as well as information of vehicle units or system (group) units. The information of vehicle units, for example, refers to Fig.17 The rewriting environment information shown, the system unit information, for example, refers to Fig.17 The group information and ECU sequence information shown. The vehicle unit and system unit input information can also be made into different files. The specification data generation process can also have a function to automatically calculate a part of the value such as the file size of the update data and reflect it in the specification data.

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

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

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

[0479] (Other Embodiments)

[0480] The functions performed by the central device 3 may be implemented by hardware or software, or may be implemented by the cooperation of hardware and software.

[0481] The data to be rewritten is not limited to application programs, but can also include map data, control parameter data, and other data.

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

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

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

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

[0486] Hereinafter, a sixth embodiment focusing on the operation of a vehicle program rewriting system 1 will be described with reference to the accompanying drawings. A vehicle program rewriting system (equivalent to a vehicle electronic control system) is a system capable of rewriting vehicle control, diagnosis, and other applications mounted on an electronic control device (hereinafter referred to as an ECU (Electronic Control Unit)) by OTA (Over The Air). In this embodiment, a case where an application is rewritten by wire or wireless is described, but for example, it can also be applied to a case where map data used in a map application, control parameters used in an ECU, and other data used in various applications are rewritten by wire or wireless.

[0487] Rewriting the application program by wire includes not only obtaining the application program from outside the vehicle via wire and rewriting it, but also obtaining various data used when executing the application program from outside the vehicle via wire and rewriting it. Rewriting the application program by wireless includes not only obtaining the application program from outside the vehicle via wireless and rewriting it, but also obtaining various data used when executing the application program from outside the vehicle via wireless and rewriting it.

[0488] like Fig.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 includes, for example, a mobile communication network based on 4G lines, the Internet, WiFi (Wireless Fidelity) (registered trademark), and the like.

[0489] The display terminal 5 is a terminal having the function of accepting operation input from the user and the function of displaying various screens, and is, for example, a portable terminal 6 such as a smartphone or a tablet computer that can be carried by the user, and a vehicle-mounted display 7 arranged in the vehicle interior. If the portable terminal 6 is within the communication circle of the mobile communication network, it can communicate data with the center device 3 via the communication network 2. The vehicle-mounted display 7 may also be a structure connected to the vehicle-side system 4 and also have a navigation function. In addition, the vehicle-mounted display 7 may also be a vehicle-mounted display ECU having the function of an ECU, and may also have a function of controlling the display on the center display, the instrument display, etc.

[0490] If the user is outside the vehicle and within the communication range of the mobile communication network, the user can confirm various screens related to the rewriting of the application through the portable terminal 6 while performing operation input, and can perform procedures related to the rewriting of the application. The user can confirm various screens related to the rewriting of the application through the vehicle display 7 inside the vehicle while performing operation input, and can perform procedures related to the rewriting of the application. That is, the user can use the portable terminal 6 and the vehicle display 7 separately outside the vehicle and inside the vehicle, and can perform procedures related to the rewriting of the application.

[0491] The center device 3 manages the program update function on the communication network 2 side in the vehicle program rewriting system 1 and functions as an OTA center. The center device 3 includes a file server 8, a network server 9, and a management server 10. Each server 8 to 10 is configured to be able to communicate data with each other. That is, the center device 3 includes a plurality of servers that differ in function.

[0492] The file server 8 is a server that manages the files of the application distributed from the center device 3 to the vehicle-side system 4. The file server 8 manages update data (hereinafter also referred to as re-edited data, write data) provided by a supplier or the like, distribution specification data provided by an OEM (Original Equipment Manufacturer), and vehicle status acquired from the vehicle-side system 4. The supplier is a company that provides the application distributed from the center device 3 to the vehicle-side system 4, and the file server 8 can perform data communication with the vehicle-side system 4 via the communication network 2. When a download request for a distribution package is generated, the file server 8 packages the re-edited data and the distribution specification data into a single file and sends the distribution package to the vehicle-side system 4.

[0493] The network server 9 is a server that manages network information. The network server 9 transmits the network data it manages in response to a request from a web browser included in the portable terminal 6, etc. The 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, etc.

[0494] The vehicle-side system 4 has a main device 11 (equivalent to a vehicle main device). The main device 11 has a DCM (Data Communication Module) 12 (equivalent to an on-board communication device) and a CGW (Central Gate Way) 13 (equivalent to a vehicle gateway device). The DCM 12 and the CGW 13 are connected via a first bus 14 so as to be able to perform data communication. The DCM 12 performs data communication with the center device 3 via the communication network 2. When the DCM 12 downloads a distribution package from the file server 8, it extracts write data from the downloaded distribution package and transmits the extracted write data to the CGW 13.

[0495] CGW13 has a data relay function. If the write data is obtained from DCM12, the CGW13 instructs the rewrite target ECU, which is the rewrite target ECU, to write the obtained write data and distributes the write data to the rewrite target ECU. In addition, if the writing of the write data is completed in the rewrite target ECU and the rewrite of the application is completed, CGW13 instructs the rewrite target ECU to activate the rewritten application.

[0496] The host device 11 manages the program update function on the vehicle side in the vehicle program rewriting system 1 and functions as an OTA host. Fig.37 In the example, the DCM12 and the vehicle-mounted display 7 are connected to the same first bus 14, but the DCM12 and the vehicle-mounted display 7 may be connected to different buses. In addition, the CGW13 may have a part or all of the functions of the DCM12, or the DCM12 may have a part or all of the functions of the CGW13. That is, in the main device 11, the function sharing of the DCM12 and the CGW13 may be arbitrarily configured. The main device 11 may be composed of two ECUs, the DCM12 and the CGW13, or may be composed of a combined ECU having the functions of the DCM12 and the CGW13.

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

[0498] The second bus 15 is, for example, a bus of a vehicle body system network. The ECU 19 connected to the second bus 15 is an ECU that controls the vehicle body system. The ECU that controls the vehicle body system is, for example, a door ECU that controls locking / unlocking of a door, an instrument ECU that controls the display on an instrument display, an air conditioning ECU that controls the driving of an air conditioner, a window ECU that controls the opening and closing of a window, a security ECU that is driven to prevent the vehicle from being stolen, and the like.

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

[0500] The fourth bus 17 is, for example, a bus of a multimedia system network. The ECU 19 connected to the fourth bus 17 is an ECU that controls the multimedia system. The ECU that controls the multimedia system is, for example, a navigation ECU for controlling a navigation system, an ETC ECU that controls an electronic toll collection system (ETC (Electronic Toll Collection System, registered trademark)), etc. Buses 15 to 17 may also be buses of systems other than the bus of a vehicle body system network, a bus of a driving system network, and a bus of a multimedia system network. In addition, the number of buses and the number of ECUs 19 are not limited to the illustrated structure.

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

[0502] The sixth bus 21 is connected to the CGW 13 as a bus outside the vehicle. A DLC (Data Link Coupler) connector 22 is connected to the sixth bus 21, and the DLC (Data Link Coupler) connector 22 is detachably connected to a tool 23 (equivalent to a service tool). The buses 14 to 18 inside the vehicle and the bus 21 outside the vehicle are composed of, for example, a CAN (Controller Area Network, registered trademark) bus, and the CGW 13 performs data communication between the DCM 12, various ECUs 19, and the tool 23 based on the CAN data communication standard and the diagnostic communication standard (UDS (Unified Diagnosis Services: Unified Diagnosis Services): ISO14229). In addition, the DCM 12 and the CGW 13 can also be connected via Ethernet, and the DLC connector 22 and the CGW 13 can also be connected via Ethernet.

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

[0504] As a form of rewriting an application, there are a form of rewriting by wire and a form of rewriting by wireless. The form of rewriting an application by wire refers to a form of rewriting the rewriting object ECU19 using an application obtained from the outside of the vehicle via a wire. Specifically, if the tool 23 is connected to the DLC connector 22, the tool 23 transmits the write data to the CGW13. The CGW13 functions as a gateway, sends a wired rewrite request to the rewriting object ECU19, instructs the rewriting object ECU19 to write (install) the write data, and distributes the write data transmitted from the tool 23 to the rewriting object ECU19. Distributing the write data to the rewriting object ECU19 means relaying the write data.

[0505] The form of rewriting the application program by wireless means a form of rewriting the rewriting target ECU 19 by using the application program obtained from the outside of the vehicle via wireless. Specifically, when the DCM 12 downloads the distribution package from the file server 8, it extracts the write data from the downloaded distribution package and transmits the write data to the CGW 13. The CGW 13 functions as a rewriting tool, instructs the rewriting target ECU 19 to write (install) the write data, and distributes the write data transmitted from the DCM 12 to the rewriting target ECU 19.

[0506] As a form of diagnosing ECU19, there are a form using wired diagnosis and a form using wireless diagnosis. The form using wired diagnosis refers to a form of diagnosing ECU19 from outside the vehicle via a wire. Specifically, if the tool 23 is connected to the DLC connector 22, the tool 23 transmits a diagnostic request to the CGW13. The CGW13 functions as a gateway, sends a diagnostic request to the diagnosis target ECU19, and distributes the diagnostic command transmitted from the tool 23 to the diagnosis target ECU19. The diagnosis target ECU19 performs a diagnostic process corresponding to the diagnostic command received from the CGW13.

[0507] The form of utilizing wireless diagnosis refers to the form of diagnosing ECU19 from the outside of the vehicle via wireless. Specifically, if a diagnostic command is sent from the center device 3 to the DCM12 as a diagnostic request, the DCM12 transmits the diagnostic command to the CGW13. The CGW13 functions as a gateway and distributes the diagnostic command to the diagnosis target ECU19 as a diagnostic request. The diagnosis target ECU performs a diagnostic process corresponding to the diagnostic command received from the CGW13.

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

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

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

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

[0512] In addition, the DCM 12 has a vehicle position detection function for detecting the vehicle position by using, for example, a GPS (Global Positioning System). The flash memory 28d of the DCM 12 has a sufficient memory capacity to store the distribution package downloaded from the center device 3, and has a larger memory capacity than the flash memory 24d of the CGW 13. That is, since the flash memory 28d of the DCM 12 has a sufficient memory capacity, even if the flash memory 24d of the CGW 13 does not have a sufficient memory capacity, the host device 11 can download the distribution package from the center device 3 and store the downloaded distribution package in the DCM 12.

[0513] like Fig.40 As shown in FIG. 1 , as an electrical function module, the ECU 19 includes a microcomputer 33, a data transmission circuit 34, a power supply circuit 35, and a power supply 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 includes a secure area where information cannot be read from outside the ECU 19. The microcomputer 33 executes various control programs stored in a non-migrating physical storage medium to perform various processes and control the operation of the ECU 19.

[0514] The data transmission circuit 34 controls data communication with the buses 15 to 17 in accordance with the CAN data communication standard. The power supply circuit 35 inputs +B power supply, ACC power supply, and IG power supply. The power supply detection circuit 36 ​​detects the voltage value of the +B power supply, the voltage value of the ACC power supply, and the voltage value of the IG power supply input by the power supply circuit 35, compares these detected voltage values ​​with a predetermined voltage threshold, and outputs the comparison result to the microcomputer 33. The microcomputer 33 determines whether the +B power supply, ACC power supply, and IG power supply supplied from the outside to the ECU 19 are normal or abnormal based on the comparison result input from the power supply detection circuit 27. In addition, regarding the ECU 19, although the loads such as sensors and actuators connected to itself are different, they are basically the same structure.

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

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

[0517] The IG power supply line 39 is connected to the positive electrode of the vehicle battery 40 via the IG switch 42. When the user performs the IG operation, the IG switch 42 is switched from off to on, and the output voltage of the vehicle battery 40 is applied to the IG power supply line 39. The so-called IG operation is, for example, an operation of inserting the key into the insertion port and turning the key from the "OFF" position to the "ON" position in the case of a vehicle of the type where the key is inserted into the insertion port, or an operation of pressing the start button twice in the case of a vehicle of the type where the start button is pressed. The negative electrode of the vehicle battery 40 is grounded.

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

[0519] The startup conditions of ECU19 vary depending on the power supply state. ECU19 is divided into +B power system ECU started in +B power state, ACC system ECU started in ACC power state, and IG system ECU started in IG power state. For example, ECU19 driven in the use of stolen vehicles is divided into +B power system ECU. For example, ECU19 driven in non-driving system uses such as audio is divided into ACC system ECU. For example, ECU19 driven in driving system uses such as engine control is divided into IG system ECU.

[0520] The +B power system ECU is configured to be connected to the +B power line 37, the ACC power line 38, and the IG power line 39, and selects the +B power line 37 in the +B power state, selects the ACC power line 38 in the ACC power state, and selects the IG power line 39 in the IG power state. The ACC system ECU is configured to be connected to the ACC power line 38 and the IG power line 39, and selects the ACC power line 38 in the ACC power state, and selects the IG power line 39 in the IG power state. The IG system ECU is connected to the IG power line 39.

[0521] CGW13 causes ECU19, which is the destination of the start request, to transfer from the sleep state to the start state by sending a start request to ECU19, which is in the sleep state. In addition, CGW13 causes ECU19, which is the destination of the sleep request, to transfer from the start state to the sleep state by sending a sleep request to ECU19, which is in the start state. CGW13 can transfer a specific ECU19 to the start state or the sleep state by, for example, making the waveform of the transmission signal sent to buses 15 to 17 different. That is, a start request waveform and a sleep request waveform are predetermined for each ECU19. If ECU19 receives a start request waveform suitable for itself, it transfers from the sleep state to the start state. If it receives a sleep request waveform suitable for itself from CGW13, it transfers from the start state to the sleep state.

[0522] For example, CGW13 transmits the first waveform when ECU (ID1) and ECU (ID2) are in the startup state, thereby causing ECU (ID1) to transition from the startup state to the sleep state and keeping ECU (ID2) in the startup state. In addition, CGW13 transmits the second waveform when ECU (ID1) and ECU (ID2) are in the startup state, thereby keeping ECU (ID1) in the startup state and causing ECU (ID2) to transition from the startup state to the sleep state.

[0523] The power control circuit 43 is connected in parallel with the ACC switch 41 and the IG switch 42. The CGW 13 sends a power control request to the power management ECU 20 to cause the power management ECU 20 to control the power control circuit 43. That is, the CGW 13 sends a power start request to the power management ECU 20 as a power control request, thereby connecting the ACC power line 38, the IG power line 39 and the positive electrode of the vehicle battery 40 inside the power control circuit 43. In this state, even if the ACC switch 41 and the IG switch 42 are turned off, the ACC power and the IG power are supplied to the vehicle-side system 4. In addition, the CGW 13 sends a power stop request to the power management ECU 20 as a power control request, thereby disconnecting the ACC power line 38, the IG power line 39 from the positive electrode of the vehicle battery 40 inside the power control circuit 43.

[0524] DCM12, CGW13, ECU19, and power management ECU20 each have a power self-holding circuit, and have a power self-holding function for holding the power supply from the vehicle battery 40. That is, if the vehicle power supply is switched from the ACC power supply or the IG power supply to the +B power supply when the DCM12, CGW13, ECU19, and power management ECU20 are in the startup state, they do not immediately shift from the startup state to the stop state or the sleep state after the switch, but the startup state is continued for a predetermined time (for example, several minutes) by the power supply from the vehicle battery 40 to self-hold the driving power. DCM12, CGW13, ECU19, and power management ECU20 shift from the startup state to the stop state or the sleep state after a predetermined time has passed after the vehicle power supply is switched from the ACC power supply or the IG power supply to the +B power supply. For example, if it is the ECU19 of the engine control system, the power self-holding function is activated after the vehicle power supply is switched from the ACC power supply or the IG power supply to the +B power supply, so that various data related to the engine control acquired during the vehicle driving are stored as logs.

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

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

[0527] As information related to the rewriting of the application program, the rewriting specification data provided by the OEM includes information that can identify the rewriting target ECU 19, information that can identify the rewriting order when there are multiple rewriting target ECUs 19, and information that can identify the rollback method described later. The rewriting specification data is data that defines the actions related to the rewriting in the DCM 12, CGW 13, and the rewriting target ECU 19. The rewriting specification data is divided into DCM rewriting specification data used by the DCM 12 and CGW rewriting specification data used by the CGW 13.

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

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

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

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

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

[0533] When the DCM12 obtains the rewrite specification data for DCM, it analyzes the obtained rewrite specification data for DCM. When the DCM12 analyzes the rewrite specification data for DCM, it obtains the write data from the address where the update program of the rewrite target ECU19 is stored, and controls the rewrite-related actions such as transmitting the obtained write data to the CGW13.

[0534] When the CGW 13 acquires the rewrite specification data for the CGW, it analyzes the acquired rewrite specification data for the CGW. When the CGW 13 analyzes the rewrite specification data for the CGW, it controls the following actions related to rewriting based on the analysis result, such as requesting the DCM 12 to transmit a predetermined amount of the update program of the rewrite target ECU 19, or distributing the write data to the rewrite target ECU 19 in a specified order.

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

[0536] When the display terminal 5 obtains the distribution specification data from the CGW 13, it analyzes the obtained distribution specification data and controls the display of various screens according to the analysis results. For example, the display terminal 5 displays the display sentence obtained from the distribution specification data in an overlapping manner with respect to the display frame stored in advance, or executes the display control program obtained from the distribution specification data. In addition to these information, the distribution specification data can also include information uniquely defined by the system.

[0537] If the file server 8 registers the re-edited data and the distribution specification data, it encrypts the registered re-edited data and generates a distribution package storing a package authenticator for authenticating the package, the encrypted re-edited data, and the distribution specification data. The authenticator is data given to verify the integrity of the re-edited data and the distribution specification data, and is generated, for example, based on the key information, re-edited data, and distribution specification data associated with the CGW 13. If the file server 8 receives a download request for the distribution package from the outside, it sends the distribution package to the DCM 12. In addition, Fig.42 In the example, the file server 8 generates a distribution package storing the re-edited data and the distribution specification data, and sends the re-edited data and the distribution specification data as one file to the DCM 12 at the same time. However, the re-edited data and the distribution specification data may be sent as different files to the DCM 12. That is, the file server 8 may first send the distribution specification data to the DCM 12, and then send the re-edited data to the DCM 12. In this case, the distribution specification data and the re-edited data may be given an authentication code respectively.

[0538] like Fig.46 As shown, if DCM12 downloads a distribution package from the file server 8, it uses the package authenticator stored in the downloaded distribution package to verify the integrity of the encrypted recoded data. If the verification result is positive, DCM12 decodes the encrypted recoded data. If DCM12 decodes the encrypted recoded data, it unpacks (hereinafter also referred to as unpacking) the decoded recoded data, splits it into the encrypted differential data and authenticator, the rewritten specification data for DCM, and the rewritten specification data for CGW, and extracts them. Fig.46In the figure, there is an example of dividing and extracting the encrypted differential data and authenticator of ECU (ID1), the encrypted differential data and authenticator of ECU (ID2), the encrypted differential data and authenticator of ECU (ID3), the rewrite specification data for DCM, and the rewrite specification data for CGW.

[0539] Next, refer to Figures 47 to 58 The flash memory 33d of the ECU 19 is described. According to the memory structure, the flash memory 33d of the ECU 19 is divided into a single-sided independent memory having a flash memory surface on one side, a single-sided suspended memory having flash memory surfaces on two simulated sides, and a double-sided memory having flash memory surfaces on two actual sides. Hereinafter, the ECU 19 equipped with a single-sided independent memory is referred to as a single-sided independent memory ECU, the ECU 19 equipped with a single-sided suspended memory is referred to as a single-sided suspended memory ECU, and the ECU 19 equipped with two-sided memories is referred to as a double-sided memory ECU.

[0540] The 1-sided independent memory is a structure having a flash memory surface on one side, so there is no concept of an operating surface and a non-operating surface, and the application cannot be rewritten during the execution of the application. On the other hand, the 1-sided suspended memory and the 2-sided memory are structures having flash memory surfaces on two sides, so there is a concept of an operating surface and a non-operating surface, and the application on the non-operating surface can be rewritten during the execution of the application on the operating surface. The 2-sided memory is a structure having flash memory surfaces on two completely separated sides, so the application can be rewritten at any time, such as when the vehicle is running. The 1-sided suspended memory is a structure of a pseudo 2-sided partition of a 1-sided independent memory, so there are restrictions on the timing of normal reading and writing, and the application cannot be rewritten while the vehicle is running, but the application can be rewritten while the IG power is disconnected.

[0541] In addition, the 1-side independent memory, 1-side suspended memory, and 2-side memory are available in a reprogramming firmware embedded type (hereinafter referred to as embedded type) in which the reprogramming firmware is embedded, and a reprogramming firmware download type (hereinafter referred to as download type) in which the reprogramming firmware is downloaded from the outside. The reprogramming firmware is firmware for rewriting the application program.

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

[0543] (A) 1 independent memory

[0544] (A-1) Embedded type single-sided independent memory

[0545] Reference Fig.47 and Fig.48The embedded 1-sided independent memory is described. The embedded 1-sided independent memory has a differential engine working area, an application area, and a startup program area. The application area is configured with version information, parameter data, application, firmware, and a normal time vector table. The startup area is configured with a startup program, progress status point 2, progress status point 1, startup judgment information, wireless reprogramming firmware, wired reprogramming firmware, startup judgment program, and a startup time vector table.

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

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

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

[0549] Reference Fig.49 and Fig.50 The download type 1-sided independent memory is described below. The download type is different from the above-mentioned embedded type in that the wireless reprogramming firmware and the wired reprogramming firmware are downloaded from the outside, and after the application is rewritten, the wireless reprogramming firmware and the wired reprogramming firmware are deleted. In the case of wirelessly updating the application, for example, Fig.42 The reprogramming data shown includes wireless reprogramming firmware executed by each ECU 19. The ECU 19 receives the wireless reprogramming firmware for its own ECU from the CGW 13, and stores the received wireless reprogramming firmware for its own ECU in the RAM.

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

[0551] like Fig.50 As shown in FIG. 1 , when the microcomputer 33 performs the rewriting operation of the rewriting process of the application program, the application program is temporarily stored in the difference engine working area as old data. The microcomputer 33 reads out the old data temporarily stored in the difference engine working area, and restores new data based on the read old data and the difference data stored in the RAM 33c by the difference engine included in the recompiled firmware downloaded from the outside. When the microcomputer 33 generates new data based on the old data and the difference data, the new data is written to rewrite the application program.

[0552] (B) 1 side suspended memory

[0553] (B-1) Embedded 1-side mount memory

[0554] Reference Fig.51 and Fig.52 The embedded 1-sided suspend memory is described. The embedded 1-sided suspend memory has a differential engine working area, an application area, and a boot program area. The recompiled firmware for program update is configured in the boot program area like the 1-sided independent memory, and is an object other than the object of program update. The object of program update, i.e., the application area, is suspected to have side A and side B, and version information, application programs, and a normal vector table are configured on side A and side B, respectively. The boot program, recompiled firmware, a recompiled vector table, a boot side judgment function, boot side judgment information, and a boot time vector table are configured in the boot area.

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

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

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

[0558] Reference Fig.53 and Fig.54 The download type 1-side suspend memory is described below. The download type is different from the above-mentioned embedded type in that the recompilation firmware and the recompilation vector table are downloaded from the outside, and after the application is rewritten, the recompilation firmware and the recompilation vector table are deleted.

[0559] like Fig.53 As shown, when the microcomputer 33 performs normal operations such as vehicle control processing and diagnostic processing, it executes the startup program in the same manner as the embedded type, and through the startup surface determination function, determines the newness and oldness based on the startup surface determination information of each surface A and surface B, and determines which of the surface A and surface B is the application surface. If the microcomputer 33 determines that the surface A is the application surface, it searches for the start address with reference to the normal time vector table of the surface A, and executes the application program of the surface A. Similarly, if the microcomputer 33 determines that the surface B is the application surface, it searches for the start address with reference to the normal time vector table of the surface B, and executes the application program of the surface B.

[0560] like Fig.54 As shown, when the microcomputer 33 performs the rewriting operation of the application program rewriting process, the non-operating application program is temporarily stored as old data in the differential engine working area. The microcomputer 33 reads the old data temporarily stored in the differential engine working area, and restores new data based on the read old data and the differential data stored in the RAM 33c through the differential engine in the 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 program. Fig.54 In the example, the case where the A side is the operation side and the B side is the non-operation side is illustrated. In this way, in one side of the suspend memory, the application program of the A side can be executed, and the rewriting of the application program of the B side can be executed in the background.

[0561] (C) 2-sided memory

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

[0563] Reference Fig.55 and Fig.56 The embedded 2-sided memory is described. The embedded 1-sided independent memory has an application area and a rewrite program area on the A side, an application area and a rewrite program area on the B side, and a startup program area. The startup program is configured in the startup area in a non-rewritable manner. The startup program includes a startup exchange function and a startup vector table. Version information, parameter data, application programs, firmware, and a normal vector table are configured in each application area. A program for controlling rewriting, reprogramming progress management information 2, reprogramming progress management information 1, startup surface determination information, wireless reprogramming firmware, wired reprogramming firmware, and a startup vector table are configured in each rewrite program area. A startup program, a startup exchange function, and a startup vector table are configured in the startup area.

[0564] like Fig.55 As shown, the microcomputer 33 executes the startup program when executing the normal operation of the application processing such as the vehicle control processing and the diagnosis processing, and when executing the rewriting operation of the rewriting processing of the application program of the non-operation surface, and determines the new and old by starting the exchange function based on the startup surface determination information of the A surface and the B surface, and determines which of the A surface and the B surface is the operation surface. If the microcomputer 33 determines that the A surface is the operation surface, it searches for the starting address with reference to the startup vector table of the A surface and the normal vector table of the A surface, and executes the application program of the A surface. Similarly, if the microcomputer 33 determines that the B surface is the operation surface, it searches for the starting address with reference to the startup vector table of the B surface and the normal vector table of the B surface, and executes the application program of the B surface.

[0565] like Fig.56 As shown, when the microcomputer 33 performs the rewriting action of the rewriting processing of the application program on the non-operating surface, the application program on the non-operating surface is temporarily stored as old data in the differential engine working area. The microcomputer 33 reads out the old data temporarily stored in the differential engine working area, and restores new data based on the read old data and the differential data stored in RAM 33c through the differential engine embedded in the recompilation firmware. If the microcomputer 33 generates new data based on the old data and the differential data, the new data is written into the non-operating surface to rewrite the application program on the non-operating surface. In addition, the old data temporarily stored in the differential engine working area may be targeted at the application program on the operating surface or the application program on the non-operating surface. At this time, when the application program on the operating surface is targeted, the data on the non-operating surface is eliminated before the new data is written. Here, when the recompiled data obtained from outside the vehicle is not differential data but overall data (all data), the obtained recompiled data is written into the non-operating surface as new data. Fig.56In the example, the case where the A side is the operating side and the B side is the non-operating side is illustrated. In addition, the old data temporarily stored in the differential engine operation area can be the application program of the operating side or the application program of the non-operating side. When it is necessary to make the execution address of the application program consistent, the application program of the non-operating side is stored as the old data.

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

[0567] Reference Fig.57 and Fig.58 The downloadable two-sided memory is described below. The downloadable type is different from the above-mentioned embedded type in that the wireless reprogramming firmware and the wired reprogramming firmware are downloaded from the outside, and after the application program is rewritten, the wireless reprogramming firmware and the wired reprogramming firmware are deleted.

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

[0569] like Fig.58 As shown, when the microcomputer 33 performs the rewriting action of the application rewriting process, the application on the non-operating surface is temporarily stored as old data in the differential engine working area. The microcomputer 33 reads out the old data temporarily stored in the differential engine working area, and restores the new data based on the read old data and the differential data stored in the RAM 33c by the recompiled firmware downloaded from the outside. If the microcomputer 33 generates new data based on the old data and the differential data, the new data is written to the non-operating surface to rewrite the application on the non-operating surface. In addition, the old data temporarily stored in the differential engine working area may be for the application on the operating surface or for the application on the non-operating surface. At this time, when the application on the operating surface is the target, the data on the non-operating surface is eliminated before the new data is written. Here, when the recompiled data obtained from the outside of the vehicle is not differential data but overall data (all data), the obtained recompiled data is written as new data to the non-operating surface. Fig.58 In the example, the case where the A side is the operating side and the B side is the non-operating side is illustrated. In addition, the old data temporarily stored in the differential engine operation area can be the application program of the operating side or the application program of the non-operating side. In this way, the application program of the A side can be executed in the two-side memory, and the rewriting of the application program of the B side can be executed in the background.

[0570] As described above, in either the embedded type or the download type, an application program and a rewriting program for rewriting the application program are arranged in each application area. Fig.56 and Fig.58 In the example, the application program is shown as the reprogramming target, but the rewriting program can also be the reprogramming target. In addition, if it is desired to make the rewriting program non-rewritable, the rewriting program can also be arranged in the startup area. For example, a program for wired rewriting can also be arranged in the startup area so that dealers and the like can reliably implement wired rewriting via the tool 23.

[0571] Next, refer to Figure 59 to Figure 61 The overall sequence of rewriting an application is described. In addition, here, a case where a user operates a portable terminal 6 as a display terminal 5 to rewrite an application while the vehicle is parked is described, and the same applies to a case where an in-vehicle display 7 is operated to rewrite an application while the vehicle is parked. The distribution packet sent from the center 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 one rewrite target ECU 19, one write data to the one rewrite target ECU 19 is stored, and if there are multiple rewrite target ECUs 19, multiple write data to each of the multiple rewrite target ECUs 19 are stored. Here, there are two rewrite target ECUs 19, and the two rewrite target ECUs 19 are referred to as rewrite target ECUs (ID1) and rewrite target ECUs (ID2). In addition, ECUs 19 other than the rewrite target ECUs (ID1) and rewrite target ECUs (ID2) are referred to as other ECUs.

[0572] If the rewrite target ECU (ID1) and the rewrite target ECU (ID2) respectively determine that they have received a request to send a version notification signal from the main device 11, for example, they determine that the sending condition of the version notification signal is met. If the sending condition of the version notification signal is met, the rewrite target ECU (ID1) sends a version notification signal including the version information of the application stored in itself and the ECU (ID) that can identify itself to the main device 11. If the main device 11 receives the version notification signal from the rewrite target ECU (ID1), it sends the received version notification signal to the center device 3. Similarly, if the sending condition of the version notification signal is met, the rewrite target ECU (ID2) sends a version notification signal including the version of the application stored in itself and the ECU (ID) that can identify itself to the main device 11. If the main device 11 receives the version notification signal from the rewrite target ECU (ID2), it sends the received version notification signal to the center device 3.

[0573] When the center device 3 receives the version notification signal from the rewrite target ECU (ID1) and the rewrite target ECU (ID2), it determines the version of the application and the ECU (ID) contained in the received version notification signal, and determines whether there is write data to be distributed to the rewrite target ECU 19 that is the source of the version notification signal. The center device 3 determines the current version of the application of the rewrite target ECU 19 based on the version notification signal received from the rewrite target, and compares the current version of the application with the latest version managed.

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

[0575] If the center 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 the content that needs to be updated, it displays a distribution screen (A1). The distribution screen is equivalent to the activity notification screen described later. The user can confirm the content that needs to be updated through the distribution screen displayed on the portable terminal 6, and can choose whether to update.

[0576] When the user selects updated content in the portable terminal 6 (A2), the portable terminal 6 notifies the center device 3 of a download request for the distribution package. When the center device 3 is notified of the download request for the distribution package from the portable terminal 6, it transmits the distribution package to the host device 11.

[0577] When the main device 11 downloads a distribution package from the center device 3, it starts a package authentication process (B1) for the downloaded distribution package. The main device 11 authenticates the distribution package, and when the package authentication process is completed, it starts a write data extraction process (B2). The main device 11 extracts the write data from the distribution package, and when the write data extraction process is completed, it sends a download completion notification signal to the center device 3.

[0578] When the center device 3 receives the download completion notification signal from the host device 11, it notifies the completion of the download to the portable terminal 6. When the portable terminal 6 is notified of the completion of the download from the center device 3, it displays a download completion notification screen (A3). The user can confirm the content of the download completion through the download completion notification screen displayed on the portable terminal 6, and can set the rewrite start time of the application on the vehicle side.

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

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

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

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

[0583] When the center device 3 receives the rewrite completion notification signal from the host device 11, it notifies the portable terminal 6 of the completion of the rewrite of the application. When the portable terminal 6 is notified of the completion of the rewrite of the application from the center device 3, the rewrite completion notification screen (A6) is displayed. The user can confirm that the rewrite of the application is completed through the rewrite completion notification screen displayed on the portable terminal 6, as an implementation that can set synchronization as activation.

[0584] When the user sets the execution of synchronization in the portable terminal 6 (A7), that is, the user sets the consent for the activation of the new program, the portable terminal 6 notifies the execution of synchronization to the center device 3. When the center device 3 is notified of the execution of synchronization from the portable terminal 6, it sends a synchronization switching instruction signal to the main device 11. When the main device 11 receives the synchronization switching instruction signal from the center device 3, it distributes the received synchronization switching instruction signal to the rewrite target ECU (ID1) and the rewrite target ECU (ID2).

[0585] When the rewrite target ECU (ID1) and the rewrite target ECU (ID2) receive the synchronous switching instruction signal from the main device 11, they start the program switching process (C2, D2) of switching the application to be started next time from the old application to the new application. When the rewrite target ECU (ID1) and the rewrite target ECU (ID2) complete the program switching process, they send a switching completion notification signal to the main device 11.

[0586] When the host device 11 receives the switching completion notification signal from the rewrite target ECU (ID1) and the rewrite target ECU (ID2), it distributes the version read signal to the rewrite target ECU (ID1) and the rewrite target ECU (ID2). When the rewrite target ECU (ID1) and the rewrite target ECU (ID2) receive the version read signal from the host device 11, they read the version (C3, D3) of the application program to be used later, and send the latest version notification signal containing the read version to the host device 11. The host device 11 checks the software version or rolls back as needed by receiving the version notification signal from the rewrite target ECU (ID1) and the rewrite target ECU (ID2).

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

[0588] The main device 11 sends a latest version notification signal to the center device 3. When the center device 3 receives the latest version notification signal from the main device 11, it determines the latest version of the application program of the rewrite target ECU (ID1) and the rewrite target ECU (ID2) based on the received latest version notification signal, and notifies the determined latest version to the portable terminal 6. When the portable terminal 6 is notified of the latest version from the center device 3, a latest version notification screen (A8) indicating the notified latest version is displayed on the portable terminal 6. The user can confirm the latest version through the latest version notification screen displayed on the portable terminal 6, and can confirm the content of the activation completion.

[0589] Next, refer to Figure 62 to Figure 65 The timing diagram of the operation of the DCM 12, CGW 13, and the rewrite target ECU 19 when the application is rewritten is described. In addition, here, the following cases are described, that is, the application of the two-side memory ECU is rewritten while the IG switch 42 is turned on by the user operation, that is, while the vehicle can travel, and the application of the one-side suspended memory ECU and the one-side independent memory ECU is rewritten while the vehicle is parked after the IG switch 42 is turned off by the user operation. In addition, the case of rewriting the application by power supply control and the case of rewriting the application by power supply self-holding are described.

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

[0591] Reference Fig.62 and Fig.63 The case of rewriting the application program by power control is described. Rewriting the application program by power control means a structure in which the rewriting action is controlled by switching the power source without using the power self-holding circuit. When the vehicle power source is switched from +B power source to IG power source by the user switching the IG switch from off to on, the DCM 12, CGW 13, 2-side memory ECU, 1-side suspended memory ECU, and 1-side independent memory ECU start normal operation (t1).

[0592] When the DCM 12 is notified of the start of downloading from the center device 3, it switches from the normal operation to the downloading operation and starts downloading the distribution package from the center device 3 (t2). The DCM 12 can perform normal operations and download the distribution package in the background. When the DCM 12 completes downloading the distribution package from the center device 3, it returns from the downloading operation to the normal operation (t3).

[0593] When the DCM 12 is notified of the rewrite instruction signal (installation instruction signal) from the center device 3 or CGW 13, it shifts from the normal operation to the data transmission / center communication operation and starts the data transmission / center communication operation (t4). That is, the DCM 12 extracts the write data from the distribution package, starts to transmit the write data to the CGW 13, obtains the progress status of the rewrite from the CGW 13, and starts to notify the center device 3 of the progress status of the rewrite.

[0594] When the CGW 13 starts to obtain write data from the DCM 12, it shifts from the normal operation to the reprogramming main operation, starts the reprogramming main operation, starts distributing write data to the two-side memory ECU, and instructs the writing of the write data. When the two-side memory ECU starts to receive write data from the CGW 13, the programming phase (hereinafter also referred to as the installation phase) starts in the normal operation. That is, the two-side memory ECU performs the normal operation and installs the application in the background. The two-side memory ECU starts writing the received write data to the flash memory and starts rewriting the application.

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

[0596] Then, when the user switches the IG switch from OFF to ON and switches the vehicle power from +B power to IG power, DCM 12 restarts the data transmission / center communication operation, CGW 13 restarts the reprogramming main operation, and the two-side memory ECU restarts the installation phase and restarts the rewriting of the application (t6). That is, when the user switches the IG switch from ON to OFF and switches the vehicle power from IG power to +B power, and then when the user switches the IG switch from OFF to ON and switches the vehicle power from +B power to IG power, each time a trip occurs, the two-side memory ECU repeats the interruption and restart of the rewriting of the application (t7, t8).

[0597] When the 2-side memory ECU completes writing of the write data and rewriting of the application, the installation phase ends and the normal operation is transferred to the waiting activation phase. That is, when the 2-side memory ECU is not in the activation phase, it will not start on the new side (B side) on which the application is rewritten, but keep starting on the old side (A side) (t9).

[0598] After the user switches the IG switch from on to off and switches the vehicle power from IG power to +B power (t10), at this point, the two-side memory ECUs complete the rewriting of the application, and the CGW13 sends a power startup request to the power management ECU20. When the vehicle power is switched from +B power to IG power by sending the power startup request to the power management ECU20 by the CGW13, the DCM12 restarts the data transmission / center communication operation, and the CGW13 restarts the reprogramming main operation and starts distributing the write data to the 1-side suspended memory ECU and the 1-side independent memory ECU. When the 1-side suspended memory ECU and the 1-side independent memory ECU start receiving the write data from the CGW13, they shift from the normal operation to the boot process, and start the installation phase in the boot process (t11). That is, the 1-side suspended memory ECU and the 1-side independent memory ECU are not installed in parallel with the normal operation, but are installed in the boot process in which the application is not operating.

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

[0600] If the 1-side suspended memory ECU completes writing of the write data and rewriting of the application, the installation phase ends in the startup process and transfers from the startup process to the waiting activation phase. That is, the 1-side suspended memory ECU will not start on the new side (B side) where the application is rewritten when the activation phase is not in progress, and will keep starting on the old side (A side). If the 1-side independent memory ECU completes writing of the write data and rewriting of the application, the installation phase ends in the startup process and becomes waiting for activation (t12).

[0601] When the power management ECU 20 switches the vehicle power supply from the IG power supply to the +B power supply according to the activation instruction from the CGW 13, the 2-side memory ECU and the 1-side suspended memory ECU respectively switch from the old side to the new side, start the new side, and start the subsequent phase (hereinafter also referred to as the activation phase) during the startup of the new side. The 1-side independent memory ECU starts to restart, and the activation phase (t13, t14) starts during the restart after the installation is completed. During the activation, it is confirmed that the new program is correctly started, and the version information is notified to the CGW 13.

[0602] If activation is completed, the power management ECU 20 switches the vehicle power supply from the IG power supply to the +B power supply according to the activation completion instruction from the CGW 13, and the DCM 12 shifts from the data transmission / center communication action to the sleep / stop action and starts the sleep / stop action. The CGW 13 shifts from the reprogramming master action to the sleep / stop action and starts the sleep / stop action. The 2-side memory ECU, the 1-side suspended memory ECU, and the 1-side independent memory ECU shift from the new start to the sleep / stop action (t15).

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

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

[0605] Reference Fig.64 and Fig.65 The case of rewriting the application program by self-power retention is described. Rewriting the application program by self-power retention refers to a structure that uses a self-power retention circuit to control the rewriting action. When the vehicle power is switched from +B power to IG power by the user switching the IG switch from off to on, the DCM 12, CGW 13, 2-side memory ECU, 1-side suspended memory ECU, and 1-side independent memory ECU each start normal operation (t21).

[0606] When the DCM 12 is notified of the start of downloading from the center device 3, that is, notified of the existence of an update based on a new program, it shifts from the normal operation to the downloading operation and starts downloading the distribution package from the center device 3 (t22). When the DCM 12 completes downloading the distribution package from the center device 3, it returns from the downloading operation to the normal operation (t23).

[0607] When the DCM 12 is notified of the rewrite instruction signal (installation instruction signal) from the center device 3 or CGW 13, it shifts from the normal operation to the data transfer / center communication operation and starts the data transfer / center communication operation (t24). That is, the DCM 12 extracts the write data from the distribution package, starts to transfer the write data to the CGW 13, obtains the progress status of the rewrite from the CGW 13, and starts to notify the center device 3 of the progress status of the rewrite.

[0608] When the CGW 13 starts to obtain write data from the DCM 12, it shifts from the normal operation to the reprogramming main operation, starts the reprogramming main operation, starts distributing write data to the two-side memory ECU, and instructs the writing of the write data. When the two-side memory ECU starts to receive write data from the CGW 13, the programming phase (hereinafter also referred to as the installation phase) starts in the normal operation. That is, the two-side memory ECU performs the normal operation and installs the application in the background. The two-side memory ECU starts writing the received write data to the flash memory and starts rewriting the application.

[0609] In the two-side memory ECU, during the rewriting of the application, if the vehicle power source is switched from the IG power source to the +B power source by the user switching the IG switch from on to off (t25), after the vehicle power source is switched from the IG power source to the +B power source, the DCM 12 continues the data transmission / center communication action, the CGW 13 continues the reprogramming main action, and the two-side memory ECU continues the installation phase, and the rewriting of the application is continued. If a predetermined time, i.e., a self-holding period, has passed after the vehicle power source is switched from the IG power source to the +B power source, the DCM 12 interrupts the data transmission / center communication action, the CGW 13 interrupts the reprogramming main action, and the two-side memory ECU interrupts the installation phase, and the rewriting of the application is interrupted (t26). That is, until the predetermined time has passed after the IG switch 42 is turned off, the installation is continued by the power supply from the vehicle battery 40.

[0610] Then, when the vehicle power is switched from +B power to IG power by the user switching the IG switch from OFF to ON, the DCM 12 restarts the data transmission / center communication operation, the CGW 13 restarts the reprogramming main operation, the two-side memory ECU restarts the installation phase, and restarts the rewriting of the application (t27). That is, the vehicle power is switched from IG power to +B power by the user switching the IG switch from ON to OFF, and then the vehicle power is switched from +B power to IG power by the user switching the IG switch from OFF to ON, and each time a trip occurs, the two-side memory ECU repeats the interruption and restart of the rewriting of the application (t28 to t30). However, after the vehicle power is switched from IG power to +B power until the self-holding period has passed, the DCM 12 continues the data transmission / center communication operation, the CGW 13 continues the reprogramming main operation, the two-side memory ECU continues the installation phase, and continues the rewriting of the application.

[0611] When the 2-side memory ECU completes writing of the write data and rewriting of the application, the installation phase ends and the normal operation is transferred to the waiting for activation. That is, when the 2-side memory ECU is not in the activation phase, it will not start on the new side (B side) on which the application is rewritten, and will keep the old side (A side) started (t31).

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

[0613] When the suspended memory ECU and the independent memory ECU have completed writing the write data and rewriting the application respectively, the installation phase is terminated in the startup process (t33). When the CGW 13 sends a power startup request to the power management ECU 20 and the vehicle power is switched from +B power to IG power, the DCM 12 restarts the data transmission / center communication operation (t34).

[0614] When the 1-side suspended memory ECU completes writing of the write data and rewriting of the application, it transfers from the startup process to the waiting for activation. That is, when the activation phase is not performed, the 1-side suspended memory ECU will not start on the new side (B side) where the application is rewritten, and will keep starting on the old side (A side). When the 1-side independent memory ECU completes writing of the write data and rewriting of the application, it ends the installation phase in the startup process and becomes waiting for activation (t35).

[0615] When the power management ECU 20 switches the vehicle power supply from the IG power supply to the +B power supply according to the activation instruction from the CGW 13, the 2-side memory ECU and the 1-side suspended memory ECU are respectively switched from the old side to the new side, and are started on the new side, and the activation phase begins during the startup of the new side. The 1-side independent memory ECU starts to restart, and the activation phase begins during the restart after the installation is completed (t36, t37).

[0616] If activation is completed, the power management ECU 20 switches the vehicle power supply from the IG power supply to the +B power supply according to the activation completion instruction from the CGW 13, and the DCM 12 shifts from the data transmission / center communication action to the sleep / stop action and starts the sleep / stop action. The CGW 13 shifts from the reprogramming master action to the sleep / stop action and starts the sleep / stop action. The 2-side memory ECU, the 1-side suspended memory ECU, and the 1-side independent memory ECU shift from the new start to the sleep / stop action (t38).

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

[0618] Before downloading the distribution package from the center device 3 and before distributing it to the rewrite target ECU 19 to which the data is to be written, the CGW 13 performs the following checks. Before downloading the distribution package from the center device 3, the CGW 13 checks the radio wave environment, the remaining battery level of the vehicle battery 40, and the memory capacity of the DCM 12 so that the download can be performed normally. Before distributing it to the rewrite target ECU 19 to which the data is to be written, in order to distribute the written data normally, the CGW 13 performs intrusion sensor detection, door lock detection, curtain detection, and IG disconnection detection as checks for a human environment to prevent the installation environment from being unstable, and performs version and abnormality checks as checks for whether the rewrite target ECU 19 can be written. In addition, as checks for the written data distributed to the rewrite target ECU 19, the CGW 13 performs tampering checks, access authentication, and version checks before starting installation, performs communication isolation checks, abnormality checks, and the like during installation, and performs version checks, integrity checks, and DTC (Diagnostic Trouble Code) checks after the installation is completed.

[0619] Next, refer to Figure 66 to Figure 82 The screen displayed by the display terminal 5 is described. Fig.66As shown, in the structure of rewriting the application of the rewriting target ECU 19 through OTA, there are stages of activity notification, download, installation, and activation. Activity notification refers to the notification of program update. For example, when the center device 3 determines that there is an update of the application, the main device 11 downloads and distributes the specification data, which is an activity notification. The display terminal 5 displays a screen at each stage as the rewriting of the application progresses. In addition, here, the screen displayed by the vehicle-mounted display 7 is explained.

[0620] like Fig.67 As shown, CGW13, in normal time before the activity notification, for example, displays a navigation screen 501 such as a well-known route startup screen, which is one of the navigation functions, on the vehicle display 7. If an activity notification is generated from this state, Fig.32 As shown, CGW 13 displays an event notification icon 501a indicating the generation of an event notification at the lower right of navigation screen 501. The user can understand the generation of an event notification related to the update of the application by confirming the display of event notification icon 501a.

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

[0622] If the user operates the "Confirm" button 502a from this state, Fig.70As shown, the CGW 13 switches the display from the navigation screen 501 to the download consent screen 503, and displays the download consent screen 503 on the vehicle-mounted display 7. In the download consent screen 503, the CGW 13 notifies the user of the activity ID and the update name, and displays a "download start" button 503a, a "details confirmation" button 503b, and a "return" button 503c, waiting for the user's operation. In this case, the user can start downloading by operating the "download start" button 503a, can display the details of the download by operating the "details confirmation" button 503b, and can refuse downloading by displaying the "return" button 503c and return to the previous screen. When the "return" button 503c is operated, the user can enter the screen for starting downloading by operating the activity notification icon 501a.

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

[0624] If the user operates the downloading execution icon 501b from this state, Fig.73 As shown, the CGW 13 switches the display from the navigation screen 501 to the downloading execution screen 504, and displays the downloading execution screen 504 on the vehicle-mounted display 7. The CGW 13 notifies the user that the download is being executed in the downloading execution screen 504, and displays a "details confirmation" button 504a, a "return" button 504b, and a "cancel" button 504c, waiting for the user's operation. In this case, the user can display the details of the downloading execution by operating the "details confirmation" button 504a, and can interrupt the download by operating the "cancel" button 504c.

[0625] If the download is complete, Fig.74As shown, CGW 13 pops up a download completion notification screen 505 on the navigation screen 501. CGW 13 displays a prompt "Download completed, software update available" on the download completion notification screen 505 to notify the user of the completion of the download, and displays a "Confirm" button 505a and a "Later" button 505b to wait for the user's operation. In this case, the user can enter the screen for starting installation by operating the "Confirm" button 505a.

[0626] If the user operates the "Confirm" button 505a from this state, Fig.75 As shown, the CGW 13 switches the display from the navigation screen 501 to the installation consent screen 506, and displays the installation consent screen 506 on the vehicle-mounted display 7. In the installation consent screen 506, the CGW 13 notifies 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 "Return" button 506c, waiting for the user's operation. In this case, the user can start the installation immediately by operating the "Update Now" button 506a. In addition, the user can set the time when the installation is desired to be performed and operate the "Schedule Update" button 506b to start the scheduled installation. In addition, the user can refuse the installation by operating the "Return" button 506c and return to the previous screen. When the "Return" button 506c is operated, the user can enter the screen for starting the installation by operating the download execution icon 501b.

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

[0628] If CGW13 starts to install, Fig.77 As shown, the display is switched from the installation consent screen 506 to the navigation screen 501, the vehicle-mounted display 7 displays the navigation screen 501 again, and the installation execution icon 501c indicating that the installation is being executed is displayed at the lower right of the navigation screen 501. The user can understand that the installation is being executed by confirming the display of the installation execution icon 501c.

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

[0630] If CGW13 is installed, Fig.79 As shown, the display is switched from the navigation screen 501 to the activation consent screen 508, and the vehicle-mounted display 7 displays the activation consent screen 508. In the activation consent screen 508, CGW13 notifies the user of the content of the activation, and displays the "Return" button 508a and the "OK" button 508b, waiting for the user's operation. In this case, the user can refuse the activation and return to the previous screen by operating the "Return" button 508a. In addition, the user can agree to the activation by operating the "OK" button 508b. In addition, when the "Return" button 508a is operated, the user can enter the screen for executing the activation by operating the installation execution icon 501c. In addition, these displays and consents can also be omitted instead of being displayed according to the user's settings and the program scene.

[0631] If the user turns on the IG power supply from the state after the user operates the "OK" button 508b, Fig.80 As shown, CGW13 pops up and displays activation completion notification screen 509 on navigation screen 501. CGW13 displays a prompt "Software update completed" on activation completion notification screen 509 to notify the user of the completion of activation, and displays an "OK" button 509a and a "Details confirmation" button 509b to wait for the user's operation. In this case, the user can eliminate the pop-up display of activation completion notification screen 509 by operating the "OK" button 509a, and can display the details of activation completion by operating the "Details confirmation" button 509b.

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

[0633] If the user operates the "Details Confirmation" button 510a from this state, Fig.82As shown, the CGW 13 switches the display content of the confirmation operation screen 510, and displays the details of the completion of the activation on the vehicle-mounted display 7. The CGW 13 displays the functions added by the update, the functions after the change, etc. as the update details, and displays an "OK" button 510b. The CGW 13 determines that the user has confirmed the completion of the software update based on the user operating the "OK" buttons 509a and 510b.

[0634] As described above, the vehicle-side system 4 controls each action stage such as activity notification, download, installation, activation, and update completion, and prompts the user with a display that corresponds to each action stage. In addition, in the above description, the structure in which the CGW 13 controls the display is adopted, but it can also be configured so that the vehicle-mounted display 7 receives the action stage from the CGW 13, distributes the specification data, and displays it.

[0635] Next, refer to Figure 83 to Figure 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.

[0636] (1) Distribution Packet Delivery Decision Processing

[0637] (2) Distribution package download determination process

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

[0639] (4) Write Data Acquisition and Determination Process

[0640] (5) Installation instruction determination process

[0641] (6) Management of security access keys

[0642] (7) Verification of written data

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

[0644] (9) Power management processing for non-rewrite targets

[0645] (10) File transfer control processing

[0646] (11) Distribution Control Processing of Write Data

[0647] (12) Activation Request Instruction Processing

[0648] (13) Activated execution control processing

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

[0650] (15) Rollback execution control processing

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

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

[0653] (18) Rewritten execution control processing

[0654] (19) Session Establishment Process

[0655] (20) Determination and processing of retesting

[0656] (21) Synchronous Control Processing of Progress Status

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

[0658] (23) Receiving and controlling display control information

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

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

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

[0662] The center device 3 , DCM 12 , CGW 13 , ECU 19 , and the onboard display 7 have the following functional blocks as structures for performing the characteristic processes (1) to (26) described above, respectively.

[0663] like Fig.83 As shown, the center device 3 includes a distribution package sending unit 51. When the distribution package sending unit 51 receives a download request for a distribution package from the DCM 12, it sends the distribution package to the DCM 12. In addition to the above-mentioned structure, the center device 3 includes a distribution package sending determination unit 52, a progress status synchronization control unit 53, a display control information sending control unit 54, and a write data selection unit 55 (equivalent to an update data selection unit) as a structure for performing characteristic processing. When the write data selection unit 55 (equivalent to an update data selection unit) receives data storage surface information from the host device 11, it selects write data suitable for the non-operation surface based on the software version and the operation surface determined by the received data storage surface information. That is, the distribution package sending unit 51 sends a distribution package including the write data selected by the write data selection unit 55 to the DCM 12. The functional modules that perform characteristic processing will be described later.

[0664] like Fig.84As shown, the DCM 12 includes a download request sending unit 61, a distribution package downloading unit 62, a write data extracting unit 63, a write data transmitting unit 64, a rewrite specification data extracting unit 65, and a rewrite specification data transmitting unit 66. The download request sending unit 61 sends a download request of a distribution package to the center device 3. The distribution package downloading unit 62 downloads the distribution package from the center device 3. When the distribution package is downloaded from the center device 3 by the distribution package downloading unit 62, the write data extracting unit 63 extracts the write data from the downloaded distribution package.

[0665] When the write data transmission unit 64 extracts the write data from the distribution package by the write data extraction unit 63, the write data transmission unit 64 transmits the extracted write data to the CGW 13. When the distribution package is downloaded from the center device 3 by the distribution package download unit 62, the rewrite specification data extraction unit 65 extracts the rewrite specification data from the downloaded distribution package. When the rewrite specification data extraction unit 56 extracts the rewrite specification data from the distribution package, the rewrite specification data transmission unit 66 transmits the extracted rewrite specification data to the CGW 13. In addition to the above-mentioned structure, the DCM 12 has a distribution package download determination unit 67 and a write data transmission determination unit 68 as structures for performing characteristic processing. The functional modules for performing characteristic processing will be described later.

[0666] like Fig.85 and Fig.86 As shown, CGW13 has an acquisition request sending unit 71, a write data acquisition unit 72 (equivalent to an update data storage unit), a write data distribution unit 73 (equivalent to an update data distribution unit), a rewrite specification data acquisition unit 74, and a rewrite specification data analysis unit 75. The write data acquisition unit 72 acquires the write data from the DCM12 by receiving the write data from the DCM12. If the write data distribution unit 73 acquires the write data through the write data acquisition unit 72, it will distribute the acquired write data to the rewrite target ECU19 when it becomes the distribution timing of the write data. The rewrite specification data acquisition unit 74 acquires the rewrite specification data from the DCM12 by receiving the rewrite specification data from the DCM12. If the rewrite specification data analysis unit 75 acquires the rewrite specification data through the rewrite specification data acquisition unit 74, it will analyze the acquired rewrite specification data.

[0667] In addition to the above-mentioned configuration, the CGW 13 has, as a configuration 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-rewrite object power management unit 81, a file transfer control unit 82, a write data distribution control unit 83, an activation request instruction unit 84, a rewrite 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 reception control unit 89, a progress display screen display control unit 90, a program update report control unit 91, and a power self-maintaining execution control unit 92. The functional blocks for performing characteristic processing will be described later.

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

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

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

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

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

[0673] like Fig.89As shown, the center device 3 includes a software information acquisition unit 52a, an update presence determination unit 52b, an update suitability determination unit 52c, and an activity information transmission unit 52d in the distribution package transmission determination unit 52. The software information acquisition unit 52a acquires the software information of each ECU 19 from the vehicle side. Specifically, the software information acquisition unit 52a acquires ECU configuration information including software information such as version and writing surface and hardware information from the vehicle side. The software information acquisition unit 52a may also acquire vehicle status information such as fault code, anti-theft alarm function setting, and license agreement information from the vehicle side together with the ECU configuration information.

[0674] If the update existence determination unit 52b obtains the software information through the software information acquisition unit 52a, it determines whether there is update data for the vehicle based on the obtained software information. That is, the update existence determination unit 52b compares the version of the obtained software information with the version of the latest software information managed by itself, determines whether the two are consistent, and determines whether there is update data for the vehicle. If the update existence determination unit 52b determines that the two are consistent, it determines that there is no update data for the vehicle, and if it determines that the two are inconsistent, it determines that there is update data for the vehicle.

[0675] If the update existence determination unit 52b determines that there is update data for the vehicle, the update appropriateness determination unit 52c determines whether the vehicle state is a state suitable for the update of the program or the like using the distribution package. Specifically, the update appropriateness determination unit 52c determines whether the license agreement is established, whether the vehicle position is within the specified range pre-registered by the user, whether the setting of the alarm function of the vehicle is effective, whether the failure information of the ECU 19 is generated, and determines whether the vehicle state is a state suitable for downloading the distribution package. That is, the update appropriateness determination unit 52c determines whether the vehicle is likely to be updated against the user's intention, or whether the vehicle is likely to fail in the installation after downloading even if the download is successful.

[0676] If the update suitability determination unit 52c determines that the license agreement is established, the vehicle position is within the specified range pre-registered by the user, the setting of the vehicle alarm function is enabled, and the ECU 19 is not generating fault information, the vehicle state is determined to be a state suitable for updating the program or the like using the distribution package. If the update suitability determination unit 52c determines that at least any one of the license agreement is not established, the vehicle position is not within the specified range pre-registered by the user, the setting of the vehicle alarm function is not enabled, and the ECU 19 is generating fault information, the vehicle state is determined to be a state not suitable for updating the program or the like using the distribution package.

[0677] If the update suitability determination unit 52c determines that the vehicle state is a state suitable for updating the program or the like using the distribution package, the event information transmission unit 52d transmits the event information to the host device 11. If the update suitability determination unit 52c determines that the vehicle state is not a state suitable for updating the program or the like using the distribution package, the event information transmission unit 52d does not transmit the event information to the host device 11. The event information transmission unit 52d stores information related to the vehicle for which the event information has not been transmitted to the host device 11 in advance by making the above determination. In addition, the center device 3 may display information related to the vehicle for which the event information has not been transmitted to the host device 11.

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

[0679] When the center device 3 starts the distribution package transmission determination process, it acquires software information from the vehicle side (S101, equivalent to the software information acquisition step). That is, the center device 3 determines whether there is a software update for the vehicle. Based on the acquired software information, the center device 3 determines whether there is update data for the vehicle (S102, equivalent to the update existence determination step). When the center device 3 determines that there is update data for the vehicle (S102: "Yes"), it determines whether the vehicle state is a state suitable for updating the program, etc. using the distribution package (S103, equivalent to the update suitability determination step). When the center device 3 determines that the vehicle state is a state suitable for updating the program, etc. using the distribution package (S103: "Yes"), it sends activity information to the main device 11 (S104, equivalent to the activity information sending step), and ends the distribution package transmission determination process.

[0680] If the center device 3 determines that there is no update data for the vehicle (S102: No), the center device 3 sends the content that is not the target of the distribution package, that is, the content of the application program update that does not exist to the main device 11 (S105), and ends the distribution package transmission determination process. If the center device 3 determines that the vehicle state is not a state suitable for updating the program etc. using the distribution package (S103: No), the center device 3 sends the content that is not suitable for updating the program etc. and the reason thereof to the main device 11 (S106), and ends the distribution package transmission determination process. In this case, the main device 11 causes the vehicle display 7 to display the content that is suitable for updating the program etc. and the reason thereof. For example, if the license agreement is not established, the main device 11 causes the vehicle display 7 to display, for example, "The license is invalid, so the program cannot be updated. Please ask the dealer." In this way, the reason why the content is not suitable for updating the program etc. can be presented to the user, and appropriate information can be presented to the user.

[0681] As described above, the center device 3 performs the distribution package transmission determination process before transmitting the distribution package to the main device 11 and before transmitting the activity information, thereby being able to determine whether the state is suitable for updating the program etc. using the distribution package. Furthermore, the center device 3 transmits the distribution package to the main device 11 and transmits the activity information to the main device 11 only when it is determined that the state is suitable for updating the program etc. using the distribution package.

[0682] In the case of an update of a program or the like suitable for use with a distribution package, the center device 3 can send action information to the host device 11 when a license agreement is established, the vehicle position is within a predetermined range pre-registered by the user, the setting of the vehicle alarm function is enabled, and no failure information of the ECU 19 is generated. That is, the center device 3 can avoid sending action information to the host device 11 when a license agreement is not established, the vehicle position is outside a predetermined range such as a position far from the home, the setting of the vehicle alarm function is disabled, or failure information of the ECU 19 is generated. In this way, the center device 3 can avoid sending action information to the host device 11 for a vehicle that may be updated against the user's intention or a vehicle that may fail in installation even if the download is successful.

[0683] In addition, the center device 3 may perform a distribution package transmission determination process during the distribution package transmission. In this case, if the center device 3 determines that the vehicle state is a state suitable for updating the program or the like using the distribution package during the distribution package transmission, the distribution package transmission is continued, but if the center device 3 determines that the vehicle state is not a state suitable for updating the program or the like using the distribution package during the distribution package transmission, the distribution package transmission is interrupted. That is, if, for example, failure information of the ECU 19 is generated during the distribution package transmission, the center device 3 interrupts the distribution package transmission.

[0684] Next, the processing of the host device 11 which receives the event information transmitted from the center device 3 will be described. Fig.91 and Fig.92 The download determination process of the distribution package in the main device 11 is described. The vehicle program rewriting system 1 performs the download determination process of the distribution package in the main device 11. The above-mentioned (1) distribution package transmission determination process is a determination process performed by the center device 3 in the activity notification phase before the download phase, but the download determination process of the distribution package is a determination process performed by the main device 11 in the download phase. In addition, in this embodiment, the case where the DCM 12 in the main device 11 performs the download determination process of the distribution package is described, but it is also possible that the CGW 13 has the function of the DCM 12 and the download determination process of the distribution package is performed by the CGW 13.

[0685] like Fig.91As shown in FIG. 1 , the DCM 12 includes an event information receiving unit 67a, a downloadable determination unit 67b, and a download execution unit 67c in the download determination unit 67 of the distribution package. The event information receiving unit 67a receives event information from the center device 3. In addition, when event information is received from the center device 3, the event information is displayed. Fig.68 The event notification icon 501a is shown. When the downloadable determination unit 67b receives the event information through the event information receiving unit 67a, it determines whether the vehicle state is a state in which the distribution package can be downloaded. That is, the downloadable determination unit 67b determines whether the radio wave environment for communicating with the center device 3 is good, whether the battery remaining capacity of the vehicle battery 40 is greater than a prescribed capacity, and whether the free capacity of the memory of the DCM 12 is greater than a prescribed capacity, and determines whether the vehicle state is a state in which the distribution package can be downloaded.

[0686] If the downloadable determination unit 67b determines that the radio wave environment is good, the battery remaining capacity of the vehicle battery 40 is greater than the prescribed capacity, and the memory free capacity of the DCM 12 is greater than the prescribed capacity, the vehicle state is determined to be a state in which the distribution package can be downloaded. If the downloadable determination unit 67b determines that at least one of the radio wave environment is not good, the battery remaining capacity of the vehicle battery 40 is not greater than the prescribed capacity, and the memory free capacity of the DCM 12 is not greater than the prescribed capacity, the vehicle state is determined not to be a state in which the distribution package can be downloaded.

[0687] In this way, the downloadable determination unit 67b determines whether the downloading may not be completed normally. Fig.70 and Fig.71 In the download consent screen 503 shown, the downloadable determination unit 67b makes a determination based on the condition that the "download start" button 503a is operated by the user. In addition, the downloadable determination unit 67b may be configured to also make a determination on the determination items of the center device 3. That is, for example, when the setting of the alarm function of the vehicle is enabled or when the failure information of the ECU 19 is not generated, the downloadable determination unit 67b determines that the download is possible.

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

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

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

[0691] When the main device 11 starts the distribution package download determination process, it receives the activity information from the center device 3 (S201, equivalent to the activity information receiving step). The main device 11 determines whether the vehicle state is a state in which the distribution package can be downloaded (S202, equivalent to the download determination step). When the main device 11 determines that the vehicle state is a state in which the distribution package can be downloaded (S202: "Yes"), the distribution package corresponding to the activity is downloaded from the center device 3 (S203, equivalent to the download execution step), and the distribution package download determination process is terminated. When the main device 11 determines that the vehicle state is not a state in which the distribution package can be downloaded (S202: "No"), the distribution package is not downloaded from the center device 3, and the distribution package download determination process is terminated.

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

[0693] In the case where the radio wave environment is good, the remaining battery level of the vehicle battery 40 is greater than or equal to a prescribed capacity, and the free memory capacity of the DCM 12 is greater than or equal to a prescribed capacity, which is a case suitable for downloading the distribution package, the main device 11 can download the distribution package from the center device 3. That is, in the case where the radio wave environment is good, the remaining battery level of the vehicle battery 40 is less than or equal to a prescribed capacity, or the free memory capacity of the DCM 12 is less than or equal to a prescribed capacity, it is possible to avoid downloading the distribution package from the center device 3.

[0694] In addition, the host device 11 may perform a download determination process of the distribution package during the download of the distribution package. In this case, if the host device 11 determines that the vehicle state is a state in which the distribution package can be downloaded during the download of the distribution package, the distribution package will continue to be downloaded from the center device 3, but if the host device 11 determines that the vehicle state is not a state in which the distribution package can be downloaded during the download of the distribution package, the download of the distribution package from the center device 3 will be interrupted. That is, if, for example, the radio wave environment is not good, the battery remaining capacity of the vehicle battery 40 is less than a prescribed capacity, or the memory free capacity of the DCM 12 is less than a prescribed capacity during the download of the distribution package, the host device 11 interrupts the download of the distribution package.

[0695] In this way, the center device 3 determines whether the vehicle is likely to receive an update contrary to the user's intention or is likely to fail in installation, and the host device 11 determines whether the download is likely to fail, thereby preventing useless activity information and distribution packages from being sent from the center device 3 to the host device 11.

[0696] The center device 3 has the following structure. It is provided with: a software information acquisition unit 52a, which acquires the software information of the electronic control device from the vehicle side; an update existence determination unit 52b, which determines whether there is update data for the vehicle based on the software information acquired by the software information acquisition unit; an update suitability determination unit 52c, which determines whether the vehicle state is suitable for updating when the update existence determination unit determines that there is update data; and an activity information sending unit 52d, which sends activity information related to the update to the vehicle main device when the update suitability determination unit determines that the vehicle state is suitable for updating.

[0697] The main device 11 has the following structure. It includes: an activity information receiving unit 67a that receives activity information from the central device; a downloadable determination unit 67b that determines whether the vehicle state is a state in which the distribution package can be downloaded when the activity information is received by the activity information receiving unit; and a download execution unit 67c that downloads the distribution package from the central device when the downloadable determination unit determines that the vehicle state is a state in which the distribution package can be downloaded.

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

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

[0700] like Fig.93As shown, the DCM 12 includes an acquisition request receiving unit 68a and a communication status determining unit 68b in the write data transmission determining unit 68. The acquisition request receiving unit 68a receives an acquisition request for write data from the CGW 13. When the acquisition request for write data is received by the acquisition request receiving unit 68a, for example, when the transmission possibility determination flag preset by the user is a first specified value, the communication status determining unit 68b determines the state of data communication between the center device 3 and the DCM 12. For example, when the specified condition is checked at the time of installation, the transmission possibility determination flag is 1 (first specified value), and when the check is omitted, the transmission possibility determination flag is 0 (second specified value). Under the condition that the communication status determining unit 68b determines that the data communication between the center device 3 and the DCM 12 is in a connected state, the write data transmission unit 64 transmits the write data to the CGW 13.

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

[0702] If DCM12 determines that a request to obtain write data is received from CGW13, it starts a write data transmission determination process. If DCM12 starts a write data transmission determination process, it determines a transmission determination flag (S301, S302). If DCM12 determines that the transmission determination flag is a first specified value (S301: "Yes"), it determines the state of data communication between the center device 3 and itself (S303). If DCM12 determines that the data communication between the center 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 center device 3 and itself is not in a connected state but in a disconnected state (S303: "No"), it does not transmit the write data to CGW13 and ends the write data transmission determination process.

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

[0704] As described above, the DCM 12 performs a write data transmission determination process before transmitting the write data to the CGW 13, and determines the state of data communication between the center device 3 and itself when the transmission availability determination flag is the first predetermined value. If the DCM 12 determines that the data communication is in the connected state, it starts the transmission of the write data, and if it determines that the data communication is in the disconnected state, it does not start the transmission of the write data and waits. When data communication with the center device 3 is possible, the write data can be transmitted to the CGW 13, and the installation can be performed in the rewrite target ECU 19.

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

[0706] Next, the acquisition determination process of write data will be described. The vehicle program rewriting system 1 performs the acquisition determination process of write data in the CGW 13. The above-mentioned (3) write data transmission determination process is a determination process performed by the DCM 12 during the installation phase, and the acquisition determination process of write data is also a determination process performed by the CGW 13 during the installation phase.

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

[0708] Next, refer to Fig.96The following describes the operation of the write data acquisition determination unit 76 in the CGW 13. The CGW 13 executes a write data acquisition determination program to perform a write data acquisition determination process.

[0709] If CGW13 determines that an event of a write data acquisition request occurs, it starts a write data acquisition determination process. If CGW13 starts a write data acquisition determination process, it determines the acquisition possibility determination flag (S401, S402). If CGW13 determines that the acquisition possibility determination flag is the first specified value (S401: "Yes"), it determines the state of data communication between the center device 3 and the DCM12 (S403: If CGW13 determines that the data communication between the center device 3 and the DCM12 is connected (S403: "Yes"), it sends a write data acquisition request to the DCM12 (S404), and ends the write data acquisition determination process. Thereafter, if write data is transmitted from the DCM12, the CGW13 distributes the transmitted write data to the rewrite target ECU19. If CGW13 determines that the data communication between the center device 3 and the DCM12 is disconnected and not connected (S403: "No"), it does not send a write data acquisition request to the DCM12, and ends the write data acquisition determination process.

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

[0711] As described above, the CGW 13 performs the write data acquisition determination process before acquiring the write data from the DCM 12, and when the acquisition possibility determination flag is the first predetermined value, determines the state of data communication between the center device 3 and the DCM 12. If the CGW 13 determines that the data communication is in the connected state, it starts acquiring the write data, and if it determines that the data communication is in the disconnected state, it does not start acquiring the write data and waits. When communication with the center device 3 is possible, the write data can be acquired from the DCM 12, and installation can be performed in the rewrite target ECU 19.

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

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

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

[0715] The second condition is that the CGW 13 can communicate data with the center device 3. The third condition is that the vehicle state is such that it can be installed. The fourth condition is such a condition that the rewrite target ECU 19 can be installed. Here, the fourth condition includes not only that the rewrite target ECU 19 of the installation target can be installed, but also that the rewrite target ECU 19 that cooperates with the rewrite target ECU 19 of the installation target can be installed. The fifth condition is that the written data is normal data. Here, normal data includes data suitable for the rewrite target ECU 19, data that has not been tampered with, etc.

[0716] If the installation condition determination unit 77a determines that all of the first condition, the second condition, the third condition, the fourth condition, and the fifth condition are satisfied, the installation instruction unit 77b instructs the rewrite target ECU 19 to install the application. That is, if the installation condition determination unit 77a determines that the user consent related to the installation is obtained, the CGW 13 can communicate data with the center device 3, the vehicle state is in a state where the installation is possible, the rewrite target ECU 19 is in a state where the installation is possible, and the written data is normal data, the installation instruction unit 77b instructs the rewrite target ECU 19 to install the application. Specifically, the installation instruction unit 77b obtains the written data from the DCM 12 and transmits the obtained written data to the rewrite target ECU 19. If the installation condition determination unit 77a determines that at least one of the first condition, the second condition, the third condition, the fourth condition, and the fifth condition is not satisfied, the installation instruction unit 77b does not instruct the rewrite target ECU 19 to install the application, and prompts the user to wait or the content and reason why the installation cannot be started.

[0717] The vehicle state information acquisition unit 77c acquires the vehicle state information from the center device 3. When the installation of the application program in all the rewrite target ECUs 19 is completed, the activation condition determination unit 77d determines whether the sixth condition, the seventh condition, and the eighth condition are satisfied. The sixth condition is a condition that the user consent related to the activation is obtained. The user consent related to the activation is, for example, indicated in Fig.79 The screen shown is a user consent operation for activation (e.g., pressing the "OK" button 508b). Alternatively, the process from download to activation may be considered as one update, which is a user consent operation for the update. The seventh condition is that the vehicle state is in a state that can be activated. The eighth condition is that the rewrite target ECU 19 is in a state that can be activated.

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

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

[0720] When the CGW 13 starts the instruction determination process for installation, it determines whether the first condition is satisfied and whether the user consent related to the installation is obtained (S501, which corresponds to a part of the installation condition determination step). When the CGW 13 determines that the user consent related to the installation is obtained (S501: "Yes"), it determines whether the second condition is satisfied and whether data communication with the center device 3 is possible (S502, which corresponds to a part of the installation condition determination step). The CGW 13 determines whether data communication with the center device 3 is possible based on the communication radio wave status in the DCM 12.

[0721] If CGW13 determines that it is able to communicate data with the center device 3 (S502: "Yes"), it determines whether the third condition is satisfied and whether the vehicle state is ready for installation (S503, equivalent to a part of the installation condition determination step). As the vehicle state, for example, CGW13 determines whether the battery remaining capacity of the vehicle battery 40 is above the specified capacity, and when the memory structure of the rewrite target ECU19 is a single-sided memory, it determines whether the vehicle is in a parking state (IG disconnected state), etc., to determine whether the vehicle state is ready for installation. These vehicle state conditions may also be determined by referring to the received rewrite specification data (refer to Fig.44 For example, when the remaining battery level of the vehicle battery 40 is greater than the specified capacity specified by the rewrite specification data and is consistent with the vehicle state specified by the rewrite specification data (only the parking state, only the driving state, or both the parking state and the driving state), the CGW 13 determines that the vehicle state is installable.

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

[0723] If CGW13 determines that the rewrite object ECU19 can be installed (S504: "Yes"), it determines whether the fifth condition is met and determines whether the written data is normal data (S505, equivalent to a part of the installation condition determination step). In the case where the written data is in accordance with the writing surface (non-operation surface) of the rewrite object ECU19 and the verification result of the integrity of the written data is normal, CGW13 determines that the written data is normal data. If CGW13 determines that the written data is normal data (S505: "Yes"), it instructs the rewrite object ECU19 to install the application (S506, equivalent to the installation instruction step). In this way, CGW13 makes determinations after the second condition based on the satisfaction of the first condition. In addition, CGW13 finally makes a determination of the fifth condition. If CGW13 determines that all the first to fifth conditions are met, it instructs the rewrite object ECU19 to install the application.

[0724] On the other hand, if the CGW 13 determines that the user consent related to the installation has not been obtained (S501: No), determines that data communication with the center device 3 cannot be performed (S502: No), determines that the vehicle state is not installable (S503: No), determines that the rewrite target ECU 19 cannot be installed (S504: No), and determines that the written data is not normal data (S505: No), the installation of the application program is not instructed to the rewrite target ECU 19. In addition, in the above-mentioned processing, the structure of determining the condition of obtaining the user consent related to the installation before other conditions is described, but the structure of determining after other conditions may also be used.

[0725] If the CGW13 instructs the rewrite target ECU19 to install the application, the CGW13 distributes the write data to the rewrite target ECU19 (S507) and determines whether the installation is completed (S508). If the CGW13 determines that the installation is completed (S508: "Yes"), it determines whether the sixth condition is met and whether the user consent related to activation is obtained (S509). If the CGW13 determines that the user consent related to activation is obtained (S509: "Yes"), it determines whether the seventh condition is met and whether the vehicle state is a state that can be activated (S510).

[0726] If the CGW13 determines that the vehicle state is in an activation state (S510: Yes), it determines whether the eighth condition is satisfied, and determines whether the rewrite target ECU19 is in an activation state (S511). If the CGW13 determines that the rewrite target ECU19 is in an activation state (S511: Yes), it instructs the rewrite target ECU19 to activate (S512). In this way, if the CGW13 determines that all the sixth to eighth conditions are satisfied, it instructs the rewrite target ECU19 to activate.

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

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

[0729] As described above, the CGW 13 performs the installation instruction determination process before instructing the rewrite target ECU 19 to install the application program, and if it is determined that the first condition that the user's consent related to the installation is obtained, the second condition that data communication with the center device 3 is possible, the third condition that the vehicle state is in a state that allows installation, the fourth condition that the rewrite target ECU 19 is in a state that allows installation, and the fifth condition that the written data is normal data are all satisfied, the CGW 13 instructs the rewrite target ECU 19 to install the application program. The rewrite target ECU 19 can be appropriately instructed to install the application program.

[0730] (6) Management of security access keys

[0731] Reference Figure 101 to Figure 105 The management process of the security access key is explained. The security access key is a key used to ...

Claims

1. A vehicle information communication system comprising a central device installed outside a vehicle and an on-board device installed in the vehicle, wherein: The central device manages data written to a plurality of electronic control devices mounted on a vehicle, and the vehicle-mounted device comprises: an in-vehicle communication unit for communicating with the plurality of electronic control devices; and an out-of-vehicle communication unit for wirelessly communicating with the central device, wherein: The vehicle-mounted device sends configuration information related to the configurations of the plurality of electronic control devices to the central device, wherein the configuration information includes identification information of hardware of the electronic control devices mounted on the vehicle and identification information of software of the electronic control devices mounted on the vehicle. The central device has: a single vehicle configuration information storage unit that stores the configuration information transmitted from a plurality of vehicles in a format that enables identification of transmission times; and an activity information storage unit storing, as activity information related to data update for a vehicle, activity identification information and target vehicle identification information capable of identifying a target vehicle for data update, Referring to the activity information storage unit and the single vehicle configuration information storage unit, if the configuration information of the target vehicle is not transmitted within a predetermined period, a message for prompting data update is transmitted to the onboard device of the target vehicle, The center device records the year, month, day and time when the configuration information is transmitted from the vehicle as an access log of the vehicle in a format that allows the transmission time to be identified.

2. The vehicle information communication system according to claim 1, wherein: The center device determines the target vehicle by referring to the single vehicle structure information storage unit and the movement information storage unit.

3. The vehicle information communication system according to claim 1, wherein: Upon receiving the configuration information of each of the plurality of electronic control devices, the vehicle-mounted device transmits the configuration information to the central device.

4. The vehicle information communication system according to claim 1, wherein: The vehicle-mounted device transmits the configuration information when the ignition switch of the vehicle is turned on.

5. The vehicle information communication system according to claim 1, wherein: The above structure information is supplemented with vehicle information indicating whether the vehicle is an electric vehicle. If the target vehicle is an electric vehicle, the central device includes an instruction for starting an electronic control device of the target vehicle in the message and sends the instruction. The in-vehicle device that has received the message activates the electronic control device to execute processing related to data updating.

6. The vehicle information communication system according to claim 5, wherein: As processing related to the data update, the in-vehicle device transmits configuration information related to the configurations of the plurality of electronic control devices to the center device.

7. The vehicle information communication system according to claim 5, wherein: If the target vehicle is not an electric vehicle, the center device transmits at least text information that can be displayed on a display of the target vehicle as the message.

8. The vehicle information communication system according to claim 1, wherein: The center device includes a user information storage unit, which stores user information associated with the target vehicle. When the destination of the portable terminal is stored in the user information storage unit, text information that can be displayed on the portable terminal is transmitted as the message.

9. The vehicle information communication system according to claim 8, wherein: If the user sends the sending date and destination of the message to the center device via the portable terminal, the center device stores the sending date and destination in the user information storage unit, and sends the message to the destination on the sending date regardless of whether the structure information is sent or not.

10. The vehicle information communication system according to any one of claims 1 to 9, wherein: The above message is sent using SMS service.

11. The vehicle information communication system according to claim 1, wherein: The vehicle-mounted device transmits the configuration information related to the configurations of the plurality of electronic control devices to the central device upon receipt of the message.

12. The vehicle information communication system according to claim 11, wherein: The above message contains instructions to the above vehicle-mounted device, When receiving the message from the center device, the vehicle-mounted device transmits the configuration information related to the configurations of the plurality of electronic control devices to the center device.

13. The vehicle information communication system according to claim 1, wherein: The above message contains instructions to the above vehicle-mounted device, When receiving the message from the center device, the vehicle-mounted device transmits the configuration information related to the configurations of the plurality of electronic control devices to the center device.

14. A central device, wherein: The central device disposed outside the vehicle is capable of wirelessly communicating with an onboard device mounted on the vehicle and managing data written to a plurality of electronic control devices mounted on the vehicle. The onboard device comprises: an in-vehicle communication unit for communicating with the plurality of electronic control devices; and an out-of-vehicle communication unit for wirelessly communicating with the outside of the vehicle. The onboard device is capable of transmitting configuration information related to the configuration of the plurality of electronic control devices to the outside of the vehicle, wherein the configuration information includes identification information of hardware of the electronic control device mounted on the vehicle and identification information of software of the electronic control device mounted on the vehicle. The central device has: a single vehicle configuration information storage unit that stores the configuration information transmitted from a plurality of vehicles in a format that enables identification of transmission times; and an activity information storage unit storing, as activity information related to data update for a vehicle, activity identification information and target vehicle identification information capable of identifying a target vehicle for data update, The center device refers to the activity information storage unit and the single vehicle structure information storage unit, and if no structure information is sent from the target vehicle within a predetermined period, sends a message for prompting data update to the vehicle-mounted device of the target vehicle, The center device records the year, month, day and time when the configuration information is transmitted from the vehicle as an access log of the vehicle in a format that allows the transmission time to be identified.

15. A method performed by a central device, wherein: The central device disposed outside the vehicle is capable of wirelessly communicating with an onboard device mounted on the vehicle and managing data written to a plurality of electronic control devices mounted on the vehicle. The onboard device comprises: an in-vehicle communication unit for communicating with the plurality of electronic control devices; and an out-of-vehicle communication unit for wirelessly communicating with the outside of the vehicle. The onboard device is capable of transmitting configuration information related to the configuration of the plurality of electronic control devices to the outside of the vehicle, wherein the configuration information includes identification information of hardware of the electronic control device mounted on the vehicle and identification information of software of the electronic control device mounted on the vehicle. The central device has: a single vehicle configuration information storage unit that stores the configuration information transmitted from a plurality of vehicles in a format that enables identification of transmission times; and an activity information storage unit storing, as activity information related to data update for a vehicle, activity identification information and target vehicle identification information capable of identifying a target vehicle for data update, The above methods include: Referring to the above-mentioned activity information storage unit and the above-mentioned bicycle structure information storage unit; and If no structural information is transmitted from the target vehicle within a predetermined period, a message for prompting data update is transmitted to the onboard device of the target vehicle, The center device records the year, month, day and time when the configuration information is transmitted from the vehicle as an access log of the vehicle in a format that allows the transmission time to be identified.

Images