Data communication system, center device and update data placement program

Abstract

This data communication system 1 comprises: a center device (2) that places update data in a content delivery network (CDN); and a master device (4) that installs the update data downloaded from the CDN into an electronic control device that is to be reprogrammed. The center device uses a predetermined cryptographic method to encrypt the update data, and places the encrypted update data in the CDN. The master device uses a division streaming method to download the encrypted update data from the CDN.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is based on Japanese Application No. 2021-161213 filed on September 30, 2021, the contents of which are incorporated herein by reference. [Technical field]

[0002] Honkai Show Data communication system, center equipment and Update data placement program To Regarding. [Background technology]

[0003] In recent years, with the diversification of vehicle control such as driving assistance functions and automatic driving functions, the scale of application programs such as vehicle control and diagnosis mounted on electronic control devices (hereinafter referred to as ECUs (Electronic Control Units)) is increasing. In addition, with version upgrades due to function improvements, etc., the opportunities to reprogram ECU application programs are also increasing. Reprogramming may also be called program updating. Meanwhile, with the development of communication networks, etc., connected car technology is also becoming widespread. In light of this, for example, Patent Document 1 discloses a technology in which an update package in which update data is packaged is distributed from a center device to a master device on the vehicle side by OTA (Over The Air) technology. The master device is a device that manages the reprogramming of ECU application programs. The update data distributed from the center device to the master device includes, for example, application programs and data for automatic driving, advanced driver-assistance systems (ADAS (Advanced Driver-Assistance Systems)), multimedia, etc. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2020-276424 A Summary of the Invention

[0005] In recent years, in order to improve the user experience (hereinafter referred to as UX (User Experience)) of a vehicle, the data size of update packages distributed from a center device to a master device has become large, reaching the order of several GB or more. Also, it has been considered to increase the update frequency by frequently updating application programs. When an update package with a large data size of several GB or more is distributed from the center device to the master device, if the memory capacity of the buffer memory of the master device is insufficient, the master device needs to download the update package divided into units of several KB from the center device by streaming and transfer the divided update package to the target ECU by streaming.

[0006] However, when calculating the cost of a content delivery network (CDN) service for cloud computing services, the cost of range requests using Hypertext Transfer Protocol (HTTP) / Hypertext Transfer Protocol Secure (HTTPS) is the dominant factor in the delivery cost, rather than the cost of data traffic. It is very important to suppress the delivery cost of HTTPS in order to improve the competitiveness of OTA service prices. Therefore, it is desirable to download update packages securely from the center device to the master device using streaming without establishing an HTTPS session to the CDN.

[0007] An object of the present disclosure is to appropriately reduce distribution costs when a master device downloads update data from a center device.

[0014] According to one aspect of the present disclosure, a center device that places update data in a content delivery network (CDN) and a master device that installs the update data downloaded from the CDN in an electronic control device to be reprogrammed are included. The center device is connected to CDNs of multiple operators, and selects a CDN with a superior delivery cost from among the CDNs of the multiple operators based on at least one of a delivery method, a delivery area, a communication protocol, and a delivery data size, and places the update data in the selected CDN without encrypting the update data. The master device establishes transport layer security (TLS) with the CDN and then downloads the update data from the CDN.

[0015] The center device selects a CDN with the most advantageous delivery cost from among CDNs of multiple operators with different delivery costs without encrypting the update data, places the encrypted update data in the selected CDN, and the master device establishes Transport Layer Security (TLS) with the CDN and then downloads the update data from the CDN. This makes it possible to appropriately suppress the delivery cost when the master device downloads the update data from the center device. [Brief description of the drawings]

[0016] The above and other objects, features and advantages of the present disclosure will become more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which: [Figure 1] FIG. 1 is a diagram showing a process flow in the entire system of the first embodiment; [Diagram 2] FIG. 2 is a functional block diagram of the OTA center and the OTA master. [Diagram 3] FIG. 3 is a diagram illustrating an encryption process in the CTR mode. [Figure 4] FIG. 4 is a diagram for explaining the decoding process in the CTR mode. [Diagram 5] FIG. 5 is a diagram showing a comparison of the advantages and disadvantages of the CBC mode and the CTR mode. [Figure 6] FIG. 6 is a graph showing a comparison of throughput between CBC mode and CTR mode. [Figure 7] FIG. 7 is a diagram illustrating the decryption process in CBC mode. [Figure 8] FIG. 8 is a diagram for explaining the decoding process in the CTR mode. [Figure 9] FIG. 9 is a diagram showing a process of the OTA center; [Figure 10] FIG. 10 is a diagram showing the processing of the center; [Figure 11] FIG. 11 is a diagram showing a process of the OTA center; [Figure 12] FIG. 12 is a diagram showing the process of the OTA master. [Figure 13] FIG. 13 is a diagram showing the process of the OTA master. [Figure 14] FIG. 14 is a diagram showing the process of the OTA master. [Figure 15] FIG. 15 is a diagram illustrating encryption processing in the OFB mode according to the second embodiment; [Figure 16] FIG. 16 is a diagram for explaining a decoding process in the OFB mode. [Figure 17] FIG. 17 is a diagram showing a comparison of advantages and disadvantages of the CBC mode and the OFB mode. [Figure 18] FIG. 18 is a diagram showing a comparison of throughput between CBC mode and OFB mode. [Figure 19] FIG. 19 is a diagram for explaining the decoding process in the CTR mode. [Figure 20] FIG. 20 is a diagram for explaining a decoding process in the OFB mode. [Figure 21] FIG. 21 is a diagram showing a process of the OTA center; [Figure 22] FIG. 22 is a diagram showing a process of the OTA center; [Figure 23] FIG. 23 is a diagram showing a process of the OTA center; [Figure 24] FIG. 24 is a diagram showing the process of the OTA master. [Diagram 25] FIG. 25 is a diagram showing the process of the OTA master. [Figure 26] FIG. 26 is a diagram showing the process of the OTA master. [Figure 27] FIG. 27 is a diagram showing a process flow in the entire system of the third embodiment; [Figure 28] FIG. 28 is a diagram showing a process of the OTA center; [Figure 29] FIG. 29 is a diagram showing a process of the OTA center. [Diagram 30] FIG. 30 is a diagram showing a process of the OTA center. [Diagram 31] FIG. 31 is a diagram showing the process of the OTA master. [Diagram 32] FIG. 32 is a diagram showing the process of the OTA master. [Diagram 33] FIG. 33 is a diagram showing the process of the OTA master. [Diagram 34] FIG. 34 is a diagram showing a process flow in the entire system of the fourth embodiment; [Diagram 35] FIG. 35 is a functional block diagram of the OTA center and the OTA master. [Diagram 36] FIG. 36 is a diagram showing the process of the OTA master. [Figure 37] FIG. 37 is a diagram showing the process of the OTA master. [Figure 38] FIG. 38 is a diagram showing the process of the OTA master. [Figure 39] FIG. 39 is a diagram showing a process of the OTA master according to the fifth embodiment; [Diagram 40] FIG. 40 is a diagram showing the process of the OTA master. [Diagram 41] FIG. 41 is a diagram showing the process of the OTA master. [Diagram 42] FIG. 42 is a diagram showing the relationship between memory capacity and access speed; [Diagram 43] FIG. 43 is a diagram showing a process flow in the entire system of the sixth embodiment; [Diagram 44]FIG. 44 is a functional block diagram of the OTA center and the OTA master. [Diagram 45] FIG. 45 is a diagram showing a manner in which RP metadata is transmitted; [Diagram 46] FIG. 46 is a diagram showing the structure of RP metadata. [Figure 47] FIG. 47 is a diagram showing the structure of RP metadata. [Figure 48] FIG. 48 is a diagram showing a process of the OTA center. [Figure 49] FIG. 49 is a diagram showing a process of the OTA center. [Figure 50] FIG. 50 is a diagram showing a process of the OTA center. [Figure 51] FIG. 51 is a diagram showing a process of the OTA center. [Figure 52] FIG. 52 is a diagram showing the process of the OTA master. [Figure 53] FIG. 53 is a diagram showing the process of the OTA master. [Figure 54] FIG. 54 is a diagram showing the process of the OTA master. [Figure 55] FIG. 55 is a diagram showing a process flow in the entire system of the seventh embodiment. [Figure 56] Figure 56 shows the function of CCMP mode. [Figure 57] FIG. 57 is a diagram for explaining the estimation of throughput in the CCMP mode. [Figure 58] FIG. 58 is a functional block diagram of a conventional method. [Figure 59] FIG. 59 is a diagram for explaining the estimation of throughput by the conventional method. [Figure 60] FIG. 60 is a diagram showing a comparison of throughput between the CCMP mode and the conventional method. [Figure 61] FIG. 61 is a functional block diagram of the OTA center and the OTA master. [Figure 62] FIG. 62 is a diagram showing a process of the OTA center. [Figure 63]FIG. 63 is a diagram showing a process of the OTA center. [Figure 64] FIG. 64 is a diagram showing a process of the OTA center. [Figure 65] FIG. 65 shows the process of the OTA master. [Figure 66] FIG. 66 is a diagram showing the process of the OTA master. [Figure 67] FIG. 67 shows the process of the OTA master. [Figure 68] FIG. 68 is a diagram showing a process flow in the entire system of the eighth embodiment. [Figure 69] FIG. 69 is a functional block diagram of the GCMP mode. [Figure 70] FIG. 70 is a diagram for explaining an estimation of throughput in the GCMP mode. [Figure 71] FIG. 71 is a diagram showing a comparison of throughput between the GCMP mode and the conventional method. [Figure 72] FIG. 72 is a diagram showing a process of the OTA center. [Figure 73] FIG. 73 is a diagram showing a process of the OTA center. [Figure 74] FIG. 74 is a diagram showing a process of the OTA center. [Figure 75] FIG. 75 is a diagram showing the processing of the OTA master. [Figure 76] FIG. 76 is a diagram showing the process of the OTA master. [Figure 77] FIG. 77 shows the process of the OTA master. [Figure 78] FIG. 78 is a diagram showing a process flow in the entire system of the ninth embodiment. [Figure 79] FIG. 79 is a diagram showing the processing of the OTA center. [Figure 80] FIG. 80 is a diagram showing a process of the OTA center. [Figure 81] FIG. 81 is a diagram showing a process of the OTA center. [Figure 82] FIG. 82 is a diagram showing a process of the OTA center. [Figure 83] FIG. 83 is a diagram showing the process of the OTA master. [Figure 84] FIG. 84 is a diagram showing the process of the OTA master. [Figure 85] FIG. 85 is a diagram showing the process of the OTA master. [Figure 86] FIG. 86 is a diagram showing the process of the OTA master. [Figure 87] FIG. 87 is a diagram showing a process flow in the entire system of the tenth embodiment. [Figure 88] Figure 88 shows a comparison of CDN costs. [Figure 89] Figure 89 shows a comparison of CDN costs. [Figure 90] Figure 90 shows a CDN price table for each cloud service. [Figure 91] FIG. 91 shows a price table of storage methods of each cloud service provider. [Figure 92] FIG. 92 is a price table for each streaming size in the streaming method of a cloud service provider. [Figure 93] FIG. 93 is a price table showing the streaming sizes of the streaming methods of each cloud service provider. [Figure 94] FIG. 94 is a functional block diagram of the OTA center and the OTA master. [Figure 95] FIG. 95 is a diagram showing the processing of the OTA center. [Figure 96] FIG. 96 is a diagram showing the processing of the OTA center. [Figure 97] FIG. 97 is a diagram showing the processing of the OTA center. [Figure 98] FIG. 98 is a diagram showing the processing of the OTA center. [Figure 99] FIG. 99 is a diagram showing the flow of processing in the entire system of the eleventh embodiment. [Figure 100]FIG. 100 is a diagram showing a common key that can be shared in DHE or ECDHE. [Figure 101] FIG. 101 is a diagram showing the processing of the OTA center. [Figure 102] FIG. 102 is a diagram showing a process of the OTA center. [Figure 103] FIG. 103 is a diagram showing the processing of the OTA center. [Figure 104] FIG. 104 is a diagram showing the processing of the OTA center. [Figure 105] FIG. 105 is a diagram showing the process of the OTA master. [Fig. 106] FIG. 106 is a diagram showing the process of the OTA master. [Figure 107] FIG. 107 is a diagram showing the processing of the OTA master. [Figure 108] FIG. 108 is a diagram showing the process of the OTA master. [Fig. 109] FIG. 109 is a diagram showing a process flow in the entire system of the twelfth embodiment. [Figure 110] FIG. 110 is a diagram showing the processing of the OTA center. [Figure 111] FIG. 111 is a diagram showing the processing of the OTA center. [Figure 112] FIG. 112 is a diagram showing the processing of the OTA center. [Figure 113] FIG. 113 is a diagram showing the process of the OTA master. [Fig. 114] FIG. 114 is a diagram showing the process of the OTA master. [Fig. 115] FIG. 115 is a diagram showing the processing of the OTA master. [Fig. 116] FIG. 116 is a diagram showing a process flow in the entire system of the thirteenth embodiment. [Fig. 117] FIG. 117 is a diagram for explaining the encryption process in the CTR mode. [Fig. 118] FIG. 118 is a diagram for explaining the decoding process in the CTR mode. [Figure 119]FIG. 119 is a diagram showing the processing of the OTA center. [Figure 120] FIG. 120 is a diagram showing a process of the OTA center. [Figure 121] FIG. 121 is a diagram showing the processing of the OTA center. [Figure 122] FIG. 122 is a diagram showing the processing of the OTA master. [Figure 123] FIG. 123 is a diagram showing the processing of the OTA master. [Figure 124] FIG. 124 is a diagram showing the process of the OTA master. [Fig. 125] FIG. 125 is a diagram showing a process flow in the entire system of the fourteenth embodiment. [Fig. 126] FIG. 126 is a diagram for explaining AES individual keys. [Figure 127] FIG. 127 is a diagram showing the processing of the OTA center. [Figure 128] FIG. 128 is a diagram showing the processing of the OTA center. [Figure 129] FIG. 129 is a diagram showing the processing of the OTA center. [Fig. 130] FIG. 130 is a diagram showing the processing of the OTA master. [Fig. 131] FIG. 131 is a diagram showing the processing of the OTA master. [Fig. 132] FIG. 132 is a diagram showing the processing of the OTA master. [Fig. 133] FIG. 133 is a diagram showing a process flow in the entire system of the fifteenth embodiment. [Fig. 134] FIG. 134 is a diagram showing the processing of the OTA center. [Fig. 135] FIG. 135 is a diagram showing the processing of the OTA center. [Fig. 136] FIG. 136 is a diagram showing the processing of the OTA master. [Fig. 137] FIG. 137 shows the process of the OTA master. [Figure 138]FIG. 138 is a diagram showing a process flow in the entire system of the sixteenth embodiment. [Figure 139] Figure 139 shows a man-in-the-middle attack. [Fig. 140] FIG. 140 is a diagram showing a mode of adding a digital signature; [Fig. 141] FIG. 141 is a diagram showing the processing of the OTA center. [Fig. 142] FIG. 142 is a diagram showing the processing of the OTA center. [Fig. 143] FIG. 143 is a diagram showing the processing of the OTA center. [Fig. 144] FIG. 144 is a diagram showing the processing of the OTA master. [Fig. 145] FIG. 145 is a diagram showing the processing of the OTA master. [Fig. 146] FIG. 146 is a diagram showing a process flow in the entire system of the seventeenth embodiment. [Fig. 147] FIG. 147 is a diagram showing the processing of the OTA center. [Fig. 148] FIG. 148 is a diagram showing the processing of the OTA center. [Figure 149] FIG. 149 is a diagram showing the processing of the OTA master. [Fig. 150] FIG. 150 is a diagram showing the processing of the OTA master. [Fig. 151] FIG. 151 is a diagram showing the processing of the OTA master. [Fig. 152] FIG. 152 is a diagram showing a process flow in the entire system of the 18th embodiment. [Fig. 153] Figure 153 shows a CDN price table for each cloud service. [Fig. 154] Figure 154 shows a CDN price table for each cloud service. [Fig. 155] Figure 155 shows a price table of storage methods of each cloud service provider. [Fig. 156]Figure 156 shows a price table of storage methods of each cloud service provider. [Fig. 157] Figure 157 is a price table showing the streaming sizes for each cloud service provider's streaming method. [Fig. 158] FIG. 158 is a price table showing the streaming sizes for each cloud service provider's streaming method. [Fig. 159] Figure 159 is a price table showing the streaming sizes for each cloud service provider's streaming method. [Fig. 160] FIG. 160 is a price table showing the streaming sizes of the streaming methods of each cloud service provider. [Fig. 161] FIG. 161 shows quality information for each cloud service provider. [Fig. 162] FIG. 162 is a diagram for explaining the selection of a CDN vendor. [Fig. 163] FIG. 163 is a diagram showing the processing of the OTA center. [Fig. 164] FIG. 164 is a diagram showing the processing of the OTA center. [Fig. 165] FIG. 165 is a diagram showing the processing of the OTA center. [Fig. 166] FIG. 166 shows a modified example of the eleventh embodiment, and is a diagram showing a part of the process flow in the entire system. [Fig. 167] FIG. 167 is a diagram showing a part of the process flow in the entire system. [Fig. 168] FIG. 168 is a diagram showing a part of the process flow in the entire system. [Fig. 169] FIG. 169 is a diagram showing a part of the process flow in the entire system. [Fig. 170] FIG. 170 is a diagram showing the processing of the OTA master. [Fig. 171] FIG. 171 shows the process of the PC. [Fig. 172] FIG. 172 is a diagram showing the processing of the OTA center. [Fig. 173] FIG. 173 is a diagram showing the processing of the OTA master. [Fig. 174] FIG. 174 shows a modified example of the twelfth embodiment, and is a diagram showing a part of the process flow in the entire system. [Fig. 175] FIG. 175 is a diagram showing a part of the process flow in the entire system. [Fig. 176] FIG. 176 is a diagram showing a part of the process flow in the entire system. [Fig. 177] FIG. 177 is a diagram showing a part of the process flow in the entire system. [Fig. 178] FIG. 178 shows the process of the OTA master. [Fig. 179] FIG. 179 shows the process of the PC. [Fig. 180] FIG. 180 is a diagram showing the processing of the OTA center. [Fig. 181] FIG. 181 is a diagram showing the processing of the OTA master. [Fig. 182] FIG. 182 shows a modification of the sixteenth embodiment, and is a diagram showing a part of the process flow in the entire system. [Fig. 183] FIG. 183 is a diagram showing a part of the process flow in the entire system. [Fig. 184] FIG. 184 is a diagram showing a part of the process flow in the entire system. [Fig. 185] FIG. 185 is a diagram showing a part of the process flow in the entire system. [Fig. 186] FIG. 186 is a diagram showing the processing of the OTA master. [Fig. 187] FIG. 187 shows the process of the PC. [Fig. 188] FIG. 188 is a diagram showing the processing of the OTA center. [Fig. 189] FIG. 189 shows the process of the OTA master. [Fig. 190]FIG. 190 is a diagram showing a process flow in the entire system of the 19th embodiment. [Fig. 191] FIG. 191 is a diagram showing the process of the campaign notification generating unit. [Fig. 192] FIG. 192 is a diagram showing a process of a CDN vendor selection unit; [Fig. 193] FIG. 193 is a diagram showing a process of the CDN vendor selection unit; [Fig. 194] FIG. 194 is a diagram showing a process flow in the entire system of the first modified example of the nineteenth embodiment; [Fig. 195] FIG. 195 is a diagram showing the processing of the CDN vendor selection unit; [Fig. 196] FIG. 196 is a diagram showing a process flow in the entire system of the second modified example of the nineteenth embodiment; [Figure 197] FIG. 197 is a diagram showing a selection table. [Figure 198] FIG. 198 is a diagram showing the processing of the CDN vendor selection unit. [Figure 199] FIG. 199 is a diagram showing the processing of the CDN vendor selection unit. [Figure 200] FIG. 200 is a diagram showing the processing of the performance measurement unit. [Figure 201] FIG. 201 is a diagram showing the process of the CDN server confirmation unit. [Fig. 202] FIG. 202 is a diagram showing a process flow in the entire system of the third modified example of the nineteenth embodiment; [Fig. 203] FIG. 203 is a diagram showing the process of the log transmission unit 3a. [Fig. 204] FIG. 204 is a diagram showing the processing of the performance measurement unit. [Fig. 205] FIG. 205 is a diagram showing the processing of the performance measurement unit. [Fig. 206] FIG. 206 shows a fourth modified example of the nineteenth embodiment, and is a diagram showing the process of the CDN vendor selection unit 7a. [Fig. 207] FIG. 207 is a diagram showing the process of the campaign notification generation unit. [Fig. 208]FIG. 208 is a diagram showing a process flow in the entire system of the fifth modified example of the nineteenth embodiment; [Fig. 209] FIG. 209 is a diagram showing a round robin record. [Fig. 210] FIG. 210 is a diagram showing the process of the CDN vendor selection unit 7a. [Fig. 211] FIG. 211 is a diagram showing the process of the switching unit. [Fig. 212] FIG. 212 is a diagram showing the flow of processing in the entire system of the twentieth embodiment. [Fig. 213] FIG. 213 is a diagram showing the calculation method. [Fig. 214] FIG. 214 is a diagram showing the processing of the campaign notification generating unit. [Fig. 215] FIG. 215 is a diagram showing the processing of the CDN vendor selection unit; [Fig. 216] FIG. 216 is a diagram showing the processing of the CDN vendor selection unit; [Fig. 217] FIG. 217 is a diagram showing the processing of the CDN vendor selection unit; [Fig. 218] FIG. 218 is a diagram showing the processing of the CDN vendor selection unit; [Fig. 219] FIG. 219 is a diagram showing the processing of the CDN vendor selection unit; [Fig. 220] FIG. 220 is a diagram showing the processing of the CDN vendor selection unit; [Fig. 221] FIG. 221 is a diagram showing the processing of the CDN vendor selection unit. [Fig. 222] FIG. 222 is a diagram showing the process of the progress information management unit. [Fig. 223] FIG. 223 is a diagram showing the processing of the CDN vendor selection unit; [Fig. 224] FIG. 224 is a diagram showing the process of the campaign notification generating unit. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0017] Hereinafter, a number of embodiments will be described with reference to the drawings. Note that in the following embodiments, descriptions of contents that overlap with the preceding embodiments may be omitted.

