Vehicle electronic control device, data communication system, format conversion program, format conversion method, and vehicle system

Abstract

This vehicle electronic control device (4) transmits a message or file acquired from an out-of-vehicle device to an electronic control device in the vehicle. The vehicle electronic control device comprises: an out-of-vehicle communication unit (6) that performs out-of-vehicle communication with an out-of-vehicle device; an in-vehicle communication unit (18) that performs in-vehicle communication with an electronic control device; and a format conversion unit (19) that converts the SOVD format of the out-of-vehicle communication into a non-SOVD-compatible format if the out-of-vehicle communication is data communication in the SOVD format and the delivery destination of the message or file is an electronic control device that is non-SOVD-compatible. The in-vehicle communication unit performs in-vehicle communication according to the non-SOVD-compatible format.

Description

Vehicle electronic control device, data communication system, format conversion program, format conversion method, and vehicle system CROSS-REFERENCE TO RELATED APPLICATIONS

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

[0002] The present disclosure relates to a vehicle electronic control device, a data communication system, a format conversion program, a format conversion method, and a vehicle system.

[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 HPCs (High-Performance Computers) that implement AUTOSAR Adaptive, Service-Oriented Vehicle Diagnostics (SOVD) technology is being provided as a next-generation diagnostic function. In the SOVD service, the SOVD format, which conforms to the SOVD communication specifications, is applied to center-to-center communications between the OTA center and the vehicle.

[0006] On the other hand, on the vehicle side, not all ECUs will necessarily be replaced with SOVD-compatible ECUs that support the SOVD service, and it is expected that SOVD-compatible ECUs and SOVD-incompatible ECUs that do not support the SOVD service will coexist. Therefore, it is expected that the SOVD service can be realized for the SOVD-compatible ECUs, but the SOVD service cannot be realized for the SOVD-incompatible ECUs.

[0007] Such a situation is also anticipated when the SOVD service is other than OTA repro, such as diagnosis or log collection. Furthermore, such a situation is not limited to when the SOVD format conforming to the SOVD communication specifications is applied to center-to-center communication between the OTA center and the vehicle side, but is also anticipated when, for example, the SOVD format conforming to the SOVD communication specifications is applied to data communication between a proximity external device connected to the vehicle side by wire and the vehicle side, or when the SOVD format conforming to the SOVD communication specifications is applied to data communication between an in-vehicle app or the like and other in-vehicle elements.

[0008] The present disclosure aims to properly realize SOVD services for electronic control devices that are not SOVD compatible, and to properly realize SOVD services even when a vehicle contains a mixture of devices that are compatible with SOVD communication specifications and devices that are compatible with communication specifications other than SOVD.

[0009] According to one aspect of the present disclosure, an electronic control device for a vehicle transmits a message or file acquired from an external device to an electronic control device in the vehicle. An external communication unit performs external communication with the external device. An internal communication unit performs internal communication with the electronic control device. A format conversion unit converts the SOVD format of the external communication into an SOVD-incompatible format when the external communication is data communication conforming to the SOVD communication specifications and the destination of the message or file based on the SOVD format is an electronic control device that does not support SOVD. The internal communication unit performs the internal communication in accordance with the SOVD-incompatible format converted by the format conversion unit.

[0010] According to one aspect of the present disclosure, the data communication system includes an external device and a vehicle electronic control unit that transmits a message or file acquired from the external device to an in-vehicle electronic control unit. In the vehicle electronic control unit, an external-vehicle communication unit performs external-vehicle communication with the external device. An internal-vehicle communication unit performs internal-vehicle communication with the electronic control unit. A format conversion unit converts the SOVD format of the external-vehicle communication into an SOVD-incompatible format when the external-vehicle communication is data communication conforming to SOVD communication specifications and the destination of the message or file based on the SOVD format is an electronic control unit that does not support SOVD. The internal-vehicle communication unit performs the internal-vehicle communication in accordance with the SOVD-incompatible format converted by the format conversion unit.

[0011] According to one aspect of the format conversion program of the present disclosure, an electronic control device for a vehicle that transmits a message or file acquired from an external device to an electronic control device in the vehicle, and that is equipped with an external communication unit that performs external communication with the external device and an internal communication unit that performs internal communication with the electronic control device, is made to execute a format conversion procedure that converts the SOVD format of the external communication into an SOVD-incompatible format when the external communication is data communication that conforms to the SOVD communication specifications and the destination of the message or file based on the SOVD format is an electronic control device that is not SOVD-compatible, and a communication procedure that performs the internal communication in accordance with the SOVD-incompatible format converted by the format conversion procedure.

[0012] According to one aspect of the format conversion method of the present disclosure, in an electronic control device for a vehicle that transmits a message or file acquired from an external device to an electronic control device in the vehicle, the electronic control device includes an external communication unit that performs external communication with the external device and an internal communication unit that performs internal communication with the electronic control device, when the external communication is data communication conforming to the SOVD communication specifications and the destination of the message or file based on the SOVD format is an electronic control device that does not support SOVD, the electronic control device performs a format conversion procedure that converts the SOVD format of the external communication into a SOVD-incompatible format, and a communication procedure that performs the internal communication in accordance with the SOVD-incompatible format converted by the format conversion procedure.

[0013] According to one aspect of the present disclosure, when the external-vehicle communication with the external device is data communication conforming to the SOVD communication specifications and the destination of a message or file based on the SOVD format is an electronic control device that does not support SOVD, the SOVD format of the external-vehicle communication is converted to a SOVD-incompatible format. The internal-vehicle communication is performed in accordance with the converted SOVD-incompatible format. By converting the SOVD format of the external-vehicle communication into the SOVD-incompatible format and performing the internal-vehicle communication in accordance with the converted SOVD-incompatible format, the SOVD service can be appropriately implemented for the electronic control device that does not support SOVD.

[0014] According to one aspect of the vehicular system of the present disclosure, a message or file acquired from a distribution source is transmitted to a distribution destination within the vehicle. A first communication unit performs first communication with the distribution source. A second communication unit performs second communication within the vehicle with the distribution destination. A format conversion unit converts the SOVD format of the first communication into a format compatible with the distribution destination when the first communication is data communication conforming to SOVD communication specifications and a message or file based on the SOVD format is distributed to the distribution destination. The second communication unit performs the second communication in accordance with the format compatible with the distribution destination converted by the format conversion unit.

[0015] According to one aspect of the present disclosure, when the first communication is data communication conforming to the SOVD communication specifications and a message or file based on the SOVD format is delivered to a delivery destination, the SOVD format of the first communication is converted into a format compatible with the delivery destination. The second communication is performed in accordance with the converted format compatible with the delivery destination. The SOVD service can be appropriately implemented even when vehicles have a mixture of devices compatible with the SOVD communication specifications and devices compatible with communication specifications other than the SOVD.

[0016] According to one aspect of the present disclosure, a vehicle system transmits information acquired from an information source within a vehicle to a destination. A first communication unit performs first communication with the destination. A second communication unit performs second communication within the vehicle with the information source within the vehicle. A format formation unit forms the SOVD format from a format acquired from the information source within the vehicle and compatible with the information source within the vehicle when the first communication is data communication conforming to SOVD communication specifications and a message or file based on the SOVD format is to be distributed to a destination. The second communication unit performs the second communication in accordance with the format compatible with the information source within the vehicle. The first communication unit performs the first communication in accordance with the SOVD format formed by the format formation unit.

[0017] According to one aspect of the present disclosure, when the first communication is data communication conforming to the SOVD communication specifications and a message or file based on the SOVD format is distributed to a distribution destination, the SOVD format is formed from a format acquired from an in-vehicle information source compatible with the in-vehicle information source. The second communication is performed according to the format compatible with the in-vehicle information source. The first communication is performed according to the formed SOVD format. The SOVD service can be appropriately implemented even when the vehicle has a mixture of devices compatible with the SOVD communication specifications and devices compatible with communication specifications other than the SOVD.

[0018] According to one aspect of the vehicle system of the present disclosure, the system includes a SOVD receiving unit that receives a message or file based on the SOVD format from an external device, interprets the SOVD format of the received message or file, and outputs an execution instruction to a SOVD conversion unit; a SOVD conversion unit that accepts the execution instruction from the SOVD receiving unit and outputs a processing instruction to a SOVD execution management unit located under the SOVD receiving unit; a SOVD execution management unit that accepts the processing instruction from the SOVD conversion unit and identifies a service to be sent based on processing target identification information that indicates an association between the 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; and a SOVD processing unit that performs processing based on the service identified by the SOVD execution management unit.

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

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

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

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

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

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

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

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

[0027] 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).

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

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

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

