CENTER DEVICE AND IN-VEHICLE ELECTRONIC CONTROL DEVICE

A center device includes an individual vehicle information DB which stores device identity information and information regarding a software architecture of the relevant device together with a vehicle category for each of a plurality of ECUs. In a PKG structure DB, for each of the plurality of ECUs, information regarding a structure of a package to be distributed for data update is stored according to a type of each of the ECUs. Based on the information stored in the individual vehicle information DB and the PKG structure DB, a determination unit identifies a package to be distributed for a target vehicle having a target device whose data is updated among the plurality of ECUs, and a PKG generation unit generates a package including the information indicating the structure of the identified package.

CROSS REFERENCE TO RELATED APPLICATION

The present application is based on and claims the benefit of priority of Japanese Patent Application No. 2021-032593, filed on Mar. 2, 2021, the disclosure of which is incorporated herein by reference.

TECHNICAL FIELD

The present disclosure generally relates to a center device that manages data to be written in a plurality of electronic control devices mounted on a vehicle, and an in-vehicle electronic control device that communicates with the center device.

BACKGROUND INFORMATION

In recent years, with the diversification of vehicle control such as driving assist control and autonomous driving control, the scale of application programs such as vehicle control and diagnosis installed in electronic control units (ECUs) of the vehicle is going up. In addition, the need to rewrite (or overwrite, or “reprog”) an application program of the ECU, is increasing due to many version upgrades for to functional improvements and the like.

A comparative example provides a technique of distributing an ECU update program from a server to an in-vehicle device by OTA (Over The Air) and rewriting the update program on the vehicle side.

Further, as shown inFIG. 14, regarding a package structure for distributing the update program according to an ECU platform, the specifications published by a general incorporated association JASPAR (Japan Automotive Software Platform and Architecture) define data requirements applicable to a classic platform (CP) running on a static OS (Operating System) of) of a standardization organization AUTOSAR (AUTomotive Open System ARchitecture). In addition, AUTOSAR defines data requirements applicable to new types of adaptive platform (AP) operable on dynamic operating system.

SUMMARY

It is an object of the present disclosure to provide a center device capable of distributing all update data in one package and to provide an in-vehicle electronic control device for use in a vehicle, which is updatable upon receiving the package of the update data, regardless of whether or not the in-vehicle electronic control devices of update target are mixture of different types.

DETAILED DESCRIPTION

The following describes an embodiment of the present disclosure with reference to the accompanying drawings. A vehicle program rewriting system is a system that can rewrite application programs such as vehicle control and diagnosis of an ECU mounted on a vehicle by OTA. As shown inFIG. 1, a vehicle program rewriting system1includes a center device3on a communication network2side, a vehicle-side system4on a vehicle side, and a display terminal5. A communication network2includes, for example, a mobile communication network using a 4G line or the like, the Internet, WiFi (Wireless Fidelity: registered trademark), and the like.

The display terminal5is a terminal having a function of accepting operation input from a user and a function of displaying various screens, and includes, for example, a mobile terminal6such as a smartphone or tablet that can be carried by the user, and an in-vehicle display7such as a display or a meter display that also provides a navigation function arranged in a vehicle interior to serve as a display device. The mobile terminal6can be connected to the communication network2as long as it is within a communication range of the mobile communication network. The in-vehicle display7is connected to the vehicle-side system4.

If the user is outside the vehicle interior and within the communication range of the mobile communication network, the user can input operations while checking various screens involved in the rewriting of the application program on the mobile terminal6, and can perform a procedure related to the rewriting of the application program. In the vehicle interior, the user can perform an operation input while checking various screens involved in the rewriting of the application program on the in-vehicle display7, and can perform a procedure related to the rewriting of the application program. That is, the user can property use the mobile terminal6and the in-vehicle display7outside the vehicle interior and inside the vehicle interior to perform procedures involved in rewriting the application program.

The center device3controls the functions of the OTA on the communication network2side in the vehicle program rewriting system1and functions as an OTA center. The center device3has a file server8, a web server9, and a management server10, and the servers8to10are configured to enable data communication with each other.

