Center, update control method, non-transient storage medium, OTA manager

Abstract

The present invention relates to a center, an update control method, a non-transitory storage medium, an OTA manager, and a software update system. The center is configured to communicate with the OTA manager and a fault management server and has a processor. The fault management server is configured to store fault occurrence information. The processor is configured to receive the fault occurrence information from the fault management server and receive an inquiry from the OTA manager regarding whether the software of the electronic control device has been updated. Upon receiving the inquiry, the processor is configured to determine whether the sender of the inquiry, i.e., the vehicle, is in a fault state based on the fault occurrence information. The processor is configured to restrict the execution of the update process of the software involved in the sender of the inquiry, i.e., the vehicle, when it is determined that the sender of the inquiry, i.e., the vehicle, is in a fault state.

Description

Technical Field

[0001] The present disclosure relates to a center, an update control method, a non-transitory storage medium, an OTA manager, and a software update system utilized in an OTA service. Background Art

[0002] The vehicle is equipped with multiple electronic control units (called "ECUs") for performing control functions. The electronic control unit includes a processor and a storage unit. The control functions of the electronic control unit are realized by the processor executing the software stored in the storage unit. In addition, the software stored in each electronic control unit can be updated. Specifically, the software can be updated in a repair shop, etc. using an external device connected via a diagnostic connector provided on the vehicle. In addition, it is also possible to wirelessly connect the communication equipment possessed by the vehicle network to a communication network such as the Internet, and update the software downloaded from a distribution server provided in an update center by means of wireless communication (for example, Japanese Patent Laid-Open No. 2020-004245). This update service by means of wireless communication is called an OTA service.

[0003] In the above-mentioned OTA service, there is a concern that the software may be updated even though the vehicle is in a faulty state (faulty state). If the software is updated on a vehicle in a faulty state, there is a possibility that the update will not be properly implemented. It is preferable not to update the software when the vehicle is in a faulty state. Here, in the execution of the software update based on the OTA service, when the vehicle and the center establish a connection, the connection is always initiated from the vehicle side, that is, it is designed to be triggered by the vehicle side to start the connection. Therefore, as long as there is no action from the vehicle, the connection with the vehicle cannot be established, and the center cannot understand the faulty state of the vehicle.

[0004] Considering the above, it's also possible to have the center request fault information from the vehicle each time a software update is performed after the connection is established. However, this scenario increases the amount of communication between the center and the vehicle, resulting in increased communication costs.

[0005] When a vehicle malfunctions, the vehicle typically transmits this information to a fault management server. This fault management system, which monitors and manages the vehicle's fault status (in near real time), includes a fault management server. Assuming, as described above, that the center requests fault information from the vehicle each time for a software update, from the vehicle's perspective, the information already reported to the fault management server is retransmitted to the center, resulting in a double transmission burden. Therefore, from this perspective, it can be said that this incurs additional communication costs. Summary of the Invention

[0006] The present disclosure provides a control center, an update control method, a non-transitory storage medium, an OTA manager, and a software update system that can implement software updates corresponding to a vehicle fault state without inquiring about fault information from the vehicle.

[0007] A first embodiment of the disclosed technology is a center configured to communicate with an OTA manager and a fault management server via a network. The OTA manager is mounted on a vehicle. The fault management server is configured to store fault occurrence information. The fault occurrence information is information that associates a fault information code transmitted from a vehicle experiencing a fault with information identifying the vehicle experiencing the fault. The center includes a processor. The processor is configured to receive the fault occurrence information transmitted from the fault management server. The processor is configured to store the fault occurrence information received from the fault management server. The processor is configured to receive an inquiry from the OTA manager regarding the availability of software updates for electronic control devices. Upon receiving the inquiry, the processor is configured to determine, based on the fault occurrence information, whether the vehicle sending the inquiry is in a faulty state. If the processor determines that the vehicle sending the inquiry is in a faulty state, the processor is configured to restrict execution of software updates related to the vehicle sending the inquiry.

[0008] In the center according to the first aspect of the disclosed technology, the processor may be configured to send information indicating that the vehicle has broken down to the vehicle sending the inquiry when the processor determines that the vehicle sending the inquiry has broken down.

[0009] In the center according to the first aspect of the presently disclosed technology, the fault management server is configured to transmit the fault occurrence information to the center when new fault occurrence information is registered in the fault management server.