[0031] 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).

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

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

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

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

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

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

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

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

[0040] 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0064] (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.

[0065] (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).

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

[0067] (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).

[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 (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).

[0069] 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).

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

[0071] (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.

[0072] (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.

[0073] (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.

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

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

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

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

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

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

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

[0081] 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0120] (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).

[0121] 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).

[0122] 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).

[0123] 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).

[0124] 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).

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

[0126] 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).

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

[0128] 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).

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

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

[0131] (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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0154] The present disclosure includes the following inventions in addition to what is set forth in the claims: [1] An electronic control device for a vehicle (4) that transmits a message or a file acquired from an external device to an electronic control device in a vehicle, comprising: an external-vehicle communication unit (7) that performs external-vehicle communication with the external device, an internal-vehicle communication unit (18) that performs internal-vehicle communication with the electronic control device, and a format conversion unit (19) that converts the SOVD format of the external-vehicle communication into an SOVD-incompatible format when the external-vehicle communication is data communication conforming to SOVD communication specifications and the destination of the message or file based on the SOVD format is an SOVD-incompatible electronic control device, and the internal-vehicle communication unit performs the internal-vehicle communication in accordance with the SOVD-incompatible format converted by the format conversion unit.

[0155] [2] The format conversion unit converts the SOVD non-compatible format into at least one of a UDS format conforming to the UDS communication specifications, a UCM format conforming to the UCM communication specifications, and an ODX / OTX format conforming to the ODX / OTX communication specifications. [1] An electronic control device for a vehicle as described in [1].

