Vehicle system, data communication system, processing target identification program, processing target identification method, out-of-vehicle device, identification information distribution program, and identification information distribution method

Abstract

A vehicle system (3) comprises a vehicle-side identification information storage unit (31) that stores processing target identification information that indicates the association between processing instructions based on messages or files in an SOVD format and connection destination information that makes it possible to identify processing targets that correspond to the processing instructions, a processing instruction reception unit (32) that receives processing instructions, and a processing target identification unit (33) that, when a processing instruction has been received by the processing instruction reception unit, references the processing target identification information and identifies a processing target that corresponds to the received processing instruction on the basis of the connection destination information.

Description

Vehicle system, data communication system, processing target specifying program, processing target specifying method, external vehicle device, specific information distribution program, and specific information distribution method CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is based on Japanese Application No. 2023-185581 filed on October 30, 2023, the contents of which are incorporated herein by reference.

[0002] The present disclosure relates to a vehicle system, a data communication system, a processing target specifying program, a processing target specifying method, an external vehicle device, a specific information distribution program, and a specific information distribution method.

[0003] For example, with the diversification of vehicle control, such as driving assistance functions and autonomous driving functions, OTA (Over The Air) repro technology has been provided, which wirelessly updates software installed in a vehicle's electronic control unit (hereinafter referred to as ECU (Electronic Control Unit)). In OTA repro, an OTA master on the vehicle distributes software downloaded from an OTA center to an ECU to be updated, and instructs the ECU to update the software, causing the ECU to update the software.

[0004] Japanese Patent Application Laid-Open No. 2020-27627

[0005] With the introduction of high-performance computers (HPCs), the technology of service-oriented vehicle diagnostics (SOVD) is being provided as a next-generation diagnostic function. In the SOVD service, when an OTA center requests an OTA master to read ECU information from a vehicle, the OTA center transmits a read instruction to the OTA master without specifying which ECU is to be read. Therefore, unless the OTA master specifies which ECU is to be read, the OTA master cannot collect ECU information specified by the read instruction from the OTA center. In other words, when the OTA master receives a read instruction from the OTA center, the OTA master needs to specify which ECU is to be read.

[0006] Such a situation is not limited to cases where ECU information on the vehicle side is read, but is also expected when, for example, data is written to the ECU, and is also expected when the SOVD service is other than OTA repro, such as diagnosis or log collection. Furthermore, such a situation is not limited to cases where the SOVD format is applied to center-to-center communication between the OTA center and the vehicle side, but is also expected when, for example, the SOVD format is applied to data communication between the vehicle side and an external device in proximity that is wired to the vehicle side, or when the SOVD format is applied to data communication between an in-vehicle app or the like and other elements in the vehicle.

[0007] The present disclosure aims to appropriately identify the processing target corresponding to a processing instruction when a processing instruction based on a message or file in SOVD format conforming to the SOVD communication specifications is received, and to appropriately realize the SOVD service.

[0008] According to one aspect of the present disclosure, a vehicle system acquires a message or file in SOVD format conforming to SOVD communication specifications. A vehicle-side identification information storage unit stores processing target identification information indicating an association between a processing instruction based on the SOVD format message or file and connection destination information capable of identifying a processing target corresponding to the processing instruction. A processing instruction receiving unit receives the processing instruction. When the processing instruction is received by the processing instruction receiving unit, the processing target identification unit references the processing target identification information and identifies a processing target corresponding to the received processing instruction based on the connection destination information.

[0009] According to one aspect of the present disclosure, a data communication system includes an external device that distributes messages or files in an SOVD format conforming to SOVD communication specifications, and a vehicle system that receives the SOVD-formatted messages or files distributed from the external device. In the vehicle system, a vehicle-side identification information storage unit stores processing target identification information that indicates an association between a processing instruction based on the SOVD-formatted message or file and connection destination information that can identify a processing target corresponding to the processing instruction. A processing instruction reception unit receives the processing instruction. When the processing instruction reception unit receives the processing instruction, the processing target identification unit references the processing target identification information and identifies a processing target corresponding to the received processing instruction based on the connection destination information.

[0010] According to one aspect of the processing target identification program of the present disclosure, a control unit of a vehicle system that holds processing target identification information indicating an association between a processing instruction based on a message or file in SOVD format conforming to the SOVD communication specifications and connection destination information that can identify a processing target corresponding to the processing instruction is caused to execute a processing instruction acceptance procedure for accepting a processing instruction based on the message or file in SOVD format, and a processing target identification procedure for, when the processing instruction is accepted by the processing instruction acceptance procedure, referring to the processing target identification information and identifying a processing target corresponding to the accepted processing instruction based on the connection destination information.

[0011] According to one aspect of the processing target identification method of the present disclosure, in a vehicle system that holds processing target identification information indicating an association between a processing instruction based on a message or file in SOVD format that conforms to the SOVD communication specifications and connection destination information that can identify the processing target corresponding to the processing instruction, the system performs a processing instruction acceptance procedure that accepts the processing instruction based on the message or file in SOVD format, and a processing target identification procedure that, when the processing instruction is accepted by the processing instruction acceptance procedure, refers to the processing target identification information and identifies the processing target corresponding to the accepted processing instruction based on the connection destination information.

[0012] According to one aspect of the present disclosure, processing target identification information indicating an association between a processing instruction based on a message or file in SOVD format conforming to the SOVD communication specifications and connection destination information capable of identifying a processing target corresponding to the processing instruction is maintained. When a processing instruction based on a message or file in SOVD format is accepted, the processing target corresponding to the accepted processing instruction is identified based on the connection destination information by referencing the processing target identification information. When a processing instruction based on a message or file in SOVD format conforming to the SOVD communication specifications is accepted, the processing target corresponding to the accepted processing instruction can be appropriately identified, thereby enabling the SOVD service to be appropriately realized.

[0013] According to one aspect of the present disclosure, an external vehicle device distributes a message or file in an SOVD format conforming to the SOVD communication specifications to a vehicle system. An external vehicle identification information storage unit stores processing target identification information indicating an association between a processing instruction based on the SOVD format message or file and connection destination information capable of identifying a processing target corresponding to the processing instruction. A identification information distribution unit distributes the processing target identification information stored in the external vehicle identification information storage unit to the vehicle system.

[0014] According to one aspect of the specific information distribution program of the present disclosure, a message or file in SOVD format conforming to the SOVD communication specifications is distributed to a vehicle system, and an external device that holds processing target specific information indicating an association between a processing instruction based on the SOVD format message or file and connection destination information that can identify a processing target corresponding to the processing instruction is caused to execute a specific information distribution procedure to distribute the processing target specific information to the vehicle system.

[0015] According to one aspect of the specific information distribution method of the present disclosure, a message or file in SOVD format conforming to the SOVD communication specifications is distributed to a vehicle system, and an external device that holds processing target specific information indicating an association between a processing instruction based on the SOVD format message or file and connection destination information that can identify a processing target corresponding to the processing instruction performs a specific information distribution procedure to distribute the processing target specific information to the vehicle system.

[0016] According to one aspect of the present disclosure, processing target identification information indicating an association between a processing instruction based on a message or file in SOVD format and connection destination information capable of identifying a processing target corresponding to the processing instruction is stored, and the processing target identification information is distributed to a vehicle system. By using the processing target identification information distributed from an external device, when a processing instruction based on a message or file in SOVD format conforming to the SOVD communication specifications is received in the vehicle system, the processing target corresponding to the received processing instruction can be appropriately identified, and the SOVD service can be appropriately realized.

[0017] The above and other objects, features, and advantages of the present disclosure will become more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which Fig. 1 is a diagram showing the overall configuration of a first embodiment, Fig. 2 is a functional block diagram of an update master, Fig. 3 is a diagram explaining format conversion, Fig. 4 is a diagram showing an HTTP method used in the SOVD format, Fig. 5 is a diagram explaining format conversion from the SOVD format to the UDS format, Fig. 6 is a diagram explaining format formation, Fig. 7 is a flowchart showing processing during download at the OTA center, Fig. 8 is a flowchart showing processing during download at the CGW, Fig. 9 is a flowchart showing processing during upload at the OTA center, Fig. 10 is a flowchart showing processing during upload at the CGW, Fig. 11 is a diagram showing the overall configuration of a second embodiment, Fig. 12 is a functional block diagram of a processing target identification table management unit, Fig. 13 is a diagram showing a processing target identification table, Fig. 14 is a diagram showing an overall sequence, and Fig. 15 is a diagram showing the overall configuration of a third embodiment. is a diagram showing routing, FIG. 16 is a diagram showing a message in SOVD format, FIG. 17 is a functional block diagram of the update master, FIG. 18 is a functional block diagram of the OTA center, FIG. 19 is a diagram showing the configuration of the processing target identification table, FIG. 20 is a flowchart showing processing by the CGW, FIG. 21 is a flowchart showing processing by the CGW, FIG. 22 is a flowchart showing processing by the CGW, FIG. 23 is a flowchart showing processing by the CGW, FIG. 24 is a flowchart showing processing by the OTA center, FIG. 25 is a functional block diagram, FIG. 26 is a diagram showing each functional block, FIG. 27 is a diagram showing an overview of SOVD, FIG. 28 is a diagram showing a one-to-one conversion execution unit, FIG. 29 is a diagram showing details of the one-to-one conversion execution unit, FIG. 30 is a diagram showing the relationship with the OTA center, FIG. 31 is a diagram showing a one-to-many conversion execution unit, and FIG. 32 is a diagram showing the one-to-many conversion execution unit.

[0018] Hereinafter, several embodiments will be described with reference to the drawings. In the subsequent embodiments, the description of parts that overlap with the preceding embodiments may be omitted.

[0019] First Embodiment A first embodiment will be described with reference to FIGS. 1 to 10 . As shown in FIG. 1 , a data communication system 1 includes an OTA (Over The Air) center 2 (corresponding to an external device, distribution source, and transmission destination), a DCM (Data Communication Module) 3 (corresponding to an information source), and a CGW (Central Gateway) 4 (corresponding to a vehicle electronic control unit and information source). The DCM 3 is an in-vehicle communication device that performs data communication with the OTA center 2 via a communication network. The communication network may include, for example, a mobile communication network using a 4G line or a 5G line, the Internet, Wi-Fi (Wireless Fidelity) (registered trademark), and the like. The DCM 3 and the CGW 4 may be integrated, and the functions of the DCM 3 may be incorporated into the CGW 4. Alternatively, the functions of the DCM 3 and the CGW 4 may be incorporated into a display or the like. The DCM 3 and the CGW 4, together with ECUs 14 to 17 (described later), constitute a vehicle system 5.

[0020] The DCM 3 transfers data distributed from the OTA center 2 to the CGW 4. The data distributed from the OTA center 2 to the DCM 3 is, for example, repro software. The inter-center communication (corresponding to the out-of-vehicle communication, first communication) which is data communication between the OTA center 2 and the CGW 4 uses the SOVD format conforming to the SOVD communication specifications or the Rest API format conforming to the Rest (REpresentational State Transfer) API communication specifications.

[0021] The CGW 4 includes a control unit 6. The control unit 6 is mainly configured with a microcomputer (hereinafter referred to as "microcomputer") having a CPU, ROM, RAM, I / O, etc., and controls the operation of the CGW 4 by executing software processing by the CPU running a computer program stored in a non-transitory physical storage medium and hardware processing by a dedicated electronic circuit. The control unit 6 executes a format conversion program and a sequence creation program as computer programs. Furthermore, the execution of the format conversion program by the control unit 6 realizes a format conversion method, and the execution of the sequence creation program by the control unit 6 realizes a sequence creation method.

[0022] The CGW 4 may provide a so-called HPC. The CGW 4 may have, for example, a System-on-Chip (SoC) as its hardware and an Adaptive Platform as its software. The CGW 4 may have a plurality of virtual machines (VMs), and the plurality of VMs may include VMs of various platforms, such as an Adaptive Platform VM and a Classic Platform VM. The CGW 4 may function as, for example, a so-called Vehicle Computer in the EE architecture of the vehicle.

