In-vehicle communication system, center device, master device, data transmission method, data update control method, and metadata generation program

Abstract

To provide an on-vehicle communication system which can perform communication by using a data format capable of flexibly coping with a platform and a distribution system, etc. of an electronic control device even when they are diversified.SOLUTION: An OTA center 1 is three-layered structure consisting of: a distribution layer in which a communication protocol and communication destination information are stored; a master layer in which information regarding a platform of an OTA master 32 is stored; and a target layer in which information regarding a platform of a target ECU 33 is stored, and transmits the information to the OTA master 32 as RP data showing configuration information of a distribution package. The OTA master 32 interprets the RP metadata and requests DL metadata, from the OTA center 1, in which control information for acquiring data to be required corresponding to each layer is stored when it is determined that the RP metadata is the distribution package suitable for an own vehicle. The OTA master 32 interprets the DL metadata, acquires required data, and performs data update control of the target ECU 33 when the OTA center 1 transmits the DL metadata to the OTA master 32.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to a system for communicating between a center device and a master device and a target device mounted on a vehicle, an intermediate device used in the system, a master device, a data transmission method, a data update control method, and a metadata generation program. Ru Se

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 for vehicle control and diagnosis mounted on vehicle electronic control units (hereinafter referred to as ECUs (Electronic Control Units)) has been increasing. In addition, with version upgrades due to function improvements and the like, the opportunity to perform so-called reprogramming 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 become widespread. Under such circumstances, for example, Patent Document 1 discloses a technology in which an update program for an ECU is distributed from a server to an in-vehicle device by OTA (Over The Air), and the update program is rewritten on the vehicle side.

[0003] As for the method of rewriting the above update program, there are 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 the update is performed, and a streaming method in which the update is performed while downloading the update program from the center device to the vehicle side. Also, regarding the package structure for distributing the update program according to the ECU platform, in the specifications of the general incorporated association JASPAR (Japan Automotive Software Platform and Architecture), the data requirements applicable to the classic platform (CP) operating on the static OS (Operating System) of the standardization organization AUTOSAR (AUTomotive Open System ARchitecture) are defined. In addition, in AUTOSAR, the data requirements applicable to a new type of adaptive platform (AP) operating on a dynamic OS are defined.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] Therefore, for the ECUs mounted on the vehicle side, it is assumed that there are cases where those adopting the storage method and the streaming method are mixed, or cases where the CP and AP types are mixed. In addition, in the future, it is also assumed to support in-vehicle Linux (registered trademark), for example, Automotive Grade Linux; AGL, or to download data to a separate smartphone or the like. However, the current OTA does not assume corresponding to such variations in communication modes.

[0006] The present invention has been made in view of the above circumstances, and an object thereof is to provide an in-vehicle communication system capable of performing communication using a data format that can flexibly respond even when the platform, distribution method, etc. of an electronic control device diversify, as well as an in-vehicle device, a master device, a data transmission method, a data update control method, and a metadata generation program used in the system. Ru Se to provide.

Means for Solving the Problems

[0007] According to the in-vehicle communication system described in claim 1, the center device has a three-layer structure including a distribution layer in which communication protocols and communication destination information are stored, a master layer in which information regarding the platform of the master device is stored, and a target layer in which information regarding the platform of the target device is stored, and transmits repro policy metadata indicating the configuration information of the distribution package to the master device.

[0008] When the master device determines, by interpreting the repro policy metadata, that it is a distribution package suitable for the host vehicle, it requests the center device for download metadata in which control information for acquiring necessary data corresponding to each of the three layers is stored. When the center device transmits the download metadata to the master device, the master device interprets the download metadata to acquire the necessary data and performs data update control of the target device.

[0009] The repro policy metadata indicating the configuration information of the distribution package is, in other words, information that includes information representing the configuration type of the package, and is information mainly aimed at preventing distribution errors of the package by checking the content of the data on the vehicle side. Also, the download metadata in which control information for acquiring data is stored is, in other words, information that defines the content for enabling the master device to grasp information for downloading update data for each of a plurality of target ECUs. By making these metadata have a three-layer structure of distribution, master, and target, even when the transfer method, the type of platform, and the type of distribution package increase, they can be flexibly defined and dealt with, and it becomes possible to update the data of the target device.

[0010] According to the in-vehicle communication system described in claim 2, the repro policy metadata includes, as parameters in the master layer, platform type information of the master device and control method type information of the platform. Also, as parameters in the target layer, it includes platform type information of the target device, control method type information of the platform, and data transfer method type information from the center device to the target device. Then, the master device determines whether the distribution package is suitable for the own vehicle by comparing each of the above information with the design configuration information managed by itself.

[0011] Incidentally, the design configuration information is information regarding the vehicle on which the master device and the target device are mounted, and information regarding the hardware and software of the master device and the target device. That is, by including each of the above type information in the parameters of the master and target layers of the repro policy metadata, the master device can interpret the type information and transfer data to the target device.

[0012] According to the in-vehicle communication system described in claim 3, the download metadata includes, as parameters for each layer, the URI of the data acquisition destination, the hash value assigned to the data, the ID of the target device, and the data transfer method type information from the center device. Further, as parameters in the master layer and the target layer, it includes the platform type information of the master device and the target device. And based on each piece of information, the master device acquires the data required for each layer at the timing when it is required, and performs data update control of the target device.

