Vehicle system, vehicle exterior device, data communication system, data processing program, and data processing method

Abstract

A vehicle system (3) implements a function by a combination of a plurality of pieces of software. The vehicle system is provided with: a malfunction confirmation unit (26) that, in response to the software being updated, confirms the state of a malfunction related to a function implemented by the updated software; and a performance data generation unit (28) that generates performance data by associating the confirmation result of the malfunction confirmation unit with the software version of the software that implements the function.

Description

Vehicle system, external device, data communication system, data processing program, and data processing method CROSS-REFERENCE TO RELATED APPLICATIONS

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

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

[0003] For example, with the diversification of vehicle control, such as driving assistance functions and autonomous driving functions, technologies are being provided for wirelessly or wiredly updating software installed in a vehicle's electronic control unit (hereinafter referred to as an ECU (Electronic Control Unit)). For example, Patent Document 1 discloses a configuration for an OTA (Over The Air) repro that updates software wirelessly.

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

[0005] A vehicle is equipped with many ECUs, and software for implementing functions is written into each ECU. In recent years, vehicles have begun to be equipped with high-performance HPCs (High-Performance Computers), and multiple pieces of software may be written into the HPC. Because these pieces of software have dependencies on each other, various functions may be implemented by combining multiple pieces of software.

[0006] For example, as OTA becomes more widespread, the degree of freedom in software updates increases, and it is expected that users will be able to freely update software at their own will. In this case, for example, there is a possibility that software version combinations that the development vendor did not anticipate may occur, and inappropriate software version combinations may cause malfunctions. In this regard, it is possible to consider verifying software version combinations in advance.

[0007] However, due to various factors, such as different development vendors independently designing ECUs and the infinite number of software version combinations, verifying software version combinations in advance would require a great deal of cost and time, making it unrealistic.

[0008] The present disclosure aims to appropriately address possible malfunctions caused by inappropriate combinations of software versions.

[0009] According to one aspect of the present disclosure, a vehicle system realizes functions by combining multiple pieces of software, and includes a malfunction check unit that checks, in response to a software update, whether a malfunction has occurred in a function realized by the updated software, and a performance data generation unit that generates performance data by associating a result of the check by the malfunction check unit with the software version of the software that realizes the function.

[0010] According to one aspect of the data processing program for a vehicle system of the present disclosure, a control unit of the vehicle system that realizes functions by combining multiple software programs executes, in response to a software update, a malfunction confirmation procedure for confirming the malfunction status of the function realized by the updated software, and a performance data generation procedure for generating performance data by correlating the confirmation results of the malfunction confirmation procedure with the software version of the software that realizes the function.

[0011] According to one aspect of the data processing method for a vehicle system of the present disclosure, in a vehicle system that realizes functions by combining multiple pieces of software, in response to a software update, a malfunction confirmation procedure is performed to confirm the malfunction status of the function realized by the updated software, and a performance data generation procedure is performed to generate performance data by correlating the confirmation results of the malfunction confirmation procedure with the software version of the software that realizes the function.

[0012] According to one aspect of the present disclosure, when software is updated, performance data is generated by correlating the results of checking the status of malfunctions related to functions realized by the updated software with the software version of the software that realizes the functions. By generating the performance data in a vehicle system, it is possible to appropriately deal with malfunctions that may be caused by an inappropriate combination of software versions.

[0013] According to one aspect of the present disclosure, an external vehicle device manages software for implementing functions in a vehicle system, and includes: a performance database storage unit that stores performance data indicating correspondence between combinations of software versions for implementing functions in the vehicle system for a plurality of vehicles and malfunction situations related to the functions as a performance database; a prediction information generation unit that references the performance database and generates prediction information that is predicted when software scheduled for update is updated; and a prediction information transmission unit that transmits the prediction information generated by the prediction information generation unit to the vehicle system.

[0014] According to a data processing program for an external device of one aspect of the present disclosure, the external device manages software for realizing functions in a vehicle system, and is equipped with a performance database storage unit that stores performance data indicating the correspondence between combinations of software versions for realizing functions in the vehicle system for multiple vehicles and malfunction situations related to those functions as a performance database.The control unit of the external device executes a prediction information generation procedure that references the performance database and generates prediction information that is predicted when software scheduled to be updated is updated, and a prediction information transmission procedure that transmits the prediction information generated by the prediction information generation procedure to the vehicle system.

[0015] According to one aspect of the data processing method for an external vehicle device of the present disclosure, the external vehicle device manages software for realizing functions in a vehicle system, and is equipped with a performance database storage unit that stores performance data indicating the correspondence between combinations of software versions for realizing functions in the vehicle system for multiple vehicles and malfunction situations related to those functions as a performance database.The external vehicle device performs a prediction information generation procedure that references the performance database and generates prediction information that is predicted in response to the update of software that is scheduled to be updated, and a prediction information transmission procedure that transmits the prediction information generated by the prediction information generation procedure to the vehicle system.

[0016] According to one aspect of the present disclosure, a performance database is referenced to generate prediction information that predicts what will happen if software scheduled for update is updated, and the generated prediction information is transmitted to the vehicle system. By generating prediction information in the external device and transmitting the generated prediction information to the vehicle system, it is possible to appropriately deal with malfunctions that may be caused by an inappropriate combination of software versions.

[0017] According to one aspect of the present disclosure, an external vehicle device manages software for implementing functions in a vehicle system and includes: a performance database storage unit that stores performance data indicating correspondence between combinations of software versions for implementing functions in the vehicle system for a plurality of vehicles and malfunction statuses related to the functions as a performance database; a performance data acquisition unit that acquires, from the vehicle system, performance data that associates confirmation results of malfunction statuses related to functions implemented by updated software with software versions of the software that implement the functions; and a performance database update unit that updates the performance database when the performance data acquisition unit acquires the performance data.

[0018] According to a data processing program for an external device of one aspect of the present disclosure, the external device manages software for realizing functions in a vehicle system, and is equipped with a performance database storage unit that stores performance data indicating the correspondence between combinations of software versions for realizing functions in the vehicle system for multiple vehicles and malfunction statuses related to those functions as a performance database. The data processing program causes a control unit of the external device to execute a performance data acquisition procedure that acquires from the vehicle system performance data that corresponds the confirmation results of the malfunction status related to the functions realized by the updated software with the software version of the software that realizes those functions, and a performance database update procedure that updates the performance database when the performance data is acquired by the performance data acquisition procedure.

[0019] According to one aspect of the data processing method for an external device of the present disclosure, the external device manages software for realizing functions in a vehicle system, and is equipped with a performance database storage unit that stores performance data indicating the correspondence between combinations of software versions for realizing functions in the vehicle system for multiple vehicles and malfunction statuses related to those functions as a performance database.The external device performs a performance data acquisition procedure that acquires from the vehicle system performance data that corresponds the confirmation results of the malfunction status related to the functions realized by updated software with the software version of the software that realizes those functions, and a performance database update procedure that updates the performance database when the performance data is acquired by the performance data acquisition procedure.

[0020] According to one aspect of the present disclosure, when performance data correlating the results of a check of the status of a malfunction related to a function realized by updated software with the software version of the software that realizes the function is obtained from the vehicle system, the performance database is updated. When the performance data is obtained from the vehicle system, the external device updates the performance database, thereby making it possible to appropriately deal with malfunctions that are expected due to an inappropriate combination of software versions.

[0021] According to an aspect of the present disclosure, a vehicle system includes a combination of a plurality of pieces of software, and a prediction information presentation unit that presents prediction information that is predicted in association with updating a piece of software that is scheduled to be updated.

[0022] According to a data processing program for an external device of one aspect of the present disclosure, a control unit of a vehicle system that realizes functions by combining multiple software programs executes a prediction information presentation procedure that presents prediction information that is predicted when software that is scheduled to be updated is updated.

[0023] According to one aspect of the data processing method for an external vehicle device of the present disclosure, in a vehicle system that realizes functions by combining multiple software programs, a prediction information presentation procedure is performed to present prediction information that is predicted when software that is scheduled to be updated is updated.

[0024] According to one aspect of the present disclosure, in a vehicle system, by presenting predictive information that is predicted when software scheduled for update is updated, it is possible to appropriately deal with malfunctions that may be caused by inappropriate combinations of software versions.

[0025] According to one aspect of the present disclosure, a data communication system includes a vehicle system that realizes functions by combining multiple pieces of software, and an external device that manages the software for realizing the functions in the vehicle system. The vehicle system includes a malfunction confirmation unit that, in response to a software update, confirms a malfunction status related to a function realized by the updated software, and a performance data generation unit that generates performance data by correlating the confirmation result of the malfunction confirmation unit with the software version of the software that realizes the function. The external device includes a performance database storage unit that stores performance data indicating a correspondence between combinations of software versions for realizing functions in the vehicle system for multiple vehicles and malfunction status related to the function as a performance database, a prediction information generation unit that references the performance database and generates prediction information that predicts when the software to be updated is updated, and a prediction information transmission unit that transmits the prediction information generated by the prediction information generation unit to the vehicle system.

[0026] According to one aspect of the present disclosure, when software is updated in a vehicle system, historical data is generated by correlating the results of checking the status of malfunctions related to functions implemented by the updated software with the software version of the software that implements the functions. An external device references a historical database to generate prediction information that predicts what will happen if the scheduled software is updated, and transmits the generated prediction information to the vehicle system. This allows appropriate countermeasures to be taken against malfunctions that may arise from an inappropriate combination of software versions.

[0027] According to one aspect of the present disclosure, an external vehicle device manages software for implementing functions in a vehicle system and includes: a performance database storage unit that stores performance data indicating correspondence between combinations of software versions for implementing functions in the vehicle system for a plurality of vehicles and operational performance data for the functions in the vehicles as a performance database; a performance data acquisition unit that acquires performance data from the vehicle system that associates operational performance data of functions implemented by updated software with software versions of the software that implements the functions; and a performance database update unit that updates the performance database when the performance data is acquired by the performance data acquisition unit.

[0028] According to a data processing program for an external device of one aspect of the present disclosure, the external device manages software for realizing functions in a vehicle system, and is equipped with a performance database storage unit that stores performance data indicating the correspondence between combinations of software versions for realizing functions in the vehicle system for multiple vehicles and the operational performance of those functions in the vehicles as a performance database. The data processing program causes a control unit of the external device to execute a performance data acquisition procedure that acquires performance data from the vehicle system that corresponds the operational performance of functions realized by updated software with the software version of the software that realizes those functions, and a performance database update procedure that updates the performance database when the performance data is acquired by the performance data acquisition procedure.