[0023] The control unit 6 has, for each function, a downloader 7 (corresponding to an exterior communication unit or a first communication unit), an OTA master 8, a first update master 9 (corresponding to a sequence creation execution unit), a second update master 10 (corresponding to a sequence creation execution unit), a third update master 11 (corresponding to a sequence creation execution unit), a fourth update master 12 (corresponding to a sequence creation execution unit), and a specification data holding unit 13. When a download execution request is input from the OTA master 8, the downloader 7 instructs the DCM 3 to execute a download process. The downloader 7 downloads data from the OTA center 2 via the DCM 3 by receiving data distributed from the OTA center 2 in the DCM 3 and then forwarding the received data from the DCM 3.

[0024] The OTA master 8 has a function of managing the entire SU (Software Update) process. The OTA master 8 includes a vehicle status check unit 8a, an approval result receiving unit 8b, an SU execution request unit 8c, and a completion notification transmitting / receiving unit 8d for each function.

[0025] The vehicle status confirmation unit 8a acquires and confirms the vehicle status from, for example, an ECU that is the target of a software update. The consent result receiving unit 8b receives consent results for the execution of download processing, installation processing, and activation processing associated with, for example, a software update from an in-vehicle HMI (Human Machine Interface) (not shown).

[0026] When an installation execution condition is met, such as when consent to the execution of the installation process is obtained, the SU execution request unit 8c outputs an installation execution request to the appropriate update master among the update masters 9 to 12. When the installation execution request is input from the SU execution request unit 8c, the update master instructs the ECU that is the target of the software update to execute the installation process. When the ECU that is the target of the software update is instructed to execute the installation process, it executes the installation process. Examples of software update modes include various types, such as firmware updates on an ECU-by-ECU basis, and updates on a software unit such as an application or library within the ECU.

[0027] When an activation execution condition is met, such as when consent to execute the activation process is obtained, the SU execution request unit 8c outputs an activation execution request to a corresponding update master among the update masters 9 to 12. When the activation execution request is input from the SU execution request unit 8c, the update master instructs the ECU whose software is to be updated to execute the activation process. When the ECU whose software is to be updated is instructed to execute the activation process, it executes the activation process.

[0028] When an installation completion notification is received from an ECU that is a target of software update, the completion notification transmission / reception unit 8d causes the DCM 3 to transmit the installation completion notification to the OTA center 2. When an activation completion notification is received from an ECU that is a target of software update, the completion notification transmission / reception unit 8d causes the DCM 3 to transmit the activation completion notification to the OTA center 2.

[0029] The update masters 9 to 12 are connected to ECUs 14 to 17 via an in-vehicle network, respectively. The in-vehicle network may be, for example, a Controller Area Network (CAN) or Ethernet (registered trademark).

[0030] A UCM (Update & Configuration Management)-compatible ECU 14 (corresponding to a distribution destination or information source) is connected to the first update master 9 via an in-vehicle network. The first update master 9 performs data communication with the UCM-compatible ECU 14 in accordance with instructions from the OTA master 8. A UCM format conforming to the UCM communication specifications is applied to inter-ECU communication (corresponding to in-vehicle communication or second communication), which is data communication between the first update master 9 and the UCM-compatible ECU 14. The UCM format is a format defined by AUTOSAR. The UCM-compatible ECU 14 is an ECU that implements, for example, UI (User Interface)-based or MM (Multimedia)-based services. The functions of the first update master 9 may be provided in the UCM-compatible ECU 14.

[0031] The UCM-compatible ECU 14 may provide a so-called HPC. The UCM-compatible ECU 14 may have, for example, an SoC as its hardware and an Adaptive Platform as its software. The UCM-compatible ECU 14 may have multiple VMs, and the multiple VMs may include VMs of various platforms, such as an Adaptive Platform VM and a Classic Platform VM. The Classic Platform VM may be configured as a UDS-compatible VM. The UCM-compatible ECU 14 may function as, for example, a domain controller or a zone ECU in the E-E architecture of the vehicle.

[0032] The second update master 10 is connected to an SOVD-compatible ECU 15 (corresponding to a distribution destination or information source) via an in-vehicle network. The second update master 10 communicates data with the SOVD-compatible ECU 15 in accordance with instructions from the OTA master 8. The SOVD format conforming to the SOVD communication specifications is applied to inter-ECU communication (corresponding to in-vehicle communication or second communication), which is data communication between the second update master 10 and the SOVD-compatible ECU 15. The SOVD format is a format defined by JSON (JavaScript Object Notation). The SOVD-compatible ECU 15 is, for example, an ECU that implements ADAS (Advanced Driving Assistant System) services. The functions of the second update master 10 may be provided in the SOVD-compatible ECU 15.

[0033] The SOVD-compatible ECU 15 may provide a so-called HPC. The SOVD-compatible ECU 15 may, for example, include an SoC as its hardware and an Adaptive Platform as its software. The SOVD-compatible ECU 15 may have multiple VMs, which may include VMs of various platforms, such as an Adaptive Platform VM and a Classic Platform VM. The Classic Platform VM may be configured as a UDS-compatible VM. The SOVD-compatible ECU 15 may function as, for example, a domain controller or a zone ECU in the vehicle's EE architecture.

[0034] A UDS (Unified Diagnostic Services)-compatible ECU 16 (corresponding to a distribution destination or information source) is connected to the third update master 11 via an in-vehicle network. The third update master 11 performs data communication with the UDS-compatible ECU 16 in accordance with instructions from the OTA master 8. A UDS format conforming to the UDS communication specifications is applied to inter-ECU communication (corresponding to in-vehicle communication or second communication), which is data communication between the third update master 11 and the UDS-compatible ECU 16. The UDS format is an OEM-dependent format. The third update master 11 references data, such as an OEM-specific format that does not comply with the ODX or OTX standards, and creates messages and communication sequences in the UDS format used for data communication with the UDS-compatible ECU 16 to communicate data. The UDS-compatible ECU 16 is an ECU that realizes services for, for example, engine systems, hybrid (HV) systems, and electric vehicles (EV) systems.

[0035] The UDS-compatible ECU 16 may include, for example, an MCU (Micro Controller Unit) as its hardware and a Classic Platform as its software.

[0036] An ODX (Open Diagnostic Data Exchange) / OTX (Open Test Sequence Exchange)-compatible ECU 17 (corresponding to a distribution destination or information source) is connected to the fourth update master 12 via an in-vehicle network. The fourth update master 12 performs data communication with the ODX / OTX-compatible ECU 17 in accordance with instructions from the OTA master 8. An ODX / OTX format conforming to the ODX / OTX communication specifications is applied to inter-ECU communication (corresponding to in-vehicle communication or second communication), which is data communication between the fourth update master 12 and the ODX / OTX-compatible ECU 17. The ODX / OTX format is a format defined by XML (eXtensible Markup Language). The fourth update master 12 refers to ODX data written in XML format according to the ODX standard, or OTX data written in XML format according to the OTX standard, and creates messages and communication sequences in UDS format used for data communication with an ODX / OTX-compatible ECU 17, and communicates data.

[0037] The ODX / OTX compatible ECU 17 may include, for example, an MCU as its hardware and a Classic Platform as its software.

[0038] As described above, the functions of the update masters 9 to 12 may be provided in the CGW 4 or the ECUs 14 to 17. Furthermore, the functions of the update masters 9 to 12 may be provided in ECUs in the vehicle other than the CGW 4 and the ECUs 14 to 17. When the functions of the update masters 9 to 12 are provided in the ECUs 14 to 17, the update masters 9 to 12 are connected to specific software in the ECUs 14 to 17 to perform data communication (in-vehicle communication, corresponding to second communication). For example, when the first update master 9 is provided in the UCM-compatible ECU 14, the first update master 9 is connected to software responsible for UCM in the UCM-compatible ECU 14 to perform data communication (in-vehicle communication, corresponding to second communication). For example, if the second update master 9 is provided in an SOVD-compatible ECU 15, the second update master 9 in the SOVD-compatible ECU 15 is connected to software responsible for SOVD and performs data communication (in-vehicle communication, equivalent to second communication).

[0039] The specification data stored in the specification data storage unit 13 includes various information related to software updates, such as information regarding the target and order of output of installation instructions, and information regarding the target and order of output of activation instructions.

[0040] The update masters 9 to 12 will now be described. As shown in Fig. 2, the update masters 9 to 12 each include, for each function, an inter-ECU data communication unit 18 (corresponding to an in-vehicle communication unit or second communication unit), a format conversion unit 19, a first compatibility table storage unit 20, a distribution sequence creation unit 21, a distribution sequence execution unit 22, an information collection unit 23, a collection sequence creation unit 24, a collection sequence execution unit 25, a format formation unit 26, and a second compatibility table storage unit 27.

[0041] The inter-ECU data communication unit 18 performs inter-ECU communication with the corresponding ECUs. The format conversion unit 19 converts the format of inter-center communication in accordance with the specifications of the corresponding ECU. As shown in FIG. 3 , the format conversion unit 19 of the first update master 9 converts the format of inter-center communication into the UCM format because the first update master 9 performs inter-ECU communication with the UCM-compatible ECU 14 in accordance with the UCM communication specifications. If the inter-center communication is in the SOVD format, the format conversion unit 19 of the first update master 9 converts the SOVD format into the UCM format. If the inter-center communication is in the RestAPI format, the format conversion unit 19 of the first update master 9 converts the RestAPI format into the UCM format. Furthermore, when inter-center communication is in the RestAPI format, the downloader 7 or the OTA master 8 may convert the RestAPI format into the SOVD format, and the format conversion unit 19 of the first update master 9 may convert the SOVD format into the UCM format.

[0042] The format conversion unit 19 of the second update master 10 converts the format of inter-center communication to the SOVD format as necessary because the second update master 10 performs inter-ECU communication with the SOVD-compatible ECU 15 in accordance with the SOVD communication specifications. If the inter-center communication is in the SOVD format, the format conversion unit 19 of the first update master 9 applies the SOVD format as is without conversion. If the inter-center communication is in the RestAPI format, the format conversion unit 19 of the second update master 10 converts the RestAPI format to the SOVD format. Note that if the inter-center communication is in the RestAPI format, the downloader 7 or the OTA master 8 may convert the RestAPI format to the SOVD format.

[0043] The format conversion unit 19 of the third update master 11 converts the format of inter-center communication into the UDS format because the third update master 11 performs inter-ECU communication with the UDS-compatible ECU 16 in accordance with the UDS communication specifications. If the inter-center communication is in the SOVD format, the format conversion unit 19 of the third update master 11 converts the SOVD format into the UDS format. If the inter-center communication is in the RestAPI format, the format conversion unit 19 of the third update master 11 converts the RestAPI format into the UDS format. Note that if the inter-center communication is in the RestAPI format, the downloader 7 or the OTA master 8 may convert the RestAPI format into the SOVD format, and the format conversion unit 19 of the third update master 11 may convert the SOVD format into the UDS format.

[0044] Because the fourth update master 12 performs inter-ECU communication with the ODX / OTX-compatible ECU 17 based on the ODX / OTX data in accordance with the UDS communication specifications, the format conversion unit 19 of the fourth update master 12 converts the format of the inter-center communication by referring to the ODX / OTX data in the ODX / OTX format. If the inter-center communication is in the SOVD format, the format conversion unit 19 of the fourth update master 12 converts the format of the SOVD format by referring to the ODX / OTX data in the ODX / OTX format. If the inter-center communication is in the RestAPI format, the format conversion unit 19 of the fourth update master 12 converts the format of the RestAPI format by referring to the ODX / OTX data in the ODX / OTX format. Furthermore, when the inter-center communication is in the RestAPI format, the downloader 7 or the OTA master 8 may convert the RestAPI format to the SOVD format, and the format conversion unit 19 of the fourth update master 12 may convert the SOVD format by referring to the ODX / OTX data in the ODX / OTX format.

