JP4337084B2 - Remote fault diagnosis system - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a remote failure diagnosis system that diagnoses a failure by connecting to a vehicle from a remote location.
[0002]
[Prior art]
Conventionally, various techniques for performing vehicle failure diagnosis are known (Patent Document 1). This Patent Document 1 discloses a failure diagnosis device that performs vehicle failure diagnosis using a select monitor (failure diagnosis device) arranged in a dealer service factory or the like. That is, in the invention described in this publication, first, an electronic control device that stores vehicle data such as data of on-vehicle sensors / switches and actuators is mounted on the vehicle. A monitor (fault diagnosis device) is arranged. This select monitor reads the internal data as these various vehicle data from the in-vehicle electronic control device, and also has its own measurement function, and reads out the self-measured vehicle data and the in-vehicle electronic control device. By displaying the internal data at the same time, it is possible to easily compare the corresponding data. In this way, the failure diagnosis apparatus described in this publication makes it possible to easily determine the validity of data read from an in-vehicle electronic control apparatus, and to improve diagnosis efficiency.
Patent Document 2 discloses a failure detection apparatus in which self-diagnosis information of a vehicle is stored in an ignition key, and a failure location, a failure state, and the like are analyzed in detail from diagnosis information read out from the ignition key. Yes. Specifically, in the invention described in this publication, when the ignition key is taken out from the cylinder lock, the transmitter of the vehicle outputs self-diagnosis information, and the receiver of the ignition key receives this information. Self-diagnosis information is stored in the memory of the ignition key. From the ignition key that stores this self-diagnosis information, the diagnostic information is read using a key information reader and input to a personal computer. The personal computer detects the fault location and failure state in detail. . According to the invention described in this publication, since the ignition key is the only part that is removed from the vehicle and carried, the dealer who took this key reads out the self-diagnosis information from the key and detects the failure location, failure state, etc. can do. Therefore, there is an effect that it is possible to immediately indicate the cost required for repairing a failure, replacement parts, etc., the delivery date of the vehicle, and the like.
In Patent Document 3, when failure diagnosis information based on abnormality due to vehicle self-diagnosis is wirelessly transmitted from the vehicle to the base station side, and then the vehicle abnormality corresponding to the failure diagnosis information is resolved (repaired) A vehicle diagnostic system is disclosed in which the abnormality elimination information (repaired code) is wirelessly transmitted from the vehicle to the base station. According to the invention described in this publication, when the base station receives the vehicle failure diagnosis information and the corresponding repaired code is received thereafter, the base station issues a request regarding the vehicle inspection / repair / maintenance to the user. This can be omitted, and wasteful processing between the vehicle and the base station can be eliminated.
[0003]
However, in each of the above-described prior arts, the vehicle itself has a failure diagnosis function, and the failure diagnosis information obtained by this self-failure diagnosis function is used as a means, for example, a failure diagnosis device (select monitor), an ignition key, etc. It is only intended to contact the outside, including dealers, via wireless transmission to the base station.
[0004]
On the other hand, Patent Document 4 proposes a failure diagnosis system that connects to a failed vehicle via a network and diagnoses the failure location. According to this conventional technology, the fault diagnosis system and the vehicle are connected remotely, so that the customer can know whether or not the vehicle is out of order without having to go to the service factory. is there.
[0005]
[Patent Document 1]
JP-A-10-10013
[Patent Document 2]
Japanese Patent Laid-Open No. 11-51817
[Patent Document 3]
JP-A-11-223578
[Patent Document 4]
JP 2002-228552 A.
[0006]
[Problems to be solved by the invention]
By the way, in order to perform failure diagnosis, it is necessary to sample vehicle data such as sensor output and control data that change every moment in a vehicle to be subjected to failure diagnosis, and transmit it to the failure diagnosis system.
[0007]
Furthermore, some types of failures may only be reproduced under certain driving conditions. For example, it is common to hear that an abnormality is felt during traveling and the vehicle is stored in a dealer or a maintenance shop, but the failure is not reproduced.
[0008]
Therefore, an object of the present invention is to reduce the burden on the user side and communication traffic regarding data necessary for vehicle failure diagnosis.
[0009]
[Means for Solving the Problems]
In order to achieve the above object, a remote fault diagnosis system according to the present invention is characterized by the following configuration.
[0015]
Invention of the present application In a remote failure diagnosis system that remotely performs failure diagnosis on a vehicle to be diagnosed and transmits the failure diagnosis result to a customer, the failure vehicle generates vehicle data of the failed vehicle necessary for failure diagnosis. A database to be stored together with the driving conditions when the database is updated, request means for requesting a plurality of faulty vehicles for vehicle data under a specific driving condition required for updating when an update request for the database is issued, and the fault Update means for updating the contents of the database based on vehicle data received from the vehicle.
[0016]
The above-described object can also be achieved by a remote failure diagnosis method corresponding to a remote failure diagnosis system having the above-described configurations.
[0017]
The object is also achieved by a program for realizing each means included in the remote fault diagnosis system by a computer and a computer-readable storage medium storing the program code.
[0018]
【The invention's effect】
According to the present invention, a remote failure diagnosis system, a remote failure diagnosis method, and a diagnosis target vehicle that can reduce the burden on the user side regarding data necessary for vehicle failure diagnosis and communication traffic as compared with the prior art are realized.
[0031]
Claim 1, 2, and 3 According to the invention described in the above, when updating the database for failure diagnosis, it is possible to request only vehicle data necessary for the update from the vehicle, so that the load related to the database update process is reduced. it can.
[0032]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, an embodiment of a remote fault diagnosis system according to the present invention will be described in detail with reference to the drawings. In the following, there may be embodiments that seem to be not described in the scope of claims, but these are not intentionally excluded. For example, since it is equivalent to the invention described in the claims, it may not be described in the claims.
[0033]
[First Embodiment]
FIG. 1 is a diagram illustrating a configuration example of a system according to the present embodiment. The information center 100 is a computer group that accumulates various types of information transmitted from the customers' vehicles 110 and 111, the service factory 120, and the like and provides a failure diagnosis result. The information center 100 is connected to the customer's vehicle 110 and the service factory 120 via the Internet 130, a mobile communication line, or the like.
[0034]
The customer vehicles 110 and 111 acquire data necessary for failure diagnosis and transmit the data to the information center 100.
[0035]
The service factory 120 is a so-called repair factory or the like, and reads vehicle data from the failed vehicle 111 and transmits information about the location of the failure and the cause of the failure to the information center 100. A client device for the service factory is set in the service factory. This client device is a kind of computer, and includes a CPU, a memory, a hard disk drive, a communication interface, and the like. In the following description, various processes are executed by the CPU executing a program corresponding to the flowchart.
[0036]
The information center 100 includes a failure diagnosis server 101 that executes failure diagnosis processing, a customer information database 102 that stores information on customers (all customers or contractors of failure diagnosis services), and information on failure vehicles 111 and service factories. Stores failure information database 103 that stores failure data transmitted from client device 121, vehicle information database 104 that stores vehicle data transmitted from customer's vehicles 110 and 111, and information related to the location of a service factory, etc. A service factory database 105, a map database 106 storing map data, and a diagnostic program database 107 storing various programs for diagnosing failures are included.
[0037]
The failure diagnosis server 101 is a kind of computer, and includes a CPU, a memory, a hard disk drive, a communication interface, and the like. In the following description, various processes are executed by the CPU executing a program corresponding to the flowchart.
[0038]
The failure diagnosis server 101 determines, for example, a determination unit (e.g., a CPU of the failure diagnosis server 101) that determines a traveling condition necessary for executing a failure diagnosis for a predetermined failure, and the determined traveling condition Transmission means for transmitting to the diagnosis target vehicle 110 (for example, communication interface of the failure diagnosis server 101) and reception means for receiving vehicle data acquired in accordance with the travel conditions from the diagnosis target vehicle (for example, failure) A communication interface of the diagnosis server 101), a failure diagnosis unit (for example, a CPU of the failure diagnosis server 101) for executing a failure diagnosis for the predetermined failure based on the received vehicle data, and a failure diagnosis by the failure diagnosis unit A notification means (for example, a communication interface of the failure diagnosis server 101) for notifying a customer of the diagnosis target vehicle of the result; Fault diagnosis system having is realized.
[0039]
FIG. 2 is a block diagram illustrating a configuration example of the vehicle according to the present embodiment. The remote vehicle client device 200 is a main controller including a CPU, a memory, and the like. The remote vehicle client device 200 acquires control data and sensor output from various control units and sensors, stores the data in the memory, and stores the stored information in a mobile terminal (mobile communication interface). ) 250 or the short-range wireless communication interface 255 to transmit to the information center 100 or receive a failure prediction result from the information center 100. The short-range wireless communication interface 225 can employ wireless standards such as wireless LAN, Bluetooth, and ETC.
[0040]
The body system 210 includes a power window unit 211, a headlight unit 212, an audio unit 213, an air conditioner unit 214, a wiper unit 215, a door lock unit 216, and the like. Output to 200.
[0041]
The control system 220 includes an ABS (anti-lock brake system) 221 that controls the brake not to lock, a DSC (dynamic stability controller) 222 that controls the behavior of the vehicle, and an EGI that controls fuel supply. (Electric Gas Injection) 223, EAT (Electric Automatic Transmission) 224 for controlling an automatic transmission, ICCW (Intelligent Cruise Control & Warning) 225 for assisting driving of a driver such as automatic driving, etc. The control result is notified to the client device 220.
[0042]
Various sensors are mounted on the vehicle. For example, a GPS sensor 231 that receives a radio wave from a GPS (Global Positioning System) satellite to calculate the current position of the vehicle, a VICS information receiver 232 that receives traffic jam information, and a vehicle speed sensor 233 that detects the speed of the vehicle. An inter-vehicle distance sensor 234 that measures the distance to other vehicles such as a vehicle ahead, a yaw rate sensor 235 that detects the yaw rate of the vehicle, an acceleration sensor that detects the acceleration of the vehicle, a steering angle sensor 237 that detects the steering angle of the vehicle, A throttle opening sensor 238 that detects the opening of the throttle, a brake pressure sensor 239 that detects the depression pressure of the brake, a winker SW sensor 240 that detects the operating state of the winker switch, an outside air temperature sensor 241 that measures the outside air temperature, and A rain sensor 24 that measures whether or not it is raining or rain Such as is mounted on the vehicle.
[0043]
The navigation controller 260 is a device that searches map information stored in a hard disk drive or the like based on the positioning data from the GPS sensor 231 and displays a map of the current position. The input / output device 270 for the driver as a customer includes a display device such as a liquid crystal display and a voice main device, and outputs map data from the navigation controller 260 and outputs a failure diagnosis result from the information center 100. To do.
[0044]
With the vehicle shown in FIG. 2, means (for example, mobile communication interface 250, short-range wireless communication interface 255, etc.) for receiving the traveling conditions from a remote failure diagnosis system (for example, failure diagnosis server 101), and the reception Means for acquiring vehicle data in accordance with the travel conditions (for example, the client device for vehicle 200, the GPS sensor 231 and the like) and means for transmitting the acquired vehicle data to the remote fault diagnosis system (for example, mobile) Communication interface 250 and short-range wireless communication interface 255), means for receiving a failure diagnosis result from the remote failure diagnosis system (eg, mobile communication interface 250 and short-range wireless communication interface 255), and the received failure Means for outputting a diagnosis result (eg, input / output device 270); Diagnosed vehicle including is realized.
[0045]
FIG. 3 is a diagram illustrating a configuration example of the service factory 120. The service factory client 121 reads out the failure diagnosis information from the tester 301 and the vehicle data before the occurrence of the failure stored in the vehicle client device 200 mounted on the failed vehicle 111 and indicates the failure that has occurred. It is a computer that transmits to the information center 100 together with an identification code. The service factory client 121 also includes a communication interface for communicating with the information center 100. When communicating with the vehicle, for example, the vehicle 111 can be connected via the short-range wireless communication interface 310. The tester 301 is a device that performs a detailed failure diagnosis by connecting to a connector provided in the failed vehicle.
[0046]
FIG. 4 is a flowchart regarding collection of vehicle data according to the present embodiment. In particular, in the flowchart, the vehicle data including normal vehicle data is collected and a vehicle information database is created. In other words, if there is vehicle data of a normal vehicle, it becomes easier to find the characteristics of the vehicle data of the failed vehicle, which is useful for creating a failure model to be used at the time of failure diagnosis and determining driving conditions for a specific failure. .
[0047]
In step S400, the CPU mounted on the vehicle client device 200 samples outputs from various sensors and units at appropriate timings and stores them in a memory.
[0048]
In step S402, the CPU mounted on the vehicle client device 200 has a predetermined timing (for example, periodically, when the engine is started, after a predetermined time has elapsed, and when an explicit instruction from the driver is input). ), The vehicle data stored in the memory is read out, information for identifying the vehicle or driver is added, and the information is transmitted to the information center 100 via the mobile communication interface 250 or the short-range wireless communication interface 255.
[0049]
In step S410, the failure diagnosis server 101 of the information center 100 receives vehicle data transmitted from the vehicle via a mobile communication interface or the like. In step S412, the failure diagnosis server 101 stores the received vehicle data in the vehicle information database 104 in association with information for specifying the corresponding vehicle or driver.
[0050]
Through the above procedure, vehicle data for a normal vehicle that has not failed is stored in the vehicle database 104.
[0051]
FIG. 5 is a flowchart relating to the collection of failure data used for failure diagnosis. There are roughly two methods for collecting failure data. One is a method of reading out failure data from a failed vehicle and writing it into the failure information database 103 (steps S500 and S502). The other is a method in which the failure data is read from the failed vehicle 111 by the client device 121 of the service factory where the failed vehicle 111 is received and then written into the failure information database 103 from the client device 121 of the service factory (S510, S512).
[0052]
In step S500, the vehicular client device 200 mounted on the failed vehicle 111 is designated by the customer who has recognized the occurrence of the failure to transmit failure data or when an abnormality is detected in various control devices (for example, a warning) When the lamp is lit), the driving conditions at the time of failure, the time of occurrence of the failure, the vehicle number (body number), the failure identification code, etc. are read from the memory, and failure data is created. The failure occurrence time and the failure identification code may be input by the customer operating the input / output device 270, or a failure code corresponding to a warning lamp or the like may be input. Information useful for identifying a vehicle such as a vehicle number may be read out from information stored in a ROM, for example.
[0053]
When the vehicle client apparatus 200 is equipped with a failure diagnosis program, the failure diagnosis program is executed, so that the vehicle client device 200 is constantly or regularly or at a predetermined timing (such as when a switch is operated) from various sensors or units. When the occurrence of a failure is detected by acquiring data and detecting the occurrence of a failure, the driving conditions at the time of the failure, the time of occurrence of the failure, and a failure identification code corresponding to the failure that has occurred are determined, and failure data is created, It can be uploaded to the information center 100.
[0054]
In step S <b> 502, the vehicle client device 200 transmits the vehicle data and failure data stored in the memory to the failure diagnosis server 101 in the information center 100. In step S <b> 504, the failure diagnosis server 101 receives vehicle data and failure data via the Internet 130. In step S506, the failure diagnosis server 101 stores the received vehicle data in the vehicle information database 104. In step S508, the failure diagnosis server 101 stores the received failure data in the vehicle information database.
[0055]
As described above, failure data and vehicle data, which are determination elements for use in failure diagnosis, are stored in each database. Although failure data and vehicle data can be said to be failure models, in the data mining method, this failure model is constantly changing as data is added from time to time, and compared with other data. It is decided at the stage. In that sense, the process in which the failure diagnosis server 101 registers the received failure data in the failure information database 103 and the vehicle information database 104, and the process of extracting desired vehicle data from them corresponds to the failure model creation process. No.
[0056]
Incidentally, failure data and vehicle data may be collected from the service factory 120. In step S510, the tester 301 is connected to the failed vehicle 111, and failure diagnosis is performed. In this failure diagnosis, the tester 301 and / or the client device 121 reads vehicle data stored in the memory of the failed vehicle 111 and performs a detailed investigation, or transmits a specific inspection signal to various units. Then, failure data is created, for example, by checking response data from various units.
[0057]
The service factory client 121 may connect to the failed vehicle 111 via the wireless communication interface 310 and read the vehicle data stored in the memory. In this case, the service factory client device 121 further includes Failure data may be created by executing a diagnostic program and diagnosing the failure location in detail. In step S512, the client device 121 for the service factory transmits the created failure data and vehicle data read from the failed vehicle to the failure diagnosis server 101 of the information center 100. Thereafter, the processing after step S504 is executed.
[0058]
In this way, two methods for collecting failure data are exemplified. However, the latter method can use a specialized diagnostic device that is too expensive to be mounted on a vehicle, so that there may be an advantage that a more detailed diagnosis result can be obtained. .
[0059]
FIG. 6 is a flowchart of the remote fault diagnosis process according to this embodiment.
[0060]
In step S <b> 600, when detecting that a failure diagnosis request has been input from the input / output device 270, the vehicle client device 200 transmits a failure diagnosis request to the failure diagnosis server 101 of the information center 100. The failure diagnosis trigger is not only triggered by the driver, but may be triggered periodically or when the vehicle client device 200 satisfies a certain condition, or the failure diagnosis server 101 periodically or It may be triggered when a specific condition is satisfied, or may be triggered when a failure is detected by a failure detection device mounted on the vehicle (the warning lamp is lit). Note that when the type of failure to be diagnosed is designated from the input / output device 270, the vehicle client device 200 includes the designated failure type (fault code or the like) in the failure diagnosis request. .
[0061]
In step S602, the failure diagnosis server 101 receives a failure diagnosis request via the communication interface.
[0062]
In step S604, the failure diagnosis server 101 determines the type of failure to be diagnosed. For example, the determination may be made based on information regarding the type of failure included in the failure diagnosis request. There may be one or more types of failures. When the type of failure is not included in the failure diagnosis request, all failures that can be diagnosed (for example, i = 0th failure code to i = nth failure code) may be determined as targets, Alternatively, it may be narrowed down to failures with a high degree of urgency.
[0063]
In step S606, the failure diagnosis server 101 determines a traveling condition corresponding to the failure determined as the diagnosis target. Two or more traveling conditions may be determined.
[0064]
FIG. 7 is a diagram showing the contents of the failure information database and the vehicle information database and the concept of failure diagnosis. For example, when a failure represented as the failure code E0001 is determined as a diagnosis target, the failure diagnosis server 101 refers to the failure information database 103 and extracts a traveling condition corresponding to the failure code E0001. In this example, the traveling condition is that the vehicle travels on a 130R curve at a speed of 50 km / h.
[0065]
In step S <b> 608, the vehicle diagnosis server 101 transmits information regarding the determined traveling condition to the diagnosis target vehicle 110. The vehicle diagnosis server 101 may add an identification number (travel condition ID) to the travel condition, and register the vehicle number of the diagnosis target vehicle and the transmitted travel condition ID in association with each other in the database. Good. Since it may be assumed that it takes a long time for the diagnosis target vehicle to meet the driving conditions, the fault diagnosis server 101 side determines which vehicle is the diagnosis target vehicle and what driving condition is being diagnosed. Because it is necessary to manage with.
[0066]
In step S610, the vehicle client device 200 receives information related to the driving conditions via the mobile communication interface 250 and stores the information in a storage device such as a RAM.
[0067]
In step S612, the vehicle client device 200 determines whether or not the output data from the sensor or the control device related to the traveling condition satisfies the traveling condition stored in the RAM, and waits until it is satisfied. . For example, if the traveling condition is that the vehicle is traveling at a speed of 50 km / h on a 130R curve, whether the vehicle is traveling on a curve that is approximately 130R by the navigation controller 260 based on information from the GPS sensor 231. To determine whether the output of the vehicle speed sensor 233 is approximately 50 km / h. When these conditions are satisfied, the process exits the standby loop and proceeds to the next step.
[0068]
In step S614, the vehicle client device 200 creates vehicle data by sampling outputs from various sensors and control devices, and stores the vehicle data in a storage device such as a RAM or a hard disk.
[0069]
In step S <b> 616, the vehicle client device 200 reads vehicle data from the storage device and transmits the vehicle data to the failure diagnosis server 101.
[0070]
In step S618, the failure diagnosis server 101 receives the vehicle data via the communication interface and stores it in the vehicle information database. In the example of FIG. 7, a number for specifying a vehicle, a yaw rate that is an example of vehicle data, a traveling condition when the vehicle data is acquired, and the like are stored in the vehicle information database 104.
[0071]
In step S620, the vehicle diagnosis server 101 determines whether or not a failure has occurred in the diagnosis target vehicle 110 based on the vehicle data of the failed vehicle and the vehicle data of the diagnosis target vehicle.
[0072]
In step S622, the vehicle diagnosis server 101 transmits information on the failure diagnosis result to the diagnosis target vehicle 110.
[0073]
In step S624, the vehicle client device 200 receives information related to the failure diagnosis result.
[0074]
In step S <b> 626, the vehicle client device 200 outputs the received failure diagnosis result from the input / output device 270.
[0075]
Remote fault diagnosis is executed according to the above flow. The remote diagnosis process is terminated when the diagnosis result is received. At that time, the vehicular client device 200 deletes the traveling condition stored in the storage device. This is because, unless it is deleted, this traveling condition is always valid, and vehicle data is acquired and transmitted when the traveling condition is satisfied.
[0076]
Note that the vehicle client device 200 may execute deletion of a specific traveling condition when a predetermined deletion condition is satisfied, such as when a command for deleting a traveling condition is received from the failure diagnosis server 101. Further, the vehicle client device 200 may continue to acquire and transmit vehicle data every time the vehicle condition is met, until a vehicle data transmission end command is received from the failure diagnosis server 101.
[0077]
FIG. 8 is a detailed flowchart of the failure diagnosis process. In step S800, the failure diagnosis server 101 extracts the vehicle data of the diagnosis target vehicle 110 from the vehicle information database 104 for the i-th failure (the initial value of i is 0) that is the diagnosis target. If it demonstrates using the example of FIG. 7, the vehicle data corresponding from the vehicle number of the diagnostic object vehicle 110 and driving conditions will be specified and read.
[0078]
In step S <b> 802, the failure diagnosis server 101 extracts vehicle data of the failed vehicle 111 from the vehicle information database 104 for the i-th failure (the initial value of i is 0) that is a diagnosis target. If it demonstrates using the example of FIG. 7, the vehicle data corresponding from the vehicle number of the failure vehicle 111 and driving conditions will be specified and read.
[0079]
In step S804, the failure diagnosis server 101 compares the read vehicle data of the diagnosis target vehicle 110 with the vehicle data of the failed vehicle 111, and the two are identical to the extent that it is considered that a similar failure has occurred. Or, it is determined whether they are similar. If they are the same or similar, the process proceeds to step S806, and if not, the process proceeds to step S708. In failure diagnosis, it may be compared with vehicle data of other normal vehicles. That is, failure diagnosis server 1010 compares the vehicle data of other normal vehicles with the vehicle data of diagnosis target vehicle 110, and determines that an abnormality (failure) has occurred if it is not statistically within the error range. . Or you may compare with the vehicle data of both a failure vehicle and a normal vehicle, and may determine which is similar. As specific data processing, a data mining technique such as MBR (Memory Based Reasoning) can be used. When MBR is applied, since a failure model and a normal model are created by directly using a large amount of failure data and vehicle data, there is an advantage that prior modeling is unnecessary as in other methods. Therefore, a new failure diagnosis that did not exist in the past can also be realized by adding new failure data as needed without changing the system. In addition, since failure diagnosis is executed based on past failure facts (failure data), the grounds for failure are clear and the reliability of failure diagnosis will be higher than in the prior art. Furthermore, since inference is performed on a subset of data (for example, vehicle data having the following time width T), it is also strong against noise.
[0080]
In step S806, the failure diagnosis server 101 adds the i-th failure identification code to the failure list. The failure list is stored in a storage means such as a memory or a hard disk drive.
[0081]
In step S808, it is determined whether failure diagnosis has been completed for all failure codes. If not completed, the value of i is incremented in step S830, the process returns to step S800, and the failure diagnosis is performed for the next failure identification code.
[0082]
In step S810, the failure diagnosis server 101 reads out the failure list stored in the storage unit and determines which failure identification code is registered. If any failure identification code is registered, it means that a failure corresponding to the failure identification code has occurred. If no failure code is registered, the process proceeds to step S822. If even one failure is found, the process proceeds to step S820.
[0083]
In step S820, the failure diagnosis server 101 creates a failure diagnosis result (prediction report) for reporting to the driver. For example, the failure identification codes registered in the failure list may be sorted according to the degree of urgency to create a failure diagnosis result. This failure diagnosis result may include, for example, all the detected failures, or only those that cause troubles in operation or have high urgency that is directly related to safety. May be. This is because there may be a driver who is overly worried when notifying a low urgency level, so there is an advantage of notifying only a high level urgency level.
[0084]
If the urgency level of the failure is high, a failure diagnosis result reflecting the urgency level may be created. This makes it easier for the driver to grasp the degree of urgency.
[0085]
In step S822, the failure diagnosis server 101 creates a diagnosis result indicating no failure and stores it in the storage unit. As a result of the diagnosis, for example, “The occurrence of a failure could not be confirmed. Please enjoy a comfortable driving.” Or “The occurrence of a failure could not be confirmed at this time. Is not guaranteed. "Or" The occurrence of a failure could not be confirmed at this time. However, since a failure may occur unexpectedly, be sure to perform a pre-service inspection and periodic inspection. " Should be the message.
[0086]
As described above, in the invention according to the present embodiment, it is only necessary to transmit the vehicle data of the diagnosis target vehicle when the specific traveling condition is met. Therefore, it is possible to reduce the load on the vehicle side and the server side than before, Furthermore, communication traffic can be reduced. In addition, there is an advantage that a failure that occurs only under a specific driving condition can be found efficiently.
[0087]
[Second Embodiment]
A second embodiment based on the remote fault diagnosis system according to the first embodiment described above will be described. In the following description, the description similar to that of the first embodiment will be omitted, and the description will focus on the characteristic part of the present embodiment.
[0088]
In the second embodiment, simple diagnosis is executed based on normal vehicle data, and when it is determined that detailed diagnosis is necessary, vehicle data is acquired by specifying a driving condition or the like, and detailed diagnosis is performed. Is to execute.
[0089]
FIG. 9 is a flowchart regarding failure diagnosis according to the second embodiment. Steps common to FIGS. 4 and 6 are given the same reference numerals to simplify the description. Assume that the diagnosis target vehicle 110 transmits vehicle data at a predetermined timing in step S400, and the failure diagnosis server 101 receives the vehicle data in step S410. Note that since the vehicle data at this time does not specify the driving conditions or the like, the data amount may be reduced by increasing the sampling interval.
[0090]
In step S904, the failure diagnosis server 101 performs failure diagnosis based on the received vehicle data. The failure diagnosis here is executed according to the flowchart shown in FIG.
[0091]
In step S905, the failure diagnosis server 101 determines whether more detailed diagnosis is necessary based on the failure diagnosis result. For example, if the comparison result does not indicate a numerical value that can be determined to be a failure, but close to it, it is determined that a detailed diagnosis is necessary. Here, the numerical value is a value indicating the degree of coincidence between the vehicle data of the failed vehicle and the vehicle data of the diagnosis target vehicle, and a correlation value obtained by a correlation calculation or the like can be adopted. As a result of the determination, if a detailed diagnosis is necessary, the process proceeds to step S606, and a traveling condition corresponding to the failure subjected to the detailed diagnosis is determined. On the other hand, if detailed diagnosis is unnecessary, the process proceeds to step S622.
[0092]
As described above, according to the present embodiment, a remote failure diagnosis system (for example, the failure diagnosis server 101) that performs failure diagnosis remotely on a diagnosis target vehicle 110 and transmits a failure diagnosis result to a customer is provided. First failure diagnosis means (for example, CPU of failure diagnosis server 101, step S904) for executing failure diagnosis for a predetermined failure based on vehicle data received from the diagnosis target vehicle 110, and the result of the failure diagnosis Based on the determination means (e.g., CPU of the failure diagnosis server 101, step S905) for determining whether more detailed failure diagnosis is necessary, and when it is determined that more detailed failure diagnosis is required, the more detailed failure diagnosis is performed. Requesting means for requesting vehicle data under specific driving conditions required when executing (e.g., CPU of failure diagnosis server 101, step S608), Receiving means (for example, step S618) for receiving vehicle data acquired in accordance with driving conditions from the diagnosis object vehicle, and based on the received vehicle data, more detailed than the first failure diagnosing means. Second failure diagnosis means for executing failure diagnosis (e.g., CPU of failure diagnosis server 101, step S620), and notification for notifying a customer of the diagnosis target vehicle of a failure diagnosis result by the second failure diagnosis means There is provided a remote fault diagnosis system having means and (example: CPU of fault diagnosis server 101, step S622).
[0093]
Further, in this embodiment, for example, when vehicle data is transmitted at a regular timing or the like, failure diagnosis can be performed. Therefore, even when the driver has forgotten to perform failure diagnosis, the failure is automatically performed. Diagnostic results can be reported.
[0094]
Also, during normal failure diagnosis, simple diagnosis is performed using vehicle data with a small amount of data, and when the possibility of failure is confirmed, more detailed vehicle data is acquired by specifying driving conditions and the like. By executing the failure diagnosis, the data size of the vehicle data can be suppressed during normal times. Further, since vehicle data for detailed diagnosis is transmitted when the driving conditions are met, the amount of vehicle data transmitted in total can be reduced over a long period of time. Furthermore, it is possible to efficiently find faults that are easily reproduced under specific driving conditions.
[0095]
[Third Embodiment]
In the above-described embodiment, the failure diagnosis is triggered mainly from the diagnostic vehicle side. However, the present invention is not limited to this, and can be triggered from the information center 100 side.
[0096]
FIG. 10 is a flowchart of failure diagnosis according to the third embodiment. Steps S600 and S602 in FIG. 6 are replaced with step S1002. In step S1002, the failure diagnosis server 101 determines whether it is a predetermined timing at which diagnosis should be started. The predetermined timing may be a periodic timing such as once a week, a timing when a request is made from the quality department, or a time when the use of automobiles increases such as the first day of consecutive holidays. . Alternatively, the previous diagnosis time is stored in the storage device, and a diagnosis request is transmitted from the vehicle side even after a certain period from there.
As described above, in the present embodiment, even when there is no diagnosis request from the vehicle or the user side, the failure diagnosis server 101 starts the diagnosis at the required time, so that the driver executes the failure diagnosis. Even when you are forgotten, you can automatically report failure diagnosis results. In addition, since the operation on the user side at the start of diagnosis becomes unnecessary, the usability for the user will be improved.
[0097]
If no failure is found, the failure diagnosis server 101 may terminate without notifying the driver of the diagnosis result. Thereby, it is possible to suppress unnecessary information from being transmitted to the driver. Further, in this embodiment, since the failure diagnosis is performed without the driver being conscious, it is preferable to keep the driver unaware as it is when the occurrence of the failure is not found. unknown.
[0098]
[Fourth Embodiment]
In this embodiment, useless traffic caused by transmission of the same or similar vehicle data each time is suppressed, and failure diagnosis is performed efficiently. FIG. 11 is a flowchart of failure diagnosis processing according to the present embodiment. In the flowcharts shown in FIGS. 6, 9, and 10, processing unique to the present embodiment is added between step S <b> 610 and step S <b> 612.
[0099]
In step S <b> 1111, the vehicle client device 200 reads the previous diagnosis time stored in advance in the storage device, compares the diagnosis time with the current time, and determines whether a predetermined time has elapsed. . If the predetermined time has elapsed, the process proceeds to step S612, and vehicle data that matches the traveling conditions is acquired. Otherwise, it is considered that the current vehicle data is not significantly different from the previous vehicle data, and therefore, the system waits for a predetermined time. The predetermined time may be, for example, a unit of one day or one week, or may be set to a time at which a significant change appears empirically.
[0100]
As described above, in this embodiment, since the vehicle data is acquired and the failure diagnosis is executed after waiting for a predetermined time from the previous diagnosis time, the same diagnosis result as the previous time is obtained because there is not much change in the vehicle data. It is possible to avoid such a situation. That is, since acquisition and transmission of vehicle data are executed when a meaningful diagnosis result is obtained, there is an advantage that acquisition and transmission of useless vehicle data can be omitted.
[0101]
Note that the purpose of step S1002 is achieved by waiting until a predetermined time elapses, but other methods may be used. For example, the vehicle client device 200 stores the previous vehicle data in a storage device such as a hard disk drive, compares the vehicle data acquired this time with the previous vehicle data, and is substantially different. In this case, the current vehicle data may be transmitted to the failure diagnosis server 101.
[0102]
Further, instead of the predetermined time, it may be a condition that the vehicle has traveled beyond a predetermined distance since the previous diagnosis. If the vehicle client device 200 stores the value of the mileage meter at the time of the previous diagnosis in the storage device and determines whether or not the vehicle has traveled beyond a predetermined distance such as 100 km or 1000 km. Good.
[0103]
Further, the vehicle client device 200 may appropriately correct the predetermined time. For example, the vehicle client device 200 compares the vehicle data acquired this time with the previous vehicle data. If the vehicle data is not substantially different, the vehicle client device 200 transmits the vehicle data and sets a predetermined time from the conventional time. Set too long. Thus, when there is not much change in the vehicle data, it is useless to frequently transmit the vehicle data, so the transmission timing may be gradually increased. Note that the size of the vehicle data transmitted at a time can be reduced by setting the sampling period longer than before instead of changing the transmission period. The failure diagnosis server 101 may make the same determination and instruct the vehicle client device 200 to change the predetermined time.
[0104]
As described above, according to the present embodiment, since the vehicle client device 200 prohibits transmission of vehicle data until a predetermined condition is satisfied, useless communication is suppressed.
[0105]
[Fifth Embodiment]
The object of the present embodiment is to efficiently update the failure information database 103. FIG. 12 is a flowchart relating to the update process of the failure information database 103 according to the present embodiment.
[0106]
In step S1200, the failure diagnosis server 101 determines whether an update request has been input. This update request may be input from the operation unit by the administrator of the failure diagnosis server 101, or an update request from a computer in the quality department may be input to the failure diagnosis server 101. Moreover, you may designate what kind of failure the failure information is updated. When specifying, a failure code can be specified.
[0107]
In step S1202, the failure diagnosis server 101 determines whether the failure to be updated is highly reproducible under a specific driving condition. For example, the failure diagnosis server 101 searches the failure information database 103 using the specified failure code as a search key, and determines whether or not a specific traveling condition is registered. If the specific traveling condition is registered, the process proceeds to step S606, and the specific traveling condition extracted by the search is determined as the traveling condition for acquiring the vehicle data. Otherwise, the process proceeds to step S614, and the failure diagnosis server 101 causes the vehicle client device 200 of the failed vehicle 111 to acquire and transmit vehicle data without specially specifying the traveling conditions.
[0108]
In step S1220, the failure diagnosis server 101 updates the failure information database 103 and the vehicle information database 104 based on the vehicle data received from the vehicle client device 200 of the failed vehicle 111.
[0109]
As described above, according to the present embodiment, in the remote failure diagnosis system (for example, the failure diagnosis server 101) that performs failure diagnosis remotely on the diagnosis target vehicle 110 and transmits the failure diagnosis result to the customer, the failure diagnosis is performed. A database (eg, failure information database 103, vehicle information database 104) that stores vehicle data of a faulty vehicle that is necessary for the vehicle, and when a database update request is issued, a specific vehicle data that is required for the update is specified. Request means for requesting one or more faulty vehicles for vehicle data under traveling conditions (eg, step S608) and update means for updating the contents of the database based on the vehicle data received from the faulty vehicle (eg, S1220) A remote fault diagnosis system is provided.
[0110]
According to the present embodiment, since various driving conditions can be designated according to the type of failure, vehicle data can be efficiently updated for failures that are not reproduced under specific driving conditions.
[0111]
[Sixth Embodiment]
In the present embodiment, when executing detailed diagnosis based on the remote failure diagnosis flowchart of FIG. 9, vehicle data is requested again when vehicle data under a specific driving condition is necessary, and the current vehicle when it is not necessary It is a flowchart which performs detailed diagnosis based on data. Note that portions already described in the description of FIG. 9 are omitted.
[0112]
FIG. 13 is a flowchart of remote failure diagnosis according to the sixth embodiment. If it is determined in step S905 that detailed diagnosis is necessary, the process proceeds to step S1306. In step S1306, the failure diagnosis server 101 can perform detailed diagnosis with the currently obtained vehicle data according to the type of failure subjected to detailed diagnosis, or vehicle data under a specific traveling condition. If there is no, it is determined whether the detailed diagnosis can be executed. For example, the determination may be made based on whether or not traveling conditions for executing the detailed diagnosis are registered in the failure information database 103 in association with the failure code.
[0113]
As a result of the determination, if vehicle data under a specific traveling condition is necessary, the process proceeds to step S606 and subsequent steps. If not required, the process proceeds to step S620, and a detailed diagnosis is executed with the currently acquired vehicle data.
[0114]
As described above, according to the present embodiment, the simple diagnosis, the detailed diagnosis, and the detailed diagnosis using the vehicle data under the specific traveling condition are selectively used according to the type of failure, so that the vehicle side and the system side can be used. It is possible to reduce the load and further reduce communication traffic.
[0115]
[Other Embodiments]
In the above-described embodiment, all vehicle data including the failed vehicle is accumulated in the vehicle information database 104. However, the vehicle data of the failed vehicle may be stored in the failure information database 103. Considering the number of vehicles in use, the amount of vehicle data may become enormous, so old information must be deleted from the vehicle information database 103 as needed. Therefore, the storage amount of the vehicle information database 103 can be reduced by leaving the failure information database 103 with only the vehicle data of the really necessary failed vehicle.
[0116]
The travel condition can be specified by latitude / longitude information for each time included in the vehicle data, speed information, acceleration information, night or day, temperature, rain or sunny. For example, the failure diagnosis server 110 specifies the position when the vehicle data is acquired from the latitude / longitude information, and further determines whether the position is a highway, a 130R curve, or a slope with a slope of 15 degrees from the map database. Specify the driving conditions such as
[0117]
The failure diagnosis result may be transmitted directly from the failure diagnosis server 110 to the vehicle client device 200, but may be transmitted to the customer as an e-mail. For example, the failure diagnosis server 110 searches the customer database 102 based on the vehicle number of the failure diagnosis target vehicle 110 and extracts the customer's e-mail address. Then, the failure diagnosis server 110 transmits a diagnosis result to the extracted e-mail address.
[0118]
If a plurality of e-mail addresses are registered in the customer database, such as the e-mail address of the company to which the driver belongs, in addition to the e-mail address of the driver, the failure diagnosis server 110 is not limited to the driver. Since the diagnosis results can be distributed to the company to which the driver belongs, the company as a whole has the advantage of being useful for safety management.
[0119]
In addition to the above driving conditions, the failure diagnosis server 101 can specify the sampling period and the sampling time, so that the size of the vehicle data can be adjusted.
[0120]
Moreover, the failure diagnosis server 101 may simultaneously transmit a plurality of traveling conditions to the vehicle client device 200. The vehicle client device 200 acquires vehicle data and stores it in a storage device whenever there is a match among a plurality of driving conditions. Note that the acquired storage device may be transmitted for each traveling condition, or may be transmitted when all traveling conditions are met.
[Brief description of the drawings]
FIG. 1 is a diagram illustrating a configuration example of a system according to an embodiment.
FIG. 2 is a block diagram illustrating a configuration example of a vehicle according to the present embodiment.
FIG. 3 is a diagram illustrating a configuration example of a service factory 120;
FIG. 4 is a flowchart regarding collection of vehicle data according to the present embodiment.
FIG. 5 is a flowchart relating to collection of failure data used for failure diagnosis.
FIG. 6 is a flowchart of a remote failure diagnosis process according to the first embodiment.
FIG. 7 is a diagram showing the contents of a database and the concept of failure diagnosis processing according to the present embodiment.
FIG. 8 is a detailed flowchart of a failure diagnosis process according to the present embodiment.
FIG. 9 is a flowchart of a remote fault diagnosis process according to the second embodiment.
FIG. 10 is a flowchart of a remote failure diagnosis process according to the third embodiment.
FIG. 11 is a flowchart of a remote fault diagnosis process according to the fourth embodiment.
FIG. 12 is a flowchart of database update processing according to the fifth embodiment;
FIG. 11 is a flowchart of a remote fault diagnosis process according to the sixth embodiment.
[Explanation of symbols]
100 ... Information Center
101 ... Failure diagnosis server
110 ... Vehicle subject to failure diagnosis
111 ... Faulty vehicle
120 ... Service factory
121 ... Client for service factory

