Repair support device, repair support method, and repair support program

Abstract

To provide a repair support device that can propose a proper repair shop for a vehicle on the basis of the content of failures.SOLUTION: A repair support device 100 includes a shop information storing unit, a positional information acquisition unit 112, an abnormality flag acquisition unit 114, a failure estimation unit 115, a part specification unit 116, a candidate shop extraction unit 117, and a notification unit 118. The shop information storing unit stores shop information of a shop which stores various different types of parts of a vehicle 20. The positional information acquisition unit 112 acquires positional information of the vehicle 20. The abnormality flag acquisition unit 114 acquires an abnormality flag from the vehicle 20. The failure estimation unit 115 estimates the content of failures on the basis of the abnormality flag. The part specification unit 116 specifies part information on the basis of the content of failures. The candidate shop extraction unit 117 extracts candidate shop information on a store candidate that can repair the vehicle 20, on the basis of the shop information, the positional information, the content of failures, and the part information. The notification unit 118 notifies the vehicle 20 and / a terminal of a passenger of the candidate shop information.SELECTED DRAWING: Figure 4

Description

[Technical field]

[0001] The present invention relates to a repair support device, a repair support method, and a repair support program. [Background technology]

[0002] A technology has been proposed in which a server collects vehicle driving information, and when it detects a vehicle malfunction, it makes a reservation for vehicle repair with a dealer or service shop and orders parts necessary for the repair. Patent Document 1 discloses a remote malfunction diagnosis server that collects data related to the vehicle's auxiliary equipment and vehicle motion system and performs vehicle malfunction diagnosis on the server. When a user feels that there is a malfunction in the vehicle, this remote malfunction diagnosis server makes a "repair reservation" or the like with a dealer and / or service shop in response to a request for malfunction diagnosis from the vehicle, and notifies the vehicle side of the completion of the "repair reservation" or the like. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2002-228553 A Summary of the Invention [Problem to be solved by the invention]

[0004] In the remote fault diagnosis server disclosed in Patent Document 1, after a fault is detected in a vehicle, the server makes a reservation for repair with a specified dealer, etc. Therefore, if the dealer that has taken the vehicle does not have the parts in stock, the vehicle cannot be repaired immediately.

[0005] The present invention has been made in consideration of the above-mentioned problems, and an object of the present invention is to provide a repair assistance device capable of suggesting an appropriate repair shop for a vehicle based on the details of the failure. [Means for solving the problem]

[0006] A repair support device according to one aspect of the present invention includes a store information storage unit, a location information acquisition unit, an abnormality flag acquisition unit, a fault estimation unit, a part identification unit, a candidate store extraction unit, and a notification unit. The store information storage unit stores store information of stores that have various vehicle parts. The location information acquisition unit acquires vehicle location information. The abnormality flag acquisition unit acquires an abnormality flag from the vehicle. The fault estimation unit estimates the fault content based on the abnormality flag. The part identification unit identifies part information based on the fault content. The candidate store extraction unit extracts candidate store information of stores that can repair the vehicle based on the store information, location information, fault content, and part information. The notification unit notifies the vehicle and / or a passenger's terminal of the candidate store information. Effect of the Invention

[0007] According to the present invention, it is possible to provide a repair assistance device capable of suggesting an appropriate repair shop for a vehicle based on the details of the failure. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 is a diagram showing a schematic configuration of a repair support system 1 according to the first embodiment. [Diagram 2] FIG. 2 is a block diagram showing a schematic configuration of an electronic control unit 200 according to the first embodiment. [Diagram 3] FIG. 3 is a diagram illustrating an example of abnormality flag data according to the first embodiment. [Figure 4] FIG. 4 is a functional block diagram for explaining functions of the repair support device 100 according to the first embodiment. [Diagram 5] FIG. 5 is a diagram for explaining the urgency of a failure content. [Figure 6] FIG. 6 is a diagram showing an example of a notification in a case where warehousing for repairs is proposed according to the first embodiment. [Figure 7] FIG. 7 is a flowchart for explaining the processing of the repair support device 100 according to the first embodiment. [Figure 8]FIG. 8 is a flowchart for explaining the store extraction process according to the first embodiment. [Figure 9] FIG. 9 is a block diagram for explaining functions of a repair support device 100 according to the second embodiment. [Figure 10] FIG. 10 is a block diagram for explaining the function of the learning unit 150 according to the third embodiment. [Figure 11] FIG. 11 is a diagram showing a schematic configuration of a repair support system 1 according to another embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] The embodiments will be described with reference to the drawings. In the description of the drawings, the same parts are given the same reference numerals and the description will be omitted.

[0010] (Overview of Repair Support System 1) The repair assistance system 1 is a system in which a server 10 acquires an abnormality flag detected in a vehicle 20 from the vehicle 20, extracts dealers or service factories suitable for repair as candidate stores, and notifies the vehicle 20 and / or a user terminal 50 of information regarding the candidate stores. The repair assistance system 1 using the server 10 will be described below with reference to several specific embodiments.

[0011] (First embodiment) (Configuration of repair support system 1) A schematic configuration of a repair support system 1 according to a first embodiment will be described with reference to Fig. 1. The repair support system 1 includes a server 10, a vehicle 20, a store terminal 30, a network 40, and a user terminal 50.

[0012] The server 10 includes a repair support device 100. As shown in FIG. 1, the repair support device 100 includes a control unit 110, a storage unit 120, and a network IF 140. The server 10 exchanges data with the vehicle 20, the store terminal 30, and the user terminal 50 via the network 40. The control unit 110 and the storage unit 120 will be described in detail later. The network IF 140 is an interface for communicating with the vehicle 20, the store terminal 30, and the user terminal 50 via the network 40. Note that the configuration example of the repair support device 100 shown in FIG. 1 is merely an example, and the present embodiment is not limited thereto. For example, the server 10 can be replaced with one or more computers capable of implementing each function implemented in the control unit 110.