The file server8is a server, which has a management function of an application program transmitted from the center device3to the vehicle-side system4, for managing (i) ECU programs and relevant information provided by a supplier or the like which is a provider of application programs, (ii) distribution specification data provided by OEM (Original Equipment Manufacturer), and (iii) vehicle state obtained from the vehicle-side system4, and the like. The file server8can perform data communication with the vehicle-side system4via the communication network2, and, when a download request for a distribution package is generated, transmits, to the vehicle-side system4, a distribution package that packages a reprog data (for rewriting or overwriting) and distribution specification data. Alternatively, when a download request for the distribution package is generated, a distribution package in which the distribution specification data is packaged and the reprog data are transmitted to the vehicle-side system4. The web server9is a server that manages web information, and provides the mobile terminal6with various screens involved in rewriting the application program. The management server10manages personal information and the like of the user registered in an application program rewriting service, and manages an application program rewriting history and the like for each vehicle.

The vehicle-side system4has a master device11. The master device11includes a DCM (Data Communication Module)12and a central ECU13, and the DCM12and the central ECU13are connected to each other via a first bus14for data communication. The DCM12is an in-vehicle communication device that performs data communication with the center device3via the communication network2. When the distribution package is downloaded from the file server8, write data is extracted from the distribution package and transferred to the central ECU13. Alternatively, when the DCM12downloads the distribution package from the file server8, the DCM12transfers the distribution package to the central ECU13. The central ECU13extracts the write data from the distribution package.

The central ECU13is a vehicle gateway device having a data relay function, and when the write data is obtained from the DCM12, the write data is distributed to a rewrite target ECU that rewrites the application program. The master device11controls an OTA function on the vehicle side in the vehicle program rewriting system1, and functions as an OTA master. AlthoughFIG. 1illustrates a configuration in which the DCM12and the in-vehicle display7are connected to the first bus14, the DCM12and the in-vehicle display7may be connected to different buses. The central ECU13corresponds to a relay device of the present disclosure.

In addition to the first bus14, a second bus15, a third bus16, a fourth bus17, and a fifth bus18are connected to the central ECU13as buses inside the vehicle, and various types of ECUs19are connected via the buses15to17, and a power management ECU20is connected via the bus18.

The second bus15is, for example, a body-system network bus. The ECUs19connected to the second bus15are respectively, for example, an ECU that controls body system, such as a door ECU that controls door lock/unlock, a meter ECU that controls meter display, an air-conditioner ECU that controls drive of an air conditioner, a window ECU that controls window opening/dosing and the like. The third bus16is, for example, a drive-system network bus. The ECUs19connected to the third bus16are respectively, for example, an ECU that controls drive system, such as an engine ECU that controls drive of an engine, a brake ECU that controls drive of a brake, an ECT (Electronic Controlled Transmission) ECU that controls drive of an automatic transmission, and a power steering ECU that controls drive of a power steering.

The fourth bus17is, for example, a so-called MM network bus for accommodating a multimedia, e.g., video and sound. The ECUs19connected to the fourth bus17are respectively an ECU for handing multimedia, such as a navigation ECU for controlling a navigation system, an ETC ECU for controlling an ETC (Electronic Toll Collection System: registered trademark) system and the like. The buses15to17may be buses of a system other than the body-system network bus, the drive-system network bus, and the multimedia network bus. Also, the number of the buses and the ECUs19are not necessarily limited to the number described above. The power management ECU20is an ECU having a function of performing power management of the DCM12, the central ECU13, various ECUs19, and the like.

The sixth bus21is connected to the central ECU13as a bus outside the vehicle. A DLC (Data Link Coupler) connector22to which a tool23is detachably connected is connected to the sixth bus21. The buses14to18on the inside of the vehicle and the buses21on the outside of the vehicle are composed of, for example, CAN (Controller Area Network: registered trademark) buses, and the central ECU13performs data communication according to a CAN data communication standard or a diagnostic communication standard (UDS: ISO14229) with the DCM12, various ECUs19, and the tool23. Note that the DCM12and the central ECU13may be connected by Ethernet, or the DLC connector22and the central ECU13may be connected by Ethernet.

When a rewrite target ECU19receives the write data from the central ECU13, the rewrite target ECU19writes the write data in a flash memory and rewrites an application program. In the above configuration, when the central ECU13receives a write data acquisition request from the rewrite target ECU19, the central ECU13functions as a reprog master that distributes the write data to the rewrite target ECU19. When the rewrite target ECU19receives the write data from the central ECU13, the rewrite target ECU19functions as a reprog slave that writes the write data to the flash memory and rewrites the application program. Note that the “rewrite target ECU” may be referred to as a “target ECU.”