[0156] [3] An electronic control device for a vehicle according to [1] or [2], further comprising a first compatibility table holding unit (20) that holds a first compatibility table for converting the SOVD format, wherein the format conversion unit converts the SOVD format of the outside-vehicle communication into the SOVD-incompatible format using the first compatibility table held in the first compatibility table holding unit.

[0157] [4] The vehicle electronic control device according to any one of [1] to [3], further comprising a format forming unit (26) that forms the SOVD format from the SOVD-incompatible format acquired from the SOVD-incompatible electronic control device.

[0158] [5] The format forming unit forms the SOVD format from at least one of the following formats that are non-SOVD compatible: a UDS format conforming to the UDS communication specifications, a UCM format conforming to the UCM communication specifications, and an ODX / OTX format conforming to the ODX / OTX communication specifications. [4] An electronic control device for a vehicle as described in [4].

[0159] [6] An electronic control device for a vehicle as described in [4] or [5], which includes a second compatibility table holding unit (27) that holds a second compatibility table for forming a format, and the format forming unit forms the SOVD format from the SOVD-incompatible format acquired from the SOVD-incompatible electronic control device using the second compatibility table held in the second compatibility table.

[0160] [7] A data communication system (1) comprising an external device (2) and a vehicle system (5), wherein, when data communication is performed between the external device and the vehicle system, a format identifier indicating whether the data communication format is a RestAPI format or an SOVD format is assigned to the data communication system.

[0161] [8] The data communication system according to [7], wherein the external device or the vehicle system determines whether the data is received in the RestAPI format or the SOVD format based on a format identifier.

[0162] [9] A data communication system according to [7] or [8], wherein the external device or the vehicle system transmits data in a RestAPI format when the type of data to be transmitted is a first type, and transmits data in an SOVD format when the type of data to be transmitted is a second type.

[0163]

[10] A system (5) for a vehicle that transmits a message or file acquired from a distribution source to a distribution destination within a vehicle, comprising: a first communication unit (7) that performs a first communication with the distribution source; a second communication unit (18) that performs a second communication within the vehicle with the distribution destination; and a format conversion unit (19) that converts the SOVD format of the first communication into a format compatible with the distribution destination when the first communication is data communication conforming to SOVD communication specifications and a message or file based on the SOVD format is distributed to the distribution destination, and the second communication unit performs the second communication in accordance with the format compatible with the distribution destination converted by the format conversion unit.

