Method for improving customer service diagnostics for root cause analysis of an identified problem in a vehicle

Abstract

A method for improving customer service diagnosis for root cause analysis of an identified problem in a vehicle (10) by creating a functional taxonomy database (22) used in conjunction with a structural taxonomy database (20), wherein the structural taxonomy database (20) identifies structural relationships between parts of a vehicle (10) and the functional taxonomy database (22) identifies functional relationships between parts of the vehicle (10), the method comprising the steps of: Generating a diagnostic trouble code of a vehicle (10); Receiving service data from previously serviced vehicles from a storage device, the service data identifying parts serviced on the previously serviced vehicles during a respective service repair; Compiling the service data into a service repair history for each vehicle; Identifying each previously serviced vehicle within the compiled service data with at least two service repairs performed within a predetermined period of time; Identify combinations of parts serviced for each vehicle; Determining a count for each combination that indicates the frequency with which the respective combination appears in the compiled service data for the identified vehicles with at least two service repairs; Determining the combinations with count values ​​greater than a predetermined threshold; determining whether any of the combinations having count values ​​greater than the predetermined threshold are present in the structural taxonomy database (20); selecting only those combinations that are not present in the structural taxonomy database (20) and have count values ​​greater than the predetermined threshold; Updating a functional taxonomy database (22) by assigning the selected combinations to the functional taxonomy database (22), wherein the functional taxonomy database (22) and the structural taxonomy database (20) are made available to a field service technician via a computer to assist the field service technician in diagnosing the root cause; searching for structural dependencies of a searchable part using the structural taxonomy database (20) on a computer, wherein the searchable part was selected based on the diagnostic error code; Generating a list of parts that are structurally dependent on the searchable part; Selecting a part from the list of parts; and Creating a list of parts in the functional taxonomy database (22) that are functionally related to the selected part of the structural taxonomy database (20).

Description

BACKGROUND OF THE INVENTION

[0001] One embodiment generally relates to the development and improvement of customer service procedures and customer service diagnostics.

[0002] Service repairs are performed by service providers, such as a dealership's service department. The problem or symptoms related to the problem are reported to a service technician, who then attempts to diagnose and repair the vehicle. The service technician uses service diagnostics, service manuals, knowledge, and past experience to correctly identify the root cause of the problem.

[0003] A structural list of parts, components, and modules may be provided in a structural taxonomy database that represents structural relationships between components; however, it is still up to the engineer to identify a specific part from an extensive list that is causing the problem. However, the abundance of possible choices can be tedious for the engineer. Furthermore, relationships may exist that are not present in the structural taxonomy database, as a functional relationship may exist between the parts as opposed to a structural relationship that is not identified in the structural list of parts.

[0004] US 2008 / 0004764 A1 discloses a vehicle diagnostic data collector / analyzer that collects historical vehicle diagnostic data. The historical vehicle diagnostic data includes measured operating parameters from a number of different vehicles operating under a variety of normal operating conditions and vehicle component failures. Furthermore, the vehicle diagnostic data collector / analyzer performs statistical analyses for various vehicle type / operating condition combinations to establish operating parameter ranges for normal operating conditions and various fault conditions.The diagnostic data collector / analyzer also measures real-time operating parameters on specific test vehicles and evaluates similarities and differences between the measured operating parameters and the defined operating parameters, and correlates the test data with known operating conditions to diagnose potential fault conditions of vehicle components.

[0005] DE 60222821 T2 discloses a server for remote vehicle troubleshooting for performing vehicle troubleshooting from a remote location. The server comprises means for transmitting to a vehicle a troubleshooting program for performing vehicle troubleshooting at the vehicle side upon receiving a request from an owner of the vehicle at the owner's selection or at a predetermined time. Furthermore, the server comprises means for receiving from the vehicle inspection results concerning the vehicle obtained by executing the troubleshooting program. The server further comprises means for determining problem details by analyzing the inspection results, and means for transmitting the fault details to the vehicle.