Modes of rewriting the application program include a mode of rewriting by wire and a mode of rewriting by wireless. In the mode of rewriting the application program by wire, when the tool23is connected to the DLC connector22, the tool23transfers the write data to the central ECU13. The central ECU13relays or distributes the write data transferred from the tool23to the rewrite target ECU19. In the mode of wirelessly rewriting the application program, as described above, when the DCM12downloads the distribution package from the file server8, the DCM12extracts the write data from the distribution package and transfers the write data to the central ECU13.

As shown inFIG. 2, the center device3which is also a package generation server includes a controller30and databases41to46. In the following, “database” may be referred to as “B.” In addition, “package” may be referred to as “PKG.” In addition, “software package” may be referred to as “SW PKG.” The controller30has functional blocks such as an information storage unit31, a determination unit32, a PKG generation unit33, and a verification data generation unit34, which are realized by the functions of hardware and software provided by a microcomputer.

Next, the contents of the data registered in each of databases41to46are described. The individual vehicle information DB41mainly registers configuration information for each of the vehicles and status information of each of the vehicle with respect to program update. Specifically, for an ID of each vehicle “VIN”, the configuration information is registered such as “Vehicle SW ID”, “System ID”, “ECU ID”, “ECU SW ID” and the like. A “Digest” value, which is a hash value for the configuration information, is also calculated and stored in the center device3. An “operation bank” is a bank in which a program currently operated by the ECU19is written when a memory has two-bank configuration having two banks, and an uploaded value that is uploaded together with the configuration information is registered. The ID of each vehicle is vehicle identification information, and may be a chassis number instead of VIN.

The following ECU-specific specification data is registered in the ECU metadata DB42, for example. That is, for the latest “ECU SW ID”, the following is registered as the specification data: the size of a update data file, the size of a rollback data file, bank information indicating which of bank A, bank B, bank C and the like the program is for when the flash memory provided in the ECU19has two-or-more-bank configuration, transfer size, read address for reading the program file, etc. These are examples of update data related information.

In addition, attribute information indicating the attributes of the ECU19is also registered in the ECU metadata DB42. The attribute information is information indicating hardware attributes and software attributes related to the ECU. The “transfer size” is a transfer size (of a divided portion of the data) when the rewrite data is divided and transferred from the central ECU13to the ECU19, and a “key” is a key used when the central ECU13securely accesses the ECU19. These are examples of the software attribute information. Further, regarding the “vehicle model” and the “ECU ID”, memory configuration of a flash memory28dincluded in the ECU19, the category of bus to which the ECU19is connected, the type of the power supply connected to the ECU19, and the like are also included. These are examples of the hardware attribute information. The package DB43registers IDs of the distribution package, files of the distribution package, and data for verifying integrity of the distribution package.

As shown inFIG. 3, the configuration information DB45registers, for each vehicle model, a platform of the central ECU13, an ID of the target ECU19, an update method for platform and the reprog. The configuration information DB corresponds to a vehicle information storage unit. In the following, a platform may be referred to as “PF”. The “vehicle model” is an ID of each vehicle specified according to a vehicle type, release date, grade of the vehicle, destination, and the like. The “vehicle model” corresponds to a category of the vehicle. The distribution package for distributing the update program may be structured as two types, i.e., a package applicable to a CP operable on a static OS defined in the AUTOSAR specifications and a package applicable to an AP operable on a dynamic OS.

Here, the difference between AP and CP is described. AP and CP represent software platforms. Software platform may also be called software architecture. CP stands for AUTOSAR Classic Platform and AP stands for AUTOSAR Adaptive Platform. Further, an ECU that operates in accordance with the CP specifications may be referred to as a CP ECU or an ECU for CP, and an ECU that operates in accordance with the AP specifications may be referred to as an AP ECU or an ECU for AP.

The operating system, the so-called OS, and development language is different for AP and CP. The CP ECU and AP ECU have different receivable package structures (i.e., receive differently-structured package data). The difference in the structure of the packages is mainly due to the difference in the processing performance of the ECU, and since the processing performance of the ECU for CP is generally low, the specification data included in the package for CP ECU is described as binary data, realizing package data structure of easy interpretation/processing by an ECU with low processing performance.

On the other hand, since the AP ECU generally has high processing performance, which allows the AP ECU to have a parser function that analyzes structural character data written in programming language and converts it into a data structure that is handlable by a program, the package data structure is not a simple binary data, but an object-oriented data format such as JSON (JavaScript Object Notation), which realizes flexible package data structure.