[0013] The vehicle 20 includes an electronic control unit 200. The electronic control unit 200 is a computer for controlling the traveling of the vehicle 20. The electronic control unit 200 is also connected to the server 10 via a network 40 so as to be able to communicate with each other. The electronic control unit 200 will be described in detail later.

[0014] The store terminal 30 is configured as a computer such as a personal computer or a tablet, and is a terminal installed at a dealer or a service factory (hereinafter referred to as a store). The store has various parts necessary for repairing the vehicle 20. Although not shown in the figure, the store terminal 30 also includes a control unit, a storage unit, a network IF, etc., like the server 10. In other words, the store terminal 30 can communicate with the server 10 via the network 40.

[0015] The network 40 is a wired and / or wireless network, and is a communication network that allows mutual communication between the server 10, the vehicle 20, the store terminal 30, and the user terminal 50. The network 40 is configured, for example, by the Internet or a carrier network such as a mobile phone network.

[0016] The user terminal 50 is configured, for example, as a smartphone, and is usually operated by a user (passenger) of the vehicle 20. The user terminal 50 may be configured as a mobile device such as a tablet or a notebook computer. Although not shown in the figure, the user terminal 50 also includes a control unit, a storage unit, a network IF, and the like, similar to the server 10. That is, the user terminal 50 is capable of mutual communication with the server 10 via the network 40.

[0017] (Functional configuration of electronic control unit 200) 2 shows a block diagram of the electronic control unit 200. The electronic control unit 200 is a computer provided in the vehicle 20 and controls the traveling of the vehicle 20. The electronic control unit 200 includes a control unit 210, a storage unit 220, and a network IF 240. The electronic control unit 200 is also connected to a sensor 21, a switch 22, an actuator 23, a GPS device 24 (Global Positioning System), and a display unit 25 provided in the vehicle 20.

[0018] The control unit 210 controls the vehicle by sending instructions to the actuator 23 based on signals from the sensor 21 and / or the switch 22. Specifically, the control unit 210 receives signals from the sensor 21 and the switch 22 and performs calculations, logical processing, and the like. Furthermore, the control unit 210 sends appropriate control signals based on the results of the calculations, logical processing, and the like to the actuators 23 such as motors and solenoids via the power devices, thereby controlling the actuators 23. That is, in the on-board system of the vehicle 20, the sensor 21 and the switch 22 play an important role in correctly grasping the state, etc., of the vehicle 20 in order to operate the actuators 23.

[0019] Furthermore, the control unit 210 operates based on a program (not shown) stored in the storage unit 220, and executes a self-diagnosis function described below. The program is not limited to being stored in the storage unit 220, and may be stored in, for example, a ROM (not shown) in the electronic control unit 200. The control unit 210 also acquires vehicle position information from the GPS device 24. Furthermore, the control unit 210 causes the display unit 25 to display various data.

[0020] The control unit 210 also has a self-diagnosis function for self-diagnosing whether or not an abnormality has occurred in the vehicle 20. The self-diagnosis function diagnoses whether or not an abnormality has occurred in the sensor 21, the switch 22, or the actuator 23. When an abnormality has occurred in the sensor 21, the switch 22, or the actuator 23, the control unit 210 stores the occurrence of the abnormality in the storage unit 220. Specifically, the control unit 210 acquires an abnormality code corresponding to the abnormality that has occurred and stores it in the storage unit 220. The abnormality code is, for example, a DTC (Diagnostic Trouble Code), which is a code assigned to the content of the abnormality. An example of an abnormality code is shown in FIG. 3. In the example shown in FIG. 3, an example of a voltage drop of the O2 sensor, in which the DTC is P0131, is shown. In the following, the abnormality code will be described as a DTC.

[0021] When the control unit 210 detects an abnormality, it acquires the state of the vehicle 20 at the time when the abnormality occurs in conjunction with storing the DTC in the storage unit 220, and stores the state of the vehicle 20 together with the DTC in the storage unit 220. The state of the vehicle 20 acquired here is, for example, freeze frame data (hereinafter, referred to as FFD), and includes the engine speed, engine cooling temperature, and the like when the DTC is stored in the storage unit 220. In this embodiment, the values ​​of the DTC and FFD shown in FIG. 3 are regarded as abnormal data. Note that the abnormal data is not limited to a form including both the DTC and the FFD, and may be a form consisting of only the DTC. Furthermore, the abnormal data may include sensor information and control information related to the vehicle 20 other than the DTC and the FFD in addition to the DTC and the FFD. Furthermore, the abnormal data may include a vehicle identification number, which is a number for identifying the vehicle 20, as shown in FIG. 3. The control unit 210 sends the abnormal data stored in the storage unit 220 as an abnormality flag to the server 10 via the network IF 240.

[0022] As described above, the sensor 21 is a sensor that measures the state of the vehicle 20. For example, the sensor 21 includes an O2 sensor that grasps the combustion state of the fuel, an airflow sensor that grasps the intake amount, a pressure sensor that grasps the hydraulic pressure of the transmission, a temperature sensor, and the like. The switch 22 includes, for example, a starter switch, an idle switch, a heat-up switch, and the like. The actuator 23 includes a motor, a solenoid, a piezoelectric element, and the like. Note that the contents related to the sensor 21, the switch 22, and the actuator 23 described above do not limit this embodiment, and may include things other than the above contents.

