In-vehicle communication system, center device, vehicle-side system, and method for verifying update data of in-vehicle communication

Abstract

To provide an on-vehicle communication system which can verify integrity also for update data to be transmitted by a streaming system from a center device.SOLUTION: In an on-vehicle communication system 1, an OTA center 2 also transmits a hash value calculated for update data to an OTA master 21 when the update data is transmitted to the OTA master 21 on a vehicle side by a streaming system. The OTA master 21 receives the update data, and after that, transfers the update data to a target ECU 22. The target ECU 22 calculates the hash value for the update data, and after that, transmits the hash value to the OTA master 21, and the OTA master 21 compares the hash value transmitted from the OTA center 2 with the hash value transmitted from the target ECU 22 to verify integrity of the update data.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to an in-vehicle communication system including a center device that transmits a distribution package including update data to be written to an electronic control device mounted on a vehicle in a streaming manner, and a master device that receives the distribution package and transfers the update data to the electronic control device, a center device and a vehicle-side system used in the system, and an update data verification method for in-vehicle communication.

Background Art

[0002] In recent years, with the diversification of vehicle control such as driving support functions and autonomous driving functions, the scale of application programs such as vehicle control and diagnosis mounted on an electronic control device (hereinafter referred to as an ECU (Electronic Control Unit)) of a vehicle has been increasing. In addition, with version upgrades due to function improvements and the like, the opportunity to perform a so-called reprogram to rewrite the application program of the ECU is also increasing. On the other hand, with the development of communication networks and the like, the technology of connected cars has also spread. Under such circumstances, for example, Patent Document 1 discloses a technology in which a data package including an update program for an ECU is distributed to an in-vehicle device by OTA (Over The Air) from a server, and the update program is rewritten on the vehicle side.

[0003] The methods for rewriting the above update program include a storage method in which all of the update program is downloaded from the center device to the memory on the vehicle side and then updated, and a streaming method in which the update program is updated while being downloaded from the center device to the vehicle side. On the vehicle side, generally, an OTA master having a unit called DCM (Data Communication Module) or CGW (Central Gate Way) receives a distribution package including an update program from the center device, and transfers and writes the update program to a target ECU to be updated.

[0004] In the storage method, a digital signature is attached to the distribution package, and the OTA master uses the digital signature to confirm the integrity of the distribution package before writing it to the target ECU.

Prior Art Documents

Patent Documents

[0005]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0006] However, in the streaming method, the OTA master sequentially writes the received update program to the target ECU without confirming the integrity as described above. Therefore, if the program data included in the distribution package is replaced in the data transfer path from the center device to the target ECU, there is a risk that the illegal data will be written to the target ECU as it is.

[0007] The present invention has been made in view of the above circumstances, and an object thereof is to provide an in-vehicle communication system, a center device, a vehicle-side system, and an in-vehicle communication update data verification method capable of verifying the integrity of update data transmitted from the center device in a streaming method.

Means for Solving the Problems

[0008] According to the in-vehicle communication system described in claim 1, when the center device transmits update data to the master device on the vehicle side in a streaming manner as a distribution package, the hash value calculated for the update data is also transmitted to the master device. The master device transfers the update data to the electronic control device when it receives the distribution package. When the electronic control device calculates the hash value for the update data, it transmits the hash value to the master device. The master device compares the hash value transmitted from the center device with the hash value transmitted from the electronic control device to verify the integrity of the update data.

[0009] With such a configuration, even if the update data included in the distribution package transmitted from the center device to the vehicle side in a streaming manner is replaced with incomplete data due to being tampered with on the way, verification using the hash value is performed in the master device, so it is possible to prevent incomplete update data from being installed in the electronic control device. Therefore, it is possible to improve the security of the communication system.

[0010] According to the in-vehicle communication system described in claim 2, when the center device causes each of a plurality of electronic control devices to write update data, the plurality of hash values calculated for each update data are also transmitted to the master device. The master device transfers each update data to each electronic control device respectively. When each electronic control device calculates the hash value for its respective update data, it transmits the hash value to the master device. The master device compares the hash values transmitted from the plurality of electronic control devices with the corresponding hash values transmitted from the center device. Therefore, similarly, in the case of transmitting update data to each of a plurality of electronic control devices, it is possible to prevent incomplete update data from being installed in each electronic control device.

[0011] According to the in-vehicle communication system described in claim 7, when the center device transmits the distribution package to the master device on the vehicle side in the streaming method, similar to claim 1, the center device also transmits the hash value calculated for the update data to the master device. The master device calculates the hash value for each predetermined data size of the update data to obtain the hash value for the entire update data, and then compares the hash value with the hash value transmitted from the center device to verify the integrity of the update data.