[0164]

[11] The format conversion unit converts the format into at least one of a UDS format conforming to the UDS communication specifications, a UCM format conforming to the UCM communication specifications, and an ODX / OTX format conforming to the ODX / OTX specifications, as a format supported by the distribution destination.

[10] A vehicle system according to the present invention.

[0165]

[12] A vehicle system according to

[10] or

[11] , further comprising a first compatibility table holding unit (20) that holds a first compatibility table for converting the SOVD format, wherein the format conversion unit converts the SOVD format of the first communication into a format compatible with the distribution destination using the first compatibility table held in the first compatibility table holding unit.

[0166]

[13] The vehicle system according to any one of

[10] to

[12] , wherein the distribution source is an external device, and the first communication unit performs external communication with the external device as the first communication.

[0167]

[14] A vehicle system (5) that transmits information acquired from an information source within a vehicle to a destination, comprising: a first communication unit (7) that performs a first communication with the destination; a second communication unit (18) that performs a second communication within the vehicle with the information source within the vehicle; and a format forming unit (26) that forms the SOVD format from a format supported by the information source within the vehicle acquired from the information source within the vehicle when the first communication is data communication conforming to SOVD communication specifications and a message or file based on the SOVD format is delivered to a destination, wherein the second communication unit performs the second communication in accordance with the format supported by the information source within the vehicle, and the first communication unit performs the first communication in accordance with the SOVD format formed by the format forming unit.

[0168]

[15] The vehicle system described in

[14] , wherein the format forming unit forms the SOVD format from at least one of a UDS format conforming to the UDS communication specification, a UCM format conforming to the UCM communication specification, and an ODX / OTX format conforming to the ODX / OTX communication specification, as a format supported by the information source within the vehicle.

[0169]

[16] A vehicle system according to

[14] or

[15] , further comprising a second compatibility table holding unit (27) that holds a second compatibility table for forming a format, wherein the format forming unit forms the SOVD format from a format corresponding to the information source within the vehicle acquired from the information source within the vehicle using the second compatibility table held in the second compatibility table holding unit.

[0170]

[17] The vehicle system according to any one of

[14] to

[16] , wherein the transmission destination is an external device, and the first communication unit performs external communication with the external device as the first communication.

[0171]

[18] An electronic control device for a vehicle (4) that transmits a message or file acquired from an external device to an electronic control device in a vehicle, comprising: an external communication unit (7) that performs external communication with the external device; an internal communication unit (18) that performs internal communication with the electronic control device; a format conversion unit (19) that converts the SOVD format of the external communication into an SOVD-incompatible format when the external communication is data communication conforming to SOVD communication specifications and the destination of the message or file based on the SOVD format is an electronic control device that does not support SOVD; and a delivery sequence creation unit (21) that creates a delivery sequence for managing the delivery order of the messages in accordance with the SOVD-incompatible format converted by the format conversion unit, wherein the internal communication unit performs the internal communication in accordance with the delivery sequence created by the delivery sequence creation unit.

[0172]

[19] The vehicle electronic control device according to

[18] , further comprising a delivery sequence execution unit (22) that executes the delivery sequence created by the delivery sequence creation unit.

[0173]

[20] An electronic control device for a vehicle as described in

[18] or

[19] , comprising a collection sequence creation unit (24) that creates a collection sequence for collecting device information from the electronic control device, and the in-vehicle communication unit performs the in-vehicle communication in accordance with the collection sequence created by the collection sequence creation unit.

[0174]

[21] The vehicle electronic control device according to

[20] , further comprising a collection sequence execution unit (25) that executes the collection sequence created by the collection sequence creation unit.

[0175]