[0023] The GPS device 24 detects position information of the vehicle 20 and sends the detected position information to the control unit 210. The GPS device 24 receives radio waves from a plurality of GPS satellites with a GPS antenna (not shown), performs a predetermined calculation process to obtain latitude and longitude information representing the current position of the vehicle 20 from the received signal, and stores it in the storage unit 220 as position information of the vehicle 20. In addition, the control unit 210 sends the position information of the vehicle 20 stored in the storage unit 220 to the server 10 via the network IF 240 at a predetermined timing.

[0024] The display unit 25 is, for example, a navigation device provided in the vehicle 20, and displays various information. In this embodiment, the display unit 25 is not limited to being configured as only a navigation device, and may include, for example, a device that displays the running state (speed, remaining gasoline) and abnormal state of the vehicle 20 as an instrument panel. The display unit 25 corresponds to an in-vehicle terminal.

[0025] (Functional configuration of repair support device 100) 4 is a functional block diagram for explaining the functions of the repair support device 100. The functions of the repair support device 100 will be explained using the functional block diagram shown in FIG.

[0026] 4, the control unit 110 has, as its functions, a store information acquisition unit 111, a position information acquisition unit 112, a driving route calculation unit 113, an abnormality flag acquisition unit 114, a failure estimation unit 115, a part identification unit 116, a candidate store extraction unit 117, and a notification unit 118. The storage unit 120 also has, as databases, a store information DB 121, a position information DB 122, an abnormality flag DB 123, a failure content DB 124, and a candidate store DB 125.

[0027] The control unit 110, for example, operates an operation system to control the entire server 10. Furthermore, the control unit 110 operates based on a program (not shown) stored in the storage unit 120 to execute each of the above-mentioned functions. Note that the program is not limited to being stored in the storage unit 120, and may be stored in, for example, a ROM (not shown) in the repair support device 100.

[0028] The store information acquisition unit 111 acquires information about the store from the store terminal 30 and stores it in the store information DB 121. Specifically, the store information includes store location information, store business hours, and information about the stock of parts required for repairing the vehicle 20 provided by the store. The store information DB 121 also stores store information about at least one store. The store information DB 121 corresponds to a store information storage unit.

[0029] The position information acquisition unit 112 acquires the position information of the vehicle 20 sent from the electronic control unit 200 of the vehicle 20, and stores the information in the position information DB 122. As described above, the position information of the vehicle 20 is position information acquired by the GPS device 24 provided in the vehicle 20, and is information of latitude and longitude that indicates the current position of the vehicle 20.

[0030] The driving route calculation unit 113 calculates the driving route of the vehicle 20 based on the position information acquired by the position information acquisition unit 112. Specifically, the driving route calculation unit 113 calculates the difference in the position information of the vehicle 20 at a timing when a certain time has elapsed from a certain timing, and calculates a rough driving route and traveling direction indicating in which direction the vehicle 20 is heading.

[0031] The abnormality flag acquisition unit 114 acquires the abnormality flag sent from the vehicle 20. Specifically, the DTC and FFD acquired by the electronic control unit 200 of the vehicle 20 are sent from the vehicle 20 as abnormality flags, and the abnormality flag acquisition unit 114 acquires the abnormality flags and stores them in the abnormality flag DB 123.

[0032] The fault estimation unit 115 estimates the fault content of the vehicle 20 based on the fault flag acquired by the fault flag acquisition unit 114 and stored in the fault flag DB 123, and stores the estimated fault content in the fault content DB 124. The fault content includes both a fault that has already occurred and a fault that is expected to occur in the future. In the first embodiment, the fault estimation unit 115 estimates the fault content based on a predetermined correspondence relationship between the fault flag and the fault content. This correspondence relationship may be a fault content that corresponds one-to-one to the DTC. Alternatively, it may be a fault content that corresponds to information indicating the state of the vehicle 20, such as the DTC and FFD. In addition, the correspondence relationship between the fault flag and the fault content may be a fault content that is determined when the DTC is specified. Alternatively, the correspondence relationship between the fault flag and the fault content may be determined based on a past inspection history or repair history for the fault flag. In addition, the fault content may include information about the fault, such as the importance of the fault content, an estimated time until occurrence, and a possibility of occurrence.

[0033] The part identification unit 116 identifies part information corresponding to the malfunction content, based on the malfunction content of the vehicle 20 estimated by the malfunction estimation unit 115. The part information corresponds to the information on the vehicle 20 and the malfunction content, and is a part required to repair the vehicle 20.

[0034] The candidate store extraction unit 117 determines whether the part identified by the part identification unit 116 is present in a store, and extracts a store to which the vehicle 20 will be brought for repair. Specifically, the candidate store extraction unit 117 calculates the degree of urgency (presence or absence of urgency) indicating the degree of urgency for repair of the vehicle 20 according to the breakdown content stored in the breakdown content DB 124. The degree of urgency is calculated based on the importance of the breakdown content, the estimated time until the breakdown occurs, and the possibility of the breakdown occurring, as shown in FIG. 5.

[0035] For example, a fault content with an urgency level of 5 is a fault that is highly important and is estimated to require immediate repair of the vehicle 20. Furthermore, fault contents with urgency levels of 4 and 3 are less important than a fault content with an urgency level of 5, but the estimated time until a fault occurs is short, or a fault has already occurred. In other words, fault contents with urgency levels of 4 and 3 are faults that are estimated to occur in a short time, or a fault has already occurred, and therefore it is preferable to bring the fault content into the store as soon as possible. In this embodiment, for fault contents with urgency levels of 4 and 3, the urgency level is 4 for fault contents that are highly likely to cause a fault or that have already caused a fault, while the urgency level is 3 for fault contents that are unlikely to cause a fault.