[0012] That is, instead of the electronic control device in claim 1, the master device calculates the hash value for the update data and verifies the integrity. Therefore, the verification process is completed in the master device, and the same effect as in claim 1 can be obtained.

Brief Description of the Drawings

[0013]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Mode for Carrying Out the Invention

[0014] (First Embodiment) As shown in FIG. 1, the in-vehicle communication system 1 of the present embodiment includes an OTA center 2 corresponding to a center device and a vehicle-side system 3. The OTA center 2 has a PKG generation server 4, a distribution server 5, and a DB unit 100. The DB unit 100 has a software package DB 101, a digital signature DB 102, configuration information DB 103, individual vehicle information DB 104, ECU reprogramming data DB 105, and ECU metadata DB 106. Note that "database" may be abbreviated as DB, and "package" may be abbreviated as PKG.

[0015] The PKG generation server 4 includes a software package generation unit 9, a hash value collection unit 10, a hash value calculation unit 11, and a digital signature generation unit 12. The software package generation unit 9 is a functional unit that generates a software package to be distributed to a vehicle equipped with a target ECU to be updated with data. Details thereof are disclosed, for example, in FIGS. 15, 16, 19, etc. of Japanese Unexamined Patent Application Publication No. 2020-27624. Hereinafter, Japanese Unexamined Patent Application Publication No. 2020-27624 is referred to as the "reference publication". The software package includes update data of the program, rewriting specifications data, and the like. The software package including the hash value is stored in the software package DB 101.

[0016] The hash value collection unit 10 is a functional unit that collects update data to be the target for calculating the hash value from the above software package, and the hash value calculation unit 11 is a functional unit that applies a hash function to the collected data to calculate the hash value. The digital signature generation unit 12 is a functional unit that assigns the generated digital signature to the hash value connection information associating the calculated hash value with the target ID which is the ID of the target ECU. The digital signature is stored in the digital signature DB 102.

[0017] The distribution server 5 includes a distribution management unit 13, a vehicle information management unit 14, a software management unit 15, a campaign management unit 16, a configuration information management unit 17, and an individual vehicle state management unit 18. The distribution management unit 13 is a functional unit that manages the distribution of software packages and campaign information to each vehicle. The vehicle information management unit 14 registers and manages the individual vehicle information uploaded from each individual vehicle in the individual vehicle information DB 104. The update program of the target ECU is registered in the software management unit 15 by an OEM (Original Equipment Manufacturer) or the like. Campaign information, which is mainly information regarding program updates to be displayed on the vehicle side system 3, is registered in the campaign management unit 16 by an OEM or the like.

[0018] The configuration information management unit 17 manages the configuration information for each vehicle model registered in the configuration information DB 103. The configuration information is identification information regarding the hardware and software of the ECUs mounted on the vehicle, and also includes identification information of a system configuration composed of a plurality of ECUs and identification information of a vehicle configuration composed of a plurality of systems. The individual vehicle status management unit 18 manages information such as the status of program updates and versions of the target ECU in each vehicle. Note that the PKG generation server 4 and the distribution server 5 are functions realized by computer hardware and software.

[0019] The configuration information DB 103, the individual vehicle information DB 104, the ECU repro data DB 105, and the ECU metadata DB 106 of the DB unit 100 correspond to the "configuration information DB 208, individual vehicle information DB 213, ECU repro data DB 204, and ECU metadata DB 205" in the reference publication.

[0020] The vehicle-side system 3 includes an OTA master 21 corresponding to a master device and update target ECUs 22(1), 22(2), 22(3),... which are electronic control devices to be updated with programs. Hereinafter, the update target ECU 22 is referred to as the target ECU 22.

[0021] The OTA master 21 is a functional unit combining the DCM 12 and the CGW 13 shown in FIG. 1 in the reference publication, and includes a download processing unit 23, an unpacking processing unit 24, a hash value calculation unit 25, and a hash value comparison unit 26. The download processing unit 23 performs wireless communication with the OTA center 2 and downloads the data of the distribution package and the data of the digital signature. The unpacking processing unit 24 performs an unpacking process of separating the downloaded distribution package for each data section that performs each process. The hash value calculation unit 25 calculates a hash value for the data value to be calculated for the hash value, and this functional unit is used in the second embodiment. The hash value comparison unit 26 compares the hash value calculated on the target ECU 22 side, as described later, with the hash value included in the downloaded distribution package.