[0013] That is, by including each of the above pieces of information in the parameters of each layer of the download metadata, the master device can interpret those pieces of information and perform data transfer to the target device in a more specific procedure.

Brief Description of the Drawings

[0014]

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 16A

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Figure 24

Figure 25

Figure 26

Embodiments for Carrying Out the Invention

[0015] (First Embodiment) As shown in FIG. 1, the OTA center 1 of the in-vehicle communication system includes a PKG generation server 2, a distribution server 3, a PKG generation logic DB 4, and a design configuration information DB 5. Here, PKG stands for "package" and DB stands for "database". Also, each processing functional unit related to the PKG generation server 2 is shown externalized. The OTA center 1 stores update data for updating the control program of the target ECU 33 in a distribution package and transmits it to the vehicle-side system 31 shown in FIG. 2. Prior to transmitting the distribution package, in this embodiment, repro policy metadata and download metadata storing necessary information are transmitted to the OTA master 32 of the vehicle-side system 31. Hereinafter, the repro policy metadata may be referred to as "RP metadata", and the download metadata may be referred to as "DL metadata".

[0016] Note that the servers, databases, and various processing units in the server in this embodiment are for convenience of display, and there are other modes that realize the same functions. Regarding the OTA master as well, the various processing units are separated for convenience of explanation, and for example, they may be integrated as software or hardware, or may be divided into a plurality of parts.

[0017] The PKG generation logic DB 4 stores data corresponding to each piece of information for generating RP metadata and DL metadata. The metadata specifying processing unit 6 performs processing for specifying each item and data format of the RP and DL metadata. The RP metadata generation processing unit 7 generates RP metadata, and the encryption / signature processing unit 8 encrypts the generated RP metadata and assigns a digital signature.

[0018] The DL metadata generation processing unit 9 generates DL metadata. The calculation processing unit 10 calculates the data size of the update data and calculates the hash value of the update data. The encryption / signature processing unit 11 encrypts the generated DL metadata and assigns a digital signature. The PKG main body generation processing unit 12 generates the main body part of the distribution package including the update data and the like.

[0019] The PKG generation server 2 transfers the RP metadata, DL metadata, and distribution package generated by the above-mentioned respective processing units and the like to the distribution server 3. The distribution server 3 accesses the design configuration information DB5, acquires the configuration information of the vehicle to which the distribution package is to be transmitted, and assigns it to the distribution package.

[0020] As shown in FIG. 2, the vehicle-side system 31 includes an OTA master 32 and target ECUs 33. The OTA master 32 is composed of a DCM (Data Communication Module) 32A and a central ECU 32B shown in FIG. 6. There are actually a plurality of target ECUs 33.

[0021] The RP metadata analysis processing unit 34 analyzes the RP metadata received by the OTA master 32. The decryption / signature verification processing unit 35 performs verification processing using the digital signature attached to the RP metadata and decrypts the RP metadata.

[0022] The DL metadata analysis processing unit 36 analyzes the DL metadata received by the OTA master 32. The calculation processing unit 37 calculates the data size of the update data, which is a parameter of the DL metadata, and calculates the hash value of the update data. The decryption / signature verification processing unit 38 performs verification processing using the digital signature attached to the DL metadata and decrypts the DL metadata.

[0023] The PKG main body acquisition processing unit 39 acquires the main body part of the distribution package received by the OTA master 32. The update data included in the acquired distribution package is transferred to the target ECU 33 by the transfer processing unit 40. The analysis processing unit 41 performs processing to analyze each item and data format of the RP and DL metadata.

[0024] ≪Repro Policy Metadata≫ The RP metadata shown in FIG. 3 is transmitted from the OTA center 1 to the OTA master 32 prior to the download of the distribution package. <RP Metadata Version> This is the version of the RP metadata, and version information such as "1.0.0" or "2.0.0" is stored.

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

[0026] <Master Layer> Regarding the OTA master 32, 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 an update program according to the ECU's platform, in the specifications of the Japan Automotive Software Platform and Architecture (JASPAR), the data requirements applicable to the classic platform (CP) operating on the static OS of the AUTomotive Open System ARchitecture (AUTOSAR) standardization organization are defined. Also, in AUTOSAR, the data requirements applicable to the new type of adaptive platform (AP) operating on the dynamic OS are defined. AGL is in-vehicle Linux, and Android is Android Automotive OS.

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

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

[0029] ≪Download metadata≫ The DL metadata shown in FIG. 4 is transmitted from the OTA center 1 to the OTA master 32 following the RP metadata.

[0030] <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. <Master layer> For example, it is information for obtaining the Vehicle PKG, and each item is the same as the delivery layer. There may be multiple cases of this information.

[0031] <Target layer> For example, it is information for obtaining the Software PKG, and each item is the same as the delivery layer. There may also be multiple cases of this information. Regarding the 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", and refer to the relevant descriptions in this document.

[0032] Here, the differences between AP and CP will be described. 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 referred to as a CP ECU or a CP's ECU, and an ECU that operates in accordance with the AP specification may be referred to as an AP ECU or an AP's ECU.