Regarding the update of the application program, there are two methods: a storage method in which all the update programs are downloaded from the center device3to 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 device3to the vehicle side.

In an example shown inFIG. 3, the central ECU13of a vehicle model A has an AP and the IDs of the target ECU19are “1 to 4”, and the PFs of the target ECUs are a mixture of AP and CP. Regarding the update method. ID1and ID2are streaming methods, and ID3and ID4are storage methods. The central ECU13of the vehicle model B has a CP, the IDs of the target ECU19are “5 to 8”, and the PFs of the target ECUs are a mixture of AP and CP. Regarding the update method, IDS and ID6are streaming methods, and ID7and ID8are storage methods. The above update method may be referred to as an OTA (Over The Air) method.

Initial values are registered in the configuration information DB45at the time of production or sale of the vehicle, and the registered information is subsequently updated as the version of the application program of any one or more ECUs is updated. That is, the configuration information DB45shows the configuration information that normally exists in the market for each vehicle model.

As shown inFIG. 4, eight types Nos.1to8are registered as package structures in the PKG structure DB44. The PKG structure D844defines (i) the configurations of the package distributed from the center device3to the vehicle-side system4when the application program is rewritten, and (ii) the file distributed without being included in the package. In Nos.1to4, the PF of the central ECU13is AP, and in Nos.5to8, the PF of the central ECU13is CP. In Nos.1,2,5, and6, the PF of the target ECU19is AR and in Nos.3,4,7, and8, the PF of the target ECU19is CP. Nos.1,3,5, and7have an OTA method of “storage,” and Nos.2,4,6, and8have an OTA method of “streaming.”

The configuration of the package and the file distributed without being included in the package are determined based on the PF of the central ECU13, the PF of the target ECU19, and the OTA method from the central ECU13to the target ECU19. As described above, the PF of the central ECU13includes a case where the central ECU13is an AP ECU and a case where the central ECU13is a CP ECU. Similarly, the PF of the target ECU19includes a case where the target ECU19is an AP ECU and a case where the target ECU19is a CP ECU.

When the PF of the central ECU13is AP, a Vehicle PKG is included so that a UCM (Update Configuration Management software module) master in the central ECU13can interpret it. On the other hand, when the PF of the central ECU13is CP, the specification data, the file configuration information, and the verification data are included so that the OTA master in the central ECU13can interpret them. Further, when the PF of the target ECU19is AP, a software package (also referred to as Software PKG or SW PKG) is included so that a UCM (Update Configuration Management software module) in the target ECU19can interpret it. The UCM may be referred to as UCM subordinate.

When the PF of the target ECU19is CP, the specification data, the file configuration information, and the verification data are included so that the installer can interpret them. Since the UCM master and UCM are explained in AUTOSAR, some details are omitted, but some details are discussed below. Further, since the OTA master and the installer are explained in the JISPAR standard document, some details are discussed below.

Further, when the OTA method is streaming, the update data is not included in the package. On the other hand, when the OTA method is storage, the update data is included in the package. The PKG structure DB44represents a data format required for updating the application program of the target ECU13for each of the target ECUs13, that is, a package configuration, a file distributed without being included in the package, and the like.

Here, the package distributed to each vehicle is composed of an integrated package and attachment files not included in the integrated package. In Nos.1to4in which the central ECU13is an AP, the integrated package includes a vehicle package described as “Vehicle PKG” in the drawing. Nos.1,2,5, and6in which the target ECU19is an AP include a software package described as “SW PKG” in the drawing. However, in Nos.1and5where the OTA method is storage, the software package is included in the integrated package, but in Nos.2and6, the software package is not included in the integrated package and is a separate file. The integrated package is distributed to the vehicle system4as a compressed file, and the attachment files are distributed to the vehicle system4uncompressed.

A software package is a unit of installation processing performed by an ECU, and includes, for example, an executable file of one or more applications developed on an AP, an OS or firmware update file, configuration data, calibration data, and the like. Each package contains manifest information that supplies metadata such as package name, version information, dependencies, and vendor-specific information required for package processing. The UCM (Update Configuration Management), which is a software module mounted on the target ECU19, processes a vendor-specific software package based on the metadata. Note that “SW PKG A. B” shown in the drawing shows two packages as an example, and may also be one package or may also be three or more packages.