[0010] The second aspect of the disclosed technology is an update control method executed by a central computer having a processor, a memory, and a communication device. The communication device is configured to communicate with an OTA manager and a fault management server via a network. The OTA manager is mounted on a vehicle. The fault management server is configured to store fault occurrence information. The fault occurrence information is information in which a fault information code sent from a vehicle that has failed is associated with information identifying the vehicle that has failed. The method comprises: receiving the fault occurrence information sent from the fault management server; storing the fault occurrence information received from the fault management server; receiving an inquiry from the OTA manager regarding whether the software of the electronic control device has been updated; upon receiving the inquiry, determining whether the sender of the inquiry, i.e., the vehicle, is in a fault state based on the fault occurrence information; and if it is determined that the vehicle that has failed is in a fault state, restricting the execution of the software update process involving the vehicle that has failed.

[0011] A third aspect of the disclosed technology is a non-transitory storage medium storing instructions executable by a central computer equipped with a processor, memory, and a communication device, causing the computer to perform the following functions. The communication device is configured to communicate with an OTA manager and a fault management server via a network. The OTA manager is mounted on a vehicle. The fault management server is configured to store fault occurrence information. The fault occurrence information is information that associates a fault information code transmitted from a vehicle experiencing a fault with information identifying the vehicle experiencing the fault. The functions include: receiving the fault occurrence information transmitted from the fault management server; storing the fault occurrence information received from the fault management server; receiving an inquiry from the OTA manager regarding the availability of software updates for electronic control devices; upon receiving the inquiry, determining whether the vehicle sending the inquiry is in a faulty state based on the fault occurrence information; and, if the vehicle sending the inquiry is determined to be in a faulty state, restricting execution of the software update process for the vehicle sending the inquiry.

[0012] A fourth embodiment of the disclosed technology is an OTA manager mounted on a vehicle. The OTA manager includes a processor. The processor is configured to be connected to an in-vehicle network including a plurality of electronic control devices. The processor is configured to communicate with a center via a network. The processor is configured to update the software of at least one of the electronic control devices. The processor is configured to send an inquiry to the center regarding whether there is an update for the software of the at least one electronic control device. The processor is configured to, upon receiving information indicating that a fault has occurred in the vehicle from the center in response to the inquiry, notify the user of prescribed information related to the fault.

[0013] A fifth aspect of the disclosed technology is a software update system. The software update system comprises: a vehicle having an OTA manager, a fault management server, and a center. The vehicle is configured to detect a fault occurring in the vehicle. The vehicle is configured to send fault occurrence information to the fault management server. The fault occurrence information includes information identifying the vehicle and a fault information code related to the fault. The fault management server is configured to communicate with the OTA manager and the center via a network. The fault management server is configured to receive the fault occurrence information sent from the vehicle. The fault management server is configured to send the fault occurrence information to the center. The center is configured to communicate with the OTA manager and the fault management server via a network. The center is configured to store the fault occurrence information sent from the fault management server. The center is configured to receive an inquiry from the OTA manager regarding the presence or absence of a software update. Upon receiving the inquiry, the center is configured to determine whether the vehicle to which the inquiry relates is in a fault state based on the stored fault occurrence information. The center is configured to restrict execution of a software update process for the vehicle that has received the inquiry, when it is determined that a malfunction has occurred in the vehicle that has received the inquiry.

[0014] According to the core, update control method, non-transitory storage medium, OTA manager, and software update system of the present disclosure, software update control corresponding to the vehicle fault state can be implemented without inquiring about fault information from the vehicle for software update. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Hereinafter, features, advantages, technical and industrial significance of exemplary embodiments of the present invention will be described with reference to the accompanying drawings, in which like reference numerals represent like elements, and in which:

[0016] Figure 1 It is a block diagram showing the overall configuration of the system according to this embodiment.

[0017] Figure 2It is a block diagram showing a schematic structure of the center 1.

[0018] Figure 3 It is a block diagram showing a schematic configuration of the fault management server 2 .

[0019] Figure 4 It is a block diagram showing a schematic structure of the OTA manager 31 .

[0020] Figure 5 This is the functional block diagram of center 1.

[0021] Figure 6 This is a functional block diagram of the fault management server 2.

[0022] Figure 7 FIG. 4 is a functional block diagram of the OTA manager 31 .

[0023] Figure 8 It is a memory map showing an example of data stored in the storage unit 26 of the fault management server 2 .

[0024] Figure 9 This is an example of the data structure of the fault condition data 52 .