[0036] Furthermore, breakdowns with urgency levels of 2 and 1 are less important than those with urgency level 5, and are estimated to take a long time to cause a breakdown. In this case, since the estimated time until a breakdown occurs is long, the user can bring the vehicle 20 into a store at his / her convenience and have the vehicle 20 inspected and repaired for the breakdown. In this embodiment, for breakdowns with urgency levels of 2 and 1, the urgency level of breakdown that is highly likely to cause a breakdown is set to 2, while the urgency level of breakdown that is low likely to cause a breakdown is set to 1.

[0037] Furthermore, a fault with an urgency level of 0 is estimated to have no possibility of causing a fault in the first place. In this case, the user does not need to bring the vehicle 20 to a shop. In the case of a fault with an urgency level of 0, an inspection or the like is carried out based on the DTC information stored in the vehicle 20 during a periodic vehicle inspection of the vehicle 20.

[0038] Furthermore, the candidate store extraction unit 117 extracts candidate store information regarding candidate stores for warehousing based on the above-mentioned urgency, store information, and location information of the vehicle 20. If there are multiple candidate stores, the multiple candidate stores are extracted. The candidate store extraction unit 117 stores the extracted candidate store information in the candidate store DB 125. The candidate store extraction unit 117 may also extract candidate stores using the travel route of the vehicle 20 calculated by the travel route calculation unit 113. This enables the candidate store extraction unit 117 to recognize the traveling direction of the vehicle 20, and to extract more appropriate candidate stores for warehousing.

[0039] The notification unit 118 notifies the vehicle 20 and / or the user terminal 50 of information on the candidate stores extracted by the candidate store extraction unit 117 and stored in the candidate store DB 125. Fig. 6 shows an example in which the information on the candidate stores notified to the user terminal 50 is displayed together with the breakdown status. That is, the user checks the notification displayed on the user terminal 50, and causes the vehicle 20 to be stored at store A where inspection is possible according to the driving status.

[0040] The candidate store extraction unit 117 may store, in addition to the information on the candidate stores, information indicating the degree of urgency in the candidate store DB 125 in association with the information. For example, if the information on the candidate stores is not urgent, the notification unit 118 may be configured to notify the vehicle 20 at the timing when the vehicle 20 is next started, thereby suggesting to the occupant of the vehicle 20 that the vehicle be repaired. For example, if the user has finished using the vehicle 20 before repairs are performed, by notifying the information on the candidate stores at the timing when the vehicle 20 is next started, it is possible to prevent the user from failing to recognize that the vehicle has been brought into the garage.

[0041] Furthermore, the notification unit 118 may be configured to notify either the vehicle 20 or the user terminal 50 of the candidate store depending on the driving status of the vehicle 20 acquired by the position information acquisition unit 112, for example. For example, when the vehicle 20 is not driving, the user can recognize the notification of the candidate store by notifying the user terminal 50. On the other hand, while the vehicle 20 is driving, for example, when the owner of the user terminal 50 is driving the vehicle 20, it may not be desirable to notify the user terminal 50. In such a situation, by notifying only the vehicle 20, the user can quickly recognize the notification content through the display unit 25 (in-vehicle terminal).

[0042] (Outline of processing flow of repair support device 100) Next, the process related to repair support in the repair support device 100 (repair support method) will be described based on the flowchart in Fig. 7. Note that the process in the flowchart shown in Fig. 7 also ends when the power is turned off or an interrupt is issued to end the process. In addition, in the following description of the flowchart, the same contents as those described in the above description of the repair support device 100 will be omitted or simplified.

[0043] In step S701, the location information acquisition unit 112 acquires the location information sent from the vehicle 20 and stores it in the location information DB 122.

[0044] In step S702, the abnormality flag acquisition unit 114 determines whether or not an abnormality flag has been sent from the vehicle 20. If the abnormality flag acquisition unit 114 determines in step S702 that an abnormality flag has been sent from the vehicle 20 (step S702: YES), the process proceeds to step S703. On the other hand, if the abnormality flag acquisition unit 114 determines in step S702 that an abnormality flag has not been sent from the vehicle 20 (step S702: NO), the process returns to step S701, and the position information acquisition unit 112 performs a process of acquiring position information. That is, in this embodiment, the position information acquisition unit 112 repeatedly acquires position information until an abnormality flag is sent from the vehicle 20.

[0045] In step S703, if it is determined that an abnormality flag has been sent from the vehicle 20, the abnormality flag acquisition unit 114 acquires the abnormality flag sent from the vehicle 20 and stores it in the abnormality flag DB 123. After that, the process proceeds to step S704.

[0046] In step S704, the fault estimation unit 115 estimates a fault based on the abnormality flag stored in the abnormality flag DB 123.

[0047] In step S705, the part identification unit 116 identifies a part required for repair based on the type of the malfunction estimated in step S704.

[0048] In step S706, the candidate store extraction unit 117 extracts candidate stores for repair based on the store information, the location information of the vehicle 20, the breakdown details, and the parts information. Specific processing of "store extraction" shown in step S706 will be described with reference to the flowchart of the subroutine related to "store extraction" shown in FIG.

[0049] 8, the candidate store extraction unit 117 calculates the urgency according to the failure content. Specifically, the candidate store extraction unit 117 calculates the urgency according to the importance of the failure content shown in FIG. 5, the estimated time until occurrence, and the possibility of occurrence.

[0050] In step S802, the candidate store extraction unit 117 determines whether the urgency calculated in step S801 is 5. If the candidate store extraction unit 117 determines that the urgency of the malfunction content is 5 (step S802: YES), the process proceeds to step S803. On the other hand, if the candidate store extraction unit 117 determines that the urgency of the malfunction content is not 5 (step S802: NO), the process proceeds to step S809.