As shown inFIG. 5, software packages are supplied to OEMs by various suppliers. In an OEM server, a backend package is generated corresponding to each package. The backend package includes a software package, and information such as a diagnostic address and ID of the UCM to which the package is distributed is added to the manifest information. Then, a vehicle package is generated from a plurality of backend packages. Multiple software packages required for each vehicle are integrated, and the vehicle package has a vehicle package manifest added to the manifest of each software package.

The vehicle package manifest includes information necessary to control and distribute campaigns distributed to vehicles as notifications that data update is ready, such as dependencies, target vehicles, safety policies, driver notification settings, and the like. The UCM master, which is a software module mounted on the central ECU13, controls which software package is transferred to which UCM and in what order, when (i.e., after) the updated contents of data are grasped by Interpreting the vehicle package. Then, the UCM interprets the software package passed from the UCM master, and executes the installation process of the target ECU19.

Note that the drawing inFIG. 5is quoted from pages50,52, and53of “Specification of Update Configuration Management AUTOSAR AP R20-11, Document ID No.706”. The same applies to a diagram of the package structure for AP shown inFIG. 14.

InFIG. 4, in Nos.3,4,7, and8in which the target ECU19is a CP, the integrated package includes specification data, file configuration information, and various verification data as needed. Further, difference data, which is a difference between the update data and the pre-update data, is included in the integrated package in Nos.3and7where the OTA method is storage, but is not included in the integrated package in No.4and8where the OTA method is streaming, i.e., is provided as a separate file.

The file configuration information (DCM specifications) is (i) information that associates the file name (FILE) with its role (TYPE) and the target ECU19(ECU-ID), (ii) information that identifies which data has which binary file name (xxxxxxxx.bin), and the like. The OTA master on the vehicle side determines, by interpreting the file configuration information, (i) which binary file plays which role (for example, specification data or the like), (ii) to which target ECU19the binary files should be transferred, and the like.

The following programs and data are registered in the ECU repro data DB46, for example. Regarding the latest “ECU SW ID” of the update target ECU19, an old and new program files of the ECU, the integrity verification data of the new program, the update data file which is the difference data between the new program and the old program, and the integrity verification data of the update data, the rollback data file, which is also difference data, the integrity verification data of the rollback data, and the like are registered in the ECU repro data DB46. The integrity (or validity) verification data is a hash value obtained by applying a hash function to the data value.

The following describes an operation of the present embodiment. As shown inFIG. 6, when the information storage unit31of the center device3starts the registration of the vehicle model, the information storage unit31registers the Information on the software architecture in the configuration information DB45for the PF of each ECU mounted on a new vehicle model (S1). Further, when the information storage unit31starts the registration of a package structure model, if a new PF exists, the information storage unit31registers a package structure corresponding to the PF in the PKG structure DB44(S2).

Further, as shown inFIG. 7, when the information storage unit31collects vehicle information about a sold vehicle, if it is detected that a new hardware device such as LiDAR (Light Detection And Ranging) is added to the vehicle (S3; Yes), the information of the detected device is registered in the configuration information DB45and the information is synchronized (with the center device3) (S4).

As shown inFIG. 8, when the determination unit32starts a distribution package generation process, the determination unit32obtains the information of the distribution target vehicle (S11). The distribution target vehicle can be obtained by comparing the information of the vehicle registered respectively in the individual vehicle information DB41and the configuration information DB45. For example, for the vehicle model B shown inFIG. 3, it is assumed that the software of the target ECU19having ID=5, 6 has an update.

Next, the determination unit32searches the configuration information DB45, and identifies the software architecture of the update target vehicle model (S12). For example, regarding the vehicle model B described above, the software architecture of the target ECU19with ID=5 and 6 is respectively identified as structure No.6and8. Subsequently, the PKG structure DB44is searched, and the package structure to be generated for the update target vehicle model is identified (S13). Then, the determination unit32instructs the PKG generation unit33to generate the package corresponding to the structure Nos.6and8.

Upon receiving the package generation processing request, the PKG generation unit33generates an integrated package from the identified package structure (S14). Here, the “integrated package” itself and a method of constructing the “integrated package” are described with reference toFIG. 9. Note that the structure Nos.6and8ofFIG. 9correspond to the package structures in Nos.6and8ofFIG. 4.