[0022] The target ECU 22 includes a microcomputer 27, a memory 28, and a hash value calculation unit 29. The memory 28 is, for example, a flash memory, and the update data downloaded by the OTA master 21 is transferred and installed. The hash value calculation unit 29 calculates the hash value for the update data transferred from the OTA master 21.

[0023] ≪Repro Policy Metadata≫ The repro policy metadata shown in FIG. 2 is transmitted from the OTA center 2 to the OTA master 21 prior to the download of the data. <Repro Policy Metadata Version> It is the version of the repro policy metadata, and version information such as "1.0.0" or "2.0.0" is stored.

[0024] <Delivery Layer> Information indicating the protocol used for communication with the OTA center 2, such as Uptane (registered trademark) or OMA-DM (Open Mobile Alliance - Device Management), information indicating that the communication means is the OTA master 21 such as "cellular", and information such as being a smartphone or a USB memory described later is stored.

[0025] <Master Layer> Regarding the OTA Master 21, information indicating that its platform (PF) is, for example, AP, CP, AGL (Automotive Grade Linux), Android (registered trademark), etc. is stored. Regarding the package structure for delivering update programs according to the ECU's platform, in the specifications of the General Incorporated Association JASPAR, data requirements applicable to the classic platform (CP) operating on the static OS of the standardization organization AUTOSAR are defined. Also, in AUTOSAR, data requirements applicable to the new type of adaptive platform (AP) operating on the dynamic OS are defined. AGL is in-vehicle Linux (registered trademark), and Android is Android Automotive OS.

[0026] In addition, regarding the control method, information such as "parameters" processed according to parameters set according to a specific format and "scripts" processed in a more free description format without a specific format is stored.

[0027] <Target Layer> It is information corresponding to the target ECU 22. Regarding PF, transfer method, and control method, they are the same as those described above. The target ID is the ID corresponding to the target ECU 22, but storing it here is optional.

[0028] ≪Download Metadata≫ The download metadata shown in Figure 3 is sent from the OTA Center 2 to the OTA Master 21 following the repro policy metadata.

[0029] <Delivery Layer> For example, if the communication protocol is Uptane, it is information for obtaining Uptane metadata, and the corresponding URI, data name, data size, hash value, target ID, transfer method, etc. are stored.

[0030] <Master Layer> For example, it is information for obtaining a Vehicle PKG, and each item is the same as the distribution layer. There are multiple cases of this information.

[0031] <Target layer> For example, it is information for obtaining a Software PKG, and each item is the same as the distribution layer. There are also multiple cases of this information. Note that for Vehicle PKG and Software PKG, they are described on pages 50, 52, and 53 of, for example, "Specification of Update Configuration Management AUTOSAR AP R20-11, Document ID No. 706". Refer to the relevant descriptions in this document.

[0032] Here, the differences between AP and CP will be explained. AP and CP represent software platforms. A software platform is also called a software architecture. CP represents AUTOSAR Classic Platform, and AP represents AUTOSAR Adaptive Platform. Furthermore, an ECU that operates in accordance with the CP specification may be denoted as a CP ECU or an ECU of CP, and an ECU that operates in accordance with the AP specification may be denoted as an AP ECU or an ECU of AP.

[0033] In AP and CP, the operating systems used, so-called OS, and development languages are different. The CP ECU and the AP ECU have different package reception structures. The differences in the structures of these packages are mainly due to the differences in the processing performance of the ECUs. Generally, since the processing performance of the CP ECU is low, the specification data and the like included in the package are also described in binary data, resulting in a package data structure that is easy to interpret and process even by an ECU with low processing performance.

[0034] On the other hand, since an ECU of an AP with high processing performance is used, it is possible to mount a parser function that analyzes structured character data described in some language and converts it into a data structure that can be processed by a program. The data structure does not use simple binary data, and an object-oriented data format such as JSON (JavaScript Object Notation) can be adopted, so it has a flexible package data structure.

[0035] Next, the operation of this embodiment will be described. FIG. 4 conceptually shows the operation of this embodiment. Assuming that the update data corresponding to the target ECUs 22(1) to 22(3) are A to C, the distribution server 4 of the OTA center 2 uses the hash value calculation unit 11 to apply a hash function such as SHA (Secure Hush Algorithm)-2 to each of the update data A to C to calculate hash values a to c (FIG. 5, S0). Similarly, a hash value d is calculated for the above-described download metadata D. However, the flowcharts shown in FIGS. 4 to 9 only show the processing related to the hash values a to c.