[0051] In step S803, the candidate store extraction unit 117 extracts stores that are candidates for warehousing (candidate stores). In step S803, since the malfunction has an urgency level of 5, it is assumed that the vehicle 20 needs to be brought into a store immediately for inspection and repair. Therefore, when extracting stores in step S803, the candidate store extraction unit 117 extracts stores that are close to the position obtained from the position information of the vehicle 20. In addition, if there are multiple candidate stores, the candidate stores are extracted in order of proximity to the position of the vehicle 20.

[0052] In step S804, the candidate store extraction unit 117 determines whether or not there is a candidate store that is a target of the candidate stores extracted in step S803. If the candidate store extraction unit 117 determines in step S804 that there is a candidate store (step S804: YES), the process proceeds to step S806. On the other hand, if the candidate store extraction unit 117 determines in step S804 that there is no candidate store (step S804: NO), the process proceeds to step S805.

[0053] In step S805, the candidate store extraction unit 117 generates a result indicating that there are no candidate stores as a result of the store extraction. However, in step S805, the urgency level is 5, which means that an inspection and / or repair is required immediately. Therefore, in step S805, a result indicating that there are no candidate stores but that there is an emergency is generated and stored in the candidate store DB 125. After that, in step S707 described below, a display is displayed indicating that there are no candidate stores but that the breakdown of the vehicle 20 is in an emergency state.

[0054] In step S806, the candidate store extraction unit 117 determines whether the extracted candidate store has the parts necessary for the repair corresponding to the malfunction in stock. If the candidate store extraction unit 117 determines in step S806 that the store extracted in step S803 has the stock necessary for the repair (step S806: YES), the process proceeds to step S807. On the other hand, if the candidate store extraction unit 117 determines in step S806 that the store extracted in step S803 does not have the stock necessary for the repair (step S806: NO), the process returns to step S803 and extracts candidate stores again.

[0055] In step S807, the candidate store extraction unit 117 determines the candidate stores, and returns to step S706 in the flowchart shown in Fig. 7. In step S807, the candidate store DB 125 stores information indicating that the vehicle 20 may break down and information regarding candidate stores suitable for storing the vehicle 20.

[0056] In step S808, the candidate store extraction unit 117 determines whether the urgency is 4 or 3. If the candidate store extraction unit 117 determines in step S808 that the urgency is 4 or 3 (step S808: YES), the process proceeds to step S809. On the other hand, if the candidate store extraction unit 117 determines in step S808 that the urgency is not 4 or 3 (step S808: NO), the process proceeds to step S812.

[0057] In step S809, the candidate store extraction unit 117 extracts candidate stores. The extraction of candidate stores in step S809 is for a breakdown with an urgency level of 4 or 3, so inspection and / or repair of the vehicle 20 is not urgent, but if there is a store suitable for repair, the store suitable for warehousing is suggested. Therefore, when extracting stores in step S809, the candidate store extraction unit 117 extracts stores close to the position obtained from the position information of the vehicle 20. Furthermore, if there are multiple candidate stores, the candidate stores are extracted in order of proximity to the position of the vehicle 20.

[0058] In step S810, the candidate store extraction unit 117 determines whether the position from the vehicle 20 to the candidate store is closer than the distance from the vehicle 20 to the "regular" store for the candidate store extracted in step S809. Here, the "regular" store is, for example, a store that the user has used in the past. In this embodiment, if there are multiple stores that have been used twice or more, the store that has been used twice or more is the "regular" store. Furthermore, if there are multiple stores that have been used twice or more, the store that has been used most recently among the stores that have been used twice or more is determined as the "regular" store. In the case of a "regular" store, it is often near the user's home. In other words, regardless of the acquired location information of the vehicle 20, a "regular" store near the user's home is extracted as a candidate store.

[0059] In step S810, if the candidate store extraction unit 117 determines that the location from the vehicle 20 to the candidate store is closer than the distance from the vehicle 20 to the "favorite" store (step S810: YES), the process proceeds to step S811. In step S810, if the candidate store extraction unit 117 determines that the location from the vehicle 20 to the candidate store is farther than the distance from the vehicle 20 to the "favorite" store (step S810: NO), the process proceeds to step S813.

[0060] In step S811, the candidate store extraction unit 117 determines whether or not the store extracted in step S809 has stock of the parts necessary for the repair. In step S811, if the candidate store extraction unit 117 determines that the extracted store has stock of the parts necessary for the repair (step S811: YES), the process proceeds to step S807. On the other hand, in step S811, if the candidate store extraction unit 117 determines that the extracted store does not have stock of the parts necessary for the repair (step S811: NO), the process returns to step S809 and extracts candidate stores again.

[0061] In step S812, the candidate store extraction unit 117 determines whether the urgency is 2 or 1. In step S812, if the candidate store extraction unit 117 determines that the urgency is 2 or 1 (step S812: YES), the process proceeds to step S813. On the other hand, in step S812, if the candidate store extraction unit 117 determines that the urgency is not 2 or 1 (step S812: NO), the process proceeds to step S814.

[0062] In step S813, the candidate store extraction unit 117 extracts the "regular" store as a candidate store for stocking the part. If the urgency of the malfunction is not 5, the importance of the malfunction is low, so the user can choose the timing when the part can be stocked at the store. Even if the part is not in stock, the user can order the part from the "regular" store and have it stocked when it arrives.

[0063] In step S814, the candidate store extraction section 117 determines that there are no candidate stores, and the process returns to step S706 in the flowchart shown in FIG.

[0064] Returning to the flowchart in Fig. 7, in step S707, the notification unit 118 obtains information on the candidate repair stores extracted by the candidate store extraction unit 117 from the candidate store DB 125 and sends the information to the vehicle 20 and / or the user terminal 50, thereby notifying the vehicle 20 of the candidate stores. For example, a notification such as that shown in Fig. 6 is displayed on the display unit 25 of the vehicle 20 and / or the user terminal 50.

