Vehicle system, off-vehicle device, data communication system, data processing program, and data processing method

Abstract

The present application relates to a vehicle system, an external device, a data communication system, a data processing program, and a data processing method. A vehicle system (3) implements a function by a combination of a plurality of software. The vehicle system includes a function insufficiency confirmation section (26) that, in response to software being updated, confirms a state of a function insufficiency related to a function implemented by the updated software, and a performance data generation section (28) that generates performance data by associating a result of the confirmation by the function insufficiency confirmation section with a software version of the software that implements the function.

Description

[0001] Cross-references to related applications

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

[0003] This disclosure relates to vehicle systems, external devices, data communication systems, data processing programs, and data processing methods. Background Technology

[0004] For example, with the diversification of vehicle control functions such as driver assistance and autonomous driving, there are technologies that allow updating the software in the electronic control unit (hereinafter referred to as ECU (Electronic Control Unit)) installed in the vehicle via wireless or wired means. For example, Patent Document 1 discloses a structure for OTA (Over-The-Air) reprogramming of software via wireless means.

[0005] Patent Document 1: Japanese Patent Application Publication No. 2020-27627

[0006] Vehicles typically contain multiple ECUs, each with its own software programmed to perform its functions. Furthermore, in recent years, high-performance HPC (High-Performance Computers) have been increasingly integrated into vehicles, and these HPCs also often contain multiple software programs. Moreover, these software programs are interdependent, meaning that various functions can be achieved through a combination of multiple programs.

[0007] For example, as OTA (Over-The-Air) updates become more widespread and users gain greater freedom in software updates, it's expected that users will be able to update software freely according to their own wishes. In this case, it's possible that the software versions might be combined in ways the development vendor hadn't anticipated, potentially leading to incomplete functionality due to inappropriate combinations of software versions. Therefore, it's advisable to verify software version combinations beforehand.

[0008] However, due to the fact that different development suppliers design ECUs independently, or that the combination of software versions becomes infinitely large, it is impractical to verify the combination of software versions in advance, as this would require enormous costs and time. Summary of the Invention

[0009] The purpose of this disclosure is to provide appropriate solutions to functional deficiencies resulting from inappropriate combinations of software versions.

[0010] According to one aspect of this disclosure, a vehicle system implements functions through a combination of multiple software programs. The vehicle system includes: a function incompleteness confirmation unit that, in response to a software update, confirms a function incompleteness related to the functions implemented by the updated software; and a performance data generation unit that establishes a correspondence between the confirmation result of the function incompleteness confirmation unit and the software version of the software implementing the function, generating performance data.

[0011] According to one aspect of the data processing program for a vehicle system disclosed herein, the control unit of the vehicle system, which implements functions through a combination of multiple software programs, executes: a function incompleteness confirmation step, in response to a software update, confirming a function incompleteness condition related to the functions implemented by the updated software; and a performance data generation step, establishing a correspondence between the confirmation result of the function incompleteness confirmation step and the software version of the software implementing the function, and generating performance data.

[0012] According to one aspect of the data processing method for a vehicle system disclosed herein, in a vehicle system that implements functions through a combination of multiple software programs, the following steps are performed: a function incompleteness confirmation step, in response to a software update, confirming a function incompleteness related to the functions implemented by the updated software; and a performance data generation step, establishing a correspondence between the confirmation result of the function incompleteness confirmation step and the software version of the software implementing the function, thereby generating performance data.

[0013] According to one aspect of this disclosure, when the software is updated, a correlation is established between the confirmation results of functional deficiencies related to the functions implemented by the updated software and the software version of the software implementing those functions, generating performance data. By generating performance data in the vehicle system, it is possible to appropriately address anticipated functional deficiencies caused by inappropriate combinations of software versions.

[0014] According to one aspect of this disclosure, an external vehicle device manages software used to implement functions in a vehicle system. The external device includes: a performance database storage unit that stores performance data of multiple vehicles in a performance database, the performance data representing a combination of software versions used to implement functions in the vehicle system and a correspondence between these software versions and situations of functional incompleteness related to those functions; a prediction information generation unit that, with reference to the performance database, generates prediction information that is predicted in the event that a predetermined software update is performed; and a prediction information transmission unit that transmits the prediction information generated by the prediction information generation unit to the vehicle system.

[0015] According to one aspect of the data processing program for an external vehicle device disclosed herein, the external vehicle device manages software used to implement functions in a vehicle system and includes a performance database storage unit that stores performance data of multiple vehicles in a performance database. The performance data represents a combination of software versions used to implement functions in the vehicle system and a correspondence between these software versions and any functional incompleteness related to those functions. The data processing program causes the control unit of the external vehicle device to execute: a prediction information generation step, referring to the performance database, generating prediction information predicted in the event that a predetermined software update is performed; and a prediction information transmission step, causing the prediction information generated by the prediction information generation step to be transmitted to the vehicle system.

[0016] According to one aspect of the data processing method for an external vehicle device disclosed herein, the external vehicle device manages software used to implement functions in a vehicle system and includes a performance database storage unit that stores performance data of multiple vehicles in a performance database. The performance data represents a combination of software versions used to implement functions in the vehicle system and a correspondence between these software versions and any incomplete functionality related to those functions. The external vehicle device performs the following steps: a prediction information generation step, referring to the performance database, generating prediction information that is predicted to occur when software is updated as scheduled; and a prediction information transmission step, sending the prediction information generated by the prediction information generation step to the vehicle system.

[0017] According to one method of this disclosure, predictive information is generated in the event of a predetermined software update, referencing a performance database, and this generated predictive information is sent to the vehicle system. By generating predictive information in an external device and sending it to the vehicle system, incomplete functionality due to inappropriate combinations of software versions can be appropriately addressed.

[0018] According to one aspect of this disclosure, an external vehicle device manages software used to implement functions in a vehicle system. The external device includes: a performance database storage unit that stores performance data of multiple vehicles in a performance database, the performance data representing a combination of software versions used to implement functions in the vehicle system and a correspondence between these functions and related functional deficiencies; a performance data acquisition unit that acquires performance data from the vehicle system, the performance data establishing a correspondence between confirmation results of functional deficiencies related to functions implemented by updated software and the software version of the software implementing those functions; and a performance database update unit that updates the performance database when the performance data is acquired by the performance data acquisition unit.

[0019] According to one aspect of the data processing program for an external vehicle device disclosed herein, the external vehicle device manages software used to implement functions in a vehicle system and includes a performance database storage unit that stores performance data of multiple vehicles in a performance database. The performance data represents a combination of software versions used to implement functions in the vehicle system and a correspondence between these functions and any functional deficiencies. The data processing program causes the control unit of the external vehicle device to execute: a performance data acquisition step, acquiring performance data from the vehicle system, whereby the performance data establishes a correspondence between the confirmation results of functional deficiencies related to functions implemented by updated software and the software version of the software implementing those functions; and a performance database update step, updating the performance database if the performance data is acquired through the performance data acquisition step.

[0020] According to one aspect of the data processing method for an external vehicle device disclosed herein, the external vehicle device manages software used to implement functions in a vehicle system and includes a performance database storage unit. This performance database storage unit stores performance data from multiple vehicles into a performance database. The performance data represents a combination of software versions used to implement functions in the vehicle system and a correspondence between these functions and any functional deficiencies. The external vehicle device performs the following steps: a performance data acquisition step, acquiring performance data from the vehicle system, whereby the performance data establishes a correspondence between the confirmation results of functional deficiencies related to functions implemented by updated software and the software version of the software implementing those functions; and a performance database update step, updating the performance database when the performance data is acquired through the performance data acquisition step.

[0021] According to one aspect of this disclosure, when performance data is acquired from a vehicle system, a performance database is updated, wherein the performance data establishes a correspondence between the confirmation results of functional deficiencies related to functions implemented by the updated software and the software version of the software implementing those functions. By updating the performance database in an external device when performance data is acquired from a vehicle system, anticipated functional deficiencies due to inappropriate combinations of software versions can be appropriately addressed.

[0022] According to one aspect of this disclosure, a vehicle system achieves its functions through a combination of multiple software programs. The vehicle system includes a predictive information prompting unit that prompts predictive information that is expected when the software is updated as scheduled.

[0023] According to one aspect of the data processing program for an external device of the present disclosure, the control unit of a vehicle system that performs functions through a combination of multiple software programs executes a prediction information prompting step, which prompts prediction information that is predicted as the software is updated along with a predetermined update.

[0024] According to one aspect of the data processing method for an external device of the present disclosure, in a vehicle system that implements functions through a combination of multiple software programs, a prediction information prompting step is performed, which prompts prediction information in the event that a predetermined software update is performed.

[0025] According to one aspect of this disclosure, by providing predictive information in the vehicle system that anticipates an upcoming software update, it is possible to appropriately address potential functional deficiencies caused by inappropriate combinations of software versions.

[0026] According to one aspect of this disclosure, a data communication system comprises: a vehicle system that implements functions through a combination of multiple software programs; and an external device for managing the software used to implement the functions in the vehicle system. The vehicle system includes: a function incompleteness confirmation unit that, in response to a software update, confirms a function incompleteness condition related to a function implemented by the updated software; and a performance data generation unit that establishes a correspondence between the confirmation result of the function incompleteness confirmation unit and the software version of the software implementing the function, generating performance data. The external device includes: a performance database storage unit that stores performance data of multiple vehicles in a performance database, the performance data representing a correspondence between combinations of software versions used to implement functions in the vehicle system and function incompleteness conditions related to those functions; a prediction information generation unit that, with reference to the performance database, generates prediction information predicted in the event of a predetermined software update; and a prediction information transmission unit that transmits the prediction information generated by the prediction information generation unit to the vehicle system.

[0027] According to one aspect of this disclosure, in a vehicle system, when the software is updated, a correlation is established between the confirmation results of functional deficiencies related to the functions implemented by the updated software and the software version of the software implementing those functions, generating performance data. In an external device, referring to the performance database, predictive information is generated in the event of a predetermined software update, and this generated predictive information is sent to the vehicle system. This allows for appropriate handling of anticipated functional deficiencies due to inappropriate combinations of software versions.

[0028] According to one aspect of this disclosure, an external vehicle device manages software used to implement functions in a vehicle system. The external vehicle device includes: a performance database storage unit that stores performance data of multiple vehicles in a performance database, the performance data representing a correspondence between combinations of software versions used to implement functions in the vehicle system and the performance data of those functions in the vehicle; a performance data acquisition unit that acquires performance data from the vehicle system, the performance data establishing a correspondence between the performance data of functions implemented by updated software and the software versions of the software implementing those functions; and a performance database update unit that updates the performance database when the performance data is acquired by the performance data acquisition unit.

[0029] According to one aspect of the data processing program for an external vehicle device disclosed herein, the external vehicle device manages software used to implement functions in a vehicle system and includes a performance database storage unit that stores performance data of multiple vehicles in a performance database. The performance data represents a correspondence between combinations of software versions used to implement functions in the vehicle system and the performance data of those functions in the vehicle. The data processing program causes the control unit of the external vehicle device to execute: a performance data acquisition step, acquiring performance data from the vehicle system, whereby the performance data establishes a correspondence between the performance data of functions implemented by updated software and the software versions of the software implementing those functions; and a performance database update step, updating the performance database if the performance data is acquired through the performance data acquisition step.

[0030] According to one aspect of the data processing method for an external vehicle device disclosed herein, the external vehicle device manages software used to implement functions in a vehicle system and includes a performance database storage unit. This performance database storage unit stores performance data from multiple vehicles into a performance database. The performance data represents the correspondence between combinations of software versions used to implement functions in the vehicle system and the performance records of those functions in the vehicle. The external vehicle device performs the following steps: a performance data acquisition step, acquiring performance data from the vehicle system, whereby the performance data establishes a correspondence between the performance records of functions implemented by updated software and the software versions of the software implementing those functions; and a performance database update step, updating the performance database when the performance data is acquired through the performance data acquisition step.