[0036] Next, when the hash value collection unit 10 collects each of the hash values a to c (FIG. 6, S1), hash value concatenation information associating these hash values a to c with the target ID is generated (S2). Then, the digital signature generation unit 12 generates and assigns a digital signature to the hash value concatenation information, that is, encrypts it with a private key (S3), and transmits and stores the digital signature in the digital signature DB 102 (S4, S5). After that, when there is a transmission request for the hash value concatenation information from the OTA master 21 (FIG. 7, S6; YES), the distribution server 5 sequentially transmits the hash value concatenation information and the distribution package to the OTA master 21 (S7, S7a).

[0037] Next, the processing on the vehicle - side system 3 side will be described. As shown in FIG. 8, when the download processing unit 23 of the OTA master 21 receives the distribution package transmitted from the distribution server 5 in a streaming manner, it transfers each of the update data A to C to each target ECU 22(1) to 22(3) (S11). Subsequently, the download processing unit 23 receives a digital signature (S12). Note that in this case, the communication protocol uses one that employs encryption such as Uptane or SSL (Secure Sockets Layer).

[0038] On the other hand, as shown in FIG. 9, when the target ECU 22 downloads the update data received from the OTA master 21 (S21), it applies a hash function to the update data to calculate a hash value (S22). Then, it transmits the calculated hash value to the OTA master 21 (S23).

[0039] The OTA master 21 verifies the received digital signature, that is, decrypts it with the public key to obtain the hash value concatenation information (S13). Then, it requests the transfer of the hash values from each target ECU 22(1) to 22(3) (S14). However, in the case where the target ECU 22 automatically transfers the hash value to the OTA master 21 in step S23, this process is unnecessary.

[0040] When receiving the hash values a' to c' from all the target ECUs 22 (S15; YES), the hash value comparison unit 26 compares the hash values a to c obtained from the hash value concatenation information with the hash values a' to c' obtained from the target ECU 22 respectively (S16). If all of them match (S17; YES), an installation instruction is issued to each target ECU 22(1) to 22(3) (S18). On the other hand, if there is any mismatch (S17; NO), a roll - back instruction is issued to the target ECU 22 where the mismatch occurred (S19). This process is optional.

[0041] When there is an installation request from the OTA master 21 (S24; YES), the target ECU 22 installs the downloaded update data (S25). Also, when there is no installation request (S24; NO) and there is a cancellation request from the OTA master 21 (S26; YES), the process ends.

[0042] Note that although the above process is for the case where there are multiple target ECUs 22, FIG. 10 shows the case where there is a single target ECU 22. Basically, it is the same as the process shown in FIG. 4 except that the hash value for the metadata E is e.

[0043] As described above, according to the present embodiment, in the in-vehicle communication system 1, when the OTA center 2 transmits the distribution package to the OTA master 21 on the vehicle side in the streaming method, the hash value calculated for the update data is also transmitted to the OTA master 21. When the OTA master 21 receives the distribution package, it transfers the update data to the target ECU 22. The target ECU 22 calculates the hash value for the update data, transmits the hash value to the OTA master 21, and the OTA master 21 compares the hash value transmitted from the OTA center 2 with the hash value transmitted from the target ECU 22 to verify the integrity of the update data.

[0044] With this configuration, even if the update data included in the distribution package transmitted from the OTA center 2 to the vehicle-side system 3 in the streaming method is replaced with incomplete data due to being tampered with on the way, verification using the hash value is performed in the OTA master 21, so it is possible to prevent incomplete update data from being installed in the target ECU 22. Therefore, it is possible to improve the security of the communication system 1.

[0045] Also, when the OTA center 2 causes the plurality of target ECUs 22(1) to 22(3) to write the update data A to C respectively, it also transmits the plurality of hash values a to c calculated for each of the update data A to C to the OTA master 21. The OTA master 21 transfers each of the update data A to C to the respective target ECUs 22(1) to 22(3). When each of the target ECUs 22(1) to 22(3) calculates hash values a' to c' for their respective update data A to C, they transmit the hash values a' to c' to the OTA master 21. The OTA master 21 compares the duplicate hash values a' to c' with the hash values a to c. Therefore, similarly, in the case of transmitting the update data A to C to the plurality of target ECUs 22(1) to 22(3) respectively, it is possible to prevent incomplete update data from being installed.