[0018] (First embodiment) The first embodiment will be described with reference to Fig. 1 to Fig. 14. As shown in Fig. 1, a data communication system 1 includes an OTA center 2 and a vehicle-side system 3 mounted on a vehicle, and is configured to enable data communication between the OTA center 2 and the vehicle-side system 3. The OTA center 2 corresponds to a center device. The OTA center 2 and the vehicle-side system 3 have a one-to-many relationship, and the OTA center 2 can communicate data with an unspecified number of vehicle-side systems 3.

[0019] The vehicle-side system 3 includes an OTA master 4 and a target ECU 5. The OTA master 4 corresponds to a master device. The OTA master 4 and the target ECU 5 are connected to an in-vehicle network such as a Controller Area Network (CAN) (registered trademark), and are connected to each other so as to be able to perform data communication via the in-vehicle network. The in-vehicle network may be a Local Interconnect Network (LIN), a FlexRay (registered trademark), a CAN Flexible Data rate (CAN FD) (registered trademark), an Ethernet (registered trademark), or the like. The target ECU 5 is an ECU to which an application program is to be reprogrammed, and may be, for example, an ECU that controls an automatic driving system, an ECU that controls an ADAS system, an ECU that controls a multimedia system, or the like. The application program is a program related to the execution of an application, and includes, for example, an application program, a firmware program, and an operating system program.

[0020] The OTA center 2 includes a package generation server 6 and a distribution server 7. The package generation server 6 is a server having a function of packaging update data to generate an update package. The update package is, for example, a zip file in which multiple files containing update data are compressed and stored. The distribution server 7 is a server having a function of distributing the update package generated by the package generation server 6 to the vehicle-side system 3.

[0021] When a request to reprogram an ECU application program occurs due to an upgrade for functional improvements, for example, the OTA center 2 distributes a campaign notification to the vehicle-side system 3 and a mobile information terminal such as a smartphone owned by the user. The OTA center 2 places the update package in a content delivery network (hereinafter referred to as CDN) 8 and distributes the update package to the OTA master 4 via the CDN 8, on the condition that the user has consented to the download. Alternatively, if the update package has already been placed in the CDN 8, the OTA center 2 distributes the update package from the CDN 8 to the OTA master 4, on the condition that the user has consented to the download.

[0022] When the OTA master 4 downloads the update package from the OTA center 2, it transfers the update package to the target ECU 5 on the condition that the user consents to the installation, and installs the update package in the target ECU 5. A business that provides the CDN 8 as a service is called a CDN vendor. In addition, the OTA master 4 obtains the update package by accessing the CDN server of the CDN 8.

[0023] In this embodiment, in order to speed up the decryption process of the Advanced Encryption Standard (hereinafter abbreviated as AES (Advanced Encryption Standard)) in the vehicle-side system 3, a counter mode (hereinafter abbreviated as CTR mode), which is a representative streaming encryption, is adopted as the encryption mode rather than a cipher block chaining mode (hereinafter abbreviated as CBC mode (Cipher Block Chaining Mode)) of a general block encryption. In this embodiment, the OTA center 2 encrypts the update package in the CTR mode with an AES key. Also, the vehicle-side system 3 encrypts the update package in the CTR mode with an AES key. Incidentally, the OTA center 2 is provided with an RSA (Rivest-Shamir-Adleman cryptosystem) public key for each vehicle. An RSA private key is written to the OTA master 4 at the vehicle manufacturing stage.

[0024] As shown in FIG. 2, the OTA center 2 includes, as functional blocks related to encryption, a common key generation unit 2a, an update package encryption unit 2b, a common key encryption unit 2c, a common key storage unit 2d, an encrypted package placement unit 2e, and a campaign notification transmission unit 2f. The update package encryption unit 2b corresponds to the update data encryption. The encrypted package placement unit 2e corresponds to the encrypted data placement unit. Each unit 2a to 2f is realized by cooperation of hardware and software of a microcomputer having a CPU (Central Processing Unit), RAM (Random Access Memory), ROM (Read Only Memory), I / O (Input / Output), etc. The CPU realizes the functions of the OTA center 2 by executing various programs including an encryption program, an update data placement program, a secret information sharing program, etc. stored in the ROM.

[0025] The common key generation unit 2a generates an AES key as a common key for encrypting the update package. The package encryption unit 2b encrypts the update package in CTR mode with the generated AES key. The package encryption unit 2b encrypts the counter value by executing AES block encryption processing on the counter value with the AES key. The package encryption unit 2b performs an exclusive OR (XOR) operation on the encrypted counter value and the update package, combines multiple encrypted fragments, and generates an update package encrypted with the AES key. The counter value is, for example, an 8-digit number, and is incremented by "1" for each AES block.

[0026] The common key encryption unit 2c encrypts the AES key with the RSA public key. The common key storage unit 2d stores the AES key encrypted with the RSA public key in the campaign notification. The encrypted package placement unit 2e places the update package encrypted with the AES key in the CDN 8. The campaign notification sending unit 2f sends the campaign notification in which the encrypted AES key is stored to the vehicle-side system 3 to be reprogrammed. The campaign notification sending unit 2f may also deliver the campaign notification to a mobile information terminal such as a smartphone owned by the user.

[0027] The OTA master 4 includes, as functional blocks related to decryption, a common key acquisition unit 4a, a common key decryption unit 4b, an encryption package acquisition unit 4c, a block cipher processing unit 4d, an encryption package decryption unit 4e, and an installation processing unit 4f. The encryption package acquisition unit 4c corresponds to an encrypted data acquisition unit. The encryption package decryption unit 4e corresponds to an encrypted data decryption unit. Each unit 4a to 4f is realized by cooperation of hardware and software of a microcomputer having a CPU, RAM, ROM, I / O, etc. The CPU realizes the functions of the OTA master 4 by executing various programs including a decryption program, an update data acquisition program, a secret information sharing program, etc. stored in the ROM.

[0028] When the OTA master 4 receives the campaign notification transmitted from the OTA center 2, the common key acquisition unit 4a acquires the encrypted AES key from the acquired campaign notification. The common key decryption unit 4b decrypts the encrypted AES key by using the RSA private key to extract the AES key. The encrypted package acquisition unit 4c downloads and acquires the encrypted update package from the CDN 8. At this time, the block encryption processing unit 4d encrypts the counter value by performing AES block encryption processing using the AES key while the encrypted package acquisition unit 4c downloads and acquires the encrypted update package from the CDN 8. The encrypted package decryption unit 4e performs an exclusive-OR (hereinafter, XOR) operation on the encrypted counter value and the encrypted update package downloaded from the CDN 8 to decrypt the counter value. The installation processing unit 4f transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5.

[0029] The encryption process in CTR mode is as shown in Figure 3, and the decryption process in CTR mode is as shown in Figure 4. As shown in Figure 5, the disadvantages of the CBC mode are that "preparation for encryption and decryption cannot be performed" and "parallel encryption cannot be performed", while the advantages of the CTR mode are that "preparation for encryption and decryption can be performed, making it possible to increase speed" and "parallel encryption and decryption can be performed". In other words, the advantage of adopting the CTR mode as the encryption mode in terms of improving throughput is that it can improve throughput by about 40% compared to adopting the CBC mode, a general block cipher, as shown in Figure 6.

[0030] As shown in Fig. 7, in the decryption process in CBC mode, the input is ciphertext, so the decryption process cannot start until the update package, which is ciphertext, is received. In contrast, as shown in Fig. 8, in the decryption process in CTR mode, the input is a counter value, so the decryption process can start before the update package, which is ciphertext, is received. Also, since there is no mutual dependency, multiple encryption operations can be executed in parallel at the same time.

[0031] Next, the operation of the above-mentioned configuration will be described with reference to FIGS. (1-1) Processing at OTA Center 2 (see Figures 9 to 11) The OTA center 2 generates an AES key for encrypting the update package (A011, corresponding to the common key generation procedure). The OTA center 2 encrypts the update package in CTR mode with the generated AES key (A012, corresponding to the update data encryption procedure). The OTA center 2 encrypts the AES key with the RSA public key (A013, corresponding to the common key encryption procedure). The OTA center 2 stores the AES key encrypted with the RSA public key in the campaign notification (A014, corresponding to the common key storage procedure). The OTA center 2 places the update package encrypted with the AES key in the CDN 8 (A015, corresponding to the encrypted data placement procedure). Placing the update package on the CDN 8 means placing the update package on the origin server of the CDN 8. The OTA center 2 transmits the campaign notification in which the encrypted AES key is stored to the vehicle-side system 3 to be reprogrammed (A016, corresponding to the campaign notification transmission procedure).

[0032] (1-2) OTA Master 4 Processing (See Figures 12 to 14) When the OTA master 4 acquires the campaign notification by receiving the campaign notification sent from the OTA center 2, it acquires the AES key from the acquired campaign notification (B011, corresponding to the common key acquisition procedure). The OTA master 4 decrypts the encrypted AES key with the RSA private key to extract the AES key (B012, corresponding to the common key decryption procedure). The OTA master 4 downloads and acquires the encrypted update package from the CDN 8 (B013, corresponding to the encrypted data acquisition procedure).

[0033] At this time, while downloading and acquiring the encrypted update package from the CDN 8, the OTA master 4 executes AES block encryption processing of the counter value using the AES key to encrypt the counter value (B014, corresponding to a block encryption processing procedure). The OTA master 4 performs an XOR operation on the encrypted counter value and the encrypted update package downloaded from the CDN 8 to decrypt the counter value (B015, corresponding to an encrypted data decryption procedure). The OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B016, corresponding to an installation processing procedure). Note that by encrypting and decrypting the difference program in the update package in CTR mode instead of in CBC mode, the throughput of the decryption process in the target ECU 5 can also be improved by about 40%.

[0034] As described above, according to the first embodiment, the following advantageous effects can be obtained. The configuration adopts CTR mode as the encryption and decryption method for the update package. By adopting CTR mode, which is different from the conventional method that used CBC mode, it is possible to perform preparations before encryption and decryption, and to perform encryption and decryption in parallel. This allows the OTA master 4 to enjoy the benefits of CTR mode when downloading the update package from the OTA center 2, and appropriately increases throughput.

[0035] Second embodiment The second embodiment will be described with reference to Fig. 15 to Fig. 26. The first embodiment is configured to adopt the CTR mode as the encryption mode, but the second embodiment adopts the output feedback mode (hereinafter, referred to as OFB mode (Output-FeedBack mode)) as the encryption mode.

[0036] In this case, the package encryption unit 2b encrypts the update package in OFB mode with the generated AES key. In parallel with the encrypted package acquisition unit 4c downloading and acquiring the encrypted update package from the CDN 8, the block cipher processing unit 4d executes an IV (Initialization Vector) value-based AES stream encryption process with the AES key to encrypt the IV value. The IV value is an initialization vector value, and indicates, for example, a randomly generated bit string. The encrypted package decryption unit 4e performs an XOR operation on the encrypted IV value and the encrypted update package downloaded from the CDN 8 to decrypt it.

[0037] The encryption process in OFB mode is as shown in Fig. 15, and the decryption process in OFB mode is as shown in Fig. 16. As shown in Fig. 17, the disadvantages of the CBC mode are that "pre-preparation for encryption and decryption cannot be performed" and "parallel encryption cannot be performed", while the advantage of the OFB mode is that "pre-preparation for encryption and decryption can be performed, so high speed processing is possible". In other words, the advantage of adopting the OFB mode as the encryption mode in improving throughput is that it can improve throughput by about 25% compared to the case of adopting the CBC mode of a general block cipher, as shown in Fig. 18.

[0038] As shown in FIG. 19, in the decryption process in the CTR mode, since the input is a counter value, the decryption process can be started before receiving the update package, which is a ciphertext. In addition, since there is no mutual dependency, multiple cryptographic operations can be executed simultaneously in parallel. In contrast, as shown in FIG. 20, in the decryption process in the OFB mode, since there is a mutual dependency, multiple cryptographic operations cannot be executed simultaneously in parallel. However, the process of decrypting the encrypted IV value and the encrypted update package by performing an XOR operation can be executed in parallel. Therefore, in the decryption process in the OFB mode, the throughput cannot be improved to the same extent as in the decryption process in the CTR mode described in the first embodiment, but the throughput can be improved compared to the case where the CBC mode is adopted.

[0039] Next, the operation of the above-mentioned configuration will be described with reference to FIGS. (2-1) Processing at OTA Center 2 (see Figures 21 to 23) The OTA center 2 generates an AES key for encrypting the update package (A021, corresponding to the common key generation procedure). The OTA center 2 encrypts the update package in OFB mode with the generated AES key (A022, corresponding to the update data encryption procedure). The OTA center 2 encrypts the AES key with an RSA public key (A023, corresponding to the common key encryption procedure). The OTA center 2 stores the AES key encrypted with the RSA public key in the campaign notification (A024, corresponding to the common key storage procedure). The OTA center 2 places the update package encrypted with the AES key in the CDN 8 (A025, corresponding to the encrypted data placement procedure). The OTA center 2 transmits the campaign notification in which the encrypted AES key is stored to the vehicle-side system 3 to be reprogrammed (A026, corresponding to the campaign notification transmission procedure).

[0040] (2-2) OTA Master 4 Processing (See Figures 24 to 26) When the OTA master 4 acquires the campaign notification by receiving the campaign notification sent from the OTA center 2, it acquires the AES key from the acquired campaign notification (B021, corresponding to the common key acquisition procedure). The OTA master 4 decrypts the encrypted AES key with the RSA private key to extract the AES key (B022, corresponding to the common key decryption procedure). The OTA master 4 downloads and acquires the encrypted update package from the CDN 8 (B023, corresponding to the encrypted data acquisition procedure).

[0041] At this time, while downloading and acquiring the encrypted update package from CDN8, the OTA master 4 executes IV-based AES stream encryption processing with the AES key to encrypt the IV value (B024, corresponding to a block encryption processing procedure). The OTA master 4 performs an XOR operation on the encrypted IV value and the encrypted update package downloaded from CDN8 to decrypt it (B025, corresponding to an encrypted data decryption procedure). The OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B026, corresponding to an installation processing procedure). Note that by encrypting and decrypting the differential program in the update package in OFB mode instead of encrypting and decrypting in CBC mode, the throughput of the decryption process in the target ECU 5 can also be improved by about 25%.

[0042] As described above, according to the second embodiment, the following advantageous effects can be obtained. The OFB mode is adopted as the encryption and decryption method for the update package. Unlike the conventional method that used CBC mode, the adoption of OFB mode allows preparations for encryption and decryption to be performed in advance. This allows the OTA master 4 to enjoy the benefits of the OFB mode when downloading the update package from the OTA center 2, and appropriately increases throughput.

[0043] Third embodiment The third embodiment will be described with reference to FIG. 27 to FIG. 33. In the third embodiment, the hypertext transfer protocol (hereinafter referred to as HTTP) is adopted as a communication protocol between the CDN 8 and the OTA master 4, a range request is sent to the CDN 8, and an update package is downloaded in a streaming manner, thereby suppressing the delivery cost more than when the hypertext transfer protocol secure (hereinafter referred to as HTTPS) is adopted. Some CDN vendors may differentiate the delivery fee of the CDN 8 between when HTTP is used as a communication protocol to the CDN 8 and when HTTPS is used. When HTTPS is used, the CDN 8 needs to perform handshake processing, encryption key exchange processing, and encryption calculation processing as defined by the transport layer security (hereinafter referred to as TLS), and the processing load of the CPU of the CDN 8 increases, so that the delivery fee of HTTPS is about 30% higher than that of HTTP in the fee table. For this reason, the delivery cost is suppressed by using HTTP to download the update package. In the third embodiment, HTTPS is not used when distributing an update package from the CDN 8 to the vehicle-side system 3.

[0044] In this case, the campaign notification sending unit 2f establishes TLS communication between the OTA center 4 and the OTA master 4, and then transmits the campaign notification in which the encrypted AES key is stored to the vehicle-side system 3 to be reprogrammed. When the campaign notification transmitted from the OTA center 2 is received by the OTA master 4 after the TLS communication is established, the common key acquiring unit 4a acquires the campaign notification and acquires the AES key from the acquired campaign notification. The encrypted package acquiring unit 4c transmits a range request to the CDN 8 to specify the data range to be downloaded, and downloads and acquires the encrypted update package from the CDN 8 by streaming. The installation processing unit 4f transfers the decrypted update package to the target ECU 5 by streaming, and installs the update package in the target ECU 5.

[0045] In this embodiment, the OTA master 4 acquires the encrypted update package from the CDN 8 in a streaming manner, but the encrypted update package may be acquired in a storage manner from the CDN 8. In the streaming manner, header information is included during communication, so that the use of HTTP can further reduce distribution costs.

[0046] Next, the operation of the above-mentioned configuration will be described with reference to FIGS. (3-1) Processing at OTA Center 2 (see Figures 28 to 30) The OTA center 2 generates an AES key for encrypting the update package (A031). The OTA center 2 encrypts the update package in CTR mode with the generated AES key (A032). The OTA center 2 encrypts the AES key with an RSA public key (A033). The OTA center 2 stores the AES key encrypted with the RSA public key in the campaign notification (A034). The OTA center 2 places the update package encrypted with the AES key in the CDN 8 (A035). The OTA center 2 establishes TLS communication between the OTA center 4 and the OTA master 4, and then transmits the campaign notification in which the encrypted AES key is stored to the vehicle-side system 3 to be reprogrammed (A036).