[0029] According to one aspect of the data processing method for an external device of the present disclosure, the external device manages software for realizing functions in a vehicle system, and is equipped with a performance database storage unit that stores performance data indicating the correspondence between combinations of software versions for realizing functions in the vehicle system for multiple vehicles and the operational performance of those functions in the vehicles as a performance database.The external device performs a performance data acquisition procedure that acquires performance data from the vehicle system that corresponds the operational performance of functions realized by updated software with the software version of the software that realizes those functions, and a performance database update procedure that updates the performance database when the performance data is acquired by the performance data acquisition procedure.

[0030] According to one aspect of the present disclosure, when performance data associating the operation performance of a function realized by updated software with the software version of the software that realizes the function is acquired from the vehicle system, the performance database is updated. When the performance data is acquired from the vehicle system, the external device updates the performance database, thereby enabling appropriate confirmation of the operation performance of the function realized by the updated software.

[0031] According to one aspect of the present disclosure, an external vehicle device manages software for implementing functions in a vehicle system and includes: a performance database storage unit that stores performance data indicating correspondence between combinations of software versions for implementing functions in the vehicle system for a plurality of vehicles and operation logs of the functions in the vehicle as a performance database; a performance data acquisition unit that acquires performance data from the vehicle system that associates operation logs of functions implemented by updated software with software versions of the software that implement the functions; and a performance database update unit that updates the performance database when the performance data acquisition unit acquires the performance data.

[0032] According to a data processing program for an external device of one aspect of the present disclosure, the external device manages software for realizing functions in a vehicle system, and is equipped with a performance database storage unit that stores performance data indicating the correspondence between combinations of software versions for realizing functions in the vehicle system for multiple vehicles and the operation logs of those functions in the vehicle as a performance database. The control unit of the external device executes a performance data acquisition procedure that acquires performance data from the vehicle system that corresponds the operation logs of functions realized by updated software to the software versions of the software that realize those functions, and a performance database update procedure that updates the performance database when the performance data is acquired by the performance data acquisition procedure.

[0033] According to one aspect of the data processing method for an external device of the present disclosure, the external device manages software for realizing functions in a vehicle system, and is equipped with a performance database storage unit that stores performance data indicating the correspondence between combinations of software versions for realizing functions in the vehicle system for multiple vehicles and the operation logs of those functions in the vehicles as a performance database.The external device performs a performance data acquisition procedure that acquires from the vehicle system performance data that corresponds the operation logs of functions realized by updated software to the software versions of the software that realize those functions, and a performance database update procedure that updates the performance database when the performance data is acquired by the performance data acquisition procedure.

[0034] According to one aspect of the present disclosure, when performance data, which associates an operation log of a function implemented by updated software with the software version of the software that implements the function, is acquired from the vehicle system, the performance database is updated. When the performance data is acquired from the vehicle system, the external device updates the performance database, thereby allowing the operation log of the function implemented by the updated software to be properly confirmed. Furthermore, by analyzing the performance log, it is possible to determine when an abnormality or malfunction occurred.

[0035] 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 diagram explaining format conversion, Fig. 3 is a diagram explaining format formation, Fig. 4 is a diagram showing a software layout, Fig. 5 is a functional block diagram of a control unit in a CGW, Fig. 6 is a functional block diagram of a control unit in an OTA center, Fig. 7 is a diagram showing performance data, Fig. 8 is a flowchart showing processing by the CGW, Fig. 9 is a diagram showing a function update inquiry screen, Fig. 10 is a diagram showing a prediction information notification screen, Fig. 11 is a flowchart showing processing by the OTA center, Fig. 12 is a diagram showing performance data, Fig. 13 is a flowchart showing processing by the OTA center, and Fig. 14 is a flowchart showing processing by the OTA center. is a diagram showing the performance database, FIG. 15 is a diagram showing a function update inquiry screen, FIG. 16 shows a second embodiment and is a diagram showing a questionnaire input screen, FIG. 17 is a diagram showing performance data, FIG. 18 is a diagram showing performance data, FIG. 19 is a diagram showing a prediction information notification screen, FIG. 20 shows a third embodiment and is a diagram showing the performance database, FIG. 21 is a flowchart showing processing at the OTA center, FIG. 22 is a diagram showing the performance database, FIG. 23 is a diagram showing the performance database, FIG. 24 is a diagram showing the performance database, FIG. 25 shows a fourth embodiment and is a diagram showing the performance database, and FIG. 26 is a flowchart showing processing at the OTA center.

[0036] Hereinafter, several embodiments will be described with reference to the drawings. In the subsequent embodiments, the description of the same parts as in the preceding embodiments may be omitted.

[0037] First Embodiment A first embodiment will be described with reference to FIGS. 1 to 15. As shown in FIG. 1, a data communication system 1 includes an OTA center 2 (corresponding to an external device) and a vehicle system 3. The vehicle system 3 includes a DCM (Data Communication Module) 4, a CGW (Central Gateway) 5, and ECUs 14 to 17 (described later). The DCM 4 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 4 and the CGW 5 may be integrated, and the functions of the DCM 4 may be incorporated into the CGW 5. Alternatively, the functions of the DCM 4 and the CGW 5 may be incorporated into a display or the like.

[0038] The DCM 4 transfers data distributed from the OTA center 2 to the CGW 5. The data distributed from the OTA center 2 to the DCM 4 is, for example, repro software. The inter-center communication, which is data communication between the OTA center 2 and the CGW 5, 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.

[0039] The CGW 5 includes a control unit 6. The control unit 6 is mainly configured with a microcomputer (hereinafter referred to as a microcomputer) having a CPU, ROM, RAM, I / O, etc., and controls the operation of the CGW 5 by executing software processing by the CPU executing a computer program stored in a non-transient physical storage medium and hardware processing by a dedicated electronic circuit.

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

[0041] The control unit 6 has, for each function, a downloader 7, an OTA master 8, a first update master 9, a second update master 10, a third update master 11, a fourth update master 12, 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 4 to execute a download process. The downloader 7 downloads data from the OTA center 2 via the DCM 4 by having the DCM 4 receive data distributed from the OTA center 2 and then forwarding the received data from the DCM 4.

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

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

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

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

[0046] 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 4 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 4 to transmit the activation completion notification to the OTA center 2.

[0047] Next, the update masters 9 to 12 will be described. The update masters 9 to 12 are connected to the 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).

[0048] A UCM (Update & Configuration Management)-compatible ECU 14 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, 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.

[0049] 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 vehicle's EE architecture.

[0050] The second update master 10 is connected to an SOVD-compatible ECU 15 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, 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.

[0051] 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, 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 SOVD-compatible ECU 15 may function as, for example, a domain controller or a zone ECU in the vehicle's EE architecture.

[0052] A UDS (Unified Diagnostic Services)-compatible ECU 16 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, 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 UDS-compatible ECU 16 is an ECU that realizes services for, for example, an engine system, a hybrid (HV) system, or an electric vehicle (EV) system.

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

[0054] An ODX (Open Diagnostic Data Exchange) / OTX (Open Test Sequence Exchange) compatible ECU 17 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, 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).

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

[0056] The functions of the update masters 9 to 12 may be provided in the CGW 5 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 5 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. 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. For example, when the second update master 9 is provided in the SOVD-compatible ECU 15, the second update master 9 is connected to software responsible for SOVD in the SOVD-compatible ECU 15 to perform data communication.

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

[0058] The update masters 9 to 12 have a format conversion function for converting the format of inter-center communication in accordance with the specifications of the corresponding ECU, and a format formation function for forming the format of inter-center communication from the format of inter-ECU communication with the corresponding ECU.

[0059] The format conversion function will be described with reference to FIG. 2 . The first update master 9 performs inter-ECU communication with UCM-compatible ECUs 14 in accordance with UCM communication specifications, and therefore converts the format of inter-center communication to the UCM format. If the inter-center communication is in the SOVD format, the first update master 9 converts the SOVD format to the UCM format. If the inter-center communication is in the RestAPI format, the first update master 9 converts the RestAPI format to the UCM 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, and the first update master 9 may convert the SOVD format to the UCM format.

[0060] The second update master 10 performs inter-ECU communication with SOVD-compatible ECUs 15 in accordance with the SOVD communication specifications, and converts the format of inter-center communication to the SOVD format as necessary. If the inter-center communication is in the SOVD format, the second update master 10 applies the SOVD format as is without converting it. If the inter-center communication is in the RestAPI format, 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.

[0061] The third update master 11 performs inter-ECU communication with UDS-compatible ECUs 16 in accordance with UDS communication specifications, and therefore converts the format of inter-center communication to the UDS format. If the inter-center communication is in the SOVD format, the third update master 11 converts the SOVD format to the UDS format. If the inter-center communication is in the RestAPI format, the third update master 11 converts the RestAPI format to 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 to the SOVD format, and the third update master 11 may convert the SOVD format to the UDS format.

[0062] The fourth update master 12 performs inter-ECU communication with the ODX / OTX-compatible ECU 17 in accordance with the ODX / OTX communication specifications, and therefore converts the format of inter-center communication to the ODX / OTX format. If the inter-center communication is in the SOVD format, the fourth update master 12 converts the SOVD format to the ODX / OTX format. If the inter-center communication is in the RestAPI format, the fourth update master 12 converts the RestAPI format to the ODX / OTX 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, and the fourth update master 12 may convert the SOVD format to the ODX / OTX format.

[0063] The format formation function will be described with reference to Figure 3. The first update master 9 performs inter-ECU communication with UCM-compatible ECUs 14 in accordance with the UCM communication specifications, and therefore forms a format for inter-center communication from the UCM format. If the inter-center communication is in the SOVD format, the first update master 9 forms the SOVD format from the UCM format. If the inter-center communication is in the RestAPI format, the first update master 9 forms the RestAPI format from the UCM format.

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

[0065] The third update master 11 performs inter-ECU communication with UDS-compatible ECUs 16 in accordance with UDS communication specifications, and therefore forms a format for inter-center communication from the UDS format. If the inter-center communication is in the SOVD format, the third update master 11 forms the SOVD format from the UDS format. If the inter-center communication is in the RestAPI format, the third update master 11 forms the RestAPI format from the UDS format.

[0066] The fourth update master 12 performs inter-ECU communication with the ODX / OTX-compatible ECU 17 in accordance with the ODX / OTX communication specifications, and therefore forms a format for inter-center communication from the ODX / OTX format. If the inter-center communication is in the SOVD format, the fourth update master 12 forms the SOVD format from the ODX / OTX format. If the inter-center communication is in the RestAPI format, the fourth update master 12 forms the RestAPI format from the ODX / OTX format.

[0067] Next, we will explain the software written into the ECU and HPC. Software for implementing functions is written into the ECU and HPC, and these pieces of software have dependencies on each other, allowing various functions to be implemented by combining multiple pieces of software. Figure 4 illustrates an example in which software A is written into the first ECU 18, software B is written into the second ECU 19, and software C to E are written into the HPC 20. The first ECU 18, second ECU 19, and HPC 20 each correspond to one of the ECUs 14 to 17 described in Figure 1.