[0031] According to one method of this disclosure, when performance data is obtained from the vehicle system, the performance database is updated, wherein the performance data establishes a correspondence between the action performance of the function implemented by the updated software and the software version of the software implementing that function. By updating the performance database in the external device when performance data is obtained from the vehicle system, the action performance of the function implemented by the updated software can be appropriately confirmed.

[0032] According to one aspect of this disclosure, an external vehicle device manages software used to implement functions in a vehicle system. The external device includes: a performance database storage unit that stores performance data of multiple vehicles in a performance database, the performance data representing a correspondence between combinations of software versions used to implement functions in the vehicle system and the action logs of those functions in the vehicle; a performance data acquisition unit that acquires performance data from the vehicle system, the performance data establishing a correspondence between the action logs of functions implemented by updated software and the software versions of the software implementing those functions; and a performance database update unit that updates the performance database when the performance data is acquired by the performance data acquisition unit.

[0033] According to one aspect of the data processing program for an external vehicle device disclosed herein, the external vehicle device manages software used to implement functions in a vehicle system and includes a performance database storage unit that stores performance data of multiple vehicles in a performance database. The performance data represents a correspondence between combinations of software versions used to implement functions in the vehicle system and the action logs of those functions in the vehicle. The data processing program causes the control unit of the external vehicle device to execute: a performance data acquisition step, acquiring performance data from the vehicle system, wherein the performance data establishes a correspondence between the action logs of functions implemented by updated software and the software versions of the software implementing those functions; and a performance database update step, updating the performance database if the performance data is acquired through the performance data acquisition step.

[0034] According to one aspect of the data processing method for an external vehicle device disclosed herein, the external vehicle device manages software used to implement functions in a vehicle system and includes a performance database storage unit. This performance database storage unit stores performance data from multiple vehicles into a performance database. The performance data represents a correspondence between combinations of software versions used to implement functions in the vehicle system and the action logs of those functions in the vehicle. The external vehicle device performs the following steps: a performance data acquisition step, acquiring performance data from the vehicle system, whereby the performance data establishes a correspondence between the action logs of functions implemented by updated software and the software versions of the software implementing those functions; and a performance database update step, updating the performance database when the performance data is acquired through the performance data acquisition step.

[0035] According to one method of this disclosure, when performance data is obtained from the vehicle system, the performance database is updated, wherein the performance data establishes a correspondence between the action logs of functions implemented by the updated software and the software version of the software implementing those functions. By updating the performance database in an external device when performance data is obtained from the vehicle system, the action logs of functions implemented by the updated software can be appropriately verified. Furthermore, by parsing the action logs, it is possible to determine at what time an anomaly or malfunction occurred. Attached Figure Description

[0036] The foregoing objects, as well as other objects, features, and advantages of this disclosure, will become more apparent from the following detailed description with reference to the accompanying drawings, which are shown below.

[0037] Figure 1 This is a diagram showing the overall structure of the first embodiment.

[0038] Figure 2 This is a diagram illustrating the format conversion.

[0039] Figure 3 This is a diagram illustrating the formation of the format.

[0040] Figure 4 This is a diagram representing the software configuration.

[0041] Figure 5 This is a functional block diagram of the control unit in CGW.

[0042] Figure 6 This is a functional block diagram of the control unit in the OTA center.

[0043] Figure 7 It is a graph representing actual performance data.

[0044] Figure 8 This is a flowchart illustrating the CGW process.

[0045] Figure 9 This is an image representing the function update query screen.

[0046] Figure 10 This is an image representing a notification screen for forecast information.

[0047] Figure 11 This is a flowchart representing the processing at the OTA center.

[0048] Figure 12 It is a graph representing actual performance data.

[0049] Figure 13 This is a flowchart representing the processing at the OTA center.

[0050] Figure 14 It is a graph representing the performance database.

[0051] Figure 15 This is an image representing the function update query screen.

[0052] Figure 16 The second embodiment is shown in the diagram, which represents the questionnaire input screen.

[0053] Figure 17 It is a graph representing actual performance data.

[0054] Figure 18 It is a graph representing actual performance data.

[0055] Figure 19 This is an image representing a notification screen for forecast information.

[0056] Figure 20 The third implementation method is represented by a diagram showing the performance database.

[0057] Figure 21 This is a flowchart representing the processing at the OTA center.

[0058] Figure 22 It is a graph representing the performance database.

[0059] Figure 23 It is a graph representing the performance database.

[0060] Figure 24 It is a graph representing the performance database.

[0061] Figure 25 The fourth implementation method is represented by a diagram showing the performance database.

[0062] Figure 26 This is a flowchart representing the processing at the OTA center. Detailed Implementation

[0063] Hereinafter, several embodiments will be described with reference to the accompanying drawings. In subsequent embodiments, descriptions of parts identical to those in the prior embodiments may be omitted.

[0064] (First Implementation)