[0046] (Second Embodiment) Hereinafter, the same parts as those in the first embodiment will be denoted by the same reference numerals and the description thereof will be omitted, and the different parts will be described. As shown in FIG. 11, in the second embodiment, the PKG generation server 4 applies a hash function to the hash values a to c obtained corresponding to the update data A to C and the hash value d obtained corresponding to the metadata. Then, the obtained hash value f is referred to as a "hash chain" (FIG. 12, S8). The hash chain f corresponds to the upper hash value. Then, when a digital signature is given to the hash chain f (S9), steps S4 and S5 are executed.

[0047] When the OTA master 21 receives a distribution package from the distribution server 5 of the OTA center 2 (FIG. 13, S31), it transfers each of the update data A to C to the respective target ECUs 22(1) to 22(3) (S32). Note that the processing performed by the target ECU 22 is the same as that in FIG. 9.

[0048] Subsequently, when the download processing unit 23 receives the digital signature given to the hash chain f (S33), it verifies the received digital signature (S34). If the verification is successful, the hash chain f is obtained.

[0049] The OTA master 21 receives the hash values a' to c' calculated by each target ECU 22(1) to 22(3) (S35). The hash value calculation unit 11 calculates a hash chain f' for the received hash values a' to c' (and d') (S36).

[0050] Then, the hash value comparison unit 26 compares the hash chain f obtained from the OTA center 2 with the hash chain f' calculated by the hash value calculation unit 11 (S37). If all of them match (S38; YES), an installation instruction is issued to each target ECU 22(1) to 22(3) (S18). On the other hand, if they do not match (S38; NO), the process is terminated or a rollback instruction is issued to the target ECU 22 (S40).

[0051] As described above, according to the second embodiment, the OTA center 2 also transmits the hash chain f, which is the hash value calculated for the plurality of hash values a to c, to the OTA master 21. When the OTA master 21 calculates the hash chain f' for the hash values a' to c' received from the ECUs 22(1) to 22(3), it compares the hash chain f' with the hash chain f. As a result, even when any of the plurality of hash values a to c becomes incomplete data, it can be detected by verification, so that the security of the communication system can be further improved.

[0052] (Third Embodiment) As shown in FIG. 14, in the third embodiment, when receiving the distribution package from the OTA center 2 in a streaming manner, the OTA master 21 sequentially calculates hash values for the update data. The SHA-2 described above is used as the hash function. Hereinafter, as an example, a case using the SHA-2 function will be described. The processing on the OTA center 2 side is the same as that in FIG. 5. The OTA master 21 grasps the size of the data to be received from the download metadata received from the OTA center 2 (FIG. 15, S41), calculates how many times the data size is a multiple of 512 bits (S42), and then receives the distribution package from the OTA center 2 in a streaming manner (S43).

[0053] The OTA master 21 divides the received data in units of 512 bits (S44). If the divided data is referred to as a "message", for example, it is assumed that the data is divided into N messages. Then, the hash value calculation unit 25 applies the SHA-2 function to the message (S45), and holds the output result as the initial buffer value of the next SHA-2 function (S46). For example, in the case of SHA-256, the hash length of the hash value obtained by applying it to 512-bit data is 256 bits. Then, the processes of steps S45 and S46 are repeated until the SHA-2 function is applied to (N - 1) messages (S47; NO).

[0054] For the Nth message (S47; YES), it is determined whether the data size thereof is an integer multiple of 512 bits (S48). If it is not an integer multiple (NO), padding is performed to make it an integer multiple, and then the SHA-2 function is applied, and the output result is used as the hash value (S49). Then, the OTA master 21 verifies the digital signature received from the distribution server 4 to obtain a hash value (S50). In step S48, if the data size of the message is an integer multiple of 512 bits (YES), since the final hash value has been obtained, the process proceeds to step S50.

[0055] Then, the hash value comparison unit 26 compares the hash value acquired in step S50 with the hash value calculated by the hash value calculation unit 25 (S51). If both match (S52; YES), an installation instruction is issued to the target ECU 22 (S53). On the other hand, if they do not match (S52; NO), the process is terminated or a rollback instruction is issued to the target ECU 22 (S54).

[0056] Note that the process shown in FIG. 15 corresponds to one target ECU 22. When there are a plurality of target ECUs 22, the process shown in FIG. 15 is repeatedly executed. Also, the process of the target ECU 22 shown in FIG. 16 only executes steps S21, S24, and S25 in FIG. 9, and the process ends when it is determined as "NO" in step S24.

[0057] According to the third embodiment as described above, when the OTA master 21 obtains the hash value for the entire update data by calculating the hash value for each predetermined data size of the update data, it compares the hash value with the hash value transmitted from the OTA center 2 to verify the integrity of the update data. With this configuration, the integrity verification can be performed as a process within the OTA master 21.