[22] A data communication system (1) comprising an external device (2) and a vehicle electronic control device (4) that transmits a message or file acquired from the external device to an electronic control device in the vehicle, wherein the vehicle electronic control device comprises: an external communication unit (7) that performs external communication with the external device; an internal communication unit (18) that performs internal communication with the electronic control device; a format conversion unit (19) that converts the SOVD format of the external communication into an SOVD-incompatible format when the external communication is data communication conforming to the SOVD communication specifications and the destination of the message or file based on the SOVD format is an SOVD-incompatible electronic control device; and a delivery sequence creation unit (21) that creates a delivery sequence for managing the delivery order of the messages in accordance with the SOVD-incompatible format converted by the format conversion unit, and the internal communication unit performs the internal communication in accordance with the delivery sequence created by the delivery sequence creation unit.

[0176]

[23] A sequence creation program that causes a control unit (5) of a vehicle electronic control device (4) that transmits messages or files acquired from an external device to an electronic control device in a vehicle, the control unit (5) including an external communication unit (7) that performs external communication with the external device and an internal communication unit (18) that performs internal communication with the electronic control device, to execute the following sequence creation procedures: a format conversion procedure that converts the SOVD format of the external communication into an SOVD-incompatible format when the external communication is data communication conforming to the SOVD communication specifications and the destination of a message or file based on the SOVD format is an electronic control device that does not support SOVD; a delivery sequence creation procedure that creates a delivery sequence for managing the delivery order of the messages in accordance with the SOVD-incompatible format converted by the format conversion procedure; and a communication procedure that performs the internal communication in accordance with the delivery sequence created by the delivery sequence creation procedure.

[0177]

[24] In a vehicle electronic control device (4) that transmits a message or file acquired from an external device to an electronic control device in the vehicle, the vehicle electronic control device having an external communication unit (7) that performs external communication with the external device and an internal communication unit (18) that performs internal communication with the electronic control device, the sequence creation method includes: a format conversion procedure that converts the SOVD format of the external communication into an SOVD-incompatible format when the external communication is data communication conforming to the SOVD communication specifications and the destination of the message or file based on the SOVD format is an electronic control device that does not support SOVD; a delivery sequence creation procedure that creates a delivery sequence for managing the delivery order of the messages in accordance with the SOVD-incompatible format converted by the format conversion procedure; and a communication procedure that performs the internal communication in accordance with the delivery sequence created by the delivery sequence creation procedure.

[0178]

[25] A system (5) for a vehicle that transmits a message or file acquired from a distribution source to a distribution destination within a vehicle, comprising: a first communication unit (7) that performs a first communication with the distribution source; a second communication unit (18) that performs a second communication within the vehicle with the distribution destination when the first communication is data communication conforming to the SOVD communication specifications and a message or file based on the SOVD format is distributed to the distribution destination; and a distribution sequence creation unit (21) that creates a distribution sequence for managing the distribution order of the messages, wherein the second communication unit performs the second communication in accordance with the distribution sequence created by the distribution sequence creation unit.

[0179]

[26] The vehicle system according to

[25] , further comprising a delivery sequence execution unit (22) that executes the delivery sequence created by the delivery sequence creation unit.

[0180]

[27] The vehicle system according to

[25] or

[26] , wherein the distribution source is an external device, and the first communication unit performs external communication with the external device as the first communication.

[0181]

[28] A vehicle system (5) that transmits information acquired from an information source within a vehicle to a destination, comprising: a first communication unit (7) that performs a first communication with the destination; a second communication unit (18) that performs a second communication within the vehicle with the information source within the vehicle when the first communication is data communication conforming to the SOVD communication specifications and a message or file based on the SOVD format is delivered to the destination; and a collection sequence creation unit (24) that creates a collection sequence for collecting the information from the information source within the vehicle, wherein the second communication unit performs the second communication in accordance with the collection sequence created by the collection sequence creation unit.

[0182]

[29] The vehicle system according to

[28] , further comprising a collection sequence execution unit (25) that executes the collection sequence created by the collection sequence creation unit.

[0183]

[30] The vehicle system according to

[28] or

[29] , wherein the transmission destination is an external device, and the first communication unit performs external communication with the external device as the first communication.

[0184] (Other Embodiments) While the present disclosure has been described with reference to examples, it is understood that the present disclosure is not limited to those examples 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.

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