[0006] US 2008 / 0065288 A1 discloses a method for diagnosing a vehicle fault, comprising receiving information about a vehicle from a customer regarding an actual vehicle fault and accessing data from the vehicle regarding the actual vehicle fault. Based on identified vehicle information, information obtained from the customer, and data accessible by the vehicle, a diagnostic program is initiated. A specific vehicle system is selected for diagnosis, wherein the vehicle system includes a specific vehicle component that may be associated with the current vehicle fault. A list of diagnostic program results is determined that defines a plurality of probable vehicle component faults for the specific vehicle system that may be associated with the actual vehicle fault.The list is used to determine how to proceed with troubleshooting the vehicle fault. A probable vehicle component fault is selected to determine whether it is the cause of the actual vehicle fault. SUMMARY OF THE INVENTION

[0007] An advantage of an embodiment is a diagnosis of a root cause of a problem for a serviced vehicle using a functional taxonomy database to identify linking relationships between the parts that may not be readily apparent from their structural relationship. The routine uses a field service repair history of serviced vehicles and identifies combinations of parts serviced for each vehicle. Parts serviced during different repairs for a vehicle but close to each other are considered. Thus, parts in two consecutive repairs for a respective vehicle that are separated by no more than a predetermined time are considered. The count is identified for each respective combination of all vehicles and is checked against a threshold count.If the count meets a threshold, a structural taxonomy database is checked to determine if the combination exists there. If the combination does not exist in the structural taxonomy database, the combination is added to the functional taxonomy database. As a result, the functional linking of the parts between the structural and functional taxonomy databases creates additional candidates that would otherwise not be apparent to the customer service technician as possible root causes from a structural perspective.

[0008] One embodiment contemplates a method for improving service diagnosis for root cause analysis of an identified problem in a vehicle by creating a functional taxonomy database used in conjunction with a structural taxonomy database. The structural taxonomy database identifies structural relationships between parts of a vehicle, and the functional taxonomy database identifies functional relationships between parts of the vehicle. A vehicle diagnostic trouble code is generated. Service data from previously serviced vehicles is received from a storage device. The service data identifies parts serviced on the previously serviced vehicles during a respective service repair. The service data is compiled into a service repair history for each vehicle.Each previously serviced vehicle within the compiled service data with at least two service repairs performed within a predetermined time period is identified. Combinations of parts serviced for each vehicle are identified. A count value for each combination is determined that indicates the frequency with which the respective combination appears in the compiled service data for the identified vehicles with at least two service repairs. The combinations with count values ​​greater than a predetermined threshold are identified. A determination is made as to whether any of the combinations with count values ​​greater than the predetermined threshold exist in the structural taxonomy database.Only those combinations that are not present in the structural taxonomy database and have count values ​​greater than the predetermined threshold are selected. A functional taxonomy database is updated by assigning the selected combinations to the functional taxonomy database. The functional taxonomy database and the structural taxonomy database are made available to a field service technician via a computer to assist the field service technician in diagnosing the root cause. Structural dependencies of a searchable part are searched using the structural taxonomy database on a computer, with the searchable part selected based on the diagnostic trouble code. A list of parts that are structurally dependent on the searchable part is generated.Furthermore, a part is selected from the list of parts and a list of parts in the functional taxonomy database that are functionally related to the selected part of the structural taxonomy database is generated. BRIEF DESCRIPTION OF THE DRAWINGS Fig. Figure 1 is a customer service and warranty report flowchart. Fig. 2 is a flowchart for creating a functional taxonomy database. Fig. Figure 3 is a flowchart for using the functional taxonomy database to diagnose a root cause of a problem. DETAILED DESCRIPTION

[0009] In Fig.1 shows a service and warranty reporting flowchart. A vehicle 10 represents any type of transportation vehicle that may experience problems requiring service repair. The vehicle 10 utilizes a service repair station 12, such as a service department at a dealership. The service technician at the service repair station diagnoses the root cause of the vehicle's problem based on the reported problem. The symptoms exhibited by the vehicle are communicated to the service technician by the vehicle's driver, or the service technician may identify the potential problem through diagnostic trouble codes (DTCs).

[0010] DTCs are generated by a diagnostic processor in the vehicle, which can assist a technician in identifying a problem with the vehicle. A DTC is a 5-digit alphanumeric code generated by the diagnostic processor in the vehicle when a problem is detected. When the diagnostic processor in the vehicle detects a fault based on sensor inputs from one or more sensors, a diagnostic algorithm analyzes the detected inputs and outputs a DTC as determined by the diagnostic algorithm. The DTC corresponds to a fault that can then be used to diagnose the problem. The DTC provides a starting point from which to diagnose the problem.