Claims (3)

In the remote failure diagnosis system that performs failure diagnosis remotely on the vehicle to be diagnosed and sends the failure diagnosis result to the customer,
A database for storing vehicle data of a failed vehicle required for failure diagnosis together with a running condition when a failure occurs in the failed vehicle;
When an update request for the database is issued, request means for requesting a plurality of faulty vehicles for vehicle data under a specific traveling condition among vehicle data necessary for the update,
A remote failure diagnosis system comprising: update means for updating the contents of the database based on vehicle data received from the failed vehicle. A remote failure diagnosis method for remotely performing failure diagnosis on a diagnosis target vehicle and transmitting a failure diagnosis result to a customer,
Receiving a database update request for storing vehicle data of a failed vehicle necessary for failure diagnosis together with a running condition when a failure occurs in the failed vehicle;
Requesting a plurality of failed vehicles to transmit vehicle data under specific driving conditions among vehicle data required for updating the database;
Updating the contents of the database based on vehicle data received from the failed vehicle. A computer program for causing a computer to execute a remote failure diagnosis for remotely executing a failure diagnosis on a vehicle to be diagnosed and transmitting a failure diagnosis result to a customer,
Receiving a database update request for storing vehicle data of a failed vehicle necessary for failure diagnosis together with a running condition when a failure occurs in the failed vehicle;
Requesting a plurality of failed vehicles to transmit vehicle data under specific driving conditions among vehicle data required for updating the database;
A computer program for causing a computer to execute the step of updating the contents of the database based on vehicle data received from the failed vehicle.

Images