[0045] As described above, it is assumed that inter-center communication is performed in both the RestAPI format and the SOVD format. Therefore, a mechanism is required for the vehicle to determine whether the format of inter-center communication from the OTA center 2 to the vehicle is the RestAPI format or the SOVD format. In this embodiment, this mechanism involves assigning a format identifier, such as a tag, to the inter-center communication, indicating whether the format is the RestAPI format or the SOVD format, and determining whether the format is the RestAPI format or the SOVD format based on the format identifier in a vehicle-side configuration, such as the downloader 7, the OTA master 8, or the format conversion unit 19. Similarly, for inter-center communication from the vehicle to the OTA center 2, a format identifier, such as a tag, is assigned to the inter-center communication, and the OTA center 2 determines whether the format is the RestAPI format or the SOVD format based on the format identifier.

[0046] In inter-center communication from the vehicle side to the OTA center 2, the vehicle side may selectively use the RestAPI format and the SOVD format depending on the data type. For example, the SOVD format may be used when transmitting a message (corresponding to the second type) and the RestAPI format may be used when transmitting a file (corresponding to the first type). Similarly, the OTA center 2 may selectively use the RestAPI format and the SOVD format depending on the data type.

[0047] The first compatibility table holding unit 20 holds a first compatibility table for adapting the format during format conversion. The format conversion unit 19 uses the first compatibility table to convert the SOVD format used in inter-center communication into a format conforming to SOVD-incompatible communication specifications. In this case, the first compatibility table held in the first compatibility table holding unit 20 may be transmitted from the OTA center 2 or may be prepared in advance in the update masters 9 to 12. That is, the format conversion unit 19 may receive the SOVD format and first compatibility table transmitted from the OTA center 2 and use the received first compatibility table. Alternatively, the format conversion unit 19 may prepare the SOVD format and first compatibility table in advance and use the prepared first compatibility table. The first compatibility table functions as a conversion map for format conversion.

[0048] When converting the SOVD format, the format conversion unit 19 interprets the content expressed in the SOVD format and converts the SOVD format into a message that can be interpreted by the corresponding ECU. For example, since messages corresponding to "SID22" and "DID1000" that request acquisition of vehicle speed information from the corresponding ECU do not exist in the SOVD format, the format conversion unit 19 assigns messages corresponding to "SID22" and "DID1000" when requesting acquisition of vehicle speed information from the corresponding ECU. When assigning such messages, the format conversion unit 19 refers to the first compatibility table.

[0049] As shown in Fig. 4, the HTTP methods used in the SOVD format are "GET," "PUT," "POST," and "DELETE." As shown in Fig. 5, the format conversion unit 19 converts the SOVD format, for example, using "GET," by replacing "data (message)" with "SID22 DID (conversion table)" to convert it to the UDS format. The format conversion unit 19 complements messages that do not exist in the SOVD format, thereby enabling inter-center communication in the SOVD format and inter-ECU communication in a SOVD-incompatible format that is not compatible with the SOVD.

[0050] The delivery sequence creation unit 21 creates a delivery sequence for managing the delivery order when delivering messages to the ECU, according to the SOVD-incompatible format converted by the format conversion unit 19. Managing the delivery order means rearranging the delivery order of messages and adding missing messages. The rearrangement of the message delivery order may be determined, for example, from the content of the specification data. The missing message to be added may be, for example, a message corresponding to a service not specified in the SOVD format (e.g., a service corresponding to SID 34, 36, or 37). The missing message to be added may be determined, for example, from the content of the specification data and the first compatibility table. Note that the OTA center 2 may create the delivery sequence, and the delivery sequence created by the OTA center 2 may be used. Alternatively, only the SOVD message may be sent to the corresponding ECU, and the corresponding ECU may create the delivery sequence, and the delivery sequence created by the ECU may be used.

[0051] The first compatibility table, which functions as the above-mentioned format conversion map, may be mapped with default converted messages and delivery sequences corresponding to messages in the SOVD format transmitted from the OTA center 2, and the delivery sequence creation unit 21 may create a delivery sequence using the first compatibility table. In this case, the delivery sequence creation unit 21 may create a sequence in which the order in which processing start instructions are sent to the target ECU and processing start conditions (whether consent is required, whether installation is performed while the vehicle is parked, etc.) are adjusted according to the content of the specification data for the default converted messages and delivery sequences.

[0052] As described above, the delivery sequence creation unit 21 creates a sequence for managing a certain delivery. A sequence for managing a certain delivery may include arbitration with a process other than the delivery. The arbitration may refer to, for example, determining which of the delivery and the other process is to be prioritized. For example, a sequence for managing a delivery in which a message is delivered to an ECU based on data transmitted from a certain delivery source (e.g., the OTA center 2) via the SOVD service may include arbitration with transmission of a message to the ECU from another delivery source (e.g., a wired tool (not shown) connected to the vehicle via a wired connection). Transmission of a message from another delivery source to the ECU may include, for example, delivery of a message transmitted from the other delivery source using a different communication protocol (e.g., UDS) to the ECU, and delivery of a message to the ECU based on data transmitted from the other delivery source via the SOVD service. Such arbitration with another process may also be included in the collection sequence, which will be described later. Various specific arbitration methods are applicable. For example, if a wired tool as one distribution source is given priority over an OTA center 2 as another distribution source, the arbitration involves delivering a message based on data sent from the OTA center 2 via the SOVD service to the ECU, provided that the wired tool is not detected as being connected to the vehicle.

[0053] The delivery sequence creation unit 21 uses, for example, "SID22" as is, since it is transmitted from the OTA center 2. The delivery sequence creation unit 21 adds a message to, for example, "SID10", "SID27", etc., since they are not transmitted from the OTA center 2. The delivery sequence creation unit 21 adds a message to, for example, "SID34", "SID36", "SID37", etc., since they cannot be expressed in the SOVD format. The delivery sequence execution unit 22 executes the delivery sequence created by the delivery sequence creation unit 21.

[0054] The information collection unit 23 collects ECU information (corresponding to device information) stored in the ECUs 14 to 17. The ECU information includes ECU identification information that can identify the ECU, version information that indicates the version of the hardware, version information that indicates the version of the software, etc.

[0055] The collection sequence creation unit 24 creates a collection sequence for collecting ECU information (corresponding to information) held in the ECUs 14 to 17. The collection sequence may be created by the ECUs 14 to 17. The collection sequence execution unit 25 executes the collection sequence created by the collection sequence creation unit 24.

[0056] The format forming unit 26 forms a format for inter-center communication from the format for inter-ECU communication with each corresponding ECU. That is, as shown in FIG. 6 , the format forming unit 26 of the first update master 9 forms a format for inter-center communication from the UCM format because the first update master 9 performs inter-ECU communication with the UCM-compatible ECU 14 in accordance with the UCM communication specifications. If the inter-center communication is in the SOVD format, the format forming unit 26 of the first update master 9 forms the SOVD format from the UCM format. If the inter-center communication is in the RestAPI format, the format forming unit 26 of the first update master 9 forms the RestAPI format from the UCM format.

[0057] The format forming unit 26 of the second update master 10 forms a format for inter-center communication from the SOVD format as necessary because the second update master 10 performs inter-ECU communication with the SOVD-compatible ECU 15 in accordance with the SOVD communication specifications. If the inter-center communication is in the SOVD format, the format forming unit 26 of the second update master 10 applies the format as is without forming the SOVD format. If the inter-center communication is in the RestAPI format, the format forming unit 26 of the second update master 10 forms the RestAPI format from the SOVD format.

[0058] The format forming unit 26 of the third update master 11 forms a format for inter-center communication from the UDS format because the third update master 11 performs inter-ECU communication in accordance with the UDS communication specifications with the UDS-compatible ECU 16. If the inter-center communication is in the SOVD format, the format forming unit 26 of the third update master 11 forms the SOVD format from the UDS format. If the inter-center communication is in the RestAPI format, the format forming unit 26 of the third update master 11 forms the RestAPI format from the UDS format.

[0059] Because the fourth update master 12 performs inter-ECU communication with the ODX / OTX-compatible ECU 17 based on the ODX / OTX data in accordance with the UDS communication specifications, the format formation unit 26 of the fourth update master 12 references the ODX / OTX data in the ODX / OTX format to form a format for inter-center communication from the UDS format. If the inter-center communication is in the SOVD format, the format formation unit 26 of the fourth update master 12 references the ODX / OTX data in the ODX / OTX format to form the SOVD format from the UDS format. If the inter-center communication is in the RestAPI format, the format formation unit 26 of the fourth update master 12 references the ODX / OTX data in the ODX / OTX format to form the RestAPI format from the UDS format.

[0060] The second compatibility table holding unit 27 holds a second compatibility table for adapting the format when forming the format. The format forming unit 26 forms a format for inter-center communication using the second compatibility table from the format for inter-ECU communication with each corresponding ECU. In this case, the format forming unit 26 uses the second compatibility table to indicate which ECU the information was obtained from, to the information received from the ECUs 14 to 17.

[0061] Next, the operation of the above-described configuration will be described with reference to Figures 7 to 10. Here, the process at the time of downloading and the process at the time of uploading will be described in order in the case where diagnosis is performed as an SOVD service.

[0062] (1) Processing During Download The center-side processing performed by the OTA center 2 during download and the vehicle-side processing performed by the CGW 4 during download will be described in order.

[0063] (1-1) Center-side processing performed by the OTA center 2 during download (see FIG. 7) When the OTA center 2 starts center-side processing, it determines whether a diagnostic service implementation request has occurred (A1). If the OTA center 2 determines that a diagnostic service implementation request has occurred (A1: YES), it generates a diagnostic message or file to be distributed to the vehicle (A2). When the OTA center 2 receives synchronization information transmitted from the vehicle, it executes synchronization processing with the vehicle (A3).

[0064] After executing the synchronization process with the vehicle side, the OTA center 2 determines a diagnostic message or file to be delivered to the vehicle side (A4), and transmits the determined diagnostic message or file to the vehicle side (A5). When the OTA center 2 receives the status and result of the diagnostic sequence transmitted from the vehicle side, it monitors and measures the status of the diagnostic service based on the status and result of the received diagnostic sequence (A6), and ends the center-side process.

[0065] (1-2) Vehicle-Side Processing Performed by CGW 4 During Download (See FIG. 8) In the CGW 4, when the control unit 6 starts the vehicle-side processing, it determines (B1) whether or not the synchronization condition with the OTA center 2 is established. When the control unit 6 determines that the synchronization condition with the OTA center 2 is established (B1: YES) and receives a diagnostic message or file from the OTA center 2 (B2), it converts the received diagnostic message or file (B3).

[0066] The control unit 6 performs the above-mentioned format conversion and generates a diagnostic message to be distributed to the ECU to be diagnosed (B4, corresponding to the format conversion procedure). The control unit 6 creates a diagnostic sequence (corresponding to the distribution sequence) to be distributed to the ECU to be diagnosed (B5, corresponding to the distribution sequence creation procedure), executes the created diagnostic sequence, and communicates with the ECU to be diagnosed (corresponding to the communication procedure). The control unit 6 generates a diagnostic message or file to be transmitted to the OTA center 2 (B6), and transmits synchronization information to the OTA center 2 (B7).

[0067] The control unit 6 determines whether or not an instruction to execute a diagnostic service has been received from the OTA center 2 (B8). If the control unit 6 determines whether or not an instruction to execute a diagnostic service has been received from the OTA center 2 (B8: YES) and receives a diagnostic message or file from the OTA center 2 (B9), the control unit 6 converts the received diagnostic message or file (B10).

[0068] The control unit 6 performs the above-mentioned format conversion and generates a diagnostic message to be distributed to the ECU to be diagnosed (B11, corresponding to the format conversion procedure). The control unit 6 creates a diagnostic sequence (corresponding to the distribution sequence) to be distributed to the ECU to be diagnosed (B12, corresponding to the distribution sequence creation procedure), executes the created diagnostic sequence, and communicates with the ECU to be diagnosed (corresponding to the communication procedure). The control unit 6 transmits the status and results of the diagnostic sequence to be distributed to the ECU to be diagnosed to the OTA center 2 (B13), and ends the vehicle-side processing.