[0011] The service technician may use a service diagnostic repair manual 14 or other assistance via a computer 16. When the repair is complete, the service technician enters the repair into a warranty report database 18. The warranty report database stores the repair history of all vehicles, not only for the service station providing service, but for all vehicle service stations that are part of a warranty report system.

[0012] The service technician can also use a structural taxonomy database 20 and a functional taxonomy database 22 to assist in determining the root cause of the problem. The structural taxonomy database 20 is a structural listing of vehicle systems, subsystems, components, and subcomponents identified by their structural relationship to one another. A hierarchical example of the structural taxonomy database 20 is shown in the table below. Table 1 STRUCTURAL TAXONOMY 1 drivetrain 2 chassis 3HVAC & powertrain cooling 31 HVAC & Powertrain Cooling Engine Compartment 32 Front interior HVAC airflow 321 Front inner airflow 321.01 Front Heater Ventilation A / C Module 321.02 Suction device 321.03 Module housing / box / cover 321.04 Valve 321.05 Fan speed control 321.06 Fan movement & spiral 321.07 Evaporator 321.08 Evaporator sensor 321.09 Heater core 321.10 Cooler 322 Front inner control 33 Rear interior HVAC airflow 34 Outer airflow at the front end 4 Inside 5 Body structure 6 Outside 7 Information & Control

[0013] Each system shown in the table has a parent-child relationship with at least one subsystem (e.g., HVAC and Powertrain Cooling - Front Interior HVAC Control). Some subsystems may have a parent-child relationship with at least one other subsystem (e.g., Front Interior HVAC Control - Front Interior Control). Each subsystem has a parent-child relationship with at least one component (e.g., Front Interior Control - Evaporator). Furthermore, each component may have a parent-child relationship with at least one subcomponent. Consequently, each of the linking relationships can be easily identified by examining the structural taxonomy for a system or part.

[0014] The functional taxonomy database 22 identifies parts that have a functional relationship with a system or component in the structural taxonomy database 20. Furthermore, the functional taxonomy database 22 complements the structural taxonomy database 20 by identifying relationships between parts that may not be easily identifiable in the structural taxonomy database 20. An example of the functional taxonomy database 22 is shown in Table 2 below. Table 2 identifies components that are functionally related to the evaporator listed in Table 1. Table 2 FUNCTIONAL TAXONOMY 1 sealing component C11.06 2 Door panel assembly 432.10 3 Door frame application C 11.07.08

[0015] As shown in Table 2, parts that are from completely different classifications (e.g., sealing component C11.06) are listed compared to the evaporator 321.07. Those parts that would not be linked by the structural taxonomy database 20 are identified by the functional taxonomy database 22. Consequently, the field service technician can use the structural taxonomy database 20 and the functional taxonomy database 22 together to identify a potential root cause of the problem, which may not be readily apparent when analyzing the parts from a structural perspective.

[0016] Fig. Figure 2 illustrates a flowchart for generating the functional taxonomy database. A structural taxonomy database is provided in block 30. The structural taxonomy database includes parts grouped according to their structural relationship to one another.

[0017] In block 31, a warranty database is accessed.

[0018] In block 32, customer service data is compiled into a customer service repair history for each vehicle.

[0019] In block 33, vehicles with at least two service repairs performed within a predetermined period of time are identified. An identified vehicle that has been serviced on at least two different occasions within a predetermined period of time preferably requires that the service data for the vehicle be different. Parts serviced during different repairs for a vehicle, but where the repairs are close together in time, are considered. Consequently, parts in two consecutive repairs for a respective vehicle that are separated by no more than a predetermined time are considered. A vehicle with repairs performed within a predetermined period of time implies that the repairs are related to each other.For example, the predetermined time period can correspond to repairs performed 90 days, 60 days, or even 30 days apart. Alternatively, a vehicle with at least two service repairs performed on the same service date can be considered.