[0047] (3-2) OTA Master 4 Processing (See Figures 31 to 33) After TLS communication is established, the OTA master 4 acquires the campaign notification by receiving the campaign notification sent from the OTA center 2, and acquires the AES key from the acquired campaign notification (B031). The OTA master 4 decrypts the encrypted AES key with the RSA private key to extract the AES key (B032). The OTA master 4 sends a range request to the CDN 8 to specify the data range to be downloaded, and acquires the encrypted update package by downloading it from the CDN 8 in a streaming manner (B033). That is, the OTA master 4 acquires the update package by downloading it from the CDN 8 in a divided streaming manner by specifying the data range to be downloaded.

[0048] At this time, while the encrypted package acquisition unit 4c downloads and acquires the encrypted update package from the CDN 8, the OTA master 4 executes AES block encryption processing of the counter value using the AES key to encrypt the counter value (B034). The OTA master 4 performs an XOR operation on the encrypted counter value and the encrypted update package downloaded from the CDN 8 to decrypt the value (B035). The OTA master 4 transfers the decrypted update package to the target ECU 5 by streaming and installs the update package in the target ECU 5 (B036).

[0049] As described above, according to the third embodiment, the following advantageous effects can be obtained. HTTP is used as the communication protocol between the CDN 8 and the OTA master 4, and the OTA master 4 transmits a range request to the CDN 8, thereby downloading the update package from the CDN 8 in a streaming manner. This makes it possible to appropriately reduce the delivery cost when the OTA master 4 downloads the update package from the OTA center 2, compared to the conventional method in which HTTPS was used as the communication protocol.

[0050] (Fourth embodiment) The fourth embodiment will be described with reference to Figures 34 to 38. The fourth embodiment aims to speed up the decryption process when downloading an update package by performing calculations of all key streams in advance in the background before download consent is obtained from the user.

[0051] In this case, as shown in Fig. 35, the OTA master 4 includes a key stream calculation unit 4g in addition to a common key acquisition unit 4a, a common key decryption unit 4b, an encrypted package acquisition unit 4c, a block cipher processing unit 4d, an encrypted package decryption unit 4e, and an installation processing unit 4f. The key stream calculation unit 4g performs calculations of all key streams in advance in the background before download consent is obtained from the user. The encrypted package acquisition unit 4c downloads and acquires the encrypted update package from the CDN 8 on the condition that download consent is obtained from the user. The encrypted package decryption unit 4e performs an XOR operation on the calculated key stream and the encrypted update package downloaded from the CDN 8 to decrypt it.

[0052] Next, the operation of the above-mentioned configuration will be described with reference to FIGS. (4-1) Processing at OTA Center 2 The processing of the OTA center 2 is similar to the processing of the OTA center 2 described in the first embodiment (FIGS. 9 to 11).

[0053] (4-2) OTA Master 4 Processing (See Figures 36 to 38) When the OTA master 4 acquires the campaign notification by receiving the campaign notification sent from the OTA center 2, it acquires the AES key from the acquired campaign notification (B041). The OTA master 4 decrypts the encrypted AES key with the RSA private key to extract the AES key (B042). The OTA master 4 performs calculations of all key streams in advance in the background before obtaining download consent from the user (B043). Identification information is assigned to each key stream, and the order of application to the encrypted update package is indicated.

[0054] The OTA master 4 distributes the campaign notification to the vehicle-side system 3 and a mobile information terminal such as a smartphone owned by the user, and displays a download consent screen on the HMI (Human Machine Interface) (B044). On the condition that the download consent is obtained from the user, the OTA master 4 downloads and acquires the encrypted update package from the CDN 8 (B045). The OTA master 4 performs an XOR operation on a pre-calculated key stream and the encrypted update package downloaded from the CDN 8 to decrypt the package (B046). The OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B047).

[0055] As described above, according to the fourth embodiment, the following advantageous effects can be obtained. The system is configured to perform all key stream calculations in advance in the background before obtaining the user's consent for downloading. This makes it possible to speed up the decryption process of the update package in the OTA master 4, and to increase the throughput when the OTA master 4 downloads the update package from the OTA center 2.

[0056] Fifth embodiment The fifth embodiment will be described with reference to Fig. 39 to Fig. 42. In the fourth embodiment, calculation of all key streams is performed in advance in the background before download consent is obtained from the user, but in the fifth embodiment, calculation of some key streams is performed in advance in the background before download consent is obtained from the user. The part of key streams to be calculated is determined taking into consideration the memory capacity of the CPU cache memory and the throughput of the AES encryption calculation, and is a size that can be stored in the cache memory.

[0057] In this case, the key stream calculation unit 4g executes calculation of a part of the key stream in advance in the background before obtaining the download consent from the user. In parallel with the encrypted package acquisition unit 4c downloading and acquiring the encrypted update package from the CDN 8, the key stream calculation unit 4g generates a key stream and adds it to the cache memory.

[0058] Next, the operation of the above-mentioned configuration will be described with reference to FIGS. (5-1) Processing at OTA Center 2 The processing of the OTA center 2 is similar to the processing of the OTA center 2 described in the first embodiment (FIGS. 9 to 11).

[0059] (5-2) OTA Master 4 Processing (See Figures 39 to 41) When the OTA master 4 acquires the campaign notification by receiving the campaign notification sent from the OTA center 2, it acquires the AES key from the acquired campaign notification (B051). The OTA master 4 decrypts the encrypted AES key with the RSA private key to extract the AES key (B052). The OTA master 4 performs calculations of a part of the key stream in advance in the background before obtaining download consent from the user (B053).

[0060] The OTA master 4 distributes the campaign notification to the vehicle-side system 3 and the user's mobile information terminal such as a smartphone, and displays a download consent screen on the HMI (B054). On the condition that the user consents to the download, the OTA master 4 downloads and acquires the encrypted update package from the CDN 8 (B055). The OTA master 4 performs an XOR operation on the pre-calculated key stream and the encrypted update package downloaded from the CDN 8 to decrypt it (B056).

[0061] At this time, the OTA master 4 generates a key stream and adds it to the cache memory (B057) while downloading and acquiring the encrypted update package from the CDN 8, and calculates the remaining key stream. The OTA master 4 transfers the decrypted update package to the target ECU 5, and installs the update package in the target ECU 5 (B058). The relationship between memory capacity and access speed is as shown in Figure 42, and the size of the cache memory can be determined according to the required access speed.

[0062] As described above, according to the fifth embodiment, the following advantageous effects can be obtained. A configuration is adopted in which some key stream calculations are performed in advance in the background before download approval is obtained from the user. This makes it possible to speed up the decryption process of the update package in the OTA master 4 while saving memory usage in the OTA master 4, and to increase the throughput when the OTA master 4 downloads the update package from the OTA center 2.

[0063] Sixth embodiment The sixth embodiment will be described with reference to Fig. 43 to Fig. 54. In the sixth embodiment, the encryption method is included in reprovision policy metadata (hereinafter referred to as RP metadata) and transmitted from the OTA center 2 to the OTA master 4, whereby the OTA master 4 specifies the encryption method. The encryption method transmitted from the OTA center 2 to the OTA master 4 includes an encryption algorithm, an encryption key length, an encryption mode, a message authentication code (hereinafter referred to as MAC (Message Authentication Code)) algorithm, and the like.

[0064] The RP metadata includes information on the configuration of the update package, i.e., information indicating the configuration type of the update package, and the OTA master 4 checks the data content to prevent delivery errors of the update package. By making the RP metadata a three-layer structure of delivery, master, and target, even if the transfer method, platform type, and types of update packages increase, they can be flexibly defined and dealt with, and the target ECU 5 can be reprogrammed. The encryption method may be included in download metadata (hereinafter referred to as DL metadata) and transmitted from the OTA center 2 to the OTA master 4, so that the OTA master 4 can identify the encryption method. The DL metadata includes information for downloading an update package for each of the multiple target ECUs 5, and is data that specifies the contents that the OTA master 4 should understand.

[0065] As shown in Fig. 44, the OTA center 2 includes a shared key generation unit 2a, an update package encryption unit 2b, a shared key encryption unit 2c, a shared key storage unit 2d, an encrypted package placement unit 2e, and a campaign notification transmission unit 2f, as well as an RP metadata generation unit 2g and an RP metadata encryption unit 2h. The RP metadata generation unit 2g generates RP metadata including a shared key cryptosystem. The RP metadata encryption unit 2h encrypts the RP metadata with an RSA public key.

[0066] The OTA master 4 includes a common key acquisition unit 4a, a common key decryption unit 4b, an encrypted package acquisition unit 4c, a block encryption processing unit 4d, an encrypted package decryption unit 4e, an installation processing unit 4f, an RP metadata acquisition unit 4h, an RP metadata decryption unit 4i, and a common key cryptography method specification unit 4j. The RP metadata acquisition unit 4h downloads and acquires the encrypted RP metadata from the CDN 8. The RP metadata decryption unit 4i decrypts the encrypted RP metadata with the RSA private key to extract the RP metadata. The common key cryptography method specification unit 4j interprets the contents of the RP metadata to specify the common key cryptography method.

[0067] The flow of events leading up to the delivery of the update package from the CDN 8 to the OTA center 2 is as follows: A campaign notification is sent from the OTA center 2 to the OTA master 4 or the mobile information terminal owned by the user. After that, the OTA master 4 accesses the CDN 8, which causes the CDN 8 to send RP metadata and DL metadata to the OTA master 4, and the update package is delivered from the CDN 8 to the OTA center 2.

[0068] As shown in Fig. 45, the RP metadata and DL metadata are transmitted from the OTA center 2 to the OTA master 4 prior to downloading an update package. As shown in Fig. 46 to Fig. 47, the RP metadata includes information on the RP metadata version, distribution layer, master layer, and target layer. Each piece of information is as follows.

[0069] (a) RP Metadata Version The version of the RP metadata, for example, "1.0.0" or "2.0.0". (b) Delivery Layer (b-1) Communication Protocol This is information indicating a protocol used for communication with the OTA center 2, such as Uptane (registered trademark) or OMA-DM (Open Mobile Alliance-Device Management). (b-2) Means of communication This is information indicating the delivery path of the update package, and indicating that it is the OTA master 4, such as cellular, smartphone, USB memory, etc.

[0070] (c) Master Layer Information about OTA Master 4 (c-1)PF This is information indicating that the platform (PF) of the OTA master 4 is, for example, AP (AUTOSAR Adaptive Platform), CP (AUTOSAR Classic Platform), AGL (Automotive Grade Linux), Android (registered trademark), etc. Regarding the package structure for distributing an update package according to the ECU platform, the specifications of the general incorporated association JASPAR prescribe data requirements applicable to the classic platform (CP) that runs on a static OS of the standardization organization AUTOSAR. In addition, AUTOSAR prescribes data requirements applicable to a new type of adaptive platform (AP) that runs on a dynamic OS. AGL is in-vehicle Linux (registered trademark), and Android is Android Automotive OS. AP and CP indicate software platforms. Software platforms are also called software architectures. APs and CPs use different operating systems and development languages. An ECU that operates in accordance with the CP specification and an ECU that operates in accordance with the AP specification have different structures of update packages that can be received. The difference in the structures of these update packages is mainly due to the difference in the processing performance of the ECU. Generally, the processing performance of ECUs that operate in accordance with the CP specification is relatively low, so the specification data and other data included in the update package are written in binary data, and the data structure is easy to interpret and process even for ECUs with low processing performance. On the other hand, the processing performance of ECUs that operate in accordance with the AP specification is relatively high, so it is possible to install a parser function that analyzes structured character data written in some language and converts it into a data structure that can be handled by a program, and the data structure is flexible because it can adopt an object-oriented data format such as JSON (JavaScript Object Notation) rather than simple binary data.

[0071] (c-2) Control method This information includes parameters that are processed according to parameters set according to a specific format, and scripts that are processed in a more freely written format without a specific format. (c-3) Encryption method This information includes the encryption algorithm, encryption key length, encryption mode, padding method, encryption key ID, signature algorithm, signature key ID, signature mode, hash algorithm, whether or not an area is specified, offset size, and protected data size.

[0072] (d) Target Layer This is information about the target ECU 5. (d-1)PF Same as the master layer. (d-2) Transfer method Either storage or streaming (d-3) Control method Same as the master layer. (d-4) Target ID Optional. (d-5) Encryption method Same as the master layer.

[0073] Next, the operation of the above-mentioned configuration will be described with reference to FIGS. (6-1) Processing at OTA Center 2 (see Figures 48 to 51) The OTA center 2 generates a common key for encrypting the update package (A061). The OTA center 2 encrypts the update package in a specific encryption mode using the generated common key (A062). The OTA center 2 encrypts the common key using the RSA public key (A063). The OTA center 2 stores the common key encrypted using the RSA public key in the campaign notification (A064). The OTA center 2 generates RP metadata including a common key encryption method (A065). The OTA center 2 encrypts the RP metadata using the RSA public key (A066). The OTA center 2 places the update package encrypted using the common key and the RP metadata encrypted using the RSA public key in the CDN 8 (A067). The OTA center 2 transmits the campaign notification in which the encrypted common key is stored to the vehicle-side system 3 to be reprogrammed (A068).

[0074] (6-2) OTA Master 4 Processing (See Figures 52 to 54) When the OTA master 4 receives the campaign notification transmitted from the OTA center 2, the OTA master 4 acquires the common key from the acquired campaign notification (B061). The OTA master 4 decrypts the encrypted common key with the RSA private key to extract the common key (B062). The OTA master 4 downloads and acquires the encrypted RP metadata from the CDN 8 (B063). The OTA master 4 decrypts the encrypted RP metadata with the RSA private key to extract the RP metadata (B064). The OTA master 4 interprets the contents of the RP metadata to identify the common key encryption method (B065). The OTA master 4 downloads and acquires the encrypted update package from the CDN 8 (B066). After this, if the CTR mode is adopted as the specific encryption mode, the OTA master 4 performs the process from step B014 onward described in the first embodiment, and if the OFB mode is adopted as the specific encryption mode, the OTA master 4 performs the process from step B024 onward described in the second embodiment. For other encryption modes, the update package is decrypted and the data is transferred to the target ECU in the same way, following the procedure corresponding to the encryption mode.

[0075] As described above, according to the sixth embodiment, the following advantageous effects can be obtained. The encryption method is included in the RP metadata and DL metadata and transmitted from the OTA center 2 to the OTA master 4. This allows the OTA master 4 to identify the encryption method.

[0076] Seventh embodiment The seventh embodiment will be described with reference to Fig. 55 to Fig. 67. The seventh embodiment employs a CCMP mode (Counter mode with Cipher-block chaining Message authentication code Protocol) as a communication channel encryption and a countermeasure against data tampering.

[0077] In this case, as shown in Figures 56 to 60, when comparing a configuration that adopts CCMP mode with a configuration that adopts the conventional method of AES CBC-HMAC (Hashed Message Authentication Mode Code) SHA (Secure Hash Algorithm)2 decryption and signature verification, the processing time of the hardware accelerator is dominant over the processing time of the main core in both cases, but the adoption of CCMP mode can improve throughput.

[0078] 61, the OTA center 2 includes a common key generation unit 2a, an update package encryption unit 2b, a common key encryption unit 2c, a common key storage unit 2d, an encrypted package placement unit 2e, and a campaign notification transmission unit 2f, as well as a MAC key generation unit 2i. The MAC key generation unit 2i generates a MAC for preventing tampering with the update package.

[0079] The OTA master 4 includes a common key acquisition unit 4a, a common key decryption unit 4b, an encrypted package acquisition unit 4c, a block cipher processing unit 4d, an encrypted package decryption unit 4e, an installation processing unit 4f, and a MAC key acquisition unit 4k. When the OTA master 4 acquires a campaign notification transmitted from the OTA center 2 by receiving the campaign notification, the MAC key acquisition unit 4k acquires a MAC key from the acquired campaign notification.

[0080] Next, the operation of the above-mentioned configuration will be described with reference to FIGS. (7-1) Processing at OTA Center 2 (see Figures 62 to 64) The OTA center 2 generates an AES key for encrypting the update package and a MAC key for preventing tampering with the update package (A071). The OTA center 2 encrypts the update package in CCMP mode using the generated AES key and MAC key, and assigns a MAC (A072). The OTA center 2 encrypts the AES key and MAC key using an RSA public key (A073). The OTA center 2 stores the AES key and MAC key encrypted using the RSA public key in a campaign notification (A074). The OTA center 2 places the update package encrypted using the AES key and MAC key in the CDN 8 (A075). The OTA center 2 transmits the campaign notification in which the encrypted AES key and MAC key are stored to the vehicle-side system 3 to be reprogrammed (A076).

[0081] (7-2) OTA Master 4 Processing (See Figure 65 to Figure 67) When the OTA master 4 acquires the campaign notification by receiving the campaign notification sent from the OTA center 2, it acquires the AES key and MAC from the acquired campaign notification (B071). The OTA master 4 decrypts the encrypted AES key and MAC key using the RSA private key to extract the AES key and MAC key (B017). The OTA master 4 downloads and acquires the encrypted update package from the CDN 8 (B073).

[0082] At this time, the OTA master 4, in parallel with downloading and acquiring the encrypted update package from the CDN 8, performs AES block encryption processing of the counter value using the AES key to encrypt the counter value (B074). The OTA master 4 performs an XOR operation on the encrypted counter value and the encrypted update package downloaded from the CDN 8 to decrypt it (B075). The OTA master 4 generates a MAC in AES-CBC mode from the plain text of the decrypted update package using the MAC key and verifies it (B076). If the MACs match, the OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B077). If the MACs do not match, the OTA master 4 ends the process. In this case, when the OTA master 4 ends the process due to a MAC mismatch, it may record a log indicating that the process has been ended due to a MAC mismatch and may display an error on an HMI (not shown). Alternatively, the OTA master 4 may perform an XOR operation to decrypt the encrypted update package, and at the same time, transfer the decrypted update package to the target ECU 5. In this case, the OTA master 4 may be configured to generate and verify a MAC in AES-CBC mode using a MAC key from the plain text of the decrypted update package, and notify the target ECU 5 of the cancellation of installation if it is determined that the MACs do not match.

[0083] As described above, according to the seventh embodiment, the following advantageous effects can be obtained. The system is configured to employ CCMP mode to encrypt the communication path between the OTA center 2 and the OTA master 4 and to protect against data tampering. By employing CCMP mode, it is possible to encrypt the communication path and also provide protection against data tampering when the OTA master 4 downloads an update package from the OTA center 2. This enhances security and enables more secure OTA distribution.

[0084] Eighth embodiment The eighth embodiment will be described with reference to Figures 68 to 77. The eighth embodiment employs a GCMP mode (Galois / Counter Mode Protocol) for communication channel encryption and measures against data tampering.

[0085] In this case, as shown in Figures 69 to 71, when comparing a configuration that adopts GCMP mode with a configuration that adopts CCMP mode or a configuration that adopts AES CBC-HMAC SHA2 decryption and signature verification as a conventional method, the processing time of the hardware accelerator is dominant in all cases compared to the processing time of the main core, but by adopting GCMP mode, the throughput can be further improved.

[0086] Next, the operation of the above-mentioned configuration will be described with reference to FIGS. (8-1) Processing at OTA Center 2 (see Figures 72 to 74) The OTA center 2 generates an AES key for encrypting the update package and a MAC key for preventing tampering with the update package (A081). The OTA center 2 encrypts the update package in GCMP mode with the generated AES key and MAC key, and assigns a MAC (A082). The OTA center 2 encrypts the AES key and MAC key with an RSA public key (A083). The OTA center 2 stores the AES key and MAC key encrypted with the RSA public key in a campaign notification (A084). The OTA center 2 places the update package encrypted with the AES key and MAC key in the CDN 8 (A085). The OTA center 2 transmits the campaign notification in which the encrypted AES key and MAC key are stored to the vehicle-side system 3 to be reprogrammed (A086).

[0087] (8-2) OTA Master 4 Processing (See Figures 75 to 77) When the OTA master 4 acquires the campaign notification by receiving the campaign notification sent from the OTA center 2, it acquires the AES key and MAC from the acquired campaign notification (B081). The OTA master 4 decrypts the encrypted AES key and MAC key using the RSA private key to extract the AES key and MAC key (B082). The OTA master 4 downloads and acquires the encrypted update package from the CDN 8 (B083).