[0065] In the flowchart of "Store Extraction" shown in Fig. 8, an example is shown in which different processes are performed when the urgency level is 5, 4 or 3, and when it is 2 or 1, but this embodiment is not limited to this configuration. For example, the urgency level is 4 may be treated as a highly urgent case, and the processes from step S802 to step S806 may be specified as the processes for when the urgency level is 5 or 4. Alternatively, the urgency levels are 4 and 2, which are likely to cause a breakdown, may be treated as highly urgent cases, and the processes from step S802 to step S806 may be specified as the processes for when the urgency level is 5, 4 or 2.

[0066] (Action and effect) As described above, according to the first embodiment, the following advantageous effects can be obtained.

[0067] The repair support device 100 includes a store information DB 121, a location information acquisition unit 112, an abnormality flag acquisition unit 114, a failure estimation unit 115, a part identification unit 116, a candidate store extraction unit 117, and a notification unit 118. The store information DB 121 stores store information of stores that have various parts for the vehicle 20. The location information acquisition unit 112 acquires location information of the vehicle 20. The abnormality flag acquisition unit 114 acquires an abnormality flag from the vehicle 20. The failure estimation unit 115 estimates the failure content based on the abnormality flag. The part identification unit 116 identifies part information based on the failure content. The candidate store extraction unit 117 extracts candidate store information that can repair the vehicle 20 based on the store information, location information, failure content, and part information. The notification unit 118 notifies the vehicle 20 and / or a passenger's terminal of the candidate store information. This makes it possible to suggest an appropriate store for warehousing to the vehicle 20 in which the abnormality flag is detected, depending on the type of failure. Furthermore, the type of failure is not limited to failures that have already occurred, but also includes failures that may occur. Therefore, for example, for a failure that may occur, it is possible to order parts corresponding to the type of failure to a store in advance, and to suggest to the user an appropriate store for warehousing and an appropriate timing for warehousing.

[0068] In conventional repair assistance, if a detected failure requires an emergency and the store where the vehicle 20 is brought for repair does not have the parts necessary for the repair in stock, there is a risk that the vehicle 20 may be brought in but not be able to be repaired. In this case, for example, the energy required to bring the vehicle 20 into the store is wasted. The repair assistance device 100 according to this embodiment suggests stores with stock or stores with a history of use as candidate stores for repair, depending on the urgency of the failure. In other words, it is possible to suggest an appropriate store for the repair depending on the failure, and it is possible to prevent wasteful energy consumption.

[0069] Moreover, the repair support device 100 according to the first embodiment includes a driving route calculation unit 113 that calculates a driving route of the vehicle 20 based on the position information of the vehicle 20. This enables the candidate store extraction unit 117 to recognize the traveling direction of the vehicle 20, and to extract more appropriate candidate stores for warehousing.

[0070] Furthermore, the candidate store extraction unit 117 determines whether or not there is an urgency to repair the vehicle 20 based on the details of the malfunction, and if it determines that there is no urgency, extracts stores that have been used for the vehicle 20 as candidate store information. This allows the user of the vehicle 20 to bring the vehicle 20 into an appropriate store at a convenient time depending on the status of the malfunction. This eliminates the need for the user to bring the vehicle 20 into the store unnecessarily, thereby reducing the energy required for unnecessary bringing the vehicle into the store.

[0071] Furthermore, when the abnormality flag is acquired and a store located near the vehicle 20 does not have the parts necessary for repair, the candidate store extraction unit 117 extracts stores that have a history of use for the vehicle 20 as candidate store information. This allows the user of the vehicle 20 to bring the vehicle 20 into a store that has the parts in stock at an appropriate time depending on the nature of the malfunction. Therefore, the user does not need to bring the vehicle 20 unnecessarily into a store that does not have the parts for the vehicle 20, and this makes it possible to reduce energy required for unnecessary warehousing.

[0072] When the candidate store extraction unit 117 determines that there is no urgency in repairing the vehicle 20 and the use of the vehicle 20 is ended before the repair is performed, the notification unit 118 notifies the occupant of the vehicle 20 of a proposal to repair the vehicle at the timing of next starting the vehicle 20. Thereby, for example, when the user ends the use of the vehicle 20 before repairing it, by notifying information about the candidate store at the timing of next starting the vehicle 20, it is possible to prevent the user from failing to recognize that the vehicle has been brought into the garage.

[0073] Second Embodiment As described above, one specific embodiment has been described, but the above-mentioned embodiment is merely an example and does not limit the present embodiment. For example, in the above-mentioned embodiment, the failure estimation unit 115 estimates the failure content based on the abnormality flag. Here, a configuration different from that of the first embodiment will be described for the repair support system 1 according to the second embodiment in which the failure estimation unit 115 in the repair support device 100 estimates the failure content based on the repair history.

[0074] Fig. 9 is a block diagram showing a part of a repair support device 100 according to a second embodiment. Note that in the repair support device 100 according to the second embodiment shown in Fig. 9, blocks having the same contents as those in the first embodiment are omitted. As shown in Fig. 9, the repair support device 100 according to the second embodiment differs from the repair support device 100 according to the first embodiment in that it includes a repair history acquisition unit 119 and a repair history DB 129. Note that the repair history DB 129 corresponds to a repair history storage unit.

[0075] The repair history acquisition unit 119 acquires the history of past repairs as data from the store terminal 30. In the second embodiment, when the repair of the vehicle 20 is completed, the store terminal 30 sends information about the vehicle 20, such as the vehicle model, mileage, area, contents of the abnormality flag, details of the malfunction, parts used in the repair, and part lot numbers, to the server 10. The repair history acquisition unit 119 acquires the above-mentioned information about the vehicle 20 sent from the store terminal 30 and stores it in the repair history DB 129.