[0025] Figure 10 This is a memory map showing an example of data stored in the storage unit 16 of the center 1 .

[0026] Figure 11 This is an example of the data structure of the fault condition data 62 .

[0027] Figure 12 This is a flowchart showing the details of the failure information management process.

[0028] Figure 13 This is a flowchart showing the details of the failure information update process.

[0029] Figure 14 This is a flowchart showing the details of the update control process.

[0030] Figure 15 This is a flowchart showing the details of the software update process. DETAILED DESCRIPTION

[0031] Hereinafter, one embodiment will be described in detail with reference to the drawings.

[0032] Regarding the overall system configuration of this embodiment

[0033] Figure 1 1 is a block diagram showing the overall configuration of an update management system in this embodiment. The update management system includes an OTA center (hereinafter referred to as simply a center) 1 , a fault management server 2 , and a vehicle 3 .

[0034] The center 1 is a server for managing software updates of onboard devices in the vehicle 3 (more precisely, the center 1 is a center system including such a server, but for ease of explanation, it is referred to as a server below). The center 1 can communicate with the fault management server 2 and the vehicle 3 .

[0035] The fault management server 2 is a server for managing the fault status of vehicle 3. When a fault is detected in vehicle 3, fault information including a fault code indicating the fault is transmitted from vehicle 3 to the fault management server 2. This fault information is stored in the fault management server 2. Therefore, if a fault occurs in vehicle 3, the fault management server 2 can understand the fault in vehicle 3 (approximately in real time). Furthermore, upon receiving fault information from vehicle 3, the fault management server 2 transmits this information to the center 1. In this embodiment, the fault management server 2 transmits the fault information received from vehicle 3 to the center 1 unchanged. However, in other embodiments, the fault management server 2 may transmit processed data of the fault information received from vehicle 3 to the center 1. Furthermore, upon receiving a fault resolution notification from vehicle 3 indicating that the fault in vehicle 3 has been resolved, the fault management server 2 updates the data related to vehicle 3 stored in the fault management server 2 to indicate that the fault has not occurred, based on the fault resolution notification. Furthermore, the fault management server 2 transmits the fault resolution notification to the center 1 .

[0036] Vehicle 3 is equipped with an in-vehicle network system. This in-vehicle network system is capable of communicating with the center 1 and the fault management server 2. The in-vehicle network system comprises at least an OTA manager (software update device) 31, a communication module 32, and multiple electronic control units 33a through 33d. In addition, the electronic control unit 33a has the function of transmitting fault information to the fault management server 2 when a fault occurs in vehicle 3. Hereinafter, this electronic control unit 33a will be specifically referred to as the fault management control unit 33a.

[0037] The OTA manager 31 is connected to the communication module 32, the fault management control unit 33a, and other electronic control units 33b-33d via a bus 35. The OTA manager 31 is capable of wireless communication with the center 1 via the communication module 32. The OTA manager 31 exchanges specified data with the center 1 and controls the software update process for each electronic control unit 33. In other words, the OTA manager 31 has a software update function. The communication module 32 is a communication device connected to a specified network (such as a telephone network or the Internet).

[0038] The fault management control device 33a can realize wireless communication with the fault management server 2 via the communication module 32. The fault management control device 33a detects that a fault has occurred in the vehicle 3, generates information related to the fault, that is, fault occurrence information, and sends the fault occurrence information to the fault management server 2. For example, the fault can be detected based on whether a fault code is output to the fault management control device 33a from an on-board diagnostic device (not shown). In addition, the fault occurrence information includes at least a vehicle identification number for identifying the vehicle 3 and the above-mentioned fault code. In addition, in the case where the fault generated in the vehicle 3 is eliminated, the fault management control device 33a detects that the fault has been eliminated and sends a fault elimination notification to the fault management server 2 to indicate that the fault has been eliminated. The fault elimination notification includes the vehicle identification number and data indicating that the fault has been eliminated.

[0039] In addition, other electronic control devices 33b to 33d control the operation of each part of the vehicle 3. Figure 1 The number of electronic control devices 33 in FIG. 3 is an example.

[0040] About the structure of Center 1