[0088] At this time, while downloading and acquiring the encrypted update package from the CDN 8, the OTA master 4 performs AES block encryption processing on the counter value using the AES key to encrypt the counter value (B084). The OTA master 4 performs an XOR operation on the encrypted counter value and the encrypted update package downloaded from the CDN 8 to decrypt it (B085). The OTA master 4 generates a MAC in GMAC mode using the MAC key from the plaintext of the decrypted update package and verifies it (B086). If the MACs match, the OTA master transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B087).

[0089] As described above, according to the eighth embodiment, the following advantageous effects can be obtained. The system is configured to employ GCMP mode to encrypt the communication path between the OTA center 2 and the OTA master 4 and to protect against data tampering. By employing GCMP mode, it is possible to provide protection against data tampering in addition to encrypting the communication path when the OTA master 4 downloads an update package from the OTA center 2. This enhances security and enables more secure OTA distribution.

[0090] Ninth embodiment The ninth embodiment will be described with reference to Figs. 78 to 86. In the ninth embodiment, the delivery path of update data is not limited to the CDN 8, but includes a smartphone, a USB memory, etc., and by responding to the diversity of delivery paths, the degree of freedom of the user's OTA update method is increased. The smartphone and the USB memory correspond to recording media. Hereinafter, a smartphone and a USB memory are described as examples of the storage medium, but an SD card, a micro SD card, a compact flash, etc. may also be used as the storage medium.

[0091] Next, the operation of the above-mentioned configuration will be described with reference to FIGS. (9-1) Processing at OTA Center 2 (see Figures 79 to 82) The OTA center 2 generates a common key for encrypting the update package (A091). The OTA center 2 encrypts the update package in a specific encryption mode with the generated common key (A092). The OTA center 2 encrypts the common key with the RSA public key (A093). The OTA center 2 stores the common key encrypted with the RSA public key in the campaign notification (A094). The OTA center 2 generates RP metadata including a common key encryption method and a distribution route (A095). The OTA center 2 encrypts the RP metadata with the RSA public key (A096). The OTA center 2 places the update package encrypted with the common key and the RP metadata encrypted with the RSA public key in the CDN 8 (A097). The OTA center 2 transmits the campaign notification in which the encrypted common key is stored to the vehicle-side system 3 to be reprogrammed (A098).

[0092] (9-2) OTA Master 4 Processing (See Figure 83 to Figure 86) When the OTA master 4 acquires the campaign notification by receiving the campaign notification transmitted from the OTA center 2, the OTA master 4 acquires the encrypted common key from the acquired campaign notification (B091). The OTA master 4 decrypts the encrypted common key with the RSA private key to extract the common key (B092). The OTA master 4 downloads and acquires the encrypted RP metadata from the CDN 8 (B093). The OTA master 4 decrypts the encrypted RP metadata with the RSA private key to extract the RP metadata (B094). The OTA master 4 interprets the contents of the RP metadata to identify the common key encryption method and the distribution route (B095). The OTA master 4 acquires the encrypted update package through the identified distribution route (B096). That is, when the OTA master 4 identifies a smartphone as the distribution route, the OTA master 4 downloads the encrypted update package from the CDN 8 via the smartphone using the bulk storage method. When the OTA master 4 identifies the USB memory as the delivery path, it downloads the encrypted update package from the CDN 8 via the USB memory in a bulk storage manner. After this, the OTA master 4 performs the processes from step B014 onward described in the first embodiment if the CTR mode is adopted as the specific encryption mode, and performs the processes from step B024 onward described in the second embodiment if the OFB mode is adopted as the specific encryption mode.

[0093] As described above, according to the ninth embodiment, the following advantageous effects can be obtained. The update package is acquired from the CDN 8 via a recording medium such as a smartphone or a USB memory. The update package distribution route can be diversified, and a distribution route having superior distribution cost and usability can be selected. This appropriately reduces the distribution cost when the OTA master 4 downloads the update package from the OTA center 2, and improves the user experience value. In the above embodiment, the OTA master 4 interprets the contents of the RP metadata in step B095 to specify the common key cryptography method and the distribution route, but if multiple distribution routes are described in the RP metadata, it may be possible to select one of the multiple distribution routes.

[0094] Tenth embodiment The tenth embodiment will be described with reference to Figs. 87 to 98. In the tenth embodiment, a plurality of CDN vendors are dynamically selected as destinations for disposing an update package in CDN8 according to the distribution method, the OTA target area which is the distribution area, and the distribution data size, to suppress the distribution cost. A comparison of CDN costs is shown in Figs. 88 to 89. A price table is shown in Figs. 90 to 93. The price advantages of each CDN vendor are different depending on the distribution area such as Japan or North America, the distribution data size, etc. For example, referring to Fig. 90, when distributing a data size of 100 TB per month, CDN2 is the cheapest in Japan, but CDN1 is the cheapest in North America and EU. Based on this fact, a CDN vendor with the lowest distribution cost is selected according to the distribution method, the OTA target area, and the distribution data size.

[0095] 94, the OTA center 2 includes a common key generation unit 2a, an update package encryption unit 2b, a common key encryption unit 2c, a common key storage unit 2d, an encrypted package deployment unit 2e, a campaign notification transmission unit 2f, and a CDN vendor selection unit 2j. The CDN vendor selection unit 2j selects a CDN vendor by referring to a CDN vendor management database.

[0096] Next, the operation of the above-mentioned configuration will be described with reference to FIGS. (10-1) Processing of OTA Center 2 (see Figures 95 to 98) The OTA center 2 generates an AES key for encrypting the update package (A101). The OTA center 2 encrypts the update package in CTR mode with the generated AES key (A102). The OTA center 2 encrypts the AES key with an RSA public key (A103). The OTA center 2 stores the AES key encrypted with the RSA public key in the campaign notification (A104). The OTA center 2 identifies a distribution method (A105), an OTA target area (A106), and a distribution data size (A107), and refers to a price table from a CDN vendor management database using the distribution method, the OTA target area, and the distribution data size as keys (A108). In this case, the OTA center 2 may refer to the price table using at least one of the distribution method such as a storage method or a streaming method, the OTA target area such as Japan, North America, or the European Union (EU), and the distribution data size such as GB, TB, or PB as a key. The OTA center 2 selects a CDN vendor with the lowest distribution cost for each area, and places the update package encrypted with an AES key in the selected CDN 8 (A109, corresponding to the CDN vendor selection step). Alternatively, the OTA center 2 may place the update package encrypted with an AES key in each CDN 8. The OTA center 2 transmits the encrypted AES key and a campaign notification that stores the data storage destination and URI information of the update package so that the selected CDN vendor can be accessed, to the vehicle-side system 3 to be reprogrammed (A110).

[0097] (10-2) OTA Master 4 Processing The processing of the OTA master 4 is similar to the processing of the OTA master 4 described in the first embodiment (FIGS. 12 to 14).

[0098] As described above, according to the tenth embodiment, the following advantageous effects can be obtained. The CDN vendor management database is referred to, and the CDN 8 with the most advantageous delivery cost is selected from among multiple CDNs 8 with different delivery costs according to the delivery method, OTA target area, and delivery data size, and the update package is placed in the selected CDN 8. The delivery cost when the OTA master 4 downloads the update package from the OTA center 2 can be appropriately suppressed. In addition, by encrypting the update package at the OTA center 2, in principle, there is no problem in terms of security even if the intermediate route is zero trust. Therefore, there is no need to encrypt the update data at the edge side of the CDN 8, and it is possible to reduce the processing load and security function of the CDN 8. Even if the data is tampered with or the CDN 8 is subjected to a DDoS attack on the intermediate route from the OTA center 2 to the OTA master 4, there is no impact on the OTA system, and it is possible to eliminate the need for intelligent security measures for systems intervening in the intermediate route, such as web application firewalls, TLS communication, and multi-layered defense safety support measures such as signed URLs that limit the OTA masters 4 to be delivered. This makes it possible to reduce the running costs of the OTA system on a cost basis and keeps distribution costs down regardless of the system configuration.

[0099] Eleventh embodiment The eleventh embodiment will be described with reference to Fig. 99 to Fig. 108. The eleventh embodiment employs Diffie-Hellman key exchange (hereinafter referred to as DHE (Diffie-Hellman key exchange)) or elliptic curve Diffie-Hellman key exchange (hereinafter referred to as ECDHE (Elliptic curve Diffie-Hellman key exchange)) for key distribution between the OTA center 2 and the OTA master 4, and the OTA center 2 encrypts an AES key based on shared secret information that differs for each vehicle and distributes the AES key to the OTA master 4, thereby enjoying the advantage of ensuring forward secrecy of ECDHE, and distributing an update package applicable to each vehicle model applicable to the CDN 8 or each specific vehicle group.

[0100] As shown in Fig. 100, each party generates and exchanges their respective public keys (A, B) from random numbers (= private keys: a, b), and secretly shares secret information (S) by combining them with their own private keys for calculations. The private key and public key pair (a / A, b / B) can be discarded after the secret information (S) is shared, and there is no need to store it in an HSM (Hardware Security Module) at both the OTA center 2 and the OTA master 4, so the secret information (S) can be shared very securely. This shared secret information (S) can be used as a key for symmetric encryption, but since the original data is random numbers (a, b), it becomes a different key for each OTA master 4.

[0101] Next, the operation of the above-mentioned configuration will be described with reference to FIGS. (11-1) Processing at OTA Center 2 (see Figures 101 to 104) The OTA center 2 generates an AES key for encrypting the update package (A111). The OTA center 2 encrypts the update package in CTR mode with the generated AES key (A112). The OTA center 2 generates an ECDHE key pair from random numbers (A113). The OTA center 2 shares a secret key with the OTA master 4 using the ECDHE algorithm (A114, which corresponds to the secret information sharing procedure). The OTA center 2 encrypts the AES key with the secret key (A115). The OTA center 2 stores the AES key encrypted with the secret key in the campaign notification (A116). The OTA center 2 places the update package encrypted with the AES key in the CDN 8 (A117). The OTA center 2 transmits the campaign notification in which the encrypted AES key is stored to the vehicle-side system 3 to be reprogrammed (A118, which corresponds to the encryption key distribution procedure).

[0102] Here, step A114 will be described. When the ignition of the vehicle is turned on and a predetermined period has passed since the previous synchronization of the vehicle configuration information, the OTA master 4 inquires the ECU mounted on the vehicle about the program version and collects the vehicle configuration information. Alternatively, when the OTA master 4 receives a push notification related to a campaign from the OTA center 2, it inquires the ECU about the program version and collects the vehicle configuration information. When the OTA master 4 collects the vehicle configuration information, it establishes TLS communication with the OTA center 2 and transmits the vehicle configuration information to the OTA center 2. At this time, the OTA master 4 collects the vehicle configuration information and generates an ECDHE key pair, and when it establishes TLS communication with the OTA center 2, it transmits the public key of the OTA master 4 of the key pair to the OTA center 2. The process of the OTA master 4 collecting the vehicle configuration information is also applicable to other embodiments. The OTA center 2 acquires a private key in the ECDHE algorithm based on the public key of the OTA master 4 acquired from the OTA master 4 and the private key of the OTA center 2.

[0103] (11-2) OTA Master 4 Processing (See Figure 105 to Figure 108) The OTA master 4 generates an ECDHE key pair from random numbers (B111). The OTA master 4 shares a secret key with the OTA center 2 using the ECDHE algorithm (B112, which corresponds to a secret information sharing step). When the OTA master 4 acquires a campaign notification by receiving the campaign notification sent from the OTA center 2, the OTA master 4 acquires an AES key from the acquired campaign notification (B113). The OTA master 4 decrypts the encrypted AES key with the secret key to extract the AES key (B114). The OTA master 4 downloads and acquires the encrypted update package from the CDN 8 (B115).

[0104] At this time, while downloading and acquiring the encrypted update package from the CDN 8, the OTA master 4 performs AES block encryption processing on the counter value using the AES key to encrypt the counter value (B116). The OTA master 4 performs an XOR operation on the encrypted counter value and the encrypted update package downloaded from the CDN 8 to decrypt the value (B117). The OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B118).

[0105] As described above, according to the eleventh embodiment, the following advantageous effects can be obtained. DHE or ECDHE is adopted for key distribution between the OTA center 2 and the OTA master 4, and the OTA center 2 encrypts the AES key based on shared secret information that differs for each vehicle and distributes it to the OTA master 4. This makes it possible to appropriately ensure the forward secrecy of ECDHE while appropriately realizing efficient distribution of update data by the CDN 8.

[0106] (Modification of the eleventh embodiment) A modified example of the eleventh embodiment will be described with reference to Figs. 166 to 173. In the eleventh embodiment, the description is based on the premise that a wireless communication device is installed in the vehicle and the OTA master 4 can transmit and receive data with the OTA center 2 and the CDN 8 via a wireless communication line. However, there are cases where the vehicle is not installed with a wireless communication device or where the user does not prefer to use a wireless communication line. In the modified example of the eleventh embodiment, a situation will be described in which the OTA master 4 does not transmit and receive data with the OTA center 2 and the CDN 8 via a wireless communication line, but instead performs a program update using a storage medium such as an SD card.

[0107] The OTA master 4 and the OTA center 2 use a storage medium for data transfer with the outside. Data transfer between the OTA master 4 and the storage medium uses a port for the storage medium installed in the vehicle. The port installed in the vehicle is, for example, a port installed in a car navigation device, a center display device, or another vehicle control device.

[0108] Data transfer between the OTA center 2 and the storage medium is performed by connecting the storage medium to a personal computer (hereinafter referred to as PC). For example, the storage medium is connected to a PC, and the website of the OTA center 2 or CDN 8 is accessed, and data stored in the storage medium is uploaded to the OTA center 2 by operating the PC, or data stored in the OTA center 2 is downloaded to the storage medium by operating the PC. Note that a smartphone, tablet terminal, etc. compatible with the storage medium can also be used instead of a PC. A PC, smartphone, tablet terminal, etc. compatible with the storage medium is also referred to as an operation terminal.

[0109] A case where an SD card is used as the storage medium will be described with reference to Figures 166 to 169. In this case, processing is performed in the following order: data transfer from the OTA master 4 to the SD card 11, data upload from the SD card 11 to the OTA center 2, data download from the OTA center 2 to the SD card 11, and data transfer from the SD card 11 to the OTA master 4.

[0110] The transfer of data from the OTA master 4 to the SD card 11 will be described with reference to Fig. 166. The OTA master 4 acquires software version information, etc. from the target ECU 5, and transfers the acquired software version information, etc. to the SD card 11 as vehicle configuration information to store. The OTA master 4 generates an ECDHE key pair from random numbers, and transfers the ECDHE public key to the SD card 11 to store it. The SD card 11 stores the vehicle configuration information transferred from the OTA master 4 and the ECDHE public key of the OTA master 4.

[0111] With reference to FIG. 167, the uploading of data from a PC to which the SD card 11 is connected to the OTA center 2 will be described. When the SD card 11 is connected to the PC, the PC reads out the vehicle configuration information and the ECDHE public key of the OTA master 4 stored in the SD card 11, and uploads the read vehicle configuration information and the ECDHE public key of the OTA master 4 to the OTA center 2. The vehicle configuration information uploaded to the OTA center 2 is used by the PKG generation server 6 to determine whether or not a campaign is running. The ECDHE public key of the OTA master 4 uploaded to the OTA center 2 shares a private key based on the ECDHE algorithm in the distribution server 7. In this case, the private key is a different private key for each vehicle.

[0112] With reference to FIG. 168, the download of data from the OTA center 2 to the SD card 11 will be described. Here, a case where a campaign is performed is shown. The OTA center 2 downloads an update package encrypted with an AES key to the SD card 11 and stores it. The OTA center 2 generates an ECDHE key pair from random numbers, and downloads the key to be shared with the OTA master 4 (the OTA center 2's ECDHE public key) to the SD card 11 and stores it. The OTA center 2 downloads a campaign notification containing the encrypted AES key to the SD card 11 and stores it. The SD card 11 stores the update package downloaded from the OTA center 2, the OTA center 2's ECDHE public key, and the encrypted AES key.

[0113] 169, a description will be given of the transfer of data from the SD card 11 to the OTA master 4. The OTA master 4 reads and acquires from the SD card 11 the encrypted update package, the ECDHE public key of the OTA center 2, and the encrypted AES key stored in the SD card 11.

[0114] Next, the operation of the above-mentioned configuration will be described with reference to FIGS. (11-3) OTA Master 4 Processing (See Figure 170) When the SD card 11 is connected to the vehicle-side system 3 and a predetermined condition is satisfied, the OTA master 4 requests the target ECU 5 to transmit configuration information such as software version information, and acquires the configuration information such as software version information transmitted from the target ECU 5 as vehicle configuration information (B1111). When the OTA master 4 acquires the vehicle configuration information, the OTA master 4 transfers the acquired vehicle configuration information to the SD card 11 and stores it (B1112). The OTA master 4 generates an ECDHE key pair from a random number (B1113). In this case, the key pair includes an ECDHE public key and an ECDHE private key of the OTA master 4. The OTA master 4 transfers the ECDHE public key of the OTA master 4 to the SD card 11 and stores it (B1114). When the vehicle configuration information and the ECDHE public key of the OTA master 4 are thus stored, the SD card 11 is disconnected from the vehicle-side system 3 and connected to the PC.

[0115] (11-4) PC processing (see Figure 171) When the SD card 11 is connected, the PC reads out the vehicle configuration information and the ECDHE public key of the OTA master 4 stored in the SD card 11, and uploads the read vehicle configuration information and the ECDHE public key of the OTA master 4 to the OTA center 2 (C1111). The PC waits to receive from the OTA center 2 a campaign notification in which the ECDHE public key of the OTA master 4 and the AES key are stored, and an encrypted update package, and also waits to receive a notification of no campaign (C1112, C1113). When the PC determines that it has received from the OTA center 2 a campaign notification in which the ECDHE public key of the OTA master 4 and the AES key are stored, and an encrypted update package (C1112: YES), or when it determines that it has received a notification of no campaign (C1113: YES), it ends the processing.

[0116] (11-5) Processing at OTA Center 2 (see Figure 172) The OTA center 2 generates an AES key for encrypting the update package, and encrypts the update package in CTR mode with the AES key. The OTA center 2 acquires the vehicle configuration information uploaded from the PC to which the SD card 11 is connected, and the ECDHE public key of the OTA master 4 (A1111). The OTA center 2 determines whether or not there is a campaign based on the vehicle configuration information (A1112). If the OTA center 2 determines that there is no campaign (A1112: NO), it sends a no-campaign notification to the PC (A1113) and ends the process.

[0117] When the OTA center 2 determines that there is a campaign (A1112: YES), it generates an ECDHE key pair from random numbers (A1114). In this case, the key pair is the ECDHE public key and ECDHE private key of the OTA center 2. The OTA center 2 downloads the ECDHE public key of the OTA center 2 to the SD card 11 and stores it (A1115). The OTA center 2 generates an ECDHE common key (private key) from the ECDHE private key of the OTA center 2 and the ECDHE public key of the OTA master 4 (A1116), and encrypts the AES key with the generated ECDHE common key (private key) (A1117). The OTA center 2 stores the encrypted AES key in the campaign notification, and downloads the campaign notification that stores the encrypted AES key to the SD card 11 and stores it (A1118). The OTA center 2 downloads the encrypted update package to the SD card 11 and stores it (A1119).

[0118] (11-6) OTA Master 4 Processing (See Figure 173) When the SD card 11 is connected to the vehicle-side system 3, the OTA master 4 acquires the ECDHE public key of the OTA center 2, the campaign notification, and the update package from the SD card 11 (B1121). The OTA master 4 generates an ECDHE common key (secret key) from the ECDHE private key of the OTA master 4 and the ECDHE public key of the OTA center 2 (B1122). The OTA master 4 extracts the encrypted AES key from the campaign notification and decrypts it with the ECDHE common key (secret key) (B1123). The OTA master 4 encrypts the counter value by performing AES block encryption processing on the counter value with the AES key (B1124). The OTA master 4 decrypts the encrypted counter value and the encrypted update package by performing an XOR operation (B1125). The OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B1126).