[0065] Reference Figures 1 to 15 The first embodiment will be described. For example... Figure 1 As shown, the data communication system 1 includes an OTA center 2 (equivalent 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-17 (described later). The DCM 4 is an in-vehicle communication unit that communicates with the OTA center 2 via a communication network. The communication network may consist of, for example, mobile communication networks based on 4G or 5G lines, the Internet, or WiFi (Wireless Fidelity) (registered trademark). Alternatively, the DCM 4 and CGW 5 may be integrated, with the functions of the DCM 4 integrated into the structure of the CGW 5. Furthermore, the functions of the DCM 4 and CGW 5 may be integrated into a structure such as a display.

[0066] DCM4 will transmit data distributed from OTA Center 2 to CGW5. Data distributed from OTA Center 2 to DCM4 may include, for example, reprogrammed software. The data communication between OTA Center 2 and CGW5, i.e., inter-center communication, follows either the SOVD format of the SOVD communication standard or the RestAPI format of the Rest (Representational State Transfer) API communication standard.

[0067] The CGW5 includes a control unit 6. The control unit 6 is mainly composed of a microcomputer (hereinafter referred to as a microcomputer) having a CPU, ROM, RAM and I / O, etc. It performs control by executing software processing of computer programs stored in non-transitory physical storage media by the CPU and hardware processing based on dedicated electronic circuits, thereby controlling the operation of the CGW5.

[0068] CGW5 can also be a component providing HPC. For example, CGW5 can have a System-on-Chip (SoC) as its hardware and an Adaptive Platform as its software. CGW5 can also have multiple Virtual Machines (VMs), which can include VMs for various platforms such as the Adaptive Platform and the Classic Platform. CGW5 can also function as a component in a vehicle's Electrical Components (EE) architecture, for example, as a so-called Vehicle Computer.

[0069] The control unit 6 includes a downloader 7, an OTA master controller 8, a first update master controller 9, a second update master controller 10, a third update master controller 11, a fourth update master controller 12, and a specification data holding unit 13, each function being configured. When a download execution request is received from the OTA master controller 8, the downloader 7 instructs the DCM4 to perform download processing. The downloader 7 downloads data from the OTA center 2 via the DCM4 by receiving data distributed from the OTA center 2 and transmitting the received data from the DCM4.

[0070] The OTA master controller 8 has the function of overall management of SU (Software Update). The OTA master controller 8 has a vehicle status confirmation unit 8a, an agreement result receiving unit 8b, an SU execution request unit 8c, and a completion notification sending and receiving unit 8d for each function.

[0071] The vehicle status confirmation unit 8a, for example, obtains and confirms the vehicle status from the ECU of the software update target. The agreement result receiving unit 8b, for example, receives the agreement results of the execution of the download process, the execution of the installation process, and the execution of the activation process from the in-vehicle HMI (Human Machine Interface) (not shown) along with the software update.

[0072] When the installation execution conditions, such as obtaining consent for the installation process, are met, the SU execution request unit 8c outputs an installation execution request to the corresponding update master controller among the update master controllers 9 to 12. When the update master controller receives an installation execution request from the SU execution request unit 8c, it instructs the ECU targeted for software update to perform the installation process. The ECU targeted for software update performs the installation process when instructed to do so. Examples of software update methods include firmware updates on an ECU-by-ECU basis, and updates on software within the ECU, such as applications and libraries.

[0073] When activation execution conditions, such as obtaining consent for activation processing, are met, the SU execution request unit 8c outputs an activation execution request to the corresponding update master controller among update master controllers 9 to 12. When the update master controller receives an activation execution request from the SU execution request unit 8c, it instructs the ECU targeted for software update to perform activation processing. The ECU targeted for software update performs activation processing when instructed to do so.

[0074] When the completion notification transceiver 8d receives an installation completion notification from the ECU of the software update recipient, it sends the installation completion notification from DCM4 to OTA center 2. When the completion notification transceiver 8d receives an activation completion notification from the ECU of the software update recipient, it sends the activation completion notification from DCM4 to OTA center 2.

[0075] Next, the update controllers 9 to 12 will be explained. The update controllers 9 to 12 are connected to ECUs 14 to 17 via the vehicle network. The vehicle network can be, for example, CAN (Controller Area Network) or Ethernet (registered trademark).

[0076] The first update controller 9 is connected to the corresponding ECU 14 of UCM (Update & Configuration Management) via the vehicle network. Following instructions from the OTA controller 8, the first update controller 9 communicates with the ECU 14 corresponding to the UCM. This data communication between the first update controller 9 and the ECU 14, i.e., inter-ECU communication, follows the UCM format of the UCM communication standard. The UCM format is defined by AUTOSAR. The ECU 14 corresponding to the UCM is, for example, an ECU implementing UI (User Interface) or MM (MultiMedia) services. The functions of the first update controller 9 can also be configured on the ECU 14 corresponding to the UCM.

[0077] The ECU14 corresponding to the UCM can also be a component providing so-called HPC. For example, the ECU14 corresponding to the UCM can have a SoC as its hardware and an adaptive platform as its software. The ECU14 corresponding to the UCM can also have multiple VMs, which can include VMs of various platforms such as adaptive platform VMs and classic platform VMs. The classic platform VMs can also constitute the VMs corresponding to the UDS. The ECU14 corresponding to the UCM can also function as a component in the vehicle's EE architecture, for example, as a so-called domain controller or regional ECU.

[0078] The second update master controller 10 is connected to the ECU 15 corresponding to SOVD via the vehicle network. Following instructions from the OTA master controller 8, the second update master controller 10 communicates data with the ECU 15 corresponding to SOVD. This data communication between the second update master controller 10 and the ECU 15, i.e., inter-ECU communication, follows the SOVD communication standard and its format. The SOVD format is defined by JSON (JavaScript Object Notation). The ECU 15 corresponding to SOVD is, for example, an ECU implementing ADAS (Advanced Driving Assistant System) services. The functions of the second update master controller 10 can also be configured on the ECU 15 corresponding to SOVD.

[0079] The ECU15 corresponding to SOVD can also be a component providing so-called HPC. For example, the ECU15 corresponding to SOVD can have a SoC as its hardware and an adaptive platform as its software. The ECU15 corresponding to SOVD can also have multiple VMs, which can include VMs of various platforms such as adaptive platform VMs and classic platform VMs. The classic platform VMs can also constitute the VMs corresponding to UDS. The ECU15 corresponding to SOVD can also function as a component in the vehicle's EE architecture, for example, as a so-called domain controller or regional ECU.

[0080] The third update master controller 11 connects to the ECU 16 corresponding to UDS (Unified Diagnostic Services) via the vehicle network. Following instructions from the OTA master controller 8, the third update master controller 11 communicates data with the ECU 16 corresponding to UDS. This data communication between the third update master controller 11 and the ECU 16 corresponding to UDS, i.e., inter-ECU communication, follows the UDS communication standard and format. The UDS format is OEM-dependent. The ECU 16 corresponding to UDS is, for example, an ECU providing services for engine systems, HV (Hybrid) systems, and EV (Electric Vehicle) systems.

[0081] For example, the ECU16 corresponding to UDS can also have an MCU (Micro Controller Unit) as its hardware and a classic platform as its software.

[0082] The fourth update master controller 12 connects to the ECU 17 corresponding to ODX (Open Diagnostic Data Exchange) / OTX (Open Test Sequence Exchange) via the vehicle network. Following instructions from the OTA master controller 8, the fourth update master controller 12 communicates data with the ECU 17 corresponding to ODX / OTX. This data communication between the fourth update master controller 12 and the ECU 17 corresponding to ODX / OTX, i.e., inter-ECU communication, follows the ODX / OTX format of the ODX / OTX communication standard. The ODX / OTX format is defined by XML (eXtensible Markup Language).

[0083] For example, the ECU17 corresponding to ODX / OTX can also have an MCU as its hardware and a classic platform as its software.

[0084] The functions of the update master controllers 9-12 can be set in CGW5 or ECUs 14-17, respectively. Alternatively, the functions of the update master controllers 9-12 can be set in ECUs other than CGW5 and ECUs 14-17. When the functions of the update master controllers 9-12 are set in ECUs 14-17, the update master controllers 9-12 communicate with specific software within ECUs 14-17. For example, if the first update master controller 9 is set in ECU 14 corresponding to the UCM, the first update master controller 9 communicates with the software responsible for the UCM within ECU 14. Similarly, if the second update master controller 9 is set in ECU 15 corresponding to the SOVD, the second update master controller 9 communicates with the software responsible for the SOVD within ECU 15.

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

[0086] The updated main controllers 9-12 have format conversion and format formation functions. The format conversion function converts the inter-center communication format according to the standard of the corresponding ECU, and the format formation function forms the inter-center communication format from the inter-ECU communication format between their respective corresponding ECUs.

[0087] Reference Figure 2The format conversion function is explained below. The first update master controller 9 communicates with the ECU 14 corresponding to the UCM according to the UCM communication standard, therefore converting the inter-ECU communication format to UCM format. If the inter-ECU communication is in SOVD format, the first update master controller 9 converts the SOVD format to UCM format. If the inter-ECU communication is in RestAPI format, the first update master controller 9 converts the RestAPI format to UCM format. Alternatively, if the inter-ECU communication is in RestAPI format, the RestAPI format can also be converted to SOVD format in the downloader 7 or the OTA master controller 8, and then the SOVD format can be converted to UCM format in the first update master controller 9.

[0088] The second update master controller 10 follows the SOVD communication standard for inter-ECU communication with the corresponding SOVD ECU 15. Therefore, it converts the inter-center communication format to SOVD format as needed. If the inter-center communication is in SOVD format, the second update master controller 10 applies it directly without conversion. If the inter-center communication is in RestAPI format, the second update master controller 10 converts the RestAPI format to SOVD format. Alternatively, if the inter-center communication is in RestAPI format, the RestAPI format can also be converted to SOVD format in the downloader 7 or the OTA master controller 8.

[0089] The third-update master controller 11 follows the UDS communication standard for inter-ECU communication with the corresponding ECU 16, thus converting the inter-center communication format to UDS format. If the inter-center communication is in SOVD format, the third-update master controller 11 converts the SOVD format to UDS format. If the inter-center communication is in RestAPI format, the third-update master controller 11 converts the RestAPI format to UDS format. Alternatively, if the inter-center communication is in RestAPI format, the RestAPI format can be converted to SOVD format in the downloader 7 or OTA master controller 8, and then the SOVD format can be converted to UDS format in the third-update master controller 11.

[0090] The fourth update master controller 12 performs inter-ECU communication with the corresponding ODX / OTX ECU 17 according to the ODX / OTX communication standard, thus converting the inter-center communication format to ODX / OTX format. If the inter-center communication is in SOVD format, the fourth update master controller 12 converts the SOVD format to ODX / OTX format. If the inter-center communication is in RestAPI format, the fourth update master controller 12 converts the RestAPI format to ODX / OTX format. Alternatively, if the inter-center communication is in RestAPI format, the RestAPI format can also be converted to SOVD format in the downloader 7 or OTA master controller 8, and then the SOVD format can be converted to ODX / OTX format in the fourth update master controller 12.

[0091] Reference Figure 3 The format formation function is explained. The first update master controller 9 communicates with the corresponding ECU 14 of the UCM according to the UCM communication standard, thus forming the inter-center communication format from the UCM format. When the inter-center communication is in SOVD format, the first update master controller 9 forms the SOVD format from the UCM format. When the inter-center communication is in RestAPI format, the first update master controller 9 forms the RestAPI format from the UCM format.

[0092] The second update master controller 10 follows the SOVD communication standard for inter-ECU communication with the corresponding ECU 15, thus forming the inter-center communication format from the SOVD format as needed. If the inter-center communication is in SOVD format, the second update master controller 10 does not form the SOVD format but applies it directly. If the inter-center communication is in RestAPI format, the second update master controller 10 forms the RestAPI format from the SOVD format.

[0093] The third-upgraded master controller 11 follows the UDS communication standard for inter-ECU communication with the corresponding ECU 16, thus forming the inter-center communication format from the UDS format. When the inter-center communication is in SOVD format, the third-upgraded master controller 11 forms the SOVD format from the UDS format. When the inter-center communication is in RestAPI format, the third-upgraded master controller 11 forms the RestAPI format from the UDS format.

[0094] The fourth-updated master controller 12 communicates with the corresponding ECU 17 of ODX / OTX according to the ODX / OTX communication standard, thus forming the inter-center communication format from the ODX / OTX format. When the inter-center communication is in SOVD format, the fourth-updated master controller 12 forms the SOVD format from the ODX / OTX format. When the inter-center communication is in RestAPI format, the fourth-updated master controller 12 forms the RestAPI format from the ODX / OTX format.

[0095] Next, the software written into the ECU and HPC will be explained. The ECU and HPC contain software that performs specific functions. These software programs are interdependent, and various functions are achieved through the combination of multiple programs. Figure 4 Examples include writing software A to the first ECU 18, software B to the second ECU 19, and software C to E to the HPC 20. The first ECU 18, the second ECU 19, and the HPC 20 respectively correspond to... Figure 1 One of ECUs 14 to 17 as described in the document.

[0096] 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 achieved through the collaboration of software B, D, and E, and function b is achieved through the collaboration of software A, B, C, and E. When multiple software programs collaborate to achieve a function, for example, if the combination of software versions is not anticipated by the development vendor, inappropriate combinations of software versions may lead to incomplete functionality. Regarding this, OTA Center 2 collaborates with Vehicle System 3 to manage incomplete functionality due to combinations of software versions.

[0097] For example, in a vehicle equipped with multiple functions implemented by multiple software programs, there may be cases where common software is included in both the multiple software programs implementing the first function and the multiple software programs implementing the second function. That is, there may be cases where software is used by both the first and second functions. In this situation, updates to the first function may cause changes in the combination of software versions for the second function. Figure 4 In the example, software B and E are software used by both function a and function b. For instance, an update to function a, which includes updates to software B and E, would cause a change in the combination of software versions of function b. In this case, the combination of software versions of function b might become a combination not anticipated by the development vendor, potentially leading to incomplete functionality due to an inappropriate combination of software versions.

[0098] The following explains the management of incomplete functionality due to the combination of software versions. The handling of incomplete management functionality includes processing the generation of performance data by vehicle system 3, processing the sending of prediction information from OTA center 2 to vehicle system 3, processing the updating of the performance database by OTA center 2, and processing of prediction information prompts from vehicle system 3.

[0099] like Figure 5 As shown, in CGW5, the control unit 6 includes: a performance data generation processing unit 22 for processing performance data; and a prediction information prompting processing unit 25 for processing prediction information. The control unit 6 executes the data processing program of the vehicle system 3, which is a computer program, through these performance data generation processing units 22 and prediction information prompting processing units 25. Furthermore, by executing the data processing program of the vehicle system 3 by the control unit 6, the data processing method of the vehicle system 3 is implemented.

[0100] like Figure 6 As shown, the OTA center 2 includes a control unit 21. The control unit 21 is mainly composed of a microcomputer with a CPU, ROM, RAM, and I / O, etc. It performs control by executing software processing of computer programs stored in a non-transitory physical storage medium by the CPU and hardware processing based on dedicated electronic circuits, thereby controlling the operation of the OTA center 2.

[0101] The control unit 21 includes a prediction information transmission processing unit 23 for transmitting prediction information to the vehicle system 3, and a performance database update processing unit 24 for updating the performance database. The control unit 21 executes a data processing program for the external device, which is a computer program, through the prediction information transmission processing unit 23 and the performance database update processing unit 24. Furthermore, by executing the data processing program for the external device, the control unit 21 implements a data processing method for the external device.

[0102] The performance data generation and processing unit 22 includes a function incompleteness confirmation unit 26, a feedback confirmation unit 27, a performance data generation unit 28, and a performance data transmission unit 29. When the software is updated, the function incompleteness confirmation unit 26 confirms function incompleteness related to the functions implemented by the updated software. When the software used to implement the first function is updated, the function incompleteness confirmation unit 26 confirms function incompleteness related to the first function, and also confirms function incompleteness related to a second function where the software version combination changes due to the software update. When the software used to implement the first function is updated, the function incompleteness confirmation unit 26 confirms function incompleteness related to multiple functions, including the first function.

[0103] exist Figure 4In the case of the software combination shown, for example, for function a, when the software version of software B is migrated from "Ver.001" to "Ver.002", the software version of software D is migrated from "Ver.001" to "Ver.002", and the software version of software E is migrated from "Ver.001" to "Ver.003", the function incompleteness verification unit 26 verifies whether function a may be incomplete, and since software B and E are related to function b, it also verifies whether function b may be incomplete.

[0104] The feedback confirmation unit 27, in response to a software update, confirms the status of user feedback regarding availability. When the incomplete functionality confirmation unit 26 confirms a functional incompleteness, the performance data generation unit 28 establishes a correspondence between the confirmation result and the software version implementing that function, generating performance data. When the performance data is generated by the performance data generation unit 28, the performance data transmission unit 29 sends the generated performance data from DCM4 to OTA center 2.

[0105] The prediction information prompting processing unit 25 includes a prediction information prompting unit 37. The prediction information prompting unit 37 prompts prediction information that is predicted when the software is updated along with a scheduled update.

[0106] The forecast information transmission and processing unit 23 includes a performance database storage unit 30, a total performance number export unit 31, a performance number ratio export unit 32, a forecast information generation unit 33, and a forecast information transmission unit 34.

[0107] The performance database storage unit 30 stores the performance data of multiple vehicles into a performance database. This performance data represents the combination of software versions used to implement functions in the vehicle system 3 and the correspondence between these software versions and any incomplete functionality related to those functions. Figure 4 In the case of the software combination shown, such as Figure 7 As shown, for function a, the performance database storage unit 30 stores the combination of software versions B, D, and E and the correspondence between whether or not it is in operation as performance data; for function b, the performance database storage unit 30 stores the combination of software versions A, B, C, and E and the correspondence between whether or not it is in operation as performance data.

[0108] Figure 7In this text, the values ​​for "Action" and "No Action" represent actual performance. "Action" means the function was implemented correctly through the software combination. For example, if it's a function related to vehicle movement, it means all functions such as acceleration, deceleration, stopping, and turning were implemented correctly. Similarly, if it's a navigation function unrelated to vehicle movement, it means all functions such as map display, location, destination setting, route search, and route guidance were implemented correctly. "No Action" means the function was not implemented correctly through the software combination. For example, if it's a function related to vehicle movement, it means at least some functions such as acceleration, deceleration, stopping, and turning were not implemented correctly. Similarly, if it's a navigation function unrelated to vehicle movement, it means at least some functions such as map display, location, destination setting, route search, and route guidance were not implemented correctly.

[0109] exist Figure 7 In the example, for function a, in the combination of software versions "Ver.001", "Ver.001", and "Ver.001" for software B, D, and E, the number of "operated" records (0) is much lower than the number of "inactive" records (1020), indicating that it cannot operate and a malfunction has occurred. In the combination of software versions "Ver.002", "Ver.002", and "Ver.003" for software B, D, and E, the number of "operated" records (1250) is much higher than the number of "inactive" records (0), indicating that it operates normally and no malfunction has occurred.

[0110] Similarly, for function b, in the combination of software versions "Ver.001", "Ver.001", "Ver.001", "Ver.001" for software A, B, C, and E, the number of "operated" records (0) is much lower than the number of "inactive" records (1220), indicating that it cannot operate and a malfunction has occurred. In the combination of software versions "Ver.001", "Ver.002", "Ver.002", "Ver.003" for software A, B, C, and E, the number of "operated" records (1450) is much higher than the number of "inactive" records (0), indicating that it operates normally and no malfunction has occurred.

[0111] The total performance score export unit 31 exports the total performance score from the performance score database. For example, for function a, the total performance score export unit 31 exports "1020" as the total performance score from the combination of software versions "Ver.001", "Ver.001", and "Ver.001" for software B, D, and E.

[0112] The performance ratio export unit 32 exports the proportion of performance data in the performance database that includes or excludes incomplete functions. For example, for function a, in the combination of software versions "Ver.001", "Ver.001", and "Ver.001" for software B, D, and E, the performance ratio export unit 32 exports "0%" as the proportion of performance data without incomplete functions and "100%" as the proportion of performance data with incomplete functions.

[0113] The prediction information generation unit 33, referring to a performance database, generates prediction information that anticipates the upcoming software update. This prediction information includes information indicating that functions implemented by the scheduled software update operate normally, or information indicating that functions implemented by the scheduled software update may become incomplete. It also generates information indicating that functions implemented by the scheduled software update may become incomplete, and information prompting the updating of other software to avoid incomplete functionality. Furthermore, the prediction information generation unit 33 generates prediction information based on user feedback regarding usability.

[0114] When the prediction information is generated by the prediction information generation unit 33, the prediction information transmission unit 34 sends the generated prediction information to the vehicle system 3.

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

[0116] The performance data acquisition unit 35 acquires performance data from the vehicle system 3. This performance data establishes a correspondence between the confirmation results of incomplete functions related to the functions implemented by the updated software and the software version of the software implementing the function. When the performance data is acquired by the performance data acquisition unit 35, the performance database update unit 36 ​​updates the performance database stored in the performance database storage unit 30.

[0117] In CGW5, the control unit 6 stores and manages multiple software programs that implement each of the various functions of the vehicle, as well as combinations of the current software versions of those programs. The control unit 6 stores information about the multiple software programs implementing each function in non-volatile memory, for example, in a list format, as in-vehicle software management information, and refers to this software management information. For combinations of the current software versions of each function, the control unit 6 retrieves the software and software version possessed by each ECU in the vehicle, for example, by querying and obtaining that ECU, and records it in the aforementioned in-vehicle software management information.

[0118] Furthermore, before updating a function, the control unit 6 determines the combination of software versions for each of the multiple functions after the update. For example, the control unit 6 determines the software whose software version has changed based on the multiple software programs implementing a function and the software versions of each program before and after the update. The control unit 6 compares the functions using the determined software with the vehicle's software management information to determine the combination of software versions for each of the multiple functions after the update before updating a function. In this way, when updating a function, the control unit 6 determines other functions whose software version combinations have changed, and the combination of software versions for those other functions after the change.

[0119] Additionally, the control unit 6 can also use information obtained from the OTA center 2 to determine the software versions of each software component in an updated function. For example, when the control unit 6 obtains information from the OTA center 2 indicating the availability of an update for a function, it can also obtain information representing the combination of software versions of the updated function.

[0120] Next, refer to Figures 8 to 12 The functions of the above structures will be explained. The vehicle-side processing performed by CGW5 and the center-side processing performed by OTA center 2 will be explained in turn.

[0121] (1) Vehicle-side treatment performed by CGW5 (refer to) Figures 8 to 10 )