[0068] Software B, D, and E are used for function a, and software A, B, C, and E are used for function b. That is, function a is realized by the cooperation of software B, D, and E, and function b is realized by the cooperation of software A, B, C, and E. When a function is realized by the cooperation of multiple software, for example, if the software version combination is not anticipated by the development vendor, there is a possibility that a malfunction will occur due to an inappropriate combination of software versions. In this regard, the OTA center 2 and the vehicle system 3 cooperate to manage possible malfunctions due to the combination of software versions.

[0069] For example, in a vehicle equipped with multiple functions realized by multiple software programs, the multiple software programs realizing a first function and the multiple software programs realizing a second function may include common software. That is, the software may include software used by both the first function and the second function. In such a case, an update to the first function may change the software version combination for the second function. In the example shown in FIG. 4 , software programs B and E are used by both function a and function b. For example, an update to function a, including updates to software programs B and E, changes the software version combination for function b. In this case, the software version combination for function b may be a combination not anticipated by the development vendor, potentially resulting in a malfunction due to an inappropriate software version combination.

[0070] The following describes how to manage malfunctions that may occur due to combinations of software versions. The malfunction management process includes a process in which the vehicle system 3 generates performance data, a process in which the OTA center 2 transmits prediction information to the vehicle system 3, a process in which the OTA center 2 updates the performance database, and a process in which the vehicle system 3 presents the prediction information.

[0071] 5 , in the CGW 5, the control unit 6 includes a performance data generation processing unit 22 that performs processing to generate performance data, and a prediction information presentation processing unit 25 that performs processing to present prediction information. The control unit 6 executes a data processing program for the vehicle system 3 as a computer program using the performance data generation processing unit 22 and the prediction information presentation processing unit 25. Furthermore, the execution of the data processing program for the vehicle system 3 by the control unit 6 realizes a data processing method for the vehicle system 3.

[0072] 6 , the OTA center 2 includes a control unit 21. The control unit 21 is mainly configured with a microcomputer having a CPU, ROM, RAM, I / O, etc., and controls the operation of the OTA center 2 by executing software processing by the CPU executing a computer program stored in a non-transient physical storage medium and hardware processing by a dedicated electronic circuit.

[0073] The control unit 21 includes a forecast information transmission processing unit 23 that performs processing to transmit forecast information to the vehicle system 3, and a performance database update processing unit 24 that performs processing to update the performance database. The control unit 21 executes a data processing program for an external device as a computer program using the forecast information transmission processing unit 23 and the database update processing unit 24. Furthermore, the execution of the data processing program for an external device by the control unit 21 realizes a data processing method for an external device.

[0074] The performance data generation processing unit 22 includes a malfunction confirmation unit 26, a feedback confirmation unit 27, a performance data generation unit 28, and a performance data transmission unit 29. When software is updated, the malfunction confirmation unit 26 confirms the status of malfunction related to functions realized by the updated software. When software for realizing a first function is updated, the malfunction confirmation unit 26 confirms the status of malfunction related to the first function, and also confirms the status of malfunction related to a second function whose software version combination has changed due to the software update. When software for realizing the first function is updated, the malfunction confirmation unit 26 confirms the status of malfunction related to multiple functions including the first function.

[0075] In the case of the software combination shown in Figure 4, for example, for function a, when the software version of software B changes from "Ver.001" to "Ver.002", the software version of software D changes from "Ver.001" to "Ver.002", and the software version of software E changes from "Ver.001" to "Ver.003", the malfunction confirmation unit 26 checks whether there is a possibility of a malfunction occurring for function a, and also checks whether there is a possibility of a malfunction occurring for function b, since software B and E are related to function b.

[0076] The feedback confirmation unit 27 confirms the status of user feedback regarding usability in response to a software update. When a malfunction is confirmed by the malfunction confirmation unit 26, the performance data generation unit 28 generates performance data by correlating the confirmation result with the software version of the software that realizes the function. When the performance data generation unit 28 generates the performance data, the performance data transmission unit 29 causes the DCM 4 to transmit the generated performance data to the OTA center 2.

[0077] The prediction information presentation processing unit 25 includes a prediction information presentation unit 37. The prediction information presentation unit 37 presents prediction information predicted in association with the update of software scheduled for update.

[0078] The forecast information transmission processing unit 23 includes a performance database storage unit 30, a total performance number deriving unit 31, a performance number ratio deriving unit 32, a forecast information generating unit 33, and a forecast information transmitting unit .

[0079] The performance database storage unit 30 stores performance data indicating the correspondence between combinations of software versions for realizing functions in the vehicle system 3 for multiple vehicles and malfunction situations related to the functions as a performance database. In the case of the software combination shown in Fig. 4, the performance database storage unit 30 stores, as performance data, the correspondence between whether function a worked with a combination of software versions B, D, and E, and the correspondence between whether function b worked with a combination of software versions A, B, C, and E, as shown in Fig. 7.

[0080] In Figure 7, the numerical values ​​for "operated" and "did not operate" indicate the number of results. "Operated" means that the function was properly implemented by the combination of software. For example, for a function related to vehicle driving, it means that all functions, such as acceleration, deceleration, stopping, and turning, operated properly. For example, for a navigation function unrelated to vehicle driving, it means that all functions, such as map display, positioning, destination setting, map display, route search, and route guidance, operated properly. "Did not operate" means that the function was not properly implemented by the combination of software. For example, for a function related to vehicle driving, it means that at least some functions, such as acceleration, deceleration, stopping, and turning, did not operate properly. For example, for a navigation function unrelated to vehicle driving, it means that at least some functions, such as map display, positioning, destination setting, map display, route search, and route guidance, did not operate properly.

[0081] 7, for function a, when the software versions of software B, D, and E are "Ver.001", "Ver.001", and "Ver.001", the number of results for "worked" (0) is significantly lower than the number of results for "did not work" (1020), indicating that the function did not work and malfunctioned. When the software versions of software B, D, and E are "Ver.002", "Ver.002", and "Ver.003", the number of results for "worked" (1250) is significantly higher than the number of results for "did not work" (0), indicating that the function worked normally and did not malfunction.

[0082] Similarly, for function b, when the software versions of software A, B, C, and E are combined as "Ver.001", "Ver.001", "Ver.001", and "Ver.001", the number of results for "worked" (0) is significantly lower than the number of results for "did not work" (1,220), indicating that the function did not work and malfunctioned.When the software versions of software A, B, C, and E are combined as "Ver.001", "Ver.002", "Ver.002", and "Ver.003", the number of results for "worked" (1,450) is significantly higher than the number of results for "did not work" (0), indicating that the function worked normally and did not malfunction.

[0083] The total achievement number deriving unit 31 derives the total achievement number in the achievement database. For example, for function a, when the software versions of software B, D, and E are a combination of "Ver. 001", "Ver. 001", and "Ver. 001", the total achievement number deriving unit 31 derives "1020" as the total achievement number.

[0084] The performance number proportion deriving unit 32 derives the proportion of performance numbers with and without malfunction in the performance database. For example, for function a, when the software versions of software B, D, and E are a combination of "Ver.001", "Ver.001", and "Ver.001", the performance number proportion deriving unit 32 derives "0%" as the proportion of performance numbers with no malfunction and "100%" as the proportion of performance numbers with malfunction.

[0085] The prediction information generating unit 33 references the performance database and generates prediction information predicted in association with the update of the software to be updated. The prediction information generating unit 33 generates, as the prediction information, information indicating that a function realized by the software to be updated will operate normally, or information indicating that a malfunction may occur in the function realized by the software to be updated. The prediction information generating unit 33 generates, as the prediction information, information indicating that a malfunction may occur in the function realized by the software to be updated, as well as information indicating that an update of other software is recommended to avoid the malfunction. The prediction information generating unit 33 also generates, as the prediction information, information indicating feedback from users regarding usability.

[0086] When the prediction information is generated by the prediction information generating unit 33 , the prediction information transmitting unit 34 transmits the generated prediction information to the vehicle system 3 .

[0087] The performance database update processing unit 24 includes a performance database storage unit 30 , a performance data acquisition unit 35 , and a performance database update unit 36 ​​.

[0088] The performance data acquisition unit 35 acquires performance data that associates the confirmation result of the malfunction status related to the function realized by the updated software with the software version of the software that realizes the function from the vehicle system 3. When the performance data acquisition unit 35 acquires the performance data, the performance database update unit 36 ​​updates the performance database stored in the performance database storage unit 30.

[0089] In the CGW 5, the control unit 6 stores and manages, for each of a plurality of functions possessed by the vehicle, a combination of a plurality of software programs that realize the function and the current software versions of the plurality of software programs. The control unit 6 stores information about the plurality of software programs that realize each function in a non-volatile memory as in-vehicle software management information, for example in list format, and references the software management information. The control unit 6 obtains the current software version combinations of each function, for example by inquiring of each ECU in the vehicle about the software and software versions possessed by that ECU, and records the information in the in-vehicle software management information.

[0090] The control unit 6 also identifies the software version combinations of the multiple functions after an update of a single function, compared to the combinations before the update of the single function. For example, the control unit 6 identifies software whose software versions will change from the multiple software programs that implement the single function and the software versions of each software program for the single function before and after the update. The control unit 6 compares the functions that use the identified software with software management information in the vehicle, and identifies the software version combinations of the multiple functions after an update of the single function, compared to the combinations before the update of the single function. In this way, the control unit 6 identifies other functions whose software version combinations will change when the single function is updated, and the software version combinations of the other functions after the change.

[0091] The control unit 6 may specify the software version of each piece of software for one function after the update using information acquired from the OTA center 2. For example, when acquiring from the OTA center 2 information that an update is available for one function, the control unit 6 may acquire information indicating the combination of software versions for one function after the update.

[0092] Next, the operation of the above-described configuration will be described with reference to Figures 8 to 12. The vehicle-side processing performed by the CGW 5 and the center-side processing performed by the OTA center 2 will be described in order.

[0093] (1) Vehicle-Side Processing Performed by CGW 5 (See FIGS. 8 to 10) In the CGW 5, the control unit 6 displays a function update inquiry screen shown in FIG. 9, for example, when the user gets in or out of the vehicle. On the function update inquiry screen, the control unit 6 displays a message "Feature updates available for your vehicle," displays a function summary for each feature to be updated, and displays "Check details" buttons 101 to 103. The user can select a feature to be updated by operating one of the "Check details" buttons 101 to 103. When the user operates one of the "Check details" buttons 101 to 103, the control unit 6 starts vehicle-side processing and identifies all software version combinations after the feature update (A1).