[0119] According to this configuration, it is possible to appropriately ensure the forward secrecy of ECDHE and appropriately realize efficient distribution of update data by the CDN 8 without relying on the wireless communication function of the vehicle-side system 3. In addition, it is possible to improve convenience for users by suppressing the number of data transfers between the OTA master 4 and the SD card 11 and the number of uploads and downloads between the OTA center 2 and the SD card 11.

[0120] Twelfth embodiment The twelfth embodiment will be described with reference to Figures 109 to 115. In the twelfth embodiment, in key sharing in ECDHE, the random number a generated by the OTA center 2 is a random number for each vehicle model (a random number according to a specific rule), and the random number b generated by the OTA master 4 is a fixed value for each vehicle model, a count-up value, or a hash value of the software version of the OTA master 4, or a combination of these, thereby making the secret key shared in ECDHE common for each vehicle model, and while enjoying the benefit of ensuring forward secrecy of ECDHE, omitting the process of distributing the key, and distributing an encryption package applicable to each vehicle model or a specific vehicle group via CDN.

[0121] Next, the operation of the above-mentioned configuration will be described with reference to Figures 110 to 115. (12-1) Processing at OTA Center 2 (see Figures 110 to 112) The OTA center 2 generates an ECDHE key pair from a random number that is common to each vehicle model or each vehicle group (A121). The OTA center 2 shares a secret key with the OTA master 4 using the ECDHE algorithm (A122, which corresponds to a secret information sharing procedure). In this embodiment, the secret key shared with the OTA master 4 using the ECDHE algorithm is used as an AES key for encrypting the update package. Furthermore, the OTA master 4 uses the secret key shared with the OTA center 2 as an AES key for decrypting the encrypted update package. The OTA center 2 generates an AES key for encrypting the update package (A123). The OTA center 2 encrypts the update package in CTR mode using the generated AES key (A124). The OTA center 2 places the update package encrypted using the AES key in the CDN 8 (A125). The OTA center 2 transmits a campaign notification in which the encrypted AES key is stored to the vehicle-side system 3 to be reprogrammed (A126, which corresponds to an encryption key distribution procedure).

[0122] (12-2) OTA Master 4 Processing (See Figure 113 to Figure 115) The OTA master 4 generates an ECDHE key pair from random numbers generated according to the specific rules described above (B121). The OTA center 2 shares a secret key with the OTA center 2 using the ECDHE algorithm (B122, which corresponds to the secret information sharing procedure). The OTA master 4 downloads and acquires the encrypted update package from the CDN 8 (B123).

[0123] At this time, while downloading and acquiring the encrypted update package from the CDN 8, the OTA master 4 performs AES block encryption processing on the counter value using the AES key to encrypt the counter value (B124). The OTA master 4 performs an XOR operation on the encrypted counter value and the encrypted update package downloaded from the CDN 8 to decrypt the value (B125). The OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B126).

[0124] As described above, according to the twelfth embodiment, the following advantageous effects can be obtained. DHE or ECDHE is adopted for key distribution between the OTA center 2 and the OTA master 4, and a configuration is adopted in which a secret key shared in ECDHE is common for each vehicle model. This makes it possible to appropriately ensure the forward secrecy of ECDHE, while simplifying the work of key distribution compared to the eleventh embodiment, and appropriately realize efficient distribution of update data by the CDN 8.

[0125] (Modification of the twelfth embodiment) A modified example of the twelfth embodiment will be described with reference to Figures 174 to 181. In the modified example of the twelfth embodiment, as in the modified example of the eleventh embodiment, a situation will be described in which the OTA master 4 does not transmit and receive data to and from the OTA center 2 or the CDN 8 via a wireless communication line, but instead performs a program update using a storage medium such as an SD card, for example.

[0126] With reference to FIG. 174, the transfer of data from the OTA master 4 to the SD card 11 will be described. The OTA master 4 acquires software version information and the like from the target ECU 5, and transfers and stores the acquired software version information and the like to the SD card 11 as vehicle configuration information. The OTA master 4 generates an ECDHE key pair common to each vehicle model using any one of a fixed value for each vehicle model, a count-up value, or a hash value of the software version of the OTA master 4, or a combination of these, and transfers and stores the key to be shared with the OTA center 2 (ECDHE public key of the OTA master 4) to the SD card 11. Any one of a fixed value for each vehicle model, a count-up value, or a hash value of the software version of the OTA master 4, or a combination of these, corresponds to a specific rule. The SD card 11 stores the vehicle configuration information transferred from the OTA master 4 and the ECDHE public key of the OTA master 4.

[0127] With reference to FIG. 175, the uploading of data from a PC to which the SD card 11 is connected to the OTA center 2 will be described. When the SD card 11 is connected to the PC, the PC reads out the vehicle configuration information and the ECDHE public key of the OTA master 4 stored in the SD card 11, and uploads the read vehicle configuration information and the ECDHE public key of the OTA master 4 to the OTA center 2. The vehicle configuration information uploaded to the OTA center 2 is used by the PKG generation server 6 to determine whether or not a campaign is running. In addition, the ECDHE public key of the OTA master 4 uploaded to the OTA center 2 shares a private key based on the ECDHE algorithm in the distribution server 7. The private key in this case is a common private key for each vehicle model.

[0128] Downloading of data from the OTA center 2 to the SD card 11 will be described with reference to FIG. 176. The OTA center 2 generates an ECDHE key pair from a random number that is common to each vehicle model or each vehicle group, and downloads and stores the key to be shared with the OTA master 4 (the ECDHE public key of the OTA center 2) to the SD card 11. The OTA center 2 encrypts the update package by using the private key shared by ECDHE as an AES key, and downloads and stores the encrypted update package to the SD card 11. The SD card 11 stores the ECDHE public key of the OTA center 2 and the update package downloaded from the OTA center 2.

[0129] With reference to Figure 177, the transfer of data from the SD card 11 to the OTA master 4 will be described. The OTA master 4 reads and acquires the encrypted update package stored in the SD card 11 and the ECDHE public key of the OTA center 2. The OTA master 4 shares a secret key based on the ECDHE algorithm. The OTA master 4 uses the secret key shared by ECDHE as an AES key to decrypt the encrypted update package.

[0130] Next, the operation of the above-mentioned configuration will be described with reference to FIGS. (12-3) OTA Master 4 Processing (See Figure 178) When the SD card 11 is connected to the vehicle-side system 3 and a predetermined condition is satisfied, the OTA master 4 requests the target ECU 5 to transmit configuration information such as software version information, and acquires the configuration information such as software version information transmitted from the target ECU 5 as vehicle configuration information (B1211). When the OTA master 4 acquires the vehicle configuration information, the OTA master 4 transfers the acquired vehicle configuration information to the SD card 11 and stores it (B1212). The OTA master 4 generates an ECDHE key pair from random numbers generated according to a specific rule (B1213). In this case, the key pair includes an ECDHE public key and an ECDHE private key of the OTA master 4. The OTA master 4 transfers the ECDHE public key of the OTA master 4 to the SD card 11 and stores it (B1214). The ECDHE key pair is a random number generated according to a specific rule as in the twelfth embodiment, and is common to each vehicle model. Once the vehicle configuration information and the ECDHE public key of the OTA master 4 have been saved in this manner, the SD card 11 is disconnected from the vehicle-side system 3 and connected to the PC.

[0131] (12-4) PC processing (see Figure 179) When the SD card 11 is connected, the PC reads out the vehicle configuration information and the ECDHE public key of the OTA master 4 stored in the SD card 11, and uploads the read vehicle configuration information and the ECDHE public key of the OTA master 4 to the OTA center 2 (C1211). The PC waits to receive a campaign notification in which the ECDHE public key of the OTA master 4 is stored and an encrypted update package from the OTA center 2, and also waits to receive a notification of no campaign (C1212, C1213). When the PC determines that it has received a campaign notification in which the ECDHE public key of the OTA master 4 is stored and an encrypted update package from the OTA center 2 (C1212: YES) or a notification of no campaign (C1213: YES), it ends the processing.

[0132] (12-5) Processing at OTA Center 2 (see Figure 180) The OTA center 2 acquires the vehicle configuration information uploaded from the PC to which the SD card 11 is connected and the ECDHE public key of the OTA master 4 (A1211). The OTA center 2 determines whether or not there is a campaign based on the vehicle configuration information (A1212). If the OTA center 2 determines that there is no campaign (A1212: NO), it sends a no-campaign notification to the PC (A1213) and ends the process.

[0133] When the OTA center 2 determines that there is a campaign (A1212: YES), it generates an ECDHE key pair from a random number that is common to each vehicle model or each vehicle group (A1214). In this case, the key pair is an ECDHE public key and an ECDHE private key of the OTA center 2. The OTA center 2 downloads and stores the ECDHE public key of the OTA center 2 to the SD card 11 (A1215). The OTA center 2 generates an ECDHE common key (private key) from the ECDHE private key of the OTA center 2 and the ECDHE public key of the OTA master 4 (A1216), and encrypts the update package with the generated ECDHE common key (private key) (A1217). The OTA center 2 downloads and stores the encrypted update package to the SD card 11 (A1218).

[0134] (12-6) OTA Master 4 Processing (See Figure 181) When the SD card 11 is connected to the vehicle-side system 3, the OTA master 4 acquires the ECDHE public key and the update package of the OTA center 2 from the SD card 11 (B1221). The OTA master 4 generates an ECDHE common key (private key) from the ECDHE private key of the OTA master 4 and the ECDHE public key of the OTA center 2 (B1222). The OTA master 4 encrypts the counter value by performing AES block encryption processing with the AES key (B1223). The OTA master 4 decrypts the encrypted counter value and the encrypted update package by performing an XOR operation (B1224). The OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B1225).

[0135] According to this configuration, it is possible to appropriately ensure forward secrecy of ECDHE without relying on the wireless communication function of the vehicle-side system 3, while simplifying the work of key distribution compared to the eleventh embodiment, and appropriately realize efficient distribution of update data by the CDN 8. In addition, by suppressing the number of data transfers between the OTA master 4 and the SD card 11, and the number of uploads and downloads between the OTA center 2 and the SD card 11, it is possible to improve convenience for the user.

[0136] Thirteenth embodiment The thirteenth embodiment will be described with reference to Fig. 116 to Fig. 124. The thirteenth embodiment does not simply apply the CTR mode, but rather improves the counter value to make it more secure. Specifically, the CTR mode is made safer by inserting a nonce into the campaign notification that is first communicated between the OTA center 2 and the OTA master 4, and inserting the nonce into the counter value. The encryption process for inserting the nonce in the CTR mode is as shown in Fig. 117, and the decryption process for inserting the nonce in the CTR mode is as shown in Fig. 118.

[0137] Next, the operation of the above-mentioned configuration will be described with reference to FIGS. (13-1) Processing at OTA Center 2 (see Figures 119 to 121) The OTA center 2 generates an AES key for encrypting the update package (A131). The OTA center 2 generates a nonce using a random number (A132). The OTA center 2 encrypts the update package in CTR mode using the generated AES key and nonce (A133). The OTA center 2 encrypts the AES key using an RSA public key (A134). The OTA center 2 may encrypt the nonce using the RSA public key at the same time as encrypting the AES key using the RSA public key. The OTA center 2 stores the AES key and nonce encrypted using the RSA public key in the campaign notification (A135). The OTA center 2 places the update package encrypted using the AES key in the CDN 8 (A136). The OTA center 2 transmits the campaign notification in which the encrypted AES key and nonce are stored to the vehicle-side system 3 to be reprogrammed (A137).

[0138] (13-2) OTA Master 4 Processing (See Figure 122 to Figure 124) When the OTA master 4 acquires the campaign notification by receiving the campaign notification sent from the OTA center 2, the OTA master 4 acquires an AES key and a nonce from the acquired campaign notification (B131). The OTA master 4 decrypts the encrypted AES key with the RSA private key to extract the AES key (B132). The OTA master 4 downloads and acquires the encrypted update package from the CDN 8 (B133). The OTA master 4 decrypts the encrypted update package downloaded from the CDN 8 with the AES key and nonce (B134). The OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B135).

[0139] As described above, according to the thirteenth embodiment, the following advantageous effects can be obtained. A nonce is included in the campaign notification that is first communicated between the OTA center 2 and the OTA master 4, and the nonce is then included in the counter value. By including the nonce in the counter value, the CTR mode can be made safer.

[0140] Fourteenth embodiment The fourteenth embodiment will be described with reference to Fig. 125 to Fig. 132. In the fourteenth embodiment, a key used for encryption is not a common key for all vehicles in order to narrow the scope of influence when a key is compromised, but a derived key individualized for each specific vehicle group is used, thereby localizing the loss when a key is leaked while maintaining the delivery cache efficiency of the CDN8, and more secure OTA delivery is achieved. As shown in Fig. 126, the VIN number is divided into multiple categories for the same vehicle model and year, and a different AES individual key is used for each category. For example, the VIN numbers are divided into AAA to CCC, DDD to KKK, and SSS to ZZZ, and different AES individual keys are used. The individual key database includes, for example, an OEM code, a vehicle model, a year, an AES master key, a seed value, and an AES individual key divided by a VIN number.

[0141] Next, the operation of the above-mentioned configuration will be described with reference to FIGS. (14-1) Processing at OTA Center 2 (see Figures 127 to 129) The OTA center 2 generates an AES individual key for encrypting the update package from the AES master key and a seed value (A141). The seed value is, for example, a random number, a counter value, or a timestamp. The OTA center 2 encrypts the update package in CTR mode with one of the generated AES individual keys and a nonce (A142). The OTA center 2 encrypts the AES individual key with an RSA public key (A143). The OTA center 2 stores the AES individual key and nonce encrypted with the RSA public key in a campaign notification (A144). The OTA center 2 places the update package encrypted with one of the AES individual keys and a nonce in the CDN 8 (A145). The OTA center 2 transmits the campaign notification in which the encrypted AES individual key and nonce are stored to the vehicle-side system 3 to be reprogrammed (A146).

[0142] (14-2) OTA Master 4 Processing (See Figure 130 to Figure 132) When the OTA master 4 acquires the campaign notification by receiving the campaign notification sent from the OTA center 2, the OTA master 4 acquires an AES individual key and a nonce from the acquired campaign notification (B141). The OTA master 4 decrypts the encrypted AES individual key with the RSA private key to extract the AES individual key (B142). The OTA master 4 downloads and acquires the encrypted update package from the CDN 8 (B143). The OTA master 4 decrypts the encrypted update package downloaded from the CDN 8 with the AES individual key and the nonce (B144). The OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B145).

[0143] As described above, according to the fourteenth embodiment, the following advantageous effects can be obtained. Regarding the key used for encryption, instead of using a common key for all vehicles, a derived key that is individualized for each specific vehicle group is used. This makes it possible to localize the loss caused by key leakage while maintaining the efficiency of the CDN8 distribution cache. This makes it possible to improve security when the OTA master 4 downloads update packages from the OTA center 2, realizing more secure OTA distribution.

[0144] Fifteenth embodiment The fifteenth embodiment will be described with reference to Fig. 133 to Fig. 137. In the fifteenth embodiment, in preparation for the worst case scenario of a private key leak, a key version is assigned so that the key can be updated by OTA, and the OTA center 2 manages the key, and a key update key is stored in the HSM area of ​​the OTA master. The OTA center 2 manages version information of the RSA public key used for encrypting the AES key and the RSA private key used for decrypting it. By managing the version information, the RSA private key and the RSA public key are not downgraded when they are updated. The OTA center 2 and the OTA master 4 are provided with a key update key used when updating the private key. The OTA center 2 generates a new private key pair when the private key is leaked or at regular intervals, generates a key update package using the key update key, and transmits the key update package to the OTA master 4, thereby realizing key update of the private key.

[0145] Next, the operation of the above-mentioned configuration will be described with reference to FIGS. (15-1) Processing at OTA Center 2 (see Figures 134 and 135) The OTA center 2 generates a new key pair of a new RSA private key and a new RSA public key (A151). The OTA center 2 encrypts and MACs the generated new RSA private key in CTR mode using the key update key, and generates a key update package (A152). The OTA center 2 switches the old RSA public key to the new RSA public key (A153). The OTA center 2 transmits the key update package to the vehicle-side system 3 to be reprogrammed (A154).

[0146] (15-2) OTA Master 4 Processing (See Figure 136 to Figure 137) The OTA master 4 acquires the key update package, and decrypts and MAC-verifies the new RSA private key in CTR mode using the key update key (B151). The OTA master 4 switches the old RSA private key to the decrypted new RSA private key (B152).

[0147] As described above, according to the fifteenth embodiment, the following advantageous effects can be obtained. A new private key pair is generated when the private key is leaked or at regular intervals, and a key update package is generated using a key update key and transmitted to the OTA master 4. In this way, by updating the private key, security can be improved when the OTA master 4 downloads an update package from the OTA center 2, and more secure OTA distribution can be realized.

[0148] Sixteenth embodiment The sixteenth embodiment will be described with reference to Fig. 138 to Fig. 145. In the sixteenth embodiment, in ECDHE key sharing, a digital signature is added to counter man-in-the-middle attacks, and a key applicable to an encrypted package is securely shared between the OTA center 2 and the OTA master 4. As shown in Fig. 139 to Fig. 140, DHE is vulnerable to man-in-the-middle attacks, but adding a digital signature counters man-in-the-middle attacks. As the digital signature, a digital signature using an RSA or elliptic curve DSA encryption algorithm is used.

[0149] Next, the operation of the above-mentioned configuration will be described with reference to FIGS. (16-1) Processing at OTA Center 2 (see Figures 141 to 143) The OTA center 2 generates an ECDHE key pair from random numbers created for each vehicle model or vehicle group (A161). The OTA center 2 digitally signs the ECDHE key with an RSA private key (A162). Here, the RSA private key is used, but it is not limited to the RSA private key, and any public key cryptosystem can be used instead, for example, an ECDSA (Elliptic Curve Digital Signature Algorithm) private key. The OTA center 2 transmits the ECDHE public key with the digital signature to the vehicle-side system 3 to be reprogrammed (A163). The OTA center 2 shares the private key with the OTA master 4 using the ECDHE algorithm (A164). The OTA center 2 generates an AES key for encrypting the update package (A165). The OTA center 2 encrypts the update package in CTR mode with the generated AES key (A166). The OTA center 2 places the update package encrypted with the AES key on the CDN 8 (A167). The OTA center 2 transmits the campaign notification containing the encrypted AES key to the vehicle-side system 3 to be reprogrammed (A168).

[0150] (16-2) OTA Master 4 Processing (See Figure 144 to Figure 145) The OTA master 4 generates an ECDHE key pair from random numbers generated according to specific rules (B161). The OTA master 4 verifies the digital signature of the ECDHE public key received from the OTA center 2 with the RSA public key (B162). Here again, as with the OTA center 2, the key is not limited to the RSA public key, and any public key cryptography method can be used, for example, an ECDSA public key. If the verification result is positive, the OTA master 4 shares a private key with the OTA center 2 using the ECDHE algorithm (B163). After this, the OTA master 4 performs the processes from step B113 onwards described in the eleventh embodiment.

[0151] As described above, according to the sixteenth embodiment, the following advantageous effects can be obtained. A digital signature is added to the ECDHE key exchange, which makes it possible to counter man-in-the-middle attacks and realize more secure OTA distribution.

[0152] (Modification of the 16th embodiment) A modified example of the 16th embodiment will be described with reference to Fig. 182 to Fig. 189. As in the modified examples of the 11th and 12th embodiments, the modified example of the 16th embodiment will also describe a situation in which the OTA master 4 does not transmit and receive data to and from the OTA center 2 or the CDN 8 via a wireless communication line, but instead performs a program update using a storage medium such as an SD card. The main difference between the modified example of the 16th embodiment and the modified example of the 12th embodiment is that a digital signature is applied to the ECDHE public key of the OTA center 2 with a key of a public key cryptography system to counter attacks from a man-in-the-middle attacker.