[0122] In CGW5, the control unit 6 displays information at specific times, such as when a user boards or alights from the vehicle. Figure 9 The function update query screen shown is displayed. On this screen, the control unit 6 displays the message "Function updates available in your vehicle," shows a summary of each function to be updated, and displays "Confirm Details" buttons 101-103. The user can select the function to be updated by pressing one of the "Confirm Details" buttons 101-103. When the user presses one of the "Confirm Details" buttons 101-103, the control unit 6 begins vehicle-side processing and determines the combination of all software versions after the function update (A1).

[0123] In detail, when the user operates one of the "Confirm Details" buttons 101-103, the control unit 6 determines, for example, the combination of software versions of the functions corresponding to the button operated by the user (hereinafter referred to as the user-selected function) after the update, for all multiple functions of the vehicle, using the method described above. At this time, the control unit 6 also determines other functions affected by the update of the user-selected function, and also determines the combination of software versions of these other functions after the update of the user-selected function. In this embodiment, other functions affected by the update of the user-selected function refer to other functions whose software version combination changes due to the update of the user-selected function. Furthermore, when the control unit 6 determines that there are no other functions affected by the update of the user-selected function, it moves from step A1 to A4, without performing steps A2 and A3.

[0124] For example, when a user operates the "Confirm Details" button 101 corresponding to function a, the control unit 6 determines the combination of software versions B, D, and E that implement function a before and after the function a update. Furthermore, the control unit 6 identifies the software whose software version changes due to the function a update, and determines whether the combination of software versions A, B, C, and E that implement function b changes due to the function a update. If at least one of software B or E is updated due to the function a update, the control unit 6 determines that the combination of software versions for function b changes due to the function a update.

[0125] When the control unit 6 determines the combination of all software versions after the function update, it sends a query notification signal from DCM4 to OTA center 2 (A2). This query notification signal is used to query prediction information based on the combination of software versions and waits to receive a prediction information notification signal from OTA center 2. In this embodiment, the control unit 6 sends a query notification signal from DCM4 to OTA center 2 to query prediction information for other functions affected by the update of the user-selected function. The query notification signal specifies the query target function and the combination of the software versions of the query target function after the update of the user-selected function. If there are multiple other functions affected by the update of the user-selected function, the control unit 6 takes each of these other functions as the query target function and sends a query notification signal from DCM4 to OTA center 2. That is, the control unit 6 performs steps A2 and A3 for each query target function.

[0126] When the control unit 6 receives the prediction information notification signal distributed from the OTA center 2 via the DCM4, it obtains the query results from the OTA center 2. The control unit 6 then determines whether the performance confirmation of all functions has been completed (A3).

[0127] Specifically, the control unit 6 determines whether query results from the OTA center 2 have been obtained for all query target functions. The query results include predictions generated by the prediction information generation unit 33, referencing the performance database, regarding the impact of updates to user-selected functions on the query target functions. That is, the query results include action predictions, such as whether a query target function with the combination of the updated software version specified by the query notification signal is predicted to operate normally, or whether it is predicted to potentially experience functional incompleteness. Furthermore, the query results may also include a functional summary of the query target function (equivalent to...). Figure 10 The functional summary of functions b and c is shown below.

[0128] When the control unit 6 determines that the performance confirmation of all functions has not been completed (A3: "No"), it returns to step A2 and repeats step A2 for the functions for which the performance confirmation has not been completed.

[0129] When control unit 6 determines that the performance confirmation of all functions has been completed (A3: "Yes"), it displays... Figure 10 The predicted information notification screen shown (A4, equivalent to the predicted information prompt step) prompts the user to wait for the function update. The content of the predicted information notification screen includes predictions of the impact of the user-selected function update on other functions. Specifically, the content of the predicted information notification screen includes predictions of the actions taken after the user-selected function update for other functions whose software version combinations have changed due to the user-selected function update. This prediction is included in the query results obtained from OTA Center 2 in steps A2 and A3.

[0130] Figure 10 An example is shown of a prediction information notification screen when a user operates the "Confirm Details" button 101 corresponding to function a in the function update query screen. In the prediction information notification screen, the control unit 6 displays the message "Update function a to the latest details", shows the impact of updating function a, and displays the "Update function a" button 111 and the "Update function a and function b" button 112.

[0131] Figure 10The example illustrates how functions b and c are affected by the update of function a. For function b, corresponding to the notification (described later) indicating insufficient action performance, the message "Due to the update of function a, function b will be affected, but the action performance is insufficient, which may result in inoperability. In this case, if function b is also updated, the action performance will be sufficient, which may resolve the problem." That is, it informs the user that function b's action performance is insufficient, which may result in inoperability; if function b is also updated, the action performance will be sufficient, which may resolve the problem. For function c, corresponding to the notification (described later) indicating sufficient action performance, the message "Due to the update of function a, function c will be affected, but the action performance is sufficient, and it is likely there will be no problem." That is, it informs the user that function c's action performance is sufficient, and it is likely there will be no problem.

[0132] Control unit 6 determines whether a function update operation has been performed (A5). For example, if control unit 6 determines that a timeout has occurred before the user performed the function update operation (A5: "No"), it terminates the vehicle-side processing.

[0133] On the other hand, for example, when the control unit 6 determines that the user has performed a function update operation before the timeout (A5: "Yes"), it performs a 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, which are software corresponding to function a. When the user operates the "Update function a and function b" button 102, the control unit 6 downloads, installs, and activates software A, B, C, and E, which are software corresponding to functions a and b.

[0134] When the control unit 6 completes the function update, it confirms any incomplete functions related to the functions implemented by the updated software (equivalent to a function incompleteness confirmation step), establishes a correspondence between the confirmation result of the function incompleteness and the software version of the software implementing the function, and generates performance data (equivalent to a performance data generation step). In this embodiment, performance data is generated for user-selected functions and other functions affected by the update of the user-selected functions. That is, as described above, since software B and E are common to both functions a and b, when updating function a, which includes an update of either software B or E, the control unit 6 generates performance data related to function b in addition to performance data related to function a.

[0135] Various methods can be envisioned for determining a malfunction, and these methods may vary depending on the function being checked. Examples of such methods include: determining malfunction based on continuity checks, such as API (Application Programming Interface) checks of relevant modules performed when the function is started; determining malfunction based on whether errors occur during function operation after startup; and determining malfunction based on whether errors occur during operation in shadow mode. Furthermore, depending on the function, it is also possible that the entity determining the malfunction is a control unit different from control unit 6, such as the control unit of an ECU different from CGW5. In this case, control unit 6 can also obtain the malfunction determination result from this different control unit and confirm the malfunction based on that result.

[0136] When the control unit 6 generates performance data, it sends an action performance notification signal containing that data from the DCM4 to the OTA center 2 (A7). The control unit 6 then determines whether the transmission of action performance notification signals for all functions implemented by the updated software has been completed (A8). Specifically, the control unit 6 determines whether the transmission of action performance notification signals for user-selected functions and other functions affected by the update of user-selected functions has been completed.

[0137] When control unit 6 determines that the transmission of action performance notification signals for all functions has not been completed (A8: "No"), it returns to step S7 and repeats step A7 for the functions for which the transmission of action performance notification signals has not been completed. When control unit 6 determines that the transmission of action performance notification signals for all functions has been completed (A8: "Yes"), it ends the vehicle-side processing.

[0138] (2) Central-side processing performed by OTA Center 2 (refer to) Figures 11 to 13 )

[0139] OTA Center 2 handles forecast information notification and performance database updates as the central processing unit. The following is a description of each process.

[0140] (2-1) Forecast Information Notification Processing (Refer to) Figures 11 to 12 )

[0141] In OTA center 2, when control unit 21 determines that it has received a query notification signal sent from vehicle system 3, it begins predictive information notification processing. When control unit 21 begins predictive information notification processing, it refers to the performance database to confirm the action performance (B1) of the combination of software versions of the function specified by the query notification signal.