[0020] In block 34, combinations of parts identified in block 33 that were serviced during each customer service repair for each respective vehicle are compiled. Preferably, the sequence in which the parts were replaced (e.g., Part A always replaced before Part B) may be required to identify the combination. Alternatively, the sequence is not required as long as both parts are present in the combination.

[0021] In block 35, a sequence count is determined that identifies the frequency with which each combination identified in block 34 appears for the compiled data.

[0022] In block 36, a respective combination is selected and is analyzed to determine whether the count value meets a predetermined threshold.

[0023] In block 37, a determination is made as to whether the count value for the selected combination is greater than the predetermined threshold. If the count value is greater than the predetermined threshold, the combination is stored for further processing in block 38. If the determination is made that the count value for the selected combination is not greater than the predetermined threshold, the combination is discarded in block 39.

[0024] In block 40, a determination is made as to whether the counts of all identified combinations have been checked against the predetermined threshold. If a combination remains unchecked, the routine proceeds to block 41; otherwise, the routine proceeds to block 42.

[0025] In block 41, a next combination is selected, and the routine returns to block 37 to check the count against the predetermined threshold. Blocks 37, 39, 40, and 41 are repeated iteratively until all combinations have been selected and checked.

[0026] After all counts have been checked, a determination is made in block 42 as to whether any of the stored combinations is a subcombination of a larger combination that meets the predetermined threshold. For example, a combination is identified that includes a battery and an alternator. A determination is made as to whether the combination of the battery and the alternator is a subcombination of a larger combination, such as a battery, an alternator, and an accessory drive belt. The determination is based on whether the larger combination (i.e., battery, alternator, drive belt) exists and whether the larger combination meets the predetermined threshold. If the combination is a subcombination of a larger combination and meets the threshold, then the larger combination is used for further processing.If a larger combination is not present or the large combination does not meet the predetermined threshold, then the combination as originally identified is used for further processing.

[0027] In block 43, a respective combination is selected to determine whether the combination is identified in the structural taxonomy database.

[0028] In block 44, a determination is made as to whether the selected combination is already listed in the structural taxonomy database. If the combination is not listed in the structural taxonomy database, the combination is stored for further processing in block 45. If the determination is made that the combination is already listed in the structural taxonomy database, the combination is discarded in block 46.

[0029] In block 47, a determination is made as to whether all identified combinations have been checked to determine their presence in the structural taxonomy database. If any combination remains unchecked, the routine proceeds to block 48; otherwise, the routine proceeds to block 49.

[0030] In block 48, a next combination is selected, and the routine returns to block 44 to check whether the selected combination is already listed in the structural taxonomy database. Blocks 44, 46, 47, and 48 are repeated iteratively until all combinations have been selected and checked.

[0031] In block 49, each stored combination in block 45 is delivered to a skilled person. A skilled person has expert knowledge of the vehicle and its systems and components, and is aware of the failures that can occur in the vehicle. Such service professionals can include engineers, technical experts, service and maintenance personnel, statisticians, and any other person with in-depth knowledge of the vehicle's systems and components. Typically, the count value determines whether the correlation between the parts is correct; however, in certain cases, a high count value for a combination may have occurred merely by chance. That is, it is by chance that the combination has a count value greater than the predetermined threshold. Therefore, the skilled person performs a final analysis to verify that a rational relationship exists between the parts of the combination.For example, the skilled person examines a combination that has made it through the process, such as a compressor and a washer fluid reservoir. The skilled person determines whether a rational correlation exists between the two parts. The skilled person evaluates structural and functional relationships that the skilled person is aware of. From a layperson's perspective, the compressor and the washer fluid reservoir may not have any structural or functional dependence on each other. However, the skilled person has a thorough knowledge of the vehicle and may identify an indirect relationship between the two parts of the combination, e.g., that both parts share the same wiring harness. Consequently, the skilled person provides a "final check" before adding a combination to the functional taxonomy database.

[0032] If the skilled person determines that a combination is a "random correlation," then the combination is ignored in block 50. A "random correlation" exists if the skilled person determines that there is no rational correlation between the parts. If the skilled person determines that the combination is an assignable correlation, then the routine proceeds to block 51.

[0033] In block 51, the combination is added to the function taxonomy database.