[0094] Specifically, when the user operates one of the "Check Details" buttons 101 to 103, the control unit 6 determines, for all of the vehicle's functions, the software version combinations of the functions corresponding to the button operated by the user (hereinafter referred to as "user-selected functions") after the update, for example, using the method described above. At this time, the control unit 6 also determines other functions that will be affected by the update of the user-selected function, and also determines the software version combinations of the other functions after the update of the user-selected function. In this embodiment, the other functions that will be affected by the update of the user-selected function are other functions whose software version combinations will change as a result of the update of the user-selected function. Note that if the control unit 6 determines that there are no other functions that will be affected by the update of the user-selected function, the control unit 6 proceeds to A4 without performing steps A1 to A3.

[0095] For example, when the user operates the "Check details" button 101 corresponding to function a, the control unit 6 identifies the combination of software versions of software B, D, and E that realize function a before and after the update of function a. The control unit 6 also identifies software whose software version will change when function a is updated, and identifies whether the combination of software versions of software A, B, C, and E that realize function b will change when function a is updated. The control unit 6 identifies that when at least one of software B or E is updated when function a is updated, the combination of software versions of function b will change when function a is updated.

[0096] When the control unit 6 has identified all combinations of software versions after the function update, it causes the DCM 4 to transmit an inquiry notification signal to the OTA center 2 inquiring about prediction information based on the combination of software versions (A2), and waits for reception of a prediction information notification signal from the OTA center 2. In this embodiment, the control unit 6 causes the DCM 4 to transmit an inquiry notification signal to the OTA center 2 inquiring about prediction information about other functions that will be affected by the update of the user-selected function. The inquiry notification signal specifies the queried function and the combination of the software versions of the queried function after the update of the user-selected function. If there are multiple other functions that will be affected by the update of the user-selected function, the control unit 6 sets each of the other functions as a queried function and causes the DCM 4 to transmit an inquiry notification signal to the OTA center 2. That is, the control unit 6 performs steps A2 and A3 for each queried function.

[0097] When the DCM 4 receives the prediction information notification signal distributed from the OTA center 2, the control unit 6 acquires the inquiry result from the OTA center 2. The control unit 6 determines whether or not the performance check of all functions has been completed (A3).

[0098] Specifically, the control unit 6 determines whether or not it has received query results from the OTA center 2 for all of the queried functions. The query results include a prediction of the impact of updating the user-selected function on the queried function, generated by the prediction information generation unit 33 with reference to the performance database. That is, the query results include an operation prediction, such as whether the queried function having the combination of updated software versions specified by the query notification signal is predicted to operate normally or to be at risk of malfunction. The query results may also include a function summary of the queried function (corresponding to the function summaries of functions b and c shown in FIG. 10 ).

[0099] If the control unit 6 determines that the performance check has not been completed for all functions (A3: NO), the control unit 6 returns to step A2 and repeats step A2 for the functions for which the performance check has not been completed.

[0100] When the control unit 6 determines that the performance check for all functions has been completed (A3: YES), it displays the predicted information notification screen shown in FIG. 10 (corresponding to A4, the predicted information presentation procedure) and waits for a function update operation. The content of the predicted information notification screen includes a prediction of the impact of updating the user-selected function on other functions. Specifically, the content of the predicted information notification screen includes a prediction of the operation after updating the user-selected function for other functions whose software version combinations change due to the update of the user-selected function. This prediction is the prediction included in the inquiry result obtained from the OTA center 2 in steps A2 and A3.

[0101] 10 shows an example of a predicted information notification screen when the user operates the "Check details" button 101 corresponding to function a on the function update inquiry screen. The control unit 6 displays a message "Details of the latest update of function a" on the predicted information notification screen, displays the impact of updating function a, and also displays an "Update function a" button 111 and an "Update functions a and b" button 112.

[0102] FIG. 10 illustrates an example in which an update to function a affects functions b and c. For function b, in response to a notification indicating insufficient operational performance (described later), a message is displayed stating, "Updating function a will affect function b, but because its operational performance is insufficient, it may stop working. In that case, if function b is also updated, the operational performance will be sufficient and the problem may be resolved." That is, the user is notified that function b's operational performance is insufficient and it may stop working, and that updating function b will also have sufficient operational performance and the problem may be resolved. For function c, in response to a notification indicating sufficient operational performance (described later), a message is displayed stating, "Updating function a will affect function c, but because its operational performance is sufficient, it is highly likely that there will be no problems." That is, the user is notified that function c's operational performance is sufficient and it may not be a problem.

[0103] The control unit 6 determines whether or not a function update operation has been performed (A5). If the control unit 6 determines that a timeout has occurred before the user performs the function update operation (A5: NO), the control unit 6 ends the vehicle-side processing.

[0104] On the other hand, if the control unit 6 determines that the user has performed a function update operation before the timeout occurs (A5: YES), the control unit 6 executes the function update (A6). That is, when the user operates the "Update function a" button 101, the control unit 6 downloads, installs, and activates software B, D, and E as software corresponding to function a. When the user operates the "Update functions a and b" button 102, the control unit 6 downloads, installs, and activates software A, B, C, and E as software corresponding to functions a and b.

[0105] When the control unit 6 completes the function update, it checks for malfunctions related to the function implemented by the updated software (corresponding to a malfunction check procedure), and generates performance data by associating the results of the malfunction check with the software version of the software implementing the function (corresponding to a performance data generation procedure). In this embodiment, performance data is generated for the user-selected function and other functions affected by the update of the user-selected function. That is, since software B and E are common to functions a and b as described above, when updating function a including an update of either software B or E, the control unit 6 generates performance data for function b in addition to performance data for function a.

[0106] Various methods are conceivable for determining whether a malfunction has occurred, and these methods may differ depending on the function being checked. Examples of conceivable methods include determining whether a malfunction has occurred based on whether an error has occurred in a continuity check, such as an API (Application Programming Interface) check of a related module, performed when the function is started; determining whether a malfunction has occurred based on whether an error has occurred during function operation after start-up; and determining whether a malfunction has occurred based on whether an error has occurred during operation in shadow mode. Depending on the function, it may be assumed that the entity that determines whether a malfunction has occurred is a control unit other than the control unit 6, such as a control unit of an ECU other than the CGW 5. In such cases, the control unit 6 may obtain a determination result of the malfunction from the other control unit and confirm the malfunction based on the determination result.

[0107] After generating the performance data, the control unit 6 causes the DCM 4 to transmit an operation performance notification signal including the performance data to the OTA center 2 (A7). The control unit 6 determines whether transmission of the operation performance notification signals for all functions implemented by the updated software has been completed (A8). Specifically, the control unit 6 determines whether transmission of the operation performance notification signals for the user-selected function and for other functions affected by the update of the user-selected function has been completed.

[0108] If the control unit 6 determines that the transmission of the operation result notification signals for all functions has not been completed (A8: NO), the control unit 6 returns to step S7 and repeats step A7 for the functions for which the transmission of the operation result notification signals has not been completed.If the control unit 6 determines that the transmission of the operation result notification signals for all functions has been completed (A8: YES), the vehicle-side processing ends.

[0109] (2) Center-Side Processing Performed by the OTA Center 2 (See FIGS. 11 to 13) The OTA center 2 performs a forecast information notification process and a performance database update process as center-side processing. Each process will be described below.

[0110] (2-1) Prediction Information Notification Processing (See FIGS. 11 and 12) In the OTA center 2, the control unit 21 starts the prediction information notification processing when it determines that it has received the inquiry notification signal transmitted from the vehicular system 3. When starting the prediction information notification processing, the control unit 21 refers to the performance database and checks the operation performance of the combination of software versions of the functions specified by the inquiry notification signal (B1).

[0111] The control unit 21 determines whether the total number of results for the function for which the operation history is to be checked is equal to or greater than a first predetermined value (e.g., 100) (B2). If the control unit 21 determines that the total number of results is equal to or greater than the first predetermined value (B2: YES), it determines whether the percentage of results that are "operated" is equal to or greater than a second predetermined value (e.g., 90%) (B3). If the control unit 21 determines that the percentage of results that are "operated" is equal to or greater than the second predetermined value (B3: YES), it generates information indicating that the operation history of the corresponding function is sufficient as prediction information (corresponding to the prediction information generation step), transmits a prediction information notification signal indicating the generated prediction information to the vehicle system 3 (B4, corresponding to the prediction information transmission step), and ends the prediction information notification process.

[0112] On the other hand, if the control unit 21 determines that the percentage of the results that "operated" is less than the second predetermined value (B3: NO), it generates information indicating the possibility of malfunction of the corresponding function as prediction information (corresponding to the prediction information generation step), and transmits a prediction information notification signal indicating the generated prediction information to the vehicle system 3 (B5, corresponding to the prediction information transmission step).The control unit 21 refers to the results database and determines whether there is a combination in which all related software versions are higher, the total number of results is equal to or greater than the first predetermined value, and the percentage of the results that "operated" is equal to or greater than the second predetermined value (S6).

[0113] In detail, the control unit 21 refers to the performance database and determines whether there is a software version combination specified in the inquiry notification signal in which the software version is higher in all of the software that realizes the queried function, the total number of performance results is equal to or greater than a first predetermined value, and the percentage of performance results that ``worked'' is equal to or greater than a second predetermined value.

[0114] When the control unit 21 determines that there is a combination in which all relevant software versions are higher, the total number of actual results is equal to or greater than a first predetermined value, and the percentage of actual results that "worked" is equal to or greater than a second predetermined value (S6: YES), it generates information as predictive information indicating that other software should be updated to avoid malfunctions (corresponding to the predictive information generation procedure), transmits a predictive information notification signal indicating the generated predictive information to the vehicle system 3 (B7, corresponding to the predictive information transmission procedure), and terminates the predictive information notification process.

[0115] If the control unit 21 determines that the total number of past performance records is less than the first predetermined value (B2: NO), it generates information indicating that the performance records of the corresponding function are insufficient as prediction information (corresponding to the prediction information generation step), and transmits a prediction information notification signal indicating the generated prediction information to the vehicle system 3 (B8, corresponding to the prediction information transmission step). In this case, the control unit 21 also performs the steps from B6 onwards and ends the prediction information notification process. The information prompting the user to update other software to avoid malfunction is, for example, information prompting the user to update to the software version combination determined to exist in step B6.

[0116] Specifically, in the case of the software combination shown in Figure 7, for example, for function a, the case where the software version of software B changes from "Ver.001" to "Ver.002", the software version of software D changes from "Ver.001" to "Ver.002", and the software version of software E changes from "Ver.001" to "Ver.003" will be described with reference to Figure 12.