[0142] For the function of confirming action performance, the control unit 21 determines whether the total number of performances is greater than or equal to a first predetermined value (e.g., "100") (B2). When the control unit 21 determines that the total number of performances is greater than or equal to the first predetermined value (B2: "Yes"), it determines whether the percentage of performances that have been "operated" is greater than or equal to a second predetermined value (e.g., "90%)" (B3). When the control unit 21 determines that the percentage of performances that have been "operated" is greater than or equal to the second predetermined value (B3: "Yes"), it generates information indicating that the function has sufficient action performances as prediction information (equivalent to the prediction information generation step), and sends a prediction information notification signal indicating the generated prediction information to the vehicle system 3 (B4, equivalent to the prediction information sending step), ending the prediction information notification processing.

[0143] On the other hand, when the control unit 21 determines that the proportion of "operated" results is less than the second predetermined value (B3: "No"), it generates information indicating that the function may be incomplete as prediction information (equivalent to the prediction information generation step), and sends a prediction information notification signal indicating the generated prediction information to the vehicle system 3 (B5, equivalent to the prediction information sending step). The control unit 21 refers to the results database to determine whether there exists a combination in which all relevant software versions are high versions, the total number of results is greater than or equal to the first predetermined value, and the proportion of "operated" results is greater than or equal to the second predetermined value (S6).

[0144] In detail, the control unit 21 refers to the performance database and determines, for the combination of software versions specified in the query notification signal, whether there is a combination of software versions that implement the function of the query object, have all software versions that are high versions, have a total number of performances that is above a first predetermined value, and have a proportion of performances that are "operated" that is above a second predetermined value.

[0145] When the control unit 21 determines that there is a combination in which all relevant software versions are high versions, the total number of actual results is above the first predetermined value, and the proportion of actual results that have been "operated" is above the second predetermined value (S6: "Yes"), it generates information indicating that it should prompt the updating of other software to avoid incomplete functionality as prediction information (equivalent to the prediction information generation step), and sends a prediction information notification signal indicating the generated prediction information to the vehicle system 3 (B7, equivalent to the prediction information sending step), and ends the prediction information notification processing.

[0146] When the control unit 21 determines that the total number of actual performances is less than a first predetermined value (B2: "No"), it generates information indicating insufficient performance for the function as prediction information (equivalent to the prediction information generation step), and sends a prediction information notification signal indicating the generated prediction information to the vehicle system 3 (B8, equivalent to the prediction information sending step). In this case, the control unit 21 also performs the processing described in B6 and thereafter, and ends the prediction information notification processing. Information indicating prompting the updating of other software to avoid functional incompleteness is, for example, information indicating prompting an update to the combination of software versions determined to exist in step B6.

[0147] Specifically, regarding Figure 7 In the case of the software combination shown, for example, for function a, when the software version of software B is migrated from "Ver.001" to "Ver.002", the software version of software D is migrated from "Ver.001" to "Ver.002", and the software version of software E is migrated from "Ver.001" to "Ver.003", refer to Figure 12 Please provide an explanation.

[0148] When the software versions of software B, D, and E implementing function a are migrated as described above, if the software version of software A is "Ver.001" and the software version of software C is "Ver.002", then along with the update of function a, for function b, the software versions of software A, B, C, and E will be migrated to a combination of "Ver.001", "Ver.002", "Ver.002", and "Ver.003". In this case, as shown in "Mode 1", since the total number of actual results is greater than or equal to a first predetermined value and the proportion of "operated" results is greater than or equal to a second predetermined value, the control unit 21 proceeds to step B4.

[0149] When the software versions of software B, D, and E implementing function a are migrated as described above, if the software version of software A is "Ver.001" and the software version of software C is "Ver.001", then along with the update of function a, for function b, the software versions of software A, B, C, and E will be migrated to a combination of "Ver.001", "Ver.002", "Ver.001", and "Ver.003". In this case, as shown in "Mode 2", since the total number of actual results is above the first predetermined value, but the proportion of "operated" results is less than the second predetermined value, the control unit 21 proceeds to step B5.

[0150] When the software versions of software B, D, and E implementing function a are migrated as described above, if the software version of software A is "Ver.001" and the software version of software C is "Ver.003", then along with the update of function a, for function b, the software versions of software A, B, C, and E will be migrated to a combination of "Ver.001", "Ver.002", "Ver.003", and "Ver.003". In this case, as shown in "Mode 3", since the total number of actual results is less than the first predetermined value, the control unit 21 proceeds to step B8.

[0151] Furthermore, the first and second specified values ​​can be either fixed or variable. For example, for functions with relatively high usage frequency, more performance data will be collected, so the first specified value can be set relatively high; on the other hand, for functions with relatively low usage frequency, less performance data will be collected, so the first specified value can be set relatively low. Additionally, the second specified value can be set to be variable depending on the nature of the function. For example, for functions requiring high security, the second specified value can be set relatively high; for functions with lower security requirements, the second specified value can be set relatively low.

[0152] (2-2) Performance Database Update Processing (Refer to) Figure 13 )

[0153] In OTA center 2, when control unit 21 determines that it has received an action performance notification signal sent from vehicle system 3, it begins performance database update processing. When control unit 21 begins performance database update processing, it acquires performance data from the action performance notification signal (B11, equivalent to the performance data acquisition step). When control unit 21 acquires the performance data, it updates the performance database stored in performance database storage unit 30 (B12, equivalent to the performance database update step), and ends the performance database update processing. That is, by updating the performance database, control unit 21 can keep the performance database up-to-date and provide vehicle system 3 with predictive information reflecting the latest performance database.

[0154] In detail, the control unit 21 identifies the software versions of functions that have established a correspondence with the confirmation results in the acquired performance data within the performance database as the update target areas. The control unit 21 increments the performance of the update target areas by "1" for the performance corresponding to the confirmation results included in the acquired performance data. Figure 7To explain, when the acquired performance data indicates that the confirmation result of "action already performed" has been established and a corresponding relationship has been established between the combination of software versions of function a, namely "Software B=SW_Ver.002, Software D=SW_Ver.002, Software D=SW_Ver.003", the control unit 21 determines the performance of "Software B=SW_Ver.002, Software D=SW_Ver.002, Software D=SW_Ver.003" of function a as the update target, and increments "action already performed" in the performance data from "1250" by "1", updating it to "1251".

[0155] Explanation of the performance database. In OTA Center 2, such as... Figure 14 As shown, the control unit 21 can also be connected to... Figure 7 Compared to the previous example, the combination of software versions that enable the function is further managed as performance data along with "manufacturer's prior action confirmation", "function generation", and "function version". Figure 14 The example provided illustrates a performance database for function a, for instance.

[0156] "Manufacturer Pre-Action Confirmation" indicates the confirmation status of pre-action confirmation performed by the manufacturer for the combination of software versions, indicating whether the pre-action confirmation has been completed and whether normal operation has been confirmed. For "Manufacturer Pre-Action Confirmation," Control Unit 21 registers "Unknown" before receiving notification of completion of pre-action confirmation from the manufacturer; upon receiving notification of completion, it registers "Completed" or "Not Completed." Control Unit 21 registers "Completed" if it is notified that pre-action confirmation of normal operation has been completed after pre-action confirmation by the manufacturer and normal operation has been confirmed; it registers "Not Completed" if pre-action confirmation by the manufacturer has been performed but normal operation has not been confirmed, and it is notified that pre-action confirmation of normal operation has not been confirmed. Furthermore, Control Unit 21 also registers "Not Completed" if, for example, the manufacturer is preparing for the completion of pre-action confirmation and has not confirmed normal operation, and it is notified by the manufacturer that pre-action confirmation has not been performed. Normal operation is, for example, an operation that ensures the safety of the vehicle while driving. Furthermore, manufacturers are not limited to companies that manufacture vehicles, but also include organizations and groups commissioned by such companies. A case where "Manufacturer's Pre-Action Confirmation" is registered as "Unknown" is, for example, in the third embodiment described later, where the combination of software versions in the action performance notification signal received from the vehicle system 3 is added to the performance database when that combination does not exist in the performance database.

[0157] "Functional Generation" refers to the generation corresponding to the representative software version within a combination of software versions. For example, if function a uses software B, D, and E, and the representative software is software D, then the combination of software versions of D with "Ver.001" represents the first generation, "Ver.002" represents the second generation, and "Ver.003" represents the third generation. As the representative software, for example, the software most relevant to function a is selected. Figure 14 The example above illustrates the case where software D is selected, but software B and software E can also be selected. The example above illustrates a "functional generation" that can be uniquely determined from a combination of software versions, but "functional generations" that cannot be uniquely determined from a combination of software versions can also be used.

[0158] "Feature version" refers to a string representing a combination of software versions of the software. For example, if the combination of software versions B, D, and E is "Ver.001", "Ver.001", and "Ver.001", then it would be "B001D001E001". The above examples illustrate "feature versions" that can be uniquely identified from the combination of software versions, but "feature versions" that cannot be uniquely identified from the combination of software versions can also be used.

[0159] The control unit 21 registers the generation corresponding to each software version combination in "Function Generation" and the string in "Function Version". That is, when the control unit 21 can determine the "Function Generation" and "Function Version" from the software version combination, it can register the corresponding generation in "Function Generation" and the string in "Function Version". On the other hand, when the control unit 21 cannot determine the "Function Generation" and "Function Version" from the software version combination, it can register the "Function Generation" and "Function Version" as "Unknown" and register the notified "Function Generation" and "Function Version" when the manufacturer notifies it of the combination's "Function Generation" and "Function Version". Furthermore, the control unit 21 can also omit the "Function Generation" and "Function Version" from the management objects in the performance database and not manage them.

[0160] In CGW5, control unit 6 can also be replaced. Figure 9 The function update query screen shown displays... Figure 15 The function update query screen shown is displayed. On this screen, the control unit 6 displays the message "Function updates available in your vehicle," shows a summary of the function for each generation of a specific feature, and displays "Confirm Details" buttons 121-122. In this case, the user can select the desired generation to update by operating one of the "Confirm Details" buttons 201-202.

[0161] As described above, according to the first embodiment, the following effects can be achieved. In the vehicle system 3, when the software is updated, a correlation is established between the confirmation result of the functional incompleteness related to the function implemented by the updated software and the software version of the software implementing that function, generating performance data. In the OTA center 2, referring to the performance database, prediction information that is predicted to occur with the scheduled software update is generated, and the generated prediction information is sent to the vehicle system 3. In the OTA center 2, when performance data is obtained from the vehicle system 3, the performance database is updated. In the vehicle system 3, the prediction information that is predicted to occur with the scheduled software update is displayed. Functional incompleteness that is anticipated due to an inappropriate combination of software versions can be appropriately addressed.

[0162] (Second Implementation)

[0163] Reference Figures 16 to 19 The second embodiment will be described. In the second embodiment, performance data is also generated based on confirmation results from user feedback regarding usability. In CGW5, the control unit 6, for example, displays the data after a predetermined period of time following a function update. Figure 16 The questionnaire input screen shown is as follows. The control unit 6 displays checkboxes for "Function N Good," "Function N Poor," and "No Answer" as part of a usability survey, and also displays a "Send Input Questionnaire Results" button 131 and a "Enter Later" button 132. Users can provide feedback on the updated software by entering information in a checkbox and pressing the "Send Input Questionnaire Results" button 131.

[0164] In this case, as performance data, such as Figure 17 As shown, for example, for function a, the correspondence between whether an action is performed is managed by a combination of software versions B, D, and E, and the information representing feedback is also managed. Figure 17 The example illustrates that for function a, in the combination of software versions "Ver.001", "Ver.001", and "Ver.001" for software B, D, and E, the "inactive" rating is high because "inactive" is much lower than "not inactive". Conversely, in the combination of software versions "Ver.002", "Ver.002", and "Ver.003" for software B, D, and E, the "inactive" rating is high because "inactive" is much higher than "not inactive". Furthermore, as performance data, such as... Figure 18 As shown, it is also possible to distinguish between feedback information indicating "action taken" and feedback information indicating "no action taken".

[0165] In CGW5, the control unit 6 is as follows: Figure 19 As shown, in the prediction information notification screen, and Figure 10 Compared to the predicted information notification screen shown, the system now displays "Customer satisfaction with feature a after feature a update", "Customer satisfaction with feature b after feature a update", and "Customer satisfaction with feature c after feature a update", showing the satisfaction of users who are updating features.

[0166] As described above, according to the second embodiment, the following effects can be achieved. It also includes confirmation results from user feedback regarding usability to generate performance data. It can also include usability information to appropriately address functional deficiencies envisioned due to inappropriate combinations of software versions.