[0076] In the second embodiment, the failure estimation unit 115 estimates the failure content based on the repair history stored in the repair history DB 129 in addition to the abnormality flag stored in the abnormality flag DB 123 and information indicating the state of the vehicle 20. For example, when the repair history DB 129 stores a repair history for a vehicle of the same model as the vehicle 20 to be repaired, information about that vehicle is used to estimate the failure content of the vehicle 20. Note that the information stored in the repair history DB 129 is not limited to information about the same vehicle as the vehicle 20 to be repaired, and information about a vehicle similar to the vehicle 20 may be used to estimate the failure content.

[0077] (Action and effect) As described above, according to the second embodiment, the following advantageous effects can be obtained.

[0078] In estimating the nature of the failure, it is possible to estimate the nature of the failure more accurately by using past repair histories of vehicles that are the same as or similar to vehicle 20. In addition, in estimating the nature of the failure, by using past repair histories of not only vehicles that are the same as vehicle 20 but also vehicles that are similar to vehicle 20, it is possible to use more repair histories in estimating the nature of the failure, thereby improving the accuracy of estimating the nature of the failure.

[0079] (Third embodiment) Next, a third embodiment will be described. In the following description, when the same reference numerals as those in the first and / or second embodiment are used, the same configuration as in the first and / or second embodiment is indicated, and the preceding description is referred to unless otherwise specified. Below, a description will be given of the configuration of the repair support device 100 according to the third embodiment, which estimates the fault content using a machine learning classifier, that is different from that of the first and / or second embodiment.

[0080] FIG. 10 is a functional block diagram for explaining a fault estimation unit 155 (learned model) created by learning the correspondence between the abnormality flag and the repair history based on the abnormality flag and the repair history in the repair support device 100 according to the third embodiment.

[0081] 10, the repair support device 100 according to the third embodiment is configured to include a learning unit 150 having a machine learning unit 152, and to perform learning using the abnormality flags stored in the abnormality flag DB 123 and the repair history stored in the repair history DB 129. The machine learning unit 152 performs machine learning using the abnormality flags stored in the abnormality flag DB 123 of the storage unit 120 and the repair history stored in the repair history DB 129, and generates a fault estimation unit 155 as a trained model (classifier).

[0082] In the third embodiment, the abnormality flags and the corresponding repair histories are used as supervised data and input data for the machine learning unit 152. The machine learning unit 152 learns what kind of repairs have been performed in the past for a certain abnormality flag. In other words, by learning the correspondence between the abnormality flags and the repair histories, the fault estimation unit 155, which is a so-called classifier that can accurately estimate the fault content, can be generated as a learned model.

[0083] A neural network model is used in the machine learning unit 152. The neural network model used in the machine learning unit 152 may be a deep neural network (DNN), a convolutional neural network (CNN), or a recurrent neural network (RNN, LSTM). However, the type of the neural network model is not limited to this embodiment.

[0084] 10, the learning unit 150 is shown as a configuration example provided as a component separate from the control unit 110, but the third embodiment is not limited to this configuration. For example, the learning unit 150 may be included in the control unit 110. Furthermore, the learning unit 150 is not limited to a configuration provided in the repair support device 100. For example, the learning unit 150 may read the abnormality flag and the repair history from the storage unit 120, and use these as learning sets, and have these learning sets learn in a system other than the server 10 to generate the fault estimation unit 155 as a learned model. In this case, the fault estimation unit 155 is assumed to be incorporated as a function into the repair support device 100 from outside the server 10 via the network IF 140.

[0085] (Action and effect) As described above, according to the third embodiment, the following advantageous effects can be obtained.

[0086] In estimating the nature of the failure, a trained model is generated that has been trained to learn the correspondence between the abnormality flag and the repair history, and this trained model is used as the failure estimation unit 155, making it possible to estimate the nature of the failure with greater accuracy.

[0087] (Other embodiments) As described above, the embodiment of the present invention has been described, but the description and drawings forming a part of this disclosure should not be understood as limiting this invention. From this disclosure, various alternative embodiments, examples and operating techniques will become apparent to those skilled in the art.

[0088] A computer program (repair assistance program) that causes a computer to execute the above-mentioned repair assistance method and a computer-readable recording medium on which the program is recorded are included in the scope of this embodiment. Here, the type of computer-readable recording medium is arbitrary. Furthermore, the above-mentioned computer program is not limited to one recorded on the above-mentioned recording medium, and may be one transmitted via a telecommunication line, a wireless or wired communication line, a network such as the Internet, or the like.

[0089] In the above-mentioned repair support system 1, the server 10 acquires an abnormality flag of the vehicle 20 from the electronic control unit 200 via the network 40, estimates the malfunction content based on the abnormality flag, and extracts a shop that has a part corresponding to the malfunction content. That is, in the above-mentioned embodiment, the repair support system 1 is configured as a so-called cloud computing. However, the configuration of the repair support system 1 is not limited to this. For example, the repair support system 1 may be provided with a repair support device 100 for each vehicle 20, receive an abnormality flag from the electronic control unit 200, estimate the malfunction content, identify the part content, and extract candidate shops. That is, the repair support system 1 may be configured as a so-called edge computing in which the vehicle 20 that acquires the abnormality flag is provided with the repair support device 100. FIG. 11 shows an example of the repair support system 1 configured as edge computing. In FIG. 11, the vehicle 20a is provided with the repair support device 100. That is, the repair support device 100 in the vehicle 20a is a device capable of communicating with the electronic control unit 200 through an in-vehicle network, and performs the functions shown in Fig. 4 in the vehicle 20a. Note that the in-vehicle network may be a Controller Area Network (CAN), a Local Interconnect Network (Lin), or FrexRay. The type of the in-vehicle network is not intended to limit the present embodiment.