[0186] 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 electronic control device (4) that transmits a message or file obtained from an external device to an electronic control device in a vehicle, comprising: an external communication unit (7) that performs external communication with the external device; an internal communication unit (18) that performs internal communication with the electronic control device; and a format conversion unit (19) that converts the SOVD format of the external communication into a SOVD non-compatible format when the external communication is data communication conforming to the SOVD communication specifications and the destination of a message or file based on the SOVD format is an electronic control device that is not SOVD-compatible, wherein the internal communication unit performs the internal communication in accordance with the SOVD non-compatible format converted by the format conversion unit.

2. The electronic control device for a vehicle as described in claim 1, wherein the format conversion unit converts the SOVD non-compatible format into at least one of a UDS format conforming to UDS communication specifications, a UCM format conforming to UCM communication specifications, and an ODX / OTX format conforming to ODX / OTX communication specifications.

3. A vehicle electronic control device as described in claim 1, further comprising a first compatibility table storage unit (20) that stores a first compatibility table for converting the SOVD format, wherein the format conversion unit converts the SOVD format of the outside-vehicle communication into the SOVD non-compatible format using the first compatibility table stored in the first compatibility table storage unit.

4. The vehicle electronic control device according to any one of claims 1 to 3, further comprising a format forming unit (26) for forming the SOVD format from the SOVD-incompatible format acquired from the SOVD-incompatible electronic control device.

5. An electronic control device for a vehicle as described in claim 4, wherein the format formation unit forms the SOVD format from at least one of the following non-SOVD compatible formats: a UDS format conforming to UDS communication specifications, a UCM format conforming to UCM communication specifications, and an ODX / OTX format conforming to ODX / OTX communication specifications.

6. An electronic control device for a vehicle as described in claim 4, further comprising a second compatibility table holding unit (27) for holding a second compatibility table for forming a format, wherein the format forming unit forms the SOVD format from the SOVD-incompatible format acquired from the SOVD-incompatible electronic control device by using the second compatibility table held in the second compatibility table.

7. A data communication system (1) comprising an external device (2) and a vehicle electronic control device (4) that transmits a message or file acquired from the external device to an electronic control device in the vehicle, wherein the vehicle electronic control device comprises: an external communication unit (7) that performs external communication with the external device; an internal communication unit (18) that performs internal communication with the electronic control device; and a format conversion unit (19) that converts the SOVD format of the external communication into a SOVD non-compatible format when the external communication is data communication conforming to the communication specifications of SOVD and the delivery destination of a message or file based on the SOVD format is an electronic control device that is not compatible with SOVD, and the internal communication unit performs the internal communication in accordance with the SOVD non-compatible format converted by the format conversion unit.

8. A format conversion program that causes a control unit (5) of a vehicle electronic control device (4) that transmits a message or file obtained from an external device to an electronic control device in a vehicle, the control unit (5) having an external communication unit (7) that performs external communication with the external device and an internal communication unit (18) that performs internal communication with the electronic control device, to execute a format conversion procedure that converts the SOVD format of the external communication into a SOVD non-compatible format when the external communication is data communication conforming to the communication specifications of SOVD and the destination of a message or file based on the SOVD format is an electronic control device that is not compatible with SOVD, and a communication procedure that performs the internal communication in accordance with the SOVD non-compatible format converted by the format conversion procedure.

9. A vehicle electronic control device (4) that transmits a message or file obtained from an external device to an electronic control device in a vehicle, the vehicle electronic control device having an external communication unit (7) that performs external communication with the external device and an internal communication unit (18) that performs internal communication with the electronic control device, the vehicle electronic control device performing a format conversion method that performs the following steps when the external communication is data communication conforming to the communication specifications of SOVD and the destination of a message or file based on the SOVD format is an electronic control device that does not support SOVD: a format conversion step that converts the SOVD format of the external communication into a SOVD non-compatible format; and a communication step that performs the internal communication in accordance with the SOVD non-compatible format converted by the format conversion step.