[0069] (2) Processing During Upload The center-side processing performed by the OTA center 2 during upload and the vehicle-side processing performed by the CGW 4 during upload will be described in order.

[0070] (2-1) Center-side processing performed by the OTA center 2 during upload (see FIG. 9) When the OTA center 2 starts the center-side processing, it determines whether a collection target confirmation request has been issued from the vehicle (A11). If the OTA center 2 determines that a collection target confirmation request has been issued from the vehicle (A11: YES), it determines a diagnostic message or file to be delivered to the vehicle (A12) and transmits the determined diagnostic message or file to the vehicle (A13). If the OTA center 2 receives the upload file transmitted from the vehicle (A14), it executes a diagnostic service (A15) and terminates the center-side processing.

[0071] (2-2) Vehicle-Side Processing Performed by the CGW 4 During Upload (See FIG. 10) In the CGW 4, when the control unit 6 starts the vehicle-side processing, it determines whether the synchronization condition with the OTA center 2 is met (B21). When the control unit 6 determines that the synchronization condition with the OTA center 2 is met (B21: YES), the control unit 6 receives a diagnostic message or file from the OTA center 2 (B22), and converts the received diagnostic message or file (B23). The control unit 6 generates a diagnostic message to be delivered to the ECU to be diagnosed (B24), creates a diagnostic sequence (corresponding to a collection sequence) to be delivered to the ECU to be diagnosed (B25), and executes the created diagnostic sequence to communicate with the ECU to be diagnosed. The control unit 6 performs the above-described formatting and generates a diagnostic message or file to be sent to the OTA center 2 (B26). The control unit 6 then transmits the upload file to the OTA center 2 (B27), and ends the vehicle-side processing.

[0072] The above describes examples of download and upload processes when diagnosis is performed as an SOVD service, but the same applies to SOVD services such as OTA repro, remote diagnosis, customization, etc. In other words, the configuration for converting the SOVD format into a SOVD-incompatible format, the configuration for creating a delivery sequence for managing the message delivery order, the configuration for creating a collection sequence for collecting ECU information, and the configuration for forming the SOVD format from a SOVD-incompatible format can also be applied to download and upload processes when OTA repro, remote diagnosis, customization, etc. are performed.

[0073] As described above, the first embodiment can achieve the following advantageous effects. In the case where center-to-center communication with the OTA center 2 is data communication in the SOVD format and a message or file based on the SOVD format is delivered to an ECU that does not support SOVD, the SOVD format for center-to-center communication is converted to a non-SOVD format, and ECU-to-ECU communication with the non-SOVD ECU is performed in accordance with the converted non-SOVD format. By converting the SOVD format for center-to-center communication into a non-SOVD format and performing ECU-to-ECU communication in accordance with the converted non-SOVD format, the SOVD service can be appropriately provided for the non-SOVD ECU.

[0074] In the first embodiment, the CGW 4 is configured such that the update masters 9 to 12 convert the SOVD format into a non-SOVD compatible format. However, as will be described in a second embodiment, the CGW 4 may be configured such that the OTA master 8 converts SOVD format messages into generic format messages, and the update masters 9 to 12 convert the generic format messages into a non-SOVD compatible format. Generic format messages (hereinafter also referred to as generic messages) are messages used by the OTA master 8 to communicate with multiple update masters 9 to 12, and may be, for example, UDS-compliant messages that have been generalized by extension. Generic messages can, for example, be extended to transmit messages related to services not included in the UDS standard.

[0075] A delivery sequence for managing the message delivery order is created in accordance with the SOVD non-compliant format, and communication between ECUs is performed in accordance with the created delivery sequence. By creating a delivery sequence for managing the message delivery order, the SOVD service can be properly implemented for SOVD non-compliant ECUs.

[0076] The SOVD format is generated from the non-SOVD compatible format acquired from the non-SOVD compatible ECU. By generating the SOVD format from the non-SOVD compatible format of the inter-ECU communication, the SOVD service can be appropriately realized for the non-SOVD compatible ECU.

[0077] A collection sequence for collecting ECU information from an ECU is created, and communication between ECUs is performed in accordance with the collection sequence. By creating a collection sequence for collecting ECU information from an ECU, the SOVD service can be properly implemented for an ECU that is not SOVD compatible.

[0078] A format identifier such as a tag indicating whether the format is the RestAPI format or the SOVD format is assigned to the inter-center communication, and the vehicle determines whether the format is the RestAPI format or the SOVD format based on the format identifier.Even if the inter-center communication is performed in a mixture of the RestAPI format and the SOVD format, the inter-center communication can be performed appropriately.

[0079] Second Embodiment The second embodiment will be described with reference to Figures 11 to 24. As shown in Figure 11, the OTA master 8 includes a processing target identification table management unit 8e in addition to the vehicle status confirmation unit 8a, the acceptance result receiving unit 8b, the SU execution request unit 8c, and the completion notification transmitting / receiving unit 8d described in the first embodiment. As shown in Figure 12, the processing target identification table management unit 8e includes, for each function, a processing target identification table storage unit 31 (corresponding to the vehicle-side identification information storage unit), a processing instruction receiving unit 32, a processing target identification unit 33, an unidentifiable information transmission unit 34, a non-compatible information transmission unit 35, a non-response information transmission unit 36, an update request transmission unit 37, a processing target identification table acquisition unit 38 (corresponding to the identification information acquisition unit), and a processing target identification table update unit 39 (corresponding to the identification information update unit).

[0080] As shown in FIG. 13 , the processing target identification table (corresponding to processing target identification information) stored in the processing target identification table storage unit 31 is a table that indicates the association between processing instructions based on messages or files in SOVD format and various information corresponding to those processing instructions. The processing target identification table is organized into units of information related to the SOVD format, connection destination, processing method, service, supported functions, and billing support. That is, the processing target identification table associates processing instructions based on messages or files in SOVD format with information related to the connection destination, processing method, service, supported functions, and billing support corresponding to those processing instructions. Note that, although the present embodiment illustrates an example in which the processing target identification table is stored in the OTA master, the location where the processing target identification table is stored is not limited to the OTA master, and the processing target identification table may be stored in, for example, a specific ECU or any location in the vehicle system 3.

[0081] The connection destination information (corresponding to connection destination information) indicates information that can identify the ECU to be processed. The ECU to be processed is sometimes referred to as the target ECU. For example, "body system bus door ECU Eth communication IP address" indicates that the ECU to be processed is a door ECU connected to a body system bus and can be identified by its IP address via Ethernet communication. The connection destination information may be information that can identify, for example, one of the multiple elements constituting an HPC functioning as an integrated ECU as the processing target. For example, assuming an HPC having multiple VMs connected to a virtual CAN bus belonging to the body system bus, the connection destination information may be information that can identify, for example, "body system bus door ECU," a VM that is connected to the body system bus and functions as a door ECU as the processing target. For example, assuming an HPC having multiple SoCs connected to each other via Ethernet communication, the connection destination information may be information that can identify which SoC is the processing target based on its IP address via Ethernet communication.

[0082] The information on the processing method (corresponding to processing method information) indicates information that can identify the processing method for the ECU to be processed. The processing methods include an OTA master collection method, a relay method, and an OTA master retention method.

[0083] The OTA master collection method is a method in which the OTA master 8 interprets the SOVD format from the OTA center 2, reads information from the target ECU, and transmits the read information to the OTA center 2. In the OTA master collection method, the OTA master 8 transmits an SOVD message or a general-purpose message converted from the SOVD message to an update master among the update masters 9 to 12 that corresponds to the connection destination to be processed. When the update masters 9 to 12 receive the SOVD message or general-purpose message from the OTA master 8, they convert the received SOVD message or general-purpose message into the appropriate format and create a sequence.

[0084] When the processing method is the OTA master collection method and there are multiple connection destinations to be processed (for example, all ECUs installed in the vehicle or all ECUs belonging to a specific category), a sequence also exists between the OTA master 8 and the update masters 9 to 12, as shown in Figure 14. The functional block of the diagnostic app shown in Figure 14 corresponds to the OTA master 8 described in Figures 1 and 11, and the functional blocks of SOVD, UCM, ODX / OTX, and UDS shown in Figure 14 correspond to the second update master 10, first update master 9, third update master 11, and fourth update master 12 described in Figures 1 and 11, respectively. In the example shown in Figure 14, the functional blocks of SOVD, UCM, ODX / OTX, and UDS are software that can be updated by so-called SOTA, and can be updated by replacing an executable file or a setting file in the file system of the Adaptive Platform, for example. The functional blocks of the SOVD-compatible ECU and the UCM-compatible ECU shown in Figure 14 correspond to the SOVD-compatible ECU 15 and the UCM-compatible ECU 14 described in Figures 1 and 11, respectively. The UDS-compatible ECU shown in Figure 14 corresponds to the UDS-compatible ECU 16 and the ODX / OTX-compatible ECU 17 described in Figures 1 and 11. As described above, the ODX / OTX-compatible ECU 17 also communicates according to the UDS. Therefore, in Figure 14, the UDS-compatible ECU 16 and the ODX / OTX-compatible ECU 17 described in Figures 1 and 11 are collectively referred to as the UDS-compatible ECU.

[0085] The ECU-embedded program (OTA repro) shown in Fig. 14 differs from the functional blocks of SOVD, UCM, ODX / OTX, and UDS in that it is a program that is already embedded in the ECU. The ECU-embedded program (OTA repro) corresponds to the first update master 9, second update master 10, third update master 11, and fourth update master 12 described in Fig. 1 and Fig. 11, and by operating the ECU-embedded program, communication is performed between the UCM-compatible ECU 14, SOVD-compatible ECU 15, UDS-compatible ECU 16, and ODX / OTX-compatible ECU 17, which correspond to the functional blocks of the target ECU shown in Fig. 14.

[0086] In this case, the sequence between the OTA master 8 and the update masters 9 to 12 corresponding to processing instructions from the OTA center 2, and the sequence between each update master and the connection destination corresponding to an SOVD message or a general-purpose message are predefined as default sequences in a map, etc.

[0087] The default sequence checks, for example, the order in which processing start instructions are issued, and the fulfillment of processing start conditions before issuing a processing start instruction, such as checking the vehicle state and consent (if required). At this time, information about function support and information about billing support (described later) are referenced to create a sequence that thins out "processes not supported by the vehicle" included in the default sequence. For software updates, a sequence is created that adjusts the order in which processing start instructions are sent to the update masters 9-12 and target ECUs, and the processing start conditions (such as whether consent is required and whether installation is performed while the vehicle is parked) according to specifications in the software update data.

[0088] If the OTA master 8 is unable to create a sequence between the update masters 9 to 12, it transmits error information indicating that the sequence cannot be created, along with the reason for the error, to the OTA center 2, which is the sender of the SOVD message. At this time, the OTA master 8 may request at least one of the latest version of a map for creating a sequence and the latest version of software for creating a sequence using the map, from the OTA center 2, which is the sender of the SOVD message. Similarly, if the update masters 9 to 12 are unable to create a sequence, they transmit error information indicating that the sequence cannot be created, along with the reason for the error, to the OTA master 8, which is the sender of the SOVD format message or general-purpose message. At this time, the OTA master 8 may request at least one of the latest version of a map for the update masters 9 to 12 to create a sequence and the latest version of software for creating a sequence using the map, from the OTA center 2, which is the sender of the SOVD message.

[0089] In the relay method, the OTA master 8 relays the SOVD format from the OTA center 2 to the target ECU without interpreting it, and transmits information acquired from the target ECU to the OTA center 2. In this case, the target ECU interprets the SOVD format. In the relay method, the OTA master 8 bypasses the second update master 10 and transmits the SOVD message to the connected target ECU (SOVD-compatible ECU) that is the processing target. As an example of processing at the destination, a SOVD-compatible ECU such as a domestic control ECU or zone ECU identifies the processing target and processing method by referring to the processing target identification table described above, and performs UDS conversion if necessary. A response from the destination to the SOVD message is transmitted from the DCM 3 to the OTA center 2 via the OTA master 8.