[0034] Fig. Figure 3 shows a flowchart for using the functional taxonomy database to diagnose a root cause of the identified problem.

[0035] In block 60, a structural taxonomy database and a functional taxonomy database are provided for access by a customer service technician via a computer. The databases may reside on the computer's hard disk and be periodically updated, or they may be accessed via an online communication connection.

[0036] In block 61, the customer service technician accesses the structural taxonomy database via the computer.

[0037] In block 62, the service technician initiates a search for structural dependencies in the structural taxonomy database via a computer by entering a system or component.

[0038] In block 63, the service technician is presented with a list of structural dependencies related to the system or component entered via the computer.

[0039] In block 64, the service technician selects a candidate part that the service technician determines may be the root cause of the problem or may be related to the cause of the problem.

[0040] In block 65, the service technician is presented with a functional taxonomy list of parts that are functionally related to the selected candidate. The parts listed in the functional taxonomy database, generated by selecting the candidate in the structural taxonomy database, are made available to the service technician to assist in diagnosing the root cause of the problem. Consequently, the functional linking of the parts between the structural and functional taxonomy databases creates additional candidates that would otherwise not be apparent to the service technician as possible root causes.

[0041] Although certain embodiments of the present invention have been described in detail, those skilled in the art to which this invention relates will recognize various alternative designs and embodiments for practicing the invention as defined by the following claims.

Claims

[1] A method for improving customer service diagnosis for root cause analysis of an identified problem in a vehicle (10) by creating a functional taxonomy database (22) used in conjunction with a structural taxonomy database (20), wherein the structural taxonomy database (20) identifies structural relationships between parts of a vehicle (10) and the functional taxonomy database (22) identifies functional relationships between parts of the vehicle (10), the method comprising the steps of: Generating a diagnostic trouble code of a vehicle (10); Receiving service data from previously serviced vehicles from a storage device, the service data identifying parts serviced on the previously serviced vehicles during a respective service repair; Compiling the service data into a service repair history for each vehicle; Identifying each previously serviced vehicle within the compiled service data with at least two service repairs performed within a predetermined period of time; Identify combinations of parts serviced for each vehicle; Determining a count for each combination that indicates the frequency with which the respective combination appears in the compiled service data for the identified vehicles with at least two service repairs; Determining the combinations with count values ​​greater than a predetermined threshold; determining whether any of the combinations having count values ​​greater than the predetermined threshold are present in the structural taxonomy database (20); selecting only those combinations that are not present in the structural taxonomy database (20) and have count values ​​greater than the predetermined threshold; Updating a functional taxonomy database (22) by assigning the selected combinations to the functional taxonomy database (22), wherein the functional taxonomy database (22) and the structural taxonomy database (20) are made available to a field service technician via a computer to assist the field service technician in diagnosing the root cause; searching for structural dependencies of a searchable part using the structural taxonomy database (20) on a computer, wherein the searchable part was selected based on the diagnostic error code; Generating a list of parts that are structurally dependent on the searchable part; Selecting a part from the list of parts; and Creating a list of parts in the functional taxonomy database (22) that are functionally related to the selected part of the structural taxonomy database (20). [2] The method of claim 1, wherein the step of determining the combinations having counts greater than a predetermined threshold further comprises the step of: Determining whether each particular combination is a subcombination of a larger combination that satisfies the predetermined threshold, wherein, if the larger combination satisfies the count value, the structural taxonomy database (20) is queried to determine whether the larger combination is present therein. [3] The method of claim 2, wherein the larger combination is updated in the functional taxonomy database (22) in response to the larger combination not being present in the structural taxonomy database (20). [4] The method of claim 1, wherein a skilled person reviews the combinations to verify an acceptable correlation between the subcomponents of the combination before adding them to the functional taxonomy database (22). [5] The method of claim 4, wherein combinations having counts greater than the predetermined threshold present in the structural taxonomy database (20) are determined. [6] The method of claim 1, wherein the predetermined period of time is less than 90 days. [7] The method of claim 1, wherein the predetermined period of time is less than 60 days. [8] The method of claim 1, wherein the predetermined period of time is less than 30 days. [9] The method of claim 1, wherein an identified combination is based on a specific repair sequence when replacing the parts.

Images