[0117] When the software versions of software B, D, and E that realize function a are changed as described above, if the software version of software A is "Ver.001" and the software version of software C is "Ver.002" at that time, with the update of function a, the software versions of software A, B, C, and E for function b will change to a combination of "Ver.001," "Ver.002," "Ver.002," and "Ver.003." In this case, as shown as "Pattern 1," the total number of achievements is equal to or greater than the first predetermined value, and the percentage of achievements that "operated" is equal to or greater than the second predetermined value, so the control unit 21 performs step B4.

[0118] When the software versions of software B, D, and E that realize function a are changed as described above, if the software version of software A is "Ver.001" and the software version of software C is "Ver.001" at that time, with the update of function a, the software versions of software A, B, C, and E for function b will change to a combination of "Ver.001," "Ver.002," "Ver.001," and "Ver.003." In this case, as shown as "Pattern 2," the total number of achievements is equal to or greater than the first predetermined value, but the proportion of achievements that "operated" is less than the second predetermined value, so the control unit 21 performs step B5.

[0119] When the software versions of software B, D, and E that realize function a are changed as described above, if the software version of software A is "Ver.001" and the software version of software C is "Ver.003" at that time, with the update of function a, the software versions of software A, B, C, and E for function b will change to a combination of "Ver.001," "Ver.002," "Ver.003," and "Ver.003." In this case, as shown as "Pattern 3," the total number of achievements is less than the first predetermined value, so the control unit 21 performs step B8.

[0120] The first and second predetermined values ​​may be fixed or variable. For example, for a function that is used relatively frequently, a relatively large amount of performance data will be acquired, so the first predetermined value may be set relatively large. On the other hand, for a function that is used relatively infrequently, a relatively small amount of performance data will be acquired, so the first predetermined value may be set relatively small. Furthermore, the second predetermined value may be variable depending on the characteristics of the function. For example, for a function that requires safety and security, the second predetermined value may be set relatively large, and for a function that does not require safety and security as much, the second predetermined value may be set relatively small.

[0121] (2-2) Performance Database Update Process (See FIG. 13) In the OTA center 2, when the control unit 21 determines that an operation performance notification signal transmitted from the vehicle system 3 has been received, the control unit 21 starts the performance database update process. When the control unit 21 starts the performance database update process, it acquires performance data from the operation performance notification signal (B11, corresponding to the performance data acquisition procedure). When the control unit 21 acquires the performance data, it updates the performance database stored in the performance database storage unit 30 (B12, corresponding to the performance database update procedure), and ends the performance database update process. That is, by updating the performance database, the control unit 21 can keep the performance database up to date at all times and can provide the vehicle system 3 with prediction information that reflects the latest performance database.

[0122] Specifically, the control unit 21 identifies, as the update target portion, the results for the combination of software versions of functions associated with the confirmation result in the acquired result data from the result database. The control unit 21 increments by "1" the results for the update target portion that correspond to the confirmation result included in the acquired result data. Explaining with reference to FIG. 7 , in the case where the acquired result data is data in which a confirmation result indicating "operated" is associated with a software version combination of function a, "software B = SW_Ver.002, software D = SW_Ver.002, software D = SW_Ver.003," the control unit 21 identifies, as the update target portion, the results for "software B = SW_Ver.002, software D = SW_Ver.002, software D = SW_Ver.003" for function a, and increments "operated" from "1250" to "1251" among the results.

[0123] The performance database will now be described. In the OTA center 2, the control unit 21 may manage, as performance data, a combination of software versions of software that realizes a function, together with "manufacturer's advance operation check," "function generation," and "function version," in addition to the example shown in FIG. 7, as shown in FIG. 14. FIG. 14 illustrates, for example, a performance database for function a.

[0124] The "Manufacturer Pre-Operation Check" indicates the status of the manufacturer's pre-operation check for the software version combination of the corresponding software, indicating whether the pre-operation check has been completed and whether normal operation has been confirmed. The control unit 21 registers "Unknown" for the "Manufacturer Pre-Operation Check" until the manufacturer notifies the control unit 21 that the pre-operation check has been completed. Once the control unit 21 is notified of the completion of the pre-operation check, the control unit 21 registers "Completed" or "Not yet completed." The control unit 21 registers "Completed" when the manufacturer notifies the control unit 21 that the pre-operation check has been completed, indicating that normal operation has been confirmed, by conducting the pre-operation check and confirming normal operation. The control unit 21 also registers "Not yet completed" when the manufacturer notifies the control unit 21 that the pre-operation check has not been completed, for example, because the manufacturer is preparing to conduct the pre-operation check and normal operation has not yet been confirmed. Normal operation refers to, for example, operation that ensures safety and security during vehicle operation. Furthermore, the term "manufacturer" is not limited to a company that manufactures a vehicle, but also includes organizations and groups commissioned by the company. The case where "Unknown" is registered in the "Manufacturer Pre-operation Check" is, for example, in the third embodiment described below, when a combination of software versions in an operation performance notification signal received from the vehicle system 3 does not exist in the performance database and the combination is added to the performance database.

[0125] A "functional generation" indicates a generation corresponding to a representative software version in a combination of software versions of the corresponding software. For example, if software B, D, and E are used for function a and software D is the representative software, a combination in which software D has a software version of "Ver. 001" indicates the first generation, a combination in which software D has a software version of "Ver. 002" indicates the second generation, and a combination in which software D has a software version of "Ver. 003" indicates the third generation. As the representative software, for example, the software most related to function a is selected. While FIG. 14 shows an example in which software D is selected, software B or software E may also be selected. The above examples illustrate "functional generations" that can be uniquely identified from a combination of software versions, but "functional generations" that cannot be uniquely identified from a combination of software versions may also be used.

[0126] The "function version" indicates a character string representing the combination of software versions of the corresponding software. For example, if the combination of software versions B, D, and E is "Ver.001," "Ver.001," and "Ver.001," the result is "B001D001E001." The above examples show "function versions" that can be uniquely identified from the combination of software versions, but "function versions" that cannot be uniquely identified from the combination of software versions may also be used.

[0127] The control unit 21 registers the generation corresponding to each software version combination in the "functional generation" field and registers a character string in the "functional version" field. That is, if the control unit 21 can identify the "functional generation" and "functional version" from the software version combination, it may register the corresponding generation in the "functional generation" field and register a character string in the "functional version" field. On the other hand, if the control unit 21 cannot identify the "functional generation" and "functional version" from the software version combination, it may register the "functional generation" and "functional version" as "unknown." When the "functional generation" and "functional version" for that combination are notified by the manufacturer, the control unit 21 may register the notified "functional generation" and "functional version." Furthermore, the control unit 21 may exclude the "functional generation" and "functional version" from the management of the performance database, or may not manage the "functional generation" and "functional version."

[0128] In the CGW 5, the control unit 6 may display a function update inquiry screen shown in Fig. 15 instead of the function update inquiry screen shown in Fig. 9. On the function update inquiry screen, the control unit 6 displays a message "Feature updates available for your vehicle," displays a function summary for each generation of a specific function, and displays "Check details" buttons 121 to 122. In this case, the user can select the generation to which the user wishes to update by operating one of the "Check details" buttons 201 to 202.

[0129] As described above, the first embodiment can achieve the following advantageous effects. When software is updated in the vehicle system 3, performance data is generated by correlating the results of checking the status of malfunctions related to functions implemented by the updated software with the software version of the software that implements the functions. The OTA center 2 references the performance database to generate prediction information that is predicted when the software to be updated is updated, and transmits the generated prediction information to the vehicle system 3. When the OTA center 2 obtains performance data from the vehicle system 3, the performance database is updated. The vehicle system 3 presents prediction information that is predicted when the software to be updated is updated. It is possible to appropriately deal with malfunctions that are expected to occur due to an inappropriate combination of software versions.

[0130] Second Embodiment A second embodiment will be described with reference to FIGS. 16 to 19 . In the second embodiment, performance data is generated that also includes confirmation results of user feedback regarding usability. In the CGW 5, the control unit 6 displays a questionnaire entry screen shown in FIG. 16 , for example, when a predetermined period of time has elapsed since a function was updated. On the questionnaire entry screen, the control unit 6 displays check boxes for “Function N is GOOD,” “Function N is NOT GOOD,” and “No Answer” as a questionnaire regarding usability, as well as a “Submit entered questionnaire results” button 131 and a “Enter later” button 132. The user can provide feedback regarding the updated software by filling in any of the check boxes and operating the “Submit entered questionnaire results” button 131.

[0131] In this case, as shown in FIG. 17 , for example, for function a, the correspondence relationship between whether function a worked with the combination of software versions B, D, and E and information indicating feedback are managed, as well as information indicating feedback. In FIG. 17 , for function a, when the software versions of software B, D, and E are "Ver. 001," "Ver. 001," and "Ver. 001," the number of "worked" responses is significantly lower than the number of "did not work" responses, resulting in a high rating of "not good." Meanwhile, when the software versions of software B, D, and E are "Ver. 002," "Ver. 002," and "Ver. 003," the number of "worked" responses is significantly higher than the number of "did not work" responses, resulting in a high rating of "good." Furthermore, as shown in FIG. 18 , the performance data may be managed separately, including information indicating feedback for when function a worked and information indicating feedback for when function a did not work.

[0132] In the CGW 5, as shown in Figure 19, the control unit 6 displays the forecast information notification screen in comparison with the forecast information notification screen shown in Figure 10, and adds "Customer satisfaction level of function a after updating function a," "Customer satisfaction level of function b after updating function a," and "Customer satisfaction level of function c after updating function a," thereby displaying the user satisfaction level following the function update.

[0133] As described above, the second embodiment can provide the following advantageous effects. Performance data is generated by including the results of user feedback regarding usability. It is possible to appropriately address malfunctions that may be caused by an inappropriate combination of software versions, including information regarding usability.

[0134] (Third Embodiment) The third embodiment will be described with reference to Figs. 20 to 24. In the third embodiment, the presence or absence of software operation history is managed. In the OTA center 2, as shown in Fig. 20, the control unit 21 manages, as history data, the software z that realizes a function, together with "presence or absence of history" in addition to the example in Fig. 14. The "presence or absence of history" indicates whether or not the software version combination of the corresponding software has an operation history. That is, for a combination of software versions for which an operation history notification signal has been received at least once from the vehicular system 3, the "presence or absence of history" is "presence"; and for a combination of software versions for which an operation history notification signal has never been received from the vehicular system 3, the "presence or absence of history" is "absence". 20 illustrates a case where the "Proven track record" is "No" for a combination of software versions "Ver. 004," "Ver. 004," and "Ver. 003" of software B, D, and E, for which the "Manufacturer's advance operation check" has been "Completed," but a software combination for which the "Manufacturer's advance operation check" is "Unknown" or "Not yet" may be registered as having a "Proven track record" of "No." Also, a software combination may be registered as having a "No" track record, provided that the "Manufacturer's advance operation check" has been "Completed."