[0058] (Fourth Embodiment) As shown in FIG. 17, the fourth embodiment shows the processing when the streaming method and the storage method are mixed. The processing of the OTA center 2 is the same as that of the first embodiment. As shown in FIG. 18, the OTA master 21 receives the storage-type package A and the streaming-type package B from the distribution server 5 (S61). Package A is in zip format and contains verification data for package A. Subsequently, the OTA master 21 verifies package A using the verification data and transmits the update data K, L contained in package B to the target ECUs 22(4), 22(5) (S62). Here, the download of packages A and B is started.

[0059] If the verification of package A is successfully completed (S63; YES, S70; YES), the update data G to I contained in package A is written to the target ECUs 22(1) to 22(3) (S71). Here, the installation of package A is started. On the other hand, if the verification is not successfully completed (S70; NO), the processing for package A is terminated. Also, a rollback instruction is issued to the target ECU 22 for which the installation process of package B has been started (S72).

[0060] If it is Package B (S63; NO), the OTA master 21 receives the hash values k' and l' calculated by the target ECUs 22(4) and 22(5) for the update data K and L (S64). Note that the processing of these target ECUs 22 is the same as that in FIG. 9. Subsequently, when a digital signature is received from the distribution server 5, verification is performed (S65).

[0061] Then, the decrypted hash values k and l are compared with the hash values k' and l' (S66). If both match (S67; YES), an installation instruction is issued to each of the target ECUs 22(4) and 22(5) (S68). Here, the installation of Package B is started. If both do not match (S67; NO), the processing for Package B is terminated. Also, a rollback instruction is issued to the target ECU 22 that has started the installation process for Package A (S69).

[0062] Here, another aspect of FIG. 18 will be described. In the above embodiment, at S63, it is determined whether the package is Package A. Alternatively, the OTA master 21 may determine the type of the package and execute processing according to the result. When receiving Package A and Package B, the OTA master 21 determines the type of the package. As a result, if the OTA master 21 determines that the package is the storage - type Package A, it proceeds to S70 and executes the processing from S70 to S72. Also, if the OTA master 21 determines that the package is the streaming - type Package B, it proceeds to S64 and executes the processing from S64 to S69. The determination of the package type by the OTA master 21 is repeated for the number of received packages.

[0063] According to the fourth embodiment as described above, when the OTA center 2 transmits update data to be written to a part of a plurality of target ECUs 22 in a storage method, the OTA center 2 transmits the update data and the hash value calculated for the data to the OTA master 21. The OTA master 21 calculates the hash value for the update data, and verifies the integrity of the update data by comparing it with the corresponding hash value transmitted from the OTA center 2. When the integrity is verified, the update data is transferred to the target ECUs 22(1) to 22(3) corresponding to the storage method. Thereby, even when the target ECUs 22 corresponding to the storage method are mixed, the security can be improved.

[0064] (Fifth Embodiment) As shown in FIG. 19, the fifth embodiment shows a case where a distribution package is once downloaded from the OTA center 2 to the smartphone 31 and then transferred from the smartphone 31 to the OTA master 21. Note that the "smartphone" may be referred to as "smartphone" and the car navigation device may be referred to as "navi". As shown in FIG. 20, when the OTA center 2 executes steps S1 to S4, as will be described later, the user is communicating with the OTA center 2 using a car navigation device or a smartphone 31 (not shown), and it is determined whether the smartphone 31 is selected as the distribution destination of the package (S73). If the smartphone 31 is selected (YES), the package is distributed to the smartphone 31 (S74). If the smartphone 31 is not selected (NO), the package is distributed to the OTA master 21 as before (S7).

[0065] As shown in FIG. 21, on the premise that the user who has the smartphone 31 has paired the smartphone 31 with the vehicle-side device by wireless communication, the user receives a push notification from the OTA center 2 (S81). Then, the smartphone 31 selects where to download the distribution package (S82). Then, the selection result is notified to the distribution server 5 of the OTA center 2 (S83).

[0066] If the user selects the smartphone 31 (S84; YES), the package is downloaded (DL) to the specified path of the smartphone 31 (S85). Subsequently, when the smartphone 31 notifies the distribution server 5 that the download of the package is completed (S86), the smartphone 31 transfers the package to the OTA master 21 (S87).