[0041] Figure 2 : is a block diagram showing a brief structure of the center 1. Figure 2 As shown, the center 1 includes a processor 11, RAM 12, a storage device 13, and a communication device 14. The storage device 13 comprises a readable and writable storage medium such as a hard disk or SSD, and stores various programs and data required for the processing involved in this embodiment. In the center 1, the processor 11 executes the program read from the storage device 13 using the RAM 12 as a work area, thereby performing the prescribed control processing. The communication device 14 is a device that communicates with the fault management server 2 and the vehicle 3 via a network.

[0042] Regarding the structure of the fault management server 2

[0043] Figure 3 2 is a block diagram showing a brief structure of the fault management server 2. Figure 3 As shown, the fault management server 2 includes a processor 21, RAM 22, a storage device 23, and a communication device 24. The storage device 23 includes a readable and writable storage medium such as a hard disk or SSD. The storage device 23 stores various programs and data required for the processing involved in this embodiment. The processor 21 executes the programs read from the storage device 23 using the RAM 22 as a work area, thereby performing the specified control processing. The communication device 24 communicates with the center 1 and the vehicle 3 via a network.

[0044] About the structure of OTA manager 31

[0045] Figure 4 3 is a block diagram showing a brief structure of the OTA manager 31. Figure 4 As shown, the OTA manager 31 includes a microcomputer 45 and a communication device 46. The microcomputer 45 includes a processor 41, RAM 42, ROM 43, and a storage device 44. In the OTA manager 31, the processor 41 of the microcomputer 45 executes a program read from the ROM 43 using the RAM 42 as a work area, thereby performing a predetermined control process. The communication device 46 is connected to the microcomputer 45 via the microcomputer 45. Figure 1 The bus 35 shown communicates with the communication module 32 and the electronic control units 33 a to 33 d.

[0046] Functional block diagram of center 1

[0047] Figure 5 This is a functional block diagram of the center 1.

[0048] The center 1 includes a storage unit 16, a communication unit 17, and a control unit 18. The communication unit 17 and the control unit 18 are connected by Figure 2 The processor 11 shown is implemented by executing a program stored in the storage device 13 using the RAM 12. The storage unit 16 is composed of Figure 2 The storage device 13 shown is implemented.

[0049] The storage unit 16 stores programs and data used in the processing according to the present embodiment.

[0050] The communication unit 17 can receive the aforementioned fault occurrence information and the aforementioned fault resolution notification from the fault management server 2. Furthermore, the communication unit 17 can receive data inquiring about the availability of a software update (hereinafter referred to as an "update inquiry") from the OTA manager 31. Furthermore, the communication unit 17 can also exchange predetermined data with the OTA manager 31 for executing software update processing.

[0051] Based on the failure information received by the communication unit 17, the control unit 18 stores data indicating the failure status of the vehicle 3 in the storage unit 16. Furthermore, upon receiving an update inquiry from the OTA manager 31, the control unit 18 determines whether the vehicle 3 is in a failure state. Furthermore, if the vehicle 3 that issued the update inquiry is in a failure state, the control unit 18 controls the update process to not start (restricts the start of the update process) even if a software update to be distributed exists. Furthermore, as long as no update inquiry is received from the OTA manager 31, the control unit 18 does not start the software update process (i.e., the center 1 does not proactively start the software update process).

[0052] Functional block diagram of fault management server 2

[0053] Figure 6 This is a functional block diagram of the fault management server 2.

[0054] The fault management server 2 includes a storage unit 26, a communication unit 27, and a control unit 28. The communication unit 27 and the control unit 28 are connected by Figure 3 The processor 21 shown is implemented by executing a program stored in the storage device 23 using the RAM 22. The storage unit 26 is composed of Figure 3 The storage device 23 shown is implemented.

[0055] The storage unit 26 stores programs and data used in the processing according to the present embodiment.

[0056] The communication unit 27 can receive the fault occurrence information from the vehicle 3 (fault management control device 33a) that has detected the fault, and can transmit the fault occurrence information and the fault resolution notification regarding the vehicle 3 in which the fault has occurred to the center 1.

[0057] Upon receiving the aforementioned fault occurrence information from the fault management control device 33a, the control unit 28 stores data indicating the fault status based on the fault occurrence information in the storage unit 26. Furthermore, the control unit 28 transmits the fault occurrence information regarding the vehicle 3 in which the fault occurred to the center 1 via the communication unit 27. Furthermore, upon receiving the aforementioned fault resolution notification, the control unit 28 updates the data indicating the fault status based on the fault resolution notification and transmits the fault resolution notification to the center 1.

[0058] Functional block diagram of OTA manager 31