[0135] The OTA center 2 performs a history database update process as a center-side process. (2-3) History Database Update Process (See FIG. 21) When the control unit 21 determines that an operation history notification signal transmitted from the vehicle system 3 has been received, the control unit 21 starts the history database update process. When the control unit 21 starts the history database update process, it acquires history data from the operation history notification signal (B21, corresponding to the history data acquisition procedure). When the control unit 21 acquires the history data, it identifies the software version combination in the acquired history data and determines whether the software version combination in the history data exists in the history database (B22).

[0136] When the control unit 21 determines that the combination of software versions in the performance data does not exist in the performance database (B22: NO), it adds the combination of software versions in the performance data as performance data with an operation performance of "Yes" (B23, corresponding to the performance database update procedure), adds "1" to either "Worked" or "Did not work" in the performance data (B24, corresponding to the performance database update procedure), and terminates the performance database update process.

[0137] Specifically, when the control unit 21 identifies a combination of software versions "Ver. 002," "Ver. 001," and "Ver. 001" for software B, D, and E as a combination of software versions in the performance data while managing the performance database as shown in FIG. 20 , the control unit 21 determines that the combination of software versions does not exist in the performance database, and adds the combination of software versions in the performance data as performance data with an operation performance of "Yes" as shown in FIG. 22 . If the performance data is determined to be "Operated," the control unit 21 increments "Operated" by "1" for the performance data. FIG. 22 illustrates an example in which the performance data is "Operated" and "Operated" is incremented by "1." However, if the performance data is "Not Operated," the control unit 21 increments "Not Operated" by "1" for the performance data. By determining that the software version combination in the performance data does not exist in the performance database, the manufacturer can confirm the operating status of a software version combination that was not anticipated.

[0138] On the other hand, if the control unit 21 determines that the software version combination in the performance data exists in the performance database (B22: YES), it determines whether or not there is a performance record for that software version combination (B25). If the control unit 21 determines that there is no performance record for that software version combination (B25: NO), it changes the performance record for that performance data from "no" to "present" (B26, corresponding to the performance database update procedure), adds "1" to either "operated" or "did not operate" for that performance data (B27, corresponding to the performance database update procedure), and ends the performance database update process.

[0139] Specifically, when the control unit 21 identifies a combination of software versions "Ver. 004," "Ver. 004," and "Ver. 003" for software B, D, and E as a combination of software versions in the performance data while managing the performance database as shown in Fig. 20, it determines that the software version combination exists in the performance database, determines that the performance record for that software version combination is "absent," and changes the performance record for that performance data from "absent" to "present" as shown in Fig. 23. If it determines that the performance data is "operated," it increments "operated" by "1" in the performance data. Fig. 23 illustrates a case where the performance data is "operated" and "operated" is incremented by "1," but if the performance data is "not operated," it increments "not operated" by "1" in the performance data.

[0140] On the other hand, if the control unit 21 determines that the software version combination has a track record of operation (B25: YES), it adds "1" to either "Worked" or "Did not work" in the track record data (B27) and terminates the track record database update process.

[0141] Specifically, when the control unit 21 identifies a combination of software versions "Ver. 003," "Ver. 002," and "Ver. 003" for software B, D, and E as a combination of software versions in the performance data while managing the performance database as shown in FIG. 20, the control unit 21 determines that the software version combination exists in the performance database and determines that the performance data for that software version combination is "present." When the control unit 21 determines that the performance data is "operated," it increments "operated" by "1" in the performance data, as shown in FIG. 24. While FIG. 24 illustrates an example in which the performance data is "operated" and "operated" is incremented by "1," if the performance data is "not operated," it increments "not operated" by "1" in the performance data.

[0142] As described above, according to the third embodiment, the OTA center 2 updates the history database when history data, which associates the operation history of a function implemented by updated software with the software version of the software that implements the function, is acquired from the vehicle system 3. The OTA center 2 can appropriately check the operation history of the function implemented by the updated software.

[0143] (Fourth embodiment) The fourth embodiment will be described with reference to Fig. 25. In the fourth embodiment, an operation log is managed. As shown in Fig. 25, in the OTA center 2, the control unit 21 cooperates with an operation log database that stores operation logs, and manages combinations of software versions of software that realize functions together with the operation logs.

[0144] The operation log includes a log showing a malfunction situation related to a function realized by the software. A log showing a malfunction situation is, for example, a log showing a state in which the original operation of the function is incomplete or a state in which some kind of malfunction prevents the function as a whole from operating properly.

[0145] The operation log also includes a log showing the operation status of multiple processes that make up a function. A process is not limited to one piece of software with one version number. For example, if a function has image display and audio output, the log showing the operation status of the image display and audio output is a log showing the operation status of the image display and audio output.

[0146] The operation log also includes a log showing the operation status of a function in chronological order, such as a log showing the start time of the function, a log showing whether each process started or ended normally during the start or operation sequence, and a log showing the time.

[0147] Furthermore, the operation log includes a log showing the operation status of other functions related to the malfunctioning function, such as a log showing whether a function using the same software as the malfunctioning function was running or stopped at the time the malfunction occurred.

[0148] The OTA center 2 performs a record database update process as a center-side process. (2-4) Record Database Update Process (See FIG. 26) When the control unit 21 determines that an operation record notification signal transmitted from the vehicle system 3 has been received, the control unit 21 starts the record database update process. When the control unit 21 starts the record database update process, it acquires record data from the operation record notification signal (B31, corresponding to the record data acquisition procedure). When the control unit 21 acquires the record data, it acquires an operation log from the acquired record data (B32), updates the record database stored in the record database storage unit 30 (B33, corresponding to the record database update procedure), and ends the record database update process.

[0149] As described above, according to the fourth embodiment, the OTA center 2 updates the performance database when it acquires from the vehicle system 3 performance data in which the operation log of a function implemented by updated software is associated with the software version of the software implementing the function. The OTA center 2 can appropriately check the operation log of the function implemented by the updated software. By analyzing the operation log, it is possible to determine when an abnormality or malfunction occurred. Furthermore, by managing the operation log together with information indicating feedback, it is possible to determine, for example, that if the rating of "NOT GOOD" is relatively high, the urgency of the abnormality or malfunction indicated by the operation log is relatively high, and conversely, if the rating of "NOT GOOD" is relatively low, the urgency of the abnormality or malfunction indicated by the operation log is relatively low.

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

[0151] An OTA center has been used as an example of an external device, and examples have been given of cases where wireless reprogramming and wireless diagnostic services are performed, 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 reprogramming is performed.

[0152] Although the example has been given in which the performance database is used to generate prediction information, the performance database may also be used for other purposes, such as to identify a malfunctioning software combination and the need for improvement.

[0153] In the above example, the vehicle system 3 generates performance data for a function among a plurality of functions possessed by the vehicle when the function is updated and for other functions affected by the update of the function, and transmits the performance data to the OTA center 2. However, the vehicle system 3 may generate performance data for each of the plurality of functions and transmit the performance data to the OTA center 2. The plurality of functions here includes the updated function and other functions that use the same software as the updated function. Even in this configuration, when a function is updated, performance data can be generated for at least the updated function and other functions affected by the update of the function, and transmitted to the OTA center 2.

[0154] The OTA center 2 may select, from the performance data of multiple functions transmitted from the vehicle system 3, performance data of functions of a combination of software versions that is received for the first time from the vehicle system 3, and update the performance database using the selected performance data. For example, the OTA center 2 may manage and select whether performance data has been received from each vehicle for each software version combination of each function using a vehicle identification number (VIN (Vehicle Identification Number)) or the like. Even with the performance database managed and updated in this manner, it is possible to appropriately present, for each function and for each software version combination, the performance of functional malfunction situations in multiple vehicles due to that software version combination.

[0155] The function update inquiry screen, prediction information notification screen, questionnaire input screen, etc. may be displayed on an in-vehicle display, or may be displayed on a mobile information terminal owned by the user, for example, by connecting the mobile information terminal to the OTA center 2 so that data communication is possible.

[0156] The vehicle system 3 may be able to set update prevention protection for each function, for example, for functions specified by the user. The vehicle system 3 may store information regarding the update prevention protection setting in, for example, a non-volatile memory. When the vehicle system 3 displays a function update inquiry screen, if update prevention protection is set for a function for which an update is available, information indicating this may be added to the display. When the vehicle system 3 displays a prediction information notification screen, if update prevention protection is set for other functions affected by an update of a user-selected function, i.e., other functions whose software version changes due to an update of a user-selected function, information indicating this may be added to the display. By enabling update prevention protection to be set for each function, for example, if a user does not want to keep a favorite function up to date and wishes to continue using the current function that they are familiar with, update prevention protection can be set for a favorite function. For example, it is possible to prevent the software used by a favorite function from being updated due to an update of another function, thereby preventing changes in the usability of the favorite function.

[0157] The vehicle system 3 may inquire of the OTA center 2 about the existence of an available update for a software version combination that has a proven track record or that has undergone manufacturer-preliminary operation check, for example, for a function specified by a user. A software version combination that has a proven track record is, for example, a software version combination that has been determined to have a sufficient track record in step B4 of Fig. 11. A software version combination that has undergone manufacturer-preliminary operation check is, for example, a software version combination that has been recorded in the track record database of Fig. 14 as having undergone manufacturer-preliminary operation check.

[0158] When the vehicular system 3 queries the OTA center 2, it may notify the OTA center 2 of a combination of a function specified by a user and the current software versions of the function in the vehicle. The OTA center 2 may then identify, from a performance database, a software version combination that has a track record of operation for the queried function or that has been pre-confirmed by the manufacturer, and notify the OTA center 2 of an update to the identified software version combination as an available update. The available updates notified may include an upgrade, which is an update that changes the software version combination of the function to a newer one, as well as a downgrade, which changes the software version combination to an older version.

[0159] When the vehicle system 3 receives a notification of an available update, it may display a function update inquiry screen such as that shown in FIG. 15 . As a subsequent process, it may display a predicted information notification screen and generate historical data, as in the above-described embodiment. This is because even when a function is updated to a software version combination that has a history of operation or that has been pre-checked by the manufacturer, other functions may be affected by the update. Furthermore, when a function is updated to a software version combination that has been pre-checked by the manufacturer, historical data may not be generated for that function, but historical data may be generated for other functions that are affected by the update. With this configuration, for example, if a user's favorite function becomes malfunctioning as various functions are updated, the user can upgrade or downgrade the user's favorite function to a software version combination that has a history of operation or that has been pre-checked by the manufacturer.