[0153] 182 to 185 respectively show data transfer from the OTA master 4 to the SD card 11, data upload from a PC connected to the SD card 11 to the OTA center 2, data download from the OTA center 2 to the SD card 11, and data transfer from the SD card 11 to the OTA master 4. The main difference from the modified example of the twelfth embodiment is that, as shown in FIG. 184, the OTA center 2 digitally signs a key to be shared with the OTA master 4 (ECDHE public key of the OTA center 2) using a public key cryptography key, for example, an RSA private key or an ECDSA private key. The OTA center 2 transfers the signed ECDHE public key to the SD card 11 and stores it. Also, as shown in FIG. 185, the OTA master 4 reads the signed ECDHE public key from the SD card 11 and verifies it using the RSA public key stored in the vehicle-side system 3.

[0154] Next, the operation of the above-mentioned configuration will be described with reference to FIGS. (16-3) OTA Master 4 Processing (See Figure 186) When the SD card 11 is connected to the vehicle-side system 3 and a predetermined condition is satisfied, the OTA master 4 requests the target ECU 5 to transmit configuration information such as software version information, and acquires the configuration information such as software version information transmitted from the target ECU 5 as vehicle configuration information (B1611). When the OTA master 4 acquires the vehicle configuration information, the OTA master 4 transfers the acquired vehicle configuration information to the SD card 11 and stores it (B1612). The OTA master 4 generates an ECDHE key pair from random numbers generated according to a specific rule (B1613). In this case, the key pair includes an ECDHE public key and an ECDHE private key of the OTA master 4. The OTA master 4 transfers the ECDHE public key of the OTA master 4 to the SD card 11 and stores it (B1614). The ECDHE key pair is a random number generated according to a specific rule as in the twelfth embodiment, and is common to each vehicle model. Once the vehicle configuration information and the ECDHE public key of the OTA master 4 have been saved in this manner, the SD card 11 is disconnected from the vehicle-side system 3 and connected to the PC.

[0155] (16-4) PC processing (see Figure 187) When the SD card 11 is connected, the PC reads out the vehicle configuration information and the ECDHE public key of the OTA master 4 stored in the SD card 11, and uploads the read vehicle configuration information and the ECDHE public key of the OTA master 4 to the OTA center 2 (C1611). The PC waits to receive from the OTA center 2 a campaign notification in which the ECDHE public key of the OTA master 4 is stored and an encrypted update package, and also waits to receive a notification of no campaign (C1612, C1613). When the PC determines that it has received from the OTA center 2 a campaign notification in which the ECDHE public key of the OTA master 4 is stored and an encrypted update package (C1612: YES), or when it determines that it has received a notification of no campaign (C1613: YES), it ends the processing.

[0156] (16-5) Processing at OTA Center 2 (see Figure 188) The OTA center 2 acquires the vehicle configuration information and the ECDHE public key of the OTA master 4 uploaded from the PC to which the SD card 11 is connected (A1611). The OTA center 2 determines whether or not there is a campaign based on the vehicle configuration information (A1612). If the OTA center 2 determines that there is no campaign (A1612: NO), it sends a no-campaign notification to the PC (A1613) and ends the process.

[0157] When the OTA center 2 determines that there is a campaign (A1612: YES), it generates an ECDHE key pair from a random number that is common to each vehicle model or each vehicle group (A1614). In this case, the key pair is the ECDHE public key and ECDHE private key of the OTA center 2. The OTA center 2 signs the ECDHE public key of the OTA center 2 with the RSA private key (A1615), and downloads and stores the signed ECDHE public key of the OTA center 2 to the SD card 11 (A1616). The OTA center 2 generates an ECDHE common key (private key) from the ECDHE private key of the OTA center 2 and the ECDHE public key of the OTA master 4 (A1617), and encrypts the update package with the generated ECDHE common key (private key) (A1618). The OTA center 2 downloads and stores the encrypted update package to the SD card 11 (A1619).

[0158] (16-6) OTA Master 4 Processing (See Figure 189) When the SD card 11 is connected to the vehicle-side system 3, the OTA master 4 acquires the signed ECDHE public key of the OTA center 2 and the update package from the SD card 11 (B1621). The OTA master 4 verifies the signed ECDHE public key of the OTA center 2 with the RSA public key (B1622). The OTA master 4 determines whether the verification result is normal or not (B1623), and if it determines that the verification result is abnormal (B1623: NO), issues an error notification (B1624).

[0159] If the OTA master 4 determines that the verification result is normal (B1623: YES), it generates an ECDHE common key (private key) from the ECDHE private key of the OTA master 4 and the ECDHE public key of the OTA center 2 (B1625). The OTA master 4 performs AES block encryption processing on the counter value using the AES key to encrypt the counter value (B1626). The OTA master 4 decrypts the encrypted counter value and the encrypted update package by performing an XOR operation (B1627). The OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B1628).

[0160] This configuration makes it possible to counter attacks from man-in-the-middle attackers and realize more secure OTA distribution without relying on the wireless communication function of the vehicle-side system 3. In addition, by reducing the number of data transfers between the OTA master 4 and the SD card 11 and the number of uploads and downloads between the OTA center 2 and the SD card 11, it is possible to improve convenience for users.

[0161] Seventeenth embodiment The seventeenth embodiment will be described with reference to Fig. 146 to Fig. 151. The tenth embodiment is configured to select a CDN vendor with the lowest delivery cost for each area from among multiple CDN vendors, whereas the seventeenth embodiment is configured to statically select a CDN vendor capable of reducing delivery cost from among multiple CDN vendors. Specifically, the tenth embodiment encrypts the update package at the OTA center 2 and minimizes the delivery cost according to the delivery method, OTA target area, and delivery data size, whereas the seventeenth embodiment does not encrypt the update package at the OTA center 2, protects the communication between the CDN 8 and the OTA master 4 by TLS communication, and minimizes the delivery cost according to the delivery method, OTA target area, and delivery data size.

[0162] Next, the operation of the above-mentioned configuration will be described with reference to FIGS. (17-1) Processing at OTA Center 2 (see Figures 147 to 148) The OTA center 2 identifies the distribution method (A171), identifies the OTA target area (A172), identifies whether TLS is used in the communication protocol to the vehicle (A173), identifies the distribution data size (A174), and refers to the price table in the CDN vendor management database using the distribution method, OTA target area, communication protocol, and distribution data size as keys (A175). In this case, the OTA center 2 may refer to the price table using at least one of the distribution method, OTA target area, communication protocol, and distribution data size as keys. The OTA center 2 selects a CDN vendor with the lowest distribution cost for each area, and places the update package in the selected CDN 8 (A176). The OTA center 2 transmits a campaign notification to the vehicle-side system 3 to be reprogrammed (A177).

[0163] (17-2) OTA Master 4 Processing (See Figure 149 to Figure 151) The OTA master 4 acquires the campaign notification by receiving the campaign notification sent from the OTA center 2 (B171). The OTA master 4 establishes TLS communication with the CDN vendor listed in the campaign notification to acquire the update package (B172). Note that as long as the URI information is included in the campaign notification, the CDN vendor information does not need to be included. After establishing TLS communication, the OTA master 4 exchanges AES common keys using the TLS communication protocol. Negotiates to select AES-CTR mode as the encryption mode. The OTA master 4 downloads and acquires the update package encrypted with the TLS AES common key from the CDN 8 based on the URI information (B173, corresponding to the update data acquisition procedure).

[0164] At this time, while downloading and acquiring the encrypted update package from the CDN 8, the OTA master 4 performs AES block encryption processing on the counter value using the AES key to encrypt the counter value (B174). The OTA master 4 performs an XOR operation on the encrypted counter value and the encrypted update package downloaded from the CDN 8 to decrypt the value (B175). The OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B176).

[0165] As described above, according to the seventeenth embodiment, the following advantageous effects can be obtained. The update package is not encrypted at the OTA center 2, and is protected by TLS communication between the CDN 8 and the OTA master 4, and the configuration is such that the distribution cost is minimized according to the distribution method, OTA target area, communication protocol, and distribution data size. This makes it possible to appropriately suppress the distribution cost when the OTA master 4 downloads the update package from the OTA center 2.

[0166] (18th embodiment) The 18th embodiment will be described with reference to Figs. 152 to 165. In the 18th embodiment, the optimal CDN vendor is selected by comprehensively considering not only the delivery cost but also the throughput and response delay time of the CDN vendor, and the price table and quality characteristics of the CDN vendor are periodically checked, the CDN vendor management database is always kept up to date, and the CDN vendor with the most competitive advantage in the market is always selected. The price table is as shown in Figs. 153 to 160, and the quality information of each cloud service provider is as shown in Fig. 161. As shown in Fig. 162, when CDN vendor A and CDN vendor B are compared, CDN vendor B is superior to CDN vendor A in terms of delivery cost, but CDN vendor A is superior to CDN vendor B in terms of throughput weighting and response delay time weighting. If we take into consideration not only the delivery cost but also the CDN vendor's throughput, response delay time, etc., we can conclude that CDN vendor A, which has an advantage after comprehensively considering the CDN vendor's throughput, response delay time, etc., should be selected, rather than CDN vendor B, which has an advantage solely in terms of delivery cost.

[0167] Next, the operation of the above-mentioned configuration will be described with reference to FIGS. (18-1) Processing at OTA Center 2 (see Figures 163 to 165) The OTA center 2 identifies a distribution method (A181), identifies an OTA target area (A182), and refers to a price table from the CDN vendor management database using the distribution method and the OTA target area as keys (A183). In this case, the OTA center 2 may refer to the price table using at least one of the distribution method and the OTA target area as keys. The OTA center 2 identifies quality characteristics of each CDN vendor from the CDN vendor management database (A184). The OTA center 2 selects an optimal CDN vendor for each area from the CDN vendor selection logic registered in the CDN vendor selection logic database based on the distribution cost and quality characteristics of the CDN vendor for each area, and places the update package encrypted with the AES key in the selected CDN 8 (A185). The OTA center 2 transmits a campaign notification in which the encrypted AES key is stored to the vehicle-side system 3 to be reprogrammed (A186).

[0168] The OTA center 2 automatically acquires the price table of each CDN vendor from the website and updates the CDN vendor management database (A187). The OTA center 2 measures the throughput and response delay time of each CDN vendor and updates the CDN vendor management database (A188). For example, the distribution server 7 periodically visits the website of each CDN vendor and downloads the latest price table. Alternatively, when a CDN vendor distributes updated information on its website, the distribution server 7 registers with the distribution service and downloads the latest price table.

[0169] (18-2) OTA Master 4 Processing The processing of the OTA master 4 is similar to the processing of the OTA master 4 described in the first embodiment (FIGS. 12 to 14).

[0170] As described above, according to the eighteenth embodiment, the following advantageous effects can be obtained. The optimal CDN vendor is selected by comprehensively taking into consideration not only the delivery cost but also the CDN vendor's throughput, response delay time, etc., and the CDN vendor's price table and quality characteristics are regularly checked, the CDN vendor management database is always kept up to date, and the CDN vendor with the most competitive advantage in the market is always selected. This makes it possible to appropriately suppress the delivery cost when the OTA master 4 downloads the update package from the OTA center 2.

[0171] In addition, the quality characteristics of a CDN are not limited to throughput and response delay time, but can also take into account the cache hit rate of content and past trouble records, and these can be included in the CDN vendor management database. In addition, it is also possible to periodically review the addition and deletion of CDN vendors to which the OTA center 2 is connected, and to connect to CDN vendors that are competitive in the market.

[0172] Nineteenth embodiment The 19th embodiment will be described with reference to Fig. 90 and Fig. 190 to Fig. 193. The above-mentioned 10th embodiment is configured to select a CDN vendor with the lowest delivery cost for each area from among multiple CDN vendors. In the 19th embodiment, the selection of a CDN vendor will be specifically described. In the 19th embodiment, a CDN vendor with the lowest delivery cost is dynamically selected from among multiple CDN vendors as the destination of an update package in CDN8 according to the delivery data size, the OTA target area (sometimes also referred to as a region) which is the delivery area, and the delivery method. The 19th embodiment will be described with reference to the price table exemplified in the above-mentioned Fig. 90. The price table may be in a format different from that of Fig. 90.

[0173] As shown in FIG. 190, in the OTA center 2, the distribution server 7 includes a CDN vendor selection unit 7a, a data storage unit 7b, a campaign notification generation unit 7c, and a CDN distribution unit 7d in addition to a CDN vendor management DB. The CDN vendor selection unit 7a selects a CDN vendor based on selection information, which is information necessary for selecting a CDN vendor, and information on an update package. The selection information includes the data size of the target campaign, the number of vehicles to which the target campaign is to be distributed, the region, information on the distribution method, and the like. The data storage unit 7b stores the campaign information, and also stores identification information that can identify the CDN vendor selected by the CDN vendor selection unit 7a. The identification information includes, for example, the name of the CDN vendor, an identification number that identifies the CDN vendor, or a URL that indicates the CDN vendor. The campaign notification generation unit 7c acquires information from the data storage unit 7b and generates a campaign notification to be distributed to vehicles, etc.

[0174] The CDN distribution unit 7d has a storage area corresponding to each CDN vendor. For example, the storage area has storage area A, storage area B, and storage area C. Each storage area of ​​the CDN distribution unit 7d is synchronized with the CDN server. That is, for example, when the CDN distribution unit 7d distributes data from the CDN server A to the vehicle-side system 3, the CDN distribution unit 7d places the data in storage area A and transfers it to the CDN server A. When the data is transferred from the CDN distribution unit 7d, the CDN server A distributes the transferred data to the vehicle-side system 3. Each storage area of ​​the CDN distribution unit 7d may be referred to as the origin server of each CDN server.

[0175] Next, the operation of the above-mentioned configuration will be described with reference to Fig. 191 to Fig. 193. The encryption process of the update package by the OTA center 2 is the same as that of the tenth embodiment or other embodiments. The process of the OTA master 4 is the same as that of the first embodiment or other embodiments. In the 19th embodiment, the selection of a CDN vendor will be mainly described.

[0176] (19-1) Processing of the Campaign Notification Generator 7c (see FIG. 191) When a campaign occurs, the campaign notification generation unit 7c acquires campaign information from an external source, such as an OEM server (A191). The campaign information includes information related to the data size of the target campaign, the number of vehicles to which the target campaign is to be distributed, the region, and the distribution method. The campaign notification generation unit 7c stores the acquired campaign information in the data storage unit 7b (A192). Storing the campaign information is sometimes referred to as arranging the campaign information.

[0177] The campaign notification generating unit 7c notifies the CDN vendor selection unit 7a of the CDN vendor selection request (A193) and waits for a selection notification from the CDN vendor selection unit 7a. When the campaign notification generating unit 7c receives the selection notification from the CDN vendor selection unit 7a (A194), it accesses the data storage unit 7b and acquires the identification information of the CDN vendor selected by the CDN vendor selection unit 7a (A195).

[0178] The campaign notification generating unit 7c generates a parameter file including the URL of the selected CDN based on the identification information of the CDN vendor as a campaign notification (A196). The campaign notification generating unit 7c delivers the generated campaign notification to the vehicle-side system 3 (A197).

[0179] (19-2) Processing of CDN vendor selection unit 7a (see Figures 192 to 193) When the CDN vendor selection unit 7a receives a CDN vendor selection request notified from the campaign notification generation unit 7 (A1911), it accesses the data storage unit 7b, obtains the selection information (A1912), and proceeds to the first CDN selection process (A1913).

[0180] When the CDN vendor selection unit 7a starts the first CDN selection process, it calculates a distribution data size indicating the data size to be distributed from the CDN server to the update target vehicle (A1921). Specifically, the CDN vendor selection unit 7a multiplies the data size of the target campaign by the number of target vehicles of the target campaign to calculate the distribution data size to be distributed from the CDN server.

[0181] The CDN vendor selection unit 7a repeats the following process for each CDN vendor (A1922 to A1929). The CDN vendor selection unit 7a acquires fee information from the CDN vendor management DB based on the distribution data size calculated earlier and region information related to the region (A1923). For example, in the case of a 30 TB campaign targeting North America, the CDN vendor selection unit 7a acquires fee information for "up to 10 TB" and "up to 40 TB" for the "North America" ​​region. Fee information may be acquired for all data sizes.

[0182] The CDN vendor selection unit 7a refers to the fee information based on the delivery data size and calculates the delivery charge (A1924). The calculation of the delivery charge may differ for each CDN vendor, and is determined by the delivery charge calculation method of the CDN vendor. For example, when calculating the delivery charge for CDN1 using the price table in FIG. 90, if the region is "North America" ​​and the delivery data size is 30TB, the price tables for "up to 10TB" and "up to 40TB" are referenced.

[0183] The CDN vendor selection unit 7a judges whether the CDN vendor under consideration is a CDN vendor that charges according to the number of requests (A1925). If the CDN vendor selection unit 7a judges that the CDN vendor does not charge according to the number of requests (A1925: NO), it determines the delivery charge as the charge for the CDN vendor (A1928), ends the calculation of the charge for the CDN vendor, and calculates the charge for the next CDN vendor.

[0184] When the CDN vendor selection unit 7a determines that the CDN vendor charges according to the number of requests (A1925: YES), it calculates the number of requests (A1926). The number of requests differs depending on the distribution method. If the distribution method is a storage method, the number of requests is the number of vehicles to which the campaign is to be distributed. If the distribution method is a streaming method, the data size of the target campaign is divided by the chunk size at the time of streaming, and multiplied by the number of vehicles to which the campaign is to be distributed to calculate the number of requests.

[0185] After calculating the number of requests, the CDN vendor selection unit 7a calculates a charge amount (sometimes called a request charge amount) based on the calculated number of requests (A1927). The request charge amount is the product of the charge amount per request and the number of requests. The CDN vendor selection unit 7a determines the total amount of the delivery charge amount and the request charge amount as the charge amount for the CDN vendor (A1928), terminates the calculation of the charge amount for the CDN vendor under consideration, and calculates the charge amount for the next CDN vendor.

[0186] After the CDN vendor selection unit 7a calculates the charges for all CDN vendors, The CDN vendor with the lowest delivery cost, i.e., the CDN vendor with the lowest billing amount, is selected (A1930), and the first CDN selection process ends. When the CDN vendor selection unit 7a ends the first CDN selection process, the CDN vendor selection unit 7a stores the selection result, i.e., the identification information of the selected CDN vendor, in the data storage unit 7b (A1914), and notifies the campaign notification generation unit 7c of the selection result (A1915).

[0187] As described above, according to the 19th embodiment, the following advantageous effects can be obtained. The distribution server 7 is configured to refer to the CDN vendor management DB, select a CDN 8 with a superior distribution cost from among multiple CDNs 8 with different distribution costs according to the distribution method, OTA target area, and distribution data size, and place the update package in the selected CDN 8. This makes it possible to appropriately suppress the distribution cost when the OTA master 4 downloads the update package from the OTA center 2.

[0188] (Modification of the 19th embodiment) Modifications of the 19th embodiment will be described with reference to Figures 194 to 211. Here, first to fifth modifications will be described.

[0189] (First modified example of the 19th embodiment) A first modified example of the 19th embodiment will be described with reference to Fig. 194 and Fig. 195. The first modified example is configured to use a DNS (Domain Name System) server, and not change the URL of the CDN server included in the campaign notification delivered to the vehicle-side system 3. In the 19th embodiment, a CDN vendor with the lowest delivery cost is selected for each campaign. The campaign notification includes the URL of the CDN server. Therefore, if the CDN vendor with the lowest delivery cost is changed, the URL described in the campaign notification is changed. The campaign notification generation unit 7c needs to access the data storage unit 7b and acquire information on the CDN vendor every time a campaign notification is generated.

[0190] In contrast, in the first modified example, the DNS setting unit 7e updates the URL and IP address conversion information registered in the DNS, so that the campaign notification generating unit 7c can always include the same URL in the campaign notification. When the CDN vendor with the lowest delivery cost is changed, the vehicle-side system 3 can access the selected CDN server by changing the information in the DNS server 12. In other words, in the 19th embodiment, each CDN server has a unique IP address and a unique URL. In contrast, the first modified example is characterized in that each CDN server has a unique IP address, but has a common URL among the CDN servers.