[0167] (Third implementation method)

[0168] Reference Figures 20 to 24 The third implementation method will be described. The third implementation method manages the presence or absence of software action records. In OTA Center 2, as... Figure 20 As shown, the control unit 21 and Figure 14 Compared to the previous example, the software z that performs the function is further managed together with "performance record" as performance data. "Performance record" indicates whether there are any action performance records for a combination of software versions of that software. That is, if it is a combination of software versions that has received at least one action performance notification signal from the vehicle system 3, then "performance record" is "yes"; if it is a combination of software versions that has never received an action performance notification signal from the vehicle system 3, then "performance record" is "no". Figure 20 The example illustrates a combination of software B, D, and E with software versions "Ver.004", "Ver.004", and "Ver.003" where "Manufacturer's prior action confirmation" is "complete" and "No performance record" is "no". However, software combinations with "Manufacturer's prior action confirmation" being "unclear" or "not completed" can also be registered as having "No performance record". Furthermore, a software combination can be registered as having "No performance record" if "Manufacturer's prior action confirmation" is "complete".

[0169] OTA Center 2 performs performance database update processing as a central-side process.

[0170] (2-3) Performance Database Update Processing (Refer to) Figure 21 )

[0171] When the control unit 21 determines that it has received an action performance notification signal sent from the vehicle system 3, it begins the performance database update process. When the control unit 21 begins the performance database update process, it obtains performance data from the action performance notification signal (B21, equivalent to the performance data acquisition step). When the control unit 21 obtains the performance data, it determines the combination of software versions in the obtained performance data and determines whether the combination of software versions in the performance data exists in the performance database (B22).

[0172] 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 appends the combination of software versions in the performance data as performance data with "Yes" as the action performance (B23, equivalent to the performance database update step), increments one of the "acted" or "not acted" of the performance data by "1" (B24, equivalent to the performance database update step), and ends the performance database update process.

[0173] Specifically, such as Figure 20 As shown, when the control unit 21, in the state of managing the performance database, determines that the software versions of software B, D, and E are a combination of "Ver.002", "Ver.001", and "Ver.001" as a combination of software versions in the performance data, it determines that this combination of software versions does not exist in the performance database. Figure 22 As shown, the combination of software versions in the performance data is added as performance data with "existence" for the action performance. When the performance data is determined to be "action performed", "action performed" is incremented by "1". Figure 22 The example illustrates the case where the "action taken" value of the performance data is incremented by "1", but if the performance data is "no action taken", the "no action taken" value is incremented by "1". By determining that the combination of software versions in the performance data does not exist in the performance database, the manufacturer can confirm situations where actions were taken with unexpected combinations of software versions.

[0174] On the other hand, when the control unit 21 determines that the combination of software versions in the performance data exists in the performance database (B22: "Yes"), it determines whether there is an action performance record for that combination of software versions (B25). When the control unit 21 determines that the action performance record for that combination of software versions is "No" (B25: "No"), it changes the action performance record of the performance data from "No" to "Yes" (B26, equivalent to the performance database update step), increments one of the "acted" or "not acted" values ​​of the performance data by "1" (B27, equivalent to the performance database update step), and ends the performance database update process.

[0175] Specifically, such as Figure 20As shown, when the control unit 21, in the state of managing the performance database, determines that the software versions of software B, D, and E are a combination of "Ver.004", "Ver.004", and "Ver.003" from the combination of software versions in the performance data, it determines that the combination of software versions exists in the performance database, and determines that the action performance of the combination of software versions is "none". Figure 23 As shown, the action record of the actual performance data is changed from "none" to "yes". When the actual performance data is determined to be "already acted", the "already acted" status of the actual performance data is incremented by "1". Figure 23 The example shows the case where the actual data is "acted", and the "acted" value of the actual data is incremented by "1", but if the actual data is "not acted", the "not acted" value of the actual data is incremented by "1".

[0176] On the other hand, when the control unit 21 determines that the combined action record of the software version is "yes" (B25: "yes"), it increments one of the "action" or "no action" of the record data by "1" (B27) and ends the record database update process.

[0177] Specifically, such as Figure 20 As shown, when the control unit 21, in the state of managing the performance database, determines that the software versions of software B, D, and E are a combination of "Ver.003", "Ver.002", and "Ver.003" as a combination of software versions in the performance data, it determines that this combination of software versions exists in the performance database, and determines that the action performance of this combination of software versions is "existing". When the control unit 21 determines that the performance data is "already acted", as follows: Figure 24 As shown, add "1" to the "Action Completed" value of the actual performance data. Figure 24 The example shows the case where the actual data is "acted", and the "acted" value of the actual data is incremented by "1", but if the actual data is "not acted", the "not acted" value of the actual data is incremented by "1".

[0178] As described above, according to the third embodiment, in the OTA center 2, when performance data is obtained from the vehicle system 3, the performance database is updated. This performance data establishes a correspondence between the performance data of functions implemented by the updated software and the software version of the software implementing those functions. In the OTA center 2, the performance data of functions implemented by the updated software can be appropriately verified.

[0179] (Fourth Implementation)

[0180] Reference Figure 25 The fourth implementation method will be described. The fourth implementation method manages the action log. In the OTA center 2, as follows... Figure 25As shown, the control unit 21 collaborates with the action log database that stores action logs to manage the combination of software versions of the software that performs the function together with the action logs.

[0181] The action log contains logs indicating incomplete functionality related to the features implemented by the software. Logs indicating incomplete functionality include, for example, logs showing that the function itself is not functioning completely, or logs showing that the function as a whole is not functioning properly due to some malfunction.

[0182] In addition, the action log contains logs representing the action status of multiple processes that constitute a function. A process is not limited to a single version of software. For example, if the function has image display and sound output capabilities, the log representing the action status of multiple processes would be the log representing the action status of image display and sound output.

[0183] In addition, the action log includes logs that represent the action status of the function in sequence. These logs, representing the action status of the function in sequence, include logs indicating the start time of the function, the start-up process, the normal or abnormal start and termination of each process in the action sequence, and logs indicating the time of the start and termination.

[0184] Furthermore, the action log includes logs indicating the operational status of other functions associated with the function experiencing the malfunction. These logs, for example, indicate whether, at the time the malfunction occurred, a function using common software with the function experiencing the malfunction was operating or stopped.

[0185] OTA Center 2 performs performance database update processing as a central-side process.

[0186] (2-4) Performance Database Update Processing (Refer to) Figure 26 )

[0187] When the control unit 21 determines that it has received an action performance notification signal sent from the vehicle system 3, it begins the performance database update process. When the control unit 21 begins the performance database update process, it acquires performance data from the action performance notification signal (B31, equivalent to the performance data acquisition step). While acquiring the performance data, the control unit 21 acquires the action log from the acquired performance data (B32), updates the performance database stored in the performance database storage unit 30 (B33, equivalent to the performance database update step), and then ends the performance database update process.

[0188] As described above, according to the fourth embodiment, in the OTA center 2, when performance data is obtained from the vehicle system 3, the performance database is updated. This performance data establishes a correspondence between the action logs of functions implemented by the updated software and the software version of the software implementing those functions. In the OTA center 2, the action logs of functions implemented by the updated software can be appropriately verified. By parsing the action logs, it is possible to determine at what time an anomaly or malfunction occurred. Furthermore, by managing this information along with feedback, for example, if a "poor" rating is relatively high, it is possible to determine that the urgency of the anomaly or malfunction indicated by the action log is relatively high; conversely, if a "poor" rating is relatively low, it is possible to determine that the urgency of the anomaly or malfunction indicated by the action log is relatively low.

[0189] (Other implementation methods)

[0190] This disclosure is described according to embodiments, but it should be understood that this disclosure is not limited to these embodiments or structures. This disclosure also includes various modifications and variations within the same scope. Furthermore, various combinations, methods, and other combinations or methods that include only one element, more elements, or fewer elements on these basis also fall within the scope and spirit of this disclosure.

[0191] An example is given of using an OTA center as an external device for wireless reprogramming and wireless diagnostic services. However, as an external device, it can also be a wired tool that is wired to the CGW via the vehicle network and can be used for wired reprogramming.

[0192] This example illustrates how a performance database can be used to generate predictive information, but it can also be used for other purposes. For instance, it could be used to identify software malfunctions and the need for improvement.

[0193] In vehicle system 3, an example is shown where, when one of the multiple functions of the vehicle is updated, performance data is generated for that function and other functions affected by the update, and then sent to OTA center 2. However, it is also possible to generate performance data for each of the multiple functions and send it to OTA center 2. The multiple functions mentioned here include the updated function and other functions that use common software with that function. Even with such a structure, when a function is updated, performance data can be generated and sent to OTA center 2 at least for that function and other functions affected by the update.

[0194] In OTA Center 2, performance data for functions based on combinations of software versions first received from Vehicle System 3 can be filtered from performance data of multiple functions sent from Vehicle System 3, and this filtered performance data can be used to update the performance database. In OTA Center 2, for example, for combinations of software versions for each function, Vehicle Identification Number (VIN) can be used to filter whether performance data has been received from each vehicle. Even with this management and updating of the performance database, for each function, performance data for incomplete functionality in multiple vehicles based on each software version combination can be appropriately displayed.

[0195] Function update query screens, prediction information notification screens, and questionnaire input screens can be displayed on the in-vehicle display. For example, they can also be displayed on the portable information terminal or the like by connecting to the OTA center 2 via data communication.

[0196] In the vehicle system 3, update prevention protection can be set for each function. For example, update prevention protection can be set for functions specified by the user. Information related to the setting of update prevention protection can be stored, for example, in non-volatile memory. In the vehicle system 3, when displaying a function update query screen, if update prevention protection is set for a function with available updates, additional information indicating this can be displayed. In the vehicle system 3, when displaying a prediction information notification screen, if update prevention protection is set for other functions affected by updates to user-selected functions—that is, other functions whose software versions change due to updates to user-selected functions—additional information indicating this can be displayed. By setting update prevention protection for each function, for example, if a user does not want their favorite function to always be up-to-date but wants to continue using their familiar current function, update prevention protection can be set for their favorite function. For example, updates to other functions can prevent the software used by the favorite function from being updated, thus preventing changes in the usability of the favorite function.

[0197] In vehicle system 3, for example, for user-specified functions, a query can be made to OTA center 2 to determine if an available update exists for a combination of software versions with proven operational history or that have undergone prior manufacturer confirmation. A combination of software versions with proven operational history includes, for example, those... Figure 11 The combination of software versions determined to have sufficient action performance in step B4. This includes combinations of software versions that have completed prior action verification by the manufacturer, for example, in... Figure 14 The performance database records a combination of software versions that have completed manufacturer pre-action confirmation.

[0198] In vehicle system 3, when querying OTA center 2, the system can also notify OTA center 2 of a combination of user-specified functions and the current software version of those functions in the vehicle. OTA center 2 then determines from its performance database the combination of software versions that have a track record of actions performed on the queried function or have received prior confirmation from the manufacturer. It then notifies OTA center 2 of available updates for these identified software version combinations. These available updates can include upgrades to newer software version combinations or downgrades to older software version combinations.

[0199] In vehicle system 3, when a notification of an available update is received, it displays as follows: Figure 15 The function update query screen shown, as in subsequent processing, can also display a prediction information notification screen and generate performance data, similar to the implementation described above. This is because even when updating a function to a combination of software versions with performance records or that have completed pre-confirmation by the manufacturer, the update may still affect other functions. Furthermore, when updating a function to a combination of software versions that have completed pre-confirmation by the manufacturer, performance data may not be generated for that function, but performance data may be generated for other functions affected by the update. With this structure, for example, when a user's preferred function becomes incomplete during the process of updating various functions, the user's preferred function can be upgraded or downgraded to a combination of software versions with performance records or that have completed pre-confirmation by the manufacturer.