[0160] In addition to the multiple functions subject to software updates, the vehicle may also have functions subject to legal requirements that are managed by RxSWIN (Rx Software Identification Number). When a user requests an update for a function managed by RxSWIN, a forecast information notification screen may be displayed and performance data may be generated for other functions that are affected by the update but are not managed by RxSWIN, as in the above-described embodiment. Furthermore, updates for functions not managed by RxSWIN may be limited so that the functions managed by RxSWIN are not changed to software combinations outside the authorized range. Such updates may be notified from the OTA center 2 to the vehicle system 3, and displayed as available updates on the forecast information notification screen.

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

[0162] In addition to what is set forth in the claims, the present disclosure also includes the following: [1] A vehicle system (3) that realizes a function by a combination of multiple pieces of software, the vehicle system including: a malfunction confirmation unit (26) that, in response to a software update, confirms a malfunction status related to a function realized by the updated software, and a performance data generation unit (28) that generates performance data by associating a confirmation result of the malfunction confirmation unit with the software version of the software that realizes the function.

[0163] [2] The vehicle system according to [1], further comprising: a performance data transmission unit (29) that transmits the performance data generated by the performance data generation unit to an external device.

[0164] [3] The vehicle system according to [1] or [2], wherein the malfunction confirmation unit confirms a malfunction status related to the first function in response to an update of software for realizing the first function, and also confirms a malfunction status related to a second function whose software version combination has changed due to the software update.

[0165] [4] The vehicle system according to any one of [1] to [3], wherein the malfunction confirmation unit confirms malfunction statuses related to a plurality of functions including the first function in response to an update of software for realizing the first function.

[0166] [5] A vehicle system according to any one of [1] to [4], further comprising a feedback confirmation unit (27) that confirms the status of feedback from users regarding usability in response to software updates, and the performance data generation unit generates the performance data by associating the confirmation results of the malfunction confirmation unit, the confirmation results of the feedback confirmation unit, and the software version of the software that realizes the function.

[0167] [6] An external device (2) that manages software for realizing functions in a vehicle system, comprising: a performance database storage unit (30) that stores performance data indicating the correspondence between combinations of software versions for realizing functions in the vehicle system for multiple vehicles and malfunction situations related to the functions as a performance database; a prediction information generation unit (33) that references the performance database and generates prediction information that is predicted when software scheduled to be updated is updated; and a prediction information transmission unit (34) that transmits the prediction information generated by the prediction information generation unit to the vehicle system.

[0168] [7] The external vehicle device according to [6], further comprising a total performance number deriving unit (31) that derives the total performance number in the performance database.

[0169] [8] The external vehicle device according to [6] or [7], further comprising a performance number ratio deriving unit (32) that derives a ratio of the number of performances without malfunction or the number of performances with malfunction in the performance database.

[0170] [9] The external vehicle device according to any one of [6] to [8], wherein the prediction information generating unit generates, as the prediction information, information indicating that a function realized by the software to be updated will operate normally, or information indicating that there is a possibility that a function realized by the software to be updated will malfunction.

[0171]

[10] The external vehicle device according to any one of [6] to [9], wherein the prediction information generating unit generates, as the prediction information, information indicating that a function realized by the software to be updated may malfunction, as well as information indicating that an update of other software is recommended to avoid the malfunction.

[0172]

[11] The external vehicle device according to any one of [6] to

[10] , wherein the prediction information generating unit generates, as the prediction information, information indicating feedback from a user regarding usability.

[0173]

[12] An external device (2) that manages software for realizing functions in a vehicle system, comprising: a performance database storage unit (30) that stores performance data indicating the correspondence between combinations of software versions for realizing functions in the vehicle system for multiple vehicles and malfunction statuses related to the functions as a performance database; a performance data acquisition unit (35) that acquires performance data from the vehicle system that associates confirmation results of malfunction statuses related to functions realized by updated software with the software versions of the software that realize the functions; and a performance database update unit (36) that updates the performance database when the performance data is acquired by the performance data acquisition unit.

[0174]

[13] The external vehicle device according to

[12] , wherein the performance database update unit updates the performance database based on performance data in which a combination of software versions has changed.

[0175]

[14] The external vehicle device according to

[12] or

[13] , wherein the performance database storage unit stores performance data as a performance database, including information indicating whether or not a combination of software versions has been pre-checked for operation.

[0176]

[15] An external vehicle device according to any one of

[12] to

[14] , wherein the performance database storage unit stores performance data indicating a correspondence between combinations of software versions for realizing functions in the vehicle system for a plurality of vehicles, malfunction statuses related to the functions, and information indicating feedback from users regarding usability, as a performance database.

[0177]

[16] A vehicle system (3) that realizes functions by combining multiple pieces of software, the vehicle system including a prediction information presentation unit (37) that presents prediction information that is predicted when software scheduled for update is updated.

[0178]

[17] The vehicle system described in

[16] , wherein the prediction information presentation unit presents, as the prediction information, information indicating that the function realized by the software to be updated will operate normally, or information indicating that the function realized by the software to be updated may malfunction.

[0179]

[18] The vehicle system according to

[16] or

[17] , wherein the prediction information presentation unit presents, as the prediction information, information indicating that a function realized by the software to be updated may malfunction, as well as information indicating that an update of other software is recommended to avoid the malfunction.

[0180]

[19] The vehicle system according to any one of

[16] to

[18] , wherein the prediction information presentation unit presents, as the prediction information, information indicating feedback from a user regarding usability.

[0181]

[20] A data communication system (1) comprising: a vehicle system (3) that realizes a function by a combination of multiple pieces of software; and an external device (2) that manages the software for realizing the functions in the vehicle system, wherein the vehicle system comprises: a malfunction confirmation unit (26) that confirms a malfunction status related to a function realized by the updated software in response to a software update; and a performance data generation unit (28) that generates performance data by correlating the confirmation result of the malfunction confirmation unit with the software version of the software that realizes the function, and the external device comprises: a performance database storage unit (30) that stores performance data indicating a correspondence between combinations of software versions for realizing a function in the vehicle system for multiple vehicles and a malfunction status related to the function as a performance database; a prediction information generation unit (33) that refers to the performance database and generates prediction information predicted in accordance with the update of software that is scheduled to be updated; and a prediction information transmission unit (34) that transmits the prediction information generated by the prediction information generation unit to the vehicle system.

[0182]

[21] The data communication system described in

[20] , wherein the external device is provided with: a performance data acquisition unit (35) that acquires performance data from the vehicle system that associates the results of confirmation of a malfunction status related to a function realized by updated software with the software version of the software that realizes that function; and a performance database update unit (36) that updates the performance database when the performance data is acquired by the performance data acquisition unit.

[0183]

[22] The data communication system according to

[20] or

[21] , wherein the vehicle system includes a prediction information presentation unit (37) that presents prediction information that is predicted when software scheduled for update is updated.

[0184]

[23] An external device (2) that manages software for realizing functions in a vehicle system, the external device comprising: a performance database storage unit (30) that stores performance data indicating the correspondence between combinations of software versions for realizing functions in the vehicle system for multiple vehicles and the operational performance of the functions in the vehicles as a performance database; a performance data acquisition unit (35) that acquires performance data from the vehicle system that associates the operational performance of functions realized by updated software with the software version of the software that realizes the functions; and a performance database update unit (36) that updates the performance database when the performance data is acquired by the performance data acquisition unit.

[0185]

[24] The external vehicle device described in

[23] , wherein the performance database update unit adds and manages the software version combination of the software in the performance data when the software version combination of the software in the performance data is a software version combination that is not stored in the performance database storage unit.

[0186]

[25] The external vehicle device according to

[23] or

[24] , wherein the performance database storage unit stores the performance record in the performance database in association with a confirmation state of a preliminary operation check.

[0187]

[26] An external device (2) that manages software for realizing functions in a vehicle system, the external device comprising: a performance database storage unit (30) that stores performance data indicating the correspondence between combinations of software versions for realizing functions in the vehicle system for multiple vehicles and operation logs of the functions in the vehicles as a performance database; a performance data acquisition unit (35) that acquires performance data from the vehicle system that associates the operation logs of functions realized by updated software with the software versions of the software that realizes the functions; and a performance database update unit (36) that updates the performance database when the performance data is acquired by the performance data acquisition unit.

[0188]

[27] The external vehicle device described in

[26] , wherein the operation log includes at least one of a log showing the status of a malfunction related to a function realized by software, a log showing the operation status of multiple processes that make up the function, a log showing the operation status of the function in chronological order, and a log showing the operation status of other functions related to the malfunctioning function.

[0189]

[28] The external vehicle device according to

[26] or

[27] , wherein the performance database storage unit stores the operation log as the performance database in association with information indicating feedback from users regarding usability.

Claims

1. A vehicle system (3) that realizes a function by a combination of multiple pieces of software, comprising: a malfunction confirmation unit (26) that confirms, in response to a software update, a malfunction status related to the function realized by the updated software; and a performance data generation unit (28) that generates performance data by associating the confirmation result of the malfunction confirmation unit with the software version of the software that realizes the function.

2. The vehicle system according to claim 1, further comprising: a performance data transmission unit (29) for transmitting the performance data generated by the performance data generation unit to an external device.

3. A vehicle system as described in claim 1, wherein the malfunction confirmation unit confirms a malfunction status related to a first function in response to an update of software for realizing a first function, and also confirms a malfunction status related to a second function whose software version combination has changed due to the software update.

4. A vehicle system as described in claim 1, wherein the malfunction confirmation unit confirms a malfunction status relating to a plurality of functions including the first function in response to an update of software for realizing the first function.

5. A vehicle system as described in claim 1, further comprising a feedback confirmation unit (27) for confirming the status of feedback from users regarding usability in response to a software update, wherein the performance data generation unit generates the performance data by correlating the confirmation results of the functional malfunction confirmation unit, the confirmation results of the feedback confirmation unit, and the software version of the software that realizes that function.

6. A data processing program for a vehicle system that causes a control unit (6) of a vehicle system (3) that realizes functions by a combination of multiple software programs to execute a malfunction confirmation procedure for confirming the malfunction status of a function realized by updated software in response to the software being updated, and a performance data generation procedure for generating performance data by matching the confirmation results of the malfunction confirmation procedure with the software version of the software that realizes the function.

7. A data processing method for a vehicle system (3) that realizes functions by a combination of multiple software programs, the data processing method comprising: a malfunction confirmation procedure for confirming, in response to a software update, a malfunction status related to the function realized by the updated software; and a performance data generation procedure for generating performance data by associating the confirmation results of the malfunction confirmation procedure with the software version of the software that realizes the function.

8. An external device (2) that manages software for realizing functions in a vehicle system, comprising: an actual database storage unit (30) that stores, as an actual database, actual data indicating the correspondence between combinations of software versions for realizing functions in the vehicle system for a plurality of vehicles and malfunction situations related to the functions; a prediction information generation unit (33) that references the actual database and generates prediction information that is predicted when software to be updated is updated; and a prediction information transmission unit (34) that transmits the prediction information generated by the prediction information generation unit to the vehicle system.