[0090] The OTA master retention method is a method in which information about a target ECU is retained in the OTA master 8 and the retained information is transmitted to the OTA center 2. In the OTA master retention method, the OTA master 8 transmits an SOVD message or a general-purpose message to an update master 9-12 corresponding to a connected target ECU to be processed, either periodically or in response to the occurrence of a preset event, and acquires and retains information corresponding to the SOVD message or general-purpose message from the connected target ECU. The information acquired from the connected target ECU and retained may be uploaded to the outside in response to a SOVD message from an external source, or may be uploaded in response to a predetermined event, such as an event specified for each piece of information to be uploaded, or periodically.

[0091] In the OTA master retention method, an example of target ECU information that is retained by the OTA master 8 and transmitted to a destination is information that is retained in advance by the OTA master 8 by periodically providing a service corresponding to "SID22 DID****" as illustrated in FIG. 13. Here, the target ECU is not limited to an ECU other than the ECU that includes the OTA master 8, but may also be the ECU that includes the OTA master 8. The OTA master collection method, relay method, and OTA master retention method correspond to the collection method, relay method, and retention method, respectively. The OTA center 2 corresponds to the distribution source and the destination.

[0092] The information about the service indicates a message corresponding to the SOVD format. The information about function support (corresponding to support information) indicates information that can identify whether the ECU to be processed supports a processing instruction request. For example, in the case of "Vehicle A," high-grade and mid-grade vehicles are "equipped," indicating that they support a processing instruction request, while low-grade vehicles are "not equipped," indicating that they do not support a processing instruction request. The same is true for other vehicles such as "Vehicle B" and "Vehicle C." The information about billing support (corresponding to support information) indicates information that can identify whether the ECU to be processed supports a processing instruction request. "With billing function" indicates a service that involves billing, and billing is a condition. If billing has been completed, it indicates that the ECU supports a processing instruction request, and if billing has not been completed, it indicates that the ECU does not support a processing instruction request. "Without billing function" indicates a service that does not involve billing, and indicates that the ECU supports a processing instruction request without billing.

[0093] The processing target identification table shown in FIG. 13 illustrates a case where a SOVD-formatted message specifies an OTA app as a path. If a SOVD-formatted message specifies a remote diagnosis app or a data collection app as a path, the remote diagnosis app or the data collection app may process the SOVD-formatted message using a similar processing target identification table. As shown in FIG. 15 , the SOVD message may be routed within the vehicle according to the path included in the SOVD-formatted message. When the control unit 6 stores an OTA app (corresponding to the OTA master 8 shown in FIG. 1 ) as diagnostic app 1, a remote diagnosis app as diagnostic app 2, and a data collection app as diagnostic app 3, the downloader 7 (functioning as the routing block shown in FIG. 13 ) interprets which app the SOVD-formatted message is addressed to and forwards it to the corresponding diagnostic app. If the downloader 7 determines that the SOVD message is addressed to an OTA app, it forwards the SOVD message to diagnostic app 1. If the downloader 7 determines that the destination of the SOVD message is a remote diagnostic application, it transfers the SOVD message to the diagnostic application 2. If the downloader 7 determines that the destination of the SOVD message is a data collection application, it transfers the SOVD message to the diagnostic application 3.

[0094] The processing instruction receiving unit 32 receives a processing instruction based on a message or file in the SOVD format from the OTA center 2. When the processing instruction receiving unit 32 receives a processing instruction based on a message or file in the SOVD format from the OTA center 2, the processing target specifying unit 33 refers to the processing target specifying table held in the processing target specifying table holding unit 31, and specifies the connection destination, processing method, service, function support, and billing support corresponding to the received processing instruction in the SOVD format.

[0095] 16, when a processing instruction based on a message in SOVD format, such as GET{base_uri} / apps / WindowControl[OTA application] / data(message) / RearWindows#1 HTTP / 1.1, is received as a request to acquire information from the OTA center 2 to the vehicle side, the processing target identification unit 33 refers to the processing target identification table shown in FIG. 13 and searches for GET{base_uri} / apps / WindowControl[OTA application] / data(message) / RearWindows#1 HTTP / 1.1. Since the processing instruction is stored, the processing target identification unit 33 identifies information related to the connection destination, processing method, service, function support, and billing support that correspond to the processing instruction. In the example of Figure 13, the processing target identification unit 33 identifies "body system bus door ECU Eth communication IP address" as the connection destination corresponding to GET{base_uri} / apps / WindowControl[OTA app] / data (message) / RearWindows#1 HTTP / 1.1, identifies "OTA master collection method" as the processing method, and identifies "SID22 DID****" as the service.

[0096] The processing target identification unit 33 identifies the ECU to be processed as compliant with the processing instruction request if, for example, the vehicle is a high-grade vehicle A and charging has been completed. The processing target identification unit 33 identifies the ECU to be processed as not compliant with the processing instruction request if, for example, the vehicle is a high-grade vehicle A and charging has not been completed. The processing target identification unit 33 identifies the ECU to be processed as not compliant with the processing instruction request if, for example, the vehicle is a low-grade vehicle A.

[0097] Similarly, when the processing target identification unit 33 receives a processing instruction based on a message in the SOVD format, GET{base_uri} / apps / WindowControl[OTA application] / data (message) / RearWindows#1 HTTP / 1.1, it refers to the processing target identification table shown in FIG. 13 and identifies "power tray bus window ECU Eth communication IP address" as the connection destination, "OTA master collection method" as the processing method, and "SID22 DID++++" as the service.

[0098] The processing target identification unit 33 identifies the ECU to be processed as compliant with the processing instruction request if, for example, the vehicle is a high-grade vehicle C and charging has been completed. The processing target identification unit 33 identifies the ECU to be processed as not compliant with the processing instruction request if, for example, the vehicle is a high-grade vehicle C and charging has not been completed. The processing target identification unit 33 identifies the ECU to be processed as not compliant with the processing instruction request if, for example, the vehicle is a low-grade vehicle C.

[0099] Furthermore, when the processing target identification unit 33 receives a processing instruction based on a message in SOVD format, such as GET{base_uri} / apps / WindowControl[OTA application] / data(message) / RearWindows#6 HTTP / 1.1, as a request to acquire information from the OTA center 2 to the vehicle side, the processing target identification unit 33 refers to the processing target identification table shown in Fig. 13 and searches for GET{base_uri} / apps / WindowControl[OTA application] / data(message) / RearWindows#6 HTTP / 1.1. Because the processing instruction is not stored, the processing target identification unit 33 cannot identify information related to the connection destination, processing method, service, supported functions, and billing support that correspond to the processing instruction.

[0100] Furthermore, when the processing target identification unit 33 receives a processing instruction based on a message in SOVD format, such as GET{base_uri} / apps / WindowControl[OTA application] / data(message) / RearWindows#8 HTTP / 1.1, as a request to acquire information from the OTA center 2 to the vehicle side, the processing target identification unit 33 refers to the processing target identification table shown in Fig. 13 and searches for GET{base_uri} / apps / WindowControl[OTA application] / data(message) / RearWindows#8 HTTP / 1.1. Although the processing instruction described above is stored in the processing target identification unit 33, information regarding the connection destination, processing method, service, function support, and billing support corresponding to the processing instruction is not recorded, and therefore the processing target identification unit 33 is unable to identify information regarding the connection destination, processing method, service, function support, and billing support corresponding to the processing instruction.

[0101] When the ECU to be processed is not identified by the processing target identification unit 33, the non-identifiable information transmission unit 34 causes the DCM 4 to transmit non-identifiable information indicating that the ECU to be processed has not been identified to the OTA center 2.

[0102] When the processing target identification unit 33 identifies the ECU to be processed, but the processing target identification unit 33 determines that the ECU to be processed does not comply with the processing instruction request, the non-compatible information transmission unit 35 causes the DCM 4 to transmit non-compatible information indicating that the ECU to be processed does not comply with the processing instruction request to the OTA center 2.

[0103] The non-response information transmitting unit 36 ​​causes the DCM 4 to transmit non-response information indicating that the ECU to be processed has not responded to the processing instruction request from the DCM 4 to the OTA center 2 when the ECU to be processed is identified by the processing target identification unit 33 and the processing target ECU has been identified by the processing target identification unit 33 as responding to the processing instruction request, but the ECU to be processed has not responded to the processing instruction request.

[0104] The update request sending unit 37 causes the DCM 4 to send an update request for the processing target identification table to the OTA center 2 in order to update the processing target identification table. In this case, the update request sending unit 37 causes the DCM 4 to send information capable of identifying the processing target identification table currently held in the processing target identification table holding unit 31 to the OTA center 2. The information capable of identifying the processing target identification table is, for example, version information indicating whether the processing target identification table is new or old. The update request sending unit 37 causes the DCM 4 to send an update request for the processing target identification table to the OTA center 2 when the processing target ECU is not identified by the processing target identification unit 33 as described above. Furthermore, the update request sending unit 37 periodically determines whether the processing target identification table has been updated in the OTA center 2, not only when the processing target ECU is not identified by the processing target identification unit 33, and when it determines that the processing target identification table has been updated, causes the DCM 4 to send an update request for the processing target identification table to the OTA center 2.

[0105] The processing target identification table acquisition unit 38 acquires the processing target identification table when the processing target identification table distributed from the OTA center 2 is received by the DCM 4 and the received processing target identification table is transferred from the DCM 4. When the processing target identification table acquisition unit 38 acquires the processing target identification table, the processing target identification table update unit 39 updates the processing target identification table held in the processing target identification table holding unit 31 with the acquired processing target identification table. In other words, by updating with the processing target identification table, the processing target identification table update unit 39 synchronizes the processing target identification table on the vehicle side with the processing target identification table held in the OTA center 2.

[0106] The timing for updating the processing target specification table may be when the OTA master 8 synchronizes the individual vehicle configuration information with the OTA center 2, when HMI data is acquired from the OTA center 2, when the validity of campaign information notified from the OTA center 2 is confirmed, when a status notification or completion notification is sent to the OTA center 2, when the software is upgraded, etc. Alternatively, the timing may be when the battery power is turned on, when the ignition switch or motor switch is turned on, when the HMI is operated, etc.

[0107] 17, the update masters 9 to 12 each include, for each function, a format conversion unit 19, a first compatibility table storage unit 20, a delivery sequence creation unit 21, a delivery sequence execution unit 22, an information collection unit 23, a collection sequence creation unit 24, a collection sequence execution unit 25, a format formation unit 26, and a second compatibility table storage unit 27. Each of the units 19 to 27 is the same as in the first embodiment.

[0108] If the format conversion unit 19 is unable to convert the format, if the delivery sequence creation unit 21 is unable to create the delivery sequence, or if the delivery sequence execution unit 22 is unable to execute the delivery sequence, the update masters 9 to 12 cause the DCM 4 to transmit error information indicating this to the OTA center 2, and request, for example, the latest conversion map for converting the format, the latest sequence creation map for creating the delivery sequence, the latest software for executing the delivery sequence, etc. from the OTA center 2. If the collection sequence creation unit 24 is unable to create the collection sequence, if the collection sequence execution unit 25 is unable to execute the collection sequence, or if the format formation unit 26 is unable to form the format, the update masters 9 to 12 cause the DCM 4 to transmit error information indicating this to the OTA center 2, and request, for example, the latest sequence creation map for creating the collection sequence, etc. from the OTA center 2.

[0109] Next, the OTA center 2 will be described. As shown in Fig. 18 , the OTA center 2 includes, for each function, a processing target identification table holding unit 41 (corresponding to an outside-vehicle identification information holding unit), a processing target identification table distribution unit 42, an update request receiving unit 43, an update presence / absence determining unit 44, and a distribution impossible information transmitting unit 45.