[0200] It can also have functions that are subject to regulatory requirements and are managed as RxSWIN (Rx Software Identification Number) separate from multiple functions that require software updates. When a user wishes to update a function managed by RxSWIN, other functions affected by the update, and those outside the scope of RxSWIN management, can also have a prediction information notification screen displayed and performance data generated, similar to the implementation described above. Furthermore, updates to functions outside the scope of RxSWIN management can be restricted so that the update does not result in the function of the RxSWIN management object changing to a software combination outside the certification scope. Such updates can also be notified from the OTA center 2 to the vehicle system 3 and displayed as available updates in the prediction information notification screen.

[0201] The control unit and method described in this disclosure can also be implemented using a dedicated computer, which is provided by comprising a processor and memory programmed to perform one or more functions embodied in a computer program. Alternatively, the control unit and method described in this disclosure can also be implemented using a dedicated computer, which is provided by comprising a processor composed of one or more dedicated hardware logic circuits. Alternatively, the control unit and method described in this disclosure can also be implemented using one or more dedicated computers, which are composed of a processor and memory programmed to perform one or more functions, and a processor composed of one or more hardware logic circuits. Furthermore, the computer program can also be stored as instructions executable by the computer in a computer-readable, non-transitory tangible recording medium.

[0202] In addition to the claims, this disclosure includes the following disclosure. [1]

[0204] A vehicle system (3) that achieves its functions through a combination of multiple software programs, the vehicle system (3) comprising:

[0205] The incomplete functionality verification unit (26), in response to a software update, verifies any incomplete functionality related to the functions implemented by the updated software; and

[0206] The performance data generation unit (28) establishes a correspondence between the confirmation result of the incomplete function confirmation unit and the software version of the software that implements the function, and generates performance data. [2]

[0208] According to the vehicle system described in [1], wherein,

[0209] It has a performance data transmission unit (29) that transmits the performance data generated by the performance data generation unit to an external device. [3]

[0211] According to the vehicle system described in [1] or [2], wherein,

[0212] In response to an update to the software used to implement the first function, the incomplete function confirmation unit confirms a state of incompleteness related to the first function, and also confirms a state of incompleteness related to a second function in which the combination of software versions changes due to the software update. [4]

[0214] The vehicle system according to any one of [1] to [3], wherein,

[0215] The incomplete functionality confirmation unit, in response to an update of the software used to implement the first function, confirms a state of incomplete functionality related to multiple functions, including the first function. [5]

[0217] The vehicle system according to any one of [1] to [4], wherein,

[0218] It includes a feedback confirmation unit (27) that, in response to a software update, confirms the status of user feedback regarding usability.

[0219] The performance data generation unit establishes a correspondence between the confirmation results of the incomplete function confirmation unit, the confirmation results of the feedback confirmation unit, and the software version of the software that implements the function, and generates the performance data. [6]

[0221] An external device (2) for managing software used to implement functions in a vehicle system, the external device (2) comprising:

[0222] The performance database storage unit (30) stores the performance data of multiple vehicles into a performance database, wherein the performance data represents the combination of software versions used to implement the functions of the vehicle system and the correspondence between the incomplete functions related to those functions.

[0223] The prediction information generation unit (33) generates prediction information based on the performance database in the event that the scheduled software update is performed; and

[0224] The prediction information sending unit (34) sends the prediction information generated by the prediction information generation unit to the vehicle system. [7]

[0226] According to the external vehicle device described in [6], wherein,

[0227] It has a total performance number derivation unit (31) that derives the total performance number from the performance database. [8]

[0229] According to the external vehicle device described in [6] or [7], wherein,

[0230] It has a performance ratio derivation unit (32) that derives the ratio of performance numbers without functional defects or with functional defects in the performance database. [9]

[0232] The vehicle exterior device according to any one of [6] to [8], wherein,

[0233] The prediction information generation unit generates information indicating that the functions implemented by the pre-updated software are operating normally, or information indicating that the functions implemented by the pre-updated software may be incomplete, as the prediction information.

[10]

[0235] The vehicle exterior device according to any one of [6] to [9], wherein,

[0236] The prediction information generation unit generates information indicating that a function implemented by a predetermined updated software may be incomplete, and information indicating that other software should be updated to avoid incomplete functionality, as the prediction information.

[11]

[0238] The vehicle exterior device according to any one of [6] to

[10] , wherein,

[0239] The prediction information generation unit generates information from user feedback regarding availability as the prediction information.

[12]

[0241] An external device (2) manages software used to implement functions in a vehicle system, the external device comprising:

[0242] The performance database storage unit (30) stores the performance data of multiple vehicles into a performance database, wherein the performance data represents the combination of software versions used to implement the functions of the vehicle system and the correspondence between the incomplete functions related to those functions.

[0243] The performance data acquisition unit (35) acquires performance data from the vehicle system, and establishes a correspondence between the performance data and the confirmation results of incomplete functions related to the functions implemented by the updated software, and the software version of the software implementing the function; and

[0244] The performance database update unit (36) updates the performance database when the performance data is obtained by the performance data acquisition unit.

[13]

[0246] According to the external vehicle device described in

[12] , wherein,

[0247] The performance database update unit updates the performance database based on performance data that has changed according to the combination of software versions.

[14]

[0249] According to the external vehicle device described in

[12] or

[13] , wherein,

[0250] The performance database storage unit stores performance data, including information indicating whether the combination of software versions has completed pre-action confirmation, as a performance database.

[15]

[0252] The vehicle exterior device according to any one of

[12] to

[14] , wherein,

[0253] The performance database storage unit stores the performance data of multiple vehicles into a performance database. The performance data represents a combination of software versions used to implement functions in the vehicle system, the status of incomplete functions related to those functions, and the correspondence of information from user feedback regarding availability.

[16]

[0255] A vehicle system (3) achieves its functions through a combination of multiple software programs, the vehicle system comprising:

[0256] The prediction information prompting unit (37) provides prediction information in the event that the scheduled software update is completed.

[17]

[0258] According to the vehicle system described in

[16] , wherein,

[0259] The prediction information prompting unit provides information indicating that the functions implemented by the scheduled software update are operating normally, or information indicating that the functions implemented by the scheduled software update may be incomplete.

[18]

[0261] According to the vehicle system described in

[16] or

[17] , wherein,

[0262] The prediction information prompts information indicating that a function implemented by a scheduled software update may be incomplete, and information prompting the updating of other software to avoid incomplete functionality, as the prediction information.

[19]

[0264] The vehicle system according to any one of

[16] to

[18] , wherein,

[0265] The prediction information prompt indicates that information about availability from user feedback is used as the prediction information.

[20]

[0267] A data communication system (1) includes a vehicle system (3) that performs functions through a combination of multiple software programs, and an external device (2) that manages the software used to perform functions in the vehicle system.

[0268] The vehicle system includes:

[0269] The incomplete functionality verification unit (26), in response to a software update, verifies any incomplete functionality related to the functions implemented by the updated software; and

[0270] The performance data generation unit (28) establishes a correspondence between the confirmation result of the incomplete function confirmation unit and the software version of the software that implements the function, and generates performance data.

[0271] The external device includes:

[0272] The performance database storage unit (30) stores the performance data of multiple vehicles into a performance database, wherein the performance data represents the combination of software versions used to implement the functions of the vehicle system and the correspondence between the incomplete functions related to those functions.

[0273] The prediction information generation unit (33) generates prediction information based on the performance database, which is predicted in conjunction with the software update scheduled for a later date; and

[0274] The prediction information sending unit (34) sends the prediction information generated by the prediction information generation unit to the vehicle system. [twenty one]

[0276] According to the data communication system described in

[20] , the external device comprises:

[0277] The performance data acquisition unit (35) acquires performance data from the vehicle system, and establishes a correspondence between the performance data and the confirmation results of incomplete functions related to the functions implemented by the updated software, and the software version of the software implementing the function; and

[0278] The performance database update unit (36) updates the performance database when the performance data is obtained by the performance data acquisition unit. [twenty two]

[0280] According to the data communication system described in

[20] or

[21] , wherein the vehicle system comprises:

[0281] The prediction information prompting unit (37) prompts the prediction information that is predicted when the software is updated along with the scheduled update. [twenty three]

[0283] An external device (2) manages software used to implement functions in a vehicle system, the external device comprising:

[0284] The performance database storage unit (30) stores the performance data of multiple vehicles into a performance database, wherein the performance data represents the correspondence between the combination of software versions used to implement the functions in the vehicle system and the performance data of the functions in the vehicle.

[0285] The performance data acquisition unit (35) acquires performance data from the vehicle system, which establishes a correspondence between the performance data of the functions implemented by the updated software and the software version of the software implementing those functions; and

[0286] The performance database update unit (36) updates the performance database when the performance data is obtained by the performance data acquisition unit. [twenty four]

[0288] According to the external vehicle device described in

[23] , wherein,

[0289] When the combination of software versions of the software in the performance data is not stored in the performance database storage unit, the performance database update unit adds and manages the combination of software versions of the software in the performance data.

[25]

[0291] According to the external vehicle device described in

[23] or

[24] , wherein,

[0292] The performance database storage unit establishes a correspondence between the performance of the actions and the confirmation status of the pre-action confirmation, and stores them as the performance database.

[26]

[0294] An external device (2) manages software used to implement functions in a vehicle system, the external device comprising:

[0295] The performance database storage unit (30) stores the performance data of multiple vehicles into a performance database, wherein the performance data represents the correspondence between the combination of software versions used to implement the functions in the vehicle system and the action log of the function in the vehicle.

[0296] The performance data acquisition unit (35) acquires performance data from the vehicle system, which establishes a correspondence between the action logs of the functions implemented by the updated software and the software version of the software implementing those functions; and

[0297] The performance database update unit (36) updates the performance database when the performance data is obtained by the performance data acquisition unit.

[27]

[0299] According to the external vehicle device described in

[26] , wherein,

[0300] The action log includes at least one of the following: a log indicating a functional incompleteness related to a function implemented by the software; a log indicating the action status of multiple processes constituting the function; a log indicating the action status of the function in chronological order; and a log indicating the action status of other functions associated with the functional incompleteness.

[28]

[0302] According to the external vehicle device described in

[26] or

[27] , wherein,

[0303] The performance database storage unit establishes a correspondence between the action logs and information from users indicating availability, and stores them as the performance database.

Claims

1. A vehicle system (3) that achieves its functions through a combination of multiple software programs, the vehicle system comprising: The incomplete functionality verification unit (26), in response to a software update, verifies any incomplete functionality related to the functions implemented by the updated software; and The performance data generation unit (28) establishes a correspondence between the confirmation result of the incomplete function confirmation unit and the software version of the software that implements the function, and generates performance data.

2. The vehicle system according to claim 1, wherein, It has a performance data transmission unit (29) that transmits the performance data generated by the performance data generation unit to an external device.

3. The vehicle system according to claim 1, wherein, In response to an update to the software used to implement the first function, the incomplete function confirmation unit confirms a state of incompleteness related to the first function, and also confirms a state of incompleteness related to a second function in which the combination of software versions changes due to the software update.

4. The vehicle system according to claim 1, wherein, The incomplete functionality confirmation unit, in response to an update of the software used to implement the first function, confirms a state of incomplete functionality related to multiple functions, including the first function.

5. The vehicle system according to claim 1, wherein, It includes a feedback confirmation unit (27) that, in response to a software update, confirms the status of user feedback regarding usability. The performance data generation unit establishes a correspondence between the confirmation results of the incomplete function confirmation unit, the confirmation results of the feedback confirmation unit, and the software version of the software that implements the function, and generates the performance data.

6. A data processing program for a vehicle system, which enables the control unit (6) of a vehicle system (3) that performs functions through a combination of multiple software programs to execute: The incomplete functionality verification step, in response to a software update, verifies any incomplete functionality related to the features implemented by the updated software; and The performance data generation step establishes a correspondence between the confirmation result of the incomplete function confirmation step and the software version of the software that implements the function, thereby generating performance data.

7. A data processing method for a vehicle system, wherein in a vehicle system (3) that performs functions through a combination of multiple software programs, the following is executed: The incomplete functionality verification step, in response to a software update, verifies any incomplete functionality related to the features implemented by the updated software; and The performance data generation step establishes a correspondence between the confirmation result of the incomplete function confirmation step and the software version of the software that implements the function, thereby generating performance data.