[0033] In AP and CP, the operating systems, so-called OS, and development languages used are different. The CP ECU and the AP ECU have different package structures that can be received. 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's 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 AP's ECU uses one with high processing performance, it is possible to install a parser function that analyzes structured character data described in some language and converts it into a data structure that can be handled by a program. The data structure does not use simple binary data, and for example, an object-oriented data format such as JSON (JavaScript Object Notation) can be adopted, resulting in a flexible package data structure.

[0035] Figure 5 shows an example of expanding the package configuration corresponding to the above-mentioned AP in this embodiment. By obtaining the Vehicle PKG manifest of Vehicle PKG according to the information of the master layer, information regarding the distribution procedure, such as which ECU, which package, in which order, and when to transfer, can be obtained.

[0036] In addition, the four Software PKGs corresponding to the target layer are different for each platform type of UCM (Update Configuration Management) 1 to 4, namely AP, CP, AGL, and Android. The latter two are platform types not defined in AUTOSAR, but the ECU can also handle them when these platforms are adopted. Note that since UCM is described in AUTOSAR, the details are omitted here.

[0037] In Figure 6, DCM32A is an in-vehicle communication device that performs data communication with the OTA center 1 via a communication network. When it downloads a distribution package from the distribution server 3, it extracts the update data from the distribution package and transfers it to the central ECU 32B. The central ECU 32B is a vehicle gateway device with a data relay function. When it acquires the update data from DCM32A, it distributes the update data to the target ECU 33, which is the target for rewriting the application program. Note that the central ECU may sometimes be denoted as "C-ECU".

[0038] Figure 6 visually shows the flow of update data transfer within the vehicle-side system 31. When the central ECU 32B acquires the Vehicle PKG in the storage mode, it performs distribution control of the Software PKG for each target ECU 33(1) to 3(3) according to the information. The UI of the target ECU 33(2) is the user interface, and the IVI is the in-vehicle infotainment. Also, the ADAS of the target ECU 33(3) is the advanced driver assistance system.

[0039] Figure 7 schematically shows the sequence when the PF types of both the central ECU 32B and the target ECU 33 are AP and each data package is transferred in the streaming mode.

[0040] Next, the operation of this embodiment will be described. As shown in FIG. 8, the OTA center 1 generates a distribution package in the PKG generation server 2 (S1). Subsequently, in the PKG generation server 2, when the PKG generation logic DB4 is confirmed using the software version of the central ECU 32B of the update target system information as a key (S2), the data item configurations of the DL metadata and RP metadata to be generated by the PKG generation server 2 are determined (S3). The update target system information includes the ID of the target ECU 33, software information, and hardware information. Based on this information, the PKG generation server 2 can identify the update target system.

[0041] Next, the PKG generation server 2 checks the inside of the PKG generation logic DB4 using the PF type (AP / CP) of the central ECU 32B of the update target system information as a key (S4). If the PF type is AP (S5; YES), the PKG generation server 2 generates DL metadata in JSON (S6) and fills in the items of the RP metadata from the update target system information (S7). On the other hand, if the PF type is CP (S5; NO), the PKG generation server 2 generates DL metadata in binary (S8) and proceeds to step S7.

[0042] Subsequently, the PKG generation server 2 calculates the data size and hash value of the DL metadata by the calculation processing unit 10 and fills in the corresponding items (S9), and then fills in the items of the target ID and transfer method from the update target system information (S10). Then, the file name of the DL metadata is obtained and set from the reprovisioning file (S11). Next, the encryption / signature processing unit 8 performs encryption / signature processing on the RP metadata (S12), and when the encryption / signature processing unit 11 performs encryption / signature processing on the DL metadata (S13), the package body, RP metadata, and DL metadata are transmitted to the distribution server 3 (S14).

[0043] Figure 9 shows the processing corresponding to the case where the PF type of the Central ECU 32B is AP. When the OTA Master 32 acquires RP metadata from the OTA Center 1 (S21), it performs decryption / title verification of the RP metadata (S22). If the verification result is an error, it returns the error status information to the OTA Center 1 (S27). If the verification result is successful, it checks the data items of the RP metadata to check whether each item matches the information managed by the OTA Master 32 (S23). If there is a mismatch, it returns the error status information to the OTA Center 1 in the same way as in step S27 (S28).

[0044] On the other hand, if each item matches (YES), it identifies the package structure based on the RP metadata (S24) and acquires DL metadata from the OTA Center 1 (S25). Then, it performs decryption / title verification of the DL metadata (S26). If the verification result is an error, it returns the error status information to the OTA Center 1 (S29). If the verification result is successful, it downloads the data of the master layer and the target layer respectively from the URI specified in the DL metadata (S30, S31).

[0045] Then, when it configures the update program for each Target ECU 33 (S32), for each platform and OTA method of the Target ECU 33 in each package structure, it performs program update and reprogramming (S33). From here, the process branches to steps S34(1) to S34(4). Note that when the Central ECU 32B is CP, it branches to steps S34(5) to S34(8) shown in Figure 10.

[0046] In step S34(1), when the combination of the central-target ECU is AP-AP and the OTA method of the target ECU 33 is storage, it is a rewrite. In this case, according to the procedure described in the AUTOSAR Specification (SWS), the update is performed by the UCM master / UCM (S35(1)). In step S34(2), when the combination is AP-AP and the OTA method is streaming, it is a rewrite, and steps S38 to S45 in FIG. 13 of Japanese Patent Application No. 2021-32593 are executed (S35(2)).