[0090] 11 shows an example of a configuration in which the electronic control unit 200 is provided with the repair support device 100 in the vehicle 20b. In this case, the control unit 210 of the electronic control unit 200 performs each function of the control unit 110 of the repair support device 100 shown in FIG. 4. Furthermore, the storage unit 220 of the electronic control unit 200 has each DB of the storage unit 120 of the repair support device 100 shown in FIG. 4. As shown in FIG. 11, when the repair support device 100 is configured as an edge computing device provided in the vehicle 20a or 20b, the time required for exchanging data with the server 10 is shortened, and repair support corresponding to the abnormality flag can be performed more quickly. It is also possible to configure the function of the repair support device 100 to be performed by a user terminal 50. [Explanation of symbols]

[0091] 1 Repair Support System 10 Server 20 Vehicles 30 Store terminals 40 Network 50 User terminals 100 Repair support equipment 110 Control section 111 Store Information Acquisition Department 112 Location information acquisition unit 113 Driving route calculation unit 114 Abnormality flag acquisition unit 115, 155 Failure estimation section 116 Parts Identification Department 117 Candidate Store Extraction Department 118 Notification Department 119 Repair History Acquisition Department 120 Storage section 121 Store Information DB 122 Location information DB 123 Abnormal Flag DB 124 Failure details DB 125 candidate store database 129 Repair History DB 140 Network Interface 152 Machine Learning Department

Claims

1. a store information storage unit that stores store information indicating the locations and business hours of stores that have various parts used in vehicles; a location information acquisition unit that acquires location information of the vehicle; an abnormality flag acquisition unit that acquires an abnormality flag detected in the vehicle from the vehicle; a fault estimation unit that estimates fault contents of the vehicle, including both a fault that has already occurred and a fault that is predicted to occur in the future, based on the abnormality flag; a part identification unit that identifies part information corresponding to the fault content based on the fault content estimated by the fault estimation unit; a candidate store extraction unit that extracts candidate store information related to stores that can repair the vehicle based on the store information, the location information, the malfunction details, and the part information; a notification unit that notifies an in-vehicle terminal provided in the vehicle and / or a terminal of an occupant of the vehicle of the candidate store information, the candidate store extraction unit calculates a degree of urgency for repairing the vehicle based on the importance of the breakdown, an estimated time until the breakdown occurs, and a possibility of the breakdown occurring, and extracts the candidate store information based on the calculated degree of urgency. Repair support equipment.

2. A repair history storage unit that stores a repair history of the vehicle, The repair support device according to claim 1 , wherein the part identification unit identifies the part information required for repair based on the abnormality flags and the repair histories acquired from a plurality of the vehicles.

3. A repair history storage unit that stores a repair history of the vehicle, The repair assistance device according to claim 1 , wherein the failure estimation unit estimates the type of the failure based on the repair history of a vehicle similar to the vehicle in which the failure is detected.

4. A travel route calculation unit that calculates a travel route of the vehicle based on the position information of the vehicle, The repair support device according to claim 1 , wherein the candidate store extraction unit extracts the candidate store information based on the travel route, the store information, the location information, the malfunction content, and the part information.

5. The repair support device according to any one of claims 1 to 4, wherein the candidate store extraction unit determines whether or not there is an urgency to repair the vehicle based on the details of the failure, and if it determines that there is no urgency, extracts stores that have a history of being used for the vehicle as the candidate store information.

6. The repair support device according to any one of claims 1 to 5, wherein when the abnormality flag is acquired, if a store located near the vehicle does not have the parts necessary for repair, the candidate store extraction unit extracts a store that has a history of use for the vehicle as the candidate store information.

7. The repair support device according to any one of claims 1 to 6, wherein the notification unit notifies an occupant of the vehicle of a suggestion to repair the vehicle when the vehicle is next started if the candidate store extraction unit determines that there is no urgency in repairing the vehicle and if the use of the vehicle is terminated before repairs are made.

8. 1. A computer-implemented repair assistance method, comprising: Acquire vehicle location information, acquiring an abnormality flag detected in the vehicle from the vehicle; estimating the type of fault in the vehicle, including both a fault that has already occurred and a fault that is predicted to occur in the future, based on the abnormality flag; Identifying part information corresponding to the fault content based on the fault content; Calculating the urgency of repairing the vehicle based on the severity of the fault, the estimated time until the fault occurs, and the likelihood of the fault occurring; extracting candidate store information related to stores capable of repairing the vehicle based on store information indicating the locations and business hours of stores that have various parts used in the vehicle, which is stored in a storage unit, the location information, the malfunction content, the urgency, and the part information; A repair support method for notifying the candidate shop information to an in-vehicle terminal provided in the vehicle and / or a terminal of an occupant of the vehicle.

9. Acquire vehicle location information, acquiring an abnormality flag detected in the vehicle from the vehicle; estimating the type of fault in the vehicle, including both a fault that has already occurred and a fault that is predicted to occur in the future, based on the abnormality flag; Identifying part information corresponding to the fault content based on the fault content; Calculating the urgency of repairing the vehicle based on the severity of the fault, the estimated time until the fault occurs, and the likelihood of the fault occurring; extracting candidate store information related to stores capable of repairing the vehicle based on store information indicating the locations and business hours of stores that have various parts used in the vehicle, which is stored in a storage unit, the location information, the malfunction content, the urgency, and the part information; A repair support program for causing a computer to execute a process of notifying the candidate shop information to an in-vehicle terminal provided in the vehicle and / or a terminal of an occupant of the vehicle.

10. A computer-readable recording medium on which the program according to claim 9 is recorded.

Images