[0110] The processing target identification table holding unit 41 holds a processing target identification table, similar to the processing target identification table holding unit 31 of the above-described OTA master 8. The processing target identification table distribution unit 42 distributes the processing target identification table held in the processing target identification table holding unit 41 to the vehicle system 3.

[0111] The update request receiving unit 43 receives an update request for the processing target identification table transmitted from the vehicle system 3. When the update request receiving unit 43 receives the update request for the processing target identification table transmitted from the vehicle system 3, the processing target identification table distribution unit 42 determines whether to distribute the processing target identification table to the vehicle system 3 based on configuration information included in the received update request for the processing target identification table. That is, the processing target identification table distribution unit 42 compares the old and new versions of the processing target identification table held in the OTA center 2 and the processing target identification table held in the vehicle system 3 based on the configuration information included in the update request for the processing target identification table. If the processing target identification table held in the OTA center 2 is newer than the processing target identification table held in the vehicle system 3, the processing target identification table distribution unit 42 distributes the processing target identification table to the vehicle system 3.

[0112] Furthermore, the update presence / absence determination unit 44 determines whether the processing target identification table held in the processing target identification table holding unit 41 has been updated. The processing target identification table delivery unit 42 determines whether the processing target identification table should be delivered to the vehicle system 3 based on whether the processing target identification table held in the processing target identification table holding unit 41 has been updated. If the processing target identification table held in the processing target identification table holding unit 41 has been updated, the processing target identification table delivery unit 42 delivers the processing target identification table to the vehicle system 3.

[0113] The update determination unit 44 determines whether the processing target identification table has been updated in the following cases, for example: when a new vehicle model from an OEM is released; when a new grade of an existing vehicle model from an OEM is released; when a function can be activated for a fee in an existing vehicle model from an OEM; or when a user can select to install or activate a function without a fee in an existing vehicle model from an OEM; the update determination unit 44 determines whether the processing target identification table has been updated (corresponding to "YES" in step A21 of FIG. 24 , which will be described later). The OTA center 2 then generates a processing target identification table (corresponding to step A22 of FIG. 24 , which will be described later). The updated processing target identification table may be generated by, for example, receiving from an OEM or the like a file containing processing instructions to be added to the processing target identification table in response to the activation of a new function, and the connection destination, processing method, service, function support, and billing support corresponding to the processing instructions, and adding these to the existing processing target identification table.

[0114] When the processing target identification table delivery unit 42 is unable to deliver the processing target identification table to the vehicle system 3, the delivery impossible information transmission unit 45 transmits delivery impossible information indicating that the processing target identification table cannot be delivered to the related system. The related system is, for example, a system that manages the SOVD service, and includes not only the OTA center 2 but also a log collection center that collects logs and a remote diagnosis center that performs remote diagnosis.

[0115] In the above configuration, the processing target identification table can be realized in various units, as shown in FIG. 19 . For example, it can be realized in units of OEM (Original Equipment Manufacturing), vehicle, system, function, application, etc. For example, if the unit is OEM or vehicle, the amount of data in each table will be relatively large and the update frequency will be relatively high, but there is an advantage that the number of tables to be managed will be relatively small. On the other hand, if the unit is application or function, there is an advantage that the number of tables to be managed will be relatively large, but there is an advantage that the amount of data in each table will be relatively small and the update frequency will be relatively low.

[0116] For example, consider a case where a function can be enabled for a certain grade of a certain vehicle model of a certain OEM for a fee. In this case, if the processing target identification table is OEM-specific, the processing target identification table used in all vehicles of that OEM can be updated. If the processing target identification table is vehicle-specific, the processing target identification table used in vehicles of the corresponding grade of the corresponding vehicle model among the OEM's vehicles will be updated, but the processing target identification table used in vehicles other than the corresponding grade of the existing vehicle model cannot be updated.

[0117] Next, the operation of the above-described configuration will be described with reference to Fig. 20 to Fig. 24. Here, the vehicle-side processing performed by the CGW 4 and the center-side processing performed by the OTA center 2 will be described in order.

[0118] (1) Vehicle-Side Processing Performed by CGW 4 (See FIGS. 20 to 23) In the CGW 4, when the control unit 6 starts the vehicle-side processing, it determines whether or not a synchronization condition with the OTA center 2 is established (B31). When the control unit 6 determines that the synchronization condition with the OTA center 2 is established (B31: YES) and receives a diagnostic message or file in the SOVD format from the OTA center 2 (B32, corresponding to the processing instruction reception procedure), it refers to the processing target identification table. The control unit 6 searches for the received diagnostic message or file in the SOVD format and determines whether or not the processing target ECU corresponding to the diagnostic message or file in the SOVD format has been identified using the processing target identification table (B33).

[0119] The control unit 6 determines that the processing instructions in the received SOVD format diagnostic message or file are stored in the processing target identification table, and when it determines that the ECU to be processed has been identified (B33: YES, corresponding to the processing target identification procedure), it converts the received diagnostic message or file (B34).

[0120] The control unit 6 performs the above-mentioned format conversion, generates a diagnostic message to be delivered to the ECU to be diagnosed (B35), and determines whether the request for processing instructions is supported based on the function support and billing support (B36). If the control unit 6 determines that the request for processing instructions is supported (B36: YES), it creates a diagnostic sequence to be delivered to the ECU to be diagnosed (B37), executes the created diagnostic sequence (B38), and communicates with the ECU to be diagnosed. The control unit 6 creates a diagnostic message or file to be sent to the OTA center 2 (B39), and sends synchronization information to the OTA center 2 (B40).

[0121] The control unit 6 determines whether or not an instruction to execute a diagnostic service has been received from the OTA center 2 (B41). When the control unit 6 determines whether or not an instruction to execute a diagnostic service has been received from the OTA center 2 (B41: YES) and receives a diagnostic message or file from the OTA center 2 (B42, corresponding to the processing instruction receiving procedure), the control unit 6 refers to the processing target identification table. The control unit 6 searches for the received diagnostic message or file in the SOVD format and determines whether or not the processing target ECU corresponding to the diagnostic message or file in the SOVD format has been identified using the processing target identification table (B43).

[0122] The control unit 6 determines that the processing instruction based on the received SOVD format diagnostic message or file is stored in the processing target identification table, and when it determines that the ECU to be processed has been identified (B43: YES, corresponding to the processing target identification procedure), it converts the received diagnostic message or file (B44).

[0123] The control unit 6 performs the above-mentioned format conversion, generates a diagnostic message to be delivered to the ECU to be diagnosed (B45), and determines whether the request for processing instructions is met based on the function support and billing support (B46). If the control unit 6 determines that the request for processing instructions is met (B46: YES), it creates a diagnostic sequence to be delivered to the ECU to be diagnosed (B47), executes the created diagnostic sequence (B48), and communicates with the ECU to be diagnosed. The control unit 6 transmits the status and results of the diagnostic sequence to be delivered to the ECU to be diagnosed to the OTA center 2 (B49), and ends the vehicle-side processing.

[0124] On the other hand, if the control unit 6 determines that the processing instruction in the received SOVD-format diagnostic message or file is not stored in the processing target identification table and determines that the ECU to be processed has not been identified (B33: NO), it transmits a processing target identification table update request to the OTA center 2 (B50) and waits for reception of the processing target identification table from the OTA center 2 (B51).If the control unit 6 determines that the processing target identification table distributed from the OTA center 2 has been received (B51: YES), it determines whether the processing target identification table currently held has been updated with the received latest processing target identification table (B52).

[0125] If the control unit 6 determines that the processing target identification table has been updated (B52: YES), the control unit 6 proceeds to step B34. That is, the control unit 6 performs step B34 and subsequent steps based on the updated processing target identification table. On the other hand, if the control unit 6 determines that the processing target identification table has not been updated (B52: NO), the control unit 6 transmits a non-update notification indicating that the processing target identification table has not been updated to the OTA center 2 (B53), and ends the vehicle-side processing.

[0126] After determining that an instruction to execute a diagnostic service has been received from the OTA center 2 (B41: YES), if the control unit 6 determines that the ECU to be processed has not been identified (B43: NO), the control unit 6 performs the same processing as in steps B50 to B53 described above. That is, the control unit 6 transmits a request to update the processing target identification table to the OTA center 2 (B54) and waits for reception of the processing target identification table from the OTA center 2 (B55). If the control unit 6 determines that the processing target identification table distributed from the OTA center 2 has been received (B55: YES), the control unit 6 determines whether the processing target identification table currently held has been updated with the latest processing target identification table received (B56).

[0127] If the control unit 6 determines that the processing target identification table has been updated (B56: YES), the control unit 6 proceeds to step B44. That is, the control unit 6 performs step B44 and subsequent steps based on the updated processing target identification table. On the other hand, if the control unit 6 determines that the processing target identification table has not been updated (B56: NO), the control unit 6 transmits a non-update notification indicating that the processing target identification table has not been updated to the OTA center 2 (B57), and ends the vehicle-side processing.

[0128] Furthermore, if the control unit 6 determines that the processing instruction request is not supported based on the function support and billing support (B36: NO, B46: NO), it stops sending the message to the ECU to be processed (B58) and terminates vehicle-side processing.

[0129] (2) Center-side processing performed by the OTA center 2 (see FIG. 24) When the OTA center 2 starts the center-side processing, it determines whether the processing target identification table has been updated (A21). If the OTA center 2 determines that the processing target identification table has been updated (A21: YES), it generates a processing target identification table to be distributed to the vehicle side (A22) and executes synchronization processing with the vehicle side (A23).

[0130] After executing the synchronization process with the vehicle side, the OTA center 2 determines a processing target identification table to be distributed to the vehicle side (A24) and determines whether an update request for the processing target identification table has been received (A25). If the OTA center 2 determines that the update request for the processing target identification table distributed from the vehicle system 3 has been received (A25: YES), the OTA center 2 distributes the processing target identification table to the vehicle system 3 (A26, corresponding to the specific information distribution procedure), and terminates the center-side process. On the other hand, if the OTA center 2 determines that the update request for the processing target identification table has not been received (A26: NO), the OTA center 2 transmits distribution disable information to the related systems indicating that the distribution of the processing target identification table to the vehicle system 3 is not possible (A27), and terminates the center-side process.

[0131] As described above, the second embodiment can achieve the following advantageous effects. The CGW 4 stores processing instructions based on messages or files in an SOVD format conforming to the SOVD communication specifications, and a processing target identification table that can identify the ECU to be processed that corresponds to the processing instruction. When a processing instruction based on a message or file in an SOVD format is accepted, the processing target identification table is referenced, and the ECU to be processed that corresponds to the accepted processing instruction is identified based on the connection destination information. When a processing instruction based on a message or file in an SOVD format conforming to the SOVD communication specifications is accepted, the ECU to be processed that corresponds to the accepted processing instruction can be appropriately identified, and the SOVD service can be appropriately implemented.

[0132] When a processing instruction based on a message or file in the SOVD format is accepted, the processing target identification table is referenced, and the processing method corresponding to the accepted processing instruction is identified based on the processing method information. In addition to appropriately identifying the ECU to be processed corresponding to the accepted processing instruction, it is possible to appropriately identify the processing method corresponding to the accepted processing instruction.

[0133] When the ECU to be processed is not identified, unidentifiable information indicating that the ECU to be processed has not been identified is transmitted to the OTA center 2. The OTA center 2 can be notified that the ECU to be processed has not been identified.

[0134] When a processing instruction based on a message or file in the SOVD format is received, the processing target identification table is referenced, and it is determined based on the support information whether the request of the received processing instruction is met. In addition to properly identifying the ECU to be processed that corresponds to the received processing instruction, it is also possible to properly determine whether the request of the received processing instruction is met.

[0135] If the received processing instruction request is not supported, non-support information indicating that the ECU to be processed does not support the processing instruction request is transmitted to the OTA center 2. It is possible to notify the OTA center 2 that the ECU to be processed does not support the processing instruction request.