8. An external device (2) for managing software used to implement functions in a vehicle system, the external device comprising: The performance database storage unit (30) stores the performance data of multiple vehicles into a performance database, wherein the performance data represents the combination of software versions used to implement the functions of the vehicle system and the correspondence between the incomplete functions related to those functions. The prediction information generation unit (33) generates prediction information in the event that the scheduled software update is updated, referring to the performance database. as well as The prediction information sending unit (34) sends the prediction information generated by the prediction information generation unit to the vehicle system.

9. The external device according to claim 8, wherein, It has a total performance number derivation unit (31) that derives the total performance number from the performance database.

10. The external device according to claim 8, wherein, It has a performance ratio derivation unit (32) that derives the ratio of performance numbers without functional defects or with functional defects in the performance database.

11. The external device according to claim 8, wherein, The prediction information generation unit generates information indicating that the functions implemented by the pre-updated software are operating normally, or information indicating that the functions implemented by the pre-updated software may be incomplete, as the prediction information.

12. The external device according to claim 8, wherein, The prediction information generation unit generates information indicating that a function implemented by a predetermined updated software may be incomplete, and information indicating that other software should be updated to avoid incomplete functionality, as the prediction information.

13. The external vehicle device according to claim 8, wherein, The prediction information generation unit generates information from user feedback regarding availability as the prediction information.

14. A data processing program for an external vehicle device, wherein, The external device (2) manages the software used to implement the functions of the vehicle system and has a performance database storage unit (30). This performance database storage unit (30) stores the performance data of multiple vehicles into a performance database. The performance data represents the combination of software versions used to implement the functions of the vehicle system and the correspondence between the incomplete functions related to those functions. The data processing program of the external device causes the control unit (21) of the external device to execute: The prediction information generation step, referring to the performance database, generates prediction information that is predicted when the software is updated according to a predetermined schedule; and The prediction information sending step sends the prediction information generated through the prediction information generation step to the vehicle system.

15. A data processing method for an external vehicle device (2), wherein the external vehicle device (2) manages software used to implement functions in a vehicle system and has a performance database storage unit (30), the performance database storage unit (30) storing performance data of multiple vehicles into a performance database, the performance data representing a combination of software versions used to implement functions in the vehicle system and a correspondence between the incompleteness of functions related to those functions, wherein the external vehicle device performs the following: The prediction information generation step, referring to the performance database, generates prediction information that is predicted when the software is updated according to a predetermined schedule; and The prediction information sending step sends the prediction information generated by the prediction information generation step to the vehicle system.

16. An external device (2) for managing software used to implement functions in a vehicle system, the external device comprising: The performance database storage unit (30) stores the performance data of multiple vehicles into a performance database, wherein the performance data represents the combination of software versions used to implement the functions of the vehicle system and the correspondence between the incomplete functions related to those functions. The performance data acquisition unit (35) acquires performance data from the vehicle system, and establishes a correspondence between the performance data and the confirmation results of incomplete functions related to the functions implemented by the updated software, and the software version of the software implementing the function; and The performance database update unit (36) updates the performance database when the performance data is obtained by the performance data acquisition unit.

17. The external device according to claim 16, wherein, The performance database update unit updates the performance database based on performance data that has changed according to the combination of software versions.

18. The external device according to claim 16, wherein, The performance database storage unit contains information indicating whether the combination of software versions has completed the pre-action confirmation, and stores the performance data as a performance database.

19. The external device according to claim 16, wherein, The performance database storage unit stores the performance data of multiple vehicles into a performance database. The performance data represents a combination of software versions used to implement functions in the vehicle system, the status of incomplete functions related to those functions, and the correspondence of information from user feedback regarding availability.

20. A data processing program for an external vehicle device, wherein, The external device (2) manages the software used to implement the functions of the vehicle system and has a performance database storage unit (30). This performance database storage unit (30) stores the performance data of multiple vehicles into a performance database. The performance data represents the combination of software versions used to implement the functions of the vehicle system and the correspondence between the incomplete functions related to those functions. The data processing program of the external device causes the control unit (21) of the external device to execute: The performance data acquisition step involves acquiring performance data from the vehicle system. This performance data will establish a correspondence between the confirmation results of incomplete functions related to the functions implemented by the updated software and the software version of the software that implements the function. as well as The performance database update step involves updating the performance database after obtaining the performance data through the performance data acquisition step.

21. A data processing method for an external vehicle device (2), wherein the external vehicle device (2) manages software used to implement functions in a vehicle system and has a performance database storage unit (30), the performance database storage unit (30) storing performance data of multiple vehicles into a performance database, the performance data representing a combination of software versions used to implement functions in the vehicle system and a correspondence between the incompleteness of functions related to those functions, wherein the external vehicle device performs the following: The performance data acquisition step involves acquiring performance data from the vehicle system. This performance data will be correlated with the confirmation results of functional deficiencies related to the functions implemented by the updated software, and with the software version of the software implementing that function. The performance database update step involves updating the performance database after obtaining the performance data through the performance data acquisition step.

22. A vehicle system (3) that achieves its functions through a combination of multiple software programs, the vehicle system comprising: The prediction information prompting unit (37) provides prediction information in the event that the scheduled software update is completed.

23. The vehicle system according to claim 22, wherein, The prediction information prompting unit provides information indicating that the functions implemented by the scheduled software update are operating normally, or information indicating that the functions implemented by the scheduled software update may be incomplete, as the prediction information.

24. The vehicle system according to claim 22, wherein, The prediction information prompting unit provides information indicating that the functions implemented by the scheduled software update may be incomplete, as well as information prompting the updating of other software to avoid incomplete functions, as the prediction information.

25. The vehicle system according to claim 22, wherein, The prediction information prompt indicates that information about availability from user feedback is used as the prediction information.

26. A data processing program for a vehicle system, which causes the control unit (6) of a vehicle system (3) that performs functions through a combination of multiple software programs to execute: The prediction information prompts the steps, indicating the predicted information in the event that the scheduled software update has been completed.

27. A data processing method for a vehicle system, wherein in a vehicle system (3) that performs functions through a combination of multiple software programs, the following is executed: The prediction information prompt step indicates the prediction information that will be predicted when the software is updated as scheduled.

28. A data communication system (1) comprising a vehicle system (3) that performs functions through a combination of multiple software programs, and an external device (2) for managing the software used to perform functions in the vehicle system. The vehicle system includes: The incomplete function verification unit (26) verifies, in response to a software update, the incomplete function status related to the functions implemented by the updated software; as well as The performance data generation unit (28) establishes a correspondence between the confirmation result of the incomplete function confirmation unit and the software version of the software that implements the function, and generates performance data. The external device includes: The performance database storage unit (30) stores the performance data of multiple vehicles into a performance database, wherein the performance data represents the combination of software versions used to implement the functions of the vehicle system and the correspondence between the incomplete functions related to those functions. The prediction information generation unit (33) generates prediction information that is predicted when the software is updated along with the scheduled update, referring to the actual performance database; as well as The prediction information sending unit (34) sends the prediction information generated by the prediction information generation unit to the vehicle system.

29. The data communication system according to claim 28, wherein, The external device includes: The performance data acquisition unit (35) acquires performance data from the vehicle system, and establishes a correspondence between the performance data and the confirmation results of the incomplete function situation related to the function implemented by the updated software, and the software version of the software that implements the function. as well as The performance database update unit (36) updates the performance database when the performance data is obtained by the performance data acquisition unit.

30. The data communication system according to claim 28, wherein, The vehicle system includes: The prediction information prompting unit (37) prompts the prediction information that is predicted when the software is updated along with the scheduled update.

31. An external device (2) for managing software used to implement functions in a vehicle system, the external device comprising: The performance database storage unit (30) stores the performance data of multiple vehicles into a performance database, wherein the performance data represents the correspondence between the combination of software versions used to implement the functions in the vehicle system and the performance data of the functions in the vehicle. The performance data acquisition unit (35) acquires performance data from the vehicle system, which establishes a correspondence between the performance data of the functions implemented by the updated software and the software version of the software implementing those functions; and The performance database update unit (36) updates the performance database when the performance data is obtained by the performance data acquisition unit.

32. The external device according to claim 31, wherein, When the combination of software versions of the software in the performance data is not stored in the performance database storage unit, the performance database update unit adds and manages the combination of software versions of the software in the performance data.

33. The external device according to claim 31, wherein, The performance database storage unit establishes a correspondence between the performance of the actions and the confirmation status of the pre-action confirmation, and stores them as the performance database.

34. A data processing program for an external vehicle device, wherein, The external device (2) manages the software used to implement the functions of the vehicle system and has a performance database storage unit (30) that stores performance data of multiple vehicles in a performance database. The performance data represents the correspondence between the combination of software versions used to implement the functions of the vehicle system and the performance data of the functions in the vehicle. The data processing program of the external device causes the control unit (21) of the external device to execute: The performance data acquisition step involves acquiring performance data from the vehicle system. This performance data establishes a correspondence between the action performance of the functions implemented by the updated software and the software version of the software that implements the functions. as well as The performance database update step involves updating the performance database after obtaining the performance data through the performance data acquisition step.

35. A data processing method for an external vehicle device (2), wherein the external vehicle device (2) manages software used to implement functions in a vehicle system and has a performance database storage unit (30), the performance database storage unit (30) storing performance data of multiple vehicles into a performance database, the performance data representing the correspondence between a combination of software versions used to implement functions in the vehicle system and the performance data of the functions in the vehicle, wherein the external vehicle device executes: The performance data acquisition step involves acquiring performance data from the vehicle system. This performance data establishes a correspondence between the action performance of the functions implemented by the updated software and the software version of the software implementing those functions; and The performance database update step involves updating the performance database after obtaining the performance data through the performance data acquisition step.

36. An external device (2) for managing software used to implement functions in a vehicle system, the external device comprising: The performance database storage unit (30) stores the performance data of multiple vehicles into a performance database, wherein the performance data represents the correspondence between the combination of software versions used to implement the functions in the vehicle system and the action log of the function in the vehicle. The performance data acquisition unit (35) acquires performance data from the vehicle system, which establishes a correspondence between the action logs of functions implemented by the updated software and the software version of the software implementing those functions; and The performance database update unit (36) updates the performance database when the performance data is obtained by the performance data acquisition unit.

37. The external vehicle device according to claim 31, wherein, The action log includes at least one of the following: a log indicating a functional incompleteness related to a function implemented by the software; a log indicating the action status of multiple processes constituting the function; a log indicating the action status of the function in chronological order; and a log indicating the action status of other functions associated with the functional incompleteness.

38. The external vehicle device according to claim 31, wherein, The performance database storage unit establishes a correspondence between the action logs and information from users indicating availability, and stores them as the performance database.

39. A data processing program for an external vehicle device, wherein, The external device (2) manages the software used to implement the functions of the vehicle system and has a performance database storage unit (30) that stores performance data of multiple vehicles in a performance database. The performance data represents the correspondence between the combination of software versions used to implement the functions of the vehicle system and the action log of the function in the vehicle. The data processing program of the external device causes the control unit (21) of the external device to execute: The performance data acquisition step involves acquiring performance data from the vehicle system. This performance data establishes a correspondence between the action logs of the functions implemented by the updated software and the software version of the software that implements those functions. as well as The performance database update step involves updating the performance database after obtaining the performance data through the performance data acquisition step.

40. A data processing method for an external vehicle device (2), wherein the external vehicle device (2) manages software used to implement functions in a vehicle system and has a performance database storage unit (30), the performance database storage unit (30) storing performance data of multiple vehicles into a performance database, the performance data representing the correspondence between a combination of software versions used to implement functions in the vehicle system and the action log of that function in the vehicle, wherein the external vehicle device executes: The performance data acquisition step involves obtaining performance data from the vehicle's system. This performance data establishes a correspondence between the action logs of the functions implemented by the updated software and the software version of the software implementing those functions; and The performance database update step involves updating the performance database after obtaining the performance data through the performance data acquisition step.

Images