For the vehicle model B shown inFIG. 3, when the software is going to be updated for the target ECUs19with ID=5 and 6, the information for the target ECU19with ID=5 and ID=6 needs to be distributed from the center device3to the vehicle side system4as one integrated package. Note that, in the storage method, the integrated package includes (i) the update data file which are the difference data between the new program and the old program and (ii) the software package. In the streaming method, the update data file, which is the difference data between the new program and the old program, and the software package are not included in the integrated package.

InFIG. 9, respective package structures corresponding to the structure Nos.6and8shown in an upper row is integrated into one package structure as shown in a lower row. This is called an integrated package structure. For a data item existing in both of the structures Nos.6and8, that is, the specification data for example, such an overlapping item is integrated as one item in the integrated package structure. In addition, a flag indicating that the integrated package is an integration of the structure Nos.6and8is added to the specification data. In such case, since the OTA method is streaming for both of the structure Nos.6and8, the software packages A and8and the difference data1and2are files not included in the integrated package.

Description ofFIG. 8resumes. Next, the PKG generation unit33obtains information required for generating a package from the ECU repro data DB46and the ECU metadata DB42(S15). Here, the “required information” is, for example, specification generation data, manifest generation data, design configuration information, package generation conditions, difference data, verification data, and the like. Then, an update software package is generated (as an integrated package) (S16).

Subsequently, the verification data generation unit34determines whether or not a package whose OTA method is streaming is included (S17), and if it is included (S17:Yes) MAC (Message Authentication Code) signature process is performed (S18), and if it is not included (S17:No), a digital signature of the update data is calculated and given/added to the package (S19). Then, the generated package is registered in the package DB43(S20).

As shown inFIG. 10, when the verification data generation unit34starts the MAC signature process, if addition of the verification data to the streaming data is required (S21; Yes), the size of a relay buffer used for streaming is confirmed (S22), the MAC signature is calculated for data of buffer size (S23), and the MAC signature is given to the some data of having a size associated with a buffer size of the relay buffer (S24). For example, when the size of the relay buffer is 10 kB and AES (Advanced Encryption Standard) 126 bits is adopted as the common key encryption method for MAC signature, 16 bytes of signature data are added for every 10 kB.

Next, the processing on the vehicle-side system4side that performs the reprog according to the distributed package is described. Steps S31to S35are substantially the same among the processing inFIG. 11in which the central ECU13is an AP and the processing inFIG. 12in which the central ECU13is a CR When a distribution package is received from the center device3(S31), flag information of the package structure stored in the specification data is read (S32). Note that, when the central ECU13is an AP, the information corresponding to the specification data is included in the manifest included in each of the software package and the vehicle package.

Subsequently, when the package structure is identified based on the flag information (S34), the program is updated and the reprog is performed for respective platforms and OTA methods of the target ECUs19in each of the package structures (S35). From here, when the central ECU13is an AP, the process branches as steps S36(1) to S36(4) according to the package structure Nos.1to4, and when the central ECU13is a CP, the process branches as steps S36(5) to S36(8) according to the package structure Nos.5to8.

In step S36(1), the rewriting is performed as the one when the combination of the central-target ECU is AP-AP and the OTA method of the target ECU19is storage. In such case, the update is performed by the UCM master/UCM according to a procedure described in the AUTOSAR Specification (SWS) (S37(1)). In step S36(2), the rewriting is performed as the one when the combination is AP-AP and the OTA method is streaming, and steps S38to S45shown inFIG. 13to be described later are performed.

In step S36(3), the rewriting is performed as the one when the combination is AP-CP and the OTA method is storage. In such case, the update is performed by the UCM master and a flushing adapter according to a procedure described in the AUTOSAR Specification (SWS) (S37(3)). In step S36(4), the rewriting is performed as the one when the combination is AP-CP and the OTA method is streaming, and the process proceeds to step S37(3).

In step S36(5) shown inFIG. 12, the rewriting is performed as the one when the combination is CP-AP and the OTA method is storage. In such case, the update is performed by UCM according to the procedure described in the AUTOSAR Specification (SWS) (S37(5)). In step S36(6), the rewriting is performed as the one when the combination is CP-AP and the OTA method is streaming, and steps S38to S45are performed.

In step S36(7), the rewriting is performed as the one when the combination is CP-CP and the OTA method is storage. In such case, the OTA master performs update according to the procedures described in paragraphs [0381] to [0400] and FIGS. 115 to 118 in a Japanese Patent application of JP-A-2020-27633 (S37(7)). In step S36(8), the rewriting is performed as the one when the combination is CP-CP and the OTA method is streaming, and steps S38to S45are performed.