[0136] When the ECU to be processed does not respond to the request for the processing instruction, non-response information indicating that the ECU to be processed did not respond to the request for the processing instruction is transmitted to the OTA center 2. It is possible to notify the OTA center 2 that the ECU to be processed did not respond to the request for the processing instruction.

[0137] When the ECU to be processed corresponding to the received processing instruction is not identified based on the connection destination information, an update request for updating the processing target identification table is transmitted to the OTA center 2. The latest processing target identification table stored in the OTA center 2 can be acquired from the OTA center 2.

[0138] When it is determined that the processing target identification table has been updated in the OTA center 2, an update request for updating the processing target identification table is transmitted to the OTA center 2. In this case, too, the latest processing target identification table held in the OTA center 2 can be acquired from the OTA center 2.

[0139] The processing target identification table held in the processing target identification table holding unit 31 is updated by the processing target identification table acquired from the OTA center 2. The processing target identification table held in the vehicle system 3 can be synchronized with the processing target identification table held in the OTA center 2, and the latest processing target identification table can be held in the vehicle system 3.

[0140] In the OTA center 2, the processing target identification table held in the processing target identification table holding unit 41 is distributed to the vehicle system 3. The processing target identification table held in the vehicle system 3 can be synchronized with the processing target identification table held in the OTA center 2, and the latest processing target identification table can be held in the vehicle system 3.

[0141] Next, supplementary explanations of the above content will be provided with reference to Figures 25 to 32. Figures 25 and 26 show the various functions installed in the vehicle. The SOVD receiver 51 corresponds to, for example, the downloader 7 described with reference to Figures 1 and 11. The SOVD converter 52 corresponds to, for example, the V-UCM or the diagnostic app described with reference to Figures 14 and 15. The SOVD execution management unit 53 corresponds to, for example, the SOVD, UCM, ODX / OTX, UDS, and ECU-embedded programs described with reference to Figures 14 and 15. The SOVD processing unit 54 corresponds to, for example, the SOVD-compatible ECU 15, UCM-compatible ECU 14, ODX / OTX-compatible ECU 17, and UDS-compatible ECU 16 described with reference to Figures 1 and 11.

[0142] The SOVD receiving unit 51 receives a message or file based on the SOVD format from the OTA center 2, interprets the SOVD format of the received message or file, and outputs an execution instruction to the SOVD converting unit 52. The SOVD converting unit 52 accepts the execution instruction from the SOVD receiving unit 51 and outputs a processing instruction to the SOVD execution managing unit 53 located under it. The SOVD execution managing unit 53 identifies a service to be transmitted based on the processing target identification table shown in Figure 13. When the service to be transmitted is identified by the SOVD execution managing unit 53, the SOVD processing unit 54 performs processing based on the identified service.

[0143] The SOVD receiver 51, the SOVD converter 52, and the SOVD execution manager 53 may be located in the same CGW 4 or in different CGWs 4. When the SOVD execution manager 53 identifies the service to be transmitted, it prepares to transmit a message to the SOVD processor 54. When the SOVD execution manager 53 does not identify the service to be transmitted but has downloaded a program to be executed, it executes the program to prepare to transmit a message to the SOVD processor 54.

[0144] After preparing to send a message to the SOVD processing unit 54, the SOVD execution management unit 53 accesses and processes the target information by sending the message to the SOVD processing unit 54. The SOVD execution management unit 53 determines whether additional processing is necessary based on the response result from the SOVD processing unit 54, and if it determines that additional processing is necessary, it requests the SOVD processing unit 54 to issue an instruction for additional processing.

[0145] Next, an overview of SOVD will be described with reference to FIGS. 27 to 32. As shown in FIG. 27, the OTA master 8 has a conversion map for converting SOVD messages. For example, if the SOVD message is "https: / / ...[restAPI]Get++**;+pp;;fajkl;ae," the OTA master 8 converts "++**;+pp;;fajkl;ae" using one-to-one or one-to-many conversion according to the conversion map. When one-to-many conversion is performed, the OTA master 8 creates a sequence that includes the transmission order of multiple converted messages. The update masters 9 to 12 convert general-purpose messages. For example, the update masters 9 to 12 convert general-purpose messages using one-to-one or one-to-many conversion according to the conversion map. When one-to-many conversion is performed, the update masters 9 to 12 create a sequence that includes the transmission order of multiple converted messages. As described above, a sequence may be created by modifying the default sequence depending on the content of the specification data.

[0146] As shown in FIG. 28, when the update masters 9-12 perform one-to-one conversion, they convert "++**;+pp;;fajkl;ae" to, for example, "SID22 DID" in the one-to-one conversion. When the OTA master 8 performs one-to-many conversion and each update master 9-12 performs one-to-many conversion, as shown in FIG. 29, the OTA master 8 may execute a communication sequence with multiple update masters 9-12, and each update master 9-12 may execute a communication sequence with multiple target ECUs. The communication sequence between the OTA master 8 and multiple update masters 9-12 may include a sequence of sending general-purpose messages to the multiple update masters 9-12. The communication sequence between one update master and multiple target ECUs may include a sequence of sending messages to the multiple target ECUs.

[0147] As shown in FIG. 30 , upon receiving a diagnostic result from the vehicular system 5, the OTA center 2 has the functions of referring to the diagnostic scenario, executing a diagnostic sequence according to the diagnostic procedure, analyzing the received diagnostic result, and identifying the next action, as well as storing the diagnostic result. The OTA center 2 executes the diagnostic sequence according to the diagnostic procedure. The diagnostic sequence includes a sequence for transmitting a message based on the SOVD format from the OTA center 2 to the vehicular system 5 to execute multiple diagnostic applications in sequence. The vehicular system 5 selects one of the multiple diagnostic applications according to identification information acquired from the OTA center 2. Specifically, the downloader 7 transfers the message to one of the multiple diagnostic applications according to a path included in the message based on the SOVD format, and the diagnostic application receiving the message executes diagnostic processing according to the content of the message.

[0148] When the OTA center 2 receives, from the vehicle system 5, the diagnosis result of the diagnostic app 1, for example, a periodic diagnosis result of the periodic diagnosis app, the OTA center 2 analyzes the periodic diagnosis result. When the OTA center 2 obtains an analysis result that is associated with a requirement for detailed diagnosis in the diagnostic procedure, the OTA center 2 specifies, as the next action, the execution of the detailed diagnosis that is associated with a requirement for detailed diagnosis in the diagnostic procedure. In this case, the OTA center 2 transmits, for example, an instruction to execute detailed diagnosis to the vehicle system 5 as an instruction to start execution of the diagnostic app 2. When the vehicle system 5 receives the instruction to start execution of the diagnostic app 2 from the OTA center 2, the vehicle system 5 executes, for example, a detailed diagnosis using the diagnostic app 2 and transmits the diagnosis result of the diagnostic app 2 to the OTA center 2.

[0149] When the OTA center 2 receives the diagnosis result of the diagnostic app 2 from the vehicle system 5, it analyzes the detailed diagnosis result. When the OTA center 2 obtains an analysis result that is associated with a cause identification diagnosis requirement in the diagnostic procedure, it specifies, as the next action, the execution of the cause identification diagnosis that is associated with the cause identification diagnosis requirement in the diagnostic procedure. In this case, the OTA center 2 transmits, for example, a cause identification diagnosis execution instruction to the vehicle system 5 as an execution start instruction for the diagnostic app 3. When the vehicle system 5 receives the execution start instruction for the diagnostic app 2 from the OTA center 3, it executes, for example, a cause identification diagnosis using the diagnostic app 3 and transmits the diagnosis result of the diagnostic app 3 to the OTA center 2.

[0150] When the OTA center 2 receives the diagnosis result of the diagnostic application 3 from the vehicle system 5, it analyzes the cause identification diagnosis result, and if, for example, a software abnormality is identified, the next action is to identify the software update associated with the abnormality in the diagnostic procedure, and deliver the software update data to the vehicle system 5 and issue a software update instruction via an SOVD message.

[0151] As shown in Figures 31 and 32, when conversion is performed according to one-to-many conversion, "++**;+pp;;fajkl;ae" is converted to, for example, "SID22 DID, SID10, SID27, ..." or "StartRepro" in the one-to-many conversion.

[0152] The present disclosure includes the following inventions in addition to what is set forth in the claims: [1] A vehicle system (3) for acquiring a message or file in an SOVD format conforming to SOVD communication specifications, the vehicle system comprising: a vehicle-side identification information storage unit (31) for storing processing target identification information indicating an association between a processing instruction based on the message or file in the SOVD format and connection destination information capable of identifying a processing target corresponding to the processing instruction, a processing instruction receiving unit (32) for receiving the processing instruction, and a processing target identification unit (33) for, when the processing instruction is received by the processing instruction receiving unit, referring to the processing target identification information and identifying a processing target corresponding to the received processing instruction based on the connection destination information.

[0153] [2] The vehicle system described in [1], wherein the processing target identification information includes, in addition to the connection destination information, processing method information that can identify a processing method for the processing target, and when the processing instruction is accepted by the processing instruction accepting unit, the processing target identification unit refers to the processing target identification information, and not only identifies the processing target corresponding to the accepted processing instruction based on the connection destination information, but also identifies a processing method for the processing target based on the processing method information.

[0154] [3] A vehicle system according to [1] or [2], comprising an unidentifiable information transmitting unit (34) that transmits unidentifiable information indicating that the processing target has not been identified to an external device when the processing target has not been identified by the processing target identifying unit.

[0155] [4] The processing target identification information includes, in addition to the connection destination information, support information that can identify whether the processing target corresponds to the request of the processing instruction, and when the processing instruction is accepted by the processing instruction accepting unit, the processing target identification unit refers to the processing target identification information and identifies the processing target that corresponds to the accepted processing instruction based on the connection destination information, and further identifies whether the processing target corresponds to the request of the processing instruction based on the support information. [5] The vehicle system described in any one of [1] to [3].

[0156] [5] The vehicle system described in [4] is provided with a non-compliant information transmission unit (35) that, when the processing target is identified by the processing target identification unit but the processing target does not correspond to the request of the processing instruction, transmits non-compliant information indicating that the processing target does not correspond to the request of the processing instruction to an external device.

[0157] [6] The vehicle system according to [4], further comprising a non-response information transmitting unit (36) that transmits non-response information indicating that the processing target has not responded to the processing instruction request to an external device when the processing target is identified by the processing target identifying unit and the processing target is identified as corresponding to the processing instruction request by the processing target identifying unit, but the processing target has not responded to the processing instruction request.

[0158] [7] The vehicle system according to any one of [1] to [6], further comprising an update request sending unit (37) that sends an update request for updating the processing target identification information to an external device.

[0159] [8] The vehicle system described in [7], wherein when the update request sending unit sends the update request to the external device, the update request sending unit sends information that can identify the processing target specific information stored in the vehicle-side specific information storage unit to the external device.

[0160] [9] The vehicle system according to [7] or [8], wherein the update request transmission unit transmits the update request to an external device when the processing target is not identified by the processing target identification unit.

[0161]

[10] The vehicle system according to [7] or [8], wherein the update request sending unit periodically determines whether the processing target specific information in the external device has been updated, and when it determines that the processing target specific information in the external device has been updated, sends the update request to the external device.

[0162]

[11] A vehicle system described in any one of [7] to

[10] , comprising: a specific information acquisition unit (38) that acquires the processing target specific information from the external device; and a specific information update unit (39) that updates the processing target specific information stored in the vehicle side specific information storage unit with the processing target specific information acquired by the specific information acquisition unit.

[0163]

[12] A vehicle system according to any one of [1] to

[11] , comprising a format conversion unit (19) that converts a message or file in the SOVD format into a message or file in a non-SOVD format that corresponds to the processing target identified by the processing target identification unit.

[0164]

[13] An external device (2) that distributes a message or file in SOVD format conforming to the SOVD communication specifications to a vehicle system, the external device comprising: an external specific information storage unit (41) that stores processing target specific information indicating an association between a processing instruction based on the message or file in SOVD format and connection destination information that can identify a processing target corresponding to the processing instruction; and a specific information distribution unit (42) that distributes the processing target specific information stored in the external specific information storage unit to the vehicle system.