10. A system (5) for a vehicle that transmits a message or file obtained from a distribution source to a distribution destination within a vehicle, comprising: a first communication unit (7) that performs a first communication with the distribution source; a second communication unit (18) that performs a second communication within the vehicle with the distribution destination; and a format conversion unit (19) that converts the SOVD format of the first communication into a format compatible with the distribution destination when the first communication is data communication conforming to SOVD communication specifications and a message or file based on the SOVD format is distributed to the distribution destination, wherein the second communication unit performs the second communication in accordance with the format compatible with the distribution destination converted by the format conversion unit.

11. A vehicle system as described in claim 10, wherein the format conversion unit converts the format supported by the distribution destination into at least one of a UDS format conforming to UDS communication specifications, a UCM format conforming to UCM communication specifications, and an ODX / OTX format conforming to ODX / OTX specifications.

12. A vehicle system as described in claim 10, further comprising a first compatibility table holding unit (20) for holding a first compatibility table for converting the SOVD format, wherein the format conversion unit converts the SOVD format of the first communication into a format compatible with the distribution destination using the first compatibility table held in the first compatibility table holding unit.

13. The vehicle system according to claim 10, wherein the distribution source is an external device, and the first communication unit performs external communication with the external device as the first communication.

14. A vehicle system (5) that transmits information obtained from an information source within a vehicle to a destination, comprising: a first communication unit (7) that performs a first communication with the destination; a second communication unit (18) that performs a second communication within the vehicle with the information source within the vehicle; and a format forming unit (26) that forms the SOVD format from a format supported by the information source within the vehicle obtained from the information source within the vehicle when the first communication is data communication conforming to SOVD communication specifications and a message or file based on the SOVD format is distributed to a destination, wherein the second communication unit performs the second communication in accordance with the format supported by the information source within the vehicle, and the first communication unit performs the first communication in accordance with the SOVD format formed by the format forming unit.

15. A system for a vehicle as described in claim 14, wherein the format forming unit forms the SOVD format from at least one of a UDS format conforming to a UDS communication specification, a UCM format conforming to a UCM communication specification, and an ODX / OTX format conforming to an ODX / OTX communication specification, as a format supported by an information source within the vehicle.

16. A vehicle system as described in claim 14, further comprising a second compatibility table holding unit (27) for holding a second compatibility table for forming a format, wherein the format forming unit forms the SOVD format from a format corresponding to the information source within the vehicle acquired from the information source within the vehicle, using the second compatibility table held in the second compatibility table holding unit.

17. The vehicle system according to claim 14, wherein the transmission destination is an external device, and the first communication unit performs external communication with the external device as the first communication.

18. A vehicle system comprising: a SOVD receiving unit (51) that receives a message or file based on a SOVD format from an external device, interprets the SOVD format of the received message or file, and outputs an execution instruction to a SOVD conversion unit; a SOVD conversion unit (52) that receives the execution instruction from the SOVD receiving unit and outputs a processing instruction to a SOVD execution management unit located under the SOVD receiving unit; a SOVD execution management unit (53) that receives the processing instruction from the SOVD conversion unit and identifies a service to be sent based on processing target identification information indicating an association between the 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 SOVD processing unit (54) that performs processing based on the service identified by the SOVD execution management unit.

19. A vehicle system as described in claim 18, wherein at least one of the SOVD receiving unit, the SOVD conversion unit, the SOVD execution management unit and the SOVD processing unit is arranged in a vehicle electronic control unit separate from the vehicle electronic control unit in which the others are arranged.

20. The vehicle system according to claim 18, wherein the SOVD execution management unit, when identifying a service to be transmitted, prepares to transmit a message to the SOVD processing unit.

21. A vehicle system as described in claim 20, wherein when the SOVD execution management unit does not specify a service to be transmitted and a program to be executed has been downloaded, the SOVD execution management unit prepares to transmit a message to the SOVD processing unit by executing the program.

22. A vehicle system as described in claim 20 or 21, wherein the SOVD execution management unit prepares to send a message to the SOVD processing unit, and then sends a message to the SOVD processing unit, thereby accessing and processing the target information.

23. A vehicle system as described in claim 18, wherein the SOVD execution management unit determines whether or not additional processing is required based on the response result from the SOVD processing unit, and if it determines that additional processing is required, requests additional processing instructions from the SOVD processing unit.

Images