In step S38shown inFIG. 13, if the verification data of streaming data is required (S38:Yes), a common key A used for signing the streaming is received by key-exchange with the center device3(S39). Then, when the streaming data is received by the size of the relay buffer (S40), the MAC signature is verified using the common key A for the data of buffer size (S41).

If the verification is successful (S42:Yes), the streaming data is transferred to the target ECU19(S43) Then, the process returns to step S40and the process is repeated until all the repro data is received (S44:No). If the verification fails in step S42(S42:No), an error is returned to the center device3(S45).

As described above, according to the present embodiment, the individual vehicle information DB41of the center device3stores the device identity and the information regarding the software architecture of the relevant device together with the vehicle category for each of the plurality of ECUs19. In the PKG structure DB44, for each of the plurality of ECUs19, the information regarding the structure of the package to be distributed for updating the data is stored according to the type of each of the ECUs19.

Based on the information stored in the individual vehicle information DB41and the PKG structure DB44, the determination unit32identifies a package to be distributed for a target vehicle having a target device whose data should be updated among the plurality of ECUs19. Then, the PKG generation unit33generates a package including the information indicating the structure of the identified package.

With such a configuration, the PKG generation unit33can generate a package to be distributed to the target vehicle as the one having an appropriate structure corresponding to the software architecture of the target device, even when various types of ECUs19having different structures are mounted on the target vehicle. Therefore, even for vehicles in which different types of ECUs19are mixed, all the updated data can be distributed in one package.

Further, the information indicating the structure of the package includes information indicating that (i) the platform type is either AP or CP, which is the platform type of the ECU19defined in the AUTOSAR specifications, and (ii) the OTA method for updating the data is one of the storage method or the streaming method. With such a configuration, it is possible to generate a distribution package corresponding to each of the vehicles in which the ECUs19having different platform types and data update methods are mixed.

Further, when the type of the central ECU13that relays data for the target ECU19to update the data is AP, the PKG generation unit33generates a package having a structure that is processable by the UCM master, and when the type of the central ECU13is CP, generates a package having a structure that is processable by the OTA master. Therefore, an appropriate distribution package can be generated according to the type of the central ECU13defined by AUTOSAR.

Further, the PKG generation unit33generates a package having a structure that is processable by the UCM when the type of the target ECU19is AP, and generates a package having a structure that is processable by the installer when the type of the target ECU19is CR Therefore, an appropriate distribution package can be generated according to the type of the target ECU19.

Further, the PKG generation unit33generates an integrated package including update data when the OTA method is a storage method, and generates an integrated package not including update data when the OTA method is a streaming method. Therefore, an appropriate distribution package can be generated corresponding to the OTA method of each of the target ECUs19. In addition, when the OTA method is the streaming method, in order to verify the validity of the data, the verification data MAC-signed by the common key encryption method is added, so the validity of the data can be securely performed on the vehicle side.

On the other hand, the central ECU13of the vehicle-side system4determines, from the information included in the distribution package received from the center device3, whether (i) the platform of each ECU is either AP or CP, and (ii) the OTA method is the storage method or streaming method, and switches the processing of the distribution package according to the identified PF and method. Therefore, it is possible to perform a reprog of each target ECU19or the like according to the information included in the distribution package.

Further, if the OTA method is a streaming method, the central ECU13obtains a common key from the center device3and verifies the validity of the received data by MAC signature using the common key encryption method. Further, when a new hardware device is added to the vehicle, the central ECU13transmits the information of the new device to the center device3, and the center device3adds the device to the information of the corresponding vehicle in the individual vehicle information DB41, thereby update of the information of the individual vehicle information DB41can be updated in response to a case where the hardware device is added to the vehicle in the aftermarket.

Other Embodiments

The PF of the ECU is not limited to AP and CP, and may correspond to other PFs. Verification by MAC signature using common key encryption method may be performed as required. The signature is not limited to the MAC signature. When it is detected that a new hardware device or the like has been added to the vehicle as shown inFIG. 7, the process of registering the device information in the configuration information DB45may be performed as required.

The integrated package may be generated as follows. The PKG generation unit33analyzes the structure of the package identified by the determination unit32, and if it is different from the package structure stored in the PKG structure DB44, the PKG generation unit33may generate an integrated package structure including data items that are included in at least one of package structures, and may generate one integrated package for a plurality of target devices based on the generated integrated package structure.