[0067] As shown in FIG. 22, the OTA master 21 transmits vehicle configuration information to the OTA center 2 in order to synchronize with the OTA center 2 side for vehicle configuration information (S91). When the user executes the instruction displayed on the car navigation device (S92; YES), the OTA master 21 verifies the digital signature received from the OTA center 2 and acquires hash value concatenation information (S93).

[0068] Then, when the car navigation device or the smartphone 31 transmits to the OTA center 2 that the smartphone 31 is selected as the transmission destination of the distribution package (S94; YES), the OTA master 21 downloads the distribution package from the smartphone 31 according to the directory notified from the OTA center 2 (S95). On the other hand, if the smartphone 31 is not selected as the transmission destination (S94; NO), the OTA master 21 downloads the distribution package from the OTA center 2 (S96). Thereafter, steps S12 to S19 of the first embodiment are executed.

[0069] As described above, according to the fifth embodiment, the OTA master 21 can selectively download the distribution package downloaded from the OTA center 2 to the smartphone 31 from the smartphone 31. Thereby, the distribution package can be acquired in a more flexible manner.

[0070] (Other embodiments) The contents of the repro policy metadata and the download metadata may be appropriately changed according to individual designs. The hash function is not limited to SHA-2. Although the present disclosure has been described in accordance with the embodiments, it should be understood that the present disclosure is not limited to such embodiments and structures. The present disclosure also includes various modifications and variations within the equivalent scope. In addition, various combinations and forms, as well as other combinations and forms including only one, more than one, or less than one element thereof, are also within the scope and spirit of the present disclosure.

[0071] The means and / or functions provided by each device or the like can be provided by software recorded in a physical memory device and a computer that executes the software, software only, hardware only, or a combination thereof. For example, when the control device is provided by an electronic circuit that is hardware, it can be provided by a digital circuit including a number of logic circuits or an analog circuit.

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

Description of Reference Numerals

[0073] In the drawings, 1 represents an in-vehicle communication system, 2 represents an OTA center, 4 represents a PKG generation server, 5 represents a distribution server, 3 represents a vehicle-side system, 21 represents an OTA master, and 22 represents a target ECU.

Claims

1. An in-vehicle communication system comprising: an in-vehicle electronic control device (22); a center device (2) that transmits update data as a distribution package in a streaming manner; a master device (21) mounted on the vehicle that receives the distribution package and transfers the update data to the electronic control device; the electronic control device that writes the update data transferred from the master device into a storage unit; wherein the center device also transmits a hash value calculated for the update data to the master device; the electronic control device calculates a hash value for the update data and transmits the hash value to the master device; and the master device compares the hash value transmitted from the center device with the hash value transmitted from the electronic control device to verify the integrity of the update data.

2. When the center device causes a plurality of electronic control devices to write update data respectively, the center device also transmits a plurality of hash values calculated for each update data to the master device; the master device transfers each update data to each electronic control device respectively; each electronic control device calculates a hash value for the update data and transmits the hash value to the master device; and the master device according to claim 1, compares the hash values transmitted from the plurality of electronic control devices with the corresponding hash values transmitted from the center device. The in-vehicle communication system described.

3. The center device uses a hash value calculated for the plurality of hash values as a higher-level hash value and also transmits the higher-level hash value to the master device; when the master device calculates a higher-level hash value for the plurality of hash values received from the plurality of electronic control devices, the master device compares the calculated higher-level hash value with the higher-level hash value transmitted from the center device. The in-vehicle communication system described in claim 2.

4. When the center device transmits update data to a part of the plurality of electronic control devices in a storage manner, the center device transmits the update data and a hash value calculated for the update data to the master device; the master device calculates a hash value for the update data, compares it with the corresponding hash value transmitted from the center device, and verifies the integrity of the update data; when the integrity of the update data is verified, the master device transfers the update data to the electronic control device corresponding to the storage method. The in-vehicle communication system described in claim 2 or 3.

5. The in-vehicle communication system according to any one of claims 1 to 4, wherein the center device adds the hash value to download metadata including at least the address of the data acquisition destination, the data name and data size, the ID of the electronic control device which is the distribution destination of the update data, and information on the data transfer method, and transmits the result to the master device.

6. The in-vehicle communication system according to any one of claims 1 to 5, further comprising a portable information terminal capable of receiving the update data from the center device, wherein the master device is also capable of receiving the update data via the portable information terminal.