[0047] In step S34(3), when the combination is AP-CP and the OTA method is storage, it is a rewrite. In this case, according to the procedure described in the AUTOSAR Specification (SWS), the update is performed by the UCM master and the flashing adapter (S35(3)). In step S34(4), when the combination is AP-CP and the OTA method is streaming, it is a rewrite, and in this case, the process also proceeds to step S35(3).

[0048] In step S34(5) shown in FIG. 10, when the combination is CP-AP and the OTA method is storage, it is a rewrite. In this case, according to the procedure described in the AUTOSAR Specification (SWS), the update is performed by the UCM (S35(5)). In step S34(6), when the combination is CP-AP and the OTA method is streaming, it is a rewrite, and the same process as in step S35(2) is performed (S35(6)).

[0049] In step S34(7), when the combination is CP-CP and the OTA method is storage, it is a rewrite. In this case, according to the procedure described in paragraphs

[0381] to

[0400] and FIGS. 115 to 118 of Japanese Patent Laid-Open No. 2020-27633, the update is performed by the OTA master (S35(7)). In step S34(8), when the combination is CP-CP and the OTA method is streaming, it is a rewrite, and the same process as in step S35(2) is performed (S35(8)).

[0050] As described above, according to this embodiment, the OTA center 1 has a three-layer structure including a distribution layer in which communication protocols and destination information are stored, a master layer in which information regarding the platform of the OTA master 32 is stored, and a target layer in which information regarding the platform of the target ECU 33 is stored, and transmits RP metadata indicating the configuration information of the distribution package to the OTA master 32.

[0051] When the OTA master 32 determines that the RP metadata is a distribution package suitable for the host vehicle after interpreting it, it requests the OTA center 1 for DL metadata in which control information for acquiring the necessary data corresponding to each of the three layers is stored. When the OTA center 1 transmits the DL metadata to the OTA master 32, the OTA master 32 interprets the DL metadata, acquires the necessary data, and performs data update control of the target ECU 33.

[0052] The RP metadata is information mainly defining the content of the distribution package transmitted from the OTA center 1 to the OTA master 32, and the DL metadata is information mainly defining the content of the update data transmitted from the OTA master 32 to the target ECU 33. By making these metadata into a three-layer structure of distribution, master, and target, even when the transfer method, the type of platform, and the type of distribution package increase, they can be flexibly defined and dealt with, and it becomes possible to update the data of the target ECU 33.

[0053] Specifically, as parameters in the master layer, the RP metadata includes the platform type information of the OTA master 32 and the control method type information of the platform. Also, as parameters in the target layer, it includes the platform type information of the target ECU 33, the control method type information of the platform, and the data transfer method type information from the OTA center 1 to the target ECU 33. Then, the OTA master 32 determines whether the distribution package is compatible with the host vehicle by comparing each of the above information with the design configuration information it manages itself.

[0054] In this way, by including the above various type information in the parameters of the master and target layers of the RP metadata, the OTA master 32 can interpret these type information and perform data transfer to the target ECU 33.

[0055] Also, the DL metadata includes, as parameters for each layer, the URI of the data acquisition source, the hash value assigned to the data, the ID of the target ECU 33, and the data transfer method type information from the OTA center 1. Also, as parameters in the master layer and the target layer, it includes the platform type information of the OTA master 32 and the target ECU 33. Then, based on each information, the OTA master 32 acquires the necessary data for each layer at the necessary timing and performs data update control of the target ECU 33. In this way, by including the above each information in the parameters of each layer of the DL metadata, the OTA master 32 can interpret these information and perform data transfer to the target ECU 33 in a more specific procedure.