[0165]

[14] An external device as described in

[13] , which includes an update request receiving unit (43) that receives an update request sent from the vehicle system, and the specific information distribution unit determines whether or not to distribute the processing target specific information stored in the external specific information storage unit to the vehicle system based on the update request received by the update request receiving unit.

[0166]

[15] The update request includes configuration information that can identify the configuration on the vehicle side, and the specific information distribution unit determines whether to distribute the processing target specific information stored in the vehicle exterior specific information storage unit to the vehicle system based on the configuration information included in the update request.

[0167]

[16] An exterior device according to any one of

[13] to

[15] , comprising an update determination unit (44) that determines whether the processing target specific information stored in the exterior specific information storage unit has been updated, and the specific information distribution unit determines whether the processing target specific information stored in the exterior specific information storage unit should be distributed to the vehicle system based on whether the processing target specific information stored in the exterior specific information storage unit has been updated.

[0168]

[17] The external vehicle device according to any one of

[13] to

[16] , further comprising a delivery impossible information sending unit (45) that sends delivery impossible information to a related system indicating that the processing target specific information cannot be delivered to the vehicle system when the specific information delivery unit is unable to deliver the processing target specific information to the vehicle system.

[0169] Although the present disclosure has been described with reference to the embodiments, it is understood that the present disclosure is not limited to the embodiments or structures. The present disclosure also encompasses various modifications and modifications within the scope of equivalents. In addition, various combinations and forms, as well as other combinations and forms including only one element, more than one element, or less than one element, are also within the scope and spirit of the present disclosure.

[0170] An OTA center has been used as an example of an external device, and the case of providing wireless repro and wireless diagnostic services has been described, but the external device may also be configured to use a wired tool that is wired connected to the CGW via an in-vehicle network, and can also be applied to cases where wired repro and wired diagnostic services are provided.

[0171] The control unit and the method described herein may be implemented by a special-purpose computer configured by configuring a processor and memory programmed to perform one or more functions embodied in a computer program. Alternatively, the control unit and the method described herein may be implemented by a special-purpose computer configured by configuring a processor with one or more dedicated hardware logic circuits. Alternatively, the control unit and the method described herein may be implemented by one or more special-purpose computers configured by combining a processor and memory programmed to perform one or more functions with a processor configured with one or more hardware logic circuits. Furthermore, the computer program may be stored as instructions executed by a computer on a computer-readable non-transitory tangible storage medium.

Claims

1. A vehicle system (3) that acquires a message or file in a SOVD format that conforms to the communication specifications of the SOVD, comprising: a vehicle-side identification information storage unit (31) that stores processing target identification information indicating an association between a processing instruction based on the message or file in the SOVD format and connection destination information that can identify a processing target corresponding to the processing instruction; a processing instruction receiving unit (32) that receives the processing instruction; and a processing target identification unit (33) that, when the processing instruction is received by the processing instruction receiving unit, refers to the processing target identification information and identifies a processing target corresponding to the received processing instruction based on the connection destination information.

2. A vehicle system as described in claim 1, wherein the processing target identification information includes, in addition to the connection destination information, processing method information capable of identifying a processing method for the processing target, and when the processing instruction is accepted by the processing instruction accepting unit, the processing target identification unit refers to the processing target identification information and identifies the processing target corresponding to the accepted processing instruction based on the connection destination information, and further identifies the processing method for the processing target based on the processing method information.

3. A vehicle system as described in claim 1, further comprising an unidentifiable information transmission unit (34) which, when the processing target is not identified by the processing target identification unit, transmits unidentifiable information indicating that the processing target has not been identified to an external device.

4. The processing target identification information includes, in addition to the connection destination information, support information capable of identifying whether the processing target corresponds to the request of the processing instruction, and when the processing instruction is accepted by the processing instruction accepting unit, the processing target identification unit refers to the processing target identification information and identifies the processing target corresponding to the accepted processing instruction based on the connection destination information, and further identifies whether the processing target corresponds to the request of the processing instruction based on the support information.A vehicle system as described in claim 1.

5. A vehicle system as described in claim 4, further comprising a non-compliance information transmission unit (35) which, when the processing target is identified by the processing target identification unit, but the processing target is determined to be incompatible with the processing instruction request, transmits non-compliance information indicating that the processing target does not comply with the processing instruction request to an external device.

6. A vehicle system as described in claim 4, further comprising a non-response information transmitting unit (36) that transmits non-response information indicating a failure to respond to the processing instruction request to an external device when the processing target is identified by the processing target identification unit and the processing target is identified by the processing target identification unit as corresponding to the processing instruction request, but the processing target does not respond to the processing instruction request.

7. The vehicle system according to claim 1, further comprising an update request transmission unit (37) for transmitting an update request for updating the processing target specific information to an external device.

8. A vehicle system as described in claim 7, wherein the update request sending unit, when sending the update request to an external device, sends information capable of identifying the processing target specific information stored in the vehicle side specific information storage unit to the external device.

9. The vehicle system according to claim 7, wherein the update request transmission unit transmits the update request to an external device when the processing target is not identified by the processing target identification unit.

10. A vehicle system as described in claim 7, wherein the update request sending unit periodically determines whether the processing target specific information in the external device has been updated, and when it determines that the processing target specific information in the external device has been updated, sends the update request to the external device.

11. A vehicle system as described in claim 7, comprising: a specific information acquisition unit (38) that acquires the processing target specific information from the external vehicle device; and a specific information update unit (39) that updates the processing target specific information stored in the vehicle side specific information storage unit with the processing target specific information acquired by the specific information acquisition unit.

12. A vehicle system as described in any one of claims 1 to 11, comprising a format conversion unit (19) that converts a message or file in SOVD format into a message or file in a non-SOVD compatible format that corresponds to the processing target identified by the processing target identification unit.

13. A data communication system (1) comprising an external device (2) that distributes messages or files in a SOVD format conforming to the communication specifications of SOVD, and a vehicle system (3) that receives the messages or files in the SOVD format distributed from the external device, wherein the vehicle system comprises: a vehicle-side specific information storage unit (31) that stores processing target specific information indicating an association between a processing instruction based on the message or file in the SOVD format and connection destination information capable of identifying a processing target corresponding to the processing instruction; a processing instruction receiving unit (32) that receives the processing instruction; and a processing target identification unit (33) that, when the processing instruction is received by the processing instruction receiving unit, refers to the processing target specific information and identifies a processing target corresponding to the received processing instruction based on the connection destination information.

14. A processing target identification program that causes a control unit (6) of a vehicle system (3) that holds processing target identification information indicating an association between a processing instruction based on a message or file in SOVD format conforming to the communication specifications of SOVD and connection destination information capable of identifying a processing target corresponding to the processing instruction to execute: a processing instruction acceptance procedure for accepting a processing instruction based on a message or file in SOVD format; and a processing target identification procedure for, when the processing instruction is accepted by the processing instruction acceptance procedure, referring to the processing target identification information and identifying a processing target corresponding to the accepted processing instruction based on the connection destination information.

15. A processing target identification method in a vehicle system (3) that holds processing target identification information indicating an association between a processing instruction based on a message or file in SOVD format conforming to SOVD communication specifications and connection destination information capable of identifying a processing target corresponding to the processing instruction, the processing target identification method comprising: a processing instruction acceptance procedure that accepts a processing instruction based on a message or file in SOVD format; and a processing target identification procedure unit that, when the processing instruction is accepted by the processing instruction acceptance procedure, refers to the processing target identification information and identifies a processing target corresponding to the accepted processing instruction based on the connection destination information.

16. An external device (2) that delivers a message or file in an SOVD format conforming to the SOVD communication specifications to a vehicle system, comprising: an external-vehicle specific information storage unit (41) that stores processing target specific information indicating an association between a processing instruction based on the message or file in the SOVD format and connection destination information capable of identifying a processing target corresponding to the processing instruction; and a specific information distribution unit (42) that distributes the processing target specific information stored in the external-vehicle specific information storage unit to the vehicle system.

17. An external device as described in claim 16, further comprising an update request receiving unit (43) for receiving an update request transmitted from the vehicle system, wherein the specific information distribution unit determines whether or not to distribute the specific information to be processed stored in the outside-vehicle specific information storage unit to the vehicle system based on the update request received by the update request receiving unit.

18. An external device as described in claim 17, wherein the update request includes configuration information capable of identifying the configuration on the vehicle side, and the specific information distribution unit determines whether or not to distribute the processing target specific information stored in the outside-vehicle specific information storage unit to the vehicle system based on the configuration information included in the update request.

19. An exterior device as described in claim 16, further comprising an update determination unit (44) that determines whether the processing target specific information stored in the vehicle exterior specific information holding unit has been updated, and the specific information distribution unit determines whether or not to distribute the processing target specific information stored in the vehicle exterior specific information holding unit to the vehicle system based on whether the processing target specific information stored in the vehicle exterior specific information holding unit has been updated.

20. An external vehicle device as described in any one of claims 16 to 19, further comprising a delivery failure information transmission unit (45) which transmits delivery failure information to a related system indicating that the processing target specific information cannot be delivered to the vehicle system when the specific information distribution unit is unable to deliver the processing target specific information to the vehicle system.

21. A specific information distribution program that distributes a message or file in a SOVD format conforming to the SOVD communication specifications to a vehicle system, and causes an external device (2) that holds processing target specific information indicating an association between a processing instruction based on the message or file in the SOVD format and connection destination information capable of identifying a processing target corresponding to the processing instruction to execute a specific information distribution procedure for distributing the processing target specific information to the vehicle system.

22. A specific information distribution method in an external device (2) that distributes a message or file in a SOVD format conforming to the SOVD communication specifications to a vehicle system and retains processing target specific information indicating an association between a processing instruction based on the message or file in the SOVD format and connection destination information capable of identifying a processing target corresponding to the processing instruction, the method comprising the steps of:

23. A vehicle system as described in claim 2, further comprising a sequence creation and execution unit (9 to 12) that creates and executes a sequence, wherein when the processing target identification unit identifies a collection method as the processing method, it transmits the SOVD format message or a general-purpose message obtained by converting the SOVD message to the sequence creation and execution unit corresponding to the processing target, and causes the sequence creation and execution unit to create and execute a sequence according to the processing target.

24. A vehicle system as described in claim 23, wherein the sequence creation and execution unit creates and executes any one of a sequence conforming to a UCM format conforming to the UCM communication specifications, a sequence conforming to an ODX / OTX format conforming to the SOVD communication specifications, a sequence conforming to an ODX / OTX format conforming to the ODX / OTX communication specifications, and a sequence conforming to an ODX / OTX format conforming to the UDS communication specifications.

25. A vehicle system as described in claim 23, wherein when the processing target identification unit identifies that there are multiple processing targets, the processing target identification unit creates a sequence including a processing order for the multiple processing targets based on a default sequence.

26. The vehicle system according to claim 25, wherein the processing target specification unit thins out from the default sequence processing for a processing target that corresponds to the SOVD format message or the general-purpose message but is not supported by the vehicle.

27. A vehicle system as described in claim 23, wherein, if the sequence creation execution unit is unable to create a sequence, it transmits error information indicating that the sequence cannot be created, together with the reason for the error, to the sender of the SOVD format message or the general-purpose message.

28. The vehicle system according to claim 27, wherein the sequence creation execution unit requests software for creating a sequence from the sender of the SOVD format message or the general-purpose message.

29. A vehicle system as described in claim 2, wherein the processing target identification unit, when identifying a relay method as the processing method, transmits to the processing target a message in the SOVD format or a general-purpose message obtained by converting the SOVD message.

30. A vehicle system as described in claim 2, wherein the processing target identification unit, when identifying a storage method as the processing method, acquires from the processing target and stores diagnostic information corresponding to the SOVD format message or a general-purpose message converted from the SOVD message.

Images