9. The external device according to claim 8, further comprising a total achievement number deriving section (31) for deriving a total achievement number in the achievement database.

10. The external vehicle device according to claim 8, further comprising a performance number ratio deriving section (32) for deriving a ratio of the number of performances without malfunction or the number of performances with malfunction in the performance database.

11. An external vehicle device as described in claim 8, wherein the prediction information generating unit generates, as the prediction information, information indicating that a function realized by the software to be updated will operate normally, or information indicating that there is a possibility that a function realized by the software to be updated will malfunction.

12. An external vehicle device as described in claim 8, wherein the prediction information generating unit generates, as the prediction information, information indicating that there is a possibility that a function realized by the software to be updated may malfunction, as well as information indicating that an update of other software is recommended to avoid the malfunction.

13. The external vehicle device according to claim 8, wherein the prediction information generating unit generates, as the prediction information, information indicating feedback from users regarding usability.

14. A data processing program for an external device that causes a control unit (21) of an external device (2) that manages software for realizing functions in a vehicle system and has a performance database storage unit (30) that stores performance data indicating the correspondence between combinations of software versions for realizing functions in the vehicle system for a plurality of vehicles and malfunction situations related to those functions as a performance database to execute a prediction information generation procedure that references the performance database and generates prediction information that is predicted in response to the update of software that is scheduled to be updated, and a prediction information transmission procedure that transmits the prediction information generated by the prediction information generation procedure to the vehicle system.

15. A data processing method for an external device (2) that manages software for realizing functions in a vehicle system, the external device having an actual database storage unit (30) that stores, as an actual database, actual data indicating the correspondence between combinations of software versions for realizing functions in the vehicle system for a plurality of vehicles and malfunction situations related to those functions, the data processing method for an external device comprising: a prediction information generation step that references the actual database and generates prediction information predicted in response to the update of software scheduled for update; and a prediction information transmission step that transmits the prediction information generated by the prediction information generation step to the vehicle system.

16. An external device (2) that manages software for realizing functions in a vehicle system, the external device comprising: a performance database storage unit (30) that stores, for a plurality of vehicles, performance data indicating the correspondence between combinations of software versions for realizing functions in the vehicle system and malfunction statuses related to the functions as a performance database; a performance data acquisition unit (35) that acquires from the vehicle system performance data that associates confirmation results of malfunction statuses related to functions realized by updated software with the software versions of the software that realizes the functions; and a performance database update unit (36) that updates the performance database when the performance data is acquired by the performance data acquisition unit.

17. The external vehicle device according to claim 16, wherein the history database update unit updates the history database based on history data in which a combination of software versions has changed.

18. The external vehicle device according to claim 16, wherein the performance database storage unit stores performance data as a performance database, including information indicating whether or not a combination of software versions has been pre-checked for operation.

19. An external vehicle device as described in claim 16, wherein the performance database storage unit stores performance data indicating a correspondence between combinations of software versions for realizing functions in the vehicle system for a plurality of vehicles, malfunction statuses related to those functions, and information indicating feedback from users regarding usability as a performance database.

20. A data processing program for an external device that causes a control unit (21) of an external device (2) that manages software for realizing functions in a vehicle system and has a performance database storage unit (30) that stores performance data indicating the correspondence between combinations of software versions for realizing functions in the vehicle system for a plurality of vehicles and malfunction statuses related to those functions as a performance database to execute: a performance data acquisition procedure that acquires from the vehicle system performance data that associates the confirmation results of the malfunction status related to a function realized by updated software with the software version of the software that realizes that function; and a performance database update procedure that updates the performance database when the performance data is acquired by the performance data acquisition procedure.

21. A data processing method for an external device (2) that manages software for realizing functions in a vehicle system and has an actual database storage unit (30) that stores, as an actual database, actual data indicating the correspondence between combinations of software versions for realizing functions in the vehicle system, for a plurality of vehicles, and malfunction statuses related to the functions, the data processing method comprising: a actual data acquisition step of acquiring from the vehicle system actual data that corresponds to the confirmation results of the malfunction status related to a function realized by updated software and the software version of the software that realizes the function; and a actual database update step of updating the actual database when the actual data is acquired by the actual data acquisition step.

22. A vehicle system (3) that realizes functions by combining multiple software programs, the vehicle system having a prediction information presentation unit (37) that presents prediction information predicted when software scheduled for update is updated.

23. A vehicle system as described in claim 22, wherein the prediction information presentation unit presents, as the prediction information, information indicating that a function realized by the software to be updated will operate normally, or information indicating that there is a possibility that a function realized by the software to be updated will malfunction.

24. A vehicle system as described in claim 22, wherein the prediction information presentation unit presents, as the prediction information, information indicating that a function realized by the software to be updated may malfunction, together with information indicating that an update of other software is recommended to avoid the malfunction.

25. The vehicle system according to claim 22, wherein the prediction information presentation unit presents, as the prediction information, information indicating feedback from a user regarding usability.

26. A data processing program for a vehicle system that causes a control unit (6) of a vehicle system (3) that realizes functions by combining multiple software programs to execute a prediction information presentation procedure that presents prediction information that will be predicted when software that is scheduled to be updated is updated.

27. A data processing method for a vehicle system (3) that realizes functions by combining multiple software programs, the data processing method comprising: a procedure for presenting predictive information that is predicted when software to be updated has been updated in a vehicle system (3) that realizes functions by combining multiple software programs.

28. A data communication system (1) comprising: a vehicle system (3) which realizes a function by a combination of multiple pieces of software; and an external device (2) which manages the software for realizing the functions in the vehicle system, wherein the vehicle system comprises: a malfunction confirmation unit (26) which confirms a malfunction status related to a function realized by the updated software in response to the software being updated; and a performance data generation unit (28) which generates performance data by correlating a confirmation result of the malfunction confirmation unit with a software version of the software that realizes the function; and the external device comprises: a performance database storage unit (30) which stores, as a performance database, performance data indicating a correspondence between combinations of software versions for realizing a function in the vehicle system for a plurality of vehicles and a malfunction status related to the function; a prediction information generation unit (33) which refers to the performance database and generates prediction information predicted in response to the update of software to be updated; and a prediction information transmission unit (34) which transmits the prediction information generated by the prediction information generation unit to the vehicle system.

29. A data communication system as described in claim 28, wherein the external device comprises: a performance data acquisition unit (35) that acquires from the vehicle system performance data that corresponds to the confirmation result of a malfunction status related to a function realized by the updated software and the software version of the software that realizes the function; and a performance database update unit (36) that updates the performance database when the performance data is acquired by the performance data acquisition unit.

30. A data communication system according to claim 28, wherein the vehicle system includes a prediction information presentation unit (37) that presents prediction information predicted when software to be updated has been updated.

31. An external device (2) that manages software for realizing functions in a vehicle system, the external device comprising: a performance database storage unit (30) that stores, for a plurality of vehicles, performance data indicating a correspondence between combinations of software versions for realizing functions in the vehicle system and the operational performance of the functions in the vehicles as a performance database; a performance data acquisition unit (35) that acquires from the vehicle system performance data that associates the operational performance of a function realized by updated software with the software version of the software that realizes the function; and a performance database update unit (36) that updates the performance database when the performance data is acquired by the performance data acquisition unit.

32. An external vehicle device as described in claim 31, wherein the history database update unit adds and manages the combination of software versions of the software in the history data when the combination of software versions in the history data is a combination of software versions not stored in the history database storage unit.

33. The external vehicle device according to claim 31, wherein the performance database storage unit stores the operation performance in the performance database in association with a confirmation state of a preliminary operation check.

34. A data processing program for an external device that causes a control unit (21) of an external device (2) that manages software for realizing functions in a vehicle system and has a performance database storage unit (30) that stores, as a performance database, performance data indicating the correspondence between combinations of software versions for realizing functions in the vehicle system, for a plurality of vehicles, and the operational performance of the functions in the vehicles, to execute: a performance data acquisition procedure for acquiring from the vehicle system performance data that corresponds the operational performance of a function realized by updated software to the software version of the software that realizes the function; and a performance database update procedure for updating the performance database when the performance data is acquired by the performance data acquisition procedure.

35. A data processing method for an external device (2) that manages software for realizing functions in a vehicle system and has a track record database storage unit (30) that stores, for a plurality of vehicles, track record data indicating the correspondence between combinations of software versions for realizing functions in the vehicle system and the operational track record of the functions in the vehicles as a track record database, the data processing method comprising: a track record data acquisition step of acquiring from the vehicle system track record data that associates the operational track record of a function realized by updated software with the software version of the software that realizes the function; and a track record database update step of updating the track record database when the track record data is acquired by the track record data acquisition step.

36. An external device (2) that manages software for realizing functions in a vehicle system, the external device comprising: a performance database storage unit (30) that stores, for a plurality of vehicles, performance data indicating the correspondence between combinations of software versions for realizing functions in the vehicle system and operation logs of the functions in the vehicles as a performance database; a performance data acquisition unit (35) that acquires from the vehicle system performance data that associates the operation logs of functions realized by updated software with the software versions of the software that realizes the functions; and a performance database update unit (36) that updates the performance database when the performance data is acquired by the performance data acquisition unit.

37. An external vehicle device as described in claim 31, wherein the operation log includes at least one of a log indicating a malfunction status related to a function realized by software, a log indicating the operation status of multiple processes that constitute the function, a log indicating the operation status of the function in chronological order, and a log indicating the operation status of other functions related to the malfunctioning function.

38. The external vehicle device according to claim 31, wherein the performance database storage unit stores the operation log in the performance database in association with information indicating user feedback regarding usability.

39. A data processing program for an external device that causes a control unit (21) of an external device (2) that manages software for realizing functions in a vehicle system and has a performance database storage unit (30) that stores, as a performance database, performance data indicating the correspondence between combinations of software versions for realizing functions in the vehicle system, for a plurality of vehicles, and operation logs of the functions in the vehicles, to execute: a performance data acquisition procedure for acquiring from the vehicle system performance data in which operation logs of functions realized by updated software are associated with the software versions of the software that realizes the functions; and a performance database update procedure for updating the performance database when the performance data is acquired by the performance data acquisition procedure.

40. A data processing method for an external device (2) that manages software for realizing functions in a vehicle system and has an actual database storage unit (30) that stores, for a plurality of vehicles, actual data indicating the correspondence between combinations of software versions for realizing functions in the vehicle system and operation logs of the functions in the vehicles as an actual database, the data processing method comprising: a actual data acquisition step of acquiring from the vehicle system actual data in which operation logs of functions realized by updated software are associated with software versions of the software that realizes the functions; and a actual database update step of updating the actual database when the actual data has been acquired by the actual data acquisition step.

Images