[0191] 194, in the OTA center 2, the distribution server 7 includes a CDN vendor management DB, a CDN vendor selection unit 7a, a data storage unit 7b, a campaign notification generation unit 7c, a CDN distribution unit 7d, and a DNS setting unit 7e. The following mainly describes the differences from the 19th embodiment.

[0192] The DNS server 12 is a server that provides a mechanism for converting domain names and IP addresses. The campaign notification received by the vehicle-side system 3 includes the URL of the CDN server to be accessed to download data. When the vehicle-side system 3 receives the campaign notification, it queries the DNS server 12 about the URL indicated in the received campaign notification. The DNS server 12 either transmits the IP address for the URL received in the query to the vehicle-side system 3, or transfers the connection destination to the address specified by the IP address.

[0193] The DNS setting unit 7e stores the identification information and IP address of the CDN vendor. When the CDN vendor selection unit 7a selects a CDN vendor, the DNS setting unit 7e transmits an IP address setting request to the DNS server 12 and sets the registration information in the DNS.

[0194] Next, the operation of the above-mentioned configuration will be described with reference to FIG. (19-3) Processing of CDN vendor selection unit 7a (see FIG. 195) When the CDN vendor selection unit 7a ends the first CDN selection process and stores the selection result in the data storage unit 7b (A1914), it causes the DNS setting unit 7e to transmit an IP address setting request to the DNS server 12, and the DNS setting unit 7e sets the registration information in DNS (A1931). As a result, the URL included in the campaign notification delivered to the vehicle-side system 3 is not changed even if the CDN vendor is changed. When the vehicle-side system 3 accesses the CDN server indicated by the URL, the DNS server 12 receives the IP address inquiry and transmits the IP address of the selected CDN server to the vehicle-side system 3.

[0195] The DNS setting unit 7e may acquire information about the DNS server 12 or store previous setting information for the DNS server 12, and when the CDN server registered in the DNS server 12 differs from the CDN server selected by the CDN vendor selection unit 7a, may transmit an IP address update request to the DNS server 12. Upon acquiring the selection notification from the CDN vendor selection unit 7a, the campaign notification generation unit 7c generates a campaign notification including a fixed URL.

[0196] According to this configuration, in addition to obtaining the same operational effects as the 19th embodiment, the CDN URL information included in the campaign notification can always be the same, thereby improving security.

[0197] (Second modified example of the 19th embodiment) A second modified example of the 19th embodiment will be described with reference to Fig. 196 to Fig. 201. Even if a CDN vendor with the lowest update package delivery cost is selected, there is a risk that the communication speed will be slow due to CDN server maintenance or trouble, access concentration, etc. The present inventors have focused on selecting a CDN vendor based on delivery cost and delivery performance.

[0198] In the second variant, when the vehicle-side system 3 queries the DNS server 12 to obtain an IP address corresponding to the URL indicated in the campaign notification, the DNS server 12 checks the delivery status of the CDN server, and if it determines that delivery is not possible, it responds to the vehicle-side system 3 with the IP address of the CDN server with the next lowest delivery cost.

[0199] As shown in FIG. 196, in the OTA center 2, the distribution server 7 includes a CDN vendor management DB, a CDN vendor selection unit 7a, a data storage unit 7b, a campaign notification generation unit 7c, a CDN distribution unit 7d, a DNS setting unit 7e, and a performance measurement unit 7f. The DNS server 12 includes a CDN server confirmation unit 12a. A test file for measuring the performance of the CDN server is placed in the storage area of ​​the CDN distribution unit 7d. The performance measurement unit 7f transmits a distribution request for the test file to the CDN server, causes the CDN server to distribute the test file, and measures the time required for the distribution of the test file as the distribution time. The distribution time is, for example, the time from the time when the distribution of the test file is started to the time when the completion of reception of the test file is identified.

[0200] The CDN vendor management DB includes a CDN server selection table as shown in Fig. 197. The selection table includes the cost ranking determined by the CDN vendor selection unit 7a and the delivery flag determined by the performance measurement unit 7f.

[0201] The performance measurement unit 7f calculates the response speed for each CDN server from the time required to deliver the test file, and inputs the judgment result based on the calculated response speed into the selection table. If the response speed is equal to or greater than a specified value, the performance measurement unit 7f sets the delivery flag of the CDN server to ON (TRUE), and if the response speed is less than the specified value, the performance measurement unit 7f sets the delivery flag of the CDN server to OFF (FALSE).

[0202] When the CDN server confirmation unit 12a receives an inquiry for an IP address corresponding to a URL from the vehicle-side system 3, it determines whether the CDN server specified by the URL is in a state where delivery is possible, and if it determines that delivery is impossible, it responds with the IP address of another CDN server.

[0203] Next, the operation of the above-mentioned configuration will be described with reference to FIGS. (19-4) Processing of CDN vendor selection unit 7a (see Figures 198 to 199) In the first CDN selection process, the CDN vendor selection unit 7a calculates the charge amount for each CDN vendor (A1921 to A1929) and then determines the cost ranking of the CDN vendors (A1951). That is, the CDN vendor selection unit 7a determines the ranking of the CDN vendor with the lowest delivery cost as the first ranking, and determines the ranking of the CDN vendor with the next lowest delivery cost as the second ranking. The CDN vendor selection unit 7a stores the selection result in the data storage unit 7b (A1914), and then stores the cost ranking in the selection table of the CDN vendor management DB (A1941).

[0204] (19-5) Processing of the performance measurement unit 7f (see FIG. 200) The performance measurement unit 7f repeats the following process for each CDN vendor (A1961 to A1966). The performance measurement unit 7f executes the following process at regular intervals while the distribution server 7 is running, or at any timing determined by the administrator of the distribution server 7.

[0205] The performance measurement unit 7f accesses the CDN server (A1962) and sends a test file distribution request to the CDN server. The performance measurement unit 7f calculates a response speed based on the time required to distribute the test file, and determines whether the calculated response speed is equal to or greater than a specified value (A1963). Note that the time required for distribution may be compared with the specified value without calculating the response speed, or the distribution data size per unit time may be compared with the specified value.

[0206] If the performance measurement unit 7f determines that the response speed is equal to or higher than a specified value (A1963: YES), it determines that the CDN server is available for distribution and sets the distribution flag to ON (A1964).If the performance measurement unit 7f determines that the calculated response speed is lower than a specified value (A1963: NO), it determines that the CDN server is unavailable for distribution and sets the distribution flag to OFF (A1965).

[0207] (19-6) Processing of the CDN server confirmation unit 12a (see FIG. 201) The campaign notification includes a URL to be accessed in order to download the update data. The vehicle-side system 3 queries the DNS server 12 about the IP address to be accessed in order to download the update package.

[0208] The CDN server confirmation unit 12a acquires an inquiry for an IP address for the URL indicated in the campaign notification from the vehicle-side system 3 (A1971). The CDN server confirmation unit 12a inquires about the distribution status of the CDN server indicated in the campaign notification from the CDN vendor management DB of the distribution server 7 (A1972). In this case, the CDN server corresponds to the CDN vendor from which data is to be acquired, and the distribution status corresponds to the distribution flag. When the CDN server confirmation unit 12a acquires the distribution flag of the CDN vendor from which data is to be acquired from the distribution server, it determines whether the CDN vendor from which data is to be acquired is available or not (A1973). That is, the CDN server confirmation unit 12a determines whether the acquired distribution flag is on or off.

[0209] When the CDN server confirmation unit 12a determines that the distribution flag is on (A1973: YES), it returns an IP address corresponding to that CDN vendor to the vehicle-side system 3, or transfers the connection with the vehicle-side system 3 to that IP address and switches to the CDN vendor corresponding to the URL of the campaign notification (A1974).When the CDN server confirmation unit 12a determines that the distribution flag is off (A1973: NO), it sets the CDN vendor with the next highest cost ranking as the CDN vendor with the next priority, sets the CDN vendor with the next priority as the CDN vendor from which data is to be acquired (A1975), and returns to step A1973.

[0210] According to this configuration, it is possible to select a CDN server that is operating normally while minimizing the delivery cost. The CDN server confirmation unit 12a may access the CDN vendor management DB and request the transmission of a selection table every time a certain period of time has elapsed. In this case, when an IP address inquiry is received from the vehicle-side system 3, instead of accessing the CDN vendor management DB, the CDN server confirmation unit 12a may refer to the selection table held by the CDN server confirmation unit 12a to determine whether the CDN vendor from which data is to be acquired is available. In addition to selecting a CDN server that is operating normally while minimizing the delivery cost, it is possible to reduce communication between the DNS server 12 and the delivery server 7.

[0211] (Third modified example of the 19th embodiment) A third modified example of the nineteenth embodiment will be described with reference to Fig. 202 to Fig. 205. In the third modified example, in the distribution server 7, the performance measurement unit 7f measures and evaluates the performance of the CDN server based on the log information from the vehicle-side system 3. Note that the operation when the DNS server 12 receives a query about an IP address for a URL from the vehicle-side system 3 is the same as in the second modified example. In the third modified example, as in the second modified example, the CDN vendor management DB includes a selection table.

[0212] The vehicle-side system 3 includes a log transmission unit 3a. When the log transmission unit 3a finishes downloading update data from the CDN server, the log transmission unit 3a transmits log information related to the download, including a download time indicating the time required for the download, to the performance measurement unit 7f of the distribution server 7. In addition to the download time, the log information related to the download may also include information such as identification information of the downloaded package, the data size, and the maximum throughput during the download.

[0213] When the performance measurement unit 7f receives log information related to downloads from the log transmission unit 3a, it calculates the throughput from the download time and inputs the judgment result based on the calculated throughput into the selection table. If the throughput is equal to or greater than a specified value, the performance measurement unit 7f sets the delivery flag of the CDN server to ON (TRUE), and if the throughput is less than the specified value, it sets the delivery flag of the CDN server to OFF (FALSE).

[0214] Next, the operation of the above-mentioned configuration will be described with reference to FIGS. (19-8) Processing of the log transmission unit 3a (see FIG. 203) When the log transmission unit 3a finishes downloading the update package from the CDN server (A1981), it transmits log information relating to the download, including the download time indicating the time required for the download, to the distribution server 7 (A1982).

[0215] (19-9) Processing of the performance judgment unit 7f (see FIG. 204) When the performance judging section 7f receives log information relating to downloading from the log transmitting section 3a (A1991), it calculates the throughput from the download time (A1992) and judges whether the calculated throughput is equal to or greater than a specified value (A1993).

[0216] If the performance measurement unit 7f determines that the calculated throughput is equal to or greater than a specified value (A1993: YES), it determines that the CDN server is available for distribution and sets the distribution flag to ON (A1994).If the performance measurement unit 7f determines that the calculated throughput is less than a specified value (A1993: NO), it determines that the CDN server is unavailable for distribution and sets the distribution flag to OFF (A1995).

[0217] (19-10) Processing of the performance judgment unit 7f (see FIG. 205) The performance determination unit 7f periodically performs a restoration process for the CDN servers whose distribution flags have been set to off. The performance measurement unit 7f notifies the CDN vendor management DB of an information request for the CDN servers whose distribution flags have been set to off, identifies the CDN servers whose distribution flags have been set to off (A19101), and repeats the following process for each CDN vendor (A19102 to A19107). While the distribution server 7 is running, the performance measurement unit 7f executes the following process at regular intervals or at any timing determined by the administrator of the distribution server 7.

[0218] The performance measuring unit 7f notifies the CDN server of the delivery request for the test file, calculates the throughput from the download time of the file delivered from the CDN server (A19103), and determines whether the calculated throughput is above a specified value (A19104).

[0219] If the performance measurement unit 7f determines that the calculated throughput is equal to or greater than a specified value (A19104: YES), it changes the delivery flag from OFF to ON (A19105). If the performance measurement unit 7f determines that the calculated throughput is less than a specified value (A19104: NO), it maintains the delivery flag OFF (A19106). Note that the performance measurement unit 7f may turn ON the delivery flag that is set to OFF in the CDN vendor management DB when the delivery server system is started or at regular intervals.

[0220] According to this configuration, unlike the second modified example in which a test file distribution request is sent to the CDN server to identify the response of the CDN server, it is not necessary to send a test file distribution request to the CDN server, and it is possible to reduce the load and costs on the communication network. Note that by providing the vehicle-side system 3 with a function for measuring the download speed of the update package, if it is determined that the throughput is less than a specified value, the connection may be changed to another CDN server.

[0221] In addition to the URL of the CDN server to be connected first, the campaign notification distributed from the distribution server 7 may also include the URL of a backup CDN server to be connected when the throughput of the CDN server is low. The backup CDN server may be, for example, the CDN server with the next lowest delivery cost or a backup CDN server determined in advance. When multiple CDN servers are specified as backup CDN servers, information indicating the connection order may be added.

[0222] When the download of the update package starts, the vehicle-side system 3 measures the throughput and checks whether the throughput is equal to or exceeds a specified value. If the vehicle-side and both-side systems 3 determine that the throughput is not equal to or exceeds the specified value, they inquire of the DNS server 12 about the IP address of the backup CDN server URL shown in the campaign notice, and change the connection from the original CDN server to the new CDN server. Since identification information is added to each packet of the distributed data, the update package can be downloaded continuously even if the CDN server is changed during the download of the update package.

[0223] (Fourth modified example of the nineteenth embodiment) A fourth modified example of the nineteenth embodiment will be described with reference to Fig. 206 and Fig. 207. In the fourth modified example, a CDN vendor selection unit 7a selects multiple CDN vendors, and a campaign notification generation unit 7c generates multiple campaign notifications for each CDN vendor. When distributing the campaign notifications to the vehicle-side system 3, a round robin method is adopted to specify different CDN servers.

[0224] (19-11) Processing of the Campaign Notification Generator 7c (see FIG. 206) When the campaign notification generation unit 7c acquires the CDN vendor information (A195), it generates a campaign notification for each CDN vendor (A19111). That is, the campaign notification generation unit 7c generates two or more campaign notifications for one campaign. The campaign notification generation unit 7c distributes the campaign notification so that the CDN server changes in a round robin manner (A19112). For example, if two CDN servers, CDN11 and CDN12, are selected, the campaign notification generation unit 7c distributes a campaign notification including the URL of CDN11 to the first vehicle, distributes a campaign notification including the URL of CDN12 to the next vehicle, and distributes a campaign notification including the URL of CDN11 to the next vehicle.

[0225] (19-12) Processing of CDN vendor selection unit 7a (see FIG. 207) In the 19th embodiment, the CDN vendor selection unit 7a selects a CDN vendor with the lowest delivery cost, but in the fourth modified example, it selects multiple CDN vendors in order of lowest delivery cost (A19121).

[0226] With this configuration, it is possible to reduce the delivery costs from the CDN server while preventing access from concentrating on a specific CDN server, and by preventing access concentration, it is possible to prevent a decrease in throughput.

[0227] (Fifth modified example of the nineteenth embodiment) A fifth modified example of the nineteenth embodiment will be described with reference to Figs. 208 to 211. In the fourth modified example, multiple CDN vendors that reduce distribution costs are selected, multiple campaign notifications with different CDN server information are generated, and the campaign notifications are distributed to the vehicle-side system 3 so that the CDN server is changed in a round-robin manner. In contrast, in the fifth modified example, multiple CDN vendors that reduce distribution costs are selected, one campaign notification is generated, and distributed to the vehicle-side system 3. When the DNS server 12 acquires an inquiry for an IP address corresponding to a URL indicated in the campaign notification from the vehicle-side system 3, the CDN server that responds to the vehicle-side system 3 is changed for each vehicle-side system 3. In other words, the DNS server 12 selects a CDN server in a round-robin manner.

[0228] As shown in Fig. 208, the DNS server 12 includes a switching unit 12b. When the switching unit 12b receives an IP address query from the vehicle-side system 3, the switching unit 12b sequentially changes the IP address to be sent to the vehicle-side system 3 in a round robin manner. The distribution server includes a DNS setting unit 7e. The DNS setting unit 7e of the fifth modified example transmits a round robin record shown in Fig. 209 to the DNS server 12.

[0229] (19-13) Processing of CDN vendor selection unit 7a (see FIG. 210) The CDN vendor selection unit 7a selects a plurality of CDN vendors in the order of lowest delivery cost (A19121) as in the fourth modified example, and sets a round robin record (A19131).

[0230] (19-14) Processing of the switching unit 12b (see FIG. 211) When the DNS server 12 receives an IP address query from the vehicle-side system 3 (A19141), it refers to the round robin record (A19142) and transmits the IP address corresponding to the CDN server listed therein to the vehicle-side system 3 (A19143). The DNS server 12 repeats the above process each time it receives an IP address query from the vehicle-side system 3, and when it receives an IP address query from another vehicle-side system 3, it refers to the round robin record and transmits an IP address corresponding to a CDN server different from the previous time to the vehicle-side system 3. That is, the DNS server 12 transmits the IP addresses of the CDN servers in order to the vehicle-side system 3 according to the round robin method.

[0231] With this configuration, it is possible to reduce the delivery costs from the CDN server while preventing access from concentrating on a specific CDN server, and by preventing access concentration, it is possible to prevent a decrease in throughput.

[0232] (Twentieth embodiment) The twentieth embodiment will be described with reference to Figures 212 to 224. In the twentieth embodiment, when information on multiple campaigns during a specified period can be obtained, multiple CDN vendors are dynamically selected as destinations for distributing update packages in CDN 8 according to the distribution method, the OTA target area as the distribution area, and the distribution data size, thereby suppressing distribution costs. The specified period is, for example, the next month.

[0233] In the 19th embodiment described above, a CDN vendor with the lowest delivery cost is selected for one campaign. However, it is also assumed that a plurality of campaigns scheduled to start delivery during a predetermined period, for example, the next month, are registered from the OEM server. In this way, when information on the data size, number of vehicles to be delivered, OTA target area, and delivery method of each campaign is acquired in advance for a plurality of campaigns, a CDN vendor different from the case where a CDN vendor is selected for each campaign as in the 19th embodiment may be the CDN vendor with the lowest delivery cost.

[0234] As shown in FIG. 212, the OTA center 2 includes a CDN vendor management DB, a CDN vendor selection unit 7a, a data storage unit 7b, a campaign notification generation unit 7c, a CDN distribution unit 7d, and a progress information management unit 7g. The progress information management unit 7g holds a predicted value indicating how much of the campaign will be distributed to the vehicle-side system 3 within a predetermined period. Even if the campaign is registered in the OTA center 2 and a campaign notification is distributed to the vehicle-side system 3, it is not necessarily the case that all vehicles immediately apply the campaign and download the update package from the CDN server. The progress information management unit 7g stores the predicted value in order to more accurately predict the distribution data size of the update package from the CDN server to the vehicle-side system 3. In this embodiment, the predetermined period is described as one month, but other periods may be used.

[0235] The calculation method in the twentieth embodiment will be described with reference to FIG. 213. In the twentieth embodiment, the CDN vendor's billing amount is calculated using three calculation methods, as described later. In the first calculation method, a CDN vendor with the smallest delivery cost is selected for each campaign. In this case, a different CDN vendor may be selected for each campaign. FIG. 213 illustrates an example in which CDN1 is selected for campaign 1, CDN2 is selected for campaign 2, and CDN3 is selected for campaign 3.

[0236] In the second calculation method, the total distribution data size of all campaigns is calculated, and a CDN vendor with the lowest distribution cost is selected based on the calculated total distribution data size of all campaigns. In this case, the same CDN vendor is selected for all campaigns. FIG. 213 illustrates an example in which CDN1 is selected for campaigns 1 to 3. In the third calculation method, the total distribution data size of campaigns by distribution method is calculated, and a CDN vendor with the lowest distribution cost is selected based on the calculated total distribution data size of campaigns by distribution method. For each distribution method, a CDN vendor is selected for each of the streaming method and the storage method. FIG. 213 illustrates an example in which the distribution methods are different between campaign 1 and campaigns 2 and 3, and CDN1 is selected for campaign 1, and CDN2 is selected for campaigns 2 and 3.