7. An in-vehicle communication system comprising: an electronic control device mounted on a vehicle; a center device that transmits update data as a distribution package in a streaming manner; a master device that receives the distribution package and transfers the update data to the electronic control device; and the electronic control device that writes the update data transferred from the master device into a storage unit, wherein the center device also transmits a hash value calculated for the update data to the master device, and the master device calculates a hash value for each predetermined data size of the update data to obtain a hash value for the entire update data, and then compares the hash value with the hash value transmitted from the center device to verify the integrity of the update data.

8. When transmitting update data to an electronic control device mounted on a vehicle in a streaming manner, a center device transmits a hash value calculated for the update data, and when transmitting update data to a plurality of electronic control devices respectively, the center device transmits a plurality of hash values calculated for each update data, and when transmitting update data to a part of the plurality of electronic control devices in a storage manner, the center device transmits the update data and a hash value calculated for the update data.

9. The center device according to claim 8, wherein a hash value calculated for the plurality of hash values is used as a higher-level hash value, and the higher-level hash value is also transmitted.

10. When transmitting update data to an electronic control device mounted on a vehicle in a streaming manner, a center device transmits a hash value calculated for the update data, A center device that adds the hash value to download metadata including at least the address of the data acquisition source, the data name and data size, the ID of the electronic control device that is the distribution destination of the update data, and information on the data transfer method, and then transmits the result.

11. A master device mounted on a vehicle that receives a distribution package including update data transmitted in a streaming manner from a center device; An electronic control device mounted on the vehicle that writes the update data transferred from the master device into a storage unit, The master device receives the hash value calculated and transmitted by the center device for the update data; When the electronic control device calculates a hash value for the update data, the electronic control device transmits the hash value to the master device; The master device compares the hash value transmitted from the center device with the hash value transmitted from the electronic control device to verify the integrity of the update data. A vehicle-side system.

12. When the center device transmits update data to a plurality of electronic control devices respectively, and the master device receives a plurality of hash values calculated and transmitted by the center device for each update data, the master device transfers each update data to each electronic control device respectively; When each electronic control device calculates a hash value for the update data, each electronic control device transmits the hash value to the master device; The vehicle-side system according to claim 11, wherein the master device compares the hash values transmitted from a plurality of electronic control devices with the corresponding hash values transmitted from the center device.

13. The master device also receives the hash value calculated by the center device for the plurality of hash values and transmitted as a higher-level hash value; The vehicle-side system according to claim 12, wherein when calculating a higher-level hash value for a plurality of hash values received from a plurality of electronic control devices, the master device compares the calculated higher-level hash value with the higher-level hash value transmitted from the center device.

14. When the center device transmits a distribution package including update data for a part of a plurality of electronic control devices in a storage manner, the master device receives the update data and the hash value calculated for the update data; Calculate a hash value for the update data, compare it with the corresponding hash value transmitted from the center device, and verify the integrity of the update data. The vehicle-side system according to claim 12 or 13, wherein when the integrity of the update data is verified, the update data is transferred to an electronic control device corresponding to the storage method.

15. A portable information terminal capable of receiving the distribution package from the center device, The vehicle-side system according to any one of claims 11 to 14, wherein the master device can also receive the distribution package from the center device via the portable information terminal.

16. A master device mounted on a vehicle and receiving update data transmitted in a streaming manner from a center device as a distribution package, An electronic control device mounted on the vehicle and writing the update data transferred from the master device into a storage unit, The center device also transmits a hash value calculated for the update data to the master device, The master device also receives the hash value calculated by the center device for the update data, and when obtaining the hash value for the entire update data by calculating the hash value for each predetermined data size of the update data, compares the hash value with the hash value transmitted from the center device to verify the integrity of the update data. A vehicle-side system.

17. When the center device transmits update data to an electronic control device mounted on a vehicle in a streaming manner, When the master device mounted on the vehicle receives the update data as a distribution package, it transfers it to the electronic control device, The center device also transmits a hash value calculated for the update data to the master device, The electronic control device transmits a hash value calculated for the update data to the master device, An update data verification method for in-vehicle communication, wherein the master device compares the hash value transmitted from the center device with the hash value transmitted from the electronic control device to verify the integrity of the update data.

18. When the center device transmits update data to an electronic control device mounted on a vehicle in a streaming manner, When the master device mounted on the vehicle receives the update data as a distribution package, it transfers it to the electronic control device, The center device also transmits a hash value calculated for the update data to the master device, The in-vehicle communication update data verification method, wherein the master device also receives the hash value calculated by the center device for the update data, and calculates the hash value for each predetermined data size of the update data to obtain the hash value for the entire update data, and then compares the hash value with the hash value transmitted from the center device to verify the integrity of the update data.

Images