[0059] Figure 7 yes Figure 4 The functional block diagram of the OTA manager 31 is shown.

[0060] The OTA manager 31 includes a storage unit 47, a communication unit 48, and a control unit 49. The storage unit 47 is composed of Figure 4 The communication unit 48 and the control unit 49 are implemented by the storage device 44 shown in FIG. Figure 4 The processor 41 shown is implemented by executing a program stored in the ROM 43 using the RAM 42 .

[0061] The storage unit 47 stores various programs and various data for executing the software update process.

[0062] When a fault is detected, the communication unit 48 can transmit the fault occurrence information to the fault management server 2 based on a command from the fault management control device 33a. In addition, the communication unit 48 can also transmit and receive various data required for software update processing, such as the above-mentioned update inquiry, to the center 1 based on a command from the control unit 49.

[0063] The control unit 49 performs various controls related to the software update process. Specifically, the control unit 49 periodically uses the communication unit 48 to transmit the aforementioned update query to the center 1. If, in response to the update query, data for the software update is distributed from the center 1, the control unit 49 executes the software update process based on the distributed data. Here, we will provide additional information regarding the timing of these update queries. In this embodiment, as an example, a scenario is assumed where update queries are sent to the center 1 once every two weeks. This frequency is based on the desire to minimize the necessary confirmation frequency, given that increasing the frequency of confirming whether an update has been performed would increase communication between the vehicle 3 and the center 1 and increase communication costs.

[0064] Hereinafter, the details of the processing according to this embodiment will be described.

[0065] About data used by the fault management server 2

[0066] First, data used in the processing of this embodiment will be described. Figure 8 2 is a memory map showing an example of data stored in the storage unit 26 of the fault management server 2. The storage unit 26 stores a fault management program 51 and fault condition data 52.

[0067] The fault management program 51 is a program for executing a process of updating the fault condition data 52 based on the fault occurrence information transmitted from the vehicle 3 and a process of transmitting the fault occurrence information to the center 1 .

[0068] The fault condition data 52 indicates the fault state of the vehicle 3 . Figure 9 This is an example of the data structure of the fault condition data 52. The fault condition data 52 is a table-like data having at least a vehicle identification number 53, a fault status 54, and a fault log 55. The vehicle identification number 53 is a number used to uniquely identify each vehicle. The fault status 54 is data indicating whether the vehicle 3 is in a fault state. In this embodiment, when the vehicle 3 is in a fault state, the fault status 54 is set to data indicating "faulty", and when the vehicle 3 is not in a fault state, the fault status 54 is set to data indicating "normal". The fault log 55 is a log that records the above-mentioned fault codes transmitted from the vehicle 3.

[0069] About the data used in Center 1

[0070] Next, data used in the processing of the center 1 will be described. Figure 10 1 is a memory map showing an example of data stored in the storage unit 16 of the center 1. The storage unit 16 stores an update control program 61 and fault condition data 62. Although not shown in the figure, the storage unit 16 also stores various other programs and data for implementing OTA services.

[0071] The update control program 61 is a program for controlling the above-mentioned software update process.

[0072] The failure status data 62 is used to determine whether the vehicle 3 is in a failure state. Figure 11 This is an example of the data structure of the fault condition data 62. The fault condition data 62 is a table-like data structure containing the following items: a vehicle identification number 63, a fault status 64, and a fault log 65. The vehicle identification number 63, like the vehicle identification number in the fault condition data 52 in the fault management server 2, is a number used to uniquely identify each vehicle. The fault status 64, like the fault status in the fault management server 2, indicates whether the vehicle 3 is in a fault state. The fault log 65 is a log of the fault codes.

[0073] Furthermore, this embodiment illustrates a configuration in which the fault log 65 is stored in the center 1. In other embodiments, the fault log 65 may not be stored in the center 1. In this case, for example, the fault management server 2 may simply transmit only the vehicle identification number 53 as the aforementioned fault occurrence information. Storing the fault log 65 in the center 1 allows the center 1 to obtain more detailed information regarding vehicle faults. Not storing the fault log 65 in the center 1 reduces the amount of communication between the fault management server 2 and the center 1.

[0074] Regarding the processing executed by the fault management server 2

[0075] Next, the details of the processing executed by the fault management server 2 will be described. Figure 12 2 is a flowchart showing details of the fault information management process executed by the control unit 28 of the fault management server 2. This process is for registering the fault occurrence information transmitted from the vehicle 3 in the fault status data 52 and updating the content thereof.