[0237] Next, the operation of the above-mentioned configuration will be described with reference to FIGS. (20-1) Processing of the Campaign Notification Generator 7c (see FIG. 214) The campaign notification generating unit 7c acquires campaign information to be distributed from an external source, such as an OEM server, from the OEM server (A201). The campaign information to be distributed includes information on the distribution start date, the data size of the target campaign, the number of vehicles to which the target campaign is distributed, the region, and the distribution method. The campaign notification generating unit 7c stores the acquired campaign information in the data storage unit 7b (A202).

[0238] The campaign notification generating unit 7c notifies the CDN vendor selection unit 7a of a CDN vendor selection request (A203) and waits for a selection notification from the CDN vendor selecting unit 7a. When the campaign notification generating unit 7c receives the selection notification from the CDN vendor selecting unit 7a (A204), it accesses the data storage unit 7b and acquires identification information of the CDN vendor selected by the CDN vendor selecting unit 7a (A205).

[0239] The campaign notification generating unit 7c generates a parameter file including the URL of the selected CDN based on the identification information of the CDN vendor as a campaign notification to be distributed (A206). The campaign notification generating unit 7c distributes the generated campaign notification to be distributed to the vehicle-side system 3 (A207).

[0240] (20-2) Processing of CDN vendor selection unit 7a (see Figures 215 to 221) When the CDN vendor selection unit 7a receives a CDN vendor selection request notified from the campaign notification generation unit 7 (A2011), it accesses the data storage unit 7b, Selection information is acquired (A2012). In this case, the selection information includes the data size of all target campaigns to be distributed, the number of target vehicles, region, distribution method, and distribution start date of each campaign.

[0241] The CDN vendor selection unit 7a acquires a delivery prediction value from the progress information management unit 7g (A2013). The CDN vendor selection unit 7a calculates a delivery data size for each campaign (A2014). Specifically, the CDN vendor selection unit 7a multiplies the data size of the campaign, the number of vehicles to which the campaign is to be delivered, and the delivery prediction value, and further multiplies the multiplication value by a correction value according to the delivery period. Depending on the campaign, the delivery period may be short, such as when the delivery start date is set to the end of next month, so adjustment is made using a correction value according to the delivery period. For example, if the delivery start date is delayed and the delivery period is only 10 days, the correction value is set to 0.3, etc., since 10 days out of 30 days are available for delivery.

[0242] The CDN vendor selection unit 7a transitions to a second CDN selection process (A2015). When the CDN vendor selection unit 7a starts the second CDN selection process, the process sequentially transitions to a calculation process of a charge amount using the first calculation method, a calculation process of a charge amount using the second calculation method, and a calculation process of a charge amount using the third calculation method (A2021 to A2023).

[0243] In the process of calculating the charge amount using the first calculation method, the CDN vendor selection unit 7a selects a CDN vendor with the smallest delivery cost for each campaign. When the CDN vendor selection unit 7a starts the process of calculating the charge amount using the first calculation method, it repeats the subsequent processes for each campaign (A2031 to A2041), and further repeats the processes for each CDN vendor (A2032 to A2039). The CDN vendor selection unit 7a acquires fee information from the CDN vendor management DB based on the delivery data size and region information (A2033). The CDN vendor selection unit 7a refers to the fee information based on the delivery data size, and calculates the delivery charge amount (A2034).

[0244] As in the 19th embodiment, the CDN vendor selection unit 7a determines whether the CDN vendor under consideration is a CDN vendor that charges according to the number of requests, and determines the charge amount of the CDN vendor (A2035 to A2038). The CDN vendor selection unit 7a repeats the calculation of the delivery charge amount for each CDN vendor and each campaign. After the CDN vendor selection unit 7a calculates the charge amounts of all CDN vendors for one campaign, it selects the CDN vendor with the smallest delivery cost for that campaign (A2040).

[0245] When the CDN vendor selection unit 7a has completed calculation of the delivery charge amount and selection of the CDN vendor for all campaigns, it adds up the delivery charge amounts for all campaigns to calculate the total amount (A2042), terminates the process of calculating the charge amount using the first calculation method, and moves on to the process of calculating the charge amount using the second calculation method.

[0246] In the process of calculating the charge amount using the second calculation method, the CDN vendor selection unit 7a selects one CDN vendor based on the total distribution data size of all campaigns to be distributed. When the CDN vendor selection unit 7a starts the process of calculating the charge amount using the second calculation method, it sums up the distribution data sizes of each campaign to calculate the total distribution data size (A2051), and repeats the subsequent process for each CDN vendor (A2052 to A2059). The CDN vendor selection unit 7a acquires fee information from the CDN vendor management DB based on the total distribution data size and region information (A2053). The CDN vendor selection unit 7a refers to the fee information based on the total distribution data size and calculates the distribution charge amount (A2054).

[0247] As in the 19th embodiment, the CDN vendor selection unit 7a determines whether the CDN vendor under consideration is a CDN vendor that charges according to the number of requests, and determines the charge amount for the CDN vendor (A2055 to A2058). The CDN vendor selection unit 7a repeats the calculation of the distribution charge amount for each CDN vendor. The CDN vendor selection unit 7a selects the CDN vendor with the smallest distribution cost (A2060). The distribution charge amounts for all campaigns scheduled for distribution are added up to calculate the total amount (A2061), the process of calculating the charge amount using the second calculation method is terminated, and the process of calculating the charge amount using the third calculation method is started.

[0248] In the process of calculating the charge amount using the third calculation method, the CDN vendor selection unit 7a selects a CDN vendor after grouping campaigns by delivery method. When the CDN vendor selection unit 7a starts the process of calculating the charge amount using the third calculation method, it determines whether the delivery methods of the campaigns to be distributed are all the same (A2071). If the CDN vendor selection unit 7a determines that the delivery methods of the campaigns to be distributed are all the same, that is, that all the campaigns to be distributed are streaming method or all storage method (A2071: YES), the process is the same as the process of calculating the charge amount using the second calculation method described above, and therefore ends the process of calculating the charge amount using the third calculation method.

[0249] When the CDN vendor selection unit 7a determines that the distribution methods of the campaigns to be distributed are not all the same, i.e., that the campaigns to be distributed include a mixture of streaming and storage methods (A2071: NO), it groups the campaigns according to the distribution method (A2072), and transitions to billing calculation processing for the streaming method for the streaming method group (A2073), and transitions to billing calculation processing for the storage method for the storage method group (A2074).

[0250] When the CDN vendor selection unit 7a starts the billing calculation process for streaming, it calculates the total value of the distribution data size of each campaign distributed by streaming (A2081), and repeats the subsequent process for each CDN vendor (A2082 to A2089). The CDN vendor selection unit 7a acquires fee information from the CDN vendor management DB based on the total value of the distribution data size and region information (A2083). The CDN vendor selection unit 7a refers to the fee information based on the total value of the distribution data size, and calculates the distribution billing amount (A2084).

[0251] As in the 19th embodiment, the CDN vendor selection unit 7a determines whether the CDN vendor under consideration is a CDN vendor that charges according to the number of requests, and determines the charge amount for the CDN vendor (A2085 to A2088). The CDN vendor selection unit 7a repeats the calculation of the delivery charge amount for each CDN vendor. The CDN vendor selection unit 7a selects the CDN vendor that minimizes the delivery cost in the streaming method (A2090), and ends the charge amount calculation process in the streaming method.

[0252] On the other hand, when the CDN vendor selection unit 7a starts the charge calculation process for the storage method, it calculates the total value of the distribution data size of each campaign distributed by the storage method (A2091), and repeats the subsequent process for each CDN vendor (A2092 to A2099). The CDN vendor selection unit 7a acquires fee information from the CDN vendor management DB based on the total value of the distribution data size and region information (A2093). The CDN vendor selection unit 7a refers to the fee information based on the total value of the distribution data size, and calculates the distribution charge (A2094).

[0253] As in the 19th embodiment, the CDN vendor selection unit 7a determines whether the CDN vendor under consideration is a CDN vendor that charges according to the number of requests, and determines the charge amount for the CDN vendor (A2095 to A2098). The CDN vendor selection unit 7a repeats the calculation of the delivery charge amount for each CDN vendor. The CDN vendor selection unit 7a selects the CDN vendor with the smallest delivery cost in the storage method (A20100), and ends the charge amount calculation process in the storage method.

[0254] When the CDN vendor selection unit 7a completes the calculation process of the charge amount using the first calculation method, the calculation process of the charge amount using the second calculation method, and the calculation process of the charge amount using the third calculation method, it determines the calculation method that minimizes the delivery cost (A2024), selects a CDN vendor for each campaign (A2025), and ends the second CDN selection process. When the CDN vendor selection unit 7a completes the second CDN selection process, it stores the selection result, i.e., identification information identifying the selected CDN vendor, in the data storage unit 7b (A2016). Here, the CDN vendor selection unit 7a stores identification information identifying the CDN vendor of the campaign to be delivered in the data storage unit 7b. The CDN vendor selection unit 7a notifies the campaign notification generation unit 7c of the selection notification (A2017).

[0255] (20-3) Processing of the progress information management unit 7g (see FIG. 222) The progress information management unit 7g stores a predicted value indicating how much of the campaign will be distributed to the vehicle-side system 3 in a predetermined period. This predicted value is expected to be updated according to the actual distribution status transmitted from the OEM server.

[0256] The progress information management unit 7g acquires a distribution status from the OEM server (A20111). The progress information management unit 7g judges whether the difference between the distribution status and the stored predicted value is equal to or greater than a predetermined value (A20112). If the progress information management unit 7g judges that the difference between the distribution status and the stored predicted value is not equal to or greater than the predetermined value (A20112: NO), the process ends.

[0257] When the progress information management unit 7g determines that the difference between the delivery status and the stored predicted value is equal to or greater than a predetermined value (A20112: YES), it updates the stored predicted value (A20113) and notifies the CDN vendor selection unit 7a of the updated predicted value (A20114). The progress information management unit 7g may have one predicted value common to all campaigns, or may have different predicted values ​​for each campaign, each vehicle to be updated, or each type of campaign.

[0258] (20-4) Processing of CDN vendor selection unit 7a (see FIG. 223) When the CDN vendor selection unit 7a receives an update of the predicted value notified from the progress information management unit 7g (A20121), it receives selection information (A20122), receives a delivery predicted value from the progress information management unit 7g (A20123), and calculates the delivery data size for each campaign (A20124). In this case, the CDN vendor selection unit 7a uses a correction value that takes into account the number of delivery days when calculating the delivery data size.

[0259] The CDN vendor selection unit 7a proceeds to the second CDN selection process (A20125), and when the second CDN selection process is terminated, it determines whether or not there has been a change in the CDN vendor (A20126). When the CDN vendor selection unit 7a determines that there has been no change in the CDN vendor (A20126: NO), it terminates the process. When there has been a change in the CDN vendor, it updates the selection result in the data storage unit 7b. When the CDN vendor selection unit 7a determines that there has been a change in the CDN vendor (A20126: YES), it updates the selection result (A20127) and sends a CDN change notification to the campaign notification generation unit 7c (A20128). The CDN vendor selection unit 7a may check at a predetermined interval whether or not the predicted value stored in the progress information management unit 7g has been changed.

[0260] (20-5) Processing of the Campaign Notification Generator 7c (see FIG. 224) When the campaign notification generation unit 7c receives a CDN change notification from the CDN vendor selection unit 7a (A20131), it accesses the data storage unit 7b to obtain the updated CDN vendor information (A20132), and regenerates the campaign notification to be distributed based on the obtained updated CDN vendor information (A20133).

[0261] As described above, according to the twentieth embodiment, the following advantageous effects can be obtained. The CDN vendor management database is referenced, and from among multiple CDNs 8 with different delivery costs, a CDN 8 with an advantageous delivery cost is selected according to the delivery method, OTA target area, and delivery data size, and the update package is placed in the selected CDN 8. This makes it possible to appropriately suppress the delivery cost when the OTA master 4 downloads the update package from the OTA center 2.

[0262] (Other embodiments) In the above-described embodiments, the embodiments that are not specified as being the streaming method or the storage method can be applied to either the streaming method or the storage method.

[0263] In some of the above-described embodiments, it is described that the campaign notification is transmitted from the OTA center 2 to the OTA master 4 after the TLS communication is established. However, in all the embodiments, the campaign notification may be transmitted from the OTA center 2 to the OTA master 4 after the TLS communication is established. By establishing the TLS communication, it is possible to further improve security. Alternatively, the campaign notification may be transmitted from the OTA center 2 to the OTA master 4 without establishing the TLS communication.

[0264] The vehicle-side system 3 of this embodiment may have the following configuration. The vehicle-side system 3 may have a configuration including a DCM (Data Communication Module) and a CGW (Central Gateway), and the DCM and the CGW are connected to each other via a bus so as to be able to communicate data with each other. The CGW is also called a central ECU. The bus may be, for example, an Ethernet or a CAN (registered trademark) bus.

[0265] A part or the whole of the functions of the OTA master 4 may be realized in the CGW. As an example, the DCM may perform data communication with the outside, such as the CDN 8 or the OTA center 2, and all of the functions of the OTA master 4 may be implemented in the CGW. In this case, the DCM transfers all data received by wireless communication with the outside to the CGW. Alternatively, in addition to performing data communication with the outside, the DCM may function as a downloader for the OTA master 4. The functions of the downloader include, for example, generating vehicle configuration information, verifying metadata, verifying packages, and verifying campaign information. Alternatively, the functions of the OTA master 4 may be realized in the DCM. In this case, functions other than those of the OTA master 4 are implemented in the CGW. Alternatively, the DCM and the CGW may be integrated.

[0266] The CGW may have a part or all of the functions of the DCM, or the DCM may have a part or all of the functions of the CGW. In other words, the division of functions between the DCM and the CGW may be configured in any way in the OTA master 4. The OTA master 4 may be configured with two ECUs, the DCM and the CGW, or may be configured with one integrated ECU having the functions of the DCM and the CGW.

[0267] Although the present disclosure has been described based on the embodiment, it is understood that the present disclosure is not limited to the embodiment or structure. The present disclosure also encompasses various modifications and modifications within the equivalent range. In addition, various combinations and forms, as well as other combinations and forms including only one element, more than one element, or less than one element, are also within the scope and concept of the present disclosure.

[0268] The means and functions provided by each device, etc. can be provided by software recorded in a physical memory device and a computer that executes the software, software alone, hardware alone, or a combination of these. For example, when the control unit is provided by an electronic circuit that is hardware, it can be provided by a digital circuit including a large number of logic circuits, or an analog circuit.

[0269] The control unit and the method described in the present disclosure may be realized by a special-purpose computer provided by configuring a processor and a memory programmed to execute one or more functions embodied in a computer program. Alternatively, the control unit and the method described in the present disclosure may be realized by a special-purpose computer provided by configuring a processor with one or more dedicated hardware logic circuits. Also, the control unit and the method described in the present disclosure may be realized by one or more special-purpose computers configured by a combination of a processor and a memory programmed to execute one or more functions and a processor configured with one or more hardware logic circuits. Also, the computer program may be stored in a computer-readable non-transitory tangible recording medium as instructions executed by the computer.

Claims

1. A data communication system comprising: a center device (2) that places update data in a content delivery network (CDN); and a master device (4) that installs the update data downloaded from the CDN in an electronic control device to be reprogrammed, the center device is connected to CDNs of multiple carriers, and selects a CDN having a superior delivery cost from among the CDNs of the multiple carriers based on at least one of a delivery method, a delivery area, a communication protocol, and a delivery data size, and places the update data in the selected CDN without encrypting the update data; A data communication system in which the master device establishes Transport Layer Security (TLS) with the CDN and then downloads the update data from the CDN.

2. A center device (2) that places update data on a content delivery network (CDN), a common key generating unit (2a) for generating a common key for encrypting update data; an update data encryption unit (2b) for encrypting the update data with the common key; a common key encryption unit (2c) for encrypting the common key with an RSA public key; a common key storage unit (2d) for storing the common key encrypted by the RSA public key in a campaign notification; a CDN vendor selection unit (2j) for selecting a CDN having an advantageous delivery cost from among CDNs of a plurality of providers based on at least one of a delivery method, a delivery area, a communication protocol, and a delivery data size; an encrypted data placement unit (2e) that places the update data encrypted by the common key in the selected CDN; a campaign notification transmission unit (2f) for transmitting a campaign notification in which the encrypted common key is stored to a vehicle-side system to be reprogrammed; The CDN vendor selection unit is a center device that calculates a distribution cost for each CDN vendor based on the distribution data size and distribution area of ​​the update data, determines whether the CDN vendor charges according to the number of distribution requests, and for CDN vendors that charge according to the number of distribution requests, calculates a charge based on the number of requests, adds up the charge based on the distribution data size and the charge based on the number of requests, and selects the CDN with the advantageous distribution cost.

3. A center device (2) that places update data on a content delivery network (CDN), a common key generating unit (2a) for generating a common key for encrypting update data; an update data encryption unit (2b) for encrypting the update data with the common key; a common key encryption unit (2c) for encrypting the common key with an RSA public key; a common key storage unit (2d) for storing the common key encrypted by the RSA public key in a campaign notification; a CDN vendor selection unit (2j) for selecting a CDN having an advantageous delivery cost from among CDNs of a plurality of providers based on at least one of a delivery method, a delivery area, a communication protocol, and a delivery data size; an encrypted data placement unit (2e) that places the update data encrypted by the common key in the selected CDN; a campaign notification transmission unit (2f) for transmitting a campaign notification in which the encrypted common key is stored to a vehicle-side system to be reprogrammed; The CDN vendor selection unit is a center device that selects a CDN with an advantageous delivery cost from among CDNs of multiple operators based on the delivery data size and delivery area of ​​update data for multiple campaigns scheduled for delivery during a predetermined period.

4. A progress information management unit (7g) for storing a predicted value based on a distribution status of update data distributed from a CDN, 4. The center device according to claim 3, wherein the CDN vendor selection unit calculates the distribution data size taking into account a predicted value.

5. A center device (2) that places update data on a content delivery network (CDN), a common key generation step for generating a common key for encrypting the update data; an update data encryption step of encrypting the update data with the common key; a common key encryption step of encrypting the common key with an RSA public key; a common key storage step of storing the common key encrypted by the RSA public key in a campaign notice; a CDN vendor selection step for selecting a CDN having an advantageous delivery cost from among CDNs of multiple providers based on at least one of a delivery method, a delivery area, a communication protocol, and a delivery data size; an encrypted data placement step of placing the update data encrypted by the common key on the selected CDN; a campaign notification transmission step of transmitting a campaign notification in which the encrypted common key is stored to a vehicle-side system to be reprogrammed; The CDN vendor selection procedure is an update data placement program that calculates a distribution cost for each CDN vendor based on the distribution data size and distribution area of ​​the update data, determines whether the CDN vendor charges according to the number of distribution requests, and for CDN vendors that charge according to the number of distribution requests, calculates a charge based on the number of requests, adds up the charge based on the distribution data size and the charge based on the number of requests to select the CDN with the advantageous distribution cost.

6. A center device (2) that places update data on a content delivery network (CDN), a common key generation step for generating a common key for encrypting the update data; an update data encryption step of encrypting the update data with the common key; a common key encryption step of encrypting the common key with an RSA public key; a common key storage step of storing the common key encrypted by the RSA public key in a campaign notice; a CDN vendor selection step for selecting a CDN having an advantageous delivery cost from among CDNs of multiple providers based on at least one of a delivery method, a delivery area, a communication protocol, and a delivery data size; an encrypted data placement step of placing the update data encrypted by the common key on the selected CDN; a campaign notification transmission step of transmitting a campaign notification in which the encrypted common key is stored to a vehicle-side system to be reprogrammed; The CDN vendor selection procedure is an update data placement program that selects a CDN with the most advantageous delivery costs from among CDNs of multiple operators based on the delivery data size and delivery area of ​​update data for multiple campaigns scheduled to be delivered during a specified period.

Images