FIG. 15illustrates the integrated package structure and the method of generating the integrated package. First, in S11, as described above, the information of the distribution target vehicle is obtained. The target ECU19to be updated is identified. In S51, it is determined whether or not there are a plurality of target ECUs19to be updated. If there are not a plurality of target ECUs19(S51:No), an integrated package is not constructed. When it is determined that there are a plurality of target ECUs19(S51:Yes), the PF of the target ECU19, the update method, and the PF of the central ECU13are identified in S52based on the ID of the target ECU19. The determination unit32searches the configuration information DB45to identify the software architecture of the update target vehicle model.

In S53, referring to the PKG structure DB44, the corresponding package structure, that is, the PKG structure No. is identified based on the PF of the target ECU19, the update method, and the PF of the central ECU13. For each of the plurality of target ECUs19, the package structure required by the central ECU13and the target ECU19is identified for updating the application program.

In S54, it is determined whether or not there are a plurality of package structures. When a plurality of target ECUs19are updated but one type of package structure is used (S54: No), the process proceeds to S55. In such case, the package structure stored in the PKG structure DB44becomes the integrated package structure.

In S55, a flag is added to the data to form an integrated package so that the vehicle-side system4can determine to which target ECU19the data is designated. Assuming that the package structure corresponding to the two target ECUs19is the structure No.6. In such case, there are specification data for updating the application program of a first target ECU19and specification data for updating the application program of a second target ECU19. Thus, a flag is added to each of the specification data.

If there are a plurality of package structures (S54:Yes), the process proceeds to S56to generate an integrated package structure. The integrated package structure is, for example, a package structure shown in the lower part ofFIG. 9. The integrated package structure is a package structure that is not included in the PKG structure DB44shown inFIG. 4. The integrated package structure is generated when there are a plurality of target ECUs19and the package structure with respect to the target ECUs19is different among the plurality of target ECUs19.

In S56, data items constituting the package structure are extracted for a plurality of package structures to be integrated. In the example shown inFIG. 4, Vehicle PKG, SW PKG, specification data, file configuration information, verification data, difference data, and the like correspond to data items. In the example shown inFIG. 9, SW package manifest, SW package manifest verification data, specification data, specification data verification data, file configuration information, file configuration information verification data. RXSWIN before update, RXSWIN before update verification data, RXSWIN after update, RXSWIN after update, RXSWIN after update verification data, difference data verification data, and the like correspond to data items.

Further, in S56, the data items of the integrated package structure are set. The data items included in the integrated package structure are, respectively, a data item included in at least one package structure among the plurality of package structures. In such manner, an integrated package structure is generated. In S57, the corresponding data is extracted from a plurality of packages for each of the data items, and an integrated package is generated. The PKG generation unit33obtains the information required for generating the package from the ECU repro data DB46and the ECU metadata DB42. A flag is added so that the vehicle-side system4can determine which package or which target ECU19the data is destined/designated for.

By performing the above steps, a plurality of packages for the plurality of target ECUs19are generated as one integrated package regardless of whether the structures of the packages are the same or different. Since the processing after S57is the same as the processing after S17inFIG. 8, the description is omitted.

The means and/or functions provided by each device or the like can be provided by software recorded in a substantive memory device and a computer that executes the software, software only, hardware only, or a combination thereof. For example, if the control device is provided by an electronic circuit that is hardware, the control device may be provided by a digital circuit or an analog circuit that includes a large number of logic circuits. While the present disclosure has been described in accordance with the embodiment, it is understood that the present disclosure is not limited to such embodiments or structures. The present disclosure also encompasses various modified examples and modifications within a range of equivalence. In addition, various combinations and forms, as well as other combinations and forms including only one element, more than that, or less than that, are also within the scope and idea of the present disclosure.

The controller and the method thereof 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 controller and the method described in the present disclosure may be realized by a dedicated computer configured as a processor with one or more dedicated hardware logic circuits. Alternatively, the controller and the method thereof described in the present disclosure may be realized as one or more dedicated computers configured as a combination of (i) a processor and memory programmed to perform one or more functions and (ii) a processor composed of one or more hardware logic circuits. The computer programs may be stored, as instructions to be executed by a computer, in a tangible, non-transitory computer-readable storage medium.