[0076] First, in step S1, the control unit 28 determines whether or not it has received failure occurrence information transmitted from a predetermined vehicle 3. If the result of this determination is that the failure occurrence information has not been received, the process proceeds to step S4 described later.

[0077] On the other hand, if fault information is received, the control unit 28 then updates the fault status data 52 based on the received fault information in step S2 (or, in the case of new fault information, newly registers the fault information). Specifically, the control unit 28 sets the fault status 54 corresponding to the vehicle identification number included in the fault information to a value indicating "faulty." Furthermore, the control unit 28 adds the fault code included in the fault information to the fault log 55.

[0078] Next, in step S3 , the control unit 28 transmits the received failure occurrence information to the center 1 .

[0079] Next, in step S4, the control unit 28 determines whether the fault resolution notification transmitted from the vehicle 3 has been received. If the result of this determination is that the fault resolution notification has not been received ("No" in step S4), the process returns to step S1 and repeats. In other words, the process continues to wait for fault occurrence information and fault resolution notification.

[0080] On the other hand, if the fault resolution notification is received ("YES" in step S4), in step S5, the control unit 28 updates the fault status data 52 based on the fault resolution notification. Specifically, the control unit 28 sets a value indicating "normal" for the fault status 54 corresponding to the vehicle identification number included in the fault resolution notification.

[0081] Next, in step S6 , the control unit 28 transmits the above-mentioned fault resolution information to the center 1 .

[0082] This concludes the description of the failure information management process executed by the control unit 28 of the failure management server 2 .

[0083] About the processing performed at Center 1

[0084] Next, the details of the processing executed in the center 1 will be described. Figure 13 1 is a flowchart showing details of the failure information update process executed by the control unit 18 of the center 1. This process is for updating the contents of the failure status data 62 based on data transmitted from the failure management server 2.

[0085] First, in step S11, the control unit 18 determines whether or not it has received the failure occurrence information transmitted from the failure management server 2. If the result of this determination is that the failure occurrence information has not been received, the process proceeds to step S13 described later.

[0086] On the other hand, if fault information is received, the control unit 18 then updates the fault status data 62 based on the received fault information in step S12 (or, in the case of new fault information, newly registers the fault information). Specifically, the control unit 18 sets the fault status 64 corresponding to the vehicle identification number included in the fault information to a value indicating "faulty." Furthermore, the control unit 18 adds the fault code included in the fault information to the fault log 65.

[0087] Next, in step S13, the control unit 18 determines whether the fault resolution notification has been received from the fault management server 2. If the fault resolution notification has not been received ("No" in step S13), the process returns to step S11 and repeats the process.

[0088] On the other hand, if the fault resolution notification is received ("YES" in step S13), in step S14, the control unit 18 updates the fault status data 62 based on the fault resolution notification. Specifically, the control unit 18 sets a value indicating "normal" to the fault status 64 corresponding to the vehicle identification number included in the fault resolution notification.

[0089] This concludes the description of the failure information update process.

[0090] Next, Figure 14 This is a flowchart showing details of the update control process executed by the control unit 18 of the center 1. In this process, when a software update request is received from the OTA manager 31, the control unit 18 determines whether the vehicle 3 associated with the OTA manager 31 is faulty. If the vehicle 3 is faulty, the update process is controlled so that it does not start (even if an update is available).

[0091] exist Figure 14 In step S21, the control unit 18 first determines whether the update inquiry has been received from the OTA manager 31. If the result of this determination is that the update inquiry has not been received ("No" in step S21), the control unit 18 continues to wait for the update inquiry.

[0092] On the other hand, when the above-mentioned update inquiry is received ("Yes" in step S21), the control unit 18 then refers to the fault status data 62 in step S22 to determine whether the fault status 64 of the vehicle 3 corresponding to the vehicle identification number included in the update inquiry is "out of order". That is, the control unit 18 determines whether the vehicle 3 that has been inquired is in a faulty state. When the result of the determination is that the fault status 64 is "out of order" ("Yes" in step S22), the process proceeds to step S23. In step S23, the control unit 18 sends a notification indicating that the vehicle 3 is in trouble (hereinafter referred to as a fault notification) as the result of the inquiry to the OTA manager 31 that sent the update inquiry. The fault notification may include, for example, a message urging the vehicle sales and repairer to repair the vehicle 3 because the vehicle 3 has failed. Then, the update control process ends.