[0056] (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 different parts will be described. As shown in FIGS. 11 and 12, in the second embodiment, a distribution package is transferred via the smartphone 42. Note that the smartphone 42 is paired with and communicates with an in-vehicle device such as a car navigation device or the DCM32A, etc., and communication with the OTA master 32 is possible via such a device. Also, a personal computer (PC) may be used instead of the smartphone 42. Note that the smartphone may be referred to as a "smartphone".

[0057] In FIG. 13, when the distribution server 3 of the OTA center 1 receives a notification for synchronizing vehicle configuration information from the OTA master 32 (S41), it notifies the OTA master 32 of campaign information (S42). The vehicle 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 "notification for synchronization" is a notification performed to match, that is, synchronize, the content of the configuration information held on the vehicle side with the content of the configuration information held on the OTA center 1 side. Also, the campaign information is information regarding a program update to be displayed on the vehicle side system 3 and the smartphone 42.

[0058] The user refers to the campaign information displayed on the smartphone 42, checks the update data size, and then selects a download destination for the distribution package. The download destination is a cellular type meaning the OTA master 32, the smartphone 42, or a portable storage terminal such as a USB memory connected to a car navigation device. When the distribution server 3 receives the selection result (S43) and the smartphone 42 or the USB memory is selected (S44; YES), the distribution server 3 notifies the smartphone 42 of the link information of the download destination by, for example, e-mail (S45).

[0059] Based on the above notification, the user downloads the delivery package from the delivery server 3 and saves it in the specified directory of the smartphone 42 or the USB memory (S46). After that, when the smartphone 42 receives a download completion notification (S47; YES), the delivery server 3, similar to step S41, receives the "notification for synchronization" from the OTA master 32 again (S48). When the PKG generation server 2 generates RP metadata and DL metadata as shown in the first embodiment (S49), the delivery server 3 transmits each metadata to the OTA master 32 (S50, S51).

[0060] As shown in FIG. 14, when the smartphone 42 receives a notification of campaign information from the OTA center 1 (S61), the user selects a download destination for the delivery package (S62) and notifies the OTA center 1 of the selection result (S63). If the smartphone 42 or the USB memory is selected (S64; YES), the smartphone 42 receives the delivery package from the delivery server 3 (S65). Then, when a download completion notification is transmitted to the OTA center 1 (S66), the delivery package is transferred to the OTA master 32 (S67).

[0061] As shown in FIG. 15, the OTA master 32 transmits vehicle configuration information to the OTA center 1 (S71). When the user selects the smartphone 42 or the USB memory as the download destination for the delivery package (S72; YES) and executes the instruction displayed on the car navigation device (S73; YES), the OTA master 32 receives RP metadata and DL metadata from the OTA center 1 (S74). Then, the OTA master 32 downloads the delivery package from the smartphone 42 or the USB memory according to the directory notified by the OTA center 1 (S75), and transfers the update data included in the delivery package to the target ECU 33 (S76).

[0062] According to the second embodiment as described above, the OTA center 1 notifies the smartphone 42 of the information of the update data. When the user designates the transmission destination of the update data to the smartphone 42 or the USB memory via the smartphone 42, the OTA center 1 transmits the update data to the smartphone 42 or the USB memory. Then, when the OTA center 1 sets the communication destination information to the smartphone 42 or the USB memory, it sequentially transmits the RP metadata and the DL metadata to the OTA master 32, and the OTA master 32 receives the distribution package from the smartphone 42 or the USB memory according to the communication destination information.

[0063] In this way, the OTA master 32 can receive the distribution package transmitted from the OTA center 1 via the smartphone 42 or the USB memory and transfer the update data to the target ECU 33. Therefore, it becomes possible to update the data of the target ECU 33 in a more flexible form.

[0064] (Third Embodiment) Conventionally, when distributing update data to a plurality of target ECUs in a storage method, a plurality of corresponding packages were bundled into one zip file and transmitted. As shown in FIG. 16, in the third embodiment, when distributing update data to a plurality of target ECUs 33 in a storage method, the distribution package is divided into a plurality of zip files for distribution. For example, assume there is update data (1) and (2) for the target ECU 33(1), and update data (3) and (4) for the target ECU 33(2). In this case, the update data (1) and (2) are set as package 1 of the zip file, and the update data (3) and (4) are set as package 2 of the zip file. Then, instruction information indicating that these two packages contain data to be updated simultaneously is transmitted to the OTA master 32 prior to the distribution of packages 1 and 2.

[0065] If the information of the master layer of download metadata is set to one set (URI, data name, data size, etc.), when updating data is distributed to a plurality of target ECUs in a storage method, the information of the master layer of download metadata is multiple sets. In other words, it is described as many as the number of target ECUs. Also, null or blank is set in the target layer.

[0066] As shown in FIG. 17, the OTA center 1 collects update data from the update target system information and checks the data size (S111). Then, it checks whether the total data size of the distribution package by the storage method exceeds the capacity of the buffer memory of the central ECU 32B (S112). If it does not exceed the capacity (NO), the update data is stored in one zip file (S116). If it exceeds the capacity (YES), the update data is divided into N pieces each and stored in M zip files (S114). Then, the information of all packages is stored in the DL metadata. The distribution package is generated as described above.

[0067] As shown in FIG. 18, when the OTA center 1 executes steps S41, S50, and S51, the distribution server 2 transmits the package including the above-mentioned instruction information to the OTA master 32 (S52). Then, packages 1 and 2 are sequentially transmitted to the OTA master 32 (S53).

[0068] As shown in FIG. 19, when the OTA master 32 executes steps S71, S74 (A, B), the OTA master 32 receives the package including the instruction information from the distribution server 2 (S77). The package is decompressed to grasp the dependency relationships regarding the data updates of the target ECUs 33(1) and 33(2) (S78). Next, the OTA master 32 checks whether the update data is divided into a plurality of zip files (S79). When the distribution package is received from the OTA center 1 and decompressed (S80), the update data included therein is transferred to the corresponding target ECU 33 (S81).

[0069] When receiving installation completion notifications from all target ECUs 33 (S82, S83; YES, S84; YES), if the installation is successful for all of them (S85; YES), the target ECU 33 is instructed to execute activation (S86). On the other hand, if there is a failure in the installation (S85; NO), the failed target ECU 33 and the target ECUs 33 that are in a dependency relationship with that ECU 33 are instructed to execute rollback (S87).

[0070] As described above, according to the third embodiment, when the OTA center 1 distributes update data to the OTA master 32 and the target ECU 33 in a storage method, a plurality of corresponding distribution packages are divided into a plurality of zip files for distribution. As a result, it becomes possible to perform decompression from the received zip file and proceed with the processing sequentially.

[0071] (Fourth Embodiment) Conventionally, for update data transmitted from the OTA center to the vehicle side, the entire data was encrypted and signed. Therefore, for example, if the data size is 2GB, verification by signature could not be performed until the download of the 2GB data was completed. However, depending on the content of the data transmitted by the OTA center, encryption and signature may not always be necessary. Therefore, if only important data, such as the data portion related to billing, among the update data can be encrypted and signed, it becomes possible to improve the processing efficiency.

[0072] In the fourth embodiment, in the master layer and the target layer of the DL metadata, as shown in FIG. 20, information items related to encryption and digital signature are provided. · Encryption type information: (Symmetric key) AES (Advanced Encryption Standard), Triple-DES (Data Encryption Standard), (Asymmetric key) RSA (Rivest-Shamir-Adleman cryptosystem), ECC (Elliptic Curve Cryptography) · Signature type information: (Symmetric key) CBC-MAC (Message Authentication Code), CMAC (Common MAC) (Asymmetric key) DSA (Digital Signature Algorithm), ECDSA (Elliptic Curve DSA) · Key ID information: Used to identify the key · Encryption mode type information: Enc (Encrypt) then MAC, MAC then ENC , ENC and MAC · Protected object information: Specify a specific file or data · Protected area specification information: Specify the whole or part of the above file · Offset size information: Specify from which byte from the beginning to be the protected object · Protected data size information: Specify how many bytes to protect

[0073] OTA Center 1 and OTA Master 32 use the above information items to encrypt and sign some files or data in the distribution package, or further encrypt and sign a part of the above files or data.

[0074] Next, the operation of the fourth embodiment will be described. As shown in FIGS. 21 and 22, the PKG generation server 2 of the OTA Center 1 refers to the DL metadata of the target update data and checks the file specified as the encryption target and the offset size of the file (S91). Then, according to each piece of information written in the DL metadata, the encryption target location is encrypted and a digital signature is attached (S92). Note that the data other than the encrypted data part is referred to as "plain text", and this "plain text" is "obfuscated" using tools such as ProGuard or DashO.

[0075] Subsequently, the PKG generation server 2 transfers the encrypted / signed data and the obfuscated plaintext to the distribution server 3 (S93), and the distribution server 3 transmits those data to the OTA master 32 (S94). Note that FIG. 21 shows that the communication between the OTA center 1 and the OTA master 32 is encrypted by TLS (Transport Layer Security).

[0076] As shown in FIG. 23, when the OTA master 32 receives the above data from the OTA center 1 (S101), it decrypts / verifies the signature of the encrypted / signed data based on the information of the DL metadata (S102). Then, it transfers the decrypted / verified updated data to the target ECU 33 (S103).

[0077] Note that FIG. 24 shows a variation of the above, where the OTA master 32 transfers the encrypted / signed data as it is to the target ECU 33, and the target ECU 33 decrypts / verifies the signature of the encrypted / signed data.

[0078] As described above, according to the fourth embodiment, only some of the files or data in the distribution package transmitted from the OTA center 1 to the OTA master 32 are encrypted / signed on the transmission side and decrypted / verified on the reception side. Thereby, the time required for processes such as encryption and decryption can be shortened.

[0079] (Fifth Embodiment) As shown in FIGS. 25 and 26, in the fifth embodiment, a car navigation device 43, a USB memory 44 which is an example of a portable storage terminal, and a personal computer 45 are interposed in the communication system. Hereinafter, the car navigation device will be referred to as "navi", and the personal computer will be referred to as "PC". Note that, for example, an SD card may be used instead of the USB memory 44.

[0080] (1) Inside the vehicle, with the USB memory 44 connected to the navigation 43, the user operates the navigation 43 to (2) write the vehicle configuration information to the USB memory 44. This information is digitally signed using the vehicle's private key. Then, (3) the USB memory 44 is removed from the navigation 43.

[0081] (4) Next, the USB memory 44 is connected to the PC 45, and the user operates the PC 45 to transmit the vehicle configuration information to the OTA center 1 using the corresponding PC application. At the OTA center 1, the received vehicle configuration information is verified by digital signature, and if the verification result is OK, a distribution package applicable to the information is searched. (5) The user downloads the distribution package to the PC 45 using the PC application and writes it to the USB memory 44. At that time, vehicle model information and the vehicle configuration information before the update are added to the distribution package.

[0082] (6) Next, inside the vehicle, when the USB memory 44 is connected to the navigation 43 again, (7) the user operates the navigation 43 to (8) transmit the RP metadata and DL metadata stored in the USB memory 44 to the OTA master 32. (9) The OTA master 32 verifies whether it is a distribution package corresponding to the own vehicle, and (10) if the verification result is OK, it instructs the target ECU 33 to download the update data and sequentially install and activate it.

[0083] As described above, according to the fifth embodiment, the user can use the navigation 43 or the PC 45 to write the necessary information and distribution package obtained from the OTA center to the USB memory 44, and from that USB memory 44, via the navigation 43, and further download the update data from the OTA master 32 to the target ECU 33.

[0084] (Other embodiments) The contents of the RP metadata and DL metadata may be appropriately changed according to individual designs. The portable information terminal is not limited to the smartphone 42 and the PC 45. The portable memory terminal is not limited to a USB memory 44 or an SD card.

[0085] Although this disclosure has been described in accordance with the embodiments, it is understood that this disclosure is not limited to such embodiments or structures. This disclosure also encompasses various modifications and variations within the equivalent scope. In addition, various combinations and forms, and further other combinations and forms including only one, more, or less than one element thereof, fall within the scope and spirit of this disclosure.

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

[0087] The control unit and its method described in this disclosure may be implemented 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 this disclosure may be implemented 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 this disclosure may be implemented 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.

Explanation of Reference Numerals

[0088] In the drawings, 1 represents an OTA master, 2 represents a PKG generation server, 3 represents a distribution server, 31 represents a vehicle-side system, 32 represents an OTA master device, 32A represents a DCM, 32B represents a central ECU, and 33 represents a target ECU.

Claims

1. An in - vehicle communication system comprising: an electronic control unit which is a target device mounted on a vehicle, a center device (1) that transmits update data as a distribution package, a master device (32) mounted on the vehicle, which receives the distribution package and transfers the update data to the target device, and the target device (33) which writes the update data transferred from the master device into a storage unit. The center device has a three - layer structure consisting of a distribution layer in which communication protocols and communication destination information are stored, a master layer in which information regarding the platform of the master device is stored, and a target layer in which information regarding the platform of the target device is stored. The center device transmits, as repro - policy metadata indicating the configuration information of the distribution package, to the master device. When the master device interprets the repro - policy metadata and determines that it is a distribution package suitable for the host vehicle, the master device requests the center device for download metadata in which control information for acquiring necessary data corresponding to each of the three layers is stored. When the center device transmits the download metadata to the master device, the master device interprets the download metadata to acquire necessary data, and then performs data update control of the target device.

2. The repro - policy metadata includes, as parameters in the master layer, platform type information of the master device and control method type information of the platform. As parameters in the target layer, the repro - policy metadata includes platform type information of the target device, control method type information of the platform, and data transfer method type information from the center device to the target device. The in - vehicle communication system according to Claim 1, wherein the master device determines whether it is a distribution package suitable for the host vehicle by comparing each of the above - mentioned pieces of information with the design configuration information managed by itself.

3. The download metadata includes, as parameters for each layer, a URI (Uniform Resource Identifier) of a data acquisition source, a hash value assigned to the data, an ID of the target device, and data transfer method type information from the center device. As parameters in the master layer and the target layer, it includes platform type information of the master device and the target device. The in-vehicle communication system according to claim 2, wherein the master device acquires data required for each layer at a timing when the data is required based on each of the above information, and performs data update control of the target device.

4. The platform type information indicates any one of software architectures including an adaptive platform or a classic platform, which is the type of device defined in the AUTOSAR specification, as information regarding the software architectures of the master device and the target device. The in-vehicle communication system according to claim 2 or 3, wherein the data transfer method type information is either a storage method or a streaming method.

5. The in-vehicle communication system according to claim 4, wherein the platform type information further includes any one of in-vehicle Linux (registered trademark) and Android (registered trademark).

6. The in-vehicle communication system according to claim 4 or 5, wherein the center device designates a plurality of distribution packages when the data transfer method type information is the storage method in the master layer of the download metadata.

7. As communication destination information of the repro policy metadata, a mobile information terminal (42) or a portable storage medium can be set. The in-vehicle communication system according to any one of claims 1 to 6, wherein the master device can acquire the distribution package transmitted from the center device via the mobile information terminal or the portable storage medium according to the communication destination information.

8. The center device notifies the mobile information terminal of the information on the update data. When the user designates the transmission destination of the update data to the mobile information terminal or the portable storage medium via the mobile information terminal, the center device transmits the update data to the mobile information terminal or the portable storage medium. When the center device sets the communication destination information to the mobile information terminal or the portable storage medium, the center device sequentially transmits the repro policy metadata and the download metadata to the master device. The in-vehicle communication system according to claim 7, wherein the master device receives a distribution package from the mobile information terminal or the portable storage medium according to the communication destination information.

9. The master device writes information necessary for data update control of the host vehicle into the portable storage medium (44) via the in-vehicle device (43) to which the portable storage medium is connected. The portable information terminal (45) writes the repro policy metadata, the download metadata, and the corresponding distribution package obtained by accessing the center device based on the information written in the portable storage medium into the portable storage medium. The center device sets the communication destination information in the repro policy metadata in the portable storage medium. When the repro policy metadata and the download metadata are transferred from the in-vehicle device to which the portable storage medium is connected to the master device. The master device receives a distribution package from the portable storage medium according to the communication destination information. The in-vehicle communication system according to claim 7.

10. The download metadata includes, as parameters in the master layer and the target layer, encryption type information, signature type information, encryption mode type information, and encryption / signature target data type information. The encryption type information is any one of AES, Triple-DES, RSA, and ECC. The signature type information is any one of CBC-MAC, CMAC, DSA, and ECDSA. The encryption mode type information is any one of Enc then MAC, MAC then ENC, and ENC and MAC. The center device encrypts and signs the encryption / signature target data according to each of the above information. The master device decrypts the encryption / signature target data according to each of the above information. The in-vehicle communication system according to any one of claims 1 to 9.

11. The download metadata includes protection target information as parameters in the master layer and the target layer. The protection target information is information specifying whether the target to be encrypted and the target to which a digital signature is to be given are the entire distribution package or a part thereof. The center device encrypts and signs the encryption / signature target data according to the protection target information. The master device decrypts the encryption / signature target data according to the protection target information. The in-vehicle communication system according to any one of claims 1 to 10.

12. A target device (33), which is an electronic control device mounted on a vehicle, a center device (1) that transmits update data to the target device, a master device (32) mounted on the vehicle, which receives the update data as a distribution package and transfers the update data to the target device, and the target device (33) that writes the update data transferred from the master device into a storage unit. The vehicle-mounted communication system includes: The center device transmits repro policy metadata indicating configuration information of the distribution package to the master device. When the master device interprets the repro policy metadata and determines that it is a distribution package suitable for the host vehicle, the master device requests the center device for download metadata indicating information for acquiring update data of the target device. When the center device transmits the download metadata to the master device, the master device interprets the download metadata, acquires necessary data, and performs data update control of the target device.

13. The repro policy metadata includes at least a master layer in which information regarding the platform of the master device is stored, and a target layer in which information regarding the platform of the target device is stored. The in-vehicle communication system according to claim 12, wherein the download metadata stores control information for acquiring data required for each of the master layer and the target layer.

14. The in-vehicle communication system according to claim 12, wherein when interpreting the repro policy metadata, the master device compares information regarding the platform of the master device indicated by the repro policy metadata and information regarding the platform of the target device with design configuration information managed by itself to determine whether it is a distribution package suitable for the host vehicle.

15. The information regarding the platform of the master device includes the platform type information and the control method type information of the platform. The in-vehicle communication system according to claim 13, wherein the information regarding the platform of the target device includes the platform type information, the control method type information of the platform, and the data transfer method type information from the center device to the target device.

16. A target device (33), which is an electronic control device mounted on a vehicle, and a center device (1) that transmits update data to the target device. A master device (32) mounted on the vehicle, which receives the update data as a distribution package and transfers the update data to the target device. The center device transmits repropolicy metadata indicating configuration information of the distribution package to the master device. When the master device interprets the repropolicy metadata and determines that it is a distribution package suitable for the host vehicle, the master device requests download metadata indicating information for acquiring the update data of the target device from the center device. An in-vehicle communication system in which, when the center device transmits the download metadata to the master device, the master device interprets the download metadata to acquire necessary data and performs data update control including writing the update data to the storage unit of the target device.

17. A device that transmits update data as a distribution package to a target device (33), which is an electronic control device mounted on a vehicle. Transmits repropolicy metadata indicating configuration information of the distribution package to a master device (32) mounted on the vehicle, which receives the distribution package and transfers the update data to the target device. A center device that transmits the download metadata to the master device when requested by the master device for download metadata indicating information for acquiring the update data of the target device.

18. When transmitting update data as a distribution package to a target device, which is an electronic control device mounted on a vehicle. Transmits repropolicy metadata indicating configuration information of the distribution package to a master device mounted on the vehicle, which receives the distribution package and transfers the update data to the target device. A data transmission method in which, when requested by the master device for download metadata indicating information for acquiring the update data of the target device, the download metadata is transmitted to the master device.

19. A computer program executed by a computer that configures a center device that transmits a distribution package including update data to a target device, which is an electronic control device mounted on a vehicle. A three - layer structure consisting of a delivery layer that stores communication protocols and destination information, a master layer that stores information related to the platform of a master device that transfers the update data to the target device, and a target layer that stores information related to the platform of the target device. The repro policy metadata indicating the configuration information of the delivery package, and Download metadata that stores control information for acquiring data required for each of the three layers, which is used to generate Identify each item and data format of the repro policy metadata and the download metadata, Acquire data corresponding to each piece of information for generating the repro policy metadata and the download metadata, Generate the repro policy metadata as parameters in the master layer, including platform type information of the master device and control method type information of the platform, Generate it as parameters in the target layer to include platform type information of the target device, control method type information of the platform, and data transfer method type information from the center device to the target device, Generate the download metadata as parameters for each layer, including the URI (Uniform Resource Identifier) of the data acquisition source, the hash value assigned to the data, the ID of the target device, and the data transfer method type information from the center device, A metadata generation program that generates the master layer and the target layer so as to include platform type information of the master device and the target device as parameters.

20. Mounted on a vehicle together with a target device that is an electronic control device. When receiving a delivery package including update data from a center device (1), it transfers the update data to the target device. Receives repro policy metadata indicating the configuration information of the delivery package from the center device. When it determines that the repro policy metadata is a delivery package suitable for the host vehicle after interpreting it, it requests the center device for download metadata indicating information for acquiring the update data of the target device. A master device that, when receiving the download metadata from the center device, interprets the download metadata to obtain necessary data and performs data update control of the target device.

21. When receiving a distribution package including update data from a center device, transfer the update data to a target device which is an electronic control device mounted on a vehicle. When receiving repropolicy metadata indicating configuration information of the distribution package from the center device and determining that it is a distribution package suitable for the host vehicle by interpreting the repropolicy metadata, request the center device for download metadata indicating information for obtaining update data of the target device. A data update control method that, when receiving the download metadata from the center device, interprets the download metadata to obtain necessary data and performs data update control of the target device.

Images