[0093] On the other hand, when the fault status 64 is not "faulty" ("No" in step S22), the control unit 18 then determines in step S24 whether there is a software update that should be distributed. If the result of the determination is that there is a software update that should be distributed ("Yes" in step S24), the process proceeds to step S25. In step S25, the control unit 18 starts the prescribed update processing for applying the software update to the vehicle 3 (such as sending the update data to the OTA manager 31). Then, if the update processing is completed, the update control processing ends. On the other hand, when there is no software update ("No" in step S24), the process proceeds to step S26. In step S26, the control unit 18 sends a notification to the OTA manager 31 that there is no software update. Then, the update control processing ends.

[0094] This concludes the description of the update control process executed by the control unit 18 of the center 1 .

[0095] Regarding the processing executed by the OTA manager 31

[0096] Next, the details of the processing executed by the OTA manager 31 will be described. Figure 15 3 is a flowchart showing details of the software update process executed by the control unit 49 of the OTA manager 31. In the present embodiment, as described above, this process is regularly executed at a frequency of, for example, once every two weeks.

[0097] First, in step S31, the control unit 49 generates data for the update inquiry and transmits the update inquiry to the center 1. The update inquiry includes the vehicle identification number and vehicle configuration information.

[0098] Next, in step S32, the control unit 49 determines whether the above-mentioned fault notification has been received from the center 1 as a result of sending the above-mentioned update inquiry. If the result of this determination is that a fault notification has been received ("Yes" in step S32), in step S36, the control unit 49 notifies the user that the vehicle 3 is in a state of failure. For example, the control unit 49 displays a message on a predetermined display device (although not shown in the figure, for example, a monitor of a navigation device) indicating that the update process cannot be performed because the vehicle 3 is in a state of failure. In addition, in this case, the control unit 49 can search for a route to the nearest vehicle sales and repair dealer, and control the display of the route on the monitor of the navigation device. Then, the control unit 49 ends the software update process. In this way, the execution of the software update when the vehicle 3 is in a state of failure can be suppressed.

[0099] On the other hand, if the result of step S32 is that the failure notification has not been received ("No" in step S32), the control unit 49 determines in step S33 whether a software update has been received as a result of the update query. If the result of this determination is that a software update has been received ("Yes" in step S33), the control unit 49 starts the process of updating the software in step S34. Specifically, the control unit 49 receives the update data transmitted from the center 1 and starts the process of updating the software of the target electronic control unit 33.

[0100] Next, in step S35, the control unit 49 determines whether the update process is complete. If the update process is not complete ("No" in step S35), the control unit 49 continues the update process. If the update process is complete ("Yes" in step S35), the control unit 49 ends the software update process.

[0101] On the other hand, if the result of the determination in step S33 is that there is no software update ("No" in step S33), the processing in steps S34 to S35 is not performed, and the control unit 49 ends the software update processing.

[0102] This concludes the description of the software update process.

[0103] Effect

[0104] Thus, in this embodiment, when the fault management server 2 receives information about a vehicle 3 failure, it transmits this information to the center 1. This information is then stored in the center 1. When the center 1 receives an inquiry from the OTA manager 31 regarding the availability of a software update, the center 1 determines whether a fault has occurred in the vehicle 3 based on this information stored in the center 1. In other words, at this point, the center 1 does not need to specifically inquire about the fault information from the vehicle 3. Furthermore, if the result of this determination is that the vehicle 3 has failed, control is performed so that the software update process is not executed for the failed vehicle 3, even if a software update is available. This prevents an increase in the amount of communication between the center 1 and the vehicle 3, and prevents software updates from being performed on a failed vehicle 3.

[0105] Modifications

[0106] Furthermore, in the above-described embodiment, the center 1 transmits a message notifying the vehicle 3 of the fault state. In this case, in addition to the message, the user may also be provided with, for example, contact information for the nearest vehicle dealer or repairer to the vehicle 3, directions to the dealer's store, etc. This facilitates the user's ability to take action to resolve the fault state of the vehicle 3.

[0107] The above describes an embodiment of the technology disclosed herein. However, the present disclosure can be understood not only as a center, but also as an update control method executed by a computer at the center having a processor, a memory, and a communication device capable of communicating with an OTA manager of a vehicle and a specified server via a network, a control program of the method, a computer-readable non-temporary recording medium storing the control program, an OTA manager capable of communicating with the center via a network, a vehicle having an OTA manager, a center, and a software update system having a fault information management server, etc.

[0108] The disclosed technology can be utilized in a center for controlling software update functions based on an OTA manager.

Claims

1. A center configured to communicate with an OTA manager and a fault management server via a network, wherein the OTA manager is mounted on a vehicle, and the fault management server is configured to store fault occurrence information, wherein the fault occurrence information is information in which a fault information code transmitted from the vehicle in which the fault occurred is associated with information identifying the vehicle in which the fault occurred. The center is characterized by The invention comprises a processor, wherein the processor is configured as follows: receiving the fault occurrence information sent from the fault management server; storing the fault occurrence information received from the fault management server; receiving, from the OTA manager, an inquiry regarding whether software of the electronic control device has been updated; When the processor receives the inquiry, it determines whether the sender of the inquiry, that is, the vehicle, is in a fault state based on the fault occurrence information; as well as If the processor determines that the vehicle that is the sender of the inquiry is in a faulty state, the processor restricts execution of the software update process related to the vehicle that is the sender of the inquiry, The fault management server is configured to transmit new fault occurrence information to the center when new fault occurrence information is registered in the fault management server.

2. The center according to claim 1, characterized in that The processor is configured to transmit information indicating that a vehicle failure has occurred to the vehicle that has issued the inquiry, when the processor determines that a vehicle that has issued the inquiry has failed.

3. An update control method, executed by a central computer having a processor, a memory, and a communication device, the communication device being configured to communicate with an OTA manager and a fault management server via a network, the OTA manager being mounted on a vehicle, the fault management server being configured to store fault occurrence information, the fault occurrence information being information in which a fault information code transmitted from a vehicle having a fault is associated with information identifying the vehicle having the fault. The update control method is characterized by comprising: receiving the fault occurrence information sent from the fault management server; storing the fault occurrence information received from the fault management server; receiving, from the OTA manager, an inquiry regarding whether software of the electronic control device has been updated; Upon receiving the inquiry, determining whether the sender of the inquiry, that is, the vehicle, is in a fault state based on the fault occurrence information; as well as If it is determined that the vehicle of the sender of the inquiry is in a faulty state, restricting execution of the software update process related to the vehicle of the sender of the inquiry, The fault management server is configured to transmit new fault occurrence information to the center when new fault occurrence information is registered in the fault management server.

4. A non-transitory storage medium storing instructions executable by a central computer having a processor, a memory, and a communication device, the instructions causing the computer to perform the following functions, wherein the communication device is configured to communicate with an OTA manager and a fault management server via a network, the OTA manager being mounted on a vehicle, and the fault management server being configured to store fault occurrence information, the fault occurrence information being information in which a fault information code transmitted from a vehicle having a fault is associated with information identifying the vehicle having the fault; The non-transitory storage medium is characterized in that the functions include: receiving the fault occurrence information sent from the fault management server; storing the fault occurrence information received from the fault management server; receiving, from the OTA manager, an inquiry regarding whether software of the electronic control device has been updated; Upon receiving the inquiry, determining whether the sender of the inquiry, that is, the vehicle, is in a fault state based on the fault occurrence information; If it is determined that the vehicle that sent the inquiry is in a faulty state, execution of the software update process related to the vehicle that sent the inquiry is restricted; The fault management server is configured to transmit new fault occurrence information to the center when new fault occurrence information is registered in the fault management server.

5. A software updating system, characterized in that: Including vehicles with OTA managers, fault management servers and centers, in, The vehicle is composed of: detecting a fault occurring in the vehicle; and sending fault occurrence information to the fault management server, the fault occurrence information including information identifying the vehicle and a fault information code associated with the fault, The fault management server is composed of: communicating with the OTA manager and the center via a network; receiving fault occurrence information transmitted from the vehicle; and Sending the fault occurrence information to the center, The center is composed of: communicating with the OTA manager and the fault management server via a network; storing the fault occurrence information sent from the fault management server; receiving a query from the OTA manager regarding the presence of a software update; Upon receiving the inquiry, determining whether the vehicle to which the inquiry is made is in a fault state based on the stored fault occurrence information; and If it is determined that the vehicle to which the inquiry is made has a malfunction, execution of a software update process for the vehicle to which the inquiry is made is restricted; The fault management server is configured to transmit new fault occurrence information to the center when new fault occurrence information is registered in the fault management server.

Images